Google vereinfacht unter Android den Wechsel zwischen verschiedenen Passwortmanagern drastisch. Bisher war der Export und Import von Passkeys und klassischen Passwörtern oft ein digitaler Spießrutenlauf – insbesondere, weil Passkeys (kryptographische Schlüsselpaare) per Design nicht einfach als Klartext-Datei auf einen USB-Stick gezogen werden können.
Mit dem neuen Update des Android Credential Managers wird ein standardisierter, sicherer Transfer direkt zwischen zwei Geräten oder Apps möglich. Doch wie funktioniert dieses Protokoll im Hintergrund? Findet der Austausch lokal statt oder läuft alles über Google-Server? Und wie sieht es mit QR-Codes oder Bluetooth aus? Wir werfen einen Blick auf die technische Architektur.
Die Kernfrage: Client-to-Client oder zentraler Server?
Aus Sicherheits- und Datenschutzgründen basiert der neue Transfer-Mechanismus auf einer hybriden Client-to-Client-Architektur.
Braucht es einen zentralen Server?
- Nein, nicht für den Datenstrom: Der eigentliche Austausch der sensiblen Credentials erfolgt Ende-zu-Ende-verschlüsselt (E2EE) direkt zwischen dem sendenden und dem empfangenden Gerät. Ein zentraler Server (etwa von Google) kann die transportierten Passkeys oder Passwörter zu keinem Zeitpunkt im Klartext lesen.
- Die Rolle des Relay-Servers: Für den Verbindungsaufbau (das sogenannte „Handshake“) wird ein temporärer Cloud-Dienst als Vermittler (Relay) genutzt. Dieser dient lediglich dazu, die beiden Geräte im Netzwerk einander vorzustellen, falls sie sich nicht direkt im selben Subnetz befinden. Da der Schlüssel für die Verschlüsselung lokal zwischen den Geräten ausgehandelt wird, fungiert der Server nur als blinde Pipeline. Eine freie Serverwahl durch den Nutzer ist im Android-Standard-Protokoll nicht vorgesehen, da der Signal-Weg fest in den Google Play Services bzw. der Android-API verankert ist.
Die Transportwege: WLAN, Bluetooth oder QR-Code?
Um maximale Flexibilität bei gleichzeitig hoher Sicherheit zu gewährleisten, kombiniert das Protokoll verschiedene Übertragungsmedien.
1. Müssen die Geräte im gleichen (W)LAN sein?
Es ist der bevorzugte und schnellste Weg. Wenn sich Sender und Empfänger im selben lokalen Netzwerk befinden, wird nach dem initialen Handshake eine direkte, lokale TCP/UDP-Verbindung aufgebaut. Das sorgt für maximale Bandbreite, besonders wenn hunderte Passwörter auf einmal migriert werden.
2. Funktioniert der Transfer via Bluetooth?
Ja, Bluetooth spielt eine essenzielle Rolle – allerdings primär für den Proximity-Check (Näherungsnachweis). Um sogenannte „Relay-Angriffe“ zu verhindern (bei denen ein Angreifer aus der Ferne versucht, die Session abzufangen), verlangt das Protokoll, dass sich die Geräte physikalisch nah beieinander befinden. Das wird über Bluetooth Low Energy (BLE) verifiziert. In Szenarien, in denen kein WLAN verfügbar ist, kann der eigentliche Datentransfer über verkoppelte Bluetooth-Kanäle abgewickelt werden, was aufgrund der geringeren Geschwindigkeit bei großen Passwort-Datenbanken jedoch etwas länger dauert.
3. Kann man sich die Credentials als QR-Code anzeigen lassen?
Nein, zumindest nicht die Credentials selbst. Ein QR-Code hat eine stark begrenzte Speicherkapazität (kryptographische Passkeys und eine komplette Passwort-Historie würden die Pixeldichte eines lesbaren QR-Codes sprengen).
Der QR-Code wird jedoch für das kryptographische Pairing genutzt:
- Das empfangende Gerät generiert einen temporären, öffentlichen Schlüssel und verpackt diesen zusammen mit einer Session-ID in einen QR-Code.
- Das sendende Gerät scannt diesen Code ab.
- Dadurch wissen beide Clients sofort, mit wem sie verschlüsselt kommunizieren müssen, und handeln den Ephemeral Key (temporären Sitzungsschlüssel) aus.
Der QR-Code transportiert also nicht deine Passwörter, sondern schließt die digitale Handschelle für den sicheren, verschlüsselten Tunnel.
Wie funktioniert die Krypto-Sicherung im Hintergrund?
Da Passkeys auf asymmetrischer Kryptographie (Public-Key-Kryptographie) basieren, wird beim Transfer nicht einfach der private Schlüssel ungeschützt kopiert. Das Protokoll nutzt in der Regel ein Verfahren, das an das Diffie-Hellman-Schlüsselaustausch-Protokoll angelehnt ist.
Sobald der QR-Code gescannt und die Bluetooth-Nähe bestätigt wurde, etablieren die Apps einen abhörsicheren Kanal (meist basierend auf dem Noise Protocol Framework). Die Passkeys werden innerhalb der sicheren Hardware-Umgebung (wie dem Titan M2-Sicherheitschip bei Pixel-Geräten oder der Knox-Sandbox bei Samsung) verpackt, verschlüsselt, übertragen und auf dem Zielgerät direkt wieder in den dortigen sicheren Keystore injiziert.
Fazit
Googles neuer Vorstoß nimmt der Passkey-Technologie einen ihrer größten Kritikpunkte: Die mangelnde Portabilität. Durch die clevere Kombination aus QR-Code-Pairing, Bluetooth-Näherungsprüfung und lokaler Ende-zu-Ende-Verschlüsselung wird der Wechsel zwischen Passwort-Managern unter Android nicht nur komfortabel, sondern bleibt auch architektonisch extrem sicher. Ein Abfangen der Daten durch Google oder böswillige Akteure im selben WLAN ist mathematisch ausgeschlossen.