AES-GCM può proteggere la riservatezza di un messaggio e rilevare modifiche non autorizzate. Da solo non indica al destinatario se un messaggio altrimenti valido sia già stato elaborato.
È facile confondere tre requisiti: coppie chiave/nonce uniche per la cifratura, autenticazione del messaggio e del suo contesto, e gestione dei replay a livello di protocollo. HKDF può aiutare a derivare le chiavi, ma non soddisfa automaticamente tutti e tre.
Il riutilizzo di un nonce e un replay sono eventi diversi
| Evento | Che cosa accade | Protezione necessaria |
|---|---|---|
| Riutilizzo del nonce durante la cifratura | Testi in chiaro diversi vengono cifrati con la stessa chiave GCM e lo stesso nonce | Una strategia affidabile di assegnazione di chiavi e nonce |
| Manomissione | Viene modificato il testo cifrato o il contesto autenticato | Decifratura autenticata e rifiuto in caso di errore |
| Replay | Un messaggio cifrato precedentemente valido viene recapitato di nuovo | Stato e regole applicative che riconoscano duplicati o messaggi obsoleti |
| Riordinamento | I messaggi validi arrivano in un ordine diverso | Ordine definito dal protocollo e gestione limitata dei messaggi fuori ordine |
Un testo cifrato riproposto può ancora avere un tag di autenticazione valido. Nulla è stato modificato. È quindi scorretto dire che ogni duplicato fallisce automaticamente l’autenticazione AES-GCM. RFC 5116 separa esplicitamente l’interfaccia AEAD dai servizi anti-replay.
Perché la coppia chiave-nonce non deve ripetersi
Il nonce di GCM non deve essere segreto, ma deve rispettare i requisiti di unicità dello schema per una determinata chiave. Un nonce di 96 bit, cioè 12 byte, è comune; scegliere questa lunghezza non garantisce una generazione corretta.
Riutilizzare la stessa chiave e lo stesso nonce per testi in chiaro diversi riutilizza il flusso di cifratura, esponendo relazioni tra i testi. Può anche compromettere l’autenticità e consentire falsificazioni. L’impatto è grave, ma non va descritto come una rivelazione automatica di tutte le vecchie chiavi o di ogni messaggio di un account. L’ambito interessato dipende dalla chiave riutilizzata e dal protocollo.
NIST SP 800-38D definisce GCM e i suoi requisiti. Le implementazioni devono rispettare i limiti di invocazione e le regole di generazione dei nonce applicabili, non una regola semplicistica come «sicuro fino a questo numero di messaggi».
Che cosa offre HKDF
HKDF, specificato in RFC 5869, deriva materiale crittografico da materiale segreto in ingresso mediante fasi di estrazione ed espansione. I protocolli possono usare etichette di contesto e input distinti per separare chiavi destinate a scopi diversi.
HKDF è deterministico. Se un client che ha subito un arresto anomalo o è stato riportato a uno stato precedente ripete lo stesso stato e gli stessi input, può derivare di nuovo lo stesso output. Aggiungere HKDF a un progetto non rende quindi impossibile il riutilizzo dei nonce.
Le chiavi per messaggio possono ridurre la quantità di contenuto protetta da una singola chiave, ma restano importanti l’avanzamento sicuro dello stato, la separazione delle chiavi e la loro eliminazione. Lo stesso valore di nonce con chiavi davvero diverse non è lo stesso errore della ripetizione di una coppia chiave/nonce; il protocollo deve stabilire che le chiavi siano effettivamente diverse.
La protezione dai replay appartiene al protocollo
Un destinatario può tenere traccia degli identificatori dei messaggi, delle posizioni nella sequenza, delle epoche di sessione o delle chiavi ratchet consumate. I campi pertinenti devono essere autenticati, affinché un attaccante non possa rietichettare un vecchio messaggio come nuovo.
L’applicazione deve poi decidere che cosa significhi un duplicato. Mostrare due volte un fumetto della chat è fastidioso; eseguire la stessa azione due volte può essere più grave. I tentativi ripetuti di rete sono normali, quindi spesso è necessaria un’elaborazione idempotente accanto ai controlli crittografici.
Non richiedere che tutti i messaggi validi arrivino rigorosamente in ordine, salvo che il protocollo specifichi questo comportamento. I client mobili si riconnettono, ritentano e ricevono abitualmente messaggi in ritardo. Una gestione sicura distingue un messaggio legittimo arrivato tardi da uno già consumato o associato al contesto sbagliato.
Che cosa testare prima di dichiarare una protezione
- Riavvio dopo l’assegnazione di un nonce ma prima della registrazione dell’invio: l’assegnazione può ripetersi?
- Ripristino di un’istantanea precedente dello stato: chiavi, contatori o registri dei replay possono tornare indietro?
- Invio simultaneo da due processi di lavoro o dispositivi: i rispettivi domini chiave/nonce sono separati?
- Consegna doppia dello stesso messaggio valido: l’azione applicativa viene eseguita una sola volta?
- Modifica di un identificatore di sessione o di un’intestazione: il contesto è vincolato crittograficamente?
- Consegna di messaggi validi fuori ordine: i ritardi supportati vengono gestiti senza accettare uno stato obsoleto?
Le API di decifratura autenticata dovrebbero restituire il testo in chiaro all’applicazione solo dopo una verifica riuscita. È un requisito dell’interfaccia, non l’affermazione che nessuna implementazione calcoli mai internamente un buffer temporaneo di testo in chiaro.
Leggere con precisione le affermazioni di Livara
La documentazione di sicurezza di Livara nomina AES-256-GCM, catene per messaggio e contesto LVR1/LGS1. Queste primitive non dimostrano autonomamente la correttezza del recupero dagli arresti anomali, dell’assegnazione dei nonce o del rifiuto dei replay. Tali affermazioni richiedono dettagli del protocollo con versioni identificate e prove di test.
Un progetto solido assegna esplicitamente ogni compito: la derivazione genera le chiavi previste, AEAD autentica contenuto e contesto, e la logica del protocollo con stato decide se un messaggio valido sia accettabile ora.
