Wireless (In)Security

Ido Dubrawsky

Wireless networks began with the IEEE 802.11 standard in 1997. This standard specified everything from how various devices on the wireless network speak to each other to the security of the network. When it was first drafted, the authors of the 802.11 standard understood the need to provide a "privacy" to the wireless network that would be similar to that provided by wired networks. Their work towards this regard was termed "Wired Equivalent Privacy", or WEP for short.

The original intent of WEP was not to provide a secure network protocol similar to that provided by IPSec, but rather to provide an equivalent level of privacy to that found on a wired network. WEP was designed to prevent "casual eavesdropping". While the design of WEP met its intended goals, the authors of the 802.11 could not have foreseen the deployment configurations systems and network administrators used for wireless networks. Wireless networks were deployed in a similar fashion to wired networks -- without regard to the one fundamental difference between the two. While wired networks remain constrained within the physical limitations of the network wire, wireless networks have no physical boundaries. Because of this fundamental difference, WEP went from being a "good enough" protocol to an inadequate protocol.

IEEE 802.11

The IEEE 802.11 standard provides for all the definitions and constructs necessary for wireless networks. Everything from the physical transmission specifications to the authentication negotiation is provided. Wireless traffic, like its wired counterpart, consists of frames transmitted from one station to another. A feature that sets wireless networks apart from wired networks is that one end of the communication pair is either another wireless client or a wireless access point.

The 802.11 standard provides for two modes for wireless clients to communicate: ad-hoc and infrastructure. The ad hoc mode is geared for a network of stations within communication range of each other. Ad hoc networks are created spontaneously between the network participants. In infrastructure mode, access points provide for a more permanent structure for the network. An infrastructure consists of one or more access points as well as a distribution system (i.e., wired network) behind the access points that tie the wireless network with the wired network.

To distinguish between different wireless networks, the 802.11 standard defines the SSID (Service Set Identifier). The SSID is a configurable string of up to 32 characters that identifies a wireless network. It is similar to the network portion of an IP address for wired LANs. The SSID can be considered the identity element that "glues" various components of a wireless LAN together. Traffic from wireless clients that use one SSID can be distinguished from other wireless traffic using a different SSID. By using the SSID, an access point can determine which traffic is meant for it and which is meant for other wireless networks.

802.11 traffic can be subdivided into three parts: control frames, management frames, and data frames. Control frames include such information as Request to Send (RTS), Clear to Send (CTS), and Acknowledgment (ACK) messages. Management frames include beacon frames, probe request/response, authentication frames, and association frames. Data frames are, as the name implies, 802.11 traffic that carries data. That data is typically considered network traffic, such as IP encapsulated frames.

There are two types of authentication mechanisms used by 802.11: open authentication and shared key authentication. Open authentication requires that the client have pre-existing knowledge of the wireless network SSID. The client must also know whether WEP is in use on the wireless network and, if it is in use, the value of the WEP key. With shared key authentication, the wireless client must prove its knowledge of the secret key. Proof is obtained through a challenge-response exchange similar to the exchange used in CHAP. The access point sends a random challenge to the client (in clear text) who then encrypts the challenge and transmits it back to the access point. The access point decrypts the response and compares the challenge to what was transmitted. If the two agree, the client is authenticated. As discussed below, shared key authentication is actually less secure than open authentication because it provides several components for a known plaintext attack.

The WEP Protocol

WEP is a form of electronic codebook in which a given block of text is encrypted at the sending station, transmitted, and then decrypted at the receiver. Figure 1 shows how WEP encryption proceeds.

In Figure 1, the plaintext message (1) is run through an integrity algorithm (the 802.11 standard specifies the use of CRC-32) to produce an Integrity Check Value (ICV), which is then appended to the end of the original plaintext message (2). A "random" 24-bit Initialization Vector (IV) is generated and prepended to the secret key (which is distributed through an out-of-band method) and that is then input (3) to generate a seed value for the WEP pseudo-random number generator (PRNG). The WEP PRNG (4) outputs a key sequence equal in length to the plaintext/ICV message. This key sequence and the plaintext/ICV message is then XOR'ed (5) to produce the WEP ciphertext. The ciphertext is then prepended with the IV (in plaintext) and transmitted (6).

Once the data is encrypted, it is packaged (Figure 2). The encrypted data/ICV combination is appended to the IV used, along with the shared secret, to generate the RC4 keystream. This IV consists of the 24-bit initialization vector, a 6-bit 0-value pad, and 2-bits set aside for the key ID. The secret key is 40 bits long. The key ID allows the network administrator or user to choose one of up to four separate 'secret' 40-bit keys on the wireless device. This allows the flexibility of providing users different keys for different wireless networks, or for easily switching between keys should one secret key become compromised.

One confusing feature of WEP is the length of the keys. While a 64-bit key is used to generate the RC4 keystream, which is then XOR'ed to the data/ICV combination, 24-bits of that key is the Initialization Vector. This leaves only 40-bits for the actual secret key.

WEP2

Realizing the problems with WEP, the IEEE proposed changes to the WEP protocol in 2001. This new version of WEP, known as WEP2, increases the IV space from 24 to 128 bits and provides for mandatory Kerberos V support. While increasing the IV size to 128 bits does alleviate the IV collision problem of WEP (discussed below), it does nothing to eliminate the problem of known plaintext attacks, keystream reuse (described below), the problems with rogue access points, and denial-of-service attacks against access points and wireless clients. Some vendors have added support for WEP2 keys in their products but complete support for the entire WEP2 proposal has yet to be achieved.

WEP Problems

Initialization (IV) Weaknesses

WEP2 only appeared recently and is still making its way to the marketplace. Most existing WEP-based wireless networks were designed around the earlier WEP standard. If you already have or are thinking of purchasing a WEP network that uses the 24-bit IV, it is worth considering the implications. An IV space of only 224 yields approximately 16 million possible IV keys. The 802.11 standard does not specify any method to choose the IV. Many vendors designed the firmware for their wireless devices to start the IV at 0 (that is 00:00:00) at device initialization and increment each successive IV value by 1. This is reminiscent of the old TCP Sequence Number incrementing on UNIX by 64K for every packet, which results in an increase in low-value IV reuse -- a widely known weakness of keystreams.

Another weakness related to the IV comes from its limited size as defined by the 802.11 standard. Because the IV is only 24 bits wide, an 11-Mbps wireless network can easily exhaust all IV values within a few hours of use by several clients. This then leads to the possibility of IV collisions. IV collisions occur when two packets are encrypted with a keystream generated from the same IV value, v, and secret key, k. A collision can result in the attacker's ability to derive the plaintext in the encrypted in the wireless packets. As shown in Figure 1, the plaintext/checksum message is XOR'ed with the RC4 keystream generated by the IV/secret key combination. If two packets are encrypted with the same keystream (i.e., an IV collision has occurred), the keystream can be removed by XOR'ing the two packets together. This leaves the XOR combination of the plaintext data in the two packets. Although this may not seem to be a problem, remember that IP traffic tends to be well structured. This feature can be used by an attacker to determine the value of the data by looking for text that, when XOR'ed with itself, results in the XOR of the two plaintexts [1].

Cipherstream Reuse

A related problem to IV collision is that given the fact that a keystream can be recovered from a WEP packet, it is possible for an attacker to use that stream later to decrypt other packets. Because the IV space is so limited, an attacker can seek to capture keystreams by sending traffic into a network with various IV values. The keystreams can be extracted by XOR'ing the encrypted traffic with the known plaintext. This, in effect, creates a dictionary of keystreams. Later when legitimate traffic crosses the wireless network, the attacker can intercept it and, if he has a keystream for the IV used with the encryption of that traffic, he can XOR out the keystream and recover the plaintext information [2].

Plaintext Attacks

Another approach that can be used to attack a wireless network is a known plaintext attack. In this attack, the attacker knows the plaintext message and has a copy of the ciphertext. The missing piece is the key used to encrypt the plaintext (or decrypt the ciphertext). A simple approach to implementing a known plaintext attack against WEP would be to send a target system on the wireless LAN a known piece of data and then capture that data as it is transmitted to the destination. This data can be generated by a simple piece of email. Once the attacker has captured the encrypted WLAN traffic of the email sent to the target, he will have three pieces of a four-piece puzzle: the known plaintext, the encrypted data, and the IV. It is a trivial matter to take all of those pieces and use a dictionary attack to try and determine the secret key. Another possibility is to use the challenge/response exchange used by the shared key authentication mechanism of the 802.11 standard as the basis of a known plaintext attack. Here the known plaintext is the random challenge sent by the access point to the client, and the ciphertext is the response provided by the client.

As with any password-based security scheme, WEP's security relies on the difficulty of discovering the secret key through a brute-force attack. And, as with any password or secret key, this difficulty is related to the length and composition of the key as well as how often the key is changed. One feature of WEP that originally was determined to be an asset (but later turned out to lead to one of the more dire attacks against it) was that WEP is self-synchronizing for each message. This feature comes out of the fact that the IV is transmitted, in plaintext, with each packet. While 802.11 suggests that the IV values change, the standard leaves it up to the implementer to decide how often the IV changes and how. In the best-case scenario, the IV should be a random value. However, as mentioned previously, some vendors implemented the 802.11 standard in their wireless cards so that the IV gets reset to 00:00:00 whenever the card or system is reset and then increments linearly with each packet sent.

One side effect of the known plaintext attack is that the attacker can take the ciphertext and XOR it with the known plaintext to recover the keystream. This keystream can then be used (with the correct IV attached) to inject packets into the wireless network by reusing the keystream and XOR'ing it with new data. In this way, an attacker can insert packets to the wireless network without actually authenticating to the access point.

Fluhrer, Mantin, and Shamir

In August of 2001, Scott Fluhrer of Cisco Systems and Itsik Mantin and Adi Shamir of the Computer Science Department of The Weizmann Institute in Israel released a paper discussing weaknesses in the Key Scheduling Algorithm (KSA) of RC4. The KSA derives an initial state from a variable size key and then feeds this state to the pseudo-random number generator (PRNG) of RC4, which uses the input to generate a pseudo-random keystream.

Problems with RC4 are not new. In 1995, Andrew Roos posted some preliminary results from an analysis of RC4's PRNG to the Usenet newsgroup sci.crypt. In 1996, Ian Farquhar posted to sci.crypt that there was an approximately 35% probability that the first byte of the keystream generated by RC4 would be the same as the first byte of the key.

Fluhrer, Mantin, and Shamir discovered two weaknesses in the KSA. The first weakness is the existence of large classes of "weak" keys where a small part of the secret key determines a large number of bits of the KSA output [3]. This ultimately results in the problem where the initial output of the RC4 algorithm is disproportionally affected by a small number of key bits. The second vulnerability is related to the first. It occurs when part of the key presented to the KSA is exposed to the attacker (as in WEP, where the IV is exposed). When the same secret part of the key is used with numerous different exposed values, an attacker can rederive the secret part by analyzing the initial word of the keystreams with relatively little work. The attack that Fluhrer, Mantin, and Shamir devised works against any key size, including both the 24-bit key of WEP and the 128-bit key of WEP2, and does not matter whether the IV precedes the secret key or follows the secret key.

The work done by Fluhrer, Mantin, and Shamir was applied by Adam Stubblefield of Rice University and John Ioannidis and Aviel Rubin of AT&T Labs. Their work utilized off-the-shelf hardware and software and was able to crack the encryption provided by WEP on their test network within the span of a few hours. Their work was duplicated by others and, while Stubblefield et al. did not release their source code to the public, they noted that two other tools were currently publicly available: airsnort and Tim Newsham's WEPCrack [4].

Securing Wireless Networks

Wireless networks are being deployed at an ever-increasing pace. According to a recent report by Allied Business Intelligence, 4.9 million wireless nodes were shipped worldwide in 2000, and the number is expected to climb to 55.9 million wireless nodes by 2006. This explosion in deployment of wireless devices and wireless LANs will result in considerable difficulties for systems and network administrators if the problems with WEP are not addressed. To deal with WEP's problems, several vendors (including Cisco Systems, Agere Systems, Enterasys Networks, and Avaya) have each devised proprietary solutions to address some of WEP's near-term problems.

Some vendors have adopted the Extensible Authentication Protocol (EAP) authentication mechanism in the IEEE 802.1x standard. This standard allows for port-based access control where access to the network is granted only after the client authenticates. For WLANs, this method works very well because access can be granted by the access point once the user has successfully authenticated to a RADIUS server. This also provides for an interim solution until the 802.11i working group can provide a better security mechanism for wireless LANs.

Access Points

However, network administrators can still deploy wireless networks even with the current problems inherent with WEP. The caveat is that wireless networks must be afforded special consideration when deployed. With that in mind, network administrators deploying wireless access points should consider the placement of the access point very carefully. Wireless access points should not be connected to the internal wired LAN even if WEP is enabled. With the well-known weaknesses of WEP and the low level of difficulty in cracking WEP-based traffic, the wireless LAN is better viewed as an insecure or "dirty" network. Thus, access points should be placed outside a firewall. Access into the network should be provided either through Secure Shell or through an IPSec-based VPN solution. The Secure Shell connection and the IPSec-based VPN connection provides for both user authentication as well as user differentiation.

Most access points can accommodate MAC filtering and should be configured to do so, even though MAC addresses can be spoofed. WEP should be active; even with the weaknesses inherent with WEP, there is no need to make it easier for an adversary to attack the network. Network address management is a difficult issue that must also be considered. One benefit to utilizing wireless devices that can support 802.1x authentication mechanisms is that network addresses can be provided after authentication is complete and access has been granted. However, many WLAN devices do not support EAP authentication. For wireless LANs based on those devices, an external DHCP server providing network addresses to specific clients only on the wireless LAN is one solution -- with the understanding that this host's only function is to provide addresses to wireless clients. However, that server will probably become the focus of access as well as denial-of-service attacks. While not optimal, it does provide for network address management on the wireless LAN. Another possibility is to use the built-in DHCP server available on many wireless access points.

The firewall should allow only IPSec traffic or Secure Shell traffic into the network. All traffic from the clients should be routed through the IPSec VPN or the Secure Shell connection. Figure 3 shows a wireless network configured as described above. In step 1, the wireless client authenticates and associates to the wireless access point using open authentication. The access point is configured to filter based on a MAC address. Once authentication and association completes, the access point forwards DHCP requests to the DHCP server. The server assigns the wireless client a network address in step 2. With the wireless client now on the wireless network, the client can proceed to access the "wired" network beyond the firewall. To do this, the client either sets up an IPSec VPN tunnel to the VPN device or uses Secure Shell to connect to the SSH server, as shown in step 3 of Figure 4. The firewall is configured to permit only SSH traffic or IPSec traffic to pass through. All other traffic is denied.

Until the problems with WEP are properly addressed, wireless networks will remain a significant problem for administrators. However, even with the current difficulties posed by wireless LANs, it is still possible to deploy them if they are treated with the proper respect and consideration.

References

1. N. Borisov, I. Goldberg, and D. Wagner. Intercepting Mobile Communications: The Insecurity of 802.11. Published in the Proceedings of the Seventh Annual International Conference of Computing and Networking. July, 2001.

2. J. Walker. Unsafe at any key size; An analysis of the WEP encapsulation. IEEE Doc: 802.11-00/362. October 2000.

3. S. Fluhrer, I. Mantin, and A. Shamir. Weakness in the Key Scheduling Algorithm of RC4. August 2001.

4. A. Stubblefield, J. Ioannidis, and A. Rubin. Using the Fluhrer, Mantin, and Shamir Attack to Break WEP. AT&T Labs Technical Report TD-4ZCPZZ. August 2001.

5. Institute for Electrical and Electronic Engineers, "ANSI/IEEE Std 802.11, 1999 Edition", 1999

Ido Dubrawsky has been working in UNIX and network administration field for nine years. When not working on security, he spends his free time with his wife, Diana, their two children, and their dog, Reidy. He is currently employed by Cisco Systems in the Cisco Secure Consulting Service as a Network Security Engineer.