WEP (In)Security

1 - Introduzione

Lo standard IEEE802.11 prevede due implementazioni di WEP:

• classica, con chiave a 40 bit
• estesa, con chiave a 128 bit

Esistono anche versioni proprietarie con chiavi a 256 bit, ma che sono fuori standard.
La versione estesa rende praticamente impossibile ricavare la chiave attraverso attacchi brute-force.

Gli obiettivi del protocollo WEP sono:

• confidenzialità: solamente gli interlocutori devo conoscere il contenuto dei messaggi scambiati;
• autenticazione: la rete deve essere utilizzata solamente da chi è autorizzato a farlo;
• integrità dei dati: i dati scambiati non debbono essere contraffatti.

In tutti e tre i casi la sicurezza risiede nella difficolta di ricerca della chiave attraverso attacchi brute-force.
Vedremo che indipendentemente dal tipo di implementazione WEP utilizzata gli obiettivi di sicurezza prefissati non vengono garantiti.

2 - Debolezza degli stream cipher

Ricordiamo che WEP utilizza l'algoritmo di crittazione di tipo stream cipher: l' RC4. Questo tipo di algoritmi operano tramite l'espansione di una chiave "corta" (in WEP è formata dalla concatenazione dell'IV e della shared key) in un flusso infinito di bit pseudo-random (key stream). Lo XOR tra il key stream e ed il messaggio in chiaro (plaintext), effettuato dal trasmettitore, produce il testo cifrato (ciphertext).
Una ben nota debolezza degli algoritmi stream cipher evidenzia che crittando 2 messaggi diversi con lo stesso key stream, dal conseguente ciphertext si possono ricavare facilmente informazioni riguardanti i due messaggi.

Supponiamo che P1 e P2 siano due messaggi in chiaro (plaintext), e che K sia la chiave (keystream) con cui vengono crittografati i due messaggi, ricordando che:

potremmo dedurre che:

ottenendo così lo XOR del plaintext.
Supponendo di conoscere uno dei due plaintext si potremmo ottenere l'altro con un semplice XOR:

Inoltre supponendo di conoscere un plaintext ed il corrispondente ciphertext si può ottenere la chiave di cifratura:

La conoscenza della chiave K permette di effettuare attacchi statistici per il recupero del testo in chiaro.

3 - Attacco FMS

Fluhrer Mantin e Shamir sono stati i primi a dimostrare la vulnerabilità del KSA (key scheduling algorithm) dell'RC4 utilizzato nell'implementazione WEP. Il loro attacco si basa sull'utilizzo del solo primo byte della sequenza pseudo-random prodotto dall'output generator di RC4. L'equazione associata a questo byte è:

Dopo la fase di setup, questo byte dipende unicamente da 3 valori dell'array di stato:

L'attacco consiste nel ricavare informazioni sulla chiave osservando questo valore.
Utilizzando la terminologia di Fluhrer e altri chiameremo resolved il pacchetto che assume il particolare stato in cui "il suo IV è tra quelli che portano l'algoritmo KSA a rilasciare informazioni sulla chiave"
L'attacco è statistico per sua natura, ogni pacchetto resolved ci dà una probabilità del 5% associata all' ipotesi di chiave corretta ed una probabilità di 95% di ipotesi di chiave errata. L'osservazione di un numero sufficiente di pacchetti "resolved" porta sicuramente alla rivelazione della shared key utilizzata da WEP.

4 - Sfruttare la debolezza degli stream cipher

5 - Dizionario di decrittazione

Abbiamo visto come ottenere la key stream K a partire da un plaintext P1 e dal suo corrispondente ciphertext C1:

Con questa key stream K si può evidentemente decrittare qualsiasi pacchetto che sia stato crittato lo stesso IV.
E' quindi possibile creare una tabella che metta in relazione un pacchetto con il corrispondente IV la quale nel WEP classico richiederà  uno spazio di:

Il vantaggio nell'utilizzo di questo sistema è nella velocità  di decrittazione dei pacchetti, lo svantaggio invece è nel tempo di necessario alla creazione della tabella completa. Questo approccio è risulta sconveniente nel caso di utilizzo di chiavi WEP di lunghezza maggiore di 40 bit

6 - Problemi di CRC

Il protocollo WEP utilizza un campo di controllo di integrità (o checksum) che dovrebbe assicurare che i pacchetti non vengano modificati durante il transito. Il meccanismo checksum CRC (Ciclic Redundant Code) applicato allo stream cipher utilizzato in WEP, garantisce solo l'integrità di pacchetti che siano stati modificati da errori nel canale e non contro attacchi maliziosi. Vediamo come sfruttare questa debolezza.

Mostriamo come un messaggio possa essere modificato in transito senza che questo venga rilevato, utilizziamo la proprietà di linearità dei checksum CRC:

Ora supponiamo che:

• sia C un ciphertext intercettato prima che abbia raggiunto la destinazione;
• sia P il plaintext associato a C;

allora otterremo che :

con <P,c(P)> pari alla concatenazione del plaintext con il suo checksum.
E' possibile trovare un nuovo ciphertext C' associato al plaintext P':

con delta scelto arbitrariamente dal malintenzionato; quindi sfruttando la linearità del CRC:

è possibile ottenere C':

Mostriamo ora come il WEP non fornisca un valido controllo di acesso, per fare questo utilizzamo un'altra proprietà del checksum: il checksum WEP è funzione del messaggio.
Un malintenzionato conoscendo un plaintext P e il corrispondente ciphertext C potrebbe inviare un nuovo messaggio P' da lui generato (injection):

il nuovo pacchetto utilizzerà lo stesso IV dell'originale, ma questo non è un problema poiché, come è stato già detto, lo standard non specifica come debbano essere variati gli IV

7 - Authentication spoofing

Descriviamo brevemente il meccanismo di associazione di una stazione mobile ad un access point:

1. la stazione mobile, all'accensione, invia all'access point una richiesta di autenticazione;
2. l'access point risponderà  con una stringa random di 128 bit inviata in chiaro (challenge);
3. la stazione mobile cifrerà  la stringa con la chiave WEP e la reinvierà all'access point;
4. l'access point verificherà se la stringa ricevuta è stata cifrata con la chiave WEP corretta.

Un malintenzionato sniffando un una sequenza di autenticazione leggittima potrebbe facilmente ricavare una coppia plaintext/ciphertext valida da cui ricavare il corrispondente key stream sufficiente per inviare la risposta corretta al challenge (inviato in chiaro) lanciato dall'access point

8 - Conclusioni

9 - Bibliografia

Nikita Borisov, Ian Goldberg, David Wagner
- Intercepting Mobile Communications: The Insecurity of 802.11 -

Scott Fluhrer, Itsik Mantin, Adi Shamir
- Weaknesses in the Key Scheduling Algorithm of RC4 -

Adam Subblefield, John Ioannidis, Aviel D. Rubin
- Using the Fluhrer, Mantin and Shamir Attack to Break WEP -