Die Antworten, die ich erhalten habe, waren gut, aber ich wollte etwas 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 zum Zeitpunkt der Erstellung dieser Antwort nichts über dieses Projekt. Alles, was hier berichtet wurde, wurde aus öffentlichen Quellen gesammelt. Dieser Beitrag enthält meine eigenen Meinungen, Beobachtungen und Kommentare und gibt nicht die Meinungen, Ansichten oder Absichten von Google wieder.

Es lohnt sich jedoch darauf hinzuweisen, dass ich ihn verwendet habe Dies und das Basteln daran seit geraumer Zeit, und als jemand, der sich viel mit Social Engineering und Kontoübernahmen beschäftigt hat, bin ich überproportional beeindruckt von dem, was hier erreicht wurde.

Warum etwas Neues benötigt wurde

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 und das Geld des Unternehmens für Design, Entwicklung, Bereitstellung und Support gelohnt hat ein Ersatzsystem, 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 verbreitet 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 was noch wichtiger ist:

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 vor Phishing-Angriffen während der Nutzung. Ein Einmalkennwort ist immer noch ein Kennwort und kann einem Angreifer mitgeteilt werden.

Und dies ist nicht nur theoretisch. Wir haben gesehen, dass diese Angriffe tatsächlich ausgeführt wurden. Angreifer erfassen tatsächlich Second-Factor-Antworten, die an Phishing-Sites gesendet werden, und spielen sie sofort auf der realen Anmeldeseite ab. Dies geschieht derzeit tatsächlich.

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. Sie müssen es herausfinden.

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

Es ist überraschend einfach, eine Second-Factor-Lösung zu erstellen, die nicht phishingfähig ist. Alles was Sie tun müssen, ist den Browser einzubeziehen. Bei 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 effektiven Einsatz dieses Geräts wird Phishing als Möglichkeit eliminiert. Dies ist eine große Sache für ein sicherheitsrelevantes Unternehmen.

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 erforderlich

Natürlich hätte Google diese Position nutzen können geben sich einen Wettbewerbsvorteil auf dem Markt, aber sie haben 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 würden. Ein Schlüsselmerkmal des Protokolls ist, dass das Token zu keinem Zeitpunkt sich identifiziert. Tatsächlich besagen die Spezifikationen, dass dieses Design ausgewählt wurde, um die Möglichkeit zu verhindern, dass ein "Supercookie" erstellt wird, mit dem Sie zwischen kolludierenden Diensten verfolgt werden können.

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

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 dasselbe Gerät verwendet haben beide. Es soll sicher sein.

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

Aus der 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.

Ich habe die Spezifikation noch nicht vollständig untersucht. 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.

   li

   Wie wirkt sich U2F auf die Durchführbarkeit von Phishing-Angriffen im Vergleich zu OTP-Systemen aus?
   Zeitgebundene OTP-Systeme leisten hervorragende Arbeit bei der Bekämpfung Phishing (Anmeldeinformationen stehlen), weil sie schwer zu stehlen sind. U2F ist wirklich dazu gedacht, MiTM-Angriffe zu bekämpfen.

2. Wie machbar sind nicht interaktive Angriffe gegen U2F (z. B. Brute-Force usw.)?
   Brute-Force-Angriffe wären nicht wirklich möglich der Weg, den man gehen sollte. 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.

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

   li

   Wie kann sich U2F gegen andere kommerzielle Angebote behaupten? Gibt es bessere Lösungen?
   Ich kann nur mit unseren 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 angezeigt.

   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 Schwung, 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.

ol>

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 die Yubico Fido U2F-Taste 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.

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", in denen jedoch nicht die tatsächlichen privaten Schlüssel gespeichert sind Speichern Sie sie verschlüsselt (verpackt) im "Schlüsselhandle", der Kennung, die private und öffentliche Schlüssel miteinander verbindet und an Remotedienste gesendet wird. 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 von Speichern der Sitzung eines Benutzers, 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, dh die Schlüssel verlassen das Gerät, anstatt darin enthalten zu sein.

Ich verstehe die wirtschaftlichen und benutzerfreundlichen Motivationen - das Speichern vieler Schlüssel Paare auf den Chips in solchen Geräten wären 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 beliebig viele Paare generieren, 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) kann überhaupt nicht abgerufen werden und verlässt das Gerät nie. 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 der Hardware-Krypto.

Quellen:

• Allgemeiner Überblick: "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".

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 keine One Time Password (OTP) - Generierung implementiert.

Registrieren eines neuen Ursprungs

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

Beim Registrieren eines neuen Ursprungs übernimmt das Token die Ursprungszeichenfolge als Eingabe und Rückgabe

• eines neu generierten öffentlichen Schlüssels (KA),
• eines Attestierungszertifikats (dh des öffentlichen Attestierungsschlüssels und einer Signatur über KA unter Verwendung des privaten Attestierungsschlüssels) ,
• ein Schlüsselhandle (H) und
• eine Signatur (über dem Ursprung, KA und H)

unter Verwendung des neu erstellten Privat Schlüssel. Das Attestierungsschlü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.

Signieren der Herausforderung

Beim Signieren einer Herausforderung (dh Generieren der Antwort) verwendet das Token die Ursprungszeichenfolge, Herausforderungsdaten (mit Sitzungsinformationen). 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 ebenso zurückgegeben wie Der Zählerwert.

Mögliche Token-Implementierungen

1. Eine gültige U2F-Token-Implementierung verfügt über ein potenziell großes beschreibbares assoziatives Array Dabei werden Schlüsselhandles privaten Schlüsseln und Ursprungsinformationen zugeordnet. 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 verschiedene Ursprünge. Daher wird ein großes Array benötigt.

2. Alternativ ist auch eine U2F-Token-Implementierung ohne Lese- / Schreibspeicher möglich: Anstatt das Private zu speichern Schlüssel und der Ursprung innerhalb des Tokens, das Token verschlüsselt 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 Ursprungszeichenfolge 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.

ol>

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 für eine solche Implementierung.

Angriffe

Unter normalen Umständen sollten Brute-Force-Angriffe nicht durchführbar sein. Ein solcher Angriff wäre der Versuch, den originenspezifischen 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 brutal zu erzwingen Schlüssel (K0), wenn Sie das originenspezifische 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 ist: für jedes Token unterschiedlich, aber K0 kann nicht neu initialisiert werden vom Endbenutzer, wird vom Anbieter behalten und (freiwillig oder unfreiwillig) mit einer anderen Partei geteilt - dann hat diese Partei weniger Aufwand, einen Schlüsselgriff (der von einem von diesem Anbieter erstellten 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 verwendet werden als Herausforderung.

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 zu aktuellen Aktionen (URI, AppID und optionale TLS-Kanal-ID). Ich denke, bevor Sie diese Geräte verwenden, ist es sinnvoll, auf das Erscheinen von U2F-Token mit einem kleinen LCD-Bildschirm zu warten, auf dem diese Informationen angezeigt werden (zumindest AppID), und dann zuzulassen, dass keine Maßnahmen ergriffen werden, wenn sich herausstellt, dass dies nicht der Fall ist Sie erwarten.