Posted by Babar Hashim, October 30, 2017
Does design flaw in WPA2 makes it vulnerable to KRACK?
All protected Wi-Fi networks are secured using some version of Wi-Fi Protected Access (WPA/2) which rely on the 4-way handshake defined in the 802.11i amendment. Key Re installation AttaCK (KRACK) abuses design or implementation flaws in the WPA2 cryptographic protocols. KRACK works by targeting these 4-way handshakes and thus both WPA and WPA2-certified products are affected by this Krack Attack. 
WPA (sometimes referred to as the draft IEEE 802.11i standard) became available in 2003. To put things in perspective this issue has always been present for the last 14 years, but has recently gained quite a bit of attention. Let's first understand what this WPA2 vulnerability is and asses it's impact.
When a device connects to a network, authentication goes through the following stages.
- Authentication Stage: Open system authentication that allows any client to authenticate.
- Four-Way Handshake: The stage where actual Authentication is performed.
- Group Key Handshake: Used when network may need to be updated due to the expiry of a preset timer. Example when device leaves the network.
Figure on the right, shows an overview of the messages exchanged when a client connect with an AP.
To understand the this WPA vulnerability it is important to understand the 4-way handshake.
What is the 4-way handshake?
Whenever a client wants to join a network (connect to an access point), it has to execute a 4 way handshake. The four-way handshake is designed so that the access point (or authenticator) and wireless client (or supplicant) can independently prove to each other that they know the Pre-Shared Key, without ever disclosing the key. Access point and the client encrypt messages to each other which can only be decrypted using this "key" that they share.
In summary, below are the 4 messages that are involved in a 4-way handshake to guarantee security.
- The authenticator (AP) initiates the 4-way handshake by sending message 1. This message contains the ANonce (Authenticator Nonce). Nonce is a arbitrary number that may only be used once.
- On reception of message 1, the supplicant (client) generates the SNonce (Supplicant nonce) and derives the session key (PTK). The supplicant then sends the SNonce to the authenticator in message 2.
- Once the authenticator learns the SNonce, it also derives the session key (PTK), and sends the group key (GTK) to the supplicant in message 3.
- Finally, to finalize the handshake, the supplicant replies with message 4 and after that installs the PTK and GTK.
To summarize, the first two messages are used to transport nonces, and the last two messages are used to transport the group key and to protect against downgrade attacks.
The Key Re-installation Attack
KRACK attack is based on design flaws in the 4-way handshake. Now that we have an idea on what is involved in the 4 way handshake, let's see how this KRACK attack tries to expoit it. This attack establishes a position between the supplicant and the authenticator as shown in figure on the right (it is being referred to as Adversary or MiTM, short for "Man in The Middle"). The purpose of this MiTM is to trigger re-transmissions of message 3 by preventing message 4 from arriving at the authenticator. This triggers the authenticator to re-transmit message 3, which causes the supplicant to reinstall an "already-in-use" session key. In effect, this also resets the nonce being used by the data-confidentiality protocol (TKIP, CCMP, GCMP).
The impact depends on what protocol is being used but in some instances it can allow hackers to replay, decrypt and/or forge packets.
Impact of the WPA supplicant's vulnerability?
CCMP protocol, which many also refer to at WPA2-AES, is the preferred and the most commonly used protocol by users. The impact when CCMP is used is very restricted. Maybe that is why Wi-Fi alliance and other organizations believe that the impact of the threat is low. Below is an interpretation of the KRACK impact:
- It is not capable to decipher the master key (also known as the PMK)
- It can also not decrypt the communication encryption key ("session key" or PTK).
- The Krack attack is not a vulnerability of the WPA protocol and does not violate any security properties. This attack just exposes that the 4-way handshake can be manipulated. At best, it highlights a vulnerability in the 4-way handshake.
- Regardless of what authentication method for WPA2 is used (PSK or Enterprise), both are equally vulnerable.
What this attack shows is that by blocking message 3 of the 4-way handshake it can cause re-transmissions. It can thus be manipulated that the key exchange in the handshake uses the same "nonce". Just because nonce can be re-used, it does not necessarily mean that the security/encryption key has been compromised. Though theoretically it may be possible, but it will be extremely be difficult for a hacker to decipher the security keys.
It is important to understand that the KRACK does not mean that the WPA2 security is broken. It just exposes a vulnerability in the 4-way handshake, which is the "key exchange" process within the WPA protocol. The likelihood of a "Krack Attack" leading to any catastrophic security breaches is extremely low. I say this because the presumption is that the hacker has to attack it from inside the network. And if successful what is the actual real impact?
Vendors are looking to mitigate this threat in two ways. Either the entity implementing the data-confidentiality protocol should check whether an already-in-use key is being installed. A second solution is to assure that a particular key is only installed
once into the entity implementing the data-confidentiality protocol during a handshake execution.
Silex's promise to customer is to provide robust and reliable products. Network security is very important to us and our customers. We are currently testing our software update to address this issue against all our product and solutions. we plan to share our plan and schedule with our customers soon. Please contact your account manager at firstname.lastname@example.org if you have any questions before we announce our next update.