CCM mode
Authenticated encryption mode for block ciphers
- 3 min read
- 4 chapters
Related on Lably
Through Confidentiality, Patent and Algorithm
The nonce of CCM must be carefully chosen to never be used more than once for a given key. This is because CCM is a derivation of counter (CTR) mode and the latter is effectively a stream cipher.
Encryption and authentication
As the name suggests, CCM mode combines counter (CTR) mode for confidentiality with cipher block chaining message authentication code (CBC-MAC) for authentication. These two primitives are applied in an "authenticate-then-encrypt" manner: CBC-MAC is first computed on the message to obtain a message authentication code (MAC), then the message and the MAC are encrypted using counter mode. The main insight is that the same encryption key can be used for both, provided that the counter values used in the encryption do not collide with the (pre-)initialization vector used in the authentication. A proof of security exists for this combination, based on the security of the underlying block cipher. The proof also applies to a generalization of CCM for any block size, and for any size of cryptographically strong pseudo-random function (since in both counter mode and CBC-MAC, the block cipher is only ever used in one direction).
CCM mode was designed by Russ Housley, Doug Whiting and Niels Ferguson. At the time CCM mode was developed, Russ Housley was employed by RSA Laboratories.
A minor variation of CCM, called CCM*, is used in the IEEE 802.15.4 standard, used as the MAC layer in Zigbee. CCM* includes all of the features of CCM. It allows a choice of MAC lengths down to 0 (which disables authentication and becomes encryption-only).
Sign in to keep reading
3 more chapters are free with a Lably account.
Performance
CCM requires two block cipher encryption operations on each block of an encrypted-and-authenticated message, and one encryption on each block of associated authenticated data.
According to Crypto++ benchmarks, AES CCM requires 28.6 cycles per byte on an Intel Core 2 processor in 32-bit mode.
Notable inefficiencies:
- CCM is not an "on-line" authenticated encryption with associated data (AEAD), in that the length of the message (and associated data) must be known in advance.
- In the MAC construction, the length of the associated data has a variable-length encoding, which can be shorter than machine word size. This can cause pessimistic MAC performance if associated data is long (which is uncommon).
- Associated data is processed after message data, so it is not possible to pre-calculate state for static associated data.
Patents
The catalyst for the development of CCM mode was the submission of offset codebook (OCB) mode for inclusion in the IEEE 802.11i standard. Opposition was voiced to the inclusion of OCB mode because of a pending patent application on the algorithm. Inclusion of a patented algorithm meant significant licensing complications for implementors of the standard.
While the inclusion of OCB mode was disputed based on these intellectual property issues, it was agreed that the simplification provided by an authenticated encryption system was desirable. Therefore, Housley, et al. developed CCM mode as a potential alternative that was not encumbered by patents.
Even though CCM mode is less efficient than OCB mode, a patent free solution was preferable to one complicated by patent licensing issues. Therefore, CCM mode went on to become a mandatory component of the IEEE 802.11i standard, and OCB mode was relegated to optional component status, before eventually being removed altogether.
Use
CCM mode is used in IEEE 802.11i (as CCMP, the CCM encryption protocol for WPA2), IPsec, and TLS 1.2, as well as Bluetooth Low Energy (as of Bluetooth 4.0).It is available for TLS 1.3, but not enabled by default in OpenSSL. From version 0.8 to 0.8.3 it was the default in OpenZFS' native encryption.