U2F / WebAuthn

Einleitung

Durch weitere zunehmende Angriffe auf einfache, passwortgeschütze Dienste im Internet, steigt der Bedarf nach sicheren Erweiterungen für die Authentifizierung der Nuetzer eines Dienstes weiter stetig. Dabei werden gleichermaßen sicherheitskritischere Dienste immer weitere in das Internet verlagert. Beispiele hierfür sind Online-Banking, digitale Behördendienste, aber auch der entfernte Zugriff auf vertrauliche oder geheime Daten mittels virtueller Netzwerke. All diese Dienste erfordern das Vertrauen darin, dass der Nutzer, der den Dienst in Anspruch nimmt, auch der berechtigte Nutzer ist.

Um dies zu gewährleisten gibt es verschiedene Verfahren zur erweiteren Garantie der Nutzer-Identifikation. Dieser zweite Faktor, neben dem Passwort als erstem Faktor, soll garantieren, dass nur der Nutzer, der im Besitz beider Token ist, einen Dienst in Anspruch nehmen kann. WebAuthn ist dabei ein neuer Standard des W3C, der dies allgemein für Webdienste verfügbar machen soll. Der Standard is unabhängig von der genauen Art des zweiten Faktors spezifiziert, gibt dabei aber gewisse Grenzen für dessen Sicherheit vor.

Bisherige 2-Faktor-Systeme

Systeme

Short Message Service (SMS)

Ein beliebert Weg, einen zweiten Faktor einzubauen, ist die Verwendung von SMS. Dabei registriert ein Nutzer seine Telefon-Nummer. An diese wird bei der Registrierung ebenso wie bei jedem Login-Vorgang ein alphanumerischer Code gesendet, den der Nutzer zur Bestätigung der Hoheit über diese Telefon-Nummer auf der Seite des Dienstes eingeben muss. Dieses System ist für verschiedene Angriffe anfällig. Am relevantesten ist dabei die grundsätzliche Angreifbarkeit des Mobilfunk-Standards GSM, wodurch SMS abgefangen werden können.<ref>GSM-Hacken leicht gemacht</ref> Aber auch mangelnde Sicherheitsprüfungen seitens der Mobilfunkanbieter<ref> Online-Banking: Neue Angriffe auf die mTAN </ref> oder die Infizierung des empfangenden Smartphones mit einem Trojaner nehmen diesem Verfahren die Sicherheit.

E-Mail

Vereinzelte Anbieter setzen noch auf die Verwendung von E-Mail als zweiten Faktor. Dabei wird ähnlich wie bei SMS verfahren. An die hinterlegte E-Mail wird ein Code gesendet, den der Nutzer beim Einloggen zusätzlich eingeben muss. Die Probleme sind dabei auch im Grunde die selben, wie bei der SMS. Durch die in der Regel unverschlüsselte Verwendung von E-Mail-Diensten, ist eine Integrität nicht gewährleistet. Darüber hinaus ist die E-Mail als zweiter Faktor nur so sicher wie das E-Mail-Konto selbst. Kann dieses einfacher kompromitiert werden, bietet das Verfahren keinerlei zusätzliche Sicherheit, abgesehen von einem zweiten zu überwindenden Passwort. Häufig ist aber nicht mal dass der Fall und es werden gleiche Passwörter für E-Mail und andere Dienste verwendet.

Time-based One Time Password (TOTP)

TOTP ist von der OATH entwickelter Standard, der in RFC 6238 spezifiziert ist. Eine der bekanntesten Implementierungen ist der Google Authenticator. Dabei wird einmal ein geheimer Schlüssel zwischen Dienst und dem zweiten Faktor ausgetausch. Der zweite Faktor ist überlichweise ein Smartphone mit einer entsprechenden App. Der austausch des geheimen Schlüssel findet meistens visuell in Form eines QR-Code statt, welcher vom Smartphone eingelesen und verarbeitet wird. Ein Schlüssel zum Einloggen wird dann durch einen Hash über die gerundete aktuelle Uhrzeit gebildet. Dies gewährleistet, dass Passwörter des zweiten Faktors nur eine begrenzte Gültigkeit besitzen. Eine Gefahr der Kompromittierung besteht bei diesem System hauptsächlich während der Übertragung des geheimen Schlüssels. Um eine sichere Verwendung des systems zu garantieren, muss die Übertragung unter absoluter Privatsphäre stattfinden. Andernfalls könnte ein Angreifer den geheimen Schlüssel ausspähen und zukünftig selbst Einmal-Passwörter berechnen.

Grundlegende Probleme

Allen Systemen gemein ist die Angreifbarkeit des zweiten Faktors durch einfache Methoden. Häufig kommt ein Smartphone als zweiter Faktor zum Einsatz. Dieses lässt sich heutzutage genau so simpel kompromittieren wie ein Windows-PC. Durch die enorme Verbreitung und teils haarsträubende Update-Politik sind die Möglichkeiten für Angreifer hier sogar unter Umständen noch umfangreicher. Das Smartphone alleine kann also nur schwer als sicherer, zweiter Faktor angesehen werden. Nötig wäre stattdessen kryptographisch abgesicherte Hardware, die ein Zugriff auf die geheimen Schlüssel gar nicht erst erlaubt. Dies soll durch die U2F-Standard ermöglicht werden.

U2F

Universal Secondary Factor (U2F) ist der Name eines Standards der FIDO Alliance, einer Industrie-Vereinigung ähnlich der OATH, die sich dem Absichern des Nutzer-Logins verschrieben hat. Sie definiert dazu den Standard U2F, welcher neben der sicheren Hardware und der Kommunikation mit dieser Hardware, auch den softwareseitigen Zugriff zur Interaktion mit einem solchen zweiten Faktor zur ermöglichen.<ref>FIDO U2F Specifications</ref> Das Signatur-Verfahren von U2F ist festgelegt auf ECDSA mit SHA-256 und der NIST-Kurve P-256.

Hardware

U2F-Keys sind heutzutage in der Regel kleine USB-Geräte, die im Sinne eines echten Schlüssels für den Schlüsselring vorgesehen sind. Dabei gilt der Besitzer des U2F-Keys als der berechtigte Nutzer. Ein Abhandenkommen des U2F-Keys sollte also tunlichst vermieden werden. Darüber hinaus gibt es verschiedene Bauformen und Technologien, die für ein U2F-Token verwendet werden können. Beispiele sind:

• USB (USB-A, Mikro-USB, USB-C)<ref>FIDO U2F HID Protocol Specification</ref>
• NFC<ref>FIDO NFC Protocol Specification v1.0</ref>
• Bluetooth<ref>FIDO Bluetooth® Specification v1.0</ref>
• Smartcard
• Smartphone, kombiniert mit einem Secure Storage und einer Trusted Zone zur Signaturberechnung

Allen U2F-Keys ist gemein, dass sie zum Ausführen einer Aktion immer eine Nutzerinteraktion fordern. In der Regel ist dies ein einfaches Berühren oder Drücken eines Tasters. Dies garantiert, dass der Key nicht per Software in einer Art Brute-Force-Angriff missbraucht werden kann. Mit dem weiterführenden Standard UAF (Universal Authentification Framework) wird diese Nutzerinteraktion weitergeführt. Hierbei werden dann ggf. biometrische Merkmale, etwa der Fingerabdruck oder das Iris-Muster, ermittelt, verglichen und davon abgeleitet eine erfolgreiche oder misslungene Aktion bewertet.

Software

U2F beschreibt eine simple Schnittstelle für Anwendungsentwickler in JavaScript.<ref>FIDO U2F JavaScript API</ref> Dies zielt auch auf den bevorzugten Einsatzkontext ab, den Login-Vorgang bei Web-Diensten im Browser. Dabei werden zwei verschiedene Schnittstellen definiert, die beide auf das Messaging API des W3C aufbauen. Der Browser stellt dabei eine Schnittstelle zum U2F-Key bereit, über die Daten ausgetauscht werden können. Der Austausch beschränkt sich dabei auf das Anfordern zweier Aktionen:

• Registrieren - Gleichbedeutend mit dem Anlegen eines neuen Schlüsselpaares. Dabei wird ein Dienst registriert und erhält vom U2F-Key einen Bezeichner für den Schlüssel sowie den zugehörigen öffentlichen Schlüssel
• Signieren - Dabei gibt der Dienst einen Wert vor, die sogenannte Challenge, welche vom U2F-Key signiert werden muss. Das Resultat dieser Signieroperation kann vom Dienst mit Hilfe des während der Registrierung erhaltenen öffentlichen Schlüssels überprüft werden. Ist die Signatur gültig, kann davon ausgegangen werden, dass der Nutzer den U2F-Key besitzt

Der U2F-Standard beschreibt weiterhin die verschiedenen Anbindungen eines U2F-Keys. Standardisiert sind bisher die Übertragungswege per USB, NFC und Bluetooth. Des Weiteren werden verschiedene Nachrichtenstrukturen bis auf Binärebene definiert. Diese ermöglichen eine Standardisierte Kommunikation zwischen Client und U2F-Key. Der Client ist überlicherweise ein Web-Browser, was aber nicht zwingen erforderlich ist.

WebAuthn

WebAuthn ist ein sich in Entwicklung befindender Standard des W3C.<ref>Web Authentication: An API for accessing Public Key Credentials Level 1</ref> Dieser kann als eine Verallgemeinerung des U2F-Standards angesehen werden. Während U2F beispielsweise zwingen eine Signatur nach ECDSA mit SHA-256 und der Kurve P-256 fordert, ist die Wahl des Signatur-Algorithmus in WebAuthn variabler. Ansonsten folgt WebAuthn konzeptuell stark dem U2F-Standard und bezieht sich sich in Teilen auch auf diesen. WebAuthn ist aber auch durch die Möglichkeit von Erweiterungen sehr allgemein gehalten. Ebenso wie in U2F ist der Standard nicht von Vornherei auf USB-Keys beschränkt, sondern lässt die Anbindung offen. Da es sich bei WebAuthn im Gegensatz zu U2F aber um die Spezifikation einer Schnittstelle explizit für JavaScript handelt, sind darüber hinausgehende Aspekte nicht Teil von WebAuthn. U2F geht hier in Teilen weiter und spezifiziert auch Formate für den Austausch über Bluetooth oder NFC. Keys über diese Anbindungen könnten dann wiederum von einem Browser per WebAuthn ansprechbar gemacht werden.

Sicherheit

Privatsphäre

Eines der Design-Ziele von U2F ist die Privatsphäre der Nutzer zu schützen. Durch den Entwurf des Protokolls ist es nicht möglich, die Privatsphäre der Nutzer zu kompromittieren. Dies wird gewährleistet, indem ein U2F-Key für einen Dienst nicht eindeutig Addressierbar ist. Der U2F-Key teilt dem Dienst keine eindeutige Kennung mit. es wird nur die Kennung für einen gespeicherten Schlüssel übermittelt. Diese Kennung ist auch nur für diesen einen Dienst gültig. So können zwei Dienste nicht ihre Datenbestände abgleichen und feststellen, ob verschiedene Nutzer den selben U2F-Key verwenden und damit wahrscheinlich die selbe Person sind.

ROCA

Die »Rückkehr der Coppersmith-Attacke« (engl. Return of the Coppersmith Attack) betrifft nicht U2F als solches. ROCA, bzw. CVE-2017-15361, bezeichnet eine Schwachstelle in einer von Infineon entwickelten Bibliothek, welche dazu führt, dass all von dieser Bibliothek generieten RSA-Schlüssel schwächer sind, als zu erwarten.<ref>CVE-2017-15361</ref><ref>Background Information on software update of RSA key generation function</ref> Aktuelle U2F-Implementierungen verwenden jedoch nicht das RSA-Verfahren, sondern elliptische Kurven.

Das Problem ist im Kontext von U2F aber trotzdem relevant, da viele von Yubico verkauften U2F-Keys nicht nur U2F unterstützen, sondern darüber hinaus auch weitere Krypto-Dienste anbieten. Einer ist etwa das Generieren von PGP-Schlüssel mit dem RSA-Verfahren. Dadurch, dass Yubico-Keys recht verbreitet sind, betrifft dieses Problem auch viele U2F-Keys.<ref> Hunderttausende Infineon-Sicherheits-Chips weisen RSA-Schwachstelle auf</ref><ref>RSA-Sicherheitslücke: Infineon erzeugt Millionen unsicherer Krypto-Schlüssel</ref> Füe per U2F abgesicherte Login-Vorgänge bedeutet ROCA aber keinen Sicherheitsverlust, da ROCA nur für das RSA-Verfahren relevant ist. Da die erweiterten DIenste der Yubico-Keys trotzdem bedeutende Relevanz besitzen, bietet Yubico für betroffene Nutzer einen Austausch der Keys an.<ref>Infineon RSA Key Generation Issue</ref>

U2F im Web

Vebreitet ist U2F derzeit nur bei Webdiensten. Die dafür notwendige Unterstützung in verbreiteten Browsern ist aber noch nicht vollständig gegeben. Daher gestaltet sich die Verwendung von U2F-Token derzeit noch etwas holprig.

Browser-Support

Browser	WebAuthn	U2F High Level	U2F Message Port
Firefox 56	Nein	Plugin	?
Firefox 57 (Dev)	Ja	Ja	?
Chrome 62	Nein	Nein	Ja
Edge	Nein	Nein	Nein

Beim Browser-Support ist anzumerken, dass die Tabelle nur für die Schnittstelle gilt, die für eine Webseite verwendbar ist. Während der Untersuchung hat sich gezeigt, dass insbesonders Firefox Probleme mit U2F-Keys von Yubico hat. Diese werden von Firefox nicht erkannt. Mit einem deutlich günstigeren U2F-Key von Key-ID war ein Zugriff aber problemlos möglich. Vermutlich liegt dies an der unterschiedlichen Art, wie sich die Sticks dem System präsentieren. Der Key-ID-Key war standardkonform als USB-HID-Gerät anzusprechen, während sich der Yubico-Key als ein Gnubby-Gerät präsentiert. Anscheinend hält sich Firefox hier streng an den Standard. Dagegen hatte Chrome keinerlei Probleme, verschiende U2F-Keys anzusprechen. Die Implementierung in Chrome basiert aber noch immer auf einem Chrome-Plugin. Dies ist auch in der Art der Programmierung auf Seiten des Dienstes sichtbar. Chrome stellt nur einen sogenannten Message Port zur Kommunikation mit dem U2F-Key bereit. Dies entspricht zwar dem U2F-Standard, ist aber nicht so komfortable verwendbar wie das High-Level-API oder gar WebAuthn. Edge, der Standard-Browser in Windows von Microsoft, unterstützt hingegen keine der Schnittstellen.

Dienst-Support

Auf Seiten der Dienst-Anbieter ist die Unterstützung von U2F derzeit noch nicht sehr verbreitet, wobei gerade große Anbieter hier hervorstechen und U2F in ihren Diensten anbieten. Alleind adurch dürfte die Anzahl der absicherbaren Dienste trotzdem recht hoch sein. Beispiele, die erfolgreich getestet wurden, sind Google, Facebook, GitHub und Dropbox. Einen Überblick über die Verbreitung von U2F bietet Dongleauth. Neben der Unterstützung von OTP, wird hier auch die Unterstützung von U2F bei verschiendenen Diensten angegeben.

U2F in anderen Umgebungen

U2F ist nicht auf die Verwendung im Browser beschränkt. Ein U2F-Key kann von allen möglichen Anwendungen angesprochen werden. Dies können zum Beispiel viele andere Dienste sein, die sich auf einen sicheren Nutzerlogin verlassen müssen.

Linux / UNIX PAM

Im UNIX-Umfeld ermöglich ein PAM, ein Pluggable Authentification Module, eine Erweiterung des Login-Vorgang des Betriebssystems. Die Softwarekomponente regelt dazu selbst, wie sie den Login handhabt. Üblich hier sind der klassische Login per Passwort oder auch per Smartcard. Für das Unix-Umfeld existiert eine Implementierung von Yubico.<ref>Yubico PAM</ref> Durch die Einbindung des PAM-Konzepts in viele andere UNIX-Dienste, ermöglicht dies auch den Login bei Diensten wie OpenVPN oder SSH. Ob dies nur mit U2F-Keys von Yubico oder allgemein mit Keys nach U2F-Standard funktioniert, wurde im Rahmen dieser Arbeit nicht getestet.

Windows Hello

Mit Windows 10 wurde der Dienst Windows Hello eingeführt. Dieser ermöglich ein Einloggen über verschiedene Merkmale, etwa eine PIN oder ein biometrisches Merkmal. Ebenfalls von Yubico existiert eine Windows App, die es erlaubt, einen U2F-Token als Login-Merkmal in Windows Hello zu verwenden.<ref>YubiKey works with Windows Hello</ref><ref>How to use your YubiKey with the YubiKey for Windows Hello app</ref> Nach ausführlichen Tests wurde jedoch festgestellt, dass dieses Feature ausschließlich mit U2F-Keys der aktuelleren Generation des Herstellers Yubico funktioniert. Ein ebenfalls dem U2F-Standard folgender Key von Key-ID konnte nicht dazu gebracht werden, einen Login per Windows Hello zu ermöglichen. Es scheint, dass die Implementierung nicht allein auf dem U2F-Standard basiert und Erweiterungen seitens Yubico verlangt.

OpenSSH

Für OpenSSH existiert ein Patch, der ein Login per U2F-Key ermöglicht.<ref>OpenSSH: 2319 - [PATCH REVIEW] U2F authentication</ref> Problematisch ist hier, dass dieses Feature noch nicht in den Code von OpenSSH integriert wurde. Für U2F-Support in OpenSSH muss ein Anwender also wohl den Server als auch den Client selbst kompilieren. Man kann hier also noch nicht von einer vorhandenen unterstützung sprechen, da diese nicht verbreitet im Einsatz ist. Zur eigenen verwendung lässt sich aber mit dem Patch eine Version von OpenSSH kompilieren, die U2F unterstützt.