Recently I came across an interesting question on Twitter that had me intrigued as I am currently in the process of studying for my CWSP exam.  The question asked what key was used by the client to encrypt a DHCP discover packet. That’s a great question that got me thinking.

What am I referring to when I talk about keys in wireless? Are there doors in wireless that must be unlocked? As a matter of speaking there are! Within the WPA2 protocol, encryption is based upon a series of keys that are created. These keys exist in both WPA2-Enterprise as well as in WPA2-Personal (or WPA2-PSK) however the creation of these keys follows a bit of a different process between the two security types with different seeding materials being used during their creation. We will save the seeding materials discussion for another day.

As you can see in the hierarchy diagram below, the temporal keys (GTK – Group Temporal Key & PTK – Pairwise Transient Key) are based off of the master keys (GMK – Group Master Key & PMK – Pairwise Master Key), which in turn are based off of the MSK (master session key).

Key Hierarchy

When a station (STA) transmits data, it uses either the PTK or GTK to encrypt the MSDU of the frame depending upon what type of frame it is. If the packet contains multicast/broadcast traffic, the GTK is used. If the packet contains unicast traffic, the PTK is used. This is true in all cases in wireless…period…..or so I thought.

After the 4 way handshake occurs during 802.11 association when using WPA2 encryption, the DHCP process then begins. The first packet sent out by the client is the DHCP Discover (DHCPD) packet which is a broadcast packet, since the STA has no idea what DHCP servers exist (if any) in the environment. According to everything I have understood in the past, if the client does not have an IP address, it can’t send unicast packets. Well obviously since the DHCP process has not started yet, the client can’t possibly have an IP address. Therefore, logic would tell you to expect the initial DHCPD packet HAS to be encrypted with the GTK!

So lets dive into the packet captures (pcap)!!!

You can see in Figure 1 from the STA > AP, the assumption that the DHCPD packet is broadcast is validated by a packet capture of a device in my lab. As you see the destination address of the packet is in fact a broadcast address (ff:ff:ff:ff:ff:ff) circled in green.

Figure 1 : DHCP Discover from client

Now that we’ve established that this is a broadcast packet, we know based on what was stated earlier that the packet should be encrypted with the GTK right? Apparently not. If you look at Figure 1 again, in blue you will notice that the decrypted packet is showing that the PTK was used on this packet. Interesting. So what you are telling me is that my assumption was wrong, and in fact the DHCP discover packet IS encrypted using the PTK.

Maybe…keep reading 🙂

I continued to look at the pcap and 2 packets later I see another DHCP Discover packet OTA that is coming from the AP. This is expected. Since a broadcast packet was transmitted to the AP, the AP will send that packet back out to the network as a broadcast packet due to the nature of how broadcast traffic works. This is where is gets interesting though.

If we take a look at Figure 2 we will see that this time a DHCP discover packet (broadcast) is sent from the AP > STAs.

Figure 2 : DHCP Discover from AP

Again as we did previously, we confirm the packet is broadcast by looking at the destination address and finding a broadcast address (ff:ff:ff:ff:ff:ff) circled in green. We show in red that this packet is from the AP by noticing the transmitter addresss (TA) is the ArubaNet_2c:5f:70. Ok so here we are again, if the packet is broadcast it HAS to be encrypted using the GTK. If you notice in Figure 2, sure enough this time circled in blue we have a packet encrypted using the GTK. Finally!

So what’s correct? That’s an interesting question. I continued to evaluate a few more packets and found that the occurrence above was the same for ARP packets. As shown in Figure 3, you see that from the STA > AP, the broadcast packet is encrypted using the PTK in blue.

Figure 3 : ARP from client

While in Figure 4, the packet from the AP > STAs is encrypted using the GTK in blue.

Figure 4 : ARP from AP

Based on these captures, it appears that while broadcast/multicast should use the GTK and unicast should use the PTK, that isn’t always the case. It would appear that in fact, if the client is transmitting broadcast/multicast traffic it chooses to use the PTK instead of what I expected to be the GTK.

If you think about it, this is the expected behavior. Since the client is transmitting the request to the AP and not to other stations, the client uses the PTK to ensure no one besides the AP can decrypt. A deeper understanding of why this is, can be found by researching the 4 address system (receiver, transmitter, source, & destination) that is used in 802.11. Thus, when the wired network forwards the packet back out to the entire broadcast domain (which now includes the wireless clients on that VLAN) all stations need to be able to see it.

Did I miss something? Post your comments below!

-Scott