基于HCE的移动支付研究

《基于HCE的移动支付研究》由会员分享，可在线阅读，更多相关《基于HCE的移动支付研究（11页珍藏版）》请在金锄头文库上搜索。

1、基于基于 HCE 移动支付研究报告移动支付研究报告1. 概念概念HCE（host-based card emulation） ，即基于主机的卡模拟。在一部配备 NFC 功能的手机 实现卡模拟，目前有两种方式：一种是基于硬件的，称为虚拟卡模式（Virtual Card Mode） ； 一种是基于软件的，被称为主机卡模式（Host Card Mode） ，即本文要讨论的方式。 在虚拟卡模式下，需要提供安全模块 SE（Secure Elemen） ，SE 提供对敏感信息的安全 存储和对交易事务提供一个安全的执行环境。NFC 芯片作为非接触通讯前端，将从外部读 写器接收到的命令转发到 SE，然后由 S

2、E 处理，并通过 NFC 控制器回复。 而在主机卡模式下，不需要提供 SE，而是由在手机中运行的一个应用或云端的服务器 完成 SE 的功能，此时 NFC 芯片接收到的数据由操作系统或发送至手机中的应用，或通过 移动网络发送至云端的服务器来完成交互。两种方式的特点都是绕过了手机内置的 SE 的 限制。2.NFC 技术简介技术简介近场通信（Near Field Communication,NFC）是一种短距高频的无线电技术，由非接触 式射频识别(RFID)演变而来。NFC 工作频率为 13.56Hz，有效范围为 20cm 以内，其传输速 度有 106 Kbit/秒、212 Kbit/秒或者 424

3、 Kbit/秒三种。NFC 有 3 种工作模式：读卡器模式、 点对点模式、卡模拟模式。在读卡器模式时，NFC 设备产生射频场从外部采用相同标准的 NFC 标签中读写数据。在点对点模式中，NFC 可以与其他的 NFC 设备通信，进行点对点 的数据传输。卡模拟模式中，读卡器是主动设备，产生射频场；NFC 设备为被动设备，模 拟一张符合 NFC 标准的非接触式卡片与读卡器进行交互。其中本文所讨论的 HCE 技术主 要是用于卡模拟的模式。传统的 NFC 终端主要包括非接触性前端 CLF(也叫 NFC 控制器)、天线(Antenna)、安 全模块(Secure Element,SE)三个主要部件。在 C

4、LF 中提供了识读接口、P2P 接口、卡模拟 接口，分别对应上面所说的三种工作模式。安全模块 SE 主要功能是实现应用和数据的安全存储，对外提供安全运算服务，它是 卡模拟的核心。安全模块还通过非接前端与外部读写设备进行通信，实现数据存储及交易 过程的安全性。非接触性前端也称为 NFC 控制器，其功能包括射频信号的调制解调，非接触通信的协 议处理。非接触前端一方面连接射频天线，实现 13.56MHz 信号的发送与接收，另一方面 与安全模块通信。天线集成在终端内部，与非接前端相连，实现 13.56MHz 射频信号的发送与接收。 NFC 的实现方案中，一般非接前端、天线都集成在手机终端中，而安全模块

5、可根据情况存 放在不同的位置。根据安全模块存放的位置不同，NFC 可分为不同的实现方案。3.基于安全模块的卡模拟基于安全模块的卡模拟图 1 基于安全模块的卡模拟当使用安全模块（SE）来提供卡模拟时，安全模块通过 NFC 芯片中的非接触前端与 外部读写设备进行通信，数据的存储和处理都在安全模块中。用户将手机放入 NFC 终端的 识别范围，NFC 控制器将从外部读写器接收到的所有数据直接转发到手机内部的安全模块， 由安全模块处理，然后再通过 NFC 控制器将响应数据发送给外部读写终端，整个事务过程 中手机上的应用程序完全没有参与其中。待事务过程完成后手机端的 Android 应用程序可 以查询安全

6、模块的事务状态然后通知客户。图 1 描述了这个过程。 基于安全模块的卡模拟主要有三种解决方案，分别是 NFC 全终端方案、eNFC 技术方 案和 NFC-SD 技术方案。 NFC 全终端方案是指将安全模块集成到手机终端的 NFC 方案，支持多安全域、多应 用安全模块架构以及相应的管理技术，可在安全模块上划分不同的安全域以承载来自不同 应用提供者的不同安全要求的各类应用，而且能保证各应用之间数据独立与数据安全。 NFC 全终端方案优势是其标准成熟，得到众多终端厂商的认可与支持。此方案中由于安全 模块与手机集成，有效避免了机卡接口和机卡兼容性的问题。缺点是安全芯片无法与手机 终端分离，业务初始化、

7、个人化、业务更新和管理不方便，用户更新手机时，所有业务需 要重新转移到新手机，成本高，流程长。谷歌钱包就是基于 NFC 全终端方案的一个典型业 务。 eNFC 技术方案是使用 SIM/UIM 卡作为安全模块的 NFC 技术方案，又被称为 SWP（单线通信协议）方案或 NFC-SIM 方案。用 SIM/UIM 卡作为安全模块，存储用户支 付账户、密钥等敏感数据，运行支付应用，手机中的 NFC 控制器通过 SWP（Single Wire Protocol）协议与 SIM/UIM 卡通信。由于 SIM/UIM 卡是移动用户必不可少的身份识别模块， 用户对 SIM 卡作为安全模块较容易接受，同时卡片和

8、应用的发行及服务可以借助电信运营 商的受理渠道，容易进行业务的推广。此外，SIM 卡与终端分离，用户更换手机不会影响 移动支付业务的继续使用，灵活性更高。由于 eNFC 方案的诸多优势，国内外的电信运营 商多选用 eNFC 方案，因此 eNFC 是业界认为最可能的移动近场支付技术方向。但是 eNFC方案还面临诸多困难，如专利、规范等，更重要的是，支持 eNFC 的手机终端很少，eNFC 的产业链不成熟，该技术的商用还有较大障碍，目前还没有比较典型的商用案例。 NFC-SD 技术方案是使用移动终端智能 SD 卡作为安全模块的 NFC 技术。其方案与 eNFC 方案类似，智能 SD 卡与 NFC

9、控制器芯片之间也采用 SWP 协议连接，可实现卡模拟、 读卡器和点对点通信三种工作模式。采用 NFC-SD 方案服务提供商（Service Provider，SP）可以自行发行 SD 卡，这样就能独立于电信运营商发展 NFC 业务，因此金 融机构做主导时更愿意采用这种方式。但是 SD 卡方案需要支持 SWP-SD 方案的手机支持， 而市面上相关款式的机型太少。另外一张 SD 卡一般只能支持一个 SP 的服务，如果用户希 望能使用多种服务的话，还必须在不同的 SD 卡中间切换，切换过程繁琐且成本偏高。尽 管 NFC-SD 方案被中国银联定为其移动现场支付标准，但 NFC-SD 卡方案被证明是比较

10、难 于实施的。 采用全终端解决方案和 eNFC 技术方案，尽管解决了多应用的服务的问题，但是 SE 的控制权却被手机制造商和移动运营商闹闹掌控，第三方的 SP 要部署的自己的服务必须 和 SE 的发行者们沟通，而这已经被证明是复杂和耗时的。而如果采用 NFC-SD 方案，尽 管服务提供商可以自己控制 SE，但是这种方案得不到手机厂商和移动运营商的支持，而且 对于用户来讲，要使用多种服务就必须切换 SD 卡。这些因素都限制了 NFC 技术在移动支 付领域的应用。而通过以上分析我们不难得出，问题的核心就在于通向“手机钱包”的一扇 门-SE 的控制权上。 2013 年 10 月 31 日，Googl

11、e 发布了最新的 Android4.4 系统，这其中提到了一个 NFC 的新技术，即 HCE（Host Card Emulation） 。自诞生之初，HCE 就引起了极大的关注，不仅 仅在于这项令人耳目一新的新技术本身，更在于它让业界的所有人看到了一种脱离安全载 体（SE）而部署 NFC 的可能性。HCE 技术对第三方的服务提供商（SP）意义重大，它使 得 SP 们可以将自己的服务在更短时间内以更低的开发成本推向市场，而用户也可以更方 便的使用多个 SP 提供的服务。4.基于主机的卡模拟（基于主机的卡模拟（HCE）图 2 基于主机的卡模拟 使用基于主机的卡模拟时（HCE） ，NFC 控制器从外

12、部读写终端接收到的数据将直接 被发送到主机系统上，而不是安全模块。图 2 描述了这个过程。4.1 支持的 NFC 卡和协议NFC 标准对很多智能卡协议提供了支持，Android4.4 系统也支持包括金融支付卡在内 的很多非接触智能卡协议，因此使用手机可以模拟出不同类型的智能卡。同样市场上很多 NFC 读卡器也支持这些协议，包括一部支持 NFC 的 Android 设备作为读卡器本身。这样通 过 HCE 技术我们只用 Android 设备就可以部署一个端对端的 NFC 解决方案。Android4.4 系统使用 NFC 论坛制定的的 ISO-DEP 标准协议（基于 ISO/IEC 14443- 4

13、（ISO-DEP）标准）进行数据传输，传输的数据单元被称为应用协议数据单元（APDUs） 。 另外，在数字协议方面（相当于层协议） ，Android 系统只要求对顶层的 NFC- A（ISO/IEC 14443-3 Type A）技术提供支持，而对 NFC-B 技术的（ISO/IEC 14443-3 Type B）的支持则是可选的，这些技术提供了包括初始化、冲突检测等解决方案。Android 系统 的 HCE 协议栈如图 3 所示。图 3 Android HCE 协议栈 4.2 HCE 服务Android 系统上的 HCE 技术是通过系统服务实现的（HCE 服务） 。使用服务的一大优 势是它可

14、以一直在后台运行而不需要有用户界面。这个特点就使得 HCE 技术非常适合像会 员卡、交通卡、门禁卡这类的交易，当用户使用时无需打开程序，只需要将手机放到 NFC 读卡器的识别范围内，交易就会在后台进行。当然如果有必要的话，用户也可以打开 UI 界面。这时的手机和普通的智能卡片已经没有区别了。 在上面的交易中我们有一个问题没有解决，当用户将手机放到 NFC 读卡器的识别范围 时,Android 系统需要知道读卡器真正想要和哪个 HCE 服务交互，这样它才能将接收到的数 据发送至相应的服务。ISO/IEC 7816-4 规范正是解决服务选择的问题，它定义了一种通过 应用程序 ID（AID）来选择相

15、应服务的方法。一个 AID 占 16 位，如果手机模拟的是一个 已经存在的 NFC 读卡设施，那么这些 NFC 读卡设施会去寻找那些经公共注册而广为人知 的 AID（类似于端口号） 。像 Visa 卡和万事达卡等这些智能卡可以注册 AID 号作为他们专 用的识别标志。反之，如果要为自己的新的读卡设施部署 NFC 应用，你就需要注册自己的 AID。AID 注册过程在 ISO/IEC 7816-5 规格中定义，为防止和其他的 Android 程序冲突， Google 建议 AID 号按此规格中推荐的注册。4.2.1 AID 组在某些情况下，为实现一个应用，HCE 服务需要注册多个 AID 号，我们

16、需要确保这些 AID 号的处理请求都会送到这个应用，而不是组中的某个 AID 号的请求被送到了其他的应 用中。 一个 AID 组中的所有 AID 号应该被系统看作是一个整体，对于这些 AID 号，操作系 统肯定会保证以下中一点： AID 组中的所有 AID 号都被路由到某个 HCE 服务； AID 组中没有一个 AID 号被路由到某个 HCE 服务；换言之，绝对不会存在中间状态，组中某个 AID 被路由到一个 HCE 服务，而另外一 个被路由到其他的 HCE 服务中。4.2.2 AID 组合和交易类型对于用户而言，他们不会去关注 AID 号及 AID 组，他们只会关注现在正在进行的是 什么交易，所以 Android4.4 定义了 Category。每个 AID 组对应一个 Category，这样系统就 可以按类型对 HCE 服务进行组织。 Android4.4 定义了两个类型：CATEGORYPAYMENT（用于符合工业标准的支付应 用）和 CATEGORYOTHER（其他的 HCE 应用） 。在应用程序的配置文件中我们可以声 明应用的类型。值得注意的是在 CATEG