WiFi Security

WPA3, announced by the Wi-Fi Alliance in January 2018, represents a significant advancement in wireless security. While WPA2 remains secure when properly configured, it has fundamental architectural limitations—particularly around password-based authentication and the vulnerability of captured handshakes to offline attack.

WPA3 addresses these issues through new cryptographic protocols that provide:

• Forward secrecy: Compromising the password cannot decrypt past sessions
• Resistance to offline dictionary attacks: Each authentication attempt requires interaction
• Protected management frames: Mandatory, not optional as in WPA2
• Enhanced open networks: Encryption without passwords via OWE
• Stronger cryptographic suites: 192-bit security mode for enterprise

WPA3's design was motivated by specific weaknesses in WPA2 that couldn't be addressed through patches:

1. Offline Dictionary Attacks

WPA2-PSK's 4-way handshake provides everything needed for offline password cracking:

• Client and AP nonces are transmitted in plaintext
• MIC in Message 2 can be verified against password candidates
• Attacker captures handshake once, then attacks for years with infinite compute

This means a weak password is vulnerable forever once the handshake is captured. With modern GPUs testing billions of candidates per second, any password below ~80 bits of entropy is at risk.

2. No Forward Secrecy

In WPA2, all session keys derive from the PMK (which derives from the password):

PMK = f(password, SSID)
PTK = f(PMK, nonces, addresses)
Traffic Keys = f(PTK)

If an attacker:

1. Captures encrypted WiFi traffic for months
2. Later obtains the password (social engineering, breach, brute force)
3. Now computes PMK, then PTK for each captured session
4. Decrypts all historically captured traffic

This 'harvest now, decrypt later' attack is particularly concerning for high-value targets.

3. Open Network Exposure

WPA2 provides no encryption for open (passwordless) networks. Coffee shop WiFi transmits all traffic in plaintext, enabling:

• Passive eavesdropping on all unencrypted protocols
• Session hijacking via captured cookies
• Content injection into HTTP traffic

HTTPS mitigates this somewhat, but not all traffic is TLS-protected.

Simultaneous Authentication of Equals (SAE) replaces WPA2's 4-way handshake for PSK authentication. SAE is a variant of the Dragonfly Key Exchange, a password-authenticated key exchange (PAKE) protocol standardized in RFC 7664.

What Makes SAE Different:

1. Zero-Knowledge Proof: Neither party reveals information about the password during the exchange. An eavesdropper learns nothing about the password from the transcript.

2. Resistance to Offline Attack: Unlike WPA2's handshake, SAE transcripts cannot be used for offline dictionary attacks. Each password guess requires completing an interactive protocol with a party that knows the password.

3. Forward Secrecy: SAE generates a fresh shared secret via ephemeral elliptic curve Diffie-Hellman. Even if the password is later compromised, past sessions remain protected.

4. Mutual Authentication: Both parties simultaneously prove password knowledge without either trusting the other first (hence 'Simultaneous' and 'Equals').

SAE High-Level Flow:

┌─────────┐                           ┌─────────┐
│  Client │                           │   AP    │
└────┬────┘                           └────┬────┘
     │                                     │
     │  ──────── SAE Commit ──────────►    │  (scalar, element)
     │  ◄─────── SAE Commit ───────────    │  (scalar, element)
     │                                     │
     │    [Both derive shared secret]      │
     │                                     │
     │  ──────── SAE Confirm ─────────►    │  (confirm value)
     │  ◄─────── SAE Confirm ──────────    │  (confirm value)
     │                                     │
     │    [Both verify peer's confirm]     │
     │                                     │
     │         [PMK established]           │
     │                                     │
     │  ──────── 4-Way Handshake ─────►    │  (derive PTK)
     │                                     │

SAE produces a PMK that then feeds into the standard 4-way handshake for PTK derivation. The difference: the PMK now incorporates ephemeral secrets that an eavesdropper cannot obtain.

Dragonfly uses elliptic curve cryptography to enable password-authenticated key agreement. Understanding its operation requires some elliptic curve concepts:

Elliptic Curve Background:

• An elliptic curve group consists of points satisfying y² = x³ + ax + b
• Points can be 'added' via a geometric construction
• Scalar multiplication: nP = P + P + ... + P (n times)
• Given nP, recovering n is the Discrete Logarithm Problem (computationally hard)

Password Element Generation:

Both parties derive a point P on the elliptic curve from the password:

P = H2C(password, MAC1, MAC2)
  = Hash-to-Curve(password || max(MAC1,MAC2) || min(MAC1,MAC2))

Multiple methods exist for hash-to-curve (hunting-and-pecking, SSWU). The key property: P is derived deterministically from the password and MACs, but an attacker cannot reverse-engineer the password from P.

Commit Phase:

Each party generates ephemeral secrets and computes a commit:

Client:                                  AP:
  rand ← random integer                    rand' ← random integer
  mask ← random integer                    mask' ← random integer
  
  scalar = (rand + mask) mod q             scalar' = (rand' + mask') mod q
  Element = mask × P (point multiplication) Element' = mask' × P
  
  Send: (scalar, Element)                  Send: (scalar', Element')

The scalar and element commitments reveal nothing about the password because:

• rand and mask are random (information-theoretically hidden)
• Element is a random multiple of P
• Without knowing P (requires password), the relation is unrecoverable

Key Derivation:

After exchanging commits, each party computes:

Client computes:
  ss = rand × (scalar' × P - Element')
     = rand × ((rand' + mask') × P - mask' × P)
     = rand × (rand' × P)
     = rand × rand' × P

AP computes:
  ss = rand' × (scalar × P - Element)
     = rand' × (rand × P)
     = rand' × rand × P  (same point!)

PMK = KDF(ss, "SAE key derivation")

Both arrive at the same shared secret (rand × rand' × P) without either party knowing the other's ephemeral values directly.

Confirm Phase:

To ensure both parties computed the same PMK (proving password agreement):

Confirm = HMAC(KCK, scalar || peer_scalar || Element || peer_Element || MAC)

Each party verifies the peer's confirm matches the expected value. If the passwords differ, the shared secrets differ, KCKs differ, and confirms don't match—authentication fails with no password information leaked.

Security Properties:

Forward secrecy (sometimes called perfect forward secrecy or PFS) is a property of key exchange protocols that ensures past session keys cannot be compromised even if long-term secrets are later exposed.

WPA2 Without Forward Secrecy:

Password leaked → PMK computed → All captured PTKs derivable → All traffic decrypted

Timeline:
  Year 1: Traffic captured (encrypted, stored)
  Year 2: Password leaked via breach
  Year 3: Attacker decrypts all Year 1 traffic

This 'harvest now, decrypt later' attack is especially concerning because:

• Storage is cheap; attackers can capture for years
• Passwords are often reused or leaked in breaches
• High-value targets (executives, activists) face nation-state adversaries with patience

WPA3 With Forward Secrecy:

Password leaked → PMK computable BUT → 
  Ephemeral secrets (rand, rand') not stored → 
  ss unrecoverable → 
  Session keys unrecoverable → 
  Past traffic remains encrypted

Timeline:
  Year 1: Traffic captured (encrypted, ephemeral secrets forgotten)
  Year 2: Password leaked via breach
  Year 3: Attacker can only compromise NEW sessions (if password not changed)

Technical Implementation:

Forward secrecy in SAE comes from the Diffie-Hellman core:

Shared secret = rand × rand' × P

Where:

• rand is client's ephemeral secret (never stored long-term)
• rand' is AP's ephemeral secret (never stored long-term)
• P is the password element (derivable from password)

Even with P known (password compromised), recovering the shared secret requires solving:

Given: A = rand × P, B = rand' × P
Find: rand × rand' × P

This is the Computational Diffie-Hellman (CDH) problem—believed hard.

Key Storage Implications:

For forward secrecy to hold, implementations must:

1. Generate fresh rand for each authentication
2. Never log or store ephemeral secrets
3. Securely erase memory after session establishment
4. Not derive long-term keys from session keys

Opportunistic Wireless Encryption (OWE), defined in RFC 8110, addresses a long-standing problem: open networks (hotels, coffee shops, airports) transmit all traffic unencrypted, enabling trivial eavesdropping.

The Problem with Open Networks:

Traditional 'captive portal' networks use no encryption:

• User associates with open SSID
• Redirected to login page (HTTPS)
• After authentication, traffic flows unencrypted
• Anyone within range can capture all non-TLS traffic

Even with HTTPS for sensitive operations, DNS queries, HTTP traffic, and some app communications expose user behavior.

OWE Solution:

OWE uses unauthenticated Diffie-Hellman to establish encryption without a password:

┌─────────┐                           ┌─────────┐
│  Client │                           │   AP    │
└────┬────┘                           └────┬────┘
     │                                     │
     │   Association Request               │
     │   (OWE DH Public Key)               │
     │  ─────────────────────────────►     │
     │                                     │
     │   Association Response              │
     │   (OWE DH Public Key)               │
     │  ◄─────────────────────────────     │
     │                                     │
     │   [Both compute shared secret]      │
     │   [Derive PMK from DH secret]       │
     │                                     │
     │  ──────── 4-Way Handshake ──────    │
     │                                     │

How It Works:

1. AP advertises OWE capability in beacon (RSN IE with OWE AKM)
2. Client generates ephemeral ECDH key pair, sends public key in Association
3. AP generates ephemeral ECDH key pair, sends public key in Association Response
4. Both compute: PMK = HKDF(g^(ab), "OWE Key Generation")
5. Standard 4-way handshake derives session keys
6. All traffic encrypted with AES-CCMP or GCMP

WPA3-Enterprise introduces an optional 192-bit security mode aligned with the Commercial National Security Algorithm (CNSA) suite, designed for environments requiring the highest level of cryptographic protection.

CNSA Suite Components:

The 192-bit mode ensures consistent security strength across all cryptographic operations. In WPA2, mixing 128-bit and 256-bit algorithms created potential weak points.

GCMP: Galois/Counter Mode Protocol

WPA3 introduces GCMP as an alternative to CCMP:

CCMP: AES-CTR (encryption) + CBC-MAC (authentication)
GCMP: AES-CTR (encryption) + GHASH (authentication)

GCMP Advantages:

• GHASH is parallelizable; faster on modern hardware
• Single-pass authenticated encryption
• Smaller authentication overhead
• Better suited for high-throughput links

GCMP-256 Specifics:

• 256-bit key for AES
• 128-bit authentication tag (vs 64-bit for CCMP-128)
• Provides 128-bit authentication security (birthday bound)

EAP-TLS with TLS 1.3:

WPA3-Enterprise 192-bit mandates EAP-TLS using TLS 1.3:

• Removes support for insecure cipher suites
• Provides forward secrecy via ephemeral ECDHE
• Faster handshake (1-RTT vs 2-RTT)
• Server certificate authentication mandatory

In April 2019, researchers Mathy Vanhoef and Eyal Ronen (who previously discovered KRACK) disclosed Dragonblood—a set of vulnerabilities in WPA3 implementations and some aspects of the SAE protocol.

Vulnerability Categories:

1. Transition Mode Downgrade

WPA3 transition mode allows both WPA2 and WPA3 clients:

• SSID advertises both WPA2-PSK and WPA3-SAE
• Attacker creates rogue AP advertising only WPA2
• WPA3-capable clients downgrade to WPA2
• Handshake captured for offline dictionary attack

Mitigation: Use WPA3-only mode when all clients support it.

2. Security Group Downgrade

SAE supports multiple elliptic curve groups (P-256, P-384, etc.):

• Attacker forces negotiation of weaker group
• Some groups more vulnerable to side-channel attacks
• Weaker groups reduce dictionary attack cost

Mitigation: Configure AP to only accept strong groups.

3. Timing Side-Channel Attacks

The hash-to-curve operation in SAE (converting password to curve point):

• Different passwords take different time to process
• Timing differences measurable over network
• Can narrow dictionary attack space

Two variants discovered:

• CVE-2019-9494: Timing leak in hash-to-curve (Brainpool curves)
• CVE-2019-9495: Cache-timing attack on hash-to-curve

Mitigation: Use constant-time implementations; prefer SSWU over hunting-and-pecking.

4. Denial of Service

SAE commit phase is computationally expensive:

• Each commit requires elliptic curve operations
• Attacker sends many forged commits
• AP's CPU saturated processing fake commits
• Legitimate clients denied service

Mitigation: Anti-clogging tokens (cookies) before expensive computation.

WPA3 represents a significant security evolution, addressing fundamental limitations in WPA2 while maintaining practical deployability. Its core innovations—SAE for password-based authentication and OWE for open networks—solve problems that no amount of WPA2 configuration could address.

Deployment Recommendations:

1. New deployments: Use WPA3-only when client support permits
2. Mixed environments: WPA3-transition mode with awareness of downgrade risks
3. Enterprise: Consider 192-bit mode for sensitive environments
4. Open networks: Migrate to OWE from traditional open
5. All deployments: Ensure firmware updated to address Dragonblood issues

What's Next:

The final page covers Security Best Practices—a comprehensive guide to securing wireless networks regardless of protocol generation. This includes defense-in-depth strategies, monitoring, and operational practices that complement the cryptographic protections we've discussed.