802.11 Association and WPA2-PSK
Published: 03/14/2009
Wi-Fi is everywhere. One evening, I happened to be running Kismet while driving down to the burger joint one freeway exit from my house and discovered just how many hotspots were out there in my suburban residential location. I picked up roughly four hundred of them ... many completely open, many using WEP, and a smaller (but probably more informed) minority using WPA or WPA2. You'd figure that because WEP has been broken since 2001 that everyone would be scrambling to configure their wireless security defenses. Perhaps that's just a bit overly-presumptuous of me.
However, based on casual conversations I've had it seems that even WPA users have very little understanding what it means to associate + encrypt. So let's examine what passes in the air and what a potential eavesdropper sitting in her car outside your house can see when your wireless card magically makes a connection to your "wireless router." Follow along with the packet trace file below.
The Invisible Touch
The first step in any Wi-Fi connection always involves the basic 802.11 association. Unfortunately, being able to see at this level of the network stack within Windows is rather difficult without specialized hardware and drivers. That's why Linux rules and provides an avenue to gain insight without paying a dime.
When an access point is available for clients to connect, it transmits beacons roughly ten times a second. Even if it's configured to "turn the SSID off," the beacons are still sent out, although with the SSID parameter set to a null value. Anyone listening to radio signals who happens to be within range of an AP can immediately sense the presence of an access point without having to use The Force since these beacons are so frequent. This is illustrated in packets 1 through 14. Notice the amount of elapsed time between them. A beacon also contains other information regarding what kind of connection rates the AP supports, the ciphers it's configured for, vendor attributes, it's operating radio channel, the hardware address, etc.. There are some giveaway clues in the example beacons that show this is a Cisco access point model.
When the machine decides to associate to a given access point, either by just being in range or initiated by user action, the client station sends an 802.11 Probe Request (packet 15) to the broadcast address. The Probe Request contains the SSID value. The AP sends back a Probe Response (packet 16).
Next comes the 802.11 Authentication Request (packet 17) from the client followed by an Authentication Response (packet 18) from the AP. This authentication is nothing more than a protocol formality since WEP isn't being used here. It shows that this is an "Open System" 802.11 auth setup. Both the request and response contains a status code of "successful." Really exciting stuff here...
Finally, the 802.11 Association Request (packet 19) is sent from the client. This is its way of saying, "Let me in already, dammit!" The AP sends back an Association Response (packet 20) containing its capability information and other parameters. The most important thing in the packet is the status code "successful." This is probably the only thing the client cares about anyway. I mean, we all want to get inside the house when it's freezing out there.
Are we there yet?
But wait, no one can step foot inside the door yet. Both the client and AP are configured to require WPA. Do they both have the secret knock to trust each other? This is where the actual WPA process starts. The client may be associated to the access point, but not really bridged to the collision domain. Just a few more steps...
In a WPA pre-shared key system, everyone knows that there's a thing called a "passphrase" that's used as a common shared secret between members of the club. This secret value is what's used to encrypt the traffic, right? Well, it's a little bit more complicated than that. Both the client and AP take the SSID of the network, the SSID length, and the passphrase value and hashes it 4096 times to form a final 256-bit value called the Pairwise Master Key (PMK). Note that any nosy neighbor can see the SSID value and it's length just by observing the public traffic. The only secret denominator in the mix is the passphrase value. The PMK by itself isn't good enough to encrypt traffic, however. There also needs something to make the encryption keys unique to the individual connection session. This is where the 4-way handshake comes into play.
After the 802.11 association has completed, the AP sends the client a nonce (fancy word for random value). Packet 21 shows this nonce value as 3FBF64692FED5AA4E15EAF6B3A2C8E421C117EDF3CB66C59... (displayed value trails off and is not the entire string).
The client receives this, generates its own nonce, uses both nonces as well as the MAC address of both itself and the AP, generates the Pairwise Transient Key (PTK), and sends the second nonce off to to the AP (packet 22) with a Message Integrity Check (MIC) value.
The AP receives the second nonce from the client and computes the same PTK value the client came up with using both nonces as well as the MAC addresses. Bear in mind that so far, the so-called super-elite hacker sitting in the parking lot outside is able to see both nonces and the MAC addresses since those are transmitted in the clear. However, she doesn't have the PMK which is partly derived from the original passphrase value. In packet 23, the AP computes its own MIC and sends back the confirmation to the client. The nonce value contained in this packet is identical to the original nonce sent at the beginning of the 4-way handshake.
Packet 24 is essentially an acknowledgement from the client to the AP with a subliminal hint saying, "From this moment forth, we're now encrypting everything; you better have computed the right key values or else you won't decrypt anything correctly!"
All traffic for this session henceforth is now scrambled (and the client, finally bridged to the network, can start going through DHCP discovery to get an IP address). You can think of this as the client and AP getting wirelessly married (for this session) because they share an intimate love (er, secret) that only they know as a pair. The next time the client tries to associate again after the user comes back from lunch break, the same process will start all over, only this time the 4-way handshake will have different nonce values, thus making the encryption keys unique to each session. An attacker sitting in the parking lot can capture virtually all of this except for the value of the original WPA passphrase. If she knows the passphrase, she can determine the PMK. If she figures out the PMK and is able to capture the nonce values in the 4-way handshake, then she can compute the PTK and thus decrypt all traffic in real-time. Guard the value of the passphrase with your life. Swear it.
Packets 25 and 26 demonstrates what happens when the client disconnects from the station. This is assuming a clean disconnect. If the machine crashes, etc., then an 802.11 Disassociate message isn't likely to be transmitted by an operating system who has fallen and can't get up.
If an attacker knows the passphrase but is unwilling to wait until another client comes online and performs a 4-way handshake with the AP, she can simply send an 802.11 Deauthentication message (similar to packet 26) using the MAC addresses visible in the air. This causes everything to hiccup, forcing the client and AP to go through the connection establishment process all over again, and thus transmitting new nonce values. Cha-ching - she's in.
The lesson here is to choose a strong passphrase. Not a dictionary word, and not a dictionary word with some numbers at the end. Those are lame. Something similar to:
LNzMAYp5ZU6ByVivZc1H4GfE5iQSsHr1zwkFEcTasVvOl7COTdgtJF79gUVsZSC
is more appropriate and can be saved on a stashed USB key to hand out to friends for copying / pasting when they come over and need to bum off your Internet connection.
Go back to the main articles list.