IEEE 802.11 Security

IEEE 802.11 Security
In today’s world, it is mandatory for the administrator of any computer network to make network
security a top priority. The threat is not only that an intruder will type his way into his
school records and change his grades: Computer networks are also under full-time assault from
people with varying relationships to the enterprisers running them. Attacks come from anonymous
virus distributors who have utterly no relationship at all with the enterpriser, from anarchic
crackers who bear a grudge against particular computer or software manufacturers, or who
delight in discovering vulnerabilities in OSs, from thrill-seeking “script kiddies” looking for some
illegal amusement and peer recognition, from thieves searching for personal information for use
in identity thefts or as blackmail material, from unscrupulous competitors looking for trade data  and secrets, and even from disgruntled or corrupted insiders that work at any level of the beleaguered
enterprisers themselves. Administrators of wired networks have to maintain solid firewalls,
keep and review network traffic logs, update software with anticracker patches, nag their users
to use strong passwords, scour their machines for “spyware” and purge it, make sure their virus
protection is up-to-date, and defend against physical break-ins. Every attack prepared for launch
against wired networks is automatically readymade for use against wireless networks as well. Wireless
network administrators must defend against the same onslaught of adversaries that wired networks
face, but in an environment that is much more convenient for attackers: WLANs operate
within hard-to-control physical boundaries. Anyone who can receive their signals has already
accessed their network. From there, with enough determination and patience, it is only a matter
of time.
Administrators can make that time too long to be acceptable to attackers, say, with encryption.
But encryption comes with a cost of its own in quality of service, and a sufficient level of encryption
may come with too high a price to be acceptable to users. A 128-bit encryption steals nearly 2 Mbps
of bandwidth from every connection [458]. If throughput is already downgraded because of weak
signal strength, these 2 Mbps take on added significance: the 802.11b claims a speed of 11 Mbps.
A more realistic estimate of actual throughput is about 3.5 to 4.5 Mbps without WEP enabled and
2.5 to 3.5 Mbps with WEP enabled [465]. And some widely used encryption schemes have already
been broken, by techniques that grow in duration only linearly when 128-bit encryption is introduced,
rather than exponentially. Today’s prevalent encryption schemes are under constant investigation. It
is still only a matter of time.
Unfortunately, all of the security mechanisms defined in the 1999 version of the IEEE 802.11
standard have been proven ineffective. The problems range all the way from issues with the lowest
primitives up to the high-level protocols used [457]. Already in 2003, the exhausting work of layering
security on top of the 802.11 was taking its toll, and some vendors were considering migrating to
a Bluetooth infrastructure to cut their losses [459]. Securing wireless networks [470] is a persistent,
dynamic struggle.
Therefore, WLAN administrators must be both wary and proactive, and just as determined as
their adversaries.
4.3.1 Authentication
The two IEEE 802.11 authentication schemes are Open System authentication and Shared Key
authentication. With either scheme, authentication takes place between two STAs, and authentication
management frames may only be unicast. However, deauthentication frames may be sent to
groups. Authentication must be used between STAs and APs in an infrastructure BSS, and may be
used between STAs in an IBSS [452].
Open System authentication is the simplest of the available authentication algorithms. Essentially
it is a null authentication algorithm [452]. It simply provides a way for two parties to agree to exchange
data and provides no security benefits [456]. Any STA can (potentially) become authenticated to
a STA configured for Open System authentication. However, a STA configured for Open System
authentication may refuse to authenticate with another STA. APs can be set up to filter out the MAC
addresses of particular STAs – perhaps, past offenders [452, 458]. In open system authentication,
one party sends a MAC control frame, known as an authentication frame, to the other party. The
frame indicates that this is an open system authentication type. The other party responds with its
own authentication frame and the process is complete [456]. Obviously, a network using Open
System authentication must have other, higher-level security protocols in place if it is to maintain
any semblance of control over its data.
Shared Key authentication requires that the WEP option be implemented. With this scheme, STAs
can only authenticate to one another if they both share a common encryption key, previously delivered
in some secure way left unspecified by the IEEE 802.11 standards. The plan was fine for a while, but WEP is now thoroughly compromised. It has been concluded that “WEP is not a well-designed
cryptographic system” [456].
The following is a description of the four-step Shared Key authentication process:
• A station requesting 802.11 service sends an authentication frame to another station.
• When a station receives the initial authentication frame, the station replies with an authentication
frame containing 40/128 octets of challenge text.
• The requesting station copies the challenge text into an authentication frame, encrypts it with
a shared key using the WEP service, and sends the frame to the responding station.
• The receiving station decrypts the challenge text using the same shared key and compares it to
the challenge text sent earlier. If they match, the receiving station replies with an authentication
acknowledgement. If not, the station sends a negative authentication notice [456].
4.3.2 WEP
In this section, we discuss in the WEP theory of operation described in the IEEE 802.11 standards.
The WEP algorithm is a form of electronic code book in which a block of plaintext is bitwise
XORed with a pseudorandom key sequence of equal length. The key sequence is generated by the
WEP algorithm. WEP is a symmetric algorithm in which the same key is used for encipherment
and decipherment. The secret key is concatenated with an initialization vector (IV) and the resulting
seed is input to a pseudorandom number generator (PRNG). The PRNG outputs a key sequence k
of pseudorandom octets equal in length to the number of data octets that are to be transmitted in
the expanded MPDU plus 4 (since the key sequence is used to protect the integrity check value
(ICV) as well as the data). Two processes are applied to the plaintext MPDU. To protect against
unauthorized data modification, an integrity algorithm operates on P (the plaintext) to produce an ICV.
Encipherment is then accomplished by mathematically combining the key sequence with the plaintext
concatenated with the ICV. The output of the process is a message containing the IV and ciphertext.
As the IEEE 802.11 WEP theory continues, note the discrepancy between the asserted value of
the IV and the way it is transmitted.
The WEP PRNG is the critical component of this process, since it transforms a relatively short
secret key into an arbitrarily long key sequence. This greatly simplifies the task of key distribution,
as only the secret key needs to be communicated between STAs. The IV extends the useful lifetime
of the secret key and provides the self-synchronous property of the algorithm. The secret key remains
constant while the IV changes periodically. Each new IV results in a new seed and key sequence, thus
there is a one-to-one correspondence between the IV and k. The IV may be changed as frequently as
every MPDU and, since it travels with the message, the receiver will always be able to decipher any
message. The IV is transmitted in the clear since it does not provide an attacker with any information
about the secret key, and since its value must be known by the recipient in order to perform the
decryption.
IEEE recognized the vulnerability of WEP if implementers do not change the IV after each
MPDU is generated: The contents of some fields in higher-layer protocol headers, as well as certain
other higher-layer information, is constant or highly predictable. When such information is transmitted
while encrypting with a particular key and IV, an eavesdropper can readily determine portions of
the key sequence generated by that (key, IV) pair. If the same (key, IV) pair is used for successive
MPDUs, this effect may substantially reduce the degree of privacy conferred by the WEP algorithm,
allowing an eavesdropper to recover a subset of the user data without any knowledge of the secret
key [452]. Here the standards caution implementers to change the IV for each MPDU.
The WEP algorithm is applied to the frame body of an MPDU. The (IV, frame body, ICV)
triplet forms the actual data to be sent in the data frame. Decipherment begins with the arrival of a message. The IV of the incoming message should be used to generate the key sequence necessary
to decipher the incoming message. Combining the ciphertext with the proper key sequence yields
the original plaintext and ICV. Correct decipherment should be verified by performing the integrity
check algorithm on the recovered plaintext and comparing the output ICV to the ICV transmitted
with the message. If ICV is not equal to ICV, the received MPDU is in error [452].
Here is an expert’s analysis of the WEP theory of operation.
To protect traffic from brute-force decryption attacks, WEP uses a set of up to four default keys,
and it may also employ pairwise keys, called mapped keys, when allowed. Default keys are shared
among all stations in a service set. Once a station has obtained the default keys for its service set, it
may communicate using WEP.
Key reuse is often a weakness of cryptographic protocols. For this reason, WEP has a second
class of keys used for pairwise communications. These keys are shared only between the two stations
communicating. The two stations sharing a key have a key mapping relationship.
Reuse of the keystream is the major weakness in any stream cipher-based cryptosystem. When
frames are encrypted with the same RC4 keystream, the XOR of the two encrypted packets is
equivalent to the XOR of the two plaintext packets. By analyzing differences between the two
streams in conjunction with the structure of the frame body, attackers can learn about the contents
of the plaintext frames themselves. To help prevent the reuse of the keystream, WEP uses the IV to
encrypt different packets with different RC4 keys. However, the IV is part of the packet header and
is not encrypted, so eavesdroppers are tipped off to packets that are encrypted with the same RC4
key. Implementation problems can contribute to the lack of security. The 802.11 admits that using
the same IV for a large number of frames is insecure and should be avoided. The standard allows for
using a different IV for each frame, but it is not required.
That is why WEP is not a well-designed cryptographic system, and the extra bits in the key will
help very little. The best publicly disclosed attack against WEP can recover the key in seconds, no
matter what its length is [456]. To make matters worse, some “helpful” person invested their time
into generating a cracker tool. Publicizing the threat was a service to everyone, but we leave it as
an exercise for the readers to determine what satisfaction is obtained by the author of tools that turn
threat into reality and waste millions of dollars of investment. However, the tool was published; it
is available on the Internet, and attackers can use it to crack WEP systems open at will [457]. Such
a “helpful” tool also enables countless others who would otherwise be unable to mount a successful
attack on WEP. Researchers have discovered other problems with the WEP algorithm and the way it
uses RC4. The first step an 802.11 security gives today should be “use something besides WEP.”
WEP should not be relied on in 802.11 networks. Here is one expert’s description of the WEP
algorithm:
• It is assumed that the secret key has been distributed to both the transmitting and receiving
stations by some secure means.
• On the transmitting station, the 40-bit secret key is concatenated with a 24-bit IV to produce
a seed for input into the WEP PRNG.
• The seed is passed into the PRNG to produce a stream (keystream) of pseudorandom octets.
• The plaintext PDU (protocol data unit) is then XORed with the pseudorandom keystream to
produce the ciphertext PDU.
• This ciphertext PDU is then concatenated with the IV and transmitted on the WM.
• The receiving station reads the IV and concatenates it with the secret key, producing the seed
that it passes to its own PRNG. • The receiver’s PRNG should produce the identical keystream used by the transmitting station,
so that when XORed with the ciphertext, the original plaintext PDU is produced [460].
Several researchers began publishing papers on WEP imperfections in 2001. The first such paper
points out that since the IV used by WEP is transmitted in the clear, it is possible to gain enough
information from transmissions with identical IVs to decrypt WEP-encrypted data without knowledge
of the secret key [474]. When you XOR two ciphertexts that have the same IV, the keystream is
cancelled out. The result is the XOR of the two original plaintexts. If one of the plaintexts is known,
the other can now be obtained, as can the keystream used to generate both. A dictionary can then be
created that specifies the keystream used for each IV. In this way, an attacker can eventually decrypt
all transmissions on the WM without ever actually obtaining the secret key [460].
Here’s how it works: K is for key, Cx is for ciphertext x, and Px is for plaintext x. Given two
ciphertexts produced with the same <IV, K> pair:
C1 = RC4(IV, K) XOR P1
C2 = RC4(IV, K) XOR P2
XORing the two ciphertexts together removes the pseudorandom stream generated by RC4 and
produces the XOR of the two plaintexts:
C1 XOR C2 = (RC4(IV, K) XOR P1) XOR (RC4(IV, K) XOR P2)
C1 XOR C2 = P1 XOR P2
The XOR of the two plaintexts makes it significantly easier to recover the two plaintexts because
of their well-known structure [457].
A 128-bit encryption does not improve the situation. It is the reuse of IVs that creates the
vulnerability, and this is nearly impossible to avoid [460]. Unfortunately, the IV in the IEEE 802.11
WEP is only 24 bits long. A 24-bit number has values from 0 to 16,777,216 – so there are about
17 million IV values possible. A busy access point at 11 Mbps is capable of transmitting/receiving
about 700 average-sized packets a second. If a different IV value were used for every packet, all the
values would be used up in less than seven hours. IV values are bound to be reused [457].
To make matters worse, many devices reset their IV to the same “startup” value when rebooted,
and the same pseudorandom sequence of IVs results as after every previous reboot. “If there are 20
mobile devices turned on in the morning, and they all start with the same IV value and follow the
same sequence, then the same IV value will appear 20 times for each value in the sequence” [457].
Collecting transmissions that have the same IV is child’s play.
Another 2001 paper found a bias in the pseudorandom encryption stream produced by RC4, the
PRNG algorithm used by the 802.11 [475]. The algorithm was reverse-engineered and made public
in 1994. It uses a 256-byte array containing a permutation of the numbers 0–255 [457]. It was found
that the second word of the pseudorandom stream is zero twice as often as should be expected (1 in
128 instead of 1 in 256) [475]. There are two consequences of this seemingly unimportant defect: it
is easy to distinguish RC4 ciphertext from other algorithms’ ciphertexts, and it sets the stage for the
next paper’s key-discovery attack [457].
Again in 2001, a “weak” class of keys used in RC4 was discovered. These “weak” keys expose
information about the secret key, and, armed with this revelation, an attack was developed that
recovers the entire secret key in WEP relatively quickly [476]. The researchers estimated that this
could be accomplished after collecting approximately 4 million packets, although they did not test the
attack on an actual WEP system. Investigators at AT&T did put the attack to the test, and achieved
success with about 5 million packets – about three hours on a partially loaded network [460]. In a
classic stroke of bad luck, the set of weak keys discovered were exactly those used by WEP [457].
They are formed when certain values of the IV are attached to the secret key and processed by RC4.
The attack, remarkably, only needs two pieces of information to work: the IV and the first
encrypted byte. The former is transmitted in the clear, and the latter in most, if not all, WEP encrypted
transmissions is the 802.2 LLC header that contains 0xAA [460]. The 128-bit encryption only makes
the key recovery slightly more difficult than the 40-bit encryption [457]. Lengthening the IV (which would require a rewrite of the 802.11 standards) makes the time involved in this attack grow only
linearly [460].
Yet another 2001 paper describes vulnerabilities in 802.11 beyond WEP. Its authors zero in on
problems with the authentication and access control protocols, and show that the challenge-response
authentication protocol for shared key authentication has a weakness that allows an attacker to determine
the keystream used to encrypt a response, and then use this keystream to gain authentication to
the network [477]. In addition, the service set identifier (SSID) used by each network is worthless
as a security mechanism, because in many 802.11 management frames, it is transmitted in the clear
[460]. Another problem identified in this paper has to do with hardware. Many 802.11 adapters allow
their MAC address to be set by the user, and therefore it is a relatively simple procedure to sniff the
WLAN for MAC addresses that are permitted access, change the MAC address of the (attacker’s)
802.11 adapter, and gain access to the WLAN [460].
While 802.11 WLANs have come under increasing attack as the technology has become more
popular, some denial of service (DoS) attacks can be entirely unintended: 802.11, 11b, and 11g all
use the 2.4 to 2.5 GHz ISM band, which is extremely crowded at the moment. Cordless phones, baby
monitors, X10 cameras, and a host of other devices (garage-door openers, microwave ovens, medical
devices, and other wireless networks themselves [465]) operate in this band and can cause packet
loss or outright disruption of service in 802.11 networks [459]. For safety’s sake we turn off our cell
phones when we enter a hospital, and turn off all wireless devices on a plane that is taking off or
landing.
Another hardware-based DoS attack is not an accident. Any attacker with a bigger amplifier,
antenna, or using more power, can deny service to an individual or group at the RF level and because
our equipment is readily available to our attackers attempts to prevent such jamming in the consumer
realm are futile [457].
DoS attacks can be launched against WLANs in the software realm, too. Because 802.11 management
frames that control association services are unauthenticated, it is easy to forge a packet
that purports to be from an AP and tells all the STAs associated with it to disassociate. There is
nothing that can be done to prevent this and an attacker could keep the station(s) off the network
indefinitely (or at least until someone turned off the computer sending the forged packets) [459]. Is
there a cracker’s tool available on the Internet that does this? You bet.
When cracker’s tools are freely available, attackers don’t have to be particularly computer-savvy.
Anyone can implement the above attack, which is otherwise fairly complicated (and tedious – who
wants to sit down and formulate the string of ones and zeros it would take to fabricate a packet?).
The 802.11 wireless networks are particularly vulnerable to what are known as man-in-themiddle
(MiM) attacks, because “there are no integrity guarantees provided at the link layer” and
it is simple to spoof MAC addresses [457]. MiMs can be established regardless of any protections
(Wi-Fi Protected Access (WPA), Robust Security Network (RSN), Virtual Private Network (VPN),
and so on) that you might be using but do not necessarily pose a threat if the (higher-level) security
protocol is strong [457]. The attacker picks as his target a STA that is already associated with a
legitimate AP, and sets up a false AP with the same SSID and MAC address as a genuine AP on
the network within range of the victim STA (but not the one currently associated with the target).
The next step is to forge a deauthentication message that appears to be from the associated AP and
send it to the target STA. The STA has no choice but to drop its association with its current AP
and attempt to reassociate (with any AP in range). The original AP denies it service because of the
counterfeit deauthentication message, and the victim STA associates with the attacker’s false AP. The
false AP immediately associates with a valid AP, forwarding all traffic, and proceeds to authenticate.
Now all messages sent between the real, hoodwinked, AP and the victim STA are controlled by
the attacker, and these messages can be analyzed and then modified for use in further attacks. If
DoS is the object, nothing prevents the attacker from “replaying” old messages and flooding the
network [457]. Another MiM that “has been a plague on wired networks for some time” is known as address
resolution protocol (ARP) spoofing, and it can be used against a WLAN if the encryption scheme
has been broken, where it can still succeed more often than not [457]. ARP is used to learn the MAC
address of a known IP address, and ARP packets do not have any integrity protection [457]. When
a STA wants to communicate with a particular IP address it broadcasts an ARP-Request to acquire
the corresponding MAC address. An attacker simply says “it’s me” and the requesting STA puts an
incorrect entry into its ARP cache. From then until the entry times out, the attacker receives all the
data intended for the spoofed machine from the victim STA [457].
Additionally, when a STA has authenticated with an AP, an attacker can simply hijack the session
by sending the STA phony disassociation frames and continuing to send forged management frames to
keep the STA from reassociating. The AP has no idea this is happening; it believes an authenticated
session is still in place. The attacker simply masquerades as the disassociated STA, taking over
the session [457]. This technique can be used to gain unpaid access at a public hotspot, at least for
a short time.
The most widespread attacks come by way of cracker’s tools that are targeted specifically at
802.11 WLANs. There are tools to facilitate “war-driving” (identifying wireless networks, users, and
authentication procedures, which literally involves driving around), tools for network mapping, tools
for sniffing and monitoring wireless networks, and tools for gaining unauthorized access to WLANs
[459]. Some of these tools only work in conjunction with a global positioning system (GPS) unit, and,
of course, specialized antennas. Do not let that fool you into thinking that this is not an extensive
problem: One antenna distributor is famous (and cracker-endorsed) for its “war-driving bundles”
[459]. Considering the potential payoffs that can be reaped from a compromised network, intruders
will not be dissuaded by the initial cost of a little apparatus. And some of the network-diagramming
activities may not even be criminal (although they clearly involve an indisputable invasion of privacy).
War-driving (also known as wilding) is done from a vehicle containing a computer and whatever
else is appropriate for the cracker’s tool in use. The attacker simply drives around the likely location
of a WLAN, or sits in an enterprise’s parking lot, and the software does the real work. War-driving
tools will find a network’s SSID, MAC addresses, IP addresses, WEP status (on or off), and the length
of the WEP key. Wireless mapping tools will map this information with GPS accuracy, giving, of
course, the locations of the all-important APs, but also the locations of the GPS coordinates with
the highest signal strength found for the AP (a tool does this!). In fact, a vehicle is not required
if the attacker can walk through an enterprise’s buildings: There are war-driving tools designed to
run on Pocket-PCs. Some war-driving tools broadcast the 802.11 Probe Requests asking for network
information, and can be blinded by administrators who do not allow Probe Responses to be sent to
unknown machines. If the attacking machine is masquerading as a legitimate machine, this measure
is ineffective. Other war-driving tools are entirely passive, listening only, and gleaning information
from the network’s transmissions. Some tools are specialized to collect only WEP-encrypted data for
use in breaking the WEP key [457, 459].
Wireless sniffers are available that specifically decompose 802.11 packets and enable WEP
cracking. Wireless monitoring tools will perform network analysis and filter out information the
attacker has no interest in. In addition, they will identify the protocols being used by the target
machines and unearth details about AP-to-client STA relationships [459].
Tools for gaining access to the 802.11 WLANs include a number of those that crack WEP
encryption. In addition, there are tools that facilitate MiM attacks on 802.11 networks, and others
that manage DoS attacks [457, 459]. Anyone can use them.
There is a special 802.11 implementation that is of concern, not only to administrators, but to
casual laptop owners as well. When using a public hotspot, special care must be taken to protect
the laptop from malicious hotspot users. On a corporate network, users are authorized to use the
network because they are trusted, and presumably have no reason to attack each other. At a public
hotspot, users are authorized to use the network because they paid a fee, not because they are trusted
[457]. A measure of vigilance is in order. The threat is that your laptop is authenticated to a network on which potential attackers are now legitimate users, with all the rights and privileges that pertain
thereto. If an attacker is present, he is already way too close (were you on your corporate network,
he would already be past your corporate firewall). Data you send and receive can be intercepted,
and your computer’s files can be copied, modified, mutilated, or deleted. At a public hotspot, the
prospect of someone accessing your computer should be taken very seriously [457]. If your computer
is configured for file sharing among your colleagues when on your corporate network, and you forget
to disable this feature before joining a hotspot network, there is a real danger it will be noticed by
a stranger and investigated [457]. Worse, someone may already be interested in your computer and
transmissions and “stalk” you until you enter a hotspot. They may want your company’s plans, or they
may want your personal information. Furthermore, since they are already on your network, attackers
can easily slip a Trojan virus on your computer, and if your antivirus software does not detect it,
your computer from then on, no matter where you are, will send out its location to the attacker and
leave a back door open for unrestricted access by the attacker [457]. Public hotspots are attractive
because they are convenient and the atmosphere is relaxed. Attackers can find them convenient, too,
and their relaxed security environment attractive.
In 1999, 802.11b still relied on WEP for data encryption. In August, 2001 the 802.11 working
group began work to remedy WEP’s shortcomings [465], and in October 2002, the Wi-Fi Alliance
announced a security solution that supercedes WEP called WPA. This standard was formerly known
as Safe Secure Network (SSN). WPA is designed to work with existing 802.11-based products and
offers forward compatibility with the 802.11i. All of the known shortcomings of WEP are addressed
by WPA which features packet key mixing, a message integrity check, an extended initialization
vector, and a rekeying mechanism [466].
These features of WPA are embedded in a new protocol called the Temporal Key Integrity Protocol
(TKIP), which was developed specifically in order to facilitate security upgrades in WEP-enabled
networks. TKIP is now a fundamental part of WPA and serves as a means to address the WEP
weaknesses mentioned above. WEP’s weaknesses can be summarized as: (1) The IV value is too
short and is reused. (2) “Weak” keys are occasionally created and easy to crack. (3) Messages are
not effectively checked for tampering. (4) The master key is applied in a perilous way and need not
be updated. (5) Messages can be replayed with impunity during DoS attacks [457].
Under WPA, Per-Packet Key Mixing addresses the second and fourth vulnerabilities by changing
the encryption key for every frame sent and constructing IVs in a way that avoids the creation of weak
keys. A Message Integrity protocol to prevent tampering is in place to handle the third WEP weakness.
The size of the IV is increased and the way in which it is chosen is changed in order to cover the
first weakness. The fourth weakness is further addressed by adding a resource for changing the keys
in use. Finally, a TKIP Sequence Counter is introduced to take care of the fifth insecurity [457].
The TKIP mechanism for per-packet key mixing is a significant improvement over the simple
WEP key. The WPA preshared key differs dramatically from the WEP key. Under WPA, the preshared
key is used only in the initial setup of the dynamic TKIP key exchange. This base key is never sent
over the air or used to directly encrypt the data stream [468]. In TKIP, there are multiple levels of
keys derived from a single master key. Session keys are derived from the master key. These keys
are then split into pieces for various uses, one of which is encryption. What per-packet key mixing
does is to further derive a key specifically for each and every packet sent. In other words, at the
level of RC4 (802.11’s choice of encryption algorithms), every packet uses a different, and apparently
unrelated, key [457]. Note that it is not the session and master keys that change for every packet, but
rather the derived, “mixed” key used for RC4 encryption.
The key mixing process makes use of the extended, 48-bit IV and adds the use of the MAC
address of the sending machine to prevent two STAs from producing identical mixed keys. The
problem is that the computation to derive the key can be processing intensive. There is not a lot of
computing power in the MAC chip of most WEP-based Wi-Fi cards. So the calculation was divided
into two phases. Phase 1 involves all the data that is relatively static, such as the secret session key,
the high order 32 bits of the IV, and the MAC address. Phase 2 is a quicker computation and includes the only item that changes every packet – the low order 16 bits of the IV [457]. The innovation is that
since the next IV value is known, the receiver can compute mixed keys in advance, in anticipation
of the arrival of packets that were encrypted with them.
The generally employed methods for ensuring message integrity create a check value known as
the message authentication code (MAC). The 802.11 standards call this the message integrity code
(MIC) to avoid confusion with the medium access control sublayer (MAC). Several secure methods
of computing a MIC have been devised for general use. However, they all require so much processing
power (from the Wi-Fi MAC chip) that, if used in a WLAN, they would drop 11 Mbps throughput to
less than 1 Mbps [457]. Since many APs do not have processing power equal to that of modern PCs,
conducting these computations at the software level is out of question for contemporary WLANs.
A means of creating MICs that would not degrade existing performance levels was needed. TKIP’s
message integrity check is implemented in a method called Michael, which solves the computation
problem with a simple set of mathematical operations. This leaves Michael open to brute force
attacks, but the solution to that problem can be found in defensive countermeasures. Essentially,
Michael forces the abandonment of current keys when an attack on them is detected. New keys are
established and the attack, as they say, is history. Michael employs a “blackout” rule that prohibits
generation of new keys for 60 sec after an attack is detected, bringing the work of the compromised
machines to a temporary halt, but also limiting an attacker to one attempt per minute [457].
In TKIP, IV length is doubled to 48 bits. The advantages of the extended-length IV are startling.
Suppose you have a device sending 10,000 packets per second. This is feasible using 64-byte packets
at 11 Mbps, for example. The 24-bit IV would roll over (begin generating already-used IV values) in
less than half an hour, while the 48-bit IV would not roll over for over 900 years [457]. In addition,
since the longer IV is used in per-packet key mixing as well, the value of the key used in RC
encryption is different for every IV value [457].
The rekeying mechanism used in TKIP generates a new encryption key every 10,000 packets
[469]. In addition, dynamic per-session and per-packet encryption keys prevent key reuse [468].
When all is said and done, WPA resolves the security problems associated with WEP, for the
present. In the future, 802.11 standards (802.11i) will incorporate a RSN protocol, designed to be
backward compatible with WPA.