标签：
Host-based Card Emulation
许多提供NFC功能的Andr??oid手机已经支持NFC卡模拟。在大多数情况下，该卡是由在该装置的单独芯片仿真，称为安全元件。无线运营商提供了很多的SIM卡还包含一个安全元件。
Android 4.4系统的介绍卡仿真的一个额外的方法，不涉及安全的元素，称为基于主机的卡仿真。这允许任何Android应用程序来模拟卡，并直接交谈的NFC读取器。本文介绍了基于主机的卡模拟（HCE）如何适用于Android以及如何开发模拟使用这种技术的NFC卡的应用程序。
卡仿真与安全元素
当使用一个安全元件提供的NFC卡模拟，要被模仿的卡通过Android应用程序供应到设备上的安全元件。然后，当用户将器件保持在的NFC终端中，NFC控制器在设备路由来自读取器直接到安全元件的所有数据。图1示出了这个概念。
图1. NFC卡模拟与安全元件。
安全元件本身执行与NFC终端的通信，并且没有Android应用是参与交易的。该交易完成后，Android应用程序可以直接查询安全元件的交易状态，并通知用户。
基于主机的卡仿真
当NFC卡使用基于主机的卡模拟仿真，数据被路??由到其上Android应用直接运行的主机的CPU，而不是路由NFC协议帧的安全元件。图2显示了基于主机的卡仿真如何工作的。
图2. NFC卡模拟没有一个安全元件。
支持NFC卡和协议
图3. Android的HCE协议栈。
在NFC标准提供许多不同的协议的支持，并且有可模拟不同类型的卡。
Android 4.4系统支持多种协议，今天在市场上很常见。许多现有的非接触式卡已经根据这些协议，如非接触式支付卡。这些协议也被当今市场上的许多读者NFC，包括Android NFC设备作为读者工作本身（见IsoDep类）的支持。这使您可以构建和部署各地HCE只使用Android手机的终端到终端的NFC解决方案。
具体地，机器人4.4支架模拟卡，基于NFC的论坛的ISO-DEP规范（根据ISO / IEC 14443-4）和如在ISO / IEC 7816-4规格定义的过程的应用协议数据单元（PDU）。 Android的授权只在NFC-A（ISO / IEC 14443-3 A型）技术之上模仿ISO-DEP。对于NFC-B（ISO / IEC 14443-4 B型）的技术支持是可选的。所有这些规范的分层显示在图3中。
HCE服务
在Android上的HCE架构基于Android的左右Service组件（称为“HCE服务”）。一个的服务的主要优点是，它可以在没有任何用户界面的后台运行。这是天作之合许多HCE应用，如忠诚或过境卡，与用户应该不需要启动的应用程序来使用它。相反，轻敲设备对NFC读取器启动正确的服务（如果没有运行），并在后台执行事务。当然，你可以自由地从服务推出更多的UI（如用户通知）如果是有道理的。
服务选择
当用户点击一个设备的NFC读写器，Android系统需要知道HCE服务的NFC读卡器居然想跟。这就是ISO / IEC 7816-4规格进来：它定义了一种方法来选择应用程序，围绕一个应用程序ID（AID）居中。援助最多由16个字节。如果你是模拟卡现有的NFC阅读器的基础设施，艾滋病，这些读者都在寻找一般知名及公开注册的（例如，支付网络，如Visa和万事达卡的艾滋病）。
如果你想为自己的应用程序部署新的基础设施的读者，您将需要注册自己的AID（S）。艾滋病的注册过程在ISO / IEC 7816-5规范中定义。谷歌建议，如果你正在为Android部署HCE申请注册一个AID按7816-5，因为这将避免与其他应用程序冲突。
援助团体
在一些情况下，HCE服务可能需要注册多个艾滋病实现一定的应用，它需要以确保它是所有这些艾滋病的默认处理（相对于该组中的一些艾滋病到另一个服务） 。
一个AID基是艾滋病的列表应被视为由OS一起属于。对于AID组中的所有艾滋病，Android的保障下列之一：
该组中的所有艾滋病被路由到该HCE服务
该组中没有艾滋病被路由到这个HCE服务（例如，由于用户优选的哪个请求的一个或多个艾滋病的组中的另一个服务以及）
换句话说，没有中间状态，其中，该组中的某些助剂可以被路由给一个HCE服务，一些到另一个。
援助团体和类别
每个AID基团可与一个类别相关联。这使得Android的分组HCE服务结合在一起按类别，而这又使用户可以在类别级别而不是AID级别设置默认值。一般情况下，避免在您的应用程序的任何面向用户的部分提的艾滋病：他们并不意味着任何普通用户。
Android 4.4系统支持两类：CATEGORY_PAYMENT（包括行业标准的支付应用程序）和CATEGORY_OTHER（对于所有其他应用HCE）。
注意：只有一个在CATEGORY_PAYMENT类别AID基团可以在该系统中的任何给定的时间被激活。通常情况下，这将是了解主要的信用卡支付protcols并可以在任何商户工作的应用程序。
对于闭环支付应用程序，只在一个商人的工作（如储值卡），你应该使用CATEGORY_OTHER。此类别中的AID团可以是总是活动的，并且可以在必要时通过NFC阅读器的AID选择期间给予优先权。
实现一个HCE服务
要使用基于主机的卡仿真模拟的NFC卡，你需要创建一个处理NFC交易服务组件。
检查HCE支持
您的应用程序可以检查通过检查FEATURE_NFC_HOST_CARD_EMULATION功能的设备是否支持HCE。您应该使用<用途特征>标签在你的应用程序的清单，宣布你的应用程序使用HCE功能，它是否需要为应用程序的功能或没有。
服务实现
Android 4.4系统配备了便民服务类，它可以被用来作为一个基础，实现HCE服务：HostApduService类。
因此，第一步骤是扩展HostApduService。
public class MyHostApduService extends HostApduService {
@Override
public byte[] processCommandApdu(byte[] apdu, Bundle extras) {
...
}
@Override
public void onDeactivated(int reason) {
...
}
}
HostApduService声明需要重写和实施两个抽象方法。
流程CommandApdu（）当一个NFC读写器发送一个应用协议数据单元（APDU）到您的服务调用。的APDU是在ISO / IEC 7816-4规格定义为好。 APDU的是NFC读写器和您的HCE服务之间交换的应用级的数据包。这种应用层协议是半双工的：在NFC读写器会送你一个APDU命令，它会等待你的回报发送响应APDU。
注：ISO / IEC 7816-4规范还定义了多个逻辑通道，在那里你可以在不同的逻辑通道多路并行APDU交换的概念。然而，Android的HCE实现只支持一个单一的逻辑通道，所以有唯一的APDU单线程交流。
正如前面提到的，Android使用的AID来确定读者想与哪个HCE服务。典型地，第一APDU的NFC读取器发送至设备是一个“SELECT AID”APDU;这个APDU包含了读者想要交谈的帮助。 Android的提取从APDU AID，它解析为HCE服务，那么APDU到解决服务前锋。
您可以通过从processCommandApdu返回响应APDU的字节发送响应APDU（）。注意，此方法将您的应用程序，它不应该被阻止的主线程中调用。所以，如果你不能马上计算并返回响应APDU，返回null。然后，您可以做另一个线程必要的工作，并使用在HostApduService类中定义的sendResponseApdu（）方法来发送响应，当你完成。
Android将保持从读者服务的新转发的APDU，直到：
在NFC读取器发送另一个“SELECT AID”APDU，该操作系统解析为不同的服务;
在NFC读写器和设备之间的NFC链路中断。
在这两种情况下，你的类onDeactivated（）实现调用参数指示哪个两个发生了。
如果您正在使用现有的基础设施读者工作，你需要实现现有应用级协议，读者在你的HCE服务的期望。
如果您正在部署，你控制，以及新的读者基础设施，您可以定义自己的协议和APDU序列。一般试图限制的APDU的量和需要被交换的数据的大小：这使得确保用户将只需要在NFC读取器持有他们的设备的时间短量。一个理智的上限是数据，这通常300ms以内进行交换约1KB。
服务清单申报和登记AID
你的服务必须在清单照常被声明，但一些附加件必须被添加到该服务声明为好。
首先，要告诉这个平台，这是实现HostApduService接口的HCE服务，您的服务声明必须包含SERVICE_INTERFACE操作的意图过滤器。
另外，告诉这是由该服务要求艾滋病群体平台，SERVICE_META_DATA <元数据>标签必须包含在服务的声明，指出有关的HCE服务的附加信息的XML资源。
出口属性设置为true，并要求在服务声明中的“android.permission.BIND_NFC_SERVICE”权限：最后，你必须在Android设置。前者可以确保该服务可以通过外部应用程序绑定。后者则强制执行该举办“android.permission.BIND_NFC_SERVICE”只允许外部应用程序可以绑定到你的服务。由于“android.permission.BIND_NFC_SERVICE”是一个系统的权限，这有效地强制执行，只有Android操作系统可以绑定到你的服务。
这里有一个HostApduService舱单申报的例??子：
<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>
这种元数据标记指向一个APDU service.xml文件。与含有两个专有艾滋病单个AID组声明这样的文件的一个例子如下所示：
<host-apdu-service xmlns:android="http://schemas.android.com/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>
他<主机-APDU服务>标签必须包含<安卓说明>包含了可以在用户界面中显示的服务的用户友好的描述属性。该requireDeviceUnlock属性可以用来指定设备必须解锁之前该服务可以被调用来处理APDU的。
在<主机-APDU服务>必须包含一个或多个<援助团>标记。每个<援助团>标签要求：
包含一个机器人：包含AID组的一个用户友好的描述，适合在UI显示描述属性。
有它的android：类属性设置为指示AID集团所属，例如类别通过CATEGORY_PAYMENT或CATEGORY_OTHER定义字符串常量。
每个<援助组>必须包含一个或多个<援助滤波器>标记，每个都包含一个帮助。援助必须以十六进制格式指定，并包含偶数个字符。
最后要注意，你的应用程序也需要持有NFC权限才能作为HCE服务注册。
AID解决冲突
多个HostApduService部件可以被安装在单个设备上，和相同的AID可以由一个以上的服务进行注册。 Android平台的解决依赖于哪一类援助属于AID冲突。每个类别可以有不同的解决冲突的政策。
例如，对于一些类别（例如支付）的用户能够在Android设置界面，选择默认服务。对于其他类别的政策可能是总是问这服务是在发生冲突时要调用的用户。要查询某一类的解决冲突的策略，请参阅getSelectionModeForCategory（）。
检查，如果你的服务是默认
应用程序可以检查通过使用isDefaultServiceForCategory（单元名，字符串）的API的HCE服务是否为特定类别的默认服务。
如果您的服务是不是默认的，可以要求其进行预设。见ACTION_CHANGE_DEFAULT。
支付应用程序
Android的认为，已经宣布的“支付”类别作为支付应用的AID组HCE服务。而Android 4.4版本包含被称为“感应付款”顶层设置菜单项，其中列举了所有此类支付应用。在此设置菜单中，用户可以选择当一个支付终端被窃听，将调用默认的支付应用。
支付应用所需的资产
为了提供更加视觉吸引力的用户体验，HCE支付应用都需要为他们提供服务的额外资产：所谓服务的一面旗帜。
该资产的大小应260x96 DP，可在您的元数据的XML文件中加入了android指定：apduServiceBanner属性添加到<主机-APDU服务>标签，它指向绘制资源。一个例子如下所示：
<host-apdu-service xmlns:android="http://schemas.android.com/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>
屏幕关闭和锁定屏幕行为
目前Android实现打开在NFC控制器和应用处理器完全关闭时，设备的屏幕被关闭。当屏幕处于关闭状态HCE服务会因此无法正常工作。
HCE服务可以但是锁屏功能：在requireDeviceUnlock属性<主机-APDU服务>您HCE服务标签：这是由机器人控制的。缺省情况下，不要求设备解锁，并且即使该设备被锁定的服务将被调用。
如果你设置了android：requireDeviceUnlock属性为“true”为您服务HCE，Android将提示用户解锁，当你点击一个选择被解析为您服务援助的NFC阅读器的设备。解锁之后，Android将显示一个对话框，提示用户再次点击即可完成交易。这是必要的，因为用户可能会以解锁移动该设备远离NFC阅读器。
共存安全元素卡
这部分是已部署了赖以卡仿真的安全元件上的应用程序开发人员的兴趣。 Android的HCE实现设计平行实施卡模拟的其他方法，包括使用安全元件的工作。
注意：Android不用于与安全元件本身直接通信提供的API。
此共存是基于一个所谓的“AID路由”的原则：在NFC控制器保持一个包含的路由规则（有限的）列表的路由表。每个路由规则包含一个AID和目标。目标可以是主机CPU（如Android应用程序正在运行），或连接的安全元件。
当NFC读写器发送一个APDU一个“SELECT AID”中，NFC控制器解析它，并检查是否艾滋病在其路由表中的任何引援。如果匹配，该APDU和其后的所有的APDU将被发送到与AID相关联的目的地，直到另一个“SELECT AID”APDU被接收或在NFC链路断开。
注意：在ISO / IEC 7816-4定义“部分匹配”的概念，那么，这是不是目前由Android HCE设备支持。
这种架构在图4中示出。
图4. Android的既安全元件和主机卡仿真运行。
该NFC控制器通常还包含APDU的默认路由。当在路由表中没有找到一个AID，则使用缺省路由。与Android 4.4开始，需要默认路由设置为主机CPU。这意味着，在路由表通常仅包含该需要去的安全元件艾滋病条目。
实现一个HCE服务或使用的安全元件不必担心配置路由表的Andr??oid应用程序 - 由Android的自动照顾。机器人仅仅需要知道哪个助剂可以由HCE服务来处理和哪些可以通过安全元件来处理。在此基础上的服务的安装和用户已配置为优选的，路由表被自动配置。
我们已经介绍了如何申报艾滋病HCE服务。以下部分说明如何声明艾滋病使用安全元素为卡仿真应用。
安全元件AID登记
使用卡模拟的安全元件的应用程序可在其清单中声明一个所谓的“关主机服务”。这种服务的声明几乎是相同的一个HCE服务的声明。例外的是：
在意向滤波器中使用的动作必须被设置为SERVICE_INTERFACE。
元数据的名称属性必须设置为SERVICE_META_DATA。
元数据的XML文件必须使用<脱离主机-APDU服务>根标签。
<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>
相应的APDU service.xml文件注册二援助的一个例子：
<offhost-apdu-service xmlns:android="http://schemas.android.com/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不参与交易，因此无法阻止执行交易安全元件时，该设备已被锁定。
Android的：apduServiceBanner属性必须被用于那些支付应用，以及，以便选择作为默认支付应用关闭主机服务。
关闭主机服务调用
Android的本身永远不会启动或绑定到被声明为“关主”的服务。这是因为实际的事务是由安全元件，而不是由在Android服务本身执行。该服务声明只是允许应用程序注册艾滋病存在的安全元素。
HCE和安全
该HCE架构本身提供了一个核心片的安全性：因为你的服务是由BIND_NFC_SERVICE系统权限保护，只有操作系统可以结合并与您的服务进行通信。这可确保您收到任何APDU实际上是一个由来自NFC控制器操作系统收到APDU，任何APDU你送回只会去操作系统，这又直接转发的APDU到NFC控制器。
核心剩下的部分是你在哪里得到你的数据，你的应用程序发送到NFC阅读器。这是分离有意在HCE设计：它并不关心那里的数据从何而来，它只是确保它安全地运送到NFC控制器和输出到NFC阅读器。
为了安全地存储和检索，你想从你的HCE服务发送的数据，就可以了，例如，依靠Android应用程序沙箱，它从其他应用程序隔离应用程序数据。有关Android安全的更多详细信息，请阅读安全提示。
协议参数和细节
这部分是为希望了解什么协议参数HCE设备中的NFC协议的防碰撞和激活阶段使用的开发人员的兴趣。这样就可以建立一个阅读器的基础设施，与Android HCE设备兼容。
NFC-A（ISO / IEC 14443 A类）协议，防冲突和激活
随着NFC-A协议激活的一部分，多个帧交换。
在这次交易中HCE设备将展示其UID的第一部分; HCE设备应当被假定为具有随机UID。这意味着，在每一个抽头，即呈现给读者将UID将随机生成的UID。正因为如此，NFC读取器不应该依赖于HCE设备的UID作为认证或识别的一种形式。
该NFC阅读器可以通过发送一个命令SEL_REQ随后选择HCE设备。该HCE器件的响应SEL_RES将至少有6位（0x20的）集，表示该设备支持ISO-DEP。注意，在SEL_RES其它位可以被设置为好，指示为NFC-DEP（P2P）协议示例的支持。因为其他位可设置，想与HCE设备进行交互的读者应该明确检查仅第6位，而不是完整的SEL_RES用0x20的值进行比较。
ISO-DEP激活
在NFC-A协议被激活后，将ISO-DEP协议激活由NFC读取器启动。它发出了一个“老鼠”（请求应答来选择）命令。的大鼠的反应中，ATS，完全是由NFC控制器产生，而不是由HCE服务配置。然而，HCE实现都必须以满足ATS响应NFC论坛的要求，因此NFC读者可以对这些参数按照任何HCE设备NFC论坛的要求被设置计数。
以下部分提供了一个HCE设备上的NFC控制器提供的ATS响应的各个字节的详细信息：
TL：ATS的响应长度。不能表明长度大于20个字节。
T0：比特5，6和7必须在所有HCE设备进行设置，指示的TA（1），TB（1）和TC（1）包括在ATS响应。位1至4指示FSCI，编码的帧的最大尺寸。在HCE设备FSCI的值必须在0H和8h之间。
T（A）1：定义码率阅读器和仿真器之间，以及他们是否可以是不对称的。有没有比特率要求或担保HCE设备。
T（B）1：1位到4指示启动帧保护时间整数（SFGI）。在HCE设备，SFGI必须<= 8小时。位5至8指示帧的等待时间整数（FWI）和编码帧的等待时间（FWT）。在HCE设备，FWI必须<= 8小时。
T（C）1：5位指示“高级功能协议”的支持。 HCE设备可能支持或不支持“高级协议功能”。第2位表示支持DID。 HCE设备可以支持或不支持DID。位1指示NAD的支持。 HCE设备必须不支持NAD和设置位1至零。
历史字节：HCE设备最多可以返回15历史字节。 NFC读者愿意与HCE服务交互，不应对历史字节或他们的存在内容的假设。
请注意，许多HCE设备都有可能做出符合在EMVCo标准统一了支付网络在他们的“非接触式通信协议”规范中指定的协议的要求。尤其是：
FSCI在T0必须2H和8h之间。
T（A）1必须设置为0x80，表示只有106千比特/秒的比特率被支持，并且不支持阅读器和仿真器之间的非对称比特率。
FWI在T（B）1必须<= 7小时。
APDU数据交换
如前所述，HCE实现只支持一个单一的逻辑通道。尝试选择不同的逻辑通道的应用将不是一个HCE设备上运行。
Android API Guides---Host-based Card Emulation
标签：
原文地址：http://blog.csdn.net/qq_21413973/article/details/51191345
