NIST SP 800-90A: standard DRBG

Le operazioni crittografiche richiedono numeri casuali di alta qualità: per la generazione di chiavi, nonce, IV, salt e token di sessione. I generatori di numeri casuali veri (TRNG) raccolgono entropia da fonti fisiche, come rumore hardware, interrupt e rumore termico, ma sono lenti e non sempre disponibili, soprattutto nelle macchine virtuali o nelle prime fasi dell'avvio. I Deterministic Random Bit Generators (DRBG) risolvono questo problema: si inizializza un DRBG con una piccola quantità di entropia vera e si usa un algoritmo crittografico per espanderla in un lungo flusso di bit pseudocasuali computazionalmente indistinguibili da bit realmente casuali. NIST SP 800-90A definisce tre meccanismi DRBG approvati, utilizzati praticamente in tutte le implementazioni crittografiche moderne.

Un DRBG opera attraverso tre operazioni fondamentali. Instantiate: inizializza lo stato interno del DRBG usando entropy_input, proveniente da una fonte di entropia, un nonce, cioè un valore usato una sola volta che garantisce l'unicità, e facoltativamente una personalization_string, cioè un contesto specifico dell'applicazione. Generate: produce il numero richiesto di bit pseudocasuali e aggiorna lo stato interno per impedire il backtracking. Reseed: inietta nuova entropia nello stato del DRBG per fornire resistenza alla predizione — dopo il reseed, persino un avversario che conosceva lo stato precedente non può prevedere gli output futuri. NIST specifica intervalli massimi di generazione (reseed_interval): 2^48 richieste prima del reseed obbligatorio per tutti e tre i tipi di DRBG.

NIST SP 800-90A definisce quattro livelli di sicurezza: 112, 128, 192 e 256 bit. Il livello di sicurezza determina l'entropia minima richiesta durante l'inizializzazione e la qualità dell'output generato. Per una sicurezza di 128 bit, l'input di entropia deve fornire almeno 128 bit di entropia. La relazione è: security_strength bit di entropia -> output del DRBG computazionalmente indistinguibile da un output casuale per un avversario che esegua 2^security_strength operazioni. Le scelte relative alla lunghezza delle chiavi, come AES-128 rispetto ad AES-256, e agli hash, come SHA-256 rispetto a SHA-512, devono raggiungere o superare il livello di sicurezza desiderato. Sovradimensionare i parametri, ad esempio usare SHA-512 per una sicurezza di 128 bit, è sicuro ma inefficiente; parametrizzarli al di sotto del necessario compromette la sicurezza.

Hash_DRBG mantiene due valori di stato: V, un valore che genera l'output, e C, una costante aggiunta durante generate. Generate: hash_gen produce bit iterando H(0x01 || V), H(0x01 || V+1), ... finché è disponibile un output sufficiente; quindi V viene aggiornato con V = V + H(0x03 || V) + C + reseed_counter. Reseed: usa Hash_df, la funzione di derivazione hash, combinando V con l'entropia fresca per produrre nuovi valori di V e C. Hash_DRBG è semplice da implementare e ha un'analisi della sicurezza lineare, caratteristiche che lo rendono adatto agli ambienti con risorse limitate. NIST raccomanda un'istanza con SHA-256 o SHA-512. Hash_DRBG viene utilizzato nello SHA1PRNG di Java, nella versione precedente, e nel DRBG legacy di OpenSSL.

HMAC_DRBG mantiene lo stato (chiave K, valore V). Generate: esegue iterativamente V = HMAC(K, V) finché non produce un output sufficiente; quindi K = HMAC(K, V || 0x00) e V = HMAC(K, V). Update: usa additional_input e reimposta K e V mediante operazioni HMAC. HMAC_DRBG dispone di una dimostrazione di sicurezza lineare basata sulla sicurezza di HMAC, con l'assunzione che HMAC sia una PRF. È il DRBG più ampiamente raccomandato: OpenSSL, a partire dalla versione 1.1.1, mbedTLS, wolfSSL e la maggior parte degli stack TLS usano HMAC_DRBG. La costruzione HMAC fornisce un mescolamento integrato tra chiamate successive, rendendo più difficili da eseguire gli attacchi di backtracking anche quando lo stato è parzialmente esposto.

CTR_DRBG usa un cifrario a blocchi, AES, in modalità contatore. Stato: chiave K e contatore V. Generate: cifra valori successivi del contatore E(K, V), E(K, V+1), ... e incrementa V. Update: usa Block_Cipher_df per derivare nuovi valori di K e V da additional_input. CTR_DRBG è il DRBG più veloce: l'accelerazione hardware AES-NI lo rende più veloce di diversi ordini di grandezza rispetto ai DRBG basati su hash sui processori moderni. È il DRBG predefinito in Windows CNG, dove CryptGenRandom usa CTR_DRBG con AES-256, in OpenSSL 3.0, dove è quello predefinito, e nel generatore casuale del kernel Linux, tramite la chiamata di sistema getrandom. La sicurezza di CTR_DRBG si basa sul fatto che AES sia una permutazione pseudocasuale, proprietà ampiamente supportata da decenni di analisi.

La resistenza alla predizione è una proprietà per cui l'output del DRBG resta imprevedibile anche per un avversario che in precedenza aveva compromesso lo stato del DRBG, a condizione che nuova entropia venga mescolata tramite il reseed. Un DRBG con prediction_resistance_flag=true chiama la fonte di entropia prima di ogni chiamata Generate per iniettare nuova entropia. Senza resistenza alla predizione, la compromissione dello stato al tempo T consente di calcolare tutti gli output futuri, compromettendo la forward security. La sicurezza all'indietro, detta anche resistenza al backtracking, significa che gli output passati restano imprevedibili anche se lo stato corrente è noto — HMAC_DRBG e CTR_DRBG la garantiscono mediante le fasi di aggiornamento che derivano una nuova chiave dallo stato corrente dopo ogni Generate.

SP 800-90A specifica gli algoritmi DRBG, ma non la fonte di entropia. SP 800-90B definisce i requisiti per le fonti di entropia: le fonti di rumore hardware devono essere caratterizzate e validate, le stime dell'entropia devono essere conservative e i test di integrità devono rilevare i guasti delle fonti di entropia. SP 800-90C specifica come combinare le fonti di entropia con i DRBG per ottenere generatori completi di bit casuali. Fonti di entropia tipiche: CPU RDRAND/RDSEED, cioè generatori casuali hardware disponibili sulle CPU Intel/AMD dal 2012; entropia del sistema operativo, come /dev/urandom su Linux e BCryptGenRandom su Windows; moduli hardware di sicurezza; RNG TPM 2.0; e rumore ambientale, come temporizzazione del disco e jitter di rete. Le condizioni di bassa entropia, ad esempio nelle macchine virtuali o nelle prime fasi dell'avvio, richiedono una gestione speciale per evitare semi deboli.

FIPS 140-3, lo standard attuale per la validazione dei moduli crittografici, impone l'uso di DRBG NIST SP 800-90A per tutta la generazione di numeri casuali all'interno dei moduli certificati. Il modulo deve: utilizzare un DRBG approvato, Hash, HMAC o CTR; inizializzarlo con una fonte di entropia approvata che soddisfi i requisiti di SP 800-90B; eseguire test automatici all'accensione (POST) per verificare il funzionamento del DRBG; implementare test continui dell'RNG (CRNGT) per rilevare guasti della fonte di entropia bloccata su zero o su uno; e supportare il reseed quando la fonte di entropia indica che è disponibile entropia. Gli HSM, tra cui Thales Luna, AWS CloudHSM e Utimaco, le schede acceleratrici TLS e gli apparati di cifratura di rete richiedono comunemente moduli convalidati secondo FIPS 140-3, favorendo l'adozione di SP 800-90A.

I moderni sistemi operativi mantengono un DRBG a livello del kernel, inizializzato con un seed derivato da fonti di entropia hardware. Linux usa un DRBG basato su ChaCha20 (a partire dal kernel 5.17, in sostituzione del precedente design simile a Fortuna), inizializzato con RDRAND, interrupt ed eventi del disco e della rete. /dev/urandom restituisce l'output del DRBG e non si blocca dopo l'inizializzazione iniziale del seed. /dev/random si blocca finché non è disponibile entropia sufficiente (comportamento legacy, in gran parte rimosso nei kernel recenti). La syscall getrandom(2) è l'interfaccia moderna e si blocca solo durante l'avvio iniziale, prima che il DRBG sia inizializzato con un seed. Windows usa CTR_DRBG (AES-256) nel generatore casuale del kernel, inizializzato con il TPM e con eventi hardware. Le applicazioni dovrebbero usare il DRBG del sistema operativo tramite API di alto livello, anziché inizializzare autonomamente i propri DRBG usando timestamp o PID.

Le vulnerabilità dei DRBG nel mondo reale derivano da errori di implementazione, non da debolezze degli algoritmi. (1) Seeding insufficiente: usare solo il timestamp corrente o il PID per inizializzare il seed fornisce agli attaccanti un seed prevedibile. (2) Ignorare il fork: quando un processo esegue un fork, il processo padre e quello figlio condividono lo stesso stato del DRBG e generano quindi gli stessi numeri casuali. Soluzione: eseguire un reseed dopo il fork (pthread_atfork o una chiamata esplicita a getrandom). (3) Riutilizzo degli snapshot delle VM: quando uno snapshot di una VM viene ripristinato, lo stato del DRBG torna a quello dello snapshot e genera output già osservato in precedenza. Soluzione: iniettare entropia univoca all'avvio della VM (VIRTIO RNG). (4) Ignorare silenziosamente il fallimento dei test di integrità: un DRBG che continua a generare output dopo aver rilevato un errore di entropia fornisce output prevedibile per l'attaccante. (5) Riutilizzare nonce tra istanze diverse del DRBG.

Quale proprietà offre il reseeding di un DRBG con entropia fresca?

NIST SP 800-90A definisce tre meccanismi DRBG approvati: Hash_DRBG (hash iterativo, semplice), HMAC_DRBG (basato su HMAC, con una dimostrazione di sicurezza chiara e ampiamente distribuito) e CTR_DRBG (modalità contatore AES, più veloce grazie ad AES-NI, predefinito in Windows/OpenSSL). Tutti condividono il ciclo di vita Instantiate/Generate/Reseed, con un limite reseed_interval pari a 2^48. Il livello di sicurezza (112-256 bit) determina i requisiti di entropia. La prediction resistance richiede un reseeding prima di ogni chiamata a Generate. FIPS 140-3 impone l'uso di DRBG conformi a SP 800-90A con fonti di entropia conformi a SP 800-90B. Ignorare il fork, riutilizzare gli snapshot delle VM e usare un seeding insufficiente sono le principali insidie delle implementazioni nel mondo reale.