Sicurezza nelle reti LAN, cablate e wireless

Per la sicurezza nelle reti LAN, ci concentriamo sul livello II dello stack TCP/IP, cioè il livello data-link: questo è soltanto una minima parte di quella che dovrebbe essere la trattazione della sicurezza a livello di reti LAN, che dovrebbe spaziare anche nei livelli del sistema operativo e della sicurezza fisica.

Gli scopi che ci prefiggiamo sono quelli di capire come si può fare autenticazione degli utenti a livello data-link, cioè quando ancora non è stato assegnato un indirizzo IP alle macchine che si attestano nella rete; vogliamo inoltre riuscire ad offrire la confidenzialità per tutti, sempre a livello II.

Gli strumenti che analizzeremo sono

• i nodi che rispondono allo standard IEEE 802, hanno lo scopo di proteggere crittograficamente le connessioni e soprattutto di eseguire il port access control, cioè autorizzare o meno un calcolatore ad usare una spina ethernet (o un canale radio wireless) senza dover proteggere fisicamente la spina o l'area coperta dal wireless;
• i protocolli di autenticazione e di autorizzazione, hanno lo scopo di permettere l'identificazione di calcolatori ed utenti e calcolare le chiavi effimere necessarie per le comunicazioni;
• i server di autenticazione, delle macchine che hanno un accesso sicuro al database degli utenti e che decidono come e quando autorizzare ogni singolo utente, secondo delle policy arbitrarie.

I protocolli di autenticazione devono risolvere alcuni problemi fondamentali:

• come trasportare dei dati nella rete, prima che i terminali siano autenticati ed autorizzati;
• come gestire la mobilità degli utenti, che possono spostarsi durante la connessione;
• prevedere la possibilità di usare protocolli diversi per scopi diversi.

Bisognerà anche capire quali tipi di credenziali possono e devono essere usati, per permettere alla rete di autenticarsi e permetterle di riconoscere gli utenti.

Accesso alle risorse della rete

Abbiamo un apparecchio della rete, un router oppure un access point wireless, che deve permettere agli utenti di scambiare dati soltanto se autenticati.

File:Sicurezza port access control generico.png

L'idea ad alto livello è di prevedere che le informazioni avranno due proprietà diverse e due canali diversi: nel caso che queste informazioni vengano da apparecchi autenticati, allora il nodo della rete dovrà comportarsi normalmente, instradando i pacchetti nella rete; al contrario, se i dati provengono da terminali non autenticati, allora questi dovranno essere deviati verso un percorso prestabilito, con destinazione un server di autenticazione specifico.

Standard IEEE 802.1x

Gli standard della famiglia IEEE 802.1x definiscono la nomenclatura necessaria per distinguere i vari apparecchi nella rete:

• supplicant, è il terminale;
• authenticator, è un nodo stupido dell'infrastruttura della rete, come può essere uno switch ethernet, un access point, un router, eccetera; questo tipo di apparecchiature fungono da relay, cioè non partecipano attivamente all'autenticazione;
• port, può essere la porta fisica di uno switch 802.3, oppure una porta virtuale, come nel caso degli access point;
• authentication server AS, è il server di autenticazione, l'entità con cui il supplicant negozia l'autenticazione; è compito dell'AS dire all'authenticator se accettare o rifiutare i dati del supplicant.

Extensible Authentication Protocol

Il protocollo EAP risponde all'esigenza di trasportare dei dati all'interno della rete, prima ancora che il terminale da autenticare abbia un indirizzo IP. Questo protocollo è nato per supportare il protocollo PPP, standardizzato dalla RFC 3748, può essere associato a più di un protocollo di autenticazione, creando i cosiddetti metodi EAP, indicati come EAP-MD5, EAP-AKA, EAP-SIM, EAP-TLS, ...

Il protocollo EAP supporta la negoziazione dinamica del metodo, quindi lo stesso server di autenticazione può proporre l'autenticazione con protocolli diversi, a seconda delle preferenze del terminale o a seconda del tipo di utente che si vuole autenticare.

Nel collegamento tra il supplicant e l'authenticator, EAP è trasportato all'interno di un livello data-link, quindi si posiziona a livello II dello stack protocollare; nel percorso tra l'authenticator e l'authentication server, invece, EAP viene incapsulato in pacchetti di livello V, cioè di livello applicativo.

Schema di principio dell'uso di EAP su rete locale o wireless

Esempio di stack EAP su RADIUS

EAP over LAN

Il metodo EAPOL prevede cinque tipi di pacchetto:

1. EAPOL Start, quando il supplicant o l'authenticator richiedono l'autenticazione;
2. EAPOL Logoff, quando il supplicant vuole chiudere la connessione;
3. EAPOL Success, quando l'autenticazione va a buon fine;
4. EAPOL Failure, usato per indicare il fallimento dell'autenticazione;
5. EAPOL Key, usato per trasportare le chiavi effimere.

File:Sicurezza EAPOL teoria.png

Quello che bisogna notare è che l'authenticator è un componente passivo nell'autenticazione, non ha bisogno di conoscere né nemmeno sapere quale tipo di metodo viene usato per l'autenticazione, si tratta di una scelta che riguarda soltanto il supplicant ed il server di autenticazione.

File:Sicurezza EAPOL esempio pratico.png

Authentication, Authorization and Accounting

L'authenticator ed il server di autenticazione possono trovarsi in zone geografiche del mondo completamente diverse, e possono essere collegate tra loro da una normale connessione ad internet. Per questo motivo, il protocollo EAP prevede di essere spedito a livello applicativo, tra authenticator e AS. Di conseguenza, sotto ad EAP deve esserci uno stack protocollare TCP/IP (o alternativi).

Il protocollo AAA definisce le modalità di comunicazione tra authenticator e AS; nello specifico, l'authenticator assume il nome di Netword Access Server NAS, e può essere uno switch 802.3, un RNC UMTS, un server PPP, ...

Un server AAA, invece, è un server che ha accesso al database degli utenti e si occupa di definire le politiche di accesso, i permessi dei vari utenti, e i pagamenti che questi utenti dovranno fare, per il servizio che stanno utilizzando. Tipicamente, un AAA server ed un AS sono lo stesso oggetto.

File:Sicurezza AAA teoria.png

Remote Authentication Dial-In User Service

Il protocollo RADIUS è definito dalla RFC 2865 ed è un protocollo di tipo client/server dove il client è il NAS, l'authenticator, mentre il server è un server AAA.

RADIUS è un protocollo di livello applicativo che si poggia su UDP nello stack TCP/IP, ed è in grado di trasportare i dati di autenticazione per tutti i più comuni protocolli di autenticazione, come PAP, CHAP, EAP, ...

Oltre all'autenticazione, RADIUS è in grado di trasportare anche i dati di autorizzazione e, se implementato secondo la RFC 2866, anche i dati di accounting. Quando fu standardizzato, RADIUS fu pensato con una serie di parametri liberi, gli attributi, che permettessero di estenderne le funzionalità.

Esempio: RADIUS con PAP

Ammettiamo che si voglia fare autenticazione di tipo PAP: quello che accade è che Alice manda al client RADIUS il suo nome utente e la sua password: qui la password viene cifrata con una pre-shared key condivisa tra client e server RADIUS, e trasmessa al server RADIUS che la decifra e la trasforma secondo le modalità del PAP. Lo username e la password cifrata vengono trattati come degli attributi del protocollo RADIUS.

File:Sicurezza RADIUS PAP.png

È importante notare che, in questo caso, l'autorizzazione viene data prima dell'autenticazione.

Esempio: RADIUS con CHAP

Nel caso in cui si decida di usare CHAP, tocca all'authenticator scegliere la challenge che dovrà essere firmata da Alice; quando la firma sarà giunta all'authenticator, questo manderà il nome utente, la challenge e la firma al server RADIUS, in modo tale che lui possa verificare il correttezza dei dati.

È da notare che il server RADIUS, come ogni server AAA, non ha alcun bisogno di avere il database degli utenti presente in locale: questo può essere memorizzato in qualunque parte del mondo, ed i dati possono essere comunicati al server AAA tramite un canale IP, sperabilmente cifrato.

Anche RADIUS soffre di alcuni problemi di sicurezza:

• per poter comunicare, client e server RADIUS condividono una pre-shared key PSK;
• molti dei parametri di autenticazione, come i nomi utenti e le challenge, sono trasportati in chiaro, quindi chiunque nel percorso tra l'authenticator e il server AS ha la possibilità di intercettarli e leggerli;
• i meccanismi crittografici usati da RADIUS sono poco sicuri, quindi è sempre meglio usare RADIUS proteggendolo prima con IPSec o TLS.

L'architettura di un sistema RADIUS può essere gerarchica, quindi possono esistere, oltre a client e server RADIUS, anche dei proxy RADIUS.

Esiste un'evoluzione di RADIUS, chiamata DIAMETER, ma non è molto usata, ad oggi.

RADIUS con EAP

La RFC 3579 specifica come deve essere trasportato il protocollo EAP all'interno di RADIUS. Grazie a questa combinazione, qualsiasi metodo EAP può essere trasportato all'interno di RADIUS.

Il protocollo EAP viene trasmesso, tra supplicant ed authenticator, a livello data-link nello stack protocollare TCP/IP; quando questi pacchetti EAP arrivano all'authenticator, però, devono essere trasmessi: qui entra in gioco RADIUS, che fa da contenitore per i pacchetti EAP tra authenticator e server RADIUS, il server di autenticazione.

Esempio: RADIUS con EAP-MD5

Come prevede lo standard, qualsiasi implementazione di EAP deve prevedere, come minimo, un'autenticazione col metodo EAP-MD5. Con questo metodo, l'AS decide una challenge che viene trasmessa al supplicant, il quale calcola un hash

$MD5(password|challenge)$

che viene rispedito al server di autenticazione.

File:Sicurezza EAP-MD5 traliccio.png

Bisogna evitare di usare questo metodo, perché è insicuro (usa MD5) e perché l'autenticazione non è mutua.

Esempio: RADIUS con EAP-PAP e TLS

L'idea è di usare un protocollo di autenticazione, per definizione insicuro, proteggendolo con un tunnel TLS.

File:Sicurezza EAP-PAP con TLS traliccio.png

Quello che accade è che viene aperta una sessione TLS tra il server RADIUS ed il supplicant, in maniera tale che nemmeno l'access point abbia la possibilità di vedere la password in chiaro. All'interno di questo tunnel TLS, viene instaurata una connessione col metodo EAP-PAP, e viene derivata sia dal supplicant che dall'AS una chiave PMK; quando il server di autenticazione informa l'authenticator dell'autenticazione avvenuta, gli comunica anche la PMK con cui cifrare i dati.

Questo approccio ha un difetto: è computazionalmente importante, genera molto traffico e non garantisce PFS, dal momento che la chiave PMK viene trasmessa attraverso internet. Nonostante questo, il meccanismo EAP-PAP su tunnel TLS è in assoluto il più usato nelle reti moderne.

Architettura 802.11

Lo standard IEEE 802.11 definisce un'architettura per reti IP wireless. Terminologia:

• Access Point, AP, è il punto di accesso per la rete wireless, il terminale che trasforma il segnale radio (IEEE 802.11) in segnale cablato (IEEE 802.3) e viceversa;
• client, l'apparecchio che si collega all'access point per poter comunicare con la rete.

Ci sono due tipi di funzionamento:

• modalità ad infrastruttura, in cui ci sono degli access point e dei client;
• modalità ad-hoc, in cui tutti i terminali comunicano tra loro, ma senza che vi sia un AP.

Per potersi collegare ad un AP, i client devono compiere quattro passaggi:

1. scansione dei canali, alla ricerca di access point che annunciano una rete;
2. autenticazione all'AP o tramite l'AP verso un server di autenticazione;
3. associazione;
4. eventualmente, DHCP per impostare i parametri della rete.

La ricerca delle reti può essere fatta in due modalità:

• passiva, cioè il client ascolta la rete ed aspetta che l'AP invii un annuncio con il nome e le caratteristiche della rete che serve;
• attiva, il client conosce in nome della rete a cui si vuole collegare e la comunica: se un access point serve una rete con quel nome (SSID), allora risponderà alla chiamata.

La modalità di funzionamento più stupida, per una rete, è quella che non prevede alcuna protezione; in questo caso, un calcolatore può comunicare con l'AP senza alcun problema, rileva l'SSID dall'annuncio fatto dall'AP, ottiene l'indirizzo necessario per comunicare ed è a posto. Con questa modalità di funzionamento, tutto il traffico generato viene trasmesso in chiaro e senza alcuna protezione, basta un attacco passivo per registrate tutto, in chiaro.

Meccanismi di protezione non crittografici

Gli AP possono non annunciare l'SSID della rete; quando questo accade, è necessario che il calcolatore usi la modalità di funzionamento attiva per collegarsi alla rete: questa è una possibile misura di sicurezza per prevenire il tentativo di accesso non autorizzato,

non sai che qui c'è una rete, non sai il nome di questa rete, quindi non puoi cercare di collegarti

Questo metodo, benché funzionante, è poco sicuro: durante l'associazione, infatti, il client deve trasmettere il nome SSID della rete in chiaro, quindi Trudy, in ascolto passivo, può intercettare il pacchetto, leggere il nome della rete e tentare di autenticarsi a sua volta. Quando gli access point adottano questa politica di sicurezza, si dice che stanno lavorando in closed mode: questa è un esempio di politica di sicurezza senza crittografia.

Un access point può accettare le connessioni in base a diversi parametri; uno di questi può essere la lista dei MAC, la MAC Address Control List: l'AP ha, nella sua memoria, la lista di tutti e soli i MAC dei calcolatori per cui accettare la connessione. Questa modalità sarebbe sicura se si fosse di fronte ad una connessione punto-punto cablata, ma nel caso del wireless è effettivamente poco utile: basta infatti che Trudy si metta in ascolto sulla rete e trovi uno o più indirizzi MAC accettati dall'AP (lo vede perché generano traffico con successo); a questo punto, Trudy può fare address spoofing immettendo nella rete dei pacchetti con MAC diverso, e mettendo il calcolatore in ascolto per quello stesso MAC: il risultato è che, quando il calcolatore che ha davvero quel MAC non è in funzione o non è presente, Trudy sarà in grado di bypassare la protezione MAC-ACL.

Meccanismi di protezione crittografici

Di meccanismi di protezione crittografici, standardizzati per le reti wireless, ce ne sono più di uno. Il primo standard è stato il Wired Equivalent Privacy, WEP, che prevede l'utilizzo di una pre-shared key, una chiave crittografica condivisa tra l'AP e tutti i client della rete. Questo approccio è stato poco fortunato, perché

• la chiave $K$ è condivisa tra tutti gli utenti della rete, non c'è riservatezza;
• la chiave $K$ è usata sia per l'autenticazione che come chiave di cifratura dei dati.

Uno standard più fortunato, quello ad oggi più usato, è il Wireless Protected Access, WPA, definito all'interno dello standard IEEE.802.11i.

Wired Equivalent Privacy

Il protocollo WEP è stato in assoluto il primo standard di crittografia per reti wireless IEEE 802.11. Gli scopi di questo standard sono autenticazione, confidenzialità e protezione d'integrità dei dati.

L'autenticazione, con il WEP, è da intendere nel senso

questo è il mio ufficio, quindi se collego una spina al muro certo che sono io

Seguendo questo ragionamento, la scelta del tipo di credenziali per l'autenticazione fu una pre-shared key $K$, una chiave condivisa dall'AP e da tutti i calcolatori all'interno della WLAN; in questo modo, la sicurezza fu intesa come

all'interno del gruppo, abbiamo fiducia

Il problema è che la stessa chiave deve essere condivisa con un gran numero di utenti, spesso che si aggregano o che se ne vanno dinamicamente, come può essere il caso di un'azienda che licenzia ed assume dipendenti.

Le scelte, per lo standard, furono poco felici:

• una chiave condivisa $K$;
• un protocollo di autenticazione molto semplice, del tipo challenge-response;
• un solo protocollo crittografico previsto, l'RC4, che col tempo è stato completamente violato;
• per l'integrità dei dati, una funzione non crittografica, quale è CRC-32.

Protocollo di autenticazione

L'autenticazione, nello standard WEP, è solo del client nei confronti della rete; quello che viene fatto, da parte del client, è cifrare una challenge con l'algoritmo RC4 e con la pre-shared key $K$. Questo metodo fa sì che l'autenticazione, che non è mutua, esponga anche la chiave di cifratura ad attacchi mirati.

File:Sicurezza WEP protocollo autenticazione.png

L'algoritmo con cui è implementato il protocollo di autenticazione non è di per sé insicuro, anzi; il problema è che, nello standard, questo algoritmo viene usato in una maniera impropria, esponendo la chiave (e quindi tutta la rete) in maniera tale da permettere di ricavare le credenziali per il login in circa un minuto.

Cifratura con RC4 nello standard WEP

Osserviamo lo schema di cifratura:

Abbiamo un Initialization Vector e la chiave $K$ che vengono passati ad una funzione che li concatena tra loro; il risultato di questa concatenazione è usato come seme per generare un keystream, un flusso di chiave da mettere in XOR con un altro flusso; il secondo flusso è generato dalla concatenazione del messaggio in chiaro con il suo Integrity Check Value ICV, cioè l'output dell'algoritmo CRC che serve per garantire l'integrità dei dati.

Lo XOR di questi due flussi è il testo cifrato che, prima di essere spedito, viene concatenato al vettore di inizializzazione, mentre in coda viene inserito il vettore d'integrità.

La chiave $K$ è una chiave condivisa tra tutti gli AP e tutti i computer che si devono collegare alla rete. Questa chiave può essere lunga o 40 bit, oppure 104 bit; in generale, la chiave dovrebbe essere un numero casuale ma, visto che non è facile ricordarla, molto spesso viene usata una password.

Il vettore di inizializzazione è lungo 24 bit, e serve per inizializzare la funzione di cifratura che, come tutte le funzioni di cifratura a flusso, presenta un problema di correlazione tra la chiave ed il testo cifrato: con l'IV si elimina questo problema.

Il valore di controllo ICV è un numero di 32 bit, ottenuto da un'elaborazione lineare, non crittografica, del testo in chiaro.

Problemi del WEP

Il problema principale con il protocollo WEP è che la chiave è condivisa. Questo porta il sistema a non essere scalabile e ad esporre tutti gli utenti alla stessa maniera: violare l'autenticazione di una persona significa istantaneamente violare la sicurezza di tutte le persone che usano quella chiave.

La scelta di usare un algoritmo di cifratura a flusso è coerente col fatto che si vuole risparmiare potenza computazionale, dal momento che stiamo parlando di sistemi wireless, quindi spesso a batteria; il problema sta nel fatto che serve un vettore di inizializzazione diverso per ogni stream di dati, ma questo non accade, perché il vettore è troppo corto, lo spazio dei vettori è troppo ristretto: con soli 24 bit per il vettore di inizializzazione, si va incontro a collisioni certe.

Esempio: Attacco al protocollo WEP sfruttando la collisione dei vettori di inizializzazione

Abbiamo visto che il sistema di cifratura prevede uno XOR tra un keystream ed il testo cifrato; il keystream dipende soltanto dal vettore di inizializzazione IV e dalla chiave.

Chiamiamo $m_{i}$ i messaggi, $c_{i}$ i messaggi cifrati e $k_{i}$ i keystream. Un testo cifrato è dato dall'equazione

$c_{1}=m_{1}\otimes k_{1}$

Ora, ipotizzando una collisione tra vettori di inizializzazione, avremo

$c_{2}=m_{2}\otimes k_{1}$

cioè, i due messaggi cifrati sono la versione in XOR di due keystream uguali con due testi diversi.

Si ha

${\begin{aligned}c_{1}\otimes c_{2}&=m_{1}\otimes k_{1}\otimes m_{2}\otimes k_{1}\\&=m_{1}\otimes m_{2}\otimes (k_{1}\otimes k_{1})\\&=m_{1}\otimes m_{2}\end{aligned}}$

cioè, semplicemente mettendo in XOR due messaggi cifrati, abbiamo ottenuto lo XOR dei due testi in chiaro, un risultato completamente indipendente dalla chiave utilizzata e dal vettore utilizzato. Non male. Questo XOR di messaggi è, ovviamente, tutto fuorché una sequenza pseudorandomica e scorrelata dai testi originali, anzi, risulta essere correlata in maniera molto stretta con il testo.

Qual è la probabilità che vi sia una collisione? abbiamo 24 bit, da cui si possono ottenere

$|K|=2^{24}=16,777216\times 10^{6}$

cioè, circa 16 milioni di possibili vettori. A causa del paradosso del compleanno, però, si ha il 50% di collisioni con $2^{12}$ (circa 4000) vettori di inizializzazione. Ciò significa che, con probabilità 50%, ogni 4000 pacchetti due saranno cifrati con lo stesso keystream. Indicativamente, con un AP abbastanza impegnato, questo evento si verifica ogni minuto o due. Potremmo adottare come soluzione quella di usare IV in maniera sequenziale, ma il risultato è che, comunque, si ha collisione ogni 16M pacchetti; con una MTU massima di 1500 byte (circa 1,4 kB), si ha al massimo

$2^{24}\times 1500\times 8=2,01326592\times 10^{11}$ bit

di trasmissione massima teorica possibile a livello, tradotto in una grandezza umana sono circa 23 GB di dati (a livello 2) massimi teorici scambiati, sfruttando al massimo ogni singolo pacchetto, cosa che non accade mai.

Ma ancora, nonostante questo, il problema peggiore del protocollo WEP è la chiave condivisa, perché una volta che questa è compromessa (e l'attaccante potrebbe essere interno alla rete), tutta la riservatezza di tutte le persone è irrimediabilmente compromessa a costo zero, e la possibilità di scoprire l'attaccante è anch'essa nulla.

Il fatto stesso che la chiave sia usata sia per l'autenticazione che per la cifratura dei dati è un errore ancora peggiore, perché il fatto che uno dei due protocolli, per esempio quello di autenticazione, venga rotto significa automaticamente che anche l'altro, la confidenzialità, sia violato.

Il problema principale è che il WEP è nato quando ancora gli Stati Uniti d'America parificavano gli algoritmi di cifratura alle armi da guerra, ne era vietata l'esportazione a meno di determinate condizioni (come una chiave corta, di soli 40 bit).

Un attacco con testo noto è particolarmente pericoloso per la sicurezza del WEP, perché permette all'attaccante di costruire un vocabolario di valori $(c_{i},m_{i},IV)\Rightarrow (IV,K)$ particolarmente utile. Questo problema è amplificato dal fatto che una chiave di cifratura $K$ è una credenziale di lungo termine, quindi usata più e più volte.

Un attacco a testo noto è semplice da fare; si può mandare una mail ad una vittima, si possono sfruttare i campi noti dei pacchetti TCP/IP, si possono studiare i flussi $m_{1}\otimes m_{2}$, oppure si può impostare un access point esca, con il quale far cifrare ai terminali delle challenge scelte.

Un altro difetto, sempre del protocollo di autenticazione, è che non vi è alcun controllo sui vettori IV: di conseguenza, un calcolatore può fare replay attack di successo semplicemente immettendo pacchetti preregistrati nella rete, perché i vettori IV vengono scelti dal mittente dei messaggi e, in questo caso, dal client.

Un errore di progetto molto grosso, comunque, è stato prevedere l'autenticazione dei client ma non della rete, perché appunto espone l'infrastruttura ad attacchi con challenge apposite, scelte in modo da massimizzare l'esposizione della chiave di cifratura $K$.

Anche la scelta di usare una funzione lineare per verificare l'integrità dei dati è stato un errore di non poco conto; una funzione è lineare quando vale

$f(a)\oplus f(b)=f(a\oplus b)$

Esempio: Attacco alla funzione d'integrità CRC-32

Supponiamo di avere un client autenticato ed autorizzato a lavorare all'interno della rete. Questo sceglie un vettore IV ed un keystream

$K_{S}=RC4(K,IV)$

Abbiamo un vettore di controllo

$ICV=K_{S}\oplus (M|ICV)$

quindi il client manda il pacchetto $[IV,C,ICV]$ all'access point.

Un attaccante sceglie un messaggio $X$ e calcola

$ICV'=ICV\oplus CRC-32(X)=CRC-32(M\oplus X)$

Il testo cifrato sarà

$C'=C\oplus (X|CRC-32(X))$

quindi, Trudy manderà il pacchetto $[IV,C',ICV']$ all'access point.

L'AP riceve i due pacchetti. Si ha

$M'=C'\otimes K_{S})K_{S}\otimes (M|ICV)\otimes (X|CRC-32(X))\otimes K_{S}=(M\otimes X)|ICV'$

Dato questo risultato, l'access point considererà il messaggio $X\otimes M$ un messaggio valido, anche se in realtà non è stato mandato da un client legittimo: scegliendo un $X$ apposito, siamo in grado di immettere un arbitrario messaggio $M'=M\otimes X$ all'interno della rete.

Questi conti dimostrano che è sempre meglio non usare funzioni lineari per fare protezione d'integrità, ci sono le funzioni MDC che fanno questo lavoro garantendo maggiore sicurezza.

Un'ultima considerazione riguarda i vettori di inizializzazione, che non sono tutti uguali: esistono alcuni vettori IV che generano dei keystream particolarmente correlati alla chiave $K$; nel caso in cui uno di questi vettori sia usato assieme ad un messaggio con testo noto, sarà semplice ricavare il keystream e, da lì, ricavare la chiave corretta.

Concludendo, registrando all'incirca un milione di pacchetti cifrati col protocollo WEP e riuscendo a metterli in relazione con il loro testo in chiaro (il che significa costruire il database di tuple $[IV,C,M]$), si ha circa il 90% di probabilità di giungere alla chiave corretta. Esistono software come AirSnort e WEPCrack che fanno questo lavoro per noi, in automatico.

Esiste un'implementazione del protocollo WEP chiamata WEP+, ma tutto quello che fa è evitare di usare i vettori di inizializzazione più pericolosi per la chiave.

Il WEP non offre più alcuna protezione, sia con la chiave da 40 bit che con la chiave da 104 bit; il suo effetto, però, è di dare una falsa sensazione di sicurezza che può risultare ancor peggiore della consapevolezza di non essere al sicuro. Quello che ci si deve domandare, di fronte all'esigenza di usare un sistema aperto oppure un sistema cifrato con WEP, è se sia effettivamente meglio dare una sensazione di falsa sicurezza agli utenti o se renderli coscienti del fatto che, all'interno della rete, manca la sicurezza.

Tutti questi problemi potevano essere evitati, se chi ha progettato il sistema fosse stato un esperto di sicurezza.

Wireless Protected Access

Il WPA è il nuovo standard di protezione delle reti wireless, adottato dopo il WEP. Nello standard IEEE 802.11i sono stati introdotti dei sistemi con EAP che permettono lo scambio di chiavi effimere per la protezione dei dati, fatto che rende tutto il protocollo molto più sicuro del WEP.

Una prima scelta di mercato significativa è stata quella di usare come algoritmo di cifratura AES e non più RC4: in questa maniera, tutto l'hardware WEP non può essere compatibile con il nuovo standard, e quindi non può più essere usato. Per venire incontro a questo problema, è stata progettata anche una modalità WPA retrocompatibile con l'hardware del WEP, con RC4 come algoritmo di cifratura e con una nuova funzione di MAC. Come nomenclatura commerciale, abbiamo WPA che indica i dispositivi che garantiscono retrocompatibilità con WEP, e WPA2 per indicare i dispositivi con AES.

Autenticazione

L'autenticazione in WPA può essere fatta con due modalità:

• con una pre-shared key PSK, ha il nome commerciale di WPA personal;
• con EAP+802.1X, con il nome commerciale di WPA enterprise.

Studiamo il protocollo di autenticazione di WPA enterprise.

File:Sicurezza WPA enterprise autenticazione.png

Il primo passaggio è quello di richiedere l'associazione; questa richiesta può essere fatta indistintamente dall'AP oppure dal client. Per iniziare l'autenticazione, il client manda un messaggio di richiesta all'AP, il quale risponde con una ricevuta ed inoltra la richiesta al server di autenticazione. A questo fatto segue uno scambio di messaggi tra l'AS ed il client, sfruttando EAP, che permette di derivare la Pairwise Master Secret PMS, una chiave di lungo periodo (per la sessione) che sarà usata per derivare tutte le altre chiavi effimere necessarie. A questo punto, l'AS invia la chiave all'access point, il quale avverte il client dell'avvenuta connessione.

Nel caso di protocollo WPA personal, la PMS coincide con la pre-shared key PSK: in questo modo, si evita la procedura dell'EAP, visto che non tutti possono permettersi un server di autenticazione casalingo.

Una volta che si ha la chiave PMS, tra access point e client possono essere derivate le chiavi temporanee PTK da usare per cifrare i dati.

File:Sicurezza WPA calcolo chiavi temporanee.png

Il client e l'AP derivano una nonce a testa, con le quali creare la chiave temporanea:

$PTK=PRF(PMK,nonce_{AP},nonce_{client})$

dove la funzione è un HMAC-SHA1, usata per generare i bit pseudocasuali della chiave temporanea. I Message Integrity Code MIC sono dei MAC che hanno lo scopo di garantire la protezione dell'integrità dei dati; inoltre, permettono l'autenticazione mutua dell'AP e del client.

Oltre a queste chiavi, esiste anche la chiave Group Temporary Key, GTK, una chiave effimera condivisa usata per cifrare i messaggi in broadcast ed in multicast; la GTK è generata dall'AP a partire da una GMK, una chiave master di gruppo, che è condivisa tra tutti i client associati ad un certo AP: la comunicazione avviene dopo lo scambio delle chiavi unicast, e viene trasmessa cifrata e protetta dagli errori usando le chiavi di EAPoL-MIC e EAPoL-ENC.

Cifratura

Nel WPA, per la cifratura, si usa il protocollo Temporal Key Integrity Protocol, TKIP, che genera una per-packet key, una chiave da dare all'algoritmo RC4 per generare il keystream da usare per la cifratura.

Si hanno:

• una chiave temporanea base key di 128 bit;
• un Transmitter Address TA, un numero di 48 bit che serve per differenziare lo stream di dati in uplink dallo stream di dati in downlink nella connessione AP-Client;
• un Initialization Vector IV di 48 bit (il doppio che nel WEP), spedito in chiaro all'interno di ogni pacchetto.

File:Sicurezza WPA TKIP creazione keystream.png

Questi tre ingredienti vengono dati in pasto ad un algoritmo che genera un array di 80 bit; questo array, assieme al vettore di inizializzazione, viene inserito in un secondo algoritmo che genera la per-packet key, una chiave diversa per ogni pacchetto, da usare per alimentare il generatore di keystream RC4. Il problema dell'IV con l'RC4 viene aggirato, perché RC4 non riceve direttamente l'IV.

Queste chiavi per-packet key possono essere calcolate anche in anticipo, in modo da non doverle calcolare dopo, durante la trasmissione.

Per evitare collisioni, lo spazio dei vettori di inizializzazione è passato dai 24 bit del WEP ai 48 bit del WPA, quindi possono essere calcolati all'incirca $10^{15}$ diversi vettori. Questi vettori, inoltre, sono usati in sequenza, quindi il ricevitore può facilmente controllare se è di fronte ad un replay attack. Quando una nuova base key viene derivata, il contatore va a zero.

File:Sicurezza WPA pacchetto trasmesso.png

Protezione dell'integrità

Il TKIP viene anche usato per il suo scopo naturale, cioè per verificare l'integrità dei dati. L'algoritmo MAC usato è chiamato Michael, è un algoritmo pensato appositamente per massimizzare la sicurezza, accettando di usare hardware pensato per il WEP; l'algoritmo Michael prevede l'utilizzo di 3/4 cicli di clock per byte su un processore ARM, 5/6 cicli di clock per byte su un processore i486.

Questo algoritmo non è del tutto sicuro, per questo sono state imposti dei forti limiti al metodo con cui può essere utilizzato: sia il client che l'AP devono tenere conto dei pacchetti spediti, e negoziare nuovamente la base key ogni volta che viene superato un certo limite.

Il campo MIC è il risultato della funzione Michael, mentre il campo ICV è lo stesso del WEP, fu mantenuto come protezione contro gli errori di trasmissione.

WPA2

Nel WPA2, il protocollo TKIP lascia il posto di Counter-Mode/CBC-Mac Protocol, CCMP, un protocollo di cifratura basato sull'algoritmo AES-128, che usa chiavi di 128 bit e cifra a blocchi di 128 bit.

Per l'integrità dei dati, viene usato AES in modalità CBC-MAC, mentre viene usato in modalità CTR per cifrare i dati.

File:Sicurezza WEP WPA WPA2 confronto.png

Problemi del WPA

• credenziali

Il primo grande problema del WPA sono le credenziali con cui fare autenticazione. Nel caso di Wide Area Network, si tende ad usare una tipologia di credenziale unificata, senza permettere all'utente finale di scegliere cosa preferisce: una PSK su una SIM è la scelta più usata.

Nel campo delle reti LAN wireless, invece, abbiamo un gran numero di reti eterogenee, dove di solito tutto quello che hanno gli utenti sono delle credenziali di login (username e password, oppure certificati digitali X.509); per questo tipo di reti, diventa centrale il problema della gestione delle credenziali.

• mobilità

Un problema di importanza crescente è quello della mobilità degli apparecchi wireless. Oramai, anche i cellulari hanno interfaccia WiFi e, siccome sono estremamente mobili, esiste il problema di come migrare i dati necessari per il servizio, da un AP all'altro.

Per risolvere questo problema esiste il protocollo Inter Access Point Protocol, IAPP, ma è troppo complesso e, allo stato delle cose, praticamente inutilizzato: l'unica via percorsa, al momento, è la rinegoziazione di tutti i parametri, il che significa che quando ci si sposta da un AP all'altro, la connessione viene meno.

• potenza dei terminali

I terminali che si affacciano al WiFi sono diversi, e sempre meno potenti: si è passati in poco tempo dai calcolatori, ai telefoni cellulari, e anche agli orologi. Questo significa che la potenza di calcolo è davvero molto variegata, quindi anche i sistemi di sicurezza dovrebbero essere scalabili, in modo tale da garantire sempre il miglior rapporto costo/beneficio; il problema è che la sicurezza non dovrebbe scendere...

• autenticazione del percorso

Come abbiamo visto, il meccanismo dell'autenticazione prevede anche la possibilità di fornire connessioni WiFi a pagamento; questo significa che, in uno stesso luogo, possono coesistere diverse reti che si differenziano per costo, velocità di connessione, affidabilità, ... come distinguerle?

La necessità che nasce è quella di autenticare tutto il percorso che porta dall'AP all'AS, in modo tale che il nostro traffico non transiti all'interno di reti sgradite. Ad oggi, non esiste un protocollo che offra l'autenticazione di tutto il percorso, ma solo del server di autenticazione e, di conseguenza, dell'access point.

Sistemi di autenticazione misti TLS/PSK

L'autenticazione, come abbiamo visto, è un problema centrale. Il metodo di autenticazione più usato, dopo la PSK, è un tunnel TLS tra il client ed il server di autenticazione, all'interno del quale far girare EAP-PAP su RADIUS. Questo approccio, però, ha il difetto di non essere performante in termini di numero di pacchetti impegnati e dal punto di vista computazionale.

La soluzione a questo difetto è rappresentata da un sistema misto nel quale, dopo un'autenticazione forte con RADIUS, TLS e EAP, venga derivata una chiave temporanea di lungo periodo, una PSK temporanea da usare con EAP-AKA tra il client ed il server di autenticazione, allo scopo di ridurre il traffico.

Questo approccio ha l'effetto di rendere più facile la gestione delle credenziali, e porta con sé anche la migliore efficienza data dai sistemi basati su PSK.

Collegamenti esterni

• Standard RFC 2865 per RADIUS (in inglese) (11/12/2008 verificato funzionante)
• Standard RFC 2865 per accounting di RADIUS (in inglese) (11/12/2008 verificato funzionante)
• Standard RFC 3579 per EAP (in inglese) (11/12/2008 verificato funzionante)
• Standard RFC 3748 per EAP (in inglese) (11/12/2008 verificato funzionante)
• Sito ufficiale del software AirSnort (in inglese) (11/12/2008 verificato funzionante)
• Sito ufficiale del software WEPCrack (in inglese) (11/12/2008 verificato funzionante)