Illustrate: WPA2’s vulnerability [KRACK] and Sequence of 4 way handshake

Logic that can be decrypted with KRACK
References
IT/インフラエンジニアの地位とスキル向上のために

Logic that can be decrypted with KRACK

I looked for various articles on WPA2's vulnerability (KRACK) published on October 16, 2017, and found there was a lot of articles about " What kind of things will happen as a result of being vulnerable?" but merely about "How did you decrypt in the end?". As the technician who said "I wanted to know the most," it was missed, so I read the original essay carefully and I will briefly explain it.

Premise

An attacker first establish the channel-based MitM (Man in the Middle) attack position where he can control the packet (but can not decrypt yet) , so he can decide the packet to pass or drop.

Preliminary knowledge - 4way Handshake Mechanism & Sequence

After establishing the Association link to the wireless AP in WPA2 (if IEEE802.1x is required, after further), both of CL & AP install the 2 keys by 4way Handshake. One is called PTK (Pairwise Master Key) and another is GTK (Group Temporal Key).

PTK is the key for unicast encryption / decryption. AP and CL has the same key. GTK is the key for multicast and broadcast encryption / decryption. AP and All CL under the AP has the same key (for encryption /decryption multicast or broadcast each other).

First of all, PTK does not directly exchange on the route, it is uniquely generated from the following information.

1. PMK (Pairwaise Master Key)
2. Anonce (transmitted with Message# 1 of 4 way Handshake)
3. Snonce (transmitted with Message# 2 of 4way Handshake)
4. MAC address of wireless AP
5. MAC address of wireless client

The PMK (Pairwise Master Key) is a pre-shared key if WPA2-Personal, and a key exchanged by IEEE 802.1x in case of WPA2-Enterprise.

At 4way Handshake's Message#1 and #2, AP and CL exchange Anonce and Snonce each other, and they generate and install the same PTK.

PTK consists of 3key , "Key Encryption Key (KEK)", "Key Confirmation Key (KCK)", and "Temporary Key (TK)". And TK is used for unicast communication encryption / decryption.

In Message#3 of 4way handshake, GTK generated by AP is encrypted with KEK and sent to CL, and CL decrypts the GTK using KCK and installs it.

Finally, CL sends a message#4 to AP indicating the completion of the 4way handshake.

KRACK's Attack Mechanism and Sequence

In KRACK , 4way Handshake Message#3 is retransmitted by intentionally stopping 4way Handshake Message#4 by man-in-the-middle attack. And each time CL receive this Message#3, CL retransmits it as "message#4 packet loss", and CL reinstall PTK but at the same time, CL reuse the nonce which should only use once(so called nonce [Number used ONCE] again to encrypt the packet.(Anonce, Snonce is also one type of nonce, but the nonce here is different from them. For example, CCMP nonce.)

Nonce is used with Temporary Key to encrypt ordinary communication (e.g. http ). Originally, a different nonce is used for each packet to be encrypted. For example, the first packet becomes nonce #1 and the second packet becomes nonce #2. However, when reinstalling PTK with this attack , the nonce will return from nonce#1 again as a standard because it allows retransmission of Message#3 and roll back and retry the process.

The big problem here is that there are no provisions regarding timing of installation of PTK in the standard, and most of the implementations install PTK at the timing of the first Message#3 reception. In other words, despite initiating encrypted communication using TK and nonce, CL retransmit the message by retransmitting Message#3, so CL will communicate using the same nonce and TK pair.

By repeating this Message#3 for a long time, TK can also use the same thing all the time. By analyzing frames encrypted with the same pair of nonce and TK, and the same pattern of series of nonce, you can understand the pattern of Temporary Key and nonce and it becomes possible to decrypt!

The worst in Android 6.0 etc

In wpa_supplicant version 2.4 to 2.6 used in Android 6.0, found that there is a fatal bug that TK is set to 0 when it receives retransmission of Message#3 of 4way Handshake. It is easy to decrypt if the bug combine with this vulnerability.

This vulnerability discoverer speculates that this is the result that the Android Developpers implmented honestly IEEE802.11 statement that "TK should be destroyed from memory once installed".

First of all, it is a vulnerability of the protocol itself of WPA2, but which part?

What is characteristic of this vulnerability is that "PTK does not leak" as a condition for securing security with WPA2, but this attack is that it has not leaked.

This is one of the grounds to show that it is a protocol itself's vulnerability, but which part is vulnerable then? Regarding the point that this vulnerability discoverer defines "How to install each key", but the definition of "When to install" is missing, and it was pointed out that we did not assume the case of "installation". Perhaps the specification formulators were stance "Leave it to the implementation because there is no problem at any timing".

Specifically, the wireless client implements the installation of PTK immediately after receiving Message#3, but this is before the completion of 4way handshake.

If nothing happens afterwards, the wireless AP will receive Message#4 and complete, but this attack will be in that gap. So it might have been prevented if the standardification to limit the timing of installing the key (for example 5way Handshake) was done.