by Rik Farrow <rik@spirit.com>
You would have to be living in a cave not to have heard about the problems with wireless security for networking. Even as more organizations (and homes) take advantage of wireless networking, we hear about "war driving" and that the security features were poorly designed.
WEP (Wireless Equivalent Privacy) was intended to provide the same level of privacy over wireless networks that one would expect from wired networks. WEP is part of the IEEE 802.11 standard document, and defines how encryption must be used to support authentication, integrity, and confidentiality of packets transmitted using wireless equipment. ALl the wireless vendors support 802.11. The IEEE standards committee chose to use RC4, a proven encryption algorithm.
But designing systems that use cryptographic tools has often proved harder than it appears. Let's take a look at just how 802.11 networks work, and see just where the problems lie, and what, if anything, can be done to mitigate the problems.
War driving is, in itself, harmless activity. By equipping yourself with a wireless card, like an Cisco or Orinoco PC card for a laptop, and running some special software, you can discover wireless networks while simply driving with the wireless antenna sitting on your dashboard. Whenever you come within range of a wireless network, the SSID (Service Set Identifiers), MAC address, and whether or not WEP is in use will be displayed on your screen. As an added embellishment, you can include a GPS receiver in your setup, so that the physical coordinates of the wireless signal get logged as well.
It is what you do next that can quickly move you into troublesome territory, as electronic eavesdropping is definitely against Federal law. But so far, all you have done is monitor management frames that get broadcast to identify that SSID of the wireless network. By definition, a broadcast annoucement hardly constitutes communications that you expect to keep private. But already anyone who is willing to eavesdrop has learned your location, and your SSID. In many cases, the SSID will be the name of the organization (depending on how the network was configured), so for the bad guy, this part is easy.
Some wireless vendors have added features that are not part of the standard to control access to their networks. One vendor uses the SSID as an access token--which is quite worthless, as Macintosh wireless cards actually list the SSID received and give the user the option to choose one to join. Others have used access control based on the MAC (Media Access Control) address, but all wireless cards today allow you to change this address under software control.
An access point, the device that sits on your internal network and acts as a bridge between the wired and wireless portions of your network, can also be configured to require authentication. The access point sends out a challenge, and any workstation wishing to join the network must use a secret shared with the access point to encrypt the challenge and join the wireless network.
This sounds fine, but in reality, it is broken.
WEP uses RC4, a stream cipher identical to the encryption scheme successfully used in SSL (Secure Sockets Layer) to protect Web transactions. RC4 works great when used with SSL because each transaction (or set of transactions, see past NetDef article) gets assigned a unique, 128 bit key. While extensions to WEP permit the use of 128 bit keys, the design of WEP makes this a practically worthless addition.
So, what's broken in WEP? The weakness in WEP all has to do with
something called the Initialization Vector, or IV, and the use of
RC4. RC4 takes an encryption key and generates a pseudorandom
stream of bytes, called the keystream. The keystream is pseudorandom
in the sense
that a different key is guaranteed to produce a different keystream, but the
same key always produces the keystream. Next, each
byte that you want to encrypt is XOR'd (exclusive OR'd, a logical
operation) with the correspoding byte in the keystream, encrypting
it. To decrypt, the same keystream gets XOR'd with the ciphertext.
Only systems that know the key used to generate the keystream can
successfully decrypt an encrypted (ciphertext) message.
The keys used in WEP are a combination of shared secrets and the IV. The shared secrets get installed during the configuration process for most devices. The secrets can be entered as hexadecimal values, or as strings that get converted to keys using a key generator. The key generator used by most wireless vendors uses the same algorithm to convert strings into the keys used, but in doing so, actually throws away most of the randomness contained in the string you entered as the secret key. In a presentation at the 2001 Black Hat conference, Timothy Newsham, of Atstake, demonstrated a tool that could crack WEP keys created using the generator in fractions of a second (worse case, 35 seconds for a 104 bit key). Newsham's recommendation is that you enter hex values when setting keys--a very good bit of advice, even though it is less convenient.
Newsham's discovery sounds pretty bad. But it gets worse. Earlier, I mentioned a challenge-response sequence for authentication. The access point sends out a challenge and the systems wishing to authenticate encrypts the response and sends it back. To complete the authentication process, the access point must also encrypt a challenge, but for an attacker, this can be ignored.
What an attacker can do is sniff the wireless network, and capture a challenge-response authentication sequence that succeeded, which will be evident when the workstation begins to exchange traffic. The attacker then takes the challenge, XOR's it with the response, and now has the keystream that was used by RC4. The attacker can now use this keystream to authenticate a challenge from the access point and authenticate to the wireless network, without knowing the key (which is based on the shared secret). This might sound like voodoo, but it is based upon how RC4 works, and I suggest you read the papers in the Resources for more details.
Even though the attacker has authenticated, using just two sniffed messages to compute the keystream, the attacker still does not know the key, so joining the network looks like a futile excercise. All traffic is still encrypted, and the purloined keystream is very little help. But, there are still more weaknesses in WEP that the attacker can use.
If the shared secret alone was used as the encryption key, WEP would be an even worse disaster. Instead, the IV mentioned earlier gets appended to the shared secret. The IV used in WEP is 24 bits long, so the shared secret provides 40 bits of the key for a 64 bit key (40+24), or 104 bits of a key for a 128 bit key. Since the participants in a wireless network only know the shared secret, the IV is send as plaintext, not encrypted, with every packet. The IV gets incremented with every packet, appended to the shared secret, so a different key gets used to generate every packet.
This is important because RC4 uses the XOR operation, and if the attacker can collect two or more packets with the same IV, the key will also be the same, and the keystream might be acquired. There are cryptographic attacks for acquiring the keystream given two packets encrypted using the same keystream (again, by XOR'ing the packets together and performing cryptanalysis). But, there are simpler attacks.
Ian Goldberg, of University of California, Berkeley, also spoke at Black Hat 2001, and described a whole array of different attacks. A simple one involves sending ping packets to a workstation on the wireless network and sniffing the encrypted data. When you send a ping packet (ICMP Echo request), you can pad it with whatever data you wish, so it is possible to send known data to the target system. When you collect the encrypted version, you then XOR it with the data you sent as padding, and recover the keystream (ignoring for the moment that the IP and ICMP header are there too, but those bytes can easily be predicted as well). The attacker needs to do this for each of the 2 to the 24th (over 16 million) IVs, but once this is complete, the attacker now can decrypt (or encrypt) any traffic on the wireless network until the key is changed.
This attack might seem ridiculous. After all, how long would it take to collect 16 million packets? Well, it could be done in a few hours, and the data (the keystreams) could be stored on a 24 GB drive, indexed by the IV's. But it's worse than this. Every time an 802.11 card is restarted, it re-initializes the IV to zero. So everytime a system is rebooted, or a notebook comes within range of a WEP-protected network, the IV begins at zero. You don't really need to collect 16 million keystreams in many cases.
Goldberg went on to describe three more attacks, all quite feasible, and none requiring sniffing long enough to collect a quantity of keystreams. But cryptographers (see the Fluher et all paper) have come up with yet another attack on the way RC4 is used with WEP. By collecting between 4 and six million packets (actually, only the first couple bytes of encrypted data are required), they theorized a way to recover the shared secret used to generate the key. Briefly, there are weaknesses in some fraction of RC4 keys that provide hints at the composition of the bits within the keys, and by looking at the second byte encrypted, they postulated that the key could be recovered. There are now two different tools written that can recover the shared secret used in WEP, even when 128 bit keys are used.
WEP has more problems, all stemming from its design. It is possible to change encrypted messages without evening knowing either the key or the keystream. Bits can be flipped in the message, and the integrity check, a 32 bit checksum, can easily be modified as well so that it appear correct when the packet is decrypted. You might wonder at the importance of this, but just consider what changing a few bits in a financial transaction might do--a couple more zeroes in the right place makes a big difference.
Designing protocols that use cryptography is more difficult than it seems. The IEEE 802.11 committee is working on fixing the standard. Suggestions include using a longer IV so that the effective key space is larger, and using a block cipher instead of a streaming cipher. Also, the checksum used for integrity needs to include the keying material to be effective.
Some vendors have come out with tools to dynamically change keys, and while this helps some, it does not fix the basic problem. For the time being, assume that whatever data you send or received over a wireless network can be sniffed (up to miles away if a large dish antenna is used with an amplifier), and encrypt all your data using VPN software. Also, consider locating any wireless access points outside your firewall in the DMZ. Effectively, wireless today operates outside your organization just like it does inside. The emporer, or 802.11 and its current variants, has no encryption.
If you are using WEP to protect a wireless, home, network, you probably have little to worry about. While WEP will not protect against a determined attacker, how likely is it that you will face someone who will spend a day or more of determined effort to crack your home network? Keep in mind that if you do use passphrase-generated keys, then the time to crack your WEP encryption key will be seconds. But, without this poorly generated key, WEP is sufficient for most home networks.
A great page of links, including Jess Walker's and the Berkeley paper, and an explanation of 802.11: http://www.cs.umd.edu/~waa/wireless.html
Early release of software for cracking the WEP encryption in 802.11b: http://sourceforge.net/projects/wepcrack/ (also /airsnort).
The Fluhrer, Mantin, and Shamir paper explaining how to crack WEP: http://www.eyetap.org/~rguerra/toronto2001/rc4_ksaproc.pdf
IEEE Standard 802.11 standards, paper (by order) or PDF: http://standards.ieee.org/catalog/IEEE802.11.html
An interview with Peter Shipley about war driving: http://www.starkrealities.com/shipley.html
An article by Lisa Phifer provides information about initiatives for "fixing" the security problems of WEP (and appeared months after this article was first published): Better Than Wep.