IEEE 802.11 Wireless Ethernet Security

References

"The Unoffical 802.11 Security Web Page", http://www.drizzle.com/~aboba/IEEE/

"Your 802.11 Wireless Network has No Clothes", "Arbaugh, Shankar, Wan", University of Maryland, March 2001.

"Intercepting Mobile Communications: The Insecurity of 802.11", Nikita Borisov, Ian Goldberg, and David Wagner, University California Berkeley,

http://www.idg.net/ic_814394_5056_1-2792.html

Overview

Wireless networks provide a "backdoor" around the traditional firewall protection organizations use on their wired networks. So called "parking lot" attacks are based on access to network traffic leaking out of buildings. While this is more likely to happen with wireless than wired networks, relying on security via restricted physical access to a network is still a bad idea, so from this perspective wireless networks simply raise the visibility of more fundamental security weaknesses.

802.11 does not have a complete security standard, in that it leaves many of the harder issues (e.g. key management) undefined. It has also been found to be lacking in what it does standardize.

Weaknesses in the design of 802.11 security mechanisms exist regardless of whether encryption is used (and independent of the strength of encryption) on the network.

Problems in 802.11 security are attributed mostly to weaknesses in how the system was implemented, and not directly to the cryptographic strength of the algorithms. Public review of the approach presumably would have shown these problems before they became embedded in silicon.

Association process

Stations associate with one another and access points in order to communicate. Associations are formed in a two step process.

Clients start in an unassociated and unauthenticated state.

Each BSS has a unique SSID (service set identifier).

Access points transmit beacon management frames periodically. Beacon frames contain the SSID associated with the AP. Clients listen for beacon frames to identify which access points are within their range. Clients may also send probe frames to find APs associated with a particular SSID.

Once a client selects an AP, the client and the AP exchange management frames to move to an authenticated state.

After authentication, the client and AP exchange some more frames to reach the authenticated and associated state.

Authentication

802.11 provides for two authentication mechanisms. These mechanisms are independent of whether WEP (encryption) is being used.

Share key authentication

Shared key mode uses a standard challenge/response approach. The station wishing to associate with an AP must provide a secret. The steps are as follows:
  1. Client sends auth request frame asking to use shared key.
  2. The AP responds with an auth frame including a 128 octets of challenge text.
  3. The client then copies the challenge text, encrypts it via WEP using the shared key and an IV, and sends it back to the AP.
  4. If everything checks, the AP sends a management frame back to the client confirming authentication.

If this first round of authentication is successful, the client and AP switch roles and reverse the process, thus insuring mutual authentication.

Lucent uses a proprietary scheme whereby the SSID acts as the shared key. If the client knows the SSID, it knows the secret, and can authenticate to the network.

Some vendors use an access control list in the APs. The APs maintain a list of MAC addresses which are authorized to use them. Clients whose MAC address are not on the list are denied association.

Problems

Key management
Shared secret (key) management is not addressed by the 802.11 standard. As a result it is left up to vendors.

In some cases vendors claim to provide key management, but do so in a weak fashion. In other cases vendors won't divulge details of their key management, making security assessment impossible.

Since there is no standard, and since key management is difficult, the majority of networks have long key periods, meaning that keys are seldom changed. This results in insecurities in that once a key is compromised in some other fashion, illegal access to a network continues for a potentially long time.

Use of SSID as key
Lucent's use of the SSID as the shared key is problematic as the SSID is broadcast in the clear in several management frames. Sniffing for these frames reveals the key and allows access to the network, whether or not WEP is being used (since the key is used by WEP).
Access control list
MAC addresses must be sent in the clear even when WEP is enabled, so sniffing for MAC addresses is easy. A bad guy can then re-program a wireless card to use one of the MAC addresses in an APs ACL.
Shared key attack
Even when the shared key is not the SSID (and hence easily obtainable), weaknesses in the authentication protocol allows for passive attacks which will allow attackers to authenticate to the AP without knowing the shared key.

An attacker can sniff the random challenge from an AP (in the clear), and the encrypted response from a client. The initialization vector is sent in the clear as part of even WEP encrypted frames. With these three known, and the fact that all fields in the management frame except the random challenge are the same for all frames in an authentication sequence, the attacker can create the frames required to authenticate with an AP without knowing the shared key.

If WEP is being used then the attacker can't communicate on the network unless the shared key is known. WEP attacks can provide this.

Wired Equivalent Privacy (WEP)

WEP is the part of the 802.11 standard which addresses privacy of communication via encryption of data. Cryptographic weaknesses in WEP are exploitable when the key being used is not changed frequently.

Problems with WEP were first published in late fall of 2000. Nikita Borisov, Ian Goldberg, and David Wagner at UCB.

WEP encrypts data with the shared secret key plus an initialization vector. Each packet includes an integrity check to detect packets that have been altered.

The encryption protocol is RC4. RC4 takes a small key and expands it into an infinite pseudo-random key stream. This keystream is then XORd with the plaintext.

Decrypting is just a matter of XORing with the key to get the plaintext back.

Problems

Stateless protocol

Stations don't keep state, so can't detect replay attacks.

Linear checksums

The integrity check used is a 32 bit CRC. This is a linear checksum, which means that it is possible to determine which bits to flip in a checksum to mask bit flips in the message it protects. That, in conjunction with the linearity of the RC4 encryption, allows attackers to alter packets and checksums so that an AP can't detect the alteration.

Initialization vector

The IV is used with the shared key to encrypt packets. The IV should be changed for each packet (though this is not required by the standard), since having two packets that were encrypted with the same IV/key pair allows for statistical attacks to decrypt the packets. Worse yet, if one of the packets is for known plaintext, the second packet's plaintext is therefore known.

The space of the IV's is small (24) bits. At 11 Mbps and 1500 byte frames, the entire space is exhausted (and hence must be reused) in about 5 hours. Small frames makes this even faster.

Some 802.11 cards (Lucent for example) reset the IV to 0 at initialization and increment it by 1 for each packet sent. This means that two laptops which are booted at roughly same time will be sending packets with a high probability of using the same IV.

Collecting a database of packets which cover the entire IV space allows you to decrypt any packet. Such a database would be about 15 Gbytes and take only a few hours to collect on a busy network.

Weak keys

In August of 2001 Fluhrer, Mantin, and Shamir published problems with the RC4 algorithm used in WEP.
  1. A large number of weak keys exist in this algorithm. Weak keys are easy to break.
  2. Knowing a small part of the key helps crack the entire key.
The second vulnerability of RC4 is a problem for WEP because the first byte of the key (the key id byte) is transmitted in the clear. This is used as part of a key management system supported in 802.11.

Depending on how IVs are generated (little or big endian rolling counters), the number of packets required to discover the complete key by knowing the first byte is 1-4 million.

At 2500 packets per second (11 M bps, 500 byte packets) collecting 1,000,000 packets only requires 400 seconds.

In this attack, the cost of the attack goes linearly with the length of the key, so longer keys don't help that much.

Attacks

Packet alteration

Being able to make alterations to packets that can't be detected by the access point means that if an attacker can guess about some of the contents of a packet, he can make selective alterations and inject them into the network.

Packet re-routing

One use for this would be to change the IP header to re-route the packet to conspiring machine on the wired network. This packet would be sent unencrypted to the wired machine, revealing the plaintext message. The TCP checksum doesn't protect you since it is only checked once the packet reaches the destination machine which is presumably in league with the attacker.

Packet insertion

Knowing a single plaintext message allows you to insert arbitrary packets into the network since it gives you the random stream associated with one of the IVs.

Future work

IEEE 802.1x Robust Security Network is supposed to address issues of key management, access control, and authentication.

Some criticism has already arisen that 802.1x has flaws. In February 2002, Mishra and Arbaugh found 802.1x was susceptible to man-in-the-middle and session highjacking attacks.

Dubbed "session hijacking" and "man-in-the-middle," both attacks basically exploit inherent problems in Wi-Fi as well as exploiting how the new 802.1x standard is designed.

"Here's how session hijacking works. The hacker waits for someone to finish successfully the authentication process. Then you as the attacker send a disassociate message, forging it to make it look like it came from the AP [access point]. The client [user] thinks they have been kicked off, but the AP thinks the client is still out there. As long as WEP is not involved you can start using that connection up until the next time out, usually about 60 minutes," said Arbaugh.

A session hijacking can occur because of the so-called race conditions between the 802.1x and 802.11 state machines. Arbaugh uses the analogy of a thief and a store owner racing for the front door at the same time. If the owner gets there first he locks the thief out, if the thief gets there first he steals everything. Because the client and the AP aren't synchronized, "loose consistency," the thief can tell the owner/client to go away and the AP still thinks he is there. "The robber gets there first," said Arbaugh.

The second form of attack is called man-in-the-middle, and while Brian Grimm, a spokesman for WECA [Wireless Ethernet Compatibility Alliance] said that the Wi-Fi association was aware of the problem and that it had already been fixed, Arbaugh said he had not heard from WECA but that he "would be shocked if they solved the problem." The man-in-the-middle attack works because 802.1x uses only one-way authentication. In this case, the attacker acts as an AP to the user and as a user to the AP.

"The trust assumption that is reflected from this design is that the access points are trusted entities, which is a misjudgement. The entire framework is rendered insecure if the higher-layer protocol also performs a one-way authentication," according to the Arbaugh, Mishra paper.

Temporal Key Integrity Protocol (TKIP)

Conclusions

In general for security systems/standards Specifically for 802.11 networks: