it-swarm.dev

La crittografia simmetrica fornisce integrità dei dati?

Diciamo che ho un server che crittografa un file con una chiave simmetrica, ad es. AES-CBC e lo invia ai client che lo decodificano. Fornisce integrità dei dati quando viene decrittografato? Oppure è possibile che qualcuno manometta il file mentre è ancora crittografato e in seguito quando il client lo decodifica, produce un file modificato?

In genere vedo l'integrità e l'autenticità dei dati discussi in termini di utilizzo di firme digitali o MAC, ma mai nel contesto della crittografia. Ho anche visto benchmark che mostrano che la crittografia è più costosa dell'hash, ma questa non è la mia considerazione principale.

[~ ~ #] aggiornamento [~ ~ #]

Ho provato un esperimento, in cui ho usato lo strumento openssl in Linux per crittografare un file. Quindi, ho provato a modificare il file in vari modi (modificando un byte, eliminando un byte, aggiungendo un byte). In ogni caso, quando provassi a decifrare, avrei ricevuto un messaggio "decodifica errata". I comandi che ho usato sono stati:

openssl enc -aes-128-cbc -in test -out test.enc
openssl enc -d -aes-128-cbc -in test.enc -out test.dec
18
88keys

La crittografia simmetrica non fornisce integrità. La quantità di controllo che un utente malintenzionato può avere sui dati crittografati dipende dal tipo di crittografia; e alcuni dettagli specifici di alcune modalità di crittografia possono rendere la vita un po 'più difficile per l'attaccante se desidera apportare modifiche chirurgiche. Con CBC, l'attaccante può capovolgere qualsiasi bit desideri, a condizione che non gli dispiaccia trasformare una dozzina di altri byte in junk casuale.

Ci sono recenti modalità di crittografia che combinano la crittografia simmetrica e l'integrità controllata (con un MAC ). Queste modalità garantiscono riservatezza e integrità. AES-CBC è no uno di questi. Se si desidera una modalità di crittografia con integrità, si consiglia EAX .

Aggiornamento: relativo all'esperimento: CBC è una modalità in cui la lunghezza dei dati di origine deve essere un multiplo della lunghezza del blocco di crittografia del blocco (16 byte, per AES) . Poiché un messaggio di input arbitrario può avere qualsiasi lunghezza, vengono aggiunti alcuni padding: pochi byte, con contenuti specifici in modo tale che possano essere rimossi in modo inequivocabile al momento della decodifica. Nel tuo caso, OpenSSL si lamenta che, al momento della decodifica, non trova una struttura di imbottitura adeguata. Tuttavia, se l'attaccante non modifica gli ultimi 32 byte dei dati crittografati, l'imbottitura non sarà danneggiata, quindi le alterazioni di tutti tranne gli ultimi 32 byte rimarranno inosservate. E anche per gli ultimi 32 byte, ci sono modi per eludere il rilevamento con una probabilità non così piccola.

19
Tom Leek

La crittografia CBC non fornisce integrità dei dati. Ecco perché:

Risolto un problema con la chiave k (sconosciuta all'attaccante). Sia E (k, -) e D (k, -) le funzioni di crittografia e decrittografia di alcuni cifrari a blocchi. Sia p un blocco singolo di testo in chiaro. Indicheremo XOR di +. Dopo aver corretto alcuni IV, crittografiamo come segue:

c = E (k, p + IV).

Quindi, inviamo IV ec sul filo. Per decifrare, calcoliamo

p = D (k, c) + IV.

(Si noti che questo equivale all'istruzione D (k, c) = IV + p.)

Supponiamo ora che un utente malintenzionato conosca una singola coppia in testo normale/testo cifrato. Indichiamoli come p e (IV, c), come sopra. Supponiamo ora che l'attaccante vorrebbe creare un testo cifrato che decifrerà in qualche altro blocco di testo in chiaro di sua scelta - diciamo p '. Dichiaro che (IV + p + p ', c) decrittografa in p'. Perché?

Bene, seguiamo semplicemente la procedura di decodifica sopra, sostituendo IV con IV + p + p '. abbiamo

D (k, c) + (IV + p + p ') = (IV + p) + (IV + p + p') = p '.

In modo divertente, la modalità BCE non è vulnerabile a questo problema (anche se non ne approvo nemmeno l'uso).

12
iamtheneal

La crittografia AES-CBC non fornisce integrità. A seconda di come viene implementato e utilizzato, potrebbe capitare di rilevare alcune modifiche accidentali al testo cifrato, ma non difende dalla manomissione malevola del testo cifrato .

La crittografia senza autenticazione è uno degli errori più comuni nell'uso della crittografia . Ha portato a serie vulnerabilità in molti sistemi, tra cui ASP.NET, crittografia XML, Amazon EC2, JavaServer Faces, Ruby su Rails, OWASP ESAPI, IPSEC e WEP. Vedere il link precedente per maggiori informazioni.

La correzione: utilizzare uno schema di crittografia autenticato (non AES-CBC), come EAX, oppure utilizzare un codice di autenticazione dei messaggi, come CMAC, in modalità crittografia e autenticazione.

Se stai per implementare la crittografia da solo, ti incoraggio a leggere la domanda qui intitolata Lezioni apprese e idee sbagliate su crittografia e crittografia per aiutarti ad evitare alcuni degli errori più comuni. L'uso della crittografia senza autenticazione è uno di questi.

9
D.W.

Le cifre simmetriche non forniscono di per sé integrità perché non rilevano modifiche dannose o accidentali al testo cifrato; la decrittografia produrrà qualcos'altro rispetto al testo in chiaro originale e, a meno che ciò non comporti una violazione del protocollo per il payload decrittografato, si verifica un problema di integrità.

La soluzione è racchiudere il testo in chiaro all'interno dei pacchetti che includono dati che possono essere utilizzati per convalidare l'integrità del pacchetto, in genere un checksum basato su hash ( modifica: HMAC con chiave). Questo è ciò che viene fatto, ad es. per la sicurezza del livello di trasporto.

Ecco un esempio di uno schema di protezione del testo in chiaro utilizzato in un protocollo di trasporto di byte sicuri Versile Platform (dichiarazione di non responsabilità: sono coinvolto nello sviluppo di VP).

Modifica: Ho capito che l'incapsulamento dei messaggi è eccessivo per il tuo scenario che coinvolge un file completo, quindi è meglio aggiungere un MAC con chiave al completo testo cifrato. Per formati protetti da pacchetti, come D.W. sottolinea la questione dei dettagli e "checksum" deve essere eseguito come MAC con chiave.

5
Versile