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.

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)
• NFC
• Bluetooth
• 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. 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 den 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.

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.