The chapter title says it all — we’re diving into WPA3 and OWE. As you probably know, wireless frames can be captured by anyone within range with the right tools. That’s why strong encryption and secure key exchange processes are essential. Wi-Fi security has to keep evolving: algorithms improve, key lengths get longer, identity checks get stronger. After all, the air is an open medium — there are no walls protecting our data.
I feel like I’m starting to sound like Tom Carpenter himself (co-author of the CWSP book), but this is serious business. In this chapter, we explore WPA3 — the latest Wi-Fi security certification — along with OWE (Opportunistic Wireless Encryption), which brings encryption to open networks without passwords.
So why do we need WPA3? Mainly to solve two major weaknesses: the risk of offline dictionary attacks, and the vulnerability exposed by KRACK (Key Reinstallation Attack). While KRACK can be patched in WPA2, many older or unmanaged clients — especially in the IoT world — still haven’t been updated. I’d consider updates from 2018 or later as safe, but it’s always better to verify.
Let’s first unpack KRACK — an attack that targets the WPA2 4-way handshake itself and can let an attacker decrypt sensitive information. Even if you’re using WPA2 with AES, you could still be vulnerable under the right (or wrong) conditions. Understanding how KRACK works sets the stage for understanding why WPA3 matters — and how it protects us going forward.
KRACK and the 4-way handshake
The 4-way handshake is a process used in Wi-Fi to confirm that both the client and the access point (AP) possess the correct credentials and to negotiate a fresh encryption key for encrypting subsequent traffic. The handshake involves four messages:
- Message 1: The AP sends an ANonce (a random number) to the client.
- Message 2: The client uses the ANonce and its own SNonce to generate a Pairwise Transient Key (PTK) and sends the SNonce to the AP.
- Message 3: The AP sends a message to the client, including a an encrypted GTK, and a Message Integrity Code (MIC) to confirm the PTK. Based on this confirmation, the client installs the PTK.
- Message 4: The client sends an acknowledgment to the AP.
In a KRACK attack, the adversary manipulates and replays message 3 of the 4-way handshake. This causes the client to reinstall the encryption key, resetting the nonce and replay counter. This reinstallation allows the attacker to decrypt and manipulate packets.
When a key is reinstalled, the associated parameters, such as the incremental transmit packet number (nonce) and receive replay counter, are reset to their initial values. This reset allows the attacker to:
- Replay Packets: By reusing the same nonce, the attacker can replay packets, making it possible to inject malicious data into the network traffic.
- Decrypt Traffic: The reuse of nonces means that the same keystream is used to encrypt multiple packets. If an attacker knows the content of one packet, they can derive the keystream and use it to decrypt other packets encrypted with the same nonce.
- Forge Packets: In some cases, nonce reuse allows attackers to forge packets, further compromising the integrity of the network.
If devices remain vulnerable to KRACK attacks, the consequences can be severe:
- Data Theft: Attackers can intercept and decrypt sensitive information transmitted over the network.
- Data Manipulation: Attackers can inject malicious data, such as ransomware or malware, into the network traffic.
- Privacy Breaches: Personal information, including login credentials and private communications, can be exposed.
Ensuring that all devices are updated and using the latest security protocols is crucial to maintaining the integrity and security of Wi-Fi networks.
How can you protect against KRACK?
KRACK was disclosed in 2017, and most vendors quickly released patches. The issue lies in how some clients handled message 3 of the 4-way handshake: they would reinstall the same key when this message was replayed, resetting critical counters used in encryption. Patches ensure that once the key is installed, it can’t be reinstalled — even if message 3 is received again.
Although it’s mainly a client-side problem, access points can still play a role. Some APs can detect suspicious replay behavior and even block these frames, depending on the vendor. Even if the AP isn’t vulnerable itself, it can act as an extra line of defense by monitoring what’s happening over the air.
Another layer of protection is Protected Management Frames (PMF). KRACK can be launched either by replaying message 3 or by sending spoofed deauth/disassoc frames to force a reauthentication. If PMF is enforced, those spoofed management frames won’t get through — effectively shutting down one of the two paths for the attack.
The full structural fix arrives with WPA3. PMF is mandatory, and protocol improvements prevent key reinstallations altogether. WPA3 also introduces Forward Secrecy, meaning each session gets its own encryption keys. So even if a key somehow gets compromised, it can’t be used to decrypt past or future sessions.
WPA3-Enterprise inherits all of this, and optionally supports 192-bit encryption, adding even more resilience — making it really hard to KRACK 😉
WPA3-Personal
WPA3-Personal comes in two modes: WPA3-SAE transition mode and strict (WPA3 only) mode. Transition mode allows legacy WPA2-PSK clients to connect to a WPA3-enabled SSID using the same passphrase, which is handy during migration. But keep in mind — PMF (Protected Management Frames) is only mandatory for WPA3 clients. In transition mode, an attacker with the passphrase could still decrypt WPA2 sessions, but not WPA3 ones. Why? Because WPA3-SAE doesn’t derive the PMK directly from the PSK anymore. The passphrase is still in play, but it’s only used as input to a secure authentication process — not to build the encryption key itself.
Instead of a direct PSK-to-PMK translation like in WPA2, SAE uses a secure Diffie-Hellman exchange backed by elliptic curve cryptography. When a client and AP start the handshake, they each send a “Commit” message, which includes a scalar and finite field element. These values are derived from a hashed version of the passphrase — the so-called password element — combined with elliptic curve group parameters (like Group 19 for 256-bit ECC). These parameters are visible in the air, but they don’t expose anything useful, even if someone knows the passphrase. That’s because the password element is hashed and then used in computations that are practically irreversible.
Once both sides have exchanged Commit messages, they do the math: each party mixes its own private secret with the other party’s public values to compute a shared key. If both had the correct password element, they end up with the same result. This becomes the Pairwise Master Key (PMK). The Confirm message follows, just to make sure both parties derived the same result, and mutual authentication is completed.
The cool part is this: each SAE handshake is unique, even if you reuse the same passphrase. So there’s no static key sitting in memory that an attacker could lift and use across sessions. And since it’s a true key exchange — not just proof of knowing the PSK — it offers forward secrecy. Even if an attacker grabs the PMK from a device somehow, it can’t be used to decrypt older or future sessions.
Bottom line: SAE protects against offline dictionary attacks, removes the need for PSK-based encryption, and builds a fresh, secure key for every session. So even if someone gets the passphrase, they’re not getting in without doing the math — and the math doesn’t work without the right secrets on both ends.
Above visual explains it perfectly for me. Note that it is simplified and does not say how the scalar and finite field play a role in relation to the secrets or hashed password. But the use of colors Also go check out this entertaining presentation by Alan Blake and Peter Mackenzie on Wireless Cryptography and Key Distribution.
Another great resource on WPA3-Personal that I strongly suggest reading: WPA3 Personal – Simultaneous Authentication of Equals(SAE) by Suraj Kumar.
WPA3-Enterprise
WPA3-Enterprise also comes in two flavors: standard mode and 192-bit security mode. The standard mode is, in practice, quite similar to WPA2-Enterprise with PMF (Protected Management Frames) enforced. Over-the-air encryption is still done using AES-128 CCMP, which includes built-in CBC-MAC for integrity. The cipher suite used during authentication still depends on the selected EAP type. I won’t go down the rabbit hole of every EAP method, but let’s just say EAP-TLS remains a top recommendation.
As with WPA3-Personal, there’s a transition mode to support WPA2-Enterprise clients connecting to the same SSID. That means you can run mixed environments during migration, with stronger security for capable clients while still supporting legacy ones.
The big leap comes with WPA3-Enterprise 192-bit mode. This isn’t just a stronger encryption setting — it enforces a full set of hardened cryptographic requirements. For one, it requires the use of certificate-based authentication via EAP-TLS. You can’t mix in PEAP or other methods here; it’s TLS or nothing. This mode mandates consistency and strength across all crypto components:
- AES-GCM-256 for encryption and authentication
- HMAC-SHA384 for hashing
- ECDH-P384 and ECDSA-P384 for key exchange and authentication
The only permitted cipher suites under these constraints are:
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
The “192-bit” label refers to the effective security strength across the cryptographic stack, not just the AES key size. It’s a significant jump from anything allowed in WPA2, and even a step above regular WPA3-Enterprise.
One important consideration: this level of security comes with a performance cost. Devices — including access points — need to support these requirements in both hardware and software. So if you’re planning to roll out WPA3-Enterprise 192-bit mode, make sure your endpoints are compatible, and do proper testing. That means association, roaming, reconnecting, and authentication flow. You don’t want to find out something breaks halfway through production.
OWE (Enhanced Open)
Alongside WPA3, the Wi-Fi Alliance also introduced a much-needed improvement for open networks: Opportunistic Wireless Encryption (OWE), often called Enhanced Open. Its goal is simple — not to secure access, but to give you privacy on networks that don’t require a password. That means everyone still gets in, but no one can passively eavesdrop on your traffic anymore. So no, OWE doesn’t protect you against malicious actors on the same network, but it does protect your data from being sniffed out of the air by someone nearby.
OWE is similar in spirit to SAE, but it happens at a different stage. In SAE (used in WPA3-Personal), the key exchange happens during authentication. But with OWE, there is no authentication step — remember, it’s still an open network. Instead, the Diffie-Hellman key exchange is slipped into the Association Request and Response frames. A new information element is included, which contains the Diffie-Hellman group (often an elliptic curve group) and the public key. Based on this Public key information, both client and AP can generate a shared secret through the use of their private key.
I asked my good friend MS Copilot to explain this process, which helped me get my head around how AP and client get to the same value. This is still a simplification and is not asked in detail on the exam, but I found it interesting enough to put it here. Here’s how both devices end up with the same shared secret:
- Key Pair Generation:
- The client generates a private key a and a corresponding public key A = g^a mod p.
- The AP generates a private key b and a corresponding public key B = g^b mod p.
- Public Key Exchange:
- The client sends its public key A to the AP.
- The AP sends its public key B to the client.
- Shared Secret Calculation:
- The client uses its private key aa and the AP’s public key B to compute the shared secret: s = B^a mod p.
- The AP uses its private key b and the client’s public key A to compute the shared secret: s = A^b mod p.
Parameter p:
- p is a large prime number. It defines the finite field over which the Diffie-Hellman key exchange is performed. The size of p (in bits) determines the security level of the key exchange.
- The prime number p is publicly known and shared between the client and the access point (AP).
Parameter g:
- g is a generator or base. It is a primitive root modulo p, meaning that g is a number such that its powers generate all the integers from 1 to p−1 modulo p.
- Like p, the generator g is also publicly known and shared between the client and the AP.
And because the private keys a and b are not transmitted, an eavesdropper does not have the information to derive the shared secret.
As an added bonus, OWE’s cryptographic processes implement forward secrecy, providing extra security as each session is uniquely encrypted. Even when a key gets compromised, it can’t be used for past or future sessions.
Conclusion
WPA3 brings the long-overdue overhaul that WPA2 needed — not only by patching known vulnerabilities like KRACK, but by introducing solid cryptographic improvements like forward secrecy and more robust key handling. Whether it’s WPA3-Personal with SAE or WPA3-Enterprise with its 192-bit mode, the improvements go well beyond just longer keys. And even open networks get a privacy boost with OWE. Still, the benefits of WPA3 can only be realized if clients and infrastructure support them — so before jumping in, map out your environment and test thoroughly. These protocols raise the bar, but only when implemented end to end.
Source(s):
Carpenter, T., et al. (2023). CWSP-207: Certified Wireless Security Professional Study Guide (1st ed.). Durham NC, USA: Certitrek Publishing
Vanhoef, M. (2017) Key Reinstallation Attacks. Retrieved June 18, 2025, from https://krackattacks.com
Kumar, S. (2024) WPA3-Personal – Simultaneous Authentication of Equals (SAE). Retrieved June 19, 2025, from https://arista.my.site.com/AristaCommunity/s/article/WPA3-Personal-Simultaneous-Authentication-of-Equals-SAE