KRACK - Breaking WPA2

18 Oct 2017 · Updated 04 Jun 2024 15 min read Author: Pixis

This article is a review of the KRACK attack - Key Reinstallation Attack presented by Mathy Vanhoef in his paper. With this attack, it is possible to break the WPA2 protocol by intercepting and decrypting communications without being authenticated on the network. Here, I try to detail as clearly as possible how this attack works by recalling a few concepts the attack revolves around, such as the cryptographic problem at play, or the 4-way handshake used in the WPA2 protocol.

I started a PoC of the attack on GitHub which works occasionally but remains quite unstable. If you feel like looking at it, understanding it, and improving it, don’t hesitate!

Cryptographic problem

This attack takes advantage of an implementation error in a protocol in order to reinstall an already-used cryptographic key while resetting parameters that are supposed to be unique. This makes it possible to obtain messages encrypted with this key, and with constant parameters, breaking the robustness of the cryptographic system.

Schematic example representing CCMP encryption:

encrypted_message_1 = plaintext_message_1 XOR F(Key, parameter_1)
encrypted_message_2 = plaintext_message_2 XOR F(Key, parameter_2)

In this example, F is a complex function (AES for CCMP), and if parameter_1 and parameter_2 are different, we cannot easily recover the plaintext message. On the other hand, if they are similar, then we will have:

encrypted_message_1 = plaintext_message_1 XOR F(Key, parameter)
encrypted_message_2 = plaintext_message_2 XOR F(Key, parameter)

encrypted_message_1 = plaintext_message_1 XOR constant
encrypted_message_2 = plaintext_message_2 XOR constant

Which allows us to remove the key from the equation, arriving at:

encrypted_message_1 XOR encrypted_message_2 = plaintext_message_1 XOR plaintext_message_2

If we know one of the messages, for example if the client sends a GET to a site (GET / HTTP/1.1), then we will have access to plaintext_message_2.

4-way handshake

Popularization

When a client connects to an access point protected by the WPA2 protocol, there is an exchange of 4 messages performed in order to then be able to exchange information by encrypting it so as to make it unreadable to anyone with prying ears who doesn’t belong to the network.

In order to construct a key that will encrypt everything, each party will need the SSID, the access point’s key, the MAC addresses of both parties, as well as a random number generated by each.

If we translate this handshake into plain language, it looks like this:

[Message 1] Access Point - I’m sending you a random number (Anonce) and my MAC address. As for me, I already have my SSID and the network key, allowing me to compute a key common to everyone (PMK)

[Message 2] Client - Received! I cooked up a mix using your number (Anonce), a number I generated (Snonce), your MAC address, my MAC address, your SSID, and the key (which also gives me the PMK), and it gave me the encryption key (PTK). And so, I’m sending you my generated number (Snonce) and my MAC address so you can do the same cooking.

[Message 3] Access Point - Received as well. I did the same cooking, giving the encryption key (PTK). Thanks!

[Message 4] Client - Perfect! Alright, let’s talk.

Once this handshake is done, a key is shared between the client and the access point without ever having been passed over the network, a key which will be used to encrypt the rest of the communication. If the client did not have the correct key to connect to the access point, then the PMK was different, which means that the encryption key (PTK) is not the same, and the client will not be able to communicate with the access point.

Here is a diagram summarizing this communication

Details

Now that we’ve understood the overall principle, we’ll go into a bit more detail.

When clients are connected to the access point, they produce a PMK (Pairwise Master Key) that is based on the SSID and the access point’s key.

PMK = hash(SSID + AP_Key)

For a client to communicate with the access point, they will need to agree on an encryption key. To do this, the encryption key will be based on different elements

PMK (Pairwise Master Key)
MAC address of the access point
MAC address of the client
A random number generated by the access point (Anonce - Authenticator Number used Once)
A random number generated by the client (Snonce - Supplicant Number used Once)

This key is temporary, and is called PTK (Pairwise Temporal Key). It doesn’t last over time, which is the whole point.

In order to agree on this PTK key, here is the 4-way handshake, viewed in a more technical way, but not yet complete

Finally, one last element must be added: the counter (Key Replay Counter). This is generated at the start of the 4-way handshake and increments throughout the handshake as well as in all communications that follow. When the first message is sent, the access point sends an initial KRC value. The client will respond with the same value, allowing the access point to know which message 1 the client is responding to (several clients can connect at the same time). Then when sending the second message, the access point increments it, and the client responds with this new value.

Then, for subsequent communications, this counter will be incremented with each message sent to the access point; it’s actually called the PN (Packet Number) and this counter will be used in the encryption as the Nonce, or IV (Initialization Vector), guaranteeing uniqueness for each message. If two messages were ever encrypted using the same Nonce, then the cryptographic strength would fall apart.

So here’s a more complete diagram

For general knowledge, the function G which derives the PMK to produce the PTK is a Pseudo Random Function (PRF) based on HMAC using SHA1 as the hashing method.

Attack: Key Reinstallation

Context and standards

So we now have a fairly clear vision of what happens when a client attempts to communicate with an access point protected via the WPA2 protocol. There is a 4-way handshake which allows the two entities to agree on a temporary encryption key which serves two purposes: The first is to ensure to the access point that the client has its password. Indeed, if this is not the case, the two encryption keys will be different and the two entities won’t be able to communicate. Second, this temporary encryption key allows the two entities to communicate in an encrypted manner so that an attacker eavesdropping on the network cannot decipher or decrypt the communications.

Different protocols exist for the encryption and integrity verification of data once the shared key has been computed, for example TKIP (Temporal Key Integrity Protocol), which is now deprecated, (AES-)CCMP (Counter-mode/CBC-Mac Protocol), widely used today, or GCMP (Galois/Counter Mode Protocol), also very widely used.

The last two (CCMP and GCMP) are two very robust protocols as long as the rules are followed, notably the fact of never reusing the same Nonce to encrypt two messages.

This is the condition that comes into play in the KRACK attack.

In the previous section, we saw that the Nonce used to encrypt communications is the PN (Packet Number), which is incremented with each message. So far, no problem since this guarantees its uniqueness for each message. If a message is lost and the client has to resend it, it will resend it with an incremented PN in order to continue guaranteeing the uniqueness of the Nonce in the encryption protocol.

There is, however, a somewhat grey area in the IEEE 802.11 standard (with the 802.11i amendment - WPA2) regarding the handling of retransmitted messages in the 4-way handshake. Fortunately, the 802.11r amendment (FT - Fast Basic Service State Transition, which specifies and improves access point switching when a person moves around) provided a state diagram that clarifies all of this. The two important points are as follows:

The access point must retransmit messages 1 and 3 if it has not received a response from the client, implying that the client must handle these retransmissions.
The client must install the PTK upon receiving message 3, which has the effect of updating the counter, equal to the one received in this 3rd message

Where things go wrong

Thanks to the two ideas from the previous paragraph:

The two CCMP and GCMP protocols are very robust as long as the rules are followed, notably the fact of never reusing the same Nonce to encrypt two messages;
The client must install the PTK upon receiving message 3, which has the effect of updating the counter, equal to the one received in this message;

we can now understand how an attack might unfold. If the attacker positions themselves between the client and the access point, and lets the first 3 messages through, but blocks the 4th message, that is to say the client’s acknowledgment sent to the access point, we find ourselves in the following situation:

The client has sent its acknowledgment, so from its point of view, the 4-way handshake is complete, and it can begin to communicate by sending various messages encrypted with the PTK, and with the incrementing counter, a counter which plays the role of Nonce.

The access point, for its part, has not received the acknowledgment. So, for it, the 4-way handshake is not complete. After a certain timeout, it will therefore resend the 3rd message to the client. Since the client must reinstall the PTK upon receiving message 3, even though it has finished the 4-way handshake, it will receive this 3rd message again, and will reinstall the PTK (which has not changed), then send back an acknowledgment, in order to finally continue communicating with the access point, starting over with the counter equal to that of the 3rd message, which it increments again for what follows.

This is where we have the problem. New messages will be encrypted and sent by the client, but they will be encrypted with a Nonce it has already used. And there we have it — the entire cryptographic strength collapses, as we saw briefly in the first paragraph. It becomes possible to decrypt messages received by the client even though we don’t have the key to connect to the network, which is exactly the opposite of the WPA2 principle.

Here is a small diagram summarizing this principle

So we have the plain_1, plain_2, plain_3 which were encrypted with the Nonces r+2, r+3, r+4, then following the reinstallation of the PTK, plain_4, plain_5 were encrypted again with the Nonces r+3, r+4. It then doesn’t take long to break the cryptographic protocol that is supposed to protect the messages, as seen at the beginning of this article.

Indeed, in this example we have

encrypted_msg_2 = plain_2 XOR F(PTK, r+3)
encrypted_msg_4 = plain_4 XOR F(PTK, r+3)

The same Nonce r+3 is used to encrypt two different messages. If we know plain_2 for example, we can reduce these two equalities to the following:

encrypted_msg_2 XOR plain_2 XOR encrypted_msg_4 = plain_4

Thus, without knowledge of the PTK key, we can deduce plain_4.

How to protect against it

If you’ve properly understood the principle of the attack, you should already be able to think of various solutions to protect against it. It is possible to protect at two levels.

Protection at the access point level

[Edit 22/10/2017] This paragraph explains a way to protect clients by configuring the access point; however the attacker can manually replay message 3 by incrementing the counter, which will still have the effect of reinstalling the PTK and resetting the counter on the client. So, I don’t think the solution I had proposed is functional. Furthermore, there are several variants of the attack, sometimes targeting access points, sometimes clients. It is therefore advisable to update both actors.[/edit]

This is the part that seems most effective to protect since if we succeed, then all the clients that will connect to this access point are no longer vulnerable. However, it is also the one that has the biggest impact. Since the attack relies on the client not responding after message 3, and the access point resending this message, it is possible to fix the problem by deciding that if the access point does not receive a response, then it disconnects the client. The client will then have to start a new 4-way handshake in order to connect. This is, however, quite a radical change in the implementation of the protocol.

Protection at the client level

It is also possible to ensure that the client’s procedure during the 4-way handshake is stateful, meaning that the client remembers previous actions. Thus, if it has already installed a key, and the access point resends message 3, then the client may well decide that its key is already installed, and therefore won’t reinstall it and won’t reset its counter, used as the Nonce for the cryptographic principle. This is the cleanest way to protect against the problem, however it implies that the behavior of all clients must be changed.

Conclusion

I hope this article helps you better understand this attack, which is really interesting, and which forced me to dive back into many areas that were a bit fuzzy for me, and to read the related standards in order to avoid saying too many silly things. If you have remarks or questions, please feel free to ask them in the comments.

I also wanted to say thank you to the_lsd for his explanations on several points and for his approach to the subject.

Open questions

[Edit 22/10/2017] I finally found the answer to my question: One must use the technique known as channel-based Man-in-the-Middle described in Advanced Wi-Fi Attacks Using Commodity Hardware [/edit]

After spending time setting up a proof of concept, I don’t see how to proceed for one link in the attack chain.

For this attack to work, in theory you need to be the intermediary between the client and the access point. However, from my understanding, it is not possible to have this role during the authentication/association of a client to an access point.

Indeed, the complete procedure for being able to communicate with the access point is as follows

Probe Request from the client to find compatible access points (Destination ff:ff:ff:ff:ff:ff which is the broadcast address);
Probe Response from all surrounding access points that are compatible with the constraints given by the client;
Authentication Request from the client to an access point (using its SSID and MAC address so that it recognizes itself. SEQ 0x1);
Authentication Response from the access point, telling it that it has been done successfully (SEQ 0x2);
Association Request from the client to associate with the access point;
Association Response from the access point to validate the association;
4-way handshake for WPA2.

If we listen to the network, we therefore see the client’s Probe Request, the Probe Response, the authentication, and the association go by. We therefore know which access point the client will communicate with. We have the MAC addresses of the client and the access point.

I don’t see, on the other hand, how we can “block” messages from the client to the access point.

I had thought about creating a rogue AP with the same SSID but a different MAC. This way, we would make the AP think we are the client, and the client think we are the AP. However, for the PTK calculation, the client and the AP would not have the same pair of MAC addresses, so their respective PTKs would not be the same. So this is not a viable technique.

For this reason, when the client communicates with the access point, it will send its packets to the correct MAC address, and since this goes over WiFi, the access point will take them into account no matter what we do. I don’t see how we can intercept message 4 from the client so that the legitimate access point does not receive it.

Another solution is to do Jamming, that is to say send a whole lot of useless packets in bulk to the access point so that it is no longer able to respond to anyone, including the client. This allows us to take the place of the access point, but not to be in MiTM. The idea being to let certain packets through so that the access point responds, if we do jamming, it simply won’t respond. So this isn’t a possible solution either, it seems to me.

If you’ve understood this part of the attack, I’d be happy if you could explain this passage to me, for example in the comments. :)

Going further

I have given here a somewhat technical description of the key reinstallation attack during the 3rd and 4th messages of the 4-way handshake. However, the author of the attack paper discusses other (similar) ways of attacking a client, focusing on different handshakes. I invite you to read his paper, which is extremely interesting, for more details, and the attack variants described in this article.