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?