Thursday, May 13, 2010

Wired Equivalent Privacy (WEP) Wireless Security

Wired Equivalent Privacy (WEP) Encryption details

Wired Equivalent Privacy (WEP) was included as the privacy of the original IEEE 802.11 standard ratified in September 1999.[6] WEP uses the stream cipher RC4 for confidentiality,[7] and the CRC-32 checksum for integrity.[8] It was deprecated as a wireless privacy mechanism in 2004, but for legacy purposes is still documented in the current standard.
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 traffic key. At the time that the original WEP standard was being drafted, U.S. Government export restrictions on cryptographic technology limited the key size. Once the restrictions were lifted, all of the major manufacturers eventually implemented an extended 128-bit WEP protocol using a 104-bit key size (WEP-104).
A 128-bit WEP key is almost always entered by users as a string of 26 hexadecimal (base 16) characters (0-9 and A-F). Each character represents four bits of the key. 26 digits of four bits each gives 104 bits; adding the 24-bit IV produces the final 128-bit WEP key.
A 256-bit WEP system is available from some vendors, and as with the 128-bit key system, 24 bits of that is for the IV, leaving 232 actual bits for protection. These 232 bits are typically entered as 58 hexadecimal characters. (58 × 4 = 232 bits) + 24 IV bits = 256-bit WEP key.
Key size is not the only major security limitation in WEP.[10] Cracking a longer key requires interception of more packets, but there are active attacks that stimulate the necessary traffic. There are other weaknesses in WEP, including the possibility of IV collisions and altered packets,[7] that are not helped at all by a longer key.

[edit] Authentication

Two methods of authentication can be used with WEP: Open System authentication and Shared Key authentication.
For the sake of clarity, we discuss WEP authentication in the Infrastructure mode (that is, between a WLAN client and an Access Point), but the discussion applies to the ad-Hoc mode as well.
In Open System authentication, the WLAN client need not provide its credentials to the Access Point during authentication. Thus, any client, regardless of its WEP keys, can authenticate itself with the Access Point and then attempt to associate. In effect, no authentication (in the true sense of the term) occurs. After the authentication and association, WEP can be used for encrypting the data frames. At this point, the client needs to have the right keys.
In Shared Key authentication, the WEP key is used for authentication. A four-way challenge-response handshake is used:
  1. The client station sends an authentication request to the Access Point.
  2. The Access Point sends back a clear-text challenge.
  3. The client has to encrypt the challenge text using the configured WEP key, and send it back in another authentication request.
  4. The Access Point decrypts the material, and compares it with the clear-text it had sent. Depending on the success of this comparison, the Access Point sends back a positive or negative response.
After the authentication and association, the pre-shared WEP key is also used for encrypting the data frames using RC4 .
At first glance, it might seem as though Shared Key authentication is more secure than Open System authentication, since the latter offers no real authentication. However, it is quite the reverse. It is possible to derive the keystream used for the handshake by capturing the challenge frames in Shared Key authentication.[2] Hence, it is advisable to use Open System authentication for WEP authentication, rather than Shared Key authentication. (Note that both authentication mechanisms are weak.)

[edit] Flaws

Because RC4 is a stream cipher, the same traffic key must never be used twice. The purpose of an IV, which is transmitted as plain text, is to prevent any repetition, but a 24-bit IV is not long enough to ensure this on a busy network. The way the IV was used also opened WEP to a related key attack. For a 24-bit IV, there is a 50% probability the same IV will repeat after 5000 packets.
In August 2001, Scott Fluhrer, Itsik Mantin, and Adi Shamir published a cryptanalysis of WEP that exploits the way the RC4 cipher and IV is used in WEP, resulting in a passive attack that can recover the RC4 key after eavesdropping on the network. Depending on the amount of network traffic, and thus the number of packets available for inspection, a successful key recovery could take as little as one minute. If an insufficient number of packets are being sent, there are ways for an attacker to send packets on the network and thereby stimulate reply packets which can then be inspected to find the key. The attack was soon implemented, and automated tools have since been released. It is possible to perform the attack with a personal computer, off-the-shelf hardware and freely available software such as aircrack-ng to crack any WEP key in minutes.
Cam-Winget et al. (2003) surveyed a variety of shortcomings in WEP. They write "Experiments in the field indicate 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 reported two generic weaknesses:
  • the use of WEP was optional, resulting in many installations never even activating it, and
  • WEP did not include a key management protocol, relying instead on a single shared key among users.
In 2005, a group from the U.S. Federal Bureau of Investigation gave a demonstration where they cracked a WEP-protected network in 3 minutes using publicly available tools.[11] Andreas Klein presented another analysis of the RC4 stream cipher. Klein showed that there are more correlations between the RC4 keystream and the key than the ones found by Fluhrer, Mantin and Shamir which can additionally be used to break WEP in WEP-like usage modes.
In 2006, Bittau, Handley, and Lackey showed[5] that the 802.11 protocol itself can be used against WEP to enable earlier attacks that were previously thought impractical. After eavesdropping a single packet, an attacker can rapidly bootstrap to be able to transmit arbitrary data. The eavesdropped packet can then be decrypted one byte at a time (by transmitting about 128 packets per byte to decrypt) to discover the local network IP addresses. Finally, if the 802.11 network is connected to the Internet, the attacker can use 802.11 fragmentation to replay eavesdropped packets while crafting a new IP header onto them. The access point can then be used to decrypt these packets and relay them on to a buddy on the Internet, allowing real-time decryption of WEP traffic within a minute of eavesdropping the first packet.
In 2007, Erik Tews, Andrei Pychkine, and Ralf-Philipp Weinmann were able to extend Klein's 2005 attack and optimize it for usage against WEP. With the new attack
it is possible to recover a 104-bit WEP key with probability 50% using only 40,000 captured packets. For 60,000 available data packets, the success probability is about 80% and for 85,000 data packets about 95%. Using active techniques like deauth and ARP re-injection, 40,000 packets can be captured in less than one minute under good conditions. The actual computation takes about 3 seconds and 3 MB of main memory on a Pentium-M 1.7 GHz and can additionally be optimized for devices with slower CPUs. The same attack can be used for 40-bit keys with an even higher success probability. In 2008, Payment Card Industry (PCI) Security Standards Council’s latest update of the Data Security Standard (DSS), prohibits the use of the WEP as part of any credit-card processing after 30 June 2010, and prohibit any new system from being installed that uses WEP after 31 March 2009. The use of WEP contributed to the T.J. Maxx parent company network invasion[12].

[edit] Remedies

Use of encrypted tunneling protocols (e.g. IPSec, Secure Shell) can provide secure data transmission over an insecure network. However, replacements for WEP have been developed with the goal of restoring security to the wireless network itself.

[edit] 802.11i (WPA and WPA2)

The recommended solution to WEP security problems is to switch to WPA2 or with older equipment the less resource intensive WPA. Either is much more secure than WEP.[13] To add support for WPA or WPA2, some old Wi-Fi access points might need to be replaced or have their firmware upgraded. WPA was designed as an interim software-implementable solution for WEP that could forestall immediate deployment of new hardware.[14] However, TKIP (the basis of WPA) has reached the end of its designed lifetime and has been deprecated in the next[dated info] full release of the 802.11 standard.[15]

[edit] Implemented non-standard fixes

[edit] WEP2

This stopgap enhancement to WEP was present in some of the early 802.11i drafts. It was implementable on some (not all) hardware not able to handle WPA or WPA2, and extended both the IV and the key values to 128 bits.[16] It was hoped to eliminate the duplicate IV deficiency as well as stop brute force key attacks.
After it became clear that the overall WEP algorithm was deficient (and not just the IV and key sizes) and would require even more fixes, both the WEP2 name and original algorithm were dropped. The two extended key lengths remained in what eventually became WPA's TKIP.

[edit] WEPplus

WEPplus, also known as WEP+, is a proprietary enhancement to WEP by Agere Systems (formerly a subsidiary of Lucent Technologies) that enhances WEP security by avoiding "weak IVs".[17] It is only completely effective when WEPplus is used at both ends of the wireless connection. As this cannot easily be enforced, it remains a serious limitation. It is possible that successful attacks against WEPplus will eventually be found. It also does not necessarily prevent replay attacks.

[edit] Dynamic WEP

Dynamic WEP changes WEP keys dynamically. It is a vendor-specific feature provided by several vendors such as 3Com.
The dynamic change idea made it into 802.11i as part of TKIP, but not for the actual WEP algorithm.
http://en.wikipedia.org/wiki/Wired_Equivalent_Privacy
05/13/10

No comments:

Post a Comment