Passkeys & WebAuthn PRF für Ende-zu-Ende-Verschlüsselung (2025)

WebAuthn & Passkeys haben die Web-Authentifizierung revolutioniert und bieten durch Public-Key-Kryptografie Phishing-resistente, passwortlose Logins. Aber ihre Fähigkeiten gehen über reine Anmeldungen hinaus. Ein spannendes Feature ist die WebAuthn Pseudo-Random Function (PRF)-Erweiterung. Diese Erweiterung ermöglicht es Webanwendungen, während der Authentifizierung geheime Schlüssel direkt aus dem Passkey oder dem Hardware-Sicherheitsschlüssel eines Nutzers abzuleiten. Dies erschließt die Möglichkeit, Daten Ende-zu-Ende zu verschlüsseln oder einen sicheren Vault nur mit dem Passkey zu entschlüsseln, ohne ein separates Passwort zu benötigen. In diesem Artikel wollen wir folgende Fragen beantworten:

• Passkey PRF Anwendungsfälle: Was sind interessante Anwendungsfälle für die WebAuthn PRF-Erweiterung?
• Unterstützung der PRF-Erweiterung: Wie sieht die tatsächliche aktuelle Unterstützung der WebAuthn PRF-Erweiterung in den verschiedenen Betriebssystemen und Browsern aus?

Dieser Artikel analysiert die WebAuthn PRF-Erweiterung und untersucht ihre technischen Spezifikationen, Anwendungsfälle, Implementierungsdetails, Sicherheitsaspekte und die aktuelle Landschaft der Browser- und Betriebssystemunterstützung. Wir konzentrieren uns auf die Veränderungen im Ökosystem 2025 und bauen auf der Vorarbeit von Matthew Miller und Levi Schuck aus dem Jahr 2023 auf, deren frühere Artikel detaillierte technische Hintergründe, Live-Beispiele und Online-Tests (einschließlich Verschlüsselung) liefern.

Die WebAuthn PRF-Erweiterung (PRF) ist formal in der WebAuthn Level 3 Spezifikation definiert. Ihr Hauptzweck ist es, einer Relying Party (Ihrer Webanwendung) zu ermöglichen, während einer Authentifizierungszeremonie (navigator.credentials.get()) die Auswertung einer pseudozufälligen Funktion anzufordern, die mit einem bestimmten WebAuthn-Credential (Passkey) verknüpft ist.

Eine PRF nimmt einen geheimen Schlüssel (der sicher im Authenticator gespeichert und an das Credential gebunden ist) und einen oder mehrere Eingabewerte (die von der Relying Party bereitgestellt werden), um eine deterministische, kryptografisch zufällig erscheinende Ausgabe zu erzeugen. Diese Ausgabe, typischerweise ein 32-Byte-String, kann dann von der clientseitigen Anwendung verwendet werden, vor allem als symmetrisches Schlüsselmaterial für die WebAuthn-Verschlüsselung oder Schlüsselableitung.

Viele Authenticatoren, insbesondere FIDO2-Sicherheitsschlüssel, implementieren eine zugrunde liegende Fähigkeit, die im Client-to-Authenticator-Protocol (CTAP2) definiert ist und als hmac-secret-Erweiterung bezeichnet wird. Diese CTAP2-Erweiterung bietet Zugriff auf eine hardwaregestützte HMAC-Funktion (Hash-based Message Authentication Code), die als pseudozufällige Funktion dient. Die WebAuthn PRF-Erweiterung fungiert als standardisierter Weg für Webanwendungen, um über die WebAuthn-API des Browsers auf diese hmac-secret-Fähigkeit zuzugreifen.

Um potenzielle Konflikte oder Sicherheitsprobleme zu vermeiden, bei denen eine Website den Authenticator dazu verleiten könnte, HMACs für nicht-webbezogene Zwecke (wie die lokale Betriebssystemanmeldung) zu generieren, schreibt die WebAuthn-Spezifikation einen wichtigen Schritt vor: Die von der Website bereitgestellten Eingaben (erstes und zweites Salt) werden zuerst mit einem spezifischen Kontextstring („WebAuthn PRF“ und einem Nullbyte) gehasht, bevor sie an die zugrunde liegende hmac-secret-Funktion übergeben werden. Dies teilt den Eingaberaum der PRF effektiv auf und stellt sicher, dass vom Web abgeleitete Ausgaben von denen unterschieden werden, die potenziell in anderen Kontexten verwendet werden.

Die Fähigkeit, an den Authenticator gebundene Schlüssel abzuleiten, eröffnet Entwicklern mehrere überzeugende Anwendungsfälle:

1. Client-seitige / Ende-zu-Ende-Verschlüsselung (E2EE): Dies ist die Hauptmotivation für die WebAuthn PRF-Erweiterung. Browserbasierte Anwendungen können während des Logins einen einzigartigen Verschlüsselungsschlüssel pro Credential ableiten. Dieser Schlüssel kann dann mit der WebCrypto API verwendet werden, um Nutzerdaten zu verschlüsseln, die lokal oder auf dem Server gespeichert sind. Die Daten bleiben im Ruhezustand verschlüsselt und können nur vom Nutzer nach erfolgreicher Authentifizierung mit dem spezifischen Passkey entschlüsselt werden, was den Datenschutz und die Datensicherheit erhöht. Dienstanbieter können Nutzerdaten speichern, ohne jemals Zugriff auf den Klartext zu haben. Dies ist besonders hilfreich für Anwendungen in der passwortlosen Welt, da sie ohne die PRF-Erweiterung zusätzlich ein Geheimnis in Form eines Passworts anfordern müssten, was der passwortlosen Architektur widerspricht.

2. Passwortlose Vault-Entschlüsselung: Dienste wie Passwort-Manager (z. B. Bitwarden, 1Password) oder sichere Notiz-Apps (z. B. Notesnook, Reflect) können PRF verwenden, um das traditionelle Master-Passwort zu ersetzen. Der Nutzer authentifiziert sich mit seinem Passkey, die PRF-Erweiterung leitet den Entschlüsselungsschlüssel für den Vault ab und der Vault wird entsperrt – kein Master-Passwort erforderlich. Bitwarden hat die Unterstützung hierfür angekündigt. Darüber hinaus hat Dashlane kürzlich die WebAuthn PRF-Erweiterung eingeführt, um die Phishing-Resistenz zu stärken und die Sicherheit beim Zugriff auf verschlüsselte Vaults zu erhöhen. Nutzer authentifizieren sich mit ihren Passkeys, wodurch PRF die Entschlüsselungsschlüssel für den Vault sicher ableiten kann und die Notwendigkeit eines Master-Passworts vollständig entfällt.

3. Sichere Schlüsselrotation: Die WebAuthn PRF-Erweiterung ermöglicht die Bereitstellung von zwei Eingabe-„Salts“ (erstes und zweites) während der Authentifizierung. Dies erleichtert kryptografische Schlüsselrotationsschemata. Ein Server könnte den „aktuellen“ Schlüssel mit dem ersten und den „nächsten“ Schlüssel mit dem zweiten anfordern. Im Laufe der Zeit kann der Server aktualisieren, welches Salt dem aktuellen Schlüssel entspricht, was eine nahtlose Rotation ohne Unterbrechung der Nutzererfahrung ermöglicht. Dies ist besonders wichtig, falls regulatorische Anforderungen oder interne Richtlinien eine Rotation aller Schlüssel innerhalb eines bestimmten Zeitplans vorschreiben und die Sicherheit erhöht.

4. Identity-Wallets & Non-Custodial-Systeme: PRF kann Schlüssel zur Sicherung von Identitätsdaten in digitalen Wallets ableiten oder Non-Custodial-Systeme ermöglichen, bei denen private Schlüssel niemals serverseitig offengelegt werden.

Obwohl die Spezifikation definiert ist, ist die tatsächliche Unterstützung durch Browser und Plattformen der entscheidende Faktor für Entwickler. Die Unterstützung hat sich weiterentwickelt und war bis vor kurzem hauptsächlich auf Chromium-basierte Browser beschränkt. Die Verfolgung der Unterstützung kann eine Herausforderung sein, da es keinen eigenen Eintrag auf CanIUse.com für die PRF-Erweiterung selbst gibt (die Suche nach „webauthn“ zeigt die allgemeine API-Unterstützung, aber nicht spezifische Erweiterungen). Informationen müssen oft aus Browser-Release-Notes, Bug-Trackern und Statusseiten gesammelt werden. Die erfolgreiche Nutzung der WebAuthn PRF-Erweiterung erfordert ein koordiniertes Zusammenspiel auf drei verschiedenen Ebenen des Technologiestapels. Die Unterstützung der PRF-Erweiterung muss auf jeder Ebene vorhanden sein, damit das Feature funktioniert:

1. Der Authenticator: Dies ist die Hardware (wie ein Sicherheitsschlüssel) oder die Plattformkomponente (wie Windows Hello, iCloud Keychain und das entsprechende Hardwaremodul, z. B. TPM oder Secure Enclave), die den geheimen Schlüssel des Credentials sicher speichert und die eigentliche Berechnung der pseudozufälligen Funktion durchführt (typischerweise unter Verwendung der CTAP2 hmac-secret-Fähigkeit). Wenn dem Authenticator diese grundlegende kryptografische Fähigkeit fehlt, kann PRF nicht funktionieren.

2. Das Betriebssystem (OS): Das Betriebssystem fungiert als Brücke zwischen dem Browser und dem Authenticator. Es stellt die notwendigen Treiber und systemweiten APIs bereit, damit der Browser Authenticatoren (insbesondere Plattform-Authenticatoren und solche, die über USB/NFC/Bluetooth verbunden sind) erkennen, mit ihnen kommunizieren und Operationen von ihnen anfordern kann. Das Betriebssystem muss in der Lage sein, die PRF (hmac-secret)-Fähigkeit des Authenticators zu erkennen und dem Browser zur Verfügung zu stellen. Wenn das Betriebssystem diesen Weg nicht bereitstellt, kann der Browser nicht auf das Feature zugreifen.

3. Der Browser: Als Schnittstelle für die Webanwendung muss der Browser die WebAuthn JavaScript API implementieren, insbesondere die prf-Erweiterung erkennen, die Web-Anfrage in die entsprechenden Befehle für das Betriebssystem/den Authenticator übersetzen, den entscheidenden Sicherheitsschritt des Hashens der Eingaben mit dem Kontextstring durchführen und die Ergebnisse korrekt parsen und an die Anwendung zurückgeben.

Ein Fehler oder mangelnde Unterstützung auf einer dieser drei Ebenen – Authenticator-Fähigkeit, OS-Bereitstellung oder Browser-Implementierung – verhindert, dass die PRF-Erweiterung funktioniert.

Dieses Sequenzdiagramm zeigt eine vereinfachte Version, wie diese Akteure zusammenarbeiten, um die PRF-Unterstützung zu ermöglichen.

Ein funktionierender PRF-Workflow erfordert, dass jede Schicht in der WebAuthn ↔ CTAP-Kette zusammenarbeitet. Zur Verdeutlichung trennen wir die Diskussion in (1) das Verhalten von Browsern und Betriebssystemen und (2) das Verhalten von Authenticatoren.

Der Weg zu einer breiten PRF-Unterstützung verdeutlicht eine häufige Herausforderung bei Web-Standard-Erweiterungen: Die Implementierung erfolgt oft gestaffelt, wobei plattformspezifische Probleme gelöst werden müssen. Wir werden versuchen, diese Tabelle auf dem neuesten Stand zu halten, aber bedenken Sie, dass laufende Anpassungen zu erwarten sind, da die PRF-Erweiterung eine der neuesten Ergänzungen ist, die eine Anpassung der gesamten Kompatibilitätskette erfordert.

Nachfolgend schlüsseln wir die Unterstützung nach Betriebssystem auf.

Die Unterstützung für die WebAuthn PRF-Erweiterung unter Windows ist begrenzt, da dem nativen Plattform-Authenticator (Windows Hello) derzeit die notwendige hmac-secret-Fähigkeit fehlt. Die PRF-Funktionalität ist daher von externen Sicherheitsschlüsseln abhängig.

Mit macOS 15 ist die PRF-Unterstützung für Plattform-Authenticatoren verfügbar. Sowohl Safari als auch Chrome unterstützen PRF über den iCloud Keychain. Die Firefox-Unterstützung für den Plattform-Authenticator steht noch aus. Sicherheitsschlüssel funktionieren nur mit Chrome.

Der Status auf iOS und iPadOS spiegelt den von macOS wider, wobei PRF über den iCloud Keychain funktioniert. Es gibt jedoch erhebliche Einschränkungen: Ein Bug in frühen Versionen von iOS 18 kann zu Datenverlust führen, und die Unterstützung für externe Sicherheitsschlüssel ist noch nicht implementiert.

Android bietet derzeit die robusteste und am weitesten verbreitete Unterstützung für die WebAuthn PRF-Erweiterung. Passkeys, die im Google Password Manager gespeichert sind, beinhalten standardmäßig PRF-Unterstützung, und es funktioniert in den meisten großen Browsern, mit Ausnahme von Firefox.

In der obigen Tabelle haben wir die wichtigsten Kombinationen für die Unterstützung von First-Party Passkey Providern aufgeführt. Bei der Verwendung von Passwort-Managern als Third-Party Passkey Provider müssen deren spezifische Fähigkeiten jedoch separat betrachtet werden. Zum Beispiel unterstützt 1Password PRF in seiner Android-Version, aber nicht in seiner iOS-Version. Auch das Chrome-Profil als Authenticator unterstützt PRF nicht. Weitere Details zu Authenticatoren finden Sie unten.

Während WebAuthn spezifiziert, was eine Relying Party anfordern kann, definiert das Client-to-Authenticator Protocol (CTAP), wie sich der Authenticator verhalten muss. In der Praxis lassen sich Authenticatoren in vier Kategorien einteilen:

1. Keine PRF-Unterstützung: Ältere Plattform-Authenticatoren (z. B. Windows Hello), ältere Sicherheitsschlüssel ohne die hmac-secret-Erweiterung und Drittanbieter, die die PRF-Erweiterung noch nicht eingeführt haben.

2. PRF nur, wenn das PRF-Flag bei der Erstellung des Credentials gesetzt wurde: Einige CTAP 2.0/2.1-Sicherheitsschlüssel bieten hmac-secret, verweigern aber PRF-Auswertungen, es sei denn, die Relying Party hat dies bei der erstmaligen Erstellung des Credentials zur Initialisierung der Geheimnisse angefordert.

3. PRF bei der Authentifizierung verfügbar, auch wenn es bei der Erstellung nicht angefordert wurde: Hardware-Token der neuen Generation sowie iCloud und Google Password Manager bieten die hmac-secret-Funktionalität bedingungslos an; Credentials, die ohne das Flag erstellt wurden, funktionieren dennoch mit PRF während navigator.credentials.get().

4. Vollständige CTAP 2.2-Konformität (PRF + erster PRF-Wert bei der Erstellung): Plattform-Authenticatoren, die Passkeys synchronisieren – wie iCloud Keychain und Google Password Manager – können auf Anfrage bereits während navigator.credentials.create() die erste PRF-Ausgabe zurückgeben, was die Schlüssel-Etablierungs-Flows optimiert.

Zu wissen, in welche Kategorie ein Authenticator fällt, ist entscheidend, wenn Sie Backup-, Migrations- oder Schlüssel-Etablierungslogiken entwerfen. Wir haben auch Tests für diese Szenarien in unsere Demo aufgenommen.

Sie können die WebAuthn PRF-Erweiterung direkt mit unserer interaktiven WebAuthn PRF Demo-Anwendung erleben. In dieser Demo können Sie:

• Einen Passkey mit PRF registrieren und bestätigen, ob Ihr Authenticator diese leistungsstarke Erweiterung unterstützt.
• Sich mit Ihrem Passkey authentifizieren und den von PRF generierten kryptografischen Wert in Aktion sehen.

Den PRF-Wert selbst zu sehen, verdeutlicht die praktischen Auswirkungen der Verwendung von Passkeys für sichere, schlüsselbasierte Operationen. Es ermöglicht Ihnen, die Kompatibilität Ihres Authenticators für die PRF-Erweiterung direkt zu überprüfen und zu beobachten, wie von PRF abgeleitete Schlüssel die WebAuthn Ende-zu-Ende-Verschlüsselung und die sichere Vault-Entschlüsselung ohne Passwörter ermöglichen.

Nehmen Sie sich einen Moment Zeit, um die Demo auszuprobieren. Das Verständnis der PRF-Fähigkeit Ihrer spezifischen Umgebung hilft Ihnen, sichere, passwortlose Erlebnisse besser zu planen, die auf Ihre Nutzer zugeschnitten sind.

Bereit, die Macht von PRF zu testen? Klicken Sie auf das Bild oben oder folgen Sie diesem Link, um Ihre praktische Erkundung zu starten.

Die WebAuthn PRF-Erweiterung ist nicht die einzige WebAuthn-Erweiterung, die sich auf das Speichern oder Ableiten von Daten bezieht. Wie schneidet Passkey PRF im Vergleich ab?

• PRF vs. credBlob / largeBlob:

  • credBlob: Ermöglicht das Speichern eines winzigen (32 Bytes) statischen Blobs mit dem Credential, möglicherweise zum Zeitpunkt der Erstellung. Es wurde nicht primär für Geheimnisse entwickelt, und die Unterstützung ist begrenzt, insbesondere für nicht auffindbare Credentials.

  • largeBlob: Ermöglicht das Speichern von mehr Daten (~1 KB) mit auffindbaren Credentials, oft für Zusatzdaten wie Zertifikate gedacht. Die Unterstützung ist ebenfalls begrenzt (unterstützt vom iCloud Keychain seit iOS 17, aber nicht von GPM). Chrome-Entwickler haben sich explizit dafür ausgesprochen, sich für die meisten Anwendungsfälle auf PRF anstelle von largeBlob zu konzentrieren, obwohl eine Entwicklung in Zukunft stattfinden könnte.

  • PRF: Im Gegensatz dazu ist PRF speziell dafür konzipiert, geheime Schlüssel bei Bedarf während der Authentifizierung unter Verwendung eines hardwaregebundenen Geheimnisses abzuleiten, anstatt einen statischen Blob zu speichern. Es wird allgemein als der am besten geeignete und sicherste Standardmechanismus zur Ableitung von Verschlüsselungsschlüsseln angesehen, die an einen Passkey gebunden sind. Die Entwicklung von der Diskussion über Blobs für Geheimnisse hin zur Standardisierung und dem Implementierungsfokus auf PRF deutet auf eine Konvergenz auf PRF als die dedizierte Lösung für diesen Anwendungsfall hin.

• PRF vs. von Passwörtern abgeleitete Schlüssel (z. B. PBKDF2): Traditionell wurden clientseitige Verschlüsselungsschlüssel aus Nutzerpasswörtern abgeleitet. PRF bietet erhebliche Vorteile:

  • Stärkere Quelle: Schlüssel werden aus starkem kryptografischem Material innerhalb des Authenticators abgeleitet, nicht aus potenziell schwachen oder wiederverwendeten Passwörtern.

  • Phishing-Resistenz: Die Ableitung ist an den Phishing-resistenten WebAuthn-Authentifizierungsfluss gebunden.

  • Passwortlos: Ermöglicht Anwendungsfälle wie die Vault-Entschlüsselung, ohne überhaupt ein Passwort zu benötigen.

• PRF vs. andere WebAuthn-Daten: Der Versuch, Schlüssel aus anderen Teilen der WebAuthn-Antwort (wie der Signatur, authenticatorData oder dem öffentlichen Schlüssel) abzuleiten, ist grundsätzlich unsicher und falsch. Diese Komponenten sind entweder öffentlich, nicht geheim oder für die Verifizierung und nicht für die Schlüsselableitung konzipiert.

Für die sichere Ableitung von kryptografischem Schlüsselmaterial, das direkt mit einem WebAuthn-Credential oder Passkey verknüpft ist, ist die WebAuthn PRF-Erweiterung der speziell dafür entwickelte und empfohlene Standardansatz.

Bei der Integration der PRF-Erweiterung in Ihre Anwendung sollten Sie diese praktischen Richtlinien berücksichtigen:

Die folgenden Empfehlungen helfen Entwicklern, den aktuellen Stand der Unterstützung der PRF-Erweiterung effektiv zu navigieren und für zukünftige Entwicklungen zu planen:

• PRF opportunistisch behandeln: Die Unterstützung für die WebAuthn PRF-Erweiterung variiert derzeit erheblich zwischen Browsern, Betriebssystemen und Authenticatoren. Behandeln Sie die PRF-Integration daher als eine Verbesserung und nicht als eine Kernabhängigkeit.

• Kritische Abhängigkeit von PRF vermeiden: Vermeiden Sie es, PRF für geschäftskritische Funktionalitäten unerlässlich zu machen. Die aktuelle Unterstützung, insbesondere auf Plattformen wie Safari unter macOS und iOS, bleibt inkonsistent und unvollständig.

• Auf Szenarien mit Passkey-Verlust vorbereiten: Denken Sie daran, dass mit PRF-abgeleiteten Schlüsseln verschlüsselte Daten ausschließlich an den spezifischen Passkey gebunden sind. Der Verlust des Passkeys macht die verschlüsselten Daten dauerhaft unzugänglich. Implementieren Sie immer robuste Backup- und Wiederherstellungsmechanismen.

• Breitere Unterstützung bis 2026 erwarten: Die Unterstützung der PRF-Erweiterung reift schnell. Bis 2026 ist eine konsistente Verfügbarkeit in den wichtigsten Browsern, Betriebssystemen und Authenticatoren zu erwarten, insbesondere bei First-Party-Passkey-Providern.

• Windows-Ökosystem beobachten: Die Unterstützung durch den Plattform-Authenticator über Windows Hello fehlt derzeit. Eine vollständige PRF-Integration in Windows-Umgebungen hängt stark von der Adoptionsstrategie von Microsoft ab, daher sollten Sie dieses Ökosystem genau beobachten.

Die Befolgung dieser Richtlinien stellt sicher, dass Entwickler PRF reibungslos integrieren können, während sie während der Einführungsphase Kompatibilität und Sicherheit gewährleisten.

Das Verständnis, wie PRF mit Ihrer gesamten Passkey-Strategie übereinstimmt, hilft Ihnen, die Vorteile zu maximieren, ohne unnötige Komplikationen:

• Flexible Integration: Es ist nicht notwendig, zum Zeitpunkt der Passkey-Erstellung zu entscheiden, ob PRF genutzt werden soll. Bestehende Passkeys können später nahtlos in PRF-Anwendungsfälle integriert werden, ohne zusätzlichen Aufwand bei der Credential-Verwaltung.

• PRF nachrüsten: Da PRF während der Authentifizierungsphase (navigator.credentials.get()) arbeitet, können zuvor erstellte Passkeys zu einem späteren Zeitpunkt PRF-basierte Workflows unterstützen. Dies ermöglicht es Ihrer Anwendung, die Sicherheit schrittweise zu erhöhen, ohne etablierte Authentifizierungsmethoden zu stören. Dieser Ansatz funktioniert mit dem iCloud Keychain und dem Google Password Manager (GPM) sowie mit neueren Sicherheitsschlüsseln. Bei älteren Sicherheitsschlüsseln wird ein hmac-secret möglicherweise nur generiert, wenn es bei der Erstellung des Credentials angefordert wird.

• Komplexität von Passkeys berücksichtigen: Die Komplexitäten, die mit der Passkey-Verwaltung verbunden sind – wie Credential-Synchronisierung, geräteübergreifende Authentifizierung und Wiederherstellungsprozesse – gelten gleichermaßen bei der Verwendung von PRF. Stellen Sie sicher, dass Ihre PRF-Implementierung kohäsiv mit Ihrer gesamten Passkey-Authentifizierungsstrategie übereinstimmt und optimierte Nutzererfahrungen sowie robuste Sicherheitskontrollen beibehält.

Die Betrachtung von PRF als Teil einer ganzheitlichen Passkey-Strategie ermöglicht einen reibungsloseren Übergang zu sichereren und nutzerfreundlicheren Authentifizierungspraktiken.

Für Dienstanbieter in Unternehmen, die sensible Nutzerdaten verarbeiten, eröffnet die Möglichkeit, WebAuthn PRF neben Passkeys zu nutzen, neue Wege zur Verbesserung von Sicherheit und Nutzererfahrung, insbesondere in Szenarien, die eine clientseitige Verschlüsselung von personenbezogenen Daten (PII) oder die Absicherung von Anwendungen mit Ende-zu-Ende-Verschlüsselung erfordern. Während Corbado Connect hauptsächlich für die nahtlose Integration von Passkeys in Unternehmen konzipiert ist, kann es auch die Implementierung von Passkey-Erweiterungen wie SPC oder PRF erleichtern.

So kann Corbado Organisationen bei der Integration von PRF unterstützen:

• Erleichterung von PRF für verschlüsselten Speicher: In Unternehmensumgebungen besteht manchmal die Anforderung, sensible Informationen sicher zu speichern, manchmal sogar direkt auf der Client-Seite, um die serverseitige Exposition von PII zu minimieren. Corbado Connect kann so konfiguriert werden, dass es während des Passkey-Authentifizierungsflusses (navigator.credentials.get()) PRF-Werte anfordert, wodurch Anwendungen die notwendigen kryptografischen Schlüssel ableiten können.
• Flexible Speichermuster: Die mit PRF-abgeleiteten Schlüsseln verschlüsselten Daten können je nach Sicherheitsanforderungen und Architektur auf verschiedene Weisen gespeichert werden:
  • Client-seitig: Direkt im Browser gespeichert mit Mechanismen wie localStorage oder sicheren Cookies. Die Klartextdaten existieren nur vorübergehend auf dem Client während der Entschlüsselung.
  • Corbado Backend (E2EE): Obwohl Corbado im Allgemeinen die Speicherung von Kunden-PII vermeidet, ermöglicht der PRF-Mechanismus technisch die Speicherung von clientseitig verschlüsselten Daten auf den Servern von Corbado. Corbado hätte nicht die Schlüssel, um diese Daten zu entschlüsseln; die Entschlüsselung würde weiterhin clientseitig nach erfolgreicher Nutzerauthentifizierung erfolgen.
  • Backend des Kunden: Die verschlüsselten Daten könnten auch an die eigenen Backend-Systeme des Unternehmens gesendet und dort gespeichert werden, wobei sie immer noch von der clientseitigen Verschlüsselung profitieren.
• Sicherer Schlüsselableitungs-Flow: Die Komponenten von Corbado Connect verwalten die Interaktion mit der WebAuthn API. Wenn PRF angefordert wird:
  1. Eine nutzerspezifische PRF-Ausgabe wird vom Authenticator generiert, die an den individuellen Passkey gebunden ist.
  2. Diese Ausgabe wird sicher an die clientseitige Anwendung zurückgegeben.
  3. Die Anwendung sollte dann eine Key Derivation Function (KDF) über die WebCrypto API (z. B. HKDF) verwenden, um einen robusten symmetrischen Verschlüsselungsschlüssel aus der PRF-Ausgabe abzuleiten.
  4. Dieser symmetrische Schlüssel wird mit WebCrypto (z. B. AES-GCM) verwendet, um die Zielinformationen (wie PII) zu ver- oder entschlüsseln.
• Nahtlose Entschlüsselung bei nachfolgenden Logins: Wenn sich der Nutzer erneut mit demselben Passkey authentifiziert, initiiert Corbado Connect dieselbe PRF-Anfrage. Dies liefert die identische PRF-Ausgabe, sodass die Anwendung denselben symmetrischen Schlüssel erneut ableiten und die zuvor gespeicherten Informationen clientseitig entschlüsseln kann.
• Informationen zur PRF-Verfügbarkeit: Die Implementierung von PRF erfordert das Wissen, ob die Umgebung des Nutzers (Betriebssystem, Browser, Authenticator) dies unterstützt. Corbado Connect sammelt während der Authentifizierung Signale über das Gerät und die Fähigkeiten des Nutzers. Diese Informationen können verwendet werden, um:
  • Die PRF-Bereitschaft in der Nutzerbasis zu bestimmen, bevor PRF-abhängige Funktionen vollständig aktiviert werden.
  • PRF opportunistisch zu implementieren, es als Verbesserung für unterstützte Nutzer bereitzustellen und gleichzeitig Fallback-Mechanismen (wie die Aufforderung zur erneuten Verifizierung oder die Verwendung alternativer Methoden) für Nutzer ohne Unterstützung beizubehalten.
• Optimierung der PII-Verfügbarkeit: Durch die Verwendung von PRF zur Verschlüsselung verifizierter PII (z. B. Identitätsattribute, die durch einen Verifizierungsfluss erhalten wurden) und deren Speicherung auf der Client-Seite können Anwendungen diese Daten nach einem Passkey-Login für nachfolgende Interaktionen oder Transaktionen sofort verfügbar machen, was die Reibung im Vergleich zu erneuten Verifizierungs- oder App-basierten Flüssen erheblich reduziert.
• Ermöglichung benutzerdefinierter E2EE-Systeme: Während Corbado Connect UI-Komponenten für Standardflüsse bietet, können die zugrunde liegenden Prinzipien Entwicklern ermöglichen, die PRF-Funktionalität tiefer in sensible Anwendungen zu integrieren. Dies ermöglicht den Aufbau von Ende-zu-Ende-verschlüsselten Systemen, bei denen die Frontend-Anwendung die von PRF abgeleiteten Schlüssel direkt für komplexe kryptografische Operationen auf bestehenden oder neuen Daten nutzt. Vorerst wird dies nur opportunistisch möglich sein, und Fallback-Mechanismen müssen eine andere Möglichkeit zur Speicherung dieser Informationen implementieren.

Corbado zielt darauf ab, die Komplexität der Passkey- und PRF-Integration zu vereinfachen, damit Unternehmen Standards sicher und effektiv nutzen können, sich an spezifische Anwendungsfälle wie die clientseitige PII-Verschlüsselung anpassen und sich in der sich entwickelnden Landschaft zurechtfinden können.

Die WebAuthn PRF-Erweiterung markiert einen wichtigen Schritt nach vorn, um wirklich passwortlose, Ende-zu-Ende-verschlüsselte Anwendungen zur praktischen Realität zu machen. Indem sie Passkeys zur sicheren Ableitung kryptografischer Schlüssel nutzt, bietet sie eine nahtlose und sichere Nutzererfahrung, ohne die Privatsphäre zu beeinträchtigen.

Um die zu Beginn dieses Artikels gestellten Fragen direkt zu beantworten:

• Interessante PRF-Anwendungsfälle: PRF ermöglicht überzeugende Anwendungsfälle wie die Ende-zu-Ende-verschlüsselte Datenspeicherung, die passwortlose Vault-Entschlüsselung für Passwort-Manager, sichere kryptografische Schlüsselrotationsschemata und sichere Identity-Wallets oder Non-Custodial-Systeme, die die Privatsphäre der Nutzer schützen, indem sie sicherstellen, dass private Schlüssel die Client-Geräte niemals verlassen.

• Aktueller Stand der PRF-Unterstützung (Juni 2025): Die Unterstützung ist nach wie vor fragmentiert und entwickelt sich weiter. Während Android eine robuste Unterstützung über Browser und Authenticatoren hinweg bietet, ist die Unterstützung auf Plattformen wie macOS und insbesondere iOS wackelig, vor allem als CDA-Quelle mit einem schwerwiegenden Bug. Die Windows-Unterstützung beschränkt sich hauptsächlich auf externe Sicherheitsschlüssel, wobei die native Plattformunterstützung über Windows Hello auffällig fehlt.

Entwickler, die die PRF-Erweiterung in Betracht ziehen, sollten mit einer schnellen Verbesserung rechnen, aber dennoch vorsichtig vorgehen und robuste Anwendungen erstellen, die die aktuellen Einschränkungen elegant handhaben. Da eine breitere Akzeptanz in den wichtigsten Plattformen und Authenticator-Ökosystemen aufkommt, scheint die Zukunft für PRF-gestützte passwortlose Verschlüsselung vielversprechend und verspricht verbesserte Privatsphäre und Benutzerfreundlichkeit bei der Web-Authentifizierung.