(In)sicurezza del WEP

Lo standard IEEE 802.11 descrive il protocollo di comunicazione nelle reti locali wireless. Il WEP (Wired Equivalent Privacy) e' nato nel lontano 1999 allo scopo di proteggere tali reti senza fili che per loro natura sono facilmente accessibili. "Wired Equivalent Privacy" significa letteralemente "Privacy come nelle LAN col filo"... ma e' davvero cosi'?. No, almeno non piu'... sono state scoperte cosi' tante falle di sicurezza nel protocollo WEP che oggigiorno e' quantomento sconsigliato utilizzarlo.
Vediamo perche' il WEP e' tanto insicuro:

Il WEP ricorre ad una chiave segreta condivisa da tutte le stazioni mobili partecipanti alla rete wifi (per stazioni intendiamo portatili, server e altri host) e dall'Access Point (o AP). Nelle utenze domestiche spesso l'AP e' il modem ADSL wifi. La chiave segreta e' utilizzata per cifrare i pacchetti prima della loro trasmissione nell'etere e un campo CRC aggiuntivo e' utilizzato per assicurare che i pacchetti non siano stati modificati durante il loro invio. La chiave segreta di solito viene impostata a mano sull'AP e sugli host della rete e puo' essere da 64,128 o 256 bit.

Per codificare i pacchetti, il WEP si avvale dell'algoritmo di crittografia RC4, un noto cifratore a flusso molto veloce ed efficiente. Un cifratore a flusso non e' altro che un PRNG cioe' un generatore di numeri a caso inizializzato da una specifica chiave segreta: data una chiave il PRNG genera una sequenza virtualmente infinita di bit (il keystream) che viene messa in XOR bit a bit con il testo in chiaro (si usa tanto keystream quanto e' lungo il pacchetto da codificare). Il risultato dello XOR e' il testo cifrato (pacchetto cifrato) che viene quindi inviato.

All'atto pratico il mittente pone in XOR il proprio pacchetto in chiaro M con il keystream K e invia il risultato C.

C = M XOR K

Il ricevente, avendo la stessa chiave di inizializzazione per l'RC4, riproduce il medesimo keystream K, lo pone in XOR con il pacchetto cifrato C e ottiene il pacchetto in chiaro M. Cioe', il ricevente esegue:

C XOR K = M

Ottenendo di nuovo M. infatti:

C XOR K = (M XOR K) XOR K      ,perche' C = M XOR K
M XOR K XOR K = M XOR 0        ,perche' K XOR K = 0 per qualsiasi scelta di K
M XOR 0 = M                          ,perche' M XOR 0 = M per qualsiasi scelta di M

Gli ultimi due passaggi derivano da proprieta' banali dello XOR.
Uno dei dieci comandamenti della crittografia moderna afferma che dato un cifratore a flusso (come ad esempio il nostro RC4) e' assolutamente vietato il riuso del medesimo keystream per cifrare altri messaggi. Perche? perche se ad esempio riutilizziamo sempre il keystream K per codificare due messaggi M1 e M2, allora avremo che i messaggi cifrati sono dati da:

C1 = M1 XOR K

e

C2 = M2 XOR K

dati questi due messaggi cifrati, basta metterli in XOR tra di loro per ottenere lo XOR dei messaggi M1 e M2. Ecco la dimostrazione:

C1 XOR C2 = M1 XOR K XOR M2 XOR K = M1 XOR M2 XOR K XOR K = M1 XOR M2 XOR 0 = M1 XOR M2

sapendo che i pacchetti IP hanno spessissimo header abbastanza prevedibili (ad esempio si sa che i 4 byte corrispondenti all'indirizzo IP di destinazione valgono rispettivamente 192,168,1 e 1, cioe' il classico indirizzo locale dell'AP) e' possibile ricostruire seppur parzialmente i due messaggi M1 e M2. Il keystream K si e' semplicemente annullato con se stesso dato che K XOR K = 0.
Il WEP rimedia a questo problema utilizzando il vettore di inizializzazione (IV): per evitare il riuso di uno stesso keystream l'IV viene appeso in fondo alla chiave segreta condivisa per generare una chiave di inizializzazione per RC4 ogni volta differente. L'IV viene inserito in chiaro nel pacchetto cifrato.
Il fatto e' che l'IV e' un campo di soli 3 byte e cio' significa che possono esserci 2^24 = 16777216 possibili IV. Sembrano molti ma in realta' non sono sufficienti a garantire che uno stesso keystream non verra' mai piu' generato (come dovrebbe essere). Statisticamente infatti, anche scegliendo a caso l'IV per ogni pacchetto e in condizioni di rete non necessariamente a pieno regime, abbiamo che uno stesso IV si ripete ogni circa 3-4 ore. Cio' significa che ogni circa 3-4 ore abbiamo due pacchetti con medesimo IV, cioe' codificati con il medesimo keystream! Possiamo quindi tentare di decodificare i pacchetti basandoci sulle ricorrenze degli header IP.
Ecco lo schema di funzionamento del WEP al lato mittente:

Come si vede in ingresso all'RC4 entra una chiave creata concatenando un IV scelto in qualche modo (a caso, in sequenza o altro) e la master key condivisa da tutti partecipanti della rete. L'RC4 genera un keystream che viene messo in XOR bit a bit con il pacchetto originale inclusivo del suo specifico valore CRC. Il risultato e' un pacchetto cifrato al quale viene affiancato l'IV assolutamente in chiaro, come si vede dalla figura.
Quanto detto si ripete per ogni singolo pacchetto trasmesso.

Altra nota dolente del WEP e' il campo di checksum CRC. Questo campo, come gia' accennato, viene aggiunto dal protocollo WEP per garantire che il pacchetto cifrato non venga manipolato durante il tragitto. Il campo CRC e' cifrato insieme al pacchetto vero e proprio. Il CRC pero' e' generato da un algoritmo di checksum lineare, cio' significa che flippare l'n-esimo bit nel messaggio comporta solo il dover flippare un set deterministico di bit nel campo CRC per produrre un checksum valido del messaggio modificato.
Un attaccante puo' quindi flippare tutti i bit che vuole nel messaggio cifrato e poi aggiustare il campo CRC in maniera tale che appaia valido. Va ricordato che il flipping dei bit puo' essere fatto anche a codifica RC4 avvenuta, in quanto questo cifratore a flusso lavora bit a bit e usa lo XOR che, per sua natura, e' "trasparente" al flipping dei bit.

Attacchi classici

Ecco alcuni degli attacchi classici cui e' soggetto il WEP:

Decodifica passiva
Deriva dalle considerazioni fatte prima in merito al metodo di codifica con l'operatore XOR. Un attaccante rimane in ascolto nella rete fintanto che trova due pacchetti con medesimo IV. A questo punto gli e' sufficiente fare lo XOR dei due pacchetti cifrati per ottenere lo XOR dei pacchetti in chiaro (come visto nella dimostrazione precedente). Dallo XOR dei pacchetti in chiaro si puo' risalire al contenuto di uno dei due (o di entrambi) grazie alla predicibilita' dei pacchetti IP che presentano spesso campi uguali, valori ben precisi in determinate posizioni e cosi' via.
Noto il contenuto di un intero pacchetto si puo' calcolare molto facilmente il keystream con il quale e' stato codificato: infatti, e' sufficiente fare lo XOR del pacchetto cifrato originale con la versione in chiaro.

K = M XOR C

A questo punto qualsiasi altro pacchetto con stesso IV potra' essere decodificato grazie a K (in realta' possono essere recuperati solo i primi N bit del paccheto se K e' lunga N bit)

Active packet injection
Dato che flippare il bit n-esimo del pacchetto cifrato corrisponde a flippare il bit n-esimo della sua versione in chiaro e' possibile manipolare il contenuto di un pacchetto avendo cura ovviamente di modificare opportunamente il campo cifrato CRC flippandone i bit allo stesso modo.

Table-based attack
Lo spazio ridotto dei possibi IV permette di costruire una tabella che mette in corrispondenza gli IV con relativi keystream (keystream recuperati con il primo degli attacchi visti). Con 2^24 possibili IV e con una media di 1024 byte a pacchetto abbiamo 2^24 * 2^10 = 2^(34) = 17179869184 byte, cioe' all'incirca 16 Gb di spazio richiesto per la tabella: una sciochezza al giorno d'oggi. Con questa tabella e' poi possibile decodificare qualsiasi altro pacchetto cifrato transiti nella rete.

WEP key scheduling attack
Come se non bastasse nel 2001 e' stato dimostrato (questo e' l'articolo originale) che l'RC4 presenta delle debolezze quando viene usato con chiavi che sono formate dalla concatenazione di una parte segreta ed una parte pubblica esattamente come avviene nel protocollo WEP (master key e IV). In pratica, e' sufficiente collezionare un insieme di IV dell'ordine dei 10^5 elementi per risalire alla chiave WEP (la master key). Acquisire 10^5 IV non e' un problema dato che la rete e' wireless e ogni pacchetto cifrato in transito include un IV in chiaro; potrebbe richiedere poco o molto tempo, dipende dal carico della rete anche se esistono particolari tecniche che forzano l'AP o gli altri client ad inviare pacchetti nella rete e quindi i relativi IV.

Dobbiamo pero' sfatare un mito che gira ormai da troppo tempo: la causa dei problemi di sicurezza del WEP non e' data dall'agoritmo RC4 di per se ma da come questo e' stato utilizzato ed inserito nel protocollo: l'RC4, se usato correttamente, si e' sempre dimostrato estremamente robusto, tant'e' che viene utilizzato nelle cipher-suite SSL senza alcun problema.
Purtroppo ancora oggi molti router e modem ADSL integrano il protocollo WEP e, sebbene spesso se ne possano attivare anche altri (come WPA e WPA2), viene scelto forse per la sua semplicita' di configurazione (una password e basta) o forse perche' di solito e' la prima voce nella lista dei vari protocolli!
Fatto e' che una rete "protetta" da WEP e' in realta' assolutamente insicura e apre la strada a tutta una serie di attacchi (eavesdropping in primis) esattamente come una rete in chiaro.

Link di riferimento:
http://en.wikipedia.org/wiki/Wired_Equivalent_Privacy
http://www.drizzle.com/~aboba/IEEE/rc4_ksaproc.pdf
http://www.isaac.cs.berkeley.edu/isaac/wep-slides.pdf
http://www.research.ibm.com/acm_sigmobile_conf_2001/
http://www.cs.umd.edu/%7Ewaa/wireless.html
http://www.cypherpunks.ca/bh2001/