NFC技术发展

　　NFC是“近场通讯”的简称，采用短距离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之后的兼容性。