Quanto è difficile modificare il testo cifrato AES in modo significativo

Se il testo in chiaro inserito si inserisce in un singolo blocco, modificarlo in modo significativo senza conoscere la chiave dovrebbe essere davvero dannatamente impossibile, nel senso tecnico di poterlo fare (anche solo una parte del tempo) conta come un'interruzione su larga scala di AES.

In altre parole, la crittografia single-block AES è auto-autenticante nel grado esatto in cui lo spazio di valori inattivi è piccolo rispetto nello spazio di tutti i possibili blocchi (supponendo che il destinatario verifichi effettivamente che il blocco decifrato sia valido). Non importa se i testi in chiaro validi sono per lo più simili o sembrano molto diversi; tutto ciò che conta è solo il numero di quelli che ci sono. Questo perché AES, come ogni altro buon codice a blocchi, dovrebbe comportarsi come una permutazione pseudo-casuale dello spazio di tutti i possibili blocchi.

Questo ovviamente ignora la possibilità di attacchi al protocollo di livello superiore, come ad esempio l'ingannare il destinatario ad accettare un blocco che era già crittografato separatamente (per esempio, per una diversa esecuzione del protocollo).

Una volta che il testo in chiaro è più lungo di un blocco, l'uso di ECB rende banalmente facile combinare elementi di messaggi codificati separatamente ai limiti dei blocchi. Ma questa è una proprietà della BCE, non di AES in particolare. Nessuna applicazione a metà strada dovrebbe utilizzare la BCE per i dati che non sono noti sempre per adattarsi a un singolo blocco.

Nel tuo esempio sembra che sarebbe molto più rilevante attaccare l'applicazione A direttamente che attaccare la comunicazione tra A e B. Ad esempio, se l'applicazione A viene eseguita su un dispositivo o account che l'utente controlla, l'utente potrebbe probabilmente modificare i dati prima che l'applicazione A li possa anche crittografare e / o ispezionare l'applicazione (in esecuzione?) per estrarre la chiave.

In alternativa, sembra che il protocollo che stai schizzando sia probabilmente vulnerabile agli attacchi di riproduzione, senza preoccuparsi di modificare tutti i messaggi. Ciò significa che un attacco al trasporto TLS (come ingannare il client nel trust di una CA radice che controlli) potrebbe essere trasformato in un attacco alla parte di autenticazione - ad esempio la crittografia aggiuntiva delle credenziali potrebbe dare molto meno sicurezza che i progettisti intendono.

La modifica dei dati crittografati è talvolta possibile tramite un attacco bitflip . Questo è più un attacco della modalità di operazione a blocchi di crittografia e non proprio all'algoritmo di crittografia. In alcune modalità operative (ma non in ECB) il testo cifrato è XORed con testo in chiaro dal blocco successivo o precedente. Ciò significa che girare un po 'altera un intero blocco e capovolge un bit in un altro blocco.

Per un esempio pratico, considera che viene offerto un cookie crittografato che contiene quanto segue:

{"user": "johndoe", "nick": "john", "admin": 0}

Quando viene crittografato utilizzando la modalità CBC, viene suddiviso in blocchi di 16 byte. Ogni blocco è XORed con il blocco precedente (o il vettore di inizializzazione) e crittografato. Il messaggio è composto dai seguenti blocchi:

• {"user": "johndo
• e", "nick": "joh
• n", "admin": 0}

Nelnostroattaccodibitflip,giriamounpo'iltestocifratodelblocco2.Ciòfaràsìcheilblocco2neltestoinchiarodecrittografatodiventiinutile,macapovolgeràancheunbitnelblocco3.CiòaccadeperchéilrisultatodelladecrittografiaèXORedconiltestocifratodelbloccoprecedente,cheèsottoilnostrocontrollo:

IlrisultatoèuncookiecontenenteJSONvalido,conilflagadminimpostatosu1:

{"user": "johndoaRbUTPasBIrmAnO5n", "admin": 1}