ed25519-unsafe-libs

Attacco Oracle alla Funzione di Firma Ed25519 con Doppia Chiave Pubblica

Un elenco di librerie di firma ed25519 potenzialmente non sicure che espongono un'API pubblica in cui chiave segreta e chiave pubblica possono essere fornite indipendentemente come input della funzione di firma. Un uso improprio di queste API pubbliche può portare all'esposizione della chiave privata.

La maggior parte dei repository nella nostra analisi è elencata in IANIX :: Cose che usano Ed25519.

Numero di librerie interessate: 45
Numero di librerie che hanno corretto il problema dopo l'annuncio: 8
ultimo aggiornamento: 4 maggio 2023

Implementazioni Proof of Concept che dimostrano questa potenziale vulnerabilità:

• Rust: ed25519-chalkias-exploit
• Python: Vulnerabilità Ed25519 in Python, Buchanan, William J (2022). Vulnerabilità Ed25519 in Python (Recupero della chiave privata). Asecuritysite.com.

Presentazioni:

• Presentazione su invito al Crypto Reading Club del National Institute of Standards and Technology (NIST) degli USA: slides - Domare i molti EdDSA (pagine 28-39), Konstantinos Chalkias, François Garillot, Valeria Nikolaenko (2023). Domare i molti EdDSA e gli attacchi di firma Ed25519.

Notizie e copertura sui social network di questo attacco

• NIST Crypto Reading Club "Domare i molti EdDSA" (8 marzo 2023)
• The Daily Swig "Decine di librerie crittografiche vulnerabili al furto di chiavi private" (28 giugno 2022)
• Risky Biz News "Nuova vulnerabilità crittografica: decine di librerie crittografiche hanno implementato erroneamente l'algoritmo di firma digitale Ed25519" (28 giugno 2022)
• Post del blog SafeHeron "Analisi dei rischi dell'uso di Ed25519: la chiave privata del tuo wallet può essere rubata" (17 giugno 2022)
• kryptera.se "Vulnerabilità nella maggior parte delle librerie ed25519" (in svedese) (29 giugno 2022)
• Difesa e Sicurezza & Yoroi "Librerie crittografiche ed25519 potenzialmente non sicure" (in italiano) (1 luglio e 29 giugno 2022)
• Post Medium del Prof. Bill Buchanan OBE "Ed25519 è fantastico, ma..." (1 luglio 2022)
• Reddit r/crypto (miglior post del mese - 18 giugno 2022)
• Reddit r/cryptography (17 giugno 2022)
• Tweet interessanti:
  • tweet 1 (di Kostas Kryptos - "Le 26 librerie vulnerabili originali")
  • tweet 2 (di Kostas Kryptos - "Le conseguenze delle 40 librerie vulnerabili")

Qual è il problema?

Nota: normalmente e secondo il relativo rfc8032, le firme EdDSA sono deterministiche e quindi, per lo stesso messaggio di input da firmare, viene restituito un output di firma unico che include due elementi: un punto della curva R e uno scalare S.

Un dettaglio algoritmico è che la chiave pubblica del firmatario è coinvolta solo nel calcolo deterministico della parte S della firma, ma non nel valore R. Ciò implica che se un avversario potesse in qualche modo usare la funzione di firma come un Oracle (che accetta chiavi pubbliche arbitrarie come input), sarebbe possibile ottenere, per lo stesso messaggio, due firme che condividono lo stesso R e differiscono solo nella parte S. Purtroppo, quando ciò accade, si può facilmente estrarre la chiave privata; questo post su StackOverflow spiega perché ciò è fattibile.

Detto questo, le API pubbliche NON dovrebbero consentire una coppia di chiavi privata/pubblica disaccoppiata come input di firma. Per ovviare a questo problema, molte implementazioni memorizzano la chiave pubblica insieme alla chiave privata (o seed) e considerano l'intera coppia di chiavi come segreta, oppure derivano nuovamente la chiave pubblica all'interno della funzione di firma. Purtroppo, un gran numero di librerie esistenti non affronta il problema, consentendo chiavi pubbliche arbitrarie come input senza verificare che la chiave pubblica corrisponda alla chiave privata inserita.

Ovviamente, ciò non significa che tutte le applicazioni con dipendenze da queste librerie siano esposte ad attacchi di esposizione delle chiavi; in realtà, la maggior parte è probabilmente al sicuro perché di solito non espone pubblicamente l'API interessata ai propri utenti e accoppia la coppia di chiavi pubbliche/private subito prima dell'invocazione di sign. D'altro canto, anche quando queste API non sono esposte, esistono applicazioni con diverse strategie di threat model TCB su come le chiavi private e pubbliche vengono gestite e memorizzate. Detto questo, per prevenire questo attacco, gli sviluppatori dovrebbero inoltre implementare un protocollo di protezione dell'integrità anche per le chiavi pubbliche.

Qui elenchiamo alcune librerie interessate insieme ai relativi riferimenti al codice.

Fig. 1. Un esempio di uso improprio dell'API nella crate Rust ed25519-dalek.

Librerie interessate

• 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 e 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

Librerie corrette

• C: Trezor firmware
  Corretto in questa PR: https://github.com/trezor/trezor-firmware/pull/2349 (Fix integrato il 27 giugno 2022)

• Java: ed25519-elisabeth (Jack Grigg)
  Corretto in questo commit: https://github.com/cryptography-cafe/ed25519-elisabeth/commit/49545ce47d550fed807522dff86546c812ccbbac (Fix integrato il 19 giugno 2022)

• C: Harbour (Viktor Szakats)
  Corretto in questo commit: https://github.com/vszakats/hb/commit/bae610b63d35c6c1793d94a3bf9467c3b1eded18 (Fix integrato il 30 giugno 2022)

• Rust/Wasm: polkadot-js/wasm
  Corretto in questa PR: https://github.com/polkadot-js/wasm/pull/381/files (Fix integrato il 3 luglio 2022)

• C: horse25519 (Yawning Angel)
  Corretto in questa PR: https://github.com/Yawning/horse25519/pull/3 (Fix integrato il 15 agosto 2022)

• Erlang: erlang-libdecaf
  Corretto in questo commit: https://github.com/potatosalad/erlang-libdecaf/commit/16ba07ea122660e95f6cfa9107e28ed58bada713. Logica affrontata in questo issue: ed25519-unsafe-libs/issues/7 (Fix integrato il 28 agosto 2022)

• Rust: ed25519-dalek (Isis Agora Lovecruft)
  Corretto in questa PR: https://github.com/dalek-cryptography/ed25519-dalek/pull/205 (Fix integrato il 22 ottobre 2022)

• C: Monocypher (Loup Vaillant)
  Corretto in questo commit: https://github.com/LoupVaillant/Monocypher/commit/da7b5407d20329f21a53ea993f516fb55e2f5e26 (Fix integrato il 27 febbraio 2023)

Falsi positivi (probabilmente sicuri)

Librerie originariamente segnalate come vulnerabili, ma rimosse dall'elenco in base al feedback della community.

• Go: threshold-ed25519 — Firme di soglia usando Ed25519
  https://gitlab.com/unit410/threshold-ed25519/-/blob/main/pkg/ed25519.go#L161 -> vedi report https://github.com/MystenLabs/ed25519-unsafe-libs/pull/9 (segnalato il 27 ottobre 2022 da nitronit)