EUCLEAK-Seitenkanalangriff auf die YubiKey-5-Serie

 (ninjalab.io)
1 Punkte von GN⁺ 2024-09-04 | 1 Kommentare | Auf WhatsApp teilen
  • Während Secure Elements als Vertrauensbasis für starke Authentifizierung dienen, ist EUCLEAK ein Seitenkanalangriff, der geheime Schlüssel aus der ECDSA-Implementierung von Infineon extrahiert und auf einem YubiKey 5Ci demonstriert wurde
  • Die zentrale Schwachstelle ist die nicht konstante modulare Inversionsberechnung in der Kryptobibliothek von Infineon, die 14 Jahre lang rund 80 Evaluierungen auf höchstem Common-Criteria-Zertifizierungsniveau bestanden hat
  • Angreifer müssen physischen Zugriff auf das Secure Element haben und benötigen einige lokale elektromagnetische Messungen sowie teure Ausrüstung, maßgeschneiderte Software und technisches Know-how, aber die Messung selbst dauert nur wenige Minuten
  • Betroffen sind die YubiKey 5 Series mit Firmware kleiner 5.7 sowie Sicherheits-Mikrocontroller, auf denen die Kryptobibliothek von Infineon läuft, einschließlich TPMs
  • Bei FIDO ermöglicht die Extraktion von ECDSA-Geheimschlüsseln das Klonen von Geräten, aber zum Schutz vor Phishing ist die Nutzung betroffener Produkte immer noch sicherer, als gar keine zu verwenden

Worauf der EUCLEAK-Angriff abzielt

  • Ein Secure Element ist ein kleiner Mikrocontroller, der geheime Werte erzeugt und speichert sowie kryptografische Operationen ausführt; häufig erhält er Sicherheitsbewertungen auf höchstem Niveau nach Common Criteria
  • FIDO-Hardware-Token sind starke Authentifizierungsmittel für die Anmeldung bei Webdiensten, und das FIDO-Protokoll verwendet ECDSA als zentrales kryptografisches Primitive
  • Die YubiKey 5 Series ist ein weit verbreiteter FIDO-Hardware-Token und verwendet das Infineon SLE78 als Secure Element
  • NinjaLab analysierte die Infineon-ECDSA-Implementierung mit dem Feitian A22, einer ähnlichen offenen JavaCard-Plattform auf Basis des Infineon SLE78, und entwickelte einen praktischen Angriff, der die Seitenkanalschwachstelle ausnutzt
    • Der Angriff wurde auf einem YubiKey 5Ci demonstriert
    • Die Schwachstelle betrifft auch neuere Sicherheits-Mikrocontroller wie Infineon Optiga Trust M und Infineon Optiga TPM
  • Ursache der Schwachstelle ist die nicht konstante modulare Inversion in der Kryptobibliothek von Infineon Technologies, die über 14 Jahre und rund 80 Evaluierungen auf höchstem Common-Criteria-Zertifizierungsniveau unentdeckt blieb
  • Detaillierte technische Unterlagen gibt es unter Download the Writeup

Betroffene Produkte und Angriffsbedingungen

  • Angreifer müssen physischen Zugriff auf das Secure Element haben und können mit einigen lokalen elektromagnetischen Seitenkanalmessungen ECDSA-Geheimschlüssel extrahieren
    • Im FIDO-Protokoll ermöglicht dies das Klonen von FIDO-Geräten
    • Der Angriff erfordert teure Ausrüstung, maßgeschneiderte Software und technisches Know-how
  • Betroffen sind folgende Produkte
    • Alle bestehenden Versionen von Infineon-Sicherheits-Mikrocontrollern mit integrierter Kryptobibliothek von Infineon
    • Bestehende Versionen von Infineon TPMs
    • Alle YubiKey 5 Series mit Firmware kleiner 5.7
  • Diese Sicherheits-Mikrocontroller stecken in vielen sicherheitskritischen Systemen, die auf ECDSA angewiesen sind, darunter elektronische Reisepässe, Hardware-Wallets für Kryptowährungen, Smartcards und Smart-Home-Geräte, aber es ist noch nicht bestätigt, ob EUCLEAK auf diese Produkte in der Praxis anwendbar ist
  • Die Feitian-A22-JavaCard ist ein älteres Produkt, das für die Forschung verwendet wurde und nicht mehr verkauft wird
    • Derzeit im Feitian-Webstore verkaufte Produkte auf Basis von Infineon-Sicherheits-Mikrocontrollern verwenden Feitians eigene Kryptobibliothek und sind nach Kenntnis von NinjaLab nicht von dieser Forschung betroffen

Minderung und offizielle Informationen

  • YubiKey Firmware 5.7 wechselte im Update vom 6. Mai 2024 von der Kryptobibliothek von Infineon auf eine neue Kryptobibliothek von Yubico
    • Nach Kenntnis von NinjaLab ist diese neue Bibliothek nicht von EUCLEAK betroffen
  • Infineon verfügt bereits über einen Patch für die Kryptobibliothek, aber nach Kenntnis von NinjaLab hat dieser noch keine Common-Criteria-Zertifizierungsevaluierung bestanden
  • Der CVE-Antrag wurde abgelehnt, und MITRE verwendet stattdessen CVE-2024-45678
    • Eine Anfrage zur Aktualisierung der Beschreibung ist noch anhängig
  • Die offiziellen Stellungnahmen finden sich in den folgenden Dokumenten

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-09-04
Meinungen auf Hacker News

  • Laut dem Ars-Technica-Artikel braucht ein Angreifer nicht nur Benutzername und Passwort, sondern auch physischen Zugriff auf den Key; außerdem müsste er das Gerät zerlegen und anschließend wieder zusammensetzen, um es zurückzugeben. Das ist also keineswegs ein trivialer Angriff.
    Ein wenig Nagellack auf die Kunststoffnaht aufzutragen, könnte als Canary dienen, um Manipulationen zu erkennen.
    Allerdings zeigt sich auch eine Schwäche von FIDO-Tokens: Man muss selbst eine Liste pflegen, wo man sie registriert hat, und wenn ein Token verloren geht oder gestohlen wird, muss man ihn überall, wo er registriert ist, manuell widerrufen.

    • Das ist kein reines YubiKey-Problem.
      Laut NinjaLab sind alle Infineon-Sicherheitsmikrocontroller, die die kryptografische Bibliothek von Infineon ausführen, in allen bekannten bisherigen Versionen für diesen Angriff anfällig.
      Dazu gehören Chips in elektronischen Reisepässen der USA, Chinas, Indiens, Brasiliens sowie mehrerer europäischer und asiatischer Länder, Sicherheitsbereiche in Smartphones von Samsung und OnePlus, Kryptowährungs-Hardware-Wallets wie Ledger und Trezor, SIM-Karten, TPMs in Laptops von Lenovo, Dell und HP sowie EMV-Chips in Kredit- und Debitkarten.
    • Ich nutze KeePassXC als Passwortmanager und versehe jedes Konto, bei dem ich einen Hardware-Key verwende, mit einem Tag.
      So kann ich schnell eine Liste der Websites erstellen, bei denen ich den Key entfernen muss, falls er verloren geht, gestohlen wird oder kaputtgeht.
      Ich registriere immer zwei Keys und bewahre sie physisch getrennt auf, damit ich mich auch dann noch anmelden kann, wenn ich einen verliere.
    • Ich stimme zu, dass dieser Angriff nicht trivial ist, aber YubiKeys werden mitunter in Umgebungen mit sehr hohem Risiko eingesetzt.
      Dazu gehört nicht nur der Zugriff auf Krypto-Assets, sondern auch ernstere Szenarien wie Rüstungsunternehmen.
      In solchen Fällen haben Angreifer viele Ressourcen und eine starke Motivation, und genau solche Angriffe sollen YubiKeys eigentlich verhindern.
      Der Key bietet also weiterhin phishingresistente Authentifizierung, aber einige Sicherheitserwartungen sind damit als gebrochen anzusehen.
    • Ein Angreifer mit ausreichenden Ressourcen könnte auch einen Backdoor-Ersatz-Key mit demselben ECDSA-Key herstellen.
    • Für Privatpersonen könnte die richtige Einschränkung sein, dieses Gerät nur für zentrale Dienste zu verwenden und sich beim Rest auf gute Passwort-Hygiene zu verlassen.

  • Am ärgerlichsten ist, dass man einen YubiKey nicht einfach austauschen kann.
    Ob man Passkeys oder nicht auffindbare Keys verwendet: Bevor man diesen Key ausmustert, muss man jedes einzelne Konto durchgehen und auf einen neuen, nicht anfälligen Key umstellen.
    Dass es sich um nicht auffindbare Keys handelt, ist ebenfalls ein Problem, weil man sich nicht daran erinnert, wo man den YubiKey früher überall eingesetzt hat.
    Im Ars-Artikel [0] geht es auch um PINs, aber das ist keine YubiKey-spezifische Funktion, sondern eine FIDO-Funktion.
    [0]: https://arstechnica.com/security/2024/09/yubikeys-are-vulner...
    [1]: https://new.reddit.com/r/yubikey/comments/12bv4sv/fido_pin_s...

    • Ein anderer Aspekt: Wegen der Zwei-Faktor-Authentifizierung, dem Hauptanwendungsfall nicht auffindbarer FIDO-Keys, mache ich mir eher Sorgen, aus Konten ausgesperrt zu werden.
      Das ist mir tatsächlich passiert, als der US-Zoll einmal elektronische Geräte einschließlich meines YubiKey einbehalten hat.
      Später konnte ich viele Konten wiederherstellen, bei denen E-Mail als zweiter Faktor oder als letztes Authentifizierungsmittel akzeptiert wurde, aber bei einigen, darunter AWS, ging das nicht.
      Viele Websites empfehlen die Einrichtung von Zwei-Faktor-Authentifizierung, ohne klar zu erklären, welche alternativen Authentifizierungsmethoden es gibt und welche Folgen ein Zugriffsverlust hat.
    • Ich verfolge das im Passwortmanager.
      Konten, bei denen ein YubiKey registriert ist, bekommen das Tag „YubiKey (FIDO)“.
    • Bei Websites wie GitHub, die residente WebAuthn-Tokens verwenden, kann man auf dem Key eine Liste bekannter Websites anzeigen.
      Die User Experience dieses gesamten Ablaufs liegt allerdings noch nicht auf dem Niveau, das man erwarten würde.
    • Ich mochte schon immer nicht, dass man einen persönlichen YubiKey nicht klonen oder sichern kann, und habe ihn deshalb nicht überall verwendet.
    • Ich habe noch keine Website gesehen, die bei der Registrierung eines FIDO-Geräts nicht verlangt, auch eine andere Form der Zwei-Faktor-Authentifizierung einzurichten.
      In meinem Fall habe ich zusätzlich TOTP in einer App hinterlegt.

  • Wenn „alle YubiKey 5 Series mit Firmware unter 5.7 betroffen sind“, dachte ich zunächst, man müsse nur die Firmware des physischen Hardware-Tokens aktualisieren.
    Dort steht aber, dass YubiKey-Firmware nicht upgradefähig ist.
    https://support.yubico.com/hc/en-us/articles/360013708760-Yu...
    Dann wird Yubico doch wohl kostenlosen Ersatz anbieten? Ich habe ein paar solcher YubiKeys …

    • YubiKeys wurden zur Abwehr von Phishing entwickelt, und dieser Angriff erfordert physischen Zugriff.
      Wenn man also in der realen Welt wertvoll genug ist, um direkt ins Visier zu geraten, sollte man von vornherein keinen YubiKey verwenden.
      Jemand könnte einen Ersatz-Key austauschen, und man bemerkt es womöglich erst, wenn es zu spät ist.
    • Ich nutze einen 5.4.3 5C Nano; kostenlosen Ersatz gibt es nicht, nur Abhilfemaßnahmen.
      https://support.yubico.com/hc/en-us/articles/15705749884444-...
    • Als es beim letzten Mal einen kryptobrechenden Bug in Infineon-Chips gab, bekamen estnische Bürger kostenlos neue ID-Karten.
      Mein YubiKey 4 hingegen, der noch keine zwei Monate auf dem Markt war, funktionierte nicht mehr als PIV-Smartcard mit Hardware-Attestation.

  • Dass es „an einer modularen Inversenberechnung liegt, die nicht in konstanter Zeit läuft“, ist kein subtiler Seitenkanal wie winzige Funkemissionen.
    Ob sich die Laufzeit abhängig von geheimen Daten ändert, gehört zu den ersten Dingen, die man bei einem Seitenkanal-Audit prüfen sollte.
    Man muss verifizieren, ob alle Operationen unabhängig von den Daten immer dieselbe Anzahl an Taktzyklen verbrauchen, und auch Fehler müssen nach einer festen, datenunabhängigen Anzahl von Taktzyklen auftreten.
    Ich frage mich, wie die Auditoren das übersehen konnten.

    • Genau genommen wirkt es eher wie so ein Funk-Seitenkanal.
      Wenn ich das Paper richtig verstanden habe, ist nicht die Ausführung des Algorithmus selbst nicht konstant, sondern der von außen beobachtbare Duty Cycle des RF-Seitenkanals.
      Wäre die Laufzeit wirklich nicht konstant, wäre der Angriff im schlimmsten Fall schon nur über USB möglich gewesen; die Infineon-Implementierung scheint aber nicht für reine Timing-Angriffe anfällig zu sein.
      Nonce-Blinding ist ebenfalls implementiert, das Problem ist aber, dass eine Multiplikationsmaske verwendet wird, die viel kleiner als die Größe der elliptischen Kurve ist und sich daher per Brute Force durchsuchen lässt.
    • Das ist eines der ersten Dinge, die man bei einem ECDSA-Code-Review prüft; aus Infineons Sicht also ein peinlicher Fehler.
    • Zustimmung. Ich hatte einen wirklich ausgefeilten Angriff erwartet, aber es ist eher ein Standard-Timing-Angriff mit einer schicken Probe.
      Die Probe selbst ist trotzdem cool.

  • Wenn jemand schon so weit geht, physischen Zugriff auf einen YubiKey zu bekommen, kann er ihn auch gegen einen ähnlich abgenutzten und ähnlich aussehenden Key austauschen.
    Dann glaubt das Opfer entweder, sein YubiKey sei kaputt, oder der Angreifer gewinnt genug Zeit, um den YubiKey zu benutzen.
    Ich habe zum Beispiel zwei YubiKeys; wenn jemand heimlich in mein Haus einbricht und den Ersatz-Key austauscht, würde ich es nicht merken, bis ich den Ersatz-Key benutze.
    Letztlich ist dieser Angriff nur sinnvoll, wenn das Ziel wertvoll genug ist, um es direkt ins Visier zu nehmen; und so ein Ziel würde vermutlich etwas Sichereres als einen YubiKey verwenden.

    • Mit ykman list kann man die Identifikationsdaten eines YubiKey prüfen, daher lässt sich leicht ein Verfahren einrichten, um zu kontrollieren, ob der Key kaputt ist oder tatsächlich ausgetauscht wurde.
      Bei hohen Sicherheitsanforderungen kann man das regelmäßig prüfen oder den physischen Aufbewahrungsort des Ersatz-Keys separat schützen.
      Mich würde auch interessieren, welche Hardware-Authenticatoren sicherer als ein YubiKey sein sollen.
    • Wenn man Zugriff hat, ist es wirklich einfach, den Key zu zerstören und ihn durch einen funktionierenden Ersatz-Key zu ersetzen.
    • In der Praxis dürfte der YubiKey selten das schwächste Glied in der Kette sein.
      Ein Angreifer kann das Gerät angreifen, die Kommunikation abfangen oder den Dienst, der die Daten hostet, per Gerichtsbeschluss zur Herausgabe zwingen oder heimlich infiltrieren.

  • EUCLEAK-Erklärungs-PDF: https://ninjalab.io/wp-content/uploads/2024/09/20240903_eucl...
    Yubico-Blogbeitrag: https://www.yubico.com/support/security-advisories/ysa-2024-...

  • Die Arbeit von NinjaLab ist hervorragend.
    Besonders interessant an Yubicos Advisory ist, dass diese lokale Klonung auch die Attestation [1] des WebAuthn-Protokolls aushebelt.
    Hätte man das Protokoll so entwerfen können, dass es gegen diesen lokalen Klonangriff besser standhält?
    „Ein Angreifer kann den wiederhergestellten Attestation Key verwenden, um einen gefälschten YubiKey zu erstellen. In diesem Fall wird während make credential eine gültige FIDO-Attestation Statement erzeugt, wodurch die von Organisationen gesteuerte Präferenz für Authenticator-Modelle für betroffene YubiKey-Versionen umgangen werden kann.“

    1. https://www.w3.org/TR/webauthn-2/#attestation
    • Wenn ein Angreifer das Geheimnis klont, das zum Signieren von Anfragen verwendet wird, scheint es keine Möglichkeit zu geben, Kopie und Originalgerät zu unterscheiden, sobald er dieses Geheimnis besitzt.
      Das gesamte Sicherheitsmodell eines Secure Elements besteht darin, die Extraktion des Schlüssels zu verhindern; wenn das möglich wird, ist es nicht besser, als den Schlüssel in einer Datei auf dem Computer zu speichern.
      Natürlich muss man das Gerät physisch öffnen, um an den Schlüssel zu kommen, daher ist es immer noch sicherer als die Speicherung auf dem Computer, solange niemand den Key tatsächlich mitnimmt.
    • Leider ist das realistisch betrachtet schwierig. Attestation beruht fast immer darauf, dass irgendeine sichere Hardware ein vom Aussteller zertifiziertes Geheimnis schützt, sich damit gegenüber einer Relying Party authentifiziert und das Vertrauen über abgeleitete und gespeicherte Geheimnisse fortführt.
      Wenn dieses Attestation-Geheimnis auf irgendeine Weise extrahierbar ist, kann man nicht verhindern, dass ein Angreifer einen gefälschten Authenticator baut, der betrügerische Attestations erzeugt, ohne sich wie ein echter zu verhalten.
      Theoretisch könnte man mit indirekter Attestation oder pro Authenticator eindeutigen Attestation Keys die Auswirkungen eines einzelnen kompromittierten Attestation-Geheimnisses verringern.
      Das wäre ein anderer Ansatz als bei YubiKey, wo Hunderttausende Authenticatoren einen Attestation Key teilen, dürfte aber dennoch nur eine probabilistische Abschwächung sein.

  • Auf der Yubico-Website steht, dass 5.7 und neuer nicht betroffen sind.
    In einem anderen Yubico-Beitrag [1] heißt es, eine der Funktionen des 5.7-Releases sei die Migration auf eine Yubico-eigene Kryptobibliothek für die zugrunde liegenden kryptografischen RSA- und ECC-Operationen.
    Ich hoffe, dass viele Leute darauf geschaut haben. In einer Zeit, in der es so viele öffentliche und private Implementierungen gibt, verstehe ich nicht ganz, warum man eine eigene Kryptobibliothek verwenden will.
    [1] https://www.yubico.com/blog/now-available-for-purchase-yubik...

    • Weil es das zweite Mal ist, dass ein Sicherheitsproblem durch einen Zulieferer entstanden ist, und das letzte Mal war es noch gravierender.
      Wenn das ganze Unternehmen auf Kryptografie basiert, ergibt es tatsächlich Sinn, genügend angewandte Kryptografen einzustellen und das eigene Schicksal selbst zu kontrollieren.
    • Auf Embedded-Plattformen sind bestehende Bibliotheken möglicherweise nicht portiert, oder die Plattform ist so anders, dass eine Portierung unrealistisch ist.
      Es kann auch andere Gründe geben, und bei Closed Source spielen wirtschaftliche Überlegungen eine große Rolle.
      Besonders dann, wenn man von einer früheren proprietären, vermutlich mit Quellcode gelieferten Zulieferer-Implementierung auf eine interne Implementierung umsteigt.
    • Wann wurde 5.7 veröffentlicht?

  • Infineon hat es wieder geschafft. Vor 7 Jahren gab es schon einmal so etwas: https://en.wikipedia.org/wiki/ROCA_vulnerability

  • „Infineon hat zwar bereits einen Patch für die Kryptobibliothek, dieser hat meines Wissens aber noch nicht die Common-Criteria-Zertifizierungsevaluierung bestanden“ – ehrlich gesagt ist das überhaupt nicht wichtig

    • Unabhängig vom Angriff selbst ist es ein interessantes Experiment und eine Veröffentlichung wert, aber in der Praxis scheinen selbst nominell anfällige Geräte keine großen Auswirkungen in der realen Welt zu haben