Ensuring Secrecy Through Encryption

After properly determining user identity and assigning access privileges, the network must protect user transmissions from eavesdropping. Several encryption protocols can be used on wireless LANs:

Static WEP

With static WEP, a single key is used to secure transmissions between the client and the access point. In most implementations, the same key is used by every station, which dramatically reduces the security.

802.1X-based dynamic WEP

In late 2001, the flaws in traditional single-key static WEP became impossible to ignore. Fortunately, the 802.1X specification had emerged from the standards committees and provided a way to dynamically send keys to clients. Refreshing WEP keys at short intervals provides defense against many of the attacks against static WEP.

Temporal Key Integrity Protocol (TKIP)

TKIP is part of 802.11i, and is designed to offer increased security on wireless interfaces with hardware assistance for RC4. To ensure frame integrity, TKIP is used with the Michael integrity check to detect frame tampering during flight. TKIP and Michael are a bandage on the open wound that is WEP. They are more secure, but it is hard to say how much more secure.

Counter Mode CBC-MAC Protocol (CCMP)

CCMP is the second major component of 802.11i. Rather than using two separate protocols for encryption and integrity, CCMP uses new cryptographic operations to combine both operations into a single protocol. It is a clean break with the checkered RC4-based past of link-layer security. Chipsets now incorporate hardware assistance for AES, which is the cipher that CCMP is based on.

Network-layer encryption

Instead of protecting the wireless network at the link layer, it is possible to apply long-standing network-layer encryption protocols, such as IPsec, SSL, or SSH.

Static WEP

Static WEP is a horrendous security protocol. It is better than nothing, but that is not saying much. Do not use static WEP unless there is nothing else that can be done to encrypt the network traffic. With most devices, static WEP can be considered obsolete. Nearly all cards have the ability to support improved 802.1X-based link-layer security mechanisms when used with recent drivers on supported operating systems. The only real reason to consider static WEP is the presence of application-specific devices that support nothing better.

You may have some older devices that support nothing better than static WEP due to limited processing power, and the cost of upgrading to a device capable of supporting better security protocols cannot be justified. Many handheld 802.11 inventory scanners and voice over IP telephones fall into this category. If you must use static WEP, first check for the most glaring security hole. Weak IVs are the lifeblood of static WEP tools. When Airsnort first made the news, many vendors updated radio firmware to avoid using weak IVs. Although an IV restricting firmware revision does little to address many of static WEP's flaws, it does dramatically reduce the exposure. Before deployment, check to see whether your static WEP implementations generate weak IVs. If they do, demand a fix. It is unconscionable that any vendor still ships products that are susceptible to this attack.

Static WEP is better than nothing, but it does offer some protection, especially compared to not using it any security measures. It is best at preventing nonhostile users from accidentially associating with the a network next door. However, static WEP will not protect against an even mildly determined attacker. If you are required to use static WEP, take precautions to ensure that the compromise of the WEP network is contained and cannot be used as a launch point for further attacks against your network.

Static WEP is an encryption protocol of last resort. Use it only if you have no other choice, and take appropriate security measures to limit your exposure.

 

Dynamic WEP Keying with 802.1X

Although 802.1X was designed for user authentication, its improvements to WEP are as important. 802.1X includes messages to distribute keys from the access point to client stations. Dynamic keying does a great deal to address outstanding flaws in WEP, although it is by no means a complete solution.

Dynamic keying has one important dependency. Keys should appear to be random, which means there must be a source of keying material or key entropy (random bits) somewhere. Keying material may come from an authentication method that generates it, such as one based on TLS, or it may be entered directly as a preshared secret. Through a series of operations that depends on the protocol in use, the keying material is transformed from a collection of random bits into the series of bits used as the link-layer encryption key.

Dynamic link-layer keys must be derived from a master secret. The master secret may be supplied directly, or come from the authentication.

Most importantly from a system administrator's perspective is that the radio link can be keyed dynamically. WEP keys need not be dreamed up by the network administration or distributed to users and network devices. Instead, the user authentication creates a cryptographically secure pool of random data that can be used to derive the WEP key. Stations still do WEP encryption to protect frames, but the key used to encrypt the frame is unique to the user and changes periodically. The rekey interval can be set by the network administrator. Rather than having a single key that is used until it is changed on all devices at the same time, the user's key is created on authentication and refreshed at regular intervals.

Keying messages can be used to distribute either the user keys (key mapping or unicast keys) as well as the broadcast keys (group or default keys). Default keys can be refreshed whenever a station leaves the network, as well as at regular intervals to bolster the protection.

Initialization vectors will repeat over the lifetime of a station association. However, the problem with IVs stems from repeated use of the same IV with the same secret key. By setting a suitably short key regeneration timer, it is possible to avoid repeating the IV+secret key combination. With a 24-bit IV, it will be 16 million (224) frames before an IV is repeated. By comparing the 16 million frame figure with 802.11 frame rates, you can derive a maximum key length. My analysis of 802.11 frame rates used a traffic load composed of "transactions" consisting of a TCP segment and corresponding TCP ACK.[*] Each transaction consumes two IVs. Based on the 16 million figure, you can calcuate the time until the IV space is exhaused. Table 22-1 presents the results of this calculation for a variety of load factors. In several ways, the table presents an unrealistically short lifetime for the key. For safety, the key lifetime is often set to half an hour, which provides a great deal of protection against IV reuse.

[*] See the analysis in "When Is 54 Not Equal to 54? An Analysis of the Maximum TCP Throughput of 802.11a, b, and g" (http://www.oreillynet.com/pub/a/wireless/2003/08/08/wireless_throughput.html). Note that this analysis assumes a 1:1 ratio between TCP segments and their ACKs, and thus consumes many more IVs than a model that assumes a better ratio of TCP segments to ACKs. However, for the purpose of security, it is useful to use an unrealistically stressful model to engineer a safe limit.

Table 22-1. IV space lifetime

	802.11b	802.11a/g, no protection
Transactions per second	479	2,334
IVs used per second	958	4,668
IV space lifetime, hours
100% load	4.8 hr	1.0 hr
75% load	6.5 hr	1.3 hr
50% load	9.7 hr	2.0 hr
25% load	19.5 hr	2.4 hr

The earliest WEP attack tools based on the Fluhrer-Mantin-Shamir attack, airsnort and wepcrack, relied on the collection of weak IVs and each required several million frames to recover keys. More recent tools, most notably aircrack,[*] combine the Fluhrer-Mantin-Shamir attack with other attacks and can recover keys much faster, sometimes with less than a million frames.

[*] Available from http://www.cr0.net:8040/code/network/aircrack/.

WEP is still subject to attacks on the frame integrity check, and there is no way to defend against them within the WEP framework. Indeed, the necessity of improving the integrity check was one of the major technical tasks for 802.11i. The only saving grace is that tools that exploit the weak integrity check hardly exist in comparison to their Fluhrer-Mantin-Shamir brethren.

At best, dynamic WEP is an interim step towards better security protocols, and should only be used when equipment does not support TKIP. When using dynamic WEP, be sure to set a relatively short key lifetime to protect against WEP analysis tools. I recommend no longer than 15 minutes.

 

Improved RC4-Based Encryption: TKIP

Dynamic WEP is a Band-Aid® that can be used when nothing better is available, or as a way of deploying a link-layer authenticated architecture in a reasonably secure fashion while considering improved alternatives. 802.11i includes two new link-layer security mechanisms. The Temporal Key Integrity Protocol (TKIP) is designed to mitigate known attacks against WEP while retaining backwards compatibility with existing hardware. TKIP is more secure than WEP, but has not yet been extensively analyzed yet.

TKIP's design goal is to be as secure as possible while retaining backwards compatibility. In the first wave of 802.11 chipsets, security was often implemented in software, if at all. To avoid the performance problems of software-based encryption, the second major wave incorporated hardware assistance for many WEP-based frame handling functions, including RC4 encryption. TKIP was designed to work with the WEP frame processing primitives while shoring up a number of the weak points in WEP.

TKIP retains RC4-based frame encryption, which allows it to be retrofitted on to existing 802.11 systems. As with dynamic WEP, TKIP depends on a source of random data to serve as the basis for its keys, so it must be used either with WPA-PSK or an 802.1X EAP method. Beyond the basic similarities, it adds per-frame keying to disrupt attacks against the initialization vector, and replay protection to stop frames from being retransmitted at a later time. TKIP also improves the integrity check by ensuring that the sender of a frame is in possession of the appropriate cryptographic key, and using an improved integrity check.

TKIP and dynamic WEP can coexist on most hardware. Most access points are capable of storing unique link layer keys for every station. If one station uses dynamic WEP and another uses TKIP, the key storage will reflect that. Using both encryption protocols simultaneously does weaken the security of broadcast frames because all stations on the same network must share the broadcast key.

For most deployments, TKIP should be considered a practical minimum standard unless it is unavailable. However, TKIP is should not be considered a long-term solution.

 

CCMP: Encryption with AES

TKIP is limited by the baggage of WEP. The Counter Mode with CBC-MAC Protocol (CCMP) in 802.11i was designed from scratch with security in mind. The design goal was to offer security comparable to existing trusted protocols such as IPsec without some of the limitations that IPsec imposes on wireless LANs. Design started with the AES cipher, which is the building block of most of the new security protocols being developed. WEP's legacy will prevent TKIP from being treated as a serious security protocol, but CCMP's underlying structure has been approved for use in sensitive U.S. government applications.

In addition to the efficiency gain from using AES, CCMP improves efficiency over existing cryptographic protocols. Traditional cryptographic protocols can be used either for encryption, which protects data over untrusted paths, or authentication, which ensures that it it was not altered in transit. WEP only provides encryption, and relied on a flawed integrity check algorithm. TKIP uses keys in two distinct ways. Like WEP, keys are used to provide frame encryption. Additional keys are used for a separate integrity check algorithm. CCMP, however, allows a single key to be used for both purposes, which reduces computational overhead and improves efficiency.

The main drawback to CCMP is a common implementation deficiency in client software. Although there is no reason why CCMP cannot coexist on the radio link with the RC4-based encryption protocols, most drivers do not support it. Mixing CCMP with RC4-based encryption requires that the driver support using CCMP for unicast frames and one of the RC4-based encryption protocols for broadcast frames. I do not know of any client vendor that supports this mode of operation. Herein lies the downside to using CCMP: it will result in more complex configurations to support two networks in parallel, and it may require replacing the wireless LAN interfaces in your computing devices.

CCMP is an attractive long-term goal for a link-layer security protocol, but product limitations may require running multiple wireless networks in parallel as well as a forklift upgrade.

 

Higher Layer Security Protocols (IPsec, SSL, and SSH)

When wireless protocols were first shown to be fundamentally broken, there was a rush to find a stopgap solution. Network architects turned to proven cryptographic protocols to encrypt network traffic as it flew through the air. IPsec was a major beneficiary of the attention paid to wireless security, although SSL and SSH are frequently considered. All of these protocols provide a way of identifying users, encrypting traffic, and ensuring that the packets are not tampered with in flight.

One drawback to using security at higher levels in the stack is that security protocols can only protect their contents. Protection at the network layer provides security services to the network layer and anything higher in the stack, but cannot do much to secure lower layers. Security administrators often worry about "turnaround" attacks that subvert an VPN client and use an established tunnel to access the protected network. To address this potential vulnerability, bolster the standard host-based security with personal firewall software and antivirus software. On the personal firewall side, several products are available, ranging from inexpensive one-off installations to robust, feature-rich, centrally managed products. Attacks against VPN client stations are enough of a concern that many VPN vendors bundle personal firewall software as part of the installation.

Security protocols implemented above the link layer do not offer effective protection to the link layer, so higher-layer security should be augmented with additional host-based security, such as personal firewall software.

Implementation at higher protocol layers also tends to dictate network architecture. VPN endpoints are typically bound to IP addresses, and most VPN clients do not cope well with having the address torn out from under them. Although 802.11 supports roaming by attaching to different networks, those networks may be different IP subnets. If the IP address changes, the VPN session must be reestablished. More importantly, users must accept the effects of changing addresses and the need to reestablish connections.

To keep connections as long-lived as possible, network architects need to maintain network state as stations move across the network. This can be done with link-layer identity management tools that provide handoff between APs using 802.1X-based protocols as in the dynamic VLAN architecture in the previous chapter, or it can be done by designing the network around the handoff limitations as in the single-subnet architecture in the previous chapter. The former case is a more complicated architecture for the network administrator to configure, but it is probably easier to build because it does not require extensive backbone engineering.

Many VPN technologies were designed around point-to-point encryption. Multicast applications can be based on IP, but IPsec does not yet include any method for group key distribution to enable the use of many-to-one transmissions. Distributing keys for point-to-point links is an "easy" problem because there are only two parties to the conversation. (By "easy," I mean that the problem is tractable and that a solution exists, not that it is trivial to accomplish.) Keying a point-to-multipoint connection is a "hard" problem because one sender and many receivers must agree on a set of keys, and it may be desirable to update keys as receivers join and leave the multicast session. Multicast data is a natural fit for several applications, most notably streaming media. Large companies may hold internal meetings over internal multicast sessions, and would undoubtedly want to ensure that any data from those sessions is encrypted over wireless networks. Multicast data is also used extensively in financial markets because it is a natural model to distribute market data. Various approaches to IPsec multicast are in progress in the standards communities, but have not been finalized yet.

IPsec is often used because it is implemented at the network layer, and thus is independent of the application with which it is used. As long as the applications can cope with the increased delay for IPsec encapsulation and decryption, it will work. In the most common IPsec architectures, no changes are required to use new applications or new servers located in the protected network. IPsec's wide adoption for remote access also means that there is often an IPsec termination device on the network that provides encryption. Many mobile devices already have clients installed and configured, and users have been trained and are comfortable using them. If an existing VPN concentrator is available and has spare capacity, it may be possible to extend an existing remote access IPsec deployment to internal wireless LAN users.

Adding new tasks to an existing concentrator may cause performance problems, especially if the VPN device was originally specified for remote access. Remote access users do not require significant bandwidth, especially compared to local LAN users. By definition, remote access capacity is defined by your uplink to the Internet. With many organizations still on T-1 lines or the equivalent speed SDSL connection, remote access connections are by definition limited to less than 2 Mbps. Extending a VPN to the wireless LAN may require significant VPN concentrator upgrades, or a wireless LAN system with IPsec termination built-in. IPsec may also cause performance problems. Maximum-size IP packets will become two IP fragments once the IPsec header information is added. One packet will include header information and also be maximum size, but the data that was elbowed out of the packet by the IPsec headers will be a second, minimal size IP fragment. Both fragments must be transmitted before the packet can be reassembled and decrypted.

While the head end of an IPsec solution is under the control of system administrators, the client side is not. Installing and configuring client software in a deployment of any size can be a challenge. That is, if the client software even exists. IPsec client software is targeted at the lowest common platform denominator, so many solutions are available only on Windows. Finding IPsec support for Mac OS and Linux is surprisingly difficult, in large part because of the differentiation on the concentrator side. Vendor X's termination device requires Vendor X's client software to use the features that make remote access easier. A few vendors provide client software for their own termination devices for Mac OS, but Linux clients are hard to find. (Free S/WAN is an IPsec implementation, but it does not support any of the special client features that are usually desirable in deployments.)

Client software loads may not stop with the IPsec client, either. IPsec protects from a wide spectrum of attacks at the network layer, but it is powerless to protect data at the link layer. For example, ARP spoofing or ARP poisoning attacks cannot be stopped by IPsec because it does not encrypt or authenticate ARP frames. IPsec cannot protect against some network layer attacks, either. Because IPsec requires that the client obtain an IP address, many wireless LANs secured by IPsec allow any system to attach to the network and obtain an IP address through DHCP. With that foothold, even casual attackers can launch IP-based denial-of-service attacks against the network infrastructure. Addressing link-layer attacks can be done through personal firewall software, but that presents another client component to install, configure, and manage. Personal firewall software has made great strides in recent years, and there are excellent solutions that can be centrally configured and managed.

IPsec user authentication may also result in a subtle security risk. Site-to-site VPNs use peer systems that are well known to each other and stay in fixed locations. In the leased-line replacement scenario, a handful of systems in well-known locations can be issued certificates for strong authentication. Remote access is a different story, however. IPsec was not designed for user authentication, and it shows. Digital certificates are one option, but are often rejected as an administrative nightmare. A variety of specifications exist to perform legacy user authentication with IPsec, all of which are incompatible. The major protocol, eXtended Authentication (XAUTH), is widely implemented but is not fully standardized. XAUTH requires the disclosure of identity early in the IPsec handshake, and must run in the security-diminishing "aggressive" mode. The security of the handshake and the resulting tunnel to pass user credentials depends on a shared secret. Many implementations of XAUTH allow, or worse, require the same shared secret to be used for all users. Furthermore, XAUTH is poorly designed, and subject to the compound binding problem discussed previously. (The "FIPS mode" on many certified IPsec products disables the use of XAUTH.) Sadly, many vendors continue to use XAUTH because it is implemented by many OEM clients. The major alternative to XAUTH is "Hybrid Mode." Hybrid Mode has a significantly better design, but is not as widely implemented.

An alternative to IPsec is to allow only applications with strong built-in cryptographic systems. Web-based systems can be secured with the secure socket layer (SSL). Host logins can be secured with SSH. SSH can also be used to secure many types of TCP-based network traffic, although the port-forwarding configuration may be too complex for many users. Some environments may have already deployed a framework such as Kerberos for application layer security, in which case it can probably be extended to wireless stations without great difficulty.