Privatsphärefreundliches maschinelles Lernen

Model Inversion bietet Angreifenden die Möglichkeit, durch Anfragen an ein Modell Teile der Trainingsdaten zu rekonstruieren, ohne dabei tiefgreifendes Vorwissen über die Daten zu benötigen. Dies geschieht in der Regel per Black-Box-Zugriff, erweiterte Angriffszenarien in White- bzw. Gray-Box-Szenarien sind jedoch ebenfalls möglich [37]. Ein bekanntes Beispiel ist in Abb. 2 zu sehen. Fredrikson u. a. [11] gelang hier die Rekonstruktion eines Portraitfotos mit erkennbaren Merkmalen aus den Trainingsdaten eines Gesichtserkennungsmodells [11]. In bestimmten Szenarien genügt es demnach, wiederholt gezielte Anfragen an ein Modell zu stellen, um Informationen aus den Trainingsdaten zu rekonstruieren. Diese Art des Angriffs wird seit der Veröffentlichung weiter erforscht und es wurden bereits verschiedene Varianten und Weiterentwicklungen publiziert (z. B. [40]). Allerdings scheinen erfolgreiche Model-Inversion-Angriffe nur in bestimmten Szenarien möglich zu sein: So zeigen etwa Shokri u. a. [36], dass der Angriff lediglich den Durchschnitt der Trainingsdaten einer Datenklasse aufdecken kann, was in vielen Anwendungsfällen zu unbrauchbaren Ergebnissen führt [36]. Dieser Zusammenhang wird durch Abb. 3 verdeutlicht.

Das Ziel eines Membership-Inference-Angriffs [36] ist es, für einzelne Datenpunkte zu entscheiden, ob sie Teil des Trainingsdatensatzes eines ML-Modells waren. Das Anwendungsgebiet eines ML-Algorithmus ist hierbei ausschlaggebend dafür, inwieweit der Angriff zu Privatsphäreverletzungen führen kann. Betrachtet man etwa einen Algorithmus, der Personen, die an einer seltenen genetischen Grunderkrankung leiden, die Wahrscheinlichkeit für eine notwendige Operation vorhersagt, dann kann in diesem Szenario bereits das Wissen über die bloße Zugehörigkeit zum Trainingsdatensatz privatsphäreverletzend sein.

Auch dieser Angriff kann per Black-Box-Zugriff realisiert werden: Zugrunde liegt hierbei die Idee, dass sich die Ausgaben des Modells für arbiträre Daten etwas von Ausgaben für jene Daten unterscheiden, mit denen das Modell trainiert wurde. Da das Modell während des Trainings schrittweise an die Trainingsdaten angepasst wurde, sind Vorhersagen für Trainingsdaten in der Regel exakter bzw. eindeutiger.

Eine zunächst wirksame Methode gegen Membership-Inference-Angriffe ist es, die Ausgabe von ML-Modellen zu reduzieren, sodass in einer Klassifizerungsaufgabe statt Wahrscheinlichkeitswerten für Klassenzugehörigkeiten lediglich der Name der wahrscheinlichsten Klasse ausgegeben wird („label-only“). Jedoch sind Membership-Inference-Angriffe gut erforscht und es wurden Varianten entwickelt, die auch für Label-only-ML-Algorithmen funktionieren [7]. Andere Arbeiten erlauben eine Erhöhung der Angriffsgenauigkeit im White-Box-Szenario, indem zusätzlich Informationen aus den Modellparametern berücksichtigt werden [22].

In der Literatur werden die beiden Fälle Zugehörigkeit und Nicht-Zugehörigkeit eines einzelnen Datenwertes zu den Trainingsdaten in der Regel scharf voneinander abgegrenzt: Angreifende evaluieren ihren Angriff für Daten, die exakt in der vorliegenden Form Teil der Trainingsdaten waren, bzw. für Daten, die sich maßgeblich von Trainingsdaten unterscheiden. Membership Inference wäre aber auch für Daten denkbar, die Trainingsdaten ähneln – etwa für Fotos aus einer leicht veränderten Perspektive oder tabellarische Daten mit geringer Unschärfe. Angreifende könnten dann mehrere Anfragen mit jeweils verschiedenen Varianten der Informationen, die über einen potenziellen Trainingsdatenwert vorliegen, an das Modell stellen. Eine systematische Auswertung der Modell-Rückgabewerte könnte dann ebenfalls Rückschlüsse auf die verwendeten Trainingsdaten zulassen.

Ähnlich wie Membership Inference zielen auch Property-Inference-Angriffe auf die einem Modell zugrunde liegenden Trainingsdaten ab [2]. Die meisten Property-Inference-Angriffe haben das Ziel, globale Eigenschaften der Trainingsdaten anhand des Modellverhaltens (im Black-Box-Szenario) oder anhand der Modellparameter (im White-Box-Szenario) zu extrahieren. Da diese Eigenschaften oft nicht in einem Zusammenhang zu der vom Modell gelernten Aufgabe stehen, können sie mehr über das Modell bzw. dessen Trainingsdaten verraten als von ihren Modellbesitzern beabsichtigt.

Beispielsweise können per Property Inference stochastische Eigenschaften in den Trainingsdaten wie die Geschlechter- oder Altersverteilung aus Modellen extrahiert werden [12]. In einigen Fällen kann dies problematisch sein, z. B. wenn eine Firma ein ML-Modell mit ihren Kundendaten trainiert und das Modell im Anschluss veröffentlichen möchte, aber keine Rückschlüsse auf die Demografie ihres Kundenstamms möglich sein sollen. Für kollaborative Lernszenarien sind Property-Inference-Angriffe von besonderer Bedeutung, da hier die Privatsphäre einzelner Teilnehmer explizit geschützt werden soll und das Extrahieren von Trainingsdateneigenschaften diese verletzen kann [26].

Ziel des Model-Extraction-Angriffs ist die Übertragung eines Zielmodell-Verhaltens auf ein eigenes Modell, um die aufwendige Trainingsphase für das eigene Modell zu umgehen [31]. Somit ist dieser Angriff ausschließlich für das Black-Box-Szenario konzipiert, da in einem White-Box-Szenario die Modellparameter ohnehin bekannt sind. Insbesondere im MLaaS-Kontext kann dieser Angriff kritisch sein, da hier oft für den Zugriff auf ein Modell bezahlt werden muss und dies durch das bösartige Anfertigen eines gleichwertigen Modells unter Umständen umgangen werden kann. Somit zielt dieser Angriff eher auf Betriebsgeheimnisse ab als auf sensible Informationen, die aus datenschutzrechtlichen Gründen geschützt werden müssen.

Nicht jedes ML-Modell ist anfällig für die genannten Privatsphäreangriffe. Die Angreifbarkeit eines Modells hängt von vielen Faktoren ab: Beispielsweise wird sie beeinflusst von der Struktur und der Größe des Trainingsdatensatzes, der Anzahl der Trainingsiterationen und der dabei verwendeten Lernrate (siehe Teil 1 im vorhergehenden Heft). Abgesehen von der Empfehlung, die Überanpassung von Modellen zu vermeiden, lassen sich kaum pauschale Aussagen zu Privatsphäreschwachstellen treffen. Daher ist es sinnvoll, entwickelte Modelle individuell zu überprüfen. Die frei zugänglichen Werkzeuge PrivacyRaven [19] und ML Privacy Meter [29] können dabei helfen, indem sie ein gegebenes Modell automatisiert per Membership Inference oder Model Extraction angreifen und die jeweilige Angreifbarkeit quantifizieren. Dies kann in manchen Fällen auch dabei unterstützen, durch Vorher-Nachher-Analysen den Erfolg von Gegenmaßnahmen, wie sie etwa im nächsten Abschnitt beschrieben werden, zu verifizieren.

Differential Privacy (DP) ist eine von Dwork u. a. [10] entwickelte Metrik [10], die sich in den vergangenen Jahren zum „de-facto Standard für privatsphärefreundliche Datenanalyse“ entwickelt hat [32]. Das Ziel von DP ist es, die Genauigkeit der Datenanalyse zu maximieren, während die Identifizierbarkeit einzelner Individuen in den zugrunde liegenden Daten minimiert wird. Dabei folgt DP der Idee, dass Außenstehende bei einer Auswertung auf einem differentially private Datensatz nicht ermitteln können, ob sich die Daten eines bestimmten Individuums im Datensatz befunden haben. Auf diese Weise können ML-Algorithmen unter anderem resistent gegen Privatsphäreangriffe gemacht werden, die wie Membership Inference auf einzelne Individuen in Trainingsdatensätzen abzielen.

DP kann dabei an verschiedenen Punkten der Datenverarbeitung ansetzen: Lokale DP wird auf den Eingabe-Datensatz angewendet, während globale DP die Ausgabe eines Algorithmus verändert und algorithmische DP in die Zwischenergebnisse von iterativen Algorithmen eingreift.

Ein Beispiel für algorithmische DP im ML-Kontext haben Abadi u. a. [1] vorgestellt. Ihr Ansatz fügt während des Trainings von neuronalen Netzen der Lernfunktion (hier: stochastic gradient descent) in jeder Iteration gezielt Rauschen hinzu, um DP zu erreichen [1].

Lokale DP kann insbesondere in verteilten ML-Szenarien wie Federated Learning genutzt werden. Dies ermöglicht es den teilnehmenden Parteien, ihre Daten lokal mit Privatsphäregarantien zu verändern. Anschließend können die so geschützten Daten im Trainingsprozess von Federated Learning (siehe folgender Abschnitt) verwendet werden [32].

DP bringt drei wichtige Eigenschaften mit sich: Einerseits ist DP kompositionsfähig (engl. composable), sodass die Komposition mehrerer DP-Mechanismen weiterhin differentially private ist. Andererseits ist DP robust gegenüber Hintergrundinformationen: Die Privatsphäregarantie von DP ist unabhängig vom möglichen Hintergrundwissen von Angreifenden, sodass ein Kombinieren der Algorithmenausgaben mit anderen Datenquellen keinen Erkenntnisgewinn aus Sicht der Angreifenden ermöglicht. Außerdem bietet DP Gruppenprivatsphäre (engl. group privacy), sodass korrelierte Eingaben (beispielsweise mehrere Datensätze zu einer Person) die Privatsphäregarantien nicht übermäßig abschwächen [1, 10].

Allerdings kann die Anwendung von DP in ML-Algorithmen dahingehend problematisch sein, dass die ohnehin schwer erklärbaren Prozesse des ML durch DP an zusätzlicher Komplexität gewinnen und für Menschen schwerer nachvollziehbar werden. Außerdem sind die Anwendungsmöglichkeiten mancher DP-Techniken auf bestimmte Datentypen beschränkt. Während die Reihenfolge tabellarischer Daten problemlos neu gemischt werden kann, ist dies für die Pixelreihenfolge auf Bildern nicht ohne Weiteres möglich. Obwohl bei Bilddaten geringfügiges Verrauschen, eine gängige Praxis zum Erreichen von DP, technisch ohne Weiteres möglich ist, sind die Auswirkungen von verrauschten Bilddaten für ML-Algorithmen mitunter unklar: Einerseits gibt es Angriffe gegen ML-Modelle mit sogenanntem adversarial noise (etwa: „bösartiges Rauschen“) in Trainingsdaten, wodurch Angreifende den Trainingsprozess bzw. das Modellverhalten zu ihren Gunsten manipulieren können [14]. Andererseits wurde gezeigt, dass das Hinzufügen von Rauschen in Trainingsdaten als Regularisierungsmethode eingesetzt werden kann, wodurch ein Modell weniger zur Überanpassung neigt, die ein häufiges Problem im Bereich des ML darstellt [39]. Vor einem großflächigen Einsatz von DP, etwa im Bereich der medizinischen Bildanalyse, sollte daher noch weitere Forschung betrieben werden [20].

Die Trainingsphase für FL funktioniert dabei wie folgt: Der Server initialisiert zunächst ein ML-Modell \(s_{0}\). Der Server wählt nun für jede Trainingsrunde \(i\) eine Menge von \(n\) Parteien aus, die in dieser Runde am Training des Modells beteiligt sind. Diese Parteien laden das aktuelle Modell \(s_{i}\) vom Server und trainieren \(s_{i}\) mit lokalen Daten weiter, wodurch das aktualisierte Modell \(s_{i}^{\prime}\) entsteht. Das Modell \(s_{i}^{\prime}\) (in der Praxis meist lediglich die Differenz zu Modell \(s_{i}\)) wird zurück an den Server geschickt, auf dem das Update \(s_{i}^{\prime}\) mit den Updates aller anderen Parteien der aktuellen Trainingsrunde zu \(s_{i+1}\) kombiniert wird. Dies kann etwa durch die Berechnung des Durchschnitts aller Updates geschehen. In der nächsten Runde wird nun das weiterentwickelte Modell \(s_{i+1}\) trainiert. Die Anzahl der Trainingsrunden kann variieren und wird vom zentralen Server festgelegt. Das Training kann (je nach Einsatzgebiet) effizienter sein, wenn die am Training beteiligten Parteien von Runde zu Runde variieren [23, 25]. Der Ablauf einer Runde in der Trainingsphase wird in Abb. 5 dargestellt.

Ein bekanntes Anwendungsbeispiel für FL ist Gboard, die Touch-Tastatur von Google [16]. Diese bietet unter anderem die Vorhersage der nächsten Wörter, basierend auf dem bereits eingegebenen Text. An der Modellentwicklung sind hunderte Millionen Android-Geräte beteiligt, die die Modellupdates jeweils nachts während ihres Akkuladevorgangs berechnen.

Auch wenn die Trainingsdaten der Teilnehmenden während des FL-Trainings nicht aggregiert oder weitergegeben werden, können unter Umständen sensible Informationen aus individuellen Modellupdates extrahiert werden. Das Vorgehen ähnelt hier den eingangs beschriebenen Angriffen [18]. Abhilfe kann beispielsweise gezieltes Verrauschen der Modellupdates mithilfe von Differential Privacy oder der Einsatz von Secure Multiparty Computation schaffen [4, 23].

Besonders in verteilten Szenarien kann Secure Multiparty Computation (SMPC) eine der Grundlagen für privatsphärefreundliches ML bilden [8]. SMPC erlaubt es mehreren Parteien \(P_{1},\dots,P_{n}\), eine Funktion \(f\) auf ihren jeweiligen persönlichen Eingaben \(x_{1},\dots,x_{n}\) gemeinsam zu berechnen. Im Zuge der Berechnung erlangt jedoch keine Partei \(P_{i}\) Zugriff auf Informationen, die über ihre eigene Eingabe \(x_{i}\) und das Ergebnis der Berechnung \(y=f(x_{1},\dots,x_{n})\) hinausgehen. Dieses Prinzip wird in Abb. 6 dargestellt.

Um dieses Ziel zu realisieren, kommen in SMPC-Protokollen üblicherweise verschiedene Techniken zum Einsatz. Ein Beispiel für Secure Two-Party Computation (2PC) sind sogenannte Garbled Circuits [38], die insbesondere in Szenarien eingesetzt werden können, in denen die Trainingsdaten auf zwei nicht kollaborierende Parteien verteilt sind [28]. So könnten etwa zwei Krankenhäuser ein Modell mit Patientendaten trainieren, ohne dabei die Daten selbst an Dritte weiterzugeben. Im Kontext von Federated Learning kann ein aus dem SMPC-Bereich stammendes Secure-Aggregation-Protokoll dabei helfen, die Modellupdates einzelner Geräte zu kombinieren, ohne dabei Einsicht in die individuellen Beiträge zu gewähren (vgl. lokale Privatsphäre im Abschnitt „Differential Privacy“) [4]. Dies kann die privatsphärefreundliche Nutzung von anonymisierten Daten, die z. B. bei der Nutzung von Smartphones entstehen, für das Training von ML-Modellen erleichtern.

Neben der Trainingsphase kann auch die Inferenzphase in verteilten Szenarien durch SMPC geschützt werden. So erlaubt etwa das Framework MiniONN [24] das Überführen beliebiger neuronaler Netze in SMPC-geschützte Netze für eine verteilte Inferenzphase.

Ein wichtiges Auswahlkriterium für ein geeignetes SMPC-Framework ist das Angreifermodell, vor dem geschützt werden soll. Grundsätzlich wird zwischen honest-but-curious (auch: semi-honest oder passiv) und malicious (aktiv) unterschieden: Während sich im honest-but-curious-Modell alle Teilnehmenden so verhalten, wie es das Protokoll vorschreibt und lediglich die Informationen nutzen, die ihnen preisgegeben werden, können malicious Angreifende auch vom Protokoll abweichen und so den Ablauf manipulieren. Die meisten implementierten Frameworks (z. B. MOTION [5]) schützen gegen das etwas schwächere honest-but-curious-Angreifermodell. Ein Schutz gegen aktive Angreifende ist in der Regel aufwendiger, wird aber beispielsweise im MP-SPDZ-Framework ermöglicht [21].

Beim Einsatz von SMPC muss ein besonderes Augenmerk auf die Recheneffizienz der eingesetzten Algorithmen gelegt werden. Eine achtlose Kombination von ML und SMPC kann ansonsten unverhältnismäßig hohe Rechenaufwände nach sich ziehen. Hierbei spielen insbesondere die Anzahl an beteiligten Parteien und die Komplexität der benötigten Berechnungen, etwa beim Training eines neuronalen Netzes, eine Rolle [6]. Einem produktiven Einsatz von SMPC steht dieser Aspekt derzeit häufig noch im Weg.

In der Mathematik wird ein Homomorphismus als eine Abbildung verstanden, die die Elemente einer Menge auf eine andere Menge abbildet und dabei deren mathematische Struktur erhält. Daten, die per homomorpher Verschlüsselung (engl. homomorphic encryption, HE) verschlüsselt wurden, behalten ihre Struktur insofern, als dass auf ihrer verschlüsselten Form Berechnungen durchgeführt werden können, die Operationen auf den unverschlüsselten Daten entsprechen. Beispielsweise lässt sich so das verschlüsselte Produkt \(E(a*b)\) zweier verschlüsselter Zahlen \(E(a)\) und \(E(b)\) als \(E(a)\otimes E(b)\) berechnen, ohne die Daten entschlüsseln zu müssen. Die Verwendung unterschiedlicher Operationen \(*\) und \(\otimes\) für die Multiplikation zweier Zahlen in unverschlüsseltem bzw. verschlüsselten Zustand liegt darin begründet, dass es sich dabei – abhängig vom verwendeten HE-Schema – auch um unterschiedliche Operationen handeln kann. Dieser Zusammenhang wird in Abb. 7 dargestellt. HE wurde erstmals 1978 von Rivest u. a. [34] im Zusammenhang mit privatsphärefreundlichen Datenanalysen vorgeschlagen [34].

Im Kontext von ML kann HE für verschiedene Verfahren genutzt werden. Dabei können die jeweiligen Berechnungsschritte während der Trainings- und/oder Inferenzphase durch entsprechende HE-Operationen auf verschlüsselten Daten ersetzt werden. So haben Graepel u. a. [15] mit ML Confidential für verschiedene Klassifizierungsverfahren gezeigt, wie sowohl während der Trainingsphase mit homomorph verschlüsselten Daten ein Modell trainiert werden kann als auch in der Inferenzphase verschlüsselte Daten klassifiziert werden können [15].

Je nach verwendeter HE-Ausprägung sind die möglichen Rechenoperationen eingeschränkt: Partially HE erlaubt nur eine einzige Operation auf verschlüsselten Daten, beispielsweise die Multiplikation. Anwendungen mit Somewhat HE und Leveled HE ermöglichen verschiedene Rechenoperationen, beispielsweise Multiplikation und Addition, schränken jedoch die möglichen Gesamtberechnungen etwa in Form der maximalen Tiefe der sich ergebenden Schaltkreise ein. Die 2009 entwickelte Fully HE (FHE) [13] schränkt die Rechenoperationen grundsätzlich nicht ein. Bei jeder Operation werden die verwendeten verschlüsselten Daten allerdings etwas verrauscht, weshalb nach einigen Operationen sog. Bootstrapping (Neuberechnung und Wiederverschlüsselung) ausgeführt werden muss, um das Rauschen zurückzusetzen. Die Anwendungsmöglichkeiten von HE sind daher durch FHE zwar theoretisch gewachsen, aber das Bootstrapping bringt einen Rechenaufwand mit sich, der in vielen Fällen nicht praktikabel ist.

Werden andere HE-Schemata als FHE verwendet, müssen in bestimmten Fällen, etwa wenn neuronale Netze in Verbindung mit Aktivierungsfunktionenen wie ReLU und Sigmoid genutzt werden sollen, nicht-lineare Funktionen durch Polynome approximiert werden oder durch MPC evaluiert werden [3]. Beispiele hierfür zeigen Hesamifard u. a. [17], die ein neuronales Netz mit entsprechenden Ersatz-Aktivierungsfunktionen trainieren und mit CryptoDL ein Framework für HE-gestützte Inferenz entwickelt haben. Eine Evaluation des Ansatzes zeigt lediglich minimale Performance-Einbußen durch das Ersetzen der Aktivierungsfunktionen und eine für viele Anwendungsfälle ausreichend schnelle HE-Inferenz [17].

Die in den vorhergehenden Abschnitten diskutierten Angriffs- und Verteidigungsmöglichkeiten setzen alle beim Datenaustausch oder der Interaktion mit ML-Modellen an. Ein weiterer Angriffsvektor kann die Betriebssystemebene oder die Hardware betreffen, beispielsweise wenn im Rahmen von MLaaS private Daten auf virtuellen Maschinen in einer Cloud verarbeitet werden. Bösartige Cloud-Provider könnten den ausgeführten Code manipulieren oder sich mutwillig Zugriff auf die verarbeiteten Daten verschaffen.

Trusted Execution Environments (TEE, etwa „vertrauenswürdige Ausführungsumgebungen“, auch: sichere Enklaven) können in einem solchen Szenario zur Erreichung verschiedener Schutzziele beitragen. Einerseits können sie die Authentizität von ausgeführtem Code und die Integrität einer Laufzeitumgebung (inkl. des Arbeitsspeichers und CPU-Registern) garantieren, andererseits können sie die Vertraulichkeit des ausgeführten Codes und der verwendeten Daten gewährleisten [35]. Dafür sind spezielle Hardwarekomponenten nötig, die beispielsweise die Verschlüsselung von Bereichen im Prozessorspeicher erlauben. Die Sicherheitsgarantien von TEEs basieren auf dieser spezieller Hardware. Es gibt allerdings auch Angriffe, die ebenjene Hardware kompromittieren [9, 27].

Insbesondere in verteilten Szenarien können TEEs mit anderen PPML-Methoden kombiniert werden, um Vertrauen zu schaffen. So stellen Ohrimenko u. a. in [30] einen Ansatz vor, in dem Teilnehmende gemeinsam auf einem Server mit einer TEE in Kombination mit SMPC ein ML-Modell trainieren können. Der auszuführende Code kann dabei gegenseitig überprüft werden und in geschützte Bereiche des Server-Arbeitsspeichers übertragen werden. Auch die Trainingsdaten können verschlüsselt in die sichere Enklave übertragen werden, wo im Anschluss an das Training das Modell in verschlüsselter Form vorliegt und heruntergeladen werden kann.

Insgesamt bieten TEEs also schwierig zu komprommitierende Umgebungen für Code und Daten, die allein oder in Kombination mit anderen PPML-Verfahren für das Training von ML-Modellen oder auch in der Inferenzphase eingesetzt werden können.