How well does the Android NFC API support Mifare Desfire?

Question

I'm likely to be working on a project where existing Desfire cards (used to access paid services) will be replaced with an NFC-capable mobile device. Can anyone point me to any resources to help me understand what's involved in a) replicating a Desfire card's data onto a mobile device so it can take the place of a card, and b) for the app to deliver NFC data in order to present to the reader as if it were a card. All relevant keys and access will be provided by the card issuer (if the project goes ahead) but I'm keen to understand the process in advance.

I also need to understand how well the Android NFC API supports Desfire, because as far as I can see it only properly support Classic. http://developer.android.com/reference/android/nfc/tech/package-summary.html

Brok

Answer 1

MIFARE DESFire is ISO 14443-4 compliant. Support in Android for ISO 14443-4 (and therefore MIFARE DESFire) is done by the IsoDep class. You can send any DESFire command using the transceive() method of that class.

Besides that, DESFire can be configured to be NFC Forum type 4 Tag compliant. In which case Android will read out automatically any NDEF messages from the tag and dispatch it in an intent. So you can make your app start automatically when a specific tag is scanned. (Android can also format a DESFire chip to contain NDEF and write NDEF data to it.)

Replacing a DESFire card by a mobile NFC device is another matter. Card emulation on currently available Android devices is done by an embedded Secure Element connected to the NFC chip. An Android app cannot emulate a card (there is also no API for this) and the Secure Element cannot emulate a DESFire chip. Furthermore, there is no open API to access the Secure Element from an app.

The only way an Android NFC app can communicate via NFC to another device (that is not a card) is using Android Beam. This is, however, a different protocol than that used between card and reader.

Brandibrandice

Many thanks for the explanation. Are you up for some consultancy (now or in future)? If so please do drop me an email ollie AT novoda.com – Brok

DESFire can't be locked on an Android device. You can read/write them but not lock them. – Auten

There is no such concept as locking with DESFire. You can, however, configure access control using authentication keys for DESFire applications and/or the files in a DESFire application. – Brandibrandice

"Secure Element cannot emulate a DESFire chip" Why is that? What kind of secure element are we talking about? – Fiske

DESFire has its own command set that is not compatible with ISO 7816-4 APDUs, which is typically what a secure element does (e.g. a JavaCard based one). Sending such a DESfire command to such a secure element will typically not be accepted by it. – Brandibrandice

If by "locking" you mean "changing keys".. of course it can be done. Like NFC guys said, you can re-configure access control. You just have to implement the correct desfire command (i.e. find the command code and build the correct PDU) – Nidanidaros

Answer 2

NFC guy answer is excellent, but a bit outdated, so I decided to add an update.

Starting with KitKat (4.4), you can now emulate cards without a secure element.

It is called Host-based Card Emulation (Hce) and with that you can emulate a ISO 14443 type A card.. Like a desfire card.

There are two small caveats:

• your reader must issues, just after polling the "card", a ISO SELECT (aid), with a fixed application id (aid) of your choice. This AID must be registered in your app manifest. Android will intercept this ISO SELECT, read the aid, and call you only if it matches with the one in your manifest. Then you can exchange anything, it does not even have to be ISO APDUs (ISO 14443 encapsulation is done by android). So, for example, if you want to, you can even emulate the challenge response authentication of desfire (0xA0 key_num, 0xAF challenge, 0xAF response, 0x00 session_key)

• you cannot rely on the UID (but you don't, right? This is a bad practice anyway, so no-one does it... right? :) ) because it is random, and it changes constantly (not inside a single session, of course, but...)

We are emulating our desfire cards, and the only change we had to do was to switch from our initial desfire select application (0x5A) to a ISO SELECT (0x00 0xA4 0x04).

Emulating authentication (the challenge-response thing) can be tricky, but we had already done it "the other way around" (using NFC to read desfire cards), so it was easy for us.

And if you rely on the card UID for authentication.. it's a good time to change it :)

Monoicous

Keep in mind that if you want to support a mixed system of (existing) DESFire cards and (new) HCE apps, this can be tricky, because of the differences between the 2. Particularly the need to send an ISO Select to activate an Android HCE app will likely clash with the use of DESFire cards. – Brandibrandice

True, it can be tricky. But the DESFire cards (at least, the EV1 I have here) support a limited set of ISO commands. ISO SELECT is one of them: the card process it correctly. I just had to substitute my first DESFire select (0x5A AID) with an ISO SELECT (0x00 0xA4). The card performed in the same way AND I made android HCE happy :) – Nidanidaros

The problem is that 1) you may not be able to touch your coupler/reader application 2) you have to re-implement all the desfire commands in software.. which may not make sense (why use 0xCD for debit when you have to implement it in sw anyway?) – Nidanidaros

Answer 3

Given your situation, i would say Android SDK is more than sufficient to solve your problem. There are two parts to your case:

1. Reading the information from the existing cards.
2. Making an app with the information you have read from the cards.

Part 1:

Your only worry has to be in reading the DESFire card. If the information in the DESFire card is stored in NDEF format, it makes things even more easy.

Ndef is a class in the SDK which can be used to retrieve the information in NdefMessage type which you can then use to save the retrieved information into your storage facility, be it a local database, or a remote database, or just in the application memory.

The above is under the assumption the card is not protected. If it is, then you have to use transceive function to interact using raw byte communication. This would unlock for the rest of the information to be read. From here you can read the NDEF records.

Part 2: My suggestion is skip the card emulation aspect of it. You are going to hit a wall at some point in time.

If the device that has been reading the card in the existing solution is attached to an android device, then Android Beam is the way to go. Which is nothing but Android App to Android App communication! Android already does the heavy lifting, so most of your work is going to be easy.

The information on the card can be stored as ndef messages and sent through beam, or you can simply create a custom object and send it through.

Daily

Answer 4

You may want to look at Mifare4Mobile, the initiative set up to transition from Mifare cards to NFC devices:

http://mifare4mobile.org/

Glassco

This is proprietary software from NXP. It looks like they even make you sign a NDA-type agreement before using it. Beware, and think twice! – Adze