Through the miracle of wireless communication technology, you can send secure confidential information over open, shared airwaves. In its 802.11 wireless LAN (WLAN) standard, the IEEE has included built-in security mechanisms to provide confidentiality, access control, and data integrity for information that travels through the air. But is the technology as secure as it promises to be?
Recent discoveries suggest that the 802.11 standard has serious security flaws that can permit attackers to perform simple attacks to gain access to your confidential information. These discoveries seriously undermine both the IEEE's claims about its standard and many vendors' claims about the security of wireless products that use the 802.11 standard. To understand 802.11's flaws, you need to delve into the inner workings of the Wired Equivalent Privacy (WEP) protocol and the protocol's RC4 encryption algorithm.
Challenging WEP
Wireless communication has been around for years, but only recently has it ascended to the status of a mainstream communication method. Portable devices (e.g., PDAs, cell phones, laptops) have proliferated, giving mobile users access to email accounts, Internet sites, online banking, and the stock exchange. This proliferation has led to WLAN vendors scurrying to develop proprietary wireless network solutions and application vendors hurrying to code new wireless programs.
Wireless communication devices use a different protocol stack and different programming languages from those of wired-LAN PCs and servers. The need for a different protocol stack is due to these devices' lack of resources (e.g., CPU power, memory, storage) and limited power and display capabilities. In an attempt to provide a connection as secure as that of an equivalent wired communication path, the 802.11 standard implements the WEP protocol, which uses a cyclical redundancy check (CRC) for data integrity and the RC4 stream cipher for encryption and decryption. WEP's developers claim that because WEP handles only encrypted messages, the protocol obstructs eavesdropping attempts and controls access to the destination computer.
Challenging these claims, a research group at the University of California, Berkeley, has demonstrated how specific attacks can compromise any wireless communication that uses WEP. (For a detailed analysis of this group's findings, go to http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html.) The group used passive eavesdropping attacks to intercept and decrypt traffic, redirected IP traffic from a wireless connection to the group's computers, used dictionary attacks to decrypt traffic in realtime, and used active attacks to inject new traffic from unauthorized wireless devices. Using only a laptop, a wireless Ethernet interface card, and a NIC driver, the group modified the driver and was able to decrypt and read data traveling from a wireless device to a base station.
CRC and Data Integrity
When a user sends information from an 802.11 wireless device to a destination computer, the message passes through a CRC function—an error-detection mechanism that returns a checksum value—before the message is encrypted. The same algorithm processes the decrypted message at the destination computer to obtain a value. If the values at both ends of the transmission are the same, the destination computer assumes that no one modified the message during transmission and accepts the message. The CRC process is designed to ensure data integrity.
If an attacker can compromise the CRC functionality (by flipping certain bits within the message), he or she can modify the original plaintext message—and the receiving computer won't detect the modification. The Berkeley group demonstrated that successful modification of the plaintext message and the CRC value is possible—which means that an attacker can alter a message during transmission and that the recipient would be unaware of the intrusion.
The ramifications of this discovery are twofold: First, if an attacker captures a packet over the airwaves, he or she can change the packet's contents and the receiving computer wouldn't recognize a problem until the computer had suffered the damage that the encryption and CRC should have protected it from. For example, the attacker could change the contents of a packet that contained the command
cd\
to
echo y | format C: /s
which would format the C drive. Second, the attacker can redirect traffic. If the attacker captured data during transmission and changed the sending IP address, any replies to that packet's request would go to the attacker instead of the intended user.
RC4 Encryption
After a wireless device runs a message through the CRC function for data-integrity purposes, it must encrypt the message before sending it to the base station (which is the access point to the network) or another wireless device. Various encryption algorithms and schemes are used all over the Internet and on individual LANs. WEP uses the RC4 stream cipher as its encryption algorithm. Although each algorithm's mathematics are unique and each encryption scheme depends on different components—an initialization vector (IV), an integrity check value (ICV), a key, a keystream—each algorithm has the same basic functionality: to protect the transmission of confidential information. All stream encryption algorithms use a keystream to transform the plaintext message into an undecipherable form called ciphertext.
Most algorithms are publicly available. Therefore, you need to make your keystream as complex as possible. Unfortunately, the 802.11 standard doesn't specify the necessary steps you need to take to ensure the input of random components (i.e., the key and IV), which would result in a complex and more random keystream. Therefore, vendors commonly implement methods that use redundant keys and IV values, resulting in a noncomplex keystream.
The RC4 encryption algorithm's keystream is a long sequence of pseudorandom bytes that performs an exclusive OR (XOR) logic function against the plaintext message to create the ciphertext. If an attacker obtains the keystream that encrypted a message, he or she needs only to reverse the process to acquire the plaintext message.
The RC4 stream cipher uses two components to derive a keystream: a secret key and a cleartext IV. Each user in an organization can have a unique secret key, or all users can share the same key. The 802.11 standard doesn't outline a method for providing each user a different key, so in many organizations, all users have the same key. The IV is a random, publicly available number with a maximum of only 24 bits. If an organization uses one secret key for all its users, the IV must use every possible available value; otherwise, the keystreams will be redundant and easier to crack. This scenario relies heavily on the IV's randomness to ensure that each keystream is unique. However, because the 802.11 standard allocates only 24 bits for the IV value—or 224 possibilities—all available unique values will be used up in less than a day. The result is reused IV values and reused keystreams.
To decrypt any message that passes between devices, an attacker needs only to learn the different keystreams that a network uses. Your goal is to use the widest possible range of IV values to make your keystreams unobtainable and unpredictable. The more IV values available to the wireless device for calculating keystreams, the more keystreams the attacker needs to uncover and record. However, the 802.11 standard further compounds the problem by failing to specify that the IV value must use at least all 224 possibilities. As a result, most vendors use only a handful of IV values. So, not only is 224 not enough, but most implementations don't even use that many.
Calculating the Keystream
WEP's major flaws relate to the way that it generates IVs. Under the 802.11 security architecture, WEP's weaknesses permit quick deduction of the keystream. After an attacker determines the keystream, decrypting future packets is simply a matter of effort and patience.
So far, you understand the following:
I want to explore the weakness in this equation—that is, the calculation of the keystream.
WEP doesn't dictate the method of IV calculation for each packet and doesn't require that each packet have a different IV value. These limitations have led many vendors to implement elementary and predictable IV calculations, which drastically reduce the number of unique keystreams that a network uses. If a device sets the IV value to 0 at each reboot and increments the value by 1 each time the NIC initializes, that device might be limited to IV values of 0 through 4. Binary math dictates that the resulting 25 possibilities produce only as many as 32 possible IV values—which obviously wouldn't provide the necessary complexity for an effective security mechanism. One wireless device can generate thousands of packets daily. Multiply those thousands by the number of wireless devices you have on your network, and you'll have some idea of the number of packets—each with a corresponding IV value—traveling across your wireless network each day.
The WEP protocol transmits the IV value in clear text along with the ciphertext. Therefore, to obtain the IV values that a network is using, an attacker needs only to passively eavesdrop on wireless network traffic. If the attacker finds two messages that use the same IV value, he or she can simply perform an XOR function against those two messages. (The XOR function requires two pieces of data.) The attacker can then obtain the two plaintext message's XOR values. Because IP traffic is often predictable and includes much redundancy, knowledge of these XOR values lets the attacker perform statistical attacks to ultimately recover the plaintext messages.
After an attacker has the plaintext and ciphertext values, a few simple calculations—plugged into the previously stated equation—can determine the keystream value. If the attacker places these calculations into a script or program (which automatically runs all the intercepted packets through the program to build the described database), he or she can assemble a database that contains an entire network's IV values and corresponding keystream values—assuming that everyone on the network is using the same key. Therefore, this newly armed traffic sniffer would be able to capture a packet, compare the packet's unencrypted IV value against the database of keystream values, extract the corresponding keystream value, and apply it to the packet—which would automatically decrypt the encrypted information.
Ideally, each packet would have a different IV value—thus, a different keystream value—which would make any efforts to obtain and track this type of information too processor-intensive for current technology. But the 802.11 standard doesn't require that each packet have a different IV value (although the standard suggests it), and it doesn't provide a method for calculating random IV values.
The Secret Key
As I mentioned earlier, most wireless-communication installations use one key for the entire network. This key resides inside each computer and device. If an attacker obtains the secret key from one device, he or she has discovered the key for every device on the network. However, if each device held a unique private key and didn't share that key with the rest of the network, an attacker's attempts to calculate the keystream would be much more difficult.
For LAN administrators, rotating secret keys on every device in the network can be a nightmare. Therefore, many administrators use only one key for the whole network and rarely—if ever—change the key. The 802.11 standard provides no method for exchanging keys or requiring that each device have a unique key. The previously stated equation
IV + Secret Key = Keystream
shows that the IV value is just one of the components necessary to calculate the keystream value. To produce the keystream, the RC4 algorithm puts the IV value through a mathematical function with a secret key. Because the IV value is easily attainable, and because each device uses the same secret key, an attacker can easily compromise this method of calculating a keystream.
If the 802.11 standard employed an algorithm that used public key cryptography, this problem wouldn't exist: Each device could have a unique private key. For each information exchange, the two communicating wireless devices would calculate a secret key, and only those two devices would share this key. The secret key would be valid for only one transmission. If the two computers needed to initiate another transmission, the two devices would calculate a different secret key. This process would provide better assurance that each keystream was unique, and any attacker attempting to discover the keystream would need to invest much more energy and time.
What Can You Do?
If your company is just beginning to consider implementing wireless capability, carefully scrutinize available products and designs before purchasing a solution. Some vendors have already begun to address the security loopholes that I've mentioned. If your company is in the midst of implementing a wireless installation, stop, review the features of your chosen product and your network design, and make any necessary changes to increase security. If your company has a functioning wireless network, evaluate your current security mechanisms and determine whether further security measures are necessary.
The correct solution also depends on how interconnected your wired and wireless networks need to be and what kind of information you need to transmit over the wireless network. If your organization transfers funds or important information over wireless radio waves, you need tougher security than what many wireless solutions provide.
Look for solutions that provide dynamic keys that change on a per-user, per-session basis. Some solutions generate dynamic keys through an automated method such as public key cryptography, and others require an administrator to manually generate keys. Whatever method you choose, you need to change these keys frequently.
Using key lengths longer than 40 bits might also help you build more complexity into your keystreams. Wireless solutions should also generate a different IV for each packet, and the sequence of IVs shouldn't be predictable. Techniques such as these drastically reduce the predictability of the keystream and make successful attacks more difficult.
If your company already has a wireless network, consider the following suggestions to increase the current security level of the infrastructure:
Part of the Process
Although you might view 802.11's security failings as a setback in the advancement of wireless communication, they're really just part of the fast and complex evolution of computers. Other architectures, protocols, software, and security mechanisms have had similar problems. Flaws come to light, articles appear, developers return to the drawing board, further testing is necessary, and a new version typically compensates for the previously discovered imperfections. These phases are typical of most new technologies.
Unfortunately, many companies that have already implemented a wireless technology are in for a lot of work. They'll need to apply patches, install VPNs, and change firewall policies—and any previously enjoyed sense of security will probably evaporate. They might also need to revisit liability concerns pertaining to private and confidential information, and they might need to erect alternative security mechanisms. The next version of the wireless standard will no doubt attempt to address and amend these security compromises. Perhaps 802.1x will be available for public scrutiny so that the IEEE can rectify further problems before ratification. For information about how the new 802.1x standard promises to address the weaknesses of 802.11, see Tim Huckaby's sidebar "Is 802.1x the Answer?"
