基于HCE移动支付研究报告

快来打我* 2022-08-09 02:23 227阅读 0赞

## 　　**1. 概念**  　　HCE(host-based card emulation)，即基于主机的卡模拟。在一部配备NFC功能的手机实现卡模拟，目前有两种方式：一种是基于硬件的，称为虚拟卡模式(Virtual Card Mode);一种是基于软件的，被称为主机卡模式(Host Card Mode)，即本文要讨论的方式。  　　在虚拟卡模式下，需要提供安全模块SE(Secure Elemen)，SE提供对敏感信息的安全存储和对交易事务提供一个安全的执行环境。NFC芯片作为非接触通讯前端，将从外部读写器接收到的命令转发到SE，然后由SE处理，并通过NFC控制器回复。  　　而在主机卡模式下，不需要提供SE，而是由在手机中运行的一个应用或云端的服务器完成SE的功能，此时NFC芯片接收到的数据由操作系统或发送至手机中的应用，或通过移动网络发送至云端的服务器来完成交互。两种方式的特点都是绕过了手机内置的SE的限制。  　　**2.NFC技术简介**  　　近场通信(Near Field Communication,NFC)是一种短距高频的无线电技术，由非接触式射频识别(RFID)演变而来。NFC工作频率为13.56Hz，有效范围为20cm以内，其传输速度有106 Kbit/秒、212 Kbit/秒或者424 Kbit/秒三种。NFC有3种工作模式：读卡器模式、点对点模式、卡模拟模式。在读卡器模式时，NFC设备产生射频场从外部采用相同标准的NFC标签中读写数据。在点对点模式中，NFC可以与其他的NFC设备通信，进行点对点的数据传输。卡模拟模式中，读卡器是主动设备，产生射频场;NFC设备为被动设备，模拟一张符合NFC标准的非接触式卡片与读卡器进行交互。其中本文所讨论的HCE技术主要是用于卡模拟的模式。  　　传统的NFC终端主要包括非接触性前端CLF(也叫NFC控制器)、天线(Antenna)、安全模块(Secure Element,SE)三个主要部件。在CLF中提供了识读接口、P2P接口、卡模拟接口，分别对应上面所说的三种工作模式。  　　安全模块SE主要功能是实现应用和数据的安全存储，对外提供安全运算服务，它是卡模拟的核心。安全模块还通过非接前端与外部读写设备进行通信，实现数据存储及交易过程的安全性。  　　非接触性前端也称为NFC控制器，其功能包括射频信号的调制解调，非接触通信的协议处理。非接触前端一方面连接射频天线，实现13.56MHz信号的发送与接收，另一方面与安全模块通信。  　　天线集成在终端内部，与非接前端相连，实现13.56MHz射频信号的发送与接收。  　　NFC的实现方案中，一般非接前端、天线都集成在手机终端中，而安全模块可根据情况存放在不同的位置。根据安全模块存放的位置不同，NFC可分为不同的实现方案。  　　**3.基于安全模块的卡模拟**  ![基于安全模块的卡模拟][2014092616401179.jpg]  　　*图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(Single Wire Protocol)协议与SIM/UIM卡通信。由于SIM/UIM卡是移动用户必不可少的身份识别模块，用户对SIM卡作为安全模块较容易接受，同时卡片和应用的发行及服务可以借助电信运营商的受理渠道，容易进行业务的推广。此外，SIM卡与终端分离，用户更换手机不会影响移动支付业务的继续使用，灵活性更高。由于eNFC方案的诸多优势，国内外的电信运营商多选用eNFC方案，因此eNFC是业界认为最可能的移动近场支付技术方向。但是eNFC方案还面临诸多困难，如专利、规范等，更重要的是，支持eNFC的手机终端很少，eNFC的产业链不成熟，该技术的商用还有较大障碍，目前还没有比较典型的商用案例。  　　NFC-SD技术方案是使用移动终端智能SD卡作为安全模块的NFC技术。其方案与eNFC方案类似，智能SD卡与NFC控制器芯片之间也采用SWP协议连接，可实现卡模拟、读卡器和点对点通信三种工作模式。采用NFC-SD方案服务提供商(Service Provider，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(Host Card Emulation)。自诞生之初，HCE就引起了极大的关注，不仅仅在于这项令人耳目一新的新技术本身，更在于它让业界的所有人看到了一种脱离安全载体(SE)而部署NFC的可能性。HCE技术对第三方的服务提供商(SP)意义重大，它使得SP们可以将自己的服务在更短时间内以更低的开发成本推向市场，而用户也可以更方便的使用多个SP提供的服务。  　　**4.基于主机的卡模拟(HCE)**  ![基于主机的卡模拟][2014092616404721.jpg]  　　*图2 基于主机的卡模拟*  　　使用基于主机的卡模拟时(HCE)，NFC控制器从外部读写终端接收到的数据将直接被发送到主机系统上，而不是安全模块。图2描述了这个过程。  　　**4.1支持的NFC卡和协议**  　　NFC标准对很多智能卡协议提供了支持，Android4.4系统也支持包括金融支付卡在内的很多非接触智能卡协议，因此使用手机可以模拟出不同类型的智能卡。同样市场上很多NFC读卡器也支持这些协议，包括一部支持NFC的Android设备作为读卡器本身。这样通过HCE技术我们只用Android设备就可以部署一个端对端的NFC解决方案。  　　Android4.4系统使用NFC论坛制定的的ISO-DEP标准协议(基于ISO/IEC 14443-4(ISO-DEP)标准)进行数据传输，传输的数据单元被称为应用协议数据单元(APDUs)。另外，在数字协议方面(相当于MAC层协议)，Android系统只要求对顶层的NFC-A(ISO/IEC 14443-3 Type A)技术提供支持，而对NFC-B技术的(ISO/IEC 14443-3 Type B)的支持则是可选的，这些技术提供了包括初始化、冲突检测等解决方案。Android系统的HCE协议栈如图3所示。  ![Android HCE协议栈][Android HCE]  　　*图3 Android HCE协议栈*  　　**4.2 HCE服务**  　　Android系统上的HCE技术是通过系统服务实现的(HCE服务)。使用服务的一大优势是它可以一直在后台运行而不需要有用户界面。这个特点就使得HCE技术非常适合像会员卡、交通卡、门禁卡这类的交易，当用户使用时无需打开程序，只需要将手机放到NFC读卡器的识别范围内，交易就会在后台进行。当然如果有必要的话，用户也可以打开UI界面。这时的手机和普通的智能卡片已经没有区别了。  　　在上面的交易中我们有一个问题没有解决，当用户将手机放到NFC读卡器的识别范围时,Android系统需要知道读卡器真正想要和哪个HCE服务交互，这样它才能将接收到的数据发送至相应的服务。ISO/IEC 7816-4规范正是解决服务选择的问题，它定义了一种通过应用程序ID(AID)来选择相应服务的方法。一个AID占16位，如果手机模拟的是一个已经存在的NFC读卡设施，那么这些NFC读卡设施会去寻找那些经公共注册而广为人知的AID(类似于端口号)。像Visa卡和万事达卡等这些智能卡可以注册AID号作为他们专用的识别标志。反之，如果要为自己的新的读卡设施部署NFC应用，你就需要注册自己的AID。AID注册过程在ISO/IEC 7816-5规格中定义，为防止和其他的Android程序冲突，Google建议AID号按此规格中推荐的注册。  　　**4.2.1 AID组**  　　在某些情况下，为实现一个应用，HCE服务需要注册多个AID号，我们需要确保这些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定义了两个类型：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中的标签中声名本程序使用HCE技术。  　　Android4.4为HCE服务提供了一个非常方便的基类HostApduService，我们可以通过继承HostApduService来实现自己的HCE服务。  　　public class MyHostApduService extends HostApduService \{  　　@Override  　　Public byte\[\] processCommandApdu(byte\[\] apdu, Bundle extras)\{  　　...  　　\}  　　@Override  　　public void onDeactivated(int reason)\{  　　...  　　\}  　　\}  　　HostApduService中声明了两个我们需要重写并实现的抽象方法。  　　任何时候，NFC读卡器向手机服务发送应用协议数据单元(APDU)的时候processCommandApdu()方法都会被调用。APDUs被定义在ISO/IEC 7816-4规范中，作为一个应用层的协议包，APDUs被用于HCE服务和NFC读卡器之间的数据交换。并且此应用层协议是半双工的：NFC读卡器向手机发送一个命令APDU，然后等待手机回复一个APDU包。  　　正如前面提到的，Android系统通过AID来决定使用哪个HCE服务与NFC读卡器交互。所以一般情况下，NFC读卡器发送的第一个APDU是"SELECT　AID"APDU，这个APDU包含NFC读卡器想要对话的服务的AID号。Android系统提取出协议包里的AID号，将其发送至相应的HCE服务，并将其后的APDU都发送至那个HCE服务。  　　我们可以通过在processCommandApdu中返回比特数组来发送一个回复APDU。由于processCommandApdu方法会在主线程中被调用，所以不能被阻塞。当在程序中无法立即计算出结果并回复时，我们应该立即返回NULL。然后在其他的线程中做相应的工作，待计算结果完成后用在HostApduService中定义的 sendResponseApdu()方法发送回复。  　　Android系统会将从NFC读卡器接收到的APDU都发送至已选择的那个HCE服务，直到遇到以下两种情况：  　　1.NFC读卡器发送另外一个"SELECT AID"APDU命令，操作系统会重新选择一个其他的HCE服务。  　　2.NFC读卡器和手机之间的连接中断。  　　以上任何一种情况发生时，onDeactivated()方法会被调用，它的参数(reason)则指明发生了哪种情况。  　　如果要开发已存在的NFC系统，我们只需要在HCE服务中实现NFC读卡器期望的应用层协议。反之如果要开发自己的新的NFC系统，我们就需要定义自己的协议和APDU序列。一般而言我们应该保证数据交换时使用很少的APDU包数量和很小的数据量，这样用户就不必花很长时间将手机放在NFC读卡器上。一个明智的选择是交换的数据量不超过1KB，这样一次通信通常只需300ms。  　　**4.4 AID冲突的解决方式**  　　在手机中我们可以安装多个HCE服务，同一个AID号可能会被很多个HCE服务所注册。Android系统对于不同的Category里的AID冲突解决方式不同。例如，对于CATEGORY\_PAYMENT(支付类)，用户可以在系统的设置菜单“tap & pay”选项中设置这类支付的默认支付应用，当冲突时将会执行默认的HCE服务。而对于CATEGORY\_OTHER类的冲突，手机会弹出对话框让用户选择要执行的应用。通过isDefaultServiceForCategory()接口可以查看本HCE服务是否是默认的服务。  　　**4.5与传统的SE卡兼容**  　　Android系统使用HCE技术模拟卡与其他的模拟卡技术是兼容的，即其他的基于SE的模拟卡技术可以在使用HCE技术的Android手机上使用，反之亦可，只要系统支持HCE技术。  　　这种兼容是建立在这样一个AID路由原则之上的：NFC控制器内部保存一个路由表，表项由AID和目标地址组成，目标地址既可以是主机(应用程序运行的地方)，也可以是与之相连的安全模块(SE)。  　　当NFC读卡器发送了一个”SELECT AID”的APDU时，NFC控制器解析出其中的AID并在路由表中检索，路由表中有相应匹配时将此APDU送至相应的目标地址，并且其后的APDU都将会送至同一个目标地址，直到遇到下一个”SELECT AID”的APDU或者连接中断。  ![同时具有HCE和SE卡模拟的系统][HCE_SE]  　　*图4 同时具有HCE和SE卡模拟的系统*  　　如果在路由表中没有检索到匹配项，则NFC控制器通常会将其送至默认的目标地址。从Android4.4开始默认的目标地址都是主机，这就意味着NFC控制器的路由表只需要包含所有路由到的SE模块的AID。  　　当用户升级完Android4.4系统之后，若想继续使用其已存在的SE实现就必须在NFC控制器的路由表中重新注册，这意味着用户有可能要到柜台等地方去重新做一次升级。  　　**5.HCE的安全性探讨**  　　HCE技术只是实现了将NFC读卡器的数据送至操作系统的HCE服务或者将回复数据返回给NFC读卡器，而对于数据的处理和敏感信息的存储则没有具体实现细，所以说到底HCE技术是模拟NFC和SE通信的协议和实现。但是HCE并没有实现SE，只是用NFC与SE通信的方式告诉NFC读卡器后面有SE的支持，从而以虚拟SE的方式完成NFC业务的安全保证。既然没有SE，那么HCE用什么来充当SE呢，解决方案要么是本地软件的模拟，要么是云端服务器的模拟。  　　对于本地软件模拟SE的方案，用户敏感信息及交易数据存放在本地。交易过程和数据存储由操作系统管理，这提供了一种基本的安全保障机制(如操作系统可以将每个程序运行在一个沙箱(sandbox)里，这样可以防止一个应用程序访问其他应用的数据)。但是Android系统的安全性本来就很差，所以这种安全保证是非常脆弱的。当一部Android手机被Root之后，用户可以取得系统的最高权限，这样基本上就可以为所欲为了。  　　相较于传统的基于SE的NFC方案，HCE技术可能面临以下的风险：  　　1. 用户可以对终端进行Root操作，通过Root用户可以取得所有储存在应用中的信息，包括类似于支付凭证之类的敏感数据,这些都是服务提供商所不愿看到的，因为这也给了恶意软件获取敏感信息的可乘之机。从统计数量上来说，只有很少一部分的安卓终端进行了Root操作，但是这仍然意味着数百万级别的终端数量。  　　2. 恶意软件可以自行Root操作系统。对于前期安卓系统来说，由于存在着一些漏洞，导致不少的恶意软件可以直接Root系统。虽然这些漏洞看起来影响范围不是特别的大(比如如果用户不安装未知来源的安卓软件就不会有这个问题)，但是这仍然是一个需要考虑的问题。安卓系统的一个已知漏洞的弥补是很难的，这是因为安卓系统冗长的更新过程，需要花费很长的时间才能使得市面上的大部分终端都更新到最新的系统版本。如果在支持HCE的系统版本中也出现了缺陷，也需要花费足够长的时间去解决现有终端上的缺陷问题。  　　3. 如果手机丢失或者被盗取，一个恶意用户可以Root终端或者通过其它方式访问终端的存储系统，并且获取各种存储于应用中的信息。这可能带来致命的问题，比如恶意用户可以使用这些敏感数据去完成一些伪卡的交易。  　　由此可见Android系统提供的安全保障机制非常有限，一旦被Root这种机制就荡然无存。提高HCE技术的安全性可以从两个方面来考虑，一个是提供一个更安全的存储敏感信息的位置，另外一个就是提供更安全的机制来保证这个位置的信息的安全性。  　　**5.1敏感信息的存储位置**  　　HCE服务虽然运行在Android系统上，但SP可以要求将敏感信息存储和处理放在在一个更安全的位置。这里有四个可以选择位置，他们都在安全性和使用代价之间有不同的平衡。图5描述了这四个不同的选择。  ![HCE服务存储敏感信息的位置][HCE]  　　*图5 HCE服务存储敏感信息的位置*  　　**5.1.1主机**  　　这是最简单但是安全性最差的实现方式，即直接将数据的存储和处理放在主机的应用上进行。除了操作系统提供的非常基本的安全机制外，没有其他附加的保护。实现起来也最容易，但是对于Root的系统没有任何防范。  　　**5.1.2云端SE**  　　使用这种方式时，HCE服务将请求通过移动网络发送至云端，敏感信息的存储和处理都在云端服务器。安全性方面比直接在主机的应用上处理和存储要高，但是此时移动网络就变得更加重要了。网络覆盖和网络延时都会成为很大的问题，在网络没有覆盖或信号差的地方这种方式就无法使用了。一次移动支付交易的时间都在一秒以内，云端SE的方案在速度上并不能保证这点。另外云端SE还有一个认证的问题，如果将设备到云端SE的认证证书放在HCE服务里，那么云端SE方案的安全性就大打折扣了。这个问题可以通过用户去完成(如登陆)认证，但是用户体验就很差了。或者用一个单独的硬件SE去处理认证问题。目前来看，对于安全性较高的移动支付服务，这个方案还是最适合的。  　　**5.1.3可信执行环境(TEE)**  ![可信执行环境][2014092616461857.jpg]  　　*图6 可信执行环境*  　　可信执行环境(TEE)是指独立于操作系统的一个执行环境，专门用于提供安全服务。TEE有自己独立的软件和硬件资源，对外提供安全服务接口，用户敏感信息的存储和处理都在这个环境里进行。由于TEE运行自己独立的系统，所以Android主系统被Root不会影响到自己。TEE提供的安全性总体上要比云端SE高，但是还是没有达到SE提供的安全性，因为它没有SE的反篡改机制。TEE方案很像传统的基于SE的方案，所以其实现起来要更复杂，另外其标准也没有敲定。  　**　5.1.4 UICC或嵌入式SE**  　　这种方式提供最高级别的安全保证，将敏感信息的存储和处理放在一块单独的安全模块上(SE)。但是这样做HCE技术与传统的基于SE的卡模拟方案相比就毫无优越性可言，甚至增加了实现的复杂度(传统的方法是直达SE，现在是经过操作系统再到达SE)。  　　**5.2安全的机制**  　　有很多方法机制来保证应用程序的安全性，原则上这些方法都可以用在上面这四种方案中来实现更安全的HCE支付方案。当然使用这些机制会增加用户使用的复杂度，同样也会增加开发者的实现难度。我们必须在安全性、用户使用的方便性和成本之间做一个权衡，来选择合适的机制。  　　**5.2.1.用户验证**  　　在支付交易中使用用户验证机制可以显著提高交易的安全性。典型的验证机制有：  　　根据用户知道的信息验证：如用户名，密码，PIN码等;  　　根据用户的行为验证：最典型的是关于异地使用拒绝，如果一次支付在某地完成后很快又在很远的其他地方进行，则这样的支付请求可以拒绝;  　　根据生物测定验证：如指纹识别，声音识别，面部识别和虹膜扫描识别等，这些生物验证机制现在已经引起了极大的关注，而且已经在某些手机上实现了。  　**　5.2.2交易限制**  　　这是通过对交易设置一些限制来减小潜在的安全风险，例如只允许小额支付，每日交易额不超过一定量，不允许境外支付等。用户可以修改这些限制，但必须输入密码，这样即使手机被盗也可以将损失减少。  　　**5.2.3 Android系统检查**  　　Android应用程序可以检查到系统是否被Root。可以将Root与风险联系起来，一旦HCE程序检测到系统被Root，我们可以执行相应的措施。  　**　5.2.4 数据加密**  　　可以将敏感数据加密然后存放在HCE程序中，这样即使恶意用户和应用获得了这些数据也无法解析。但是这么做的话也会增加应用程序的复杂性和成本。  　　**6.HCE技术展望**  　　不可否认的一点是，HCE技术提供了一种安全性稍差但是部署起来非常方便的NFC服务解决方案。HCE技术对服务提供商而言至关重要，无需SE，剪除了不少NFC支付利益方纠葛，因此他们会是HCE技术的坚决支持者。据最新的消息，万事达卡(MasterCard)已正式宣布将推出适用于HCE技术的NFC规范，而Visa则将在Visa Ready Program中加入HCE支付应用的支持特色。而NFC论坛也表态力挺HCE技术，其旗下多种标准已支持HCE技术，包括NFC控制器介面(NCI)规范，该标准结合国际标准组织(ISO)14443及日本工业标准(JIS)X 6319-4等。NFC论坛指出，现在多个产业团体陆续启动NFC服务，而HCE技术将十分有希望成为加速整体NFC市场成长的潜在因素，因此NFC论坛将持续追踪HCE技术新的开发动态并持续透过标准开发工作回应市场需求。Google公司也是大力推动HCE技术的重要角色，在其最新的Nexus 5智能手机当中，已经应用HCE技术到谷歌钱包中，搭配安卓4.4系统，无需SE安全元件就可以进行PayPass交易。  　　HCE技术面临的最大难题还是其安全性问题。无论是本地软件还是云端SE的方案，都没有硬件级别的安全性高。对于金融级别的移动支付，HCE技术最可行的解决方案还是基于云端SE的方法，将支付数据存储在云端并且采用一些技术(如Token或者非对称密钥等)确保从HCE Host到云端服务器的数据传输通道是安全的，HCE的安全性是可以得到提高和增强的。所以在金融业务方面，HCE技术能否登堂入室，首先要看Visa、Master、银联等金融机构是否能够解决本地软件、远程云端SE的安全问题。目前，国内有个别运营商和银行在小规模试用类似HCE的技术手段，希望推动移动支付的发展，但是否能够成为标准，形成规模，还需要时间考验。  　　虽然在金融级别的移动支付方面前景还不太明朗，但是对于像会员卡、优惠券、电子票等低价值的闭环支付方面HCE技术还是有很大的发挥余地的。这些类型的NFC应用安全要求不像账户中有大量资金的银行类支付业务，虽然需要对用户身份、凭证的安全性做出确认，避免假冒和伪造，但还未上升到金融业务的高度，因此如何在安全、便利和业务发展之间寻求平衡十分重要。谷歌HCE的出现为这些非金融支付类的O2O业务打开了一扇门，在一定程度上提供安全的模拟手段，经济的解决SE的问题，为业务的蓬勃发展大有助力。服务供应商须评估、决定储存安全凭据最好的方式，并清楚在不同的使用情境下不同的解决方案将各有优缺点，安全风险(Security Risk)与便利性间须有所取舍。  　　总之，HCE技术带来的是一次变革，为NFC的发展和普及带来了价值，同样也带来了一定的安全风险。移动支付中的安全问题至关重要，解决这个问题需要金融服务提供商、通信运营商和谷歌等方面建立起完备的安全机制。另外HCE的出现，对于传统的卡厂、运营商来说都产生了一定的威胁和挑战，能否实现产业的共赢，亦是产业各方需要去权衡和考虑的。 ##

[2014092616401179.jpg]: http://www.mpaypass.com.cn/UpLoadFiles/image/2014092616401179.jpg
[2014092616404721.jpg]: http://www.mpaypass.com.cn/UpLoadFiles/image/2014092616404721.jpg
[Android HCE]: http://www.mpaypass.com.cn/UpLoadFiles/image/2014092616422551.jpg
[HCE_SE]: http://www.mpaypass.com.cn/UpLoadFiles/image/2014092616441871.jpg
[HCE]: http://www.mpaypass.com.cn/UpLoadFiles/image/2014092616453759.jpg
[2014092616461857.jpg]: /images/20220731/77dbe0c8973745c1b4647219f06cc8bd.png