AES CBC MAC Generation 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
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.