1

(23 replies, posted in NXP MIFARE DESFire)

Hi,

I have just seen there are some responses to my post. I just want to say that I completed the changeKey procedure, it was an encryption problem because I was not doing the DES properly (all the send mode staff).

If someone needs a capture or something to test its values I could provide it. I have all the classes implemented in java (I am using a mobile with J2ME and JSR257 as a reader).

Regards.

2

(4 replies, posted in NXP MIFARE DESFire)

Hi,

I finally achieved to get the CMAC properly. I don´t know why I was doing the padding to 32 bytes, I think I read it somewhere but obviously I was wrong. I tried using a 16 bytes input XORed with the k2 key and I got the correct value.

Regards, Gorka

3

(4 replies, posted in NXP MIFARE DESFire)

Hi,

I am trying to migrate the AES part of the DESFire Ev1 to the application I use in my mobile to read DESFire tags. I completed the authentication properly and now I have a problem trying to get the CMAC values and the IV vectors.

I know I have to implement the SP 800-38B specification to get the CMAC values. Actually, I can diversificate an AES Master Key, so the SubKey generation and the CMAC calculation shoul be ok. So, I guess it must bt a problem of concept. I tried to compare my code in JAVA with the one available in libnfc in C++ and I cannot get the wrong step.

Assume that I want to make a read and that I already have the sessionKey and a IV that is different from 0x00..000. When I start the subKey phase I think I have to use the 0x00..000 IV (not the new I got) and the sessionKey (not the application key) in order to get the k0 key , is that correct?

Well, once the SubKeys are correctly generated I have k1 and k2. The command I use to read is : BD010000000F0000. Then I guess I have to apply the padding to 32 bytes:     (byte) 0xBD, (byte) 0x02, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x0F, (byte) 0x00, (byte) 0x00, (byte) 0x80, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00. So now since I have applied padding I use k2 to xor the second half of my input and then I encrypt the result and encrypt it using the sessionKey and the IV (that is 0x93..32). The CMAC is 32 bytes long.

Can someone tell my what I am doing wrong or at least guide me, because I don´t know how to solve the problem.

Thanks a lot.

Gorka.

4

(23 replies, posted in NXP MIFARE DESFire)

Hi again,

There is no way to make that work !!! sad

Well, here is all I have done, maybe there is something else bad and that is why I cannot change the key.

Application creation:
90 CA 0000 05 11 EE EE 0F 02 00

Old key: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
New key: 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF CC

Data Field: 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF CC 69 CC 69 00 00 00 00

I authenticate to key 0 of the application
Session Key: D9 CE 99 89 BF 65 18 BF 0C DB C6 8C 8C 38 A5 F8

I encrypt the Data field using 3DES and the session key I have just get:
C9 70 F4 CE CB CD D8 2C 4F F7 2F 2D BC 44 EF DB 39 28 9F B2 3A 6E D3 69

And finally I add it to the APDU send it:
APDU: 90 C4 00 00 19 01 C9 70 F4 CE CB CD D8 2C 4F F7 2F 2D BC 44 EF DB 39 28 9F B2 3A 6E D3 69 00


Can someone please check which step is wrong??
I would appreciate if someone could try to change a key and send me a log like the one I have posted. That why I could repeat the steps using the indicated session key and see if I get the same values.

I don´t know if it can affect to the change key, so just say that I am using a Desfire EV1 8k card.

-----------------

I´ve been doing some tests regarding the writing/reading of encrypted data and the same thing happens to me. When I read a field I get the data encrypted. I decrypted it using the sessionkey and I can get the original data, the CRC16 and the padding bytes. Everything is ok. However, when I try to write something encrypted I cannot do it.

The data I received after I decrypt it is:
-->90 BD 0000 07 09 000000 100000 00
d(00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 77 F5 00 00 00 00 00 00)

So, then I try to send the same data to another file:
--> 90 3D 0000 1F 06 000000 100000 e(00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 77 F5 00 00 00 00 00 00) 00
<-- 911E

What could be the problem??


Thank you again and regards

5

(23 replies, posted in NXP MIFARE DESFire)

Hi,

Thanks for your response. I have downloaded and installed the nfc-tools code but I cannot work directly in a Linux distribution and the vmware is giving me many problems. I will try to install nfc-tools in another linux machine and test the Desfire tools. I have to complete some operations soon, so I am using another tool to manage my Desfire card.

By the way, there is something I don´t understand in your response. The especification says: "The new key and the current key are bit-wise XORed (16 byte). A CRC (2 byte) is calculated over the XORed data and appended at the end. Additionally a CRC (2 byte) of the new key is appended". So, why do you say is a crc32 and 4 bytes long?? Can you explain this to me??

Well, if I try to get the crc32 for the key 0011..FF I get 7f601da6, is that correct?? Then, you say the second CRC is supposed to include the headers. Ok, so the input should be : 90 C4 0000 19 01 00 11 22 .. FF 7F 60 1D A6?? Hope you can clarify me this point.


Once again, thank you very much for your time.

Regards.

6

(23 replies, posted in NXP MIFARE DESFire)

Hi,

I am trying to change the keyno1 of my application but I am having some problems.
The keySettings are defined to 0f 02. I am able to authenticate to key0 and get the session key.

The old key is 00..00 since I have not changed it. And the new key I want to set is 0x00112233445566778899AABBCCDDEEFF. When I send the command to the PICC always returns a 911E (apparently it doesn´t like the CRC or the padding).

Assuming that my key is 00.00 the XOR does not affect the key, so the first parameter I guess should be the new key itself. Then I calculate the CRC and I get 69CC (Is that correct???), so I have to append it twice (once for the XORed key and once for the new key), and then I append 4 0x00s as padding.

Here are the values I am receiving right now:

Session Key: D8 15 60 CE 33 55 7D BC 3E F4 34 EA 1D FF F9 28
Old Key: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
New Key: 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF

Key Data: 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF 69 CC 69 CC 00 00 00 00
Transmitted data: 71 66 0B 4C C6 EB A6 F9 D6 36 86 2F 6A ED 33 E5 D9 84 50 B0 04 6B A9 85

Can anyone complete the key changing using this values and pass mw the values I should receive in all the steps?? I must be doing something bad bat I have read the documentation and I don´t know where.


Thanks, Gorka