A Security Analysis of the Wireless Networks (IEEE 802.11) Sampath Thodupunuri Abstract The 802.11 standard for wireless networks includes a Wired Equivalent Privacy (WEP) protocol, used to protect link-layer communications from eavesdropping and other attacks. In this paper I discussed about the security flaws in the protocol arising from the misapplication of cryptographic primitives. These flaws lead to several practical attacks that demonstrate that WEP fails to achieve its security goals. As currently defined, WEP s usage of encryption is a fundamentally unsound construction; the WEP encapsulation remains insecure whether its key length is 1 bit or 1000 or any other size whatsoever, and the same remains true when any other stream cipher replaces RC4. The weakness stems from WEP s usage of its initialization vector. This vulnerability prevents the WEP encapsulation from providing a meaningful notion of privacy at any key size. The deficiency of the WEP encapsulation design arises from attempts to adapt RC4 to an environment for which it is poorly suited.
Table of Contents 1. Introduction to Wireless Networks --- ad hoc mode --- infrastructure mode --- walkthrough of association 2. Overview of WEP protocol --2.1 security goals --2.2 Attack practicality 3. The risks of keystream reuse --3.1 Finding instances of keystream reuse --3.2 Exploiting keystream reuse to read encrypted traffic --3.3 Decryption dictionaries --3.4 Key management --3.5 Summary 4. Message Authentication --4.1 Message modification --4.2 Message Injection --4.3 Summary 5. History of wireless LAN security --5.1 In the beginning, there was obfuscation --- cordless phones --- wireless networks and war dialing --- alternatives to WEP --5.2 WEP: Unsafe at any key length --5.3 802.1X and 802.11i: Is that your final answer 6. Summary 7. Bibliography
1 Introduction to 802.11 Wireless Networks [1] With more and more companies and individuals requiring portable and mobile computing the need for wireless local area networks continues to rise throughout the world. Because of this growth, IEEE formed a working group IEEE 802.11. This standard defines the Medium Access Control (MAC) and Physical Layer (PHY) for wireless local area network. The standard defines three different physical layers for the 802.11 wireless LAN, each operating in a different frequency range and at rates of 1 Mbps and 2 Mbps. Figure 1 illustrates the principal components of the 802.11 wireless LAN architecture. The fundamental building block of the 802.11 architecture is the cell, knows as the basic service set (BSS) in the 802.11 parlance. A BSS typically contains one or more wireless stations and a central base station, known as an access point (AP) in 802.11 terminology. Figure 1 The wireless stations, which may be either fixed or mobile, and the central base station communicate among themselves using the IEEE 802.11 wireless MAC protocol. Multiple APs may be connected together (for example using a wired Ethernet or another wireless channel) to form a socalled distribution system (DS). The DS appears to upper-level protocol (for example, IP) as a single 802 network to the upper-layer protocol. 802.11 wireless networks operate in one of two modes- ad-hoc or infrastructure mode. The IEEE standard defines the ad-hoc mode as Independent Basic Service Set (IBSS), and the infrastructure mode as Basic Service Set (BSS). In the remainder of this section, the differences between the two modes and how they operate are explained. ad hoc mode Figure 2 shows that IEEE 802.11 stations can also group themselves together to form an ad-hoc network a network with no central control and with no connections to the outside world. Here, the network is formed on the fly, simply because there happen to be mobile devices that have found themselves in proximity to each other, that have a need to communicate, and that find no pre-existing network infrastructure (for example, a pre-existing 802.11 BSS with an AP) in the location. An ad hoc network might be formed when people with laptops meet together (for example in conference room, a train, or a car or in a battlefield) and want to exchange data in the absence of a centralized AP.
infrastructure mode In infrastructure mode, each client sends all of it s communications to a central station, or access point (AP). The access point acts as an Ethernet bridge and forwards the communications onto the appropriate network either the wired network, or the wireless network, see figure 3. Prior to communicating data, wireless clients and access points must establish a relationship, or an association. Only after an association is established can the two wireless stations exchange data. In infrastructure mode, the clients associate with an access point. The association process is a two step process involving three states: 1. Unauthenticated and unassociated, 2. Authenticated and unassociated, and 3. Authenticated and associated.
Figure 4 shows the classic 802.11 state machine [3]. An 802.11 frame can be of two basic types: a management frame or a data frame. To transition between the states, the communicating parties exchange management frames. walk through of association Figure 4 I will now walk through a wireless client finding and associating with an access point. All access points transmit a beacon management frame at fixed interval. To associate with an access point and join a BSS, a client listens for beacon messages to identify the access points within range. The client then selects the BSS to join in a vendor independent manner. For instance on the Apple Macintosh, all of the network names (or service set identifiers (SSID)), which are usually contained in the beacon frame, are presented to the user so that they may select the network to join. A client may also send a probe request management frame to find an access point with a desired SSID. After identifying an access point, the client and the access point perform a mutual authentication by exchanging several management frames as part of the process. The primary methods for authentication and access control are open-system, shared-key authentication and MAC-address based access-control lists. After successful authentication, the client moves into the second state, authenticated and unassociated. Moving from the second state to the third and final state, authenticated and associated, involves the client sending an association request frame, and the access point responding with an association response frame. After following the process described in the previous paragraph, the client becomes a peer on the wireless network, and can transmit data frames on the network. 2 The WEP Protocol Due to the proliferation of laptop computers and PDA s wireless networks of various kinds have gained much popularity. But with the added convenience of wireless access come new problems, not the least of which are heightened security concerns. When transmissions are broadcast over radio waves, interception and masquerading becomes trivial to anyone with a radio, and so there is a need to employ additional mechanisms to protect the communications. The 802.11 standard for wireless LAN communications introduced the Wired Equivalent Privacy (WEP) protocol in an attempt to address these new problems and bring the security level of wireless
systems closer to that of wired ones. The primary goal of WEP is to protect the confidentiality of user data from eavesdropping. WEP is part of an international standard; it has been integrated by manufacturers into their 802.11 hardware and is currently in widespread use. Unfortunately, WEP falls short of accomplishing its security goals. Despite employing the wellknown and believed-secure RC4 cipher, WEP contains several major security flaws. The flaws give rise to a number of attacks, both passive and active, that allow eavesdropping on, and tampering with, wireless transmissions. In this section, we discuss the flaws that are identified and describe the attacks that ensue. The following section is devoted to an overview of WEP and the threat models that it is trying to address. Sections 2.2 and 2.3 identify particular flaws and the corresponding attacks, and also discuss the security principles that were violated. Finally, Section 6 offers some conclusions. 2.1 Overview of the WEP Protocol The Wired Equivalent Privacy protocol is used in 802.11networks to protect link-level data during wireless transmission. It is described in detail in the 802.11 standard; I will reproduce a brief description to enable the following discussion of its properties. WEP relies on a secret key k shared between the communicating parties to protect the body of a transmitted data. Encryption of a frame proceeds as follows: Checksumming: First, we compute an integrity checksum c(m) on the message M. We concatenate the two to obtain a plaintext P = <M,c(M)>, which will be used as input to the second stage. Note that c(m), and thus P, does not depend on the key k. Encryption: In the second stage, we encrypt the plaintext P derived above using RC4. We choose an initialization vector (IV) v. The RC4 algorithm generates a keystream i.e., a long sequence of pseudorandom bytes as a function of the IV v and the key k. This keystream is denoted by RC4 (v, k). Then, we exclusive-or ( XOR, denoted by ) the plaintext with the keystream to obtain the ciphertext: C = P RC4(v, k). Transmission: Finally, we transmit the IV and the ciphertext over the radio link. Symbolically, this may be represented as follows: A B : v,( P RC4(v, k)) where P = <M,c(M)> The format of the encrypted frame is also shown pictorially in Figure 5. We will consistently use the term message (symbolically, M) to refer to the initial frame of data to be protected, the term plaintext (P) to refer to the concatenation of message and checksum as it is presented to the RC4 encryption algorithm, and the term ciphertext (C ) to refer to the encryption of the plaintext as it is transmitted over the radio link.
Figure 5 Encrypted WEP frame. To decrypt a frame protected by WEP, the recipient simply reverses the encryption process. First, he regenerates the keystream RC4(v, k) and XORs it against the ciphertext to recover the initial plaintext: P = C RC4(v, k) = (P RC4(v, k)) RC4(v, k) = P. Next, the recipient verifies the checksum on the decrypted plaintext P by splitting it into the form <M, c >, re-computing the checksum c(m ), and checking that it matches the received checksum c. This ensures that the receiver accepts only frames with a valid checksum. 2.2 Security Goals The WEP protocol is intended to enforce three main security goals: Confidentiality: The fundamental goal of WEP is to prevent casual eavesdropping. Access control: A second goal of the protocol is to protect access to a wireless network infrastructure. The 802.11 standard includes an optional feature to discard all packets that are not properly encrypted using WEP, and manufacturers advertise the ability of WEP to provide access control. Data integrity: A related goal is to prevent tampering with transmitted messages; the integrity checksum field is included for this purpose. In all three cases, the claimed security of the protocol relies on the difficulty of discovering the secret key through a brute-force attack. There are actually two classes of WEP implementation: classic WEP, as documented in the standard, and an extended version developed by some vendors to provide larger keys. The WEP standard specifies the use of 40-bit keys. This key length is short enough to make bruteforce attacks practical to individuals and organizations with fairly modest computing resources. However, it is straightforward to extend the protocol to use larger keys, and several equipment manufacturers offer a so-called 128-bit version (which actually uses 104-bit keys, despite its misleading name). This extension renders brute-force attacks impossible for even the most resourceful of adversaries given today s technology. Nonetheless, we will demonstrate that there are shortcut attacks on the system that do not require a bruteforce attack on the key, and thus even the 128-bit versions of WEP are not secure.
In the remainder of this paper, we will argue that none of the three security goals are attained. First, we show practical attacks that allow eavesdropping. Then, we show that it is possible to subvert the integrity checksum field and to modify the contents of a transmitted message, violating data integrity. Finally, we demonstrate that our attacks can be extended to inject completely new traffic into the network. 2.3 Attack Practicality Before describing the attacks, we would like to discuss the feasibility of mounting them in practice. In addition to the cryptographic considerations discussed in the sections to follow, a common barrier to attacks on communication subsystems is access to the transmitted data. Despite being transmitted over open radio waves, 802.11 traffic requires significant infrastructure to intercept. An attacker needs equipment capable of monitoring 2.4GHz frequencies and understanding the physical layer of the 802.11 protocol; for active attacks, it is also necessary to transmit at the same frequencies. A significant development cost for equipment manufacturers lies in creating technologies that can reliably perform this task. As such, there might be temptation to dismiss attacks requiring link-layer access as impractical; for instance, this was once established practice among the cellular industry. However, such a position is dangerous. First, it does not safeguard against highly resourceful attackers who have the ability to incur significant time and equipment costs to gain access to data. This limitation is especially dangerous when securing a company s internal wireless network, since corporate espionage can be a highly profitable business. Second, the necessary hardware to monitor and inject 802.11 traffic is readily available to consumers in the form of wireless Ethernet interfaces. All that is needed is to subvert it to monitor and transmit encrypted traffic. There were successful attempts of passive attacks using off-the-shelf equipment by modifying driver settings. Active attacks appear to be more difficult, but not beyond reach. The time investment required is non-trivial; however, it is a one-time effort the rogue firmware can then be posted on a web site or distributed amongst underground circles. Therefore, it would be prudent to assume that motivated attackers will have full access to the link layer for passive and even active attacks. Further supporting this assumption are the WEP documents themselves. They state: Eavesdropping is a familiar problem to users of other types of wireless technology. The difficulties of link layer access will not be discussed further, and instead the focus shifts on cryptographic properties of the attacks. 3 The Risks of Keystream Reuse WEP provides data confidentiality using a stream cipher called RC4. Stream ciphers operate by expanding a secret key (or, as in the case of WEP, a public IV and a secret key) into an arbitrarily long keystream of pseudorandom bits. Encryption is performed by XORing the generated keystream with the plaintext. Decryption consists of generating the identical keystream based on the IV and secret key and XORing it with the ciphertext. A well-known pitfall of stream ciphers is that encrypting two messages under the same IV and key can reveal information about both messages: If and then C1 = P1 RC4(v,k) C2 = P2 RC4(v,k)
C1 C2 = (P1 RC4(v,k)) (P2 RC4(v,k)) = P1 P2. In other words, XORing the two ciphertexts (C1and C2) together causes the keystream to cancel out, and the result is the XOR of the two plaintexts (P1 P2). Thus, keystream reuse can lead to a number of attacks: as a special case, if the plaintext of one of the messages is known, the plaintext of the other is immediately obtainable. More generally, real-world plaintexts often have enough redundancy that one can recover both P1 and P2 given only P1 P2; there are known techniques, for example, for solving such plaintext XORs by looking for two English texts that XOR to the given value P1 P2. Moreover, if we have n ciphertexts that all reuse the same keystream, we have what is known as a problem of depth n. Reading traffic in depth becomes easier as n increases, since the pairwise XOR of every pair of plaintexts can be computed, and many classical techniques are known for solving such problems (e.g., frequency analysis, dragging cribs, and so on). Note that there are two conditions required for this class of attacks to succeed: The availability of ciphertexts where some portion of the keystream is used more than once, and Partial knowledge of some of the plaintexts. To prevent these attacks, WEP uses a per-packet IV to vary the keystream generation process for each frame of data transmitted. WEP generates the keystream RC4(v,k) as a function of both the secret key k (which is the same for all packets) and a public initialization vector v (which varies for each packet); this way, each packet receives a different keystream. The IV is included in the unencrypted portion of the transmission so that the receiver can know what IV to use when deriving the keystream for decryption. The IV is therefore available to attackers as well1, but the secret key remains unknown and maintains the security of the keystream. The use of a per-packet IV was intended to prevent keystream reuse attacks. Nonetheless, WEP does not achieve this goal. We describe below several realistic keystream reuse attacks on WEP. First, we discuss how to find instances of keystream reuse; then, we show how to exploit these instances by taking advantage of partial information on how typical plaintexts are expected to be distributed. Finding instances of keystream reuse. One potential cause of keystream reuse comes from improper IV management. Note that, since the shared secret key k generally changes very rarely, reuse of IV s almost always causes reuse of some of the RC4 keystream. Since IV s are public, duplicate IV s can be easily detected by the attacker. Therefore, any reuse of old IV values exposes the system to keystream reuse attacks. We call such a reuse of an IV value a collision. The WEP standard recommends (but does not require) that the IV be changed after every packet. However, it does not say anything else about how to select IV s, and, indeed, some implementations do it poorly. A particular PCMCIA card reset the IV to 0 each time they were re-initialized, and then incremented the IV by one for each packet transmitted. These cards re-initialize themselves each time they are inserted into the laptop, which can be expected to happen fairly frequently. Consequently, keystreams corresponding to low-valued IV s were likely to be reused many times during the lifetime of the key.
Even worse, the WEP standard has architectural flaws that expose all WEP implementations no matter how cautious to serious risks of keystream reuse. The IV field used by WEP is only 24 bits wide, nearly guaranteeing that the same IV will be reused for multiple messages. A back-of-theenvelope calculation shows that a busy access point sending 1500 byte packets and achieving an average 5Mbps bandwidth (the full transmission rate is 11Mbps) will exhaust the available space in less than half a day. Even for less busy installations, a patient attacker can readily find duplicates. Because the IV length is fixed at 24 bits in the standard, this vulnerability is fundamental: no compliant implementation can avoid it. Implementation details can make keystream reuse occur even more frequently. An implementation that uses a random 24-bit IV for each packet will be expected to incur collisions after transmitting just 5000 packets, which is only a few minutes of transmission. Worse yet, the 802.11 standard does not even require that the IV be changed with every packet, so an implementation could reuse the same IV for all packets without risking noncompliance! Exploiting keystream reuse to read encrypted traffic. Once two encrypted packets that use the same IV are discovered, various methods of attack can be applied to recover the plaintext. If the plaintext of one of the messages is known, it is easy to derive the contents of the other one directly. There are many ways to obtain plausible candidates for the plaintext. Many fields of IP traffic are predictable, since protocols use well-defined structures in messages, and the contents of messages are frequently predictable. For example, login sequences are quite uniform across many users, and so the contents e.g., the Password: prompt or the welcome message may be known to the attacker and thus usable in a keystream reuse attack. As another example, it may be possible to recognize a specific shared library being transferred from a networked file system by analyzing traffic patterns and lengths; this would provide a large quantity of known plaintext suitable for use in a keystream reuse attack. There are also other, sneakier, ways to obtain known plaintext. It is possible to cause known plaintext to be transmitted by, for example, sending IP traffic directly to a mobile host from an Internet host under the attacker s control. The attacker may also send e-mail to users and wait for them to check it over a wireless link. Sending spam e-mail might be a good method of doing this without raising too many alarms. 3.1 Decryption Dictionaries Once the plaintext for an intercepted message is obtained, either through analysis of colliding IV s, or through other means, the attacker also learns the value of the keystream used to encrypt the message. It is possible to use this keystream to decrypt any other message that uses the same IV. Over time, the attacker can build a table of the keystreams corresponding to each IV. The full table has modest space requirements perhaps 1500 bytes for each of the 224possible IV s, or roughly 24 GB so it is conceivable that a dedicated attacker can, after some amount of effort, accumulate enough data to build a full decryption dictionary, especially when one considers the low frequency with which keys are changed (see next section). The advantage to the attacker is that, once such a table is available, it becomes possible to immediately decrypt each subsequent ciphertext with very little work. Of course, the amount of work necessary to build such a dictionary restricts this attack to only the most persistent attackers who are willing to invest time and resources into defeating WEP security. It can be argued that WEP is not designed to protect from such attackers, since a 40-bit key can be
discovered through brute-force in a relatively short amount of time with moderate resources. However, manufacturers have already begun to extend WEP to support larger keys, and the dictionary attack is effective regardless of key size. (The size of the dictionary depends not on the size of the key, but only on the size of the IV, which is fixed by the standard at 24 bits.) Further, the dictionary attack can be made more practical by exploiting the behavior of PCMCIA cards that reset the IV to 0 each time they are reinitialized. Since typical use of PCMCIA cards includes reinitialization at least once per day, building a dictionary for only the first few thousand IV s will enable an attacker to decrypt most of the traffic directed towards the access point. In an installation with many 802.11 clients, collisions in the first few thousand IV s will be plentiful. 3.2 Key Management The 802.11 standard does not specify how distribution of keys is to be accomplished. It relies on an external mechanism to populate a globally-shared array of 4 keys. Each message contains a key identifier field specifying the index in the array of the key being used. The standard also allows for an array that associates a unique key with each mobile station; however, this option is not widely supported. In practice, most installations use a single key for an entire network. This practice seriously impacts the security of the system, since a secret that is shared among many users cannot stay very well hidden. Some network administrators try to ameliorate this problem by not revealing the secret key to end users, but rather configuring their machines with the key themselves. This, however, yields only a marginal improvement, since the keys are still stored on the users computers. The reuse of a single key by many users also helps make the attacks in this section more practical, since it increases chances of IV collision. The chance of random collisions increases proportionally to the number of users; even worse, PCMCIA cards that reset the IV to 0 each time they are reinitialized will all reuse keystreams corresponding to a small range of low-numbered IV s. Also, the fact that many users share the same key means that it is difficult to replace compromised key material. Since changing a key requires every single user to reconfigure their wireless network drivers, such updates will be infrequent. In practice, we expect that it may be months, or even longer, between key changes, allowing an attacker more time to analyze the traffic and look for instances of keystream reuse. 3.3 Summary The attacks in this section demonstrate that the use of stream ciphers is dangerous, because the reuse of keystream can have devastating consequences. Any protocol that uses a stream cipher must take special care to ensure that keystream never gets reused. This property can be difficult to enforce. The WEP protocol contains vulnerabilities despite the designers apparent knowledge of the dangers of keystream reuse attacks. Nor is it the first protocol to fall prey to streamcipher- based attacks; 4 Message Authentication The WEP protocol uses an integrity checksum field to ensure that packets do not get modified in transit. The checksum is implemented as a CRC-32 checksum, which is part of the encrypted payload of the packet. We will argue below that a CRC checksum is insufficient to ensure that an attacker cannot tamper with a message: it is not a cryptographically secure authentication code. CRC s are designed to detect random errors in the message; however, they are not resilient against malicious attacks. As we will demonstrate, this vulnerability of CRC is exacerbated by the fact that the message payload is encrypted using a stream cipher.
4.1 Message Modification First, we show that messages may be modified in transit without detection, in violation of the security goals. We use the following property of the WEP checksum: Property 1 The WEP checksum is a linear function of the message. By this, we mean that checksumming distributes over the XOR operation, i.e., c(x y) = c(x) c(y) for all choices of x and y. This is a general property of all CRC checksums. One consequence of the above property is that it becomes possible to make controlled modifications to a ciphertext without disrupting the checksum. Let s fix our attention on a ciphertext C which we have intercepted before it could reach its destination: A (B) : <v, C> We assume that C corresponds to some unknown message M, so that C = RC4(v,k) <M, c(m)> (1) We claim that it is possible to find a new ciphertext C that decrypts to M, where M = M and may be chosen arbitrarily by the attacker. Then, we will be able to replace the original transmission with our new ciphertext by spoofing the source, (A) B : <v, C >, and upon decryption, the recipient B will obtain the modified message M with the correct checksum. All that remains is to describe how to obtain C from C so that C decrypts to M instead of M. The key observation is to note that stream ciphers, such as RC4, are also linear, so we can reorder many terms. We suggest the following trick: XOR the quantity <,c( )> against both sides of Equation 1 above to get a new ciphertext C : C = C <, c( )> = RC4(v,k) <M, c(m)> <,c( )> = RC4(v,k) <M, c(m) c( )> = RC4(v,k) <M, c(m )> = RC4(v,k) <M, c(m )>. In this derivation, we used the fact that the WEP checksum is linear, so that c(m) c( ) = c(m ). As a result, we have shown how to modify C to obtain a new ciphertext C that will decrypt to P. This implies that we can make arbitrary modifications to an encrypted message without fear of detection. Thus, the WEP checksum fails to protect data integrity, one of the three main goals of the WEP protocol. Notice that this attack can be applied without full knowledge of M: the attacker only needs to know the original ciphertext C and the desired plaintext difference, in order to calculate C = C <,c( )>. For example, to flip the first bit of a message, the attacker can set = 1000 0. This allows an attacker to modify a packet with only partial knowledge of its contents.
4.2 Message Injection Next, we show that WEP does not provide secure access control. We use the following property of the WEP checksum: Property 2 The WEP checksum is an unkeyed function of the message. As a consequence, the checksum field can also be computed by the adversary who knows the message. This property of the WEP integrity checksum allows the circumvention of access control measures. If an attacker can get a hold of an entire plaintext corresponding to some transmitted frame, he will then able to inject arbitrary traffic into the network. As we saw in Section3, knowledge of both the plaintext and ciphertext reveals the keystream. This keystream can subsequently be reused to create a new packet, using the same IV. That is, if the attacker ever learns the complete plaintext P of any given ciphertext packet C, he can recover keystream used to encrypt the packet: P C = P (P RC4(v,k)) = RC4(v,k) He can now construct an encryption of a message M : (A) B : <v, C >, where C = <M, c(m )> RC4(v,k). Note that the rogue message uses the same IV value as the original one. Therefore, the attack works only because of the following behavior of WEP access points: Property 3 It is possible to reuse old IV values without triggering any alarms at the receiver. Therefore it is not necessary to block the reception of the original message. Once we know an IV v along with its corresponding keystream sequence RC4(v,k), this property allows us to reuse the keystream indefinitely and circumvent the WEP access control mechanism. A natural defense against this attack would be to disallow the reuse of IV s in multiple packets, and require that all receivers enforce this prohibition. However, the 802.11 standard does not do this. While the 802.11 standard strongly recommends against IV reuse, it does not require it to change with every packet. Hence, every receiver must accept repeated IV s or risk non-interoperability with compliant devices. Note that in this attack we do not rely on Property 1 of the WEP checksum (linearity). In fact, substituting any unkeyed function in place of the CRC will have no effect on the viability of the attack. Only a keyed message authentication code (MAC) such as SHA1-HMAC will offer sufficient strength to prevent this attack. 4.4 Summary In this section, we have shown the importance of using a cryptographically secure message authentication code, such as SHA1-HMAC, to protect integrity of transmissions. The use of CRC is wholly inappropriate for this purpose, and in fact any unkeyed function falls short from defending against all of the attacks in this section. A secure MAC is particularly important in view of composition of protocols, since the lack of message integrity in one layer of the system can lead to breach of secrecy in the larger system.
5 History of Wireless LAN security In this section I will focus on the history of wireless LAN security, especially security in IEEE 802.11. 5.1 In the Beginning, There Was Obfuscation [5] Cordeless Phones 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. Wireless Networks and War dialing 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 [6]. 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. Tools to assist with war driving are now famous (or infamous, if you prefer). One of the better known tools is NetStumbler [7]. 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. Alternatives to WEP 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. 5.1 WEP: Unsafe at any Key Length 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 [3] and the University of Maryland (UMD) [2], attacked the design of WEP as flawed on various grounds. The Berkeley paper (explained int the previous section)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.[8] 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 exportcrippled 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.[4] 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.[9]
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. [10] 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.[11] Key recovery with AirSnort takes only a few seconds once enough weakly-encrypted frames are gathered. In fact, gathering enough frames can be done within a day, depending on your traffic load. 5.3 802.1x and 802.11i: Is That Your Final Answer? 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.[12] 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. 6 Summary In this paper I have explained major security flaws in the WEP protocol and described practical protocol that result. As a result WEP should not be counted on to provide strong link-level security, and that additional precautions be taken to protect network traffic. 7 Bibliography: [1] James F. Kurose, Keith W. Ross, Computer Networking, A top-down approach featuring the Internet, 1st edition, Pearson Education, 2001. [2] W.A.Arbaugh, N.Shankar, and Y.J.Wan. Your 802.11 wireless network has no clothes, www.issac.cs.berkely.edu/issac/mobicom.pdf, Mar.2001. [3] N. Borisov, I. Goldberg, and D. Wagner, Intercepting Mobile Communications:
The Insecurity of 802.1, http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html. [4] J. Walker, Unsafe at any key size: an analysis of the WEP encapsulation, Tech. Rep. 03628E,IEEE 802.11 committee, March 2000. http://grouper.ieee.org/groups/802/11/documents/documentholder/0-362.zi%p. [5] Matthew Gast, Wireless LAN Security: A Short History, http://www.oreillynet.com/pub/a/wireless/2002/04/19/security.html, 4/19/2002 [6] 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/ [7] NetStumbler home page: http://www.netstumbler.com [8] Arbaugh, William A. An inductive chosen plaintext attack against WEP/WEP2, IEEE Document 802.11-01/230, May 2001. http://grouper.ieee.org/groups/802/11/documents/index.html [9] Fluhrer, Scott, Itsik Mantin, and Adi Shamir. Weaknesses in the Key Scheduling Algorithm of RC4, Eighth Annual Workshop on Selected Areas in Cryptography, August 2001. http://downloads.securityfocus.com/library/rc4_ksaproc.pdf [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. http://www.cs.rice.edu/~astubble/wep. [11] AirSnort home page: http://airsnort.shmoo.com [12] Mishra, Arunesh, and William Arbaugh, An Initial Security Analysis of the IEEE 802.1x Security Standard, February 6, 2001. http://www.cs.umd.edu/~waa/1x.pdf.