Practical Analysis of HCE Technology

After Google began to release HCE support, a huge response was triggered. Get rid of the dependence of SWP-SIM on operators, get rid of the dependence of eSE on mobile phone manufacturers, its impact on the industrial ecology is self-evident. The prospects and application discussions based on HCE on the Internet are not satisfactory, but there is little technical information. Now we will reveal the HCE through a specific implementation and give a technical understanding.

First, the required environment:

A development environment that supports Android 4.4.2 SDK: it can be an eclipse plug-in or ADT tool. You can go to google's website to download: http://developer.android.com/sdk/index.html. (If you are not sure about the issue, you can search for it on your own)

A mobile phone supporting HCE testing: it can be confirmed that the NFC mobile phone using NXP PN547 as CLF has already connected to HCE. Currently, Sony Xperia Z2 and Samsung Galaxy S5 are available on the market. Xperia Z2 is used in this test. (The CLF chip is not included in the materials released by the mobile phone. it is determined whether the CLF chip of Z2 depends on the disassemble diagram from the Internet)

A reference: http://developer.android.com/guide/topics/connectivity/nfc/hce.html written in very meticulous, I Abstract:

1. HCE works in ISO 7816-4, that is, the ISO-DEP layer. (If You Want To simulate the Mifare label, wash your bed)

2. Command distribution is based on the SelectbyName command taken over by the system, and the HCE service registers with the system's AID. HCE distribution is higher than SE, does not support logic channel, and does not support gp aid partial matching.

3. HCE is started as an Android service and responds to APDU through the interface function. You can configure multiple AID groups. You can configure the type-payment class or other classes. This type is used for system policies in AID conflict. The payment class is set to the default application, while the other class is the UI pop-up selection prompt.

4. When the screen is off, HCE is unavailable. When the screen is locked, you can select support for HCE, or you can choose to prompt the user to unlock and then support it.

5. When the terminal only has HCE without SE, the non-connection parameter of ISO 14443-3 is taken over by Android. The UID uses a random number. Do not use HCE to implement any UID-based idcard.

6. The Open Mobile API cannot access HCE like the access to se.

Then, we start encoding. First, we implement the Service:

package com.broadthinking.hcedemo;import android.nfc.cardemulation.HostApduService;import android.os.Bundle;import android.util.Log;public class MyHostApduService extends HostApduService {private int messageCounter = 0;@Overridepublic byte[] processCommandApdu(byte[] apdu, Bundle extras) {if (selectAidApdu(apdu)) {Log.i("HCEDEMO", "Application selected");return getWelcomeMessage();}else {Log.i("HCEDEMO", "Received: " + new String(apdu));return getNextMessage();}}private byte[] getWelcomeMessage() {return "Hello Desktop!".getBytes();}private byte[] getNextMessage() {return ("Message from android: " + messageCounter++).getBytes();}private boolean selectAidApdu(byte[] apdu) {return apdu.length >= 2 && apdu[0] == (byte)0 && apdu[1] == (byte)0xa4;}@Overridepublic void onDeactivated(int reason) {Log.i("HCEDEMO", "Deactivated: " + reason);}}

ProcessCommandApdu is used to overload the received CAPDU, And the return value of the function is RAPDU. However, the call to this interface uses the main stack of the program. If the processing time is long (for example, cloud-based processing), start the processing thread and return null, and actively call sendResponseApdu to send RAPDU after the processing thread ends.

Continue to configure AndroidManifest. xml in the Android environment:

<?xml version="1.0" encoding="utf-8"?><manifest xmlns:android="http://schemas.android.com/apk/res/android"    package="com.broadthinking.hcedemo"    android:versionCode="1"    android:versionName="1.0" >    <uses-sdk        android:minSdkVersion="19"        android:targetSdkVersion="19" />    <uses-permission android:name="android.permission.NFC" />    <application        android:allowBackup="true"        android:icon="@drawable/ic_launcher"        android:label="@string/app_name"        android:theme="@style/AppTheme" >        <activity            android:name="com.broadthinking.hcedemo.MainActivity"            android:label="@string/app_name" >            <intent-filter>                <action android:name="android.intent.action.MAIN" />                <category android:name="android.intent.category.LAUNCHER" />            </intent-filter>        </activity>        <service            android:name=".MyHostApduService"            android:exported="true"            android:permission="android.permission.BIND_NFC_SERVICE" >            <intent-filter>                <action android:name="android.nfc.cardemulation.action.HOST_APDU_SERVICE" />            </intent-filter>            <meta-data                android:name="android.nfc.cardemulation.host_apdu_service"                android:resource="@xml/apduservice" />        </service>    </application></manifest>

Key points:

User authorization: android. permission. NFC
Service Authorization: android. permission. BIND_NFC_SERVICE
Exported: Must be true
Initent-filter: android. nfc. cardemulation. action. HOST_APDU_SERVICE
Meta-data: Specify service details. For details, see apduservice. xml.

Key points:

You can specify multiple aid-filters to register multiple AID IDs.
Category can be specified as other or payment.
When requireDeviceUnlock is set to false, the screen can be unlocked. If it is set to true, the user is required to unlock the screen.


 Start test:
Download the application to your mobile phone, keep the screen on, put the mobile phone in a non-contact card reader, and send APDU: 00A4040007F0010203040506 or 00A4040007F0394148148100. You will get feedback: decoding, "Hello Desktop!" . The application is successfully selected. If you continue sending an APDU 00010000 Message, you will get feedback: 4D6573736167652066726F6D20616E64726F69643A2030. After decoding, the Message from android: 0 is the ASCII value!


A few words:
Combined with practice, we can see that HCE Technical Support provides a soft path to implement SE. There are many Service implementation methods, including using files, using the network, and even connecting to the real SE. The specific implementation scheme depends on the specific business needs. The hot-selling cloud solution on the Internet is only one of them. I am not optimistic about the cloud-based approach. From the security perspective, the cloud-based approach ensures data security, but how can we ensure the security of client access? From the perspective of ease of use: network-based card swiping time instability is not suitable for public transit and subway scenarios that need to pass quickly. The file-based approach is more suitable for card-integrated businesses with low security levels such as idcard and credit card.
Whether or not cloud-based HCE payment is actually implemented is not understood by myself at the technical level.