Switch from DES to AES authentication

[Samuel LIOULT]

Hi all,

I’m trying to switch from DES to AES but I don’t known how I can do it. I tried to authenticate me with AES auth command with all 0 key, but I have the error “AE”. Also, I tried to change key with a 16 b key but that requires a 3DES authentication and not working with AES command (0xAA)

Please help

---

+ 0  |  - 0

[AdnanM]

Hi,

Can you please be a bit more specific? What card do you have?

In my experience you can switch from DES to AES in this way (speaking for a DESFire EV1 card here):
1- Authenticate with the DES key (supposing you already know the key), (APDU: 0x90 [CLA], 0x0A or 0x1A [INS], 0x00 [P1], 0x00 [P2], 0x01 [Lc], 0x00 [KeyNo], 0x00 [Le]).
2- Change the key Settings to AES mode, (for this check MF3ICD81 MIFARE DESFire EV1 Product Data Sheet p.43 - is Company Confidential under NDA). The command INS or cmd should be 0xC4 and for AES you should write 0x10 I guess.
3- then you should be able to authenticate using the 0xAA command.

Kind regards,
Adnan

---

+ 0  |  - 0

[Samuel LIOULT]

Hi Adnan,

Thanks for your help. I have two cards (MFC3ICD41 and MFC3ICD81).
Since I posted this topic, I was able to authenticate me. My problem is now to execute others functionalities (ChangeKey, ChangeKeySettings, etc) because it seems that I have a bad CRC32 calculation. I use this :
https://community.oracle.com/thread/3603633
But I have always a 0x911E error.

According to you, what is wrong in my CRC32 implementation ?

Thanks

---

+ 0  |  - 0

[AdnanM]

Hi Samuel,

0x911E stands for INTEGRITY_ERROR (CRC or MAC does not match data. Paddinng bytes not valid).
With what did you authenticate? 3DES? If you want now to change the Key [ChangeKey] you should use:
0x90[CLA] 0xC4[INS] 0x00[KeyNo] and Ciphered_Key_Data [24 to 40 bytes] ... (you should have a look at the document that I wrote earlier p.43-45, you can find it at docstore.nxp.com).

Are you in an application level, or transponder level (PICC)? According to the documentation, once you are in the application level you cannnot change the key type (after application creation).

As you use a CRC32, I guess you Authenticate with AuthenticateISO 0x1A. Is it right? After this you have these choices to change the key: (CASE I) KeyNo use for authentication is different from the KeyNo to be changed, and (CASE II) KeyNo used for authentication is the same as the KeyNo to be changed (the procedure is diffrent). There is also (CASE III) when the Key is set to 0x0F (all keys except the Master Key are frozen).

It depends on the method how you pass the "Ciphered_Key_Data" to get it right.

Good luck.
Adnan

---

+ 0  |  - 0

[Samuel LIOULT]

Hi Adnan,

Thanks for your reply.
I use AES mode. I've already change the PICC master key to use the AES mode, and I manage AES authentication and I think my change key command is good. I really don't understand what is wrong in my procedure. I send you all my logs for authentication and change key and I hope you could help me :

AES key : 00 … 00

Authentication with the PICC master key (00) and 0xAA command :

Ciphered RndB (received from the PICC) :
76 A4 40 10 FE A9 DE F6 42 CE CB 0B C7 9F 1C 5C

Deciphered RndB :
17 26 6E C6 18 03 EE D1 23 45 FE E6 02 31 E6 FB

RndB’:
26 6E C6 18 03 EE D1 23 45 FE E6 02 31 E6 FB 17

RndA (generated by the PCD):
82 F6 C3 29 C0 00 50 07 B1 A7 5F 0B D8 37 5B CD

RndA and RndB’ concatenation :
82 F6 C3 29 C0 00 50 07 B1 A7 5F 0B D8 37 5B CD 26 6E C6 18 03 EE D1 23 45 FE E6 02 31 E6 FB 17

Ciphered datas to send:
C3 95 0F 45 1D 25 84 D8 FB 3A 52 79 E7 D2 36 D3 F5 A6 65 79 7F D6 D2 57 24 03 97 F9 CE 26 BF 1D

Datas received from PICC with successful code :
4B 98 54 6C BC 27 99 7E B2 E0 58 AD 3A A8 5D EE

Session key : 82 F6 C3 29 17 26 6E C6 D8 37 5B CD 02 31 E6 FB

Authentication OK!

Change key :

New AES key = 01 … 01

CRC calculate over:
C4 80 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 00

CRC value:
BC 71 57 FB

Datas to ciphered:
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 00 BC 71 57 FB 00 00 00 00 00 00 00 00 00 00 00

Ciphered datas:
8A 6B 2D 2C 58 33 40 64 BC 8C 95 7C 5A 90 E4 B6 C1 E9 64 E9 22 AF 60 8D E4 20 A1 E6 6C 8C 1E 9C

Datas to send (without command byte):
80 8A 6B 2D 2C 58 33 40 64 BC 8C 95 7C 5A 90 E4 B6 C1 E9 64 E9 22 AF 60 8D E4 20 A1 E6 6C 8C 1E 9C

Complete sent APDU buffer as input of the ScardTransmit method:
0 C4 00 00 21 80 8A 6B 2D 2C 58 33 40 64 BC 8C 95 7C 5A 90 E4 B6 C1 E9 64 E9 22 AF 60 8D E4 20 A1 E6 6C 8C 1E 9C 00

PICC always return 0x911E

Note I work in PICC level and get key settings command returns 0x0F01

Samuel

---

+ 0  |  - 1

[Elmue Meister]

Hello Samuel

I made tests with your data and found why it does not work.
Your session key is wrong.

You wrote: "Authentication OK!"
But your authentication is NOT successfull.

When you send Random A+B to the card you get Random A back encrypted.
You must check that it equals to the random A that you have generated.
I suppose you were too lazy to write that code and the result is that you do not notice that your authentication was NOT successfull.

The reason for the wrong encryption is that you reset the IV vector before doing the CBC encryption.
This is correct for legacy authentication but not for ISO and not for AES.

You must set the IV to zeroes ONLY ONCE at the beginning of the authentication function, and then leave it alone.

---

+ 0  |  - 0

[Sébastien Pautet]

Hello,

I managed to authenticate on my side and got the Random A back from the card.
At this point, should I reset the IV for next operation ? if not what is the correct IV ?
I'm trying to read data right after authentication, but I keep having random byte as response.
I'm usign IV 16x00 and Session key for descryption.
Any suggestion ?

Thank you
Seb

---

+ 0  |  - 0

[TapLinx Support]

Hi Sébastien,

It depends on the underlaying cipher how the authentication is implemented. But usually the IV is reset to zero when you start an authentication. Depending on the cipher the IV is updated while authentication. If you get “random values” for your data, the session key generation is wrong.

The TapLinx team

---

+ 0  |  - 0

[Elmue Meister]

Hello Sebastian

The IV is a delicate topic. If you get it wrong the communication will fail.
But apart from that there are much more pitfalls.
It is impossible to answer your question in a few phrases.

I recommend you to have a look of the entire communication process with a Desfire EV1 card which I have published here:
Desfire EV1 communication examples
https://stackoverflow.com/questions/38283998/desfire-ev1-communication-examples

You will also need a working code to see how to do all the encryption stuff works.
I strongly recommend to study the code of my Desfire DoorOpener (electronics and C++ code)
DIY electronic RFID Door Lock with Battery Backup
https://www.codeproject.com/Articles/1096861/DIY-electronic-RFID-Door-Lock-with-Battery-Backup

The code is made for a Teensy processor, but you find in the ZIP file also a Visual Studio project.
You can study the encryption life in Visual Studio if you write a code which simulates the card answers.

Elmü

---

+ 0  |  - 0

[komal shah]

wow good post
free gift card generator and free gift code generator and real gift card generator and online video downloader

---

+ 0  |  - 0

[Author]

Posts