Supponiamo di non generare in modo casuale i vettori di inizializzazione (utilizzando AES in modalità CBC). Invece è inizialmente tutto zero e lo incrementiamo di 1 ogni volta che un messaggio viene crittografato. Come può questo causare un problema? Potrebbe spiegare con un esempio?
Un codice a blocchi come AES è deterministico: per la stessa chiave e lo stesso input, si ottiene lo stesso risultato. Poiché i dati della vita reale tendono a mostrare ridondanza, ciò rende ECB, la modalità di crittografia più basilare, piuttosto debole . CBC tenta di evitare tale problema "randomizzando" i blocchi di input, attraverso un XOR con il blocco crittografato precedente: l'idea è che l'output di un codice a blocchi dovrebbe apparire "abbastanza casuale". L'AES è ancora deterministico, ma la randomizzazione assicura che il rischio di collisione rimanga molto basso (AES ha blocchi a 128 bit, quindi la prima collisione dovrebbe essere incontrata dopo aver crittografato, in media, circa 2 64 blocchi, ovvero 256 exabyte, ovvero "un sacco di dati", questo non succederà spesso). Poiché il primo blocco non ha un blocco precedente, abbiamo bisogno di un "blocco precedente artificiale" e questo è l'IV. Pertanto, l'IV dovrebbe essere "casuale".
Una prima osservazione di base è che un semplice criterio +1 sulla IV potrebbe non essere abbastanza casuale. Immagina di crittografare i messaggi che contengono alcuni dati come un elenco di coppie "chiave = valore" (ad esempio la codifica standard di un oggetto Properties di Java) e che tutti i messaggi iniziano con userPassword = thepassword (per varie password utente). Con AES e i relativi blocchi da 16 byte, si noti che il primo blocco termina immediatamente dopo la prima lettera della password. Quindi i primi blocchi successivi saranno quasi identici, salvo il loro ultimo byte. Supponiamo che IV e i messaggi siano:
IV message
--------------------------------------------------------------------------------
5c17eacc047fd32fdecc2e0f226e4e86 userPassword = mypassword
5c17eacc047fd32fdecc2e0f226e4e87 userPassword = PaSSwo3D!
5c17eacc047fd32fdecc2e0f226e4e88 userPassword = bob
5c17eacc047fd32fdecc2e0f226e4e89 userPassword = z!Ghj0$.\+
5c17eacc047fd32fdecc2e0f226e4e8a userPassword = anotherpassword
5c17eacc047fd32fdecc2e0f226e4e8b userPassword = correcthorsebatterystaple
Se si elaborano i valori per il primo blocco passato come input per AES per ciascun messaggio, si scoprirà che per il primo e il quinto messaggio si finisce con lo stesso blocco (29648fbe541ea05ca9a35c6b02536ee7). Quindi i primi sedici byte dei due messaggi crittografati saranno identici. Individuando tale uguaglianza, l'attaccante dedurrà esattamente quali bit differiscono nel primo byte di ciascuna password. Osservando molti messaggi successivi, l'attaccante può accumulare parecchie equazioni di questo tipo sui dati sconosciuti. Questo è esattamente il tipo di perdita che una buona crittografia dovrebbe evitare.
La situazione è peggiorata in presenza di attacchi a testo normale scelti : questi sono attacchi in cui il cattivo arriva a scegliere parte del testo in chiaro. Nell'esempio sopra descritto, supponiamo che l'autore dell'attacco sia uno degli utenti e che la sua password sia nel primo messaggio. Quindi, l'attaccante sa che la sua password inizia con una 'm'; osservando la crittografia dei messaggi successivi, deduce che la password nel quinto messaggio inizia con una 'a'. Inoltre, l'attaccante può cambiare la sua password e fare un altro tentativo, ottenere informazioni su altre password e così via.
L' attacco BEAST recentemente pubblicizzato si basa su un CPA, in uno scenario più realistico che coinvolge un browser Web, una connessione HTTPS e un cookie "sicuro" Paypal. La pietra angolare dell'attacco è che i dati in una connessione SSL sono suddivisi in "record", ogni record viene crittografato in modalità CBC e l'ultimo blocco di un record viene utilizzato come IV per il successivo. L'utente malintenzionato forza quindi alcuni dati personali nella connessione, osserva il primo record e calcola i dati che aggiunge (che verranno crittografati come secondo record), in modo che il primo blocco di quei dati XORed con l'IV produce un valore prevedibile. I dettagli sono intricati, ma finiscono con la rivelazione del cookie sicuro. Affinché l'attacco funzioni, tutto ciò di cui l'attaccante ha bisogno è un prevedibile IV, che ottiene osservando i record ( TLS 1.1 corregge quello aggiungendo per-random random IV).
Per riassumere, l'attacco BEAST dimostra che CBC con un IV che può essere previsto da un utente malintenzionato che può eseguire attacchi con testo in chiaro, è debole. Una politica di +1 per la gestione IV porta a IV che può essere facilmente previsto. Quindi ...
Si deve notare che mentre CBC richiede IV casuale, uniforme, imprevedibile, non tutte le modalità di cifratura a blocchi di operazioni sono così schizzinose. Molte nuove modalità, in particolare quelle che combinano crittografia e controllo dell'integrità, possono convivere con IV non ripetitive anche se i valori IV sono totalmente non casuali (ad esempio EAX o GCM ); per loro, un +1 su IV è perfettamente a posto. In alcuni protocolli, questo consente un implicito IV (un numero di sequenza, per i messaggi successivi inviati su un filo) che può salvare un po 'di larghezza di banda.
Non utilizzare un IV casuale con modalità CBC è una vulnerabilità riconosciuta da CWE-329
L'IV è quasi sempre noto all'attaccante, e idealmente questo valore è inutile senza la chiave segreta.
Tuttavia, se l'attaccante sa quale IV sarà per un determinato messaggio di testo normale o se l'attaccante può controllare il messaggio, allora può calcolare tutte le possibili chiavi per quella combinazione di Messaggio + IV. Il codice prodotto da questo messaggio + IV + chiave può quindi essere cercato nella tabella precalcata per ottenere la chiave segreta in un brevissimo periodo di tempo.
Ho posto questa domanda su Stack Overflow e erickson ha dato un'ottima risposta .
Leggi altre domande sui tag encryption aes