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).    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. Kryptogrammtabelle:  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)

EScholar Technologies

EScholar

Dieses Audio ist in der Originalsprache der Geschichte produziert!

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

About Author

KOMMENTARE

Hängeetiketten

DIESER ARTIKEL WURDE VORGESTELLT IN

Related Stories

HackerNoon Decoded 2024: Wir feiern unsere Remote-Work-Community!

Genuine Content Creation in the Age of AI: Why Startups Need Quality Content

Welcome to HackerNoon Decoded: The Best of 2024 Tech Blogging

HackerNoon Decoded 2024: Celebrating Our Writing Community!

HackerNoon Decoded 2024: Wir feiern unsere Remote-Work-Community!

Genuine Content Creation in the Age of AI: Why Startups Need Quality Content

Welcome to HackerNoon Decoded: The Best of 2024 Tech Blogging

HackerNoon Decoded 2024: Celebrating Our Writing Community!

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps