In shared-key authentication, the AP sends a random number to the MT when it receives an access request from the MT (usually an 802.11 registration request). This random number is the challenge that the AP sends to the MT. On receiving this random number, the MT signs this random number using a "pre-shared " secret key and sends the response back to the AP. The AP verifies that the random number has been correctly signed by calculating the signature itself and comparing the computed and the received values. Once the AP verifies that the random key has been signed correctly, it authenticates the MT.

After AP has granted access to the MT, data packets exchanged between the AP and the MT is encrypted and signed using the wireless equivalent privacy (WEP) protocol. Specified as an option in 802.11 standards, WEP employs an RC4 algorithm based on a 40-bit "pre-shared" secret key and a 24-bit initialization vector (IV). An integrity check value (ICV) is also included in every packet to ensure data integrity.

So What's Wrong with WLAN Security
There are actually quite a few security loopholes in the 802.11 authentication methods. For example, there is no security support for handoffs. In fact, the standard does not mention how to maintain a secure session while moving across cells. The bigger problems, however, lie in the pre-shared keys, one-way authentication methodology, and use of WEP. Let's explore each of these in detail, starting with the problems with pre-shared keys.

Needless to say a network operating in the OSA mode of authentication is wide open to attacks. However, the onus of lack of security in this case belongs to the organization operating the network. In the shared-key authentication mode, 802.11 uses the challenge-response system for authenticating the end-points.

On paper, there's nothing wrong with using a shared-key authentication approach. However, 802.11's implementation is the problem. As stated above, 802.11 calls for the use of pre-shared keys. This pre-shared approach causes problems. Let's explore why.

802.11 systems do not provide a key management protocol. Therefore, real-life 802.11 system implementations require manual configuration of keys into all mobiles that wish to communicate with an AP. In practice, most installations use a single key that is shared between all mobiles. This means that even when an AP authenticates a mobile in the shared-key authentication (SKA) mode, all it ensures is that the mobile belongs to a certain group of mobiles. There is no way for the AP to determine the exact identity of the mobile that is asking for access.

To make matters worse, most 802.11 implementation share keys across APs. This increases the size of the group to which a mobile can be traced.

Theoretically, more sophisticated key management techniques can be used to make authentication better. However, since such techniques are not part of the standard, they raise interoperability issues and therefore service providers tend to avoid them.

One-way Authentication Problems
The one-way nature of the 802.11 authentication also creates headaches for designers and network operators. The 802.11 specification provides a mechanism for having the AP authenticate the mobile terminal. However, a mechanism is not in place to have the mobile authenticate the AP.

Based on this situation, a rogue node may masquerade as an AP and establish communication with the mobile. Since, the mobile can never find out that it is communicating with a rogue node, the rogue node has access to everything that mobile sends to it.

The Infamous WEP Situation
802.11's WEP has earned a bad name in the industry and rightly so. There are several reasons why WEP is a bad security solution. In fact, these reasons together create a multiplicative effect on reducing WEP's effectiveness.

WEP uses RC4 (a stream-cypher) in synchronous mode for encrypting data packets. A synchronous stream cypher encrypts data bit-wise (practically byte-wise) using a key-stream that is independent of any feedback and depends solely on the seed (key) provided to the algorithm. This means that the security of the 802.11 network is completely compromised if the key is compromised.

Additionally, the two key generators at the two communicating nodes must be kept synchronized (by some external means) to make this arrangement work. In synchronous stream cyphers (like RC4 used in 802.11), the loss of a single bit of a data stream encrypted under the cypher causes the loss of all data following the lost bit (including data in the following packets). The reason this happens is because data loss de-synchronizes the keystream generators at the two end-points.

Since data loss is widespread in the wireless medium, it is not-feasible to use a synchronous stream cypher across 802.11 frame boundaries. Thus, the WEP employs a cypher that is not suitable for the environment it operates in.

It's important to note that WEP's problem does not lie in the use of the RC4 algorithm. The problem is created by a stream cypher not suited for the lossy wireless medium.

Instead of selecting a block cypher (like AES or DES) suitable for wireless medium, 802.11 tries to solve the stream cypher synchronization problem by shifting synchronization requirement from a session to a packet. Since the synchronization between the end-points is not perfect (and subject to packet loss), 802.11 changes keys for every packet. This way each packet can be encrypted/decrypted irrespective of the previous packets loss (Figure 2).

Using a separate key for each packet solves the synchronization problem but hinders the performance of the RC4 algorithm RC4 requires systems to never reuse the same key. But, since 802.11 offers no mechanisms to share a key, most 802.11 implementations use the same key in a basic service set (BSS). The bottom line is that for all practical purposes the key being used by RC4 is a concatenation of a constant (the pre-shared key) and the IV. Therefore, the key space for the RC4 is 2^N, where N is the length of the IV. 802.11 specified the IV length as 24.

To put things in perspective, realize that if we have a 24-bit IV, a busy base station which is sending 1500-byte packets at 11 Mbps will exhaust all keys in the key space in (1500x8)/(11x10⁶x2²⁴) seconds [approximately 5 hours]. On the other hand, RC4 in SSL would use the same key space for 2²⁴ (=10⁷) sessions. Even if the application has 10,000 sessions per day, the key space would last for 3 years.

Analyses of WEP^3,4, have shown that there is a 50% chance of key-reuse after 4823 packets and there is 99% chance of collision after 12,430 packets. These are dangerous numbers for a cryptographic algorithm.

Just the Tip of the Iceberg
Believe it or not, the WEP situation gets worse. 802.11 specifies that changing the IV with each packet is optional. Combine this with the fact that the whole BSS is using a common shared key and you have a clear violation one of the most important requirements of RC4 (no key should ever be reused).

Why is it so important to avoid key reuse in RC4? Reusing the same key means that 802.11 allows different packets to use the same keystream to produce the respective cypher-text. This is dangerous.

To illustrate why this is dangerous, let k_i (i = 1,2,3, ....) be the key stream produced for a specific packet and p_i be the packet data in plain-text. Then RC4 produces cypher text c_i = p_i xor k_i. Now, because the medium is wireless, an intruder has easy access to c_i, the cypher-text. If the intruder knows the plain text part of a certain message, he can calculate the key stream used to encrypt this certain packet since k_i = p_i xor c_i.

Once k_i is known, any future packets encrypted with the same k_i can be easily decrypted since p_i = c_i xor k_i. This negates the whole purpose of using RC4.

Integrity Check
To ensure that a packet has not been modified in transit, 802.11 uses an integrity check (IC) field in the packet. This IC is implemented as a CRC-32 checksum, which is part of the WEP encrypted payload.

The problem with CRC-32 is that it is linear. This means that it is possible to compute the bit difference of two CRCs based on bit difference of the message over which they are taken. In other words, flipping bit x in the message results in a deterministic set of bits in the CRC that must be flipped to produce the correct checksum of the modified message. Because the flipping bit carries through after an RC4 decryption, an intruder can flip the desired bits in the message and then adjust the IC so that the message appears valid to the receiver.

An Important Question
When looking at WLAN authentication, one of the questions that comes to mind is "Why is IEEE sticking with RC4 even when it has been shown to be unsuitable for the wireless medium?". Well, ultimately, the IEEE is expected to use AES, a more appropriate cipher for wireless. Unfortunately, AES requires considerably more horsepower than most existing 802.11b cards provide today and therefore IEEE is sticking with RC4 for the time being.

That wraps up Part 2 in our series. Part 3 will further our discussion, providing some solutions to the WLAN security problems highlighted in Part 1. Note: To view Part 1, Click Here. To view Part 3, Click Here.

References

1. Applied Cryptography — Bruce Schneier.
2. Wireless Security — Randall Nicholas & Panos Lekkas.
3. Unsafe at any key size; An analysis of the WEP encapsulation — Jesse R. Walker (Intel)
4. (In)Security of the WEP algorithm — Nikita Borisov, Ian Goldberg, David Wagner (University of California, Berkeley).
5. Cisco's White Paper on IPSec.
6. Pesky Home Networks Trouble Cable Behemoths -- Steven M. Cherry (IEEE Spectrum, April 2002)
7. An Initial Security Analysis of the IEEE 802.11X standard — Arunesh Mishra, William A.Arbaugh (University of Maryland, College Park)
8. Making Unbreakable Code -- Justin Mullins (IEEE Spectrum, May 2002)

About the Author
Praphul Chandra is a software design engineer at Teleogy Networks, a Texas Instruments Company. Praphul obtained his Bachelors in Electronics Engineering from IT-BHU, India. Prior to joining Telogy, he worked for Lucent Technologies and Tachion Networks. Praphul can be reached ay pchandra@telogy.com.

Author's Note: This article represents the author's own thoughts and understanding of the subject matter, and in no way reflects an official or unofficial position of Telogy Networks or its parent company Texas Instruments.