802.11 Security

Photo of author

By Miro Stoichev

“Today business customers’ single objection to deploying wireless technology is the fact that it’s not secure,” — Bill Rossi, vice president and general manager of Cisco’s wireless networking operation.

“We came across a company with one of these wireless networks. All their source code, everything was available. This network was beaconing, ‘log onto me’…It basically had its Rolls- Royce parked in the driveway, engine running, with a sign saying ‘steal me.’ — Thubten Comberford of White Hat Technologies, a wireless security firm.

Bottom-line : Wireless LANs are broadcasting secrets of enterprises that have spent millions on Internet security. Wireless security has become a serious business requirement today. So much so that some companies have blocked wireless deployment till the networking industry makes the wireless networks as secure as wire-line networks.

Why is wireless security such a big issue?

After all wire-line networks never had to cross the security hurdle to see wide-scale deployment. The answer is inherent in the question. The wireless medium by its very nature can’t be contained. Wire-line networks could be physically contained into the network they formed by ensuring that rogue nodes did not have access to the medium (wires). Companies were willing to deploy wire-line networks by ensuring this. This is not to say that the wire-line networks did not have to cross the security hurdle. Once the internet grew and there was a need to send out data over insecure networks, security in wire-line networks became an absolute must too. However, for wireless networks this requirement has to be met at a much earlier stage because of the insecure nature of the medium.

The wireless medium is so open to attacks that today’s wireless networks can be accessed by using a laptop and an empty can of pringles chips (or a coffee can). This is not so surprising once you think about it. The pringles can acts as an antenna (amazingly it provides a gain of up to 15 dB) providing a “tap” (a wireless network scanner/sniffer) into the medium. Once the laptop gets access to the packets flowing through the network, it is an open world from there on. Since it is so much more easier to access the wireless networks, it has given rise to the practice of “war- driving” which involves driving around in a car with a laptop and some sort of antenna looking for open networks. Surprisingly, this practice is more widespread than it may seem – specially in Europe where the wireless market is more widespread than the North American market.

802.11 Security modes

For authentication 802.11 specifies two modes : OSA (Opens Systems Authentication) and Shared Key Authentication. The former basically means null authentication. In this mode, any MT requesting access to a network is granted the access by the AP without performing any security checks on the identity of the MT. In the latter, the AP uses a “pre-shared” key based challenge-response system similar to HIPERLAN to authenticate the MT. The figure below details the process.

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 signed by the correct key by calculating the signature itself and comparing the computed and the received values. Once the AP verifies this, it authenticates the MT.

Once the AP has granted access to the MT, data packets exchanged between the AP and the MT is encrypted and signed using WEP (Wired Equivalent Privacy). WEP is specified as an option in 802.11 standards, to provide confidentiality and integrity for wireless traffic. It uses RC4 algorithm based on a 40-bit “pre-shared” secret key and a 24-bit IV (Initialization Vector). An ICV(Integrity Check Value) is included in every packet to ensure data integrity.

What’s wrong with 802.11 Security?

The first thing that contrasts 802.11 security with HIPERLAN security is the fact that unlike HIPERLAN, 802.11 binds itself to a single cryptographic algorithm (RC4). The second glaring difference is that 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 following sub-sections aim to expose other important loopholes in 802.11 security.

Before proceeding, keep in mind that the security of a communication network is ensured by the use of secret keys which act as seeds into cryptographic algorithms. Put another way, a network is as secure as the keys it uses, assuming that the cryptographic algorithms are publicly known.

1) 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. There is nothing wrong with this scheme.

The loophole lies in the use of “pre-shared” keys. What does pre-shared mean? How are nodes supposed to pre-share keys with an AP? 802.11 says nothing about how the AP and a node end up pre-sharing a key? Compare this to HIPERLAN (or even the much weaker Bluetooth) where the protocol defines exactly how sharing of keys can be achieved over an insecure medium and you begin to realize why the 802.11 security diagram is much smaller than the other diagrams. HIPERLAN uses Public Key Cryptography to obtain a link-key over an insecure medium. It then uses this link-key to exchange session keys which are used in Symmetric Key Cryptography for applications. In short, 802.11 leaves out the difficult part of key management over an insecure medium.

In the absence of any key management protocol, real life implementations of 802.11 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 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 Access Points. 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.

2) One way authentication

There is another issue with 802.11 authentication. It is one-way i.e. it provides a mechanism for the AP to authenticate the mobile but has no provision for the mobile to be able to authenticate the network. This means that 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.

3) The Infamous WEP

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. From section 1.3.2, note that a synchronous stream cypher encrypts data bit-wise (practically byte-wise) using a key-stream which 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. Also, 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). This is so because data loss de-synchronizes the keystream generators at the two end-points. Since data loss is widespread in the wireless medium, it is infeasible to use a synchronous stream cypher across 802.11 frame boundaries. This is the basic problem of WEP. It uses a cypher not suitable for the environment it operates in. Note here that the problem is not the RC4 algorithm. The problem is that a stream cypher is not suitable for wireless medium where packet loss is widespread. SSL(Secure Socket Layer) uses RC4 at the application layer successfully because SSL (and therefore RC4) operates over a reliable data channel that does not lose any data packets and can therefore guarantee perfect synchronization between the two end points.

Instead of selecting a block cypher (like AES or DES) suitable for wireless medium, 802.11 tries to solve the synchronization problem of stream cyphers by shifting synchronization requirement from a session to a packet. Going back to SSLs use of RC4, SSL uses one key for a complete session. The key does not need to be replaced on every packet since the end points are synchronized and RC4 can produce the same keystream at both ends using the session key. In the wireless medium 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. Here is how RC4 works in 802.11:-

How WEP works?

RC4(SharedKey + IV) = KeyStream for a packet. ——- (1)
LengthOf(KeyStream) = LengthOf(DataPacket+CRC) ——- (2)

Step-1 shows that the RC4 cypher uses the combination of the shared key and the IV to produce a key stream for each packet. Step-2 shows that the length of the key stream is equal to the length of the packet since the data bits in the packet have to be XORed with the key stream to generate the cypher text.

Using a separate key for each packet solves the synchronization problem but realize that one of the most important requirements of RC4 is that the same key should not be reused EVER. This requirement, combined with the fact 802.11 would need a new key for every single packet to make the network really secure, means that 802.11 needs a very large key space. Recall now that the shared key referred to in step-1 above is the “pre-shared” key discussed before. Since 802.11 specifies no way to share a key, most 802.11 implementations use the same key in a BSS (some implementations use the same key across BSSs to make matters worse). 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 2N 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 (=> 224 keys in the key- space), a busy base station which is sending 1500 byte-packets @ 11Mbps will exhaust all keys in the key space in (1500*8)/(11*106*224) seconds or appx. 5 hours. On the other hand RC4 in SSL would use the same key space for 224 (=107) sessions. Even if the application has 10,000 sessions per day, the key space would last for 3 years. In other words, an 802.11 BS using RC4 has to reuse the same key in appx. 5 hours whereas an application using SSL RC4 can avoid key reuse for appx. 3 years. This shows clearly that the fault lies not in the cypher but in the way it is being used. Going beyond an example, analyses of WEP [3],[4] has 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.

Believe it or not, it 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 be reused EVER).

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. Let ki (i = 1,2,3, ….) be the key stream produced for a specific packet and pi be the packet data in plain-text. Then RC4 produces cypher text ci = pi xor ki. Now, because the medium is wireless, an intruder has easy access to ci, 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 ki = pi xor ci. Once ki is known, any future packets encrypted with the same ki can be easily decrypted since pi = ci xor ki. This is the reason why RC4 warns against key re-use, which unfortunately 802.11 ignores. Note that since the variable part of the RC4 key (the IV) is attached to each packet in plain-text, it is trivial to find out that two packets have been encrypted with the same key.

4) Integrity Check

To ensure that a packet has not been modified in transit, 802.11 uses an IC (Integrity Check) 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.

To summarize, here is the list of things (in decreasing order importance) that is wrong with 802.11 security:-

* WEP uses a synchronous stream cypher over a medium, where it is difficult to ensure synchronization during a complete session. * 802.11 does not provide any mechanism for sharing keys over an insecure medium leading to key-sharing in a BSS and sometimes across BSSs. * 802.11 specifies that changing the IV with each packet is optional. * The IV used in 802.11 is just 24 bits long giving a very limited key-space specially since each packet needs to have a separate key for the network to be really secure. * No support for a MT to authenticate the network. * CRC-32 used for message integrity is linear. * WEP concatenates the IV directly to the pre-shared key to produce a key for RC4, thus exposing the base-key to direct attack.

Note that the limited size of the IV figures much lower in the list than one would expect. This emphasizes the fact that simply increasing the IV size would not improve WEP’s security considerably. The deficiency of the WEP encapsulation design arises from attempts to adapt RC4 to an environment for which it is poorly suited.

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 the Advanced Encryption Standard (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.

Leave a Comment