802.1x on Linux with xsupplicant

Many of the well-known problems in 802.11 security are quite old and can be addressed by using 802.1x appropriately. Here's the client side.

When WEP's flaws became apparent, the wireless
industry started developing new protocols to address
the published weak points. These new protocols grew
up around the IEEE 802.1x framework, which is a way
of using the Extensible Authentication Protocol (EAP)
and all of its methods on a LAN link. 802.1x client
software programs, called supplicants, were brought
to market by operating system vendors as well as by
third-party developers.

Linux, however, initially was left out of the
802.1x frenzy. Network administrators who supported
power users were forced to rely on manual WEP-based
solutions with MAC address filtering or VPNs to secure
Linux before supplicants were widely available.
Happily, now two open-source supplicants are
bringing high-quality wireless security to Linux.
This article describes the process of setting up
xsupplicant, which is also known as Open1X.

Wireless Extensions

The wireless extensions API originally was designed
to provide a unified way of having programs interact
with drivers. Like any API, it saves developers
from having to know the details of how to interact
with every card. 802.1x supplicants, for example,
are able to use a wireless extensions system call to
set keys, rather than using card-specific calls for
every card that exists.

The wireless extensions interface has gone through
several versions. WPA support was added in wireless
extensions version 18 (WE-18). Some distributions
using the 2.6 kernel already have WE-18 support.
Older kernels need to be patched, however. My test
laptop runs Slackware, which still is using the 2.4
kernel. The 2.4 kernel has support for version 16
of wireless extensions, but patches are available for
version 2.4.30. Patch download locations appear in
the on-line Resources for this article.
Begin by applying two patches to the kernel source:

To keep modules straight, I often find it helpful when patching kernels
to edit the Makefile to include an extra version number in addition to
the patch level. My wireless extensions 18 kernel is built as 2.4.30WE18.

The most common tools used with wireless extensions are the wireless toolset, and the most common tool you will use is iwconfig. Wireless tools
version 28 is the current version and supports WE-18. Grab the source
code from the Web site (see Resources). A simple
make
command builds the tools.

Getting the Driver Going

Many cards are supported under Linux, but a handful
of drivers have captured the bulk of the popularity:

MADwifi, the Multi-band Atheros Driver for Wi-Fi:
Atheros-based cards have some of the best hardware
support for 802.11a networking. Chances are good
that if your card supports 802.11a, it uses an
Atheros-designed chip.

Intel IPW drivers for Centrino chipsets: Intel
sponsors open-source driver development projects for
the various Centrino chipsets. Due to the sheer number
of Centrino chipsets on the market, these drivers
are widely used.

orinoco_cs: the first widely used 802.11 card was
the Orinoco Gold card, based on the Hermes chipset.
These cards were sold under a variety of names,
and they all performed quite well in their day. Although the
radio performance and throughput of these cards is
no longer cutting-edge, the driver is well
understood and often serves as a testbed for new
ideas.

This article is not meant to be a definitive treatment
of working with drivers. I use Atheros-based cards
because I have an 802.11a network at home and want
a dual-band card for packet analysis. Therefore,
I am writing about MADwifi.

MADwifi has not released any packaged source files.
To use the driver, you must download the code from
CVS. The build files distributed with MADwifi
use your current kernel. If you have patched
the kernel to update wireless extensions, reboot
before building MADwifi:

Atheros-based cards do not use firmware. Instead,
they have a binary-only object called the hardware
abstraction layer (HAL). Atheros has interpreted
FCC regulations in such a way that requires the
HAL to be kept closed-source. The HAL serves the same
purpose as firmware on other cards—it implements
low-level operations for the driver. The HAL
is distributed as a uuencoded file, so you must
install the uudecode program to install the HAL.
It probably is in the shell archive utilities package
for your distribution, but the location may vary.
The OpenBSD Atheros driver includes an open-source,
reverse-engineered HAL, but it has not been ported yet
to Linux.

The kernel modules built as part of the process are
installed in your modules directory. The driver
includes its own 802.11 support layer composed of
the modules wlan, wlan_wep, wlan_tkip and so on.
The hardware-specific part of MADwifi is composed of
modules that begin with the prefix ath_: the driver
ath_pci, the HAL ath_hal and rate adaptation algorithms
(ath_rate_*). All the modules are installed in the
net/ directory.