For AP and client exchanging encrypted data, both need to have the right key(s) installed. Each time a client (Supplicant) associates to an AP (Authenticator), new temporal keys for the pairwise data transmissions are generated, which are unique for each connected client. In case of Broad- and Multicast frames, all clients use the same Groupwise Temporal Key (GTK) that don’t require a new generation for each association.
Transient keys are derived from a master key, a Pairwise Master Key (PMK) could be the passphrase for WPA-PSK or a key derived from the EAP process for WPA-802.1X or WPA-Enterprise. Since transient keys are used, an attacker cannot obtain the master key from sniffing the frames in the air and it is possible to change the PTK without changing the passphrase itself.
The installation of Pairwise and Groupwise Transient Keys (PTK/GTK) is done by the so called 4-Way Handshake with the following flow graph:
Source: Wikipedia
Pairwise Temporal Key Generation
The function to generate a Pairwise Temporal Key (PTK) is known as a Pseudo Random Function (PRF):
PTK = PRF(PMK | ANonce | SNonce | AA | SA)
With ANonce and SNonce as Nonces (Nonce: Number used once) from Authenticator (AP) and Supplicant (client) and the Authenticator’s and Supplicant’s MAC Addresses (AA/SA).
EAP-Key Message 1/4 (ANonce)
As the first message is send from AP to client, this message includes a random number as ANonce for PTK generation at the client. Since the client knows its own SNonce and SA as well as the AA (from Beacons, Probe Response and/or Association Response) and PMK, the ANonce from this message is the only missing information.
EAP-Key Message 2/4
As the Supplicant (client) replies to the first EAP Key message, the client sends the used SNonce as clear text to the AP “protected” by a cryptographic hash (HMAC-SHA1) called Message Integrity Code (MIC) for integrity of of this message the installed key on the client side. The AP will generate its own MIC and compare it the the one in this message, if they match, EAP-Key message 3 is send for key installation. This message also includes the Robust Security Network Information Element (RSN IE).
EAP-Key Message 3/4
Message 3 is the last unencrypted key message, as long as no retransmission(s) occur and the pairwise temporal key remains valid. The AP informs the client about the installation of the PTK and the receive sequence counter (RSC) for the GTK. The GTK itself is given in the WPA Key Data field, secured/encrypted with the PTK.
EAP-Key Message 4/4
The Supplicant acknowledges the installation of PTK and GTK afterwards, encrypted Unicast and Broad-/Multicast transmission can start now.
Conclusion
The generation of P/GTKs is quite easy and three of the four frames for the installation are unencrypted, which means that the only secret in PTK derivation is the Pairwise Master Key (PMK). As I will show in another post, the generation of a new PTK for each association to an AP can be shortened to enable a much faster association. This is especially important for client roaming and should not bother any single AP installation at home.
Attacks
In October 2017, postdoctoral researcher Mathy Vanhoef (PhD @ KU Leuven, Belgium) published his research paper on how the EAPoL key exchange can be attacked to read encrypted data without retrieving the actual PMK. He named the attack “KRACK” and here is the link to his paper.
*2017-04-18 Updated due to feedback from apoorva in the comment section*
*2018-01-18 Updated with a link to Mathy van Hoef’s research paper on Key Reinstallation Attacks*
WLAN by german engineering 
Very nice post!
But, I have two questions: what is the field “WPA Key Data” inside EAP-Key Message 2/4? Is this encrypted?
(Forgive my bad english, please).
Thanks!
\o/
LikeLike
Hello Henrique,
the key handshake itself does not use encryption, that’s why you can sniff and take a look at all 4 packets without being connected to the network. Therefore, the “WPA Key Data” is not encrypted, you can see all the interpreted details below that field which is basically the RSN Information Element, which can also be found in Probe Responses for example. So the client basically tells the AP that WPA2 with AES (CCM) encryption has to be used to groupwise and pairwise keys and that it does not support any further features like Protected Management Frames for example.
You might think it is encrypted since you see the hexadecimal representation of the tags and flags below it. I hope this answers your questions?
PS: Your english is perfectly fine.
LikeLike
Thank you very much, mtroi!
You answered perfectly.
I wanted to discover the PTK looking at all 4 handshake’s frames. Learn now that PTK is not transmitted through medium. So, think discover PTK through of Message Integrity Code (MIC), but researched quickly and see that it is not possible.
LikeLike
Researching MIC’s vulnerabilities I found the article:
Click to access A%20Practical%20Message%20Falsification%20Attack%20on%20WPA.pdf
LikeLike
Thanks for the link, I will read it as soon as I can. Are you investigating something in particular?
LikeLike
Good morning;
(1) Is the PTK and Snonce (Hashed) and transmitted to the AP as an “Snonce ?” and
(2) Once the Client receives and Ack for the GTK, does the proceeding data exchanges get encrypted by AES CCMP ? Is this how it works?
Thanks in advance,
Dj
LikeLike
Hello Dj,
if you read the post more carefully, you find most of your questions answered.
1) PTK is never transmitted, it is derived from information (ANonce, SNonce and MACs) that are given/transmitted
2) SNonce is transmitted as clear text, the Hash (MIC) is for only for verification, that the information is valid
3) After Client has sent EAPoL Message 4, AP and client transmit encrypted (unicast, multicast, broadcast) data packets.
kind regards,
mtroi
LikeLike
Hi Mtroi, nice article and quite well explained.
But I think there is a correction required.
In EAP-Key Message 1/4 (ANonce) –> The client only waits for ANonce value to generate PTK, it already has by this time the value of authenticator’s mac address from beacon frames and that is how supplicant will get to know whom to send the key request.
In EAP-Key Message 2/4 –> SNonce is not protected by MIC, SNonce is send with MIC, SNonce is non-encrypted or non-hashed value (just clear text) as you have correctly pointed out in wireshark and that is not to protect the integrity of the message but it allows authenticator to go verify the PTK generated by supplicant.
How ??
The authenticaor goes ahead and use the SNonce from EAP packet 2, it already has supplicant’s MAC address, PSK/PMK, its own mac addr to generate it’s own MIC and then it will compare both (one sent from supplication and generated by itself) if the match results to 0, it authenticates and sends packet 3 as Key installation and if it results to 1 it goes ahead and send “Deauthentication” packet.
LikeLiked by 1 person
Hi Apoorva,
thanks for your feedback including a very detailed explanation of the stuff that I’ve been unsure/uncertain about. The post has been updated.
kind regards,
mtroi
LikeLike
Hi Apoorva, I’m new to 802.11 and i was looking for 4-way handshake videos. Unfortunately there were not plenty of them on the youtube, could you please explain it to me in detail? I’d appreciate if you could explain me in hindi. TIA.
LikeLike
Thanks, Nicely explained.. Expecting for similar more articles
LikeLike
[…] 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. […]
LikeLike
[…] breaks WPA2 without obtaining the real key (Passphrase). As Enhanced Open uses the same EAPoL 4-Way Handshake like WPA2 (and WPA3) to exchange transmission keys, it could be attacked by KRACK as well. […]
LikeLike
hi,
i just need to know how GTK formed.. to get new GTK what are all required(does it require PMK/mac/anonce/snonce).
LikeLike
Hi Ashok,
sorry, but I’m currently too busy to answer your request. Maybe you can check this yourself or someone else can step in.
Regards,
mtroi
LikeLike
Hallo werter mtroi,
ich arbeite aktuell an einer Hausarbeit zu WPA2 und Auswertung mit Wireshark. Bitte ganz kurze Erklärung warum im EAP-Frame 3 in WireShark letzte Zeile eine WPA-Key-Data angezeigt wird und in EAP-Frame 4 die Daten auf 0 gesetzt wurden – 1) ist das der GTK und nicht der Key für PTK, richtig? 2) dann müsste der GTK aber doch auch in Frame 4 vorhanden sein?
Vielen Dank, mir wäre sehr geholfen wenn ein kurzes Feedback möglich wäre,
PAPSI
LikeLike
Hallo PAPSI,
der GTK wird verschlüsselt als WPA Key Data vom AP zur STA übertragen, wie im Blogpost beschrieben mit dem PTK als Schlüssel. Wenn die STA Frame 3 empfängt und bisher alles richtig gerechnet hat, dann ist sie in der Lage den PTK zu benutzen und damit die WPA Key Data zu entschlüssseln, um den GTK zu erhalten/installieren. Anders als der PTK, welcher auf beiden Seiten ausgerechnet wird, kommt der GTK allein vom AP, daher braucht die STA diesen nicht mehr an den AP zurückzuschicken (WPA Key Data Feld leer). Frame 4 stellt nur eine Bestätigung der STA dar, dass sie alles korrekt empfangen hat und nun verschlüsselt kommunizieren kann.
Viel Erfolg bei deiner Hausarbeit.
mtroi
LikeLike
Hi
There is a case, let’s say I am a legitimate user and already get connected to the AP, So I can see the Anonce and the SNonce of the new node joining the network, and can derive the PTK of those new nodes. Then how this PTK is unique to every user
LikeLike
Hello Manish,
the PTK is unique as ANonce & SNonce are unique for each connection attempt and the MAC address of a STA (SA) differs from others (The AP MAC (AA) does of course not change). By the way, you don’t need to be connected to the AP to see the A/SNonce, that’s something anybody can obtain by sniffing the packets over the air. As long as the Pairwise Master Key is unknown to not-connected user, (s)he’s not able to compute the PTK based on A/SNonce and AA/SA alone. I hope that answers your question?!
Regards,
mtroi
LikeLike
Hi mtroi,
Thanks for detailed explanation. I have a doubt “How AP will generate GTK?”
Regards,
Anusha.
LikeLike
AP will generate GTK based on a Group Master Key (GMK), please see “12.7.1.4 Group key hierarchy” of IEEE 802.11-2016 for an example. Since we don’t use authenticate STAs with the GTK and only distribute it via encrypted frames, the GMK and/or GTK is basically a random number.
LikeLike
Hi Mtroi ,
I have a doubt , ” When one of the clients joins or leaves the connected to AP , is that GTK renewal happens or not ? ” When a new client connects to AP , old configured GTK is shared with client or new GTK is generated and shared with all the clients ?
LikeLike
GTK renewal can either be turned off, happen at a fixed interval and/or whenever a client leaves the network. It depends on the AP configuration, either by the user (if such a setting is exposed) or the vendor.
The new GTK is distributed by the AP to all connected clients via the group key handshake (12.7.7 in IEEE 802.11-2016). The AP will try to update the GTK of all clients and then install the new GTK. However, if a client doesn’t reply within a certain interval, the AP deauthenicates this client and proceeds with the GTK renewal process.
So even in the rare case that a client joins the network during a GTK renewal, the client should receive the new GTK after a successful association.
LikeLike
Why RSN IE included again in 4 way handshake ? when It is already communicated in becon, probe response and (re)association frame ?
LikeLike
Without re-reading the spec on it: I assume that the client should indicate to the AP (once again), which AKM und security settings should be used and no “change of mind” between (re)association and key handshake has happened. As the RSN IE is only present in message 2 from client to AP, this already uses a hash for verification. That is not the case for the frames you mentioned.
LikeLike
Thanks for the response !
Please suggest any related document or specification.
LikeLike
You should always look at the latest IEEE 802.11 Standard. Currently that’s 802.11-2020.
LikeLike
In WPA2 and WPA3, I understand that once the PMK is known, then once should be able to compute the PTK, KCK, etc. Also, I understand the key derivation function for 00-0f-ac:8 (SAE(SHA2560) is based on PRF(SHA256). All my attempts to find a Python implementation of this function were unsuccessful. I appreciate your help finding a python implementation to validate the following wpa_supplicant log:
WPA: PTK derivation using PRF(SHA256)
WPA: PTK derivation – A1=ec:08:6b:08:49:47 A2=a4:2b:b0:c0:61:f9
WPA: Nonce1 – hexdump(len=32): 0c 0d 42 28 d1 d0 f6 0a 5c 28 30 b6 b3 ee 44 7c 19 86 68 8a 3d 7c d7 a3 ec 1c 78 77 12 91 4c bd
WPA: Nonce2 – hexdump(len=32): e5 0c e2 8e 36 74 44 3f d0 09 90 95 d1 37 1b e7 54 02 ee cf 8d 84 e5 8b c2 25 c2 09 82 80 bc 3a
WPA: PMK – hexdump(len=32): 3e f6 be 81 88 cd 53 58 9c f9 aa 4f 14 2d bd 3d df fc 99 e1 f9 fa e0 c2 bc b6 05 73 1d f4 d5 8f
WPA: PTK – hexdump(len=48): 0b 64 02 2d 23 71 7d 0f ab 4a cd 58 cc 10 a6 d4 89 9c b5 61 e5 42 0c 78 7c 25 27 47 93 bd 85 18 14 b9 f9 aa a5 c8 fd 52 d3 0f 4a ea ec 26 20 98
WPA: KCK – hexdump(len=16): 0b 64 02 2d 23 71 7d 0f ab 4a cd 58 cc 10 a6 d4
WPA: KEK – hexdump(len=16): 89 9c b5 61 e5 42 0c 78 7c 25 27 47 93 bd 85 18
WPA: TK – hexdump(len=16): 14 b9 f9 aa a5 c8 fd 52 d3 0f 4a ea ec 26 20
LikeLike
Sorry Emil Habib, but for such a specific question I can’t help you.
LikeLike