Here’s the summary of the issue as described by industry security experts:
Security experts at AirTight Networks have discovered a hole in the WPA2 Wi-Fi security protocol. The security hole was named as Hole 196 after the number of the relevant page in the IEEE 802.11 (2007) standard document. At the bottom of page 196, the IEEE standard introduces the keys used by WPA2: the PTK (Pairwise Transient Key), which is unique for every Wi-Fi client and used for unicast traffic, and the GTK (Group Temporal Key) used for broadcasts. While data forgeries and spoofed mac addresses can be detected with the PTK, the GTK does not offer this functionality.
The AirTight experts say that this is the crux of the matter, because it allows a client to generate arbitrary broadcast packets which other clients respond to with information about their secret PTKs which can be decrypted by attackers. AirTight reportedly only needed to add 10 extra lines of code to the freely available open source Madwifi driver to make a PC with an off-the-shelf Wi-Fi client card spoof the MAC address of the Access Point and pretend to be the gateway for sending out traffic. Attackers could exploit this to cause damage on the network, for instance via denial-of-service (DoS) attacks. The experts say that the only factor mitigating the attack potential is that attackers need to be internal, authorised Wi-Fi users. They do not anticipate that a patch will become available because “Hole 196″ is written into the standard.
via The H-Security
Why everyone other than Meru cares
So this boils down to a simple issue that doesn’t matter when you consider Meru’s architecture is virtualized.
Basically, each client has a “Unicast” key (or a key based on a unique ID) and a “Broadcast” key that is set on a per BSSID basis and is common to every client associated with that BSSID. This is the crux of the issue. It is possible for a nefarious client to exploit that broadcast key to damage the network or potentially steal information.
In a microcell architecture, the AP acts as an Ethernet hub and everyone associates with that AP is associated with the same BSSID and is now vulnerable to the “Hole 196” vulnerability.
The question is – if the vulnerability is in the broadcast, how do you stop broadcasts on a wireless network from using the same shared key to all users when the APs act like hubs? The answer is to virtualize and make the AP act more like a switch.
Why you are safer with Meru
Since connections to Meru are controlled via Virtual Port each station has a unique BSSID generated and controlled by System Director. This means that each client now has a unique broadcast key for WPA2. This is the element of virtualization makes it impossible for a nefarious client to spoof the AP’s MAC address and exploit the broadcast key to launch security attacks (because there are no other clients with the same broadcast key and therefore no one will be exposed to the attack).
So the nefarious client will use the broadcast key based on the BSSID that Meru’s Virtual Port generates thinking its going out to everyone. In reality, the actual broadcast is not seen by anyone other than the Meru system and the attacker never has access directly to the other clients.
Conclusion
Whether or not this is an issue that will bring down the house remains to be seen. Either way the answer is again virtualization makes wireless act like an Ethernet Switch while microcell continues to remain oblivious to the limitations of Ethernet Hubs.
It will be interesting to see what Airtight has to say about this…
