Reputation: 43
I'm using a Omnikey 5321 reader to communicate with Mifare DESFire EV1 tags. I want to read 40 bytes in a standard data file. I'm using Winscard DLL (c++) to wrap native desfire commands in ISO 7816 APDU message structure.
The application selection and AES authentication are OK. I have problem with read data command. The communication settings are set to 0x03 (fully enciphered).
APDU sended :
0x90 BD 00 00 07 01 00 00 00 28 00 00 00
I received 48 data bytes and "0x9100" status code. Into calculate the IV using to decrypt the data:
I first XOR (0xBD 01 00 00 00 28 00 00 80 00 00 00 00 00 00 00) and the subkey 2 calculated after AES authentication).
Then I encrypt the result with an Init Vector set to 0x00 and the session key. The data encrypted are considered as the IV.
I finally decrypt the 48 data bytes received with IV and the session key.
I get :
40 data bytes + 4 CRC bytes + 4 padding bytes (0x00 00 00 00)
The 40 data bytes are sometimes good but sometimes wrong. I don't know why it is not always the same result. The CRC decrypted is always the same and so do the padding.
When I try to read plain data in another file, I have no problem. So I think it's the decipherment which is problematic. But CRC and padding would not be always the same.
Some help would be very useful
Upvotes: 0
Views: 1752
Reputation: 8457
Well, I'll hazard a guess: Are you using AES decryption in CBC mode? If that is the case, then you need the correct IV and the correct key to decrypt.
If you have the right key, but the wrong IV, you will be able to decrypt the ciphertext, but the first 16 bytes of the decrypted plaintext will be wrong. Since the CRC and padding bytes are not in the first 16 bytes, they will always be correct, even if you have the wrong IV. A bad IV will only corrupt the first 16 bytes of the decryption output.
So, it would be interesting, in the case where the data bytes are wrong, if it is only the first 16 bytes which are wrong, and if you are using CBC mode. In that case, look to the IV.
Upvotes: 1