AirSnort — released in summer — is the practical-public WEP-key recovery tool I predicted at 75% probability in my January list. I have spent six weeks testing it; the tool works exactly as the FMS attack paper described. Time to write about what this changes.
What AirSnort does
AirSnort uses the Fluhrer-Mantin-Shamir attack on RC4 keystreams. The attack exploits a specific weakness in RC4's key-scheduling algorithm: certain initialisation vectors leak information about specific bytes of the key. With enough captured packets containing weak IVs, the key can be recovered.
The operational version: AirSnort runs on a laptop with a wireless card in monitor mode. It passively captures encrypted packets. Once it has accumulated enough weak IVs (typically 5-10 million packets), it runs the FMS attack and recovers the WEP key.
The time required depends on the network's traffic level. A busy network with substantial traffic produces enough captures in a few hours. A quiet network can take days.
What I have observed testing it
I tested AirSnort against my own home wireless network, with my own permission. The setup:
- WaveLAN PCMCIA card, Linux, AirSnort 0.2.1.
- 128-bit WEP enabled with a strong key.
- Normal home traffic levels (a few megabytes per day).
Results:
- After 4 hours of capture, AirSnort had collected about 800,000 packets but no weak IVs that produced key bytes.
- After 24 hours, ~5 million packets captured, partial key recovery.
- After 36 hours, full key recovery.
The quietness of the network was the limiting factor. On a busier network, the recovery would have been substantially faster.
For an attacker scanning for vulnerable networks, the workflow is:
- Drive around with a laptop running AirSnort.
- Identify networks (which are visible from beacon frames).
- Capture from each network for some duration.
- Run AirSnort against the captures.
- The keys for vulnerable networks come out.
This is exactly the operational reality I predicted in March 2000. The wait between research and operation was 18 months.
What this changes
Three things, in increasing order.
WEP is operationally broken. Any WEP-protected network can have its key recovered by an attacker willing to invest a few hours of capture. "WEP is enabled" is no longer a meaningful statement of security.
The wireless deployment recommendations need to change. WEP can no longer be the primary protection on a wireless network. The architecture I described in early 2000 — wireless-as-untrusted plus VPN over the top — is now the only defensible architecture.
The community is starting to demand better wireless security. Conversations on the operational lists have shifted from "how do we deploy WEP?" to "what comes after WEP?". The IEEE working groups are reportedly working on something better; deployment is years away.
What operators should do
For anyone running a wireless network:
Stop relying on WEP for confidentiality. Treat the wireless segment as the equivalent of an open public network.
Apply VPN or other application-layer encryption for any traffic that needs confidentiality. SSH for shell access; HTTPS for web; SSL/TLS for application traffic.
Firewall the wireless segment so it cannot reach internal resources directly. Wireless clients should be required to authenticate via VPN before reaching anything sensitive.
Plan for the WEP-replacement standard. When WPA (the working name for the next standard) ships, deploy it. In the interim, accept that WEP is decorative.
What this teaches
The specific point is about WEP. The general point is about cryptographic engineering quality. WEP was designed quickly to add encryption to 802.11; the design was not reviewed by mainstream cryptographers; the result has known weaknesses that were not caught at design time.
This is the same lesson as the SSH-1 weaknesses I described in 2000. Cryptographic protocols designed without rigorous review have weaknesses; the weaknesses are eventually exploited; the deployment is expensive to remediate.
The right architecture is to subject any cryptographic protocol to extensive review before deployment, and to have a clear migration path to a replacement when weaknesses are found. WEP did neither well; the replacement (WPA, eventually WPA2) is in development; the deployment will take years.
What I am doing
For my own wireless network: I disabled WEP after the AirSnort test confirmed it provides little security. The network is now an open WiFi (no WEP), with a strict firewall between it and my internal network. Any client wanting access to internal resources has to authenticate via SSH-tunnel or VPN.
For friends running wireless networks: a note explaining the situation and recommending the same architecture.
More as wireless attacks continue to mature.