Authentifizierungsmechanismen des Yubikeys erklärt

Je nach Modell beherrschen die Yubikeys der Firma Yubico verschiedene Authentifizierungsverfahren. Nach dem ich mir einen Yubikey Neo zugelegt hatte, fiel es mir schwer, zwischen den Betriebsmodi zu unterscheiden. Mit diesem Beitrag will ich neuen Usern einen Überblick über die möglichen Authentifizierungsverfahren geben, sie erklären und die Vor- und Nachteile nennen.

Vorgestellt werden hier die folgenden Yubikey-Modi:

• HOTP
• TOTP
• Challenge-Response via HID
• Yubico OTP
• U2F

HOTP

HOPT steht für „HMAC-based one time password“.

Funktionsweise

Um zu verstehen, wie das HOTP-Verfahren funktioniert, ist es zunächst wichtig zu wissen, was ein HMAC ist. HMAC steht für „Keyed-Hash Message Authentication Code“ und bezeichnet einen Hashwert, der über eine kryptographische Hashfunktion wie z.B. MD5 oder SHA1, von einem Secret Key und einer Nachricht abgeleitet wurde. Mit einem HMAC kann der Empfänger einer Nachricht sowohl Integrität als auch Authentizität der erhaltenen Nachricht überprüfen. Integrität bedeutet, dass der Inhalt der Nachricht auf dem Transportweg nicht verändert wurde; Authentizität bedeutet, dass der Empfänger die Nachricht von der richtigen Person / Personengruppe erhalten hat. Damit ein so abgesicherter Datenaustausch stattfinden kann, müssen sich Sender und Empfänger zuvor auf einen gemeinsamen, geheimen Schlüssel einigen (shared secret). Der Absender schickt seine Nachrichten dann mit einem HMAC , der aus seiner Nachricht und dem Key generiert wurde. Der Empfänger kann nun Integrität und Authentizität überprüfen, indem er auf die empfangene Nachricht zusammen mit seinem Key ebenfalls einen HMAC-Generator anwendet und die HMACs überprüft: Stimmen die MACs überein, wurde die Nachricht nicht manipuliert und kommt von einem Absender, der den Key kennt. Es ist also davon auszugehen, dass die Nachricht vom richtigen stammt. Ein Angreifer kann gültige Nachrichten nicht ändern oder eigene im Namen anderer Verfassen, wenn er den Key nicht kennt. Verwendet er einen anderen Key, ergibt sich ein anderer HMAC. Der Key kann nicht aus dem HMAC rekonstruiert werden. Die einzig verbleibende Möglichkeit wäre, alle möglichen Keys auszuprobieren, und zu sehen, mit welchem sich ein korrekter HMAC ergibt. Das ist allerdings sehr, sehr rechen-aufwendig.

Das HOTP-Verfahren basiert auf HMACs, wobei die „Nachrichten“ hierbei OTPs (One time passwords – Einmalpasswörter)  in Form von Zählerwerten sind.

Client (der Yubikey) und Server (der Server, an dem sich der User anmelden will) müssen sich wie beim normalen HMAC-Verfahren zuerst auf ein gemeinsames Geheimnis einigen. Bei der Aktivierung der HOTP-Authentifizierung generiert der Server einen zufälligen Secret Key, welcher dem Benutzer angezeigt wird. Der Benutzer richtet seinen Yubikey nun so ein, dass dieser den Key kennt und in seinem Speicher ablegen kann. Neben dem Key müssen beide Parteien über einen Zähler verfügen, dessen Werte gewissermaßen die Einmalpasswörter sind. Die Zähler von Client und Server sollten dabei synchron sein. Nach jedem Anmeldeversuch wird der Zähler auf beiden Seiten um eins erhöht.

Sobald der Benutzer einen Anmeldeversuch startet, generiert der Yubikey intern aus Zählerstand (=> „Nachricht“) und dem geheimen Key einen HMAC. Der HMAC wird dann zuerst in eine kürzere, benutzerfreundlichere Zahlenfolge konvertiert und via Tastatur-Simulation direkt am Rechner „eingetippt“. Sobald der Benutzer die Anmeldedaten über das Anmeldeformular an den Server übermittelt hat, beginnt der Server, dieselbe Operation auszuführen: Sein Zählerstand und der Key werden zu einer HMAC verrechnet, die wiederum zu einer Zahlenfolge umgewandelt wird. Stimmen die gesendete und die empfangene und die selbst errechnete Zahlenfolge überein, verfügen beide Parteien offenbar über denselben Zählerstand und denselben Key – der Benutzer ist authentifiziert. Wie bereits erwähnt, erhöhen beide Seiten nach einem Login-Versuch ihre Zähler – egal, ob der Versuch erfolgreich war, oder nicht. Nachdem der Zähler geändert wurde, wird auch der nächste HMAC ein anderer sein – wie er aussieht, ist ohne Kenntnis des Keys nicht vorhersagbar.

Vielleicht ist euch an dieser Stelle schon ein mögliches Problem in den Sinn gekommen: Was ist, wenn jemand über den Yubikey einen Anmeldeversuch startet, der Server davon aber nichts mitbekommt? Der Zähler am Yubikey wäre dann um 1 höher, als der Zählerstand am Server und der nächste Authentifizierungsversuch muss scheitern. Für dieses Praktische Problem gibt es eine relativ einfache Lösung: Der Server wird nicht nur für seinen aktuellen Zählerstand den Zahlencode generieren, sondern beispielsweise auch für den vorherigen und den nächsten Zählerstand. Stimmt der vom Client übermittelte Code mit einem dieser selbst errechneten Codec überein, zählt das als erfolgreiche Authentifizierung. Danach kann der Server auf den aktuellen Zählerstand am Client rückschließen und seinen eigenen Zähler dem anpassen. Auf diese Weise gewinnt man einen gewissen Toleranzbereich, innerhalb dessen eine Authentifizierung noch möglich ist. Freilich hat jeder Server festgelegte Grenzen, sodass man nicht unnötig auf seinem angeschlossenen Yubikey herumdrücken sollte, ohne einen ernsthaften Anmeldeversuch unternehmen zu wollen. ;) Falls sich der Yubikey-Zähler nicht mehr innerhalb des Toleranzbereichs des Servers befindet, ist eine Authentifizierung unmöglich und es muss auf ein Backup-Anmeldeverfahren zurückgegriffen werden. Yubikey und Server können dann neu eingerichtet und synchronisiert werden.

Vorteile:

• Einfaches Verfahren
• Weite Verbreitung
• Zeit-unabhängig
• Keine dauerhafte Energieversorgung des Clients notwendig
• Yubikey kann als simulierte Tastatur HOTP Code direkt eintippen

Nachteile:

• Ggf. zu große Zählerabweichung bei unsachgemäßer Nutzung, => keine Anmeldung mehr möglich
• Nur Nutzung mit einem einzigen Account möglich

TOTP

TOTP steht für „Time-based one time password“ und funktioniert analog zu HOTP, nur, dass keine Zähler verwendet werden, sondern zeitabhängige Zahlenwerte.

Funktionsweise

Wie beim HOTP-Verfahren wird ein gemeinsames Secret (Key) zwischen Client und Server vereinbart. Außerdem müssen beide Parteien eine übereinstimmende Zeit-Schrittweite X nutzen. Der Zahlenwert, der den Zähler aus dem HOTP-Verfahren ersetzt, wird standardmäßig berechnet aus der aktuellen UNIX-Zeit geteilt durch die Zeit-Schrittweite X. Letztendlich gibt der Zahlenwert also an, wie oft eine Zeit der Länge X seit dem 1.1.1970 UTC bereits vergangen ist. Der Zahlenwert wird wie bei HOTP mit dem Key kombiniert, eine kryptographische Hash-Funktion darauf angewendet und das Ergebnis in eine einfach lesbare Ziffernfolge umgewandelt. Bei einem Anmeldeversuch berechnet der Server ebenfalls eine solche Ziffernfolge basierend auf seiner eigenen Systemzeit und dem Key. Stimmen die Ziffernfolgen überein, gilt der Benutzer als authentifiziert.

Durch die Schrittweite X wird, definiert, wie lange jedes der generierten Einmalpasswörter in Form der Ziffernfolge gültig bleibt. Üblich sind hier 30 Sekunden, sodass der Benutzer die Ziffernfolge eingeben kann, bevor eine andere Folge gültig ist. Ähnlich wie bei HOTP kann auch bei diesem Verfahren eine Abweichung zu einer unmöglichen Authentifizierung führen: Wenn die Uhren in Client und Server nicht synchron laufen, wird eine Seite gerade eine Ziffernfolge generieren, die für die andere Seite schon lange ungültig oder noch nicht gültig ist. Die Kommunikationspartner würden „aneinander vorbeireden“. Um trotz einer gewissen Uhren-Abweichung eine Authentifizierung zu ermöglichen, vergleicht der Server in der Praxis nicht nur mit den Ziffernfolgen der aktuellen Systemzeit, sondern auch mit allen möglichen Ziffernfolgen aus einem fest definierten Toleranz-Zeitraums. Theoretisch wäre auch an dieser Stelle eine automatische Angleichung der Serverzeit an die Zeit des Clients möglich, sodass die Uhren zwar nicht zwangsläufig richtig, aber dafür einigermaßen synchron laufen.

Vorteile

• Weite Verbreitung
• Zu große Uhrenabweichung unwahrscheinlich, weniger Risiko bei unsachgemäßer Nutzung

Nachteile

• Der Key benötigt die aktuelle UNIX-Zeit
• … und daher i.d.R. eine Stromversorgung in Form einer Batterie (=> Wartungsaufwand, Produktionskosten, Baugröße?)

Wichtig: Der Yubikey beherrscht mangels eigener Stromversorgungdas TOTP-Verfahren nicht eigenständig. Zur Nutzung ist immer ein zweites Programm nötig, das dem Yubikey die aktuelle Systemzeit mitteilt und den vom Yubikey generierten Code entgegennimmt und anzeigt. Die Berechnung des Passworts findet auf dem Yubikey selbst statt. Für Android kann über NFC der „Yubico Authenticator“ genutzt werden. Für Windows, Linux und MacOS gibt es ebenfalls passende Software: https://developers.yubico.com/OATH/YubiKey_OATH_software.html

Yubico OTP

Yubico OTPs funktionieren nur im Zusammenspiel mit den Yubico-eigenen Authentifizierungsservern. Jeder Yubikey enthält ab Werk bereits einen einzigartigen, geheimen Schlüssel, über den auf Knopfdruck dynamisch Passwörter generiert werden können. Im Grunde funktioniert dieser Mechanismus ähnlich wie HOTP: Ein Zähler im Yubikey und auf den Yubikey-Servern wird bei jedem Login inkrementiert. Beide Seiten berechnen einen Soll-Schlüssel und vergleichen diesen miteinander. Der Hauptunterschied: Der Key ist fest eingebrannt, kann nicht ausgetauscht werden und eine Authentifizierung ist nur gegenüber Yubikey-Servern möglich. Dazu kommt noch eine Komfortfunktion: Der Yubikey tippt das Passwort selbstständig ein.

Yubico stellt eine API bereit, über die die Authentifizierungsserver durch verschiedene Fremdanwendugen genutzt werden können. Eine Fremdanwendung leitet das vom Yubikey empfangene OTP an die Yubico-Server weiter und erhält Rückmeldung, ob der Login gültig ist oder nicht.

Vorteile:

• Einfache Überprüfung der Anmeldung über die von Yubico bereitgestellte API

Nachteile:

• Abhängigkeit von Yubico-Servern

Challenge-Response via HID

Der Challenge-Response-Modus ist vor allem für Anwendungen gedacht, bei denen der Yubikey ständig überprüft und auf eine Benutzerinteraktion verzichtet werden soll (beispielsweise im Bereich der Anwendungslizensierung – nur bei angestecktem Yubikey ist ein Programm benutzbar). Programme können über die HID-Schnittstelle des Betriebssystems selbstständig mit dem Yubikey kommunizieren. Der Challenge-Response Modus belegt einen sog. „Slot“ des Yubikeys (2. Slot empfohlen) und muss ggf. im Yubikey Personalization Tool erst aktiviert werden. Bei der Einrichtung kann entweder der Yubico OTP Challenge-Response Modus gewählt werden (nur in Verbindung mit speziellen Tools und den Yubico Cloud Servern) oder der universell einsetzbare HMAC-SHA1 Modus.

Funktionsweise (HMAC-SHA1-Modus)

Die grundsätzliche Funktionsweise des HMAC-Verfahrens wurde oben bereits erklärt. Wie auch bei HOTP und TOTP werden im Challenge-Response-Modus (CR-Modus) eine Nachricht (Challenge) und ein Secret Key miteinander kombiniert und durch eine Hashfunktion (in diesem Fall SHA1) verarbeitet. Ergebnis (Response) ist ein kryptographischer SHA1-Hash, der nur auf Basis des korrekten Keys mit der Nachricht erzeugt werden konnte. Ich will die Funktionsweise des Yubico-PAM Moduls für Linux und Mac an dieser Stelle kurz erklären, denn dieses kann auch ohne Yubikey-Server und mit dem HMAC-SHA1-Verfahren im Challenge-Response Modus genutzt werden. Eine Anleitung für (Arch) Linux könnt ihr hier finden: Mit Yubikey unter Arch Linux einloggen.

Wenn ihr der Anleitung folgt, kommt ihr an die Stelle, an der dem Yubikey-PAM mitgeteilt wird, welcher Yubikey zugriffsberechtigt ist. Dafür reicht ein eingesteckter Yubikey und folgende Befehlszeile aus:

ykpamcfg -2 -v

(-2 steht für „zweiten Slot benutzen“ und -v für „verbose“, also eine ausführliche Protokollausgabe)

Im Hintergrund läuft dabei folgendes ab: Der Computer generiert eine zufällige Zeichenfolge (Challenge), die er über das HID-Interface direkt an den Yubikey sendet. Dieser „verhasht“ die Zeichenfolge mit seinem intern gespeicherten Secret Key und gibt das Ergebnis zurück. Die Challenge und die Response des Yubikeys darauf werden vom PAM nun in eine Datei geschrieben – die „Initial Challenge“ ist angelegt.

Beim ersten Authentifizierungsversuch schickt der Computer erneut die Challenge an den Key, auf die er mittlerweile schon die korrekte Antwort kennt. Gibt ihm der Key wieder dieselbe Response zurück, ist offenbar ein Key am Rechner angesteckt, der dasselbe Secret kennt, wie der Key, der angesteckt war, als die Initial Challenge generiert wurde. Es muss sich um denselben Key handeln. Das heißt: Zugang wird gewährt. Direkt danach generiert der Computer erneut eine zufällige Challenge, fragt den Key nach seiner individuellen Antwort und speichert Challenge und Response wieder in der Datei ab. Beim nächsten Authentifizierungsversuch wiederholt sich der Ablauf: Der Computer fragt den angeschlossenen Key wiederholt nach der Challenge, auf die er inzwischen die korrekte Antwort kennt, usw.

Wie euch vielleicht auffällt, wurde niemals ein Secret zwischen Computer und Yubikey vereinbart. Der Computer kennt gar kein Secret. Das muss er auch nicht, denn er braucht keine eigenen Hashes zu erzeugen: Er fragt nach erfolgreicher Authentifizierung einfach den Yubikey, wie die nächste Antwort auf seine neue Challenge lauten muss, damit er den Zugriff auf den Rechner freigibt. Beim nächsten Anmeldeversuch muss genau diese Antwort erneut vom Yubikey gegeben werden, sonst gilt der Anmeldeversuch als gescheitert. Ein Vorteil ist, dass nur ein einziger Key gespeichert werden muss, der völlig beliebig und nicht von einem Partner abhängig ist. So kann man sich mit einem Key im CR-Modus an vielen verschiedenen Rechnern anmelden.

Übrigens: Eigentlich handelt es sich auch bei TOTP und HOTP um Challenge-Response-Verfahren, allerdings versteht Yubico unter diesem Begriff speziell den Modus ohne Benutzerinteraktion über eine Betriebssystemschnittstelle.

U2F

U2F steht für „Universal 2nd factor“ und wurde von der FIDO Allianz 2014 verabschiedet. U2F ist also sehr neu, noch wenig unterstützt, aber umso genialer und immer mehr im kommen. Unterstützt wird das neue Authentifizierungsverfahren bereits von Google, GitHub und Dropbox. U2F ist für die Anmeldung bei Webdiensten über den Webbrowser konzipiert. Der Webbrowser muss U2F aktiv unterstützen. Leider hat bisher nur Google Chrome / Chromium native Unterstützung dafür. Für Firefox lässt sich U2F Support über ein Addon nachrüsten. Auch im Hause Microsoft ist man gerade dabei, am Internet Explorer U2F-Support nachzurüsten.

Prinzipiell ist U2F ein erweitertes Challenge-Response Verfahren, welches u.A. folgendes ermöglicht:

• Für jede Anwendung kann ein eigenes Secret registriert und genutzt werden
• Das Secret wird direkt auf dem Yubikey generiert und kann diesen nicht verlassen. Dem Authentifizierungsdienst wird nur ein Public Key mitgeteilt, über den eine Anmeldung auf Gültigkeit geprüft werden kann
• Optional fließt eine TLS Connection ID mit in die Challenge ein, sodass MITM (Man in the middle) -Attacken verhindert werden können
• Die URL des genutzten Webdienstes wird in die Challenge aufgenommen, um Phishingattacken zu verhindern

Wer sich mit den Details zu U2F befassen möchte, dem sei dieser Artikel empfohlen: https://developers.yubico.com/U2F/Protocol_details/Overview.html

Vorteile:

• Secret wird individuell für jede Anwendung auf dem Yubikey generiert
• Unterstützung von mehreren Onlineaccounts
• MITM- und Phishingresistent
• Bequeme Handhabung

Nachteile:

• Noch geringe Unterstützung durch Webdienste