Crittografia autenticata: AES-GCM e ChaCha20-Poly1305

Authenticated Encryption (AE) risolve un problema fondamentale: la cifratura tradizionale garantisce solo la riservatezza, mantenendo segreti i dati, ma non verifica se il ciphertext è stato manomesso. Un aggressore potrebbe modificare alcuni bit del ciphertext e il destinatario decifrerebbe dati privi di senso senza sapere che sono stati alterati. La Authenticated Encryption with Associated Data (AEAD) aggiunge simultaneamente una garanzia di integrità e autenticità, producendo sia il ciphertext cifrato sia un tag di autenticazione che rileva qualsiasi modifica.

AES-GCM (Galois/Counter Mode) combina due componenti: AES-CTR (Counter Mode) per la cifratura e GMAC (Galois Message Authentication Code) per l'integrità. AES-CTR genera un keystream cifrando un valore contatore ed eseguendo l'XOR con il plaintext; questo rende la cifratura parallelizzabile, a differenza della modalità CBC. GMAC calcola un tag di autenticazione sul ciphertext e sugli eventuali dati associati. Il tag risultante, di 128 bit, viene trasmesso insieme al ciphertext; la modifica di un solo bit invalida il tag.

AES-GCM richiede un nonce (numero usato una sola volta), in genere di 96 bit (12 byte). Il nonce deve essere univoco per ogni singola operazione di cifratura con la stessa chiave: non deve essere segreto, ma non deve mai ripetersi. Il riutilizzo del nonce in AES-GCM è catastrofico: se due messaggi vengono cifrati con la stessa chiave e lo stesso nonce, un attaccante può applicare XOR ai testi cifrati per eliminare il keystream e potenzialmente recuperare entrambi i testi in chiaro. Questa vulnerabilità viene talvolta chiamata 'uso improprio del nonce' e ha causato attacchi reali di recupero delle chiavi.

Quando i nonce AES-GCM vengono riutilizzati, l'attaccante può calcolare C1 XOR C2 = P1 XOR P2 (lo XOR dei due testi in chiaro), perché per entrambi è stato usato lo stesso keystream. Inoltre, il riutilizzo del nonce consente di recuperare la chiave di autenticazione H, permettendo all'attaccante di forgiare tag di autenticazione validi per messaggi arbitrari e compromettendo completamente sia la riservatezza sia l'integrità. Sistemi come la Sony PS3 hanno subito esattamente questo attacco. La difesa consiste nell'usare nonce casuali (generati con un CSPRNG) oppure un contatore deterministico che non venga mai reimpostato.

ChaCha20-Poly1305 è l'altro cifrario AEAD obbligatorio in TLS 1.3. ChaCha20 è un cifrario a flusso progettato da Daniel Bernstein che genera un keystream usando operazioni addizione-rotazione-XOR (ARX): non utilizza tabelle di ricerca, ha un tempo di esecuzione completamente costante ed è estremamente veloce sulle CPU prive di accelerazione hardware per AES. Poly1305 è un MAC monouso (codice di autenticazione del messaggio) che calcola il tag di autenticazione sul testo cifrato. Insieme, offrono una sicurezza equivalente a quella di AES-GCM, ma sono significativamente più veloci sui dispositivi mobili e IoT.

I moderni processori x86 e ARM64 per desktop e server includono istruzioni hardware AES-NI che rendono AES-GCM estremamente veloce. Tuttavia, molti processori per dispositivi mobili e IoT non dispongono di AES-NI, rendendo relativamente lento AES-GCM implementato via software. ChaCha20-Poly1305 è stato progettato per essere veloce via software, grazie all'uso di semplici operazioni aritmetiche, e offre ai dispositivi mobili prestazioni comparabili senza accelerazione hardware. Google ha aggiunto ChaCha20-Poly1305 a TLS come alternativa proprio per i dispositivi Android, e oggi è una suite di cifratura di primo livello in TLS 1.3.

La sigla 'AD' in AEAD sta per Associated Data (dati associati): metadati in chiaro autenticati ma non cifrati. Ciò consente di autenticare dati che devono rimanere leggibili, come le intestazioni dei pacchetti o i campi relativi al tipo di record, proteggendoli al tempo stesso dalle manomissioni. In TLS 1.3, i byte dell'intestazione del record sono inclusi come dati associati nel calcolo AEAD. Se un attaccante modifica l'intestazione, ad esempio cambiando la lunghezza del record, la verifica del tag di autenticazione fallisce e la connessione viene terminata.

Prima che AEAD diventasse uno standard, i crittografi raccomandavano Encrypt-then-MAC (EtM): cifrare il testo in chiaro e poi calcolare un MAC sul testo cifrato. Questo approccio è sicuro, ma richiede due operazioni separate con due chiavi separate. Gli schemi AEAD come AES-GCM combinano entrambe le operazioni usando una sola chiave, riducendo la complessità dell'implementazione ed eliminando un'intera classe di attacchi padding oracle che affliggeva MAC-then-Encrypt (MtE), l'ordine usato nelle versioni precedenti di TLS (CBC + HMAC). TLS 1.3, usando AEAD, evita completamente questi problemi.

Sia AES-128-GCM sia AES-256-GCM sono approvati dal NIST e considerati sicuri contro i computer classici. AES-128 offre una sicurezza di 128 bit con prestazioni leggermente migliori; AES-256 offre una sicurezza di 256 bit, garantendo un margine maggiore contro la crittoanalisi futura e le minacce quantistiche. Per la maggior parte delle applicazioni odierne, AES-128-GCM è sufficiente, ma i sistemi governativi con informazioni classificate (NSA Suite B) richiedono AES-256. TLS 1.3 offre entrambe le opzioni e i server possono stabilire le priorità in base alla propria policy di sicurezza.

Quando decifra un testo cifrato AEAD, il destinatario deve verificare il tag di autenticazione prima di decifrare. Il processo consiste nel ricalcolare il tag previsto a partire dal testo cifrato ricevuto, dalla chiave e dal nonce; confrontarlo con il tag ricevuto usando una funzione di confronto a tempo costante; procedere con la decifratura solo se i tag coincidono. Il confronto a tempo costante è fondamentale: se il confronto si interrompe al primo byte diverso, un attaccante può eseguire un attacco side-channel basato sui tempi per forgiare tag validi un byte alla volta. Qualsiasi libreria AEAD che utilizzi un confronto con uscita anticipata è vulnerabile.

Gli algoritmi AEAD sono onnipresenti nella sicurezza moderna: TLS 1.3 usa AES-GCM e ChaCha20-Poly1305 per la cifratura di tutti i record; WireGuard VPN usa esclusivamente ChaCha20-Poly1305; Signal Protocol lo usa per la cifratura dei messaggi; il protocollo QUIC (alla base di HTTP/3) usa AES-GCM. Quando vede una suite di cifratura come TLS_AES_256_GCM_SHA384, SHA384 si riferisce alla funzione hash HKDF per la derivazione delle chiavi, non al meccanismo di integrità: è il tag GCM a gestire l'integrità.

In questa lezione ha imparato che: gli algoritmi AEAD forniscono simultaneamente riservatezza e integrità tramite un tag di autenticazione che rileva qualsiasi modifica al testo cifrato; il riutilizzo del nonce AES-GCM è catastrofico, perché consente di recuperare il keystream e forgiare la chiave di autenticazione, quindi i nonce devono essere univoci per ogni cifratura; infine, ChaCha20-Poly1305 è l'alternativa più efficiente ad AES-GCM per i dispositivi privi di accelerazione hardware per AES. Nella prossima lezione esploreremo le funzioni di derivazione delle chiavi per la protezione delle password.