What AES mode does the CMAC use in Secure Channel Protocol 3 (SCP03)?

Question

I am looking to verify a card cryptogram sent from a smart card chip in accordance with SCP03. According to the SCP03 spec, the CMAC is used to generate a MAC to authenticate messages sent to/from the secure element.

The SCP03 spec says that AES in CBC mode is used to do encryption and decryption, but it is unclear what mode is used in the CMAC.

Currently I am using OMAC1 which is using AES in ECB mode. My CMAC (in KDF counter mode) works with the test vectors provided by NIST (https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/KBKDF800-108/CounterMode.zip), however, I am not producing the correct card cryptogram when talking with the secure element.

I have double checked that the key and fixed input data to the CMAC are correct.

The terminology in general confusing:

• AES-CBC != AES-CMAC (but if AES-CMAC uses CBC then is it the same as AES-CBC...)
• OMAC1 == AES-CMAC (but OMAC1 uses ECB vs. AES-CMAC can use any AES mode...)

---

The SCP03 CMAC specification states (links are below):

[link 2] section 4.1.3:

CMAC as specified in [NIST 800-38B] is used for MAC calculations. Note that [NIST 800-38B] also specifies the padding to be applied to the input. This complies with [FIPS 140-2] Annex A (Message authentication – 3).

[link - 2] section 4.1.5:

Data derivation shall use KDF in counter mode as specified in NIST SP 800-108 [NIST 800-108]. The PRF used in the KDF shall be CMAC as specified in [NIST 800-38B], used with full 16 byte output length.

---

Below is a sample unit test from the secure element which is failing:

// The static key used to generate the session MAC key
uint8_t key_raw[16] = { 0x58, 0x56, 0x33, 0x62, 0xEC, 0x5A, 0x45, 0x41, 0xAB, 0xCD, 0x32, 0xB3, 0x4B, 0x1E, 0xAE, 0x7D };

// Used to generate the session MAC key
uint8_t key_derivation_data_raw[32] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x06, // derivation constant
                                        0x00, // separator byte
                                        0x00, 0x80, // length
                                        0x01, // iteration counter
                                        0xA6, 0xFE, 0xFE, 0xAE, 0xB2, 0xE1, 0x27, 0x18, // host challenge
                                        0x51, 0x70, 0xF4, 0x5F, 0xCA, 0x00, 0x00, 0x15 }; // card challenge

// Used to generate the card cryptogram                                        
uint8_t data_raw[32] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // derivation constant
                         0x00, // separator byte
                         0x00, 0x80, // length
                         0x01, // iteration counter
                         0xA6, 0xFE, 0xFE, 0xAE, 0xB2, 0xE1, 0x27, 0x18, // host challenge
                         0x51, 0x70, 0xF4, 0x5F, 0xCA, 0x00, 0x00, 0x15 }; // card challenge
                         
 // Card cryptogram
uint8_t expected_output[8] = { 0xB0, 0x1E, 0x60, 0x94, 0xFC, 0x7E, 0x25, 0xCF };

---

Relevant links:

[link - 1] NIST 800-38B link: https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-38b.pdf [link - 2] SCP03 Link (Section 4.1.3 and 4.1.5 is of interest): https://globalplatform.org/wp-content/uploads/2014/07/GPC_2.2_D_SCP03_v1.1.1.pdf

---

TLDR -> Does the CMAC in SCP03 use AES in CBC mode?

Answer 1

TLDR -> Does the CMAC in SCP03 use AES in CBC mode?

In not familiar with the SCP03 protocol, but the confusion stems from how AES is used in CMAC. Technically, we don't need to talk about "modes" in the context of CMAC. In this context, AES is used as a block cipher that takes 16 bytes key, a 16 bytes blob and returns another 16 bytes blob. Modes like CBC refer to using a block cipher to encrypt data of arbitrary length.

With that said, for all intents and purposes, the block cipher usage I talk about above can also be seen as AES in ECB mode. Indeed, ECB consists of chopping up the message to be "encrypted" into 16 bytes blobs and applying the AES blockcipher(or anything else) to each block. So AES-ECB on a single 16 bytes blob is the same as using the AES block cipher...

I also don't know how the software used to test all of this is structured, but I would guess that the solution is to "use AES-ECB" in your implementation of CMAC. Besides that, it would be worth also checking what encryption mode is expected by the receiver. Perhaps you have to first encrypt the data with AES-CBC and then apply CMAC to the result of encryption? Perhaps no encryption is actually needed?

Answer 2

I have implemented CMAC from CBC-MAC and just AES in CBC mode. CBC-MAC - as the name implies - can certainly be implemented using CBC long as you have some space to temporarily stash the unneeded ciphertext blocks. However, as indicated in the comments, usually AES is simply indicated as block cipher, and CBC-MAC and the derived CMAC are just like CBC mode.

If you have to choose a mode then ECB mode without padding is simply identical to the block cipher. For CBC you'd have to use one block and a zero IV, but you can definitely do without a XOR with zero values.

Probably your CMAC calculation is correct if it conforms to test vectors (including those consisting of a precise multiple of 128 bit / 16 byte blocks). After that it is making sure that the right bytes are included in the calculation.