In che modo l'attacco di ChopChop contro WEP funziona davvero?

Question

In che modo l'attacco di ChopChop contro WEP funziona davvero?

#1 da (1 voti)

2

Da quanto ho capito, l'attacco di ChopChop contro WEP, che ha lo scopo di decrittografare un pacchetto senza conoscere la chiave WEP, equivale a questo:

In primo luogo, l'attaccante prende un messaggio di testo cifrato dal flusso RF, indirizzato all'AP di destinazione. Successivamente, "abbassa" l'ultimo byte del messaggio, immediatamente prima dell'ICV (che è anche crittografato nel pacchetto) e lo sostituisce con un valore casuale compreso nell'intervallo da 01 a FA. Quindi, l'utente malintenzionato trova questa posizione di byte modificata nell'ICV e calcola che è corretta (poiché è CRC-32 lineare), pertanto il pacchetto modificato avrà il checksum ICV corretto quando viene controllato dall'AP durante il processo di decrittografia.

I pacchetti ora vengono iniettati nell'AP. L'attaccante ascolta il traffico broadcast per vedere se il pacchetto (richiesta ARP, nella maggior parte dei casi) viene nuovamente ritrasmesso.

Non riesco a capire, se il checksum è sempre corretto (l'attaccante lo calcola per corrispondere al mutato con il byte di testo in chiaro nel testo cifrato subito prima dell'iniezione di pacchetti nell'AP), come l'AP sa che il byte modificato è in realtà sbagliato e non corrisponde al testo in chiaro?

L'AP decodificherà il pacchetto (l'ultimo byte in chiaro verrà ignorato dall'algoritmo di decodifica, è già in chiaro), quindi calcolerà il checksum del testo in chiaro e vedrà se corrisponde al valore ICV decrittografato. E sarà sempre uguale, perché l'attaccante calcola appena prima dell'iniezione del pacchetto nell'AP. Quindi, l'AP non rifiuterà mai il pacchetto?

In che modo il nostro AP determina che il pacchetto con il byte capovolto è corrotto?

wifi wep

posta programings 16.11.2014 - 14:46

fonte

1 risposta

Leggi altre domande sui tag wifi wep

È più sicuro usare un modulo HTML invece di un popup javascript? È sicuro usare la crittografia a chiave privata per molti piccoli blocchi di dati?

score 1 · Accepted Answer

Risposta breve

Il punto principale per rispondere alla tua domanda è che abbiamo bisogno di conoscere il bit trito originale per poter ricostruire l'ICV. Solo se conosciamo quel bit originale, possiamo correggere il pacchetto modificato in modo che venga accettato di nuovo.

Risposta più lunga

AFAIK Penso che tu pensi che

Next, he/she "chops-off" the last byte of the message, right before the ICV (which is also encrypted in the packet)

è sbagliato. L'utente malintenzionato non sa dove inizia l'ICV, abbassa l'ultimo byte del messaggio crittografato. Tuttavia, non ne sono completamente sicuro. Non importa per il resto della risposta comunque.

È importante iniziare la risposta con due considerazioni:

È sempre possibile creare un pacchetto corrotto basato su un pacchetto catturato, che sarà accettato dall'AP (e quindi il checksum ICV è corretto)
Il punto dell'attacco di ChopChop non è quello di creare un pacchetto corrotto. Il suo scopo è ricreare il pacchetto in chiaro originale bit per bit.

Non ho intenzione di entrare nei dettagli sul perché (1) sia corretto, per favore leggi una guida matematica per quello. Ora, sfruttiamo le scoperte matematiche del punto (1) per arrivare all'attacco di ChopChop. Immagina il seguente pacchetto (dati + icv):

0101 = data ; 11 = ICV ; full packet = 0101 11

L'attacco chopchop funziona tagliando l'ultimo bit del pacchetto (in modo da ottenere 0101 1). Ovviamente, questo pacchetto non sarà accettato dall'AP, poiché non esiste modo che il checksum ICV sia ancora corretto. Ora la matematica del chopchop mostra che posso modificare questo pacchetto in modo che diventi nuovamente corretto (ad esempio 0101 0). È stato matematicamente provato che abbiamo bisogno del bit di dati originale, tritato per sapere come dobbiamo modificare il pacchetto in modo che possa essere accettato di nuovo.

Quindi abbiamo bisogno di un calcolo che utilizzi il bit del bit di testo semplice come input. Se non conosciamo il bit in chiaro, non saremo in grado di sapere come modificare il pacchetto tagliato in modo che il suo ICV diventi nuovamente corretto.

Pertanto, iniziamo a indovinare il bit tritato, e lo eseguiamo attraverso il calcolo, adattiamo l'ICV e controlliamo se l'AP lo accetta. Se lo fa, sappiamo che abbiamo indovinato il bit tritato. Altrimenti, ne proviamo un altro.

In questa risposta, ho fatto astrazione della crittografia (ho lavorato con pacchetti di testo normale). Tuttavia, a causa della natura della crittografia (associativa e commutativa), ciò non ha importanza per la logica sottostante, che in realtà è dimostrata dal punto (1).