ed25519-unsafe-libs

Double Public Key Signing Function Oracle Attack auf Ed25519

Eine Liste potenziell unsicherer Ed25519-Signatur-Bibliotheken, die eine öffentliche API bereitstellen, bei der geheimer und öffentlicher Schlüssel unabhängig voneinander als Eingaben für die Signierfunktion angegeben werden können. Eine missbräuchliche Verwendung dieser öffentlichen APIs kann zur Offenlegung des privaten Schlüssels führen.

Die meisten Repositories in unserer Analyse sind in IANIX :: Things that use Ed25519 aufgeführt.

Anzahl betroffener Bibliotheken: 45
Anzahl der Bibliotheken, die das Problem nach der Ankündigung behoben haben: 8
zuletzt aktualisiert: 4. Mai 2023

Proof-of-Concept-Implementierungen, die diesen potenziellen Exploit demonstrieren:

• Rust: ed25519-chalkias-exploit
• Python: Ed25519 Vulnerability in Python, Buchanan, William J (2022). Ed25519 Vulnerability in Python (Recovering Private Key). Asecuritysite.com.

Vorträge:

• Eingeladener Vortrag beim Crypto Reading Club des US-amerikanischen National Institute of Standards and Technology (NIST): Folien – Taming the Many EdDSAs (Seiten 28–39), Konstantinos Chalkias, François Garillot, Valeria Nikolaenko (2023). Taming the Many EdDSAs & Ed25519 Signing Attacks.

Nachrichten- und Social-Media-Berichterstattung zu diesem Angriff

• NIST Crypto Reading Club „Taming the Many EdDSAs" (8. März 2023)
• The Daily Swig „Dozens of cryptography libraries vulnerable to private key theft" (28. Juni 2022)
• Risky Biz News „New crypto vulnerability: Tens of cryptography libraries have misimplemented the Ed25519 digital signature algorithm" (28. Juni 2022)
• SafeHeron-Blogbeitrag „Analysis on Ed25519 Use Risks: Your Wallet Private Key Can Be Stolen" (17. Juni 2022)
• kryptera.se „Vulnerability in most ed25519 libraries" (auf Schwedisch) (29. Juni 2022)
• Difesa e Sicurezza und Yoroi „Librerie crittografiche ed25519 potenzialmente non sicure" (auf Italienisch) (1. Juli und 29. Juni 2022)
• Medium-Beitrag von Prof. Bill Buchanan OBE „Ed25519 is Great, But ..." (1. Juli 2022)
• Reddit r/crypto (bester Beitrag des Monats – 18. Juni 2022)
• Reddit r/cryptography (17. Juni 2022)
• Interessante Tweets:
  • Tweet 1 (von Kostas Kryptos – „The original 26 vulnerable libs")
  • Tweet 2 (von Kostas Kryptos – „Aftermath of the 40 vulnerable libs")
  • Tweet 3 (von Catalin Cimpanu – „40 cryptography libraries are impacted by same Ed25519 misimplementation")

Worum geht es?

Beachte, dass EdDSA-Signaturen gemäß der zugehörigen rfc8032 normalerweise deterministisch sind. Für dieselbe zu signierende Eingabenachricht wird also eine eindeutige Signaturausgabe zurückgegeben, die zwei Elemente enthält: einen Kurvenpunkt R und einen Skalar S.

Ein algorithmisches Detail ist, dass der öffentliche Schlüssel des Unterzeichners nur in die deterministische Berechnung des S-Teils der Signatur einfließt, nicht jedoch in den R-Wert. Das bedeutet, dass ein Angreifer, wenn er die Signierfunktion irgendwie als Orakel nutzen könnte (das beliebige öffentliche Schlüssel als Eingaben erwartet), für dieselbe Nachricht zwei Signaturen erhalten könnte, die dasselbe R teilen und sich nur im S-Teil unterscheiden. Wenn dies geschieht, kann man leider leicht den privaten Schlüssel extrahieren; dieser StackOverflow-Beitrag erklärt, warum dies machbar ist.

Öffentliche APIs sollten es daher NICHT erlauben, ein entkoppeltes privates/öffentliches Schlüsselpaar als Signiereingabe zu verwenden. Um dies zu umgehen, speichern viele Implementierungen den öffentlichen Schlüssel zusammen mit dem privaten Schlüssel (oder Seed) und behandeln das gesamte Schlüsselpaar als Geheimnis, ODER sie leiten den öffentlichen Schlüssel innerhalb der Signierfunktion immer neu ab. Leider versäumen es zahlreiche bestehende Bibliotheken, dieses Problem zu beheben, indem sie beliebige öffentliche Schlüssel als Eingaben zulassen, ohne zu prüfen, ob der eingegebene öffentliche Schlüssel zum eingegebenen privaten Schlüssel gehört.

Natürlich bedeutet das nicht, dass alle Anwendungen mit Abhängigkeiten zu diesen Bibliotheken anfällig für Schlüsseloffenlegungsangriffe sind; tatsächlich sind die meisten wahrscheinlich sicher, weil sie die betroffene API ihren Benutzern normalerweise nicht öffentlich zugänglich machen und ihr öffentliches/privates Schlüsselpaar direkt vor dem sign-Aufruf koppeln. Andererseits gibt es selbst dann, wenn diese APIs nicht exponiert sind, Anwendungen mit unterschiedlichen TCB-Bedrohungsmodellstrategien, wie private und öffentliche Schlüssel verwaltet und gespeichert werden. Um diesen Angriff zu verhindern, sollten Entwickler daher auch ein Integritätsschutzprotokoll für die öffentlichen Schlüssel durchsetzen.

Hier listen wir einige betroffene Bibliotheken zusammen mit den zugehörigen Code-Referenzen auf.

Abb. 1. Ein Beispiel für API-Missbrauch in der Rust-Crate ed25519-dalek.

Betroffene Bibliotheken

• C: OpenGNB
  https://github.com/gnbdev/opengnb/blob/master/libs/ed25519/sign.c#L7

• C: GNU Nettle
  https://github.com/gnutls/nettle/blob/fe7ae87d1b837e82f7c7968b068bca7d853a4cec/ed25519-sha512-sign.c#L43

• ASM/C: iroha-ed25519 (Hyperledger Project)
  https://github.com/hyperledger/iroha-ed25519/blob/main/lib/ed25519/ref10/ed25519.c#L27 und https://github.com/hyperledger/iroha-ed25519/blob/main/lib/ed25519/amd64-64-24k-pic/ed25519.c#L30

• C: ed25519-donna (Andrew Moon)
  https://github.com/floodyberry/ed25519-donna/blob/master/ed25519.c#L59

• C: ed25519 (Orson Peters)
  https://github.com/orlp/ed25519/blob/master/src/sign.c#L7

• C: libbrine (Kevin Smith)
  https://github.com/kevsmith/libbrine/blob/master/src/ed25519/sign.c#L7

• C++: Ed25519 (ArduinoLibs)
  https://rweather.github.io/arduinolibs/classEd25519.html#a36ecf67b4c5d2d39a31888f56af1f8a5

• C#: ed25519 (Hans Wolff)
  https://github.com/hanswolff/ed25519/blob/master/Ed25519/Ed25519.cs#L146

• C#: Ed25519 (CryptoManiac)
  https://github.com/CryptoManiac/Ed25519/blob/972829ac688847895d5105f19ca1e5777131b421/Chaos.NaCl/Internal/Ed25519Ref10/keypair.cs#L7

• Dart: ed25519_dart (Oleksii Semeshchuk)
  https://github.com/semolex/ed25519_dart/blob/master/lib/src/ed25519_dart_base.dart#L200

Behobene Bibliotheken

• C: Trezor Firmware
  Behoben in diesem PR: https://github.com/trezor/trezor-firmware/pull/2349 (Fix eingefügt am 27. Juni 2022)

• Java: ed25519-elisabeth (Jack Grigg)
  Behoben in diesem Commit: https://github.com/cryptography-cafe/ed25519-elisabeth/commit/49545ce47d550fed807522dff86546c812ccbbac (Fix eingefügt am 19. Juni 2022)

• C: Harbour (Viktor Szakats)
  Behoben in diesem Commit: https://github.com/vszakats/hb/commit/bae610b63d35c6c1793d94a3bf9467c3b1eded18 (Fix eingefügt am 30. Juni 2022)

• Rust/Wasm: polkadot-js/wasm
  Behoben in diesem PR: https://github.com/polkadot-js/wasm/pull/381/files (Fix eingefügt am 3. Juli 2022)

• C: horse25519 (Yawning Angel)
  Behoben in diesem PR: https://github.com/Yawning/horse25519/pull/3 (Fix eingefügt am 15. August 2022)

• Erlang: erlang-libdecaf
  Behoben in diesem Commit: https://github.com/potatosalad/erlang-libdecaf/commit/16ba07ea122660e95f6cfa9107e28ed58bada713. Die Logik wird in diesem Issue behandelt: ed25519-unsafe-libs/issues/7 (Fix eingefügt am 28. August 2022)

• Rust: ed25519-dalek (Isis Agora Lovecruft)
  Behoben in diesem PR: https://github.com/dalek-cryptography/ed25519-dalek/pull/205 (Fix eingefügt am 22. Oktober 2022)

• C: Monocypher (Loup Vaillant)
  Behoben in diesem Commit: https://github.com/LoupVaillant/Monocypher/commit/da7b5407d20329f21a53ea993f516fb55e2f5e26 (Fix eingefügt am 27. Februar 2023)

Falschmeldungen (wahrscheinlich sicher)

Bibliotheken, die ursprünglich als verwundbar gemeldet wurden, aber aufgrund von Community-Feedback von der Liste entfernt wurden.

• Go: threshold-ed25519 — Threshold Signatures using Ed25519
  https://gitlab.com/unit410/threshold-ed25519/-/blob/main/pkg/ed25519.go#L161 -> siehe Bericht https://github.com/MystenLabs/ed25519-unsafe-libs/pull/9 (gemeldet am 27. Okt. 2022 von nitronit)