共计 3236 个字符，预计需要花费 9 分钟才能阅读完成。
NFC 技术发展
NFC(Near Field Communication)是“近场通讯”的简称，采用短距离 RF(射频)通讯技术。NFC 工作频率为 13.56Hz，有效范围为 500px 以内，其传输速度有 106 Kbit/ 秒、212 Kbit/ 秒或者 424 Kbit/ 秒三种，能够应用在手机 / 平板、电脑 / 游戏机、印表机、电子产品，甚至家电设备中。
NFC 技术已经有十来年历史，在过去的几年里一直被称为很有前景的便利移动支付技术。但即使在 NFC 手机日渐成为智能机标配的今天，基于 NFC 的移动支付却没有在消费者群体中形成气候。一个重要的原因在于：所有人都在争着控制 NFC 技术的安全元件(the Secure Element)。安全元件，顾名思义，是保证财产信息安全的，控制这个就可以控制每一笔交易的费用。SE 导致了金融机构、OEM 和运营商之间无休止的争斗，没办法联合起来，这使得 NFC 移动支付发展缓慢。
HCE 概念
HCE(host-based cardemulation)，即基于主机的卡模拟。
在一部配备 NFC 功能的手机实现卡模拟，目前有两种方式：一种是基于硬件的，称为虚拟卡模式(Virtual Card Mode); 一种是基于软件的，被称为主机卡模式(Host Card Mode)。
在虚拟卡模式下，需要提供安全模块 SE(Secure Elemen)，SE 提供对敏感信息的安全存储和对交易事务提供一个安全的执行环境。NFC 芯片作为非接触通讯前端，将从外部读写器接收到的命令转发到 SE，然后由 SE 处理，并通过 NFC 控制器回复。
在主机卡模式下，不需要提供 SE，而是由在手机中运行的一个应用或云端的服务器完成 SE 的功能，此时 NFC 芯片接收到的数据由操作系统或发送至手机中的应用，或通过移动网络发送至云端的服务器来完成交互。两种方式的特点都是绕过了手机内置的 SE 的限制。这一标准的妙处在于，它不需要整个行业为了控制安全元件而争斗。
使用基于主机的卡模拟时(HCE)，NFC 控制器从外部读写终端接收到的数据将直接被发送到主机系统上，而不是安全模块。上图描述了这个过程。
HCE 技术的关键大事记
2012/09/19,SimplyTapp 在 Android 第三方 CyanogenMod 固件中实现主机卡模拟技术 HCE;
2013/11/01,Google 发布最新的 Android4.4 操作系统，支持主机卡模拟 HCE 技术，目前已通过谷歌钱包将 HCE 应用到 Nexus 5 手机中，可支持 Paypass;
2013/12/13, 美国连锁咖啡 TimHortons 在北美 4000 多家门店推出基于 HCE 的 NFC 支付应用;
2014/02/17, 西班牙银行 Bankinter 发布基于 HCE 技术的虚拟卡手机钱包;
2014/02/19,Visa 和万事达卡同时宣布将基于 HCE 技术推动云端移动支付;
2014/02/20, 全球智能卡制造商 ABnote 与 SimplyTapp 合作，将 HCE 技术加入到其 TSM 平台中。
NFC 标准对 Android 支持
NFC 标准对很多智能卡通讯协议提供了支持，而 Android4.4 系统也支持包括主流智能卡应用在内的很多非接触智能卡协议，因此使用 NFC 手机和 HCE 应用，就可以方便的模拟出不同类型的智能卡应用。
同样市场上很多 NFC 读卡终端也支持这些协议，包括一部支持 NFC 的 Android 设备作为读卡器本身。这样通过 HCE 技术我们只用 Android 设备就可以部署一个端对端的 NFC 解决方案。
Android4.4 系统使用 NFC 论坛制定的的 ISO-DEP 标准协议 (基于 ISO/IEC14443-4(ISO-DEP) 标准)进行数据传输，传输的数据单元被称为应用协议数据单元(APDUs)。
另外，在数字协议方面 (相当于 MAC 层协议)Android 系统只要求对顶层的 NFC-A(ISO/IEC 14443-3 Type A) 技术提供支持，而对 NFC- B 技术的 (ISO/IEC 14443-3 Type B) 的支持则是可选的，这些技术提供了包括初始化、冲突检测等解决方案。
Android 系统上的 HCE 技术是通过系统服务实现的(HCE 服务)。使用服务的一大优势是它可以一直在后台运行而不需要有用户界面。这个特点就使得 HCE 技术非常适合像会员卡、交通卡、门禁卡这类的交易，当用户使用时无需打开程序，只需要将手机放到 NFC 读卡器的识别范围内，交易就会在后台进行。当然更推荐为用户提供配套的 HCE 应用 UI 界面，这样除了像普通的智能卡片一样刷卡使用以外，还可以通过 UI 界面为用户提供更多的在线服务功能，包括查询、充值和信息推送等。
当用户将手机放到 NFC 读卡器的识别范围时,Android 系统需要知道读卡器真正想要和哪个 HCE 服务交互，这样它才能将接收到的数据发送到相应的 HCE 应用。HCE 参考 ISO7816 规范，定义了一种通过应用程序 AID 来选择相应应用的方法。因此，如果要为自己的新的读卡设施部署 NFC 应用，就需要定义自己的 AID。
HCE 技术实现 NFC 模拟
在手机上用 HCE 技术实现 NFC 卡模拟，首先要创建一个处理交易事务的 HCE 服务，Android4.4 为 HCE 服务提供了一个非常方便的基类，我们可以通过继承基类来实现自己的 HCE 服务。如果要开发已存在的 NFC 系统，我们只需要在 HCE 服务中实现 NFC 读卡器期望的应用层协议。反之如果要开发自己的新的 NFC 系统，我们就需要定义自己的协议和 APDU 序列。一般而言我们应该保证数据交换时使用很少的 APDU 包数量和很小的数据量，这样用户就不必花很长时间将手机放在 NFC 读卡器上。
HCE 技术只是实现了将 NFC 读卡器的数据送至操作系统的 HCE 服务或者将回复数据返回给 NFC 读卡器，而对于数据的处理和敏感信息的存储则没有具体实现细，所以说到底 HCE 技术是模拟 NFC 和 SE 通信的协议和实现。但是 HCE 并没有实现 SE，只是用 NFC 与 SE 通信的方式告诉 NFC 读卡器后面有 SE 的支持，从而以虚拟 SE 的方式完成 NFC 业务的安全保证。既然没有 SE，那么 HCE 用什么来充当 SE 呢，解决方案要么是本地软件的模拟，要么是云端服务器的模拟。负责安全的 SE 如何通过本地化的软件或者远程的云端实现，并且能够保障安全性，需要 HCE 厂商自己考虑和实现。
HCE 方案与 SE 方案的路由和兼容
支持 HCE 功能的 Android4.4 手机，很多也同时支持 SWP-SIM 或者 SWP-SD 之类的 SE 模式实现手机支付功能，因此存在一个应用 AID 路由的问题，通常是由 CLF 芯片中的 AID 路由表来负责进行相关的路由工作，由手机生产厂商负责开发实现具体的规则。具体系统架构和指令流向如下图：
因为 CLF 芯片的路由表，是通过读卡终端发送的 Select 指令中的应用 AID 来进行区分和路由的，因此对于 SE(SWP-SIM)和手机 HOSTCPU 中的 HCE 应用，如果各自支持的具体智能卡应用的 AID 均不相同，则不会出现任何路由和兼容性的问题，所有的应用均能够被正确识别和分别路由到 SE(SWP-SIM)或者 HCE 应用，并正常完成交易的实现和处理。
如果 SE(SWP-SIM)和手机 HOST CPU 中的 HCE 应用，支持的智能卡应用中有相同的 AID，则存在一个路由优先级的问题，同时涉及到支持 SE(SWP-SIM)的设备升级到 Android4.4 之后，对于 SWP-SIM 中原有的应用的兼容问题。
按照 google 提供的 Android API 的要求，HCE APP 的路由优先级更高，表示说如果存在相同的 AID 的应用，则会被优先路由到 HCE 应用来处理，那么 SWP-SIM 中的相同 AID 的应用将无法被调用和使用，会出现系统升级到 4.4 版本后，无法兼容既有应用使用的问题，除非不安装 HCE 应用。
因此运营商的定制手机，通常会要求修改一下路由的优先级，使 SE(SWP-SIM)的路由优先级更好，即如果存在相同的 AID 的应用，则会被优先路由到 SWP-SIM 来处理，确保对于旧时发行的支持 SE 的设备，在系统升级到 4.4 之后的兼容性。
