Lesson Contents
Wireless security is important because we use wireless signals for transmission that go everywhere. Everyone can listen in, and you can’t detect when someone does. The first IEEE 802.11 standard had Wired Equivalent Privacy (WEP), which, as it turns out, was completely broken and had many vulnerabilities. The 802.11i amendment introduced a new security framework known as Wi-Fi Protected Access (WPA).
Instead of using a single key for encryption, WPA uses a key hierarchy with many keys for encryption and integrity checks of unicast and multicast/broadcast traffic. WPA uses a 4-way handshake for authentication and to create all required keys. Once the 4-way handshake is complete, the wireless client and access point (AP) have a secure connection, and all traffic will be encrypted.
To understand this lesson, you must be familiar with the keys explained in the WPA key hierarchy lesson. The 4-way handshake uses EAPOL-Key frames. If you are unsure what EAPOL is, you might also want to check the EAPOL lesson.
We’ll start with an overview of what the 4-way handshake looks like, and we’ll go through a packet capture so that you can see it in action.
4-Way Handshake Overview
Let’s start with a high-level overview of what the 4-way handshake looks like:
The 4-way handshake uses EAPOL-Key frames. Let me explain what happens:
- The AP generates the Anonce value and sends message one to the client, which includes the Anonce:
- This message is unencrypted and has no integrity check.
- If someone messes with this message, the handshake will fail and that’s it.
- The client receives message one and derives the Pairwise Transient Key (PTK):
- The client already had:
- Pairwise Master Key (PMK)
- Snonce
- client MAC address
- The client received this in message one:
- Anonce
- AP MAC address
- The client already had:
- The client sends message two with SNonce and a Message Integrity Check (MIC) value:
- This message is unencrypted, but it does have a MIC to prevent tampering.
- We use the Key Confirmation Key (KCK) to calculate the MIC.
- The AP receives message two from the client and does this:
- Derive the PTK, which is possible because we now have the client Snonce.
- Use KCK to generate the MIC.
- Compare received MIC with calculated MIC.
- If the MIC is the same, this proves that the client and AP both have the same PMK.
- We are at 50% of the 4-way handshake, and both sides have derived the PTK.
- We have not encrypted anything yet. The AP and client both have the keys, but we don’t install them yet.
- The AP sends message three that includes:
- Key installation request: this will ask the client to install the keys.
- MIC
- Group Transient Key (GTK)
- The client receives message three and does this:
- Compare received MIC with calculated MIC:
- If the MIC is the same, this proves that the client and AP both have the same PMK.
- Compare received MIC with calculated MIC:
- The client installs the PTK and GTK and sends message four:
- This message is unencrypted but includes a MIC.
- This message includes an ACK and completes the 4-way handshake.
- This indicates that the client will install the keys and use encryption from now on.
- The client sends an EAPOL-Key to confirm it has installed the keys.
- The AP receives message four and does this:
- Compares received MIC with calculated MIC.
- If the MICs are the same, install the PTK and GTK.
- Compares received MIC with calculated MIC.
This completes the 4-way handshake, and from now on, the client and AP can transmit protected frames with encryption and integrity checks.
Packet Capture
Look at it in wireshark.
Packet Capture: WPA 4-way handshake
Message 1
This is the first message sent from the AP to the wireless client:
Frame 1: 155 bytes on wire (1240 bits), 155 bytes captured (1240 bits)
IEEE 802.11 QoS Data, Flags: ......F.
Type/Subtype: QoS Data (0x0028)
Frame Control Field: 0x8802
.... ..00 = Version: 0
.... 10.. = Type: Data frame (2)
1000 .... = Subtype: 8
Flags: 0x02
.... ..10 = DS status: Frame from DS to a STA via AP(To DS: 0 From DS: 1) (0x2)
.... .0.. = More Fragments: This is the last fragment
.... 0... = Retry: Frame is not being retransmitted
...0 .... = PWR MGT: STA will stay up
..0. .... = More Data: No data buffered
.0.. .... = Protected flag: Data is not protected
0... .... = +HTC/Order flag: Not strictly ordered
.000 0001 0011 1010 = Duration: 314 microseconds
Receiver address: be:09:77:06:31:96 (be:09:77:06:31:96)
Transmitter address: Cisco_ca:e0:c0 (24:16:1b:ca:e0:c0)
Destination address: be:09:77:06:31:96 (be:09:77:06:31:96)
Source address: Cisco_ca:e0:c0 (24:16:1b:ca:e0:c0)
BSS Id: Cisco_ca:e0:c0 (24:16:1b:ca:e0:c0)
STA address: be:09:77:06:31:96 (be:09:77:06:31:96)
.... .... .... 0000 = Fragment number: 0
0000 0000 0000 .... = Sequence number: 0
[WLAN Flags: ......F.]
Qos Control: 0x0007
Logical-Link Control
DSAP: SNAP (0xaa)
SSAP: SNAP (0xaa)
Control field: U, func=UI (0x03)
Organization Code: 00:00:00 (Xerox Corporation)
Type: 802.1X Authentication (0x888e)
802.1X Authentication
Version: 802.1X-2004 (2)
Type: Key (3)
Length: 117
Key Descriptor Type: EAPOL RSN Key (2)
[Message number: 1]
Key Information: 0x008a
.... .... .... .010 = Key Descriptor Version: AES Cipher, HMAC-SHA1 MIC (2)
.... .... .... 1... = Key Type: Pairwise Key
.... .... ..00 .... = Key Index: 0
.... .... .0.. .... = Install: Not set
.... .... 1... .... = Key ACK: Set
.... ...0 .... .... = Key MIC: Not set
.... ..0. .... .... = Secure: Not set
.... .0.. .... .... = Error: Not set
.... 0... .... .... = Request: Not set
...0 .... .... .... = Encrypted Key Data: Not set
..0. .... .... .... = SMK Message: Not set
Key Length: 16
Replay Counter: 2
WPA Key Nonce: 7e9e4a5a45118061996946a2cde36060dbd7cbab3c655e3c0354be29d5a87521
Key IV: 00000000000000000000000000000000
WPA Key RSC: 0000000000000000
WPA Key ID: 0000000000000000
WPA Key MIC: 00000000000000000000000000000000
WPA Key Data Length: 22
WPA Key Data: dd14000fac0477e76a18bc306a97ecb82fcc82f050ad
Tag: Vendor Specific: Ieee 802.11: RSN PMKID
Tag Number: Vendor Specific (221)
Tag length: 20
OUI: 00:0f:ac (Ieee 802.11)
Vendor Specific OUI Type: 4
Data Type: PMKID KDE (4)
PMKID: 77e76a18bc306a97ecb82fcc82f050ad
There is quite some information in this message:
- Key Information:
- Key Descriptor Version bits: the encryption and integrity protocols we use. AES and HMAC-SHA1.
- Key Type bit: the PTK
- Key Ack bit: this frame requires an acknowledgment from the client.
- Replay counter: this is used to discard retransmitted frames.
- WPA Key Nonce: the AP sends its nonce (Anonce) , which is required to derive the PTK.
- WPA Key MIC: the MIC value is set to zeroes because we can’t do an integrity check yet.
- PMKID: the ID of the PMK
The client now knows all attributes required to derive the PTK:
- PMK
- Snonce
- Anonce
- Client MAC address
- AP MAC address
The client derived the PTK, and we continued.
Message 2
The client now sends message two to the AP:
Frame 2: 155 bytes on wire (1240 bits), 155 bytes captured (1240 bits)
IEEE 802.11 QoS Data, Flags: .......T
Type/Subtype: QoS Data (0x0028)
Frame Control Field: 0x8801
.... ..00 = Version: 0
.... 10.. = Type: Data frame (2)
1000 .... = Subtype: 8
Flags: 0x01
.... ..01 = DS status: Frame from STA to DS via an AP (To DS: 1 From DS: 0) (0x1)
.... .0.. = More Fragments: This is the last fragment
.... 0... = Retry: Frame is not being retransmitted
...0 .... = PWR MGT: STA will stay up
..0. .... = More Data: No data buffered
.0.. .... = Protected flag: Data is not protected
0... .... = +HTC/Order flag: Not strictly ordered
.000 0001 0011 1010 = Duration: 314 microseconds
Receiver address: Cisco_ca:e0:c0 (24:16:1b:ca:e0:c0)
Transmitter address: be:09:77:06:31:96 (be:09:77:06:31:96)
Destination address: Cisco_ca:e0:c0 (24:16:1b:ca:e0:c0)
Source address: be:09:77:06:31:96 (be:09:77:06:31:96)
BSS Id: Cisco_ca:e0:c0 (24:16:1b:ca:e0:c0)
STA address: be:09:77:06:31:96 (be:09:77:06:31:96)
.... .... .... 0000 = Fragment number: 0
0000 0000 0000 .... = Sequence number: 0
[WLAN Flags: .......T]
Qos Control: 0x0117
Logical-Link Control
DSAP: SNAP (0xaa)
SSAP: SNAP (0xaa)
Control field: U, func=UI (0x03)
Organization Code: 00:00:00 (Xerox Corporation)
Type: 802.1X Authentication (0x888e)
802.1X Authentication
Version: 802.1X-2001 (1)
Type: Key (3)
Length: 117
Key Descriptor Type: EAPOL RSN Key (2)
[Message number: 2]
Key Information: 0x010a
.... .... .... .010 = Key Descriptor Version: AES Cipher, HMAC-SHA1 MIC (2)
.... .... .... 1... = Key Type: Pairwise Key
.... .... ..00 .... = Key Index: 0
.... .... .0.. .... = Install: Not set
.... .... 0... .... = Key ACK: Not set
.... ...1 .... .... = Key MIC: Set
.... ..0. .... .... = Secure: Not set
.... .0.. .... .... = Error: Not set
.... 0... .... .... = Request: Not set
...0 .... .... .... = Encrypted Key Data: Not set
..0. .... .... .... = SMK Message: Not set
Key Length: 0
Replay Counter: 2
WPA Key Nonce: 5ca5387e136b6aada07df88cd39247c6f910c588df5e8395f129bde29dc8b2f4
Key IV: 00000000000000000000000000000000
WPA Key RSC: 0000000000000000
WPA Key ID: 0000000000000000
WPA Key MIC: 3a1aaa2d905766505ae58c23b890885b
WPA Key Data Length: 22
WPA Key Data: 30140100000fac040100000fac040100000fac028c00
Tag: RSN Information
Tag Number: RSN Information (48)
Tag length: 20
RSN Version: 1
Group Cipher Suite: 00:0f:ac (Ieee 802.11) AES (CCM)
Group Cipher Suite OUI: 00:0f:ac (Ieee 802.11)
Group Cipher Suite type: AES (CCM) (4)
Pairwise Cipher Suite Count: 1
Pairwise Cipher Suite List 00:0f:ac (Ieee 802.11) AES (CCM)
Pairwise Cipher Suite: 00:0f:ac (Ieee 802.11) AES (CCM)
Pairwise Cipher Suite OUI: 00:0f:ac (Ieee 802.11)
Pairwise Cipher Suite type: AES (CCM) (4)
Auth Key Management (AKM) Suite Count: 1
Auth Key Management (AKM) List 00:0f:ac (Ieee 802.11) PSK
Auth Key Management (AKM) Suite: 00:0f:ac (Ieee 802.11) PSK
Auth Key Management (AKM) OUI: 00:0f:ac (Ieee 802.11)
Auth Key Management (AKM) type: PSK (2)
RSN Capabilities: 0x008c
.... .... .... ...0 = RSN Pre-Auth capabilities: Transmitter does not support pre-authentication
.... .... .... ..0. = RSN No Pairwise capabilities: Transmitter can support WEP default key 0 simultaneously with Pairwise key
.... .... .... 11.. = RSN PTKSA Replay Counter capabilities: 16 replay counters per PTKSA/GTKSA/STAKeySA (0x3)
.... .... ..00 .... = RSN GTKSA Replay Counter capabilities: 1 replay counter per PTKSA/GTKSA/STAKeySA (0x0)
.... .... .0.. .... = Management Frame Protection Required: False
.... .... 1... .... = Management Frame Protection Capable: True
.... ...0 .... .... = Joint Multi-band RSNA: False
.... ..0. .... .... = PeerKey Enabled: False
..0. .... .... .... = Extended Key ID for Individually Addressed Frames: Not supported
.0.. .... .... .... = OCVC: False
Let me explain what we see here:
- Key Information:
- Key MIC bit: the client added an integrity check to this frame so this bit is set.
- WPA Key Nonce: the Snonce from the client.
- WPA Key MIC: the value of the integrity check.
- RSN Information: contains information about the cipher suite (encryption algorithms) and the authentication method used.
When the AP receives this message, it checks if the replay counter matches the value of the replay counter in message one. If not, it discards the frame. Otherwise, it derives the PTK. The AP checks if the calculated MIC matches the MIC that the client included. If not, the frame is discarded.
The 4-way handshake is now half-way, and the client and AP have derived the PTK.
Message 3
The third message is sent from the AP to the client and includes the GTK:
Frame 3: 189 bytes on wire (1512 bits), 189 bytes captured (1512 bits)
IEEE 802.11 QoS Data, Flags: ......F.
Type/Subtype: QoS Data (0x0028)
Frame Control Field: 0x8802
.... ..00 = Version: 0
.... 10.. = Type: Data frame (2)
1000 .... = Subtype: 8
Flags: 0x02
.... ..10 = DS status: Frame from DS to a STA via AP(To DS: 0 From DS: 1) (0x2)
.... .0.. = More Fragments: This is the last fragment
.... 0... = Retry: Frame is not being retransmitted
...0 .... = PWR MGT: STA will stay up
..0. .... = More Data: No data buffered
.0.. .... = Protected flag: Data is not protected
0... .... = +HTC/Order flag: Not strictly ordered
.000 0001 0011 1010 = Duration: 314 microseconds
Receiver address: be:09:77:06:31:96 (be:09:77:06:31:96)
Transmitter address: Cisco_ca:e0:c0 (24:16:1b:ca:e0:c0)
Destination address: be:09:77:06:31:96 (be:09:77:06:31:96)
Source address: Cisco_ca:e0:c0 (24:16:1b:ca:e0:c0)
BSS Id: Cisco_ca:e0:c0 (24:16:1b:ca:e0:c0)
STA address: be:09:77:06:31:96 (be:09:77:06:31:96)
.... .... .... 0000 = Fragment number: 0
0000 0000 0001 .... = Sequence number: 1
[WLAN Flags: ......F.]
Qos Control: 0x0007
Logical-Link Control
DSAP: SNAP (0xaa)
SSAP: SNAP (0xaa)
Control field: U, func=UI (0x03)
Organization Code: 00:00:00 (Xerox Corporation)
Type: 802.1X Authentication (0x888e)
802.1X Authentication
Version: 802.1X-2004 (2)
Type: Key (3)
Length: 151
Key Descriptor Type: EAPOL RSN Key (2)
[Message number: 3]
Key Information: 0x13ca
.... .... .... .010 = Key Descriptor Version: AES Cipher, HMAC-SHA1 MIC (2)
.... .... .... 1... = Key Type: Pairwise Key
.... .... ..00 .... = Key Index: 0
.... .... .1.. .... = Install: Set
.... .... 1... .... = Key ACK: Set
.... ...1 .... .... = Key MIC: Set
.... ..1. .... .... = Secure: Set
.... .0.. .... .... = Error: Not set
.... 0... .... .... = Request: Not set
...1 .... .... .... = Encrypted Key Data: Set
..0. .... .... .... = SMK Message: Not set
Key Length: 16
Replay Counter: 3
WPA Key Nonce: 7e9e4a5a45118061996946a2cde36060dbd7cbab3c655e3c0354be29d5a87521
Key IV: 00000000000000000000000000000000
WPA Key RSC: 0000000000000000
WPA Key ID: 0000000000000000
WPA Key MIC: 3edc181cf6336de731000724ec31a91e
WPA Key Data Length: 56
WPA Key Data: 94b229ee700b8473770e5c47f217bb140f17500e329c729bf9c23ada1211f3f2ffb616e0bf47ce335a322955be11ced3cf835aeda7a3e218
Let me explain the highlighted fields:
- Key information:
- Install bit: This bit signals the client to install its derived keys.
- Key ACK bit: the client has to acknowledge this frame.
- Key MIC bit: the integrity check is present.
- Secure bit: This bit means that the initial key exchange is now complete and signals the client that from now on, the connection should switch from unsecured to secure.
- Encrypted Key Data: the GTK is included in this frame.
- Replay Counter:
- WPA Key Nonce: the Anonce from the AP.
- WPA Key MIC: the value of the integrity check.
- WPA Key Data: the GTK in an encrypted format.
When the client receives this frame, it checks these items:
- If the replay counter value has already been used.
- Whether the Anonce is the same.
- If the calculated MIC matches the value included in the frame.
If any of these checks fail, the frame is discarded, and the handshake fails. The AP has now installed the PTK and GTK.
Message 4
The fourth and last message is sent from the client to the AP:
Frame 4: 133 bytes on wire (1064 bits), 133 bytes captured (1064 bits)
IEEE 802.11 QoS Data, Flags: .......T
Type/Subtype: QoS Data (0x0028)
Frame Control Field: 0x8801
.... ..00 = Version: 0
.... 10.. = Type: Data frame (2)
1000 .... = Subtype: 8
Flags: 0x01
.... ..01 = DS status: Frame from STA to DS via an AP (To DS: 1 From DS: 0) (0x1)
.... .0.. = More Fragments: This is the last fragment
.... 0... = Retry: Frame is not being retransmitted
...0 .... = PWR MGT: STA will stay up
..0. .... = More Data: No data buffered
.0.. .... = Protected flag: Data is not protected
0... .... = +HTC/Order flag: Not strictly ordered
.000 0001 0011 1010 = Duration: 314 microseconds
Receiver address: Cisco_ca:e0:c0 (24:16:1b:ca:e0:c0)
Transmitter address: be:09:77:06:31:96 (be:09:77:06:31:96)
Destination address: Cisco_ca:e0:c0 (24:16:1b:ca:e0:c0)
Source address: be:09:77:06:31:96 (be:09:77:06:31:96)
BSS Id: Cisco_ca:e0:c0 (24:16:1b:ca:e0:c0)
STA address: be:09:77:06:31:96 (be:09:77:06:31:96)
.... .... .... 0000 = Fragment number: 0
0000 0000 0001 .... = Sequence number: 1
[WLAN Flags: .......T]
Qos Control: 0x0117
Logical-Link Control
DSAP: SNAP (0xaa)
SSAP: SNAP (0xaa)
Control field: U, func=UI (0x03)
Organization Code: 00:00:00 (Xerox Corporation)
Type: 802.1X Authentication (0x888e)
802.1X Authentication
Version: 802.1X-2001 (1)
Type: Key (3)
Length: 95
Key Descriptor Type: EAPOL RSN Key (2)
[Message number: 4]
Key Information: 0x030a
.... .... .... .010 = Key Descriptor Version: AES Cipher, HMAC-SHA1 MIC (2)
.... .... .... 1... = Key Type: Pairwise Key
.... .... ..00 .... = Key Index: 0
.... .... .0.. .... = Install: Not set
.... .... 0... .... = Key ACK: Not set
.... ...1 .... .... = Key MIC: Set
.... ..1. .... .... = Secure: Set
.... .0.. .... .... = Error: Not set
.... 0... .... .... = Request: Not set
...0 .... .... .... = Encrypted Key Data: Not set
..0. .... .... .... = SMK Message: Not set
Key Length: 0
Replay Counter: 3
WPA Key Nonce: 0000000000000000000000000000000000000000000000000000000000000000
Key IV: 00000000000000000000000000000000
WPA Key RSC: 0000000000000000
WPA Key ID: 0000000000000000
WPA Key MIC: 4694d44df9dd59ca4177cce75eea6e84
WPA Key Data Length: 0
This is what we see:
- Key information:
- Key MIC bit: this message contains a MIC value so the bit is set.
- Secure bit: This bit means that the initial key exchange is now complete and signals the AP that from now on, the connection should switch from unsecured to secure.
- Replay counter: Uses the same value as message three.
- WPA Key MIC: the MIC value.
The client has installed the PTK and GTK. The AP checks if the replay counter matches. If not, the frame is discarded. The calculated MIC is compared to the included MIC. If it isn’t the same, the frame is discarded.
The 4-way handshake is now finished, and the client and AP send encrypted frames to each other.
Conclusion
You have now learned how the WPA 4-way handshake works. WPA and WPA2 have been around for a while, and there are vulnerabilities. It is important to have a PMK that is not easy to predict. When people use weak pre-shared keys, it is possible to use a dictionary attack or brute force the 4-way handshake. The first tools such as aircrack used CPUs, newer tools such as hashcat can use GPUs which speeds up the process dramatically. Most tools are able to crack the 4-way handshake by capturing the first two messages.
WPA3 is more secure and
If you want to learn more, the 4-way handshake is covered in detail in the IEEE 802.11i amendment, or you can check the latest standard, such as IEEE 802.11-2020.
I hope you enjoyed this lesson. If you have any questions, feel free to leave a comment!
Hello Rene,
just to verify a few things here.
First of, I heared that both sides not only know the PMK but also the GMK, that is why the GTK can derived right? Essentially the entities on both sides (STA, AP) know the PMK and the GMK, correct?
My understanding is that in the 4-way handshake nothing is encrypted and basically open. So if anyone will throw up a wireshark anywhere and sees those messages in the air, and also knows the PMK somehow. He would be able to read all the data the client sends back and forth no?
So why exactly is the 4-way handshake consid
... Continue reading in our forumHello Mirko
You’re correct in your understanding that both the STA and AP know the PMK and the GMK. However, let me clarify a few things.
In the 4-way handshake, the PMK is used to derive the PTK, and the GMK is used to derive the GTK. The PTK is then used to encrypt unicast communication between the STA and AP, while the GTK is used to encrypt multicast and broadcast traffic from the AP to all STAs.
The 4-way handshake is considered secure, even though the handshake itself is not encrypted. This is because the handshake is designed in such a way that it verifi
... Continue reading in our forumHello Rene, I hope you’re doing great.
I’m concerned about this lesson, because i don’t see it on the CCNP topic lists. However, what i see is EAPOL (4-way Handshake) not WPA2 (4-way handshake).
https://learningnetwork.cisco.com/s/encor-exam-topics
Hello Chris
Indeed the WPA2 4-way handshake is not explicitly stated in the Cisco blueprint, however, in typical Cisco style, they always state a disclaimer of some sort that typically says that although these are the topics that are likely to be covered, there may still be others that are related that can also be included.
In any case, because the WPA2 4-way handshake is an integral part of how wireless networks securely operate, it has been included here to ensure that this process is understood. Although not explicitly stated in the blueprint, it may be a r
... Continue reading in our forum