If you're holding back on an 802.11 deployment because of security concerns, you're not alone. Research indicates that the perceived insecurity of wireless networks is a major inhibitor to further market growth.
This short history of the security issues in wireless networks should help shed some light on the problem. How the security problems affect you depends on your goals and the type of network you are building. Community networks  may be deployed to give away Internet access to the masses, and securing the network from end-user access is not a goal.
At the other extreme, a wireless extension of an internal network at a bank or other financial institution will undoubtedly require strong user authentication to prevent unauthorized users, as well as strong privacy protection to keep information confidential. In the middle are commercial "hot-spot" networks which do not need to provide privacy protection, but do need to restrict use of the network to paying customers.
It's depressing how often we see that those who don't remember history are doomed to repeat it. When cordless phones and the first analog cell phones hit the market, anybody with a scanner that operated at the right frequency could easily listen to calls not intended for them. The same cycle played out with 802.11 equipment.
Vendors first claimed that spread-spectrum modulation made it hard to build a receiver. That assertion was true in a limited sense. Traditional RF receivers listen at a narrow band for the signal, and spread spectrum uses wide bands. However, the claim is also a silly assertion because the receiver of a frame must, by definition, be able to receive and process it. Therefore, any 802.11 interface must, by definition, be the receiver that vendors claimed didn't exist.
Finding wireless networks is easy. By necessity, wireless access points must announce themselves to the world. 802.11 beacon frames, used to broadcast network parameters, are sent unencrypted. By monitoring beacon frames, wandering users with an 802.11 receiver can find out about wireless networks in the area simply by putting up an antenna. A few people made headlines by attaching high-gain antennas to their automobiles and running custom software to log the wireless networks they found while driving around .
By analogy to "war dialing" (dialing every number looking for a modem backdoor into a network), driving around looking for access points was called "war driving." War driving can be surprisingly effective. On one trip I took into San Francisco, I found half a dozen wireless networks without even trying.
Had I been serious, I would have been using a high-gain antenna mounted on the roof of my vehicle, rather than the relatively low-gain built-in antenna sitting on the passenger seat next to me, where radio signals could be blocked by the metal passenger door. Tools to assist with war driving are now famous (or infamous, if you prefer). One of the better known tools is NetStumbler. 
Once a wireless network has been located, there was originally only one standardized provision for restricting access to a wireless network in the 802.11 standard, and it required implementing WEP, the Wired Equivalent Privacy specification .
Many vendors did not implement WEP initially, and needed to develop an alternative security solution that could be deployed quickly. MAC-address filtering emerged as the solution. Like all other IEEE 802 networks, 802.11 uses 48-bit station identifiers in the frame headers. Address filtering was based on the dubious theory that IT departments are responsible for issuing wireless LAN cards to users and should therefore be able to maintain a corporate-wide list of MAC addresses allowed to connect to a wireless network. During the initial connection procedures, wireless access points can check the MAC address of connecting stations to ensure the station is on the list of known good MAC addresses.
Address filtering was never part of the standard, but it has been widely deployed anyway. It is not, however, a serious security solution. Addresses identify stations, not users. Malicious attackers with a "good" MAC address are not prevented from accessing the network. Addresses do not validate that the system software is free from tampering. Stations on the "good" list may have any number of eavesdropping programs, spyware, or Trojan horses installed. Granting access to a station with the right wireless card but the wrong software can have disastrous consequences for your network security.
Most importantly, addresses are not strong authentication. Users with sufficient operating-system privileges can alter addresses to masquerade as an allowed wireless-network user. Obtaining a list of authorized wireless stations can be done quite economically.
Sniffers can be built entirely from open-source components. To turn a Linux laptop into a sniffer, the only additional cost would be less than $100 for a wireless LAN card based on the Intersil PRISM chipset. Once an attacker has built a sniffer, all that remains is to gather a list of allowed addresses. The sniffer can be used to monitor stations which successfully associate with the wireless LAN, and then the attacker can easily adopt one of the addresses on the authorized list.
Although WEP was the first serious attempt to fix the insecurity of wireless LANs, it was hamstrung from the beginning because it was designed during the infamous era in which strong cryptographic systems fell under the same export regulations as weapons of mass destruction.
Until these rules were relaxed, the U.S. government prevented the export of cryptographic products with long key lengths. WEP secret keys were limited to 40 bits, the longest, exportable key length allowed at the time.
WEP was also limited by the complexity of 802.11 itself. The 802.11 MAC is quite complex and takes a great deal of processing power to run. The additional burden imposed by cryptography was too much for a number of early products, which simply did not implement WEP. In addition to limitations on the strength of the cryptography that could be used, WEP has always been an option feature of the standard. 802.11-compliant products do not have to implement WEP.
When it became clear that wireless networks unprotected by WEP were extremely vulnerable, users were urged to select products that implemented WEP, and WEP became the linchpin of 802.11 network security. It was, however, a flawed anchor point for security.
Two major papers, from teams at Berkeley  and the University of Maryland (UMD) , attacked the design of WEP as flawed on various grounds. The Berkeley paper demonstrated weaknesses due to key reuse and weak message authentication. The UMD paper showed the weaknesses of 802.11 access control mechanisms, even those based on WEP's cryptographic authentication.
A later paper argued that the weak message authentication made it possible to inject traffic into the network. Although long-key length versions of WEP were released to the market, the flaws in WEP were not due to a short key. The flaws persist in any version of WEP, whether a short export-crippled key is used or a reasonably long key. One member of the 802.11 working group memorably described WEP as "unsafe at any key length" and urged the working group to redesign WEP.
Though there was a great deal of discussion about redesigning WEP, the issue was finally forced in August 2001. Up until that point, WEP had been a dam resisting minor cracks and design flaws, but the torrent was now ready to sweep away any perception of WEP security.
Until this point, attacks on WEP were based on the design of the system, and most people assumed the underlying cryptography, RSA's RC4 algorithm, was sound. A paper by Scott Fluhrer, Itsik Mantin, and Adi Shamir about the method RC4 used to expand the key into a long keystream dispelled that assumption.
Fluhrer, Mantin, and Shamir found a flaw in the "key scheduling algorithm" of RC4 that made certain RC4 keys fundamentally weak, and they designed an attack that would allow a passive listener to recover the secret WEP key simply by collecting a sufficient number of frames encrypted with weak keys. They did not, however, implement the attack. Several others did, though; the first public description was from an AT&T Labs technical report. 
Open-source implementations of the attack are now widely available. One of the best-known programs is AirSnort, which was covered by the industry media when it was released. Key recovery with AirSnort takes only a few seconds once enough weakly-encrypted frames are gathered. In my experience, gathering enough frames can be done within a day, depending on your traffic load.
After August 2001, WEP was clearly in ruins. It was designed to provide both authentication and privacy, but had been shown to provide neither. To solve the user-authentication problem, the 802.11 working group adopted the 802.1x standard , which provides "per-port user authentication." It was designed to require user authentication before granting network access. It was, however, designed for a wired network, which leads to several problems.
At the heart of it all is that 802.1x was designed for a network with a fixed physical topology. The main threats to authentication traffic are that the frames may be altered, authorized sessions may be hijacked, and an imposter may impersonate the network to steal authentication credentials.
On a wired network, authentication is implicit in the connection to the network itself. Data ports on the walls almost always go to the real network infrastructure, and altering traffic as it traverses the wire is difficult. Wireless networks, however, have a very different physical topology. It is much easier to inject messages into an authentication sequence or hijack authorized sessions in the absence of strong mutual authentication and integrity checks.
Even if 802.1x is imperfect, it is a far better user-authentication solution than WEP ever was. 802.1x clients are now becoming available for many popular operating systems.
802.11i has not yet been standardized. It takes 802.1x as its base and adds several features for wireless networks. The most notable addition is that 802.11i includes a key distribution framework, which should replace the static, manually-configured WEP key. 802.11i also allows the use of the AES encryption algorithm. Some observers had hoped it would be standardized by September 2002, but skeptics are predicting it may take until mid- to late-2003 before 802.11i completes the standardization process.
This article has focused on protocol weaknesses. When protocols become products, however, a whole new class of attacks becomes available because of potentially poor implementation decisions. As an example, consider the implementation choices made for management protocols.
Several vendors use the Simple Network Management Protocol (SNMP) as an access-point management mechanism. One vendor uses SNMPv1 for access-point management, so all management traffic traverses the network unencrypted. Another vendor allowed SNMP read access to WEP keys, even though WEP keys need to remain secret. Most vendors use the cleartext telnet for remote command-line interfaces, even though OpenSSH could be licensed for incorporation into proprietary products for no charge. Web-based interfaces are nearly all plain HTTP and do not use SSL for security.
Successfully designing a wireless network may also mean designing your network around the poor security of management tools, so that network management traffic is encrypted as much as possible.
Wireless LAN security is a work in progress. The protocols are evolving to meet the needs of serious users. Until the protocols have proven themselves, the best course of action for network engineers is to assume that the link layer offers no security. Treat wireless stations as you would treat an unknown user asking for access to network resources over an untrusted network.
Polices and resources developed for remote dial-up users may be helpful because of the similarity between a wireless station and a dial-up client. Both are unknown users who must be authenticated before network access is granted, and the use of an untrusted network means that strong encryption (IPSec, SSL, or SSH) should be required. Although this cautious approach requires much more work than simply throwing up some access points, a conservative approach with several layers of defense is the best way to sleep at night.
1. Community network sites: Seattle Wireless (http://www.seattlewireless.net/), NYCwireless (http://www.nycwireless.com/)
2. News story about Peter Shipley's war driving: http://online.securityfocus.com/news/192, April 2001; maps of San Francisco war-driving results available from http://www.dis.org/wl/maps/
3. NetStumbler home page: http://www.netstumbler.com
4. The formal WEP specification is clause 8.2 of the 802.11 standard. IEEE 802 specifications are now free six months after publication. You can download the four released 802.11 specifications (802.11, 802.11a, 802.11b, and 802.11d) from http://standards.ieee.org/getieee802. The 802.11 working group home page itself is http://grouper.ieee.org/groups/802/11/.
5. Borisov, Nikita, Ian Goldberg, and David Wagner. "Intercepting Mobile Communications: The Insecurity of 802.11." Published in the proceedings of the Seventh Annual International Conference on Mobile Computing And Networking, July 16-21, 2001. Paper is at http://www.isaac.cs.berkeley.edu/isaac/mobicom.pdf; conference page is http://www.research.ibm.com/acm_sigmobile_conf_2001.
6. Arbaugh, William A., Narendar Shankar, and Y.C. Justin Wan. "Your 802.11 Wireless Network has No Clothes." March 30, 2001. Paper available from http://www.cs.umd.edu/~waa/wireless.pdf.
7. Arbaugh, William A. "An inductive chosen plaintext attack against WEP/WEP2." IEEE Document 802.11-01/230, May 2001. Paper available from http://grouper.ieee.org/groups/802/11/Documents/index.html as year 2001 document number 230.
8. Walker, Jesse R. "Unsafe at any key size; an analysis of the WEP encapsulation." IEEE Document 802.11-00/362, October 2000. Available from http://grouper.ieee.org/groups/802/11/Documents/index.html as year 2000 document number 362.
9. Fluhrer, Scott, Itsik Mantin, and Adi Shamir. "Weaknesses in the Key Scheduling Algorithm of RC4." Presented to the Eighth Annual Workshop on Selected Areas in Cryptography, August 2001. Available online from many locations; see http://downloads.securityfocus.com/library/rc4_ksaproc.pdf and http://www.crypto.com/papers/others/rc4_ksaproc.ps.
10. Stubblefield, Adam, John Ioannidis, and Aviel D. Rubin. "Using the Fluhrer, Mantin, and Shamir Attack to Break WEP." AT&T Labs Technical Report TD-4ZCPZZ. Revision 2, August 2001. Available from http://www.cs.rice.edu/~astubble/wep.
11. AirSnort home page: http://airsnort.shmoo.com
12. The 802.1x specification was approved in June 2001. It is now available for free from the Get IEEE 802 program. See the first reference for details.
13. Mishra, Arunesh, and William Arbaugh. "An Initial Security Analysis of the IEEE 802.1x Security Standard." February 6, 2001. Paper available from http://www.cs.umd.edu/~waa/1x.pdf.
Matthew Gast is the director of product management at Aerohive Networks responsible for the software that powers Aerohive's networking devices.
O'Reilly & Associates will be releasing 802.11 Wireless Networks: The Definitive Guide in April of 2002.
Return to the Wireless DevCenter.
Copyright © 2009 O'Reilly Media, Inc.