PN5180 to Mifare Desfire EV3 communication

[c_hahn]

Hello,

I am trying to get a Mifare Desfire EV3 tag to communicate with a PN5180.
The PN5180 is connected through SPI bus to a ESP32 controller module.
I am using a library from the Internet, initially written for EV1 tags and basing on Public documents from NXP.
I also have an NDA with NXP, so I also have various non-public documents.
My library currently activates the EV3 tag, I can read the UID and SAK,
like described in the AN10834-MIFARE ISO/IEC 14443 PICC selection.
As the EV3 tag has bit 6 = 1, I am trying a RATS afterwards.
I get back an ATS value.
The AN10834 states that after the RATS command, the tag enters the ISO/IEC 14443-4 mode.
I've tried many commands in the ISO7816-4 format, but I never get an answer from the PN5180.
The PN5180 register returning the number of readable bytes is always 0

On Linux there is libnfc and libfreefare.
Libfreefare contains a few functions to access my EV3 tag.
Unfortunately there is no support for the PN5180 in libnfc, so I bought an ACR122-USB NCF reader.
This reader bases on the PN532, which has a single command to activate the card and I cannot check,
if my activation code for the PN5180 does the same like the InListPassiveTarget command from the PN532.
I tried the commands that libfreefare sends to the EV3 card, but as I already mentioned, I do not get back an answer.

Sending this commands from the PN532 will get an answer, so I assume the format is correct.
00 a4 04 00 07 d2 76 00 00 85 01 00 - ISOSelectFile: DS487030 doc page 323 – ISO7816-4 format
90 60 00 00 00 - get_version - DS487030 doc page 141 - ISO7816-4 wrapped command
90 45 00 00 00 - get_key_settings - ISO7816-4 wrapped command
90 64 00 00 01 00 00 - get_key_version - ISO7816-4 wrapped command
90 6e 00 00 00 - get free mem - ISO7816-4 wrapped command

Is there any example or extended version of the AN12650-Using the PN5180 without library,
which explains the activation sequence with RATS, Select AID and Authenticate,
like on page 11 of AN12650?
Or a simple example how to use the get_version command from above?

Best Regards

Cajus

[c_hahn · Accepted solution]

Hi all,

I was asked to mark an answer as solution of my problem...

The solution is:

• get all NXP documents first (all usefull documents are available under NDA only, the public documents won't help)
• get ISO14443-3, ISO1444-4 and ISO7816-4
• Main info is in DS487030-MF3D(H)x3 MIFARE DESFire EV3 contactless smartcard IC(3.0).pdf 
  and AN588113-AN12757 MIFARE DESFire EV3 features and hints(1.3).pdf
• Using the public available code for the PN532 (libfreefare) is not helping too much, as the low-level protocol is embedded in that chip, while for the PN5180, this low-level protocol has to be implemented in the host-software. This low-level protocol gave me a hard time.
• The NXP library source code isn't really easy-reading and not useful for a small controller like an ESP32.

I cannot go into more details to respect the NDA conditions.

Best Regards

Cajus

[c_hahn]

I found the root cause for the problems with talking to the MIFARE Desfire EV3: After successful card activation and after successful reception of ATS, the card only communicates with ISO/IEC 14443-4 protocol.

The PN5180 library I have did send the native commands, but not wrap the command in the block format described in the ISO/IEC 14443-4 .

All I needed to do was adding the Prologue field. I only use the PCB byte with 0x02, which marks the following data as "I-block". The Epilogue field (2 byte CRC) do not seem to be required, in another forum message I found that this CRC is created and appended automatically by the PN5180.

The PN532, which I use on Linux together with libnfc and libfreefare, seem to have this block framing embedded, which seems to be one of the major differences between those chips.

But now I am stuck with another issue: If I send the "Format" command (0xFC) to the card (of course after selecting the PICC and authentication), I do not get an answer. The card is supposed to acknowledge the command with 0x00, but I do not get any response at all. I tried with a longer delay between sending the command and checking for a reply, but there is no answer within 80ms, after 80ms I get a response "0xf2 0x01", which is an S-block with WTX and according to the ISO14443-4 the PICC request more time. I do not understand the "Frame waiting time" chapter in the ISO14443-4, nor do have an idea what to do after reception of a S-block with WTX. Do I simply need to wait some more time and try to read a response after a certain time again?

The real big issue is that after such a failed "Format" command my library cannot access the EV3 card with ISO14443-4 framed blocks any more!

Activation and the RATS (with ISO14443-3 commands) works, but any later command  with ISO14443-4 framed blocks will not get an answer. Even releasing the card from the reader or switching off the RF field does not bring the card back to a normal state.

Only way to get such an EV3 card back to work is reading it once with the PN532 reader and libfreefare on Linux. You don't need to call the "Format" command, just do a mifare-desfire-info, which returns some info from the card (by sending some ISO14443-4 commands to the card, exactly the same commands that I send and which do not get a reply ?!)

So there are two questions open now:

How to deal with the FWT (FrameWaitTime) and a s-block with "WTX" ?

What to do to get a EV3 card back to normal operation mode after a failed "Format" command ?

Best Regards

Cajus

[AlexanderB]

Hi @c_hahn ,

in addition to the mentioned application note I want to recommend you have a look into the NXP NFC Reader Library. If you are not using it you might want to give it a try. If not, it is a nice piece of software to take as reference of certain protocol handling.

In general every Layer-4 tag will only communicate with Layer-4. Which requires the PCB (Protocol Control Byte). The CRC is automatically added in all of our reader chips. 
At the PCB you have also to take care of the Block number, which is toggling. 

The WTX (Waiting Time Extension) is a information from the Tag to the reader that it needs more time, as the FWT (Frame Waiting Time), to process whatever command it received before. On the S-WTX request from the Tag you have to answer with a S-WTX response. This can, theoratically, go on forever. 
On your host-controller you have to have also some timer running checking the FWT. If the FWT elapses without you having received any response you have to do error-recovery. 

If you are not familiar with the ISO/IEC 14443-3 & -4 spec I highly recommend to use the NFC Reader Library as it will take care of ALL of that for you. There is also a MIFARE DESFire abstraction layer (phalMfdf.h) where you simply can call whatever command you want by passing a few parameters and the reader library takes care of all underlaying layers, protocols, timings and settings. 

Anyhow as you are working with NFC I also recommend to get familiar with the related specs and the protocol handling of it. 

Best regards,

[c_hahn]

Hi,

thanks for the fast answer.

I've tried to find any hint in the NXP NFC Reader Library, but failed. This library is really huge and unless you know exactly where to search (which file) you are lost.

As mentioned in my first post, my target hardware is an ESP32 module without any operating system. The memory of this tiny processor is very limited and I am in doubt, that the library would fit. I am only targeting MIFARE Desfire EV3 tags (maybe I will use the EV1 compatibility mode, because it is easier to implement) and I only need a few functions. Porting the whole library does not make sense.

If you could point me to the path inside the NXP NFC Reader Library, where I will find the sources for the protocol handling (PCB (Block number toggle), FWT, error-recovery, S-WTX) this would be really helpful.

I have all the documents (ISO/IEC 14443-3 & -4 & 7816-4),  but they are very theoretically. I am missing some use-cases and examples. 

My current issue with the "Format" command looks like a low level issue with the protocol. I don't need that command on the ESP32 target, but I would like to make sure that this issue won't have an impact on other commands as well.

Best Regards

Cajus

[AlexanderB]

Hi,

yes, the library is not small. That is due to the fact it is incoporating all protocols etc... It can be stripped down to whatever you need with a couple of defines. 

The ISO handling you will find in the file "phpalI14443p4_Sw.c" and method "IsoHandling(...)". The method itself is also not small but that is again due to the fact that the iso handling of I-, S- and R-Blocks is actually not that simple. There are a lot of scenarios where you have to react differently; Chaining, Error Recovery, WTX handling, etc... 

If you really need only a handful of DESFire commands and you don't care about compliance and the target is that it works in 'good-case' scenarios the reader library might be too complex. 

Regarding your issue; Did you take care about the correct block numbering of the PCB? The first bit is toggling, after you sent 0x02 and received 0x02 the next frame has to be 0x03. 

The WTX handling has to be implemented as you already received a WTX request. But that you can also easily do quick & dirty by just checking if the PCB indicates a WTX and if it is send back the response. This will loop until a exit condition is met. Either timeout, actual reception of the I-Block response or whatever condition you have foreseen. 

Greetings, Alex

[c_hahn]

Hi,

I solved toggling the block number bit, answering to WTX and I implemented a loop with the correct FWT.

With this extensions, the FormatCard command works.

Authentication for the PICC master key (factory default, brand new chip) seems only to work with DES (8 byte default key). The authentication itself also seem to work with DES3 (24 byte key), but afterwards the CMAC calculation in my controller differs from the CMAC that is returned by the chip. I am not sure, if this is expected or if there is a bug in the CMAC calculation with DES3 (24 byte) keys.

Right now I am fighting with transmission issues during the CreateStdDataFile command.

I either get only parts of the RX CMAC in the return telegram (only 4 byte instead of 8 byte), although the status in the return is 0x00 (Success) or the transmission itself fails, because the BUSY line of the PN5180 will not act as expected: At the end of the SPI read routine (to read back the status telegram of the CreateStdDataFile command), the SPI SlaveSelect line will be set to inactive (high) and then the routine waits until the BUSY line goes low. This isn't happening within 50ms, which is detected as an error.

If you have any hints for the issues above, I would be grateful.

Best Regards

Cajus

[Florian_Mikulik]

Hi @c_hahn,

regarding your question about the DESFire Authentication methods:

Unfortunately, we can not discuss that in detail here, as MIFARE DESFire documentation is only provided via NDA.

but regarding CMAC length: The used secure messaging (D40, EV1 or EV2) is selected by which authentication command you are using (there are 5!). The authentication command is again dependent from the used key type you selected during application creation. I would highly recommend you to use EV2 secure messaging with AES keys and AuthenticateEV2 commands. usage of DES keys (any length) is not recommended anymore byte the NIST, and in my opinion the EV2 secure messaging is also very easy to implement, even easier than EV1.

Please have a look in the DESFire datasheet section 7.3, and in the AN12757 for examples. If you don't have them available, just let me know, i will push via NXP secure files.

Best regards,

Florian

[c_hahn]

Hi Florian,

thanks for the fast reply.

I have both documents and will read them once more. I did not dig deeper in the AN12757

If we cannot discuss this in this forum, maybe there is the possibility of a  direct communication, just in case the AN12757 does not answer my question.

Best Regards

Cajus

[danielchen]

Hi @c_hahn  

MIFARE DESFire family is secured by NDA.  It means all the information and support should be delivered in a secure way.   You can contact NXP via ticket. Please refer to below picture.   I created a case 00492228 for this issue,  maybe you  received an email, you can reply this mail.

  @Florian_Mikulik 

Regards

Daniel

[c_hahn]

Thanks! 

I received an email and also tried to access the ticket through the path from your screenshot.

Currently I cannot login, I always get Login to NXP Case Portal not successful

I filled the form coming with that error message and hopefully your IT can fix this issue.

I've also edited the content of my last post, shortly after I sent it.
Maybe you didn't get this change. I found the Application Note you referenced after taking a deeper look into all the documents I've already downloaded through the Secure Files Area of my NXP account.

Best Regards

Cajus

[danielchen]

Hi @c_hahn 

please register here, then you can access it.

https://www.nxp.com/webapp-signup/register

Regards

Daniel

[c_hahn]

Hi,

The transmission issues during the CreateStdDataFile command came from reading at the wrong time.

I read the RX_STATUS register from the PN5180 in the middle of the reception of incoming data. Then I read the data, assuming that I got all data from the incomming package. This confused the PN5180 as well as my state machine and gave me that stupid errors.

So the only open question is regarding  the authentication for the PICC (application #0) with DES / DES3 and the issues with the CMAC calculation afterwards, when using a 24 byte DES3 key.

Best Regards

Cajus

[AlexanderB]

Hi,
regarding the authentication I will hand over to another expert on this matter.
@Florian_Mikulik 

Best regards,
Alexander

[danielchen]

Hi

I would suggest  you refer to AN 10833: MIFARE type identification procedure. there is figure shows a flow diagram  about MIFARE Card Activation examples. Using GetVersion command to identify the ICs.

https://www.nxp.com/docs/en/application-note/AN10833.pdf

Regards

Daniel