AES CBC MAC Generation

Question

I am working with Atmel's/MicroChip's ATAES132A 32K AES Serial EEPROM chip for hardware encryption and decryption. This is my first venture into cryptography. I've been reading through the datasheet and have a question on how to generate the MAC for decryption. I've asked this question on the Atmel forum, but I didn't get any responses. I figured this is more of a cryptography question rather than a technical one.

Per the datasheet:

I.3 MAC Generation

The following example shows how the integrity MAC is calculated for an authentication operation requiring up to 14 bytes of authenticate-only data. This operation involves three passes through the AES crypto engine; all three using the same key. If there are more than 14 bytes of authenticate-only data, then another pass through the AES crypto engine is required. There are two passes through the AES crypto engine in CBC mode to create the cleartext MAC. The inputs to the crypto engine for those blocks are labeled B0 and B1, and the outputs are B’0 and B’1, respectively.

• B0 is composed of the following 128 bits:

– 1 byte flag, a fixed value of b0111 1001. – 12 byte Nonce, as generated by the Nonce command. – 1 byte MacCount, one for first MAC generation. – 2 byte length field, always 0x00 00 for authentication only.

• B1 is the XOR of B’0 with the following 128 bits: – 2 byte length field, size of authenticate-only data. – 14 byte data to be authenticated only.

• B’1 is the cleartext MAC, which must be encrypted before being sent to the system.

There is one additional pass through the AES crypto engine in CTR mode to create the key block that is used to encrypt the MAC. The input to the crypto engine for this block is labeled A0 and the output is A’0. A’0 is the MAC sent to the system as the output parameter of the Auth command.

• A0 is composed of the following 128 bits: – 1 byte flag – fixed value of b0000 0001. – 12 byte Nonce – as generated by ATAES132A during Nonce command. – 1 byte MacCount – one for first MAC generation. – 2 byte counter field – always 0x00 00 for A0.

• A’0 is XOR’d with the cleartext MAC (B’1) and sent to the system.

Input integrity MACs for Auth, Counter, KeyCreate, and Lock are also calculated using this procedure. If the input MAC does not match A’0, then the command returns an AUTH error.

So my question is, in suede-code, are my steps correct?

B'0 = B0 XOR with the secret Key

B'1 = B1 XOR with B'0

A'0 = B'1 XOR with A0

Answer 1

What you are reading is a description of how CCM is performed within the "Cryptographic Element Device. The block names are from the CCM description by NIST.

A more clear description is the following:

N = Nonce(12)

# this implements CBC(key, IV, 79 | NONCE | 01 | 00 00 | LL LL | DATA)
# taking only the last block (AES / CBC-MAC)

IV = 00000000000000000000000000000000 # presumed, it's logical

B0 = 79 | NONCE | 01 | 00 00
B'0 = CBC(key, IV, B0)

B1 = XOR(B'0, LL LL | DATA)
B'1 = CBC(key, IV, B1)

N2 = Nonce(12) # it may be that N2 should be identical to N1, look into spec

# this implements CTR(key, A0, B'1)

A0 = 01 | N | 01 | 0000 # this is the initial counter for CTR mode
A'0 = CTR(key, A0, 00000000000000000000000000000000)
R = XOR(A'0, B'1)

This is a block by block description on how CCM mode is performed internally when up to 14 bytes of data are just MAC'ed - not encrypted. You could use it to mimic the implementation if you're just given AES-CBC and AES-CTR or indeed just AES. On a normal computer you'd just use an existing library that contains CCM.