Eine Einführung in Federated Learning im industriellen Kontext: Fortgeschritten

Im Bereich des maschinellen Lernens wurde eine lange Zeit angenommen, dass die Eingabedaten von Modellen und Gewichten sicher sei und nicht extrahiert werden könnten. In den letzten Jahren veröffentlichte Forschung hat diese Annahme in Frage gestellt. Heutzutage gibt es zahlreiche Modell-Attacken, die Trainingsdaten gefährden: Von Membership-Inference-Attacks bis hin zu Property-Inference-Attacks (Stock et al.). Obwohl ich nicht auf die Einzelheiten dieser Angriffe eingehen werde, veranschaulicht das folgende Beispiel, wie Modell-Daten extrahiert werden können.

Der oben abgebildeten Grafik (Ziegler et al. 13) kann entnommen werden, dass Forscher in der Lage waren, einen Teil des Eingabe-Datensatzes zu rekonstruieren. Dies wurde ermöglicht, indem die lokalen Modellaktualisierungen von einzelnen Clients solchen Rekonstruktionsangriffen ausgesetzt wurden. (Ziegler et al. 1)

Wenn du den ersten Teil dieser Blogserie noch nicht gelesen hast, in dem ich erkläre, was föderiertes Lernen im industriellen Kontext ist, hier ist der Link zum ersten Teil.

Kryptografiebasierte Techniken

Ich möchte darauf hinweisen, dass kryptografiebasierte Techniken Gegenstand intensiver Forschung sind, und ständig Verbesserungen erzielt werden. Schauen wir uns diese kryptografiebasierten Techniken einmal an.

Sichere Aggregation

Sichere Aggregation ist im Wesentlichen ein Protokoll, um den Ursprung der Modellparameter zu verbergen und damit die einzelnen Clients zu schützen. Die Bedeutung kann in den oben beschriebenen Angriffen gesehen werden. Parameter können eine ziemlich sensible Information über einen Client sein, daher erhöht das Verbergen des Ursprungs die Privatsphäre und verringert die Angriffsfläche. Die verfügbaren Protokolle umfassen unter anderem SecAgg/SecAgg+/LightSecAgg/FastSecAgg. Jedes Protokoll hat seine eigenen Vor- und Nachteile, deren Diskussion den Rahmen dieses Artikels sprengt.

Eine sichere Aggregation kann erreicht werden, indem die Updates zwischen den Clients gemischt werden, sodass der Server zum Zeitpunkt der Aggregation nicht weiß, woher die Updates stammen. Bei diesem Shuffling werden mathematische Methoden verwendet, um sicherzustellen, dass alle Updates rekonstruiert werden können, wenn sie den Server erreichen.

Ein weiterer Weg, sichere Aggregation zu implementieren, ist die Verwendung einer vertrauenswürdigen Ausführungsumgebung, wo nur die Umgebung den Ursprung der Updates sieht und der Server das Endergebnis sieht. Dieser Ansatz hat seine Vor- und Nachteile, aber der Rest des Abschnitts wird sich mehr auf die erste Technik konzentrieren, da es der am weitesten verbreitete Ansatz ist.

Eine der größten Herausforderungen bei der sicheren Aggregation sind Client-Ausfälle und die daraus resultierenden Konsequenzen. Zuerst schauen wir uns an, warum Ausfälle überhaupt ein Problem darstellen und welche Konsequenzen sie mit sich tragen können. Anschließend werden wir uns kurz ansehen, warum sichere Aggregation über mehrere Runden mit den traditionellen sicheren Aggregationsprotokollen, welche uns zur Verfügung stehen, nicht einwandfrei realisierbar ist.

Client-Ausfälle

Es wird oft angenommen, dass Clients, also die Edge Devices, welche Daten sammeln, nicht so häufig von Ausfällen betroffen sind. Energiemangel, fehlender Internetzugang und Gerätewartung sind nur einige der Gründe, warum ein Client nicht immer verfügbar sein könnte. In diesen Situationen können wir nicht auf den Client zugreifen und somit kein Training darauf durchführen. Der Client ist somit nicht in der Lage, Parameter zu teilen, die er von anderen Clients erhalten hat.

Sichere Aggregation über mehrere Runden: Wer hat was gekocht?

Beginnen wir mit den schlechten Nachrichten: Die meisten Protokolle zur sicheren Aggregation sind über mehrere Runden hinweg nicht sicher. Dieses Problem ist spezifisch für den Ansatz des Durchmischens der Clients, ist aber dennoch ein großes Problem. Die meisten sicheren Aggregationsalgorithmen betrachten nur, wie man die Gewichte sicher mischt und den Ursprung in einer einzigen Runde verbirgt. Die Idee ist, dass wenn wir eine Runde richtig machen können, dann wird der Prozess in einem Multi-Runden-Kontext einfach wiederholt. Leider passiert jedoch, dass in einem Multi-Runden-Kontext auch die Client-Ausfälle berücksichtigt werden müssen.

Eine einfache Analogie, um diese Situation zu beschreiben, ist das Kochen. Stell dir vor, der Tester ist der Server, und es gibt drei Personen (Clients), die drei verschiedene Pastasoßen zubereiten: Pesto, Bolognese und Tomatensoße. In der ersten Runde probierst du alle Soßen, ohne zu wissen, welcher Client welche Soße gemacht hat. In der folgenden Runde ist die Person, die das Pesto gekocht hat, krank und kann ihre Soße nicht präsentieren. Die anderen Personen verändern ihre Soßen leicht, bevor sie sie erneut präsentieren. Obwohl du nicht weißt, wer welche Soße gekocht hat, weißt du jetzt, dass das Pesto fehlt, und kannst erkennen, wer abwesend war (ein Client-Ausfall). Das ermöglicht es, eine Korrelation zwischen dem Client und seinen Updates herzustellen. Dies ist das Dilemma, dem viele sichere Aggregationsalgorithmen gegenüberstehen. Während neu entstehende Algorithmen darauf abzielen, dieses Problem zu lösen, wurden sie zum Zeitpunkt des Schreibens laut meiner Recherche noch in keinem Framework implementiert.

Homomorphe Verschlüsselung

Stufen der Verschlüsselung

Verschlüsselung kann in drei unterschiedlichen Stufen auftreten: im Ruhezustand (at-rest), während der Übertragung (in-transit) und während der Verwendung (in-use). Die ersten beiden verwenden wir stark in unserem Leben, manchmal sogar, ohne es zu wissen.

Die Verschlüsselung im Ruhezustand bezieht sich auf den Prozess, bei dem eine Datei, einmal verschlüsselt, auf der Festplatte liegt, bis sie zur Verwendung entschlüsselt wird. Verschlüsselung in der Übertragung beschreibt die Verschlüsselung, wenn zwei Geräte miteinander kommunizieren. Zum Beispiel sorgt TLS dafür, dass Ihre Verbindung während der Übertragung sicher bleibt und niemand den Datenverkehr abfangen kann, wenn du eine Website besuchst. Verschlüsselung während der Verwendung beschreibt die faszinierende Idee, Berechnungen auf verschlüsselten Daten durchführen zu können. Bis vor kurzem waren die verwendeten Methoden nicht praktikabel und du wirst gleich sehen, warum.

Die Rolle der homomorphen Verschlüsselung im Federated Learning

Homomorphe Verschlüsselung ermöglicht, dass der gesamte Aggregationsprozess auf verschlüsselten Daten stattfindet. Der Server/Aggregator sieht niemals die Modellupdates und auch nicht das globale Modell, im Gegensatz zur sicheren Aggregation. Die Clients senden ihre verschlüsselten Modellupdates an den Server, welcher die Gewichte aggregiert, das globale Modell, wieder verschlüsselt und an die Clients zurücksenden. Im Standardprotokoll der homomorphen Verschlüsselung teilen die Clients einen privaten Schlüssel und teilen dem Aggregator einen öffentlichen Schlüssel mit. Das folgende Diagramm(Arbeit des Autors) zeigt, wie der Prozess abläuft.

Die spezifischen Implementierungsdetails liegen außerhalb des Rahmens dieses Artikels, aber ich ermutige dich, dir die Implementierung von NVFlare anzusehen, wenn du nach Inspiration suchst (https://developer.nvidia.com/flare).

Einschränkungen der homomorphen Verschlüsselung:

Die Verwendung homomorpher Verschlüsselung ist rechenintensiv und erfordert deutlich mehr Speicherplatz. Im Laufe der Jahre ist sie praktikabler geworden, aber sie ist immer noch ressourcenintensiv. Beachte jedoch, dass die Beschränkungen nicht nur auf die Komplexität und den benötigten Speicherplatz beschränkt sind; es gibt auch technische Limitierungen und Sicherheitsüberlegungen, die du berücksichtigen musst.

Nicht-kryptografische Techniken:

Techniken zur Datenanonymisierung:

Anonymisierte Daten können niemals vollständig anonym sein. Forschungen haben immer wieder gezeigt, dass mithilfe einiger grundlegender Informationen über eine Person, die anonymisierten Datensätze deanonymisiert werden können. Im Jahr 2019 beispielsweise haben Forscher des Imperial College London und der belgischen Université Catholique de Louvain (UCLouvain) ein Modell entwickelt, das es ihnen ermöglichte, 99,98 % der Amerikaner in jedem Datensatz anhand von 15 demografischen Merkmalen korrekt wiederzuerkennen (Rocher et al. 2019). Dieses Beispiel und ähnliche Fälle, wie der Netflix-Datensatz von 2008, zeigen, dass wir den Anonymisierungsmethoden nicht vollständig vertrauen können (Narayanan and Shmatikov). An dieser Stelle würde ich dir empfehlen, den Test “How unique am I?” von AboutMyInfo.org zu machen, um ein Gefühl dafür zu bekommen, wie einfach es ist, Daten zu deanonymisieren und eine Einzelperson in einer Gruppe zu identifizieren.

Aber was wäre, wenn wir wüssten, welche Daten im schlimmsten Fall abhanden kommen?

Differential Privacy

Differential privacy bedeutet, kalkulierte Risiken einzugehen. Sie ermöglicht es uns, den maximalen Verlust an Privatsphäre zu quantifizieren, der entsteht, wenn ein Algorithmus für differential privacy verwendet wird, indem wir das Datenschutzbudget ε verwenden. Dann fügen wir den Daten Rauschen hinzu und stoppen, wenn wir ein vernünftiges Gleichgewicht zwischen dem Verlust an Privatsphäre und den nützlichen Informationen, die dem Modell zur Verfügung gestellt werden, finden. Hier liegt unser Fokus nicht auf den einzelnen Datenpunkten, sondern auf der Verteilung dessen, was damit zusammenhängt. Das Hinzufügen von Rauschen wird fast immer die Genauigkeit des Modells verringern, aber ein gewisser Genauigkeitsverlust ist meist tolerierbar, insbesondere angesichts der Vorteile erhöhter Privatsphäre. Ein weiterer Vorteil des Rauschens ist, dass es helfen könnte, ein Überanpassen zu vermeiden, da der Einfluss eines einzelnen Datenpunkts nach dem Rauschen geringer sein wird. Das ist gut, denn normalerweise sind wir immer an robusten Modellen interessiert, die die Verteilung lernen und gut verallgemeinern.

Einschränkungen

Differential privacy ist nur für das Hinzufügen von Rauschen nützlich, aber nicht für den Schutz des gesamten Trainingsdatensatzes. Wenn solche Bedenken relevant sind, dann könnten kryptographische Techniken besser für Ihren Anwendungsfall geeignet sein. Wie bereits früher erwähnt, kann "differential privacy" auch auf Kosten der Modellgenauigkeit gehen, insbesondere bei unterrepräsentierten Untergruppen.

Fazit

Wie du siehst, ist Federated Learning ein Paradigmenwechsel, der die Art und Weise prägt, wie wir mit Daten umgehen. Es handelt sich nicht um einen hochmodernen Ansatz, der nur in Forschungsarbeiten existiert. Obwohl das Gebiet noch intensiv erforscht und an seine Grenzen gebracht wird, ist es heute schon nutzbar. Es hat eine große Gemeinschaft von Anwendern und Forschern auf der ganzen Welt, die es ermöglichen, es leicht mit Frameworks zu nutzen.

Wie bei jeder neuen Technologie erfordert die Navigation in der Landschaft eine Mischung aus technischem Verständnis und sorgfältigem Risikomanagement. Es muss zwischen Sicherheit, Privatsphäre und Benutzerfreundlichkeit der Daten abgewogen werden.

Im industriellen Kontext sind Fragen wie die Sensibilität der Daten, die Verfügbarkeit von Rechenressourcen sowie das Bedrohungsmodell Ihrer Organisation besonders relevant. Es ist auch wichtig, darauf hinzuweisen, dass ohne herkömmliche Sicherheitsmaßnahmen die fortgeschrittenen Techniken zum Schutz des Datensatzes unwirksam sind.

Ich hoffe, die Einführung war verständlich und du bist nun bereit, das Potenzial deiner Daten zu erschließen. Wenn du Fragen oder Anregungen hast, zögere nicht, dich zu melden!

Quellen:

1. Narayanan, Arvind, and Vitaly Shmatikov. "Robust de-anonymization of large sparse datasets." 2008 IEEE Symposium on Security and Privacy (sp 2008). IEEE, 2008.
2. Stock, Joshua, et al. "Studie zur fachlichen Einschätzung und Prüfung des Potenzials von Federated-Learning-Algorithmen in der amtlichen Statistik." (2023).
3. Rocher, Luc, Julien Hendrickx, and Yves-Alexandre Montjoye. "Estimating the success of re-identifications in incomplete datasets using generative models." Nature Communications, vol. 10, 2019, doi: 10.1038/s41467-019-10933-3.
4. Ziegler, Joceline, et al. "Defending against reconstruction attacks through differentially private federated learning for classification of heterogeneous chest x-ray data." Sensors 22.14 (2022): 5195.