Beiträge

U2F im Unternehmenseinsatz

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

Security-Key-by-Yubico-in-USB-Port-on-Keychain

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

privacyIDEA-200pxWeiterhin 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.

 

 

Wider den Kontrollverlust: Mehr-Faktor-Authentisierung zum Schutz der eigenen Daten

Auf der FrOSCon 2015 in Sankt Augustin hielt ich einen Vortrag mit dem Titel „Alles meins!“.

Kontrollverlust

Der Untertitel hätte auch Wider den Kontrollverlust heißen können.

Denn nicht nur gleitet uns angesichts ansteigender Überwachungsszenarien und Diskussionen über Routerzwang und Netzneutralität die Kontrolle aus den Händen. Bisweilen geben wir die Kontrolle auch freimütig selber ab. Ich rede hier nicht von der Medieninkompetenz, die wir auf den sozialen Netzwerken betreiben. Vielmehr geht es mir – meinem Beruf entsprechend – um die Datensicherheit in den Unternehmensnetzwerken.

Hier wird es für Unternehmen zusehends attraktiver, die Authentisierungsinfrastruktur zu outsourcen.

Sowohl für das Unternehmen, das seine Mitarbeiter authentifizieren möchte, als auch für die andere Seite. Die klassischen Player am Markt haben für sich das Geschäftsmodell entdeckt, Mehr-Faktor-Authentisierung als gehostete Dienste zu betreiben. Für die Kunden wirkt das ebenfalls attraktiv:

Die IT-Abteilung muss keinen OTP-Server installieren oder keine PKI aufsetzen. Man kann die (virtuellen) Server sparen und muss sich nicht mehr um Software-Updates und Security-Patches kümmern. Und vielleicht kann man so auch schließlich die IT-Abteilung verschlanken.

Doch möchte man Zwei-Faktor-Authentisierung richtig betreiben, muss man sein Augenmerk auf drei Punkte legen:

Der Algorithmus

Einmalpasswort-Authentisierung basiert auf einem symmetrischen Algorithmus. Der Token (als der Besitz) und das Serverbackend (wie bpsw. privacyIDEA) müssen den gleichen Algorithmus und das gleiche Schlüsselmaterial verwenden, um ein Einmal-Passwort zu berechnen. Ein solcher Algorithmus muss sicherstellen, dass von dem aktuellen Einmalpasswort oder einer Reihe älterer Einmalpassörter nicht auf das nächste Einmalpasswort geschlossen werden kann. Auf jeden Fall muss auch verhindert werden, dass man mit einer Liste von alten Einmalpasswörtern sogar den geheimen Schlüssel berechnen könnte. In einem solchen Fall könnte ein Angreifer den geheimen Schlüssel berechnen und sich eine Kopie des Besitzfaktors erzeugen. Die Idee des Besitzes, anhand dessen der Benutzer authentifiziert werden soll, wäre also dahin. Es gäbe keinen eindeutigen Besitz mehr.

Der Algorithmus muss also gewährleisten, dass solche Angriffe nicht leicht möglich sind.

Standardisierte Algorithmen wie HOTP oder TOTP bieten den Vorteil, dass man sich von den Stärken und den Grenzen oder Schwächen der Algorithmen selber überzeugen kann und somit in der Lage ist, die richtigen Entscheidungen zu treffen. Hierzu hatte ich einen Artikel über HOTP oder TOTP verfasst.

Proprietäre Algorithmen verhindern, dass man sich über die Verlässlichkeit und die Grenzen des Algorithmus selber ein Urteil bilden kann. Man muss die Kontrolle aus der Hand geben und komplett auf die Aussage des Herstellers vertrauen. „Security by Obscurity“ war in der IT-Sicherheit noch nie die richtige Wahl!

Anforderung: Der verwendete Algorithmus sollte ein offener, standardisierter Algorithmus sein.

Das Schlüsselmaterial

OTP-Token arbeiten mit einem symmetrischen Schlüssel – X.509-Zertifikate mit einem asymmetrischen. Es gibt also einen symmetrischen geheimen oder einen asymmetrischen privaten Schlüssel, der für die Authentisierung verwendet wird. Es gilt, diesen geheimen Schlüssel zu schützen. So lange kein anderer an diesen Schlüssel kommt, ist es möglich, den Benutzer sicher zu authentifizieren. Genauer gesagt, ist es möglich sicherzustellen, dass der Benutzer im Besitz des geheimen Schlüssels ist.

Oben beschrieb ich bereits, dass deswegen der Algorithmus den geheimen Schlüssel nicht preisgeben darf.

Anforderung: Aber darüber hinaus sollte der geheime Schlüssel nicht kopierbar sein.

D.h. der geheime Schlüssel sollte, wenn möglich, in Hardware existieren. Weiterhin sollte der geheime Schlüssel von Ihnen selber erzeugt worden sein.

Die meisten Hardware-Token-Hersteller erzeugen den Schlüssel heutzutage in der Fabrik. D.h. Sie als Kunde erhalten die Hardware, in der bereits ein geheimer Schlüssel enthalten ist. Da ein Backend wie privacyIDEA ebenfalls den geheimen Schlüssel kennen muss, wird vom Hersteller eine Datei mit den geheimen Sclüsseln mitgeliefert. In diesem Fall können Sie aber nicht endgültig sicher sein, ob der geheime Schlüssel in der Lieferkette vom Hersteller über den Distributor und Reseller zu Ihnen tatsächlich geheim geblieben. Angreifer, die die Lieferung abgefangen und die Datei kopiert haben oder direkt beim Hersteller eingedrungen sind, können sich nun unbemerkt als die jeweiligen Benutzer authentisieren.

Anforderung: Der geheime Schlüssel sollte von Ihnen erzeugt werden.

Kunden, die Ihren Zwei-Faktor-Authentisierungsservice hosten lassen, können niemals sicher sein, wie und wo eine weitere Kopie eines geheimen Schlüssels existiert. Der Anbieter der Authentisierungs-Hosting Lösung kann die besten und edelsten Absichten haben. Wenn er Opfer eines Angriffs oder einer gesetzlichen Verpflichtung gegenüber Geheimdiensten oder anderen Regierungsstellen wird, sind Sie als Kunde evtl. der letzte der davon erfährt.

Anforderung: Sie sollten Ihre Authentisierungslösung selber betreiben.

In meinem Vortrag gehe ich genauer auf das Thema der Besitzfaktoren und des Schlüsselmaterials ein.

Der Code

Die Software, die letztendlich im Backend darüber entscheidet ob einer Authentisierungsanfrage eines Benutzers stattgegeben wird oder nicht, kann es in verschiedenen Ausführungen geben. Software enthält viele Zeilen Code, die verschlungene Wege gehen, die demjenigen, der die Software einsetzt, evtl. nicht immer klar sind. Wie die jüngste Vergangenheit zeigt, kann Software auch Hintertüren enthalten und Funktionen bieten, die nicht beabsichtig waren – jedenfalls nicht von Ihnen als Anwender und Kunde.

Daher muss nicht nur der verwendete Algorithmus und das Schlüsselmaterial unter Ihrer Kontrolle sein. Ebenso sollten Sie in der Lage sein, zu bewerten oder bewerten zu lassen, was die Software tut. Dies geht evtl. mit Code Escrow und dem Unterzeichnen von NDAs. Letztendlich geht es aber nur, wenn der Quelltext der Software per se offen liegt.

Anforderung: Aus diesem Sicherheitsaspekt heraus ist Open Source Software als Authentisierungslösung zu bevorzugen.

privacyIDEA ist eine komplett offen liegende Open Source Software, für die wir – die NetKnights GmbH – Enterprise Support anbieten.