WPA3 – Improving your WLAN security

Introduction

After Wi-Fi Alliance (WFA) introduced “Wi-Fi Protected Access” version 3 (WPA3) in late June of 2018 [1], 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.

WPA2_Connection_Graph
WPA2 Connection Flow Chart

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:

WPA2 Authentication Req + Text
WPA2 Authentication Request
WPA2 Authentication Resp + Text
WPA2 Authentication Response

Cryptographic Consistency

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 [2] for Hashes.

WPA3-Personal

Beacon with SAE

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 [3] 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 [4] 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 [5], 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 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 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 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 [7].

Attack Resistance

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 [8].

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:

WPA3_Connection_Graph
WPA3 Connection Flow Chart
WPA3_Connection_Graph_Detailed
WPA3 Authentication Messages

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:

WPA3 Authentication 1/4
WPA3 Authentication 2/4

The last two authentication frames contain the token as confirmation.

WPA3 Authentication 3of4 + Text
WPA3 Authentication 3/4
WPA3 Authentication 4of4 + Text
WPA3 Authentication 4/4

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.

Password Complexity

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.

Transition Mode

Beacon with SAE Transition Mode

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.

WPA3-Enterprise

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

Beacon with WPA3-Enterprise 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.

KRACK-Attacks

Maybe you heard of the so called KRACK-attacks by Mathy Vanhoef [9] 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 [9] for more information about the attack itself.

Mathy’s Analysis of WPA3

In April 2019, Mathy Vanhoef published a paper [10] 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.

Conclusion

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.

Links

[1] WFA Press Release on WPA3

[2] Wikipedia on SHA-256

[3] Wikipedia on Diffie-Hellman Key Exchange

[4] Elliptic Curve P-256

[5] Dragonfly Key Exchange

[6] Elliptic Curve Point Addition and Multiplication

[7] Andrea Corbellini: Introduction to EC

[8] IEEE Simultaneous Authentication of Equals: A Secure, Password-Based Key Exchange for Mesh Networks

[9] KRACK Attacks

[10] Dragonblood

Updates

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”

39 thoughts on “WPA3 – Improving your WLAN security

  1. Thanks for the detailed explanation. This is wonderful.

    When AP sends 1st Authentication frame, does it send Scalar + P(x,y) or Scalar + new_point(AP1)?

    Like

    • Hi there,
      since both parties calculate the same P(x, y), this is not and does not have to be transmitted. They always transmit the “new_point”. Both, scalar and new_point, are unique for each party.

      regards,
      mtroi

      Like

      • Thanks mtroi.

        I got confused by the Scalar + P(x,y) in the Auth Request and Authe Response picture. Hence I had asked.

        Great article and nicely put 🙂

        Like

      • Good catch! I’m going to change that, my plan is to update the pictures with a new version of wireshark that has WPA3 support in it.

        Like

  2. Dear mtroi,
    I have been meaning to tell you, i appreciate the post. I am currently Msc student of Computer Science focusing on IoT Security. On your post there were some figures that look like a “wireshark” screen shots, is there any real implementation of WPA3? I feel strong partiality towards investigating WPA3 more? Do you have access to any hard-to-find material that could help me?

    Sincerely,
    Muhammad

    Like

    • Hi Muhammad,
      yes those are pictures with a development version of Wireshark (v2.9). So far LANCOM and Aruba have released Firmwares with WPA3 support on the APs. Aruba did so for their 11ac Wave2 products, whereas LANCOM released the Firmwares back to 11n APs. If you run a Linux PC, you could update to the latest wpa_supplicant to get a client with WPA3 support.

      Since WPA is a Wi-Fi Alliance brand technology, material can only be obtained as a WFA member. Sorry.

      Regards,
      mtroi

      Like

  3. Dear Mtroi,
    Thank you for your explanation. But I have some problem with anti-clogging token. What happens when AP reach anti-clogging threshold. I know when AP responses code 76, then the station will carry a token. How does the token generate?How does the AP verify the token ? How does this method avoid denial of service attack?
    Sincerely,
    Yang

    Like

    • Please read the IEEE-802.11-2016 Standard in section 12.4.6 for all the details. The basic idea is to prevent flooding attacks with forged MAC addresses. So the token is bound to the MAC address of the sender of an SAE Commit message and the sender has to respond with the token in subsequent Commit messages. An attacker with forged MAC addresses will fail to do so or at least will have less flooding speed due to the token calculation.

      A suggested method for the Anti-Clogging Token is based on a random secret value that is passed together with the sender’s MAC address to the Hash-Function of the token process described in “Establishing a Pairwise Master Key in SAE with ECC”. The sender then has to figure out the random secret value before he can generate his token.

      Like

  4. Hello Mtroi, thank you for the post.

    I was wondering if you have more details about the EAP-pwd security issues. I’ve seen that Mathy Vanhoef published the “dragonslayer” tool on his github, but there’s not much information yet besides that one of the exploits is based on filling zeros in the scalar of a pwd exchange.

    Thank you.

    Like

    • Hello Matheus,
      I could do that, but I like to keep this post on WPA3 as it was released in Summer 2018. The topic EAP-pwd might be covered in a new post, together with the issues that Mathy found. In the meantime, I would recommend to read the CERT publication based on Mathy’s findings (CERT Link), which should give you a hint.

      Regards,
      mtroi

      Like

  5. Hello Mtroi.

    Thank you very much, this was actually exactly what I needed. I could verify this issue also with freeradius when doing some tests.

    Like

  6. HI,
    From the following 2 phrases
    >> party chooses two random numbers, private and mask to calculate two new values
    >> = private(AP1) • private(AP2) • P(x, y)
    private(AP1) and the random number private picked by AP1. Are they both same?

    Like

  7. Hi,

    >> K = private(AP1) • (scal(AP2) • P(x, y) ◊ new_point(AP2))
    >> K = private(AP1) • private(AP2) • P(x, y)

    This mean that
    private(AP2) • P(x, y) = (scal(AP2) • P(x, y) ◊ new_point(AP2))

    so it comes to something like
    K = (scal(AP1) • new_point(AP1)) • (scal(AP2) • P(x, y) ◊ new_point(AP2))

    Except P(x,y) I could get all other parameters from Auth1 and Auth2 frames. Using dictionary attack, I can generate P(x,y) and validate this by looking at token in Auth3 frame. Can you please help understand this.

    Like

    • The problem is to calculate the private as both parties send the scalar. To retrieve the private random number from the scalar, you need to inverse “scal = (private + mask) mod r”. As there are two random numbers and a modulo operation involved, this will be the tricky part.

      Could you elaborate more on how you got to the equation that only includes scalars and new_points? Why did you assume that “private(AP1) = scal(AP1) • new_point(AP1)”? A scalar multiplied with a point will again result in a point and not a number/scalar.

      Like

  8. Hello, thanks for the write-up.
    OpenWRT 19.07 with WPA3 support released a few days ago – is there a CLI program I can run on Linux to find out whether my client network adapter (ath9k-based) supports WPA3?
    Thanks!

    Like

    • Not that I know of. You should check your version of the wpa_supplicant and just try it out. SAE itself doesn’t need Hardware support, only the WPA3-Enterprise with 192-bit would require it.

      Like

  9. If I want to take a call on implementing WPA3 now? what will be your thought to proceed for this?
    If researcher has already found vulnerabilities on WPA3-personal and transition mode is not secure since client can still be enforced to WPA2 in transition mode.I am bit confused here. What would be your call on implementing WPA3 now.

    Like

    • Dear Vinod,
      form my perspective, this shouldn’t be a question. WPA2-Personal is not a secure option. It has and always will have the security flaw of enabling dictionary attacks, the main issue that is mitigated in WPA3-Personal. WPA3-Personal is not broken yet and will also become mandatory for WFA certifications soon. There are some smaller issues, but the cryptography itself remains secure. Furthermore, IEEE and WFA are working on the remaining issues to further improve the protocol and mitigate the mentioned issues.

      Like

  10. Hello Mtroi,
    Thanks for your explanation about WPA3. I appreciate this post.
    I want to ask you something about create and manipulate network packet using scapy on python.
    In your opinion, is that wpa3 frames can be created using scapy too? Have you ever try it? Give me some suggestion to create wpa3 frames on python script.

    Sincerely,
    Erika

    Like

    • Hello Erika,
      what do you mean by “WPA3 Frames”? Depending on what you want to achieve, I suggest to use scapy together with WPA-supplicant to bring up encrypted connections. Though it is possible to create WPA3 elements within the Authentication frames (Commit & Confirm), you will most likely fail to keep the required timing during the EAPOL phase. The last part is also true for any key derivation/installation via scapy as your wireless NIC will not allow to send out the frames as quick as required.

      Like

  11. Dear Mtroi,

    Thank you for your hard work!
    I’m studying WPA3 for my undergraduate work and I don’t this text fragment:

    > Since scal(APx) • P(x, y) is another point, the scalar multiplied point of e.g. scal(AP1) • P(x, y) is added to the new_point(AP2) and afterwards multiplied by private(AP1).

    But the formula before it says something else:
    scal(AP2) • P(x, y) is added to the new_point(AP2) and afterwards multiplied by private(AP1).

    Where is the error?

    Like

  12. Hi Mtroi ,

    How the cofirmation hash code validated by both by AP an client ?

    By comparing any value ?

    Thanks in advance ,
    Sandy

    Like

    • Dear Sandy,
      I’d say that is already written in the blog post: “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.”

      Best Regards,
      mtroi

      Like

  13. Hi Mtroi ,

    Thanks for the quick reply .

    I have one doubt , in which step Wpa3 security fails when we give wrong password . What will be the failure reason ?

    I captured the packets on my system to check where it is failing , I see lot of messages are in Authentication stage (multiple commits or confirm messages exchanged b/w Ap & Client and unable to see failure message)

    Thanks in Advance ,
    Sandy

    Like

    • Hi Sandy,
      happy new year to you and sorry for the late reply. This is a good question, the message indicating a wrong password for WPA3-Personal is send in the last Authentication message of the AP, It usually just says “Unspecified failure (0x0001)” as Status Code.

      BR,
      mtroi

      Like

  14. Hi Mtroi,

    This is a superb article. Thank you!

    I am perplexed why WPA3-Enterprise did not use choose to use SAE to provide PFS.

    I can see that this might have been difficult to bootstrap, because as specified SAE precedes the 802.1X authentication (and there is no shared key, of course).

    Or perhaps PFS wasn’t considered a priority in this scenario, because the EAP MSK is high entropy and regularly refreshed?

    Josh

    Like

    • Hi Josh,
      the method of SAE applies to a common Pre-Shared Key for all users. In WPA-Enterprise, you usually do not use a common password, so PFS is already possible there by using individual credentials and public key cryptography (maybe via ECC).

      Taken from https://security.stackexchange.com/questions/182983/what-is-stronger-wpa2-enterprise-with-2048-bit-key-or-personal-with-63-charac :
      “In practice, WPA2 Enterprise using public key cryptography is more secure. This is not because it is more difficult to attack with cryptanalysis, but because it provides other security benefits such as forward secrecy, which ensures that an attacker who compromises one session will not be able to then retroactively decrypt previously recorded sessions, because each key is generated randomly for each session. WPA2 Personal on the other hand uses the passphrase to derive the key, and as long as the passphrase remains the same, any data encrypted under that passphrase can be decrypted as soon as you learn what it is. Because WPA2 Enterprise allows the key to be generated entirely randomly, there is no risk of using a poor passphrase that can be broken.”

      BR,
      MTroi

      Like

      • Thanks Mtroi.

        I’m still not clear about this. If the EAP MSK (which is used as the PSK by the 4way handshake) is obtained by an attacker, surely the attacker can observe the 4four way handshake and derive the PTK/GTK? (just as they could with a compromised WPA2-Personal PSK).

        Josh

        Like

      • In case the attacker is able to obtain the MSK in an enterprise setup, you got a severe problem! This is not as trivial as for WPA2-Personal with a dictionary attack. But still, the RADIUS-Server will use/create session keys to derive the PMK from MSK, so the attacker needs to compute the PMK for each session.

        See also this excellent White Paper on this topic: https://www.cwnp.com/uploads/802-11i_key_management.pdf

        Like

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.