CCM mode (Counter with CBC-MAC) is a mode of operation for cryptographic block ciphers. It is an authenticated encryption algorithm designed to provide both authentication and confidentiality. CCM mode is only defined for block ciphers with a block length of 128 bits.
Encryption and authenticationEdit
As the name suggests, CCM mode combines the well known CBC-MAC with the well known counter mode of encryption. These two primitives are applied in an "authenticate-then-encrypt" manner, that is, CBC-MAC is first computed on the message to obtain a tag t; the message and the tag are then encrypted using counter mode. One key 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 size block cipher, and for any size cryptographically strong pseudo-random function (since in both counter mode and CBC-MAC, the block cipher is only ever used in one direction).
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.
- CCM is not an "on-line" 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.
The catalyst for the development of CCM mode was the submission of 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.
CCM mode is used in the IEEE 802.11i (as CCMP, an encryption algorithm 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.
- Dworkin, Morris (May 2004). Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality (PDF) (Technical report). NIST Special Publications. NIST. doi:10.6028/NIST.SP.800-38C. 800-38C.
- Whiting, D.; Housley, R.; Ferguson, N. (September 2003). Counter with CBC-MAC (CCM). IETF. doi:10.17487/RFC3610. RFC 3610.
- "rfc4309". IETF. p. 3.
AES CCM employs counter mode for encryption. As with any stream cipher, reuse of the same IV value with the same key is catastrophic.
- Jakob Jonsson, On the Security of CTR + CBC-MAC
- "IEEE Standard for Local and metropolitan area networks--Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs)" (PDF). IEEE Standards. 2011-09-05. p. 229. Retrieved 2015-12-18.
- "Crypto++ 5.6.0 Benchmarks". Crypto++. Retrieved 6 September 2015.
- RFC 4309 Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)
- RFC 6655 AES-CCM Cipher Suites for Transport Layer Security (TLS)
- Bluetooth Low Energy Security
- Caswell, Matt (2017-05-04). "Using TLS1.3 With OpenSSL". OpenSSL blog. Retrieved 2018-12-29.