Universal 2nd Factor ist ein von der FIDO Alliance spezifiziertes Protokoll, bei dem die Anmeldung an einer Webseite um einen zweiten Faktor — konkret einen Hardware-Besitz — ergänzt wird.
Die FIDO Alliance
In der FIDO Alliance engagieren sich große Player mit einer großen Benutzeranzahl wie Google und Paypal und klassische Hardwarehersteller wir RSA, Gemalto, Feitian und Yubico. Die Masse der Benutzer bei Google und Paypal sind überwiegend denzentrale, nicht organisierte Endanwender.
Das U2F Protokoll
Yubico U2F Yubiky
Die Idee bei U2F ist, dass ein Benutzer lediglich ein Hardware-Gerät hat, mit dem er sich ausweisen kann. Dazu registriert er dieses Gerät an den Webdiensten und Portalen, die das U2F Protokoll unterstützen. Das besondere hierbei ist, dass die einzelnen Webdienste nichts voneinander wissen. D.h. der Webdienst B weiß nicht, dass das gleiche Gerät bei Webdienst A registriert wurde. Dies soll die Anonymität des Endanwenders sicherstellen und die komplette Unabhängigkeit zwichen den einzelnen Webdiensten gewährleisten.
U2F ist also ein Protokoll für eine denzentrale Authentifizierung von Endanwendern.
Die Registrierung und Authentifizierung
Um dies zu ermöglichen, muss der Benutzer an jedem Webdienst, das Gerät registrieren. Dabei wird ein asymmetrisches Schlüsselpaar erzeugt. Der öffentliche Schlüssel wird mit weiteren Meta-Informationen bei dem Webdienst gespeichert.
Wenn nun der Benutzer sich später an dem Webdienst authentisieren möchte, kann der Webdienst eine Challenge zusammen mit den Metainformationen an das U2F-Device senden. Die Authentifizierung erfolgt als Challenge-Response-Verfahren mit dem asymmetrischen Schlüsselmaterial.
Wieviele Schlüsselpaare passen auf den Yubikey?
Unendlich viele. Wenn der Yubikey bei der Registrierung das Schlüsselpaar erzeugt, speichert er den privaten Schlüssel nicht ab. Sondern er generiert das Schlüsselpaar aus einem Masterkey, der fest auf dem Yubikey gespeichert ist.
In die Generierung fließen außerdem die Metainformationen mit ein. Allem voran die sogenannte AppId, die im wesentlichen der URL des Webdienstes entspricht. Hierzu später mehr.
D.h. wenn der Webdienst die Challenge und die Metainformationen an das U2F-Device sendet, kann der Yubikey daraus mit dem fest gespeicherten Masterkey wiederum den speziellen, privaten Schlüssel für diesen Webdienst berechnen und die Challenge korrekt beantworten.
U2F im Unterschied zu klassischen 2FA
OTP Authentifizierung
Die Authentifizierung mit Einmalpasswörtern setzt auf symmetrische Kryptographie. Außerdem wird für die Authentifizierung mit Einmalpasswörtern ein Backend benötigt, das den gemeinsamen, symmetrischen Schlüssel kennt. Will man sich mit Einmalpasswörtern an mehreren Webdiensten anmelden, so benötigt man entweder eine zentrale Authentifizierungsinstanz, die die symmtrischen Schlüssel kennt, oder man benötigt für jeden Webdienst ein eigenen OTP-Token.
Eine Weile sind verschiedene Anbieter den zweiten Ansatz gefahren. Bei allen möglichen Webdiensten konnte man sich einen Google Authenticator — speziell bei diesem Webdienst — ausrollen. Die Google Authenticator App quillt über mit Profilen unterschiedlicher Webdienste. Der Benutzer muss in der langen Liste der Profile, jeweils im richtigen Moment das richtige finden.
Mit einem U2F-Token ist das nicht nötig. Der Benutzer hat nur ein Gerät und wo er sich mit diesem Gerät überall registriert hat, ist im Endeffekt egal. Die Anzahl der registrierten Webdienste beeinträchtigt die Usability nicht.
Authentifizierung mit Smartcard
Eine Authentifizierung mit einer Smartcard arbeitet genau wie U2F mit einem asymmetrischen Schlüsselpaar. Der große Nachteil der Smartcard ist aber die Notwendigkeit eines Treibers. Nicht zuletzt ist das ein entscheidender Grund, weshalb in den vergangenen Jahren OTP ein solches Revival erlebt hat. Gerade im B2C bzw. Endanwender-Bereich ist es undenkbar, von Benutzern die Installation eines Treibers zu fordern.
Das U2F Protokoll wird mittels einer Javascript Bibliothek, die der jeweilige Webdienst einbinden muss, bereitgestellt.
Die Nutzung des USB-basierten U2F-Tokens funktioniert zur Zeit allerdings lediglich im Chrome Browser. Andere Browser sollen folgen.
U2F im Unternehmenseinsatz
U2F ist ein Protokoll, das deutlich für den Endanwender-Bereich gedacht ist. Es ist dezentral. Es schottet die einzelnen Webdienste gegeneinander ab. Der Benutzer kann bzw. muss den U2F-Token selber registrieren.
Wenn man sich die Player vom Anfang anschaut, dann macht auch dies Sinn. Die FIDO Alliance Mitglieder kommen zum größten Teil aus dem Endanwender-Markt. Ob Google, Mastercard, American Express. D.h. per se ist U2F nicht für den Unternehmenseinsatz entworfen.
Die charmante Handhabung bei der Anmeldung und der vergleichsweise niedrige Preis der Hardwaregeräte lassen uns aber trotzdem ein zweites mal über den Unternehmenseinsatz nachdenken.
Die AppId und Trusted Facets
Die oben erwähnte AppId ist im wesentlichen die URL. Anhand derer wird das für diesen Webdienst gültige Schlüsselpaar erzeugt bzw. später identifiziert. D.h. andere Webdienste mit anderen URLs müssten selber ein Schlüsselpaar registrieren. Da aber manche Anbieter wie https://google.com, https://maps.google.com, https://docs.google.com unter unterschiedlichen URLs mehrere Webdienste bereitstellen, für die der Anwender nicht jeweils wieder seinen U2F-Token registrieren soll, gibt es das Konzept der „Trusted Facets“. Hier kann definiert werden, dass ein einmal registrierter U2F-Token für spezielle Subdomains bzw. Hosts innerhalb der gleichen Domain verwendet werden darf.
D.h. der U2F-Token, der einmal für https://google.com registriert wurde kann außerdem auf https://maps.google.com und https://docs.google.com ohne erneute Registrierung verwendet werden.
Im Unternehmenseinsatz kommt man um die Nutzung der „Trusted Facets“ nicht umhin. Denn kein Unternehmen erwartet von seinen Benutzern, dass er sein Authentifizierungs-Device an https://crm.example.com, https://portal.example.com und https://vpn.example.com registrieren soll. Mit den „Trusted Factes“ lässt sich eine einmalige Registrierung realisieren.
Grenzen der Trusted Facets
Das Leben im Unternehmen gestaltet sich aber oft nicht so geradlinig. Innerhalb des Unternehmensnetzwerks sind manche Resourcen evtl. über andere Domainnamen als extern erreichbar. Manche Unternehmen verwenden intern bspw. eine Domain wie example.intranet oder example-intern.com, währen sie extern example.com verwenden.
Das CRM, das innerhalb des Unternehemsnetzwerk steht, ist also über https://crm.example-intern.com erreichbar, während der VPN-Zugang über https://vpn.example.com läuft. Die Trusted Facets erlauben aber nicht, eine andere Domain als vertrauenswürdig anzugeben. D.h. mit einem U2F-Token, der an https://example.com registriert wurde, kann man sich nicht an https://…example-intern.com anmelden. In dieser Domäne wäre eine erneute Registrierung nötig.
Zentrales Rollout
Weiterhin will man im Unternehmensumfeld die Verteilung von Authentifizierungsgeräten zentral kontrollieren und nicht unbegrenzt und unkontrolliert dem Benutzer überlassen. Hierzu unterstützt ein Management-System wie privacyIDEA die Registrierung von U2F-Token nicht nur durch den Anwender, sondern auch durch den Administrator bzw. den Helpdesk. So können U2F-Geräte zentral und kontrolliert für die Mitarbeiter im Unternehmen ausgerollt bzw. registriert werden.
Der Masterkey
Schließlich gibt es bei den U2F-Geräten weiterhin einen Punkt, über den man sich im Klaren sein muss. Das Schlüsselmaterial. Zwar wird bei der Registrierung das asymmetrische Schlüsselpaar für den jeweiligen Webdienst erzeugt. Allerdings passiert dies auf Basis des Masterkeys. Dieser wurde vom Hersteller in einer konktrollierten Umgebung auf dem U2F-Token erzeugt. Es ist nicht vorgesehen, den Masterkey selber zu erzeugen. An anderer Stellen hatten wir bereits über die Risiken, das eigene Schlüsselmaterial nicht selber zu erzeugen, berichtet.
Die Argumentationslinie bei U2F ist hierbei folgende. Das Gerät schickt bei der Registrierung ein sogenanntes „Attestation Certificate“ — ein Beglaubigungszertifikat. Dieses Zertifikat soll gegenüber dem Registrar nachweisen, dass es sich um ein bestimmtes Gerät einer gewissen Klasse handelt. Somit könnte der Registrar sicherstellen, dass bspw. nur Geräte des Herstellers A registriert werden dürfen, weil diese vermeindlich einen höheren Sicherheitsstandard haben. D.h. durch das Beglaubigungszertifikat ist somit auch nachgewiesen, dass dies ein Gerät des Herstellers A ist und dieses Gerät nach gewissen Sicherheitsstandards erzeugt und initialisiert worden war. Könnte nun ein Anwender oder Unternehmen ein U2F-Token selber initialisieren, so wäre das Beglaubigungzertifikat nutzlos, da für den Registrar nicht mehr ersichtlich wäre, mit welchen Sicherheitsstandards der Token initialisiert wurde.
Hier muss jeder für sich abwägen, ob der Einsatz von vorinitialisierten U2F-Token im Unternehemsumfeld eine Option ist. Yubikeys im OTP- oder Challenge-Response-Modus lassen sich mit privacyIDEA initialieren, so dass Sie die Wahl zwischen U2F, OTP und Challenge Response haben.
