Google Research hat ein föderiertes Lernsystem der nächsten Generation angekündigt, das auf Trusted Execution Environments basiert, und das Team erhebt eine Behauptung, die vor einigen Jahren als unerreichbar abgetan worden wäre: erstmals extern überprüfbare zentrale differenzielle Datenschutzgarantien für föderiertes Lernen. Das System, das auf Gboard angewendet wird, ersetzt eine langjährige „Vertrauens-uns“-Vereinbarung durch kryptografische Bescheinigungen und öffentliche Protokolle, die externe Prüfer tatsächlich einsehen können. Für eine fortlaufende Berichterstattung über datenschutzschonendes maschinelles Lernen folgen Sie unseren neuesten KI-Entwicklungen.
Die Vertrauenslücke beim föderierten Lernen
Federated Learning, das Google 2017 einführte, sollte ein spezifisches Problem lösen: wie man nützliche Modelle auf Benutzerdaten trainiert, ohne diese Daten zentral zu sammeln. Anstatt rohes Tippverhalten auf einen Server hochzuladen, berechnen Geräte Modellaktualisierungen lokal und tragen nur diese Aktualisierungen bei. Der Ansatz ermöglicht im Stillen eine bemerkenswerte Menge dessen, was Benutzer jeden Tag berühren – die Vorhersage des nächsten Wortes und Smart Compose in Gboard, Antwortvorschläge in Google Messages und Smart Text Selection in Android.
Aber die ursprüngliche Architektur hatte im Kern eine Vertrauenslücke. Geräte luden ihre Daten zur sofortigen Aggregation hoch, und Außenstehende hatten keine Möglichkeit zu überprüfen, ob die Daten unterwegs nie protokolliert, aufbewahrt oder überprüft wurden. Die Nutzer mussten sich auf Googles Wort verlassen, was serverseitig geschah. Später fügte Secure Aggregation einen kryptografischen Schutz hinzu, so dass einzelne Beiträge nicht isoliert gelesen werden konnten – diese Technik war jedoch nicht mit modernen zentralen differenziellen Datenschutzalgorithmen wie der Matrixfaktorisierung DP-FTRL kompatibel und ließ dennoch eine Annahme unangetastet: Google musste darauf vertrauen können, dass das differenzielle Datenschutzrauschen korrekt hinzugefügt wurde. Ein falsch konfigurierter Geräuschparameter wäre für alle unsichtbar, außer für das Unternehmen, das den Fehler gemacht hat.
So funktioniert das neue System
Das neue Design greift die Vertrauensannahme direkt an. Es verlagert die Gradientenberechnung des Clients auf den Server – innerhalb einer vertrauenswürdigen Ausführungsumgebung – und macht diese Serverlogik dann nachweisbar, sodass dem Bediener überhaupt nicht mehr vertraut werden muss. Ein TEE ist eine hardwareisolierte Prozessorenklave, deren laufender Code von Außenstehenden kryptografisch verifiziert werden kann; Wenn die Enklave etwas anderes tut, als sie behauptet, wird die Bescheinigung unterbrochen.
Laut Googles Ankündigung koordiniert das System vier Kernkomponenten. Zuerst der Daten-Upload: Geräte verschlüsseln Trainingsbeispiele lokal und autorisieren vorab eine Zugriffsrichtlinie, die genau auflistet, welche TEE-Berechnungen die Daten verarbeiten dürfen – und diese Richtlinien müssen in einem öffentlichen Transparenzprotokoll erscheinen. Zweitens gibt ein Schlüsselverwaltungssystem, das aus TEEs besteht, die das RAFT-Konsensprotokoll ausführen, Entschlüsselungsschlüssel nur für Workloads frei, die der veröffentlichten Richtlinie entsprechen. Drittens: Workload-Ausführung: Ein Root-TEE führt eine Python-Trainingsschleife aus und delegiert Unteraufgaben an Worker-TEEs, wobei die Orchestrierung von einem System namens Federated Language übernommen wird, das vom TensorFlow Federated-Framework von Google abgeleitet ist. Aus der Enklave werden immer nur unterschiedliche private Modellgewichte freigegeben. Viertens fehlertolerante Wiederherstellung: Jede Trainingsrunde speichert einen KMS-verschlüsselten Wiederherstellungsstatus, sodass Root- oder Worker-Ausfälle laufende Schulungen nicht zerstören.
Warum die Garantien tatsächlich überprüft werden können
Der Anspruch auf Überprüfbarkeit beruht auf einer Kette öffentlicher Beweise und nicht auf Unternehmensbescheinigungen. Zugriffsrichtlinien werden in Rekor, dem öffentlichen Transparenzprotokoll von Sigstore, veröffentlicht, sodass externe Prüfer jede Serverauslastung verfolgen können, die möglicherweise von den Daten eines Geräts gespeist werden könnte. Die KMS- und Datenverarbeitungs-Binärdateien können aus Open-Source-Code reproduzierbar erstellt werden, was bedeutet, dass jeder die veröffentlichte Quelle kompilieren und bestätigen kann, dass sie mit den in der Produktion ausgeführten Binärdateien übereinstimmt.
Die Richtlinien selbst beschreiben direkt das Python-Trainingsprogramm, das die häufigste Lücke in Datenschutzarchitekturen schließt: eine Lücke zwischen dem, was eine Datenschutzrichtlinie sagt, und dem, was der Code tatsächlich tut. Um proprietäre Modellarchitekturen zu schützen, unterstützen die TEEs das Seitenladen serialisierter Logik zur Laufzeit – jedoch mit der strengen Einschränkung, dass die gesamte datenschutzrelevante Logik im zertifizierten Programm fest codiert bleiben muss. Workload-Betreiber, darunter Googles eigenes Infrastrukturpersonal, sehen nur Metriken und differenziell private Modellgewichtungen. Verschlüsselte Daten können nach dem Hochladen nur für eine begrenzte Zeit entschlüsselt werden, wodurch das Fenster begrenzt wird, in dem überhaupt etwas überprüft werden kann.
Vom Versprechen zum Beweis
Die Bedeutung des Designs liegt weniger in der einzelnen Komponente als vielmehr in der Belastungsverlagerung, die es verursacht. Datenschutzgarantien beim maschinellen Lernen wurden in der Vergangenheit als Versprechen formuliert, die durch Richtliniendokumente, interne Audits und den Ruf des Betreibers gestützt wurden. Dieses System wandelt diese Versprechen in Artefakte um – Attestierungsberichte, Transparenzprotokolleinträge, reproduzierbare Builds – die ein Skeptiker ohne Zugriff auf die Interna von Google überprüfen kann.
Es markiert auch eine bemerkenswerte Konvergenz zweier Forschungsgemeinschaften, die größtenteils parallel gearbeitet haben. Vertrauenswürdige Ausführungsumgebungen und differenzierter Datenschutz lösen verschiedene Probleme: TEEs schränken ein, wer mit Daten rechnen darf, während DP einschränkt, was bei jeder Berechnung durchsickern kann. Durch die Kombination unter einem einzigen nachweisbaren Programm, bei dem die DP-Rauschenerzeugung selbst innerhalb der überprüften Enklave erfolgt, werden die Restschwächen jedes Ansatzes isoliert behoben.
Derzeit läuft das System im Google-eigenen Stack und ermöglicht Trainings-Workloads, wie sie Gboard durchführt. Ob überprüfbarer Datenschutz branchenweit zu einer Wettbewerbserwartung wird – so wie HTTPS, nachdem die Transparenzprotokollierung für Zertifikate standardisiert wurde –, hängt davon ab, ob Benutzer und Regulierungsbehörden anfangen, anderen KI-Anbietern die Frage zu stellen, die dieses System beantworten soll: es beweisen.
---
Der KI einen Schritt voraus seinErhalten Sie die neuesten KI-Nachrichten, Analysen und Durchbrüche – alles an einem Ort.
Weitere KI-Neuigkeiten lesen →
