After Wi-Fi Alliance (WFA) introduced “Wi-Fi Protected Access” version 3 (WPA3) in late June of 2018 , vendors are pretty busy to adopt this security enhancement, which will become mandatory for WFA certifications in the future. This post introduces the changes in regards to WPA2, which is also undergoing some more robustness and consistency tests within the WPA3 program. Another post on the enhancements for unencrypted Wi-Fi networks (open SSIDs), can be found here. Now, let’s start with WPA3.
Changes to WPA2
WPA2 Connection Establishment
Before we get to the changes of WPA3, we need to know how (secure) connections are established in WPA2. The following flow graph shows the frames that are exchanged between a client (STA) and an Access Point (AP). If you want to get more details on the EAP-Key messages, I’ve got an older post about the EAP 4-Way Handshake.
After EAP-Key message number 4, client and AP are ready to exchange data securely. As WPA3 makes changes to the authentication frames, we should take a detailed look at the two exchanged authentication frames in WPA2:
In contrast to WPA2, WPA3 is only allowed to use the “Advanced Encryption Standard” (AES) and no longer legacy protocols like the “Temporal Key Integrity Protocol” (TKIP) or “Wired Equivalent Privacy” (WEP). Anyone, who was keen on security before and also wants fast Wi-Fi transmissions, has gotten rid of TKIP and WEP already, since 11n and 11ac only offer high throughput with AES.
Protected Management Frames (PMF)
All WPA3 devices need to use PMF, so it is activated implicitly as soon as the user selects either WPA3-Personal or WPA3-Enterprise for an SSID. PMF delivers a protection against forging management frames, e.g. an attacker can disassociate any user by claiming he is the Access Point (AP) that the client is currently connected to. Although it has been around for a longer time, even as a requirement for WFA 802.11ac (VHT) certification, the market adoption was rather low. A more detailed look into this topic is given by my previous blog post on Protected Management Frames (802.11w). WPA3 uses the “Management Frame Protection Required” mode with SHA-256  for Hashes.
The “Pre-Shared Key” (PSK) method of WPA2 is replaced by “Simultaneous Authentication of Equals” (SAE), which offers a more robust password-based authentication. The passphrase itself is no longer used for key derivation (keyword: “Pairwise Master Key” (PMK)), the key derivation is based on “Elliptic Curve Cryptography” (ECC) or a special form of ECC with integer numbers only called “Finite Field” instead.
Simultaneous Authentication of Equals (SAE)
In the classic scenario, a client (STA) connects to an access point and the roles of supplicant (STA) and authenticator (AP) are clear. This concept doesn’t work for a mesh scenario, where two APs (two equals) are trying to establish a connection between each other and each one could have the role of supplicant or authenticator. Even worse, both APs could discover each other simultaneously and start a key handshake immediately, which could mess up their internal state machine. For 802.11s, the mesh Amendment for the 802.11 standard, a new connection method called “Simultaneous Authentication of Equals” got rid of this problem, so that it is now possible to authenticate each other at the same time and independently of any role.
SAE also offers a much better method of establishing a secure connection over an unsecure medium – the Diffie-Hellman (DH) key exchange  in combination with a Prime Modulus Group or an Elliptic Curve Group. Since the later is made mandatory for WPA3-Personal, the following explanations refer to it. There already exist some predefined curves as DH groups 19, 20 and 21 (group order r) with given prime numbers p of certain (bit-)lengths. For example DH19 refers to the 256-bit elliptic curve defined as NIST p-256  with the prime number p = 2^(256) – 2^(224) + 2(192) + 2(96) – 1 = 1,157920892×10⁷⁷ and the elliptic curve equation: y2 = x3 – 3x + b, where b is given by a certain 384 bit number.
Establishing a Pairwise Master Key in SAE with ECC
The following paragraphs require knowledge about hash functions, scalars, points/vectors and operations on them. Please jump to the next section, called “WPA3-Personal Connection Establishment”, in case you are not interested in this detailed explanation.
SAE is build upon the Dragonfly Key Exchange, which is described in , this text refers to it with some simplifications. We keep the mesh context with two APs that want to connect to each other, but the same concept applies to an AP-STA connection in WPA3-Personal. Both APs start with a hashed presentation of the entered/stored passphrase. This hash-function H concatenates (symbolized by “|”), their identities (MACs), the passphrase and an integer value i. The sequence of the elements, that are put into this hash-function is important and as SAE allows simultaneous authentication, the sequence is defined by a greater/smaller comparison of the involved AP-MACs, so that both parties use the same sequence of inputs for the hashed password representation:
if AP1-MAC > AP2-MAC: hashed_password = H(AP1-MAC | AP2-MAC | Passphrase | i) else: hashed_password = H(AP2-MAC | AP1-MAC | Passphrase | i)
The hashed password is then transformed into a point represented by x, y coordinates. All we need is a “Key Derivation Function” (KDF) that stretches a string to a certain length len (length of prime p) and performs modulo p-1 on the result. After that, y is calculated by entering the calculated x in the equation f(x) of the elliptic curve and getting the square root (sqrt) of the result.
x = ((KDF(hashed_password, len)) mod (p-1)) + 1 y = sqrt(f(x)) P = (x, y)
If the generated x, y coordinates do not match a point on the elliptic curve, the integer i is increased by one and the procedure is started again. Otherwise, each party chooses two random numbers, private and mask to calculate two new values, a new point new_point and a scalar scal like this (r is the order of the elliptic curve DH group):
scal = (private + mask) mod r new_point = inverse(mask • P)
Note that the new_point includes x, y coordinates, whereas a scalar is a single number. A scalar and an elliptic curve point can be multiplied (•), please see this wikipedia article [6, wikipedia article] for more details about scalar multiplications of elliptic curve points.
Both parties send their scal and elem to the other one, so that each party has scal(AP1), scal(AP2), new_point(AP1) and new_point(AP2). This material is used to calculate a new point K, which is the new shared secret between AP1 and AP2.
AP1: K = private(AP1) • (scal(AP2) • P(x, y) ◊ new_point(AP2)) = private(AP1) • private(AP2) • P(x, y) AP2: K = private(AP2) • (scal(AP1) • P(x, y) ◊ new_point(AP1)) = private(AP2) • private(AP1) • P(x, y)
The ◊ symbol represents the point operation, which in case of elliptic curve is an addition of two points that result in a new point on the curve. Again, please see this wikipedia article [6, wikipedia article] for more details on additions of two elliptic curve points.
Since scal(APx) • P(x, y) is another point, the scalar multiplied point of e.g. scal(AP2) • P(x, y) is added to the new_point(AP2) and afterwards multiplied by private(AP1). As both parties need to confirm that their calculation of K is correct, a bijective function F is required that maps a point K to a single number again, which is then used to create a token for each party:
k = F(K) tok(AP1) = H(k | scal(AP1) | scal(AP2) | new_point(AP1) | F(new_point(AP2)) | AP1-MAC) tok(AP2) = H(k | scal(AP2) | scal(AP1) | new_point(AP2) | F(new_point(AP1)) | AP2-MAC)
Note that tok(AP1) ≠ tok(AP2) as hash functions with different sequences of input values result in different values. Nonetheless, both parties are able to verify the token of the other party by calculating the other token themselves and compare it to the one they received. In case the tokens could be confirmed, the “Pairwise Master Key” (PMK) is calculated by the hash-function H as follows:
PMK = H(k | scal(AP1) + scal(AP2) mod r)
Important to know is, that this PMK is not based on the passphrase itself, but on scalars and points that were calculated with random numbers, which only used a hashed version of the passphrase. Each time these random numbers change, the PMK will be different and that brings us perfect forward secrecy.
With an established PMK, the “Personal Transition Key” (PTK) can be set up during the EAP 4-Way Handshake and secure data transmissions between AP and client are enabled.
Note: If you got the mathematical background to understand the further details of elliptic curves, there is a great blog post series by Andrea Corbellini, which explains it pretty well .
Offline-Dictionary: Although an attacker can sniff the scalars, it is infeasible to calculate private or mask and therefore is unable to use the transmitted tokens to check if a guessed passphrase is correct.
Active-Attack: Again, as private and mask are infeasible to calculate, an active attacker will fail to create a valid token. Furthermore, due to the discrete logarithm problem, calculations of P(x, y) with faked private and mask values are also infeasible. More details can be found in .
Side-Channel: As calculation can take different amount of power and/or time to calculate, the algorithm will always use a certain amount of iterations to create the hashed_password even if it found a point on the curve already. The fixed amount of iterations should at least be large enough, that it is possible to find a valid point without any extra iterations required.
WPA3-Personal Connection Establishment
The main difference to the WPA2 connection flow chart are the two extra authentication frames. This is the WPA3 connection flow chart with a detailed look at the authentication frames:
All four authentication frames for WPA3-Personal contain important information to calculate the PMK based on Elliptic Curve Cryptography (ECC). As mentioned in “Establishing a Pairwise Master Key (PMK) in SAE with ECC”, the station and the access point need to know the calculated scalar and point (Finite Field Element) of the other party. These information are shared in the first two authentication frames:
The last two authentication frames contain the token as confirmation.
If the confirmation information is correct, the association/connection of the station can continue.
Offline Dictionary Attacks and Key Recovery Resistance
WPA3-Personal prohibits offline dictionary attacks, where an attacker uses a dictionary of “passphrases” on a passively observed WPA3-Personal key exchange to obtain the correct passphrase. As shown above, ECC offers (perfect) forward secrecy of recorded network traffic, even if the attacker was able to obtain the correct passphrase, e.g. via social engineering, he can not decrypt other sessions as the passphrase is not part of the PMK anymore. Nonetheless, the attacker can access your network with an obtained passphrase.
Bruteforcing or Denial of Service (DoS) Attacks
Since offline dictionary attacks are mitigated, an attacker might move to bruteforcing the passphrase against the SSID. Furthermore, the use of ECC requires some calculation power on a device, which could be exploited by DoS attacks with multiple connection attempts. Both attacks are prohibited by WPA3-Personal due to an anti-clogging feature. As soon as an AP notices too many SAE connection requests, it will use tokens to limit the amount of simultaneous attempts and thus makes it harder to bruteforce or DoS.
As the password/passphrase is no longer part of the PMK, the complexity of it does no longer play an important role. Therefore, it is suitable to use passwords that are easy to enter and remember. However, you should still go for a complex enough password, so that an attacker is unable to guess your passphrase within a short amount of time. Although offline dictionary attacks are prevented, the access to your network with a guessed passphrase is still possible.
Adoption is key and WFA made sure that it is possible to deploy WPA3 as soon as possible by creating a transition mode. This mode allows WPA2 and WPA3 at the same time and on the same SSID. However, this makes the SSID only PMF optional and not PMF required and a hacker could still gain access on your network via WPA2 attacks.
Note: We found an issue within iOS 11.x and 12.0, that an iPhone/iPad does not connect to an SSID using this WPA3 transition mode. However, a Macbook with macOS 10.12 has no issues. Neither macOS nor iOS support WPA3 (yet), but at least the WPA2 connection should work. Apple has fixed this issue in iOS 12.2.
2nd Note: As Windows 10 with latest updates has “SAE” as an option for Wi-Fi security, we’ve seen Surface devices trying to connect with this option. Unfortunately, the shipped Marvell driver is not yet capable of SAE, so the client won’t connect to the SSID. Furthermore, in transition mode, the client won’t connect using WPA2-PSK as it tries to use SAE as default and even a manually configured profile for the SSID with WPA2-PSK selected doesn’t work.
Unfortunately, there is no big update for the enterprise world except an optional 192-bit security mode. In the mandatory version, WPA3-Enterprise is WPA2-Enterprise + “PMF optional/required” (both configuration options are valid) and nothing else. There is no use of SAE/ECC in WPA3-Enterprise and no standard support for fast roaming (802.11r).
Optional 192-bit security mode
Some sensitive security enterprises/governmental/military sites require a consistent use of network security. With the optional 192-bit security mode, WPA3-Enterprise makes sure that the AP, the RADIUS server and the client use (at least) 192-bit keys, so that there is no weak link in this setup. The WPA3-Enterprise 192-bit security mode uses 256-bit “Galois/Counter Mode Protocol” (GCMP-256) for authenticated encryption, 384-bit “Hashed Message Authentication Mode” (HMAC) with “Secure Hash Algorithm” (HMAC-SHA-384) for key derivation and confirmation, and “Elliptic Curve Diffie-Hellman” (ECDH) exchange and “Elliptic Curve Digital Signature Algorithm” (ECDSA) using a 384-bit elliptic curve for key establishment and authentication.
Note: The bad news is that all involved parties (access points, clients and RADIUS-server) need to support this 192-bit security mode, otherwise no connection can be established at all. Furthermore, you should keep in mind, that an 192-bit 802.1X SSID should also be separated/encapsulated from other traffic in your network. Otherwise, someone could identify the weakest “entrance” by looking for other, non-192-bit-mode SSIDs connected to the same network and attack them.
Maybe you heard of the so called KRACK-attacks by Mathy Vanhoef  that breaks WPA2 without obtaining the real key (Passphrase). You might expect that WPA3 will be secure since it is newer than WPA2 and released nearly one year after the KRACK-attacks were released, but that is a misconception. As the development of WPA3 started in 2012, long before the KRACK-attacks came to life, and rely on the same EAPoL 4-Way Handshake to exchange transmission keys, WPA3 could be attacked by KRACK as well. However, if you want to get a nice WFA WPA3 sticker on your device, WFA makes sure that your device is “KRACK-save”. Visit the link  for more information about the attack itself.
Mathy’s Analysis of WPA3
In April 2019, Mathy Vanhoef published a paper  on the WPA3-Personal part of WPA3 and also published security issues in EAP-pwd. Please note that EAP-pwd is not part of WPA3, but uses a similar method like SAE to connect to an enterprise network. He did not find any issues that compromise the security of SAE itself, but for some features that come-along with it. Please note that WPA3 itself is still considered secure and is a major update over WPA2. As it is still in its early phase of adoption, WFA will make sure that everything that can be done to mitigate the mentioned issues, will be done.
He was able to identify a side channel attack on the hostap implementation (commit 0eb34f8f2 from 2019-01-26) to leak enough information to compute the used password. Since the hostap is a very popular implementation to handle WPA security and is often used as a code reference for other implementations, this is a critical issue. To utilize this, an attacker needs to run a compromised application on the user device. Most Access Points do not allow any third party applications to be installed, but a user device like a smartphone could be attacked that way. Nonetheless, this issue can and will be fixed via software updates.
Furthermore, the WPA3 Transition Mode has the downside of using the same password for WPA2 and WPA3. Even if there are only WPA3 capable devices, that are required to be downwards compatible to WPA2, an attacker can spawn an evil twin AP with the same SSID with WPA2 only. A client device might then start to auto-connect using WPA2 to this evil twin AP. Although the client will notice that it has been tricked as soon as EAP message 3 arrives and the RSN element of the evil twin does not match the RSN elemt of the original network, a dictionary attack with the already gained information might be successful. Clients, once they connected to a (B)SSID via WPA3, should considering storing this key method and not use auto-connect if the same (B)SSID wants to use WPA2. The upcoming Android Q has implemented this (as of current BETA).
Additionally, the negotiation of the DH-group to be used can be manipulated to downgrade or upgrade the client to a lower or higher group than initially intended. However, all DH-groups 19 (mandatory), 20 (optional) and 21 (optional) are considered secure (at the moment). This issue could only be solved by changing the SAE protocol exchange in IEEE 802.11, which would break interoperability with current SAE implementations.
At last, the anti-clogging feature can be defeated if the attacker is able to replay the generated tokens to the AP. The severity of this issue can be mitigated by letting the SAE token/key calculation be run as a low-priority job, so that other jobs like data traffic is not that much affected. To resolve this issue, the SAE anti-clogging mechanism would need to be revised in IEEE 802.11, which would also break interoperability with current SAE implementations.
After several years of development, WPA3 improves the security for personal (PSK) networks tremendously but leaves a lot to desire for the enterprise sector.
The introduction of a transition mode is a nice way to let people install WPA3-Personal along with WPA2-Personal. On the one hand, WPA3-Personal can be implemented on existing hardware, which will drive vendor support, and on the other hand, users can use the transitional mode to deploy WPA3 on their network already and wait for client device or firmware upgrades in the meantime. As WPA3 will be mandatory for 802.11ax (High Efficiency WLAN), my guess is, that we will see a lot of WPA3 support with the next round of smartphone updates in 2019. One of the first client implementations available is the Google’s Pixel 3 (Plus) with Android Q BETA.
The mandatory part of WPA3-Enterprise should also be easy to implement since it is just WPA2-Enterprise together with PMF. For the optional 192-bit security mode, all devices require an upgrade and furthermore, network admins need to know how to configure this setup correctly.
For the future, it would be great to see more upgrades for the enterprise market, especially since “Fast Roaming” (802.11r) was left out of the current WPA3-“Standard” (for personal and enterprise networks).
Feel free to comment on this post, especially to correct any errors in this post.
 KRACK Attacks
2018-11-09: Elliptic Curve for DH19 is P-256 instead of P-384, link has been updated as well. Thank you Mathy Vanhoef for pointing that out.
2018-11-13: Added a second note regarding Microsoft Surface devices with SAE issues.
2019-01-10: Pictures updated with Wireshark v2.9.0
2019-01-25: Clarify that WPA3-Enterprise (without 192-bit mode) has the option of PMF optional or required.
2019-04-10: Added a paragraph on the Mathy’s new paper “Here be Dragons: A Security Analysis of WPA3’s SAE handshake”