Fondamenti del Protocollo WiFi e Evoluzione della Sicurezza

Stack del Protocollo WiFi: PHY, MAC e Architettura dei Frame

IEEE 802.11 opera su due livelli principali. Il Physical Layer (PHY) gestisce la modulazione, la codifica e la trasmissione RF—evolvendo da DSSS/CCK in 802.11b attraverso OFDM in 802.11a/g fino a OFDMA in 802.11ax (WiFi 6). Il Medium Access Control (MAC) Layer gestisce l'accesso al canale tramite CSMA/CA con backoff esponenziale, l'indirizzamento dei frame, la frammentazione e la gestione dell'alimentazione. A differenza del CSMA/CD di Ethernet, il WiFi non può rilevare collisioni durante la trasmissione; si affida alla clear channel assessment e ai frame di acknowledgment.

I frame MAC portano quattro distinti campi indirizzo in certe modalità—un artefatto dei wireless distribution system (WDS) e dei formati frame a quattro indirizzi per il bridging AP-to-AP. La maggior parte del traffico utilizza tre indirizzi: destinazione, sorgente e BSSID.

Tipo di Frame Scopo Rilevanza per la Sicurezza
Management Autenticazione, associazione, beacon, probe Storicamente non autenticati; 802.11w aggiunge protezione dell'integrità
Control RTS/CTS, ACK, Block Ack Nessun payload; protezione frame tramite disciplina di sequenza
Data Trasmissione payload utente Cifrato sotto PTK/GTK; sottotipi QoS in 802.11e

La struttura del frame segue questo ordine: Frame Control (2 byte), Duration/ID, campi Address, Sequence Control, QoS Control (se presente), HT Control (se presente), Frame Body (0–2304 byte), FCS (CRC-32). I bit Type e Subtype del campo Frame Control determinano la gestione; i bit To DS/From DS controllano l'interpretazione degli indirizzi.

Catturare e ispezionare frame 802.11 raw con:

# Richiede interfaccia in monitor mode e privilegi root
sudo airmon-ng start wlan0
sudo tcpdump -i wlan0mon -e -s 0 -w beacon_capture.pcap 'type mgt subtype beacon'

Cosa fa: Mette l'interfaccia in monitor mode, cattura frame 802.11 di Layer 2 inclusi header radiotap con metadati del segnale. Il filtro limita ai frame beacon. Quando usarlo: Rilevamento di base, rilevamento AP rogue, analisi dell'utilizzo del canale. Rischi: La monitor mode interrompe il normale funzionamento della stazione; le catture possono includere dati sensibili di broadcast SSID. Output atteso: File PCAP con frame 802.11 raw visualizzabili in Wireshark o tshark.

tshark -r beacon_capture.pcap -T fields -e wlan.bssid -e wlan.ssid -e wlan.rsn.ie.akms.type -c 10

f8:e4:e3:12:34:56	CorpWiFi	00
f8:e4:e3:12:34:57	CorpWiFi	00
00:14:d1:ab:cd:ef	GuestNet	02

Interpretazione: Il campo akms.type rivela la gestione delle chiavi di autenticazione: 00 = 802.1X (enterprise), 02 = PSK (personal). Il BSSID duplicato con MAC incrementale suggerisce molteplici AP sullo stesso SSID—normale per deployment enterprise.

Evoluzione dei Meccanismi di Sicurezza: Da WEP a WPA3

La progressione da WEP a WPA3 non è un miglioramento incrementale ma una sostituzione architetturale. Ogni generazione ha affrontato fallimenti fondamentali:

Generazione Cifrario Derivazione della Chiave Debolezza Critica
WEP RC4 Chiave statica 40/104-bit + IV 24-bit Riutilizzo IV; recupero keystream RC4; nessuna integrità oltre CRC-32
WPA/TKIP RC4 con key mixing per-pacchetto 4-way handshake da PSK o 802.1X Michael MIC troppo debole; deprecato 2012
WPA2-Personal AES-CCMP (128-bit) PMK da PBKDF2(HMAC-SHA1, passphrase, SSID, 4096 iterazioni) Attacco dizionario offline su cattura 4-way handshake
WPA2-Enterprise AES-CCMP PMK da scambio chiave 802.1X/EAP RADIUS rogue; fallimenti validazione certificati
WPA3-Personal AES-CCMP o AES-GCMP-256 SAE (Simultaneous Authentication of Equals) Trasmissioni side-channel in implementazioni early; vulnerabilità dragonblood
WPA3-Enterprise GCMP-256 (obbligatorio) Modalità sicurezza 192-bit Complessità implementativa; attacchi downgrade se modalità transizionale abilitata

L'SAE di WPA3 sostituisce lo scambio PSK con uno scambio di chiavi autenticato da password basato su logaritmi discreti o crittografia a curve ellittiche. A differenza di WPA2-Personal, la conoscenza della password non produce il PMK; non c'è materiale da attaccare offline. Tuttavia, implementazioni early hanno trasmesso informazioni di timing abilitando il recupero side-channel—patchate, ma un promemoria che la correttezza della specifica non garantisce la sicurezza dell'implementazione.

Meccanismi Crittografici: CCMP, GCMP e SAE

CCMP (Counter Mode with CBC-MAC Protocol) combina AES-128 in modalità CTR per confidenzialità con CBC-MAC per integrità. La struttura di 8-ottetti MIC e 8-ottetti IV/nonce impone un overhead di 16 ottetti per MPDU. GCMP (Galois/Counter Mode Protocol) sostituisce CBC-MAC con GHASH, abilitando operazione parallela e throughput maggiore—obbligatorio nella modalità 192-bit di WPA3-Enterprise, opzionale in WPA3-Personal.

SAE opera in due fasi:

  1. Commit: Ogni peer genera coppia scalar/element, trasmette pubblicamente. La maschera derivata dalla password assicura il contributo della password.
  2. Confirm: Entrambe le parti derivano segreto condiviso, confermano mutua derivazione.

La Pairwise Master Key (PMK) risultante è specifica per sessione; anche password identiche producono PMK distinti per associazione.

Gerarchia delle Chiavi e il Four-Way Handshake

Comprendere la derivazione delle chiavi è prerequisito per analizzare attacchi di cattura handshake o risolvere fallimenti di roaming.

Chiave Derivazione Ambito Durata
PSK Passphrase utente o hex 64 caratteri Solo modalità personal Statico fino a riconfigurazione
PMK PSK via PBKDF2, o export chiave EAP Per-sessione Durata associazione
PTK PRF(PMK, "Pairwise key expansion", ANonce‖SNonce‖MAC_AP‖MAC_STA) Per coppia STA/AP Rekeyed o vincolato a sessione
GTK Generato AP, cifrato in EAPOL-Key Broadcast/multicast Rekeying di gruppo periodico

Il four-way handshake (802.11i-2004, Clausola 8.5.3) deriva PTK da nonce e indirizzi MAC:

  1. Messaggio 1 (AP→STA): ANonce, key info (unicast, key ACK, key MIC)
  2. Messaggio 2 (STA→AP): SNonce, key info (unicast, key MIC, encrypted key data include RSNE)
  3. Messaggio 3 (AP→STA): Installazione GTK, key info (unicast, install, key ACK, key MIC, encrypted key data)
  4. Messaggio 4 (STA→AP): Conferma finale

La vulnerabilità nonce reuse (KRACK, 2017) ha sfruttato il Messaggio 3 ritrasmettuto forzando il reset del nonce nella variante GTK handshake, abilitando replay e decrittazione. La fix: non reinstallare mai chiavi già in uso.

Ispezionare lo stato dell'handshake con:

# Lab: Analizzare completezza handshake e comportamento nonce
tshark -r wpa_handshake.pcap -Y "eapol" -T fields -e frame.number -e wlan.fc.retry \
  -e eapol.keydes.nonce -e eapol.keydes.key_info.key_mic -e eapol.keydes.key_info.install

Cosa fa: Estrae campi frame EAPOL-Key per verificare completezza handshake e rilevare anomalie (flag retry, nonce ripetuti, timing del bit install). Quando usarlo: Validare qualità cattura per hashcat/aircrack, investigare varianti KRACK, risolvere fallimenti roaming. Rischi: L'analisi PCAP è passiva; nessun impatto di rete. Output atteso: Sequenza tabellare mostrando progressione nonce e stato bit install.

frame.number wlan.fc.retry eapol.keydes.nonce key_mic install
142 0 ANonce_value... 1 0
144 0 SNonce_value... 1 0
146 0 ANonce_value... 1 1
148 0 (empty) 1 0

Flag retry su Messaggio 1 o 3 meritano scrutinio—attaccanti attivi iniettano ritrasmissioni per sfruttare la logica di reinstallazione.

802.11w: Protected Management Frames

Il problema persistente: i frame di management devono propagarsi a tutte le stazioni, incluse quelle non associate, precludendo la cifratura standard. 802.11w (PMF) fornisce protezione dell'integrità e resistenza al replay senza confidenzialità—le stazioni ignorano deautenticazione, disassociazione o annunci di channel switch rogue contraffatti.

PMF richiede CCMP o GCMP; non può operare con TKIP. Il deployment utilizza association comebacks con procedure SA Query per prevenire che disassociazione spoofata forzi una piena riautenticazione—critico per applicazioni sensibili alla latenza e fast-secure roaming (802.11r).

Verificare la capacità PMF nei frame beacon:

# Lab: Estrarre capacità RSN incluso MFP (Management Frame Protection)
tshark -r survey.pcap -Y "wlan.fc.type_subtype == 0x08" -T fields \
  -e wlan.bssid -e wlan.ssid -e wlan.rsn.ie.capabilities.mfp \
  | sort | uniq -c | sort -rn | head -20

Cosa fa: Analizza frame beacon per bit capacità MFP: 0 = no PMF, 1 = capable (opzionale), 2 = required. Quando usarlo: Rilevamento pre-deployment, analisi gap compliance, rilevamento AP rogue (impostazioni PMF inconsuete). Rischi: Solo passivo. Output atteso: Lista BSSID con annotazione di frequenza e postura PMF.

  47 f8:e4:e3:12:34:56	CorpWiFi	2
  12 00:14:d1:ab:cd:ef	GuestNet	0
   3 f8:e4:e3:12:34:57	CorpWiFi	1

Interpretazione: 2 significa PMF required—associazione senza negoziazione PMF rifiutata. 1 è "capable," permettendo downgrade. 0 è assente. L'entry 1 sullo stesso SSID suggerisce deployment transizionale o misconfigurazione che invita attacchi downgrade.

Framework 802.1X/EAP per Autenticazione Enterprise

I deployment enterprise disaccoppiano AP dalla verifica delle credenziali. L'AP agisce come authenticator, inoltrando frame EAP a un RADIUS authentication server (AS) via 802.1X. Il metodo EAP—PEAP, EAP-TLS, EAP-TTLS, EAP-FAST—determina la superficie di vulnerabilità.

Metodo Tunneling Credenziale Modalità di Fallimento Comune
PEAP-MSCHAPv2 TLS outer, inner MSCHAPv2 Username/password Bypass inner authentication; password deboli crackabili da challenge/response
EAP-TLS Mutual TLS Client certificate Onere gestione lifecycle certificati; dipendenza disponibilità CRL/OCSP
EAP-TTLS TLS outer, inner legacy PAP/CHAP Variabile Downgrade metodo inner

Misconcezione critica: "Enterprise è più forte di Personal" dipende interamente dall'implementazione. PEAP-MSCHAPv2 con password deboli e senza validazione certificato server è più debole di WPA3-Personal con password SAE forte. Il confine enterprise aggiunge identity management e revocazione centralizzata, non superiorità crittografica intrinseca.

Errori comuni in deployment WiFi enterprise:

Errore Perché ti colpisce
EAP-TLS senza OCSP stapling o distribuzione CRL Certificati revocati autenticano indefinitamente; dispositivi rogue con cert rubati persistono
PEAP con anonymous outer identity e nessuna validazione cert server Evil twin cattura challenge/response MSCHAPv2 inner; cracking hash offline segue
Fast-secure roaming (802.11r) senza PMF Gerarchia chiavi FT derivata da frame plaintext; flood deauth forzano riautenticazione per collezionare PMK-R0/PMK-R1
Modalità transizionale WPA3-Enterprise abilitata Downgrade a WPA2-Enterprise accettato; GCMP-256 mai negoziato

Approfondimento Derivazione Chiavi: Da PMK a PTK

La costruzione PRF conta per validazione forense:

PTK = PRF-512(PMK, "Pairwise key expansion", Min(ANonce,SNonce) ||
              Max(ANonce,SNonce) || Min(MAC_AP,MAC_STA) || Max(MAC_AP,MAC_STA))

La Key Confirmation Key (KCK) e la Key Encryption Key (KEK) sono estratte da PTK per calcolo MIC e cifratura key data rispettivamente. In 802.11r fast BSS transition, la gerarchia si estende a PMK-R0 (mantiene su AP/controller) e PMK-R1 (distribuita all'AP target), riducendo latenza di autenticazione a costo di complessità distribuzione chiavi—controller compromessi espongono materiale chiave più ampio.

Intuizione pratica: Le catture handshake per attacco WPA2-Personal funzionano offline perché la derivazione PSK-to-PMK (4096 iterazioni PBKDF2) è deterministica per coppia SSID/passphrase. Lo SSID agisce da salt—rainbow tables mirano SSID comuni. Cambiare lo SSID default da "linksys" fornisce protezione marginale contro tabelle precompute ma zero protezione contro computazione PBKDF2 mirata con GPU. L'SAE di WPA3 elimina interamente questo vettore di attacco rendendo il PMK non derivabile dalla sola password.

Approfondimenti