Domanda:
Costretto a usare un IV statico (AES)
Mantorok
2010-12-10 21:44:35 UTC
view on stackexchange narkive permalink

Abbiamo dovuto estendere il nostro sito Web per comunicare le credenziali utente a un sito Web di fornitori (nella stringa di query) utilizzando AES con una chiave a 256 bit, tuttavia utilizzano un IV statico per decrittografare le informazioni.

Ho consigliato che l'IV non dovrebbe essere statico e che non è nei nostri standard farlo, ma se lo cambiassero alla loro fine dovremmo sostenere i [grandi] costi, quindi abbiamo deciso di accettarlo come un rischio per la sicurezza e utilizzare lo stesso IV (con mia grande frustrazione).

Quello che volevo sapere è, quanto rappresenta una minaccia alla sicurezza? Devo essere in grado di comunicarlo in modo efficace alla direzione in modo che sappia esattamente cosa sta accettando.

Stiamo anche utilizzando la stessa CHIAVE ovunque.

Grazie

Tre risposte:
#1
+40
Thomas Pornin
2010-12-10 22:54:49 UTC
view on stackexchange narkive permalink

Dipende dalla modalità di concatenamento. AES è un cifrario a blocchi, viene applicato su blocchi di 16 byte (esattamente). La modalità concatenamento definisce il modo in cui i dati di input diventano diversi blocchi di questo tipo e come i blocchi di output vengono quindi assemblati. La maggior parte delle modalità di concatenamento deve funzionare con una sorta di "valore iniziale", che non è segreto ma dovrebbe cambiare per ogni messaggio: questo è l'IV.

Riutilizzare lo stesso IV è mortale se si utilizza il concatenamento CTR modalità. In modalità CTR, AES viene utilizzato su una sequenza di valori di contatore successivi (che iniziano con IV) e la sequenza risultante di blocchi crittografati viene combinata (da XOR bit per bit) con i dati da crittografare (o decrittografare). Se usi la stessa flebo, ottieni la stessa sequenza, che è il famigerato "two-time pad". Fondamentalmente, XORing due stringhe crittografate insieme, si ottiene lo XOR dei due dati in chiaro. Questo apre a un sacco di attacchi e fondamentalmente l'intera faccenda è rotta.

Le cose sono meno terribili se usi CBC. In CBC, i dati stessi vengono suddivisi in blocchi da 16 byte. Quando un blocco deve essere crittografato, viene prima XORed con il precedente blocco crittografato . L'IV ha il ruolo del blocco "-1" (il blocco crittografato precedente per il primo blocco). La principale conseguenza del riutilizzo dell'IV è che se due messaggi iniziano con la stessa sequenza di byte, anche i messaggi crittografati saranno identici per alcuni blocchi. Questo fa trapelare dati e apre la possibilità di alcuni attacchi.

Per riassumere, non farlo. Usare lo stesso IV con la stessa chiave sconfigge sempre e sempre l'intero scopo dell'IV, motivo per cui è stata utilizzata una modalità concatenamento con IV in primo luogo.

Sono solo intervenuto per dire che la risposta di Thomas Pornin (e il commento di GregS) sono assolutamente corretti. Cordiali saluti, Thomas Pornin è un crittografo e crittoanalista molto rispettato.
Questa è la risposta esatta. Se hai la possibilità di inserire dati casuali da qualche parte nel messaggio prima che i dati inizino a diventare sensibili, dovresti essere d'oro (i dati casuali serviranno come IV di un uomo povero). Dovresti usare almeno un blocco di dati casuali. Ad esempio, se stai inviando un messaggio in formato XML e puoi inserire un attributo `random-data =" # {base_64_encode (secure_random_bytes (32))} "" nell'elemento radice XML (senza rompere alcuno schema o contratto) , che dovrebbe sostituire. Ma quando possibile, dovresti evitare le criptovalute dei poveri.
Ho trovato https://crypto.stackexchange.com/questions/3883/ utile per saperne di più sul motivo per cui CBC con un IV statico può essere problematico (probabilmente, le due domande sono duplicati).
#2
+8
user185
2010-12-10 22:46:27 UTC
view on stackexchange narkive permalink

Usare lo stesso IV per tutti i dati equivale a non usare affatto un IV: il primo blocco di testo cifrato sarà identico per testo in chiaro identico. Sarei interessato a sapere perché il tuo fornitore desidera utilizzare una flebo costante, ma non è questo il punto. Il punto è che il sistema è suscettibile in questo modo: se un utente malintenzionato può impostare le proprie credenziali e osservare il testo cifrato che viene generato, può confrontarlo con altre credenziali crittografate per trovare informazioni sulla chiave.

Le prime 2 frasi di questa risposta sono corrette, ma l'ultima frase è sbagliata. Un IV statico non rivela informazioni sulla chiave AES. Rivela le informazioni sul primo blocco di testo in chiaro, come accenni.
@D.W. Non sono un crittoanalista sufficientemente esperto per verificarlo, ma questo significa che posso accettare che potrei sbagliarmi. Se puoi fornire un riferimento che lo dimostri, modifico la risposta (oppure puoi ;-).
È una conseguenza di un fatto fondamentale: non esiste un modo noto e fattibile per trovare la chiave AES mediante un attacco solo testo cifrato, testo in chiaro noto o testo in chiaro scelto. Non saprei dove darti un riferimento per questo; una buona lezione di crittografia, forse, o forse un recente libro di testo sulla crittografia. Forse [questo] (http://stackoverflow.com/questions/810533/is-it-possible-to-reverse-engineer-aes256). Se AES fosse suscettibile a un attacco con testo in chiaro scelto che rivelasse informazioni sulla chiave, non sarebbe stato scelto dal NIST: questo è uno dei requisiti fondamentali per un cifrario a blocchi.
#3
+2
Steve
2010-12-10 22:32:53 UTC
view on stackexchange narkive permalink

Non sono un tipo criptato, ma la mia comprensione è che se l'IV non cambia e lo stesso valore viene ricodificato, l'output sarebbe lo stesso. Pertanto sarebbe possibile dedurre il contenuto cercando valori ripetuti, come una credenziale che viene passata ad ogni richiesta.

Anche in questo caso, però, non sono un tipo criptato, quindi potrei sbagliarmi.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 2.0 con cui è distribuito.
Loading...