2. Crittografia Wi-Fi

Il Wi-Fi funziona su onde radio, il che significa che è soggetto ad ascolto indiscreto e, pertanto, è necessario utilizzare la crittografia per proteggere i dati trasmessi.

Wired Equivalent Privacy (WEP) è stato creato quando è stato rilasciato lo standard 802.11 per fornire funzionalità di privacy simili a quelle presenti nelle reti cablate.

Non appena sono state scoperte le falle nel WEP (il WEP può essere crackato in meno di un minuto), l'IEEE ha creato un nuovo gruppo chiamato 802.11i volto a migliorare la sicurezza Wi-Fi. Wi-Fi Protected Access (WPA) ha sostituito il WEP nel 2003, seguito dal WPA2 nel 2004 (standard 802.11i).

Poco dopo, le tecnologie di vari vendor hanno consentito agli utenti di condividere in modo sicuro le passphrase sui dispositivi da aggiungere alla rete senza doverle digitare. Wi-Fi Protected Setup (WPS) è stato rilasciato nel 2006 per standardizzarlo.

Il WPA3 è stato annunciato per la prima volta dalla Wi-Fi Alliance nel gennaio 2018 e rilasciato nel giugno dello stesso anno. Non è pensato per sostituire le soluzioni di sicurezza esistenti, ma mira a risolvere alcuni problemi chiave con quanto segue:

Forward secrecy, utilizzando un Dragonfly handshake, con SAE
Semplificare il processo di configurazione dei dispositivi senza display (come IoT)
Una nuova modalità a 192 bit per reti enterprise con cipher suite più robuste
Uso obbligatorio di Protected Management Frames (PMF), da 802.11w

Opportunistic Wireless Encryption (OWE), noto anche come "Enhanced Opened", aggiunge la crittografia alle reti Wi-Fi pubbliche.

2.1. Reti wireless aperte

Le reti aperte non prevedono alcuna crittografia, quindi chiunque esegua uno sniffer wireless può vedere il traffico "così com'è". Hotspot pubblici e reti mesh più datate sono buoni esempi di reti aperte. Il processo di connessione a una rete aperta è mostrato nella Figura 1 di seguito.

Figura 1: Il processo di connessione alle reti aperte

Il processo di connessione alla rete è il seguente:

Il client invia una richiesta di autenticazione all'AP
L'AP invia una risposta di autenticazione di "successful"
La STA invia una richiesta di associazione all'access point
L'AP invia una risposta di associazione se le capacità dei client corrispondono a quelle dell'AP

2.2. Wired Equivalent Privacy

Le reti aperte sono suscettibili ad ascolto indiscreto, poiché il traffico su di esse non è crittografato. Il WEP mira a fornire un certo grado di privacy ai dati scambiati sulla rete wireless. Fa parte dello standard IEEE 802.11 ed è uno schema utilizzato per proteggere le reti wireless usando Rivest Cipher 4 (RC4) per crittografare il traffico ed esegue checksum CRC32 per l'integrità dei messaggi.

La crittografia WEP utilizza solo un initialization vector (IV) a 24 bit poiché, quando lo standard WEP era in fase di redazione, la dimensione della chiave era limitata a causa delle restrizioni governative statunitensi sull'esportazione di tecnologie crittografiche. Era consentita una chiave a 64 bit, di cui 24 bit sono utilizzati per gli IV, riducendo così la dimensione reale della chiave a 40 bit. Una volta revocate le restrizioni all'esportazione, è stato implementato il WEP a 128 bit (utilizzando lo stesso IV a 24 bit).

2.2.1. RC4

Il RC4 è stato progettato da Ron Rivest di RSA Security ed è stato scelto per la crittografia wireless grazie alla sua semplicità e alla sua velocità impressionante.

Il RC4 è un cipher simmetrico, il che significa che la stessa chiave viene utilizzata sia per crittografare che per decrittografare i dati. Crea un flusso di bit che viene sottoposto a XOR con il plain text per ottenere i dati crittografati. Per decrittografarlo, possiamo semplicemente eseguire XOR del testo crittografato con il keystream per recuperare il plain text.

Il RC4 consiste in due elementi chiave:

Key Scheduling Algorithm (KSA): Inizializza la tabella di stato con l'IV e la chiave WEP
Pseudo-Random Generation Algorithm (PRGA): Crea il keystream

La Figura 2 illustra la crittografia e la decrittografia di dati in plain text utilizzando il keystream generato sopra.

Figura 2: Panoramica crittografia/decrittografia RC4

Di seguito, nella Figura 3, abbiamo un diagramma che illustra il processo di crittografia WEP.

Figura 3: Il processo di crittografia WEP

Una breve descrizione dei passaggi coinvolti nella crittografia WEP è la seguente:

Concatenare l'IV e la chiave WEP, quindi eseguire KSA e PRGA per ottenere il keystream.
Creare l'Integrity Check Value (ICV) del messaggio, quindi concatenarlo al messaggio.
Eseguire XOR del messaggio in plain text più il CRC32 e il keystream per ottenere il testo crittografato.
Il pacchetto contiene quindi i seguenti elementi:
- IV (utilizzato in precedenza)
- Key ID
- Encrypted Text
- ICV che è il CRC32 del plain text

Il processo di decrittografia WEP procede secondo la Figura 4 mostrata di seguito.

Figura 4: Il processo di decrittografia WEP

I passaggi che avvengono durante il processo di decrittografia sono i seguenti:

Concatenare l'IV e la chiave corrispondente al key ID, quindi eseguire KSA e PRGA per ottenere il keystream.
Eseguire XOR del messaggio crittografato e del keystream, ottenendo il messaggio + ICV.
Confrontare l'ICV decrittografato con quello ricevuto con il pacchetto. Se sono uguali, il frame è integro e accettato, altrimenti scartare il frame, poiché il pacchetto è falso o corrotto.

2.2.2. Autenticazione WEP

Il WEP può utilizzare due sistemi di autenticazione: Open o Shared authentication. L'open authentication è banale e comunemente utilizzata. La shared authentication, d'altra parte, è piuttosto rara e i client spesso faticano provando l'open authentication prima di passare alla shared authentication.

Open Authentication

Nell'open authentication, un client non fornisce alcuna credenziale durante l'autenticazione all'Access Point. Tuttavia, una volta associato, deve possedere la chiave corretta per crittografare e decrittografare i data frame.

Shared Authentication

Durante l'autenticazione, un challenge text viene inviato al client. Il challenge text deve essere crittografato con la chiave WEP dal client e inviato all'AP per la verifica, il che consente al client di dimostrare la conoscenza della chiave. Una volta ricevuto il challenge text crittografato, l'AP tenta di decrittografarlo. Se ha successo e corrisponde alla versione in clear text del challenge text, al client è consentito procedere all'associazione all'access point.

2.3. Wi-Fi Protected Access

Il gruppo IEEE 802.11i, volto a migliorare la sicurezza wireless, ha proceduto a sviluppare due nuovi protocolli di crittografia del livello di collegamento: Temporal Key Integrity Protocol (TKIP) e Counter Mode with CBC-MAC (CCMP).

Il CCMP è stato progettato da zero e ha richiesto molto più tempo per essere completato rispetto al TKIP. Al TKIP è stato assegnato il nome commerciale WPA1, mentre WPA2 è stato assegnato al CCMP.

La crittografia WPA si presenta in due varianti:

WPA Personal: Utilizza l'autenticazione pre-shared key (WPA-PSK), una passphrase condivisa da tutti i peer della rete.
WPA Enterprise: Utilizza 802.1X e un server Radius per Authentication, Authorization, and Accounting (AAA).

Nella Figura 5 di seguito, abbiamo un'illustrazione della configurazione per creare il canale di comunicazione sicuro WPA.

Figura 5: Il processo di connessione WPA

2.3.1. Cipher WPA

Sono disponibili due cipher, TKIP, per hardware legacy che può gestire solo WEP, e CCMP, basato su Advanced Encryption Standard (AES).

TKIP

Il TKIP si basa sulla terza bozza di 802.11i. È stato progettato per essere retrocompatibile con hardware legacy e utilizza ancora il WEP come algoritmo di crittografia, sebbene affronti le falle riscontrate nel WEP con i seguenti elementi:

Per packet key mixing
IV sequencing per evitare replay attacks
Nuovo Message Integrity Check (MIC), utilizzando l'algoritmo Michael e contromisure sui fallimenti MIC
Meccanismo di key distribution e rekeying

CCMP

Il CCMP è l'implementazione della versione finale di 802.11i ed è anche chiamato Robust Security Network (RSN). Utilizza un nuovo algoritmo basato su AES. È stato progettato da zero e non è compatibile con hardware più datato.

2.3.2. Connessione di rete WPA

Il canale di comunicazione sicuro viene configurato in quattro passaggi:

Accordo sui protocolli di sicurezza
Autenticazione
Key distribution e verifica
Crittografia dei dati e integrità

Nella Figura 6 di seguito, abbiamo un'illustrazione della configurazione per creare il canale di comunicazione sicuro WPA Enterprise.

Figura 6: Il processo di connessione WPA Enterprise

Nei sistemi WPA-PSK, il processo è leggermente semplificato, poiché sono necessari solo 3 passaggi. Il passaggio di autenticazione viene rimosso come illustrato di seguito.

Figura 7: Il processo di connessione WPA-PSK

Accordo sui protocolli di sicurezza

I diversi protocolli di sicurezza consentiti dall'AP sono forniti nei suoi beacon:

Mezzi di autenticazione, tramite PSK o tramite 802.1X utilizzando un server AAA
Encryption suite per traffico unicast e multicast/broadcast: TKIP, CCMP

La STA invia prima una probe request per ricevere informazioni sulla rete (ad es. data rate, crittografia, canale, ecc.) e si unirà alla rete utilizzando l'open authentication seguita dall'associazione in cui indica quali cipher verranno utilizzati.

2.3.3. Autenticazione WPA

Il passaggio di autenticazione viene eseguito solo nelle configurazioni WPA Enterprise. Si basa sull'Extensible Authentication Protocol (EAP) e può essere eseguito con quanto segue:

EAP-TLS con certificati client e server
EAP-TTLS
PEAP per autenticazione ibrida in cui è richiesto solo il certificato del server

Questa autenticazione viene avviata quando il client seleziona la modalità di autenticazione da utilizzare. Diversi messaggi EAP, a seconda della modalità di autenticazione, verranno scambiati tra l'authenticator e il supplicant per generare una Master Key (MK).

Alla fine della procedura, se ha successo, un messaggio "Radius Accept" viene inviato all'AP contenente la MK e un altro messaggio, un messaggio EAP inviato al client per indicare il successo.

Key Distribution and Verification

La terza fase si concentra sullo scambio delle diverse chiavi utilizzate per autenticazione, integrità dei messaggi e crittografia dei messaggi. Ciò avviene tramite il 4-way handshake per scambiare la Pairwise Transient Key (PTK) e la corrente Group Temporal Key (GTK), rispettivamente le chiavi utilizzate per unicast e multicast/broadcast, e poi il Group Key handshake per rinnovare la GTK.

Questa parte consente:

Conferma del cipher suite utilizzato
Conferma della conoscenza della PMK da parte del client
Installazione delle chiavi di integrità e crittografia
Invio sicuro della GTK

Un'illustrazione delle fasi di key distribution e verifica è mostrata nella Figura 8.

Figura 8: La fase di key distribution e verifica

Nota: L'authenticator è l'AP e il supplicant è la STA.

L'authenticator invia un nonce al supplicant, chiamato ANonce.
Il supplicant crea la PTK e invia il proprio nonce, SNonce, con il MIC. Dopo la costruzione della PTK, verificherà se il supplicant ha la PMK corretta. Se il controllo MIC fallisce, il supplicant ha la PMK sbagliata.
Il messaggio dall'authenticator al supplicant conterrà, quando viene utilizzato WPA2/3, la GTK corrente. Questa chiave viene utilizzata per decrittografare il traffico multicast/broadcast. Se quel messaggio non viene ricevuto, viene reinviato. Se 802.11w è negoziato, l'IGTK è inclusa. Con WPA1, la GTK verrà inviata in uno scambio successivo.
Infine, il supplicant invia un acknowledgement all'authenticator. Il supplicant installa le chiavi e avvia la crittografia.

Il group key handshake è molto più semplice delle pairwise keys perché viene eseguito dopo il 4-way handshake (dopo l'installazione delle chiavi) e quindi ora abbiamo un collegamento sicuro. Viene eseguito anche tramite messaggi Extensible Authentication Protocol over LAN (EAPoL), ma questa volta i messaggi sono crittografati. Il diagramma sottostante illustra questo processo.

Figura 9: Il processo di group key handshake

Se 802.11w è negoziato, un'IGTK viene inviata insieme alla GTK. Il MIC viene verificato dalla STA e riconosciuto nel messaggio 2.

Questo processo di aggiornamento avviene per i seguenti motivi:

WPA1, dopo il 4-way handshake
Una stazione si unisce alla rete
Una stazione lascia la rete
Quando scade un timer (controllato dall'authenticator, l'AP)
Una stazione può richiederlo inviando un messaggio di conferma non sollecitato
Una stazione può richiederlo inviando un frame EAPOL-Key con entrambi i bit Request e Group Key impostati

Pairwise Transient Key

Nella Figura 10, abbiamo il processo per generare la Pairwise Transient Key (PTK), derivata dalla Pairwise Master Key (PMK).

Figura 10: Il processo di generazione della Pairwise Transient Key

Input

Come input, prende entrambi i valori nonce, entrambi gli indirizzi MAC (supplicant e authenticator) e la PMK. Il calcolo della PMK funziona come segue:

Se il sistema è WPA Personal, utilizza la funzione PBKDF2 con i seguenti valori per generare la PSK (la PSK viene quindi utilizzata come PMK):

Password, la passphrase
SSID (e la sua lunghezza)
Il numero di iterazioni, 4096
La lunghezza della chiave risultante, 256 bit

Per WPA Enterprise che utilizza un server Radius, la PMK viene generata dalla Master Key (ottenuta durante lo scambio con il server) tramite la funzione TLS-PRF.

Hash Algorithm

PRF-X utilizzando HMAC-SHA1, dove X è 128, 192, 256, 384, 512 o 704, che indica la dimensione dell'output in bit.

Output

La PTK viene quindi divisa in diverse chiavi. Di seguito sono riportate le parti comuni da TKIP e CCMP:

Key Encryption Key (KEK) (128-bit; bits 0-127): utilizzata dall'AP per crittografare dati aggiuntivi inviati alla STA, ad esempio la RSN IE o la GTK
Key Confirmation Key (KCK) (128-bit; bits 128-255): utilizzata per calcolare il MIC sui messaggi WPA EAPOL Key
Temporal Key (TK) (128-bit o 256-bit; bits 256-383 o 256-511): utilizzata per crittografare/decrittografare i pacchetti dati unicast

La dimensione della PTK CCMP è di 384 bit, composta dalle tre chiavi mostrate sopra. Il TKIP richiede altre due chiavi per l'integrità dei messaggi, aumentando così la dimensione della PTK a 512 bit:

MIC TX Key (64-bit; bits 384-447): utilizzata per calcolare il MIC sui pacchetti dati unicast inviati dall'AP
MIC RX Key (64-bit; bits 448-511): utilizzata per calcolare il MIC sui pacchetti dati unicast inviati dalla STA

La TK è a 128-bit a meno che non vengano utilizzate le seguenti cipher suite:

WEP-40 (40 bits)
WEP-104 (104 bits)
GCMP-256 (256-bits)
CCMP-256 (256-bits)
BIP-GMAC-256 (256-bits)
BIP-CMAC-256 (256-bits)

Group Temporal Key

La GTK viene utilizzata per crittografare e decrittografare il traffico multicast/broadcast. La sua costruzione avviene secondo l'illustrazione seguente. Si noti che la GTK è semplicemente un numero casuale, il che significa che qualsiasi funzione pseudocasuale può essere utilizzata per generarla.

Figura 11: Il processo di costruzione della GTK

Crittografia dei dati e integrità

Ci sono tre algoritmi diversi che possono essere utilizzati per la crittografia dei dati e l'integrità:

Temporal Key Integrity Protocol (TKIP)
Counter Mode with CBC-MAC (CCMP)
Wireless Robust Authenticated Protocol (WRAP)

Questi algoritmi sono molto più complessi del WEP e non verranno descritti in dettaglio qui.

Temporal Key Integrity Protocol

Il diagramma seguente mostra i diversi campi in un frame crittografato TKIP:

Figura 12: Un frame crittografato TKIP

Counter Mode with CBC-MAC

La Figura 13 di seguito mostra i diversi campi in un frame crittografato CCMP:

Figura 13: Un frame crittografato CCMP

Wireless Robust Authenticated Protocol

Il WRAP è basato su AES ma utilizza il cipher e lo schema di autenticazione Offset Codebook Mode (OCB). È stato il primo selezionato dal working group 802.11i, ma è stato abbandonato per motivi di proprietà intellettuale.

2.4. Wi-Fi Protected Access 3

Simultaneous Authentication of Equals (SAE) sostituisce la PSK nel WPA personal, che è la stessa crittografia utilizzata nelle reti mesh (802.11s). È una variante di Dragonfly. In modalità solo WPA3, il PMF è obbligatorio. In modalità transition, con WPA2 e WPA3 misti, il PMF è opzionale in WPA2 e obbligatorio quando si stabilisce una connessione in WPA3.

WPA Enterprise ottiene una modalità a 192-bit con protocolli di sicurezza più robusti. Autenticazione e crittografia utilizzeranno GCMP-256. Key derivation e conferma utilizzano HMAC-SHA384. Key establishment e autenticazione utilizzano ECDHE e ECDSA con una curva ellittica a 384 bit.

Il WPA3 non utilizza alcun algoritmo di crittografia più recente, ma ora AES è l'unico cipher consentito.

Mentre WPA/WPA2 (così come le reti Open e WEP) ha una semplice fase di autenticazione e associazione, prima del 4-way handshake, la fase di autenticazione viene rielaborata ed è qui che avviene il Dragonfly handshake.

Ci sono due fasi, o scambi, nella fase di autenticazione. Prima un commit exchange seguito da un confirm exchange.

Nel commit exchange, entrambe le parti si impegnano verso un segreto condiviso. Nel confirm exchange, confermano di condividere entrambe la stessa password e poi derivano una PMK che verrà quindi utilizzata nel 4-way exchange.

Il SAE offre un modo migliore per stabilire una connessione sicura utilizzando uno scambio di chiavi Diffie-Hellman (DH) con una Elliptic Curve o un Prime Modulus.

Di seguito è riportato l'elenco dei diversi gruppi per il Diffie-Hellman Exchange:

Number	Name
0	NONE
1	768-bit MODP Group
2	1024-bit MODP Group
3-4	Reserved
5	1536-bit MODP Group
6-13	Unassigned
14	2048-bit MODP Group
15	3072-bit MODP Group
16	4096-bit MODP Group
17	6144-bit MODP Group
18	8192-bit MODP Group
19	256-bit random ECP group
20	384-bit random ECP group
21	521-bit random ECP group
22	1024-bit MODP Group with 160-bit Prime Order Subgroup
23	2048-bit MODP Group with 224-bit Prime Order Subgroup
24	2048-bit MODP Group with 256-bit Prime Order Subgroup
25	192-bit Random ECP Group
26	224-bit Random ECP Group
27	brainpoolP224r1
28	brainpoolP256r1
29	brainpoolP384r1
30	brainpoolP512r1
31	Curve25519
32	Curve448
33-1023	Unassigned
1024-65535	Reserved for Private Use

Il minimo indispensabile richiede che tutte le implementazioni supportino il gruppo 19.

Sebbene tutti potrebbero essere utilizzati, solo i gruppi da 15 a 21 sono adatti alla produzione per motivi di sicurezza. Questi gruppi hanno un prime con 3072 bit e oltre per FFC e un prime a 256 bit e oltre quando si tratta di ECC.

Figura 14: Autenticazione WPA3

2.5. Opportunistic Wireless Encryption

Commercializzato come Enhanced Open dalla Wi-Fi Alliance, l'OWE consente di mitigare attacchi e ascolto indiscreto sulle reti aperte crittografando le connessioni.

Come menzionato sopra, in una situazione di rete Open, l'autenticazione e l'associazione sono un processo semplice, che porta all'accesso alla rete immediatamente. Non c'è autenticazione né crittografia.

Con OWE, uno scambio Diffie-Hellman viene eseguito durante la fase di associazione e il risultato viene quindi utilizzato come segreto per eseguire un 4-way handshake. Il client, notando che l'access point supporta OWE, aggiungerà la propria chiave pubblica alla Association request che sarà seguita dalla chiave pubblica dell'access point nella Association response.

Figura 14: Connessione Opportunistic Wireless Encryption

Il Diffie-Hellman Exchange può sembrare simile alla crittografia a chiave pubblica (come RSA). È una tecnologia asimmetrica/a chiave pubblica, ma differisce nel fatto che non è un algoritmo di crittografia: è finalizzato a generare e scambiare una chiave che viene poi utilizzata per la crittografia simmetrica. In questo caso, per il 4-way handshake.

Come il WPA3, dipende anche dal PMF e deve essere impostato come 'required' sull'AP affinché OWE sia disponibile (al contrario di 'optional'). Quando disponibile, sarà indicato nel Beacon e nelle Probe responses. Specificamente, nella lista Authentication and Key Management (AKM) suite nella RSN IE.

Gli AP supporteranno probabilmente la Transition mode, che consente reti Open e OWE contemporaneamente, in modo che i dispositivi legacy possano ancora connettersi. Gli AP in Transition mode possono avere un BSSID/ESSID separato per gestire entrambi i tipi di client.

L'algoritmo hash dipenderà dalla dimensione della chiave, che è collegata al gruppo DH utilizzato. Per Elliptic Curve Cryptography (ECC), con chiavi fino a 256 bit, viene utilizzato SHA-256. Fino a 384 bit, SHA-384 e per qualsiasi valore superiore, SHA-512. Utilizzando Finite Field Cryptography (FFC), fino a 2048 bit, verrà utilizzato SHA-256. Fino a 3072 bit, SHA-384 e per qualsiasi valore superiore, SHA-512.

Sebbene i gruppi Diffie-Hellman referenziati siano gli stessi del WPA3, si ritiene che solo i gruppi 19, 20 e 21, che sono ECC, verranno utilizzati in OWE.

Quando ci si connette all'Access Point, due specifici Information Elements (IE) devono essere presenti nella association request inviata dal client:

La RSN IE deve indicare OWE AKM
Un IE (ID 255) contenente la chiave pubblica e il gruppo. Il suo contenuto sarà il seguente:
Element ID extension, che è un ottetto e ha il valore di 32
Element-specific data, suddiviso in due parti, un campo di due ottetti (in little endian), che indica il gruppo utilizzato, seguito dalla chiave pubblica

L'encoding della chiave pubblica dipende dal suo tipo. Se è FFC, deve essere codificata in base alla conversione integer-to-octet-string di RFC6090. L'ECC è un po' più complessa, poiché dipende dalla curva utilizzata, definita in RFC6090 o RFC7748. Inoltre, deve essere utilizzata la compact representation se la curva proviene da RFC6090.

Controlli aggiuntivi devono essere eseguiti dal ricevitore dei frame per garantire la validità della chiave pubblica e del gruppo prima di generare la PMK.

Ciascuna parte deve eseguire quanto segue:

Diffie-Hellman sulla propria chiave privata e sulla chiave pubblica dell'altro peer
Alimentare il risultato a una funzione di element-to-scalar mapping. Chiameremo il risultato z
Concatenare la propria chiave pubblica, la chiave pubblica dell'altra parte, il Diffie-Hellman group come ottetti. Questo verrà utilizzato come salt in HKDF-extract insieme alla chiave 'z'. Genererà una chiave pseudo-casuale chiamata 'prk'. Come menzionato sopra, la funzione HMAC utilizzata dipenderà dalla dimensione della chiave (HMAC-SHA256, HMAC-SHA384 o HMAC-SHA512)
Generare la PMK da utilizzare nel 4-way handshake con HKDF-expand. I parametri saranno la chiave pseudocasuale, la stringa "OWE Key Generation" come contesto e la lunghezza in bit dell'algoritmo hash utilizzato (256, 384 o 512)

Verrà generato anche un PMKID, facendo hash della concatenazione delle chiavi pubbliche di entrambe le parti utilizzando SHA256/384 o 512 (a seconda del Diffie-Hellman utilizzato) e mantenendo i 128 bit più a sinistra. Il client può scegliere di fare PMK caching per evitare di ripetere la costosa autenticazione e indicare il PMKID nella sua association request. Sia il client che l'AP possono memorizzare nella cache le chiavi per un certo periodo di tempo. Se l'access point accetta il PMKID, lo indicherà nella association response. Altrimenti, inizierà il normale processo di associazione OWE.

2.6. Wireless Protected Setup

Noto anche come Wi-Fi Simple Configuration, questo protocollo consente agli utenti di associare dispositivi a una rete senza dover inserire l'ESSID e/o la sua passphrase (a volte complessa).

In passato, diversi vendor fornivano varie soluzioni a questo problema, ma erano incompatibili tra loro. La Wi-Fi Alliance ha lanciato il WPS nel 2006 con l'obiettivo di standardizzare le soluzioni.

Il WPS attualmente supporta reti Open o WPA2 (con CCMP o GCMP) così come reti WPA2 Enterprise. Il WPA (TKIP) è stato deprecato nella versione corrente della specifica.

L'enrollment può essere eseguito in vari modi, come utilizzando un pulsante sull'access point, inserendo un PIN da un'etichetta, tramite un display sull'Access Point, dalla sua interfaccia web (PIN statico o dinamico), o utilizzando Near Field Communications (NFC) con tap to connect.

2.6.1. Architettura WPS

Il WPS definisce tre componenti:

Enrollee: un dispositivo che cerca di unirsi a una WLAN
Access point
Registrar: un'entità con l'autorità di emettere o revocare credenziali per una WLAN

Ci sono tre interfacce:

E: logicamente posizionata tra l'Enrollee e il Registrar. Lo scopo è che il Registrar emetta credenziali a un Enrollee
M: l'interfaccia tra il Registrar e l'Access Point. Gestisce e configura l'access point
A: consente la scoperta degli access point WPS (tramite IE nei beacon) e, per registrar esterni, consente le comunicazioni tra enrollee e registrar

Figura 15: Componenti e interfacce WPS

Sebbene il Registrar spesso giri sull'access point (noto come "standalone AP" o "internal registrar"), il Registrar e l'AP possono essere sistemi distinti, come un dispositivo mobile utilizzato per configurare l'Enrollee. Il Registrar può anche trovarsi su un'interfaccia di gestione centralizzata.

Sebbene il WPS sia considerato solo WPA-PSK, tecnicamente può essere utilizzato anche in alcuni casi per WPA Enterprise. Nel caso di una rete WPA-PSK, è possibile che un client diventi registrar e configuri nuovi client.

2.6.2. Metodi di configurazione WPS

Un dispositivo che supporta Wi-Fi Simple Configuration dovrebbe sempre avere un PIN predefinito disponibile (noto anche come device password), stampato sull'AP o su un'etichetta applicata. Tuttavia, si raccomanda che il PIN sia modificabile dall'utente finale.

Sono disponibili due modalità operative: configurazione in-band e configurazione out-of-band. L'in-band viene eseguita tramite comunicazione WLAN e l'out-of-band viene eseguita utilizzando qualsiasi altro canale o metodo di comunicazione, come utilizzando un tag NFC o una chiavetta USB.

L'out-of-band può essere non crittografato e ha il vantaggio di poter essere riutilizzato con più enrollee, ma se un attaccante mette le mani sul supporto, ha le credenziali WLAN. I metodi out-of-band possono anche contenere credenziali WLAN crittografate. Utilizza la chiave pubblica dell'enrollee ottenuta sul canale WLAN. Un'ultima possibilità è eseguire uno scambio Diffie-Hellman su NFC, quindi crittografare le credenziali consegnate all'interfaccia NFC utilizzando AES.

Nell'in-band, viene eseguito uno scambio Diffie-Hellman e autenticato utilizzando un segreto condiviso (il device password) tramite inserimento manuale o utilizzando NFC. Nella maggior parte dei casi, utilizzando un dispositivo headless, il PIN deve essere lungo 8 cifre (dove l'ultima cifra è un checksum). Se il dispositivo ha un display, il PIN può essere lungo 8 o 4 cifre, ma in questo caso deve essere generato casualmente.

2.6.3. Protocollo WPS

Il protocollo WPS varia in base ai diversi scenari possibili. Tratteremo solo lo scenario più comune in cui l'enrollee utilizza WPS PIN su un standalone AP. I protocolli dettagliati di altri scenari possibili possono essere trovati nella Wi-Fi Simple Configuration technical specification.

Figura 16: Configurazione utilizzando un standalone AP/Registrar

Nella Figura 16, il primo passaggio è la discovery in cui l'enrollee interroga l'AP con un Wi-Fi Simple Configuration Information Element (IE) nella probe request. Se risponde positivamente, il dispositivo eseguirà il consueto processo di autenticazione e associazione, quindi procederà ad avviare il processo 802.1X e risponderà con un'identità WFA-SimpleConfig-Enrollee-1-0. L'enrollee viene provisionato dopo lo scambio dei messaggi da M1 a M8. Infine, il dispositivo viene disconnesso dall'AP e si riconnette con le credenziali ricevute in precedenza.

I messaggi M1 e M2 possono essere scambiati mentre si attende che l'utente inserisca il device password dell'enrollee dall'interfaccia del dispositivo nell'AP.

Quando si utilizza un registrar esterno e/o un pulsante, la comunicazione tra l'enrollee e l'AP è essenzialmente la stessa di quanto descritto sopra. La comunicazione tra l'AP e il registrar è ciò che differisce.

Una volta raggiunto M5, conosciamo la prima metà del PIN. Se riceviamo un NACK dopo M6, la seconda metà è errata.

2.6.4. Messaggi del protocollo di registrazione WPS

I messaggi EAP da M1 a M8 sono specifici del protocollo di registrazione WPS e sono creati come segue:

M1 = Version || N1 || Description || PKE
M2 = Version || N1 || N2 || Description || PKR [ || ConfigData ] || HMACAuthKey( M1 || M2* )
M3 = Version || N2 || E-Hash1 || E-Hash2 || HMACAuthKey( M2 || M3* )
M4 = Version || N1 || R-Hash1 || R-Hash2 || ENCKeyWrapKey(R-S1) || HMACAuthKey( M3 || M4* )
M5 = Version || N2 || ENCKeyWrapKey(E-S1) || HMACAuthKey( M4 || M5* )
M6 = Version || N1 || ENCKeyWrapKey(R-S2) || HMACAuthKey( M5 || M6* )
M7 = Version || N2|| ENCKeyWrapKey(E-S2 [||ConfigData]) || HMACAuthKey( M6 || M7* )
M8 = Version || N1 || [ ENCKeyWrapKey(ConfigData) ] || HMACAuthKey( M7 || M8* )

Quanto segue spiega il significato dei diversi simboli e elementi utilizzati sopra:

||: concatenazione di parametri per formare un messaggio
I pedici sono utilizzati nel contesto di una funzione crittografica come HMACKey. In questo caso, si riferisce alla chiave utilizzata da quella funzione (HMAC)
Quando un messaggio è seguito da *, si riferisce al messaggio meno il suo valore HMAC-SHA-256
Version: identifica il tipo di messaggio Registration Protocol
N1 e N2: nonce a 128 bit (numero casuale generato una volta) generati rispettivamente dall'Enrollee e dal Registrar
Description: descrizione leggibile del dispositivo mittente (UUID, produttore, numero di modello, indirizzo MAC, ecc.) e capacità del dispositivo come algoritmi supportati, canali I/O, ruolo Registration Protocol, ecc. I dati Description sono inclusi anche nei messaggi probe request e probe response 802.11
PKE e PKR: chiavi pubbliche Diffie-Hellman dell'Enrollee e del Registrar, rispettivamente. Se in futuro verrà aggiunto il supporto per altre cipher suite (come elliptic curve), verrà utilizzato un numero Version del protocollo diverso
AuthKey: chiave di autenticazione derivata dal segreto Diffie-Hellman gAB mod p, dai nonce N1 e N2 e dall'indirizzo MAC dell'Enrollee. Se M1 e M2 sono entrambi trasportati su un canale non suscettibile ad attacchi man-in-the-middle, il device password dell'Enrollee può essere omesso dalla key derivation
E-Hash1 e E-Hash2: pre-commitment effettuati dall'Enrollee per dimostrare la conoscenza delle due metà del proprio device password
R-Hash1 e R-Hash2: pre-commitment effettuati dal Registrar per dimostrare la conoscenza delle due metà del device password dell'Enrollee
ENCKeyWrapKey(...): indica la crittografia simmetrica dei valori tra parentesi utilizzando la chiave KeyWrapKey con l'algoritmo di crittografia AES-CBC secondo FIPS 197, con padding PKCS#5 v2.0
R-S1 e R-S2: nonce segreti a 128 bit che, insieme a R-Hash1 e R-Hash2, possono essere utilizzati dall'Enrollee per confermare la conoscenza da parte del Registrar della prima e seconda metà del device password dell'Enrollee, rispettivamente
E-S1 e E-S2: nonce segreti a 128 bit che, insieme a E-Hash1 e E-Hash2, possono essere utilizzati dal Registrar per confermare la conoscenza da parte dell'Enrollee della prima e seconda metà del device password dell'Enrollee, rispettivamente
HMACAuthKey(...): indica un attributo Authenticator che contiene un hash HMAC con chiave sui valori tra parentesi e utilizzando la chiave AuthKey. La funzione hash con chiave è HMAC-SHA-256 secondo FIPS 180-2 e RFC-2104. Per ridurre le dimensioni dei messaggi, solo 64 bit dell'output HMAC a 256 bit sono inclusi nell'attributo Authenticator
ConfigData: impostazioni WLAN e credenziali per l'Enrollee. Impostazioni aggiuntive per altre reti e applicazioni possono essere incluse anche in ConfigData. Sebbene qui sia mostrato come sempre crittografato, la crittografia è obbligatoria solo per chiavi e key binding ed è opzionale per altri dati di configurazione. È decisione del mittente se crittografare o meno una determinata parte di ConfigData

2.7. 802.11w

Sebbene la crittografia protegga i dati trasmessi sulla rete, questi restano vulnerabili al Denial of Service attraverso attacchi comuni che utilizzano frame come deauthentication o disassociation.

Noto anche come Protected Management Frames, l'802.11w è stato rilasciato nel luglio 2009. Mira a migliorare il livello Medium Access Control aggiungendo integrità ad alcuni management frame critici sulle reti WPA (TKIP o CCMP) per prevenire la replay protection. È un requisito obbligatorio per la certificazione 802.11ac o Passpoint. È diventato parte dello standard 802.11 nel marzo 2012.

I seguenti frame sono protetti:

Disassociation
Deauthentication
Action frames: Block ACK (request and response), QoS Admission Control, Radio Measurement, Spectrum Management e Fast BSS Transition
Channel switch announcement (quando diretto a un client)
Security Association Query
Protected Dual of Public Action frame
Vendor-specific Protected

Alcuni dei frame menzionati sopra sono unicast, mentre altri sono multicast/broadcast. La crittografia utilizzata per l'unicast è la stessa PTK utilizzata per i data frame unicast. Per quelli multicast, una nuova Integrity Group Temporal Key (IGTK) viene ricevuta durante il 4-way handshake, contemporaneamente alla GTK.

Senza 802.11w, quando viene inviato un deauth, l'AP o uno o tutti i client lo accettano ciecamente e si disconnettono. Nella maggior parte dei casi, il client si riconnetterà automaticamente senza che l'utente lo sappia, eseguendo un 4-way handshake. Gli access point inviano deauthentication e disassociation di tanto in tanto come parte delle operazioni normali, ma questi frame possono anche essere utilizzati per attaccare i client.

Nel primo scenario, forzerà il client (o tutti i client) a disconnettersi e riconnettersi. Avverrà un 4-way handshake, che può successivamente essere crackato offline. È utile anche per attacchi contro il WEP.

Il secondo scenario è un denial of service, quando la deauthentication è sostenuta, poiché impedirà a uno o più client di connettersi.

Sebbene nella maggior parte dei casi il denial of service venga eseguito manualmente, i Wireless Intrusion Prevention System a volte hanno un'opzione per "contenere" un AP, ad esempio quando l'amministratore lo ha identificato come rogue. Disconnetterà automaticamente e immediatamente i client che tentano di connettersi al rogue. In alcuni casi, questa opzione può essere utilizzata in modo improprio.

2.7.1. Connessione

Lo stato PMF è indicato nel beacon, nella RSN IE, e due bit mostrano le impostazioni, nelle RSN capabilities.

Il primo, il bit 6, riguarda il requisito PMF. Se impostato, se il client non supporta PMF (capable o required), non sarà in grado di connettersi.

Il bit 7 indica se l'AP è PMF capable. Viene impostato automaticamente quando il bit 6 è impostato. In questo caso, un AP accetterà client con e senza PMF. Quelli con (capable o required) beneficeranno della protezione aggiuntiva pur consentendo ancora client che non possono gestirlo.

Durante la connessione, il client avrà una RSN IE nella sua association request con le proprie impostazioni per PMF.

La tabella seguente dettaglia l'esito della connessione a seconda delle impostazioni PMF del client e dell'AP:

AP	Client	Connection	PMF
No	No	Yes	No
No	Capable	Yes	No
No	Required	No
Capable	No	Yes	No
Capable	Capable	Yes	Yes
Capable	Required	Yes	Yes
Required	No	No
Required	Capable	Yes	Yes
Required	Required	Yes	Yes

Nel caso in cui un client o un AP abbia impostazioni non valide, non dovrebbe verificarsi alcuna connessione. Quando una stazione lo fa e tenta di associarsi a un AP, l'associazione verrà rifiutata.

2.7.2. Security Association Teardown Protection

Questo meccanismo previene attacchi che utilizzano frame di associazione, disassociazione o deautenticazione non protetti per interrompere una connessione.

Un client che ha perso la chiave tenterà di associarsi di nuovo, utilizzando un frame di associazione non protetto. L'AP, vedendo ciò, rifiuterà l'autenticazione chiedendo al client di riprovare più tardi, solitamente 10-20 secondi dopo. Nel frattempo, l'AP invierà un frame SA Query. Poiché il client non ha più la chiave, non è in grado di rispondere e quindi l'AP invierà una disassociation/deauthentication protetta e cancellerà le chiavi di crittografia. Quando è il momento di associarsi di nuovo, funzionerà. Nel caso in cui un attaccante tenti di associarsi mentre il client reale è ancora presente, riceverà la stessa risposta di associazione "torna tra XXX". Il client reale, avendo ancora le chiavi di crittografia, è in grado di rispondere al SA Query e quindi non succede nulla, non viene disconnesso.

Dall'altro lato, quando l'AP perde le chiavi, a un certo punto, il client associato invierà un data frame crittografato all'AP, poiché ha le chiavi di crittografia. L'AP, non avendo più il client nella sua lista (o semplicemente non ha più le chiavi), invierà un frame deauthentication/disassociation al client (molto probabilmente un frame con reason code 6 o 7: class 2 frame received from nonauthenticated STA o class 3 frame received from nonassociated STA). Il client invierà quindi un SA Query protetto all'AP, per assicurarsi che sia l'access point legittimo. Poiché l'AP non ha le chiavi, non è in grado di rispondere entro il tempo assegnato. La connessione verrà interrotta e dovrà riconnettersi. Nel caso in cui sia un AP falso o rogue, poiché entrambi hanno le chiavi, l'AP reale risponderà al SA Query e la connessione rimarrà.

Ci sono alcuni scenari in cui un client o un AP possono perdere le chiavi e vengono gestiti con questo meccanismo. Può accadere in caso di un problema hardware o software e il dispositivo/connessione viene resettato. Ad esempio, un problema firmware in cui il dispositivo crasha e viene resettato, o l'alimentazione è andata via per un secondo, resettando così il dispositivo.

Nota: Un dispositivo trasmette solo quando necessario, e possono esserci periodi di tempo in cui non c'è alcun traffico tra l'AP e un client specifico.

2.8. Conclusione

In questo modulo abbiamo esaminato alcuni dettagli di base sui vari metodi di crittografia Wi-Fi disponibili.