Esaurimento dell'entropia e bug delle chiavi deboli

L'insufficienza di entropia si verifica quando un sistema non dispone di un input sufficientemente imprevedibile per inizializzare il proprio CSPRNG. Questo accade nei dispositivi embedded appena avviati, nei server virtualizzati o nei sistemi privi di input dell'utente. L'output dell'RNG diventa prevedibile.

Nel 2006, uno sviluppatore Debian rimosse una riga segnalata da Valgrind: MD_Update(&m, buf, j). Questa riga era la sorgente di entropia. Risultato: OpenSSL su Debian utilizzava come seed solo il PID (al massimo 32.768 valori). Tutte le chiavi generate tra il 2006 e il 2008 appartengono a un insieme di 32.768 possibilità.

Le chiavi RSA, DSA ed ECDSA, le chiavi host SSH, i certificati TLS e le chiavi SSL VPN generati su sistemi Debian/Ubuntu tra il 2006 e il 2008 erano compromessi. Sistemi interessati: Debian Etch, Debian Lenny, Ubuntu 7.04-8.04. Sono state pubblicate blacklist e i certificati sono stati revocati.

Le VM possono essere clonate con uno stato del disco identico. Se entrambe generano chiavi a partire dallo stesso stato del CSPRNG, produrranno le stesse chiavi. Oggi gli hypervisor iniettano entropia tramite VirtIO RNG o tabelle ACPI, ma le VM configurate in modo errato sono ancora esposte a questo rischio durante l'avvio.

I dispositivi IoT (router, telecamere) spesso generano le chiavi SSH/TLS al primo avvio, prima di aver accumulato entropia. Gli studi hanno rilevato milioni di dispositivi che condividevano alcune migliaia di coppie di chiavi RSA, perché tutti utilizzavano come seed lo stesso stato di avvio con bassa entropia.

Lenstra et al. (2012) hanno raccolto 11,7 milioni di certificati TLS e calcolato i MCD a coppie. Hanno trovato 12.720 chiavi RSA che condividevano un fattore primo, il che significava che entrambe le chiavi potevano essere completamente fattorizzate. Lo 0,2% di tutte le chiavi pubbliche era compromesso. Causa: entropia insufficiente durante l'avvio.

ECDSA richiede un nonce casuale k univoco per ogni firma. Se k viene riutilizzato (o è debole), la chiave privata può essere recuperata immediatamente: d = (s1-s2)^{-1} * (z1-z2) * k / (r1-r2) mod n. La PS3 di Sony utilizzava k=constant: tutti i giochi potevano essere firmati con la chiave recuperata.

In determinate condizioni, SecureRandom di Java su Android 4.x veniva inizializzato usando l'ora del sistema. Diverse app per portafogli Bitcoin generavano firme con lo stesso nonce k, esponendo le chiavi private. Furono rubati milioni di dollari. Google ha corretto l'implementazione di SecureRandom.

Strumenti: ssh-vulnkey (verifica le chiavi rispetto alla blacklist delle chiavi deboli di Debian), badkeys (verifica la presenza di primi noti come deboli nei certificati TLS), algoritmo GCD-batch per l'audit in blocco delle chiavi RSA. I log di Certificate Transparency consentono analisi su scala globale.

Utilizzi getrandom(GRND_RANDOM) alla prima generazione di una chiave. Legga da /dev/urandom dopo aver atteso l'inizializzazione iniziale (verifichi che /proc/sys/kernel/random/entropy_avail > 128). Utilizzi un RNG hardware (RDRAND) come entropia supplementare. Non generi mai chiavi al primo avvio senza un'attesa.

Renda persistente lo stato del CSPRNG tra i riavvii: salvi 32 byte da /dev/urandom in un file di seed durante l'arresto; legga il file e reinserisca i dati nel CSPRNG all'avvio. In questo modo si mantiene la continuità dell'entropia tra gli avvii a freddo. Linux lo fa automaticamente; spesso i sistemi embedded non lo fanno.

Qual è stata la causa principale del bug di entropia di OpenSSL in Debian?

L'insufficienza di entropia causa chiavi prevedibili. Compromissioni reali: OpenSSL in Debian (seed basato solo sul PID), attacchi GCD all'IoT, riutilizzo del nonce ECDSA sulla PS3, portafogli Bitcoin di Android. Inizializzi sempre il seed a partire dall'entropia del sistema operativo e verifichi con attenzione la generazione delle chiavi nei sistemi embedded. Prossimo argomento: generare chiavi, nonce e IV in modo sicuro.