Ja was nun – Zwei-Faktor-Authentisierung oder Zwei-Faktor-Authentifizierung?

Im Deutschen gibt es zwei Begriffe. Die Authentisierung und die Authentifizierung. Im normalen Umfeld mag das noch klar sein. Die Authentisierung ist die Sichtweise des Benutzers. Der Benutzer authentisiert sich an einem System. Die Authentifizierung ist die Sichtweise des Systems selber. Das System authentifiziert den Benutzer.

Wenn sich ein Benutzer anmeldet, muss der Server definitiv viel mehr tun als der Benutzer. Seine Aufgabe ist viel komplexer. Es muss erst einmal nachschauen, ob der Benutzer existiert und dann auch noch, ob die Credentials, die der Benutzer gesendet hat, valide sind. Hieraus ergibt sich eine kleine Eselsbrücke. Der Server macht die Authentifizierung. Denn das Wort Authentifizierung ist auch viel komplexer als Authentisierung. Schließlich hat der Server mehr zu tun und deswegen das Wort auch zwei Buchstaben (fi) mehr.

Doch wie ist das, wenn man zwei Faktoren hat?

Die „Two-Factor-Authentication“im Computerbereich mit einem Hardware-Faktor hat RSA im Jahr 1986 ins Leben gerufen. Dumme Sache nur, dass die englische Sprache nicht zwischen Authentisieren und Authentifizieren unterscheidet. Dort heißt es eben nur to authenticate und authentication.

Bundesamt für Sicherheit in der Informationstechnik

Das BSI selber spricht im Grundschutzkatalog von von Zwei-Faktor-Authentisierung bei Maßnahme 4.392 und Maßnahme 4.133. Allerdings scheint im ganzen Maßnahmenkatalog auch nicht das Wort Authentifizierung zu fallen.

Wikipedia

Die Einträge bei Wikipedia laufen unter Zwei-Faktor-Authentifizieung.

Heise

Ebenso wird das Schlagwort Zweifaktor-Authentifizierung als Thema bei Heise geführt.

Der Duden

Der Duden (20. Auflage, 1991) kennt die Worte authentifizieren und authentisieren.

authentifizieren: Die Echtheit bezeugen, beglaubigen.

authentisieren: Gehoben für glaubwürdig/rechtsgültig machen

Keep it simple and the customer happy

Unabhängig davon, dass es scheinbar offiziell Zwei-Faktor-Authentifizierung heißt, wähle ich persönlich oft die einfachere Bezeichnung Zwei-Faktor-Authentisierung. Damit stelle ich die Person als den Handelnden und nicht das authentifizierende Geräte in den Mittelpunkt. Außerdem erscheint mir das Wort leichter zu merken und auszusprechen zu sein.

Neulich wies mich ein Bekannter darauf hin, dass es doch zwei Faktoren sein. Grammitikalisch korrekt müsste es also Zwei-Faktoren-Authentifizierung heißen. Oder aber Zweit-Faktor-Authentifizierung.

Doch das nehme ich gar nicht in den Mund. Denn hätte ich meine Kunden mit komplizierten Worten verwirren wollen, wäre ich Arzt geworden.

 

Und mal wieder ging ein Beitrag durch die Presse, dass weitere Schlupflöcher für eine klassische Erklärung von verschränkten Photonpaaren in der Wiener Hofburg gestopft wurden.

Doch was hat es mit der Quantenkryptographie eigentlich auf sich? Und dabei bietet die Schweizer Firma ID Quantique dazu schon seit Jahren Produkte an!

Zentralbild Prof. Dr. phil Werner Kar. Heisenberg, Physiker, geboren 5.12.1901 in Würzburg, Professor für theoretische Physik, Direktor des Max-Planck-Instituts für Physik in Göttingen, Nobelpreis für Physik 1932 (Aufnahme 1933) 39049-33

Werner Heisenberg, Vater der Quantenmechanik (1933) [Bundesarchiv, Bild183-R57262 / CC-BY-SA 3.0]

Management Abstract

„Quantenkryptographie“ ist ein irreführender Name, da hier nicht wirklich die Verschlüsselung selber Thema ist. D.h. mit Quantenkryptographie kann man keine Email und vor allem keine Festplatte verschlüsseln. Der Prozess, der weithin mit „Quantenkryptigraphie“ bezeichnet wird, dient lediglich dazu, zwischen zwei Kommunikationspartnern, „sicher“ einen Schlüssel auszutauschen, um diesen Schlüssel dann zu verwenden, um den eigentlichen Nachrichtentext mit klassischen Algorithmen zu verschlüsseln. „Sicher“ heißt dabei auch nicht, dass ein Angreifer nicht mithören kann, sondern, dass die Kommunikationspartner wissen, ob ein Angreifer mitgehört hat oder nicht und daher wissen, ob der ausgehandelte Schlüssel vertrauenswürdig ist.

Quantenkryptographie löst also das Problem des Man-In-The-Middle-Angriffs beim Schlüsselaustausch.

Quantenkryptographie Hintergründe

Erwin_Schrödinger_(1933)

Erwin Schrödinger (1933) brachte uns die Katze

Disclaimer: Dieser Beitrag beansprucht nicht für sich wissenschaftlich korrekte Detailausführung, sondern ein grobes Verständnis für die Zusammenhänge zu vermitteln.

Die Quantenkryptographie arbeitet in der Welt der Quantenmechanik. Dies sind Effekte auf atomarer Ebene. Da wir – anders als die Newtonsche Mechanik – die Quantenmechanik in unserem Alltag nicht beobachten, haben wir hierzu keine persönlichen Erfahrungswerte. Uns fehlt Intuition. So wirkt sie auf uns merkwürdige, bisweilen unlogisch und ist schwer begreifbar.

In der Quantenmechanik gilt, dass der Zustand eines Objekts durch die Messung verändert bzw. erst bestimmt wird. Für die dicke meines Haares klingt das merkwürdig. Doch für die Quantenmechanik ist ein Haar immer noch die makroskopische Welt. Unheimlich dick. Und daher greift die Quantenmechanik erst bei ganz winzigen Größen. Bpsw. bei einem winzigen Lichtteilchen.

Erwin Schrödinger gab dazu das Gedankenexperiment mit der Katze in dem Kasten ab, bei dem die Katze erst tot oder lebendig ist, wenn wir den Deckel aufmachen. D.h. die Messung legt erst den Zustand fest, in dem sich die Katze befindet.

Messung von Lichtquanten

Die Messung von Lichtquanten haben einen angenehmen Vorteil, weil es hierzu eine gute Parallele in unserer makroskopischen Welt gibt – nämlich die Polarisation des Lichtes als elektromagnetische Welle. Dies ist vielleicht eingängiger, als den Lebenszustand einer Katze zu messen.

Wenn vor unpolarisiertes Licht mit verschiedenen Schwingungsebenen ein linearer Polarisationsfilter gehalten wird, erhält man danach linear polarisiertes Licht.

quantenkrypto-1

Mit Hilfe eines Polarisationsfilters kann die Schwingungsebene des Lichtes auf eine einzige Ebene festgelegt werden.

Wenn man nun vor das linear polarisierte Licht wiederum einen um 90 Grad gedrehten Polarisationsfilter hält, so wird das Licht ausgelöscht.

quantekrypto-2

Ein Polarisationsfilter kann makroskopisches, polarisiertes Licht auslöschen.

Auf Lichtquantenebene ist der sogenannte Spin polarisiert. Auch dieser Spin ist messbar – vergleichsweise der Schwingungsebene. Wir unterscheiden hier vertikalen und Diagonalen Spin.

quantenkrypto-3

Die Messung von Lichtquanten mit polarisiertem Spin kann zu nicht vorhersagbaren Ergebnissen führen.

Um den Spin eines polarisierten Lichtquantes zu bestimmen, muss er gemessen werden. Doch dabei läuft man Gefahr – genau wie bei dem obigen Beispiel – das Lichtquant zu „vernichten“ oder in einen neuen Polarisationszustand zu zwingen. Man kann mit Sicherheit nicht sagen, wie das Lichtquant vorher tatsächlich gewesen ist. Es gilt:

  • Wird vor ein Lichtquant mit „vertikal“ polarisierten Spin ein vertikaler Filter gehalten, so kommt das Lichtquant immer durch. Wie nehmen das als binäre 1.
  • Wird vor ein Lichtquant mit „horizontal“ polarisierten Spin ein vertikaler Filter gehalten, so kommt das Lichtquant niemals durch. Wir nehmen das als binäre 0.
  • Wird aber vor ein Lichtquant mit „diagonal“ polarisierten Spin ein vertikaler Filter gehalten, so kommt das Lichtquant entweder durch als vertikal polarisiertes Lichtquant (binäre 1) oder nicht (binäre 0). D.h. man misst eine 1 oder eine 0 und weiß aber nicht, dass man auch das andere hätte messen könne. Das nebenstehende Bild veranschaulicht dies. In dem Bild zeigt eine 0,5, dass man entweder 1 oder 0 gemessen haben kann.

 

Quantenkryptographie Beispiel

In diesem Beispiel polarisiert Alice Lichtquanten aus einer unpolarisierten Lichtquelle wie einer LED. D.h. sie erzeugt einen Strom aus polarisierten Lichtquanten. Sie selber wendet die Filter an und kennt somit die Filteranordnung und die Polarisierung. Diesen Strom sendet sie an Bob.

quantenkrypto-5

Ein ungestörter Schlüsseltausch zwischen Alice und Bob.

Bob muss sich selber frei überlegen, welche Filter er pro Lichtquant anwendet.

Alice teilt ihm mit, welche seiner Wahl richtig war. Nämlich der erste, der fünfte und der siebte Filter.

So nehmen Alice und Bob die erste, fünfte und siebte Stelle und erhalten beide den gleichen 3 bit langen Verschlüsselungskey.

Sie können sicher sein, dass nur sie beide diesen Verschlüsselungskey kennen.

Man in the middle

Nun hört Eve diese Kommunikation ab. Doch schon die Bezeichnung ist falsch. In der Quantenkryptographie kann man nicht einem vorbeiziehendem Strom zuhören. Um ihn zu sehen (oder zu hören) muss er gemessen und wieder neu ausgesendet werden. Und genau hier entsteht das Problem, weil Eve mit den Messungen die Polarisationszustände der Lichtquanten verändern wird.

quantenkrypto-0006

Der Schlüsseltausch wird von Eve gestört. Der Schlüssel wird durch Eve ungewollt verändert.

Auch Eve muss sich für eine Filteranordnung entscheiden mit der sie misst. Und genau hier entsteht das Problem.

Das fünfte Bit wurde von Alice vertikal polarisiert gesendet. Eve hat sich für einen diagonalen Filter entschieden. D.h. Eve kann eine 0 (\) messen – es kann aber auch sein, dass sie eine 1 (/) gemessen hat. Dies ist nicht ihre Entscheidung, sondern quantenmechanischer Zufall. In diesem Universum hat Eve nun eine 1 (/) gemessen, weswegen sie nun auch eine 1 (/) weitersendet. Da Bob das fünfte Bit mit einem diagonalen Filter miss, kann auch bei Bob eine 0 oder 1 gemessen werden.

Dadurch dass Eve messend und somit verändert in den Strom der Lichtquanten eingreift, schüttelt sie die Informationen durcheinander. In diesem Beispiel des 3-Bit-Schlüssels hat sie mit 75% Wahrscheinlichkeit den Schlüssel zerstört.

Alice wird mit ihrem originalen Schlüssel 101 etwas verschlüsseln was Bob mit dem Schlüssel 100 nicht entschlüsseln kann. Somit merken sie, dass die Verbindung abgehört wurde. Das Datenleck muss gefunden werden und der Schlüsseltausch kann neu beginnen.

funkmast

Gute Netzabdeckung, ein großes Angebot von preiswerten Smartphones und der Trend „bring your own device“ führten zu einem Paradigmenwechsel beim Thema Mehr-Faktor-Authentisierung.

Während vor einigen Jahre Mehr-Faktor- oder Zwei-Faktor-Authentisierung nur von großen Unternehmen angegangen wurde und solchen die einen hohen Schutzbedarf haben, wurde nun doch erkannt, dass Daten zu schützen, die Aufgabe eines jeden Geschäftsführers ist.

Gleichzeitig wird immer öfters auf die einfachereren und preiswerteren Varianten mit einem Smartphone-App, Email oder SMS zurückgegriffen. Doch muss man sich klarmachen, wieviel Sicherheit bei dem Einsatz solch schwacher Faktoren noch übrig bleibt.

Der Google Authenticator

Der Google Authenticator war eine der ersten Apps, die die OTP-Funktionalität bisheriger Hardware-Token in Software auf einem Smartphone abbildete. Der Google Authenticator unterstützt HOTP und TOTP Algorithmen. Alternative Apps sind FreeOTP (TOTP) oder HDE OTP (TOTP).

Die Nutztung des Smartphones als Authentisierungsdevice hat durchaus seine Berechtigung. Denn ein wichtiger Aspekt eines Besitztums zur Anmeldung ist, dass der Benutzer diesen mit sich trägt und nicht auf dem Schreibtisch liegen oder im Computer stecken lässt.

Das Seed (1)

Die OTP Algorithmen HOTP und TOTP arbeiten auf der Basis eines symmetrischen geheimen Schlüssels oder auch Seed, anhand dessen die Einmalpassworte berechnet werden. Das bedeutet aber auch, dass dieses Seed sicher geschützet werden muss. Ob dieses im Smartphone jeweils immer gegeben ist, darf – da das Smartphone auch nur ein leistungsstarker Computer mit veralteter Software und schlechtem Virenschutz ist – berechtigter Weise bezweifelt werden.

Das Seed (2)

Doch ein viel einfacherer Missbrauch ergibt sich aus dem bequemen Konzept zur Initialisierung der Smartphone App.

QrCode-TOTP

Dies geschieht über den QRCode, in dem das oben genannte Seed im Klartext enthalten ist. Der hier gezeigte QRCode enthält den folgenden Inhalt:

otpauth://totp/TOTP00017410?secret=O6LVCAVTS2IJ25NKXKOOGCNTJIOFNUXA&counter=1&digits=6&issuer=privacyIDEA

Dabei ist O6LVCAVTS2IJ25NKXKOOGCNTJIOFNUXA der geheime Schlüssel in sogenannter „Base32“ Schreibweise. Das mag für das menschliche Auge zwar merkwürdig und kompliziert aussehen, ist für den Computer oder das Smartphone aber tatsächlich Klartext.

Da dies ein zeibasierter OTP Token ist, wird jedes Gerät, das diesen QRCode scannt, immer den gleichen OTP-Wert anzeigen.

Ein Selbstversuch

Ich lade ein zum Selbstversuch: Haben Sie zwei Smartphones zur Hand? Installieren Sie auf beiden Smartphones den Google Authenitcator, HDE OTP oder FreeOTP. Einzige Voraussetzung für das Gelingen dieses Versuchs ist es, dass die Uhren der beiden Smartphones genau gehen.

Versuch 1

Scannen Sie den QRCode mit Ihrem Smartphone A und mit ihrem Smartphone B.

Starten Sie den Google Authenticator und beobachten Sie, dass auf beiden Smartphones jeweils das gleiche Einmalpasswort angezeigt wird. Zwei Mal das gleiche Einmalpasswort? Da stimmt doch was mit der Namensgebung nicht!

Versuch 2

Dieser Versuch verdeutlicht das Problem noch etwas mehr. Löschen Sie den Token von Smartphone B. Drucken Sie diese Seite mit dem QRCode aus und legen sie sie eine Woche in die Schublade.

Nach einer Woche gehen Sie zur Schublade und Scannen mit Smartphone B den QRCode. Smartphone B wird sofort die gleichen Einmalpassworte wie das Smartphone A anzeigen.

Das Problem im Unternehmen

Aufgrund der Struktur des TOTP-Algorithmus und des Rollout-Prinzips des Google Authenticators können Sie identische Kopien des Tokens erstellen. Auch noch nach Wochen und Monaten.

Ein Unternehmen, das die Passwortweitergabe unter Mitarbeitern verhindern will, darf sich bei der Einführung einer Zwei-Faktor-Lösung nicht blind auf diesen Algorithmus verlassen. Denn derselbe QRCode kann von allen Kollegen gescannt werden, so dass jeder Mitarbeiter den Token des anderen Kollegens hat. Schon wieder ist es dem Unternehmen nicht möglich, sicherzustellen, welcher Mitarbeiter denn nun wirklich hinter dem Account steckt. Die Idee des zweiten Faktors ist ausgehebelt.

Eine mögliche Lösung

Das Problem liegt hier im Rollout-Prozess, bei dem der geheime Schlüssel im Klartext übertragen wird. Ein besseres Rollout-Konzept weist der TiQR-Token auf. Dabei erzeugt das Smartphone den Schlüssel und scannt einen QRCode, in dem aber nur ein Registrierungslink enthalten ist, wohin der Schlüssel (über einen verschlüsselten Kanal) gesendet werden muss.

Doch dieser Rollout-Prozess erfordert auch eine aufwändigere Infrastruktur. Das Smartphone muss online sein und für den Registrierungslink muss ein verstrauenswürdiges Zertifikat vorhanden sein.

Gerade die Leichtigkeit des Rollouts im Falle des Google Authenticators haben gewiss zu seinem Erfolg beigetragen. Doch es bleibt nicht aus, dass man bei der Einführung einer Zwei-Faktor-Lösung sich Gedanken machen muss, wie die diversen Prozesse am besten umzusetzen sind. Schwächen in der Sicherheit sind nur dann tragbar, wenn man sich bewusst für diese entschieden hat und das Restrisiko akzeptieren und damit leben kann.

 

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

Dieses Video ansehen auf YouTube.

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.

Mit HOTP und TOTP sind zwei Algorithmen standardisiert, die offen sind und nach heutigem Dafürhaltenvom Algorithmus her als sicher angesehen werden können.

Viele Hersteller klassischer Hardware-Token und aber auch Smartphone-Apps bedienen sich dieser Algorithmen, um Einmalpasswörter zu erzeugen. Immer wieder taucht in unseren Projekten die Frage auf, ob denn HOTP- oder TOTP-Token eingesetzt werden sollen.

Das kommt drauf an.

HOTP und TOTP sind, wie eingangs erwähnt, nach heutigem Kenntnisstand per se als sicher anzusehen. D.h. aus einem oder mehrerer gewonnenen OTP-Werte könnten keine zukünftigen OTP-Werte berechnet werden. Ebenso kann im Falle von HOTP aus der Kenntnis des Zählers kein zukünftiger OTP-Wert berechnet werden. In beiden Fällen geht der symmetrische, geheime Schlüssel in einen HMAC-SHA1 Algorithmus ein. Zusätzlich wird das Ergebnis auf 6 oder 8 stellen gekürzt, so dass die Angriffsmöglichkeiten weiter schwinden.

In der praktischen Handhabung unterscheiden sich HOTP und TOTP aber sehr. Wenn man sich dies vor Augen hält, kann es bei der Entscheidungsfindung entsprechend helfen.

Ich starte nicht mit HOTP, damit ich mit TOTP aufhören kann. Es ist lediglich eine historische Herangehensweise. HOTP ist der ältere Algorithmus. (HOTP: RFC4226, Dezember 2005, TOTP: RFC6238, Mai 2011).

HOTP

Nachteile

  • Die TAN-Liste. HOTP ist ereignisbasiert. Ein Tastendruck zählt einen Zähler hoch. Der so erzeugte OTP-Wert wird erst ungültig, wenn entweder dieser OTP-Wert oder ein nachfolgender OTP-Wert benutzt wird. Wenn der Benutzer sich einen OTP-Wert drückt, hat er alle Zeit der Welt, diesen einzutippen. Das bedeutet aber auch, dass er sich diesen OTP-Wert aufschreiben kann. Und den nächsten. Und noch einen. Somit ist der Benutzer in der Lage, sich eine TAN-Liste zu erzeugen. Diese kann er mit seinen Arbeitkollegen teilen, in die Schreibtischschublade legen oder ins Portemonnaie stecken.

Vorteile

  • HOTP ist ereignisbasiert. Das macht ihn robust und stromsparend. Naja, das mit dem Strom lassen wir mal gerade bei Seite. Aber es existiert nicht das Problem, dass die Uhr des Tokens aus der Synchronisation mit dem Server läuft. Weil er keine Uhr hat. Der Mechanismus, einen out-of-sync HOTP-Token wieder zu synchronisieren ist ebenso einfach und robust. In der Praxis ist der HOTP-Token einfacher anzuwenden als ein TOTP-Token.
  • Der HOTP-Token lässt sich nicht so leicht klonen. Wenn man bspw. einen Google Authenticator ausrollt, so kann der QR-Code, der das geheime Seed enthält, auf zwei oder mehreren Smartphones gescannt werden. Wenn man nun anfängt, sich mit dem Smartphone 1 zu authentisieren, so zählt das Smartphone 1 den Zähler hoch. Im Server wird ebenfalls der Zähler hochgezählt. Kommt nun der Kollege mit dem gleichen Seed auf dem Smartphone 2, so erzeugt er einen bereits verbrauchten OTP-Wert. Die Zähler zwischen den Smartphones laufen auseinander.
    • Im Falle eines Angriffs: Wenn ein Angreifer den QR-Code scannt und sich erfolgreich anmeldet, wird dadurch der Zähler im Server hochgezählt. Wenn nun der legitime Besitzer kommt, erzeugt er einen bereits verbrauchten OTP-Wert und kann sich nicht anmelden. Wenn der Angreifer sich schon öfters als einmal angemeldet hat, dann wird auch das Resynchronisieren des legitimen Benutzers fehlschlagen. Ein Angriff ist somit also potentiell leichter zu bemerken.

TOTP

Nachteile

  • Die Uhr und die Synchronität. Der TOTP-Token ist zeitbasiert. D.h. in diesem kleinen Token tickt eine Uhr, die möglichst genau so schnell gehen soll, wie die in dem Server. Es existieren hier Mechanismen, diese synchron zu halten. So kann bei jeder Authentisierung das Offset der Uhr ermittelt werden. Wenn ein Benutzer sich aber sehr lange nicht anmeldet, dann geht die Uhr sehr falsch, so dass man Probleme bekommen kann. Die Resynchronisierung erweist sich in der Praxis nicht immer so leicht, wie beim HOTP Token.
  • Die Uhr im Auslieferungszustand. Die Uhr im Auslieferungszustand könnte schon eine unbekannte Zeitdrift haben, die man erstmal feststellen muss. Der HOTP-Token wird mit dem Counter „0“ ausgeliefert.
  • Der TOTP-Token schneidet die Unix-System-Time in Zeitscheiben. Dies können 30 oder 60 Sekunden sein. In manchen Fällen kann das zu Verwirrungen führen. Wählt man die Zeitscheibe falsch, dann schlägt die Authentisierung und die Synchronisation fehl!
  • Der TOTP-Token lässt sich leichter Klonen. Im Falle des Google Authenticators kann der QR-Code mit verschiedenen Smartphones gescannt werden. Jedes Smartphone erzeugt zu jedem Zeitpunkt einen gültigen OTP-Wert.
    • Lediglich innerhalb der Zeitscheibe von 30 oder 60 Sekunden kann eine Authentisierung fehlschlagen, weil sich in diesem Fenster der Angreifer schonmal angemeldet hat. Nach einer Minute ist aber nichts mehr davon zu merken, dass ein Angreifer einen Klon des Smartphone-Tokens besitzt.
  • Mit einem TOTP-Token kann man sich innerhalb von 30 oder 60 Sekunden nur einmal anmelden. Während das für den klassischen Einsatzzweck eines Remote-Zugang durchaus OK ist, kann dies in anderen Fällen problematisch sein. Nutzt man OTP bspw. für die SSH-Server-Farm, so kann es durchaus notwendig sein, sich öfters als alle 30 Sekunden einen OTP-Wert zu erzeugen.

Vorteile

  • Es können keine TAN-Listen erzeugt werden.

 

Fazit

HOTP und TOTP haben beide ihre Vor- und Nachteile. In machen Fällen passt der eine besser, in anderen der andere. Welcher Tokentyp in Ihrem Szenario passt, lässt sich am besten im Rahmen eines Projekts klären.  Alle Tokentypen werden von privacyIDEA unterstützt und können in beliebigen Mischbetrieben genutzt werden.

Wie Heise berichtet, soll die öffentliche Hand in Zukunft endlich mal mit Backdoor-freier Software arbeiten können. So die Idee der Bundesregierung. Hierzu hat das Bundesinnenministerium die Musterverträge für die Beschaffung von Standard-Software aktualisiert und bereitgestellt.

Konkret geht es wohl um den Punkt 2.3 aus Ergänzende Vertragsbedingungen für die Überlassung von Standardsoftware gegen Einmalvergütung – EVB-IT Überlassung-AGB (Typ A) –:

[…] Der Auftragnehmer gewährleistet darüber hinaus, dass die von ihm zu liefernde Standardsoftware* frei
von Funktionen ist, die die Integrität, Vertraulichkeit und Verfügbarkeit der Standardsoftware*, anderer
Soft- und/oder Hardware oder von Daten gefährden und den Vertraulichkeits- oder Sicherheitsinteres-
sen des Auftraggebers zuwiderlaufen durch

  • Funktionen zum unerwünschten Absetzen/Ausleiten von Daten,
  • Funktionen zur unerwünschten Veränderung/Manipulation von Daten oder der Ablauflogik oder
  • Funktionen zum unerwünschten Einleiten von Daten oder unerwünschte Funktionserweiterungen.

[…]

trojan-horse-152800_1280

Read the Source, Luke! (by OpenClipartVectors @pixabay)

D.h. der Software-Lieferant soll gewährleisten, dass die Betriebssysteme, Mailserver, Virenscanner, Firewalls, VPN Clients zumeist der den Markt beherrschenden U.S. amerikanischen Hersteller frei von Backdoors sind. Herzlichen Glückwunsch! Da werden sich so einige auch der großen Dienstleister umschauen, wie sie das bewerkstelligen sollen.

Ich lade alle Lieferanten der öffentlichen Hand daher ein, Ihr Software-Portfolio zu überdenken und vermehrt auf Open Source zu setzen. Denn nur hier kann der Dienstleister selber sicher sein, dass die Software keine Funktionen zum unerwünschten Ausleiten von Daten enthält. Ansonsten muss er auf Aussagen wie „Die NSA hat uns zugesichert, dass sie Recht und Gesetz in Deutschland achtet.“ vertrauen.

Die NetKnights GmbH setzt auf Open Source und engagiert sich nicht zuletzt mit der Entwicklung des Multi-Faktor-Authentisierungs-Systems privacyIDEA für die Verbreitung von Open Source und transparente Software-Entwicklungsprozesse und eine sicherere IT-Infrastruktur.