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, WEPs 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 WEPs 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 centra l 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 its 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.

Figure 4
walk through of association
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 PDAs 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 keystreami.e., a long
sequence of pseudorandom bytesas 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 todays 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 companys 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 effortthe 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 IVs almost always causes reuse of some of
the RC4 keystream. Since IVs are public, duplicate IVs 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 IVs, 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 IVs 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 contentse.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 attackers 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 IVs,
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 requirementsperhaps 1500 bytes for each of the 224possible IVs, 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
IVs 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 IVs 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 IVs. 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.
CRCs 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. Lets 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 = 10000. 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 IVs 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 IVs 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]
[2]
[3]

James F. Kurose, Keith W. Ross, Computer Networking, A top-down approach featuring

the Internet, 1st edition, Pearson Education, 2001.
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.
N. Borisov, I. Goldberg, and D. Wagner, Intercepting Mobile Communications:

[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]

The Insecurity of 802.1, http://www.isaac.cs.berkeley.edu/isaac/wep- faq.html.

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.
Matthew
Gast,
Wireless
LAN
Security:
A
Short
History,
http://www.oreillynet.com/pub/a/wireless/2002/04/19/security.html, 4/19/2002
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/
NetStumbler home page: http://www.netstumbler.com
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
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
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.
AirSnort home page: http://airsnort.shmoo.com
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.