paint-brush
FaaS-Architektur und nachweisbare Fairness für ML-Systemeby@escholar
266

FaaS-Architektur und nachweisbare Fairness für ML-Systeme

In diesem Abschnitt wird die Architektur von Fairness as a Service (FaaS) erläutert, einem revolutionären System zur Gewährleistung des Vertrauens in Fairness-Audits beim maschinellen Lernen. Die Diskussion umfasst das Bedrohungsmodell, den Protokollüberblick und die wesentlichen Phasen: Einrichtung, Kryptogrammgenerierung und Fairnessbewertung. FaaS führt einen robusten Ansatz ein, der kryptografische Beweise und überprüfbare Schritte umfasst und eine sichere Grundlage für faire Bewertungen in der ML-Landschaft bietet.
featured image - FaaS-Architektur und nachweisbare Fairness für ML-Systeme
EScholar: Electronic Academic Papers for Scholars HackerNoon profile picture

Dieses Papier ist auf arxiv unter der CC BY 4.0 DEED-Lizenz verfügbar .

Autoren:

(1) Ehsan Toreini, University of Surrey, Großbritannien;

(2) Maryam Mehrnezhad, Royal Holloway University of London;

(3) Aad Van Moorsel, Universität Birmingham.

Linktabelle

Zusammenfassung und Einführung

Hintergrund und verwandte Arbeiten

FaaS-Architektur

Implementierung und Leistungsanalyse

Abschluss

Danksagung und Referenzen

3 FaaS-Architektur

In diesem Abschnitt stellen wir die Architektur unseres Systems vor (Abb. 1) und beschreiben seine Funktionen. Die FaaS-Architektur umfasst Stakeholder in drei Rollen: A) ML-System: ein System, das die Daten und den ML-Algorithmus besitzt, B) Fairness Auditor Service: ein Dienst, der die faire Leistung des ML-Systems berechnet, und C) Universal Verifier: jeder der über das technische Fachwissen und die Motivation verfügt, den Auditierungsprozess zu überprüfen.

3.1 Bedrohungsmodell

Das Design und die Implementierung der Sicherheit der Parteien, die die jeweiligen Protokollrollen implementieren (ML-System, Fairness Auditor Service und Universal Verifier) (Abb. 1), sind unabhängig voneinander. Die zwischen den Rollen stattfindende Kommunikation setzt kein Vertrauen zwischen den Parteien voraus; Daher müssen allen Ansprüchen Validierungsnachweise beigefügt sein (für die wir ZKP verwenden). Wir gehen davon aus, dass das Auditor-System anfällig für verschiedene Angriffe und nicht vertrauenswürdig ist. Daher müssen die im Fairness Auditor System gespeicherten Daten in allen Phasen verschlüsselt, manipulationssicher und überprüfbar sein. Darüber hinaus gehen wir davon aus, dass der Kommunikationskanal zwischen dem ML-System und dem Fairness-Prüfer nicht geschützt ist. Daher müssen die sensiblen Daten vor Beginn der Übertragung verschlüsselt werden. Eine Einigung über die kryptografischen Grundelemente wird jedoch bereits im Vorfeld der Protokollsequenz erfolgen.


Bei FaaS gehen wir davon aus, dass das ML-System beim Versenden der Kryptogramme der Originalbezeichnungen der Datensatzbeispiele ehrlich ist. Man könnte gegen eine solche Annahme argumentieren und diskutieren, dass das ML-System möglicherweise die Absicht hat, den Auditor Service und damit auch die Prüfer zu täuschen, indem es die tatsächlichen Bezeichnungen des Datensatzes ändert. Beispielsweise würde das ML-System die Kryptogramme der tatsächlichen und der vorhergesagten Etiketten so ähnlich wie möglich bereitstellen, damit der Prüfer zu dem Schluss kommt, dass die Algorithmen fair sind. Dies ist ein interessantes Gebiet für weitere Forschung. Dies kann beispielsweise durch die unabhängige Bereitstellung der Kryptogramme der tatsächlichen Etiketten an den Auditor Service behoben werden. Beispielsweise kann der Verifizierer einen Datensatz besitzen, den er einem ML-System bereitstellt. Der Verifizierer entscheidet dann separat über die gewünschten Werte für die tatsächlichen Etiketten und leitet diese an den Auditor-Dienst weiter. Auf diese Weise ist es für das ML-System weitaus weniger klar, wie es die an den Prüfer gesendeten Daten manipulieren kann, da einige der Etiketten von woanders stammen.


Die interne Sicherheit der Rollen geht über FaaS hinaus. Das ML-System selbst muss zusätzliche Maßnahmen zum Schutz seiner Daten und Algorithmen in Betracht ziehen. Wir gehen davon aus, dass das ML-System die Daten und Vorhersagen ehrlich darstellt. Dies ist eine vernünftige Annahme, da der Anreiz, sich ethisch zu verhalten, im Gegensatz zur Unehrlichkeit bei der Teilnahme am Fairness-Audit-Prozess steht. Dies wird im Abschnitt „Diskussion“ ausführlicher besprochen.


Tabelle 2: Mögliche Permutationen der 3-Bit-Darstellung eines Eintrags in den Originaldaten.

3.2 Protokollübersicht

Die Hauptsicherheitsprotokollsequenz findet zwischen dem ML-System und dem Fairness Auditing Service oder kurz Auditor statt. Beachten Sie, dass wir zwar drei Rollen in unserer Architektur vorschlagen, die Kommunikation jedoch hauptsächlich zwischen den beiden oben genannten Rollen stattfindet und sich jeder universelle Verifizierer an den Prüferdienst (der das Fairness Board vertritt) wenden kann, wenn er die Berechnungen anfechten möchte.


Das ML-System ist für die Implementierung und Ausführung des ML-Algorithmus verantwortlich. Es hat Daten als Eingabe und führt einige Vorhersagen durch (je nach Anwendungsfall und Zweck), die die Ausgabe bilden (Abb. 1). Der Fairness Auditor Service erhält Informationen vom ML-System und bewertet seine Fairness-Leistung durch Berechnung einer Fairness-Metrik. Anschließend wird das Ergebnis für die Metrik an das ML-System zurückgegeben. Außerdem veröffentlicht es die Berechnungen in einem Fairness Board zur öffentlichen Überprüfung. Das Public Fairness Board ist ein öffentlich zugängliches, schreibgeschütztes Fairness Board (z. B. eine Website). Der Prüfer hat lediglich das Recht, Daten (und die entsprechenden Nachweise) dem Fairness Board beizufügen. Außerdem überprüft der Prüfer die Authentizität, Richtigkeit und Integrität der Daten vor der Veröffentlichung.

3.3 Protokollsequenz

Dieses Protokoll besteht aus drei Phasen: Einrichtung, Kryptogrammgenerierung und Berechnung der Fairnessmetrik.

3.3.1 Phase I: Einrichtung

In dieser Phase einigen sich das ML-System und der Auditor auf die Anfangseinstellungen. Wir gehen davon aus, dass das Protokoll in der multiplikativen zyklischen Gruppeneinstellung funktioniert (z. B. DSA-ähnliche Gruppe (Digital Signature Algorithm) [18]), aber es kann auch in additiven zyklischen Gruppen (ECDSA-ähnliche Gruppen (Elliptic Curve Digital Signature Algorithm)) funktionieren [18]. ]). Der Prüfer und das ML-System einigen sich vor Beginn des Protokolls öffentlich auf (p, q, g). Seien p und q zwei große Primzahlen mit q|(p − 1). In einer multiplikativen zyklischen Gruppe (Z ∗ p ) ist Gq eine Untergruppe der Primzahlordnung q und g ihr Generator. Der Einfachheit halber gehen wir davon aus, dass das Decision-Diffie-Hellman-Problem (DDH) außerhalb des Anwendungsbereichs liegt [31].

Als nächstes generiert das ML-System mithilfe von DSA oder ECDSA einen öffentlichen/privaten Paarschlüssel und veröffentlicht die öffentlichen Schlüssel im Fairness Board. Der Schutz des privaten Schlüsselpaars hängt von der Sicherheitsarchitektur des ML-Systems ab und wir gehen davon aus, dass der private Schlüssel in einer industriellen Standardpraxis sicher gespeichert wird (z. B. mithilfe des sicheren Speichermoduls an Bord).


Kryptogrammtabelle: Nach anfänglichen Vereinbarungen erstellt das ML-System eine Kryptogrammtabelle mit n Zeilen, die der Anzahl der Proben in ihrem Testdatensatz entsprechen. Wir werden diese Tabelle im Rest dieses Dokuments als Kryptogrammtabelle bezeichnen. Falls das ML-System die Anzahl der Proben im Testsatz nicht offenlegen möchte, können sich der Prüfer und das ML-System öffentlich auf n einigen. In diesem Fall muss n groß genug sein, damit die universellen Prüfer mit dem Ergebnis zufrieden sind.


Jede Zeile in der Kryptogrammtabelle fasst drei Parameter zusammen: (1) den Mitgliedschaftsstatus der geschützten Gruppe, (2) ihre tatsächliche Bezeichnung und (3) die vom ML-Modell vorhergesagte Bezeichnung. Jede Zeile enthält das verschlüsselte Format der drei Parameter sowie Beweise für deren Richtigkeit. Eine Kryptogrammtabelle in der Setup-Phase ist in Tabelle 3 dargestellt. Im einfachsten Fall ist jeder Parameter binär. Daher erzeugen die kombinierten Parameter insgesamt acht Permutationen. In der Einrichtungsphase wird die Tabelle so generiert, dass sie alle acht möglichen Permutationen und ihre Beweise für jede Datenprobe enthält. Die Gesamtstruktur der Permutationen ist in Tabelle 2 dargestellt. Jede Zeile erfüllt vier Eigenschaften: (a) man kann leicht überprüfen, ob ein einzelnes Kryptogramm die verschlüsselte Version einer der acht möglichen Permutationen ist, (b) wenn überhaupt überprüfbar Wenn ein einzelnes Kryptogramm ausgewählt wird, kann man nicht festlegen, welche Permutationen das aktuelle Kryptogramm darstellt, (c) für jeweils zwei Kryptogramme, die aus einer einzelnen Zeile ausgewählt werden, kann jeder sie voneinander unterscheiden, und (d) es wird eine Reihe von Kryptogrammen gegeben, die willkürlich ausgewählt werden Anhand jeder Zeile als Menge kann man leicht überprüfen, wie viele Fälle für jede „Permutation“ in der Menge vorhanden sind.


Die Generierung der Kryptogrammtabellenfunktionen erfolgt nach folgendem Ablauf:


Schritt (1): Für jede der n Stichproben generiert das System einen zufälligen öffentlichen Schlüssel g xi, wobei xi der private Schlüssel ist und xi ∈ [1, q − 1].


Schritt (3): Die entsprechende Spaltennummer, die dem Dezimalwert der Binärkodierung entspricht, wird aus der Kryptogrammtabelle ausgewählt, um die Fairness-Prüfungstabelle zu vervollständigen (wie in Tabelle 2 gezeigt).


Schließlich wird die generierte Fairness-Auditing-Tabelle vom ML-System digital signiert und dann über den Fairness-Auditing-Service gesendet.

3.3.3 Phase III: Fairnessbewertung

Zunächst erhält der Fairness-Auditing-Dienst die Fairness-Auditing-Tabelle, verifiziert die digitale Signatur und die ZKPs und veröffentlicht die Inhalte im Fairness-Board.


An dieser Stelle erweitern wir jede dieser Gleichungskomponenten, um sie miteinander zu vergleichen.


Dieser Prozess ist rechenintensiv, insbesondere wenn die Anzahl der Datenproben in der Fairness-Auditing-Tabelle groß ist. In diesem Fall kann der Fairness-Prüfer die Deklaration der Permutationszahl an das ML-System delegieren. Der Prüfer erhält weiterhin die Fairness-Prüfungstabelle und die entsprechenden ZKPs. Es kann die Fairness-Prüfungstabelle im Fairness-Board speichern, die Fairness berechnen und die Richtigkeit der deklarierten Permutationszahlen überprüfen. Der universelle Verifizierer kann dieselben Schritte ausführen, um die Berechnungen der Fairness-Metrik mithilfe der Fairness-Auditing-Tabelle zu überprüfen, die über das Fairness Board öffentlich zugänglich ist.


Am Ende dieser Phase verwendet der Prüfer die ermittelten Zahlen, um die Fairness-Metrik zu berechnen und die Informationen öffentlich zu veröffentlichen. Die Anzahl jeder Permutation gibt die Gesamtleistung des ML-Algorithmus für jede der Gruppen mit geschütztem Attribut an. Tabelle 4 zeigt die Permutationen und wie sie mit der Fairnessmetrik des ML-Systems zusammenhängen. Die Kryptogrammtabelle und die Ergebnisse werden im Fairness Board veröffentlicht (Abb. 1)