How can I access a MIFARE DESFire card using an Android phone as NFC reader? I am planning to develop an android application (for payment) on Android phone.
The DESFire operations (Authentication, Read and Write) that I want to perform using the Android phone need a SAM card, I thought I can emulate that SAM card in the phone using HCE.
DESFire/DESFire EV1 cards communicate on top of the ISO/IEC 14443-4 data exchange protocol (ISO-DEP). Therefore, on Android devices, they can be accessed through the IsoDep class. So once you get your tag handle (Tag object), you can instantiate the IsoDep object using:
Tag tag = ... // (e.g. get from NFC discovery intent)
IsoDep isoDep = IsoDep.get(tag);
You can connect to the card and use the IsoDep object's transceive() method to send commands to (and receive responses from) the card:
isoDep.connect();
byte[] response = isoDep.transsceive(command);
You can either use the DESFire native command set, the DESFire APDU wrapped native command set or the ISO/IEC 7816-4 command set (see the DESFire datasheet for more details). Due to known problems with the presence detection on some devices (which automatically sends READ BINARY APDUs to detect if a tag is still available), I strongly suggest to use either the APDU wrapped native command set or the ISO/IEC 7816-4 command set (see this question).
Now, the problematic part is the SAM. A SAM (Secure Access Module) is a secure smartcard chip that holds keys and performs security critical parts of the communication with the DESFire card. You cannot simply "emulate" such a SAM using host-based card emulation. That would not make much sense, as the whole idea of HCE is route communication from contactless smartcard readers through the NFC interface to the (insecure) application processor. Implementing the SAM functionality on the application processor would defeat the whole purpose (i.e. high security level) of a dedicated SAM chip. Moreover, in order to emulate SAM functionality, you would not need HCE as you could directly store the credentials for access to the DESFire card within your application.
An option that you might have is to use a cloud-based secure element approach. Thus, you could have the SAM functionality on a server/in the cloud and route the communication with your DESFire card though your app to that server.
byte[] command = receiveCommandFromBackend(); // receive command from server/cloud over the network
byte[] response = isoDep.transsceive(command);
sendResponseToBackend(response); // send response to server/cloud over the network
To summarize this: You don't need HCE. Depending on your security requirements, you could either store the credentials for access to the DESFire cards within your app (note that an attacker might be able to extract that information) or you could use a cloud-based SE approach to shift the security critical parts to an online backend system (but that would typically require continuous network access during communication with the card).
Yet another approach would of course be to use a local secure element within your device, but that would require that you have access to it which is usually not easy/impossible.
Mifare DESFire is not a standard for payment, you should rely on ISO14443-4 (i.e. ISO7816-4) instead, at least that's what all the big names did. These are also the standards that HCE is based upon. Having a payment system based on DESFire would probably be something very specific. The problem with DESFire is that it is proprietary technology. Developing a payment app using HCE is very challenging in terms of security.
Related
I have few questions when the reader initiates the transaction with NFC emulated payment application using HCE
Does the reader send the PPSE command as with the regular contactless card infrastructure?
Does the host controller respond to PPSE command with the list of AID's from the registered AIDs listed in the routing table?
So after the reader selects the AID, the host controller directs to the right HCE service?
Please correct my understanding on the above concept.
An EMV payment card terminal will not distinguish plastic cards, secure element based cards or HCE emulated cards. In all cases it will speak the same protocol. Actually "protocols" as EMV has several different kernel variants that speak (slightly) different protocols with card applications. But that differentiation is based on application variants and brands (e.g. MasterCard EMV, MasterCard MagStripe, Visa, etc.) and not on form factor/"smartcard" hardware.
So a contactless EMV reader will select the PPSE for any type of card (plastic, SE, HCE, etc.) to detect the actual payment application.
Android does not interpret the PPSE selection command and, consequently, it does not generate or send a list of available payment applications. Note that HCE payment applications are selected by the user through the settings UI and only one payment application can be active/accessible at a time.
It's left up to applications to handle the PPSE. So, typically, a HCE payment application based on EMV standards would register for both, the payment application AID and the PPSE DF name. Note that from a protocol perspective there is no difference between a DF name and an AID, so you can register for it in your host APDU service XML file with an AID filter for the DF name ("2PAY.SYS.DDF01") in its ASCII hexadecimal representation 325041592E5359532E4444463031:
<aid-filter android:name="325041592E5359532E4444463031" />
Consequently, your host APDU service will need to handle the PPSE selection command and respond to it will an FCI that contains the list of EMV payment applications in its discretionary data template.
I would like to write an application where I can store NFC tag on my phone so that NFC readers can access it. For example storing a boarding card on phone so that it can be accessed by NFC reader at the airport. I guess it can be implemented beaming NDEF messages, however in order to do that the phone needs to be on.
My problem is, I need to get it working when phone is off. As per my understanding, the only way is to store the NFC TAG in Secure Element (SE) so that it can be emulated as card. NFC reader's power can be used to access information stored in SE.
Is there anyway I can store my TAG to Secure Element? As per my search so far, there is no way to access SE directly. Following post talks about it, not sure if things are changed since the time it was posted.
NFC card emulation Android
If storing in SE is not possible, is there any other way to store TAGs on the device so that it can be read by NFC reader when phone is off.
Thanks
B
When it is a strict requirement that your emulated card ("NFC tag" is not necessarily the best terminology to use in that context) is accessible while the phone is powered off, then your only option is to use a technology that bypasses the phone's main application processor. Consequently, your only option is to use a secure element.
Accessing the SE: This requires cooperation with either the device manufacturer (for embedded SEs) or the mobile network operator (UICC/SIM card). If you have that cooperation, they will likely be able to give you further advice on how to access their SE. If you don't have that cooperation, then there is pretty much no way to get access to an SE on a production device. (I did not mention the µSD scenario, as this is completely idependent of a device's NFC chipset.)
Other options: All other communication through the NFC interface is performed by the mobile phone's main application processor. Thus, in order to have such capabilities (peer-to-peer data exchange, host card emulation, inverse reader mode) the device needs to be powered on and have its operating system loaded.
Hi I am android developer. I already build android NFC reader and writer and beam. So using writer i can write simple data on NFC tags and with the help of reader I can read data from tag. Using beam I can transmit data between two NFC enabled devices. So till now everything works fine. Now I want to work on NFC payments. I am working on android platform. So my question is that how NFC readers works which are use for payments. Are they work on Beam or our device act as nfc tag for NFC readers and it simply reads data from device.Mean how on device side I conform that this reader is for payments or something else. I read about HCE of android it helps a lot for understanding concept. But I am bit confuse regarding readers concepts and there working scenarios. Is there any one can help me out to understand this things, Need Help. Thank you.
When you talk about payments I assume you refer to payments based on well-known credit card schemes like AmEx, Discover, JCB, MasterCard, VISA, etc. Their payment protocols are standardized in EMVCo. Note that there are other (not that wide-spread) payment schemes that use different approaches.
For the contactless protcols of EMV-based payment cards, they typically follow the following scheme:
ISO/IEC 14443 anti-collision and activation (either Type A or Type B)
ISO/IEC 14443-4 transport protocol
ISO/IEC 7816-4 APDUs
Payment scheme specific command-sets (the reader side for those command sets is standardized in EMVCo's EMV Contactless Specifications for Payment Systems, seperated in 5 different kernels for different credit/debit card schemes)
(In Android's reader/writer mode NFC API terminology, "ISO/IEC 14443 anti-collision and activation (either Type A or Type B)" would be NfcA or NfcB and the combination of "ISO/IEC 14443 anti-collision and activation (either Type A or Type B)" and "ISO/IEC 14443-4 transport protocol" would be IsoDep.)
So the payment terminal (e.g. POS) implements the reader side for the above protocol stack. The user-side payment device (e.g. plastic credit card, mobile phone with virtual credit card) implements the card-side of these protocols.
So to your questions:
Beam (or NFC's peer-to-peer mode) is not involved in these payment card schemes.
NFC's reader/writer mode (as implemented on Android devices) is mostly capable of implementing the payment terminal side of these schemes.
I don't like the term "act as NFC tags" in that context. NFC tags (as defined by the NFC Forum) are pure data containers with read (and optional write) access, where NDEF messages can be stored on. Payment cards, however, are (contactless) smartcards with processing capabilities (i.e. they execute program code), secure data storage and cryptographic capabilities. Besides freely readable static data, they typically also contain program logic that processes requests from the reader side and they also contain secret keys (that can never be read from the card by conventional means) used for signature generation over payment transactions, etc.
Android's HCE facility permits developers to implement the above protocol stack on an Android device. So with HCE and Android device can be put in a mode where it acts as a contactless smartcard and interprets ISO/IEC 7816-4 smartcard commands (APDUs).
I am working on nfc based Identification System. I am storing data on android device and at the time of Identification The nfc reader reads the data from android device for this thing the android device should run in HOST based card emulation based on ISO/IEC 14443-3 and for the deployment the nfc reader send the Application ID to identify service as per Google Developer NFC documentation so how i get the application id for custom application
According to the documentation:
"Specifically, Android 4.4 supports emulating cards that are based on the NFC-Forum ISO-DEP specification (based on ISO/IEC 14443-4)" So you cannot do ISO 14443-3 based HCE using this.
If you are creating a proprietary application using HCE then it is up to you to create the AID used by the reader and registered by the app. You can choose any AID but see this Setting up host card emulation answer for more detail about how to choose the AID to avoid clashes with other apps.
I'm trying to get a better understanding of how the Secure Element on an android phone interacts with a reader in card emulation mode. Any insight to the following questions would be useful.
Theoretically (based on hardware design), is it absolutely necessary to go through the SE when communicating with a reader? If I'm not interested in sending private data, is it possible to "transceive" directly to a reader? If yes, how would that work?
If you do have to go through the SE, conceptually, how does that work? For example, say a reader sends a SELECT AID command...presumably, the android host queries the SE to get the SELECT AID command. If the host wants to respond to the SELECT AID command (assume dynamic responses), does the host send the response back THROUGH the SE? I've read a lot about querying the SE to get info (e.g. ISO 7816-4), but haven't yet understood this final point. How do you send responses to a reader?
This is for current generation NFC chips, the next generation are a bit more flexible:
From the NFC chips point of view, the chip has two different hosts, the Secure Element and the Android host.
The NFC chip also knows which host has opened which operation mode on the NFC chip (e.g. peer-to-peer, reader-modes, card emulation modes etc).
Requests and events that belong to one operation mode will only be send to the host that has opened the operation mode.
For secure elements the most usual 'mobile payment' configuration is that the SE opens card emulation in the NFC chip, and the android hosts opens reader-modes and peer-to-peer.
If an external reader gets detected by the NFC chip all communication will get sent to the SE only. The Android host will not see any of the data exchanged between the SE and the external reader. The android host may however see that an external RF field has been detected at the antenna, so android knows that something is happening.
The software running on the SE usually consists of a small OS that manages multiple applications, parses the SELECT AID command and forwards the requests to whatever application matches with the AID.
The applications running on the SE may decide later to send data to the android host. These events are called transaction events and are a one way communication. The android host is not able to reply to the transaction events sent from the SE.
The android host will also not be able to send data to the SE via the NFC chip. If it wants to communicate with the SE directly, e.g. to install a new application, it has to use another physical connection, usually the sim-card pins or the micro-sd pins.
For completes sake: There are also embedded secure elements that are built into the NFC chip. These don't have any physical connection and the NFC chip allows bidirectional communication between the android host and the SE host.
Theoretically it is not necessary to "go through the SE" when communicating with a reader. If the NFC chip has the capability to generate a card's RF signal (some NFC chips do), the phone can send responses directly to the reader. Of course, you need an API for that to be able to access this functionality from your app. Android ICS does not have such an API (in contrast, BlackBerry OS does have one).