Crittografia NON protegge automaticamente i dati da modifiche.
Per esempio, diciamo che abbiamo un codice di flusso che è semplicemente un PRNG (generatore di numeri casuali), dove la chiave è il seme. La crittografia funziona generando numeri casuali in sequenza (il keystream) ed escludendoli, oppure eseguendoli con il testo in chiaro. Se un utente malintenzionato conosce alcuni byte di testo in chiaro e in chiaro in un punto particolare, può crearli insieme per ripristinare il flusso di chiavi per quei byte. Da lì, può semplicemente scegliere alcuni nuovi byte di testo in chiaro e condividerli con il keystream.
Spesso l'attaccante non deve conoscere il testo in chiaro per ottenere qualcosa. Facciamo un esempio in cui un utente malintenzionato ha semplicemente bisogno di corrompere un particolare campo nei dati interni di un pacchetto. Non sa quale sia il suo valore, ma non ne ha bisogno. Semplicemente sostituendo quei byte di testo cifrato con numeri casuali, ha cambiato il testo in chiaro.
Questo è particolarmente interessante nei cifrari a blocchi in cui viene usato il padding, in quanto ci apre fino a riempire gli attacchi di oracle . Questi attacchi implicano la modifica del testo cifrato in un modo che altera la stringa di riempimento e osservando il risultato. Altri attacchi come BEAST e Lucky Thirteen Attack comporta la modifica del testo cifrato in modo simile. Questi tendono a fare affidamento sul fatto che alcune implementazioni decifrano ciecamente i dati prima di eseguire qualsiasi tipo di controllo di integrità.
Inoltre, potrebbe essere possibile inviare nuovamente un pacchetto crittografato, che potrebbe causare un comportamento sul client o sul server. Un esempio di questo potrebbe essere un comando per commutare lo stato abilitato del firewall. Questo è chiamato un attacco di replay e la crittografia da sola non proteggerà contro di essa. In effetti, spesso i controlli di integrità non risolvono questo problema.
Esistono, infatti, tre proprietà primarie che sono auspicabili in uno schema di comunicazione sicuro:
-
Riservatezza - La possibilità di impedire agli intercettatori di scoprire il messaggio in chiaro o le informazioni sul messaggio in chiaro (ad esempio, il peso di hamming).
-
Integrità : la possibilità di impedire a un utente malintenzionato attivo di modificare il messaggio senza che gli utenti legittimi se ne accorgano. Questo di solito viene fornito tramite un Message Integrity Code (MIC).
-
Autenticità : la capacità di dimostrare che un messaggio è stato generato da una particolare parte e impedire la falsificazione di nuovi messaggi. Questo di solito viene fornito tramite un Message Authentication Code (MAC). Nota che l'autenticità implica automaticamente l'integrità.
Il fatto che MAC e MIC possano essere forniti da un singolo schema di hash HMAC opportunamente scelto (talvolta chiamato MAIC) in alcune circostanze è del tutto incidentale. La differenza semantica tra integrità e autenticità è reale, in quanto è possibile avere integrità senza autenticità e un tale sistema può ancora presentare problemi.
La vera distinzione tra integrità e autenticità è difficile da definire, come mi ha fatto notare Thomas Pornin in chat:
There's a tricky definition point there. Integrity is that you get the "right data", but according to what notion of "right" ? How comes the data from the attacker is not "right" ? If you answer "because that's from the attacker, not from the right client" then you are doing authentication...
È un po 'un'area grigia, ma in entrambi i casi siamo tutti d'accordo sul fatto che l'autenticazione è importante.
Un'alternativa all'utilizzo di un MAC / MIC separato consiste nell'usare una modalità di cifratura a blocchi autenticata, come Gallois / Counter Mode ( GCM) o modalità EAX .