Anyone developing wireless LAN (WLAN) systems knows the security problem created by the wired equivalency protocol (WEP). The bigger issue designers must wrestle with is how to solve the problems caused by WEP.
Fortunately, the IEEE 802.11 committee is helping out. Through the work in its "i" working group, the 802.11 committee is producing a detailed specification that will dramatically enhance the security features provided in a WLAN system.
After more than two years of work, the 802.11i committee is coming closer to having a unified spec in the market. In this article, we'll examine the key technical elements that have been defined by the spec to date. While these elements might change, the information below will provide insight into some of the changes that 802.11i promises to deliver to the market.
Three Pieces, Two layers
The 802.11i specification can be viewed as consisting of three main pieces organized into two layers. On the lower level are improved encryption algorithms in the form of the temporal key integrity protocol (TKIP) and the counter mode with CBC-MAC protocol (CCMP). Both of these encryption protocols provide enhanced data integrity over WEP, with TKIP being targeted at legacy equipment and CCMP being targeted at future WLAN equipment.
Above TKIP and CCMP sits 802.1x, a standard for port based access control developed by a different body within the IEEE 802 organization. As used in 802.11i, 802.1x provides a framework for robust user authentication and encryption key distribution, both features originally missing from the original 802.11 standard.
When looking at 802.11i, it's important to understand that the three pieces discussed above work together to form an overall security system. But to understand how each of these pieces fit together, we must first understand how they operate individually. So, let's take a look at each piece in more detail, starting with 802.1x.
The Basics on 802.1x
IEEE 802.1x (http://www.ieee802.org/1/pages/802.1X.html) is a standard for port based network access control. The standard can be applied to both wired and wireless networks and provides a framework for user authentication and encryption key distribution. It can be used to restrict access to a network until the user has been authenticated by the network. In addition, 802.1x is used in conjunction with one of a number of upper layer authentication protocols (discussed later) to perform verification of credentials and generation of encryption keys.
There are three primary roles played by enterprise equipment in an 802.1x system. The authenticator (typically the AP in 802.11) is the port that enforces the authentication process and routes the traffic to the appropriate entities on the network. The supplicant (typically the client device in 802.11) is the port requesting access to the network.
In the enterprise, the authentication server (AS) is a third entity that performs the actual authentication of the credentials supplied by the supplicant. The AS is typically a separate entity on the wired side of the network, but could also reside directly in the authenticator. The most common type of authentication server in use today to authorize remote users is Radius although other authentication services could be used. The particular authentication server to be used is not specified in the 802.1x standard.
The Controlled/Uncontrolled Port Concept
802.1x operation can be understood using the concept of a controlled port and uncontrolled port as show the 802.11 context highlighted in Figure 1.
Click here for Figure 1
Figure 1: 802.1x state before (left) and after (right) successful mutual authentication.
The controlled and uncontrolled ports are logical entities and are the same physical connection to the network. Whether a frame traveling through the access point (AP) is routed through the controlled or uncontrolled port is determined by the authentication state of the client computer.
Prior to authentication by the AS the AP will only allow the client to communicate with the AS. After successful authentication by the AS, the AP will also allow the client to access other services available on the network.
The actual authentication data exchanged is a function of the upper layer authentication protocol used (discussed below) and the message protocol and routing of these messages is controlled by 802.1x. It's important to note that a mutual authentication process is used and both the network and the client are authenticated to each other. As part of the authentication process, the media access control (MAC) level encryption keys used by the chosen encryption protocol will be generated. 802.1x is then used to plumb the encryption keys down to the MAC on both the AP and the client computer.
In 802.1x-enabled WLAN systems, two sets of keys are generated, session keys (also referred to as pairwise keys) and group keys (also referred to as groupwise keys). Group keys are shared amongst all the clients connected to the same AP and are used for multi-cast traffic. Session keys are unique to each association between an individual client and the AP and create a private virtual port between a client and the AP.
802.1x enhances the enterprise security model by providing the following improvements over standard WEP:
- It provides support for a centralized security management model.
- The primary encryption keys are unique to each station so the traffic on any single key is significantly reduced.
- When used with an AS, the encryption keys are generated dynamically and don't require a network administrator for configuration or intervention by the user (this is analogous to the use of dynamic IP addresses versus static IP addresses on the network).
- It provides support for strong upper layer authentication.
802.1x in the Home/Small Business
In the home and small business environment most users are not expected to have a Radius server available for authentication. In this case, the 802.11i standard uses 802.1x in a pre-shared key configuration, however most of the previous concepts and operation remain the same.
When operating with AS support, a master key, called the pairwise master key (PMK), is generated via the exchange between the client and the AS. The PMK is used as source material for generation of the lower level keys used by the MAC layer encryption. When an AS is not present, the PMK is manually entered into each device in the WLAN and serves as a pre-shared key for authentication and source material of the lower level encryption keys. The user model is more analogous to standard WEP in this case since it requires manual distribution and configuration of a shared secret; however this should be adequate for most small deployments.
When used in pre-shared key mode, session keys are still provided and the improved encryption methods discussed below are fully supported. It's important to note that upper-layer authentication is not supported and the security of the network is broken if the shared key is ever compromised. In many small deployment scenarios, these tradeoffs are likely acceptable in exchange for ease of deployment and configuration of the Wi-Fi equipment.
Improved Encryption
The 802.11i standard provides two improved encryption algorithms to replace WEP. TKIP and CCMP are both called out in the standard and the standard is written in such a way that it is extensible to support the addition of new encryption protocols should they be required in the future. A WLAN can support the simultaneous use of more than one encryption protocol and the client and AP will use the highest level of security that both can mutually support.
However, a true 802.11i system uses either the TKIP or CCMP protocol for all equipment. A WLAN that supports the simultaneous use of WEP along with the CCMP or TKIP encryption protocols is called a transitional network and is assumed to be a temporary configuration for the purposes of converting all clients to a TKIP- or CCMP-based security solution.
Let's take a closer look at the two encryption algorithms. We'll start with TKIP.
Understanding TKIP
TKIP was designed to address all the known attacks and deficiencies in the WEP algorithm while still maintaining backward compatibility with legacy hardware. It was designed to be made available as a firmware or software upgrade to existing hardware so that users would be able to upgrade their level of security without replacing existing equipment or purchasing new hardware. TKIP provides an upgrade path by offering an additional protocol or a wrapper around WEP.
TKIP is comprised of the following elements:
- A message integrity code (MIC) provides a keyed cryptographic checksum using the source and destination MAC addresses and the plaintext data of the 802.11 frame (or MAC service data unit (MSDU) in IEEE nomenclature). This protects against forgery attacks.
- Countermeasures to bound the probability of successful forgery and the amount of information that an attacker can learn about a particular key.
- A 48-bit IV and an IV sequence counter to address replay attacks. Fragmented packets (MAC protocol data units (MPDUs) in IEEE nomenclature) received out of order are dropped by the receiver.
- Per packet key mixing of the IV is used to break up the correlation used by weak key attacks.
The structure of a TKIP encrypted MPDU is shown in Figure 2. As mentioned previously, TKIP uses an extended 48-bit IV called the TKIP sequence counter (TSC). The use of a 48-bit TSC extends the life of the temporal key (discussed below) and eliminates the need to re-key the temporal key during a single association. Since the TSC is updated with each packet, 248 packets can be exchanged using a single temporal key before key reuse would occur. Under steady, heavy traffic conditions, it would take approximately 100 years for key reuse to occur.
Click here for Figure 2
Figure 2: MPDU format after TKIP encryption.
The TSC is constructed from the first and second bytes from the original WEP IV and the 4 bytes provided in the extended IV. TKIP extends the length of a WEP encrypted MPDU by 12 bytes—4 bytes for the extended IV information and 8 bytes for the MIC.
The TKIP encapsulation process is shown in Figure 3. Temporal and MIC keys are used, which are derived from the PMK generated as part of the 802.1X exchange discussed previously.
Click here for Figure 3
Figure 3: Diagram depicting the TKIP encapsulation process.
The temporal key, transmitter address, and TSC are combined in a two-phase key mixing function to generate a per packet key to be used to seed the WEP engine for encryption. The per packet key is 128 bits long and is split into a 104-bit RC4 key and a 24-bit IV for presentation to the WEP engine.
The MIC is calculated over the source and destination MAC addresses and the MSDU plaintext after being seeded by the MIC key and the TSC. By computing the MIC over the source and destination addresses, the packet data is keyed to the sender and receiver preventing attacks based on packet forgery.
The MIC function, nicknamed Michael, is a one-way cryptographic hash function, not a simple CRC-32 as is used in computing the WEP integrity check vector (ICV). This makes it much more difficult for an attacker to successfully intercept and alter packets in a denial of service attack. If necessary, the MSDU is fragmented into MPDUs, incrementing the TSC for each fragment, before encryption by the WEP engine.
The decapsulation process is essentially the same as the process illustrated in Figure 3 with the following exceptions. After recovery of the TSC from the received packet, the TSC is examined to ensure that the packet just received has a TSC value greater than the previously received packet. If it does not, the packet is discarded in order to prevent potential replay attacks.
Also, after the MIC value has been calculated based on the received and decrypted MSDU, the calculated MIC value is compared to the received MIC value. If the MIC values do not match, the MSDU is discarded and countermeasures are then invoked. These countermeasures consist primarily of rekeying the temporal key while controlling the rate at which this happens and sending alerts to network administration for follow-up.
Digging into CCMP
In addition to TKIP encryption, the 802.11i draft defines a new encryption method based on the advanced encryption standard (AES). AES based encryption can be used in a number of different modes or algorithms. The mode that has been chosen for 802.11 is the counter mode with CBC-MAC (CCM). The counter mode delivers data privacy while the CBC-MAC delivers data integrity and authentication.
AES is a symmetric iterated block cipher meaning that the same key is used for both encryption and decryption, multiple passes are made over the data for encryption, and the clear text is encrypted in discrete fixed length blocks. The AES standard uses 128-bit blocks for encryption, and for 802.11 the encryption key length is also fixed at 128 bits. Unlike TKIP, CCMP is mandatory for anyone implementing 802.11i.
Figure 4 shows the format of an AES encrypted MPDU. The packet is expanded by 16 bytes over an unencrypted frame and is identical to a TKIP frame with the exception of the legacy WEP ICV included in a TKIP frame.
Click here for Figure 4
Figure 4: MPDU format after CCMP encryption
Like TKIP, CCMP also uses a 48-bit IV called a packet number (PN). The packet number is used along with other information to initialize the AES cipher for both the MIC calculation and the frame encryption.
Figure 5 shows the CCMP encapsulation process.
Click here for Figure 5
Figure 5: Diagram of the CCMP encapsulation process.
The AES encryption blocks in both the MIC calculation and the packet encryption use the same temporal encryption key (K in Figure 5). As with TKIP, the temporal key is derived from the master key that was derived as part of the 802.1X exchange discussed previously.
The MIC calculation and encryption proceed along parallel paths as shown in Figure 5. The MIC calculation is seeded with an IV formed by a flag value, the PN, and other data pulled from the header of the frame. This IV is fed into an AES block and its output is XORed with select elements from the frame header, which is then fed into the next AES block. This process continues over the remainder of the frame header and down the length of the packet data to compute a final 128-bit CBC-MAC value. The upper 64 bits of this MAC are extracted and used in the final MIC appended to the encrypted frame.
The encryption process is seeded by a counter preload also formed from the PN, a flag value, data from the frame header, and a counter value which is initialized to 1. This preload value is fed to the AES block and its output is XORed with 128 bits of clear text from the unencrypted frame. The counter value is incremented by one and this process is repeated for the next block of 128 bits of clear text. This process continues down the length of the frame until the entire frame has been encrypted. The final counter value is set to 0 and input to an AES block whose output is XORed with the MIC value computed previously before appending to the end of the encrypted frame for transmission.
The CCMP decapsulation process is not shown but is essentially the reverse of the encapsulation process of Figure 5. A final step is added to compare the value of the computed MIC to that received before the decrypted frame is passed on by the MAC.
Authentication Protocols
Upper layer authentication (ULA) protocols are not specified in the 802.11i standard, but will be an integral part of the security system in the majority of deployments. ULA protocols were not included in the 802.11i standard because as the name implies, they operate at higher layers of the OSI network layer model and are therefore outside the scope of the 802.11 standard that operates at the physical and MAC layers only.
There are a number of popular ULA protocols in use today, primarily in the enterprise environment where the network infrastructure is in place to support their use. The ULA protocols are used to provide a mutual authentication exchange between the client and an authentication server residing somewhere on the network and to generate session keys to be used between the client and the AP over the wireless link.
The ULAs work in conjunction with 802.1x, where 802.1x is used to enforce their use and route the messages properly and the ULA protocols define the actual authentication exchange that takes place. In most cases a Radius server will be used for authentication since many companies are already using Radius for their dial-up users.
Some of the more popular authentication protocols include: the extensible authentication protocol with transport layer security (EAP-TLS), the protected extensible authentication protocol (PEAP), the extensible authentication protocol with tunneled transport layer security (EAP-TTLS), and the lightweight extensible authentication protocol (LEAP).
EAP-TLS is a certificate-based authentication protocol and is supported natively in Windows XP. It requires initial configuration by a network administrator to establish the certificate(s) on the user's machine and the authentication server, but no user intervention is required thereafter. The certificates are digital signatures that are used in conjunction with public key encryption techniques to verify the identity of the client.
During an EAP-TLS exchange, the client and authentication server exchange credentials and random data in order to simultaneously synthesize the encryption keys at both ends of the link. Once this has been completed, the server sends the encryption keys to the AP through a secure Radius channel and the AP exchanges messages with the client to plumb the encryption keys down to the MAC encryption layer.
PEAP is an IETF draft standard and can be used to provide a secure password based authentication mechanism. Although it has not been implemented in any products to date, this is likely to change in the near future.
In a PEAP exchange, only the authentication server is required to have a certificate. After the initial communication with the authentication server, the public key from the AS certificate is sent to the client computer. The client computer then generates a master encryption key and encrypts this key using the AS's public key and sends the encrypted key to the AS.
Now that the master key is on both ends of the channel, this key can be used as source material to establish a secure tunnel between the AS and the client over which any subsequent authentication method can be used to authenticate the client computer to the AS. In many cases is it expected that this will be some form of a password based authentication protocol.
EAP-TTLS is also an IETF draft standard and can be used to provide password-based authentication of the client computer. EAP-TTLS is very similar in operation to PEAP and has been implemented in some Radius server and supplicant software designed for use in 802.11 WLAN networks.
LEAP is a proprietary standard developed by Cisco Systems and was designed to be portable across a variety of wireless platforms. It has gained popularity due to the fact that it was the first, and for a long time, the only password based authentication scheme and it also provided this support across several different client operating system platforms.
LEAP is based on a straightforward challenge-password hash exchange where the authentication server issues a challenge to the client and then the client returns the password to the authentication server after first hashing it with the challenge text sent by the AS.
Combo Thinking
One of the mistakes that designers can make when evaluating the individual security elements discussed above is to consider them as individual security silos. It's important to understand that all the 802.11i pieces described above work together to form an overall security system. Taken individually and out of the context of the overall system, any single piece could be shown to have security weaknesses.
About the Author
Dennis Eaton is a senior product manager at Intersil Corporation. He holds engineering degrees from Michigan State University and the University of Central Florida. Dennis can be reached at deaton@intersil.com.
