Einleitung

Mit dem vermehrten Einsatz von Verfahren des maschinellen Lernens (ML) in zahlreichen Bereichen der Gesellschaft werden zunehmend auch Kontexte erschlossen, in denen personenbezogene Daten verarbeitet werden. Darunter sind auch immer häufiger sensible Daten wie etwa Gesundheits- oder Sozialdaten.

Dabei kann es beim Einsatz von ML aus Sicht der Betroffenen zu verschiedenen Gefährdungen kommen, die der Verarbeitung von personenbezogenen Daten teilweise innewohnen, teils aber auch erst durch den Einsatz von ML entstehen. In diesem Artikel werden primär Gefahren für das Schutzziel Vertraulichkeit, also den Schutz vor unberechtigter Kenntnisnahme von Daten, adressiert. Werden z. B. besonders sensible personenbezogene Daten für das Training der Verfahren verwendet, so kann ein unberechtigter Zugriff auf diese Daten negative Konsequenzen für Betroffene mit sich bringen. Aber auch eine Verletzung der Vertraulichkeit von Inferenzergebnissen, etwa der unberechtigte Zugriff auf ein durch ML-Verfahren vorhergesagtes Risiko für eine spezifische Erkrankung, kann Betroffenen schaden.

Einen Überblick über geeignete Maßnahmen zur Minimierung dieser Risiken, zusammengefasst unter dem Begriff Privacy-Preserving Machine Learning, bietet der letzte Abschnitt dieses Artikels. Zunächst jedoch werden im folgenden Abschnitt Gefahren für die Privatsphäre von Betroffenen, deren Daten für das Training von ML-Modellen verwendet wurden, geschildert. ML birgt Risiken für die Privatsphäre. Eine Teilmenge dieser Risiken besteht aus Privatsphäreangriffen. Diese Teilmenge wird in diesem Artikel diskutiert.

Angriffe auf maschinelle Lernverfahren

Den betrachteten Angriffen auf die Privatsphäre liegt meist folgendes Szenario zugrunde: Angreifende haben Zugriff auf ein bereits trainiertes ML-Modell und versuchen, hieraus unrechtmäßig Informationen zu extrahieren, die über die gewöhnliche Anwendung des Modells hinausgehen. Damit kann die Privatsphäre von Betroffenen, deren Daten für das Training des Modells verwendet wurden, gefährdet sein. Dies gilt insbesondere, wenn ein Modell im Anschluss an die Trainingsphase von anderen Parteien uneingeschränkt genutzt werden kann.

Prinzipiell sind Privatsphäreangriffe auf verschiedene ML-Algorithmen möglich. Im Fokus der aktuellen Forschung stehen vor allem neuronale Netze, wenngleich die meisten Angriffe auch für andere Verfahren realisiert wurden. Eine Übersicht über bisher veröffentlichte Arbeiten zu Privatsphäreangriffen auf verschiedene ML-Verfahren bieten Rigaki und Garcia [33].

Unabhängig von den ML-Verfahren wird grundsätzlich zwischen zwei Angriffsszenarien unterschieden: White-Box und Black-Box. Im Black-Box-Szenario (siehe Abb. 1) können Angreifende ein ML-Modell nutzen, um Inferenzen (z. B. Vorhersagen oder Klassifizierungen) durchzuführen. Wie bei einem Orakel können dabei Datensätze an das Modell geschickt werden, um die Modellausgaben zu erhalten. Dabei steht aber lediglich ein Interface zur Verfügung, hinter dem die Modellinterna, also die Hyperparameter (siehe Teil 1 im vorhergehenden Heft) und die antrainierten Parameter, versteckt sind. Im Gegensatz dazu bedeutet White-Box-Zugriff komplette Einsicht in das ML-Modell: Neben der Möglichkeit, mit dem Modell Inferenzen durchzuführen, haben Angreifende hiermit vollen Zugriff auf die Modellparameter und -hyperparameter. Als Abstufung zwischen diesen beiden Extremen sind verschiedene Gray-Box-Szenarien möglich. Hierzu könnte beispielsweise die Einsicht in manche Hyperparameter oder die Architektur eines neuronalen Netzes zählen, ohne Zugriff auf andere Parameter.

Abb. 1
figure 1

Eine schematische ML-Pipeline mit möglichen Angriffspunkten für Privatsphäreangriffe

Wie ebenfalls aus der Übersicht von Rigaki und Garcia [33] hervorgeht, sind die meisten ML-Privatsphäreangriffe per Black-Box-Zugriff realisierbar und benötigen daher keinen Vollzugriff auf das Modell. Dieses Szenario ist insbesondere im Kontext von Machine Learning as a Service (MLaaS) oftmals gegeben. MLaaS ist ein Sammelbegriff für Dienstleistungen, die bei der Entwicklung von ML-Modellen unterstützen. Angefangen bei der Installation von Software, über das Preprocessing von Daten bis hin zur Trainingsphase selbst können damit ressourcenintensive Schritte zu kommerziellen Dienstleistern ausgelagert werden. MLaaS-Provider können ihren Kundinnen und Kunden also neben Hardware, vorinstallierten Arbeitsumgebungen und Algorithmen auch fertige Modelle zur Verfügung stellen. Neben spezialisierten ML-Plattformen (z. B. BigML) bieten mittlerweile auch alle großen Cloud-Computing-Anbieter wie Google Cloud MLaaS an. Entsprechende Privatsphäreangriffe können folglich auch auf ML-Modelle, die zu diesen Anbietern ausgelagert wurden, gerichtet sein.

Die folgenden Abschnitte widmen sich detailliert den einzelnen ML-spezifischen Angriffen, die in Abb. 1 in einer Übersicht zusammengefasst sind.

Model Inversion

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.

Abb. 2
figure 2

Ein Beispiel des Model-Inversion-Angriffs mit einer Rekonstruktion (links) des Originalbilds (rechts) aus den Trainingsdaten. Abbildung entnommen aus [11]

Abb. 3
figure 3

Die Ergebnisse von Shokri u. a. [36], die den Model-Inversion-Angriff auf ein Bilderkennungsmodell für den Datensatz CIFAR-10 ausgeführt haben. Hier sind Rückschlüsse auf die Trainingsdaten kaum möglich: Die Darstellungen zeigen die rekonstruierten Daten für die jeweiligen Zielklassen des angegriffenen Modells (von oben links: Flugzeug, Auto, Vogel usw.). Abbildung entnommen aus [36]

Membership Inference

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.

Property Inference

Ä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].

Model Extraction

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.

Angreifbarkeit von Modellen

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.

Privacy-Preserving Machine Learning

Aufgrund der mit dem Einsatz von ML-Verfahren verbundenen Risiken, auch durch die im vorangehenden Abschnitt beschriebenen Privatsphäreangriffe, gibt es zahlreiche Bestrebungen, ML datenschutzgerechter zu gestalten. Privacy-Preserving Machine Learning (PPML) ist ein Sammelbegriff für verschiedene Techniken, die zu diesem Ziel beitragen können. Je nach Bedarf können diese Techniken verschiedene Schutzziele in der Trainingsphase und in der Inferenzphase verfolgen. Beispielsweise kann der Einsatz von Federated Learning in einem kollaborativen Szenario die zum Training verwendeten Daten vor anderen Parteien schützen. Die Nutzung von homomorpher Verschlüsselung in der Inferenzphase ermöglicht die Verwendung eines ML-Verfahrens, ohne dass Nicht-Berechtigte Zugriff auf Eingabe- oder Inferenzdaten erhalten. Abb. 4 bietet einen Überblick darüber, welche Mechanismen für welche Aspekte in ML-Verfahren eingesetzt werden können. Die einzelnen Techniken werden in den folgenden Abschnitten näher vorgestellt, eine Übersicht befindet sich in Tab. 1.

Abb. 4
figure 4

Verfahren des Privacy-Preserving Machine Learning und wo sie zum Einsatz kommen.

Tab. 1 Übersicht über die vorgestellten Verfahren des Privacy-Preserving-Machine-Learning

Differential Privacy

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].

Federated Learning

Sollen ML-Modelle mithilfe von Daten aus verschiedenen Quellen trainiert werden, so kann dies auf verschiedene Weisen erfolgen. Der klassische Ansatz besteht in der zentralen Zusammenführung aller verteilt vorliegenden Daten und dem anschließenden Trainieren auf dem so entstandenen Gesamtdatensatz. Auf diese Weise erhält die das Training durchführende Partei jedoch volle Kenntnis über die Daten aller Quellen. Handelt es sich um vertrauliche oder sensible Daten, so kann die Weitergabe an Dritte unerwünscht sein und im Zweifel dazu führen, dass die Daten nicht verwendet werden können. Durch Federated Learning (FL) können ML-Modelle mit Daten aus verschiedenen Quellen trainiert werden, ohne dass diese zuvor zusammengeführt werden müssen. Dabei findet das Training des Modells unter Nutzung lokaler Daten direkt auf den Geräten der Datenbesitzenden statt. Die Daten müssen somit weder mit anderen Teilnehmenden noch mit der zentralen, orchestrierenden Einheit geteilt werden. Es werden lediglich Modellupdates zwischen den Teilnehmenden und einem zentralen Server ausgetauscht, der die Updates kombiniert und Runde für Runde das globale ML-Modell optimiert.

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.

Abb. 5
figure 5

Eine vereinfachte Darstellung des Federated-Learning-Prozesses für eine Runde \(i\) mit einem zentralen Server und \(n\) teilnehmenden Parteien

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].

Secure Multiparty Computation

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.

Abb. 6
figure 6

Secure Multiparty Computation, hier dargestellt mit drei Parteien, erlaubt die Berechnung einer Funktion \(f\) auf den geheimen Eingaben \(x_{i}\), ohne dass die Parteien die Eingaben anderer Parteien erfahren

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.

Homomorphe Verschlüsselung

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].

Abb. 7
figure 7

Das Prinzip homomorpher Verschlüsselung, dargestellt anhand der Multiplikation zweier Zahlen \(a\) und \(b\). \(E(x)\) beschreibt den Schlüsseltext, der entsteht, wenn die Eingabe \(x\) verschlüsselt wird

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].

Trusted Execution Environments

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.

Fazit

Durch die zunehmende Anzahl an Anwendungsmöglichkeiten von ML-Verfahren ist zu erwarten, dass der Einsatz von ML-Verfahren auch weiterhin an Bedeutung gewinnen wird. Die Gefahren für Privatsphäre und Sicherheit, die insbesondere bei der Verwendung sensibler Trainingsdaten entstehen können, müssen dabei stets beachtet werden. In dieser Artikelserie wurden im ersten Teil die oft abstrakten Begriffe rund um ML konkretisiert und gängige Verfahren zu dessen Nutzung erklärt. Im zweiten Teil wurden mögliche Privatsphäreangriffe im Kontext von ML aufgezeigt und Techniken für datenschutzfreundliches ML vorgestellt. Durch den geschickten Einsatz dieser Techniken können ML-unterstützte Fortschritte in sensiblen Bereichen wie der medizinischen Forschung erzielt werden, während das Risiko einer Gefährdung personenbezogener Daten reduziert werden kann. Da dem Einsatz vieler PPML-Techniken in der Praxis jedoch noch Hindernisse entgegenstehen, bleibt abzuwarten, wie sich dieses Feld in Wissenschaft und Praxis in den nächsten Jahren entwickeln wird.