FIDO2-Authentifizierung

Übersicht

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

WebAuthn definiert eine Standard-Web-API, die in Browsern (WebAuthN Client) und Plattformen integriert ist, um die Unterstützung der FIDO-Authentifizierung zu ermöglichen. CTAP2 ermöglicht die Verwendung von externen Authentifikatoren (FIDO-Sicherheitsschlüssel, mobile Geräte) für die Authentifizierung auf 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 für die Authentifizierung auf FIDO2-fähigen Browsern und Betriebssystemen über USB, NFC oder BLE für eine Second-Factor-Erfahrung.

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

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

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

Einzigartige Merkmale 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 (die im Browser/Betriebssystem eines Geräts implementiert ist) eine Herausforderung an den Authentifikator, der Authentifikator sendet eine signierte Antwort an den RP. Der RP prüft die signierte Antwort, um dem Benutzer den Zugang zu ermöglichen.

FIDO2-Authentifizierung sind phishing-resistente Authentifikatoren.

Wie FIDO2 funktioniert

Anmeldung

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 Nutzer bestätigt seine Absicht, sich beim RP-Dienst zu registrieren.
3. Der Browser fordert über die Webauthn JS API den Authentifikator auf, ein Schlüsselpaar für den Benutzer zu erstellen. Im Falle von Roaming-Authentifikatoren wird CTAP2 zur Kommunikation mit dem Authentifikator verwendet.
4. Der Benutzer gibt eine PIN oder sein biometrisches Merkmal ein. Dies wird bei der Authentifizierung verwendet, um zu überprüfen, ob der Benutzer die Kontrolle und den Besitz des kryptografischen Berechtigungsnachweises auf diesem Gerät hat.
5. Der Authentifikator erstellt das Schlüsselpaar und verknüpft es mit der Identität (Kennung) des RP-Dienstes. Dadurch wird sichergestellt, dass der erstellte Berechtigungsnachweis nicht für einen anderen Dienst verwendet werden kann.
6. Der öffentliche Teil des Schlüssels wird über den Browser an den RP-Server gesendet

‍

Authentifizierung

Hier ist eine detaillierte Darstellung des FIDO2-Authentifizierungsflusses. In diesem Fluss ist der Identitätsanbieter (IdP) für die Benutzerauthentifizierung zuständig. Die weiterleitende Partei hängt vom IdP ab, um ihre Benutzer zu authentifizieren. Dieser Ansatz wird als föderierte oder delegierte Authentifizierung bezeichnet.

Wie bei allen Authentifizierungsverfahren beginnt der Prozess beim Benutzer.

1. Der initiiert eine Zugangsanfrage an 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 in den Browser der Plattform eingebettete Webauthn-Client findet den Authentifikator über die Webauthn JS API oder CTAP2 im Falle eines Roaming-Authentifikators und fordert den Benutzer zur Verifizierung auf. Die Aufgabe von CTAP2 besteht darin, die Authentifizierungsanfrage vom Webauthn-Client an den Roaming-Authentifikator weiterzuleiten.
6. Der Benutzer verifiziert sich durch Entsperren mit einer PIN oder einem biometrischen Merkmal. Diese Verifizierung macht den eindeutigen privaten Schlüssel des Benutzerdienstes verfügbar. Dadurch wird auch sichergestellt, dass der Benutzer, der den Authentifikator beim RP-Dienst registriert hat, dieselbe Person ist, die das registrierte Gerät für den Zugriff auf den Dienst verwendet.
7. Der aktivierte eindeutige private Schlüssel des Benutzerdienstes wird dann in der sicheren Umgebung des Authentifikators verwendet, um die empfangene Authentifizierungsanfrage digital zu signieren. Vor dem Signieren der Herausforderung stellt der Authentifikator sicher, dass die Herausforderung von genau dem Dienst stammt, bei dem sich der Benutzer zu authentifizieren versucht. Ist dies nicht der Fall, wird die Authentifizierung abgelehnt. Der Authentifikator stellt dies sicher, indem er die Kennung der weiterleitenden Partei validiert (d. h. den Domänennamen des Dienstes der vertrauenden Partei). Aus diesem Grund ist er resistent gegen Phishing.
8. Der Authentifikator sendet die digital signierte Antwort an den Webauthn-Client (Browser). Wie Sie vielleicht schon erraten haben, kommuniziert der Authentifikator nicht direkt mit dem RP (oder IdP wie in diesem Ablauf), sondern muss über den Webauthn-Client gehen, der im Browser der Plattform oder im Betriebssystem implementiert sein kann.
9. Der Webauthn-Client sendet die digital signierte Antwort des Authentifikators an den IdP.
10. Der IdP verifiziert die Signatur und die Authentifizierungsdaten gemäß den FIDO-Spezifikationen.
11. Der IdP sendet einen Authentifizierungsstatus an den RP.
12. Der RP prüft den vom RP erhaltenen Authentifizierungsstatus
13. Der RP baut eine authentifizierte Sitzung mit dem Browser auf, wenn die Authentifizierung erfolgreich war. Wenn nicht, wird keine Sitzung aufgebaut.
14. Der RP gewährt dem Benutzer dann Zugang zu dem gewünschten Dienst
15. Der Nutzer kann dann auf den gewünschten Dienst zugreifen.

‍

Die Authentifizierungsherausforderung

• Die Challenge vom IdP an den Webauthn-Client (Browser) enthält eine eindeutige Zufallszahl und optionale Erweiterungen.
• Der Webauthn-Client bildet die Client-Daten, die aus der Challenge des IdP, der Kennung der übermittelnden Partei (in diesem Fall die voll qualifizierte Domäne des IdP) und den Tls-Daten für die Kanalbindung bestehen.
• Der webauthn-Client sendet einen Hash der Client-Daten, die Challenge und die Rpid an den Authentifikator. Unabhängig davon, ob es sich bei dem Authentifikator um einen Plattform- oder einen Roaming-Authentifikator handelt, ist die Anfrage die gleiche. Der einzige Unterschied besteht darin, dass bei Roaming-Authentifikatoren CTAP2 verwendet wird, um die Anfrage über USB, NFC oder BLE an den Authentifikator zu übertragen.

‍

Die Authentifizierungsantwort

• Der Authentifikator signiert die Challenge und sendet die Signatur zusammen mit den Authentifizierungsdaten an den Webauthn-Client
  • Die Authentifizierungsdaten enthalten den Hash der rpid, des Zählers und der Beglaubigungsdaten
  • Die Signatur enthält den Hash-Wert der Kundendaten, den Zähler
• Auch hier ist die Antwort unabhängig davon, ob es sich um einen Plattform- oder einen Roaming-Authentifikator handelt, die gleiche. Der einzige Unterschied besteht darin, dass bei Roaming-Authentifikatoren CTAP2 verwendet wird, um die Antwort zurück an den Webauthent-Client zu übermitteln.  
• 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 prüfen. Der private Schlüssel des Benutzers kann nur dann zum Signieren der Antwort verwendet werden, wenn der Benutzer den zweiten Faktor (PIN oder biometrisches Merkmal) eingegeben hat. Und da der private Schlüssel so geschützt ist, dass er nicht gestohlen werden kann, kann der IdP davon ausgehen, dass die Authentifizierung tatsächlich vom Benutzer und nicht von einem Betrüger durchgeführt wurde.

Ähnlichkeiten zwischen Plattform- und Roaming-Authentifikatoren

• Sowohl die Plattform- als auch die Roaming-Authentifikatoren sind auf den WebAuthN-Client angewiesen, der in einem Browser und/oder im Betriebssystem und auf dem WebAuthN-Client-Gerät (Plattform) implementiert ist, damit sie funktionieren.
• Beide stützen sich auf die Plattform zur Kommunikation mit dem Authentifikator
• Beide verwenden genau dasselbe Verschlüsselungsprotokoll mit öffentlichem Schlüssel (Challenge-Response)
• Beide sind phishing-resistent
• Authentifizierungszeremonien sind resistent gegen Man-in-the-Middle-Angriffe.

‍

Unterschiede zwischen Plattform- und Roaming-Authentifikatoren

Der Hauptunterschied zwischen Plattform- und Roaming-Authentifikatoren ist der zusätzliche Transport (CTAP2), den die Roaming-Authentifikatoren benötigen, um die Anfragen und Antworten zum und vom Webauthn-Client zu transportieren.

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

Schlussfolgerung

Die Hauptfunktion des Authentifikators 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 Authentifikator weitergeleitet wird. Bei der Verifizierung einer Signatur überprüft der Server diese Bindungen anhand der erwarteten Werte. Jede Änderung der erwarteten Werte würde zu einem Scheitern der Authentifizierung führen.

Referenz

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

• Web-Authentifizierung: Eine API für den Zugriff auf öffentliche Schlüssel Anmeldedaten - Stufe 3