Passkeys in der Praxis – Teil 1: Die Architektur von Passkeys

close notice

Passwörter sind nicht deshalb unsicher, weil Menschen nachlässig damit umgehen – sie sind strukturell gebrochen. Das zugrunde liegende Modell beruht auf einem geteilten Geheimnis zwischen Client und Server, das abgefangen, erraten oder durch Datenlecks kompromittiert werden kann. Passkeys setzen an genau dieser Schwachstelle an und lösen das Problem auf architektonischer Ebene: Anstelle eines Passworts kommt ein kryptografisches Schlüsselpaar zum Einsatz. Der private Schlüssel verlässt niemals das Gerät – auf dem Server liegt ausschließlich der öffentliche Schlüssel.

Die Authentifizierung erfolgt lokal, durch Biometrie oder PIN, und ist kryptografisch an exakt eine Relying Party ID gebunden: Ein Credential, das für example.com registriert wurde, kann auf evil-example.com schlicht nicht verwendet werden – egal, ob es auf einem einzelnen Gerät liegt oder via iCloud auf mehreren. Phishing wird damit nicht nur erschwert, sondern technisch unmöglich gemacht.

Der erste Teil dieser Artikelserie steigt direkt auf Architekturebene ein und legt das technische Fundament: Wie greifen FIDO2, WebAuthn und CTAP2 ineinander? Welche Akteure sind an jeder WebAuthn-Interaktion beteiligt, und welche Aufgabe hat jeder von ihnen? Was liefern navigator.credentials.create() und navigator.credentials.get() zurück – und welche Informationen verbergen sich in der authData-Struktur, die beide Methoden durchzieht? Wer diese Fragen beantworten kann, verfügt über das Vokabular und Strukturverständnis, auf dem Registration und Authentication in Teil 2 aufbauen.

FIDO2, WebAuthn und CTAP2 – Begriffsklärung

Zunächst lohnt sich eine kurze Begriffsklärung – nicht, weil die Begriffe kompliziert wären, sondern weil sie in der Praxis häufig durcheinandergeworfen werden, was zu Verwirrung bei der Implementierung führt.

FIDO2 ist der Oberbegriff. Er kombiniert zwei Spezifikationen, die auf unterschiedlichen Ebenen ansetzen: Web Authentication (WebAuthn) und Client to Authenticator Protocol 2 (CTAP2). WebAuthn ist die Browser-API, die vom World Wide Web Consortium (W3C) standardisiert wird und die Kommunikation zwischen Webanwendung und Browser beschreibt. CTAP2 ist eine Spezifikation der FIDO Alliance und regelt, wie der Browser beziehungsweise das Betriebssystem mit dem Authenticator kommuniziert. Beide Spezifikationen sind voneinander unabhängig standardisiert, aber konzeptuell aufeinander abgestimmt: WebAuthn definiert, was der Browser nach oben zur Webanwendung durchreicht; CTAP2 definiert, was der Browser nach unten zum Authenticator sendet.

Der Begriff Passkey ist jünger als die beiden Spezifikationen und dient als benutzerfreundliche Bezeichnung für Synced Credentials im Sinne der FIDO Alliance – also Multi-Device FIDO Credentials, die verschlüsselt über ein Cloud-Ökosystem wie iCloud Keychain oder den Google Password Manager auf mehrere Geräte repliziert werden können. Davon abzugrenzen sind Device-bound Passkeys: gerätegebundene Credentials, bei denen der private Schlüssel das Gerät nie verlässt, etwa auf einem Roaming Authenticator wie einem YubiKey. Technisch basieren beide Varianten identisch auf WebAuthn – der Unterschied liegt im Sicherheitsmodell des Authenticators, nicht in der API.

Die drei Akteure: Relying Party, WebAuthn Client und Authenticator

Jede WebAuthn-Interaktion – ob Registration oder Authentication – involviert genau drei Akteure. Ihr Zusammenspiel bestimmt, welche Daten ausgetauscht werden, wer welche Validierungen durchführt und wo das Vertrauen im System verankert ist. Es lohnt sich, diese drei Rollen klar auseinanderzuhalten, denn Verwechslungen führen direkt zu falschen Annahmen in der Serverlogik.

Die Relying Party (RP) ist die Webanwendung, genauer gesagt, der Server dahinter. Sie initiiert beide Ceremonies – Registration und Authentication –, indem sie Options-Objekte mit einer kryptografisch zufälligen Challenge bereitstellt, und validiert anschließend die Antwort des Authenticators. Identifiziert wird sie durch ihre rpId – typischerweise die Domain der Anwendung, etwa example.com. Wichtig dabei: Die rpId muss eine registrierbare Domain-Teilmenge der aktuellen Origin sein. Das bedeutet, dass example.com als rpId für login.example.com gültig ist, aber auth.other.com es nicht für example.com sein darf. Diese Einschränkung klingt technisch, ist aber der eigentliche Kern der Phishing-Resistenz – dazu gleich mehr. Was die RP am Ende einer erfolgreichen Registration speichert, ist ausschließlich der Public Key. Kein Passwort, kein geteiltes Geheimnis.

Zwischen Relying Party und Authenticator sitzt der WebAuthn-Client – in der Regel der Browser, manchmal das Betriebssystem. Er implementiert die navigator.credentials-API und übernimmt die Rolle des Vermittlers: Er empfängt die Options-Objekte der RP, leitet sie an den Authenticator weiter und verpackt dessen Antwort als PublicKeyCredential-Objekt zurück an die Webanwendung. Was dabei oft übersehen wird: Der Client führt eigene Sicherheitsprüfungen durch, bevor er den Authenticator überhaupt kontaktiert. Er validiert, ob die rpId zur aktuellen Origin passt – und bricht die Anfrage mit einem SecurityError ab, wenn das nicht der Fall ist. Das ist keine optionale Validierung, sondern eine Pflichtprüfung des Browsers.

Der Authenticator schließlich ist das Gerät oder die Software, die das Schlüsselpaar erzeugt und Assertions signiert. Konzeptuell ist er eine vollständig separate Vertrauensdomäne – weder Teil der Webanwendung noch des Browsers. Was der Authenticator signiert, haben weder Browser noch RP manipuliert. Genau das macht ihn zur Vertrauensquelle des gesamten Systems.

Das Vertrauensmodell folgt daraus fast zwingend: Der Server vertraut dem registrierten Public Key. Der Browser vertraut dem Authenticator über das CTAP2-Protokoll oder die Plattform-API. Und der Authenticator vertraut der lokalen Nutzerverifizierung – der Biometrie oder der PIN, die den privaten Schlüssel freischaltet. Kein Akteur muss dem anderen blind vertrauen, weil jeder Schritt kryptografisch abgesichert ist.

Platform Authenticator vs. Roaming Authenticator

Es folgt ein genauerer Blick auf den Authenticator – denn nicht jeder Authenticator ist gleich. Die WebAuthn-Spezifikation unterscheidet grundlegend zwischen zwei Varianten, die sich in Sicherheitsmodell, Recovery-Optionen und praktischem Einsatzszenario erheblich unterscheiden. Ein Platform Authenticator ist fest in das Gerät integriert: Touch ID und Face ID auf Apple-Geräten, Windows Hello auf PC und Laptop, Android Biometrics auf Android-Smartphones.

Der private Schlüssel wird direkt im sicheren Element des Geräts erzeugt und gespeichert – in der Secure Enclave auf Apple-Hardware oder dem Trusted Platform Module (TPM) auf Windows-Systemen. Er verlässt diese Sicherheitsdomäne nicht. Bei Synced Passkeys gibt es eine wichtige Nuance: Das Schlüsselmaterial wird verschlüsselt über die iCloud Keychain oder den Google Password Manager auf andere Geräte desselben Ökosystems repliziert. Der Schlüssel selbst bleibt dabei immer geschützt. Was synchronisiert wird, ist ein verschlüsselter Blob, kein Klartext-Schlüssel.

Ein Roaming Authenticator hingegen ist ein externes Gerät, das unabhängig vom Endgerät funktioniert. Die häufigsten Beispiele sind YubiKeys, FIDO2-USB-Sicherheitsschlüssel und NFC-Token. Sie sind per Definition Device-bound – das heißt, sie bleiben fest mit dem Gerät verbunden, auf dem sie erstellt wurden. Ein Cloud-Sync oder Transfer der Schlüssel zwischen Geräten ist nicht möglich. Besonders interessant ist dabei die Rolle des Smartphones als Cross-Device Authenticator: Es kann mittels QR-Code-Scan und einer verschlüsselten Bluetooth-Verbindung (Hybrid Transport) als Roaming Authenticator für andere Geräte dienen – beispielsweise für einen Desktop-Browser, der selbst über keinen Platform Authenticator verfügt.

Eine verbreitete Fehlannahme ist, dass Synced Passkeys weniger phishingresistent seien als Hardware-Schlüssel. Das stimmt nicht. Phishing-Resistenz ist kein Merkmal eines bestimmten Authenticator-Typs, sondern sie ergibt sich direkt aus dem kryptografischen Origin-Binding der WebAuthn-Spezifikation. Zur Erinnerung: Ein Credential, das für example.com registriert wurde, kann schlicht nicht auf evil-example.com verwendet werden, egal ob es auf einem YubiKey oder in der iCloud liegt. Der Authenticator signiert immer die rpId, die der Browser mitliefert, und der Browser prüft zuvor, ob diese rpId zur aktuellen Origin passt. Der Unterschied liegt woanders: bei der Angriffsfläche des Schlüsselmaterials und bei den Recovery-Optionen. Ausführliche Informationen dazu folgen zu einem späteren Zeitpunkt in dieser Artikelserie.

In den AuthenticatorSelectionCriteria kann die RP über authenticatorAttachment festlegen, welchen Typ sie bevorzugt:

{
“authenticatorSelection”: {
“authenticatorAttachment”: “platform”,
“residentKey”: “required”,
“userVerification”: “required”
}
}

Listing 1: authenticatorSelection-Objekt mit Präferenz für Platform Authenticators

“platform” schränkt auf eingebettete Authenticators ein, “cross-platform” auf externe Geräte. “residentKey”: “required” erzeugt ein Discoverable Credential – Voraussetzung für eine Anmeldung ohne Benutzernamen.