In un'altra domanda risposta , DW ha scritto:
Make sure there is authenticity protection for the encrypted data (e.g., encrypt and then sign/MAC): you will need both confidentiality and authenticity protection. A very common error is to encrypt but fail to sign; this error can introduce subtle security problems
Quali sono esattamente questi problemi di sicurezza?
Un buon esempio è la falla su CBC, dimostrata all'interno di SSL e in particolare per il recupero della password in una configurazione IMAP-over-SSL. Vedi per i dettagli . In breve, SSL ha un MAC, ma una piccola parte di esso stava facendo cose con i dati crittografati ricevuti dopo decrittografia ma prima verificando il MAC . Vale a dire, il sistema ricevente stava decifrando i dati, controllando che il padding fosse corretto, riportando un errore al peer se non era il caso, e quindi controllando solo il MAC. Il messaggio di errore era diverso se il MAC era sbagliato. Quindi il ricevitore (il server, nel caso del recupero della password IMAPS) stava perdendo un singolo bit di informazioni sul fatto che il padding trovato dopo la decodifica fosse corretto o meno. Accade che SSL utilizzi un padding simile a quello descritto in PKCS # 5. I dettagli sono sottili (ma non matematicamente difficili, una volta compreso che XOR è commutativo e associativo) ma ha permesso all'aggressore, modificando alcuni byte ben scelti, di indovinare uno per uno i normali byte di dati. Supponendo un normale tentativo di connessione con contenuti identici (tipicamente, un Outlook Express che controlla il server per la nuova posta ogni 5 minuti), l'autore dell'attacco ha avuto una probabilità di 1/256 di indovinare un nuovo byte ad ogni connessione. Alla fine della giornata, voilà! una password completa.
Questo caso mostra cosa può accadere in presenza di attaccanti attivi e senza MAC, anche quando la parte "no MAC" è molto transitoria; perché SSL ha un MAC, solo che è stato controllato troppo tardi nel processo. La correzione è quella di sempre controllare il MAC, indipendentemente dal fatto che il padding fosse buono o meno, e riportare il riempimento difettoso e il MAC errato con lo stesso codice di errore (devi controllare il MAC, perché non farlo quando il padding è sbagliato può far sì che il server risponda un po 'troppo velocemente in quel caso, perdendo il bit di informazione attraverso i tempi). Senza questa correzione, il server perde alcune informazioni attraverso il suo comportamento, sia esso un messaggio di errore distinto o anche un leggero ritardo (o mancanza di esso) quando risponde. Questo è un singolo bit ad ogni tentativo. Eppure è sufficiente montare un attacco per il recupero della password.
Questo attacco è stato pubblicato nel 2002. Tuttavia, nel 2010, lo stesso bug era ancora presente in ASP gestisce i cookie crittografati , consentendo a un utente malintenzionato di dirottare una sessione protetta in meno di un'ora. L'attacco è stato dimostrato pratico nel 2002; nel 2010, è stato dimostrato come effettivamente praticato sul campo.
Non abbiamo una lista esaustiva degli attacchi resi possibili da una mancanza di MAC. Quindi la saggezza comune è che non esiste una protezione adeguata contro un attaccante attivo quando non c'è un controllo di integrità dedicato, e questo è un MAC. Il comune errore è credere che in ogni situazione data, gli attaccanti possono essere passivi. Le comunicazioni cablate e wireless sono abitualmente soggette a attacchi attivi da parte di cattivoni anche di bassa potenza (ad esempio, studenti annoiati in un cybercafé).
Quando si esegue la crittografia simmetrica, il modo corretto per aggiungere un MAC è utilizzare una modalità combinata di crittografia e MAC come GCM o EAX . Queste sono modalità che si basano su un codice a blocchi (tipicamente AES). Esistono altre modalità, ma alcune sono brevettate; questi due non sono creduti.
Le firme (al contrario di MAC) sono una questione del tutto distinta, in particolare nel loro rapporto con la riservatezza.
Leggi altre domande sui tag cryptography encryption digital-signature