Frage:
Wie sicher sind die FIDO U2F-Token?
tylerl
2014-10-22 10:55:07 UTC
view on stackexchange narkive permalink

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

Speziell:

  • Inwiefern U2F unterscheidet sich 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?
  • Wir müssen zwischen dem U2F-Protokoll und aktuellen U2F-Geräten unterscheiden. Das U2F * -Protokoll * schützt Sie mit allen Geräten vor Phishing, wenn der Benutzeragent nicht gefährdet ist. Da aktuelle U2F-Geräte jedoch keinen Bildschirm haben, können Sie phishing werden, wenn der Benutzeragent gefährdet ist. Es kann Sie glauben machen, dass Sie sich bei Dienst A anmelden, Sie drücken die Taste, aber tatsächlich melden Sie sich bei Dienst B an. Dies kann durch kein Protokoll behoben werden, das Gerät benötigt einen Bildschirm. Das U2F-Protokoll schränkt Geräte jedoch nicht ein, um diese zusätzliche Sicherheit zu bieten. Dies wurde auch [von Mathieu Stephan hervorgehoben] (http://goo.gl/bBPvM0).
    @user10008 gibt es per Definition keine Möglichkeit, sich vor einem kompromittierten Benutzeragenten zu schützen. Selbst wenn Sie den Anmeldeschritt schützen können, kann ein Man-in-Browser-Angriff einfach still warten, bis die Authentifizierung erfolgreich abgeschlossen wurde, und dann den böswilligen Datenverkehr mithilfe der ordnungsgemäß authentifizierten Sitzung einfügen. Dies liegt außerhalb des Bereichs eines Authentifizierungssystems, da die Authentifizierung nicht beeinträchtigt werden muss. Ein Bildschirm im Gerät kann hier keine sinnvolle Perfektion bieten.
    Ja, kann es. Wenn ein Bildschirm vorhanden ist und ich mich an einem möglicherweise kompromittierten Computer (z. B. einem Internetcafé) befinde, weiß ich, ob ich Zugriff auf mein Online-Banking (auf das ich vom Internetcafé aus niemals zugreifen würde) oder auf ein unwichtiges Konto gebe.
    @user10008, eh. OK. Das ist jedoch kein wirklich glaubwürdiges Szenario. Mit Sicherheit keine, die besondere Designüberlegungen und eine 10-fache Erhöhung der Hardwarekosten rechtfertigt. Der intelligente Benutzer würde eine kompromittierte Workstation * überhaupt * nicht wissentlich verwenden, und eine vernünftige Sicherheitslage würde sie vollständig verbieten und nicht versuchen, sie sicher unterzubringen.
    Obwohl ich es immer noch für sehr wahrscheinlich halte, stimme ich dem von Ihnen vorgebrachten Kostenargument zu. Ein niedriger Preis ist einer der Vorteile von U2F. Als alternative Lösung für das Problem kann ich mir vorstellen, Smartphones (mit Bildschirmen) als U2F-Tasten (oder Relais) für nicht vertrauenswürdige Workstations zu verwenden. Ich denke, U2F ist etwas sehr Großartiges und der Schritt von manuell eingegebenen Dezimalcodes zu binären Drahtübertragungen war eine sehr gute Entscheidung.
    Wenn @tylerl sieht, dass das Gerät eine Bestätigung über die Anmeldung bei einem anderen Dienst anfordert, kann dies einen Kompromiss aufzeigen.
    Kundenzertifikate gibt es seit Jahrzehnten und sie sind viel besser als diese.
    @AndréBorie dies wurde diskutiert, und nein, Client-Zertifikate erfüllen nicht die gleiche Rolle. Kundenzertifikate haben ihren Platz, aber das ist es nicht.
    -1
    Diese Frage wurde ziemlich gut beantwortet, aber da diese Frage gestellt (und beantwortet) wurde, hat Google ein Papier zu diesem Thema veröffentlicht, das alle im ursprünglichen Beitrag gestellten Fragen und viele weitere beantwortet.Siehe http://fc16.ifca.ai/preproceedings/25_Lang.pdf
    Sechs antworten:
    #1
    +88
    tylerl
    2014-10-27 11:55:07 UTC
    view on stackexchange narkive permalink

    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.

    Warum also nicht SSL-Client-Zertifikat? Das sollte auch MITM mildern.
    @phoeagon: Wurde versucht; Normale Zertifikate sind kompliziert zu verwenden, leicht zu verlieren (die Leute vergessen, sie vor der Neuinstallation zu exportieren, Angreifer können sie leicht exportieren usw.), und die Art und Weise, wie TLS sie verwendet, wurde kürzlich als anfällig für ähnliche Angriffe befunden. (Ich kann mich überhaupt nicht erinnern, wo genau ich das gesehen habe.)
    @grawity Ich denke, es ist ein bisschen sicherer, sich vor Superfischen zu schützen. Es stimmt, dass Sie nicht konsequent garantieren können, wenn eine Seite kompromittiert wird, aber angesichts der Tatsache, dass die PCs der Benutzer viel anfälliger sind, kann die Implementierung eine Menge Grunzarbeit bedeuten. (und ja leider grunzarbeit auch für benutzer)
    Dies ist eine fantastische Version von Phishing. Ich bin ziemlich verärgert über "Lösungen", die vorschlagen, Benutzerzeit zu verbrauchen, um Phishing zu erkennen, da sie psychisch und wirtschaftlich anstrengend sind.
    @grawity Hier ist ein ausgezeichneter Artikel, der die Probleme mit Client-Zertifikaten beschreibt: http://www.browserauth.net/tls-client-authentication
    "Alles, was Sie tun müssen, ist den Browser einzubeziehen ..." ist ein wenig irreführend, da dieser Prozess von Benutzeragenten ausgeführt werden kann (und wird), die keine Browser sind.
    @grawity, In letzter Zeit versuchen sie auch, TLS neu zu erstellen, daher sind die gegenwärtigen TLS-Schwachstellen nicht ** inhärent ** und können in Zukunft behoben werden.Während Hardware-Token sicherer und in Situationen mit hohen Einsätzen sinnvoll sein können, ist es nicht überzeugend, dass es sich um eine praktikable Lösung oder eine realisierbare Alternative handelt, ** im Allgemeinen ** für die Massen.
    @tylerl, Wie passt diese Lösung zu SecurID von RSA? Http://www.cnet.com/news/rsa-cyberattack-could-put-customers-at-risk/
    @tylerl, Übrigens, wollen Sie damit sagen, dass Sie nicht im Sicherheitszweig von Google arbeiten, oder möchten Sie damit sagen, dass Sie im Sicherheitszweig arbeiten, aber nicht speziell im u2f-Zweig?
    @Pacerier Wie wäre es mit: "Zum Zeitpunkt des Schreibens dieser Antwort habe ich noch keinen Beitrag zum Sicherheitsschlüsselprojekt geleistet.":) :)
    Die SecurID von @Pacerier RSA ist nur ein OTP-Gerät.
    #2
    +35
    Natanael
    2014-10-22 15:35:48 UTC
    view on stackexchange narkive permalink

    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.

    #3
    +23
    nowen
    2014-10-22 18:20:08 UTC
    view on stackexchange narkive permalink

    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.

    4. ol>
    Ein großes Dankeschön für die Offenlegung Ihrer Beziehung zu einem kommerziellen Produkt. Es hilft wirklich, Relevanz und Kontext bereitzustellen.
    Ich hoffe, Sie sind nicht sarkastisch. Manchmal ist es nicht einfach, Beiträge zu leisten, selbst wenn Open-Source-Software veröffentlicht wird. "Betrachten Sie die Quelle" ist wichtig. Jeder ist irgendwie voreingenommen. Ich werde sagen, dass ich nicht glaube, dass es viele Lösungen gibt, die auf diesen Bereich abzielen. Hauptsächlich b / c ist die Bankenbranche in NA kein sehr guter Markt für Anbieter - es gibt relativ wenige Käufer.
    Nein! Total dankbar! Wir bringen die Leute dazu, ihre eigenen Sachen zu shillen, und das schafft Komplikationen. Das Internet muss diese Sarcasm-Schrift wirklich entwickeln.
    Darüber hinaus hat mir Ihre Antwort wirklich geholfen und es mir ermöglicht, mit Leuten in meinem Unternehmen über U2F zu sprechen.
    Angesichts der Antwort des OP, das sich stark auf Phishing konzentriert, denke ich, dass Ihre (2) (die derzeit zu sagen scheint, dass U2F nichts über zeitgebundene OTP-Systeme hinzufügt) geändert werden muss. Wie das OP sagt: "Angreifer erfassen tatsächlich Second-Factor-Antworten, die an Phishing-Sites gesendet werden, und spielen sie sofort auf der echten Anmeldeseite ab." Siehe zum Beispiel (seit kurzem) https://www.seancassidy.me/lostpass.html, in dem auch der TOTP-Code (Google Authenticator) angezeigt wird.
    #4
    +17
    wvh
    2014-10-24 18:12:39 UTC
    view on stackexchange narkive permalink

    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:

    +1 für die Erwähnung des privaten Schlüssels wird aus wirtschaftlichen Gründen * nicht * auf dem Yubikey gespeichert.Kennen Sie ein FIDO-kompatibles Gerät, das die privaten Schlüssel anstelle des Schlüsselhandles speichert?
    Ich verstehe nicht, warum das überhaupt wirtschaftlich ist.Sind private Schlüssel nicht unter einem Megabyte und würden die meisten Leute dies nicht mit weniger als zwei Dutzend Sites verwenden?Lagerung ist nicht so teuer ...
    Die Menge an dauerhaftem Speicher, die Sie auf einen typischen Yubikey passen könnten, wäre immer noch recht begrenzt und würde das Gerät weiter komplizieren.Da auf dem Gerät selbst kein Speicherplatz vorhanden ist, können Sie tatsächlich lebenslange Dienste in Anspruch nehmen, anstatt sich plötzlich zu einem scheinbar zufälligen Zeitpunkt zu weigern, ein neues Schlüsselpaar zu registrieren.Auf jedem Gerät, das bei der Erstellung des Schlüsselpaars für jeden Dienst verwendet wird, gibt es einen einzigen eindeutigen privaten Schlüssel.Dieser Schlüssel kann nicht abgerufen werden, und das Herausfinden des nächsten zu generierenden Schlüssels ist daher selbst bei offensichtlichen physischen Kompromissen eines Schlüssels äußerst schwierig.
    #5
    +10
    maxschlepzig
    2016-01-02 04:00:35 UTC
    view on stackexchange narkive permalink

    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.

    3. 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.

    #6
    +6
    Ivan from Russia
    2015-10-08 05:50:20 UTC
    view on stackexchange narkive permalink

    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.

    Guter Punkt. Ohne Bildschirm gibt es wenig Sicherheit für Transaktionen und gegen Malware.
    Das [Trezor] (https://trezor.io) hat einen Bildschirm und unterstützt U2F. Der Benutzer muss die Anmeldung bestätigen.


    Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
    Loading...