Crittografia dei dati crittografati a riposo

1

Immagina di avere un file crittografato usando la modalità CBC AES con una chiave e una IV casuale. L'attaccante accede al testo crittografato e l'IV usato ma non la chiave.

In questo scenario non c'è vulnerabilità poiché la IV è casuale.

Ora assumiamo che l'attaccante ottenga informazioni sul testo in chiaro usato. Il testo in chiaro è un modulo di sondaggio compilato da un utente. Quindi esiste un formato fisso per i dati crittografati. In tal caso, se ipotizziamo che l'autore dell'attacco abbia accesso al modulo di sondaggio vuoto (con le domande), ciò modifica la presunta sicurezza dei dati crittografati? L'IV casuale non ha più importanza. La situazione si presta a un attacco di testo in chiaro scelto. Mi sto perdendo qualcosa qui?

Come proteggi i dati in questo caso?

EDIT: la chiave viene generata in modo casuale e memorizzata in un database completamente separato dai dati crittografati.

    
posta user220201 23.05.2014 - 19:32
fonte

2 risposte

4

L'intero punto della crittografia simmetrica è che se un utente malintenzionato non ha la chiave, non può decodificare i dati. AES non ha attacchi fattibili computazionalmente noti ( significativamente migliori di quelli brute-forzando l'intero spazio chiave 128 ) su di esso che sono rilevanti per questo scenario.

Se i dati sono a riposo, non esiste un attacco in chiaro in chiaro: non esiste un sistema che accetti il testo in chiaro scelto e lo crittografa. Puoi solo eseguire l'attacco in chiaro in chiaro se un utente malintenzionato può inviare un testo in chiaro ad un sistema che lo cripta e restituisce il testo cifrato.

Ora, se si espandeva la superficie di attacco a una in cui un utente malintenzionato poteva richiedere che un testo in chiaro venisse crittografato con una chiave sconosciuta, esiste un potenziale attacco di testo in chiaro se l'IV viene riutilizzato o noto all'avversario prima di inviare il testo in chiaro.

Con la superficie di attacco espansa, quindi se (1) l'IV è stato corretto o noto all'attaccante prima di inviare il testo in chiaro, e (2) un utente malintenzionato potrebbe convincere il tuo sistema (che ha la chiave) a crittografare il testo arbitrario presentato da loro, e (3) lo spazio dei messaggi per ogni blocco è abbastanza piccolo (solo diciamo alcune migliaia / milioni / miliardi di possibilità che è significativamente più piccola delle 2 opzioni complete 128 consentite con 16 byte arbitrari) per ogni blocco di 16 byte di testo in chiaro), quindi sì l'attaccante può inviare in modo arbitrario un testo in chiaro con la stessa IV fissa (o account per il cambiamento IV quando indovina il testo in chiaro) fino a quando non trovano una corrispondenza per ogni blocco del testo cifrato che desiderano decifrare. Potrebbero fare questo blocco per blocco (un blocco AES è 128-bit = 16 byte) per indovinare sequenzialmente il testo in chiaro originale mediante brute-force (dello spazio dei messaggi piccolo).

Tuttavia con un IV casuale a 128 bit non noto in anticipo, questo attacco non funzionerebbe. Perché? Perché in modalità CBC c[0] = E(k, p[0] XOR IV) , c[i] = E(k, p[i] XOR c[i-1]) per i > 0 e IV cambia ogni volta (ed è sconosciuto quando si invia il testo in chiaro, quindi non si può tenere conto della modifica in IV e della modifica della propria ipotesi di p [0]).

How do you protect the data in this case?

I dati sono già protetti.

    
risposta data 23.05.2014 - 20:58
fonte
0

I dati sono protetti. L'utente malintenzionato non può decifrare il suo contenuto, nemmeno con il testo in chiaro (parziale) (altrimenti parleremmo di AES come un codice cifrato).

Tuttavia, devi anche proteggere integrità .

Ad esempio, supponiamo che il sondaggio contenga alcune domande Sì / No e che stessimo criptando in modalità CTR. Se Eva ha accesso alle risposte all'indagine fornita da altri dipendenti, potrebbe cambiare ciecamente le risposte di qualcuno che lei odia per farle sembrare cattive (ad esempio, immagina che un quesiton sia «Sei un terrorista?»).

L'uso di CBC rende l'attacco più difficile, in quanto il prossimo blocco sarebbe corrotto, ma non lo eliminerei. Una soluzione sarebbe quella di salvare un hash alla fine e verificare che corrisponda al messaggio decrittografato.

    
risposta data 24.07.2014 - 21:57
fonte

Leggi altre domande sui tag