FYI: Solution to the DESfire APDU problem

[micolous]

Looking over your StackOverflow question, it is mentioned the major issue for emulating DESfire is the three flavours of the protocol: "native", "wrapped native" and "pure ISO7816", and that in order for an existing DESfire deployment to work, you'd need to talk one of the latter two protocols and send an ISO7816 SELECT APPLICATION first.

Since your post, there now are a small number of organisations which have rolled out support for DESFire on Android HCE using an SDK called "MIFARE 2GO". This finally gives an opportunity to discover what a real-world DESfire+HCE deployment looks like.

It looks like that these implementations have ISO7816 AIDs prefixed with A000000396 by convention.

There's two ways to get the "correct" AIDs for a particular deployment:

1. Log / sniff the SELECT APPLICATION commands from a "legitimate" reader, or,

2. Pull the Android manifest from a HCE application, and look for the AIDs in the manifest.

Once you've sent a SELECT APPLICATION, it appears that you can talk ISO7816-wrapped DESfire commands just fine.

If I understand the status of things correctly, this should mean that it's possible for this project to actually work, and emulate a card in the DESfire-recommended way.

It should also be possible to proxy card communication using two Android devices, provided that the reader unit supports connection with the ISO7816 SELECT APPLICATION command, one of your Android devices does HCE, and then just plumb the commands over the network.

[jekkos]

What I found is that if you want to use standard android HCE functionality, then you are stuck with the fact that the OS is doing AID routing and is expecting the select prefixes from the reader side to determine which application it wants to talk to. In my case I wanted full control over the APDUs which I obtained by modifying the nfc nxp libraries (and thus had this android AID routing disabled). You can go even further in case you want to change the ATQA and SAK values (whch are used to detect the card brand normally and just constants in AOSP heafer files)

In that case I was able to detect the phone as a DESfire card using the 'native' protocol, which should be the 'hardest' of all three. So depending on what your application speaks it might then also work for the ISO7816 case. This might be easier as you don't need to patch those system libraries.

I just managed to build only those libs and replaced them on a rooted phone. It's not that much work after you found out how to run the AOSP build system (but it's quite a lot of source code after all)

[jekkos]

In fact what I wasn't able to test further is the session key authentication step that is actually done to read files and directories on the card.

I did develop the crypto for it based on various 'communication' examples I found on the internet and also the code in libfreefare, but never tested it with the actual setup I wanted to use it for. You can find some unittests based on those communication logs in this project.

So but to test it I had to ask them to actually 'program' this app with the private key they had, which would come down to asking them to give me a hard copy (as then I would have had to store it insecurely inside of my app instead of having it on a SE or something).