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.
Related
Mifare DESFire communication is routed to HCE instead off-host (UICC) on several Android devices.
From OMAPI based communication with off-host secure elements, I already learned how to add AIDs to Android off-host routing table, so that I can select them on UICC. (Thanks to #MichaelRoland)
My current problem: I do have a virtual Mifare DESfire card on my UICC. Now some devices do not route my native wrapped Mifare commands to the UICC and I still do not have a switch to change the default routing. So I wanted to have another entry in my off-host routing table, but I do not know which AID to use.
There is a PICC application AID of our MIFARE DESFire test application F01010. This is the AID that is used for selecting the application on CLT interface, but this cannot be entered to Android off-host routing table. In addition, we have two additional AIDs related to the MIFARE DESFire application. This is the Virtual Card Manager AID (A0000003964D344D1400000000000000) and the Service Manager AID (A0000003964D344D2400000000000000).
But which AID do I have to insert into the routing table?
Android (and probably the NFC controllers themselves) currently only supports routing configuration based on ISO/IEC 7816-4 AIDs/DF names. You can't add routing for native DESFire AIDs (i.e. those 3 byte AIDs) nor for all native wrapped communication.
What you can do:
Assign your DESFire applications an ISO/IEC 716-4 DF name during application creation. This DF name is an AID that can be specified in the Android off-host routing configuration. However, you need to use the DESFire ISO command set (and specifically issue a SELECT FILE (by DF name) command to select your DESFire application) to trigger the AID based routing.
DESFire EV1 itself has the AID/DF name D2 76 00 00 85 01 00. If your reader selects this AID (using a SELECT FILE (by DF name) command), the DESFire card will switch to ISO framing (ISO commands and wrapped native commands allowed) and select its master file. You can register this AID with Android to route all DESFire communication to the UICC. However, each reader needs to start the DESFire communication by sending that SELECT FILE command.
you have to follow the ISO7816-5 link, if you want to deploy your app in a broad way to get no conflicts between apps which use the same AID. Second way is just to use a Proprietary non-registered AID which always starts with 0x0F.
example: 0x0F, 0x11, 0x22, 0x33, 0x44
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.
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'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).
When somebody purchases something and pays with google's NFC payment system (google wallet) , is the phone sending information to the register (if yes, what?) or is it just receiving the cashier's ID code, and then completing the transaction online (like dwolla)?
-gk
during the payment the phone behaves exactly in a the same way as a contact-less payment plastic card (it is based on same ISO/IEC standards). Phone works in so called 'card-emulation' mode. The card is emulated in the secure element, which is highly protected chip. This chip can be so-far programmed only by Google or Samsung. Only those two manufacturers or possibly highly trusted 3rd party (currently I am not aware of any) companies have the possibility to use the build-in NXP SmartMX secure element. It means that nobody else can develop similar application like Google Wallet.
You can of course use other NFC HW for payment - the SIM card, but then you must deal with MNOs (Android SDK does not support the SWI officially), bluetooth NFC sticker or NFC SD card or SD card connected with NFC antenna via NFC-WI (S2C). Note that the last option is the best one, but is not supported by any phone.
You can also invent some proprietary payment system, which is less secure or which uses different schema like e.g. NFC PayPal application, which does not use the secure element, but the peer-to-peer mode for communication between phones. In this application the NFC is just the bearer to transport information - they can do the same over bluetooth or WiFi.
BR
STeN