Test e convalida delle implementazioni RNG

Il test dei generatori di numeri casuali presenta una difficoltà fondamentale: le sequenze realmente casuali e le sequenze pseudo-casuali prodotte da un buon PRNG appaiono identiche nei test statistici. Nessun test su una sequenza di lunghezza finita può dimostrare che la sequenza sia casuale; la statistica può soltanto rilevare la non casualità con un certo grado di confidenza. I test verificano che un RNG non presenti distorsioni o schemi evidenti, ma non possono dimostrare la sicurezza crittografica. Il test degli RNG crittografici ha due obiettivi distinti: (1) qualità statistica, cioè verificare che la distribuzione dell'output appaia uniforme e indipendente; (2) robustezza crittografica, cioè verificare che l'algoritmo DRBG sia implementato correttamente e che le garanzie di sicurezza siano valide. Questi obiettivi richiedono approcci di test diversi.

NIST SP 800-22 fornisce 15 test statistici per valutare sequenze di bit. I test includono: test di frequenza (monobit), in cui la proporzione di 1 dovrebbe essere vicina a 0,5; test della frequenza dei blocchi, cioè la frequenza di 1 in ciascun blocco di m bit; test delle sequenze, cioè il numero di sequenze ininterrotte di bit identici; test della sequenza più lunga, cioè la lunghezza della sequenza più lunga di 1; test del rango delle matrici binarie, cioè il rango delle matrici binarie formate dalla sequenza; test spettrale (DFT), per rilevare schemi periodici; corrispondenza di modelli sovrapposti, per contare le occorrenze di schemi specifici; test statistico universale di Maurer, che comprime la sequenza e misura di quanto si riduce la sua lunghezza. Ogni test produce un p-value; p < 0.01 suggerisce una non casualità. I test vengono eseguiti su sequenze da 1 milione a 1 miliardo di bit.

TestU01 (L'Ecuyer e Simard, 2007) è una batteria completa di test statistici ampiamente utilizzata nella comunità degli RNG. SmallCrush: 10 test, circa 35 secondi, adatto a controlli rapidi. Crush: 144 test, circa 2 ore. BigCrush: 160 test, circa 24 ore. I test di BigCrush rilevano correlazioni sottili che NIST SP 800-22 non individua. I DRBG crittografici ben progettati (HMAC_DRBG, CTR_DRBG) superano BigCrush senza difficoltà: il loro output è computazionalmente indistinguibile dal casuale per gli algoritmi in tempo polinomiale. I PRNG non crittografici (Mersenne Twister, generatori congruenziali lineari) falliscono alcuni test di BigCrush. Il fallimento di BigCrush è un forte indicatore del fatto che l'RNG non dovrebbe essere utilizzato per scopi crittografici.

SP 800-90B e 90A specificano i test di integrità che i DRBG devono eseguire continuamente durante il funzionamento. Continuous RNG Test (CRNGT): ogni blocco generato viene confrontato con il blocco precedente; se sono uguali (RNG bloccato), il DRBG deve entrare in stato di errore e interrompere la generazione. Repetition Count Test: se campioni consecutivi presentano lo stesso valore ripetuto più volte di quanto previsto statisticamente in base alla stima dell'entropia, il test fallisce. Adaptive Proportion Test: se il valore più frequente compare più volte di una soglia prestabilita all'interno di una finestra, il test fallisce. Questi test di integrità rilevano i guasti delle fonti di entropia (sensore bloccato, guasto hardware dell'HWRNG) prima che compromettano silenziosamente la generazione delle chiavi crittografiche.

PractRand è uno strumento moderno per il test degli RNG, progettato per la valutazione online (in streaming): analizza la sequenza mentre viene generata, invece di richiedere una lunghezza prestabilita. Applica test tra cui test degli intervalli, test della distribuzione dei bit e test spettrali, con precisione adattiva. PractRand è particolarmente efficace nel rilevare RNG che producono sequenze brevi di buona qualità, ma rivelano schemi dopo miliardi di bit. I DRBG crittografici producono un output che PractRand non è in grado di distinguere da una sequenza casuale, indipendentemente dalla lunghezza; questa è la definizione operativa dell'indistinguibilità computazionale. PractRand viene utilizzato anche per valutare le fonti di entropia, testando l'output di /dev/urandom e di RDRAND per rilevare guasti hardware o distorsioni sistematiche.

Il Cryptographic Algorithm Validation Program (CAVP) fornisce vettori di test ufficiali per i DRBG di SP 800-90A. I test CAVP prevedono l'invio di un'implementazione al sistema di test automatizzato di NIST con vettori per test con risposta nota (KAT): dati uno specifico input di entropia, un nonce, una stringa di personalizzazione e additional_input, l'implementazione deve produrre esattamente i bit di output previsti. CAVP non verifica le proprietà statistiche, ma la correttezza algoritmica. La certificazione FIPS 140-3 richiede la convalida CAVP per tutti gli algoritmi crittografici utilizzati entro il confine del modulo. I vettori di test CAVP sono disponibili pubblicamente sul server ACVP (Automated Crypto Validation Protocol) di NIST e sono integrati nelle suite di test di OpenSSL, mbedTLS e BoringSSL.

Prima che un DRBG possa essere inizializzato in modo sicuro, la sua fonte di entropia deve essere convalidata. SP 800-90B definisce: (1) stima dell'entropia, cioè la misurazione dell'entropia effettiva per bit mediante test statistici (stima della min-entropia); (2) test di avvio, per verificare che la fonte di entropia produca un output valido prima del primo utilizzo; (3) test su richiesta, test facoltativi attivati dall'applicazione; (4) test di integrità della fonte di rumore, per rilevare il deterioramento dell'hardware. Fonti di entropia comuni e relativa entropia stimata per bit: CPU RDRAND/RDSEED (circa 1 bit/bit, hardware certificato); /dev/urandom (combina più fonti, con una stima dell'entropia prudenziale); TRNG con oscillatore ad anello (0,5-0,9 bit/bit a seconda del progetto); rumore ADC (0,1-0,5 bit/bit). La convalida secondo SP 800-90B richiede test di laboratorio con apparecchiature specializzate.

Gli ambienti virtuali introducono specifiche difficoltà per i test degli RNG. Le VM possono trovarsi in condizioni di bassa entropia all'avvio (in assenza di eventi hardware) o dopo il ripristino di uno snapshot (stato reimpostato). I container Docker condividono l'RNG del kernel dell'host: un container non può testare direttamente la qualità dell'entropia sottostante. Test per le distribuzioni su VM: (1) Misuri il tempo necessario per completare una lettura da /dev/random: attese prolungate indicano entropia insufficiente. (2) Verifichi la presenza di UUID o chiavi duplicati generati in parallelo da istanze VM (un caso di errore reale documentato nelle distribuzioni cloud). (3) Verifichi che VIRTIO-RNG (virtio_rng.ko) sia caricato nelle VM: fornisce l'iniezione di entropia dall'host al guest. (4) Verifichi la sequenza di avvio dell'applicazione: la generazione delle chiavi avviene prima che sia disponibile entropia sufficiente?

La verifica della sicurezza nei fork degli RNG previene una vulnerabilità insidiosa: quando un processo esegue un fork, il processo padre e quello figlio condividono lo stesso stato DRBG e di conseguenza generano sequenze identiche. Rilevamento: avvii N processi figli, generi un UUID in ciascuno e verifichi che tutti gli UUID siano univoci. Se due UUID coincidono, l'RNG non è sicuro rispetto ai fork. OpenSSL ha corretto un bug di fork safety nel 2020 (CVE-2020-1971 non riguardava direttamente il DRBG, ma lo schema è simile). Le versioni attuali di OpenSSL usano un aggiornamento del seed basato sul PID: se il PID è cambiato dall'ultima chiamata (a indicare un fork), il DRBG viene automaticamente reinizializzato. Per testare questo comportamento, esegua il test prima e dopo un fork e confermi che la reinizializzazione sia avvenuta verificando che gli output siano distinti.

Una checklist pratica di audit per le implementazioni RNG: (1) L'RNG viene inizializzato dal sistema operativo (getrandom, BCryptGenRandom) anziché con seed basati sul tempo? (2) Il tipo di DRBG è un meccanismo approvato dallo standard NIST SP 800-90A (Hash, HMAC, CTR)? (3) La lunghezza del seed è sufficiente per il livello di sicurezza dichiarato? (4) La reinizializzazione viene attivata periodicamente o dopo un numero fisso di chiamate a generate? (5) L'implementazione gestisce la sicurezza nei fork (reinizializzazione dopo un fork)? (6) I test di integrità sono abilitati e arrestano il sistema in caso di errore? (7) Lo stato viene azzerato durante l'arresto? (8) I vettori di test CAVP vengono eseguiti nella CI/CD? (9) Le stime dell'entropia sono documentate e convalidate? (10) Per i requisiti FIPS: il modulo è certificato FIPS 140-3?

Gli errori storici degli RNG dimostrano quanto siano importanti questi aspetti. Debian OpenSSL (2006-2008): una patch rimosse accidentalmente due righe di codice per la raccolta dell'entropia, riducendo il pool del seed a uno spazio di PID di 15 bit: per l'intera base di utenti Debian furono generate soltanto 32.767 possibili chiavi SSH. Tutte le chiavi host SSH e le chiavi degli utenti generate da Debian dovettero essere sostituite. Wallet Bitcoin Android (2013): SecureRandom di Android utilizzava un'inizializzazione del seed a livello Java che non funzionava su alcuni dispositivi, causando valori k duplicati nelle firme ECDSA: ciò rivelava direttamente le chiavi private. Sony PS3 (2010): utilizzava un nonce costante nella firma del firmware ECDSA, consentendo di estrarre la chiave privata da due firme (lo stesso k per messaggi diversi rivela la chiave tramite una semplice manipolazione algebrica).

I test statistici (NIST SP 800-22, TestU01 BigCrush, PractRand) verificano la qualità dell'output, ma non possono dimostrare la sicurezza crittografica. I test CAVP con risposta nota verificano la correttezza algoritmica delle implementazioni di SP 800-90A. I test delle sorgenti di entropia di SP 800-90B (stima della min-entropia, test di integrità) convalidano l'input del seed. Il Continuous RNG Test (CRNGT) rileva in tempo reale gli output bloccati. Le distribuzioni su VM e container richiedono l'iniezione di entropia (VIRTIO-RNG) e controlli dell'entropia all'avvio. I test della sicurezza nei fork verificano che i processi figli non ereditino lo stato DRBG del processo padre. Gli errori del mondo reale (Debian, Android) dimostrano che i bug degli RNG portano direttamente alla compromissione delle chiavi crittografiche. Le checklist di audit formalizzano questi controlli per le distribuzioni in produzione.