# CTR and CBC-MAC Demystified

I am trying to understand the background processes within the CCMP. However the concept of CTR and CBC-MAC made me lost.

According to the CCMP Encapsulation block diagram there are inputs like Plaintext MPDU, TK, PN, KeyId, etc. What is the temporary key (TK)? Which part of the diagram represents CTR and which one is for the MIC computation (CBC-MAC)? Construct Nonce from the image constructs the nonce for the MIC or for the counter computation?

If I've understood well, counter is a 128-bit value derived from Source MAC address, Packet number, Flag, Priority and Ctr which increment by 1 for each MPDU. Each message is broken into 128-bit chunk of data and then XORed with the encrypted counter.

CBC-MAC is a mode used to generate 64-bit MIC. Again, each message is splitted into 128-bit message blocks. First message block is derived from the nonce which is constructed from Source MAC Address, Priority, DLen and Packet Number. This message block is encrypted with AES and its result is then XORed with second message block and the result of XOR operation is encrypted again. This keeps repeating until the whole message is encrypted. Finally, this forms 128-bit MIC which is then discarded to 64-bit MIC.

I've got lost in RFCs since I've couldn't find any good explanation in my literature.

It is not entirely clear what your question is, so I just try to explain what CCMP and CCM are, and roughly how they work. Please update your question if this does not answer it.

First of, remember that CCM is a general purpose mode-of-operation for authenticated encryption, while CCMP is a specific way of using CCM within the context of IEEE 802.11 (WiFi).

### CCM

CCM is a general purpose mode-of-operation for authenticated encryption defined in RFC 3610. However, since your question is asked in the context of CCMP I specialize the description of CCM to that setting. CCM is a combination of CTR mode encryption and CBC-MAC in a variant of MAC-then-Encrypt. Within CCMP, it uses AES as the underlying block cipher, and takes as input a 128 bit key $K$, a plaintext $P$, associated data $A$, and a 104 bit nonce $N$.

To process $P$ and $A$, CCM first computes a CBC-MAC over $A$ and $P$ to produce a tag $T$. It then encrypts $P$ using CTR mode encryption to produce a ciphertext $C'$. Finally, it encrypts $T$ using a single CTR block to produce an encrypted tag $C_T$. The output of CCM is $C$ and $C_T$.

What is missing from this description is how CCM constructs the (128 bit) IV block for CBC-MAC and the (128 bit) initial counter value for CTR mode. Both of these are constructed from the 104 bit nonce $N$ as follows:

\begin{align} IV &\gets Flag_1 || N || Length(A + P)_{16} \\ CTR_0 &\gets Flag_2 || N || 0^{16} \end{align}

where $Flag_1$ and $Flag_2$ are two distinct 8 bit values (you can look up their definitions in the RFC).

### CCMP

CCM is a stateless authenticated encryption scheme. As such, it cannot protect against replay attacks. Essentially, the purpose of CCMP is to add replay protection on top of CCM by introducing some state. In particular, CCMP maintains a 48 bit counter called the packet number (PN in your diagram) which is incremented for each encrypted IEEE 802.11 frame. Since CCMP uses CCM, one of its responsibilities is to create the 104 bit nonce $N$. This is what is shown in your diagram above. Basically, $N$ is created from the 48 bit MAC address of the sender ($A2$ in your diagram), the 48 bit packet number PN, and a 8 bit flag $Flag$ which encodes various IEEE 802.11 settings, in the following way:

$$$N \gets Flag || A_2 || PN$$$

Thus, when this 104 bit nonce is feed into CCM, the 128 bit IV and 128 bit initial CTR value, will look like this:

\begin{align} IV &\gets Flag_1 || Flag || A2 || PN || Length(A + P)_{16} \\ CTR_0 &\gets Flag_2 || Flag || A2 || PN || 0^{16} \end{align}

This is essentially all that is happening in your diagram above. The value TK corresponds to what I called $K$ as the input to CCM.

• TL;DR AES-CTR and AES CBC-MAC are inside the CCM block in the question, that's why you don't see them in the higher level CCMP protocol. Longer answer above upvoted of course. – Maarten Bodewes Aug 22 '17 at 17:22