2
$\begingroup$

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?

New contributor
veda-s4dhak is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
$\endgroup$

2 Answers 2

1
$\begingroup$

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?

$\endgroup$
5
  • $\begingroup$ I see your point but no mention of enc. before cmac. But doesn't AES always need to be specified to use a mode? Why is ECB assumed? I have added some literature of the spec and references to the question if you get a chance to take a look. $\endgroup$ Jun 21 at 1:17
  • $\begingroup$ @veda-s4dhak CMAC is a mode of AES. “AES-CMAC” is fully precise, it doesn't need any more qualification. CMAC/OMAC1 (the two are synonyms) is inspired by CBC, but it doesn't use CBC or ECB as a building block, it uses the block cipher itself (e.g. AES) as a building block. Depending on your interface, if your library doesn't provide CMAC as a primitive, you can build it on top of either AES or AES-ECB where you pass one block at a time. Passing a single block at a time to AES-ECB is equivalent to calling AES. $\endgroup$ Jun 21 at 5:38
  • $\begingroup$ @Gilles'SO-stopbeingevil' I see, but I have some conflicting evidence. I have been investigating an implementation for SCP03 to try to answer this question. If you look at the CMAC method (line 173) in github.com/kaoh/globalplatform/blob/master/globalplatform/src/… on line 173. It is specifying one of aes-128-cbc", "aes-192-cbc", "aes-256-cbc for the CMAC. Based on your answer should I be interpreting this as it is building on top of AES-CBC to compute the CMAC? So that means you can essentially use any AES mode to compute a CMAC and they should all produce the same result? $\endgroup$ Jun 21 at 5:49
  • $\begingroup$ @veda-s4dhak No, you cannot use any AES mode to compute CMAC. CMAC is inspired by CBC but it is not built on top of another mode. It's built on top of AES itself. $\endgroup$ Jun 21 at 5:55
  • $\begingroup$ @Gilles'SO-stopbeingevil', hmm I see. So AES-CMAC is totally independent. It could essentially be considered its own mode? If you put your comment as an answer, you got it. As an aside do you know any test vectors for SCP03? $\endgroup$ Jun 21 at 6:05
1
$\begingroup$

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.

$\endgroup$

Your Answer

veda-s4dhak is a new contributor. Be nice, and check out our Code of Conduct.

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.