# FIDO2

FIDO2 ist eine Initiative der FIDO-Allianz gemeinsam mit dem World Wide Web Consortium (W3C) mit dem Ziel eine Multi-Faktor-Authentisierung, auch als starke Authentisierung bezeichnet, primär für Anwendungen im World Wide Web (Web) zu schaffen. Dabei können Passwörter bei der Anmeldung an Onlinediensten durch eine Kombination von verschiedenen kryptographischen Methoden ersetzt oder ergänzt werden. Das Akronym steht für „Fast IDentity Online“.

## Überblick

Das FIDO2-Projekt umfasst, wie in nebenstehender Abbildung dargestellt, verschiedene kryptografische Kommunikationsprotokolle wie das WebAuthn und das Client to Authenticator Protocol (CTAP) zwischen den Funktionseinheiten, und als Funktionseinheiten die sogenannten Authentifikatoren, wie beispielsweise Sicherheits-Token, den Benutzer (englisch Client), welcher beispielsweise einen Web-Browser nutzt, und den Dienstanbieter; dieser wird englisch Relying Party (RP) oder auch als FIDO2-Server bezeichnet, der einen Dienst für den Kunden anbietet.
Die Schnittstelle zwischen dem Authentifikator und dem Client (dies ist beispielsweise eine USB-Verbindung zwischen dem Sicherheitstoken und dem lokalen Web-Browser vom Kunden) wird durch die beiden alternativen Protokolle CTAP1 und CTAP2 wahrgenommen. CTAP1 basiert auf früheren Arbeiten der FIDO-Allianz, nämlich dem Authentifizierungsstandard Universal 2nd Factor (U2F), welcher im Rahmen von FIDO2 in CTAP1 umbenannt wurde. CTAP2 bietet über CTAP1 hinausgehende Funktionen an und kann im Gegensatz zu CTAP1, welche nur auf die Anwendung als Zwei-Faktor-Authentisierung ausgelegt war, je nach Situation Ein-, Zwei- oder Mehrfachauthentisierung anbieten.
Die Schnittstelle zwischen dem Client und dem FIDO2-Server des Dienstanbieters stellt im Regelfall eine Internetverbindung dar und wird über das Kommunikationsprotokoll WebAuthn realisiert. Die Schnittstelle zwischen CTAP und WebAuthn liegt in der Kundenanwendung, beispielsweise im Web-Browser oder in Teilen des Betriebssystems. Für den Client (Web-Browser) ist es zwingend notwendig, JavaScript aktiviert zu haben, und die Verbindung zum FIDO2-Server muss verschlüsselt erfolgen. Die verschlüsselte Übertragung wird üblicherweise unter Nutzung von TLS in Form des Hypertext Transfer Protocol Secure (https) realisiert.
Zusammengenommen spezifizieren WebAuthn und das korrespondierende CTAP der FIDO-Allianz ein Standardauthentifizierungsprotokoll, bei dem die Endpunkte aus zwei Elementen bestehen:
* Benutzerkontrollierten kryptografischen Authentifikatoren. Diese können externe Geräte wie Security-Token oder ein Smartphone sein. Die physische Schnittstelle zu diesen externen Geräten kann beispielsweise der Universal Serial Bus (USB), Near Field Communication (NFC) oder Bluetooth Low Energy (BLE) sein. Auch interne, im Client fix untergebrachte Authentifikatoren, welche mit dem Trusted Platform Module (TPM) zusammenarbeiten, sind möglich. Im Rahmen von CTAP2 kann der Authentifikator zusätzlich biometrisch oder mit einem Passwort (hier PIN genannt) gesichert werden, was die Mehrfachauthentisierung ergibt.
* Einer WebAuthn-Gegenstelle, englisch Relying Party (RP) oder FIDO2-Server. Diese umfasst neben dem eigentlichen Dienst verschiedene Speicher wie den Attestation Store und den User Store zur Ablage der für die Authentisierung nötigen Daten.
Ein Web-Benutzerprogramm, wie zum Beispiel ein Webbrowser, bildet somit zusammen mit einem WebAuthn-Client einen Vermittler zwischen dem Authentifizierer und der Gegenstelle im Web. Ein einzelnes WebAuthn-Clientgerät kann mehrere WebAuthn-Clients unterstützen. Zum Beispiel kann ein Laptop mehrere Clients unterstützen: einen für jedes auf dem Laptop laufende kompatible Benutzerprogramm. Dafür muss das Benutzerprogramm die WebAuthn-JavaScript-API implementieren.

## Anwendung

Für die praktische Anwendung von FIDO2 sind technisch zwei unterschiedliche Verfahren vorgesehen. Diese sind die zunächst erfolgende und im Regelfall nur einmalig auszuführende Registrierung (englisch Client Registration), in deren Ablauf sich ein Anwender mit seinem Authentifikator bei einem FIDO2-Server registriert. Nach erfolgreicher Registrierung kann sich dann der Anwender mit seinem Authentifikator an dem FIDO2-Server beliebig oft authentifizieren (englisch Client Authentication).

### Registrierungsablauf

Zur Registrierung löst der Client, beispielsweise ein Web-Browser, zunächst bei dem FIDO2-Server eine Registrierungsanforderung aus. Diese Anforderung kann bereits grundlegende Informationen wie eine Benutzerkennung enthalten. Der FIDO2-Server antwortet darauf mit einem Datenpaket, welches unter anderem eine sogenannte englisch Challenge enthält, dies ist ein aus Zufallszahlen bestehendes Datenfeld, welches im Rahmen der Challenge-Response-Authentifizierung verwendet wird und Replay-Angriffe verhindert, und verschiedenen weiteren Informationen beispielsweise die Domain und den Typ des FIDO2-Servers. Der Web-Browser prüft, ob die vom Server gelieferte Domain mit der aufgerufenen Domain übereinstimmt, dies verhindert im Rahmen der Registrierung Phishing, und leitet diese Daten via CTAP an den Authentifikator weiter.
Der Authentifikator muss für die weitere Verarbeitung zunächst um die explizite Zustimmung des Benutzers bitten. Dies kann technisch in verschiedener Art und Weise erfolgen, beispielsweise durch Drücken eines Tasters direkt am Authentifikator oder durch Aktivierung eines biometrischen Sensors. Damit ist sichergestellt, dass sich ein Benutzer physisch unmittelbar am Authentifikator befindet. Eine Fernsteuerung dieser Auslösung, beispielsweise mittels Fernwartungssoftware auf einem PC, ist nicht zulässig. Weiters und optional kann gefordert sein, dass sich der Benutzer gegenüber dem Authentifikator als legitimer Benutzer zusätzlich zu erkennen geben muss. Das kann durch Abfrage eines PIN-Codes oder durch biometrische Merkmale wie einen Fingerabdruck erfolgen. Dabei ist wesentlich, dass diese Daten nur zwischen dem Client, beispielsweise dem lokalen Web-Browser, und dem Authentifikator erfolgt und nicht über das Internet übertragen werden. Mit dieser Benutzerkennung wird verhindert, dass ein verlorener oder entwendeter Authentifikator durch eine andere Person genutzt werden kann.
Im erfolgreichen Fall nutzt bzw. generiert der Authentifikator im Rahmen der Public-Key-Authentifizierung mittels asymmetrischer Kryptotechniken einen öffentlichen und privaten Schlüssel. Je nach Verfahren (CTAP1 oder CTAP2) verbleibt der private Schlüssel ausschließlich im Authentifikator und kann auch in Folge nicht ausgelesen werden, oder diese Daten werden verschlüsselt und als Teil der Antwort an den FIDO2-Server übertragen und dort gespeichert. Je nach Protokoll umfasst die Antwort vom Authentifikator neben den Daten der Challenge-Response-Authentifizierung auch noch verschiedene weitere Daten. Zusätzlich kann eine „Beglaubigung“ (englisch attestation) des Authentifikators erfolgen, welche nur bei der Registrierung vorgesehen ist. Dabei werden Informationen über den verwendeten Authentifikator wie die AAGUID mit übertragen. Mit diesen zusätzlichen Daten wie die AAGUID kann der FIDO2-Server seinen Service auf bestimmte Typen von Authentifikatoren einschränken, auch den konkreten Authentifikator anhand einer eindeutigen Kennung ermitteln und zum Beispiel für die Nutzung des Services eine bestimmte FIDO2-Zertifizierungsstufe oder die Verwendung eines Hardware-Token eines bestimmten Herstellers oder Herstellergruppe erzwingen. Diese zusätzliche Übermittlung von Daten für die „Beglaubigung“ kann in bestimmten Anwendungen punkto Datenschutz problemematisch sein, weshalb auch bei diesem Schritt bei manchen Clients eine zusätzliche Rückfrage erfolgt.
Die vom Client mittels WebAuthn an den FIDO2-Server übermittelten Daten werden im erfolgreichen Fall der Registrierung dort permanent gespeichert und dienen in Folge der Authentifizierung des Benutzers. Die Registrierung ist zum Schutz gegen Phishing an den genauen Namen bzw. die Domain des FIDO2-Servers gebunden. Wird vom Betreiber des FIDO2-Servers der Name oder die Domain geändert, verlieren alle Registrierungen ihre Gültigkeit.

### Authentifizierungsablauf

Der Authentifizierungsablauf dient dazu, dass sich ein bestimmter, vorher registrierter Benutzer mit seinem Authentifikator bei einem FIDO2-Server anmelden kann. Aus praktischer Sicht ist der Ablauf für den Benutzer nahezu identisch mit den einzelnen Schritten bei der Registrierung, nur dass dabei die Daten, welche im finalen Schritt an den FIDO2-Server übermittelt werden, mit den bereits am Server abgelegten Daten verglichen werden und bei positivem Ausgang der Zugang zu den Diensten des Servers erfolgt.

### Passwortlose Anmeldung

Im Rahmen von FIDO2 und eingeschränkt auf CTAP2 und je nach Gestaltung des Anmeldeablaufes am FIDO2-Server besteht auch die Möglichkeit, dass sich ein Benutzer nur mit seiner Benutzerkennung (Benutzernamen) und ohne Passwort bei einem Dienst anmelden kann. Dieses Verfahren besteht technisch zwar auch bei CTAP1 und FIDO1, allerdings mit der Schwierigkeit, dass keine Möglichkeit vorgesehen ist, die unberechtigte Nutzung des Authentifikators durch Dritte zu verhindern. Erst ab CTAP2 besteht die Möglichkeit, dass der FIDO2-Server im Rahmen des Authentifizierungsablaufes den Authentifikator via Web-Browser anweist, dass sich der Benutzer gegenüber dem Authentifikator als legitimer Benutzer zu erkennen geben muss, beispielsweise durch Eingabe einer PIN oder durch die Erkennung von biometrischen Merkmalen.

### discoverable credentials

Darüber hinaus bietet CTAP2 auch die Möglichkeit, sich ohne einer Benutzerkennung und ohne Password nur mit dem Authentifikator als einziger Faktor gegenüber dem FIDO2-Server zu authentifizieren. Dies ermöglicht CTAP2 im Rahmen der englisch discoverable credentials, dt. etwa „auffindbare Anmeldeinformation“, die auch bei dem Verfahren Passkey zur Anwendung kommen. Bei CTAP2 besteht die Möglichkeit, dass vor der eigentlichen Anmeldung am FIDO2-Server der Client, wie zum Beispiel der Web-Browser, den Authentifikator nach einer Benutzerkennung für eine bestimmte Domain fragt. Dazu muss der Benutzer am Authentifikator durch Tastendruck die Freigabe erteilen, gegebenenfalls sich gegenüber dem Authentifikator mittels PIN oder biometrischer Merkmale als autorisierter Benutzer zu erkennen geben, womit der Web-Browser die Benutzerkennungen für die gewünschte Domain bekommt. Die Benutzerkennung schickt der Web-Browser im ersten Schritt an den FIDO2-Server, womit dieser den Bezug zu den am FIDO2-Server gespeicherten Registrierungsdaten herstellen kann. Der restliche Ablauf der Authentifizierung erfolgt dann wie bei einer manuellen Eingabe eines Benutzernamens.
Der Nachteil dieser englisch discoverable credentials besteht darin, dass die meisten Authentifikatoren wie übliche Hardware-Token nur über einen sehr eingeschränkten Speicherumfang verfügen, mit Stand Ende 2023 sind ca. 20 bis 30 „auffindbare Anmeldeinformationen“ machbar, danach kann keine weitere neue Registrierung mit dem Authentifikator erfolgen. Ein weiterer Nachteil dieser bequem wirkenden discoverable credentials besteht in dem Umstand, dass der Server erkennen kann, mit welchen Benutzerkennungen ein bestimmter Authentifikator verwendet wurde und damit wahrscheinlich einer Person zuordenbar ist. Diese Möglichkeit zur Erkennung, bei welchem FIDO2-Server ein bestimmter Authentifikator zur Registrierung verwendet wurde, besteht bei non-discoverable credentials und bei CTAP1 grundsätzlich nicht, da dabei im Rahmen der Registrierung keinerlei Daten am Authentifikator gespeichert werden. Mit non-discoverable credentials ist eine beliebig große Anzahl an Registrierungen, auch von verschiedenen Benutzern und unter Nutzung desselben Authentifikators, an einem oder mehreren FIDO2-Servern möglich. Wird im Rahmen der Registrierung mittels non-discoverable credentials keine englisch attestation durchgeführt, kann der FIDO2-Server auch nicht erkennen, welcher Authentifikator verwendet wird.

### Verlust des Authentifikators

Da die Daten des Authentifikators geheim und fix an diesen gebunden sind, besteht bei Anwendung von FIDO2 das grundsätzliche Problem, dass jeder Authentifikator in Form eines Hardware-Token einzigartig und nicht duplizierbar ist. Bei Verlust des Authentifikators ist daher auch der Verlust der darauf aufbauenden Zugänge verbunden. Auch bei Änderung des Namens bzw. Domain des FIDO2-Servern gehen alle Registrierungen verloren. Für die reale Anwendung ist daher zusätzlich zu FIDO2 eine Wiederherstellungsstrategie nötig. FIDO2 umfasst keinerlei Wiederherstellungsstrategien oder Vorschläge dazu. Eine solche Implementierung kann beispielsweise darin bestehen, dass ein Benutzer sich mit mindestens zwei verschiedenen Authentifikatoren am FIDO2-Server registrieren muss, was die Anschaffungskosten verdoppelt, um so bei Verlust von einem Authentifikator auf den Zweiten zurückgreifen zu können. Oder es können unter Umgehung von FIDO2 auch Einmalpasswörter oder eine Wiederherstellung mit hinterlegter E-Mail-Adresse oder einer Mobiltelefonnummer eingesetzt werden. Dabei besteht das grundsätzliche Problem, dass die hohe Sicherheit von FIDO2 durch eine schwache oder in Praxis fehlerhaft implementierte Wiederherstellungsstrategie vernichtet werden kann.

## Zertifizierungen

Im Rahmen der FIDO-Allianz sind unterschiedliche Zertifizierungsebenen für die Kernspezifikationen (UAF, U2F und FIDO2) vorgesehen. Mit Stand Ende 2023 sind in Summe drei verschieden hohe Zertifizierungsstufen vorgesehen, die sich wiederum teilweise in Substufen unterteilen, wobei eine höhere Zertifizierungsstufe eine größere Widerstandsfähigkeit gegen verschiedene Angriffe bietet:
* Stufen 1 und 1+
* Stufe 2
* Stufen 3 und 3+
Die Stufe 1 ist generell das einfachste Niveau, das unter anderem Lösungen in einem mobilen Gerät, wie dem Android keystore oder TouchID unter iOS umfasst, aber auch reine Softwareimplementierungen, die auf einem PC ausgeführt werden, fallen in diese Stufe. Stufe 2 setzt voraus, dass eine dezidierte Hardware (Security Key) zum Einsatz kommt, in der die zertifizierte und von außen unveränderliche Software läuft, die gegen Softwareangriffe von außen gesichert ist; die Hardware muss dabei nicht besonders gegen physische Angriffe geschützt sein. Die Stufen 3/3+ setzen zusätzlich noch eine spezielle Hardware voraus, wie den Einsatz von Kryptoprozessoren, die auch gegen lokale, physische Angriffe auf die Hardware geschützt sind.
Auf der Web-Seite der FIDO-Allianz ist eine herstellerübergreifende, öffentlich Datenbank mit den aktuell verfügbaren Produkten und den dazu erteilten Zertifizierungen einsehbar.

## Passkey

Passkey ist ein Begriff aus dem Marketing und stellt eine Art Erweiterung des FIDO2-Standards dar, welche auf den discoverable credentials aufbaut. Passkeys sollen FIDO2 einfacher nutzbar machen, indem man nicht jeden Authentifikator mit allen Benutzerkonten paaren muss. Auch der Verlust eines Authentifikators wirkt sich in der Anwendbarkeit geringer aus. Die geheimen und in den Authentifikatoren abgelegten und damit nicht kopierbaren Primärschlüssel sind bei Passkey nicht mehr an einen Authentifikator gebunden, üblich sind reine Softwarelösungen, welche beispielsweise auf einem Smartphone laufen. Die Daten der Primärschlüssel sind in verschiedener Form auslesbar und damit duplizierbar, was die einfachere Nutzbarkeit begründet, womit aber ein Sicherheitsverlust verbunden ist, da die Schlüsseldaten potentiell auch unerlaubt dupliziert werden können; optional werden die geheimen Primärschlüsseldaten auch in der Cloud abgelegt oder über die Cloud synchronisiert und sind überhaupt nicht mehr an einen bestimmten physischen Authentifikator gebunden. Apple, Google und Microsoft bewerben aus kommerziellen Gründen das Passkey-Verfahren.
Gegen Phishing ist Passkey genauso wie FIDO2 widerstandsfähig, weil auch dabei die Domain in die Berechnung des Schlüssels einfließt, nicht aber gegen das ungerechtfertigte Duplizieren der Primärschlüsseldaten. Hardwarebasierte Security-Token, welche das Duplizieren der geheimen Schlüsseldaten im Token unterbinden, sind dafür mit weniger Komfort als Passkey anzuwenden, aber sicherer.