1. INTRODUCTION
The 802.11 standard [15] 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 well-known and believed-secure RC4 [16]1
The work was done while Ian Goldberg was a student at UC Berkeley , 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 paper, we discuss the flaws that we 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.
The following section is devoted to an overview of WEP and the threat models that it is trying to address.
Sections 3 and 4 identify particular flaws and the corresponding attacks, and also discuss the security principles that were violated.
Section 5 describes potential countermeasures.
Section 6 suggest some general lessons that can be derived from the WEP insecurities. Finally, Section 7 offers some conclusions.
2. THE WEP PROTOCOL
2. THE WEP PROTOCOL
The Wired Equivalent Privacy protocol is used in 802.11 networks to protect link-level data during wireless transmission. It is described in detail in the 802.11 standard [15]; we reproduce a brief description to enable the following discussion of its properties. WEP relies on a secret key _ shared between the communicating parties to protect the body of a transmitted frame of data.
Encryption of a frame proceeds as follows:
Checksumming:
Checksumming:
First, we compute an integrity checksum on the message _____ _ . We concatenate the two to obtain a plaintext ______________ __, which will be used as input to the second stage. Note that ______ , and thus _ , does not depend on the key _ .
Encryption: In the second stage, we encrypt the plaintext _ derived above using RC4. We choose an initialization vector (IV) _ . The RC4 algorithm generates a keystream—i.e., a long sequence of pseudorandom bytes—as a function of the IV _ and the key _ . This keystream is denoted by ______________ . Then, we exclusive-or (XOR, denoted by _ ) the plaintext with the keystream to obtain the ciphertext: _ _ _!_"______________ $#
Encryption: In the second stage, we encrypt the plaintext _ derived above using RC4. We choose an initialization vector (IV) _ . The RC4 algorithm generates a keystream—i.e., a long sequence of pseudorandom bytes—as a function of the IV _ and the key _ . This keystream is denoted by ______________ . Then, we exclusive-or (XOR, denoted by _ ) the plaintext with the keystream to obtain the ciphertext: _ _ _!_"______________ $#
Transmission:
Finally, we transmit the IV and the ciphertext over the radio link.
Symbolically, this may be represented as follows: % &('*)___+_,_!_"___________-_. _
Symbolically, this may be represented as follows: % &('*)___+_,_!_"___________-_. _
where ______ _______ __$# The format of the encrypted frame is also shown pictorially in Figure will consistently use the term message (symbolically, _ ) to refer to the initial frame of data to be protected, the term plaintext (_ ) to refer to the concatenation of message and checksum as it is presented to the RC4 encryption algorithm, and the term ciphertext (_ ) to refer to the encryption of the plaintext as it is transmitted over the radio link.
To decrypt a frame protected by WEP, the recipient simply reverses the encryption process. First, he regenerates the keystream ___________-__ and XORs it against the ciphertext to recover the initial plaintext: _546_ _ _7___________-_. _,_!_"___________-_. _ 8_9_____._____-__ _ _:# Next, the recipient verifies the checksum on the decrypted plaintext_ 4 by splitting it into the form __ 4___ 4_, re-computing the checksum _____ 4 , and checking that it matches the received checksum _4 . This ensures that only frames with a valid checksum will be accepted by the receiver.
2.1 Security Goals
The WEP protocol is intended to enforce three main security goals
[15]:
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” [15]. 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, so chosen because of US Government restrictions on the export of technology containing cryptography, which were in effect at the time the protocol was drafted. This key length is short enough to make brute-force attacks practical to individuals and organizations with fairly modest computing resources [3, 8]. However, it is straightforward to extend the protocol to use larger keys, and several equipment manufacturers offer a socalled
“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 brute-force 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.
A number of these results (particularly the IV reuse weaknesses described in Section 3) have been anticipated in earlier independent work by Simon et. al [19] and by Walker [24]. The serious flaws in the WEP checksum (see Section 4), however, to the best of our knowledge have not been reported before. After our work was completed, Arbaugh et. al have found several extensions that may make these weaknesses even more dangerous in practice [2, 1].
2.2 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. We were successfully able to carry out passive attacks using off-the-shelf equipment by modifying driver
settings. Active attacks appear to be more difficult, but not beyond reach. The PCMCIA Orinoco cards produced by Lucent allow their firmware to be upgraded; a concerted reverse-engineering effort hould be able to produce a modified version that allows injecting arbitrary ; traffic. 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, we believe that 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 our position are the WEP documents themselves. They state: “Eavesdropping is a familiar problem to users of other types of wireless technology” [15, p.61]. We will not discuss the difficulties of link layer access further, and focus on cryptographic properties of the attacks.
To decrypt a frame protected by WEP, the recipient simply reverses the encryption process. First, he regenerates the keystream ___________-__ and XORs it against the ciphertext to recover the initial plaintext: _546_ _ _7___________-_. _,_!_"___________-_. _ 8_9_____._____-__ _ _:# Next, the recipient verifies the checksum on the decrypted plaintext_ 4 by splitting it into the form __ 4___ 4_, re-computing the checksum _____ 4 , and checking that it matches the received checksum _4 . This ensures that only frames with a valid checksum will be accepted by the receiver.
2.1 Security Goals
The WEP protocol is intended to enforce three main security goals
[15]:
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” [15]. 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, so chosen because of US Government restrictions on the export of technology containing cryptography, which were in effect at the time the protocol was drafted. This key length is short enough to make brute-force attacks practical to individuals and organizations with fairly modest computing resources [3, 8]. However, it is straightforward to extend the protocol to use larger keys, and several equipment manufacturers offer a socalled
“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 brute-force 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.
A number of these results (particularly the IV reuse weaknesses described in Section 3) have been anticipated in earlier independent work by Simon et. al [19] and by Walker [24]. The serious flaws in the WEP checksum (see Section 4), however, to the best of our knowledge have not been reported before. After our work was completed, Arbaugh et. al have found several extensions that may make these weaknesses even more dangerous in practice [2, 1].
2.2 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. We were successfully able to carry out passive attacks using off-the-shelf equipment by modifying driver
settings. Active attacks appear to be more difficult, but not beyond reach. The PCMCIA Orinoco cards produced by Lucent allow their firmware to be upgraded; a concerted reverse-engineering effort hould be able to produce a modified version that allows injecting arbitrary ; traffic. 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, we believe that 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 our position are the WEP documents themselves. They state: “Eavesdropping is a familiar problem to users of other types of wireless technology” [15, p.61]. We will not discuss the difficulties of link layer access further, and focus on cryptographic properties of the attacks.
3. MESSAGE AUTHENTICATION
The GWEP 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.
3.1 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 ahold of an entire plaintext corresponding to some transmitted frame, he will then able to inject arbitrary traffic into the network. As we saw in Section 3, 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 _ of any given ciphertext packet _ , he can recover keystream used to encrypt the packet: _\_ _ _ _\_ _,_\_"___________-_. _ N_ ___________-__ $# He can now construct an encryption of a message _ 4 : _% &c'Z)____ _ 4_$_ where _ 4M_____4________ 4d __=_"___________-_. $#
Note that the rogue message uses the same IV value as the original one. However, we can appeal to the following behaviour 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 _ along with its corresponding keystream sequence ___________-_. , 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.4 However, the 802.11 standard does not do this. Whilee 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. We consider this a flaw in the 802.11 standard. In networking one often hears the rule of thumb “be conservative in what you send, and liberal in what you accept.” However, when security is a goal, this guideline can be very dangerous: being liberal in what one accepts means that each low-security option offered by the standard must be supported by everyone, and is thus available to the attacker. This situation is analogous to the ciphersuite rollback attacks on SSL [23], which also made use of a standard that included both high-security and low-security options. Consequently, to avoid security at the least-common denominator level, we suggest that the 802.11 standard should be more specific about forbidding IV reuse and other dangerous behavior.
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 [13] will offer sufficient strength to prevent this attack. Simon et. al had earlier warned in independent work that, givenknown plaintext for a single packet, one can use Property 2 to forge packets until the IV changes [19], and they too recommended replacing WEP’s checksum with a MAC. However, they did not appear to recognize the possibility to replay old IV values indefinitely (Property 3), which heightens the impact of this attack.
3.2Authentication Spoofing
A special case of the message injection attack can be used to defeat the shared-key authentication mechanism used by WEP. The mechanism is used by access points to authenticate mobile stations before allowing them to form an association. After a mobile station requests shared-key authentication, the access point sends it a challenge, a 128-byte random string, in cleartext. The mobile station then needs to respond with the same challenge encrypted using WEP. The authentication succeeds if the decryption of the response calculated at the access point matches the challenge. The ability to generate a an encrypted version of the challenge is considered proof of possession of a key. However, as described in the previous section, it is possible to inject properly encrypted WEP messages without the key. All that is necessary is knowledge of a plaintext/ciphertext pair of the requisite length. It is easy to obtain such a pair by monitoring a legitimate authentication sequence: the attacker learns both the plaintext challenge sent by the access point and the encrypted version sent by the mobile station. From this, it is easy to derive the keystream used to encrypt the response. Since all authentication responses are of the same length, the recovered keystream will be sufficient to create a proper response for a new challenge (received in plaintext). Therefore, after intercepting a single authentication sequence using a particular key, the attacker can authenticate himself with that key indefinitely. This is a particularly serious problem when the same shared key is used by all mobile stations, which is frequently the case in practice. This attack on the authentication protocol was EThere are sophisticated physical layer attacks that may be able to monitor a packet being sent and jam the receiver at the same time; at best such attacks would allow to reuse an IV once. also discovered independently by Arbaugh et al. [2] based on a preliminary version of our results.
3.3 Message Decryption
What may be surprising is that the ability to modify encrypted packets without detection can also be leveraged to decrypt messages sent over the air. Consider WEP from the point of view of
the adversary. Since WEP uses a stream cipher presumed to be secure (RC4), attacking the cryptography directly is probably hopeless. But if we cannot decrypt the traffic ourselves, there is still someone who can: the access point. In any cryptographic protocol, the legitimate decryptor must always possess the secret key in order to decrypt, by design. The idea, then, is to trick the access point into decrypting some ciphertext for us. As it turns out, the ability to modify transmitted packets provides two easy ways to exploit the access point in this way.
3.2Authentication Spoofing
A special case of the message injection attack can be used to defeat the shared-key authentication mechanism used by WEP. The mechanism is used by access points to authenticate mobile stations before allowing them to form an association. After a mobile station requests shared-key authentication, the access point sends it a challenge, a 128-byte random string, in cleartext. The mobile station then needs to respond with the same challenge encrypted using WEP. The authentication succeeds if the decryption of the response calculated at the access point matches the challenge. The ability to generate a an encrypted version of the challenge is considered proof of possession of a key. However, as described in the previous section, it is possible to inject properly encrypted WEP messages without the key. All that is necessary is knowledge of a plaintext/ciphertext pair of the requisite length. It is easy to obtain such a pair by monitoring a legitimate authentication sequence: the attacker learns both the plaintext challenge sent by the access point and the encrypted version sent by the mobile station. From this, it is easy to derive the keystream used to encrypt the response. Since all authentication responses are of the same length, the recovered keystream will be sufficient to create a proper response for a new challenge (received in plaintext). Therefore, after intercepting a single authentication sequence using a particular key, the attacker can authenticate himself with that key indefinitely. This is a particularly serious problem when the same shared key is used by all mobile stations, which is frequently the case in practice. This attack on the authentication protocol was EThere are sophisticated physical layer attacks that may be able to monitor a packet being sent and jam the receiver at the same time; at best such attacks would allow to reuse an IV once. also discovered independently by Arbaugh et al. [2] based on a preliminary version of our results.
3.3 Message Decryption
What may be surprising is that the ability to modify encrypted packets without detection can also be leveraged to decrypt messages sent over the air. Consider WEP from the point of view of
the adversary. Since WEP uses a stream cipher presumed to be secure (RC4), attacking the cryptography directly is probably hopeless. But if we cannot decrypt the traffic ourselves, there is still someone who can: the access point. In any cryptographic protocol, the legitimate decryptor must always possess the secret key in order to decrypt, by design. The idea, then, is to trick the access point into decrypting some ciphertext for us. As it turns out, the ability to modify transmitted packets provides two easy ways to exploit the access point in this way.
3.4.1 IP redirection
The first way is called an “IP redirection” attack, and can be used when the WEP access point acts as a IP router with Internet connectivity; note that this is a fairly common scenario in practice, because WEP is typically used to provide network access for mobile laptop users and others. In this case, the idea is to sniff an encrypted packet off the air, and use the technique of Section 4.1 to modify it so that it has a new destination address: one the attacker controls. The access point will then decrypt the packet, and send the packet off to its (new) destination, where the attacker can read the packet, now in the clear. Note that our modified packet will be traveling from the wireless network to the Internet, and so most firewalls will allow it to pass unmolested. The easiest way to modify the destination IP address is to figure out what the original destination IP address is, and then apply the technique of Section 4.1 to change it to the desired one. Figuring out the original destination IP address is usually not difficult; all of the incoming traffic, for example, will be destined for an IP address on the wireless subnet, which should be easy to determine. Once the incoming traffic is decrypted, the IP addresses of the other ends of the connections will be revealed, and outgoing traffic can then be decrypted in the same manner. In order for this attack to work, however, we need to not only modify the destination IP address, but also to ensure that the IP checksum in the modified packet is still correct—otherwise, the decrypted packet will be dropped by the access point. Since the modified acket differs from the original packet only in its destination IP address, and since both the old and new values for the destination IP address are known, we can calculate the required change to the IP checksum caused by this change in IP address. Suppose the high and low 16-bit words of the original destination IP address were fSg and fQh , and we wish to change them to f 4g and f h4. If the old IP checksum was i (which we do not necessarily know, since it is encrypted), the new one should be i=4j_>iIk9fSg4 k9fShI4 l f g l f h (where the additions and subtractions here and below are one’scomplement) [5, 14].
The trick is that we only know how to modify a packet by applying an XOR to it, and we don’t necessarily know what we need to XOR to i to get i 4 , even though we do know what we would need to add (namely m , f 4g k9f 4h l f g l f h ).
The trick is that we only know how to modify a packet by applying an XOR to it, and we don’t necessarily know what we need to XOR to i to get i 4 , even though we do know what we would need to add (namely m , f 4g k9f 4h l f g l f h ).
We now discuss three ways to try to correct the IP checksum of the modified packet:
The IP checksum for the original packet is known:
If it happens to be the case that we somehow know i , then we simply calculate i 4 as above, and modify the packet by XORing in in_i 4, which will change the IP checksum to the correct value of i 4.
The original IP checksum is not known:
If i is not known, the task is harder. Given o_pi4 l i , we need to calculate PO_ i 4 _"i .
In fact, there is not enough information to calculate P given only o.
In fact, there is not enough information to calculate P given only o.
For example, if oq_ r_sut_vxw_y , it could be that:
A i 4 _ r_sut_vxw_y8_Fiz_ r_surxrxr_r , so PO_ r_sut_v_w_y
A i 4 _ r_s_{rxr}{8_Fiz_ r_suru~_r_w , so PO_ r_s_{~_ru€
A i 4 _ r_s_byxyu.j_Fiz_ r_s~_._yu. , so PO_ r_sx._{ur_w A #b#+#
However, not all D __. values for P are possible, and some are much more likely than others. In the above example, there are four values for P (0x3501, 0x4B01, 0x4D01, 0x5501) which occur more than 3% of the time each. Further, we are free to make multiple attempts—any incorrect
guesses will be silently ignored by the access point. Depending on the value of o , a small number of attempts can succeed with high probability. Finally, a successful decryption of one packet can be used to bootstrap the decryption of others; for example, in a stream of communication between two hosts, the only field in the IP header that changes is the identification field. Thus, knowledge of the full IP header of one packet can be used to predict the full header of the surrounding packets, or narrow it down to a small number of possibilities.
3.5 Summary
In this section, we have shown the importance of using a cryptographically secure message authentication code, such as SHA1-HMAC [13], to protect integrity of transmissions. The use of CRCis 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.
4. COUNTERMEASURES
A i 4 _ r_sut_vxw_y8_Fiz_ r_surxrxr_r , so PO_ r_sut_v_w_y
A i 4 _ r_s_{rxr}{8_Fiz_ r_suru~_r_w , so PO_ r_s_{~_ru€
A i 4 _ r_s_byxyu.j_Fiz_ r_s~_._yu. , so PO_ r_sx._{ur_w A #b#+#
However, not all D __. values for P are possible, and some are much more likely than others. In the above example, there are four values for P (0x3501, 0x4B01, 0x4D01, 0x5501) which occur more than 3% of the time each. Further, we are free to make multiple attempts—any incorrect
guesses will be silently ignored by the access point. Depending on the value of o , a small number of attempts can succeed with high probability. Finally, a successful decryption of one packet can be used to bootstrap the decryption of others; for example, in a stream of communication between two hosts, the only field in the IP header that changes is the identification field. Thus, knowledge of the full IP header of one packet can be used to predict the full header of the surrounding packets, or narrow it down to a small number of possibilities.
3.5 Summary
In this section, we have shown the importance of using a cryptographically secure message authentication code, such as SHA1-HMAC [13], to protect integrity of transmissions. The use of CRCis 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.
4. COUNTERMEASURES
There are configuration options available to a network administrator that can reduce the viability of the attacks we described. The best alternative is to place the wireless network outside of the organization firewall. Instead of trying to secure the wireless infrastructure,
it is simpler to consider it to be as much of a threat as other hosts on the Internet. The typical clients of a wireless network are portable computers that are mobile by their nature, and will frequently employ a Virtual Private Network (VPN) solution to access hosts inside the firewall when accessing via dial-up or from a remote site. Requiring that the same VPN be used to access
the internal network when connected over 802.11 obviates the need for link-layer security, and reuses a well-studied mechanism. To provide access control, the network can be configured such that no routes to the outside Internet exist from the wireless network. This prevents people within radio range of the wireless infrastructure from usurping potentially costly Internet connection bandwidth, requiring VPN use for any outside access. (However, it may be desirable to allow visitors to access the Internet wirelesslywithout additional administrative setup.)
A useful additional measure is to improve the key management of a wireless installation. If possible, every host should have its own encryption key, and keys should be changed with high frequency. The design of a secure and easy-to-use mechanism for automated key distribution to all users is a good subject for further research. Note, though, that good key management alone cannot solve all of the problems described in this paper; in particular, the attacks from section 4 remain applicable.
5. CONCLUSIONS
In this paper, we have demonstrated major security flaws in the WEP protocol and described several practical attacks that result. Consequently, we recommend that WEP should not be counted on to provide strong link-level security, and that additional precautionsbe taken to protect network traffic. We hope that our discoveries will motivate a redesign of the WEP protocol to address the vulnerabilities that we found. Our further hope is that this paper will expose important security principles and design practices to a wide audience, and that the lessons we identify will benefit future designers of both WEP and other mobile communications security protocols.
