Wired Equivalent Privacy

Wired Equivalent Privacy (WEP) is an obsolete security algorithm for 802.11 wireless networks. It was introduced as part of the original IEEE 802.11 standard ratified in 1997. The standard described WEP as providing a level of security and privacy comparable to that of a traditional wired network. WEP, recognizable by its key of 10 or 26 hexadecimal digits (40 or 104 bits), was once widely used and was often the default security option presented to users by router configuration tools. After a major design flaw in the algorithm was disclosed in 2001, WEP was no longer considered secure. In most cases, Wi-Fi hardware that relied on WEP could not be upgraded to support stronger encryption. Some of WEP's flaws were addressed in WEP2, but it also proved insecure and was never widely adopted or standardized.

In 2003, the Wi-Fi Alliance announced that WEP and WEP2 had been superseded by Wi-Fi Protected Access (WPA). In 2004, with the ratification of the full 802.11i standard (i.e. WPA2), the IEEE declared that both WEP-40 and WEP-104 were deprecated. WPA retained some design characteristics of WEP that continued to present weaknesses.

WEP was the only encryption protocol available to 802.11a and 802.11b devices built before the WPA standard, which was introduced with 802.11g. Some 802.11b devices later received firmware or software updates to enable WPA, and newer devices included it by default.

History

WEP was ratified as a Wi-Fi security standard on September 17, 1999. The first versions of WEP were relatively weak, even at the time of release, due to U.S. restrictions on the export of cryptographic technologies. These restrictions led manufacturers to limit devices to 64-bit encryption. When the restrictions were lifted, the encryption length was increased to 128 bits. Although 256-bit WEP was later introduced, 128-bit WEP remained the most common implementation.

Encryption details

WEP was included as the privacy component of the original IEEE 802.11 standard ratified in 1997. WEP uses the stream cipher RC4 for confidentiality, and the CRC-32 checksum for integrity. It was deprecated in 2004 and is documented in the current standard.

Basic WEP encryption: RC4 keystream XORed with plaintext

Standard 64-bit WEP uses a 40-bit key (also known as WEP-40), which is concatenated with a 24-bit initialization vector (IV) to form the RC4 key. At the time the original WEP standard was drafted, U.S. export restrictions on cryptographic technology limited the key size. Once those restrictions were lifted, manufacturers of access points implemented an extended 128-bit WEP protocol using a 104-bit key size (WEP-104).

A 64-bit WEP key is usually entered as a string of 10 hexadecimal (base 16) characters (0–9 and A–F). Each character represents 4 bits; 10 digits at 4 bits each gives 40 bits. Adding the 24-bit IV produces the complete 64-bit WEP key (4 bits × 10 + 24-bit IV = 64-bit WEP key). Most devices also allow the user to enter the key as 5 ASCII characters (0–9, a–z, A–Z), each of which is turned into 8 bits using the character’s byte value in ASCII (8 bits × 5 + 24-bit IV = 64-bit WEP key). However, this restricts each byte to printable ASCII characters, which represent only a small fraction of possible byte values, greatly reducing the space of possible keys.

A 128-bit WEP key is usually entered as a string of 26 hexadecimal characters. Twenty-six digits at 4 bits each gives 104 bits; adding the 24-bit IV produces the complete 128-bit WEP key (4 bits × 26 + 24-bit IV = 128-bit WEP key). Most devices also allow entry as 13 ASCII characters (8 bits × 13 + 24-bit IV = 128-bit WEP key).

152-bit and 256-bit WEP systems were available from some vendors. As with other WEP variants, 24 bits are reserved for the IV, leaving 128 or 232 bits for the key material. These are typically entered as 32 or 58 hexadecimal characters (4 bits × 32 + 24-bit IV = 152-bit WEP key; 4 bits × 58 + 24-bit IV = 256-bit WEP key). Most devices also allow entry as 16 or 29 ASCII characters (8 bits × 16 + 24-bit IV = 152-bit WEP key; 8 bits × 29 + 24-bit IV = 256-bit WEP key).

Authentication

Two methods of authentication can be used with WEP: Open System authentication and Shared Key authentication.

In Open System authentication, the WLAN client does not provide credentials to the access point during authentication. Any client can authenticate with the access point and then attempt to associate. In effect, no authentication occurs. After association, WEP keys are used for encrypting data frames, and the client must have the correct keys.

In Shared Key authentication, the WEP key is used in a four-step challenge–response handshake:

1. The client sends an authentication request to the access point.
2. The access point replies with a clear-text challenge.
3. The client encrypts the challenge text using the configured WEP key and sends it back in another authentication request.
4. The access point decrypts the response. If it matches the challenge text, the access point sends back a positive reply.

After authentication and association, the pre-shared WEP key is also used for encrypting data frames with RC4.

Although Shared Key authentication might appear more secure than Open System authentication, the opposite is true. The keystream used for the handshake can be derived by capturing the challenge frames in Shared Key authentication. This makes it easier to intercept and decrypt data with Shared Key authentication than with Open System authentication. If privacy is a concern, Open System authentication is generally preferable when using WEP, though it also allows any WLAN client to connect to the access point. Both mechanisms are weak, and Shared Key WEP has been deprecated in favor of WPA/WPA2.

Weak security

Further information: Fluhrer, Mantin and Shamir attack

Because RC4 is a stream cipher, the same traffic key must never be reused. The purpose of an IV, which is transmitted as plaintext, is to prevent repetition. However, WEP’s 24-bit IV is too short to guarantee uniqueness on a busy network. The way the IV was implemented also exposed WEP to a related-key attack. For a 24-bit IV, there is a 50% probability of repetition after about 5,000 packets.

In August 2001, Scott Fluhrer, Itsik Mantin, and Adi Shamir published a cryptanalysis of WEP that exploited the way RC4 and IVs were used, enabling a passive attack that could recover the RC4 key after eavesdropping on network traffic. Depending on traffic volume, a successful key recovery could take as little as one minute. If insufficient packets were available, attackers could stimulate traffic by sending packets to the network and analyzing the replies. The attack was quickly implemented, and automated tools were released. With a personal computer, standard hardware, and freely available software such as aircrack-ng, WEP keys can be cracked in minutes.

Cam-Winget et al. surveyed WEP’s shortcomings. They noted that “experiments in the field show that, with proper equipment, it is practical to eavesdrop on WEP-protected networks from distances of a mile or more from the target.” They also identified two general weaknesses:

• WEP was optional, and many installations never enabled it.
• By default, WEP relied on a single shared key among users, making it difficult to manage compromises, which were often ignored.

In 2005, the U.S. Federal Bureau of Investigation demonstrated cracking a WEP-protected network in three minutes using publicly available tools. Andreas Klein later presented an analysis of RC4 showing additional correlations between the keystream and the key, which could also be exploited to break WEP.

In 2006, Bittau, Handley, and Lackey showed that the 802.11 protocol itself could be leveraged to make earlier attacks practical. After eavesdropping a single packet, an attacker could bootstrap to transmit arbitrary data. The captured packet could then be decrypted one byte at a time (by transmitting about 128 packets per byte) to reveal local network IP addresses. If the network was connected to the Internet, attackers could use 802.11 fragmentation to replay packets with modified headers, allowing the access point to decrypt them and forward them online. This enabled real-time decryption of WEP traffic within a minute of capturing the first packet.

In 2007, Erik Tews, Andrei Pyshkin, and Ralf-Philipp Weinmann extended Klein’s 2005 attack and optimized it for WEP. Their method could recover a 104-bit WEP key with 50% probability using only 40,000 captured packets. With 60,000 packets, the probability rose to about 80%, and with 85,000 packets, about 95%. Using active techniques such as Wi-Fi deauthentication attacks and ARP re-injection, 40,000 packets could be captured in under a minute under favorable conditions. The computation required about three seconds and 3 MB of memory on a Pentium-M 1.7 GHz processor, and could be optimized for slower devices. The same attack worked against 40-bit keys with even higher success rates.

In 2008, the Payment Card Industry Security Standards Council (PCI SSC) updated the Data Security Standard (DSS) to prohibit the use of WEP in credit-card processing after 30 June 2010, and to prohibit the installation of any new WEP-based systems after 31 March 2009. The use of WEP was a factor in the TJ Maxx parent company network breach.

Caffe Latte attack

The Caffe Latte attack is another method of defeating WEP. Unlike many other attacks, it does not require the attacker to be within range of the target network. By exploiting a vulnerability in the Windows wireless stack, it is possible to obtain the WEP key from a remote client. The attack works by sending a flood of encrypted ARP requests, taking advantage of shared key authentication and message modification flaws in 802.11 WEP. The attacker then uses the ARP responses to recover the WEP key, often in less than six minutes.

Countermeasures

The use of encrypted tunneling protocols (e.g., IPsec, Secure Shell) can provide secure data transmission over an insecure network. However, replacements for WEP were developed to restore security at the wireless network layer itself.

802.11i (WPA and WPA2)

The recommended solution to WEP’s security problems is to migrate to WPA2. WPA was introduced as an interim solution for hardware that could not support WPA2. Both WPA and WPA2 are significantly more secure than WEP. To enable WPA or WPA2, some older Wi-Fi access points required firmware upgrades or replacement. WPA was designed as a software-implementable stopgap to extend the life of WEP-based hardware. However, the TKIP (the basis of WPA) has reached the end of its intended lifetime, has been partially broken, and was officially deprecated with the release of the 802.11-2012 standard.

Implemented non-standard fixes

WEP2

WEP2 was a stopgap enhancement included in some early 802.11i drafts. It was supported on certain hardware that could not handle WPA or WPA2, and extended both the IV and key values to 128 bits. It was intended to address the duplicate IV problem and resist brute-force key attacks.

Once it became clear that WEP’s overall design was fundamentally flawed, both the WEP2 name and algorithm were abandoned. The extended key lengths were retained in what later became WPA’s TKIP.

WEPplus

WEPplus, also known as WEP+, is a proprietary enhancement developed by Agere Systems (formerly a subsidiary of Lucent Technologies) that attempted to improve WEP security by avoiding "weak IVs". It is only fully effective when implemented at both ends of the wireless connection, which is difficult to enforce. It also does not prevent replay attacks and is ineffective against later statistical attacks that do not rely on weak IVs.

Dynamic WEP

Dynamic WEP refers to the use of 802.1x technology with the Extensible Authentication Protocol to change WEP keys dynamically. It was a vendor-specific feature offered by several companies, including 3Com.

The concept of dynamic key changes was later incorporated into 802.11i as part of TKIP, but not retained for WEP itself.

See also

• Stream cipher attacks
• Wireless security
• Wi-Fi Protected Access

External links

• The Evolution of 802.11 Wireless Security, by Kevin Benton, April 18th 2010 Archived 2016-03-02 at the Wayback Machine