WiFi Protocol Foundations and Security Evolution

WiFi Protocol Stack: PHY, MAC, and Frame Architecture

IEEE 802.11 operates across two primary layers. The Physical Layer (PHY) handles modulation, coding, and RF transmission—evolving from DSSS/CCK in 802.11b through OFDM in 802.11a/g to OFDMA in 802.11ax (WiFi 6). The Medium Access Control (MAC) Layer manages channel access via CSMA/CA with exponential backoff, frame addressing, fragmentation, and power management. Unlike Ethernet's CSMA/CD, WiFi cannot detect collisions while transmitting; it relies on clear channel assessment and acknowledgment frames.

MAC frames carry four distinct address fields in certain modes—an artifact of wireless distribution systems (WDS) and four-address frame formats for AP-to-AP bridging. Most traffic uses three addresses: destination, source, and BSSID.

Frame Type Purpose Security Relevance
Management Authentication, association, beacon, probe Historically unauthenticated; 802.11w adds integrity protection
Control RTS/CTS, ACK, Block Ack No payload; frame protection via sequence discipline
Data User payload transmission Encrypted under PTK/GTK; QoS subtypes in 802.11e

Frame structure follows this order: Frame Control (2 bytes), Duration/ID, Address fields, Sequence Control, QoS Control (if present), HT Control (if present), Frame Body (0–2304 bytes), FCS (CRC-32). The Frame Control field's Type and Subtype bits determine handling; the To DS/From DS bits control address interpretation.

Capture and inspect raw 802.11 frames with:

# Requires monitor-mode interface and root privileges
sudo airmon-ng start wlan0
sudo tcpdump -i wlan0mon -e -s 0 -w beacon_capture.pcap 'type mgt subtype beacon'

What it does: Puts interface in monitor mode, captures Layer 2 802.11 frames including radiotap headers with signal metadata. The filter restricts to beacon frames. When to use it: Baseline surveying, rogue AP detection, channel utilization analysis. Risks: Monitor mode disrupts normal station operation; captures may include sensitive SSID broadcast data. Expected output: PCAP file with raw 802.11 frames viewable in Wireshark or 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

Interpretation: The akms.type field reveals authentication key management: 00 = 802.1X (enterprise), 02 = PSK (personal). The duplicate BSSID with incremental MAC suggests multiple APs on shared SSID—normal for enterprise deployments.

Security Mechanism Evolution: WEP to WPA3

The progression from WEP to WPA3 is not incremental improvement but architectural replacement. Each generation addressed fundamental failures:

Generation Cipher Key Derivation Critical Weakness
WEP RC4 Static 40/104-bit key + 24-bit IV IV reuse; RC4 keystream recovery; no integrity beyond CRC-32
WPA/TKIP RC4 with per-packet key mixing 4-way handshake from PSK or 802.1X Michael MIC too weak; deprecated 2012
WPA2-Personal AES-CCMP (128-bit) PMK from PBKDF2(HMAC-SHA1, passphrase, SSID, 4096 iterations) Offline dictionary attack on 4-way handshake capture
WPA2-Enterprise AES-CCMP PMK from 802.1X/EAP key exchange Rogue RADIUS; certificate validation failures
WPA3-Personal AES-CCMP or AES-GCMP-256 SAE (Simultaneous Authentication of Equals) Side-channel leaks in early implementations; dragonblood vulnerabilities
WPA3-Enterprise GCMP-256 (mandatory) 192-bit security mode Implementation complexity; downgrade attacks if transitional mode enabled

WPA3's SAE replaces the PSK exchange with a password-authenticated key exchange based on discrete logarithm or elliptic curve cryptography. Unlike WPA2-Personal, knowledge of the password does not yield the PMK; there is no material to attack offline. However, early implementations leaked timing information enabling side-channel recovery—patched, but a reminder that specification correctness does not guarantee implementation security.

Cryptographic Mechanisms: CCMP, GCMP, and SAE

CCMP (Counter Mode with CBC-MAC Protocol) combines AES-128 in CTR mode for confidentiality with CBC-MAC for integrity. The 8-octet MIC and 8-octet IV/nonce structure impose 16 octets of overhead per MPDU. GCMP (Galois/Counter Mode Protocol) replaces CBC-MAC with GHASH, enabling parallel operation and higher throughput—mandatory in WPA3-Enterprise's 192-bit mode, optional in WPA3-Personal.

SAE operates in two phases:

  1. Commit: Each peer generates scalar/element pair, transmits publicly. Password-derived mask ensures password contribution.
  2. Confirm: Both parties derive shared secret, confirm mutual derivation.

The resulting Pairwise Master Key (PMK) is session-specific; even identical passwords produce distinct PMKs per association.

Key Hierarchy and the Four-Way Handshake

Understanding key derivation is prerequisite to analyzing handshake capture attacks or troubleshooting roaming failures.

Key Derivation Scope Lifetime
PSK User passphrase or 64-char hex Personal mode only Static until reconfiguration
PMK PSK via PBKDF2, or EAP key export Per-session Association lifetime
PTK PRF(PMK, "Pairwise key expansion", ANonce‖SNonce‖MAC_AP‖MAC_STA) Per-STA/AP pair Rekeyed or session-bound
GTK AP-generated, encrypted in EAPOL-Key Broadcast/multicast Periodic group rekey

The four-way handshake (802.11i-2004, Clause 8.5.3) derives PTK from nonces and MAC addresses:

  1. Message 1 (AP→STA): ANonce, key info (unicast, key ACK, key MIC)
  2. Message 2 (STA→AP): SNonce, key info (unicast, key MIC, encrypted key data includes RSNE)
  3. Message 3 (AP→STA): GTK install, key info (unicast, install, key ACK, key MIC, encrypted key data)
  4. Message 4 (STA→AP): Final confirmation

The nonce reuse vulnerability (KRACK, 2017) exploited retransmitted Message 3 by forcing nonce reset in the GTK handshake variant, enabling replay and decryption. The fix: never reinstall already-in-use keys.

Inspect handshake status with:

# Lab: Analyze handshake completeness and nonce behavior
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

What it does: Extracts EAPOL-Key frame fields to verify handshake completeness and detect anomalies (retry flags, repeated nonces, install bit timing). When to use it: Validating capture quality for hashcat/aircrack, investigating KRACK variants, troubleshooting roaming failures. Risks: PCAP analysis is passive; no network impact. Expected output: Tabular sequence showing nonce progression and install bit state.

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

Retry flags on Message 1 or 3 warrant scrutiny—active attackers inject retransmissions to exploit reinstall logic.

802.11w: Protected Management Frames

The persistent problem: management frames must propagate to all stations, including unassociated ones, precluding standard encryption. 802.11w (PMF) provides integrity protection and replay resistance without confidentiality—stations ignore forged deauthentication, disassociation, or rogue channel switch announcements.

PMF requires CCMP or GCMP; it cannot operate with TKIP. Deployment uses association comebacks with SA Query procedures to prevent spoofed disassociation from forcing full reauthentication—critical for latency-sensitive applications and fast-secure roaming (802.11r).

Verify PMF capability in beacon frames:

# Lab: Extract RSN capabilities including 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

What it does: Parses beacon frames for MFP capability bits: 0 = no PMF, 1 = capable (optional), 2 = required. When to use it: Pre-deployment survey, compliance gap analysis, rogue AP detection (uncommon PMF settings). Risks: Passive only. Expected output: Frequency-annotated BSSID list with PMF posture.

  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

Interpretation: 2 means PMF required—association without PMF negotiation rejected. 1 is "capable," permitting downgrade. 0 is absent. The 1 entry on same SSID suggests transitional deployment or misconfiguration inviting downgrade attacks.

802.1X/EAP Framework for Enterprise Authentication

Enterprise deployments decouple AP from credential verification. The AP acts as authenticator, forwarding EAP frames to a RADIUS authentication server (AS) via 802.1X. The EAP method—PEAP, EAP-TLS, EAP-TTLS, EAP-FAST—determines vulnerability surface.

Method Tunneling Credential Common Failure Mode
PEAP-MSCHAPv2 TLS outer, inner MSCHAPv2 Username/password Inner authentication bypass; weak passwords crackable from challenge/response
EAP-TLS Mutual TLS Client certificate Certificate lifecycle management burden; CRL/OCSP availability dependency
EAP-TTLS TLS outer, inner legacy PAP/CHAP Variable Inner method downgrade

Critical misconception: "Enterprise is stronger than Personal" depends entirely on implementation. PEAP-MSCHAPv2 with weak passwords and no server certificate validation is weaker than WPA3-Personal with a strong SAE password. The enterprise boundary adds identity management and centralized revocation, not inherent cryptographic superiority.

Common mistakes in enterprise WiFi deployment:

Mistake Why it bites you
EAP-TLS without OCSP stapling or CRL distribution Revoked certificates authenticate indefinitely; rogue devices with stolen certs persist
PEAP with anonymous outer identity and no server cert validation Evil twin captures inner MSCHAPv2 challenge/response; offline hash cracking follows
Fast-secure roaming (802.11r) without PMF FT key hierarchy derived from plaintext frames; deauth floods force reauthentication to collect PMK-R0/PMK-R1
WPA3-Enterprise transitional mode enabled Downgrade to WPA2-Enterprise accepted; GCMP-256 never negotiated

Key Derivation Deep Dive: From PMK to PTK

The PRF construction matters for forensic validation:

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

The Key Confirmation Key (KCK) and Key Encryption Key (KEK) are extracted from PTK for MIC calculation and key data encryption respectively. In 802.11r fast BSS transition, the hierarchy extends to PMK-R0 (holds on AP/controller) and PMK-R1 (distributed to target AP), reducing authentication latency at the cost of key distribution complexity—compromised controllers expose broader key material.

Practical insight: Handshake captures for WPA2-Personal attack offline because PSK-to-PMK derivation (4096 PBKDF2 iterations) is deterministic per SSID/passphrase pair. The SSID acts as salt—rainbow tables target common SSIDs. Changing the default SSID from "linksys" provides marginal protection against precomputed tables but zero protection against targeted PBKDF2 computation with GPUs. WPA3's SAE eliminates this attack vector entirely by making the PMK non-derivable from password alone.

Further reading