text 5 Jul A note about WEP and WPA

About the last thing remaining before the driver is ready for public release, is support for WEP and WPA1/2. Since a lot of people are wondering what use a wireless card driver will be if it can only connect to unsecured networks, here’s some information on the current status.

The card supports WEP, TKIP and CCMP cipher suites in hardware. This means the card can itself encrypt and decrypt the packets when the appropriate keys have been set up. However, so far I’ve only managed to get hardware decryption working. Encrypting outgoing packets seems to not work at all (going by my quick test with a packet sniffer, all packets are still sent out unencrypted). Hardware crypto is also disabled in both the FreeBSD and Linux drivers, because of several problems. These operating systems have their own wireless stacks which can encrypt/decrypt packets, but Mac OS X has no such thing (at least that I’m aware of). It seems the Apple-supplied drivers do their own encryption (either hardware or software-based).

Now: with that said, WEP works on the receive route, ie. the driver can associate with WEP-protected networks and can receive decrypted packets from the access point. However, the access point receives unencrypted packets which are then dropped. Therefore, with just one-way WEP, for all intents and purposes, the connection is unusable.

It’s the same story with WPA. So far I’ve implemented WPA1 and WPA2 with both TKIP and CCMP hardware encryption/decryption. As you can see in the screenshot below:

Image showing Airport asking for WPA password

Airport recognizes the WPA network and asks for the PSK password. The Airport user interface is severely buggy and this dialog box fails utterly. The driver is simply asked to disassociate and that’s it. Googling around points out that Network Diagnostics is a better place to establish connections to protected networks, and sure enough, once I used that, the driver was properly sent an association request with the RSN IEs (information elements) and the proper PMK keys setup.

[VoodooIntel2200BG] ASSOC: configuring adapter
[VoodooIntel2200BG] ASSOC: setting SSID to Camphor
[VoodooIntel2200BG] ASSOC: setting negotiated rates (total 12)
[VoodooIntel2200BG] ASSOC: Setting optional IEs (for RSN), length 24
[VoodooIntel2200BG] ASSOC: setting sensitivity to 51 dBm
[VoodooIntel2200BG] Setting privacy key index 0 len 32 cipher type 6 key [ ..snip.. ]
[VoodooIntel2200BG] ASSOC: Setting .11b channels tx power
[VoodooIntel2200BG] ASSOC: Setting .11g channels tx power
[VoodooIntel2200BG] ASSOC: Setting QoS parameters to non-QoS defaults for all queues
[VoodooIntel2200BG] ASSOC: Sending assoc command with ssid_len 7 bssid 00:1b:57:cc:a6:e5 dst 00:1b:57:cc:a6:e5 channel 1 policy 0x2 auth 0 capinfo 0x411 
lintval 100 bintval 100
[VoodooIntel2200BG] Authentication SUCCESSFUL.
[VoodooIntel2200BG] Notif: WE ARE ASSOCIATED!

Association with WPA-PSK networks works. I can see incoming packets which have been decrypted and can be passed up to the networking stack. However, once again, the hardware encryption doesn’t work, so no encrypted packets can be transmitted (yet).

So we have two problems here (as mentioned in an earlier post) :

  1. Airport interface is buggy, for WEP it sends Apple’s proprietary 128 bit hashed password regardless of what type of password the user has entered. For WPA it totally doesn’t work at all. “Network Diagnostics” applet (found in /System/Library/CoreServices) actually does work (not tested for WEP but works for WPA). So the ball for seamless Airport-integration is in Apple’s court now.

  2. Hardware decryption is working but encryption is not working. Hence connections are protected only one-way. To solve this, the only solution is to use software encryption (or to figure out why hardware crypto isn’t working and fix it). Software encryption for WEP is not a big problem, but for TKIP and AES, it’s a bit more involved and I’m not sure I have the expertise or the time and resources to manage this. Unless I can get hardware crypto working (which has been a source of pain for Linux and BSD devs already), WPA seems tough. I am in no mood to implement and support something like wpa_supplicant for OS X (apparently Apple does have its own RSNSupplicant but from the point of view of the driver, it’s pretty much inaccessible.)

That’s it for now.

EDIT: After some deliberation, I’ve decided to support WEP, WPA1 and WPA2 — all in software. This is made slightly easier by the availability of the excellent net80211 layer from the BSDs (which is also what Apple’s own driver for Atheros cards uses), so I don’t have to re-implement the ciphers. In fact the XNU kernel already has full AES crypto suite. This will be substantial work, though, but since I plan to include it in the VoodooIEEE80211 layer of the redesigned framework, the individual HALs won’t need to have basically anything to do with it (except supporting WEP and WPA auth/association in hardware). WPA for all!

blog comments powered by Disqus

© 2009, Prashant Vaibhav (mercurysquad). Credits: Designed by Prashanth Kamalakanthan. Content powered by Tumblr.