A Field Guide to Wireless LANs for Administrators and Power Users

During the standardization of IEEE 802.11-1997, there was a strong desire to include a set of minimal (but adequate) security services that could challenge the potential eavesdropper in the same way that a physical wire challenges an eaves dropper (or, in that case, wiretapper). WEP was carried forward, unchanged, in the next version of the standard, IEEE 802.11-1999.

WEP was designed to be a simple, yet secure-enough technology that could be implemented in software or firmware for little or no cost. Unfortunately, the design of WEP turned out to include a number of fatal flaws. In the course of describing how WEP works, we will have the opportunity to describe what is broken.

Unfortunately, security is a notoriously digital endeavor…either you have it or you don't. It is difficult to cut corners and still maintain a desired level of security. Once a security system has been implemented, it is inevitable that many people will attempt to find its weakness (or weaknesses), especially if it is popular and/or widely used. There are quite a few network security researchers, including many candidates for Masters or Ph.D. degrees in Mathematics or Computer Science who like nothing more than an opportunity to write a paper (or a thesis) on how to exploit the weaknesses of a given security scheme.

One aspect security is that it might take an extremely talented individual quite some time to find such a weak point…but once a weakness has been found, software tools that exploit the weakness can be distributed over the Internet, and anyone (regardless of IQ) can use those tools. Just because a security system has not yet been compromised does not mean that it is truly secure in any absolute way, it just means that it is secure for the moment. WEP is a case in point, in that it was defined and deployed for over four years before tools became available to reduce its security value to zero.

Authentication within IEEE 802.11's MAC-Layer

There are two modes of user authentication defined for WEP. The first is not really a form of authentication at all. The second is a simple challenge-based exchange that relies on WEP encryption for protection. In IBSS mode, an association is never possible since there are no APs, and by definition an association must include an AP and a STA. Now would also be a good time to note that in IBSS mode, MAC-layer Authentication is optional.

Before a STA can join a WLAN, it must identify itself. The degree to which it is trusted depends on the configuration of the STA and the credentials of the user. In traditional WLANs (i.e., those based on the IEEE 802.11-1999 standard), a station must first "authenticate" itself to an AP within range of its radio, which requires one of the following two packet exchanges.

When using encryption to form a link, the two parties form a "security association," which is a formal name for the set of characteristics that define a given binding between a STA and an AP (in infrastructure mode) or between two STAs (in IBSS mode). A security association may enumerate some (or all) of the following characteristics pertinent to the connection: the authenticated key management protocol in use (if any), unicast and multicast ciphersuites, cryptographic keys, key lifetimes, and other parameters governing the operation of the cryptosystem.

The first step to defining a security association is to perform an authentication step, to make sure that each party finds the other acceptable in whatever way they care to check. There are three "states" in which a legacy IEEE 802.11-1999 STA may be in, relative to an AP. First, there is the state in which the STA is are unauthenticated and unassociated. In this state, the STA can only send management frames to establish authentication. It is also permissible to send certain control frames that are necessary to participate in the MAC protocol, such as Request to Send (RTS) and Clear to Send (CTS) frames. It is also possible to send data frames in this state provided they do not need to go beyond the AP (i.e., if they are contained within the STA's local BSS). This capability enables STAs in IBSS mode to exchange data without performing authentication (which is ultimately up to the user who is driving the STA). If the STA has successfully authenticated with at least one AP, it can move to the second state, in which it can proceed to association. The second state is characterized by the STA being authenticated, but as yet unassociated. In this state, the STA can send more kinds of frames, specifically MMPDUs that have to do with Association, Re-Association, or Disassociation. Remember that a STA may only be associated with one AP at a time. Finally, the third state is reached when the STA has associated with an AP, and thus is referred to as the "authenticated and associated" state. In this state, data frames may be sent that can cross the AP and access the Distribution System Service (DSS) provided by the wired LAN to which the AP is attached.

Figure 7-4 shows the relationship between these three states, and enumerates all the different types of frames that can be sent in each state. In each state, all the frames in the lower state or states are explicitly permissible, so in State 2, it is possible to send all frame types permissible in both State 1 and State 2; likewise, in State 3, all frame types are permissible.

Because IBSS mode does not have an AP (so there is nothing to associate with, since an association requires an AP), or its associated Portal functionality (so there is no DSS (wired LAN), which is only accessible to a STA via an AP and it associated Portal), STAs in IBSS mode can never be in the third state; in other words, they may be either "unauthenticated and unassociated," or "authenticated but unassociated."

User Authentication: "Open System"

The term "Open System authentication" is semantically equivalent to "no authentication." In Open System authentication, the WLAN is open to any potential user, who needs only go through a basic "authentication" exchange, which serves little purpose other than to identify the new STA's MAC address to the AP. In the case of IBSS mode, this form of user authentication can be used between two STAs, although MAC-layer user authentication is not mandatory in IBSS mode.

The IEEE 802.11-1999 "legacy" authentication exchange is comprised of management frames. The MMPDU's Frame Control (FC) field is depicted in Figure 7-5. The MMPDUs used to negotiate authentication are indicated by a Type of "00" (management) and a Subtype of "1101" (authentication) or "0011" (de-authentication).

Open System authentication consists of just two messages, as shown in Figure 7-6.

Each message carries different information, but has the same structure, which is shown in Figure 7-7. Not shown in the diagram is the MMPDU header (which is functionally similar to the MPDU header), nor the FCS. The diagram only shows the format of the payload MMPDU that is used in Authentication messages.^[21]

^[21] As with all IEs containing a Length field, the Length field applies to the data field of the IE. In the case of the Challenge Text Information Element, the Challenge Text field must be at least one octet in length, and may be up to 253 octets in length.

The first message flows from the Authentication-Initiating STA to the Authenticating STA.^[22] The purpose of this frame is to initiate the Open System authentication negotiation. Keep in mind that in infrastructure mode, a STA can authenticate with as many APs as it can hear. The first frame of the Open System authentication exchange contains the following information:

^[22] When the WLAN is in infrastructure mode, the Authenticating STA lies within the AP. When two STAs are in IBSS mode and they are configured to perform authentication, each STA will play the role of both the Authentication-Initiating STA and an Authenticating STA.

Authentication Algorithm Number: 0^[23] (i.e., "Open System")

^[23] The decimal number "0" is encoded in a little-endian two-octet field (i.e., 0000 0000 0000 0000).

Authentication Transaction Sequence Number: 1^[24]

^[24] The decimal number "1" is encoded in a little-endian two-octet field (i.e., 1000 0000 0000 0000).

Status Code: Reserved (i.e., set to 0^[23])

Challenge Text: Not present when Authentication Algorithm Number is zero

Station Identity: (From the MMPDU header's Source Address (SA) field)

The second (and final, in the case of Open System authentication) message flows from the Authenticating STA back to the Authentication-Initiating STA. This frame is only ever sent in response to the first authentication frame, and the contents of this frame are as follows:

Authentication Algorithm Number: 0^[23] (i.e., "Open System")

Authentication Transaction Sequence Number: 2^[25]

^[25] The decimal number "2" is encoded in a little-endian two-octet field (i.e., 0100 0000 0000 0000).

Status Code: (i.e., successful or otherwise)

Challenge Text: Not present when Authentication Algorithm Number is zero

The complete list of status codes is listed in Table 7-1. The codes that might apply during the Open System authentication exchange are numbers 0, 1, 12, 13, 15, or 16. It is possible that the Authenticating STA would refuse^[26] to authenticate an Authentication-Initiating STA if it were trying to use Open System authentication. In such a case, the Authenticating STA would respond with a Status Code of 13, the meaning of which is listed in Table 7-1, along with all the other Status Codes that have been defined in IEEE 802.11-1999. Note that some of the codes in this table pertain to association exchanges, while others are only usable in the context of authentication exchanges.

^[26] For example, in the case of infrastructure mode, in which the Authenticating STA would be inside an AP, or in the case of IBSS mode, in which the Authenticating STA is simply another STA in IBSS mode, if the Authenticating STA was configured by the Authenticating STA's administrator to enforce a stronger level of authentication than Open System authentication, then the Authenticating STA would refuse to authenticate using the Open System authentication method.

Warning: This Part Is Confusing

In the IEEE 802.11-1999 standard, when in infrastructure mode, the Authentication step is followed by a step called Association. A STA can only be associated with one AP at a time, but it may be authenticated with as many APs as it can hear. This enables a mode of operation known as "pre-authentication" in which a STA may easily roam from one AP to another, because all it needs to do is disassociate from one AP and associate with the other, since it has already authenticated itself to the AP prior to associating with it. In the next section, we discuss the Association procedure.

Now, for the confusing part: Later in this chapter, you will learn that in the IEEE 802.11i work-in-progress, the order of Association and Authentication has (apparently) been reversed. Actually, a new kind of Authentication, based on IEEE 802.1X-2001, has been introduced that happens after Association. (IEEE 802.11 MAC-layer Open System authentication is still permissible prior to Association, but it is optional under the new rules specified in IEEE 802.11i as of this writting.) Remember, these statements apply to infrastructure mode, not IBSS mode.

For infrastructure mode, the current design of IEEE 802.11i dictates that a STA may first perform an IEEE 802.11 MAC-layer Open Authentication (this is optional, but may be required on certain APs or STAs that require MAC-layer authentication to begin the process that culminates with the ability to send data frames), which is then followed by IEEE 802.11 Association,^[27] and finally IEEE 802.1X-based strong authentication.

^[27] APs that support IEEE 802.11i will allow unauthenticated STAs to associate (i.e., IEEE 802.11 MAC-layer "Open System" authentication is optional).

To summarize, we have MAC-layer authentication (which is optional), followed by association, followed by IEEE 802.1X-based authentication. The last authentication step is where the real work of user authentication happens, and it happens after association. The reason why the current design forces the "real" authentication to happen after association is that IEEE 802.1X authentication frames are data frames, and a STA can only send data frames after it has associated with an AP.

User Authentication: "Shared Key"

The overall procedure employed in Shared Key authentication follows the template established by Open System authentication. Note that "Shared Key authentication" is a proper name and refers to an authentication method that is specific to IEEE 802.11-1997 and succeeding versions. The term "Shared Key authentication" refers to the fact that all the STAs share knowledge of the same (set of) key(s), which they use to prove that they should be allowed to join the WLAN.

In the broader context of cryptography, there is a concept of "pre-shared keys." There is no relationship between "pre-shared keys" and "Shared Key authentication." At some point in the future, it is possible that Shared Key authentication will be removed from the IEEE 802.11 standard, but that is not even a consideration at this point in time. The frame exchange used to implement Shared Key authentication is illustrated in Figure 7-8.

The format of the messages in the Shared Key authentication negotiation is identical to those in the Open System authentication exchange, which is illustrated in Figure 7-9. The main difference is that Open System authentication does not make use of the Challenge Text Information Element, while Shared Key authentication does.

Even though the Challenge Text Information Element is capable of containing up to 253 octets of challenge text, only 128 octets are required in order to negotiate Shared Key authentication. Figure 7-9 shows the maximum capacity of the information element, rather than illustrating a special case that would only be applicable to Shared Key authentication.

As in Open System authentication, the first message of the Shared Key authentication exchange flows from the Authentication-Initiating STA to the Authenticating STA. All of the MMPDUs that are used in the Shared Key authentication negotiation have their two-bit message Type set to 00 (Management) and the four-bit message Subtype set to 0xB (Authentication).

The first message of the Shared Key authentication negotiation contains the following information:

Authentication Algorithm Number: 1^[28] (i.e., "Shared Key")

^[28] The decimal number "1" is encoded in a little-endian two-octet field (i.e., 1000 0000 0000 0000).

Authentication Transaction Sequence Number: 1^[28]

Status Code: Reserved (i.e., set to 0x0000)

Challenge Text: Not present in this message

Station Identity: (From the MMPDU header's Source Address (SA) field)

The second message of the Shared Key authentication negotiation flows from the Authenticating STA back to the Authentication-Initiating STA. If the status code is not "successful," then this Authenticating STA is either configured to not accept Shared Key authentication, or it may have insufficient resources to handle this Shared Key authentication negotiation at this time. In this case, the second message would be the final message of the aborted Shared Key authentication exchange.

This frame is only ever sent in response to the first authentication frame, and the contents of this frame are as follows:

Authentication Algorithm Number: 1^[28] (i.e., "Shared Key")

Authentication Transaction Sequence Number: 2^[29]

^[29] The decimal number "2" is encoded in a little-endian two-octet field (i.e., 0100 0000 0000 0000).

Status Code: (i.e., successful or otherwise)

Challenge Text: 128 octets of challenge text (generated by WEP's pseudo-random number generator seeded with any initialization vector (IV) and key)

The third message of the Shared Key authentication negotiation is only sent if the second message indicates "successful" in the Status Code. The message flows from the Authenticating STA back to the Authentication-Initiating STA. The third frame is encrypted using one of the statically defined WEP^[30] keys, and contains the following information:

^[30] The mechanics of WEP will be discussed shortly. Unfortunately, there is a bit of a catch-22, in that a STA can't join a BSS unless it can do WEP, since the Shared Key authentication exchange depends on encrypting the third message. Rather than discuss WEP encapsulation and encryption in between Open System and Shared Key authentication, the author chose to finish describing authentication first.

Authentication Algorithm Number: 1^[31] (i.e., "Shared Key")

^[31] The decimal number "1" is encoded in a little-endian two-octet field (i.e., 1000 0000 0000 0000).

Authentication Transaction Sequence Number: 3^[32]

^[32] The decimal number "3" is encoded in a little-endian two-octet field (i.e., 1100 0000 0000 0000).

Status Code: (i.e., successful)

Challenge Text: 128 octets of challenge text (generated by WEP's pseudo-random number generator seeded with any initialization vector (IV) and key)

The receiver of the third frame (the Authenticating STA) can tell from the WEP header which key was used to encrypt the frame, and if the frame is successfully decrypted, it will attempt to match the challenge text with the text that it sent out in the second frame. WEP uses the CRC-32 algorithm to generate an ICV. The CRC-32 algorithm is more commonly found in Frame Check Sequences, and it is well-known to be fairly weak, in that errored frames have a reasonable chance of having the same CRC as the original frame. The ICV is calculated over the data frame and appended to the data frame before the data frame and the CRC-32 ICV, are encrypted. If, once the frame is decrypted, the ICV in the frame is found to match a CRC-32 separately calculated over the data then the frame is taken to have arrived intact.

Note that anyone with knowledge of this BSS' WEP keys could forge the second frame in this exchange. The fact that the third message is encrypted is only proving that the Authentication-Initiating STA knows the WEP keys, which is a fairly low barrier to entry. An imposter could easily interfere with the Authenticating STA's transmissions, and impersonate it (e.g., by spoofing its MAC address), once the challenge text has been chosen.

The final (fourth) frame of the Shared Key authentication exchange is a confirmation that the Authenticating STA received the third frame, and that the Authentication-Initiating STA is now authorized to use the BSS. Note that the BSS may be in either infrastructure or IBSS mode, although authentication is optional in IBSS mode.

Authentication Algorithm Number: 1^[33] (i.e., "Shared Key")

^[33] The decimal number "1" is encoded in a little-endian two-octet field (i.e., 1000 0000 0000 0000).

Authentication Transaction Sequence Number: 4^[34]

^[34] . The decimal number "4" is encoded in a little-endian two-octet field (i.e., 0010 0000 0000 0000).

Status Code: (i.e., successful or unsuccessful, depending on the ICV check)

Challenge Text: 128 octets of challenge text (generated by WEP's pseudo-random number generator seeded with any initialization vector (IV) and key)

Association

Regardless of the order of authentication and association, the association procedure is quite simple. Remember that there is no AP in IBSS mode, so there are no associations. Associations are, by definition, only between a STA and an AP, and an AP will only accept data from a STA if they are associated with each other. STAs can only send and receive frames to the wired world on the far side of the AP if they have completed association.

There are actually three different types of association messages: "Association," "Re-Association," and "Disassociation." The first type is used to establish an association, and the latter is used to terminate an association. The Re-Association message is used to either change the parameters of an existing association with an AP, or to move a STA to a different AP.

The process of association, which occurs after IEEE 802.11-1999 MAC-layer authentication, consists of just two messages, as shown in Figure 7-10. The Association Request message flows from the Association-Initiating STA to the AP,^[35] and the Association Response message is sent in the opposite direction.

^[35] Association can only occur when the WLAN is in infrastructure mode, since an AP must be involved in an association. In IBSS mode, associations are not performed.

Figure 7-11 shows the encoding of the MMPDU Frame Control field for each of these message types, both of which have a message type indicating that they are "management" frames (i.e., "00"). The message subtype for the "Association Request" MMPDU is "0000", and the message subtype for the "Association Response" MMPDU is "1000".^[36]

^[36] Note that the message subtype fields were written with the least-significant bit on the left.

Each association message carries different information, and therefore has different payload structure. The Association Request MMPDU conveys the following information:

Association-Initiating STA's Identity: (from the MMPDU header's SA field)

AP's Identity: (from the MMPDU header's DA field)

(E)SS ID: (Ensures that the STA is joining the correct WLAN). The SSID is an ASCII string that serves as a sort of "VLAN name." A STA wanting to join a WLAN must know its name, which is accomplished either by having the user enter the name statically, or by having the OS dynamically detect the name of the WLAN, after which the user can be prompted to see if he or she would like to join that WLAN.

Various control information such as ESS versus IBSS mode, whether Privacy is enabled in this WLAN, whether the Association-Initiating STA supports Contention-Free operation, and the rates at which the Association-Initiating STA can operate. The AP will use this information to determine whether it should accept the association. The Association-Initiating STA also can inform the AP how long its "Listen Interval" will be. The Listen Interval is the amount of time that the STA will spend in power-saving mode, and is expressed in units of Beacon intervals, so the STA can "sleep" for anywhere from 1 to 65,535 Beacon intervals.

The format of the Association Request MMPDU is shown in Figure 7-12.

The Association Response message flows from the AP back to the Association-Initiating STA if the proposed association is accepted. This MMPDU is only ever sent in response to the Association Request MMPDU. The Association Response MMPDU conveys the following information:

• Association Identifier. The Association ID is a 14-bit number between 1 and 2007, inclusive. The two most-significant bits of the 16-bit Association ID field are set to 1. This is a number assigned by the AP, which is used as a shorthand way to refer to this association. The only other frame type that has an Association ID field is the Power-Save Poll control frame, which the AP uses to indicate to a STA that traffic is queued for it in the AP. As with other fields in the various IEEE 802.11 frame headers, the least-significant bit of the Association Identifier is written on the left. The values in Figure 7-13 reflect the proper bit ordering. Note that the most-significant two bits of the AID field are both set to "1" in accordance with the specification.

  Figure 7-13. Contents of Association Response MMPDU

• The AP will return a list of its own supported rates, so that the Association-Initiating STA can limit itself to the intersection of its own set of supported rates against the set of supported rates which the AP supports.

• Status Code. The Status code will be chosen from the values in Table 7-1 that are applicable to association events. Given that we have assumed that the association was successful, the Status Code field will contain the value zero.

The format of the Association Response MMPDU is shown in Figure 7-13.

Once completed, the associated STA will be able to send frames to any other MAC address within its own BSS, or accessible via the DSS (i.e., the wired LAN that interconnects the APs of the ESS).

Encryption

In the beginning, there was WEP. Despite the "P" in its name, "Privacy" is not what WEP was attempting to provide…it was trying to provide a minimal level of "confidentiality." There is a reference that defines various security terms very precisely, and I do my best to follow it. RFC-2828 is an informational RFC entitled "Internet Security Glossary." The concept of privacy has to do with controlling information; for example, about yourself (i.e., keeping information about what books you read, or what stores you shop at, etc., from being disseminated too widely), whereas the concept of "confidentiality" has to do with preventing your communications from being understood by others.

WEP was completely inadequate for its intended purpose…protecting traffic as it flowed across the air so it would be just as secure as traffic that is traversing a wire. WEP was designed to be strong enough to prevent casual eavesdropping. The mechanisms it used to provide "security," however, were not well thought out, and in retrospect it turned out that WEP was quite easy to break. In fact, given the proper tools in the hands of miscreants, WEP-protected networks were no more secure than networks that operated in the clear. In fact, WEP might have been slightly dangerous, in that it may have conveyed a false sense of security to users that enabled it.

This chapter concerns itself with all forms of WLAN security, including WEP, although it must be re-stated that WEP is not secure and should not be used if better alternatives are available. The IEEE 802.11 WG is in the process of defining new procedures that are collectively known as "Robust Security Network" protocols, which are able to provide much more secure operation for WLANs. In fact, in some ways, WLANs using RSN procedures may be more secure than their wired counterparts.

WEP employs RSA Security Inc.'s RC4 stream-oriented cipher algorithm. Curiously, RC4 used to be a trade secret of RSA, but the algorithm was leaked and a publicly available implementation now exists that can be used without license. It is known as "Alleged RC4" or "ARC4" (which can still be pronounced the same as RC4, if you stretch the rules of English pronunciation a bit, pronouncing the "AR" as if it were just an "R"). RSA^[37] has even admitted that it is, in fact, the actual RC4 algorithm, so anyone can effectively use ARC4 for free, even though RSA Security, Inc. still claims it as their intellectual property (RC4 is at least a registred trade mark).

^[37] RSA is an acronym representing the names of the three people who co-invented a popular form of public-key cryptography: Ronald L. Rivest, Adi Shamir, and Leonard M. Adleman. RSA is also a company that was founded in 1982 by the three co-inventors in order to commercialize their invention. Today, RSA is a premier data security company, selling everything from cryptographic toolkits for software developers to consulting services. RSA Security Inc. is the most recent name for the company.

Stream-oriented ciphers take a seed value (in the case of RC4, this seed is comprised of a 24-bit number that is included with the frame, known as an IV) plus a key (can be variable size; in the case of WEP's use of RC4 it is either 40 or 104 bits long^[38] ) and generate a pseudo-random string of bits (via RC4's Pseudo-Random Number Generator, or PRNG) that is known as a "keystream." This keystream is exclusive-OR'ed against the data to be encrypted, effectively scrambling it.

^[38] The author is aware of products that have claimed to have WEP implementations based on RC4 with 152-bit seeds. Presumably, this consisted of the usual 24-bit IV, plus a 128-bit key. It is also possible that the spec sheet on which the author saw this claim was in error.

In WEP, the seed is either 64 or 128 bits long, corresponding to a 24-bit IV concatenated with either a 40-bit or 104-bit key. RC4 keys can be as small as eight bits (one octet), and as large as 2048 bits (256 octets), and can have a length that is any intermediate multiple of 8 bits. RC4 keys are not limited to multiples of, for example, 32 or 64 bits, as you might conclude from looking at the key sizes used with WEP.

The bitwise exclusive-OR operator is also known as the "not equal to" function, since the result of an exclusive-OR operation is only true when the inputs are unequal. If either input matches (either both are zero, or both are one), the output of the bitwise exclusive-OR operator is zero. In summary: the result of the logical exclusive-OR operation is 1 only if the two inputs do not match. The truth table diagram for the exclusive-OR operator is shown in Figure 7-14, with the logical "OR" operator provided for the sake of comparison.

Due to an interesting property of the exclusive-OR function, it is just as easy to decrypt a frame as it is to encrypt it. The following simple equation says that if you take some plaintext (P) and XOR it with a keystream (K), and then you XOR the resulting ciphertext (C) with the same keystream, the result is the same plaintext that you started with. If we take "" to be the exclusive-OR operator, then we have the following equations that represent the encryption and decryption procedure:

C = P K (encryption)

P = C K (decryption)

By combining the two equations algebraically, we have the following identity:

P = C K

P = (P K) K

Because the exclusive-OR function obeys the associative rule, we see that

P = P (K K)

P = P

Therefore, if a peer can re-create the keystream, it can decrypt a frame. In order to perform the decryption, the receiving peer needs to know the proper IV, plus the key. The RC4 PRNG will do the rest. In WEP, the IV is sent as part of the frame, but the key is kept secret (well, it's supposed to be…). The receiver can use its knowledge of the secret key plus the IV (which is included as plaintext in the frame) to generate its own keystream with which to decrypt the frame, which is accepted provided the ICV is verified to be correct.

In WEP, the ICV is the CRC-32 function (the same function that is used in the Ethernet and IEEE 802.11 Frame Check Sequence). In a moment, when the frame encapsulation and decapsulation rules are shown, it will be clear that even though the ICV is a CRC-32, there is still an FCS at the MAC layer.

WEP is more than just a way to use an encryption algorithm. As was noted earlier, an ICV is required to enable the receiver to verify that what was received was the same thing that was sent by the sender. One thing to keep in mind about WEP is that it was designed to be able to be implemented in software or firmware. RC4 is a fast algorithm, and it is not CPU-intensive compared with other encryption algorithms, making it ideal for implementation in APs and PC Cards.

As noted earlier, the frame header must remain exposed to the intermediate devices (e.g., the AP), so that it can be properly forwarded. Consequently, there is a need to "encapsulate" the original data frame (MSDU), which consists of 1) computing the ICV, 2) appending the ICV to the MSDU, 3) encrypting the MSDU and ICV (using the IV and a secret key), and 4) pre-pending the IV to the encrypted data. WEP encapsulation transforms the frame as shown in Figure 7-15. The gray box in Figure 7-15 that surrounds the MSDU at the top of the figure is meant to symbolize that the ICV is calculated over that entire MSDU. Visually, and actually, the ICV covers the MSDU.

When a STA or AP is configured to use WEP, there is typically a user interface that permits the entry of up to four RC4 keys. The values are either 40 bits (i.e., 5 octets), or 104 bits (i.e., 13 octets) in length. When an MSDU is encapsulated with WEP, the sending STA may choose any of the four keys that are at its disposal. It is a pre-requisite that all STAs and APs that want to communicate must have their WEP keys statically pre-defined before they can use WEP to protect frames that they exchange between each other.

To use WEP, at least one key must be defined in the AP or STA. Because the KeyID field in the IV header provides for up to four WEP keys, many implementations allow the entry of up to four 40-bit keys. To provide an example, Figure 7-16 shows the user interface for the author's WLAN PC Card. Remember in Chapter 3, we saw that the Red Hat Linux 9.0 "neat" user interface for WLAN configuration allowed the WEP key to be entered in the top-level configuration dialog box.

Note that as an alternative to typing in 20 hex octets (five for each of the four keys), the user interface supports entering a "pass phrase" from which the keys are derived. The mapping between pass phrases and keys is not defined in the standard, so if a user wanted to configure a STA or AP that way, that user might have to use equipment from one vendor. Also note that, in the case of WEP-104, the user interface of my product only supports entering a single key (although in principle, it should also be possible to enter four keys, since the KeyID field only enumerates the key number, it does not care how large the key(s) is(are)).

The STA that receives a WEP-encrypted frame can tell it is encrypted since the WEP bit in the MPDU's Frame Control field is set. The first four octets of the MSDU are then known to be the WEP IV, and the final two bits of that four-bit field constitute the WEP Key ID. By selecting one of the four possible values of the Key ID field, the receiving STA knows the key to use to combine with the IV to determine the seed from which the pseudo-random keystream may be calculated. A complete MPDU, showing the full MPDU header and the WEP pieces that surround the original MSDU, is shown in Figure 7-17.

Once the decryption step is complete, the receiving STA has recovered the original frame, plus the ICV that was supplied by the sending STA. The receiving STA calculates its own ICV, from scratch, over the received MSDU, and compares this to the ICV that was inside the WEP-protected MPDU. If the two ICVs match, the frame is accepted.

What Can Go Wrong? (Or: What's So Bad about WEP?)

There are a number of flaws in WEP; some are obvious, and others less so. As to the obvious flaws, we see that the initial authentication is very weak. Shared Key authentication is virtually no better than Open System authentication, since knowledge of the WEP keys can be very easy to come by. The very idea that it makes sense to operate a large network based on WEP is foolish, since the entire user population needs to have the same static key configuration. Consequently, the keys are not exactly a secret. When an employee leaves a company, or loses his or her laptop, all of the remaining machines' keys should all be changed to protect the integrity of the corporation's network; however, in reality that is really quite unlikely to happen. The administrative overhead necessary to change what might be hundreds (or even thousands) of system configurations in a relatively short period of time makes changing the keys a prohibitively expensive operation. Anyone who knows the key can access the network, since no strong authentication is used.

On the topic of message authentication, even though WEP includes an ICV, it is not a keyed hash function, so its value is essentially zero. As we now know, the ICV is just a simple CRC-32 checksum, which WEP "protects" by appending it to the original MSDU and encrypting the whole thing. However, since the CRC-32 function is mathematically linear, flipping any bit in the ciphertext message results in a deterministic set of bits in the ICV that must be flipped to repair the ICV in the modified (and still encrypted) message. The location of the ICV in the encrypted frame can be found by working backward from the end of the MPDU…the ICV is the four octets that immediately precede the MPDU's FCS.

The bits that must be flipped are knowable even without knowing the key (i.e., an attacker does not need to have access to the plaintext to re-compute the encrypted ICV!). The modified MPDU's ICV can be repaired because any bits that the attacker flips in the encrypted ICV field are flipped in the plaintext that the receiver will recover after it decrypts the frame (by the properties of the exclusive-OR operator). Therefore, the attacker can flip arbitrary bits in an encrypted message and correctly adjust the checksum of the encrypted frame such that the resulting message appears valid, and can do this without first needing to decrypt the message.

This type of attack is known as a "bit flipping" attack, and it is not inherent in stream ciphers. If WEP employed a nonlinear ICV, bit-flipping attacks would be far more difficult, especially if the ICV depended on a secret key (separate from the encryption key) that was only known to the two communicating entities.

The biggest problem with WEP is that it specifies a ridiculously small IV, and the IEEE 802.11-1999 standard only recommends that it be changed periodically. The original standard makes the following statements about the IV (see Clause 8.2.3, page 63).^[39] The second paragraph of this excerpt is a virtual recipe for many of the attacks that were subsequently successfully mounted against WEP.

^[39] Excerpted from IEEE Std. 802.11^™-1999, copyright 1999. All rights reserved.

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.

When choosing how often to change IV values, implementors [sic] should consider that 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. Changing the IV after each MPDU is a simple method of preserving the effectiveness of WEP in this situation.

Despite the recommendation that the IV be changed (as frequently as on a per-MPDU basis!), the frequency at which that should happen was never actually specified, nor did the standard make it mandatory for an implementation to support changing the IV at all. It turns out that even if you do change the IV once per packet, an attacker won't have to wait long before one is re-used, and if a keystream is used twice, the attacker can begin to deduce quite a bit about the keys, eventually recovering the "secret" keys.

The ways the IV and keys are used in this particular application of RC4 make WEP extremely vulnerable to chosen plaintext attacks. The topic of cryptanalysis is beyond the scope of this book, but suffice it to say that it is easier to break a code if you can see some examples of ciphertext, especially if you know the plaintext that was used to create that ciphertext. It is easier to do this than you might think: If a cracker parks near a company, he or she can send packets to that subnet and see what they look like when encrypted. A cracker can do this by using a dial-up connection to an ISP over a cell phone to send a packet to one of the local machines (if it can determine the ISP subnet address of the WLAN). The AP will happily encrypt the frame before sending it to the destination STA, so the attacker will know the plaintext, the ciphertext, and the IV (from the encrypted frame itself).

As we know, WEP's IV is only 24 bits long, and it is sent in the clear, immediately following the MPDU header, and just before the encrypted MSDU+ICV. Given that the only thing that makes the keystream unique is the IV, and given that it is likely that the IV may not change for many frames, and given that the total space of initialization vectors is so small, virtually guarantees that a given keystream will be reused. How bad is this? It's much worse than one might think. If an AP had only one STA associated with it, which was receiving a steady stream of 1500-octet frames at 11 Mbps, all possible IVs would be used after only about five hours.

How do we arrive at this surprising result? There are 1500*8 (i.e., 12,000), bits in a 1500-octet frame. This corresponds to a frames-per-second (fps) rate of about (11,000,000 bps / 12,000 b), or a little more than 910 fps. To be precise, the theoretical best-case throughput of an IEEE 802.11b WLAN operating at a bit rate of 11 Mbps is just under 6.25 Mbps. This is the theoretical maximum bit rate, allowing for all types of overhead and all mandatory quiet intervals between frames. So, in reality, 910 fps at that frame size is absolutely unachievable.

The maximum frame rate for 1500-octet frames is more like (6,245,8560 bps / 12,000 b), or 520 fps. If the 2²⁴ (16,777,216) IVs in the 24-bit IV space were used at the worst-case rate of one IV per frame (presuming for the moment that they were changed that rapidly), a cracker would be guaranteed to see an IV re-used in at most (16,777,216 / 520) seconds, or about 32,200 seconds. This is about 540 minutes, which is about nine hours. If the AP were not sending large-sized frames, then it could be sending more frames per second, which would further reduce the amount of time it would take to cycle through the 16 million or so IVs. Moreover, given that all the STAs and the AP share the same WEP keys, either 40- or 104-bits long, any frames sent to or received from other STAs will help eliminate the IVs that the cracker hasn't seen that much more quickly. In practice, it's unlikely that an attacker will have to wait more than a few hours to observe a keystream being reused.

If an attacker can collect two frames that were encrypted with the same keystream, he or she can perform statistical analysis to recover the plaintext. If the cracker originated some of the frames that are subsequently "recovered," then the attacker knows the plaintext plus the IV, and has at least two different frames that were encrypted using the same keystream.

The five-hour figure is the worst-case length of time that an attacker would have to wait in order to have enough information to begin such an analysis. If the IV isn't changed that frequently, or at all, the attacker won't have to wait very long to find two frames that were encrypted with the same keystream. In such a scenario, attackers may not have to do very much at all before they know all the keys, especially if they send the frames and know what the plaintext looks like. Therefore, it's clear that making the WEP key longer (from 40 to 104 bits) did nothing to improve the security of WEP, since the weakness is in the small IV space and the fact that the keys, regardless of their length, are static.

Besides the ability to literally choose the plaintext in such an attack by sending packets that will cross the wired LAN for the attacker's examination, the structure of the MSDUs for many packet types is well known. Simply knowing the structure of the packets, and knowing that certain values always appear at certain offsets in the plaintext, may be sufficient to give just enough information that, if enough frames are harvested, enables a cracker to determine one or more of the keys. Remember that the keys are the only thing that stands between a legitimate user and a cracker in legacy IEEE 802.11-1999 WEP-based security. Software exists to allow a cracker to determine keys, hijack existing associations, impersonate APs or STAs, and so forth. The only thing the cracker needs is time. He or she doesn't even need to be present to carry out an attack…the cracker can drop a laptop in a concealed location, such as under a shrub on the outside of a building, which can then harvest the necessary information for a few days, so that by the time the cracker returns, the laptop will have derived enough information to enable the cracker to join the LAN as an (apparently) valid user. The only enemy of the cracker in such a scenario is the weather.

As a side note, WEP does support per-association keys, via a "key mapping key" table. The table can associate a WEP key with every (RA, TA) pair. The IEEE 802.11-1999 standard requires that implementations shall support^[40] a minimum of 10 key mapping keys, but provides no way to install the keys, other than manually. The MIB in which the key mapping key table is stored is mandatory-to-implement, according to the normative text of the standard, as well as the Protocol Implementation Conformance Statement (PICS). However, the initial test suite that was used to grant Wi-Fi logos did not require that key mapping keys be supported, so it is unclear how many implementations actually support this feature. (To be precise, the earliest Wi-Fi logo testing did not require that an AP or STA support more than one WEP key.) The lack of secure dynamic key distribution dooms any static scheme, due to the other weaknesses in the WEP encryption design.

^[40] The author has never seen a Wi-Fi product that supports key-mapping keys via the user interface, although the author would also like to state for the record that he has not seen everything. To qualify this statement, it's possible that a given implementation supports the MIB table that stores the key-mapping keys, but provides no user interface from which to configure them. However, given that the Wi-Fi Alliance does not make this feature part of their certification test suite, it would be easy for an implementer to justify not supporting this "mandatory" feature.

If WEP had been designed with a better ICV, and a secure authentication and key management protocol, then it's possible that certain attacks might have been impractical, but the IV space was still too small, and the BSS would have to re-key at a fairly high rate to keep from reusing a keystream.

The Post-WEP Era: WLAN Security Evolves

The first "patch" to WEP was to allow longer keys. As we have seen, WEP's key length is not its weakness, and products that support longer (104-bit) keys have no security advantage over those that are limited to 40-bit keys. The only advantage of longer keys is in product marketing, since consumer perception is that bigger is usually better. That's the implicit (and incorrect) assertion that vendors of big-key WEP were making.

There were several inadequate attempts at an improved WEP, including WEP+, but the most effective initial "patch" to WEP was the Temporal Key Integrity Protocol (TKIP), that allowed per-association keys and provided for secure, dynamic key management based on IEEE 802.1X-2001. TKIP has evolved somewhat, but it is still based on the RC4 algorithm, which is not bad, since the algorithm was never the problem (although the stream-oriented cipher did enable certain kinds of attacks e.g., bit flipping that would not have been possible with a block-oriented cipher. The original TKIP still had a too-small IV space, and still used 40- or 104-bit keys. An upgraded version of TKIP (with fixes for those problems, plus a stronger ICV) is part of the IEEE 802.11i draft standard, and is the basis for the Wi-Fi Alliance's Wi-Fi Protected Access (WPA) specification.

The third "patch" to WEP is effectively a complete alternative to WEP. The IEEE 802.11i TG is defining new encryption schemes for WLANs, based on the Advanced Encryption Standard (AES). The AES-based based protocol is called Counter-mode with Cipher-block-chaining Message authentication code (i.e., Counter-mode with CBC-MAC) Protocol (CCMP), and it leverages the same secure dynamic key distribution protocol that is based on a four-way handshake using IEEE 802.1X-inspired frames, while offering a much stronger encryption algorithm. The combination of TKIP and CCMP, with IEEE 802.1X, is known as Robust Security Network, or RSN.