Authentifizierung durch Besitz mit FIDO2

Inhalt

FIDO2
… Entwicklung von FIDO2
… Parteien und Protokolle
… Funktionen
[]

FIDO2

FIDO2 ist ein Projekt der Fast Identiy Online (FIDO) Alliance in Kooperation mit dem World Wide Web Consortium (W3C). Das Ziel der FIDO Alliance ist es, das “Passwort-Problem der Welt zu lösen” [1]. FIDO2 ist dabei ein vielversprechender Kandidat im Rennen um die Nachfolge von Passwörtern als Standardauthentifizierungsmechanismus.

Entwicklung von FIDO2

Ursprünglich basiert FIDO2 auf dem von Google entwickelten Security Keys Protocol [2] entstanden. Das Security Keys Protocol bietet Zweifaktorauthentifizierung über einen Hardwaretoken (Security Key), den der Nutzer mit sich führt. Ein solcher Security Key kann von einem beliebigen Anbieter sein, solange er das Security Keys Protocol unterstützt.

Das Security Keys Protokoll wurde anschließend als Universal Second Factor (U2F) standardisiert. Im FIDO2 Projekt wurde U2F schließlich mit WebAuthn ergänzt, wobei U2F zur ersten Version des Client-to-Authenticator Protocols (CTAP) umbenannt wurde.

Parteien und Protokolle

Im Kontext von FIDO interagieren drei Parteien über zwei Protokolle:

• die Relying Party, bei der der Nutzer sich authentifizieren möchte
• der Client. Gemeint ist hier das Gerät, auf dem der Nutzer sich authentifieren möchte
• der Authenticator, über den der Nutzer sich authentifiziert

Beispiel: Ein Nutzer browst an seinem Laptop und möchte sich bei GitHub anmelden. Zur Authentifizierung nutzt er einen SoloKey.

• Relying Party: GitHub
• Client: Laptop des Nutzers
• Authenticator: Solokey

Die Kommunikation zwischen Client und Relying Party wird über WebAuthn [3] abgebildet. WebAuthn ist ein von W3C entwickelter Standard zur Authentifizierung in Webbrowsern. Das Protokoll basiert auf einem Public-Key-Verfahren und bietet beidseitige Authenfizierung von Webanwendung und Benutzer.

Ergänzt wird WebAuthn durch das Client-to-Authenticator Protocol (CTAP) [4]. CTAP verbindet den Client mit externen Authenticators. Dabei unterstützt es USB, Bluetooth Low Energy (BLE) und Near-Field Communication (NFC) als Schnittstellen.

Weiterhin gibt es die Möglichkeit, anstelle von externen Authenticators interne Authenticators zu verwenden, die sich bereits auf dem Client Device befinden. Ein Beispiel hierfür ist die Verwendung von Biometrie auf einem Smartphone.

Funktionen

Das Protokoll besteht aus zwei großen Funktionen:

1. Registrieren
2. Anmelden

Während der Registrierung wird ein asymetrisches Schlüsselpaar in der sicheren Hardware des Security Keys erzeugt. Die private Komponente dieses Schlüsselpaars wird in der sicheren Hardware gespeichert und mit Informationen über die Relying Party versehen. Anschließend wird die öffentliche Komponente des Schlüsselpaars an die Relying Party gesendet, wo sie ebenfalls mit Informationen über Nutzer und verwendeten Authenticator gespeichert wird.

Die Anmeldung erfolgt daraufhin als Challenge-Response-Verfahren. Nachdem der Client die Authentifizierung anstößt, generiert die Relying Party eine Challenge und sendet sie an den Client. Dieser leitet die Challenge an den Authenticator weiter, der die Challenge auswertet.

Die Challenge enthält Informationen über die Relying Party sowie über die Verbindung zwischen Client und Relying Party. Diese Informationen überprüft der Authenticator mit denen, die bei der Registierung hinterlegt wurden. Bei erfolgreicher Bestätigung löst und signiert er die erhaltene Challenge mit der privaten Komponente des Schlüsselpaars.

Die so entstandene Response wird an den Client übertragen, von wo sie an die Relying Party gesendet wird. Diese kann die Signatur mit Hilfe des öffentlichen Teils des Schlüsselpaars kontrollieren und somit den Nutzer authentifizieren.

Absicherung von Applikationen

Im Rahmen einer MOVI-Anwendung auf Smartphones kann FIDO eingesetzt werden, um den Nutzer zu authentifizieren. Die Authentifizierung des Nutzers kann dabei sowohl durch externe als auch interne Authenticators erfolgen. Abhängig vom genutzten Authenticator und der Ausstattung des genutzten Smartphones lassen sich verschiedene Sicherheitsstufen erreichen.

Sicherheitsstufen

FIDO zertifizierte Authenticators wird eine Stufe (L1-L3) zugeordnet [5]. Die unsicherste Stufe ist L1, die sicherste Stufe ist L3+. Die Stufen bauen aufeinander auf, sodass jede Stufe die Anforderungen der darunterliegenden Stufen (sowie weiterführende Anforderungen der eigenen Stufe) erfüllt.

Die erreichbare Sicherheit steigt mit der Ausstattung des genutzten Smartphones. Während ohne sichere Hardwareumgebung in der Regel nur die Stufen L1 bzw. L1+ erreichbar sind, lässt sich mit sicherer Hardwareumgebung oder Verwendung eines externen Authenticators die Stufe L3 oder sogar L3+ erreichen.

Mögliche Sicherheitsstufen

Es folgt eine Auflistung von beispielhaften Szenarien und der damit verbundenen Sicherheitstufe:

• L1: FIDO2 mit Android Keystore als internet Authenticator, Keystore ist nicht zertifiziert
• L1: iOS Anwendung mit Touch ID als interner Authenticator
• L2+: FIDO2 mit Android Keystore als interner Authenticator, Keystore läuft in einer Trusted Execution Environment (TEE)
• L3: FIDO zertifizierter externer Authenticator (Yubikey etc.), Betriebssystem des Smartphones ist zertifiziert

Bildquelle: https://fidoalliance.org/certification/authenticator-certification-levels/

Quellen

[1] https://fidoalliance.org
[2] Lang, Juan, et al. “Security keys: Practical cryptographic second factors for the modern web.” International Conference on Financial Cryptography and Data Security. Springer, Berlin, Heidelberg, 2016.
[3] https://www.w3.org/TR/webauthn/
[4] https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-client-to-authenticator-protocol-v2.0-id-20180227.html
[5] https://fidoalliance.org/certification/authenticator-certification-levels/