Counter Mode with CBC-MAC (CCMP)

TKIP is better than WEP, but that is the only statement that can be made with certainty. WEP's basis in a stream cipher will always leave lingering doubts about the security of anything built using a similar set of operations. To address the concerns of the 802.11 user community, the IEEE working group began developing a security protocol based on the Advanced Encryption Standard (AES) block cipher. AES is a flexible

cipher that can operate at many key lengths and block sizes; to prevent user confusion, 802.11i mandates the use of AES with both 128-bit keys and 128-bit blocks.

There has been some concern over the key size used with 802.11i. AES can operate with a variety of key lengths. The U.S. National Security Agency has approved AES for use with "secret" data with 128-bit and longer keys, but more sensitive "top secret" data requires the use of 192-or 256-bit keys.[*] Some observers have therefore concluded that 128-bit keys do not offer adequate security. Regardless of the merits in the debate over key size, 128-bit AES is much better suited to 802.11 frame encryption RC4 at any key length.

[*] See the Committee on National Security Systems (CNSS) Policy No. 15, Fact Sheet No. 1, "National Policy on the Use of the Advanced Encryption Standard (AES) to Protection National Security Systems and National Security Information" at http://www.nstissc.gov/Assets/pdf/fact%20sheet.pdf.

The link-layer security protocol based on AES is called the Counter Mode with CBC-MAC Protocol (CCMP).[] The name comes from the underlying use of the block cipher, in the Counter Mode with CBC-MAC (CCM) mode, which is specified in RFC 3610. CCM is a "combined mode of operation, in which the same key is used in encryption for confidentiality as well as creating a cryptographically secure integrity check value.

[images/ent/U2020.GIF border=0>] One of the delays in finishing 802.11i was that the AES algorithm was initially based on a different mode of operation, AES-OCB. Intellectual property concerns required that it be dropped from the final specification in favor of CCMP.

In September 2003, the National Institute of Standards and Technology (NIST) began a study of CCM. In May 2004, NIST gave its approval to CCM, which will allow 802.11i to serve as the basis for secure wireless LANs in demanding applications.

CCMP Data Processing

Like other link-layer encryption methods, CCMP provides support for encryption and integrity protection as part of the same process, as shown in Figure 7-6.

Figure 7-6. CCMP frame processingencryption

As input, CCMP takes the following items:

• The frame, naturally.
• A temporal key used to encrypt and authenticate the frame. One key is used for both frame encryption and frame authentication.
• A key identifier to support the use of multiple keys over the air. Only one key, however, will be used for any given frame.
• A packet number, used to uniquely identify the frame being transmitted. The packet number is incremented for each frame transmission, but it remains the same for each attempt to transmit the frame. That is, retransmissions do not cause the PN to increment.

CCMP data transmission

When a frame is generated and sent to TKIP for transmission, this procedure occurs:

1. The 802.11 frame is queued for transmission. It consists of a frame header and the payload. Like WEP, TKIP protects only the payload of the 802.11 MAC, and leaves the 802.11 frame header, as well as any lower-layer headers, intact.
2. A 48-bit Packet Number (PN) is assigned. As with the TKIP sequence number, packet numbers are never re-used for the same temporal key. Packet numbers are increased by one for every transmission, and are used for replay detection.
3. The Additional Authentication Data (AAD) field is constructed. It consists of the fields in the frame header which must be authenticated for security but must also remain unencrypted so that the 802.11 protocols may operate. The receiver will use the AAD field to verify that the authenticated fields were not altered in transit. The AAD field protects the 802.11 protocol version, frame type, the distribution system bits, and fragmentation and order bits. It also protects the address fields from the MAC header, and the sequence control field, with the sequence number (though not the fragment number) set to zero. It ends with two optional components: the fourth address field from the MAC header (if the wireless distribution system is in use), and quality of service header information.
4. Next, the CCMP nonce is built. Nonces are little bits of data that guarantee that the encryption operation occurs on unique data. Nonces should never be re-used with the same key. In CCMP, the nonce is constructed with the packet number and the sender's address so that the same packet number can be used by multiple stations. The nonce also includes priority data used in QoS.
5. Next, the CCMP header is built. It consists of the packet number, broken across six bytes, with a key identifier in the middle. As in WEP, there are four potential key slots used in CCMP. The Extended IV bit is always set to 1 in CCMP because an eight-byte header is always needed to accommodate the large packet number field. The header is shown in Figure 7-7.
6. All the inputs to the CCM encryption engine are available at this point. As input, it takes the 128-bit temporal key, the nonce from step 4, the additional authentication data from step 3, and the frame body. All the data is authenticated with a 8-byte MIC, and the frame body and MIC are encrypted. Figure 7-6 illustrates the encryption process.
7. The encrypted frame is prepared for transmission by taking the original MAC header and appending the CCMP header and the encrypted data from step 6. The resulting frame is pushed down to the radio interface for transmission, and looks like Figure 7-10.

The encapsulation of a CCMP-protected frame is quite straightforward, and is shown in Figure 7-7. Following the MAC header, a CCMP header holds the packet number and key ID. The higher-layer protocol frame and its MIC are encrypted before the FCS.

Figure 7-7. CCMP encapsulation

CCMP reception

When CCMP receives a frame, the encryption and transmission process must be reversed. With no backwards compatibility baggage requiring the use of the WEP engine, the CCMP decryption process is a straightforward reversal of Figure 7-6:

1. When a frame is received by the wireless interface and passes the frame check sequence to ensure it has not been corrupted, it is passed to CCMP for validation.
2. The additional authentication data (AAD) is recovered from the received frame. It consists only of frame headers, which are transmitted in the clear.
3. The CCMP nonce is also recovered from the frame. It consists of the packet number, the sender's address, and contents of the quality of service field, all of which are available in the frame header in the clear.
4. The receiver decrypts the ciphertext. It requires the temporal key, the nonce recovered from step 3, the authentication data from step 2, and of course, the encrypted frame body. When the process completes, the receiver has a copy of the decrypted frame plus the decrypted integrity code.
5. The integrity check is calculated over the plaintext data and the additional authentication data. If the calculated integrity check value matches the integrity check value extracted in step 4, then processing proceeds. Otherwise, processing ends.
6. A plaintext frame is constructed from the MAC header and the data recovered in step 4. To pass through the replay detection check, the packet number must be greater than or equal to the last received packet number that passed through the integrity check process.