搜索
基于HCE移动支付研究报告1.概念HCE（host-basedcardemulation），即基于主机的卡模拟。在一部配备NFC功能的手机实现卡模拟，目前有两种方式：一种是基于硬件的，称为虚拟卡模式（VirtualCardMode）；一种是基于软件的，被称为主机卡模式（HostCardMode），即本文要讨论的方式。在虚拟卡模式下，需要提供安全模块SE（SecureElemen），SE提供对敏感信息的安全存储和对交易事务提供一个安全的执行环境。NFC芯片作为非接触通讯前端，将从外部读写器接收到的命令转发到SE，然后由SE处理，并通过NFC控制器回复。而在主机卡模式下，不需要提供SE，而是由在手机中运行的一个应用或云端的服务器完成SE的功能，此时NFC芯片接收到的数据由操作系统或发送至手机中的应用，或通过移动网络发送至云端的服务器来完成交互。两种方式的特点都是绕过了手机内置的SE的限制。2.NFC技术简介近场通信（NearFieldCommunication,NFC）是一种短距高频的无线电技术，由非接触式射频识别(RFID)演变而来。NFC工作频率为13.56Hz，有效范围为20cm以内，其传输速度有106Kbit/秒、212Kbit/秒或者424Kbit/秒三种。NFC有3种工作模式：读卡器模式、点对点模式、卡模拟模式。在读卡器模式时，NFC设备产生射频场从外部采用相同标准的NFC标签中读写数据。在点对点模式中，NFC可以与其他的NFC设备通信，进行点对点的数据传输。卡模拟模式中，读卡器是主动设备，产生射频场；NFC设备为被动设备，模拟一张符合NFC标准的非接触式卡片与读卡器进行交互。其中本文所讨论的HCE技术主要是用于卡模拟的模式。传统的NFC终端主要包括非接触性前端CLF(也叫NFC控制器)、天线(Antenna)、安全模块(SecureElement,SE)三个主要部件。在CLF中提供了识读接口、P2P接口、卡模拟接口，分别对应上面所说的三种工作模式。安全模块SE主要功能是实现应用和数据的安全存储，对外提供安全运算服务，它是卡模拟的核心。安全模块还通过非接前端与外部读写设备进行通信，实现数据存储及交易过程的安全性。非接触性前端也称为NFC控制器，其功能包括射频信号的调制解调，非接触通信的协议处理。非接触前端一方面连接射频天线，实现13.56MHz信号的发送与接收，另一方面与安全模块通信。天线集成在终端内部，与非接前端相连，实现13.56MHz射频信号的发送与接收。NFC的实现方案中，一般非接前端、天线都集成在手机终端中，而安全模块可根据情况存放在不同的位置。根据安全模块存放的位置不同，NFC可分为不同的实现方案。3.基于安全模块的卡模拟图1基于安全模块的卡模拟当使用安全模块（SE）来提供卡模拟时，安全模块通过NFC芯片中的非接触前端与外部读写设备进行通信，数据的存储和处理都在安全模块中。用户将手机放入NFC终端的识别范围，NFC控制器将从外部读写器接收到的所有数据直接转发到手机内部的安全模块，由安全模块处理，然后再通过NFC控制器将响应数据发送给外部读写终端，整个事务过程中手机上的应用程序完全没有参与其中。待事务过程完成后手机端的Android应用程序可以查询安全模块的事务状态然后通知客户。图1描述了这个过程。基于安全模块的卡模拟主要有三种解决方案，分别是NFC全终端方案、eNFC技术方案和NFC-SD技术方案。NFC全终端方案是指将安全模块集成到手机终端的NFC方案，支持多安全域、多应用安全模块架构以及相应的管理技术，可在安全模块上划分不同的安全域以承载来自不同应用提供者的不同安全要求的各类应用，而且能保证各应用之间数据独立与数据安全。NFC全终端方案优势是其标准成熟，得到众多终端厂商的认可与支持。此方案中由于安全模块与手机集成，有效避免了机卡接口和机卡兼容性的问题。缺点是安全芯片无法与手机终端分离，业务初始化、个人化、业务更新和管理不方便，用户更新手机时，所有业务需要重新转移到新手机，成本高，流程长。谷歌钱包就是基于NFC全终端方案的一个典型业务。eNFC技术方案是使用SIM/UIM卡作为安全模块的NFC技术方案，又被称为SWP（单线通信协议）方案或NFC-SIM方案。用SIM/UIM卡作为安全模块，存储用户支付账户、密钥等敏感数据，运行支付应用，手机中的NFC控制器通过SWP（SingleWireProtocol）协议与SIM/UIM卡通信。由于SIM/UIM卡是移动用户必不可少的身份识别模块，用户对SIM卡作为安全模块较容易接受，同时卡片和应用的发行及服务可以借助电信运营商的受理渠道，容易进行业务的推广。此外，SIM卡与终端分离，用户更换手机不会影响移动支付业务的继续使用，灵活性更高。由于eNFC方案的诸多优势，国内外的电信运营商多选用eNFC方案，因此eNFC是业界认为最可能的移动近场支付技术方向。但是eNFC方案还面临诸多困难，如专利、规范等，更重要的是，支持eNFC的手机终端很少，eNFC的产业链不成熟，该技术的商用还有较大障碍，目前还没有比较典型的商用案例。NFC-SD技术方案是使用移动终端智能SD卡作为安全模块的NFC技术。其方案与eNFC方案类似，智能SD卡与NFC控制器芯片之间也采用SWP协议连接，可实现卡模拟、读卡器和点对点通信三种工作模式。采用NFC-SD方案服务提供商（ServiceProvider，SP）可以自行发行SD卡，这样就能独立于电信运营商发展NFC业务，因此金融机构做主导时更愿意采用这种方式。但是SD卡方案需要支持SWP-SD方案的手机支持，而市面上相关款式的机型太少。另外一张SD卡一般只能支持一个SP的服务，如果用户希望能使用多种服务的话，还必须在不同的SD卡中间切换，切换过程繁琐且成本偏高。尽管NFC-SD方案被中国银联定为其移动现场支付标准，但NFC-SD卡方案被证明是比较难于实施的。采用全终端解决方案和eNFC技术方案，尽管解决了多应用的服务的问题，但是SE的控制权却被手机制造商和移动运营商闹闹掌控，第三方的SP要部署的自己的服务必须和SE的发行者们沟通，而这已经被证明是复杂和耗时的。而如果采用NFC-SD方案，尽管服务提供商可以自己控制SE，但是这种方案得不到手机厂商和移动运营商的支持，而且对于用户来讲，要使用多种服务就必须切换SD卡。这些因素都限制了NFC技术在移动支付领域的应用。而通过以上分析我们不难得出，问题的核心就在于通向“手机钱包”的一扇门-SE的控制权上。2013年10月31日，Google发布了最新的Android4.4系统，这其中提到了一个NFC的新技术，即HCE（HostCardEmulation）。自诞生之初，HCE就引起了极大的关注，不仅仅在于这项令人耳目一新的新技术本身，更在于它让业界的所有人看到了一种脱离安全载体（SE）而部署NFC的可能性。HCE技术对第三方的服务提供商（SP）意义重大，它使得SP们可以将自己的服务在更短时间内以更低的开发成本推向市场，而用户也可以更方便的使用多个SP提供的服务。4.基于主机的卡模拟（HCE）图2基于主机的卡模拟使用基于主机的卡模拟时（HCE），NFC控制器从外部读写终端接收到的数据将直接被发送到主机系统上，而不是安全模块。图2描述了这个过程。4.1支持的NFC卡和协议NFC标准对很多智能卡协议提供了支持，Android4.4系统也支持包括金融支付卡在内的很多非接触智能卡协议，因此使用手机可以模拟出不同类型的智能卡。同样市场上很多NFC读卡器也支持这些协议，包括一部支持NFC的Android设备作为读卡器本身。这样通过HCE技术我们只用Android设备就可以部署一个端对端的NFC解决方案。Android4.4系统使用NFC论坛制定的的ISO-DEP标准协议（基于ISO/IEC14443-4（ISO-DEP）标准）进行数据传输，传输的数据单元被称为应用协议数据单元（APDUs）。另外，在数字协议方面（相当于ＭＡＣ层协议），Android系统只要求对顶层的NFC-A（ISO/IEC14443-3TypeA）技术提供支持，而对NFC-B技术的（ISO/IEC14443-3TypeB）的支持则是可选的，这些技术提供了包括初始化、冲突检测等解决方案。Android系统的HCE协议栈如图3所示。图3AndroidHCE协议栈4.2HCE服务Android系统上的HCE技术是通过系统服务实现的（HCE服务）。使用服务的一大优势是它可以一直在后台运行而不需要有用户界面。这个特点就使得HCE技术非常适合像会员卡、交通卡、门禁卡这类的交易，当用户使用时无需打开程序，只需要将手机放到NFC读卡器的识别范围内，交易就会在后台进行。当然如果有必要的话，用户也可以打开UI界面。这时的手机和普通的智能卡片已经没有区别了。在上面的交易中我们有一个问题没有解决，当用户将手机放到NFC读卡器的识别范围时,Android系统需要知道读卡器真正想要和哪个HCE服务交互，这样它才能将接收到的数据发送至相应的服务。ISO/IEC7816-4规范正是解决服务选择的问题，它定义了一种通过应用程序ID（AID）来选择相应服务的方法。一个AID占16位，如果手机模拟的是一个已经存在的NFC读卡设施，那么这些NFC读卡设施会去寻找那些经公共注册而广为人知的AID（类似于端口号）。像Visa卡和万事达卡等这些智能卡可以注册AID号作为他们专用的识别标志。反之，如果要为自己的新的读卡设施部署NFC应用，你就需要注册自己的AID。AID注册过程在ISO/IEC7816-5规格中定义，为防止和其他的Android程序冲突，Google建议AID号按此规格中推荐的注册。4.2.1AID组在某些情况下，为实现一个应用，HCE服务需要注册多个AID号，我们需要确保这些AID号的处理请求都会送到这个应用，而不是组中的某个AID号的请求被送到了其他的应用中。一个AID组中的所有AID号应该被系统看作是一个整体，对于这些AID号，操作系统肯定会保证以下中一点：AID组中的所有AID号都被路由到某个HCE服务；AID组中没有一个AID号被路由到某个HCE服务；换言之，绝对不会存在中间状态，组中某个AID被路由到一个HCE服务，而另外一个被路由到其他的HCE服务中。4.2.2AID组合和交易类型对于用户而言，他们不会去关注AID号及AID组，他们只会关注现在正在进行的是什么交易，所以Android4.4定义了Category。每个AID组对应一个Category，这样系统就可以按类型对HCE服务进行组织。Android4.4定义了两个类型：CATEGORY＿PAYMENT（用于符合工业标准的支付应用）和CATEGORY＿OTHER（其他的HCE应用）。在应用程序的配置文件中我们可以声明应用的类型。值得注意的是在CATEGORY＿PAYMENT类型中，只有一个AID组应用可以在任何时候处于可用状态，这个AID组所代表的应用一般是能够读懂大部分的银行卡支付协议并能够在任何一个支付商家处使用。对于像储值卡这类只能在某个商家处使用的闭环支付应用，我们应该使用CATEGORY＿OTHER。这个类型里的AID组可以一直保持激活状态，如有必要在AID选择的时候可以被NFC读卡器赋予优先级。4.3实现HCE服务在手机上用HCE技术实现NFC卡模拟，首先要创建一个处理交易事务的HCE服务。我们可以通过检查FEATURE_NFC_HOST_CARD_EMULATION特性来检查手机是否支持HCE技术，然后在配置文件manifest中的uses-feature标签中声名本程序使用HCE技术。Android4.4为HCE服务提供了一个非常方便的基类HostApduService，我们可以通过继承HostApduService来实现自己的HCE服务。publicclassMyHostApduServiceextendsHostApduService{@OverridePublicbyte[]