Cipher Block Chaining Message Authentication Code Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

CCM is stand for Counter with CBC-MAC, which is a conventional authenticated-encryption scheme obtained from a 128-bit block ciphers. It combines the techniques of the Counter (CTR) mode and the Cipher Block Chaining-Message Authentication Code (CBC-MAC) algorithm to provide confidentiality and authenticity of the data. In RFC 3610, and CCM is designed to use the Advanced Encryption Standard(AES) block cipher, or any other block cipher with a block size of 128 bits or more, to provide authentication and encryption using a single key.

CCM, As the name indicates, combines the counter mode of encryption with the CBC-MAC mode of authentication. The most important idea is that the same encryption key can be used for both, if counter values used in the encryption and the initialization vector used in the authentication do not conflict with each other. On the security bases of block cipher, security can be proofed with any size of CCM


Back to the time CCM was developed, it was named CCM*. The designers of CCM are Russ Housley, Doug Whiting and Niels Ferguson. They designed CCM to have additional encryption-only and integrity-only capabilities.


The main processes of CCM are generation-encryption and decryption-verification. They combine the CTR(counter mode) encryption and the CBC-MAC to compute a MAC to provide authentication. To ensure the efficiency of the block cipher algorithm used for encryption, a valid key establishment and management are needed. The secret key must be randomly generated and be only shared by the parties to the information, otherwise the whole cipher algorithm would be useless. Moreover, the same key can be used for a maximum number of invocations of the cipher block algorithm and this limit should be set to 261.

As discussed before,the two cryptographic mechanism based on this cipher block algorithm, CTR mode and CBC-MAC mode, are combined. Counter mode used for confidentiality, which requires a long sequence of counter blocks to be generated to encrypt the message. These block have to be distinct within a single invocation and any others under the same secret key.

CBC-MAC is basically an adaption of CBC used for authentication. The key used for CTR and CBC-MAC is the same key. The two parameters are: size of the authentication tag M, and size of the length field L. Valid values for M are 4, 6, 8, 10, 12, 14 and 16 bytes, which involves a trade-off between message expansion and the probability that an attack can undetectably modify a message. L requires a trade-off between the maximum message size and the size of the nonce. Thus length of message to be encrypt and authenticated must be defined ahead.


CCM requires a well-designed key management structure as there is only one secret key, and being a symmetric key. The key must not be known by a third party and must be established beforehand. The header within the plaintext is authenticated but not encrypted; however, payload is. In order to not use CCM with stream data, it is supposed to be used in a packet environment. Each packet must be an integral number of bytes and nonce, a unique value, must be assigned. The size of nonce decides the maximum number of packets that can be authenticated with the same key, and this is one of the requisite parameters when designing the algorithm. By appending an encrypted authentication tag, CCM processing can expand the size of the packet. If the tag appended was successfully verified, it would be sure that the packet comes from a source with access to the block cipher key and the packet was not altered after the tag was generated. However, if the authentication tag was failed from verification, then accidental, intentional, and unauthorized modification of the packet are revealed.

It will save half of the loading process if nonce value is known so that key stream can be pre-calculated. Thus making the implementation more efficient, and a reduced size of it while only the forward encryption function of block cipher is used and not the inverse function. The figure below shows the summary of properties from Doug Whiting, and Russ Housley(n.d.).

Figure 1

Efficiency and performances

Performances depend on the speed of the block cipher implementation. In hardware, for large packets, the speed achievable for CCM is roughly the same as that achievable with the CBC encryption mode. There are two block cipher encryption operations required for each CCM block of encrypted and authenticated message. For each block of additional authentication data one additional block cipher encryption operation is required (if you include the length encoding). Each message block requires two block cipher encryption operations. The worst-case situation is when both the message and the additional authentication data are a single octet. In this case, CCM requires five block cipher encryption operations. Both CCM encryption and CCM decryption operations require only the block cipher encryption function. CCM results in the minimal possible message expansion; the only bits added are the authentication bits. Both the CCM encryption and CCM decryption operations require only the block cipher encryption function.

In AES, the encryption and decryption algorithms have some significant differences. Thus, using only the forward encrypt operation can lead to a significant saving in code size and hardware implementation and size. In hardware, CCM can compute the message authentication code and perform encryption in a single pass. This means that the implementation doesn't have to wait for the calculation of the MAC to be completed to start the encryption. Thus there is a good advantage in the speed of this algorithm.

Criticism of CCM

We discuss three efficiency problems with CCM: (a) CCM is not on-line, (b) CCM disrupts word-alignment, and (c) CCM can't pre-process static associated data.

(a) CCM is not on-line

Being on-line indicates being able to process a stream of data as it arrives, with constant memory, without knowing in advance when the stream finishes. This means

we cannot start processing until we know the length of the input data. It would not work on a stream of data as we said before. On the other hand it's true that CCM is often used in environments where packet length are well known even if in many context we can't know the length of the message we're handling until it's finished.

(b) CCM disrupts word-alignment

Length-prepend annotation also causes another problem for the associated data: CCM disrupts its word-alignment. This problem may cause significant losses in the performances, as modern machines perform operations much more efficiently when pointers into memory fall along word-boundaries. This can't be done when we prepend the length-annotation to the associated data. This problem becomes more relevant when the associated data is long, but we usually expect the associated data to be just a few bytes.

(c) CCM can't pre-process static associated data

Another problem related to the associated data comes from the fact that CCM can't pre-process static associated data. This would be very useful in contexts where the associated data is the same during a whole communication session so that we could process it once for all in order to reduce the time needed for encryption and decryption. This cannot be done because the algorithm encodes the nonce and the message length before the associated data rather than after it. Parametrization of CCM is another aspect that is often criticized. The main points of this criticism include the fact that a trade-off between the length of the nonce and the message length, induced by the choice the user has to do before using CCM, is apparently without any sense as the two parameters have nothing to do with each other. Furthermore byte orientation of CCM, as it's defined only on octet strings, could be seen as a limit for this mode of operation(Whiting & Hifn & Housley & Security & Ferguson & MacFergus, 2003).


The main security function offered is of course authenticated encryption. There is no error prop-

agation during the generation process. Sender and recipient must be synchronized as they both need

to use the same nonce, based for example on a counter. The encryption process can be parallelized

if needed but this is not true for the authentication process so CCM algorithm can't be parallelized.

The process needs a unique key, shared by sender n receiver and used both for the counter mode and

the cipher block encryption, a nonce and a counter, which are part of the counter block. In terms of

memory requirements CCM requires memory for the encrypt operation of the underlying block cipher

algorithm, for the plaintext, the ciphertext and a packet counter.

One important feature of CCM is that the encryption key stream can be precomputed, saving time

and increasing speed. Unluckily the same cannot be said for authentication.

Security Analysis of CCM

In this section we analyze the security of CCM. There are two aspects of security

in our setting:

{ Privacy: It should be infeasible for an adversary to derive any information

from the ciphertexts without access to the secret key.

{ Authenticity: It should be infeasible for an adversary to forge a valid ciphertext

without access to the secret key.

In Section 3.1 we argue heuristically for the security of CCM. Formal denitions

are provided in Section 3.2, while the main theorems are given in Section 3.3.