KRACK vulnerability explained – Part 2
In general 4-way handshake process happens as described earlier. Keys are generated on either sides(client and AP) both parties confirm on keys.Then keys are used for encryption.
But reinstalling an already installed key creates a new problem.
When supplicant(client) receives Msg3/4, it installs key which was generated by it (PTK) and resets Packet counter. Packet number for generating keystream is reinitialised.
Supplicant responds back to Authenticator on this by Msg4/4. If an attacker intercepts Msg4/4 and drops the packet. Authenticator will not know if key was installed at supplicant end.
Msg3/4 is resent from Authenticator to supplicant.
NOW , since key was received again, supplicant reinstalls key and resets packet number again.
Note that the packet counter is reset again. Keystream generated will be same as that of earlier one. With this, we can see that two different data packets are encrypted with same keystream. Reuse of keystream breaks basic principle of AES-CCMP.
As we can see in picture above, Data1 and Data2 are encrypted using same keystream. When two packets are encrypted with same keystream knowing Data1 will help to predict Data2.
Thus KRACK. 🙂
This vulnerability is present in peer key, group key and Fast BSS Transition key handshake processes.
Check these below resources to know more about this. I just loved the youtube videos created by SecurityTube and mojoNetworks.
— By Fabian Darius