Wireless networks began with the IEEE 802.11 standard in 1997.
This standard specified everything from how various devices on the
wireless network speak to each other to the security of the network.
When it was first drafted, the authors of the 802.11 standard understood
the need to provide a "privacy" to the wireless network
that would be similar to that provided by wired networks. Their
work towards this regard was termed "Wired Equivalent Privacy",
or WEP for short.
The original intent of WEP was not to provide a secure network
protocol similar to that provided by IPSec, but rather to provide
an equivalent level of privacy to that found on a wired network.
WEP was designed to prevent "casual eavesdropping". While
the design of WEP met its intended goals, the authors of the 802.11
could not have foreseen the deployment configurations systems and
network administrators used for wireless networks. Wireless networks
were deployed in a similar fashion to wired networks -- without
regard to the one fundamental difference between the two. While
wired networks remain constrained within the physical limitations
of the network wire, wireless networks have no physical boundaries.
Because of this fundamental difference, WEP went from being a "good
enough" protocol to an inadequate protocol.
The IEEE 802.11 standard provides for all the definitions and
constructs necessary for wireless networks. Everything from the
physical transmission specifications to the authentication negotiation
is provided. Wireless traffic, like its wired counterpart, consists
of frames transmitted from one station to another. A feature that
sets wireless networks apart from wired networks is that one end
of the communication pair is either another wireless client or a
wireless access point.
The 802.11 standard provides for two modes for wireless clients
to communicate: ad-hoc and infrastructure. The ad hoc mode is geared
for a network of stations within communication range of each other.
Ad hoc networks are created spontaneously between the network participants.
In infrastructure mode, access points provide for a more permanent
structure for the network. An infrastructure consists of one or
more access points as well as a distribution system (i.e., wired
network) behind the access points that tie the wireless network
with the wired network.
To distinguish between different wireless networks, the 802.11
standard defines the SSID (Service Set Identifier). The SSID is
a configurable string of up to 32 characters that identifies a wireless
network. It is similar to the network portion of an IP address for
wired LANs. The SSID can be considered the identity element that
"glues" various components of a wireless LAN together.
Traffic from wireless clients that use one SSID can be distinguished
from other wireless traffic using a different SSID. By using the
SSID, an access point can determine which traffic is meant for it
and which is meant for other wireless networks.
802.11 traffic can be subdivided into three parts: control frames,
management frames, and data frames. Control frames include such
information as Request to Send (RTS), Clear to Send (CTS), and Acknowledgment
(ACK) messages. Management frames include beacon frames, probe request/response,
authentication frames, and association frames. Data frames are,
as the name implies, 802.11 traffic that carries data. That data
is typically considered network traffic, such as IP encapsulated
There are two types of authentication mechanisms used by 802.11:
open authentication and shared key authentication. Open authentication
requires that the client have pre-existing knowledge of the wireless
network SSID. The client must also know whether WEP is in use on
the wireless network and, if it is in use, the value of the WEP
key. With shared key authentication, the wireless client must prove
its knowledge of the secret key. Proof is obtained through a challenge-response
exchange similar to the exchange used in CHAP. The access point
sends a random challenge to the client (in clear text) who then
encrypts the challenge and transmits it back to the access point.
The access point decrypts the response and compares the challenge
to what was transmitted. If the two agree, the client is authenticated.
As discussed below, shared key authentication is actually less secure
than open authentication because it provides several components
for a known plaintext attack.
The WEP Protocol
WEP is a form of electronic codebook in which a given block of
text is encrypted at the sending station, transmitted, and then
decrypted at the receiver. Figure 1 shows how WEP encryption proceeds.
In Figure 1, the plaintext message (1) is run through an integrity
algorithm (the 802.11 standard specifies the use of CRC-32) to produce
an Integrity Check Value (ICV), which is then appended to the end
of the original plaintext message (2). A "random" 24-bit
Initialization Vector (IV) is generated and prepended to the secret
key (which is distributed through an out-of-band method) and that
is then input (3) to generate a seed value for the WEP pseudo-random
number generator (PRNG). The WEP PRNG (4) outputs a key sequence
equal in length to the plaintext/ICV message. This key sequence
and the plaintext/ICV message is then XOR'ed (5) to produce
the WEP ciphertext. The ciphertext is then prepended with the IV
(in plaintext) and transmitted (6).
Once the data is encrypted, it is packaged (Figure 2). The encrypted
data/ICV combination is appended to the IV used, along with the
shared secret, to generate the RC4 keystream. This IV consists of
the 24-bit initialization vector, a 6-bit 0-value pad, and 2-bits
set aside for the key ID. The secret key is 40 bits long. The key
ID allows the network administrator or user to choose one of up
to four separate 'secret' 40-bit keys on the wireless
device. This allows the flexibility of providing users different
keys for different wireless networks, or for easily switching between
keys should one secret key become compromised.
One confusing feature of WEP is the length of the keys. While
a 64-bit key is used to generate the RC4 keystream, which is then
XOR'ed to the data/ICV combination, 24-bits of that key is
the Initialization Vector. This leaves only 40-bits for the actual
Realizing the problems with WEP, the IEEE proposed changes to
the WEP protocol in 2001. This new version of WEP, known as WEP2,
increases the IV space from 24 to 128 bits and provides for mandatory
Kerberos V support. While increasing the IV size to 128 bits does
alleviate the IV collision problem of WEP (discussed below), it
does nothing to eliminate the problem of known plaintext attacks,
keystream reuse (described below), the problems with rogue access
points, and denial-of-service attacks against access points and
wireless clients. Some vendors have added support for WEP2 keys
in their products but complete support for the entire WEP2 proposal
has yet to be achieved.
Initialization (IV) Weaknesses
WEP2 only appeared recently and is still making its way to the
marketplace. Most existing WEP-based wireless networks were designed
around the earlier WEP standard. If you already have or are thinking
of purchasing a WEP network that uses the 24-bit IV, it is worth
considering the implications. An IV space of only 224 yields approximately
16 million possible IV keys. The 802.11 standard does not specify
any method to choose the IV. Many vendors designed the firmware
for their wireless devices to start the IV at 0 (that is 00:00:00)
at device initialization and increment each successive IV value
by 1. This is reminiscent of the old TCP Sequence Number incrementing
on UNIX by 64K for every packet, which results in an increase in
low-value IV reuse -- a widely known weakness of keystreams.
Another weakness related to the IV comes from its limited size
as defined by the 802.11 standard. Because the IV is only 24 bits
wide, an 11-Mbps wireless network can easily exhaust all IV values
within a few hours of use by several clients. This then leads to
the possibility of IV collisions. IV collisions occur when two packets
are encrypted with a keystream generated from the same IV value,
v, and secret key, k. A collision can result in the attacker's
ability to derive the plaintext in the encrypted in the wireless
packets. As shown in Figure 1, the plaintext/checksum message is
XOR'ed with the RC4 keystream generated by the IV/secret key
combination. If two packets are encrypted with the same keystream
(i.e., an IV collision has occurred), the keystream can be removed
by XOR'ing the two packets together. This leaves the XOR combination
of the plaintext data in the two packets. Although this may not
seem to be a problem, remember that IP traffic tends to be well
structured. This feature can be used by an attacker to determine
the value of the data by looking for text that, when XOR'ed
with itself, results in the XOR of the two plaintexts .
A related problem to IV collision is that given the fact that
a keystream can be recovered from a WEP packet, it is possible for
an attacker to use that stream later to decrypt other packets. Because
the IV space is so limited, an attacker can seek to capture keystreams
by sending traffic into a network with various IV values. The keystreams
can be extracted by XOR'ing the encrypted traffic with the
known plaintext. This, in effect, creates a dictionary of keystreams.
Later when legitimate traffic crosses the wireless network, the
attacker can intercept it and, if he has a keystream for the IV
used with the encryption of that traffic, he can XOR out the keystream
and recover the plaintext information .
Another approach that can be used to attack a wireless network
is a known plaintext attack. In this attack, the attacker knows
the plaintext message and has a copy of the ciphertext. The missing
piece is the key used to encrypt the plaintext (or decrypt the ciphertext).
A simple approach to implementing a known plaintext attack against
WEP would be to send a target system on the wireless LAN a known
piece of data and then capture that data as it is transmitted to
the destination. This data can be generated by a simple piece of
email. Once the attacker has captured the encrypted WLAN traffic
of the email sent to the target, he will have three pieces of a
four-piece puzzle: the known plaintext, the encrypted data, and
the IV. It is a trivial matter to take all of those pieces and use
a dictionary attack to try and determine the secret key. Another
possibility is to use the challenge/response exchange used by the
shared key authentication mechanism of the 802.11 standard as the
basis of a known plaintext attack. Here the known plaintext is the
random challenge sent by the access point to the client, and the
ciphertext is the response provided by the client.
As with any password-based security scheme, WEP's security
relies on the difficulty of discovering the secret key through a
brute-force attack. And, as with any password or secret key, this
difficulty is related to the length and composition of the key as
well as how often the key is changed. One feature of WEP that originally
was determined to be an asset (but later turned out to lead to one
of the more dire attacks against it) was that WEP is self-synchronizing
for each message. This feature comes out of the fact that the IV
is transmitted, in plaintext, with each packet. While 802.11 suggests
that the IV values change, the standard leaves it up to the implementer
to decide how often the IV changes and how. In the best-case scenario,
the IV should be a random value. However, as mentioned previously,
some vendors implemented the 802.11 standard in their wireless cards
so that the IV gets reset to 00:00:00 whenever the card or system
is reset and then increments linearly with each packet sent.
One side effect of the known plaintext attack is that the attacker
can take the ciphertext and XOR it with the known plaintext to recover
the keystream. This keystream can then be used (with the correct
IV attached) to inject packets into the wireless network by reusing
the keystream and XOR'ing it with new data. In this way, an
attacker can insert packets to the wireless network without actually
authenticating to the access point.
Fluhrer, Mantin, and Shamir
In August of 2001, Scott Fluhrer of Cisco Systems and Itsik Mantin
and Adi Shamir of the Computer Science Department of The Weizmann
Institute in Israel released a paper discussing weaknesses in the
Key Scheduling Algorithm (KSA) of RC4. The KSA derives an initial
state from a variable size key and then feeds this state to the
pseudo-random number generator (PRNG) of RC4, which uses the input
to generate a pseudo-random keystream.
Problems with RC4 are not new. In 1995, Andrew Roos posted some
preliminary results from an analysis of RC4's PRNG to the Usenet
newsgroup sci.crypt. In 1996, Ian Farquhar posted to sci.crypt that
there was an approximately 35% probability that the first byte of
the keystream generated by RC4 would be the same as the first byte
of the key.
Fluhrer, Mantin, and Shamir discovered two weaknesses in the KSA.
The first weakness is the existence of large classes of "weak"
keys where a small part of the secret key determines a large number
of bits of the KSA output . This ultimately results in the problem
where the initial output of the RC4 algorithm is disproportionally
affected by a small number of key bits. The second vulnerability
is related to the first. It occurs when part of the key presented
to the KSA is exposed to the attacker (as in WEP, where the IV is
exposed). When the same secret part of the key is used with numerous
different exposed values, an attacker can rederive the secret part
by analyzing the initial word of the keystreams with relatively
little work. The attack that Fluhrer, Mantin, and Shamir devised
works against any key size, including both the 24-bit key of WEP
and the 128-bit key of WEP2, and does not matter whether the IV
precedes the secret key or follows the secret key.
The work done by Fluhrer, Mantin, and Shamir was applied by Adam
Stubblefield of Rice University and John Ioannidis and Aviel Rubin
of AT&T Labs. Their work utilized off-the-shelf hardware and
software and was able to crack the encryption provided by WEP on
their test network within the span of a few hours. Their work was
duplicated by others and, while Stubblefield et al. did not release
their source code to the public, they noted that two other tools
were currently publicly available: airsnort and Tim Newsham's
Securing Wireless Networks
Wireless networks are being deployed at an ever-increasing pace.
According to a recent report by Allied Business Intelligence, 4.9
million wireless nodes were shipped worldwide in 2000, and the number
is expected to climb to 55.9 million wireless nodes by 2006. This
explosion in deployment of wireless devices and wireless LANs will
result in considerable difficulties for systems and network administrators
if the problems with WEP are not addressed. To deal with WEP's
problems, several vendors (including Cisco Systems, Agere Systems,
Enterasys Networks, and Avaya) have each devised proprietary solutions
to address some of WEP's near-term problems.
Some vendors have adopted the Extensible Authentication Protocol
(EAP) authentication mechanism in the IEEE 802.1x standard. This
standard allows for port-based access control where access to the
network is granted only after the client authenticates. For WLANs,
this method works very well because access can be granted by the
access point once the user has successfully authenticated to a RADIUS
server. This also provides for an interim solution until the 802.11i
working group can provide a better security mechanism for wireless
However, network administrators can still deploy wireless networks
even with the current problems inherent with WEP. The caveat is
that wireless networks must be afforded special consideration when
deployed. With that in mind, network administrators deploying wireless
access points should consider the placement of the access point
very carefully. Wireless access points should not be connected to
the internal wired LAN even if WEP is enabled. With the well-known
weaknesses of WEP and the low level of difficulty in cracking WEP-based
traffic, the wireless LAN is better viewed as an insecure or "dirty"
network. Thus, access points should be placed outside a firewall.
Access into the network should be provided either through Secure
Shell or through an IPSec-based VPN solution. The Secure Shell connection
and the IPSec-based VPN connection provides for both user authentication
as well as user differentiation.
Most access points can accommodate MAC filtering and should be
configured to do so, even though MAC addresses can be spoofed. WEP
should be active; even with the weaknesses inherent with WEP, there
is no need to make it easier for an adversary to attack the network.
Network address management is a difficult issue that must also be
considered. One benefit to utilizing wireless devices that can support
802.1x authentication mechanisms is that network addresses can be
provided after authentication is complete and access has been granted.
However, many WLAN devices do not support EAP authentication. For
wireless LANs based on those devices, an external DHCP server providing
network addresses to specific clients only on the wireless LAN is
one solution -- with the understanding that this host's
only function is to provide addresses to wireless clients. However,
that server will probably become the focus of access as well as
denial-of-service attacks. While not optimal, it does provide for
network address management on the wireless LAN. Another possibility
is to use the built-in DHCP server available on many wireless access
The firewall should allow only IPSec traffic or Secure Shell traffic
into the network. All traffic from the clients should be routed
through the IPSec VPN or the Secure Shell connection. Figure 3 shows
a wireless network configured as described above. In step 1, the
wireless client authenticates and associates to the wireless access
point using open authentication. The access point is configured
to filter based on a MAC address. Once authentication and association
completes, the access point forwards DHCP requests to the DHCP server.
The server assigns the wireless client a network address in step
2. With the wireless client now on the wireless network, the client
can proceed to access the "wired" network beyond the firewall.
To do this, the client either sets up an IPSec VPN tunnel to the
VPN device or uses Secure Shell to connect to the SSH server, as
shown in step 3 of Figure 4. The firewall is configured to permit
only SSH traffic or IPSec traffic to pass through. All other traffic
Until the problems with WEP are properly addressed, wireless networks
will remain a significant problem for administrators. However, even
with the current difficulties posed by wireless LANs, it is still
possible to deploy them if they are treated with the proper respect
1. N. Borisov, I. Goldberg, and D. Wagner. Intercepting Mobile
Communications: The Insecurity of 802.11. Published in the Proceedings
of the Seventh Annual International Conference of Computing and
Networking. July, 2001.
2. J. Walker. Unsafe at any key size; An analysis of the WEP encapsulation.
IEEE Doc: 802.11-00/362. October 2000.
3. S. Fluhrer, I. Mantin, and A. Shamir. Weakness in the Key Scheduling
Algorithm of RC4. August 2001.
4. A. Stubblefield, J. Ioannidis, and A. Rubin. Using the Fluhrer,
Mantin, and Shamir Attack to Break WEP. AT&T Labs Technical
Report TD-4ZCPZZ. August 2001.
5. Institute for Electrical and Electronic Engineers, "ANSI/IEEE
Std 802.11, 1999 Edition", 1999
Ido Dubrawsky has been working in UNIX and network administration
field for nine years. When not working on security, he spends his
free time with his wife, Diana, their two children, and their dog,
Reidy. He is currently employed by Cisco Systems in the Cisco Secure
Consulting Service as a Network Security Engineer.