mystenlabs/ed25519-unsafe-libsLista di librerie di firma ed25519 non sicure
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
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.
