FIDO2-Authentifizierung

Überblick

FIDO2 ist eine Kombination aus der W3C Web Authentication (WebAuthn) -Spezifikation und den Client-to-Authenticator Protocols (CTAP2) der FIDO Alliance.

WebAuthn definiert eine Standard-Web-API, die in Browser (WebAuthn Client) und Plattformen integriert ist, um die Unterstützung der FIDO-Authentifizierung zu ermöglichen. CTAP2 ermöglicht die Verwendung externer Authentifikatoren (FIDO Security Keys, Mobilgeräte) zur Authentifizierung in FIDO2-fähigen Browsern und Betriebssystemen über USB, NFC oder BLE. CTAP1 (der neue Name für FIDO U2F) ermöglicht die Verwendung vorhandener FIDO-U2F-Geräte zur Authentifizierung in FIDO2-fähigen Browsern und Betriebssystemen über USB, NFC oder BLE für ein Erlebnis der zweiten Stufe.

FIDO2-Authentifikatoren können entweder in ein Benutzergerät oder in ein separates externes Gerät integriert sein. Wenn ein Authentifikator in das Verbrauchergerät eingebaut ist, wird er als interner (Plattform) Authenticator bezeichnet. Wenn der Authenticator ein externes Gerät ist, wird er als externer (Roaming-) Authenticator bezeichnet.

Platform Authenticators nutzt sichere kryptografische Hardware wie Trusted Platform Module (TPM), Secure Enclave/Element (SE) oder Trusted Execution Environment (TEE) auf Plattformen (wie Computern und Smartphones), um die für die Authentifizierung verwendeten kryptografischen Schlüssel zu verwalten. Roaming-Authenticatoren sind unabhängig von den Plattformen. Sie sind in der Regel ein eigenständiges Gerät wie USB-Sicherheitsschlüssel, das kryptografische Operationen gemäß den FIDO2-Spezifikationen ausführen kann.

Plattformauthentifikatoren kommunizieren mit der Relaying Party über die WebAuthn-Javascript-API, die in Browsern auf verschiedenen Plattformen (Windows, macOS und Smartphones) integriert ist. FIDO2-fähige Browser/Plattformen benötigen jedoch einen zusätzlichen Transportkanal, um mit Roaming Authenticators über USB, NFC und BLE kommunizieren zu können. Daher CTAP2.

Einzigartige Eigenschaften der FIDO2-Authentifizierung

Alle FIDO-Authentifizierungen basieren auf einem kryptografischen Challenge-Response-Protokoll mit öffentlichem Schlüssel zwischen einem Relaying-Party-Server (RP) und einem Authentifikator. Der RP sendet über die WebAuthn-API (implementiert im Browser/Betriebssystem eines Geräts) eine Anfrage an den Authenticator. Der Authenticator gibt eine signierte Antwort an den RP zurück. Der RP überprüft die signierte Antwort, um dem Benutzer den Zugriff zu ermöglichen.

Bei der FIDO2-Authentifizierung handelt es sich um phishing-resistente Authentifikatoren.

So funktioniert FIDO2

Registrierung

1. Die RP-Anwendung (Dienst) fordert den Benutzer auf, sich über den Webauthn-Client (Browser) auf dem Gerät des Benutzers zu registrieren
2. Der Benutzer bestätigt seine Absicht, sich beim RP-Dienst zu registrieren.
3. Der Browser, der die Webauthn JS-API verwendet, fordert den Authenticator auf, ein Schlüsselpaar für den Benutzer zu erstellen. Bei Roaming-Authenticators wird CTAP2 verwendet, um mit dem Authenticator zu kommunizieren.
4. Der Benutzer gibt eine PIN oder seine Biometrie an. Dies wird bei der Authentifizierung verwendet, um zu überprüfen, ob der Benutzer die Kontrolle über die kryptografischen Anmeldeinformationen auf diesem Gerät hat und diese besitzt.
5. Der Authenticator erstellt das Schlüsselpaar und verknüpft es mit der Identität (Identifier) des RP-Dienstes. Dadurch wird sichergestellt, dass die erstellten Anmeldeinformationen nicht für einen anderen Dienst verwendet werden können.
6. Der öffentliche Teil des Schlüssels wird über den Browser an den RP-Server gesendet.

‍

Authentifizierung

Hier finden Sie eine detaillierte Darstellung des FIDO2-Authentifizierungsablaufs. In diesem Ablauf kümmert sich der Identity Provider (IdP) um die Benutzerauthentifizierung. Die Relaying-Partei ist auf den IdP angewiesen, um ihre Benutzer zu authentifizieren. Dieser Ansatz wird als föderierte oder delegierte Authentifizierung bezeichnet.

Wie bei allen Authentifizierungsprozessen beginnt es beim Benutzer.

1. Der initiiert eine Zugriffsanfrage für den RP-Dienst
2. Der RP-Dienst/Browser sendet die Zugriffsanfrage an den RP-Server
3. Der RP leitet die Anfrage an einen IdP weiter, der die Authentifizierung seiner Benutzer übernimmt
4. Der IdP fordert den Benutzer auf, sich über das FIDO-Authentifizierungsprotokoll zu authentifizieren
5. Der im Browser der Plattform eingebettete Webauthn-Client lokalisiert den Authenticator über die Webauthn JS-API oder CTAP2 im Falle eines Roaming-Authenticators und fordert zur Benutzerverifizierung auf. Die Aufgabe von CTAP2 besteht darin, die Authentifizierungsanforderung vom Webauthn-Client an den Roaming-Authenticator weiterzuleiten.
6. Der Benutzer verifiziert durch Entsperren mit PIN oder Biometrie. Diese Überprüfung macht den eindeutigen privaten Schlüssel des Benutzerdienstes verfügbar. Dadurch wird auch sichergestellt, dass es sich bei dem Benutzer, der den Authentifikator beim RP-Dienst registriert hat, um dieselbe Person handelt, die das registrierte Gerät für den Zugriff auf den Dienst verwendet.
7. Der aktivierte eindeutige private Schlüssel für den Benutzerservice wird dann in der sicheren Umgebung des Authentifikators verwendet, um die empfangene Authentifizierungsanforderung digital zu signieren. Vor dem Signieren der Herausforderung stellt der Authenticator sicher, dass die Herausforderung von genau dem Dienst stammt, bei dem der Benutzer versucht, sich zu authentifizieren. Andernfalls wird die Authentifizierung abgelehnt. Dieser Authentifikator stellt dies sicher, indem er die Kennung der weiterführenden Partei (d. h. den Domainnamen des Dienstes der vertrauenden Partei) validiert. Aus diesem Grund ist es phishing-resistent.
8. Der Authenticator sendet die digital signierte Antwort an den Webauthn-Client (Browser). Wie Sie vielleicht bereits vermutet haben, kommuniziert der Authenticator nicht direkt mit dem RP (oder IdP wie in diesem Flow), er muss den Webauthn-Client durchlaufen, der im Browser der Plattform im Betriebssystem implementiert werden kann.
9. Der Webauthn-Client sendet die digital signierte Antwort vom Authenticator an den IdP.
10. Der IdP überprüft die Signatur- und Authentifizierungsdaten gemäß den FIDO-Spezifikationen.
11. Der IdP sendet einen Authentifizierungsstatus an den RP.
12. Der RP überprüft den vom RP erhaltenen Authentifizierungsstatus
13. Der RP richtet eine authentifizierte Sitzung mit dem Browser ein, wenn die Authentifizierung erfolgreich war. Andernfalls wird keine Sitzung eingerichtet.
14. Der RP gewährt dem Benutzer dann Zugriff auf den beabsichtigten Dienst
15. Der Benutzer kann dann auf den vorgesehenen Dienst zugreifen.

‍

Die Herausforderung der Authentifizierung

• Die Herausforderung vom IdP an den Webauthn-Client (Browser) enthält eine eindeutige Zufallszahl und optionale Erweiterungen.
• Der Webauthn-Client bildet die Client-Daten, die die Anfrage vom IdP, die Relay-Party-ID (in diesem Fall die vollständig qualifizierte Domain des IdP) und Tlsdata für die Kanalbindung umfassen.
• Der Webauthn-Client sendet einen Hash der Client-Daten, der Challenge und des Rapid an den Authenticator. Unabhängig davon, ob es sich bei dem Authenticator um eine Plattform oder um einen Roaming-Authentifikator handelt, ist die Anfrage dieselbe. Der einzige Unterschied besteht darin, dass bei Roaming-Authentifikatoren CTAP2 verwendet wird, um die Anfrage über USB, NFC oder BLE an den Authenticator zu übertragen.

‍

Die Authentifizierungsantwort

• Der Authenticator signiert die Herausforderung und sendet die Signatur mit den Authentifizierungsdaten an den Webauthn-Client
  • Die Authentifizierungsdaten enthalten den Hash der Rapid-, Zähler- und Anmeldebestätigungsdaten
  • Die Signatur enthält den Hash der Kundendaten, Zähler
• Auch hier gilt: Unabhängig davon, ob es sich beim Authenticator um eine Plattform oder um einen Roaming-Authentifikator handelt, ist die Antwort dieselbe. Der einzige Unterschied besteht darin, dass bei Roaming-Authentifikatoren CTAP2 verwendet wird, um die Antwort zurück zum Webauthn-Client zu transportieren.
• Der Webauthn-Client sendet die Antwort an den RP (in diesem Fall IdP).

‍

Überprüfung

Der IdP verwendet den öffentlichen Schlüssel des Benutzers, um die Signatur der Authentifizierungsantwort zu überprüfen. Der private Schlüssel des Benutzers kann nur dann zum Signieren der Antwort verwendet werden, wenn der Benutzer den zweiten Faktor (PIN oder biometrische Daten) eingegeben hat. Und da der private Schlüssel so geschützt ist, dass er nicht gestohlen werden kann, kann der IdP glauben, dass die Authentifizierung tatsächlich vom Benutzer und nicht von einem Betrüger vorgenommen wurde.

Ähnlichkeiten zwischen Plattform- und Roaming-Authentifikatoren

• Sowohl Platform als auch Roaming Authenticators hängen vom WebAuthn-Client ab, der in einem Browser und/oder im Betriebssystem implementiert ist, und vom WebAuthn-Client-Gerät (Plattform), damit es funktioniert.
• Beide verlassen sich auf die Plattform, um mit dem Authentifikator zu kommunizieren.
• Beide verwenden genau das gleiche Challenge-Response-Kryptografieprotokoll mit öffentlichen Schlüsseln
• Beide sind Phishing-resistent
• Authentifizierungszeremonien sind resistent gegen Man-in-the-Middle-Angriffe.

‍

Unterschiede zwischen Plattform- und Roaming-Authentifikatoren

Der Hauptunterschied zwischen Platform Authenticators und Roaming Authenticators ist der zusätzliche Transport (CTAP2), den Roaming Authenticators benötigen, um die Anfrage und Antworten zum und vom Webauthon-Client zu transportieren.

Plattformauthentifikatoren sind in die Plattform eingebettet, während Roaming-Authenticatoren unabhängig von der Plattform sind.

Fazit

Die Hauptfunktion des Authenticators besteht darin, WebAuthn-Signaturen bereitzustellen, die an verschiedene Kontextdaten gebunden sind. Diese Daten werden auf verschiedenen Ebenen des Stacks beobachtet und hinzugefügt, wenn eine Signaturanforderung vom Server an den Authenticator weitergeleitet wird. Bei der Überprüfung einer Signatur überprüft der Server diese Bindungen anhand der erwarteten Werte. Jede Änderung der erwarteten Werte würde zu einem Authentifizierungsfehler führen.

Referenz

• Überblick über die Spezifikationen der Benutzerauthentifizierung - FIDO Alliance

• Webauthentifizierung: Eine API für den Zugriff auf Anmeldeinformationen mit öffentlichen Schlüsseln — Level 3