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
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.
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 :)
Given your situation, i would say Android SDK is more than sufficient to solve your problem.
There are two parts to your case:
Reading the information from the existing cards.
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.
You may want to look at Mifare4Mobile, the initiative set up to transition from Mifare cards to NFC devices:
http://mifare4mobile.org/
Related
I'm posting this question because I couldn't find an appropriate place to ask it.
I'm developing a custom secure element using a smartcard.
I successfully got SEService connected and got a Reader instance using seservice.getReaders().
However, when I called reader.isSecureElementPresent(), it returns false.
When I tried with a normal SIM card, I could find the secure element and it returns true when I called reader.isSecureElementPresent().
So I deduced that the phone can not recognize my custom SIM card which is a native smartcard. Actually my native smartcard works properly with a normal card reader and the card supports ISO/IEC 7816-4 interface with T=0 protocol.
And when I tried with a Java Card, the phone was able to find the card, and get the ATR successfully.
Therefore, the phone can not recognize the native smartcard but the javacard.
Is there a specific requirement for a secure element to be found by isSecureElementPresent() method on Android?
I looked through Open Mobile API 3.3, but there is not enough explanation about the isSecureElementPresent() method.
And I assume that the phone can not find my native smartcard maybe because it does not implement GlobalPlatform Card Specification since the Open Mobile API 3.3 is created by GlobalPlatform organization. And actually the Java Card supports the GlobalPlatform Card Specification. That is why I suppoed so.
This is an interesting questions, although I have no answer I can point out an approach to get hold of some information which I have already used.
2 guesses:
Your SE has no SIM card file system and is not recognized as an UICC
The carrier privileges applet (GP secure element access rules) is missing and maybe it is required
If this does not help here are the links to the sources for further study:
http://aosp.opersys.com/xref/android-10.0.0_r39/xref/frameworks/base/core/java/android/se/omapi/Reader.java
http://aosp.opersys.com/xref/android-10.0.0_r39/xref/frameworks/base/core/java/android/se/omapi/ISecureElementReader.aidl
Unfortunately the AIDL is internal. What I did was in this case to use Magisk and then the edXposed framework. The latter allows to intercept system calls, e.g. for logging purposes. I have written a sample project to unmask response APDUs of the radio log. This can be used for this advise and the next one.
At a lower level level it should also be helpful to see the exchanged APDUs. This should be possible by looking into the radio log with logcat -b radio *:V
Finally also very useful is a SIM card tracer to see how the phone interacts with your SE, e.g. see the APDUs. If some commands are returning errors you have hit a candidate. This should give you the complete control to compare an accepted UICC and your solution.
I have use the previous version of SIMTrace with success, but on older phones. If this is not available search for alternatives or maybe you have an engineer who can solder something together.
I am making a Host Card Emulation app on Android, everything works fine with my PC/SC reader. I am able to send APDU commands and get the reponses. Now I want to know if it's possible to manipulate the ATR of the card emulated by Android using Android's NFC library (or not)? I have looked into the documentation but there's nothing about the ATR, does Android generate it automatically for each device?
Yes, Android generates the answer-to-select (ATS) automatically. There is no Android API to change its contents. The same applies to the anti-collision identifier (UID).
ATS vs. ATR
Note that contactless smartcards (ISO/IEC 14443-4A) do not expose an ATR (answer-to-reset) during the activation sequence. Instead, they provide an ATS (in response to the selection procedure). PC/SC readers for contactless smartcards typically map parts of that ATS into an (emulated) ATR for compatibility.
Rooted devices
Even though Android does not provide an API, you might be able to modify values such as the ATS by modifying the NFC controller configuration files. See Editing Functionality of Host Card Emulation in Android and Host-based Card Emulation with Fixed Card ID
I merely want to emulate a transit card with an Android application using HCE. I'm confused about the AID of the card. Do I have to know what the AID of the card is?
According to Host-based Card Emulation document:
If you are emulating cards for an existing NFC reader infrastructure,
the AIDs that those readers are looking for are typically well-known
and publicly registered (for example, the AIDs of payment networks
such as Visa and MasterCard).
So, what is the point?
P.S. I don't think the AID of my card is well-known. Even if it is, how do I know what it is?
Do I have to know what the AID of a card is for card emulation with Android HCE?
Yes, definitely! The AID is the name of your application. The reader will ask cards (emulated or not) if they contain an application with a certain name and will only communicate with those cards that contain the application that the reader supports.
How do I find the AID (or AIDs) of the applications on a certain card?
The most obvious way: Ask the system owner or manufacturer. If they don't tell you, you most probably should not be fiddling around with emulating the card anyways.
There are, of course, other ways to find out how the card works. Many cards follow some standards. Payment cards, for instance, usually implement EMV protocols. For transport cards there are also several standards, e.g. VDV-KA, ITSO, etc. You could try to find out if the card uses some standard/well-known application by doing some finger-printing (e.g. analyze the card to find out the card type, chip type, chip manufacturer, etc.) and by doing brute-foruce scans (e.g. try to select well-known application AIDs, try to enumerate files on the card, etc.) You should be able to find a couple of free tools that could help you with this.
Is knowing the AID enough to emulate (e.g. using HCE) a certain card
No, certainly not.
First of all, you also need to know and implement the protocol that the reader speaks with the application. While many smartcard applications use common command/response constructs (cf. ISO/IEC 7816-4 inter-industry commands), each application typically uses them in its slightly own way. If the application follows some standard, you can simply implement that standard. If the application uses some proprietary protocol, you are back at asking the system owner/manufacturer or at heavy trial-and-error.
Second, even the AID and the protocol are typically not enough to duplicate and emulate a specific card. Smartcards are usually designed to store some secret to usiquely identify and authenticate a card. These secrets typically cannot be extracted from a card. Hence, you cannot simply transfer that secret data into your HCE application.
Before implementing HCE is good to learn your native card application. At least read ATR/ATS of card to understand the chip manufacture and as second step sniff the communication flow between card and terminal for next analyzing. Google/Search your card solution.
The reason to register your application AID on Android device - to map Card AID to your HCE application.
"NFC TagInfo by NXP" - Android application, is good for quick NFC analyzing.
Card type description from ATR/ATS you can try resolve from ludovic rousseau smartcard list.
Some AIDs (payment cards mostly) listed in EFTlab AIDs collection.
Most important for your implementation is your transit card EMV/NFC communication flow and algorithms behind.
AIDs for Visa, Master card and other known companies are registered. You can find the AIDs in the below Wikipedia link
https://en.wikipedia.org/wiki/EMV
AIDs for the Visa from the above link
Visa - A0000000031010, A0000000032010, A0000000032020, A0000000038010
We have a ACR 1252u NFC card reader. We want to read/write NFC cards on Android with this device. The problem is that this device is not seen as a NFC device but as a USB device instead. Therefore native Android NFC can not be used. Currently we are able to detect the device and to trigger an event by adding or removing a card. But we are neither able to read nor to write a card. In the documentation we found some HEX codes that are transmitted to the device, but we did not figure out how they work in order to read/write cards. Also on the net we found some example codes using other ACR devices but obviously they are not compatible to our one.
I am looking for any working examples in order to get the ACR1252u reading/writing NFC cards on Android.
The reader is a USB CCID (chip card interface device, see http://www.usb.org/developers/docs/devclass_docs/) device. Hence, you need to implement the PC/SC abstraction layer (see http://www.pcscworkgroup.com/specifications/overview.php) or use some ready-made library in order to send smartcard commands to that reader.
So I understand that, in Android, a smart phone can be configured in emulation mode to emulate a given NFC tag. What I'm curious about is whether there is a way to identify an NFC reader through some sort of unique id during the NFC handshake.
For example, let's say I use a few NFC-compatible tags on a daily basis...say a fuel rewards card, my security badge for work, and my major brand credit card. Is it possible to automatically emulate the correct tag based on the reader detected by the phone, so that when I tap at the fuel pump my fuel perks tag is emulated, when I tap the sensor at work my badge is emulated, and when I tap at whatever retail store my credit card is emulated?
Short answer: probably not. Readers do not have unique IDs. They send out polling commands, which are standardized and fixed.
However, contactless smart card systems are often ISO 7816-4 compatible. They support multiple applications on a single card. The readers select the Application IDs of the application they want to interact with. So if all your cards are ISO 14443-4 cards that are ISO 7816-4 compatible, it is (theoretically) possible to combine them into a single card, for example in the secure element of your NFC phone.
Another popular contactless system is MIFARE Classic. The secure element in your NFC phone can very likely emulate a MIFARE Classic card, too. These cards are not ISO 7816-4 compliant, but still have ways of combining multiple applications on a single card (using a so-called MIFARE Application Directory). So if your cards are a collection of ISO 7816-4 compliant cards and MIFARE Classic cards, it is theoretically possible to combine them in the secure element. However, the MIFARE card have limited memory and use secret keys for read and write access, so you cannot read out their content. So even if it may be theoretically possible to combine multiple applications, it may still be impossible in practice.
Very likely, one or more of your cards are not ISO 7816-4 compliant and not MIFARE Classic, but for example MIFARE Ultralight, DESFire or ICODE (to name but a few). You can check what chip is inside with an Android app such as TagInfo.