Attacchi replay e vulnerabilità del riutilizzo dei nonce

Un nonce (numero usato una sola volta) garantisce che lo stesso messaggio in chiaro, cifrato due volte, produca testi cifrati diversi. Questo è essenziale per la sicurezza semantica: osservando più testi cifrati, un attaccante non ricava alcuna informazione sul fatto che cifrino testi in chiaro uguali o diversi. Nei cifrari a flusso e nei cifrari a blocchi in modalità CTR, il nonce avvia la generazione del flusso di chiavi, rendendolo di importanza fondamentale per la sicurezza.

In AES-GCM, il nonce di 96 bit viene usato per inizializzare un contatore per la cifratura in modalità CTR e contribuisce anche al calcolo di autenticazione GHASH. Il valore del contatore per ogni blocco AES viene ottenuto incrementando il nonce. Se due cifrature usano lo stesso nonce e la stessa chiave, generano lo stesso flusso di chiavi, perciò lo XOR dei loro testi cifrati è uguale allo XOR dei loro testi in chiaro.

Per due testi cifrati GCM ottenuti con la stessa coppia (chiave, nonce), lo XOR dei due testi cifrati è uguale allo XOR dei rispettivi testi in chiaro. Se un attaccante conosce un testo in chiaro, come accade spesso negli scenari a testo in chiaro scelto, recupera immediatamente l'altro. Anche senza conoscere un testo in chiaro, lo XOR dei testi cifrati rivela schemi linguistici e può essere attaccato con tecniche di crib-dragging. Questo è uno degli schemi di uso improprio più catastrofici della crittografia.

Il riutilizzo del nonce in GCM ha una conseguenza catastrofica aggiuntiva, oltre al recupero del testo in chiaro. La chiave di autenticazione GHASH H deriva esclusivamente dalla chiave di cifratura. Se due messaggi condividono la stessa coppia (chiave, nonce), l'attaccante può risolvere equazioni polinomiali per recuperare H. Una volta nota H, l'attaccante può falsificare tag di autenticazione GCM validi per testi cifrati arbitrari, compromettendo completamente l'integrità dei messaggi.

TLS 1.3 ha tratto insegnamento dai rischi del riutilizzo dei nonce nelle implementazioni di TLS 1.2. TLS 1.3 genera i nonce GCM eseguendo lo XOR tra l'IV di scrittura di 12 byte (derivato dall'handshake) e il numero di sequenza di 8 byte (esteso con zeri fino a 12 byte). Poiché i numeri di sequenza aumentano a ogni record, ogni record usa un nonce univoco. Questo elimina il rischio della generazione casuale dei nonce e ne garantisce l'unicità attraverso il meccanismo del numero di sequenza.

Un attacco di replay cattura un messaggio valido o un token di autenticazione e lo ritrasmette in un secondo momento per ottenere un effetto fraudolento. Esempi: ritrasmettere una transazione bancaria per effettuare un doppio addebito, ritrasmettere una risposta di autenticazione valida per impersonare un utente o ritrasmettere un comando firmato a un dispositivo. L'attaccante non deve comprendere né modificare il messaggio: è sufficiente ritrasmettere i dati catturati per eseguire l'attacco.

Includere un timestamp nei messaggi autenticati offre protezione contro il replay. Il destinatario accetta i messaggi solo entro una breve finestra temporale, ad esempio entro 5 minuti dal timestamp dichiarato. Un messaggio ritrasmesso dopo alcune ore è fuori dalla finestra e viene rifiutato. Il timestamp deve essere autenticato, cioè incluso nell'HMAC o nei dati aggiuntivi di AEAD, per impedire a un attaccante di modificarlo e farlo apparire recente.

I numeri di sequenza offrono una protezione contro il replay più forte dei timestamp, perché rilevano non solo le ritrasmissioni di messaggi vecchi, ma anche le consegne duplicate e fuori ordine. Il destinatario mantiene il numero di sequenza successivo previsto e una finestra scorrevole dei numeri visti di recente. Ogni messaggio deve avere un numero di sequenza compreso nella finestra accettabile e non già utilizzato. TLS usa i numeri di sequenza per impedire il replay dei record all'interno di una sessione.

Per AES-GCM, la strategia consigliata per generare nonce casuali consiste nell'usare nonce di 96 bit ottenuti da un generatore di numeri pseudocasuali crittograficamente sicuro (CSPRNG). Con nonce casuali di 96 bit, la probabilità di collisione dovuta al limite del compleanno raggiunge 2^-32 dopo 2^32 cifrature, cioè circa 4 miliardi. Per le applicazioni ad alto volume, è opportuno passare a un nonce basato su contatore oppure usare un AEAD diverso, come XChaCha20-Poly1305 con il suo nonce di 192 bit, per estendere il limite di sicurezza.

I nonce deterministici basati su contatore evitano i problemi del limite del compleanno, ma richiedono una gestione attenta dello stato. Il contatore deve essere mantenuto anche dopo il riavvio dell'applicazione: un contatore che dopo il riavvio torna a zero crea immediatamente il riutilizzo del nonce con la stessa chiave. Il contatore deve essere aggiornato atomicamente prima di usare il nonce, non dopo. Nei sistemi distribuiti, i nonce basati su contatore richiedono il coordinamento per impedire che due nodi usino lo stesso valore del contatore.

XChaCha20-Poly1305 estende il nonce di ChaCha20-Poly1305 da 96 a 192 bit. Con nonce casuali di 192 bit, la probabilità di collisione dovuta al limite del compleanno è trascurabile anche dopo 2^96 cifrature, un numero astronomicamente grande di messaggi. Questo rende sicura la generazione casuale dei nonce senza preoccupazioni pratiche legate al limite del compleanno. Il crypto_secretbox di libsodium (XSalsa20-Poly1305) usa nonce di 192 bit per lo stesso motivo.

Riepilogo sul riutilizzo dei nonce: i nonce garantiscono l'unicità del testo cifrato; il riutilizzo dei nonce in GCM rivela lo XOR dei testi in chiaro e compromette l'autenticazione consentendo di recuperare H; TLS 1.3 usa lo XOR tra il numero di sequenza e l'IV per garantire l'unicità dei nonce; gli attacchi di replay ritrasmettono messaggi validi senza modificarli; timestamp e numeri di sequenza nei messaggi autenticati impediscono il replay; per GCM si usano nonce casuali di 96 bit, tenendo conto del limite del compleanno, oppure XChaCha20 per uno spazio più ampio di nonce casuali.