Föderiertes Lernen gilt als datenschutzfreundlich, weil die Trainingsdaten das Gerät der Nutzer gar nicht erst verlassen müssen. Nur Modellupdates gehen zum Server, so die verbreitete Darstellung. Der Beitrag „Toward provably private learning from federated data“, den Katharine Daly und Daniel Ramage von Google Research auf dem Forschungsblog des Unternehmens veröffentlicht haben, zeigt aber, dass dieses Versprechen über Jahre auf Vertrauen gebaut war und nicht auf Nachprüfbarkeit: Ob die hochgeladenen Daten tatsächlich nie zwischengespeichert oder eingesehen wurden, konnte von außen niemand belegen. Genau darum geht es im Folgenden – föderiertes Lernen war nie automatisch datenschutzfreundlich, es musste erst überprüfbar gemacht werden. Warum plötzlich von Trusted Execution Environments, Transparenz-Logs und reproduzierbaren Builds die Rede ist, klärt dieser Überblick.
Föderiertes Lernen, vier Prinzipien und eine nachgeschärfte Definition
Google stellte das föderierte Lernen 2017 als Verfahren vor, das Modelle über verteilte, private Daten trainiert, ohne diese zusammenzuführen. Laut Unternehmen kam es unter anderem bei der Wortvorhersage und Smart Compose auf Gboard zum Einsatz, bei Antwortvorschlägen in Google Messages sowie bei der intelligenten Textauswahl unter Android. Das Team nennt vier Prinzipien, an denen es sich orientiert: Datenminimierung, Anonymisierung, Transparenz und Kontrolle sowie Verifizierbarkeit und Auditierbarkeit. Der vierte Punkt ist der entscheidende, denn er verschiebt die Frage von „Ist das datenschutzfreundlich?“ zu „Kann jemand von außen nachprüfen, dass es das ist?“. An dieser Verschiebung hängt der Rest des Beitrags.
2025 hat das Team eine überarbeitete Definition vorgelegt, die mehr festhält als die technische Grundidee. Föderiertes Lernen ist demnach eine Lernumgebung, in der mehrere Einheiten als Clients unter der Koordination eines Diensteanbieters zusammenarbeiten. Ein vollständiges System müsse den Clients die volle Kontrolle über ihre Daten geben: über die Menge der Arbeitslasten, die auf diese Daten zugreifen dürfen, und über die Anonymisierungseigenschaften dieser Arbeitslasten. Auch die Menschen, deren Daten von den Clients verwaltet werden, sollen angemessene Transparenz und Kontrolle erhalten. Das klingt nach einer Formalie, ist aber eine Machtverschiebung: Nicht der Betreiber legt fest, was mit den Daten passieren darf, sondern das Gerät führt eine Positivliste der erlaubten Berechnungen.
Trusted Execution Environments: versiegelte Räume mit beglaubigtem Siegel
Vorstellen kann man sich das wie einen Laborraum, in dem gearbeitet werden darf, aber niemand hineinsehen kann – nicht einmal der Hausherr. Trusted Execution Environments, kurz TEEs, sind abgeschottete Ausführungsumgebungen auf einem Prozessor. Sie bieten drei Eigenschaften, die hier zusammenwirken: Vertraulichkeit, weil der interne Zustand nicht beobachtet werden kann, Integrität, weil die Logik nicht unterbrochen oder verändert werden kann, und die Möglichkeit der Remote-Attestierung, bei der Dritte nachprüfen können, welcher Code dort tatsächlich läuft. Einschränkungen der aktuellen TEE-Generation gelten dabei ausdrücklich mit, wie die Autoren betonen.
Ein einzelner versiegelter Raum genügt aber nicht. Das neue System setzt viele solcher Umgebungen so zusammen, dass daraus ein durchgängig überprüfbarer Ablauf entsteht, vom Gerät bis zur fertigen Modellaktualisierung. Die Attestierung, die auf einer einzelnen Maschine nur eine Aussage über diese eine Maschine erlaubt, wird also zum Baustein einer Kette. Erst durch diese Verkettung entsteht, was der Beitrag verifizierbaren Datenschutz nennt – und erst dadurch werden Eigenschaften, die vorher Zusicherungen waren, zu überprüfbaren Tatsachen.
Vier Bausteine: Upload, Schlüsselverwaltung, Workload-Ausführung, Wiederherstellung
Der erste Baustein ist der Upload. Client-Geräte verschlüsseln Trainingsbeispiele lokal und laden sie hoch. Dabei autorisieren sie vorab eine Zugriffsrichtlinie, also die Menge der TEE-Berechnungen, die diese Daten verarbeiten dürfen, und diese Berechnungen geben ausschließlich anonymisierte Ergebnisse frei. Die Richtlinien müssen in einem öffentlichen Transparenz-Log veröffentlicht werden, sonst greift der Mechanismus nicht. Wer die Daten erzeugt, bestimmt also, welcher Code sie später überhaupt anfassen darf.
Der zweite Baustein ist die Schlüsselverwaltung. Ein Key Management System, das als Cluster von TEEs den Konsensalgorithmus RAFT umsetzt, gibt Entschlüsselungsschlüssel nur an serverseitige TEE-Arbeitslasten heraus, die exakt den Berechnungen aus der Zugriffsrichtlinie entsprechen. Ohne passende Richtlinie kein Schlüssel – die Policy ist damit keine Dokumentation, sondern eine technische Sperre. Der dritte Baustein ist die Ausführung: Eine Root-TEE startet ein Python-Programm mit der Trainingsschleife und delegiert parallelisierbare Teilaufgaben an einen Cluster von Worker-TEEs. Die verteilte Logik wird in Federated Language ausgedrückt, einer quelloffenen, framework-unabhängigen Orchestrierungssprache, die aus TensorFlow Federated hervorgegangen ist. Der vierte Baustein schließlich ist die Fehlertoleranz: Am Ende jeder Trainingsrunde speichert das Programm einen KMS-verschlüsselten Wiederherstellungszustand, mit dem sich Ausfälle von Root- oder Worker-TEEs überbrücken lassen, ohne zusätzliche privatheitsrelevante Informationen preiszugeben.
Verifizierbarer Datenschutz durch Transparenz-Log, reproduzierbare Builds und Sideloading
In älteren Systemen wurden Gerätedaten zum Zweck der unmittelbaren Aggregation hochgeladen, doch externe Beobachter konnten nicht prüfen, dass diese Daten nie protokolliert oder eingesehen wurden. Später schützte Secure Aggregation die Uploads kryptografisch, war aber nicht mit modernen zentralen Garantien differenzieller Privatsphäre vereinbar. Die neue Architektur ist nach Darstellung der Autoren ein weiterer Schritt auf dem Weg, das Vertrauen in den Serverbetreiber vollständig überflüssig zu machen. Sichtbar bleiben für die Betreiber der Arbeitslasten nur Metriken und differenziell private Modellgewichte. Verschlüsselte Trainingsdaten von Geräten lassen sich ausschließlich innerhalb von TEEs entschlüsseln und verarbeiten, die den in der Richtlinie hinterlegten Python-Programmen entsprechen, und das nur für eine begrenzte Zeit nach dem Upload.
Die Zugriffsrichtlinien werden in Rekor veröffentlicht, einem öffentlichen Transparenz-Log, in dem externe Auditoren nachvollziehen können, welche serverseitigen Arbeitslasten ein Gerät potenziell unterstützt. Die Binärdateien von Schlüsselverwaltung und Datenverarbeitung lassen sich reproduzierbar aus offengelegtem Quellcode bauen, der im Repository Confidential Federated Compute auf GitHub liegt. Ein Detail verdient Aufmerksamkeit: Die TEEs unterstützen dynamisches Sideloading, mit dem zur Laufzeit serialisierte Informationen in das Python-Programm geladen werden. Proprietäre Modellarchitekturen und Vorverarbeitungslogik bleiben dadurch geschützt, während die privatheitsrelevante Logik fest im auditierten Programm verankert ist. Die Garantie hängt also daran, dass diese Trennung sauber eingehalten wird – ein Punkt, an dem Auditoren künftig genau hinschauen sollten.
Was Gboard konkret gewinnt: weniger Tagesrhythmus, deutlich kürzere Trainingsläufe
Gboard hat das TEE-basierte System bereits produktiv eingesetzt, um englische und japanische Modelle für die Wortvorhersage zu starten – mit stärkeren Datenschutzgarantien und besserer Genauigkeit. Die Autoren führen das auf mehrere Eigenschaften des neuen Designs zurück. Weil alle Geräte-Uploads gesammelt werden, bevor die serverseitige Trainingslast startet, müssen sie keine Rücksicht mehr auf tageszeitliche Schwankungen der Geräteverfügbarkeit nehmen. Der optimale Beteiligungsplan der Geräte lässt sich zur Ausführungszeit dynamisch berechnen und dazu nutzen, weitere Parameter der differenziellen Privatsphäre abzustimmen.
Der zweite Gewinn ist die Geschwindigkeit. Früher dauerten solche Trainingsläufe ein bis zwei Monate, begrenzt durch Geräteverfügbarkeit, Rechenleistung auf den Geräten und den Wettbewerb mehrerer Trainingslasten um dieselben Ressourcen. Im neuen System hat sich der Engpass auf die Serverseite verschoben, wo die Parallelisierung über viele Maschinen erheblich beschleunigt; begrenzend wirkt derzeit nur die Verfügbarkeit von TEE-Ressourcen. Für dich als Leser bedeutet das weniger eine technische Fußnote als eine Verschiebung der Machbarkeitsgrenze: Was vorher aus Praktikabilität klein bleiben musste, lässt sich nun größer denken. Ganz ohne Preis ist das nicht, denn die Rechenarbeit wandert vom Gerät in Rechenzentren, und die brauchen Strom und Hardware.
Wo die Grenzen liegen und was als Nächstes ansteht
Die Autoren benennen die Schwächen offen. TEEs bieten Schutz auf Basis aktueller Hardware, und Seitenkanalbeobachtungen bleiben ein Forschungsfeld, gegen das dynamisch geladene Arbeitslasten bislang weniger gut geschützt sind als fest eingebauter Code. Man erwartet, dass künftige TEE-Generationen hier tieferen Schutz bieten. Zudem verschiebt das neue System die Berechnung der Client-Gradienten auf den Server, wodurch Beschränkungen der Rechenleistung auf Endgeräten entfallen – der Weg zu größeren Modellen mit föderierten Verfahren wird damit frei. Die Integration von TEEs mit Beschleunigern spielt für solche Fälle eine zentrale Rolle.
Die Infrastruktur ist nicht auf föderiertes Lernen beschränkt, sondern führt beliebige in Python ausdrückbare Arbeitslasten verifizierbar aus. Das Team experimentiert unter anderem mit der Erzeugung synthetischer Daten und mit der Kombination von TEEs für allgemeine Datenverarbeitung und solchen, die auf Aufgaben wie LLM-Inferenz spezialisiert sind. Als Fernziel nennt der Beitrag vollständige Korrektheitsbeweise für die Softwareimplementierungen der DP-Algorithmen und Systemkomponenten. Konkret heißt das für die Praxis: Der Datenschutz bei föderiertem Lernen wird nicht dadurch besser, dass man es föderiert nennt, sondern dadurch, dass Geräte eine überprüfbare Positivliste erlaubter Berechnungen durchsetzen, dass Auditoren diese Listen einsehen können und dass der Code reproduzierbar aus offenen Quellen gebaut wird. Solange Seitenkanäle und proprietär nachgeladene Logik Restrisiken bleiben, ist das ein Fortschritt mit klaren Kanten – und so sollte man ihn auch lesen.
Quelle: research.google
