Hole196 debunked?

Mika/ August 1, 2010/ Security

(Warning: some technical details, not suited for the TL;DR type of audience)

“WPA2 vulnerability discovered” was a headline that caught my attention for several reasons:

  1. Someone detected a security flaw in 802.11 RSNA (vulgo “WPA2”) that slipped Chuck Norris’ attention for 3 years (replace the name with any respected security researcher).
  2. It’s from a Best-of-breed, Award-winning, World-market-leader etc… company. Reminds me of the CfP submission we received from Ligatt Security. But maybe (hopefully) I’m wrong.
  3. Virtually all results of the search engine you prefer point to a copy&paste of the press release without any details (as of Jul 28th). Is this just a result of our copy&paste journalism?
  4. I have the impression, that nobody verified the possibility in detail. For example JJ from “Security Uncorked” writes (although expressing clear doubt about the impact): “Without reading the entire 1,000+ pages of the standard again, my understanding is the threat is limited …” (http://securityuncorked.com/2010/07/smoke-and-mirrors-the-upcoming-defcon-wpa2-crack/)

Let’s take a look at the claims:

Claim 1:

“WPA2 uses two types of keys: 1) Pairwise Transient Key (PTK), which is unique to each client, for protecting unicast traffic; and 2) Group Temporal Key (GTK) to protect broadcast data sent to multiple clients in a network. PTKs can detect address spoofing and data forgery. “GTKs do not have this property,” according to page 196 of the IEEE 802.11 standard.”

Granted, this is inherent to cryptographically secured group addressing with shared keys or any shared key between a larger group. Look at IPsec GDOI (Group Domain of Interpretation) for example or some IPsec Remote Access Solutions with a group name and key. They have similar issues and these are communicated clearly.

The IEEE 802.11 standard states clearly in RNSA some assumptions about security, specifically in clause 8.1.5 h):

(It is assumed that) “The destination STA chosen by the transmitter is the correct destination. For example, Address Resolution Protocol (ARP) and Internet Control Message Protocol (ICMP) are methods of determining the destination STA MAC address that are not secure from attacks by other members of the ESS. One of the possible solutions to this problem might be for the STA to send or receive only frames whose final DA or SA are the AP and for the AP to provide a network layer routing function. However, such solutions are outside the scope of this standard.”

Let me translate that for you: “WPA2 does not verify the identity of the sender of a broadcast/multicast frame, thus putting ARP, ICMP and others at risk. We know about that but it is not our goal to do anything about it. No “hidden vulnerability” or big surprise so far…

Claim 2:

“Because a client has the GTK protocol for receiving broadcast traffic, the user of that client device could exploit GTK to create its own broadcast packet. From there, clients will respond to the sending MAC address with their own private key information.”

Besides of the unusual wording “…has the GTK protocol…” this claim is dificult for me to identify in the current standard of 802.11 http://standards.ieee.org/getieee802/download/802.11-2007.pdf.

Sure, a client, associated to the same SSID will be in possession of the valid Group Temporal Key (GTK) and there is no mechanism to verify the Sender’s MAC address. We talked about that.

Let’s assume we are talking about CCMP (everything else, like TKIP, would be flogging dead horses).

CCMP (Counter Mode with Cipher Block Chaining Message Authentication Code Protocol) is the current recommendation to secure 802.11 and this should be the reference for any breaking news. TKIP was a standard introduced to enable pre-RSNA (resp. pre-WPA2) Stations to implement RSNA (“WPA2”).

Looking at the involved keys:

the GTK is formed used the following function:
GTK <- PRF-X(GMK, “Group key expansion” || AA || GNonce) according to 802.11-2007 clause 8.5.1.3 Group Key Hierarchy. Where the GNonce is contributed by and known only to the 801.1X authenticator (the Access Point), AA is the MAC address of the authenticator and GMK is the Group Master Key, a random generated by the authenticator and finally the constant string “Group key expansion”. PRF-X is a pseudo random function. The GTK is distributed via message 3 of the 4 way handshake.

Now we have a group key, which is distributed via EAPOL to all clients associated with the SSID during the authentication phase and -naturally- allows spoofed messages. No surprise here.

But how could a station be tricked into revealing information about the Pairwise Transient Key (PTK) in response to broadcast?

Let’s take a closer look at GTK and PMK:

PTKs are used between a single Supplicant and a single Authenticator (from the authentication phase). The PTK is derived from the PMK (Pairwise Master Key), which is either derived from the Pre Shared Key of “WPA2” or the first 256 bits of the Master Session Key, derived from the EAP authentication. Here is the formula for generating the 384 bit PTK:

PTK <- PRF-X(PMK, “Pairwise key expansion”, Min(AA,SPA) || Max(AA,SPA) || Min(ANonce,SNonce) || Max(ANonce,SNonce))

For CCMP: PRF-X is a 384 bit pseudo random function, PMK is the mentioned pairwise master key, Min(AA,SPA) is the smaller Mac address of Authenticator or Supplicant, Max(AA,SPA) is the larger, similar for the nonces, which are random values for a single authentication process.

Finally, TK (the actual key used for encrypting/decrypting with AES-CCMP) is taken from the last 128 bit of that PTK.

I could not find any frame or exchange in the standard that would use or re-use any of the key material of the PMK generation. So where is the “information about the PMK” sent to the attacker after receiving a spoofed broadcast?

If the attacker used it’s own MAC address, the response could result in the negotiation of a STSL Masterkey (station to station link master key) which uses none of the PMK material.

If that spoofed frame would be a EAPOL frame for triggering a 4-way handshake for SMK the nonce of the 4-way handshake message 1 would be different from the nonce used to generate the PMK (Snonce respectively Inonce). Still I don’t see any revealing of the PMK. BTW, the SMK handshake, which is done before the 4-way handshake to verify the SMK, runs through the AP and consits of six messages. Communication between stations (SMK Initiator or SMK Peer) is protected by the PMK, reps. TK and verified with the AES-MIC (message Integrity Code) from the original authentication process.

Maybe I’m blind -I admit that I sometimes don’t see the Wood for the trees. But I just don’t see it.

Either there is something hidden about claim 2 of Hole196 or some assumptions of IEEE 802.11 are ignored or exploits of secondary issues are addressed which are beyond the scope of the 802.11 framework. Or the hole thing is really just a marketing stunt to achieve some publicity.

Now, a couple of days after the presentation, more and more doubt rises about the actual impact of Hole196:

  • Aerohive’s Matthew Gast, who’s also chairman of the Wi-Fi Alliance’s Technical Security Working Group thinks: “To say that the specification had a “little-known vulnerability” regarding group keys is an overstatement. ”
    http://blog.aerohive.com/blog/?p=362

What can we learn from that?

  • Bad news is not always as bad as it seems – look at it carefully, use wise judgment and common sense. Just because a myriad of unreflected reposts of the same vague claim are flooding the Internet and news channels doesn’t make the claim more trustworthy.
  • Mainstream media can’t verify every message. They do not have the experts and time to go into details. Wait for detailed analysis and responses before you panic and howl with the crowd.
  • Announcing something with vague claims and and acting like a carnival barker doesn’t always rise one’s reputation.
  • And last not least (this applies especially to me): do not put anyone in doubt unless you completely understand every detail and everything involved. I did not go through every algorithm, every negotiation and every exchange of 802.11 in detail. There might still be something lurking in the depths of a 1233-page standard but it might not have something to do with Hole196. My judgment is therefore incomplete and I might have missed something. But I take the risk of saying something stupid, the details I have found are too tempting to do so.
Share this Post