it-swarm.com.de

Wie sicher sind die FIDO U2F-Token?

Google und Yubico haben gerade die Verfügbarkeit von kryptografischen Sicherheitstoken gemäß der FIDO U2F-Spezifikation angekündigt. Ist dies nur eine weitere 2FA-Option oder ist dies deutlich besser als Lösungen wie SecureID und TOTP?

Speziell:

  • Inwiefern unterscheidet sich U2F grundlegend von OTP?
  • Wie wirkt sich U2F auf die Durchführbarkeit von Phishing-Angriffen im Vergleich zu OTP-Systemen aus?
  • Wie machbar sind nicht interaktive Angriffe gegen U2F (z. B. Brute-Force usw.)?
  • Kann ich ein einzelnes U2F-Token mit mehreren unabhängigen Diensten sicher verwenden?
  • Wie kann sich U2F gegen andere kommerzielle Angebote behaupten? Gibt es bessere Lösungen?
126
tylerl

Die Antworten, die ich erhalten habe, waren gut, aber ich wollte ein bisschen mehr Tiefe bieten, insbesondere, warum das System überhaupt existiert, was ein bisschen mehr darüber erklären sollte, wofür es gut ist.

Haftungsausschluss : Während ich jetzt für Google arbeite, wusste ich zu diesem Zeitpunkt nichts über dieses Projekt Antwort wurde geschrieben. Alles, was hier berichtet wurde, wurde aus öffentlichen Quellen gesammelt. Dieser Beitrag ist meine eigene Meinung und Beobachtung und mein Kommentar und gibt nicht die Meinungen, Ansichten oder Absichten von Google wieder.

Obwohl es erwähnenswert ist, dass ich dies bereits seit einiger Zeit benutze und daran bastele und als jemand, der sich viel mit Social Engineering und Kontoübernahmen beschäftigt hat, bin ich überproportional beeindruckt von dem, was erreicht wurde hier.

Warum wurde etwas Neues gebraucht?

Denken Sie darüber nach: Google hat vor langer Zeit die Zwei-Faktor-Authentifizierung bereitgestellt. Dies ist ein Unternehmen, das sich sehr um Sicherheit kümmert und das erstklassig ist. Und während sie bereits die beste verfügbare Technologie verwendeten , ist die zusätzliche Sicherheit, die U2F gegenüber dem herkömmlichen 2-Faktor bietet, so bedeutend , dass sich die Zeit des Unternehmens gelohnt hat und Geld für das Entwerfen, Entwickeln, Bereitstellen und Unterstützen eines Ersatzsystems, das sie selbst nicht verkaufen. Ja, es ist ein sehr sozialbewusster Schritt von ihnen, diesen Weg zu gehen, aber es geht nicht nur um die Gemeinschaft. Google hat es auch getan, weil sie selbst die Sicherheit benötigen, die U2F allein bietet. Viele Menschen vertrauen Google mit ihren wertvollsten Informationen, und einige in gefährlichen politischen Umgebungen vertrauen Google sogar mit ihrem Leben. Google benötigt die Sicherheit, um dieses Vertrauen erfüllen zu können.

Es kommt auf Phishing an. Phishing ist eine große Sache. Es ist sehr häufig und super effektiv. Bei Angriffen auf gehärtete Ziele sind Phishing- und ähnliche Angriffe die beste Wahl für Angreifer, und sie wissen es. Und wichtiger:

Unser Phishing-Schutz ist lächerlich. Wir haben eine Zwei-Faktor-Authentifizierung, aber die Implementierungen bieten wenig Schutz. Gängige Systeme wie SecurID, Google Authenticator, E-Mail, Telefon und SMS Schleifen - alle diese Systeme bieten überhaupt keinen Schutz gegen Time-of- Verwenden Sie Phishing-Angriffe. Ein Einmalkennwort ist immer noch ein Kennwort und kann einem Angreifer mitgeteilt werden.

Und das ist nicht nur theoretisch. Wir haben gesehen, dass diese Angriffe tatsächlich ausgeführt wurden. Tatsächlich erfassen Angreifer Antworten auf den zweiten Faktor, die an Phishing-Sites gesendet werden, und spielen sie sofort auf der realen Anmeldeseite ab. Das passiert tatsächlich gerade.

Angenommen, Sie sind Google. Sie haben die besten verfügbaren Schutzfunktionen bereitgestellt und können feststellen, dass diese nicht ausreichen. Wie geht's? Niemand anderes löst dieses Problem für Sie. du musst es herausfinden.

Die Lösung ist einfach; Annahme ist das eigentliche Problem

Das Erstellen einer Second-Factor-Lösung, die nicht phishingfähig ist, ist überraschend einfach. Alles was Sie tun müssen, ist den Browser einzubeziehen. Im Fall von U2F erstellt das Gerät für jeden Standort ein öffentliches/privates Schlüsselpaar und brennt die Identität des Standorts in das "Schlüsselhandle", mit dem der Standort die Authentifizierung anfordern soll. Diese Site-Identität wird dann jedes Mal vom Browser überprüft, bevor eine Authentifizierung versucht wird. Die Site-Identität kann sogar an einen bestimmten öffentlichen TLS-Schlüssel gebunden werden. Und da es sich um ein Challenge-Response-Protokoll handelt, ist auch keine Wiedergabe möglich. Und wenn der Server bei einem Datenbankverstoß versehentlich Ihr "Key Handle" verliert, hat dies keine Auswirkungen auf Ihre Sicherheit oder die Offenlegung Ihrer Identität. Durch den Einsatz dieses Geräts wird Phishing als Möglichkeit effektiv eliminiert, was für eine sicherheitsrelevante Organisation eine große Sache ist.

Weder die Krypto noch ihre Anwendung sind neu. Beide sind gut verstanden und vertrauenswürdig. Die Technologie war nie die Schwierigkeit, die Schwierigkeit ist die Annahme. Google ist jedoch einer der wenigen Anbieter, die in der Lage sind, die Hindernisse zu überwinden, die Lösungen wie diese normalerweise zurückhalten. Da Google den beliebtesten Browser herstellt, können sie sicherstellen, dass er standardmäßig kompatibel ist. Da sie das beliebteste mobile Betriebssystem sind, können sie sicherstellen, dass es auch funktioniert. Und da sie den beliebtesten E-Mail-Dienst ausführen, können sie sicherstellen, dass diese Technologie einen relevanten Anwendungsfall hat.

Offener als nötig

Natürlich hätte Google diese Position nutzen können, um sich einen Wettbewerbsvorteil auf dem Markt zu verschaffen, aber das taten sie nicht. Und das ist ziemlich cool. Jeder benötigt diese Schutzstufe , einschließlich Yahoo und Microsoft mit ihren konkurrierenden E-Mail-Angeboten. Was cool ist, ist, dass es so konzipiert wurde, dass selbst Konkurrenten es sicher zu ihrem eigenen machen können. Nichts an der Technologie ist an Google gebunden - selbst die Hardware ist völlig nutzungsunabhängig.

Das System wurde mit der Annahme entwickelt, dass Sie es nicht Nur für Google verwenden. Ein Schlüsselmerkmal des Protokolls ist, dass das Token zu keinem Zeitpunkt selbst identifiziert. Tatsächlich geben die Spezifikationen an, dass dieses Design ausgewählt wurde, um die Möglichkeit zu verhindern, einen "Supercookie" zu erstellen, der verwendet werden kann, um Sie zwischen kolludierenden Diensten zu verfolgen.

So können Sie ein einzelnes Token erhalten und es nicht nur in Google Mail, sondern auch in jedem anderen Dienst, der U2F unterstützt, sicher verwenden. Dies gibt Ihnen viel mehr Grund, das Geld für einen zu setzen. Und da Yubico veröffentlicht Referenzimplementierungen der Serversoftware in PHP, Java und Python ist, ist es selbst für kleine Geschäfte sicher, die Authentifizierung auf Ihrem eigenen Server zum Laufen zu bringen.

85
tylerl

U2F kann einen verschlüsselten Kanal mit Krypto mit öffentlichem Schlüssel verwenden, um sicherzustellen, dass NUR der richtige Server das einmalige Token erhält. Dies bedeutet, dass das Einstecken auf einer Phishing-Site bedeutet, dass nichts passiert - sie können nicht in Ihr Konto gelangen. Stattdessen müssen sie sich auf technische Angriffe wie XSS und lokale Malware verlassen.

Es soll in der Lage sein, die Tatsache zu verbergen, dass Sie dasselbe Gerät für mehrere Dienste verwenden, sodass jemand, der sowohl Standort A als auch Standort B steuert, nicht erkennen kann, dass Sie auf beiden Geräten dasselbe Gerät verwendet haben. Es soll sicher sein.

Es scheint die beste derzeit verfügbare Option zu sein, vor allem aufgrund des laufenden Standardisierungsprozesses und der breiten Unterstützung und Dynamik dafür.

Von die FIDO-Spezifikation

Während der Registrierung bei einem Onlinedienst erstellt das Clientgerät des Benutzers ein neues Schlüsselpaar. Es behält den privaten Schlüssel bei und registriert den öffentlichen Schlüssel beim Onlinedienst. Die Authentifizierung erfolgt durch das Clientgerät, das den Besitz des privaten Schlüssels für den Dienst durch Signieren einer Abfrage nachweist. Die privaten Schlüssel des Clients können nur verwendet werden, nachdem sie vom Benutzer lokal auf dem Gerät entsperrt wurden. Das lokale Entsperren wird durch eine benutzerfreundliche und sichere Aktion erreicht, z. B. durch Wischen eines Fingers, Eingeben einer PIN, Sprechen in ein Mikrofon, Einsetzen eines Geräts mit zweitem Faktor oder Drücken einer Taste.

35
Natanael

Ich habe die Spezifikation noch nicht vollständig erforscht. Aber:

  1. Inwiefern unterscheidet sich U2F grundlegend von OTP?
    U2F verwendet kein OTP. Es geht wirklich um die Site-Authentifizierung und die Verwendung des Besitzes eines privaten Schlüssels als Faktor.

  2. Wie wirkt sich U2F auf die Durchführbarkeit von Phishing-Angriffen im Vergleich zu OTP-Systemen aus?
    Zeitgebundene OTP-Systeme können Phishing (Diebstahl von Anmeldeinformationen) hervorragend bekämpfen, da sie schwer zu stehlen sind. U2F ist wirklich dazu gedacht, MiTM-Angriffe zu bekämpfen.

  3. Wie machbar sind nicht interaktive Angriffe gegen U2F (z. B. Brute-Force usw.)?
    Brute-Force-Angriffe wären nicht der richtige Weg. Sie möchten die Schlüssel stehlen - entweder vom Server oder vom Client. Wie es mit Malware usw. umgeht, ist der Schlüssel. Die Implementierung wird sehr wichtig sein.

  4. Kann ich ein einzelnes U2F-Token mit mehreren unabhängigen Diensten sicher verwenden?
    Sicher - deshalb sind öffentliche/private Schlüssel besser als gemeinsame Geheimnisse.

  5. Wie kann sich U2F gegen andere kommerzielle Angebote behaupten? Gibt es bessere Lösungen?
    Ich kann nur mit uns sprechen, sowohl in unserer kommerziellen als auch in unserer Open-Source-Version. Der Hauptunterschied besteht darin, dass wir einen Hash des SSL-Zertifikats der Zielsite auf dem Authentifizierungsserver speichern und mit einem OTP liefern, das mit dem privaten Schlüssel des Authentifizierungsservers verschlüsselt ist. Bevor der Benutzer das OTP erhält, ruft das Software-Token das Zertifikat der Zielsite über die Verbindung des Benutzers ab, hasht es und vergleicht die beiden. Wenn sie übereinstimmen, wird das OTP angezeigt, in die Zwischenablage kopiert und der Browser mit der URL gestartet. Wenn dies nicht der Fall ist, wird ein Fehler ausgegeben.

    Es sind also keine Änderungen am Server oder Browser erforderlich. Die Schlüssel werden auf einem anderen Server als dem Webserver gespeichert. Das OTP ist Teil des Prozesses (obwohl es entfernt/ausgeblendet werden kann). Es ist Open Source. Auf der anderen Seite hat U2F eine gewisse Dynamik, obwohl es sich um ein Pay-to-Play-Konsortium handelt. U2F ist für einige "sichere" Hardwareangebote verfügbar. Unsere können auf ihnen implementiert werden (z. B. ein Krypto-USB-Laufwerk). YMMV.

    Weitere Informationen zur gegenseitigen Authentifizierung von WiKID finden Sie hier: https://www.wikidsystems.com/learn-more/technology/mutual_authentication und eine Anleitung hier: http: // www. howtoforge.com/prevent_phishing_with_mutual_authentication .

22
nowen

Ich habe gerade einige Spezifikationen gelesen, weil ich wissen wollte, ob das Gerät die tatsächlichen (privaten) Schlüssel speichert. Ich kann versuchen, einige der Fragen zu beantworten.

OTP sind einfach einmalige Token, während U2F auf Kryptografie mit öffentlichen Schlüsseln basiert. Insbesondere scheint der Yubico Fido U2F-Schlüssel eine Kryptographie mit elliptischen Kurven zu verwenden.

U2F sollte zum Schutz vor Phishing-Angriffen beitragen, da Sie die Transaktion durch manuelles Eingreifen, d. H. Drücken der Taste, bestätigen müssen. Das Stehlen der Schlüssel würde das Stehlen des Geräts selbst erfordern, was je nach Speicherort möglicherweise schwieriger ist als bei OTP-Pins. Natürlich sind beide Ansätze immer noch etwas anfällig für MitM-Angriffe. Wenn ein Angreifer irgendwie zwischen Sie und den Dienst geraten und sich in eine laufende Sitzung einmischen kann, kann nicht viel getan werden. Der Datenverkehr sollte verschlüsselt, der Endpunkt überprüft und niemand sollte vollen Zugriff auf Ihren Computer haben. das offensichtliche Zeug.

Ich nehme an, dass die Machbarkeit des Brechens von U2F-Schlüsseln von der Stärke der implementierten Algorithmen für öffentliche Schlüssel auf dem spezifischen Hardwareschlüssel abhängt. Der Yubico-Schlüssel scheint ECDSA auf der elliptischen Kurve des P-256 NIST zu verwenden. Beurteilen Sie selbst, ob die Anzahl der Bits (und die Quelle für die Kurve) ausreichend sicher und zuverlässig sind ...

Das Übersichtsdokument von FIDO erwähnt "Preiswerte U2F-Geräte", die die eigentlichen privaten Schlüssel nicht speichern, sondern verschlüsselt (verpackt) im "Schlüsselhandle" speichern. Dies ist die Kennung, die private und öffentliche Schlüssel miteinander verbindet und an die gesendet wird Remote-Dienste. Wenn ich es richtig verstehe, erhält der Remote-Dienst sowohl den öffentlichen (wie er ist) als auch den privaten Schlüssel (im Schlüsselhandle verschlüsselt), sodass die Sicherheit wirklich mit der Sicherheit des auf dem Hardwaregerät verwendeten Algorithmus steht oder fällt. Die Remote-Site hat Ihre privaten Schlüssel! In gewisser Weise ist es das Gegenteil des Speicherns einer Benutzersitzung, die in einem Cookie verschlüsselt ist. Hier speichert der Remote-Standort die Schlüssel, wobei der private Schlüsselteil verschlüsselt ist und theoretisch nur vom Hardwaregerät entschlüsselt werden kann. Interessanterweise scheint dieses Yubico-Gerät selbst ein solches Gerät zu sein, d. H. Die Schlüssel verlassen das Gerät, anstatt darin enthalten zu sein.

Ich verstehe die wirtschaftlichen und benutzerfreundlichen Gründe - das Speichern vieler Schlüsselpaare auf den Chips in solchen Geräten wäre teurer -, aber ich bin mir nicht sicher, ob mir dieser Ansatz gefällt.

Um auf Ihre Frage zur Verwendung der Token mit mehreren unabhängigen Diensten zurückzukommen: Das Gerät kann so viele Paare generieren, wie es möchte, da die Schlüsselpaare im Dienst selbst gespeichert sind. Wenn Sie sich anmelden, packt das Gerät den privaten Schlüssel aus und überprüft die Signatur. Die Nachricht enthält den Ursprung, daher sollte der Schlüssel nur für diesen bestimmten Dienst funktionieren.

Für hochsichere Zwecke ist es besser, ein Gerät zu verwenden, das die privaten Schlüssel so speichert (oder generiert), dass sie überhaupt nicht abgerufen werden können und das Gerät niemals verlassen. Ich weiß nichts über die elektronische Seite dieser Geräte, aber ich gehe davon aus, dass ein ziemlich hoch entwickelter Angreifer die physische Hardware stehlen und dann knacken müsste, um die Schlüssel zu erhalten, vorausgesetzt, das Gerät verwendet dieselben Chips wie moderne Smartcards , Sims und andere Formen von Hardware-Krypto.

Quellen:

Allgemeine Übersicht: "7. Preiswerte U2F-Geräte zulassen"

Überlegungen zur Implementierung: "U2F-Token speichern möglicherweise kein Material für privaten Schlüssel und exportieren stattdessen möglicherweise einen umschlossenen privaten Schlüssel als Teil des Schlüsselhandles."

Überprüfen Sie auch das FIDO-Dokument "Raw Message Format", auf das ich keinen Link verlinken kann, da ich noch nicht als würdig erachtet werde.

17
wvh

Ein U2F-Token implementiert einen Challenge-Response-Algorithmus unter Verwendung der Kryptographie mit öffentlichem Schlüssel. Es bietet zwei Funktionen: Registrieren eines neuen Ursprungs und Berechnen der Antwort auf eine Herausforderung.

Daher wird die Generierung Einmalkennwort (OTP) nicht implementiert.

Registrieren eines neuen Ursprungs

(Eine Origin-Zeichenfolge identifiziert das Remote-System, z. B. den Hostnamen des Remote-Servers.)

Bei der Registrierung eines neuen Origin verwendet das Token die Origin-Zeichenfolge als Eingabe und gibt sie zurück

  • ein neu generierter öffentlicher Schlüssel (KA),
  • eine Bescheinigungsbescheinigung (d. h. der öffentliche Bescheinigungsschlüssel und eine Signatur über KA unter Verwendung des privaten Bescheinigungsschlüssels),
  • einen Schlüsselgriff (H) und
  • eine Unterschrift (über Origin, KA und H)

mit dem neu erstellten privaten Schlüssel. Das Bestätigungsschlüsselpaar wird von einer Gruppe von Geräten gemeinsam genutzt, die vom selben Hersteller hergestellt und normalerweise von einer bekannten Zertifizierungsstelle signiert werden. Das Schlüsselhandle ist eine Zeichenfolge, die KA identifiziert. Alle diese Elemente werden an den Ursprung gesendet.

Die Herausforderung unterschreiben

Beim Signieren einer Herausforderung (d. H. Generieren der Antwort) verwendet das Token die Origin-Zeichenfolge, Herausforderungsdaten (die Sitzungsinformationen enthalten) und ein Schlüsselhandle als Eingabe.

  • Wenn der Ursprung zum Zeitpunkt der Generierung des Schlüsselhandles nicht mit dem Ursprung übereinstimmt, wird ein Fehler zurückgegeben.
  • Wenn das Schlüsselhandle unbekannt ist, wird ein Fehler zurückgegeben.
  • Andernfalls wird die Signatur über die Herausforderungsdaten und der Wert eines internen Transaktionszählers berechnet (unter Verwendung des privaten Schlüssels, auf den das Schlüsselhandle verweist) und zusammen mit dem Zählerwert zurückgegeben.

Mögliche Token-Implementierungen

  1. Eine gültige U2F-Token-Implementierung verfügt über ein potenziell großes beschreibbares assoziatives Array , bei dem Schlüsselhandles privaten Schlüsseln und Origin-Informationen zugeordnet werden. Dieses Array darf dieses Token nicht verlassen und sollte daher vor dem Auslesen geschützt werden.

    Die U2F-Spezifikation erlaubt nicht die Wiederverwendung privater Schlüssel für unterschiedliche Ursprünge. Daher wird ein großes Array benötigt.

  2. Alternativ kann eine U2F-Token-Implementierung ohne Lese-/Schreibspeicher ist auch möglich : Anstatt den privaten Schlüssel und den Ursprung im Token zu speichern, verschlüsselt das Token sie symmetrisch mit einem internen Schlüssel (K0). Das Ergebnis wird dann einfach als Schlüsselhandle zurückgegeben. In einem vernünftigen Hardware-Design kann K0 das Token nicht verlassen. Mit anderen Worten, der private Schlüssel und die Origin-Zeichenfolge werden extern gespeichert und an die Ursprünge verteilt, da sie als Schlüsselhandles verwendet werden. Dies ist in Ordnung, solange die Verschlüsselung nicht unterbrochen werden kann.

Grundsätzlich implementieren die meisten verfügbaren U2F-Token die zweite Methode und sind daher relativ kostengünstig herzustellen (ab ca. 5 € bei Amazon: Suche nach 'FIDO U2F'). Das Yubikey U2F ist ein Beispiel einer solchen Implementierung.

Anschläge

Unter normalen Umständen sollten Brute-Force-Angriffe nicht durchführbar sein. Ein solcher Angriff wäre der Versuch, den origin-spezifischen privaten Schlüssel brutal zu erzwingen, wenn Sie den öffentlichen Schlüssel kennen.

  • Unter der Annahme, dass ein kostengünstiges U2F-Token verwendet wird, könnte man auch versuchen, den internen Schlüssel (K0) brutal zu erzwingen, wenn Sie das Origin-spezifische Schlüsselhandle kennen. Dies ist nur möglich, wenn der Token-Anbieter einen Konstruktionsfehler gemacht hat. Zum Beispiel, wenn der Anbieter jedes Token mit demselben internen Schlüssel versendet und der Schlüssel irgendwie leckt.
  • Oder wenn der interne Schlüssel K0: für jedes Token unterschiedlich ist, K0 jedoch vom Endbenutzer nicht neu initialisiert werden kann, vom Anbieter beibehalten und (freiwillig oder unfreiwillig) mit einer anderen Partei geteilt wird - dann hat diese Partei weniger Bemühungen, einen Schlüsselgriff (der von einem von diesem Anbieter hergestellten Token stammt) brutal zu erzwingen.
  • Ein weiteres Risiko wäre eine schwache Implementierung eines symmetrischen Verschlüsselungsalgorithmus, der im Token verwendet wird, wodurch das brutale Erzwingen der verschlüsselten Daten im Schlüsselhandle H einfacher wird.

Einige Phishing und Man-in-the-Middle Szenarien sind besiegt , da das U2F-Token den Ursprung überprüft und sitzungsspezifische Daten als Herausforderung verwendet werden.

10
maxschlepzig

Ich finde es sehr schlimm, dass der Benutzer des Tokens nicht sieht, welcher Aktion er tatsächlich zustimmt, indem er die Taste auf seinem Token drückt. Andernfalls kann ein Benutzer mit einem infizierten Betriebssystem auf dem öffentlichen, nicht vertrauenswürdigen PC ein Schadprogramm unabsichtlich auf sein eigenes Bankkonto übertragen, anstatt sich bei Facebook anzumelden.

Das U2F-Protokoll enthält jedoch Informationen zur aktuellen Aktion (URI, AppID und optionale TLS-Kanal-ID). Ich denke, bevor Sie mit der Verwendung dieser Geräte beginnen, ist es sinnvoll, auf das Erscheinen von U2F-Token mit einem kleinen LCD-Bildschirm zu warten, auf dem diese Informationen (mindestens AppID) angezeigt werden, und dann zuzulassen, dass Sie nicht zustimmen, wenn es erweist sich als nicht das, was Sie erwarten.

6