Internals di Hash-DRBG, HMAC-DRBG e CTR-DRBG

Ciascuno dei tre meccanismi DRBG NIST mantiene componenti diversi nello stato interno, in accordo con il proprio approccio algoritmico. Hash_DRBG memorizza V (un seed della lunghezza dell'hash) e C (una costante derivata da V, usata durante la generazione dell'output). HMAC_DRBG memorizza la chiave segreta K (una chiave della lunghezza dell'hash) e il valore V (un valore di concatenamento della lunghezza dell'hash). CTR_DRBG memorizza la chiave K (una chiave AES) e V (un contatore della lunghezza di un blocco). Tutti e tre mantengono un reseed_counter che tiene traccia delle chiamate a generate dall'ultimo seeding. La dimensione dello stato determina l'occupazione di memoria: Hash/HMAC_DRBG con SHA-256 usano 64 byte di stato; CTR_DRBG con AES-256 usa 48 byte (chiave di 32 byte + contatore di 16 byte).

Hash_DRBG usa Hash_df (funzione di derivazione basata su hash) per derivare lo stato dal materiale di entropia. Hash_df(input_string, no_of_bits_to_return) esegue iterativamente queste operazioni: per counter = 1, 2, ..., calcola H(counter || no_of_bits || input_string) e concatena gli output finché non vengono prodotti bit a sufficienza. In questo modo estende input di entropia brevi trasformandoli in seed delle dimensioni dello stato. Durante Generate, la funzione di output calcola W = H(0x03 || V), dove il prefisso 0x03 distingue questo uso dagli altri impieghi dell'hash. Il ciclo di output è: data = H(0x01 || V); V = V + 1; ripetere per ottenere altro output. Dopo la generazione, V viene aggiornato: V = V + H(0x03 || V) + C + reseed_counter. La separazione dei domini ottenuta tramite i byte prefisso (0x01, 0x03) impedisce di confondere l'output della fase di generazione con quello della fase di aggiornamento dello stato.

La funzione Update di HMAC_DRBG è il nucleo di tutte le transizioni di stato. Update(provided_data, K, V): K = HMAC(K, V || 0x00 || provided_data); V = HMAC(K, V). Se provided_data non è vuoto: K = HMAC(K, V || 0x01 || provided_data); V = HMAC(K, V). Questo aggiornamento in due passaggi garantisce che sia la nuova chiave sia il nuovo valore dipendano dallo stato precedente e dall'eventuale nuova entropia. Generate: eseguire in ciclo V = HMAC(K, V) e aggiungere il risultato all'output finché non vengono prodotti bit a sufficienza; quindi chiamare Update con additional_input per far avanzare lo stato. La sicurezza di HMAC_DRBG si basa sull'ipotesi che HMAC sia una PRF sicura: un avversario che non è in grado di distinguere l'output di HMAC da quello casuale non è in grado di distinguere l'output del DRBG da quello casuale.

CTR_DRBG usa Block_Cipher_df (funzione di derivazione) per trasformare il materiale di seed nel formato chiave/contatore. Block_Cipher_df(input_string, no_of_bits) usa una costruzione BCC (Block Cipher Chaining): applica iterativamente AES-CBC a blocchi di input per produrre un output della lunghezza richiesta. La funzione di derivazione è necessaria per gestire input di entropia di lunghezza variabile e fornire la separazione dei domini. CTR_DRBG senza funzione di derivazione (consentito nei test FIPS con input formattati con precisione) è più veloce, ma più sensibile ai requisiti di formato dell'input. Il ciclo di Generate è: temp = E(K, V); V = V + 1; aggiungere temp all'output. Update: K || V = Block_Cipher_df(V || additional_input, seedlen); applicare XOR con la chiave corrente.

Le prestazioni variano sensibilmente tra i diversi tipi di DRBG. Su una moderna CPU x86_64 con AES-NI, CTR_DRBG (AES-256) raggiunge circa 5-10 GB/s di output pseudocasuale: l'istruzione AES-NI rende il calcolo AES quasi gratuito. HMAC_DRBG (SHA-256) raggiunge circa 200-400 MB/s: SHA-256 è veloce, ma non beneficia dell'accelerazione hardware nella stessa misura. Hash_DRBG (SHA-256) raggiunge circa 100-300 MB/s. Per la generazione massiva di chiavi o in sostituzione di un cifrario a flusso, CTR_DRBG è nettamente più veloce. Per gli utilizzi a basso throughput (generazione di chiavi di sessione, derivazione di nonce), la differenza di prestazioni è trascurabile. Per questo motivo, OpenSSL 3.0 usa CTR_DRBG (AES-256) come impostazione predefinita.

Durante l'istanziazione, tutti e tre i DRBG accettano un parametro opzionale personalization_string, che viene combinato con l'input di entropia per rendere univoca l'istanza del DRBG. In questo modo si impedisce che due DRBG istanziati contemporaneamente con la stessa entropia producano lo stesso output: i due flussi divergono in base alla personalization_string. Stringhe di personalizzazione consigliate: identificatore dell'applicazione + ID del processo + ID del thread + timestamp + identificatore hardware. Anche se due VM ricevono la stessa entropia, come può accadere con gli snapshot delle VM cloud, stringhe di personalizzazione diverse garantiscono flussi DRBG diversi. NIST SP 800-90C raccomanda di usare sempre una stringa di personalizzazione. Il parametro nonce svolge una funzione simile: è un valore breve e univoco che garantisce che nessuna coppia di istanziazioni inizi nello stesso stato.

Tutti e tre i DRBG supportano un parametro additional_input nelle chiamate a Generate. Questo consente al chiamante di iniettare contesto o entropia aggiuntivi in una singola chiamata di generazione, senza eseguire un reseed completo. Utilizzi: (1) iniettare entropia per ogni richiesta proveniente da una fonte di entropia secondaria; (2) fornire contesto a livello applicativo (ID della richiesta, timestamp) per associare i valori generati al loro utilizzo; (3) fornire una resistenza opzionale alla predizione iniettando entropia fresca dal sistema operativo. additional_input viene combinato con lo stato del DRBG prima della generazione dell'output. Se additional_input fornisce entropia reale, migliora la sicurezza senza richiedere un reseed formale, che coinvolge l'interfaccia della fonte di entropia e il relativo overhead.

Dopo che un DRBG viene deistanziato (o quando si passa a una nuova istanza), lo stato interno deve essere azzerato in modo sicuro. Lo stato V, C (Hash_DRBG), K, V (HMAC/CTR_DRBG) e tutte le variabili di lavoro intermedie devono essere sovrascritti con zeri. Questa operazione è chiamata azzeramento esplicito ed è obbligatoria nei moduli FIPS 140-3. Nel codice C, usare explicit_bzero() o SecureZeroMemory(): un memset ottimizzato dal compilatore potrebbe essere rimosso come ottimizzazione di una scrittura inutile, lasciando il materiale delle chiavi in memoria. La crate zeroize di Rust e soluzioni analoghe specifiche del linguaggio gestiscono questa operazione in modo portabile. La distruzione sicura delle chiavi è importante nei contesti in cui dump della memoria, attacchi cold boot o strumenti di ispezione dei processi potrebbero esporre residui dello stato.

NIST fornisce vettori di test del Cryptographic Algorithm Validation Program (CAVP) per tutti i DRBG di SP 800-90A. Tipi di test: (1) Known Answer Tests (KAT): dato un input di entropia, un nonce e una stringa di personalizzazione fissi, verificare che l'output generato corrisponda ai valori precalcolati. (2) Test di reseed: verificare lo stato del DRBG dopo un'operazione di reseed. (3) Test PR (Prediction Resistance): verificare che la richiesta prediction_resistance=true produca l'output corretto dopo l'iniezione di entropia fresca. La validazione CAVP è necessaria per la presentazione alla certificazione FIPS 140-3. Le librerie open source (OpenSSL, mbedTLS) includono vettori di test CAVP nelle proprie suite di test di regressione per rilevare regressioni nelle implementazioni dei DRBG.

Le implementazioni dei DRBG affrontano sottili rischi di side channel che vanno oltre il modello di sicurezza algoritmico. Gli attacchi di cache timing su AES (in CTR_DRBG senza AES-NI) possono rivelare il materiale delle chiavi di round; AES-NI elimina questo rischio eseguendo i calcoli nei registri senza accessi a tabelle. HMAC_DRBG usa internamente HMAC, che è constant-time se anche l'implementazione sottostante di SHA-256 è constant-time; SHA-256 è generalmente considerato constant-time perché non contiene rami dipendenti dai dati. I side channel fisici (analisi dei consumi, radiazioni elettromagnetiche) contro l'hardware che produce DRBG sono una preoccupazione per smart card e dispositivi IoT e vengono affrontati con implementazioni basate sul masking. L'attacco tramite copia dello stato: se un avversario riesce a leggere lo stato del DRBG attraverso una vulnerabilità di divulgazione della memoria (di tipo Heartbleed), tutto l'output futuro è compromesso fino al successivo reseeding con entropia fresca.

Se lo stato di un DRBG viene compromesso, ad esempio tramite una vulnerabilità di divulgazione della memoria, il ripristino richiede: (1) rilevare la compromissione: le fughe di informazioni sullo stato del DRBG non sono rilevabili autonomamente; sono necessari monitoraggio esterno o controlli di integrità; (2) eseguire un reseed con entropia fresca proveniente da una fonte affidabile non coinvolta nella compromissione; (3) rinnovare tutto il materiale crittografico derivato dal DRBG compromesso, incluse le chiavi di sessione e le chiavi di firma generate dall'ultimo reseed riuscito; (4) nelle implementazioni software, riavviare il processo per ottenere una nuova istanziazione pulita del DRBG. SP 800-90C raccomanda fonti di entropia concatenate: se una fonte è compromessa, la combinazione continua a garantire la sicurezza purché l'altra fonte fornisca entropia reale.

Quale meccanismo DRBG è più veloce per la generazione massiva di output pseudocasuale sulle CPU moderne?

Hash_DRBG usa l'hashing iterativo con Hash_df per la derivazione e produce l'output tramite cicli H(0x01 || V). HMAC_DRBG usa HMAC come PRF con una funzione Update in due passaggi (prima la chiave, poi il valore), che offre una chiara riduzione di sicurezza. CTR_DRBG usa AES in modalità contatore con Block_Cipher_df e raggiunge 5-10 GB/s sull'hardware con AES-NI. Tutti accettano personalization_string durante l'istanziazione per rendere univoca l'istanza e additional_input durante ogni generate per associare il contesto. I vettori di test CAVP convalidano le implementazioni. Lo stato deve essere azzerato in modo sicuro dopo l'uso. La compromissione dello stato richiede un reseed con entropia fresca e il rinnovo del materiale derivato.