Combating WEP Weaknesses: Securing WLANs with IPSec

Combating WEP Weaknesses: Securing WLANs with IPSec
Providing security for wireless LANs (WLANs) presents particular challenges. In a wired network it is possible to maintain physical control over the access points (APs)-an intruder must have access to the facility in order to plug into a network jack. Within a wireless system, a potential intruder need only have access to an area where the wireless signal penetrates. Due to signal bleed-over, intruders can sit outside the building, across the street, or just in adjacent office space within the same building and tap into a wireless network.

Clearly, the threat of breaking into WLAN airwaves has been a hot topic. With that in mind, the 802.11 committee, which governs the WLAN specs in the US, developed the wired equivalent privacy (WEP) protocol. The problem, however, is that WEP's use of a static key does little to prevent hackers from cracking into corporate WLAN structures, thus potentially creating gaping security holes within a large number of corporate networks.

With its ability to set up secure tunnels, IPSec is being viewed as a potential solution to the WEP problem. In this article, we'll explore the WEP protocol, why WEP has problems, and how IPSec can be implemented to solve these problems.

The WEP Approach
As designated under the 802.11b specification, the WEP uses the RC4 symmetric key encryption algorithm to encrypt data traffic between clients and APs. In WEP, each AP employs a single key to encrypt and decrypt traffic; this same single key is disseminated to each client that is granted access to the wireless network. Key dissemination takes place outside of the wireless network.

WEP specifies the use of 40-b or 104-b keys. When data is transmitted, a checksum is appended to the data. A 24-b initialization vector (IV) is chosen randomly and appended to the WEP key to form a 64-b or 128-b encryption key. The data and the checksum are then encrypted using that encryption key.

The 24-bit IV is then appended to the packet and the packet is transmitted. Upon receipt of the packet, the IV is retrieved from the packet and appended to the original WEP key. The reconstituted key is then used to decrypt the packet, and the checksum is verified.

In addition to encryption, the WEP key also provides authentication when a new client accesses the network. Upon registration for access, the AP issues a challenge, and the client uses the WEP key to compute a valid response. The process is then reversed, providing the client with authentication of the AP.

In theory, for small networks with low security requirements, 128-b WEP could provide adequate security. Many of the 802.11b products that are on the market even today offer multiple tiers of security settings, with the use of 128-bit WEP in conjunction with hardware-based identification processes being a lead component of the lowest tier (highest security is provided through the incorporation of an IPsec VPN).

This positioning, however ignores the two glaring weaknesses in WEP-poor key management and easily broken encryption.

On the key front, 802.11b offers no defined key management process. In most implementations, a single WEP key is shared by all APs and clients. The shared key is distributed to users and then manually input into their client devices.

Maintaining a "secret" key in this environment is virtually impossible. Theft of a laptop or PDA, the departure of a disgruntled employee, or even the use of the network by a visitor or temporary contractor would necessitate re-keying every wireless device within the network-not a likely occurrence.

This key management structure has two likely outcomes:

1. When WEP is used, keys are rarely updated, leaving the network vulnerable to break-in, and
2. WEP itself is rarely used. Needless to say, neither outcome is desirable from a security standpoint.

WEP Encryption
For that small subset of 802.11b networks that do attempt to use WEP (estimates range between 10% and 40% of 802.11b networks bother to try), the encryption that it provides is easily broken.

As stated above, WEP is based on a symmetric key algorithm-RSA Security's RC4. RC4 is a perfectly good cryptographic primitive. The 802.11 standard's use of RC4 in WEP, however, is fundamentally unsound.

First, 40-b keys are still commonly used for WEP. These small keys can be easily broken with reasonable computing resources. Second, because WEP uses a static base key, keys remain in play for a long time, making them much easier for a hacker to break by checking patterns in the intercepted data stream.

RC4 is used with great effect with the secure sockets layer (SSL) protocol. Within SSL, RC4 provides the bulk encryption of actual data, within a larger protocol that provides for secure exchange of encryption keys and extensive authentication of data. Further, SSL employs true 128-b keys, meaning that key re-use is a virtual impossibility. WEP provides none of these safeguards, with perilous results.

In an article, Intel's Jesse Walker provided a detailed breakdown of the problems with WEP. According to Walker, because the WEP base key is static, the key size is irrelevant; in effect WEP employs 24-b security with a total of 2^24 possible keys for each base key. RC4 is a stream cipher, as such it must never reuse encryption keys. WEP, by design, does just that. With an AP running at 11 Mbps, Walker says the pool of 2^24 possible keys would use all of the potential keys within an hour. An attacker with two packets encrypted with identical keys would have enough data to launch an attack and penetrate the system. ³

Some of the proprietary "dynamic WEP" key management schemes that are currently being offered provide base key updates ever 20 minutes, and newer systems will re-key even faster-at first glance enough to prevent duplication. But, according to Walker, the one-hour figure is a best-case scenario since there is a 99% chance of at least one set of duplicate keys will be used within 2 to 3 seconds of normal traffic.

If you add in the use of those same keys across multiple nodes and the coming migration to 5 Ghz/54 Mbps systems, the severity of the security compromise becomes even worse. Over the course of just a few hours of collecting traffic, enough data can be collected for extensive traffic analysis and system penetration.

Solving the Problem
Efforts are underway within the wireless community to address outstanding security issues. The 802.11 committee has formed its "i" subcommittee to explore the problems with and correct the WEP protocol.

The temporal key integrity protocol (TKIP) is an interim solution already being pushed by the 802.11i committee. Under TKIP, the client starts with a 128-bit "temporal key" (TK) that is then combined with the client's MAC address and with an initialization vector to create a key that is used to encrypt data via the RC4. Temporal keys are changed every 10,000 packets, addressing the glaring key reuse issue in WEP and making WLAN systems considerably more secure.

TKIP systems are expected to be available during the second quarter of 2002, and will be backward compatible with existing 802.11b hardware. While TKIP represents a step forward, it is widely seen as a stopgap measure that has not been widely tested. Many industry experts are pointing the recently adopted Advanced Encryption Standard (AES) protocol as the best long term security option. AES equipped wireless LAN hardware should be available in 2003.

Another alternative is to use IPsec for wireless security. IPsec is the Internet Engineering Task Force (IETF) protocol for providing encryption and authentication for IP traffic. IPsec is characterized by a strong key exchange, or "handshake" function, that is used to establish a connection and strong data encryption and authentication that ensure both confidentiality and integrity.

The IPSec protocol includes two main parts: a key-exchange function (a "handshake") that determines how the two sites will communicate, and a bulk encryption/authentication function that manages the encryption and authentication of the actual data being communicated.

Where WEP employs only the RC4 encryption algorithm with no real authentication, IPsec employs multiple encryption and authentication, or "hash" algorithms, to provide for secure key management, authentication, and encryption of traffic. The primary means of providing the "handshake" within IPsec is the use of the Internet key exchange (IKE) protocol.

The IKE protocol offers a secure means of establishing a connection that uses secret material that prevents even someone who intercepts data from compromising the keys. Further, the IKE protocol regularly re-keys. This prevents an intruder from intercepting data and using it to eventually break the keys.

At a very simplified level, IKE works like this: when one party attempts to pass data to another in a way that requires the use of IPsec, IKE first establishes the security associations (SAs) between the two parties. The SAs govern how the actual data transfer will take place. A typical IKE exchange starts with a Phase 1 exchange that employs at least one Diffie-Hellman (DH) exchange, an RSA sign operation, and two RSA verify operations to create the SAs that verify the two parties' identities, set a variety of parameters, and generate a shared key.

The Phase 2 IKE process uses the Phase 1 exchange to set up Phase 2 exchanges. The Phase 2 exchanges create the SAs that drive IPsec. Phase 2 IKE uses the Phase 1 SA to generate Phase 2 SAs.

The Phase 2 SAs include the key material for generating the new keys for the actual data encryptions. Phase 2 SAs also determine which of several IPsec options are employed, including tunnel or transport mode, authentication header (AH) or encapsulating security payload (ESP), and 3DES or AES encryption.

With the Phase 2 SAs in place, the actual IPsec encryption and transfer of data can commence. IPsec does require a fair level of attention to choosing and setting up security policies, but if the goal is to provide a truly secure environment then some work should be expected.

IPsec can sit cleanly within the 802.11b architecture. By adding a VPN appliance between the AP and the network, or by using only access equipment that incorporates IPsec-based VPN capability into the AP, an 802.11b system can be made readily secure. Several vendors now offer this functionality under the label of "highest security."

Adding VPN functionality to the client isn't as easy. Part of 802.11b's popularity stems from the ease of setup--loading an access card into a laptop is a quick and easy installation. Adding IPsec VPN security requires some setup work at the client side--adding to the administrative burden. In later versions of Windows this involves a process slightly more complicated than setting up a new dial-up connection.

While client setup does require some administrator time and effort, it quickly pales when compared to attempting to update WEP keys on a regular basis. New software products are being introduced that help apply VPN functionality to handheld devices, extending the security umbrella beyond the laptop to cover most portable devices.

Some firewalls will reject IPsec-encrypted packets as potential threats, as the firewall is unable to inspect the packet contents. Similarly, the network address translation (NAT) scheme used in some networks can present problems; if translation occurs after encryption occurs the receiving VPN station may reject the incoming packets as having been corrupted. Security advisors recommend using single-source vendors when possible to limit interoperability hurdles and allow standardization.

WLAN LAN systems provide tremendous flexibility to corporate users. However, wireless users should not make the mistake of believing that any WEP-based security option provides anything more than a way of keeping the honest people out. Within a VPN architecture, IPsec can solve the security problem that threatens to limit the use and utility of 802.11b systems.

References

1. "Security of the WEP algorithm" Nikita Borisov, Ian Goldberg, and David Wagner http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html
2. "Your 802.11 Wireless Network has No Clothes" William A. Arbaugh, Narendar Shankar, Y.C. Justin Wan; Department of Computer Science University of Maryland http://www.cs.umd.edu/~waa/wireless.pdf
3. "Unsafe at any key size; An analysis of the WEP encapsulation" Jesse R. Walker, Intel Corporation, http://grouper.ieee.org/groups/802/11/Documents/DocumentHolder/0-362.zip
4. AT&T Labs Technical Report TD-4ZCPZZ, "Using the Fluhrer, Mantin, and Shamir Attack to Break WEP" August 6, 2001 Adam Stubblefield, Rice University; John Ioannidis and Aviel D. Rubin, AT&T Labs -- Research, Florham Park, NJ, www.sublimation.org/security/localarchive/802.11/wep_attack.pdf
5. IETF's IPsec draft specs, http://www.ietf.org/ids.by.wg/ipsec.html
6. "Better Than WEP" Feb 1, 2002 Lisa Phifer, Core Competence http://www.isp-planet.com/fixed_wireless/technology/2002/better_than_wep.html
7. "Certicom Serves up Wireless VPN Using 802.11b" Michael Singer, Silicon Valley Internet.com; http://siliconvalley.internet.com/news/article/0,2198,3531_907461,00.html

About the Author
Robert Doud is the Director of Technology at NetOctave. Prior to joining NetOctave, he was the Senior Systems Architect at SafeNet. Robert can be reached at bdoud@netoctave.com.