39 WLAN Security

Learning Objectives

• To know about importance of wireless LAN Security

•  To learn about WEP mechanisms

• To learn about Authentication and Key Management

•  To learn about 802.11i Data Transfer Techniques

40.1 Introduction

802.11-based devices communicate with one another using radio frequencies (RFs) as the carrier signal for data. The data is broadcast from the sender in the hopes that the receiver is within RF range. The drawback to this mechanism is that any other station within range of the RF also receives the data.

Without a security mechanism of some sort, any 802.11 station can process the data sent on a WLAN, as long as that receiver is in RF range. To provide a minimum level of security in a WLAN, you need two components:

• To decide who or what can use a WLAN— This requirement is satisfied by authentication mechanisms for LAN access control.

• To decide who or what can use a WLAN— This requirement is satisfied by authentication mechanisms for LAN access control.

As Figure 40-1 depicts, wireless security consists of both authentication and encryption. Neither mechanism alone is enough to secure a wireless network.

The 802.11 specification defines Open and Shared Key authentication and WEP to provide device authentication and data privacy, respectively. The Open and Shared Key algorithms both rely on WEP encryption and possession of the WEP keys for access control. Because of the importance of WEP in 802.11 security, the following section focuses on the basics of encryption and ciphers in general.

40.2 WEP – Encryption in the 802.11 Standard

The 802.11 specification provides data privacy with the WEP algorithm. WEP is based on the RC4 symmetric stream cipher. The symmet ric nature of RC4 requires that matching WEP keys, either 40 or 104 bits in length, must be statically configured on client devices and access points (APs). WEP was chosen primarily because of its low computational overhead. Although 802.11-enabled PCs are common today, this situation was not the case back in 1997. The majority of WLAN devices were application-specific devices (ASDs).

Examples of ASDs include barcode scanners, tablet PCs, and 802.11-based phones. The applications that run on ASDs generally do not require much computational power, so as a result, ASDs have meager CPUs. WEP is a simple-to-implement algorithm that you can write in as few as 30 lines of code, in some cases. The low overhead incurred by WEP made it an ideal encryption algorithm to use on ASDs.

To avoid the ECB mode of encryption, WEP uses a 24-bit IV, which is concatenated to the key before being processed by the RC4 cipher. Figure 40-2 shows a WEP-encrypted frame, including the IV.

The IV must change on a per-frame basis to avoid IV collisions. IV collisions occur when the same IV and WEP key are used, resulting in the same key stream beingused to encrypt a frame. This collision gives attackers a better opportunity to guess the plaintext data by seeing similarities in the ciphertext. The point of using an IV is to prevent this scenario, so it is important to change the IV often. Most vendors offer per-frame IVs on their WLAN devices.

The 802.11 specification requires that matching WEP keys be statically configured on both client and infrastructure devices. You can define up to four keys on a device, but you can use only one at a time for encrypting outbound frames.

WEP encryption is used only on data frames and during Shared Key authentication. WEP encrypts the following fields of an 802.11 data frame:

• The data or payload
• The integrity check value (ICV)

All other fields are transmitted without encryption. The IV must be sent unencrypted within the frame so that the receiving station can use it to properly decrypt the payload and ICV.

Figure 40-3 details the process for encryption, transmission, receipt, and decryption of a WEP encrypted data frame.

In addition to data encryption, the 802.11 specification provides for a 32-bit value that functions as an integrity check for the frame. This check tells the receiver that the frame has arrived without being corrupted during transmission. It augments the Layer 1 and Layer 2 frame check sequences (FCSs), which are designed to check for transmission-related errors.

The ICV is calculated against all fields in the frame using a cyclic redundancy check (CRC)-32 polynomial function. The sender calculates the values and places the result in the ICV field.

The ICV is included in the WEP-encrypted portion of the frame, so it is not plainly visible to eavesdroppers. The frame receiver decrypts the frame, calculates an ICV value, and compares what it calculates against what has arrived in the ICV field. If the values match, the frame is considered to be genuine and untampered with. If they don’t match, the frame is discarded. Figure 40-4 diagrams the ICV operation.

40.3 Authentication Mechanisms in the 802.11 Standard

The 802.11 specification stipulates two mechanisms for authentication of WLAN clients:

• Open authentication
• Shared Key authentication

Open authentication is a null authentication algorithm. The AP grants any request for authentication. It might sound pointless at first to have such an algorithm defined, but Open authentication has its place in 802.11 network authentication.

The requirements for authentication allow devices to quickly gain access to the network. Access control in Open authentication relies on the preconfigured WEP key on the client and AP. The client and AP must have matching WEP keys to enable them to communicate. If the client and AP do not have WEP enabled, there is no security in the BSS. Any device can join the BSS and all data frames are transmitted unencrypted.

After Open authentication and the association process, the client can begin transmitting and receiving data. If the client is configured with a key that differs from the key on the AP, the client will be unable to encrypt or decrypt data frames correctly, and the frames will be discarded by both the client and the AP. This process essentially provides a means of controlling access to the BSS. It is illustrated in Figure 40-5.

Unlike Open authentication, Shared Key authentication requires that the client station and the AP have WEP enabled and have matching WEP keys. The following summarizes the Shared Key authentication process:

1. The client sends an authentication request for Shared Key authentication to the AP.

2. The AP responds with a clear text challenge frame.

3. The client encrypts the challenge and responds back to the AP.

4. If the AP can correctly decrypt the frame and retrieve the original challenge, the client is sent a success message.

5. The client can access the WLAN.

The premise behind Shared Key authentication is similar to that of Open authentication with WEP keys as the access control means. The client and AP must have matching keys. The difference between the two schemes is that the client cannot associate in Shared Key authentication unless the correct key is configured. Figure 4-6 shows the Shared Key authentication process.

40.3.1 MAC Address Authentication

MAC address authentication is not specified in the 802.11 specification, but it is supported by many vendors. MAC address authentication verifies the client’s MAC address against a locally configured list of allowed addresses or against an external authentication server, as shown in Figure 4-7. MAC authentication augments the Open and Shared Key authentications provided by 802.11, potentially reducing the likelihood of unauthorized devices accessing the network.

For example, a network administrator might want to limit a particular AP to just three specific devices. If all stations and APs in the BSS have the same WEP keys, it is difficult to use Open or Shared Key authentication to facilitate this scenario. The administrator can configure MAC address authentication to augment 802.11 authentication.

40.3.2 The Authentication Framework

The authentication framework in 802.11 is the 802.11 authentication management frame. The authentication frame facilitates Open and Shared Key authentication algorithms, yet the frame itself does not possess the ability to authenticate a client. Because the shortcomings of 802.11 authentication have already been highlighted, it is important to understand what is needed to provide secure authentication in a WLAN.

802.11 is missing some key components to provide effective authentication:

• Centralized, user-based authentication
• Dynamic encryption keys
• Encryption key management
• Mutual authentication

User-based authentication is critical for network security. Device-based authentication, such as Open or Shared Key authentication, does not prevent unauthorized users from using authorized devices. Also, logistical issues, such as lost or stolen devices and employee termination, can force network administrators to manually rekey all 802.11 APs and clients.

Centralized, user-based management via an authentication, authorization, and accounting (AAA) server, such as a RADIUS, lets you allow or disallow specific users, regardless of the specific devices they use.

The requirement for user-based authentication has a positive side effect: user-specific encryption keys. Authentication types that support the creation of dynamic encryption keys fit well into the WLAN security and management model. Per user, dynamic keys relieve the network administrator from having to statically manage keys. Encryption keys are dynamically derived and discarded as the user authenticates and disconnects from the network. Should you need to remove a user from the network, you only need to disable her account to prevent her access.

Mutual authentication is two-way authentication. The “two-way” nature comes from not only the network authenticating the client, but also the client authenticating the network. In Open and Shared Key authentication, the AP or network authenticates the client. The client does not know for sure that the AP or network is valid because no mechanism is defined in the 802.11 specification to allow the client to authenticate the network. As a result, a rogue AP or rogue client station can pose as a valid AP and subvert the data on the client’s machine. Figure 40-8 diagrams one-way authentication versus mutual authentication.

802.11 WLAN vendors and the IEEE understand the need to augment and replace existing security mechanisms, both in authentication and encryption. Work is currently underway in task group I of the 802.11 working group, and after the changes are complete, the security specifications will be ratified as the 802.11i specification.

The IEEE has addressed the shortcomings of 802.11 authentication by incorporating the 802.1X authentication framework. 802.1X itself is an IEEE standard that provides all 802 link layer topologies with extensible authentication, normally seen in higher layers. 802.1X is based on a Point-to-Point Protocol (PPP) authentication framework known as the Extensible Authentication Protocol (EAP). In oversimplified terms, 802.1X encapsulates EAP messages for use at Layer 2. 802.11i incorporates the 802.1X authentication framework requiring its use for user-based authentication. Figure 40-9 illustrates 802.1X message exchanges during Authentication process.

40.4 802.11i Data Transfer Techniques in WLAN

40.4.1 Data Privacy

Temporal Key Integrity Protocol (TKIP) as part of 802.11i (and WPA) uses many key functions of WEP to maintain client investment in existing 802.11 equipment and infrastructure but fixes several of the vulnerabilities to provide effective data-frame encryption.

The key enhancements contained with TKIP are

• Per-frame keying – The WEP key is quickly changed on a per-frame basis.
• Message integrity check (MIC) – A check provides effective data-frame integrity to prevent frame tampering and frame replay.

The Fluhrer, Mantin, and Shamir paper describes the vulnerability of RC4 as it is implemented in WEP. Attacks that leverage this weak IV vulnerability, such as AirSnort, rely on collecting several data frames with encrypted data using weak IVs. The easiest way to mitigate these attacks is to change the WEP key used between the client and AP before an attacker can collect enough frames to derive key bytes.

The IEEE has adopted a scheme known as per-frame keying. (It is also known as per-packet keying and fast packet keying.) The premise behind per-frame keying is that the IV, the transmitter MAC address, and the WEP key are processed together via a two-phase mixing function. The output of the function matches the standard 104-bit WEP key and 24-bit IV.

The IEEE is also proposing that the 24-bit IV be increased to a 48-bit IV. Subsequent sections detail why the IV expansion is necessary. Figure 40-10 depicts a sample 48-bit IV and how the IV is broken apart for use in per-frame keying.

The following steps outline the process for per-frame keying:

1. The base WEP key (derived from 802.1X authentication) is mixed with the most significant 32 bits (a 32-bit number ranges from 0 to 4,294,967,295) of the 48-bit IV and the MAC address of the transmitter. The output is called a phase 1 key. This process allows the phase 1 key to be cached and also places directionality into the key (see Figure 40-11).

2. The phase 1 key is again mixed with the IV and the transmitter MAC address to yield the per-frame key.

3. The IV used for frame transmission is only 16 bits (a 16-bit number ranges from 0 to 65,535). The remaining 8 bits is a fixed value used as a placeholder.

4. The per-frame key is used to WEP-encrypt the data frame.

5. When the 16-bit IV space is exhausted, the phase 1 key is discarded, and the 32 most significant bits are incremented by 1. (If the phase 1 IV was 12, it increments to 13.)

6. The per-frame key is recalculated as in Step 2.

The per-frame key is only valid when the 16-bit IV values have not been used. If an IV value is used twice, an IV collision occurs, which gives attacks an opportunity to derive the key stream. To avoid IV collision, the phase 1 key is recalculated by incrementing the most significant 32 bits of the IV by 1 and recalculating the per-frame key.

40.4.2 Data Integrity

The MIC is a feature used to augment the ineffective ICV of the 802.11 standard. The IEEE has proposed a specific algorithm, known as Michael, to augment the ICV function in the encryption of 802.11 data frames.

The MIC has a unique key that differs from the key used to encrypt data frames. This unique key is mixed with the destination MAC address and the source MAC address from the frame as well as the entire unencrypted data payload portion of the frame. Figure 40-12 illustrates the Michael MIC algorithm.

The entire TKIP encryption mechanism is detailed in the following steps:

1.  The per-frame keying algorithm derives a per-frame key (see Figure 40-13).

2.  The MIC algorithm generates a MIC for the entire frame.

3.  The frame is fragmented according to MAC settings for fragmentation.

4. The per-frame key encrypts the frame fragments.

5. The encrypted fragments are transmitted.

Similar to the TKIP encryption process (see Figure 40-14), the following steps detail the

TKIP decryption process:

1.      The phase 1 key is precomputed.

2.      The phase 2 per-frame key is calculated based on the IV from the incoming WEP frame fragment.

3.      If the IV arrives out of order, the frame is discarded.

4.      The frame fragment is decrypted and the ICV check is done.

5.      If the ICV fails, the frame is discarded.

6.      The decrypted frame fragments are reassembled into the original data frame.

7.      The receiver calculates the MIC value and compares it to what is in the MIC field of the frame.

8.      If the values match, the frame is processed by the receiver.

9.      If the values do not match, the frame has a MIC failure and the receiver initiates MIC countermeasures.

Broadcast and multicast frames use the group key hierarchy. The group master key (GMK) is at the top of the hierarchy and is derived on the AP. GMK derivation is based on a PRF that outputs a 256-bit GMK. The inputs into the PRF-256 are a cryptographically secure random number (or nonce), a text string, the MAC address of the AP, and the time in network time protocol (NTP) format. Figure 40-15 illustrates the group key hierarchy.

The GMK, a text string, the AP MAC address, and the GNonce (a value taken from the AP key counter) are concatenated and processed via a PRF, which outputs a 256-bit group transient key (GTK). The GTK is divided into a 128-bit broadcast/multicast encryption key, a 64-bit transmit MIC key, and a 64-bit MIC receive key. The keys encrypt and decrypt broadcast and multicast frames in exactly the same manner as unicast keys derived from the PMK.

The client is updated with the group encryption keys via an EAPoL-Key message. The AP sends the client the EAPoL message encrypted with the client’s unicast encryption key. The group keys are purged and regenerated every time a station disassociates or deauthenticates the BSS. Also, if a MIC failure occurs, one of the countermeasures is to purge all the keys for the impacted receiver, and this purge includes the group keys.

40.4.3 AES Encryption

WEP encryption and 802.11 authentication are known to be weak. The IEEE and WPA are enhancing WEP with TKIP and providing robust authentication options with 802.1X to make 802.11-based WLANs secure. At the same time, the IEEE is also looking to stronger encryption mechanisms. The IEEE has adopted the AES to the data-privacy section of the proposed 802.11i standard. WPA does not include support for AES encryption. Later versions of WPA are likely to be released to align with 802.11i for interoperable AES encryption support.

The AES is the next generation encryption function approved by the National Institute of Standards and Technology (NIST). NIST solicited the cryptography community for new encryption algorithms. The algorithms had to be fully disclosed and available royalty free.

Candidates were judged on cryptographic strength as well as practical implementation. The finalist, and the adopted method, is also known as the Rijndael algorithm. Like most ciphers, AES requires a feedback mode to avoid the risks associated with ECB mode. The IEEE has designed a mode for AES tailored to the needs of WLANs.The mode is known as Cipher Block Chaining Counter Mode (CBC-CTR) with Cipher Block Chaining Message Authenticity Check (CBC-MAC), collectively known as AES-CCM. CCM mode is the combination of CBC-CTR encryption mode and the CBC-MAC message authenticity algorithm. The functions are combined to provide encryption and message integrity in one solution.

CBC-CTR encryption operates by using a counter to augment the key stream. The counter increments by 1 after encrypting each block. This process provides a unique key stream for each block. The plaintext frame is fragmented into 16-byte blocks. As each block is encrypted, the counter increments by 1, until all blocks are encrypted. The counter resets for each new frame.CBC-MAC operates by using the result of CBC encryption over frame length, destination address, source address, and data. The resulting 128-bit output is truncated to 64 bits for use in the transmitted frame.

AES-CCM uses cryptographically known functions but has the overhead of requiring two operations for encryption and message integrity. This process is computationally expensive and adds a significant amount of overhead to the encryption process.

40.4.4 CCMP

CCMP uses CCM that combines CTR for data confidentiality and CBC-MAC for authentication and integrity. CCM protects the integrity of both the MPDU data field and selected portions of the IEEE 802.11 MPDU header. CCMP is based on AES processing and uses a 128-bit key and a 128-bit block size. CCMP uses CCM with the following two parameters:

M = 8; indicating that the MIC is 8 octets (eight bytes).

L = 2; indicating that the Length field is 2 octets.

A CCMP Medium Access Control Protocol Data Unit (MPDU) comprises five sections. The first is the MAC header which contains the destination and source address of the data packet. The second is the CCMP header which is composed of 8 octets and consists of the packet number (PN), the Ext IV, and the key ID. The packet number is a 48-bit number stored across 6 octets. The PN codes are the first two and last four octets of theCCMP header and are incremented for each subsequent packet. Between the PN codes are a reserved octet and a Key ID octet. The Key ID octet contains the Ext IV (bit 5), Key ID (bits 6-7), and a reserved subfields (bits 0-4).

CCMP uses these values to encrypt the data unit and the MIC. The third section is the data unit which is the data being sent in the packet. Lastly are the Message Integrity Code (MIC) which protects the integrity and authenticity of the packet and the frame check sequence (FCS) which is used for error detection and correction. Of these sections only the data unit and MIC are encrypted.

CCMP  is  the  standard  encryption  protocol  for  use  with  the Wi-Fi  Protected  Access II (WPA2) standard and is much more secure than the Wired Equivalent Privacy (WEP) protocol and Temporal Key Integrity Protocol (TKIP) of Wi-Fi Protected Access (WPA). CCMP provides the following security services:

• Data confidentiality; ensures only authorized parties can access the information
• Authentication; provides proof of genuineness of the user
• Access control in conjunction with layer management