When using Desfire native wrapped APDUs to communicate with the card, which parts of the command and response must be used to calculate CMAC?
After successful authentication, I have the following session key:
Session Key: 7CCEBF73356F21C9191E87472F9D0EA2
Then when I send a GetKeyVersion command, card returns the following CMAC which I'm trying to verify:
<< 90 64 00 00 01 00 00
>> 00 3376289145DA8C27 9100
I have implemented CMAC algorithm according to "NIST special publication 800-38B" and made sure it is correct. But I don't know which parts of command and response APDUs must be used to calculate CMAC.
I am using TDES, so MAC is 8 bytes.
Sry for my English,- its terrible :) but it's not my native language. I'm Russian.
Check first MSB (7 - bit) of array[0] and then shiffting this to the left. And then XOR if MSB 7 bit was == 1; Or save first MSB bit of array[0] and after shiffting put this bit at the end of array[15] at the end (LSB bit).
Just proof it's here: https://www.nxp.com/docs/en/application-note/AN10922.pdf
Try this way:
First u have to encrypt 16 bytes (zeros) with SesionKey;
And u get EncryptedData.
Check bit 7 [MSB - LSB] of EncryptedData[0] == 1? switch i to true;
Then do Shiffting of all EncryptedData to 1 bit <<.
And now, when i == true - XOR the last byte [15] with 0x87
Save it as KEY_1.
Try bit 7 [MSB - LSB] of ShiftedEncryptedData[0] == 1?
Then do Shiffting of all ShiftedEncryptedData to 1 bit <<.
And now, when i == true - XOR the last byte [15] with 0x87
Save it as KEY_2.
Now we take our Data (6F 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
As Michael say's - pad command with 0x80 0x00...
XOR Data with KEY_2 - if command was padded, or KEY_1 if don't. If we have more like 16 bytes (32 for example) u have to XOR just last 16 bytes.
Then encrypt it:
Now u have a CMAC.
C/C++ function:
Have a nice day :)