基于主机的卡仿真(Host-based Card Emulation)能提供NFC功能很多Android手机已经支持NFC卡模拟。在大多数情况下,该卡是由设备中的单独的芯片仿真,所谓的安全元件。由无线运营商提供了许多的SIM卡还包含一个安全元件。 安卓4.4引入卡仿真的附加方法,该方法不涉及安全元件,称为基于主机的卡模拟。这允许任何Android应用程序来模拟卡,并直接与NFC读取器。本文档介绍了如何基于主机的卡仿真( HCE )适用于Android和如何使用这种技术开发的应用程序,模拟的NFC卡。 带安全元件的卡仿真(Card Emulation with a Secure Element)当采用安全元件提供的NFC卡仿真,要被仿真的卡是通过Android应用程序配置到该设备上的安全元件。然后,当用户将设备放在一个NFC终端上,在设备安卓设备上的NFC控制器转发所有数据直接从读卡器到安全元件。图1示出了这一概念。 图1.卡仿真与安全元件 安全元件本身进行与NFC终端的通信,安卓应用程序并没有参与通信,通信结束后,安卓应用程序可以直接查询安全元件的通信状态,并通知用户。 基于主机的卡仿真(Host-based Card Emulation)当使用基于主机的卡仿真模拟的NFC卡,这些数据被传输到运行在安卓应用程序上的主机CPU,而不是NFC协议的帧传输到安全元件上,图2说明了如何基于主机的卡仿真 图2,NFC卡仿真没有安全元件。 支持NFC卡和协议(Supported NFC Cards and Protocols)NFC标准提供了许多不同协议的支持,并且不同类型的卡可以仿真。
图3.安卓的HCE协议栈 HCE服务在安卓上HCE架构师基于安卓的服务组件(称为“HCE services”)。一个服务的主要优点是,运行在后台没有任何用户界面。对于许多HCE应用这是很适合的,如忠诚或公交卡,用户不需要启动应用程序来使用它,相反,NFC读卡器启动相应的服务(如果尚未运行),并在后台执行通信,当然,你可以自由地从服务启动额外的用户界面(如用户通知),如果是有意义的。 服务选择(Service selection)当用户点击一个设备的NFC读卡器,安卓系统需要知道NFC读卡器实际上想要那些服务通信,这就是ISO / IEC 7816-4规范进来:它定义了一种方法来选择应用,围绕应用ID(AID )为中心。一个AID最多由16个字节,如果你仿真卡用一个现有的NFC读卡器设备,这些读卡器都在寻找通常是众所周知的公开注册的(例如如Visa和MasterCard的AIDS)。
AID组(AID groups)在某些情况下, HCE服务可能需要注册多个设备,以实现一个特定的应用程序,它需要确保它是默认的处理程序,对于所有的这些AIDs(如在一个组的一些AIDs到其他的服务)。
AID组和类别(AID groups and categories)每个AID组能够和一个类别关联起来,这样就允许安卓把HCE服务按照类别组织在一起,而这又使用户可以在类级别而不是AID级别设置的默认值。一般情况下,避免在你的应用中的任何面向用户部分提及AIDs:AIDs对于普通用户而言没有意义的。
检查HCE支持您的应用程序可以检查设备是否支持HCE通过检查FEATURE_NFC_HOST_CARD_EMULATION功能。您应该使用<uses-feature>标记在你的应用程序的清单中声明你的应用程序使用HCE功能,以及它是否是必需的应用程序功能或没有。 服务实现安卓4.4自带的,可以用来作为实现HCE服务的基础便利服务类:HostApduService类。因此,第一步是要继承HostApduService 。 1 public class MyHostApduService extends HostApduService { 2 @Override 3 public byte[] processCommandApdu(byte[] apdu, Bundle extras) { 4 ... 5 } 6 @Override 7 public void onDeactivated(int reason) { 8 ... 9 }10 } HostApduService 声明了两个需要重写和实现的抽象方法,如上面代码所示。
服务清单申报和AID注册(Service manifest declaration and AID registration)您的服务必须在manifest像往常一样进行声明,但一些额外的块必须被添加到服务声明。
<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> 这个元数据标签指向一个apduservice.xml文件。如下: <host-apdu-service xmlns:android='http://schemas./apk/res/android' android:description='@string/servicedesc' android:requireDeviceUnlock='false'> <aid-group android:description='@string/aiddescription' android:category='other'> <aid-filter android:name='F0010203040506'/> <aid-filter android:name='F0394148148100'/> </aid-group></host-apdu-service> 该<host-apdu-service>标签必须包含一个含有可能在用户界面显示该服务的用户友好描述一个<android:description>属性。该requireDeviceUnlock属性可以用来指定该设备必须解锁之前,这项服务可以被调用来处理APDU的。
AID冲突的解决(AID Conflict Resolution)多个HostApduServicez组件可以安装在一台设备上并在同一AID可以由一个以上的服务进行注册。安装平台解决AID冲突依赖于AID属于哪个类别。每个类别都可能有不同的冲突解决策略。 检查如果你的服务是默认(Checking if your service is the default)应用程序可以检查自己的HCE服务是否是某一类的默认服务使用isDefaultServiceForCategory (单元名,字符串)的API 。 支付应用(Payment Applications)安卓认为,有“payment”类别的一个已宣布的AID组作为支付应用服务。而Android 4.4版本包含所谓的“挖掘与支付”顶层设置菜单项,其中列举了所有此类支付应用程序。在这种设置菜单,用户可以选择当一个支付终端被触发,将调用默认的支付应用。 支付应用程序所需的资源为了提供更视觉吸引力的用户体验,HCE支付应用程序必须为他们的服务提供一个额外资源:所谓服务的一面旗帜。 <host-apdu-service xmlns:android='http://schemas./apk/res/android' android:description='@string/servicedesc' android:requireDeviceUnlock='false' android:apduServiceBanner='@drawable/my_banner'> <aid-group android:description='@string/aiddescription' android:category='payment'> <aid-filter android:name='F0010203040506'/> <aid-filter android:name='F0394148148100'/> </aid-group></host-apdu-service> 屏幕关闭和锁屏行为(Screen Off and Lock-screen Behavior)当该设备的屏幕被关闭时,目前安卓实现NFC控制器和应用处理器完全关闭,当屏幕关闭的时候,HCE服务将要不起作用。
与安全元件共存卡(Coexistence with Secure Element Cards)本节感兴趣的开发人员已经部署的应用程序依赖于一个安全元件卡模拟,安卓的HCE实现并行设计工作与其他的方法实现卡模拟,包括使用安全元件。
这种共存是基于一个原则称为:“AID routing”:NFC控制器保持一个路由表,由一个(有限)的路由规则列表,每个路由规则包含一个AID和目的,目标可以是主机CPU ( Android应用程序正在其上运行) ,或连接的安全元件。
图4.安卓操作安全元件盒host-card仿真 NFC控制器通常还包含一个默认的APDUs路由,如果一个AID在路由表中没有发现,这个默认的路由表被使用。从安卓4.4开始,默认的路由需要设置到主机CPU中。这意味着,路由表通常只包含需要到一个安全元件的AIDs。
安全元件AID注册(Secure element AID registration)使用一个安全元件来卡仿真的应用程序可以再其清单中声明一个所谓的“off host service”,这种服务的声明几乎和声明一个HCE服务一样,不同点: <service android:name='.MyOffHostApduService' android:exported='true' android:permission='android.permission.BIND_NFC_SERVICE'> <intent-filter> <action android:name='android.nfc.cardemulation.action.OFF_HOST_APDU_SERVICE'/> </intent-filter> <meta-data android:name='android.nfc.cardemulation.off_host_apdu_ervice' android:resource='@xml/apduservice'/></service> 相应的apduservice.xml文件注册AID的一个例子: <offhost-apdu-service xmlns:android='http://schemas./apk/res/android' android:description='@string/servicedesc'> <aid-group android:description='@string/subscription' android:category='other'> <aid-filter android:name='F0010203040506'/> <aid-filter android:name='F0394148148100'/> </aid-group></offhost-apdu-service> android:requireDeviceUnlock 属性不适合于关主机服务,因为主机CPU不参与交易。因此不能防止安全元件从执行交易时,该设备已被锁定。
关闭主机服务调用(Off host service invocation)Android的本身永远不会启动或绑定到声明为“关主”的服务。这是因为实际的交易由安全元件,并且不执行安卓服务本身。这个服务声明只是允许应用程序在安全元件上注册AIDs。 HCE和安全(HCE and Security)HCE架构本身提供一个核芯片的安全性:因为你的服务是由BIND_NFC_SERVICE系统权限保护,只有操作系统可以结合并与您的服务进行通信。这可以确保您收到任何APDU实际上是由操作系统从NFC控制器收取的。你回发的任何APDU仅会去操作系统,这反过来又直接转发的APDU到NFC控制器。
协议参数和细节(Protocol parameters and details)这部分是对于开发人员,想了解协议参数HCE设备使用期间防撞和NFC的激活阶段协议。这允许建立一个基础设施,与安卓HCE设备兼容。
ISO-DEP激活(ISO-DEP activation)之后, NFC -A协议被激活时,ISO -DEP协议激活由NFC读取器启动。它发出一个'RATS' (Request for Answer To Select) 命令,RATS响应,该ATS ,完全由NFC控制器产生,而不是由HCE服务配置。然而, HCE实现都必须满足ATS服务响应NFC格式的要求,因此NFC读写器可以对这些参数按照任何HCE设备NFC规定被设置计数。
APDU的数据交换(APDU data exchange)如前所述, HCE实现只支持一个单一的逻辑通道。尝试选择不同的逻辑通道的应用将不是一个HCE设备上工作。 |
|
来自: kadiwinyang > 《通讯,网络,计算机信息》