Come vengono scelti gli attacchi di testo normale contro la BCE implementati nel mondo reale?

9

Leggendo gli attacchi contro AES ho visto innumerevoli esempi del motivo per cui la BCE è cattiva, e la logica dietro di essa è comprensibile, ma non riesco a capire come questi attacchi funzionino realmente nel mondo reale.

Quindi il grande esempio che vedo molto abituato è un token di sessione crittografato con AES-ECB, e come suo token di sessione (cookie ad esempio) possiamo iniettare ripetutamente il testo in chiaro scelto e monitorare le modifiche nel testo cifrato, supponendo che il token di sessione sia sempre crittografato con la stessa chiave. Ma da che cosa deduciamo il testo in chiaro corretto?

Ad esempio, supponiamo che io inserisca 64 A come nome utente e che nell'esagglomerato del cookie restituito sia possibile vedere la ripetizione ripetuta di 16 blocchi di byte che indicano in modo abbastanza conclusivo che la crittografia è AES-ECB. Posso cambiare gli ultimi 16 A per essere invece 15 A's a B, quindi ora so non solo quale sia il testo cifrato per 16 A, ma anche quale sia il testo cifrato per tutte le A e le B.

Ma poi mi blocco e non vedo come questo attacco si espanda per diventare pratico. Finora tutto quello che posso vedere è che sappiamo come è l'ultimo byte e un mucchio di A.

Buone spiegazioni che ho visto finora sono state: link anche se mi ha perso intorno ai 42 minuti e link

EDIT: Dopo aver pensato al problema, penso che un modo migliore per formulare questa domanda sarebbe - assumendo che il blocco che controlliamo è una lunghezza arbitraria nel testo cifrato, e il testo cifrato totale è una lunghezza arbitaria, come calcoli il lunghezza del prefisso (il numero di A) da iniettare in modo da poter decifrare ogni byte successivo?

EDIT: la modifica sopra riportata che costituisce un'aggiunta alla domanda, "come calcoliamo la lunghezza del prefisso" è in realtà imprecisa. Ho trovato la sua banale calcolare la lunghezza del prefisso del testo cifrato che eseguiamo il controllo non , e l'attacco della BCE come ho visto spiegato è progettato per decifrare il testo che viene esplicitamente dopo il testo cifrato del testo in chiaro scelto.

    
posta AlexH 29.06.2014 - 17:43
fonte

1 risposta

12

Sembra che tu sia sulla buona strada per capire questo. Non ho mai sfruttato il testo in chiaro scelto dalla BCE, ma di recente ho fatto un exploit oracle, quindi ho qualche idea su come farlo.

L'idea di base è quella di forza bruta un byte alla volta.

Supponiamo di avere un semplice esempio in cui non ci sono altri dati inseriti quindi è solo "[nome utente] [segreto]". Innanzitutto, imposta il tuo nome utente su 16 A. Quindi cambi l'ultimo carattere in un B. In effetti, passa attraverso tutti i 256 possibili valori per il byte finale e mantieni una registrazione dei testi cifrati.

Ora imposta il tuo nome utente su 15 A. Il blocco di testo in chiaro sarà composto da 15 A e un byte dal segreto. Il testo cifrato corrisponderà a uno dei testi cifrati generati in precedenza e da questo è possibile dedurre un byte del segreto.

Ora imposta il tuo nome utente su un valore di 16 caratteri: 14 A, l'un byte di testo normale che conosci e passa in rassegna i 256 possibili valori per il byte finale. Registra tutti i testi cifrati. Il passo successivo è impostare il tuo nome utente su 14 A e nient'altro. Dal testo cifrato generato puoi dedurre il secondo byte del segreto.

Continua e molto presto hai il segreto completo!

In uno scenario pratico ci sono probabilmente altre cose che rendono più difficile lo sfruttamento, ma questa è l'idea di base.

    
risposta data 29.06.2014 - 20:24
fonte

Leggi altre domande sui tag