I ricercatori dell'università di Masaryk hanno rivelato informazioni importante sulle vulnerabilità in vari iImplementazioni dell'algoritmo di generazione della firma digitale ECDSA / EdDSA, che permette di recuperare il valore della chiave privata sulla base dell'analisi delle fughe di informazioni sui singoli bit che compaiono applicando metodi di analisi attraverso canali di terze parti. Le vulnerabilità hanno il nome in codice Minerva.
I progetti più famosi che influiscono il metodo di attacco proposto sono OpenJDK, OracleJDK (CVE-2019-2894) e la libreria libgcrypt (CVE-2019-13627) utilizzato in GnuPG. I problemi sono suscettibile anche per le biblioteche MatrixSSL, Crypto ++, wolfCrypt, ellittico, jsrsasign, Python-ECDSA, ruby_ecdsa, fastecdsa e anche alcune smart card Athena IDProtect, TecSec Armored Card, SafeNet eToken 4300, S / A valido IDflex V.
Oltre alle vulnerabilità menzionate al momento non sono interessate OpenSSL, Botan, mbedTLS e BoringSSL. Mozilla NSS, LibreSSL, Nettle, BearSSL, cryptlib, OpenSSL in modalità FIPS. Microsoft .NET crypto, Linux kernel libkcapi, Sodium e GnuTLS devono ancora essere testati.
Abbiamo trovato implementazioni che perdono la lunghezza in bit dello scalare durante la moltiplicazione scalare in ECC. Questa perdita può sembrare minuscola poiché la lunghezza del bit ha una quantità molto piccola di informazioni presenti nello scalare. Tuttavia, nel caso della generazione di firme ECDSA / EdDSA, filtrare la lunghezza in bit del nonce casuale è sufficiente per il pieno ripristino della chiave privata utilizzata dopo aver osservato da poche centinaia a poche migliaia di firme nei messaggi noti, a causa dell'applicazione di alcune tecniche.
Riteniamo che tutte le schede di cui sopra siano interessate perché condividono un componente ECDSA comune (modulo FIPS 214), che è descritto come componente Athena OS2 ECDSA755 in Inside Secure AT90SC A1.0 (firmware). Abbiamo testato la vulnerabilità solo sulla scheda Athena IDProtect con dati CPLC e ATR
Il problema è causato dalla capacità di determinare i singoli valori di bit durante la moltiplicazione per uno scalare durante la negoziazione ECC. I metodi indiretti, come la stima del ritardo nell'esecuzione dei calcoli, vengono utilizzati per estrarre le informazioni dai bit.
Un attacco richiede un accesso senza privilegi all'host in cui viene generata la firma digitale (un attacco remoto non è escluso, ma è molto complicato e richiede una grande quantità di dati per l'analisi, quindi può essere considerato improbabile).
Nonostante le ridotte dimensioni del leak, per ECDSA la definizione anche di pochi bit con informazioni sul vettore di inizializzazione (nonce) è sufficiente per effettuare un attacco per ripristinare sequenzialmente la chiave privata completa.
Secondo gli autori del metodo, per il corretto ripristino delle chiavi, è sufficiente un'analisi da diverse centinaia a diverse migliaia di firme digitali generate per i messaggi noti all'attaccante. Ad esempio, per determinare la chiave privata utilizzata nella smart card Athena IDProtect basata sul chip Inside Secure AT90SC, utilizzando la curva ellittica secp256r1, sono state analizzate 11mila firme digitali. Il tempo di attacco totale è stato di 30 minuti.
Il nostro codice di attacco e la prova del concetto sono ispirati al metodo Brumley & Tuveri.
Il problema è già stato risolto in libgcrypt 1.8.5 e wolfCrypt 4.1.0, altri progetti non hanno ancora generato aggiornamenti. È anche possibile rintracciare la correzione della vulnerabilità nel pacchetto libgcrypt nelle distribuzioni su queste pagine: Debian, Ubuntu, RHEL, Fedora, openSUSE / SUSE, FreeBSD, Arch.
I ricercatori hanno anche testato altre carte e librerie, di cui le seguenti non sono vulnerabili:
- OpenSSL 1.1.1d
- Castello gonfiabile 1.58
- BoringSSL 974f4dddf
- libtomcrypt 1.18.2
- Botanico 2.11.0
- Microsoft metano
- mbedTLS 2.16.0
- Crittografia Intel IPP
Carte
- ACS ACOSJ 40K
- Feitiano A22CR
- G&D SmartCafe 6.0
- G&D SmartCafe 7.0
- Infineon CJTOP 80K INF SLJ 52GLA080AL M8.4
- Infineon SLE78 JCard universale
- NXPJCOP31 v2.4.1
- NXPJCOP CJ2A081
- NXPJCOP v2.4.2 R2
- NXPJCOP v2.4.2 R3
- SIMOME TaiSYS Vault
Se vuoi saperne di più sull'attacco utilizzato e sulle vulnerabilità rilevate, puoi farlo nel seguente link Gli strumenti utilizzati per replicare l'attacco sono disponibili per il download.