I'm working through the examples in AN0945. I'm stuck on table 41, trying to understand how to calculate AES CMACs.
In step one, it says
...Calculate CMAC on “3D01000000100000010203040 50607080910111213141516” (cmd + file no + offset + length + data) as done in native mode.
I used my CMAC implementation to correctly calculate the CMAC on this as 7CC4A0C770A11F62762F397482F75E92, using the session key, which gives me some confidence that my CMAC implementation is correct.
However, in step 5, it says
...Calculate CMAC on “00” (success code as in native)... and it says that the result should be 99FF486D1BCE3F24.
I assume this means I should get a 16 byte CMAC and these are the first eight? In any case, if I calculate the CMAC on "00" using the session key of 00112233F9B7C14CCCDDEEFF1E92CBD4, I get something completely different (I actually get 5C0821A202813197E29134F30CF3728D).
So, my question is, does the calculation actually work on just "00"? Is there some other difference between steps 1 and 5? For example, I don't believe that I should use the IV in the CMAC calculation, but perhaps I should?
Thanks in advance
- Dave
Response: Dear AtekPayments,
Here's a simple pseudocode for generating CMAC, CRC32, and CRC16:
1. CMAC Generation:
```
function generate_cmac(key, message)
// Initialize the CMAC context with the given key
cmac_context = init_cmac_context(key)
// Update the CMAC context with the message
update_cmac_context(cmac_context, message)
// Finalize the CMAC context and get the result
cmac_result = finalize_cmac_context(cmac_context)
return cmac_result
end function
```
2. CRC32 Calculation:
```
function crc32(data)
crc = 0xFFFFFFFF
for each byte in data
crc = update_crc32(crc, byte)
end for
return crc ^ 0xFFFFFFFF
end function
function update_crc32(crc, byte)
crc = crc ^ byte
for i = 0 to 7
if crc & 1
crc = (crc >> 1) ^ 0xEDB88320
else
crc = crc >> 1
end if
end for
return crc
end function
```
3. CRC16 Calculation:
```
function crc16(data)
crc = 0xFFFF
for each byte in data
crc = update_crc16(crc, byte)
end for
return crc
end function
function update_crc16(crc, byte)
crc = crc ^ byte
for i = 0 to 7
if crc & 1
crc = (crc >> 1) ^ 0xA001
else
crc = crc >> 1
end if
end for
return crc
end function
```
Please note that these are simple pseudocode examples and may need to be adapted to your specific programming language and use case
Quiet in here, isn't it?
In case anyone comes this way, then I found the answer, which is that yes, you do use the IV in the CMAC calculation. But not in the bit where you use the cipher to calculate sub keys, just in the final encryption pass. This makes it difficult to do this using bouncy castle, and I ended up rolling my own CMAC implementation. After that, everything just worked.
Dear David Cleal,
I deeply apologize for the delay, yes you will have to use the updated IV for future calculations not the zeros IV, so the calculations should be
Data = 00
IV = 7CC4A0C770A11F62762F397482F75E92
Session Key = 00112233F9B7C14CCCDDEEFF1E92CBD4
and the result should be 99 FF 48 6D 1B CE 3F 24 60 69 D8 4D 03 38 55 A6.
Hope this is clear and please let me know if you have more questions.
BR
Jonathan
Can you provide me with sample sudo code for cmac generation also CRC32 & CRC16
Dear jonathaniglesias
thanks for the message - as I said earlier, I did manage to get it working, once I realised we were using a modified IV. Incidentally, varying the IV seems like pointless complexity: it makes it harder to use standard implementations like bouncycastle, and it doesn't add security. But I guess it's way too late to complain ;-)
- Dave
Update... I can't even make the example in table 24, step 4, work. Is there a reference implementation of this calculation somewhere that I can use? Preferably in Java?