Gerätegebundene vs. synchronisierte Passkeys (SCA & Passkeys I)

Übersicht: Starke Kundenauthentifizierung mit Passkeys#

• Analyse von PSD2- und SCA-Anforderungen
• Was SCA-Anforderungen für Passkeys bedeuten
• Auswirkungen von PSD3 / PSR auf Passkeys

1. Einleitung: Gerätegebundene vs. synchronisierte Passkeys#

In unserem vorherigen Blogbeitrag zu Passkeys und PSD2 haben wir besprochen, wie Passkeys bereits von Fintechs wie Revolut und Finom genutzt werden und wie sie die digitale Sicherheit im Banking verbessern.

Passkeys gibt es in zwei Hauptformen: synchronisierte Passkeys und gerätegebundene Passkeys. Während synchronisierte Passkeys es Benutzern ermöglichen, sich nahtlos über mehrere Geräte hinweg zu authentifizieren, sind gerätegebundene Passkeys strikt an ein Passkey-Gerät wie einen Hardware-Sicherheitsschlüssel oder einen lokalen Authentifikator gebunden.

Mit dieser vierteiligen Blogserie möchten wir im Detail analysieren, wie die verschiedenen Arten von Passkeys (gerätegebunden vs. synchronisiert) die Anforderungen von SCA und PSD2 erfüllen.

In diesem ersten Teil der Serie geht es darum, den Unterschied zwischen gerätegebundenen und synchronisierten Passkeys zu verstehen.

Der zweite Teil erklärt auf verständliche Weise, was PSD2 und starke Kundenauthentifizierung (Strong Customer Authentication, SCA) bedeuten, und beleuchtet auch deren historische Entwicklung.

Der dritte Teil der Serie zeigt, wie die verschiedenen Passkey-Arten SCA erfüllen und was das für Banken, Fintechs und Finanzinstitute bedeutet, die über die Einführung von Passkeys nachdenken.

Der vierte und letzte Teil der Serie fasst zusammen, was PSD3 / PSR in Zukunft für SCA und Passkeys bedeuten werden.

2. Starke Kundenauthentifizierung, PSD2 und Passkeys#

Nach der Veröffentlichung unseres letzten Blogbeitrags erhielten wir viele Rückfragen zu unserer Haltung bezüglich Passkeys, insbesondere in Bezug auf SCA unter dem PSD2-Rahmenwerk. Es besteht ein klares Interesse daran, nicht nur die Anwendung von Passkeys zu verstehen, sondern auch, wie sie mit den Regulatory Technical Standards (RTS) übereinstimmen. Darüber hinaus sind die Stakeholder neugierig auf mögliche Interpretationen und Richtlinien von Aufsichtsbehörden, einschließlich der Europäischen Bankaufsichtsbehörde (EBA), zur Verwendung von Passkeys.

Aus diesem Grund möchten wir genauer untersuchen, wie Passkeys in die PSD2-Richtlinie und die RTS zu SCA integriert werden können, und Klarheit über unsere Position zur Nutzung dieser Technologie schaffen. Wir werden auch bestehende Fragen und Antworten der EBA untersuchen, um zu beleuchten, wie Regulierungsbehörden und die EBA Passkeys wahrnehmen könnten. Diese Untersuchung wird nicht nur die Unterschiede zwischen synchronisierten und gerätegebundenen Passkeys behandeln, sondern auch ihre praktischen Anwendungen zur Verbesserung von Sicherheit und Benutzererfahrung.

Indem sie die Nuancen verstehen, können Stakeholder fundierte Entscheidungen treffen, die nicht nur die strengen Anforderungen von PSD2 erfüllen, sondern auch die neueste Authentifizierungstechnologie nutzen, um digitale Transaktionen abzusichern. Unsere Diskussion soll den Weg für die Integration von Passkeys in Authentifizierungsprozesse weiter erhellen und sicherstellen, dass Sicherheitsmaßnahmen mit der sich entwickelnden digitalen Landschaft Schritt halten.

Natürlich muss jedes regulierte Unternehmen, das unter PSD2 fällt, eigene Entscheidungen darüber treffen, wie die regulatorischen Ziele erreicht werden können, da jede Implementierung ihre eigenen Komplexitäten aufweist. Dieser individuelle Ansatz trägt der Tatsache Rechnung, dass der regulatorische Rahmen zwar einen einheitlichen Standard bietet, die praktische Anwendung dieser Standards jedoch in verschiedenen Organisationen aufgrund ihrer einzigartigen betrieblichen Umgebungen, technologischen Fähigkeiten und Benutzerbasen stark variieren wird.

Auch wenn unsere Erkenntnisse Orientierung und Informationen bieten sollen, sind sie nicht präskriptiv. Jedes Unternehmen muss seine spezifischen Umstände und Herausforderungen bei der Integration von Passkeys in seine Sicherheits- und Authentifizierungsprotokolle berücksichtigen.

3. Von gerätegebundenen Passkeys zu synchronisierten Passkeys#

Um die Unterscheidung zwischen gerätegebundenen und synchronisierten Passkeys zu verstehen, werden wir kurz untersuchen, wie sich das Ökosystem entwickelt hat.

3.1 Was sind gerätegebundene Passkeys (Single-Device-Passkeys)?#

Wir beginnen mit der Geschichte und Entwicklung von gerätegebundenen Passkeys, bevor wir einen genaueren Blick auf ihre technischen Details werfen.

3.1.1 Geschichte von gerätegebundenen Passkeys#

Historisch gesehen waren Authentifizierungsmechanismen innerhalb von WebAuthn (dem Standard, der Passkeys zugrunde liegt) eng an physische Geräte gekoppelt: Sicherheitsschlüssel (z. B. YubiKeys). Vor der weit verbreiteten Einführung von Passkeys stellten an einen einzigen Authentifikator gebundene FIDO2-Anmeldeinformationen den Goldstandard dar in der Sicherheit. Diese Anmeldeinformationen sind mit dem Gerät verknüpft, auf dem sie sich befinden. Die Auswirkungen dieser Bindung waren erheblich: Die Anmeldeinformationen konnten nicht übertragen oder über die ursprüngliche Hardware hinaus verwendet werden.

Dieser Ansatz erhöhte zwar die Sicherheit, indem er den Authentifizierungsprozess auf ein einziges Gerät lokalisierte, stieß jedoch unweigerlich auf praktische Einschränkungen, die seine breite Akzeptanz insbesondere bei allgemeinen, nicht technisch versierten Verbrauchern beeinträchtigten. Die Benutzer waren gezwungen, ihr authentifizierendes Gerät für jeden Anmeldeversuch zur Hand zu haben, was nicht nur die Mobilität der Benutzer einschränkte, sondern auch Bedenken in Szenarien aufkommen ließ, in denen das Gerät verloren ging, beschädigt oder nicht sofort zugänglich war.

Darüber hinaus zögerten Verbraucher auch, in zusätzliche Hardware zu investieren. Historisch gesehen war der Besitz und die Nutzung spezieller Sicherheitsschlüssel bei allgemeinen Verbrauchern sehr gering. Die Aussicht, für Authentifizierungszwecke spezielle Hardware zu kaufen, fand bei der Mehrheit der B2C-Nutzer trotz der verbesserten Sicherheitsvorteile keinen Anklang – und das, obwohl genau diese Nutzer normalerweise das Ziel von breit angelegten Phishing-Kampagnen oder Credential-Stuffing-Angriffen sind.

3.1.2 Technische Details von gerätegebundenen Passkeys#

Gerätegebundene Passkeys zeichnen sich durch ihre spezifische Kategorisierung in auffindbare (discoverable) und nicht auffindbare (non-discoverable) Anmeldeinformationen aus, eine Unterscheidung, die hauptsächlich ihre Auffindbarkeit definiert. Der entscheidende Faktor, der gerätegebundene Schlüssel auszeichnet, ist jedoch in den Eigenschaften der WebAuthn-Anmeldeinformationen gekapselt, insbesondere durch die Flags isBackupEligible und isBackupSynchronized. Für gerätegebundene Passkeys sind beide Felder auf Null gesetzt, was anzeigt, dass die Anmeldeinformationen nicht für Backups oder Synchronisierung über Geräte hinweg berechtigt sind. Diese Eigenschaften unterstreichen ihre intrinsische Verbindung zu dem physischen Gerät, auf dem sie erstellt wurden, und stellen sicher, dass die Anmeldeinformationen an diese spezifische Hardware gebunden bleiben und nur dort verwendbar sind.

Ein bemerkenswertes Beispiel für gerätegebundene Anmeldeinformationen in der Praxis findet sich im Windows-Ökosystem. Windows Hello-Anmeldeinformationen unter Windows 10 und Windows 11 bleiben gerätegebunden – Windows Hello selbst synchronisiert Passkeys noch nicht über Geräte hinweg. Microsoft hat jedoch einen bedeutenden ersten Schritt getan, indem es das Speichern und Synchronisieren von Passkeys in Microsoft Edge eingeführt hat (ab Edge 142). Diese Synchronisierung auf Browserebene über den Microsoft Password Manager ermöglicht die Synchronisierung von Passkeys über Windows-Geräte hinweg bei Verwendung von Edge, ähnlich wie der Google Password Manager die Passkey-Synchronisierung im Chrome-Browser unter Windows ermöglicht. Dies stellt einen wichtigen Fortschritt bei den Windows-Passkey-Funktionen dar, obwohl es spezifisch für den Edge-Browser und nicht für den Windows Hello-Plattform-Authentifikator ist. Windows Hello-Passkeys bleiben gerätegebunden, aber diese Edge-Integration bietet einen praktischen Weg in Richtung synchronisierter Passkeys unter Windows, während sich der Plattform-Authentifikator selbst in Zukunft möglicherweise weiterentwickeln wird, um Synchronisierung zu unterstützen.

Andererseits hat Google eine klare Haltung in Bezug auf nicht auffindbare Passkeys formuliert und darauf hingewiesen, dass bestehende nicht auffindbare Passkeys in zukünftigen Implementierungen weiterhin nicht synchronisiert werden können. Diese Entscheidung steht im Einklang mit dem breiteren Prinzip, dass nicht auffindbare Anmeldeinformationen in bestimmten Sicherheitskontexten eine entscheidende Rolle spielen, indem sie strikt gerätegebunden bleiben, nicht auffindbar sind und daher nicht als Passkeys verwendet werden können.

Im Gegensatz dazu unterscheidet sich der Ansatz, den Apple mit macOS und iOS verfolgt, erheblich. Anders als die festgelegte, gerätegebundene Strategie, die bei Windows und Googles nicht auffindbaren Schlüsseln zu beobachten ist, neigt das Apple-Ökosystem viel stärker dazu, nur synchronisierte Passkeys zuzulassen, insbesondere auf iOS, wodurch es unmöglich wird, einen gerätegebundenen Passkey via WebAuthn zu erstellen.

Diese Aufteilung der Strategien auf den großen Plattformen veranschaulicht die unterschiedlichen Ansätze zur Verwaltung von WebAuthn-Anmeldeinformationen, insbesondere wenn es darum geht, ein Gleichgewicht zwischen Sicherheit, Komfort und Benutzerzugänglichkeit zu finden. Während gerätegebundene Passkeys ein hohes Maß an Sicherheit bieten, indem sie sicherstellen, dass Anmeldeinformationen nicht außerhalb ihres vorgesehenen Geräts verschoben oder missbraucht werden können, entwickelt sich die Branche weiter und sucht nach Lösungen, die Sicherheitsstandards aufrechterhalten, ohne Kompromisse bei der Benutzererfahrung und Mobilität einzugehen.

3.2 Was sind synchronisierte Passkeys (Multi-Device-Passkeys)?#

Auch hier werfen wir einen Blick auf die historische Entwicklung synchronisierter Passkeys, bevor wir die technischen Details analysieren. Manchmal werden synchronisierte Passkeys auch als synchronisierbare Passkeys bezeichnet.

3.2.1 Geschichte synchronisierter Passkeys#

Nach der Veröffentlichung der Spezifikationen WebAuthn Level 2 und CTAP 2.1 etwa Mitte bis Ende 2021 startete die WebAuthn-Arbeitsgruppe eine bedeutende Brancheninitiative. Diese zielte darauf ab, die Haupthindernisse zu überwinden, die der Fähigkeit des WebAuthn-Standards im Wege standen, Passwörter zu ersetzen und die Akzeptanz zu erhöhen. Die Initiative konzentrierte sich auf zwei kritische Bereiche: die Beseitigung der Notwendigkeit zusätzlicher Hardware-Sicherheitsgeräte und die Minderung des Risikos, das mit dem Verlust des Authentifikators verbunden ist, unter Beibehaltung der vollen Abwärtskompatibilität mit den bestehenden Standards.

3.2.1.1 Nutzung von Plattform-Authentifikatoren als sichere Hardware-Module#

Die erste Herausforderung – die Beseitigung des Bedarfs an neuer Hardware – wurde durch die Nutzung integrierter Plattform-Authentifikatoren in modernen Verbrauchergeräten (z. B. Touch ID, Face ID, Windows Hello) angegangen.

Moderne Geräte sind zunehmend mit speziellen Sicherheitsmodulen ausgestattet, wie z. B. der Trusted Execution Environment (TEE) unter Android, Secure Enclave unter iOS und macOS und dem Trusted Platform Module (TPM) auf Windows-Geräten. Diese integralen Sicherheits-Keystores dienen als robustes Fundament für Passkeys und fungieren effektiv als integrierte „Sicherheitsschlüssel“. Dieser Ansatz ermöglicht die weite Verbreitung asymmetrischer Kryptographie, ein Sicherheitsniveau, das zuvor nur über externe Hardware-Sicherheitsschlüssel (z. B. YubiKeys) erreichbar war und weitgehend auf technikaffine Personen oder Organisationen in stark regulierten Branchen beschränkt blieb.

Durch die Nutzung der Fähigkeiten von TEE, Secure Enclave oder TPM werden die WebAuthn-Protokolle in die Lage versetzt, starke, kryptografische Mechanismen zur Benutzerauthentifizierung bereitzustellen. Nun werden ausgefeilte Authentifizierungsmethoden benutzerfreundlich und der breiten Öffentlichkeit zugänglich gemacht, ohne dass zusätzliche, spezielle Hardware erforderlich ist.

Diese Entwicklung ist eine sehr starke Verbesserung des Ansatzes für digitale Sicherheit und unterstreicht die entscheidende Rolle, die nutzerzentrierte Sicherheitslösungen bei der Förderung einer breiten Akzeptanz spielen. Organisationen, die synchronisierte Passkeys mit optimierten Passkey-Erstellungs- und Passkey-Login-Abläufen kombinieren, verzeichnen die höchsten Akzeptanzraten. Durch die Nutzung der Sicherheitsfunktionen moderner Geräte konnte die Brancheninitiative die anfängliche Hürde, die Notwendigkeit externer Hardware zu beseitigen, erfolgreich meistern.

Diese Entwicklung war ein entscheidender Schritt in eine neue Ära des digitalen Authentifizierungs-Ökosystems, in der die breite Anwendung asymmetrischer Kryptographie auf eine Vielzahl von Anwendungsfällen direkt anwendbar wird und gleichzeitig die Authentifizierung für Benutzer vereinfacht.

3.2.1.2 Synchronisierung von Passkeys mit der Cloud#

Um das Risiko des Verlusts des Mobiltelefons und damit auch der darauf gespeicherten Passkeys zu adressieren, konzentrierte sich die Brancheninitiative darauf, die Synchronisierung von auffindbaren Anmeldeinformationen mit der Cloud zu ermöglichen. Dieser Ansatz wandelte die Anmeldeinformationen effektiv von rein gerätegebundenen in mandantenfähige und genauer gesagt in solche um, die an das Konto des Benutzers bei seinem Cloud-Anbieter gebunden sind, wie z. B. iCloud bei Apple-Geräten oder Google bei Android-Geräten.

Diese praktische Lösung bedeutete, dass selbst wenn das Telefon eines Benutzers verloren ging oder ersetzt wurde, die zuvor erstellten Anmeldeinformationen nicht dauerhaft verloren waren. Stattdessen konnten diese Anmeldeinformationen aus dem Cloud-Konto des Benutzers abgerufen und mit einem neuen Gerät synchronisiert werden. Diese Verschiebung verringerte die Unannehmlichkeiten und Sicherheitsrisiken, die zuvor mit dem Verlust eines physischen Authentifikators verbunden waren, erheblich.

Durch die Nutzung der Cloud-Synchronisierung konnten Passkeys nun nahtlos zwischen den Geräten eines Benutzers wechseln, wobei ihre Integrität und Sicherheit unabhängig vom verwendeten Gerät erhalten blieben. Wenn sich ein Benutzer beispielsweise von einem neuen Gerät aus bei einer Website anmeldet, könnten die in seinem Cloud-Konto verfügbaren Anmeldeinformationen automatisch zur Authentifizierung vorgeschlagen werden. Bei Bedarf könnten diese Anmeldeinformationen auf das neue Gerät übertragen werden, wodurch ein konsistentes und sicheres Authentifizierungserlebnis über verschiedene Plattformen und Geräte hinweg aufrechterhalten wird.

Dieser Übergang zu cloud-synchronisierten, kontogebundenen Anmeldeinformationen stellt einen pragmatischen Ansatz für digitale Sicherheit dar. Er erkennt die Realitäten der modernen Gerätenutzung und das häufige Auftreten von Gerätewechseln an, sei es durch Verlust, Beschädigung oder Upgrades. Durch die Bindung der Anmeldeinformationen an das Cloud-Konto des Benutzers – sei es mit Apples iCloud oder den Cloud-Diensten von Google – mindert die Lösung nicht nur das Risiko im Zusammenhang mit dem Verlust eines Geräts, sondern verbessert auch die Fähigkeit des Benutzers, seine digitale Identität über mehrere Geräte hinweg zu verwalten und wiederherzustellen.

Diese Entwicklung erweitert die Anwendbarkeit der starken, kryptografischen Authentifizierungsmechanismen von WebAuthn effektiv und macht sie anpassungsfähiger an reale Benutzerszenarien. Sie stellt auch sicher, dass starke Authentifizierung zugänglich und handhabbar ist, nicht nur für Personen mit technischem Hintergrund oder solche in stark regulierten Branchen, sondern für den durchschnittlichen Benutzer, der mit mehreren Geräten durch die digitale Welt navigiert.

3.2.2 Technische Details von synchronisierten Passkeys#

Synchronisierte Passkeys sind auch als auffindbare Anmeldeinformationen (discoverable credentials) oder residente Schlüssel (resident keys) bekannt. Diese unterscheiden sich von gerätegebundenen Schlüsseln durch zwei entscheidende Eigenschaften: isBackupEligible und isBackedUp haben unterschiedliche Werte. Bei synchronisierten Passkeys ist das Flag isBackupEligible auf 1 gesetzt, was anzeigt, dass diese Anmeldeinformationen für ein Backup berechtigt sind. Nach erfolgreicher Synchronisierung mit der Cloud wird auch das Flag isBackedUp auf 1 gesetzt, was bestätigt, dass die Anmeldeinformation ordnungsgemäß synchronisiert wurde. Es ist wichtig anzumerken, dass sich der Status der Synchronisierung im Laufe der Zeit ändern kann, was die dynamische Natur der Gerätenutzung und -verwaltung widerspiegelt.

Wenn Plattformen residente Schlüssel anfordern, indem sie den Parameter "requireResidentKey" auf required oder preferred setzen, erstellen Plattformen, die Cloud-Dienste unterstützen, automatisch synchronisierte Passkeys. Dieser Prozess stellt sicher, dass sich Benutzer darauf verlassen können, dass ihre Anmeldeinformationen über ihre verschiedenen Geräte hinweg zugänglich sind. Unter Windows sind synchronisierte Passkeys jetzt über Microsoft Edge/Microsoft Password Manager (Synchronisierung auf Browserebene) verfügbar, während die Anmeldeinformationen des Windows Hello-Plattform-Authentifikators gerätegebunden bleiben. Passwort-Manager von Drittanbietern (z. B. Dashlane, KeePassXC, 1Password) mit Passkey-Verwaltungsfunktionen bieten ebenfalls eine plattformübergreifende Synchronisierung an. In Szenarien, in denen synchronisierte Passkeys verwendet werden, sind die Flags isBackupEligible und isBackedUp auf 1 gesetzt, was auf Backup-Berechtigung und erfolgreiche Synchronisierung hinweist.

Während es derzeit noch möglich ist, den spezifischen Authentifikator zu identifizieren, auf dem der Passkey gespeichert wurde, bedeutet das Fehlen einer Attestierung für die Mehrheit dieser Anmeldeinformationen außerdem, dass ihre Herkunft nicht kryptografisch verifiziert werden kann. Dieser Aspekt verdeutlicht eine potenzielle Einschränkung bei der Gewährleistung der Sicherheitsherkunft synchronisierter Passkeys allein durch die Standardmechanismen von WebAuthn.

Diese Entwicklung bei synchronisierten Passkeys erweitert im Wesentlichen den Anwendungsbereich auffindbarer Anmeldeinformationen, indem sie in ein Cloud-basiertes Synchronisierungs-Framework integriert werden. Indem diese Schlüssel backup-berechtigt gemacht und ihre Synchronisierung über die Geräte eines Benutzers hinweg sichergestellt werden, adressiert WebAuthn zwei der Hauptherausforderungen in der digitalen Authentifizierung: das Risiko des Zugriffsverlusts durch verlorene Geräte und die Unannehmlichkeiten der Verwaltung mehrerer gerätegebundener Anmeldeinformationen.

3.3 Single-Device-Bindung von WebAuthn-Anmeldeinformationen dem Gemeinwohl geopfert#

Der Übergang von gerätegebundenen zu synchronisierten Passkeys stieß innerhalb der WebAuthn-Arbeitsgruppe einen kritischen Dialog an, der sich auf die Notwendigkeit fortschrittlicher Sicherheitsmaßnahmen, die damit verbundenen rechtlichen Fragen und einen Kompromiss konzentrierte, der sowohl verbraucherfreundlich als auch sicher war.

Die Einführung synchronisierter Passkeys wurde für ihr Versprechen gefeiert, den Benutzerkomfort und die Sicherheit durch Funktionen wie Cloud-Synchronisierung und nahtlose Multi-Device-Funktionalität zu verbessern. Allerdings führte sie bei einigen Relying Parties (RPs) zu Unbehagen, insbesondere hinsichtlich der Auswirkungen auf Sicherheit und Compliance in Umgebungen mit erhöhten Anforderungen. Kern der Debatte war die Forderung nach einem Mechanismus, der sicherstellte, dass auch synchronisierte Passkeys eine Verbindung zu bestimmten Geräten beibehielten – ein Konzept, das für Relying Parties, die sensible Transaktionen durchführen oder unter strengen regulatorischen Standards arbeiten, von entscheidender Bedeutung ist.

Für RPs, die Passkeys nicht einführen konnten oder wollten, stellte das Fehlen einer zuverlässigen Methode zur Bindung dieser Anmeldeinformationen an bestimmte Geräte in kritischen Anwendungen eine erhebliche Herausforderung dar. Ein solcher Mechanismus wurde von einigen RPs als sehr wichtig erachtet. Das Fehlen dieser Gerätebindungsfähigkeit – eine Erwartung, die vielleicht nicht explizit formuliert, aber sicherlich vorhanden war – stellte aus ihrer Sicht eine böse Überraschung und einen Vertrauensbruch dar.

Die Diskussion kam zu dem Schluss, dass es eine Harmonisierung der Interessen geben sollte, aber zunächst das Gemeinwohl der Verbreitung von Passkeys Vorrang haben sollte. In der Diskussion wurde die devicePubKey-Erweiterung als eine Möglichkeit angesehen, diesen Bedenken zu begegnen, wurde aber später durch supplementalPubKeys ersetzt, die einen viel breiteren Ansatz in den aktuellen Entwurf von WebAuthn Level 3 einbringen. Leider wurde auch dieser Ansatz im August 2024 eingestellt.

3.4 Das Beste aus zwei Welten: Passkeys und supplementalPubKeys-Erweiterung [veraltet ab August 2024]#

Lassen Sie uns analysieren, wie der Kompromiss mit der Erweiterung supplementalPubKeys zustande kam und was dies technisch bedeutet.

3.4.1 Von devicePubKey zur supplementalPubKeys-Erweiterung#

Die Diskussion um den Übergang von der devicePubKey-Erweiterung zur supplementalPubKeys-Erweiterung unterstreicht die dynamische Natur der WebAuthn-Spezifikation. Zunächst diente devicePubKey der Erhöhung der Sicherheit durch gerätegebundene öffentliche Schlüssel, wurde aber später durch den Vorschlag von supplementalPubKeys im WebAuthn Level 3 Editor's Working Draft ersetzt. Diese neuere Erweiterung bietet eine umfassendere Lösung, indem sie die Verwendung mehrerer Schlüssel zur Verbesserung von Authentifizierungsprozessen ermöglicht.

Der Kern der Debatte konzentrierte sich darauf, ein Gleichgewicht zwischen erweiterten Sicherheitsmaßnahmen und der breiteren Akzeptanz und praktischen Anwendbarkeit von Passkeys auf verschiedenen Geräten und Plattformen zu finden. Die Erweiterung supplementalPubKeys stellt eine Kombination dieser Prioritäten dar und ermöglicht eine strengere Authentifizierung. Beispielsweise wird sie Vorschriften gerecht, die bestimmte Authentifizierungsstandards vorschreiben, indem sie zusätzliche „Subschlüssel“ mit Attestierungsnachweisen zulässt. Diese Schlüssel können die Einhaltung von Authentifizierungsanforderungen signalisieren, wodurch möglicherweise die Notwendigkeit zusätzlicher Anmelde-Herausforderungen unter bestimmten Bedingungen verringert wird (selbst mit Passkeys).

Ein Beispiel direkt aus dem WebAuthn-Entwurf:

„Nehmen wir an, dass eine Anmeldeanforderung bei einer Website zusammen mit einem Geolokalisierungssignal eingeht, das für dieses Benutzerkonto noch nie zuvor gesehen wurde und außerhalb der typischen Nutzungszeiten liegt, die für das Konto beobachtet wurden. Das Risiko könnte als hoch genug erachtet werden, um die Anforderung nicht zuzulassen, selbst bei einer Bestätigung durch eine mandantenfähige Anmeldeinformation allein. Wenn jedoch auch eine Signatur von einem ergänzenden Schlüssel vorgelegt werden kann, der gerätegebunden ist und für diesen Benutzer gut etabliert ist, dann könnte das den Ausschlag geben.“

Während der Diskussion wurde hervorgehoben, dass diese nur für RPs mit extrem hohen Sicherheitsanforderungen (z. B. im öffentlichen Sektor) gedacht waren.

Durch die Einbeziehung von Feedback und die Adressierung spezifischer Anwendungsfälle – wozu auch regulierte Finanztransaktionen und die Notwendigkeit gerätegebundener Signale in einer Multi-Device-Credential-Umgebung gehören – zielte die WebAuthn-Community darauf ab, sowohl Sicherheits- als auch Interoperabilitätsbedenken zu adressieren. Die supplementalPubKeys-Erweiterung ist somit ein Ansatz, der darauf abzielt, robuste Sicherheitsfunktionen bereitzustellen und gleichzeitig die nahtlose Benutzererfahrung und breite Kompatibilität zu unterstützen, die für die weite Verbreitung von Passkeys unerlässlich sind. Es ist eine völlig optionale Erweiterung, die nicht in die Passkey-Implementierung eingreift, wie sie bereits in den letzten 2 Jahren beobachtet wurde.

Diese Entwicklung hin zu einem integrativeren und flexibleren Rahmenwerk unterstreicht das Engagement der WebAuthn-Community, Web-Authentifizierungsmethoden selbst für strengere Anwendungsfälle zu verbessern.

3.4.2 Technische Details zu supplementalPubKeys#

Die in WebAuthn eingeführte Erweiterung supplementalPubKeys ermöglicht die Verwendung zusätzlicher Schlüsselpaare neben den primären Anmeldeinformationen.

Entnommen aus dem ursprünglichen GitHub-Issue

Das Bild zeigt das Konzept von supplementalPubKey, entnommen aus dem ursprünglichen GitHub-Issue (pk = Passkey, pspk = Provider Supplemental Key, dspk = Device Supplemental Key).

Hier ist eine Aufschlüsselung der Funktionsweise und des Verwendungszwecks:

Zweck und Funktionalität von supplementalPubKey

• Ein zentraler Passkey-Berechtigungsnachweis bleibt erhalten: Es ist wichtig zu bedenken, dass nur ein zentraler Passkey die primäre Methode der Benutzerauthentifizierung bleibt und die zusätzlichen Schlüssel zusätzliche Sicherheits- und Gewissheitsebenen bieten. Diese Struktur bewahrt die Einfachheit und Effizienz der Verwendung eines einzigen, zentralen Passkeys für die Authentifizierung über mehrere Geräte hinweg und gewährleistet eine nahtlose Benutzererfahrung. Die ergänzenden Schlüssel dienen derweil dazu, den Authentifizierungskontext zu verbessern, indem sie der Relying Party (RP) zusätzliche Signale über die Sicherheitsumgebung oder die Einhaltung bestimmter Authentifizierungsstandards bieten. Diese ergänzenden Schlüssel sind keine eigenständigen Authentifizierungsmethoden, sondern ergänzen den primären Passkey und stärken seine Vertrauenswürdigkeit durch Nachweise der Geräteintegrität.
• Gerätegebundene Schlüssel: Diese sind speziell an ein Gerät gebunden. Sie können Zusicherungen geben, dass eine Authentifizierungsanforderung von einem vertrauenswürdigen Gerät stammt, das zuvor authentifiziert wurde. Sie werden unter keinen Umständen synchronisiert.
• Provider-gebundene Schlüssel: Diese Schlüssel haben einen „Provider“-Bereich, was bedeutet, dass sie zusätzliche Zusicherungen basierend auf den Richtlinien des Authentifizierungsanbieters oder der spezifischen Attestierung des Anbieters bieten können. Ein Anbieter könnte beispielsweise einen solchen Schlüssel erst ausstellen, nachdem ein Benutzer eine höhere Authentifizierungsstufe (wie 2FA) abgeschlossen hat.
• Mehrere öffentliche Schlüssel: Im Gegensatz zu ihrer Vorgängerin, der devicePubKey-Erweiterung, die nur einen gerätegebundenen öffentlichen Schlüssel zuließ, ermöglicht supplementalPubKeys die Einbeziehung von ein oder zwei ergänzenden Schlüsseltypen. Diese Schlüssel können unterschiedlichen Zwecken und Bereichen dienen – nämlich gerätegebundenen und provider-gebundenen Bereichen.

Anwendungsfälle und Beispiele für supplementalPubKey

1. Erhöhte Sicherheit: In Situationen, in denen eine Website (Relying Party) bestimmte erweiterte Sicherheitsstandards für die Authentifizierung einhalten muss, können ergänzende Schlüssel verwendet werden, um diese Anforderungen zu erfüllen. Wenn dieser ergänzende Schlüssel von der Site zuvor gesehen und verifiziert wurde, könnte er es dem Benutzer ermöglichen, zusätzliche Anmelde-Herausforderungen zu umgehen, da die Gerätekontinuität durch frühere Signale bestätigt werden kann.
2. Risikomanagement: Bei Anmeldeanforderungen, die riskant erscheinen (z. B. aus einer neuen Geolokalisierung oder zu ungewöhnlichen Zeiten stammen), könnte das Vorhandensein eines gerätegebundenen ergänzenden Schlüssels, der in der Vergangenheit mit dem Konto des Benutzers verwendet wurde, das wahrgenommene Risiko verringern und die Durchführung der Anforderung ermöglichen, die andernfalls blockiert worden wäre.

Technische Aspekte von supplementalPubKey

• Keine eigene Credential ID: Ergänzende Schlüssel sind keine Benutzeranmeldeinformationen und haben keine eigenen Credential IDs.
• Attestierungsnachweise: Ergänzende Schlüssel können optional eine Attestierung aufweisen. Diese sind entscheidend für das Verständnis des Umfangs und der Sicherheitsstufe von ergänzenden Schlüsseln. Eine Attestierung kann das Schutzniveau angeben, das ein hardwaregebundener Schlüssel genießt, oder die Richtlinien für andere Arten von ergänzenden Schlüsseln.
• Implementierung für Relying Parties: Relying Parties können diese ergänzenden Schlüssel als Teil des Authentifizierungsprozesses anfordern. Die Komplexität des Umgangs mit mehreren Schlüsseln und Attestierungsnachweisen bedeutet jedoch, dass diese Erweiterung am besten für Unternehmen mit spezifischen Sicherheitsanforderungen geeignet ist, wie z. B. Banken oder Dienste, die unter strengen regulatorischen Auflagen arbeiten.

Es ist wichtig anzumerken, dass die supplementalPubKeys-Erweiterung (Stand April 2024) noch von keinem der großen Browser übernommen wurde und die WebAuthn Level 3-Spezifikation sich noch in der Entwicklung befindet und Änderungen unterliegt. Ob diese Funktion in der endgültigen Version der Spezifikation enthalten sein wird und ihre mögliche zukünftige Implementierung und Akzeptanz, bleibt ungewiss, da sie sich derzeit nur im Editor's Draft befindet.

3.4.3 Einstellung von supplementalPubKeys im August 2024#

Seit August 2024 wurde die Erweiterung supplementalPubKeys offiziell eingestellt. Die WebAuthn-Arbeitsgruppe hat beschlossen, diese Funktion aufgrund mangelnder Unterstützung zu entfernen. Die Einstellung dieser Erweiterung verdeutlicht auch eine neue Richtung. Derzeit arbeitet die FIDO Alliance an der Entwicklung eines anderen Ansatzes zur Unterstützung von Relying Parties mit hohen Sicherheitsanforderungen. Diese kommende Lösung wird voraussichtlich die Lücken schließen, die durch die Einstellung von supplementalPubKeys entstanden sind, und neue Methoden zur Stärkung von Authentifizierungsprozessen in Szenarien bieten, in denen strenge Sicherheitsstandards entscheidend sind.

Weitere Details zur Einstellung finden Sie im offiziellen WebAuthn GitHub Pull Request.

4. Wie Corbado in der Praxis mit den Unterschieden zwischen gerätegebundenen und synchronisierten Passkeys umgeht#

Es ist essenziell, die Unterschiede zwischen gerätegebundenen und synchronisierten Passkeys zu verstehen, aber Banken benötigen auch Tools, um diese Unterschiede im großen Maßstab zu operationalisieren. Die Plattform von Corbado bietet Device-Trust-Intelligenz, die Passkey-Typen automatisch klassifiziert und auf jeden die richtige SCA-Behandlung anwendet.

Sichtbarkeit des Device Trust über verschiedene Passkey-Typen hinweg#

Das Device-Trust-Dashboard von Corbado zeigt, wie sich gerätegebundene und synchronisierte Passkeys in der Produktion unterschiedlich verhalten. Gerätegebundene Passkeys erreichen höhere Erfolgsquoten (99,1 %) bei null Step-up-Anforderungen, während synchronisierte Passkeys mit Device-Trust-Signalen 98,4 % erreichen, mit einer geringen Step-up-Quote für neue Geräte.

Das Dashboard verfolgt auch die Geräteklassifizierung – es identifiziert, welche Geräte exklusiv einem einzelnen Benutzer gehören (92 % bei typischen Banking-Implementierungen), welche zwischen zwei Benutzern geteilt werden (7 %) und welche gemeinsam genutzte/Kiosk-Geräte sind (0,8 %). Diese Klassifizierung fließt direkt in SCA-Compliance-Entscheidungen ein.

Richtlinienbasierte Kontrolle für verschiedene Passkey-Szenarien#

Anstatt alle Passkeys gleich zu behandeln, ermöglichen die Trust-Richtlinien von Corbado Banken, basierend auf Passkey-Typ, Gerätestatus und Vertrauensstufe unterschiedliche Regeln anzuwenden. Gerätegebundene Passkeys auf bekannten Geräten erhalten eine reibungslose Authentifizierung, während synchronisierte Passkeys auf neuen Geräten eine Step-up-Verifizierung auslösen – genau der nuancierte Ansatz, den das SCA-Rahmenwerk der PSD2 verlangt.

Dies bedeutet, dass Banken synchronisierte Passkeys für eine bessere Benutzererfahrung zuverlässig einsetzen und gleichzeitig die strenge Gerätekontrolle aufrechterhalten können, die gerätegebundene Passkeys für Hochsicherheitsszenarien bieten – alles verwaltet über Richtlinienkonfiguration anstelle separater Authentifizierungsabläufe.

Über Corbado

Corbado ist die Passkey Intelligence Platform für CIAM-Teams, die Consumer-Authentifizierung im großen Maßstab betreiben. Wir zeigen Ihnen, was IDP-Logs und generische Analytics-Tools nicht sehen können: welche Geräte, OS-Versionen, Browser und Credential-Manager Passkeys unterstützen, warum Enrollments nicht zu Logins werden, wo der WebAuthn-Flow scheitert und wann ein OS- oder Browser-Update den Login still und leise unterbricht – und das alles, ohne Okta, Auth0, Ping, Cognito oder Ihren In-House-IDP zu ersetzen. Zwei Produkte: Corbado Observe ergänzt Observability für Passkeys und jede andere Login-Methode. Corbado Connect bringt Managed Passkeys mit integrierter Analytics (neben Ihrem IDP). VicRoads betreibt Passkeys für über 5 Mio. Nutzer mit Corbado (+80 % Passkey-Aktivierung). Mit einem Passkey-Experten sprechen →

Häufig gestellte Fragen#

Wie erhöhen gerätegebundene Passkeys die Sicherheit?#

Gerätegebundene Passkeys sind WebAuthn-Anmeldeinformationen, die strikt an das Gerät gebunden sind, auf dem sie erstellt wurden. Im Gegensatz zu synchronisierten Passkeys verbleiben sie auf einem einzigen Gerät, was sie für bestimmte Anwendungsfälle von Natur aus sicherer macht:

• Kein Diebstahl von Anmeldeinformationen: Der private Schlüssel verlässt das Gerät nie, sodass Angreifer keine Anmeldeinformationen abfangen können.
• Verhinderung von unberechtigtem Zugriff: Die Authentifizierung erfolgt nur über das spezifische Gerät, auf dem der Passkey erstellt wurde.
• Keine Cloud-Abhängigkeit: Eliminiert Risiken im Zusammenhang mit Cloud-Datenlecks oder Kontoübernahmen.
• Hohe Sicherheitskonformität: Erfüllt strenge Anforderungen an gerätegebundene Authentifizierung für regulierte Branchen wie Finanzdienstleistungen (AAL3).

Der Hauptnachteil ist die eingeschränkte Portabilität. Wenn das Gerät verloren geht, kann der Passkey nicht wiederhergestellt werden, es sei denn, der Benutzer registriert einen neuen auf einem anderen Gerät.

Warum wurden synchronisierte Passkeys eingeführt und was sind ihre Vorteile?#

Synchronisierte Passkeys (Multi-Device-Passkeys) wurden eingeführt, um die Usability-Herausforderungen gerätegebundener Passkeys zu lösen, insbesondere die mangelnde Portabilität und mögliche Kontosperrung bei Verlust eines Geräts. Zu den Hauptvorteilen gehören:

• Multi-Device-Authentifizierung: Greifen Sie von mehreren Geräten aus auf Konten zu, ohne für jedes manuell einen neuen Passkey registrieren zu müssen.
• Kein Risiko des Zugriffsverlusts: Anmeldeinformationen werden in der Cloud gesichert (z. B. iCloud Keychain, Google Password Manager), um die Wiederherstellung bei Geräteverlust sicherzustellen.
• Verbesserte UX: Eliminiert Reibungsverluste, da Anmeldeinformationen nicht mehr manuell übertragen oder neu erstellt werden müssen.
• Keine zusätzliche Hardware erforderlich: Im Gegensatz zu Hardware-Sicherheitsschlüsseln verwenden synchronisierte Passkeys integrierte Geräte-Sicherheitsmodule.
• Starke Sicherheit mit Cloud-Komfort: Ende-zu-Ende-Verschlüsselung stellt sicher, dass der private Schlüssel das Gerät niemals in unverschlüsseltem Format verlässt.

5. Fazit#

Im ersten Teil unserer vierteiligen Serie haben wir analysiert, worin die historischen und technischen Unterschiede zwischen gerätegebundenen und synchronisierten Passkeys bestehen. Das Verständnis dieser Unterschiede wird uns helfen, die Anforderungen von PSD2 und SCA entsprechend anzuwenden. Außerdem haben wir einen Blick in die Zukunft geworfen, indem wir uns die jüngsten Änderungen im sich noch in der Entwicklung befindlichen Webauthn Level 3 Standard angesehen haben.

Hier sind die Links zu den anderen Teilen unserer Serie:

• Teil 2 „Analyse der Anforderungen von PSD2 & SCA (SCA & Passkeys II)“
• Teil 3 „Was SCA-Anforderungen für Passkeys bedeuten (SCA & Passkeys III)“
• Teil 4 „Auswirkungen von PSD3 / PSR auf Passkeys (SCA & Passkeys IV)“