Contributed by johan on from the is-wire-less-wire-more? dept.
Federico Biancuzzi wrote to us about the latest issue of BSD Magazine which is dedicated to OpenBSD, read on for his story:
The following interview with wireless developer Damien Bergamini has been published in the recent BSD Magazine issue fully dedicated to OpenBSD. Now that release 4.4 is out, I am happy to be able to share this interview that covers the new support for WPA, a topic that didn't make the traditional release interview.
Could you introduce yourself?
I'm French, I'm 28 years old. I'm an OpenBSD developer since 2004. I've written numerous drivers for 802.11 wireless devices, and lately, I added support for WPA-PSK (Wi-Fi Protected Access using pre-shared keys) to our generic 802.11 layer.
What type of difficulties did you have to overcome to implement WPA/WPA2?
The reason it took a long time to implement WPA in OpenBSD is that the various standards that make WPA are fairly complicated. It's a steep learning curve. Of course we could have thrown in whatever existing WPA implementation that would have made the trick but this is not the way we operate in OpenBSD.
OpenBSD tends to be more quality-driven than feature-driven. Before we import a large piece of code in the base system, we must make sure someone in OpenBSD can maintain that code and can fix it should it break. This means at least one developer must fully master that code and be very comfortable with it. We prefer to not support a feature rather than import code we cannot maintain. Although this may be frustrated for our users sometimes, this is a winning strategy in the end.
Before beginning my work on WPA, I studied various existing WPA implementations (mostly wpa_supplicant, hostapd and xsupplicant) but I did not like their design so I decided to write my own implementation from scratch, taking a very different approach.
What differences do you see in OpenBSD's WPA implementation compared with other BSDs' ones?
Other BSDs use wpa_supplicant for client mode and hostapd for AP mode.
The reason I chose to not go that road is that wpa_supplicant and hostapd are rather huge (in terms of lines of code) and that they try to implement too many things at the same time (802.1X, 802.11i, EAPs). I particularly did not like the way those tools were reimplementing parts of the 802.11 management entity (MLME) in userspace. This is very redundant with what we already do in the kernel, and it requires that the kernel implement hooks to let the userspace play with the 802.11 management state machine.
In OpenBSD, support for 802.11i is fully implemented in the kernel (in our generic 802.11 layer) because this is the natural place to do it (this is where we keep all the information and states about APs and stations.) As a result, you can setup a WPA-PSK network (AP or client mode) without running any external daemon. You only need to know one command: ifconfig.
However, in OpenBSD, we do not support WPA-Enterprise yet, while other BSDs support it. But this is something I'm actively working on. I'd like to implement the 802.1X PACP protocol in the kernel (both supplicant and authenticator state machines) for both wired and wireless interfaces. Then I'll implement some of the most used EAPs.
Does running WPA in the kernel increase the security risk?
Not at all. In this particular case, I would say quite the opposite because implementing the 4-way handshake and group key handshake in userspace require that you to let the userspace control the 802.11 kernel state machine which is very error-prone given that the 802.11 state machine is quite complicated and that not all drivers handle all the possible state transitions properly, especially those that implement the 802.11 state machine in firmware.
Considering that your implementation runs in the kernel, do you see any performance advantage over the other implementations?
No. Except for software encryption/decryption (that other OSes do in the kernel too), WPA is not performance critical. It consists in the exchange of a small number of packets (4 for the 4-way handshake) between the supplicant (the client) and the authenticator (the access point). This does not require any special optimization.
Is there any work on performance improvements or power saving for wifi drivers?
I'm currently adding hardware crypto support for more chipsets. This should help a bit performance-wise. I'm also working on supporting stations in power-save mode when operating as an access point.
I remember that you used only software crypto for WEP, instead of the features included in some chips. Is this still true? What about modern WPA-compliant chips? What advantages do you have using software crypto and opensource drivers?
That is not exactly true. Some drivers were already doing WEP in hardware, however, because CCMP is more costly to do in software, it will become critical to support hardware crypto for more devices. I've already implemented hardware crypto for TKIP and CCMP in the Ralink RT2860 driver to make sure our net80211 design was clean enough to allow for both types of crypto.
I'm now working on other drivers, like wpi(4) and iwn(4). Some crypto engines are so badly designed though that supporting them will offer little to no performance benefit (because, for instance, even if the device supports scatter/gather, the crypto engine does not, and you have to copy every outgoing packet). For these devices we will continue to use the software crypto code.
OpenBSD developed a lot of drivers for wireless chips using reverse engineering. We saw some exploits for closed-source drivers provided by vendors. Were your drivers vulnerable? What type of measures did you adopt to improve wireless drivers security?
Offering open-source drivers does not guarantee that no vulnerability will ever be found. However, you do not need to wait for the vendor (or the developer that wrote the driver under an NDA) to fix that vulnerability.
How are your relationships with vendors? Do they offer you access to datasheets and specs without NDA agreements? Do they let you redistribute their firmwares?
Only a few vendors provide datasheets without NDAs. Ralink is one of them. Zydas also provided some documentation for their USB chipsets before they got bought by Atheros. There was some documentation available for the earliest Realtek chipsets too, but I'm not sure it's still the case for their latest chipsets. Some vendors, like Intel or Marvell, provide open-source Linux drivers but no documentation. The worst players are Atheros and Broadcom, though things may change with Atheros in the future.
From a security point of view what setup would you suggest for a wireless network?
For a home network, WPA2-PSK (with 256-bit AES) is a good compromise between security and ease of configuration. WPA2-Enterprise or IPSEC are equally good solutions for enterprise networks.
What reasons do you see to deploy an OpenBSD based access point instead of using one of those cheap little boxes?
Of course, you can always use a classical access point as a bridge if you want, but it is a bit of an overkill if you want to build something small. With the support of more embedded systems in OpenBSD (armish, socppc ports), it becomes even more important to have a good support for AP mode. This way you can for example setup a smaller NAS with Wi-Fi support, and all the good things that OpenBSD brings to you (pf, etc).
Any thought on 802.11n?
802.11n is not yet standardized at the time of this writing [May 2008]. It is not yet supported in OpenBSD.
Although we already have drivers for 802.11n devices, they only support 802.11g mode for now. Some parts of the 802.11n specification are very complicated to implement (like block ACK sessions) while the performance gain in a real-life setup is not clear at all. I don't buy the argument about the improved speed in 802.11n at all. Anyway, I'm planning to work on 802.11n at some point, but there are more important things to do first, like multi-bss support and improved power management.
Thanks for sharing this with us Federico, your articles always make a nice read.
(Comments are closed)