DE112022002623T5

DE112022002623T5 - Vertrauenswürdige und dezentrale aggregation für föderiertes lernen

Info

Publication number: DE112022002623T5
Application number: DE112022002623.5T
Authority: DE
Inventors: Jayaram Kallapalayam Radhakrishnan; Ashish Verma; Zhongshu Gu; Enriquillo Valdez; Pau-Chen Cheng; Hani Jamjoom
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2021-05-18
Filing date: 2022-05-17
Publication date: 2024-03-14
Also published as: GB202317017D0; JP2024519365A; CN117242463A; US20220374762A1; GB2621732A; WO2022243871A1

Abstract

Techniken für verteiltes föderiertes Lernen nutzen eine mehrschichtige Verteidigungsstrategie, um eine verringerte Preisgabe von Informationen bereitzustellen. Statt Modellaktualisierungen zentral zu aggregieren, ist eine Aggregationsfunktion in mehrere unabhängige und funktional gleichwertige Ausführungsentitäten dezentralisiert, die jeweils innerhalb ihrer eigenen vertrauenswürdigen Ausführungsumgebung (TEE) ausgeführt werden. Die TEEs ermöglichen eine vertrauliche und aus der Ferne attestierbare föderierte Aggregation. Jede Aggregator-Entität wird bevorzugt innerhalb einer verschlüsselten virtuellen Maschine ausgeführt, die eine Laufzeitspeicherverschlüsselung unterstützt. Jede Partei prüft die TEE aus der Ferne auf Berechtigung, bevor sie am Training teilnimmt. Mithilfe von mehreren dezentralen Aggregatoren wird den Parteien ermöglicht, ihre jeweiligen Modellaktualisierungen auf Modellparametergranularität zu partitionieren, und sie können einzelne Gewichtungen einer bestimmten Aggregator-Entität zuordnen. Parteien können darüber hinaus fragmentarische Modellaktualisierungen bei jeder Trainings-Iteration dynamisch mischen, um die an jede Aggregator-Ausführungsentität gesendeten Informationen weiter zu verschleiern. Diese Architektur verhindert, dass der Aggregator ein Single Point of Failure ist, und dient dazu, das Modell zu schützen, selbst wenn alle Aggregatoren beeinträchtigt werden.

Description

HINTERGRUND
Gebiet der Technik
Diese Offenbarung bezieht sich allgemein auf Techniken für verteiltes maschinelles Lernen.
Beschreibung der verwandten Technik
Föderiertes Lernen (FL) stellt einen gemeinsamen Trainings-Mechanismus bereit, der ermöglicht, dass mehrere Parteien gemeinsam ein Modell für maschinelles Lernen (ML) erstellen. Statt sämtliche Trainings-Daten auf einem zentralen Trainings-Server (oder Rechenzentrum) in Pools zusammenzufassen, ermöglicht föderiertes Lernen, dass Parteien private Daten innerhalb ihrer vertrauenswürdigen und geschützten Domänen/Infrastrukturen behalten. Jede Partei trainiert ein lokales Modell und lädt nur Modellaktualisierungen oder -gradienten regelmäßig auf einen zentralen Aggregations-Server hoch. Dieser Aggregator verbindet Modellaktualisierungen und überträgt das aggregierte Modell zur Modellsynchronisation zurück an alle Parteien. Die Trainings-Umgebung für föderiertes Lernen bietet einen einzigartigen Vorteil zum Wahren des Datenschutzes bei Trainings-Daten. Dies ist besonders attraktiv für sich gegenseitig misstrauende/konkurrierende Trainings-Parteien sowie für Inhaber sensibler Daten (z.B. Gesundheits- und Finanzdaten), bei denen ein gemeinsames Nutzen von Daten durch Gesetze oder Vorschriften verboten ist.
Es besteht ein Missverständnis beim föderierten Lernen, nämlich dass die ausgetauschten Modellaktualisierungen bei FL-Datenübertragungen weniger Informationen als die Trainings-Rohdaten enthalten. Dies hat zu der Schlussfolgerung geführt, dass ein gemeinsames Nutzen von Modellaktualisierungen als „den Datenschutz erhaltend“ betrachtet wird. Modellaktualisierungen werden jedoch direkt von den lokalen Trainings-Daten abgeleitet. Auch wenn dies nicht eindeutig erkennbar ist, sind die Informationen der Trainings-Daten dennoch in der Darstellung der Modellaktualisierungen verborgen. Neuere Forschungen haben die Datenschutzversprechen des föderierten Lernens in Frage gestellt. Im Besonderen haben diese Forschungen gezeigt, dass es unter der Annahme eines ehrlichen, aber neugierigen zentralen Aggregations-Servers für Angreifer definitiv möglich ist, private Attribute abzuleiten oder Trainings-Daten zu rekonstruieren, indem sie die Modellaktualisierungen ausnutzen.
Bestehende Techniken, die diese Probleme behandeln, sind differentielle private Aggregation durch das Hinzufügen von statistischem Rauschen zu Modellaktualisierungen und die Verwendung von kryptographischen Basiselementen wie zum Beispiel von Protokollen für sichere Mehrparteienberechnung (Secure Multi-Party Computation, SMC) oder homomorpher Verschlüsselung (Homomorphic Encryption, HE). Beide Techniken weisen mehrere Nachteile auf. Erstere verringert die Genauigkeit des trainierten Modells oft erheblich und erfordert eine sorgfältige Abstimmung von Hyperparametern, während letztere sehr rechenintensiv ist. Da die Parteien einander darüber hinaus nicht vertrauen, wird der zentrale Aggregator häufig auf nicht vertrauenswürdigen (Cloud-)Computing-Infrastrukturen Dritter ausgeführt und kann bei Angriffen zu einem Single Point of Failure werden.
Es bleibt also eine Notwendigkeit, verbesserte Frameworks für föderiertes Lernen bereitzustellen, die dieses Bedrohungsmodell behandeln.
KURZDARSTELLUNG
Gemäß dieser Offenbarung werden ein System für föderiertes Lernen und ein Verfahren zum Trainieren von neuronalen Netzen zur Abwehr von Datenschutzlecks und Angriffen zur Datenrekonstruktion beschrieben. Der hierin bereitgestellte Ansatz bietet einen verbesserten Schutz vor einer Preisgabe von Informationen, indem er eine mehrschichtige Verteidigungsstrategie nutzt, die mehrere Aspekte aufweist, und zwar eine vertrauenswürdige Aggregation, eine dezentrale Aggregation mit Modellpartitionierung und eine dynamische Permutation.
So, wie der Begriff hierin verwendet wird, bezieht sich „vertrauenswürdige Aggregation“ auf die Vorstellung, vertrauenswürdige Ausführungsumgebungen (trusted execution environments, TEEs) zu verwenden, die eine Laufzeitspeicherverschlüsselung und eine Attestierung aus der Ferne bereitstellen, um eine isolierte und vertrauliche Ausführung auf nichtvertrauenswürdigen Servern zu erleichtern. Dezentrale Aggregation bezieht sich auf die Vorstellung, dass der zentrale Aggregator in mehrere unabhängige und funktional gleichwertige Ausführungsentitäten partitioniert wird, wobei jede solche Entität innerhalb einer verschlüsselten virtuellen Maschine ausgeführt wird. Mit mehreren dezentralen Aggregatoren haben die Parteien die Freiheit, Modellaktualisierungen auf Modellparametergranularität zu zerlegen und jede einzelne Gewichtung einem bestimmten Aggregator zuzuordnen. Auf diese Weise verfügt jeder Aggregator bevorzugt nur über einen teilweisen Überblick über die Modellaktualisierungen und kennt die Modellarchitekturen nicht. Durch Dezentralisieren eines einzelnen Aggregators mit einer Partitionierung von Modellaktualisierungen verhindert der Ansatz, dass der Aggregator bei Angriffen auf die Sicherheit, die z.B. auf bestimmte TEEs abzielen, zu einem Single Point of Failure wird. Darüber hinaus können Benutzer mehrere Aggregatoren auf physischen Servern an verschiedenen geographischen Standorten und möglicherweise mit verschiedenartigen TEEs auf sonstigen Mikroprozessoren bereitstellen. Selbst wenn eine Teilmenge der Aggregatoren verletzt wird, können die Angreifer nicht die gesamten Informationen über Modellaktualisierungen zusammensetzen.
Bei einer beispielhaften Implementierung wird jede Aggregator-Ausführungsentität innerhalb einer verschlüsselten virtuellen Maschine (encrypted virtual machine, EVM) mit Laufzeitspeicherverschlüsselung ausgeführt. Bevor sie an dem Training teilnimmt, prüft jede Partei des föderierten Lernens aus der Ferne, ob die Hardware echt ist, und baut einen durchgängigen, sicheren Kanal zum Austauschen von Modellaktualisierungen auf.
Gemäß einem zusätzlichen Aspekt wird, wie oben erwähnt, eine zusätzliche Verteidigungsstrategie hierin als dynamische Permutation bezeichnet. Die dynamische Permutation nutzt die Vorstellung, dass die Rechenoperationen von Fusionsalgorithmen für föderiertes Lernen, z.B. ein föderierter stochastischer Gradientenabstieg (Federated Stochastic Gradient Descent, FedSGD) und eine föderierte Mittelwertbildung (Federated Averaging, FedAvg), über Modellaktualisierungen hinweg bijektiv sind. Daher hat ein Partitionieren und ein (internes) Mischen einer Modellaktualisierung keinen Einfluss auf die Fusionsergebnisse. Gemäß diesem Aspekt der Offenbarung wird den Parteien die Möglichkeit bereitgestellt, fragmentarische Modellaktualisierungen bei jeder Trainings-Iteration dynamisch zu mischen, um die an jede Aggregator-Ausführungsentität gesendeten Informationen weiter zu verschleiern. Diese Strategie garantiert, dass selbst wenn alle dezentralen Aggregatoren verletzt werden, die Angreifer nicht in der Lage sind, die korrekte Reihenfolge der Modellaktualisierungen zu entschlüsseln, um die Trainings-Daten zu rekonstruieren. Dynamische Permutation wird ermöglicht, wenn die parteiseitige Umwandlung von Modellaktualisierungen deterministisch, umkehrbar und über Parteien hinweg identisch ist.
Oben sind einige der relevanteren Merkmale des Gegenstandes umrissen worden. Diese Merkmale sind so auszulegen, dass sie lediglich zur Veranschaulichung dienen. Zahlreiche sonstige vorteilhafte Ergebnisse können durch Anwenden des offenbarten Gegenstandes auf andere Weise oder durch Modifizieren des Gegenstandes erzielt werden, wie im Folgenden beschrieben wird.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Für ein umfassenderes Verständnis des Gegenstandes und seiner Vorteile wird im Folgenden auf die nachfolgenden Beschreibungen zusammen mit den beigefügten Zeichnungen Bezug genommen, in denen:

1 ein beispielhaftes Blockschaubild einer verteilten Datenverarbeitungsumgebung darstellt, in der beispielhafte Aspekte der veranschaulichenden Ausführungsformen implementiert werden können;
2 ein beispielhaftes Blockschaubild eines Datenverarbeitungssystems darstellt, in dem beispielhafte Aspekte der veranschaulichenden Ausführungsformen implementiert werden können;
3 eine Cloud-Computing-Umgebung darstellt, in der ein Fusions-Server eines Frameworks für sicheres verteiltes maschinelles Lernen gemäß dieser Offenbarung implementiert werden kann;
4 ein Framework für verteiltes Lernen darstellt, das einen Aggregations-Server und einen Satz von Dateneignern/Lernagenten aufweist;
5 eine erste Sicherheitstechnik darstellt, die hierin als vertrauenswürdige Aggregation bezeichnet wird;
6 eine Systemarchitektur darstellt, die das vertrauenswürdige und dezentrale föderierte Lernen dieser Offenbarung implementiert; und
7 eine repräsentative Implementierung des Schemas zur Modellpartitionierung und dynamischen Permutation darstellt.

AUSFÜHRLICHE BESCHREIBUNG EINER VERANSCHAULICHENDEN AUSFÜHRUNGSFORM
Im Folgenden werden unter Bezugnahme auf die Zeichnungen und im Besonderen unter Bezugnahme auf 1 bis 2 beispielhafte Schaubilder von Datenverarbeitungsumgebungen bereitgestellt, in denen veranschaulichende Ausführungsformen der Offenbarung implementiert werden können. Es ist zu beachten, dass 1 bis 2 lediglich als Beispiele dienen und nicht dazu bestimmt sind, eine Einschränkung in Bezug auf die Umgebungen, in denen Aspekte oder Ausführungsformen des offenbarten Gegenstandes implementiert werden können, geltend zu machen oder einzuschließen. Es können zahlreiche Modifizierungen an den dargestellten Umgebungen vorgenommen werden, ohne vom Wesensgehalt und Umfang der vorliegenden Erfindung abzuweichen.
Unter Bezugnahme auf 1 wird eine bildliche Darstellung eines beispielhaften verteilten Datenverarbeitungssystems gezeigt, in dem Aspekte der veranschaulichenden Ausführungsformen implementiert werden können. Ein verteiltes Datenverarbeitungssystem 100 kann ein Netzwerk von Computern enthalten, in dem Aspekte der veranschaulichenden Ausführungsformen implementiert werden können. Das verteilte Datenverarbeitungssystem 100 enthält zumindest ein Netzwerk 102, bei dem es sich um das Medium handelt, das zum Bereitstellen von Datenübertragungsverbindungen zwischen verschiedenen Einheiten und Computern verwendet wird, die innerhalb des verteilten Datenverarbeitungssystems 100 miteinander verbunden sind. Das Netzwerk 102 kann Verbindungen wie zum Beispiel drahtgebundene und drahtlose Datenübertragungsverbindungen oder Lichtwellenleiterkabel enthalten.
In dem dargestellten Beispiel sind ein Server 104 und ein Server 106 zusammen mit einer Speichereinheit 108 mit dem Netzwerk 102 verbunden. Darüber hinaus sind Clients 110, 112 und 114 ebenfalls mit dem Netzwerk 102 verbunden. Bei diesen Clients 110, 112 und 114 kann es sich zum Beispiel um Personalcomputer, Netzwerkcomputer oder dergleichen handeln. In dem dargestellten Beispiel stellt der Server 104 den Clients 110, 112 und 114 Daten wie zum Beispiel Startdateien, Betriebssystemabbilder und Anwendungen bereit. In dem dargestellten Beispiel handelt es sich bei den Clients 110, 112 und 114 um Clients des Servers 104. Das verteilte Datenverarbeitungssystem 100 kann zusätzliche Server, Clients und sonstige Einheiten enthalten, die nicht dargestellt sind.
In dem dargestellten Beispiel handelt es sich bei dem verteilten Datenverarbeitungssystem 100 um das Internet, wobei das Netzwerk 102 einen weltweiten Bestand von Netzwerken und Gateways darstellt, die die Transmission-Control-Protocol/Internet-Protocol(TCP/IP)-Gruppe von Protokollen dazu verwenden, Daten miteinander auszutauschen. Im Kern des Internet befindet sich ein Backbone aus Hochgeschwindigkeits-Datenübertragungsverbindungen zwischen Hauptknoten oder Host-Computern, die aus Tausenden von kommerziellen, behördlichen, Bildungs- und sonstigen Computersystemen bestehen, die Daten und Nachrichten weiterleiten. Selbstverständlich kann das verteilte Datenverarbeitungssystem 100 auch so implementiert werden, dass es eine Reihe verschiedener Netzwerktypen wie zum Beispiel ein Intranet, ein lokales Netzwerk (local area network, LAN), ein Weitverkehrs-Netzwerk (wide area network, WAN) oder dergleichen enthält. Wie oben angegeben, ist 1 als Beispiel gemeint und nicht als architektonische Einschränkung verschiedener Ausführungsformen des offenbarten Gegenstandes, und daher sollten die jeweiligen in 1 dargestellten Elemente im Hinblick auf die Umgebungen, in denen die veranschaulichenden Ausführungsformen der vorliegenden Erfindung implementiert werden können, nicht als einschränkend betrachtet werden.
Unter Bezugnahme auf 2 wird ein Blockschaubild eines beispielhaften Datenverarbeitungssystems dargestellt, in dem Aspekte der veranschaulichenden Ausführungsformen implementiert werden können. Bei dem Datenverarbeitungssystem 200 handelt es sich um ein Beispiel für einen Computer wie zum Beispiel den Client 110 in 1, in dem sich durch einen Computer verwendbarer Code oder Anweisungen befinden können, die die Prozesse für veranschaulichende Ausführungsformen der Offenbarung implementieren.
Unter Bezugnahme auf 2 wird ein Blockschaubild eines Datenverarbeitungssystems dargestellt, in dem veranschaulichende Ausführungsformen implementiert werden können. Bei dem Datenverarbeitungssystem 200 handelt es sich um ein Beispiel für einen Computer wie etwa den Server 104 oder den Client 110 in 1, in dem sich durch einen Computer verwendbarer Code oder Anweisungen für die veranschaulichenden Ausführungsformen befinden können, die die Prozesse implementieren. In diesem veranschaulichenden Beispiel enthält das Datenverarbeitungssystem 200 eine Datenübertragungsstruktur 202, die eine Datenübertragung zwischen einer Prozessoreinheit 204, einem Speicher 206, einem nichtflüchtigen Speicher 208, einer Datenübertragungseinheit 210, einer Eingabe-/ Ausgabe(E/A)-Einheit 212 und einer Anzeige 214 bereitstellt.
Die Prozessoreinheit 204 dient zum Ausführen von Anweisungen für Software, die in den Speicher 206 geladen werden kann. Bei der Prozessoreinheit 204 kann es sich abhängig von der jeweiligen Implementierung um einen Satz aus einem oder mehreren Prozessoren oder um einen Mehrprozessorkern handeln. Des Weiteren kann die Prozessoreinheit 204 mithilfe eines oder mehrerer heterogener Prozessorsysteme implementiert werden, in denen sich ein Hauptprozessor mit untergeordneten Prozessoren auf einem einzelnen Chip befindet. Als weiteres veranschaulichendes Beispiel kann es sich bei der Prozessoreinheit 204 um ein symmetrisches Mehrprozessor(SMP)-System handeln, das mehrere Prozessoren desselben Typs enthält.
Der Speicher 206 und der nichtflüchtige Speicher 208 sind Beispiele für Speichereinheiten. Eine Speichereinheit ist eine Hardware, die in der Lage ist, Informationen zeitweilig und/oder dauerhaft zu speichern. Bei dem Speicher 206 kann es sich in diesen Beispielen etwa um einen Direktzugriffsspeicher oder eine beliebige sonstige geeignete flüchtige oder nichtflüchtige Speichereinheit handeln. Der nichtflüchtige Speicher 208 kann abhängig von der jeweiligen Implementierung verschiedene Formen annehmen. Beispielsweise kann der nichtflüchtige Speicher 208 eine oder mehrere Komponenten oder Einheiten enthalten. Bei dem nichtflüchtigen Speicher 208 kann es sich zum Beispiel um eine Festplatte, einen Flash-Speicher, eine wiederbeschreibbare optische Speicherplatte, ein wiederbeschreibbares Magnetband oder um eine Kombination der Obigen handeln. Die durch den nichtflüchtigen Speicher 208 verwendeten Medien können auch auswechselbar sein. Beispielsweise kann eine Wechselfestplatte als nichtflüchtiger Speicher 208 verwendet werden.
Die Datenübertragungseinheit 210 stellt in diesen Beispielen eine Datenübertragung mit sonstigen Datenverarbeitungssystemen oder -einheiten bereit. In diesen Beispielen handelt es sich bei der Datenübertragungseinheit 210 um eine Netzwerk-Schnittstellenkarte. Die Datenübertragungseinheit 210 kann Datenübertragungen durch die Verwendung von physischen und/oder von drahtlosen Datenübertragungsverbindungen bereitstellen.
Die Eingabe-/Ausgabe-Einheit 212 ermöglicht die Eingabe und Ausgabe von Daten in/aus sonstige(n) Einheiten, die mit dem Datenverarbeitungssystem 200 verbunden sein können. Die Eingabe-/Ausgabe-Einheit 212 kann zum Bespiel eine Verbindung für Benutzereingaben durch eine Tastatur und eine Maus bereitstellen. Des Weiteren kann die Eingabe-/Ausgabe-Einheit 212 Ausgaben an einen Drucker senden. Die Anzeige 214 stellt einen Mechanismus zum Anzeigen von Informationen für einen Benutzer bereit.
Anweisungen für das Betriebssystem und Anwendungen oder Programme befinden sich in dem nichtflüchtigen Speicher 208. Diese Anweisungen können zur Ausführung durch die Prozessoreinheit 204 in den Speicher 206 geladen werden. Die Prozesse der verschiedenen Ausführungsformen können durch die Prozessoreinheit 204 mithilfe von auf einem Computer implementierten Anweisungen durchgeführt werden, die sich in einem Speicher wie zum Beispiel dem Speicher 206 befinden können. Diese Anweisungen werden als Programmcode, durch einen Computer verwendbarer Programmcode oder durch einen Computer lesbarer Programmcode bezeichnet, der durch einen Prozessor in der Prozessoreinheit 204 gelesen und ausgeführt werden kann. Der Programmcode in den verschiedenen Ausführungsformen kann auf verschiedenen physischen oder greifbaren durch einen Computer lesbaren Medien wie zum Beispiel dem Speicher 206 oder dem nichtflüchtigen Speicher 208 verkörpert sein.
Der Programmcode 216 befindet sich in einer funktionalen Form auf einem durch einen Computer lesbaren Medium 218, das wahlweise auswechselbar ist, und kann zur Ausführung durch die Prozessoreinheit 204 in das Datenverarbeitungssystem 200 geladen oder übertragen werden. Der Programmcode 216 und das durch einen Computer lesbare Medium 218 bilden in diesen Beispielen ein Computerprogrammprodukt 220 aus. In einem Beispiel kann das durch einen Computer lesbare Medium 218 in einer greifbaren Form wie zum Beispiel als optische Speicherplatte oder Magnetplatte vorliegen, die zur Übertragung auf eine Speichereinheit wie zum Beispiel ein Festplattenlaufwerk, das einen Teil des nichtflüchtigen Speichers 208 bildet, in ein Laufwerk oder eine sonstige Einheit eingelegt oder platziert wird, bei der es sich um einen Teil des nichtflüchtigen Speichers 208 handelt. In einer greifbaren Form kann das durch einen Computer lesbare Medium 218 auch die Form eines nichtflüchtigen Speichers wie zum Beispiel eines Festplattenlaufwerks, eines USB-Speichersticks oder eines Flash-Speichers annehmen, das/der mit dem Datenverarbeitungssystem 200 verbunden ist. Die greifbare Form des durch einen Computer lesbaren Mediums 218 wird auch als durch einen Computer beschreibbares Speichermedium bezeichnet. In einigen Fällen ist es möglich, dass das durch einen Computer beschreibbare Medium 218 nicht auswechselbar ist.
Alternativ kann der Programmcode 216 von dem durch einen Computer lesbaren Medium 218 durch eine Datenübertragungsverbindung mit der Datenübertragungseinheit 210 und/oder durch eine Verbindung mit der Eingabe-/Ausgabe-Einheit 212 zu dem Datenverarbeitungssystem 200 übertragen werden. Die Datenübertragungsverbindung und/oder die Verbindung können in den veranschaulichenden Beispielen physisch oder drahtlos sein. Das durch einen Computer lesbare Medium kann außerdem die Form von nichtgreifbaren Medien wie zum Beispiel Datenübertragungsverbindungen oder drahtlosen Übertragungen annehmen, die den Programmcode enthalten. Die verschiedenen für das Datenverarbeitungssystem 200 veranschaulichten Komponenten sind nicht dazu bestimmt, der Architektur Beschränkungen in der Weise aufzuerlegen, in der verschiedene Ausführungsformen implementiert werden können. Die verschiedenen veranschaulichenden Ausführungsformen können in einem Datenverarbeitungssystem implementiert werden, das Komponenten zusätzlich zu oder anstelle von denjenigen enthält, die für das Datenverarbeitungssystem 200 veranschaulicht werden. Sonstige in 2 dargestellte Komponenten können von den dargestellten veranschaulichenden Beispielen abweichen. Als ein Beispiel handelt es sich bei einer Speichereinheit in dem Datenverarbeitungssystem 200 um eine beliebige Hardware-Vorrichtung, die Daten speichern kann. Der Speicher 206, der nichtflüchtige Speicher 208 und das durch einen Computer lesbare Medium 218 sind Beispiele für Speichereinheiten in einer greifbaren Form.
In einem weiteren Beispiel kann ein Bussystem dazu verwendet werden, die Datenübertragungsstruktur 202 zu implementieren, und es kann aus einem oder mehreren Bussen wie zum Beispiel einem Systembus oder einem Eingabe-/Ausgabe-Bus bestehen. Das Bussystem kann selbstverständlich mithilfe eines beliebigen geeigneten Typs einer Architektur implementiert werden, der eine Übertragung von Daten zwischen verschiedenen, mit dem Bussystem verbundenen Komponenten oder Einheiten ermöglicht. Zusätzlich kann eine Datenübertragungseinheit eine oder mehrere Einheit(en) enthalten, die zum Übertragen und Empfangen von Daten verwendet wird/werden, wie zum Beispiel einen Modem oder einen Netzwerkadapter. Des Weiteren kann es sich bei einem Speicher zum Beispiel um den Speicher 206 oder um einen Cache handeln, wie er beispielweise in einem Schnittstellen- und Speichersteuereinheiten-Hub zu finden ist, der in der Datenübertragungsstruktur 202 vorhanden sein kann.
Computerprogrammcode zum Ausführen von Operationen der vorliegenden Erfindung kann in jeder Kombination einer oder mehrerer Programmiersprachen geschrieben werden, zum Beispiel in einer objektorientierten Programmiersprache wie etwa Java™, Smalltalk, C++ oder dergleichen und in herkömmlichen verfahrensorientierten Programmiersprachen wie zum Beispiel der Programmiersprache „C“ oder ähnlichen Programmiersprachen. Der Programmcode kann vollständig auf dem Computer eines Benutzers, zum Teil auf dem Computer des Benutzers, als eigenständiges Software-Paket, zum Teil auf dem Computer des Benutzers und zum Teil auf einem entfernt angeordneten Computer oder vollständig auf dem entfernt angeordneten Computer oder Server ausgeführt werden. In letzterem Fall kann der entfernt angeordnete Computer mit dem Computer des Benutzers durch eine beliebige Art Netzwerk verbunden sein, darunter ein lokales Netzwerk (LAN) oder ein Weitverkehrs-Netzwerk (WAN), oder die Verbindung kann mit einem externen Computer hergestellt werden (zum Beispiel über das Internet mithilfe eines Internet-Diensteanbieters).
Fachleuten ist ersichtlich, dass die Hardware in 1 bis 2 abhängig von der Implementierung variieren kann. Sonstige interne Hardware- oder Peripherieeinheiten wie zum Beispiel ein Flash-Speicher, ein gleichwertiger nichtflüchtiger Speicher oder Laufwerke für optische Speicherplatten und dergleichen können zusätzlich oder anstelle der in 1 bis 2 dargestellten Hardware verwendet werden. Darüber hinaus können die Prozesse der veranschaulichenden Ausführungsformen auf ein anderes Mehrprozessor-Datenverarbeitungssystem als das zuvor erwähnte SMP-System angewendet werden, ohne vom Wesensgehalt und Umfang des offenbarten Gegenstandes abzuweichen.
Wie ersichtlich wird, können die hierin beschriebenen Techniken innerhalb des Client-Server-Standardkonzeptes zusammenwirken, wie zum Beispiel in 1 veranschaulicht, in dem Client-Maschinen Daten mit einem über das Internet zugänglichen Portal auf Grundlage des Web austauschen, das auf einem Satz aus einer oder mehreren Maschinen ausgeführt wird. Endbenutzer betreiben mit dem Internet verbindbare Einheiten (z.B. Desktop-Computer, Notebook-Computer, internetfähige mobile Einheiten oder dergleichen), die in der Lage sind, auf das Portal zuzugreifen und mit diesem zu interagieren. Typischerweise handelt es sich bei jeder Client- oder Server-Maschine um ein Datenverarbeitungssystem, wie zum Beispiel in 2 veranschaulicht, das Hardware und Software aufweist, und diese Entitäten tauschen Daten über ein Netzwerk wie zum Beispiel das Internet, ein Intranet, ein Extranet, ein privates Netzwerk oder ein(e) beliebige(s) sonstige(s) Datenübertragungsmedium oder -verbindung miteinander aus. Ein Datenverarbeitungssystem enthält typischerweise einen oder mehrere Prozessoren, ein Betriebssystem, eine oder mehrere Anwendungen und ein oder mehrere Dienstprogramme. Die Anwendungen auf dem Datenverarbeitungssystem stellen native Unterstützung für Web-Dienste bereit, darunter unter anderem Unterstützung für HTTP, SOAP, XML, WSDL, UDDI und WSFL, ohne auf diese beschränkt zu sein. Informationen über SOAP, WSDL, UDDI und WSFL sind bei dem World Wide Web Consortium (W3C) erhältlich, das für die Entwicklung und Verwaltung dieser Standards zuständig ist; weiterführende Informationen über HTTP und XML sind bei der Internet Engineering Task Force (IETF) erhältlich. Die Kenntnis dieser Standards wird vorausgesetzt.
Die Anwendungen auf dem Datenverarbeitungssystem können auch native Unterstützung für nichtstandardmäßige Protokolle oder private Protokolle verwenden, die für die Arbeit in einem TCP/IP-Netzwerk entwickelt wurden.
Cloud-Computing-Modell
Wie oben beschrieben, nutzen die Techniken dieser Offenbarung für verteiltes maschinelles Lernen bevorzugt Datenverarbeitungselemente, die sich in einer Cloud-Computing-Umgebung befinden. Daher wird der folgende zusätzliche Hintergrund im Hinblick auf Cloud-Computing bereitgestellt.
Bei Cloud-Computing handelt es sich um ein Modell zum Erbringen von Dienstleistungen, um einen praktischen, bedarfsgesteuerten Netzwerkzugriff auf einen gemeinsam genutzten Pool von konfigurierbaren Datenverarbeitungs-Ressourcen (z.B. Netzwerken, Netzwerkbandbreite, Servern, Verarbeitung, Arbeitsspeicher, Speicher, Anwendungen, virtuellen Maschinen und Diensten) zu ermöglichen, die schnell mit möglichst geringem Verwaltungsaufwand oder Interagieren mit einem Anbieter des Dienstes bereitgestellt und freigegeben werden können. Dieses Cloud-Modell kann zumindest fünf Merkmale, zumindest drei Dienstmodelle und zumindest vier Bereitstellungsmodelle enthalten, die sämtlich in „The NIST Definition of Cloud Computing“ von Peter Mell und Tim Grance vom September 2011 ausführlicher beschrieben und definiert werden.
Im Besonderen handelt es sich bei Folgendem um typische Merkmale:

On-Demand Self-Service: Ein Cloud-Nutzer kann einseitig automatisch nach Bedarf für Datenverarbeitungsfunktionen wie Server-Zeit und Netzwerkspeicher sorgen, ohne dass ein menschliches Interagieren mit dem Anbieter der Dienste erforderlich ist.

Broad Network Access: Es sind Funktionen über ein Netzwerk verfügbar, auf die durch Standardmechanismen zugegriffen wird, welche die Verwendung durch heterogene Thin- oder Thick-Client-Plattformen (z.B. Mobiltelefone, Laptops und PDAs) unterstützen.
Resource-Pooling: Die Datenverarbeitungs-Ressourcen des Anbieters werden zusammengeschlossen, um mehreren Nutzern unter Verwendung eines Multi-Tenant-Modells zu dienen, wobei verschiedene physische und virtuelle Ressourcen dynamisch nach Bedarf zugewiesen und neu zugewiesen werden. Es gibt eine gefühlte Standortunabhängigkeit, da der Nutzer allgemein keine Kontrolle bzw. Kenntnis über den genauen Standort der bereitgestellten Ressourcen hat, aber in der Lage sein kann, einen Standort auf einer höheren Abstraktionsebene festzulegen (z.B. Land, Staat oder Rechenzentrum).
Rapid Elasticity: Funktionen können für eine schnelle horizontale Skalierung (scale out) schnell und elastisch bereitgestellt werden, in einigen Fällen auch automatisch, und für ein schnelles Scale-in schnell freigegeben werden. Für den Nutzer erscheinen die für das Bereitstellen verfügbaren Funktionen häufig unbegrenzt, und sie können jederzeit in jeder beliebigen Menge gekauft werden.
Measured Service: Cloud-Systeme steuern und optimieren die Verwendung von Ressourcen automatisch, indem sie eine Messfunktion auf einer gewissen Abstraktionsebene nutzen, die für die Art von Dienst geeignet ist (z.B. Speicher, Verarbeitung, Bandbreite sowie aktive Benutzerkonten). Die Nutzung von Ressourcen kann überwacht, gesteuert und gemeldet werden, wodurch sowohl für den Anbieter als auch für den Nutzer des verwendeten Dienstes Transparenz geschaffen wird.
Es handelt sich typischerweise um folgende Dienstmodelle:

Software as a Service (SaaS): Die dem Nutzer bereitgestellte Funktion besteht darin, die in einer Cloud-Infrastruktur laufenden Anwendungen des Anbieters zu verwenden. Auf die Anwendungen kann von verschiedenen Client-Einheiten durch eine Thin-Client-Schnittstelle wie zum Beispiel einen Web-Browser (z.B. eMail auf Grundlage des Web) zugegriffen werden. Der Nutzer verwaltet oder steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter das Netzwerk, Server, Betriebssysteme, Speicher oder sogar einzelne Anwendungsfunktionen, mit der möglichen Ausnahme von eingeschränkten benutzerspezifischen Anwendungskonfigurationseinstellungen.

Platform as a Service (PaaS): Die dem Nutzer bereitgestellte Funktion besteht darin, durch einen Nutzer erstellte bzw. erhaltene Anwendungen, die unter Verwendung von durch den Anbieter unterstützten Programmiersprachen und Tools erstellt wurden, in der Cloud-Infrastruktur bereitzustellen. Der Nutzer verwaltet oder steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter Netzwerke, Server, Betriebssysteme oder Speicher, hat aber die Kontrolle über die bereitgestellten Anwendungen und möglicherweise über Konfigurationen des Application Hosting Environment.
Infrastructure as a Service (laaS): Die dem Nutzer bereitgestellte Funktion besteht darin, das Verarbeiten, Speicher, Netzwerke und andere grundlegende Datenverarbeitungs-Ressourcen bereitzustellen, wobei der Nutzer in der Lage ist, beliebige Software bereitzustellen und auszuführen, zu der Betriebssysteme und Anwendungen gehören können. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, hat aber die Kontrolle über Betriebssysteme, Speicher, bereitgestellte Anwendungen und möglicherweise eine eingeschränkte Kontrolle über ausgewählte Netzwerkkomponenten (z.B. Host-Firewalls).
Es handelt sich typischerweise um folgende Bereitstellungsmodelle:

Private Cloud: Die Cloud-Infrastruktur wird einzig und allein für eine Organisation betrieben. Sie kann durch die Organisation oder einen Dritten verwaltet werden und kann sich innerhalb oder außerhalb der eigenen Räumlichkeiten befinden.

Community Cloud: Die Cloud-Infrastruktur wird von mehreren Organisationen gemeinsam genutzt und unterstützt eine spezielle Benutzergemeinschaft, die gemeinsame Angelegenheiten hat (z.B. Mission, Sicherheitsanforderungen, Richtlinien sowie Überlegungen bezüglich der Einhaltung von Vorschriften). Sie kann durch die Organisationen oder einen Dritten verwaltet werden und kann sich innerhalb oder außerhalb der eigenen Räumlichkeiten befinden.
Public Cloud: Die Cloud-Infrastruktur wird der allgemeinen Öffentlichkeit oder einer großen Industriegruppe zur Verfügung gestellt und sie gehört einer Cloud-Dienste verkaufenden Organisation.
Hybrid Cloud: Die Cloud-Infrastruktur ist eine Zusammensetzung aus zwei oder mehreren Clouds (privat, Benutzergemeinschaft oder öffentlich), die zwar einzelne Entitäten bleiben, aber durch eine standardisierte oder proprietäre Technologie miteinander verbunden sind, die Daten- und Anwendungsportierbarkeit ermöglicht (z.B. Cloud-Zielgruppenverteilung für den Lastenausgleich zwischen Clouds).
Eine Cloud-Computing-Umgebung ist dienstorientiert mit einem Schwerpunkt auf Zustandslosigkeit, geringer Kopplung, Modularität und semantischer Interoperabilität. Im Kern von Cloud-Computing befindet sich eine Infrastruktur, die ein Netzwerk aus miteinander verbundenen Knoten aufweist. Ein repräsentativer Cloud-Computing-Knoten entspricht dem in 2 oben veranschaulichten. Im Besonderen befindet sich in einem Cloud-Computing-Knoten ein Computersystem/Server, der mit zahlreichen sonstigen Universal- oder Spezial-Datenverarbeitungssystem-Umgebungen oder -Konfigurationen betrieben werden kann. Zu Beispielen für allgemein bekannte Datenverarbeitungssysteme, -umgebungen und/oder -konfigurationen, die zur Verwendung mit dem Computersystem/Server geeignet sein können, zählen Personal-Computersysteme, Server-Computersysteme, Thin Clients, Thick Clients, Hand- oder Laptop-Einheiten, Mehrprozessorsysteme, Systeme auf Grundlage von Mikroprozessoren, Set-Top-Boxen, programmierbare Unterhaltungselektronik, Netzwerk-PCs, Minicomputersysteme, Großrechnersysteme und verteilte Cloud-Computing-Umgebungen, die beliebige der obigen Systeme oder Einheiten enthalten, und dergleichen, ohne auf diese beschränkt zu sein. Das Computersystem/der Server kann im allgemeinen Zusammenhang von Anweisungen beschrieben werden, die durch ein Computersystem ausgeführt werden können, wie zum Beispiel Programmmodule, die durch ein Computersystem ausgeführt werden. Im Allgemeinen können Programmmodule Routinen, Programme, Objekte, Komponenten, Logik, Datenstrukturen usw. enthalten, die bestimmte Aufgaben durchführen oder bestimmte abstrakte Datentypen implementieren. Das Computersystem/der Server kann in verteilten Cloud-Computing-Umgebungen angewendet werden, in denen Aufgaben durch entfernt angeordnete Verarbeitungseinheiten durchgeführt werden, die durch ein Datenübertragungsnetzwerk miteinander verbunden sind. Bei einer verteilten Cloud-Computing-Umgebung können sich Programmmodule sowohl in lokalen als auch in entfernt angeordneten Computersystem-Speichermedien befinden, darunter in Speichereinheiten.
In einer typischen Cloud-Computing-Umgebung und wie in 3 dargestellt, wird ein Satz von funktionalen Abstraktionsschichten bereitgestellt. Dazu gehören eine Hardware- und Software-Schicht, eine Virtualisierungsschicht, eine Verwaltungsschicht und eine Verarbeitungsprozessschicht.
Die Hardware- und Software-Schicht 300 enthält Hardware- und Software-Komponenten. Zu Beispielen für Hardware-Komponenten zählen Großrechner, in einem Beispiel IBM^® zSeries^®-Systeme; Server auf Grundlage einer RISC-Architektur (Reduced Instruction Set Computer, Computer mit reduziertem Anweisungssatz), in einem Beispiel IBM pSeries^®-Systeme; IBM xSeries^®-Systeme; IBM BladeCenter^®-Systeme; Speichereinheiten, Netzwerke und Netzwerkkomponenten. Zu Beispielen für Software-Komponenten zählen Netzwerkanwendungs-Server-Software, in einem Beispiel die Anwendungs-Server-Software IBM WebSphere^®; und Datenbank-Software, in einem Beispiel die Datenbank-Software IBM DB2^®. (IBM, zSeries, pSeries, xSeries, BladeCenter, WebSphere und DB2 sind in vielen Ländern weltweit eingetragene Marken von International Business Machines Corporation.)
Die Virtualisierungsschicht 302 stellt eine Abstraktionsschicht bereit, aus der die folgenden Beispiele für virtuelle Entitäten bereitgestellt werden können: virtuelle Server; virtueller Speicher; virtuelle Netzwerke, darunter virtuelle private Netzwerke; virtuelle Anwendungen und Betriebssysteme; und virtuelle Clients.
Die Verwaltungsschicht 304 stellt verschiedene Verwaltungsfunktionen bereit. Ressourcen-Bereitstellung stellt zum Beispiel eine dynamische Beschaffung von Datenverarbeitungs-Ressourcen und sonstigen Ressourcen bereit, die zum Durchführen von Aufgaben innerhalb der Cloud-Computing-Umgebung verwendet werden. Messen und Preisbildung stellen die Kostenverfolgung beim Verwenden von Ressourcen innerhalb der Cloud-Computing-Umgebung sowie die Abrechnung oder Rechnungsstellung für die Inanspruchnahme dieser Ressourcen bereit. In einem Beispiel können diese Ressourcen Anwendungs-Software-Lizenzen aufweisen. Die Sicherheit stellt die Identitätsüberprüfung für Cloud-Nutzer und Aufgaben sowie Schutz für Daten und sonstige Ressourcen bereit. Ein Benutzerportal stellt Nutzern und Systemadministratoren den Zugang zu der Cloud-Computing-Umgebung bereit. Eine Dienstgüteverwaltung stellt die Zuordnung und Verwaltung von Cloud-Computing-Ressourcen bereit, so dass die benötigten Dienstziele erreicht werden. Eine Planung und Erfüllung von Dienstgütevereinbarungen (Service Level Agreement, SLA) stellt eine Vorbereitung für und eine Bereitstellung von Cloud-Computing-Ressourcen bereit, für die eine künftige Erfordernis gemäß einer SLA erwartet wird.
Eine Verarbeitungsprozessschicht 306 stellt die Funktionalität bereit, für die die Cloud-Computing-Umgebung eingesetzt wird. Zu Beispielen für Verarbeitungsprozesse und Funktionen, die von dieser Schicht bereitgestellt werden können, gehören: Zuordnung und Navigation; Software-Entwicklung und Lebenszyklusverwaltung; Bereitstellung von virtuellen Schulungen; Datenanalyseverarbeitung; Transaktionsverarbeitung; unternehmensspezifische Funktionen in einer privaten Cloud; und gemäß dieser Offenbarung verteiltes maschinelles Lernen 308.
Folglich weist eine repräsentative Cloud-Computing-Umgebung einen Satz von übergeordneten funktionalen Komponenten auf, zu denen eine Front-End-Identitätsverwaltungseinheit, eine Geschäftsunterstützungsdienste(business support services, BSS)-Funktionskomponente, eine Betriebsunterstützungsdienste(operational support services, OSS)-Funktionskomponente und die Computing-Cloud-Komponente zählen. Die Identitätsverwaltungseinheit ist dafür zuständig, eine Verbindung mit anfordernden Clients zum Bereitstellen einer Identitätsverwaltung herzustellen, und diese Komponente kann mit einem oder mehreren bekannten Systemen implementiert werden, zum Beispiel mit Tivoli Federated Identity Manager (TFIM), das von IBM Corporation, Armonk, New York, erhältlich ist. Unter bestimmten Umständen kann TFIM dazu verwendet werden, sonstigen Cloud-Komponenten eine föderierte einmalige Anmeldung (federated single sign-on, F-SSO) bereitzustellen. Die Geschäftsunterstützungsdienste-Komponente stellt bestimmte administrative Funktionen wie zum Beispiel Abrechnungsunterstützung bereit. Die Betriebsunterstützungsdienste-Komponente wird dazu verwendet, ein Bereitstellen und Verwalten der sonstigen Cloud-Komponenten wie zum Beispiel Instanzen von virtuellen Maschinen (VM) bereitzustellen. Bei einer virtuellen Maschine handelt es sich um ein Betriebssystem oder eine Anwendungsumgebung, die in Software installiert ist, die jedoch eine Hardware-Maschine imitiert. Die Cloud-Komponente stellt die Hauptrechen-Ressourcen dar, bei denen es sich typischerweise um eine Mehrzahl von Instanzen virtueller Maschinen handelt, die dazu verwendet werden, eine Zielanwendung auszuführen, auf die der Zugriff über die Cloud verfügbar gemacht wird. Eine oder mehrere Datenbanken werden dazu verwendet, Verzeichnis-, Protokoll- und sonstige Arbeitsdaten zu speichern. Alle diese Komponenten (einschließlich der Front-End-Identitätsverwaltungseinheit) befinden sich „innerhalb“ der Cloud, dies ist jedoch nicht erforderlich. Bei einer alternativen Ausführungsform kann die Identitätsverwaltung außerhalb der Cloud betrieben werden. Der Diensteanbieter kann ebenfalls außerhalb der Cloud betrieben werden.
Einige Clouds beruhen auf nichtherkömmlichen IP-Netzwerken. So kann eine Cloud zum Beispiel auf zweistufigen Netzwerken auf Grundlage von CLOS mit einem speziellen einschichtigen IP-Routing unter Verwendung von Hash-Werten von MAC-Adressen beruhen. Die hierin beschriebenen Techniken können in solchen nichtherkömmlichen Clouds verwendet werden.
Verallgemeinernd stellt die Cloud-Computing-Infrastruktur eine Hosting-Umgebung für virtuelle Maschinen bereit, die Host-Maschinen (z.B. Server oder ähnliche physische Maschinendatenverarbeitungseinheiten), die über ein Netzwerk verbunden sind, und einen oder mehrere Verwaltungs-Server aufweist. Typischerweise sind die physischen Server jeweils so angepasst, dass sie dynamisch eine oder mehrere virtuelle Maschinen mithilfe von Virtualisierungstechnologie wie zum Beispiel VMware ESX/ESXi bereitstellen. Mehrere VMs können in einer einzelnen Host-Maschine platziert werden und die CPU, den Speicher und sonstige Ressourcen der Host-Maschine gemeinsam nutzen, wodurch die Auslastung eines Rechenzentrums einer Organisation erhöht wird. Neben sonstigen Aufgaben überwacht der Verwaltungs-Server die Infrastruktur und manipuliert bei Bedarf automatisch die VM-Platzierung, z.B. durch Verschieben von virtuellen Maschinen zwischen Hosts.
In einer nichtbeschränkenden Implementierung handelt es sich bei repräsentativen Plattformtechnologien ohne Einschränkung um IBM System-x^®-Server mit VMware vSphere 4.1 Aktualisierung 1 und 5.0.
Föderiertes Lernen und Bedrohungsmodelle
Ein bekannter Ansatz für verteiltes maschinelles Lernen wird in 4 dargestellt. Dieses System weist einen Fusions(Aggregations)-Server 400 und eine Anzahl N von Dateneignern oder Agenten 402 auf, die hierin bisweilen als Lernagenten bezeichnet werden. Bei dieser Ausführungsform hat jeder Lernagent Zugang zu einem lokalen Datensatz d_{_i}, der typischerweise aus gekennzeichneten Stichproben besteht, und möchte dasselbe Modell für maschinelles Lernen oder neuronale Netze trainieren. Jeder Agent verfügt über seinen eigenen Datensatz, den er schützen möchte und nicht mit sonstigen Agenten oder dem Aggregations-Server teilen kann. Bei einer typischen Operation kann ein Prozess verteilten Lernens wie folgt ausgeführt werden. In Schritt (1) kontaktiert jeder Agent 402 den Aggregations-Server 400, um Hyperparameter für das Training zu gewinnen. Beim maschinellen Lernen handelt es sich bei einem Hyperparameter um einen Parameter, dessen Wert vor Beginn des Lernprozesses festgelegt wird; im Gegensatz dazu werden die Werte sonstiger Parameter über das Training abgeleitet. Jeder Agent 402 trainiert denselben Typ von neuronalem Netz. In einem repräsentativen Beispiel wird ein einem Agenten zugehöriges Modell dann durch einen Parametervektor A = [p₁...p_k] gekennzeichnet, der aus mehreren Parametern besteht. Es sind mehrere Agenten in dem System vorhanden, wobei es sich bei A_i um einen durch einen Agenten i gegebenen Parametervektor handelt. In Schritt (2) trainiert der i^te Agent das Modell anhand seines lokalen Datensatzes d_{_i}, und ein solches Training wird typischerweise unter Verwendung eines Mini-Batch durchgeführt, bei dem es sich um eine kleine Teilmenge der gesamten Trainings-Daten handelt, und auf diese Weise berechnet der i^te Agent seinen Parametervektor A_i. In Schritt (3) sendet jeder Agent 402 die resultierenden Parameter an den Aggregations-Server 400, der dann jeden Parameter (typischerweise durch Berechnen eines Mittelwerts oder eines gewichteten Mittelwerts für diesen) in dem Vektor verbindet. Der Mittelwert kann verschiedene Prioritäten (Gewichtungen m) für verschiedene Agenten verwenden; wenn zum Beispiel ein Agent i eine Gewichtung m_i erhält, beträgt der durch den Aggregations-Server berechnete mittlere Parametervektor Σ_i m_iA_i/Σ_i m_i. In Schritt (4) meldet der Aggregations-Server 400 den mittleren Parametervektor an die Agenten 402 zurück. Anschließend werden die Schritte (2) bis (3) mit einer bestimmten Anzahl von Iterationen wiederholt, bis das Lernen als abgeschlossen betrachtet wird.
Es hat sich gezeigt, dass der oben beschriebene Prozess zu demselben Modell führt, das erstellt worden wäre, wenn alle Daten an einem einzigen Ort gesammelt und zum Trainieren des Modells verwendet worden wären, zumindest für Verlustfunktionen, die additiv sind, nämlich Indikatorverlustfunktionen (z.B. Kreuzentropieverlust, auf Normen beruhender Verlust, binäre Kreuzentropie und sonstige). Der Ansatz birgt jedoch das Problem, dass das Modell dem Aggregations-Server offengelegt wird, bei dem es sich typischerweise um einen in der Cloud gehosteten Dienst handelt, dem die Dateneigner/Agenten, die sich möglicherweise nicht selbst in der Cloud befinden, unter Umständen nicht vertrauen. Wie im Folgenden beschrieben wird, behandelt die mehrschichtige Sicherheitstechnik dieser Offenbarung dieses Problem.
Als weiterer Hintergrund war ein Hauptfaktor für das Entstehen des föderierten Lernens die Notwendigkeit, Gefahren für den Datenschutz und Beschränkungen eines zentralen Trainings zu behandeln, bei dem die Trainings-Daten von allen Parteien gesammelt und für das Training auf einem zentralen Server zusammengefasst werden müssen. Bei FL werden die Trainings-Daten dezentral auf den lokalen Einheiten aller Beteiligten gehalten. Teilnehmer (oder Parteien) müssen sich auf eine Modellarchitektur einigen und eine lokale Trainings-Pipeline unterhalten. Anstatt einem zentralen Server Rohdaten für das Training bereitzustellen, trainiert jede Partei, wie in 4 dargestellt, ein lokales Modell mit ihren privaten Trainings-Daten und lädt die Modellaktualisierungen auf einen zentralen Server hoch. Typischerweise ist der Aggregator auch für das Verwalten von Parteien, Koordinieren von Trainings-Aufgaben und Zusammenführen von Modellaktualisierungen zuständig. Die aggregierten Modellaktualisierungen werden (typischerweise) nach jeder Trainings-Iteration zum Synchronisieren ihrer lokalen Modelle an die Parteien gesendet.
Im Folgenden wird weiterer zusätzlicher Hintergrund im Hinblick auf das Trainieren eines DNN in der verteilten Umgebung des föderierten Lernens bereitgestellt. Die Modellparameter seien als θ und die Verlustfunktion als L gekennzeichnet. Jede Partei verfügt über ihre eigenen Trainings-Daten/Kennzeichenpaare (x_i,y_i). Die Parteien können sich dafür entscheiden, die Gradienten ∇_ϑL_ϑ (x_i,y_i) für einen Daten-Batch mit dem Aggregator zu teilen. Der Aggregator berechnet die Gradientensumme aller Parteien und lässt die Parteien ihre Modellparameter lokal synchronisieren: $θ \leftarrow θ - η \sum_{i = 1}^{N} \nabla_{θ} L_{θ} (x_{i}, y_{i}) .$
Dieser Fusionsalgorithmus wird als FedSGD bezeichnet. Alternativ können die Parteien auch über mehrere Epochen lokal trainieren und die Modellparameter: θⁱ←θⁱ-η∇_θiL_θi(x_i,y_i) zu dem Aggregator hochladen. Der Aggregator kann den gewichteten Mittelwert der Modellparameter $θ \leftarrow \sum_{i = 1}^{N} \frac{n_{i}}{n} θ_{i}$
berechnen, wobei n_i die Größe der Trainings-Daten bei der Partei i ist und n die Summe aller n_i ist. Anschließend sendet der Aggregator die aggregierten Modellparameter zur Synchronisierung an die Parteien zurück. Dieser Fusionsalgorithmus zur Modellmittelung wird als FedAvg bezeichnet. FedAvg und FedSGD sind gleichwertig, wenn man nur einen Daten-Batch in einer einzelnen FL-Trainings-Runde trainiert und die Modellparameter synchronisiert, da Gradienten aus der Differenz zweier aufeinanderfolgender Modellparameter-Uploads berechnet werden können. Da FedAvg den Parteien ermöglicht, mehrere SGD-Iterationen vor der Synchronisierung von Aktualisierungen zu stapeln, wäre ein Gelingen von Datenschutzangriffen schwieriger, da die Modellparameter mit mehr eingebrachten Daten verschleiert werden.
Sowohl der FedSGD- als auch der FedAvg-Algorithmus enthalten nur bijektive Summierungs- und Mittelwertbildungsoperationen. Einfach ausgedrückt, wenn das Modell als Array dargestellt wird, führen diese Fusionsalgorithmen eine koordinatenweise Fusion zwischen Parteien durch. Das heißt, sie addieren oder mitteln den Parameter am Index i eines Modells M₁ von der Partei P₁ zu/mit dem Parameter an demselben Index i des Modells M₂ der Partei P₂ - Parameter an einem jeweiligen Index i über Parteien hinweg können ohne Kenntnis derjenigen an einem beliebigen sonstigen Index verbunden werden. Auf diese Weise ist es möglich, die gesamte Modellaktualisierung in mehrere Teile zu partitionieren, sie auf mehreren Servern bereitzustellen und dieselben Fusionsalgorithmen unabhängig voneinander auszuführen. Darüber hinaus können Parameter oder Gradienten vor der Aggregation auch gemischt werden, solange alle Parteien dieselbe Permutation durchführen. Bei FL-Datenschutzangriffen sind die Vollständigkeit und die Datenreihenfolge der Modellaktualisierungen von zentraler Bedeutung für die Optimierungsprozedur, um die Trainings-Daten zu rekonstruieren. Ein Mangel an einem von beidem führt zu Rekonstruktionsfehlern. Wie im Folgenden beschrieben wird, weist die Technik hierin keine solche Einschränkung auf, da lediglich erforderlich ist, dass die Parteien die Partitionierung und Permutation auf den lokalen Seiten umkehren können.
Im Allgemeinen kann föderiertes Lernen in Szenarien sowohl über Einheiten hinweg als auch über Silos hinweg verwendet werden. FL-Training über Einheiten hinweg geht im Allgemeinen mit einer großen Anzahl von mobilen Einheiten oder Einheiten des Internets der Dinge (Internet of Things, loT) als Clients einher. Die Clients sind hochgradig unzuverlässig. Die Einheiten können häufig teilnehmen und ausscheiden, und sie unterliegen Energiebeschränkungen, da sie oft mit Batterien betrieben werden. Ein FL-Training über Silos hinweg geht dagegen typischerweise mit einer festen Anzahl von Organisationen einher, die sich den Anreiz teilen, ein Modell gemeinsam zu lernen. Sie können zuverlässige lokale Trainings-Einrichtungen bereitstellen. Daher können Aggregatoren Parteienstatus aufrechterhalten und die Parteien mit ihren eindeutigen IDs ansprechen. Training über Silos hinweg konzentriert sich mehr auf den Datenschutz mit strengen Anforderungen an die Vertraulichkeit der Daten. Wie ebenfalls zu sehen sein wird, behandelt der Ansatz hierin die Probleme des FL-Trainings über Silos hinweg, er kann aber auch an die Domäne über Einheiten hinweg angepasst werden.
Das Bedrohungsmodell hierin geht von ehrlichen, aber neugierigen Aggregations-Servern aus. Es wird davon ausgegangen, dass alle an dem FL-Trainings-Prozess beteiligten Parteien gutartig sind und nicht dazu neigen, Trainings-Daten miteinander zu teilen. Die Angreifer versuchen, die von den Parteien hochgeladenen Modellaktualisierungen zu untersuchen. Ihr Zweck ist es, die Trainings-Daten der Parteien, die an dem FL-Training teilnehmen, zu rekonstruieren. Dieses Bedrohungsmodell ist dasselbe wie bei den FL-Datenschutzangriffen. Darüber hinaus wird davon ausgegangen, dass die an dem FL beteiligten Parteien der Hardware von Ein-Chip-Systemen (System-on-Chip, SoC) und den EVMs, die die Verarbeitungsprozesse der Modellaggregation enthalten, vertrauen.
Systemkonstruktion
Im Folgenden wird eine repräsentative Konstruktion des Frameworks für föderiertes Lernen dieser Offenbarung genau beschrieben und beschrieben, wie der Ansatz Kanäle zur Preisgabe von Informationen bei FL-Datenschutzangriffen wirksam vermindert. Wie oben angemerkt, nutzt das Framework bevorzugt einen mehrschichtigen Sicherheitsansatz, der (1) vertrauenswürdige Aggregation, (2) dezentrale Aggregation und (3) dynamische Permutationen enthält. Die erste Aggregationstechnik ermöglicht eine vertrauliche und vertrauenswürdige Aggregation bevorzugt über aus der Ferne attestierbare, verschlüsselte virtuelle Maschinen mit Laufzeitspeicherverschlüsselung (z.B. AMD^®-SEV-EVMs). Bei Secure Encrypted Virtualization (SEV), die in dieser beispielhaften Ausführungsform verwendet wird, handelt es sich um eine Datenverarbeitungstechnologie, die 2016 durch AMD eingeführt wurde. Sie zielt darauf ab, sicherheitsrelevante Verarbeitungsprozesse in öffentlichen Cloud-Umgebungen zu schützen. SEV hängt davon ab, dass die Secure Memory Encryption (SME) von AMD die Laufzeitspeicherverschlüsselung ermöglicht. In Kombination mit der AMD-Virtualization(AMD-V)-Architektur kann SEV eine kryptographische Isolierung zwischen Gast-VMs und dem Hypervisor durchsetzen. Daher kann SEV verhindern, dass Systemadministratoren mit höheren Berechtigungen, z.B. auf der Hypervisor-Ebene, auf die Daten innerhalb der Domäne einer verschlüsselten virtuellen Maschine zugreifen. Wenn SEV ermöglicht ist, kennzeichnet die SEV-Hardware den gesamten Code und die Daten einer VM mit einer Adressraumkennung (Address Space Identifier, ASID), die einem eindeutigen ephemeren Schlüssel nach dem Advanced Encryption Standard (AES) zugehörig ist, der als VM Encryption Key (VEK) bezeichnet wird. Die Schlüssel werden durch einen AMD-SP verwaltet, bei dem es sich um eine 32-Bit-ARM-Cortex-A5-Mikrosteuereinheit handelt, die in den AMD-SoC integriert ist. Die Laufzeitspeicherverschlüsselung wird über Speichersteuereinheiten auf dem Chip durchgeführt. Jede Speichersteuereinheit weist eine AES-Engine auf, die Daten verschlüsselt/entschlüsselt, wenn sie in den Hauptspeicher geschrieben werden oder in das SoC gelesen werden. Die Steuerung der Verschlüsselung der Speicherseiten erfolgt über die Seitentabellen. Das Bit 47 der physischen Adresse, auch C-Bit genannt, wird verwendet, um zu kennzeichnen, ob die Speicherseite verschlüsselt ist. Ähnlich wie sonstige TEEs stellt SEV auch einen Attestierungsmechanismus aus der Ferne für die Berechtigungsprüfung der Hardware-Plattform und die Attestierung der zu startenden Gast-VMs bereit. Die Echtheit der Plattform wird mit einem Identitätsschlüssel nachgewiesen, der durch AMD und den Eigentümer der Plattform signiert ist. Vor einem Bereitstellen jeglicher geheimer Schlüssel überprüfen die Eigentümer von Gast-VMs sowohl die Echtheit von SEV-fähiger Hardware als auch den Messwert von UEFI-Firmware, der das Starten verschlüsselter virtueller Maschinen unterstützt.
5 stellt diese allgemeine Vorstellung von vertraulicher Aggregation dar. Es wird davon ausgegangen, dass in der Cloud isolierte und unabhängige vertrauenswürdige Ausführungsumgebungen vorhanden sind, von denen eine bei 500 dargestellt wird, wie zum Beispiel die oben in Bezug auf 3 beschriebene Cloud-Ausführungsumgebung. TEEs wie zum Beispiel die TEE 500 ermöglichen Benutzern, ihre Berechnungen an Cloud-Server von Dritten auszulagern und dabei auf das CPU-Paket zu vertrauen. Zu repräsentativen TEE-Technologien zählen z.B. Intel^® SGX (Software Guard Extensions)/TDX (Trust Domain Extensions), AMD^® SEV (wie oben beschrieben), IBM^® PEF (Protected Execution Facility), ARM TrustZone und sonstige. TEEs sind besonders attraktiv für gemeinsame ML-Berechnungen, die eine große Menge an datenschutzrelevanten Trainings-Daten, mehrere verteilende Parteien und strengere Datenschutzbestimmungen beinhalten können. Hier und wie im Folgenden beschrieben wird, fungiert die TEE 500 als vertrauenswürdiger Vermittler für eine Isolierung einer Aggregator-Ausführungsentität von anderen solchen Ausführungsentitäten, die das föderierte Lernen erleichtern.
Wie in 5 dargestellt, ist die TEE 500 einem auf einem Betriebssystem beruhenden Container-Mechanismus (z.B. einem Open-Source-Container wie etwa Kata-Container) zum Verpacken und zur Bereitstellung zugehörig und führt eine isolierte virtuelle Maschine aus. Im Besonderen führt die TEE 500 einen Aggregator 502 innerhalb einer verschlüsselten virtuellen Maschine (EVM) 504 aus, die durch Laufzeitspeicherverschlüsselung (wie zum Beispiel SEV) 506 unterstützt wird. Durch Ausführen des Aggregators innerhalb der TEE werden Angriffe zur Beschädigung des Speichers vermindert. Der Aggregator 502 ist einer von einem Satz von dezentralen Aggregatoren, die zusammen den in 4 dargestellten einzelnen Aggregator aufweisen. Jeder Aggregator wie zum Beispiel der Aggregator 502 wird innerhalb einer EVM 504 ausgeführt, und ein EVM-Speicher ist durch einen eindeutigen ephemeren Verschlüsselungsschlüssel für virtuelle Maschinen (VEK) geschützt. Auf diese Weise wird die Vertraulichkeit der Modellaggregationsberechnung auch vor unberechtigten Benutzern, z.B. Systemadministratoren, und berechtigter Software wie zum Beispiel einem Hypervisor oder Betriebssystem, die auf den Hosting-Servern ausgeführt werden, geschützt. Wie beschrieben wird, prüfen die Parteien 508 des föderierten Lernens jeweils aus der Ferne die echte SEV-Hardware/Firmware auf Berechtigung, bevor sie am Training teilnehmen, und bauen einen durchgängigen, sicheren Kanal zum Austauschen von Modellaktualisierungen auf. Im Besonderen wird eine Attestierung aus der Ferne, die durch den Attestierungs-Server 505 erleichtert wird, zum Bereitstellen einer Berechtigungsprüfung von Hardware und Integritätsprüfungen des Aggregators zur Ladezeit verwendet. Wie ebenso dargestellt, verfügt jede Partei 508 über Daten und ihre eigene Infrastruktur 510 für maschinelles Lernen (ML) und arbeitet typischerweise durch Austauschen von Attributen (z.B. Modellgradienten) zusammen.
Vor dem Hintergrund des Obigen wird im Folgenden eine ausführlichere Beschreibung eines repräsentativen Bereitstellungsbeispiels für das Framework für föderiertes Lernen dieser Offenbarung bereitgestellt.
Ein repräsentatives Bereitstellungsbeispiel für das Framework für föderiertes Lernen wird in 6 dargestellt. In diesem Beispiel nehmen vier (4) Parteien 600 (von Partei 1 bis 4 durchnummeriert) an dem föderierten Lernen teil, und der Aggregationsmechanismus ist in drei (3) Aggregator-Ausführungsentitäten 602 (von Aggregator 1 bis 3 durchnummeriert) dezentralisiert. Jede Aggregator-Ausführungsentität 602 wird innerhalb einer TEE 604 ausgeführt, und folglich sind drei TEEs (von TEE1 bis 3 durchnummeriert) vorhanden. Ähnlich wie bei herkömmlichem föderierten Lernen muss sich in dem Ansatz hierin jede Partei 600 bei den Aggregatoren 602 registrieren, um an dem Training teilzunehmen. Jede Partei muss die TEE-Plattform vor der Registrierung überprüfen, z.B. über eine Attestierung aus der Ferne. Eine Aggregator-Ausführungsentität initiiert den Trainings-Prozess zuerst durch Benachrichtigen sämtlicher Parteien. Während der Trainings-Phase beteiligen sich die Aggregatoren an einer Reihe von Trainings-Iterationen mit sämtlichen Parteien. Bei jeder Trainings-Iteration synchronisiert jede Partei zuerst das lokale Modell durch Herunterladen der neuesten Modellaktualisierungen von den Aggregatoren, verwendet anschließend lokale Trainings-Daten, um eine neue Modellaktualisierung herzustellen, und lädt sie zu den Aggregatoren hoch. Die Aggregatoren führen Modellaktualisierungen von allen Parteien zusammen und senden die aggregierte Version an alle Parteien zurück. Das globale Training endet, sobald vorgegebene Trainings-Kriterien erfüllt sind, z.B. dass das FL-Training eine vorgegebene Anzahl von Trainings-Iterationen erreicht, oder die Parteien können beschließen, das FL-Training zu beenden, nachdem eine Anforderung an die Modellgenauigkeit lokal erfüllt ist. Anders als bei herkömmlichem FL geht die Bereitstellung damit einher, dass statt eines einzelnen zentralen Aggregators, wie in 4 dargestellt wurde, mehrere Aggregatoren 602 innerhalb der TEEs 604 ausgeführt werden. In diesem System müssen die Aggregatoren 602 zur Synchronisierung des Trainings Daten miteinander austauschen. Darüber hinaus wird auch ein Attestierungs-Server 606 bereitgestellt, der für das Attestieren des Verarbeitungsprozesses des Aggregators und das Bereitstellen von geheimen Schlüsseln zuständig ist, wie im Folgenden beschrieben wird.
Vertrauenswürdige Aggregation
Wie zuvor erwähnt, können zwischen Parteien und Aggregatoren ausgetauschte Modellaktualisierungen wichtige Informationen für eine Rückentwicklung von privaten Trainings-Daten enthalten. Die folgende Technik wird verwendet, um die Kanäle zu beseitigen, über die Angreifer die Modellaktualisierungen während der Übertragung und auch während der Verwendung abfangen und untersuchen. Bei dieser Konstruktion wird bevorzugt eine kryptographische Isolierung für die FL-Aggregation über einen Mechanismus wie zum Beispiel SEV (aber nicht darauf beschränkt) durchgesetzt. Wie in 5 angemerkt, werden die Aggregatoren innerhalb von EVMs ausgeführt, und der Speicher jeder EVM ist mit einem eindeutigen ephemeren VEK geschützt. Bei der in 6 dargestellten Ausführungsform wird ein Herstellen des Vertrauens zwischen Aggregatoren 602 und Parteien 600 in zwei Phasen unterteilt:
Phase I: Starten von vertrauenswürdigen Aggregatoren
Zuerst werden die SEV-EVMs mit darin ausgeführten Aggregatoren sicher gestartet. Um das Vertrauen von EVMs herzustellen, wird eine Attestierung bereitgestellt, um nachzuweisen, dass (1) es sich bei der Plattform um eine authentische, sichere (z.B. AMD-SEV-fähige) Hardware handelt, die die erforderlichen Sicherheitseigenschaften bereitstellt, und (2) ein Unified Extensible Firmware Image (UEFI) zum Starten der EVM nicht manipuliert ist. Nachdem die Attestierung aus der Ferne abgeschlossen ist, wird ein geheimer Schlüssel bevorzugt als eindeutige Kennung eines vertrauenswürdigen Aggregators für die EVM bereitgestellt. Der geheime Schlüssel wird in den verschlüsselten physischen Speicher der EVM eingefügt und in der im Folgenden beschriebenen Phase II zur Berechtigungsprüfung der Aggregatoren verwendet. In 6 stellt Schritt (1) den Attestierungs-Server 606 dar, der eine Attestierung aus der Ferne erleichtert. Zu diesem Zweck weist der EVM-Eigentümer einen Diensteanbieter (z.B. einen AMD^®-SP) an, eine Zertifikatskette z.B. von einem öffentlichen Plattform-Diffie-Hellman(PDH)-Schlüssel in ein Stammverzeichnis herunterzuladen (z.B. einen AMD-Root-Schlüssel (AMD Root Key, ARK)). Diese Zertifikatskette kann durch die Stammzertifikate überprüft werden. Darüber hinaus sind zusammen mit der Zertifikatskette bevorzugt auch ein Auszug eines UEFI-Image, eine SEV-API-Version und eine VM-Bereitstellungsrichtlinie in dem Attestierungsbericht enthalten.
Der Attestierungsbericht wird an den Attestierungs-Server 606 gesendet, der mit den Stammzertifikaten versorgt wird, um die Zertifikatskette zu überprüfen, um die Berechtigung der Hardware-Plattform zu prüfen. Danach erzeugt der Attestierungs-Server 606 ein Start-Blob und ein Zertifikat für einen öffentlichen Gasteigentümer-Diffie-Hellman-Schlüssel (Guest Owner Diffie-Hellman Public Key, GODH). Diese werden zum Vereinbaren eines Transportverschlüsselungsschlüssels (Transport Encryption Key, TEK) und eines Transportintegritätsschlüssels (Transport Integrity Key, TIK) durch einen Diffie-Hellman-Schlüsselaustausch (Diffie-Hellman Key Exchange, DHKE) und zum Starten der EVMs an den Aggregations-Server 606 zurückgesendet. Der UEFI-Messwert kann durch den SP durch Anhalten der EVM zur Startzeit abgerufen werden. Dieser Messwert wird zum Nachweisen der Integrität des UEFI-Boot-Prozesses an den Attestierungs-Server 606 gesendet. Erst danach erzeugt der Attestierungs-Server 606 ein geheimes Schlüsselpaket, das bevorzugt einen ECDSA-prime251v1-Schlüssel enthält. Der (nicht dargestellte) Hypervisor fügt diesen geheimen Schlüssel als eindeutige Kennung eines vertrauenswürdigen Aggregators in den physischen Speicherbereich der EVM ein und setzt den Startprozess fort. Die Einfügeprozedur für diesen geheimen Schlüssel befolgt bevorzugt ein Protokoll zur Attestierung aus der Ferne wie zum Beispiel das Protokoll zur SEV-Attestierung aus der Ferne der 1^-sten Generation. Sonstige Protokolle zur Attestierung aus der Ferne, z.B. das aufkommende SEV-SNP, können implementiert werden, um die Integrität des Startprozesses weiter zu verstärken.
Phase II: Berechtigungsprüfung von Aggregatoren
An einem FL teilnehmende Parteien müssen sicherstellen, dass sie mit vertrauenswürdigen Aggregatoren mit Laufzeitspeicherverschlüsselungsschutz interagieren. Um eine Berechtigungsprüfung von Aggregatoren zu ermöglichen, und wie oben beschrieben worden ist, stellt der Attestierungs-Server 606 in Phase I während einer EVM-Bereitstellung einen privaten ECDSA-Schlüssel als geheimen Schlüssel bereit. Dieser Schlüssel wird zum Signieren von Prüffrageanforderungen verwendet und dient somit zum Erkennen eines berechtigten Aggregators. In Schritt (2) in 6 attestiert eine Partei, bevor sie an einem FL teilnimmt, einen Aggregator, indem sie an einem Prüffrage-Anforderungsprotokoll teilnimmt. Zu diesem Zweck sendet die Partei 600 eine willkürlich erzeugte Nonce an den Aggregator 602. Der Aggregator 602 signiert die Nonce digital mithilfe seines entsprechenden privaten ECDSA-Schlüssels und gibt anschließend die signierte Nonce an die anfordernde Partei zurück. Die Partei überprüft, ob die Nonce mit dem entsprechenden öffentlichen ECDSA-Schlüssel signiert ist. Wenn die Überprüfung erfolgreich ist, geht die Partei 600 anschließend dazu über, sich bei dem Aggregator 602 zu registrieren, um an dem FL teilzunehmen. Darüber hinaus werden bevorzugt sichere Kanäle bereitgestellt, um die Datenübertragung unter Aggregatoren und zwischen den Aggregatoren und Parteien zum Aktualisieren von Modellparametern zu schützen. Sichere Kanäle können mithilfe von Transport Layer Security (TLS) implementiert werden, um eine gegenseitige Berechtigungsprüfung zwischen einer Partei und einem Aggregator zu unterstützen. Auf diese Weise werden alle ausgetauschten Modellaktualisierungen sowohl bei der Verwendung als auch bei der Übertragung geschützt.
Dezentrale Aggregation mit Modellpartitionierung
Wenngleich ein Ermöglichen einer vertrauenswürdigen Aggregation erhebliche Vorteile bietet, reicht dies allein möglicherweise nicht aus, da nicht garantiert ist, dass TEEs allmächtig sind und in Zukunft keine Sicherheitslücken aufgedeckt werden. Daher erhöht die zweite Sicherheitsschicht, die dezentrale Aggregation mit Modellpartitionierung, die Widerstandsfähigkeit des Systems, um sicherzustellen, dass, selbst wenn TEEs durch Datenlecks verletzt werden, Angreifer dennoch keine Trainings-Daten aus Modellaktualisierungen rekonstruieren können. Dieser Aspekt dieser Offenbarung wird im Folgenden ausführlich erläutert, erneut in Bezug auf die in 6 dargestellte repräsentative Implementierung.
Wie zuvor erläutert, wird jeder Aggregator 602 innerhalb einer EVM ausgeführt und ist lediglich für einen Teil der Modellaktualisierungen zuständig. In 6 werden drei (3) Aggregatoren aufgebaut, und wie zuvor beschrieben worden ist, überprüft jede teilnehmende Datei die Berechtigung aller Aggregatoren bzw. registriert sich bei diesen. Die dezentrale Aggregation wird in diesem Beispiel wie folgt ermöglicht.
Trainings-Synchronisierung zwischen Aggregatoren
Zwischen den Aggregatoren werden Datenübertragungskanäle für eine Synchronisierung des Trainings unterhalten, z.B. Schritt (3). Standardmäßig kann ein beliebiger der Aggregatoren 602 die Trainings-Iterationen starten und zu einem Initiatorknoten werden. Alle sonstigen Aggregatoren werden zu Follower-Knoten und warten auf die Befehle von dem Initiator. Bei jeder Trainings-Iteration fragt der Initiator zuerst alle Parteien ab, um ein lokales Training zu starten und die Modellaktualisierungen zur Fusion abzurufen. Danach benachrichtigt der Initiator alle Follower-Knoten, damit sie ihre entsprechenden Modellaktualisierungen abrufen, sie zusammen aggregieren und die aggregierten Aktualisierungen an die Parteien zurückverteilen.
Dezentrale Aggregation erhöht den Aufwand für ein unrechtmäßiges Gewinnen von Modellinformationen am Aggregationspunkt. Die Aggregatoren halten keine Informationen über die Modellarchitektur mehr vor; sie sehen nur noch Vektoren von Zahlen. Darüber hinaus kann selbst ein Verpassen eines sehr kleinen Teils der Modellaktualisierungen die Angriffe zur Datenrekonstruktion völlig unwirksam machen. Daher erfordert dieses Schutzschema eine Beeinträchtigung aller durch eine TEE geschützten Aggregatoren, um einen vollständigen Satz von Modellaktualisierungen zu gewinnen.
Wenngleich es sehr schwierig ist, alle TEE-geschützten Aggregatoren zu beeinträchtigen, wird im Folgenden die dritte Sicherheitsschicht, die dynamische Permutation, beschrieben, die implementiert werden kann, um das föderierte Lernen weiter vor einer Preisgabe von Informationen oder sonstigen Beeinträchtigungen zu schützen.
Dynamische Permutation
Zu diesem Zweck und um die von den Parteien an die Aggregatoren übertragenen Informationen weiter zu verschleiern, wird bevorzugt ein Schema zur dynamischen Permutation bereitgestellt, um die partitionierten Modellaktualisierungen zu mischen, bevorzugt bei jeder Trainings-Iteration (oder in einem sonstigen definierten Zeitraum). Wie oben angemerkt, beruht das Schema zur dynamischen Permutation auf der Erkenntnis, dass die Reihenfolge von Parametern bei der Modellaktualisierung für Fusionsalgorithmen irrelevant ist, wohingegen sie für Algorithmen zur Datenrekonstruktion, die bei FL-Datenschutzangriffen verwendet werden, entscheidend ist. Da diese Datenreihenfolge verschleiert ist, ist es für Angreifer unmöglich, rekonstruierte Trainings-Daten zu erzeugen, selbst wenn sie die gesamten Modellaktualisierungen gewinnen.
Randomisierte Modellpartitionierung.
Die Modellpartitionierung und die dynamische Permutation werden in 7 dargestellt, und zwar in Bezug auf die drei (3) dort dargestellten Aggregatoren. Im Besonderen entsprechen Aggregatoren 702 (Aggregator 1 bis 3) den Aggregatoren 602 in 6. Bevor das Training beginnt, wird für jedes zu trainierende DNN-Modell zufällig ein Aggregator-Mapper 710 (eine Datenstruktur) erzeugt. Die Parteien wählen den Anteil der Modellparameter für jeden Aggregator, wenngleich dieser auf einen Standardwert festgelegt werden kann. Darüber hinaus müssen sich die lokalen Parteien auf den Mapper 710 einigen, und auf diese Weise wird dieser Mapper 710 von all den Parteien, die an dem FL-Training teilnehmen, gemeinsam genutzt. In 7 weist eine erste Partei ein trainiertes lokales Modell 712 auf. Wie in 7 dargestellt, und mithilfe des Mappers 710 werden die k Parameter des lokalen Modells 712 den drei Aggregatoren, d.h., den Aggregatoren{1 bis 3}, wie dargestellt, zugeordnet, wobei die dargestellten Abtönungen und Schraffierungen die Aggregator-Attribute für jeden Parameter innerhalb des Modells darstellen. Wie ebenfalls dargestellt, werden die Modellaktualisierungen zerlegt und für verschiedene Aggregatoren neu angeordnet (Schritt (4) in 6), um die gemischten Partitionen zu erzeugen. Die gemischten Partitionen werden dann zu den jeweiligen Aggregatoren hochgeladen, und die Fusion wird ausgeführt, um die aggregierten Partitionen zu erzeugen. Nachdem die Parteien die aggregierten Modellaktualisierungen von den verschiedenen Aggregatoren empfangen haben, mischen sie die aggregierten Modellaktualisierungen zurück in die richtige Reihenfolge. Derselbe Mapper 710 wird dann erneut abgefragt, um Modellaktualisierungen an den ursprünglichen Positionen innerhalb des lokalen Modells zusammenzuführen (Schritt (5) in 6). In 7 wird nur ein lokales Modell (trainiert und dann zusammengeführt) dargestellt, aber jede der Parteien weist ihre eigenen lokalen Modellkonstruktionen auf.
Bevorzugt mischt dieses Schema zur dynamischen Permutation die partitionierten Modellaktualisierungen bei jeder Trainings-Iteration. Jede Permutation wird mit einem zwischen allen Parteien vereinbarten geheimen Schlüssel (z.B. über einen vertrauenswürdigen Vermittler verbreitet) und einer dynamisch erzeugten Trainings-Iterations-ID initialisiert. Auf diese Weise ändert sich die Permutation bevorzugt bei jeder Trainings-Iteration, stimmt aber über alle Parteien hinweg überein. Anders ausgedrückt, der Ansatz hierin mischt bevorzugt die Modellaktualisierungen bei jeder Trainings-Iteration dynamisch mit einer deterministischen Permutation. Der Aggregator (und zwar die Aggregator-Ausführungsentitäten) führt die Modellaktualisierungen zusammen, und die Parteien sind dafür zuständig, die Reihenfolge der aggregierten Modellaktualisierungen wiederherzustellen. Der Ansatz vermindert Datenleckangriffe, indem er die Reihenfolge der hochgeladenen Modellparameter dynamisch mischt. Auf diese Weise und neben sonstigen Vorteilen macht der Ansatz den Datenschutz von lokalen Trainings-Daten beim föderierten Lernen effizienter.
Auf diese Weise wird gemäß diesem Aspekt bevorzugt eine gesamte Modellaktualisierung, die durch eine Partei erzeugt wird, in mehrere Teile (Partitionen) partitioniert, wobei die Partitionen auf mehreren Servern (Aggregationsausführungsentitäten) bereitgestellt werden, auf denen dieselben Fusionsalgorithmen unabhängig voneinander ausgeführt werden. Das Weiteren werden Parameter oder Gradienten (oder allgemeiner, Elemente) vor der Aggregation auch lokal gemischt (d.h., permutiert), sofern alle Parteien dieselbe Permutation durchführen. Es ist lediglich erforderlich, dass die Parteien die Partitionierung und Permutation auf den lokalen Seiten umkehren können. Die Partitionierung und Permutation der lokalen Modellaktualisierung kann periodisch ausgeführt werden, z.B. bei jeder Trainings-Iteration oder in einem sonstigen definierten Zeitraum; alternativ können die Partitionierung und Permutation der Aktualisierung asynchron erfolgen.
Die Partitionierung des gesamten lokalen Modells in die Partitionen und die Permutation eines oder mehrerer Elemente innerhalb jeder Partition erfolgen bei jeder Modellierungsiteration. Für alle Partitionen gelten entweder dieselben Partitionen oder keine. Darüber hinaus kann die Strategie der Partitionierung und/oder Permutation auch auf einen zentralen Aggregator angewendet werden (ein Fall, in dem die Anzahl der Aggregationsentitäten gleich 1 ist); in diesem Fall ist keine Partitionierung vorhanden, jedoch gibt es eine Permutation der Gewichtungen bei der Modellaktualisierung.
Verallgemeinernd erleichtert das Schema zur dynamischen Permutation, wie es oben beschrieben worden ist, eine aggregierte Verschleierung beim föderierten Lernen. Eine Partei beim föderierten Lernen (oder allgemeiner, ein erstes System einer Mehrzahl von Systemen, die an dem föderierten Lernen beteiligt sind) legt fest, dass ein Aktualisierungsvektor (oder allgemeiner, eine Aktualisierung) zur Fusion übertragen werden sollte. Anschließend wird ein Verschleierungsalgorithmus angewendet, um den Aktualisierungsvektor zu verschleiern, um einen verschleierten Aktualisierungsvektor zu erzeugen. Zu diesem Zweck kann ein geheimer Schlüssel verwendet werden, der von allen Parteien gemeinsam genutzt wird, und jede Partei des föderierten Lernens verwendet denselben gemeinsam genutzten geheimen Schlüssel, um den Verschleierungsalgorithmus lokal anzuwenden. Wie in 7 beispielhaft erläutert, wechselt ein bevorzugter Verschleierungsalgorithmus eine Reihenfolge von Elementen des Aktualisierungsvektors, um den verschleierten Aktualisierungsvektor zu erzeugen. So, wie sie hierin verwendet wird, ist die Vorstellung des Wechselns der Reihenfolge der Elemente gleichbedeutend mit dem Mischen oder Permutieren. Der verschleierte Aktualisierungsvektor wird dann an jede Aggregator-Ausführungsentität übertragen (wenn mehrere solcher Entitäten zum Erstellen des Models für maschinelles Lernen verwendet werden). Die Aktualisierung kann bei jeder Trainings-Iteration mit verschiedenen Reihenfolgen der Elemente durchgeführt werden. Wenngleich es sich beim Mischen der Reihenfolge der Elemente des Aktualisierungsvektors um eine bevorzugte Technik zur Verschleierung handelt, können sonstige Verschleierungsalgorithmen verwendet werden.
Die hierin beschriebenen Techniken bieten erhebliche Vorteile. Wie einem Fachmann ersichtlich ist, sichert und schützt die Aggregation beim föderierten Lernen vor Rückentwicklungsangriffen und hält gleichzeitig den Aufwand gering und unterstützt viele verschiedene Deep-Learning-Modelle und -Frameworks. Darüber hinaus stellen die Techniken hierin mehrere strukturelle und randomisierte Modellpartitionierungsmechanismen bereit, um die ausgewechselten Modellparameter zu zerlegen. Selbst wenn eine Teilmenge von Aggregatoren beeinträchtigt wird, werden die Angreifer dennoch daran gehindert, die Informationen der Trainings-Daten zu rekonstruieren. Darüber hinaus ermöglichen die Techniken hierin den Lernteilnehmern, die vertrauenswürdige Hardware-Plattform auf Berechtigung zu prüfen und die Verarbeitungsprozesse zu attestieren, die Gegenstand eines föderierten Lernens sind, so dass weiterhin sichergestellt ist, dass sensible Daten nicht offengelegt und ohne durchgängigen kryptografischen Schutz übertragen werden. Die Techniken hierin haben keinen Einfluss auf die endgültige Modellgenauigkeit und Konvergenzgeschwindigkeit im Vergleich mit herkömmlichem FL-Training. Gleichzeitig minimiert der Ansatz die Offenlegung von nichtwesentlichen Informationen zwischen Parteien und Aggregatoren erheblich, was für ein Durchführen von FL-Datenschutzangriffen entscheidend ist.
Wie oben beschrieben, nutzt der Ansatz hierin die einzigartigen Recheneigenschaften von Fusionsalgorithmen für föderiertes Lernen und stellt architektonische und Protokollverbesserungen bereit, um potenzielle Kanäle zur Preisgabe von Informationen zu vermindern. Das beschriebene System für föderiertes Lernen setzt bevorzugt dreischichtige Sicherheitsstrategien ein, d.h., vertrauliche und vertrauenswürdige Aggregation, dezentrale Modellpartitionierung und dynamische Permutation von Modellaktualisierungen. Ein System für föderiertes Lernen, das diese Sicherheitsstrategien implementiert, ist immun gegen Angriffe zur Rekonstruktion von Trainings-Daten.
Wenngleich die drei Techniken bevorzugt zusammen verwendet werden, ist dies ferner keine Voraussetzung. So kann ein Framework für föderiertes Lernen, das die Techniken dieser Offenbarung implementiert, von einer oder mehreren der folgenden Techniken und Strategien profitieren. Eine erste Strategie ermöglicht eine vertrauenswürdige und aus der Ferne attestierbare Modellaggregation durch Nutzen vertraulicher Datenverarbeitungstechnologien. Eine zweite Strategie besteht in einem Dezentralisieren eines einzelnen Aggregators auf mehrere unabhängige Ausführungsentitäten, die bevorzugt jeweils nur einen unvollständigen Überblick über die Modellaktualisierungen haben und die Modellarchitekturen nicht kennen. Eine dritte Strategie stellt eine Unterstützung für randomisierte und dynamische Permutationen für die partitionierten Modellaktualisierungen bei jeder Trainings-Iteration bereit, um Algorithmen zur Datenrekonstruktion undurchführbar zu machen. Durch Implementieren aller dreischichtigen Sicherheitsstrategien und wie oben angemerkt, neutralisiert das System Datenschutzangriffe nach dem Stand der Technik beim föderierten Lernen und weist eine geringe Leistungseinbuße im realen Einsatz auf.
Es bestehen noch weitere Vorteile. Einer besteht darin, dass der Ansatz des verteilten Lernens keine Erzeugung von Hilfseingaben erfordert und die Trainings-Teilnehmer sich nur eine Teilmenge der verschleierten Modellparameter in dem Prozess des föderierten Lernens teilen. Die vertrauenswürdigen Ausführungsumgebungen schützen die Vertraulichkeit der Modellaktualisierungsdaten bei der Übertragung und bei der Aggregation. Darüber hinaus verhindert der Ansatz, dass böswillige oder beeinträchtigte Aggregations-Server Trainings-Daten von Teilnehmern am föderierten Lernen rekonstruieren. Der Ansatz verhindert, dass sowohl (i) ehrliche, aber neugierige Aggregatoren als auch (ii) böswillige oder beeinträchtigte Aggregatoren die privaten Trainings-Daten aus Modellaktualisierungen rekonstruieren. Ein weiterer Vorteil besteht darin, dass derselbe Ansatz für verschiedene FL-Aufgaben eingesetzt werden kann und dasselbe Niveau der Trainings-Leistung wie bei der Vergleichsbasis erreichen kann.
Die oben beschriebene Technik kann mithilfe von beliebigen Algorithmen oder Berechnungen für maschinelles Lernen implementiert werden, die in der Lage sind, in der beschriebenen Weise verteilt zu werden.
Dieser Gegenstand kann ganz oder teilweise als Dienstleistung implementiert werden. Verallgemeinernd kann die vertrauenswürdige und dezentrale Aggregation für eine Funktionalität föderierten Lernens als eigenständige Funktion bereitgestellt werden, oder sie kann eine Funktionalität sonstiger auf ML beruhender Produkte und Dienstleistungen nutzen. Beispielsweise kann die Sicherheitstechnik hierin bekannte Angebote und Lösungen wie IBM Framework for Federated Learning (FFL) nutzen, um die beschriebene vertrauenswürdige Aggregation, dezentralisierte Mehrfach-Aggregatoren mit Modellpartitionierung und dynamische Permutation von Modellaktualisierungen zu unterstützen. Bevorzugt ist die Aggregator-Anwendung containerisiert, um ihre Bereitstellung zu erleichtern, wenngleich dies keine Voraussetzung ist. Es können Kata-Container eingesetzt werden, um Aggregator-Container innerhalb von einfachen VMs bereitzustellen. Auf diese Weise und wie beschrieben worden ist, wird jeder Aggregator-Container bevorzugt in einer durch SEV (oder gleichwertig) geschützten EVM ausgeführt. Um die TEE-Sicherheitsfunktionen bereitzustellen, und in dieser beispielhaften, aber nichtbeschränkenden Ausführungsform wird ein Mikroprozessor AMD EPYC 7642 (Rome) verwendet, auf dem die Firmware SEV API ausgeführt wird.
Die oben insgesamt oder zum Teil beschriebene Funktionalität kann als eigenständiger Ansatz implementiert werden, z.B. eine Funktion auf Grundlage von Software, die durch einen Hardware-Prozessor ausgeführt wird, oder sie kann als verwalteter Dienst (einschließlich eines Web-Dienstes über eine SOAP/XML-Schnittstelle) verfügbar sein. Die jeweiligen hierin beschriebenen Einzelheiten der Hardware- und Software-Implementierung dienen lediglich der Veranschaulichung und sollen den Umfang des beschriebenen Gegenstandes nicht einschränken.
Allgemeiner ausgedrückt, bei Datenverarbeitungseinheiten im Zusammenhang mit dem offenbarten Gegenstand handelt es sich jeweils um ein Datenverarbeitungssystem (wie es zum Beispiel in 2 dargestellt wird), das Hardware und Software aufweist, und diese Entitäten tauschen Daten über ein Netzwerk wie zum Beispiel das Internet, ein Intranet, ein Extranet, ein privates Netzwerk oder ein(e) beliebige(s) sonstige(s) Datenübertragungsmedium oder -verbindung miteinander aus. Die Anwendungen auf dem Datenverarbeitungssystem stellen native Unterstützung für Web-Dienste und sonstige bekannte Dienste und Protokolle bereit, darunter unter anderem Unterstützung für HTTP, FTP, SMTP, SOAP, XML, WSDL, UDDI und WSFL, ohne auf diese beschränkt zu sein. Informationen über SOAP, WSDL, UDDI und WSFL sind bei dem World Wide Web Consortium (W3C) erhältlich, das für die Entwicklung und Verwaltung dieser Standards zuständig ist; weiterführende Informationen über HTTP, FTP, SMTP und XML sind bei der Internet Engineering Task Force (IETF) erhältlich. Die Kenntnis dieser bekannten Standards und Protokolle wird vorausgesetzt.
Das hierin beschriebene Schema kann in oder in Verbindung mit verschiedenen Server-seitigen Architekturen implementiert werden, darunter mit einfachen n-stufigen Architekturen, Sicherheitssystemen, Web-Portalen, föderierten Systemen und dergleichen. Wie ebenfalls angemerkt, können die Techniken hierin in einer (darunter auf einer „Cloud“ beruhenden) Umgebung von lose gekoppelten Servern umgesetzt werden, wie im Zusammenhang mit 3 beschrieben.
Noch allgemeiner ausgedrückt, der hierin beschriebene Gegenstand kann eine reine Hardware-Ausführungsform, eine reine Software-Ausführungsform oder eine Ausführungsform annehmen, die sowohl Hardware- als auch Software-Elemente enthält. Bei einer bevorzugten Ausführungsform wird die Funktion in Software implementiert, was Firmware, residente Software, Mikrocode und dergleichen einschließt, jedoch nicht darauf beschränkt ist. Darüber hinaus kann die auf einem Identitätskontext beruhende Funktionalität der Zugriffssteuerung, wie oben angemerkt, die Form eines Computerprogrammprodukts annehmen, auf das von einem durch einen Computer verwendbaren bzw. durch einen Computer lesbaren Medium zugegriffen werden kann, das Programmcode zur Verwendung durch bzw. in Verbindung mit einem Computer bzw. einem beliebigen System zur Anweisungsausführung bereitstellt. Im Sinne dieser Beschreibung kann ein durch einen Computer verwendbares oder durch einen Computer lesbares Medium jede Vorrichtung sein, die das Programm zur Verwendung durch das System, die Vorrichtung bzw. Einheit zur Anweisungsausführung bzw. in Verbindung mit diesen enthalten oder speichern kann. Bei dem Medium kann es sich um ein elektronisches, magnetisches, optisches, elektromagnetisches oder Infrarotmedium oder ein Halbleitersystem (bzw. eine entsprechende Vorrichtung oder Einheit) handeln. Zu Beispielen für ein durch einen Computer lesbares Medium zählen ein Halbleiter- bzw. Solid-State-Speicher, ein Magnetband, eine auswechselbare Computer-Diskette, ein Direktzugriffsspeicher (random access memory, RAM), ein Festwertspeicher (read-only memory, ROM), eine starre Magnetplatte und eine optische Speicherplatte. Zu aktuellen Beispielen für optische Speicherplatten zählen ein Compact-Disk-Festwertspeicher (compact disk-read only memory, CD-ROM), ein Compact-Disk-Schreib-Lese-Speicher (compact disk-read/write, CD-R/W) und eine DVD. Bei dem durch einen Computer lesbaren Medium handelt es sich um ein greifbares Element.
Bei dem Computerprogrammprodukt kann es sich um ein Produkt handeln, das Programmanweisungen (oder Programmcode) zum Implementieren einer oder mehrerer der beschriebenen Funktionen aufweist. Diese Anweisungen oder dieser Code kann in einem durch einen Computer lesbaren Speichermedium in einem Datenverarbeitungssystem gespeichert werden, nachdem diese(r) über ein Netzwerk von einem entfernt angeordneten Datenverarbeitungssystem heruntergeladen worden sind/ist. Alternativ können diese Anweisungen oder kann dieser Code in einem durch einen Computer lesbaren Speichermedium in einem Server-Datenverarbeitungssystem gespeichert und zum Herunterladen über ein Netzwerk auf ein entfernt angeordnetes Datenverarbeitungssystem zur Verwendung in einem durch einen Computer lesbaren Speichermedium innerhalb des entfernt angeordneten Systems angepasst werden.
Bei einer repräsentativen Ausführungsform werden der Fusions-Server und jeder Agent in einem Spezialcomputer implementiert, bevorzugt in Software, die durch einen oder mehrere Prozessoren ausgeführt wird. Die Software wird in einem oder mehreren Datenspeichern oder Arbeitsspeichern verwaltet, die dem einen oder den mehreren Prozessoren zugehörig sind, und die Software kann als ein oder mehrere Computerprogramme implementiert werden. Gemeinsam weisen die Spezial-Hardware und -Software die oben beschriebene Funktionalität auf.
Wenngleich Obiges eine bestimmte Reihenfolge von Operationen beschreibt, die durch bestimmte Ausführungsformen der Erfindung durchgeführt werden, versteht es sich, dass eine solche Reihenfolge beispielhaft ist, da alternative Ausführungsformen die Operationen in einer anderen Reihenfolge durchführen, bestimmte Operationen kombinieren, bestimmte Operationen sich überschneiden lassen können oder dergleichen. Wenn in der Beschreibung auf eine bestimmte Ausführungsform Bezug genommen wird, weist dies darauf hin, dass die beschriebene Ausführungsform ein bestimmtes Merkmal, eine bestimmte Struktur oder Eigenschaft enthalten kann, jedoch muss nicht jede Ausführungsform das bestimmte Merkmal, die bestimmte Struktur oder Eigenschaft unbedingt enthalten.
Wenngleich bestimmte Komponenten des Systems getrennt beschrieben worden sind, ist schließlich einem Fachmann ersichtlich, dass einige der Funktionen in bestimmten Anweisungen, Programmsequenzen, Codeabschnitten und dergleichen kombiniert oder gemeinsam genutzt werden können.
Die Techniken hierin stellen Verbesserungen an einer/einem sonstigen Technologie oder Gebiet der Technik, z.B. an Systemen für maschinelles Lernen, Systemen für die Verwaltung von Sicherheitsvorfällen und -ereignissen (security incident and event management, SIEM), sonstigen Sicherheitssystemen sowie Verbesserungen an auf Automatisierung beruhenden Cyber-Sicherheitsanalysen bereit.
Nachdem der Gegenstand beschrieben worden ist, wird Folgendes beansprucht.

Claims

Verfahren zum Bereitstellen von föderiertem Lernen mit verringerter Preisgabe von Informationen über eine Modellaggregation, das aufweist: Laden einer Aggregator-Ausführungsentität in einer vertrauenswürdigen Ausführungsumgebung, wobei die vertrauenswürdige Ausführungsentität Schutz durch Laufzeitspeicherverschlüsselung bereitstellt, es sich bei der Aggregator-Ausführungsentität um eine aus einem Satz von Aggregator-Ausführungsentitäten handelt, die zusammen einen Aggregator aufweisen, der dazu ausgebildet ist, Modellaktualisierungen zu verbinden, die durch mehrere Parteien bereitgestellt werden, die gemeinsam daran arbeiten, ein Modell für maschinelles Lernen zu erstellen; Registrieren jeder der mehreren Parteien bei der Aggregator-Ausführungsentität; Empfangen einer Modellaktualisierung in der Aggregator-Ausführungsentität von jeder der mehreren Parteien, wobei die Modellaktualisierungen durch die vertrauenswürdige Ausführungsentität automatisch speicherintern verschlüsselt werden; und Ausführen der Aggregator-Ausführungsentität innerhalb der vertrauenswürdigen Ausführungsumgebung mithilfe der Modellaktualisierungen und gemeinsam mit den sonstigen des Satzes von Aggregator-Ausführungsentitäten, um das Modell für maschinelles Lernen in einer sicheren und vertrauenswürdigen Weise zu erzeugen.
Verfahren nach Anspruch 1, das des Weiteren ein Attestieren einer Integrität der Aggregator-Ausführungsentität aufweist.
Verfahren nach einem der vorhergehenden Ansprüche, das des Weiteren aufweist: Aufbauen und Unterhalten eines sicheren Datenübertragungskanals mit zumindest einer sonstigen Aggregator-Ausführungsentität; und Verwenden des sicheren Datenübertragungskanals für eine Synchronisierung eines Trainings während des föderierten Lernens.
Verfahren nach einem der vorhergehenden Ansprüche, wobei es sich bei der von einer Partei empfangenen Modellaktualisierung um eine Partition einer durch die Partei erzeugten gesamten Modellaktualisierung handelt.
Verfahren nach Anspruch 4, wobei eine Reihenfolge von Parameter- oder Gradientenelementen in zumindest einer Partition gemischt wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei in Bezug auf zumindest eine sonstige des Satzes von Aggregator-Ausführungsentitäten die Aggregator-Ausführungsentität ausgeführt wird in/an einer/einem von: einer anderen Maschine, einem anderen Rechenzentrum, einer anderen vertrauenswürdigen Ausführungsumgebungsarchitektur und einem anderen geographischen Standort.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Laden der Aggregator-Ausführungsentität ein Empfangen eines eindeutigen geheimen Schlüssels in der vertrauenswürdigen Ausführungsumgebung und ein Verwenden des eindeutigen geheimen Schlüssels zur Berechtigungsprüfung der Aggregator-Ausführungsentität bei einer Registrierung einer Partei aufweist.
Vorrichtung, die aufweist: einen Hardware-Prozessor; einen Computerspeicher, der Computerprogrammanweisungen enthält, die durch den Hardware-Prozessor ausgeführt werden, um föderiertes Lernen mit einer verringerten Preisgabe von Informationen über eine Modellaggregation bereitzustellen, wobei die Computerprogrammanweisungen ausgebildet sind zu einem: Laden einer Aggregator-Ausführungsentität in einer vertrauenswürdigen Ausführungsumgebung, wobei die vertrauenswürdige Ausführungsentität Schutz durch Laufzeitspeicherverschlüsselung bereitstellt, es sich bei der Aggregator-Ausführungsentität um eine aus einem Satz von Aggregator-Ausführungsentitäten handelt, die zusammen einen Aggregator aufweisen, der dazu ausgebildet ist, Modellaktualisierungen zu verbinden, die durch mehrere Parteien bereitgestellt werden, die gemeinsam daran arbeiten, ein Modell für maschinelles Lernen zu erstellen; Registrieren jeder der mehreren Parteien bei der Aggregator-Ausführungsentität; Empfangen einer Modellaktualisierung in der Aggregator-Ausführungsentität, wobei die Modellaktualisierungen durch die vertrauenswürdige Ausführungsentität automatisch speicherintern verschlüsselt werden; und Ausführen der Aggregator-Ausführungsentität innerhalb der vertrauenswürdigen Ausführungsumgebung mithilfe der Modellaktualisierungen und gemeinsam mit den sonstigen des Satzes von Aggregator-Ausführungsentitäten, um das Modell für maschinelles Lernen in einer sicheren und vertrauenswürdigen Weise zu erzeugen.
Vorrichtung nach Anspruch 8, wobei die Computerprogrammanweisungen des Weiteren dazu ausgebildet sind, eine Integrität der Aggregator-Ausführungsentität zu attestieren.
Vorrichtung nach einem der Ansprüche 8 bis 9, wobei die Computerprogrammanweisungen des Weiteren ausgebildet sind zu einem: Aufbauen und Unterhalten eines sicheren Datenübertragungskanals mit zumindest einer sonstigen Aggregator-Ausführungsentität; und Verwenden des sicheren Datenübertragungskanals für eine Synchronisierung eines Trainings während des föderierten Lernens.
Vorrichtung nach einem der Ansprüche 8 bis 10, wobei es sich bei der von einer Partei empfangenen Modellaktualisierung um eine Partition einer durch die Partei erzeugten gesamten Modellaktualisierung handelt.
Vorrichtung nach Anspruch 11, wobei eine Reihenfolge von Parameter- oder Gradientenelementen in zumindest einer Partition gemischt ist.
Vorrichtung nach einem der Ansprüche 8 bis 12, wobei in Bezug auf zumindest eine sonstige des Satzes von Aggregator-Ausführungsentitäten die Aggregator-Ausführungsentität ausgeführt wird in/an einer/einem von: einer anderen Maschine, einem anderen Rechenzentrum, einer anderen vertrauenswürdigen Ausführungsumgebungsarchitektur und einem anderen geographischen Standort.
Vorrichtung nach einem der Ansprüche 8 bis 13, wobei die Computerprogrammanweisungen, die dazu ausgebildet sind, die Aggregator-Ausführungsentität zu laden, des Weiteren Computerprogrammanweisungen enthalten, die dazu ausgebildet sind, einen eindeutigen geheimen Schlüssel in der vertrauenswürdigen Ausführungsumgebung zu empfangen und den eindeutigen geheimen Schlüssel zur Berechtigungsprüfung der Aggregator-Ausführungsentität bei einer Registrierung einer Partei zu verwenden.
Computerprogrammprodukt in einem nichttransitorischen, durch einen Computer lesbaren Medium zur Verwendung in einem Datenverarbeitungssystem zum Bereitstellen von föderiertem Lernen mit einer verringerten Preisgabe von Informationen über eine Modellaggregation, wobei das Computerprogrammprodukt Computerprogrammanweisungen enthält, die, wenn sie durch das Datenverarbeitungssystem ausgeführt werden, ausgebildet sind zu einem: Laden einer Aggregator-Ausführungsentität in einer vertrauenswürdigen Ausführungsumgebung, wobei die vertrauenswürdige Ausführungsentität Schutz durch Laufzeitspeicherverschlüsselung bereitstellt, es sich bei der Aggregator-Ausführungsentität um eine aus einem Satz von Aggregator-Ausführungsentitäten handelt, die zusammen einen Aggregator aufweisen, der dazu ausgebildet ist, Modellaktualisierungen zu verbinden, die durch mehrere Parteien bereitgestellt werden, die gemeinsam daran arbeiten, ein Modell für maschinelles Lernen zu erstellen; Registrieren jeder der mehreren Parteien bei der Aggregator-Ausführungsentität; Empfangen einer Modellaktualisierung in der Aggregator-Ausführungsentität, wobei die Modellaktualisierungen durch die vertrauenswürdige Ausführungsentität automatisch speicherintern verschlüsselt werden; und Ausführen der Aggregator-Ausführungsentität innerhalb der vertrauenswürdigen Ausführungsumgebung mithilfe der Modellaktualisierungen und gemeinsam mit den sonstigen des Satzes von Aggregator-Ausführungsentitäten, um das Modell für maschinelles Lernen in einer sicheren und vertrauenswürdigen Weise zu erzeugen.
Computerprogrammprodukt nach Anspruch 15, wobei die Computerprogrammanweisungen des Weiteren dazu ausgebildet sind, eine Integrität der Aggregator-Ausführungsentität zu attestieren.
Computerprogrammprodukt nach einem der Ansprüche 15 bis 16, wobei die Computerprogrammanweisungen des Weiteren ausgebildet sind zu einem: Aufbauen und Unterhalten eines sicheren Datenübertragungskanals mit zumindest einer sonstigen Aggregator-Ausführungsentität; und Verwenden des sicheren Datenübertragungskanals für eine Synchronisierung eines Trainings während des föderierten Lernens.
Computerprogrammprodukt nach einem der Ansprüche 15 bis 17, wobei es sich bei der von einer Partei empfangenen Modellaktualisierung um eine Partition einer durch die Partei erzeugten gesamten Modellaktualisierung handelt.
Computerprogrammprodukt nach Anspruch 18, wobei eine Reihenfolge von Parameter- oder Gradientenelementen in zumindest einer Partition gemischt ist.
Computerprogrammprodukt nach einem der Ansprüche 15 bis 19, wobei in Bezug auf zumindest eine sonstige des Satzes von Aggregator-Ausführungsentitäten die Aggregator-Ausführungsentität ausgeführt wird in/an einer/einem von: einer anderen Maschine, einem anderen Rechenzentrum, einer anderen vertrauenswürdigen Ausführungsumgebungsarchitektur und einem anderen geographischen Standort.
Computerprogrammanweisungen nach einem der Ansprüche 15 bis 20, wobei die Computerprogrammanweisungen, die dazu ausgebildet sind, die Aggregator-Ausführungsentität zu laden, des Weiteren Computerprogrammanweisungen enthalten, die dazu ausgebildet sind, einen eindeutigen geheimen Schlüssel in der vertrauenswürdigen Ausführungsumgebung zu empfangen und den eindeutigen geheimen Schlüssel zur Berechtigungsprüfung der Aggregator-Ausführungsentität bei einer Registrierung einer Partei zu verwenden.
System für föderiertes Lernen, das vor einer Preisgabe von Informationen über eine Modellaggregation sicher ist, das aufweist: einen Satz von vertrauenswürdigen Ausführungsumgebungen; und einen Aggregator, der in einen Satz von unabhängigen Aggregator-Ausführungsentitäten partitioniert ist, wobei sich jede Aggregator-Ausführungsentität in einer jeweiligen des Satzes von vertrauenswürdigen Ausführungsumgebungen befindet; wobei eine Aggregator-Ausführungsentität dazu ausgebildet ist, eine Modellaktualisierung von jeder aus einem Satz von Parteien zu empfangen, die an einer Sitzung eines föderierten Lernens teilnehmen, wobei die Modellaktualisierungen durch die vertrauenswürdige Ausführungsentität automatisch speicherintern verschlüsselt werden; wobei die Aggregator-Ausführungsentitäten, die innerhalb der vertrauenswürdigen Ausführungsentitäten ausgeführt werden, einen Fusionsalgorithmus mithilfe der Modellaktualisierungen ausführen, um ein Modell für maschinelles Lernen in einer sicheren und vertrauenswürdigen Weise zu erzeugen.
System für föderiertes Lernen nach Anspruch 22, wobei in Bezug auf zumindest eine sonstige des Satzes von Aggregator-Ausführungsentitäten eine Aggregator-Ausführungsentität ausgeführt wird in/an einer/einem von: einer anderen Maschine, einem anderen Rechenzentrum, einer anderen vertrauenswürdigen Ausführungsumgebungsarchitektur und einem anderen geographischen Standort.
System für föderiertes Lernen nach einem der Ansprüche 22 bis 23, wobei es sich bei einer von einer Partei empfangenen Modellaktualisierung um eine Partition einer durch die Partei erzeugten gesamten Modellaktualisierung handelt.