U2F (Universal Second Factor, universeller zweiter Faktor) ist ein Industriestandard für eine allgemein anwendbare Zwei-Faktor-Authentisierung, basierend auf einer adaptierten Challenge-Response-Authentifizierung. Sie dient neben einem Zugangskennwort dem Nachweis der Zugriffsberechtigung, beispielsweise für webbasierte Dienste, und kann in Kombination mit digitalen Personaldokumenten auch zur Identitätsfeststellung eingesetzt werden.

Die U2F-Spezifikationen wurden von Google unter Beteiligung der Unternehmen Yubico und NXP Semiconductors entwickelt. Zur Fortentwicklung und Zusammenarbeit der U2F-Anbieter wurde die nichtkommerzielle FIDO-Allianz gegründet. Am 9. Dezember 2014 wurde der erste entsprechende Standard FIDO v1.0 veröffentlicht.^[1] Im folgenden Jahr wurde die Initiative FIDO2 ins Leben gerufen, in welcher U2F in Folge unter der geänderten Bezeichnung Client to Authenticator Protocol (CTAP1) aufging.^[2]

Im Gegensatz zur Industrie-Initiative „Open Authentication“ (OATH), die ebenfalls Lösungen zur Zwei-Faktor-Authentisierung als Industriestandard zu etablieren sucht, unterliegen U2F-Verfahrensbeschreibungen keinen Geheimhaltungsvorschriften der beteiligten Unternehmen.

Als wesentliche Eigenschaft weist der U2F-Standard keine nach außen hin eindeutige Kennung eines bestimmten U2F-Gerätes auf und erlaubt so den Schutz der Privatsphäre. Ein Dienstanbieter (Server), bei dem ein Kunde zwecks Identifizierung mit seinem U2F-Gerät angemeldet ist, kann deshalb auch nicht feststellen, bei welchen anderen Diensten dieses U2F-Gerät noch registriert ist. Dies gilt sogar dann, wenn ein bestimmter Dienstanbieter zu den Anmeldedaten der anderen Dienstanbieter auch Zugang hat oder Kenntnis über diese Anmeldedaten bekommen hat.^[3]

Diese Eigenschaft des U2F-Verfahrens trägt wesentlich zum weiteren Schutz bei, wenn die bei der Anmeldung beim Dienstanbieter hinterlegten Anmeldedaten im Rahmen von Datenlecks von Dritten ausgelesen werden und sich dann unkontrolliert verbreiten können.

Dieser Schutz ist auch dann gegeben, wenn ein U2F-Gerät bei einem Anbieter von verschiedenen Personen oder von einer Person zur Anmeldung von mehreren Konten verwendet wird. Auch in diesen Fällen kann aufgrund der am Server hinterlegten U2F-Anmeldedaten vom jeweiligen Dienstanbieter nicht festgestellt werden, dass es dasselbe U2F-Gerät ist und derselbe oder unterschiedliche Benutzer dieses U2F-Gerät benutzen.

Ermöglicht wird dies dadurch, dass im U2F-Gerät ein (von den Merkmalen des Dienstanbieters wie Serveradresse, TLS-Zertifikat und anderen Daten wie zufällig erzeugten Sitzungsbezeichner (Token) abhängiges) Schlüsselpaar aus einem privaten und öffentlichen Schlüssel individuell erzeugt wird. Der private und öffentliche Schlüssel wird im Rahmen eines asymmetrischen Kryptosystems berechnet. Zur Anmeldung wird im Rahmen des U2F-Verfahrens der so erzeugte öffentliche Schlüssel, gemeinsam mit einer vom U2F-Gerät inhaltlich beliebig gestaltbaren sogenannten Schlüsselkennung (englisch key handle) an den Dienstanbieter übermittelt.

Bei der erstmaligen Anmeldung bei einem Dienstanbieter wird dieses Datenpaar aus öffentlichem Schlüssel und Schlüsselkennung auf dem Server abgelegt. Bei einer nachfolgenden Authentifizierung übermittelt der Server die zu dem Benutzer gehörende Schlüsselkennung samt zusätzlicher Daten wie der Serveradresse, einer einmaligen Sitzungskennung und weiteren Daten. Das U2F-Gerät kann so aus der übermittelten Schlüsselkennung den zugehörigen privaten Schlüssel ermitteln und damit die Daten der Retourantwort zum Server passend signieren. Die signierte Retourantwort wird vom Server gemeinsam mit dem zugeordneten öffentlichen Schlüssel zur Authentifizierung des Kunden verwendet. Dieses Verfahren erlaubt einen gewissen Schutz vor Man-in-the-Middle-Angriffen.^[4]

Die fehlende eindeutige öffentliche Erkennungsmöglichkeit eines U2F-Gerätes steht im Gegensatz zu den klassischen Challenge-Response-Authentifizierungen mit asymmetrischen Schlüsseln, wie beispielsweise der Authentifizierung bei der Secure Shell (SSH) für einen Kommandozeilenzugang. Bei der SSH-Authentifizierung wird der öffentliche Schlüssel nämlich auf allen Servern genau da deponiert, wo auch ein öffentlicher Zugang erlaubt ist. Somit kann man dort auch ohne Kenntnis des geheimen privaten Schlüssels feststellen, auf welchem Server ein Zugang mit diesem SSH-Schlüssel vorliegt, wenn nur ein Zugang zu den öffentlichen Schlüsseldaten besteht.

In nebenstehender Grafik ist der Ablauf einer Authentifizierung bei U2F dargestellt, die initiale Anmeldung bei dem Dienstanbieter ist dabei als bereits erfolgt angenommen.

• Zur Authentifizierung fragt der Dienstanbieter als ersten Faktor nach dem Nutzernamen und bei Bedarf nach dem regulären Passwort, prüft diese Daten, und leitet – falls in Ordnung – den zweiten Faktor in Form von U2F ein:
• Im ersten Schritt schickt der Dienstanbieter ein Datenpaket an den Kundenrechner (Web-Browser). Dieses besteht aus einer Challenge, dies sind einige zufällig gewählte Ziffern. Dazu eine Applikationskennung, im Diagramm als app id bezeichnet und die Schlüsselkennung key handle, welche bei der initialen Anmeldung hinterlegt wurde.
• Der Kundenrechner prüft die Applikationskennung, ergänzt diese um zusätzliche Daten wie beispielsweise eine Kanalkennung (Channel ID) und leitet diese Daten an das U2F-Gerät weiter.
• Das U2F-Gerät ermittelt mit Hilfe der Schlüsselkennung (key handle) den für diese Sitzung passenden privaten Schlüssel k_priv, und signiert mit diesem die Applikationskennung und die Challenge c und bildet so die signierte Antwort s.
• Zusätzlich kann optional ein Zähler (Counter) mit in die signierte Antwort integriert werden, um duplizierte U2F-Geräte erkennen zu können.
• Der Kundenrechner, wie beispielsweise der Web-Browser, leitet diese Daten weiter an den Dienstanbieter, welcher mit dem öffentlichen Sitzungsschlüssel die Signatur s und die darin enthaltenen Daten prüft und – falls in Ordnung – den Zugang gewährt.

Damit das U2F-Gerät eine Antwort liefert, ist es im Standard zwingend vorgeschrieben, dass eine Benutzeraktion direkt am U2F-Gerät nötig ist. Im einfachsten Fall ist nur das Drücken eines Tasters am U2F-Gerät nötig. Es sind aber auch andere Initiierungen möglich: Beispielsweise bietet das Unternehmen EyeLock seit Januar 2015 den Iris-Scanner myris mit USB-Anschluss an, der zum U2F-Protokoll kompatibel ist.^[5] Diese Vorgabe soll die Zustimmung des Benutzers zu einer Authentifizierungsanforderung unabhängig vom PC und dessen Software sicherstellen – erfolgt diese Zustimmung des Benutzers nicht, erfolgt nach einem Zeitablauf auch keine Antwort vom U2F-Gerät. Diese Vorgabe soll verhindern, dass Software am Rechner ohne Wissen des Benutzers Antworten des U2F-Gerätes in großer Anzahl anfordern und in Folge auswerten kann.

Das U2F-Gerät kann als Security-Token in Hardware mit entsprechend sicherem Speicher gestaltet sein, muss aber nicht. Grundsätzlich ist auch eine rein softwarebasierende U2F-Anwendung möglich, dann allerdings mit dem grundsätzlichen Problem, dass geheime Daten wie die eindeutige und intern verwendete U2F-Primärkennung leichter ausgelesen und kompromittiert werden kann.

Um die Kosten für hardwarebasierende U2F-Geräte, wie beispielsweise als USB-Dongle, zu minimieren, ist das Verfahren so ausgelegt, dass im U2F-Gerät keine veränderlichen Daten wie die erzeugten sitzungsbasierten privaten Schlüssel gespeichert werden müssen. Das Verfahren lässt offen, wie und wo die geheimen privaten Schlüsseldaten für einen Dienstanbieter gespeichert werden.

Die Speicherung kann einerseits in einem Speicher am U2F-Gerät erfolgen, was das U2F-Gerät verteuert und die Anzahl der Anmeldungen aufgrund der Speichergröße limitiert. Es ist aber auch möglich, die erzeugten sitzungsbasierten privaten Schlüssel mit einem gerätespezifischen Verfahren zu verschlüsseln und im Rahmen der Schlüsselkennung (Key Handle) mit am Server zu speichern. Denn bei jeder nachfolgenden Anmeldung wird dieses Key Handle vom Server an das U2F-Gerät übermittelt, womit dieses U2F-Gerät seinen privaten Schlüssel wiedergewinnen kann. So kann das U2F-Gerät bei beliebigen vielen Diensten verwendet werden, da auf dem U2F-Gerät keine verbindungsabhängigen Schlüsseldaten gespeichert werden und keine Speicherplatzbeschränkung eine Begrenzung ergibt.

Um verschiedene Typen von U2F-Geräten und deren unterschiedliche Vertrauenswürdigkeit seitens Dienstanbieter unterscheiden zu können (beispielsweise weisen hardwarebasierende U2F-Geräte ein höheres Sicherheitsniveau gegen Auslesen auf als PC-basierende Softwarelösungen), kommt im Rahmen von U2F auch noch eine Signierung der Antwort mit einem herstellerabhängigen privaten Schlüssel hinzu. Der private Schlüssel ist fix im U2F-Gerät gespeichert und ist bei allen U2F-Geräten dieses Herstellers identisch, womit eine Identifizierung eines bestimmten U2F-Gerätes verhindert wird. Der dazu passende öffentliche Schlüssel ist allgemein bekannt und kann Dienstanbietern dazu dienen, für den Zugang die Verwendung bestimmter U2F-Geräte einzufordern.^[3]

Als erster Webbrowser unterstützt Google Chrome seit Oktober 2014 U2F.^[6] Seit Version 57 (Januar 2018) ist U2F auch in Mozilla Firefox integriert.^[7] Apple Safari unterstützt U2F seit Version 13 (September 2019).^[8] Die Funktionalität kann auf der U2F-Testseite von Yubico überprüft werden.^[9]

Diverse Internetdienste unterstützen die Anmeldung mittels U2F, primär aus dem Umfeld von Google wie beispielsweise Gmail, Dropbox, GitHub. Für die Anmeldung an einem Rechner unter Linux und macOS steht ein Pluggable Authentication Module zur Verfügung.^[10][11]

Das Betriebssystem Windows 10 von Microsoft unterstützt die U2F-Funktionen sowohl über Hardware Tokens, als auch über "Windows Hello". Bei "Windows Hello" implementiert die Software die Funktionalitäten des Tokens.^{[12] [13]}

• FIDO-Allianz-Überblick (englisch)
• U2F, Yubico (englisch)
• Erklärungen für Einsteiger zu FIDO1/U2F und FIDO2, FIDO-Allianz (englisch)

1. ↑ FIDO 1.0 Specifications are Published and Final Preparing for Broad Industry Adoption of Strong Authentication in 2015. FIDO-Allianz, 9. Dezember 2014, abgerufen am 11. April 2018. 
2. ↑ FIDO 2.0: Web API for accessing FIDO 2.0 credentials. W3C, 20. November 2015, abgerufen am 12. Dezember 2023. 
3. ↑ ^{a b} U2F Specifications. Abgerufen am 28. November 2016. 
4. ↑ Universal 2nd Factor (U2F) Overview, FIDO-Allianz, 11. April 2017, PDF-Datei, abgerufen am 24. April 2019
5. ↑ EyeLock's myris Is First and Only Iris Authenticator for New FIDO Open Industry Standard, EyeLock, abgerufen am 5. Januar 2015
6. ↑ Google Launches Security Key, World’s First Deployment of Fast Identity Online Universal Second Factor (FIDO U2F) Authentication. Abgerufen am 16. April 2020. , fidoalliance.org, 21. Oktober 2014
7. ↑ Security/CryptoEngineering. Abgerufen am 15. November 2017. 
8. ↑ Safari 13 Release Notes. Abgerufen am 17. Februar 2020. 
9. ↑ Test your U2F device. Abgerufen am 15. November 2017. 
10. ↑ pam-u2f. In: developers.yubico.com. Abgerufen am 25. Mai 2016. 
11. ↑ yubico-pam. In: developers.yubico.com. Abgerufen am 25. Mai 2016. 
12. ↑ FIDO / U2F / Windows Hello msxfaq.de, abgerufen am 28. Juni 2023.
13. ↑ Windows 10 für Unternehmen: Höchste Sicherheit für alle Geräte und Szenarien - Innovative Sicherheit: Zwei-Faktor-Authentifizierung, technet.microsoft.com vom 19. März 2015, abgerufen am 30. November 2016.