Editing Functionality of Host Card Emulation in Android

Editing Functionality of Host Card Emulation in Android

Ok ! So i've found a solution to the problem I was having!

On the Nexus 7, when the NFC is turned on, it gets its information from a config file in "/etc/" called "libnfc-brcm-20791b05.conf"

Inside of this file there is a parameter called "NFA_DM_START_UP_CFG"

By default, it looks like this:

NFA_DM_START_UP_CFG={42:CB:01:01:A5:01:01:CA:14:00:00:00:00:0E:C0:D4:01:00:0F:00:00:00:00:C0:C6:2D:00:14:0A:B5:03:01:02:FF:80:01:01:C9:03:03:0F:AB:5B:01:00:B2:04:E8:03:00:00:CF:02:02:08:B1:06:00:20:00:00:00:12:C2:02:01:C8}

To edit the UID that is generated at Emulation, you need to add some bytes to the end of this parameter.

The first byte you add is 0x33 (This means that you are going to manually set the UID)

The second byte that is added is the length of the UID you wish to set (This can be either 4,7 or 10 bytes, so this second byte can be 0x04, 0x07 or 0x0A)

The next bytes are then the ID you wish to set! (NOTE: Depending on how many Bytes you add, you should change the first byte of the array to reflect the new size of the array - it starts at 42, so if you were to add 6 bytes it should change to 48)

For example, if you wished to set a 7 byte ID of 01 02 03 04 05 06 07, the new config line would look like this:

NFA_DM_START_UP_CFG={4B:CB:01:01:A5:01:01:CA:14:00:00:00:00:0E:C0:D4:01:00:0F:00:00:00:00:C0:C6:2D:00:14:0A:B5:03:01:02:FF:80:01:01:C9:03:03:0F:AB:5B:01:00:B2:04:E8:03:00:00:CF:02:02:08:B1:06:00:20:00:00:00:12:C2:02:01:C8:33:07:01:02:03:04:05:06:07}

You can then push this config file to your nexus device using adb:

-> adb root
-> adb remount
-> adb push libnfc-brcm-20791b05.conf /etc/
-> adb reboot

This will reset the Nexus with the new config file in, and upon emulation the UID will now be set to 01 02 03 04 05 06 07

Hope this helps anyone reading my question!

Host-based Card Emulation, any guidance please?

Before CyanogenMod 11, CyanogenMod supported its own host-based card emulation functionality. You could register a foreground dispatch for the android.nfc.tech.IsoPcdA technology and could then emulate a smartcard by using the IsoPcdA.transceive() method. See Nikolay Elenkov's blog post on how to use this API.

However, browsing through the CyanogenMod 11 source (specifically tht of the NFC service) it seems that this functionality has been dropped in version 11 in favor of Android 4.4's official HCE API.

The official Android 4.4 HCE API permits apps to emulate a contactless smartcard (ISO 14443-4 + ISO 7816-4 APDUs) in an Android service. That service would handle all incoming command APDUs for an application and generate proper response APDUs. See the official API user guide for further information on how to register such a HCE service and this answer on how to handle incoming command APDUs within your HCE service.

Unfortunately this API is not available either on devices that use libnfc-nxp as the low-level NFC stack (see the empty implementation of routeAid() and enableRoutingToHost() in the CyanogenMod 11 source code).

So to summarize this, it seems as if it's currently not possible to do host-based card emulation on a Nexus S with CM 11.

Write in a emulated card Android HCE (Host card Emulation)

The question "How [do I] write in a [Android HCE] emulated card?" does not really match the concept of Android HCE.

With Android HCE you do not emulate a memory card, hence there is no such thing as writing to/reading from such an emulated card by default. Instead, you emulate an APDU based smartcard application (note: application, not memory area, not whole card). APDUs are commands that you can send to a card (for instance with a PC/SC-compliant contactless smartcard reader). These commands are then interpreted by your emulated smartcard application (i.e. your HCE service) and used to generate response messages.

So, to summarize, you define the commands (based on ISO 7816-4 APDU structure) that your application should understand and the response message format (again based on ISO 7816-4 APDU structure) that your application sends back.

HCE - Is there a way to manipulate the ATR?

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

Write NFC-A host-based card emulation for CPR 40.30 reader

Android only supports emulation of ISO/IEC 7816-4 application structures on top of ISO-DEP (ISO/IEC 14443-4). The Android API does not provide any means to access emulation of lower protocol layers.

From the developer guide:

Specifically, Android 4.4 supports emulating cards that are based on the NFC-Forum ISO-DEP specification (based on ISO/IEC 14443-4) and process Application Protocol Data Units (APDUs) as defined in the ISO/IEC 7816-4 specification.

Note that the CPR 40.30 should support ISO-DEP too.

Samsung device nfc mode and host card emulation

My Samsung Device does not have 2 separate NFC modes but does have 2 different NFC capabilities - Emulation a Card or Reading/Writing to a Card. But these capabilities are not mutually exclusive they are enabled together.

It does have 2 locations where Card Emulation can happen, the first being in the NFC's Chip Secure Element (an independent CPU) or on the Host CPU (Hence the term Host Card Emulation).

All card emulation is about emulation of Type 4 NFC vards (Credit cards and similar cards)

Type 4 Nfc cards have an "Application Identifier" number or AID that identifies the format to the card.

Normally the Secure Element handles the AID's first that it has been configure to process before passing them on to the Host CPU. Normally the order of routing of AID's is seamless with Secure Element first, then Host CPU but Samsung does offer settings to change this order.

But

NfcAdapter.isEnabled() says

If this method returns false, the NFC hardware is guaranteed not to generate or respond to any NFC communication over its NFC radio.

My understanding is the UI setting that influences this status is basically a hardware power switch for the NFC chip, if this returns false the chip is turned off and won't do any NFC (Secure Emulation, Host Emulation or reading/writing)

So I would check NfcAdapter.isEnabled() before starting your HCE service.

Making Host Card Emulation work for payment

The first applet that will be selected by a EMV terminal is the PPSE applet, so you can try to add it also to your AID filters:

<aid-filter android:name="325041592E5359532E4444463031"/>

I don't know why you are trying to emulate payment with HCE but this will never be approved by Visa and MasterCard since for EMV transaction you need a cryptographic keys that need to be stored in secure environment. In the best case the HCE can be used for card not present transactions.

---

Related Topics