Putting WPA Under the Microscope | Jacob Hegy

If you ask one hundred people what communication means, you’re gonna get a lot of answers along the lines of “being understood”, “getting your point across”, and “exchanging information”.

You ask one hundred security professionals the same question and you’re gonna spend several hours getting lectured on what kind of security risks communication poses.

In truth, the ability for any number of devices to communicate is only as efficient as their ability to ensure that only the intended recipients are listening in. Nobody cares that you can tell your whole army the battleplans if you also broadcast them to the enemy. So how does modern wi-fi address this issue? That’s what we’re here to discuss.

As you might have already guessed by the title, the answer to that is “WPA” or “wi-fi protected access”. “What is used” is a question that could be solved in seconds with a google search. Instead, we’re gonna discuss the how.

If you’re not already comfortable with wi-fi as a concept and what WPA is at a high-level, check out my article discussing both of them here. Otherwise, let’s dive in!

NOTE: This article is specifically going to discuss WPA/WPA2-PSK (Pre-Shared Key). This is the typical WPA standard used for home networks and small businesses. We’re not gonna cover WPA/WPA2-Enterprise or WPA3. Maybe in a future article, but not today. Additionally, for simplicity, we’re only covering unicast keys, not multicast keys (GTKs)

Agent 802.11

In order for devices to connect to one another over a wireless network they have to know each other exist. It’s not really viable for an access point (AP) to constantly search for every possible client, so instead what it does is it advertises itself through what’s called a “beacon frame”. These frames contain information that will help the client figure out if the AP is compatible with itself. Some examples of such info would be the upload and download speeds supported by the router, the frequency its running on, and supported cipher’s for communication.

While the AP is advertising itself, endpoints can either scan all frequencies for existing APs (passive scanning) or they can send “probe requests” (active scanning) to the broadcast address or to a specific AP based on its SSID (for all intents and purposes, SSID = name of the wireless network). A probe request is essentially the client asking for additional information needed to connect with the AP.

Once the probe request is received by the AP, a probe response is crafted and sent back. The probe response is similar to the beacon frame we saw earlier, but in addition to all the information contained in that it also contains info the endpoint needs to properly connect to with the AP.

After the probe response is received by the client, they’ll send an authentication request packet to the AP and receive an authentication response back. Basically, this is just the AP and the client both recognizing that they’re about to start a conversation with one another.

The client will then send an association request to the AP with the desired settings for the connection they want to establish. If everything checks out, the AP will respond with an association response.

At this point, the client and AP have found each other, agreed to connect, and agreed how they’ll connect. Now we get to the meat and potatoes.

TCP Eat Your Heart Out

WPA/WPA2 has what’s called a 4-way handshake. This is where the encryption keys are created by the AP and client, agreed upon, and verified.

There’s a lot going on here, so let’s break it down.

The handshake is performed for two main reasons:

1. To ensure the client has the correct pre-shared key (aka the PSK)
2. To create the encryption keys that the client and AP will use

Something I just said might have caught you off guard. Yes, the encryption keys are created. You might be wondering, “Wait, why don’t they just use the password the client used to access the wi-fi to encrypt the traffic?” The simple answer is that would mean that every wi-fi network with the same password would encrypt data the exact same. With how frequently common passwords get reused, we’d be in a scenario where just observing traffic would eventually give an attacker enough data to know the PSK.

Alright so we can’t use the PSK, now what? Well that leads us to our first derivation: the PMK.

PMK stands for “pairwise master key”. It’s created by mixing the PSK, the name of the network (aka the SSID), and some pseudorandom input to generate a new key. What it does is ensures that the network’s traffic won’t look the exact same as the traffic of another network using the same password. Great! Problem solved, right?

NOPE!

See, that’s still not enough. Even with the PMK, it’s possible for two networks using the same password with the same SSIDs to create identical traffic. This means it would still be possible to guess the PSK based on traffic alone, although it would prove to be trickier. No, we need to come up with an approach that not only takes into account the SSID of the network but also the most unique part of every connection: the user.

Enter the PTK (pairwise transient key). This is a unique key created every single time a client connects to the AP. It’s different every time and takes into account the MAC addresses of the client and AP as well as the PMK and two random numbers (referred to as SNonce for the client’s number and ANonce for the AP’s number). With all this information, the PTK takes into account the network’s password, its name, and the individual connecting on top of a bit of randomness. This means that it’s now impossible for an attacker to guess the key by just listening in on traffic.

Now, and only now, can traffic be sent between the client and the AP while being encrypted and decrypted with the PTK.

In summary, the handshake is as follows:

1. The AP creates and sends the ANonce to the client
2. Because the client has already derived the SNonce, they have all the information they need to generate the PTK. Using part of the PTK, the client creates what’s called a “Message Integrity Check” or MIC and sends that + the SNonce to the AP
3. The AP is then able to generate the PTK, verify the client’s MIC with the PTK, and send its own MIC to verify its successful generation of the PTK
4. One final message from the client to the AP is sent to confirm that all is installed correctly and they’re ready for an encrypted conversation

Conclusion

As much as that all was, there’s still a lot more to sink our teeth into with WPA, particularly on the math side and its vulnerabilities. Trust me, I want to go so in depth with this that we’re talking about the 1’s and 0’s, and we will! But to keep a long article from getting any longer, I’m leaving it here for now.

Thanks for reading! I hope you enjoyed a bit of a more educational article from me. I’ve been a tutor for about five years now, so I adore getting to dive into various topics in depth like this.

Keep your eyes peeled for two more articles I’m going to release later. One is going to discuss the actual vulnerabilities present in WPA/WPA2 and how they’re exploited. The other is going to go in depth with the algorithms that WPA uses to create its keys (this one is going to have to wait until I finish writing my implementations of said algorithms in C, so have some patience).

Besides that, that’s all for now! Catch ya later!