802.11 is a set of standards carrying out wireless local area network (WLAN) computer communication in the 2.4, 3.6 and 5 GHz frequency bands. They are created and maintained by the IEEE LAN/MAN Standards Committee (IEEE 802). The base current version of the standard is IEEE 802.11-2007.
IEEE 802.11i enhances IEEE 802.11-1999 by providing a Robust Security Network (RSN) with two new protocols, the 4-Way Handshake and the Group Key Handshake. These utilize the authentication services and port access control described in IEEE 802.1X to establish and change the appropriate cryptographic keys. The RSN is a security network that only allows the creation of robust security network associations (RSNAs), which are a type of association used by a pair of stations (STAs) if the procedure to establish authentication or association between them includes the 4-Way Handshake. It also provides two RSNA data confidentiality and integrity protocols, Temporal Key Integration Protocol (TKIP) and Counter Mode (CTR) with Cipher-Block Chaining Message Authentication Code (CBC-MAC) Protocol (CTR with CBC-MAC (CCMP)), with implementation of CCMP being mandatory.
The Four-Way Handshake
The authentication process leaves two considerations: the access point (AP) still needs to authenticate itself to the client station (STA), and keys to encrypt the traffic need to be derived. The earlier Extensible Authentication Protocol (EAP) exchange has provided the shared secret key Pairwise Master Key (PMK). This key is, however, designed to last the entire session and should be exposed as little as possible. Therefore the four-way handshake is used to establish another key called the Pairwise Transient Key (PTK). The PTK is generated by concatenating the following attributes: PMK, AP nonce (ANonce (AP number used once)), STA nonce (SNonce), AP MAC address, and STA MAC address. The product is then put through a cryptographic hash function.
The handshake also yields the GTK (Group Temporal Key), used to decrypt multicast and broadcast traffic. The actual messages exchanged during the handshake are depicted in the figure and explained below:
Figure 1: 4-way handshake message exchange
1. The AP sends a nonce-value to the STA (ANonce). The client now has all the attributes to construct the PTK.
2. The STA sends its own nonce-value (SNonce) to the AP together with a MIC (Message Integrity Code), including authentication, which is really a Message Authentication and Integrity Code: (MAIC).
3. The AP sends the GTK and a sequence number together with another MIC. This sequence number will be used in the next multicast or broadcast frame, so that the receiving STA can perform basic replay detection.
4. The STA sends a confirmation to the AP.
All the above messages are sent as EAPOL (Extensible Authentication Protocol over LAN's (Local Area Networks)) -Key frames.
As soon as the PTK is obtained it is divided into five separate keys:
PTK (Pairwise Transient Key - 64 bytes)
16 bytes of EAPOL-Key Confirmation Key (KCK)- Used to compute MIC on WPA (Wi-Fi Protected Acces) EAPOL Key message
16 bytes of EAPOL-Key Encryption Key (KEK) - AP uses this key to encrypt additional data sent (in the 'Key Data' field) to the client (for example, the RSN IE or the GTK)
16 bytes of Temporal Key (TK) - Used to encrypt/decrypt Unicast data packets
8 bytes of Michael MIC Authenticator Tx Key - Used to compute MIC on unicast data packets transmitted by the AP
8 bytes of Michael MIC Authenticator Rx Key - Used to compute MIC on unicast data packets transmitted by the station
The Michael MIC Authenticator Tx/Rx Keys provided in the handshake are only used if the network is using TKIP to encrypt the data.
The Group Key Handshake
The GTK used in the network may need to be updated due to the expiry of a preset timer. When a device leaves the network, the GTK also needs to be updated. This is to prevent the device from receiving any more multicast or broadcast messages from the AP.
To handle the updating, 802.11i defines a Group Key Handshake that consists of a two-way handshake:
The AP sends the new GTK to each STA in the network. The GTK is encrypted using the KEK assigned to that STA, and protects the data from tampering, by use of a MIC.
The STA acknowledges the new GTK and replies to the AP.
GTK ( Groupwise Transient Key - 32 bytes)
16 bytes of Group Temporal Encryption Key - Used to encrypt Multicast data packets
8 bytes of Michael MIC Authenticator Tx Key - Used to compute MIC on Multicast packet transmitted by AP
8 bytes of Michael MIC Authenticator Rx Key - This is currently not used as stations do not send multicast traffic
The Michael MIC Authenticator Tx/Rx Keys provided in the handshake are only used if the network is using TKIP to encrypt the data.
Temporal Key Integration Protocol (TKIP)
The TKIP is a cipher suite enhancing the WEP protocol on pre-RSNA hardware. TKIP modifies WEP as follows:
1. A transmitter calculates a keyed cryptographic message integrity code (MIC) over the MSDU (MAC (Medium Access Control) Service Data Unit) SA (Source Address) and DA (Destination Address), the MSDU priority, and the MSDU plaintext data. TKIP appends the computed MIC to the MSDU data prior to fragmentation into MPDUs. The receiver verifies the MIC after decryption, Integrity Check Value (ICV) checking, and defragmentation of the MPDUs into an MSDU and discards any received MSDUs with invalid MICs. TKIP's MIC provides a defense against forgery attacks.
2. Because of the design constraints of the TKIP MIC, it is still possible for an adversary to compromise message integrity; therefore, TKIP also implements countermeasures. The countermeasures bound the probability of a successful forgery and the amount of information an attacker can learn about a key.
3. TKIP uses a per-MPDU TKIP sequence counter (TSC) to sequence the MPDUs it sends. The receiver drops MPDUs received out of order, for example, not received with increasing sequence numbers. This provides replay protection. TKIP encodes the TSC value from the sender to the receiver as a WEP IV (Initialization Vector) and extended IV.
4. TKIP uses a cryptographic mixing function to combine a temporal key, the Transmission Address (TA), and the TSC (TKIP Sequence Counter) into the WEP seed. The receiver recovers the TSC from a received MPDU and utilizes the mixing function to compute the same WEP seed needed to correctly decrypt the MPDU. The key mixing function is designed to defeat weak-key attacks against the WEP key.
TKIP Cryptographic Encapsulation
TKIP enhances the WEP cryptographic encapsulation with several additional functions, as depicted in Figure 2.
Figure 2: TKIP encapsulation block diagram
1. TKIP MIC computation protects the MSDU Data field and corresponding SA, DA, and Priority fields. The computation of the MIC is performed on the ordered concatenation of the SA, DA, Priority, and MSDU Data fields. The MIC is appended to the MSDU Data field. TKIP discards any MIC padding prior to appending the MIC.
2. If needed, IEEE Standard 802.11 fragments the MSDU with MIC into one or more MPDUs. TKIP assigns a monotonically increasing TSC value to each MPDU, taking care that all the MPDUs generated from the same MSDU have the same value of extended IV.
3. For each MPDU, TKIP uses the key mixing function to compute the WEP seed.
4. TKIP represents the WEP seed as a WEP IV and ARC4 key and passes these with each MPDU to WEP for generation of the ICV, and for encryption of the plaintext MPDU, including all or part of the MIC, if present. WEP uses the WEP seed as a WEP default key, identified by a key identifier associated with the temporal key.
TKIP Cryptographic Decapsulation
TKIP enhances the WEP decapsulation process with the following additional steps:
1. Before WEP decapsulates a received MPDU, TKIP extracts the TSC sequence number and key identifier from the WEP IV and the extended IV. TKIP discards a received MPDU that violates the sequencing rules and otherwise uses the mixing function to construct the WEP seed.
2. TKIP represents the WEP seed as a WEP IV and ARC4 key and passes these with the MPDU to WEP for decapsulation.
3. If WEP indicates the ICV check succeeded, the implementation reassembles the MPDU into an MSDU. If the MSDU defragmentation succeeds, the receiver verifies the TKIP MIC. If MSDU defragmentation fails, then the MSDU is discarded.
4. The MIC verification step recomputed the MIC over the MSDU SA, DA, Priority, and MSDU Data fields (but not the TKIP MIC field). The calculated TKIP MIC result is then compared bit-wise against the received MIC.
5. If the received and the locally computed MIC values are identical, the verification succeeds, and TKIP shall deliver the MSDU to the upper layer. If the two differ, then the verification fails; the receiver shall discard the MSDU and shall engage in appropriate countermeasures.
Figure 3: TKIP decapsulation block diagram
CTR with CBC-MAC Protocol (CCMP)
CCMP is based on the CCM of the AES encryption algorithm. CCM 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. All AES processing used within CCMP uses AES with a 128-bit key and a 128-bit block size. CCM is a generic mode that can be used with any block-oriented encryption algorithm. CCM has two parameters (M and L), and CCMP uses the following values for the CCM parameters:
M = 8; indicating that the MIC is 8 octets.
L = 2; indicating that the Length field is 2 octets, which is sufficient to hold the length of the largest possible IEEE 802.11 MPDU, expressed in octets.
CCM requires a fresh temporal key for every session. CCM also requires a unique nonce value for each frame protected by a given temporal key, and CCMP uses a 48-bit packet number (PN) for this purpose. Reuse of a PN with the same temporal key voids all security guarantees.
CCMP Cryptographic Encapsulation
CCMP encrypts the payload of a plaintext MPDU and encapsulates the resulting cipher text using the following steps:
1. Increment the PN, to obtain a fresh PN for each MPDU, so that the PN never repeats for the same temporal key. Note that retransmitted MPDUs are not modified on retransmission.
2. Use the fields in the MPDU header to construct the additional authentication data (AAD) for CCM. The CCM algorithm provides integrity protection for the fields included in the AAD. MPDU header fields that may change when retransmitted are muted by being masked to 0 when calculating the AAD.
3. Construct the CCM Nonce block from the PN, A2, and the Priority field of the MPDU where A2 is MPDU Address 2.
4. Place the new PN and the key identifier into the 8-octet CCMP header.
5. Use the temporal key, AAD, nonce, and MPDU data to form the cipher text and MIC. This step is known as CCM originator processing.
6. Form the encrypted MPDU by combining the original MPDU header, the CCMP header, the encrypted data and MIC.
Figure 4: CCMP encapsulation block diagram
CCMP Cryptographic Decapsulation
CCMP decrypts the payload of a cipher text MPDU and decapsulates a plaintext MPDU using the following steps:
1. The encrypted MPDU is parsed to construct the AAD and nonce values.
2. The AAD is formed from the MPDU header of the encrypted MPDU.
3. The Nonce value is constructed from the A2, PN, and Priority Octet fields.
4. The MIC is extracted for use in the CCM integrity checking.
5. The CCM recipient processing uses the temporal key, AAD, nonce, MIC, and MPDU cipher text data to recover the MPDU plaintext data as well as to check the integrity of the AAD and MPDU plaintext data.
6. The received MPDU header and the MPDU plaintext data from the CCM recipient processing may be concatenated to form a plaintext MPDU.
7. The decryption processing prevents replay of MPDUs by validating that the PN in the MPDU is greater than the replay counter maintained for the session.
Figure 5: CCMP decapsulation block diagram
