Wireless Security

Wireless networks are inherently broadcast - every nearby device can receive every frame. The protocols below are the answer to “how do we keep that traffic private?”

---

Protocol Evolution (Quick Reference)

Protocol	Year	Cipher	Auth	Status
WEP	1997	RC4 + 24-bit IV	Shared/Open	❌ Broken - never use
WPA	2003	RC4 + TKIP	PSK or 802.1X	⚠️ Deprecated
WPA2-Personal	2004	AES-CCMP	Pre-shared key	✅ Acceptable (strong passphrase required)
WPA2-Enterprise	2004	AES-CCMP	802.1X/RADIUS	✅ Recommended for orgs
WPA3-Personal	2018	AES-CCMP + SAE	SAE (Dragonfly)	✅ Best for home/small office
WPA3-Enterprise	2018	AES-256-GCMP	802.1X + PMF	✅ Best for orgs

---

WEP - Why It Failed

WEP (Wired Equivalent Privacy) was the first 802.11 security protocol (1997). It failed due to a fundamental flaw in how it used the RC4 stream cipher.

The IV Problem

WEP generates a per-packet key by appending a 24-bit Initialization Vector (IV) to the shared key:

Per-packet key = [shared_key] + [24-bit IV]   (IV sent in plaintext!)

• Only 2²⁴ ≈ 17 million possible IVs
• After ~5,000 packets, IVs start repeating → same RC4 keystream reused
• RC4 keystream reuse: C1 XOR C2 = P1 XOR P2 → attacker recovers plaintext

The Authentication Flaw

WEP’s shared-key authentication transmits both plaintext challenge and the encrypted response in the same exchange - exposing (plaintext, ciphertext) pairs to any eavesdropper, making key recovery trivial.

Caution

WEP can be cracked in minutes. Tools like aircrack-ng collect weak IVs passively and recover the key after ~40,000 packets. If you see WEP anywhere in production - replace it immediately.

---

WPA - Temporary Fix

WPA (Wi-Fi Protected Access, 2003) was a firmware-upgradeable patch for WEP hardware. It kept the RC4 cipher but replaced the broken key generation with TKIP (Temporal Key Integrity Protocol).

TKIP Improvements over WEP

Problem in WEP	TKIP Fix
Weak IV → reused keystream	Secure per-packet key mixing (IV incorporated correctly into key derivation)
No replay protection	48-bit sequence counter; out-of-order packets are rejected
No integrity check	64-bit MIC (Michael) over each packet

Passphrase → Key Derivation

WPA never uses the Wi-Fi password directly to encrypt traffic. Instead:

PMK = PBKDF2(HMAC-SHA1, passphrase, SSID, 4096 iterations, 256-bit output)

• PBKDF2 with SSID as salt makes rainbow tables specific to each SSID - a table for “HomeNetwork” doesn’t work for “CoffeeShop”
• 4,096 HMAC-SHA1 iterations increases brute-force cost

WPS Vulnerability

WPA introduced Wi-Fi Protected Setup (WPS) for easy pairing. The PIN method (8 digits, last digit is checksum → ~11,000 effective guesses) is vulnerable to brute force with no lockout by default.

# Check for WPS vulnerabilities with wash
wash -i wlan0mon

# Brute-force WPS PIN (for authorized penetration testing only)
reaver -i wlan0mon -b [BSSID] -vv

Recommendation: Disable WPS on all access points.

---

WPA2 - The Current Standard

WPA2 replaces RC4+TKIP with AES-CCMP - a fundamentally stronger cipher suite.

AES-CCMP

• AES (Advanced Encryption Standard) - block cipher, 128-bit key
• CCMP (Counter Mode CBC-MAC Protocol) - a mode providing:
  • Confidentiality via AES in Counter Mode (CTR)
  • Integrity + authenticity via CBC-MAC

CCMP = AES-CTR (encryption) + AES-CBC-MAC (authentication tag)
     → Authenticated Encryption: can't modify ciphertext without detection

WPA2 Four-Way Handshake

After association, client and AP authenticate without transmitting the PMK - it stays secret on both ends.

AP                                    Client
│── [1] ANonce ──────────────────────→│
│                                     │  Client generates SNonce
│                                     │  Derives PTK:
│                                     │  PTK = PRF(PMK, ANonce, SNonce, AA, SA)
│←── [2] SNonce + MIC ───────────────│
│  AP verifies MIC (proves client     │
│  has correct PMK)                   │
│  AP derives same PTK                │
│── [3] GTK (encrypted) + MIC ──────→│
│←── [4] ACK ────────────────────────│
│                                     │
│══ Encrypted data (AES-CCMP) ═══════│

Key derivation:

PTK = PRF(PMK + ANonce + SNonce + MAC_AP + MAC_Client)

PTK contains 5 sub-keys:
  ├── KCK  - Key Confirmation Key (MIC in handshake msgs 2/3)
  ├── KEK  - Key Encryption Key (encrypts GTK in msg 3)
  ├── TK   - Temporal Key (encrypts actual data traffic)
  └── (2 MIC keys for Tx/Rx)

GTK - GroupWise Transient Key (shared, encrypts broadcast/multicast)

Note

PMK is long-lived. PTK is unique per session - each client-AP connection generates a fresh PTK even with the same password. This means capturing one client’s traffic doesn’t help decrypt another’s.

WPA2 Weakness: Handshake Capture + Offline Brute Force

# Capture handshake (authorized testing only)
airmon-ng start wlan0
airodump-ng wlan0mon --bssid [AP_MAC] -c [channel] -w capture

# Deauth a client to force handshake re-capture
aireplay-ng -0 1 -a [AP_MAC] -c [Client_MAC] wlan0mon

# Brute-force offline with hashcat (GPU-accelerated)
hashcat -m 22000 capture.hc22000 wordlist.txt

The attack works because:

1. Attacker captures the 4-way handshake (just needs to observe the air)
2. Guesses password → computes PMK → derives PTK → checks MIC against captured MIC
3. GPU acceleration: ~1 million PMK guesses/second on mid-range GPU

Defence: Use a long (20+ char), random passphrase that’s not in any wordlist.

---

WPA3 - Next Generation

WPA3 (2018) fixes the offline brute-force vulnerability.

WPA3-Personal: SAE (Simultaneous Authentication of Equals)

Replaces the PSK handshake with Dragonfly - a zero-knowledge proof protocol:

• Even if an attacker captures the handshake, they cannot perform offline dictionary attacks - each guess requires a live exchange with the AP (online brute force only, easily rate-limited)
• Provides Forward Secrecy: capturing traffic now can’t be decrypted later even if the password is eventually revealed

WPA3-Enterprise

• Mandates Protected Management Frames (PMF) - prevents deauth attacks (attackers could kick clients off WPA2 networks)
• Optional 192-bit security mode for government/sensitive environments (AES-256-GCMP, ECDH P-384)

---

802.1X - Port-Based Network Access Control

802.1X separates “connecting to a port” from “being allowed to use the network.” No traffic flows until authentication completes.

Three Parties

[Supplicant]          [Authenticator]          [Authentication Server]
 (client device)       (AP or switch)            (RADIUS server)
      │                     │                          │
      │←── EAPOL start ────→│                          │
      │                     │──── RADIUS request ─────→│
      │                     │←── RADIUS challenge ─────│
      │←── EAP challenge ───│                          │
      │── EAP response ────→│──── RADIUS response ────→│
      │                     │←── RADIUS Accept ────────│
      │←── EAP Success ─────│                          │
      │                     │  [port unblocked]         │

• Supplicant: wpa_supplicant (Linux), Windows built-in 802.1X client
• Authenticator: Enterprise AP or managed switch (just forwards EAP, makes no auth decisions)
• Authentication Server: RADIUS (FreeRADIUS, Cisco ISE, Microsoft NPS)

EAP Methods Compared

Method	What client presents	What server presents	Security
EAP-MD5	Password hash	Nothing	❌ Weak - no mutual auth
EAP-PEAP	Username + password (inside TLS tunnel)	Certificate	✅ Good, widely supported
EAP-TTLS	Various (inside TLS tunnel)	Certificate	✅ Good, flexible
EAP-TLS	Certificate	Certificate	✅✅ Best - mutual cert auth

EAP-TLS: The Gold Standard

Client                    AP                    RADIUS Server
  │── cert + TLS ────────→│──────────────────────→│
  │                       │←─ server cert verified─│
  │ verifies server cert  │                        │
  │←──────────────────────│←── Access Accept ──────│
  │  [network access granted]

Requirements for EAP-TLS:

• Client certificates issued by an internal CA (and distributed to all devices via MDM)
• CA certificate distributed to RADIUS server
• Private keys protected - ideally bound to TPM

Tip

EAP-TLS + TPM binding = client cert stored in hardware. Even if a laptop is stolen, the private key can’t be extracted, and the certificate can’t be used on another machine.

/etc/wpa_supplicant/wpa_supplicant.conf

# Configure wpa_supplicant for EAP-TLS (Linux)
network={
    ssid="CorpNetwork"
    key_mgmt=WPA-EAP
    eap=TLS
    identity="[email protected]"
    ca_cert="/etc/ssl/certs/corp-ca.crt"
    client_cert="/etc/ssl/certs/client.crt"
    private_key="/etc/ssl/private/client.key"
}

---

Wireless Hardening - Decision Tree

Do you need wireless for an org?
│
├── Yes, many users, IT managed
│   └── WPA2-Enterprise or WPA3-Enterprise (802.1X + RADIUS + EAP-TLS)
│
├── Yes, small team, simple setup
│   └── WPA2-Personal (AES-CCMP, 20+ character random passphrase)
│       + Disable WPS
│       + Unique non-identifying SSID
│
└── Personal/Home
    └── WPA3-Personal (SAE) if router supports it
        WPA2-Personal otherwise
        Change default router credentials
        Disable WPS
        Enable router firewall
        Guest network for IoT/visitors

---

Packet Capture on Wireless

# Put wireless interface into monitor mode
sudo airmon-ng start wlan0           # creates wlan0mon

# Scan for networks
sudo airodump-ng wlan0mon

# Capture packets from a specific AP
sudo airodump-ng wlan0mon \
  --bssid AA:BB:CC:DD:EE:FF \
  -c 6 \
  -w /tmp/capture

# Open in Wireshark (set WPA passphrase in Edit → Preferences → Protocols → IEEE 802.11)
wireshark /tmp/capture-01.cap