HCE方案全面解析：特点、安全及展望

　　2013年10月31日，Google发布了最新的Android4.4操作系统，其中提到了新的NFC特性——HCE (Host Card Emulation)功能。它为基于普通UIM卡和通用设备的“刷手机”应用，提供了一种可能的解决方案。本文汇总了多方面的信息，希望从HCE方案本身的特点、安全和商业的角度分析HCE技术带来的影响。

　　如对本文中涉及到的一些基本概念有疑问，请看本期的另一篇文章《HCE知识盘点》。

　　HCE方案的特点

　　HCE解决方案有着以下的特点和优势：

　　兼容性

　　完全兼容普通的UIM卡和支持NFC功能的Android手机(包括NFC定制机和标准机型)，除系统要求支持4.4及以上版本外无特殊要求;

　　兼容既有的交易处理流程，从通讯频率到交易流程、交易指令流和交易结果反馈，采用HCE方案的“刷手机”交易流程与采用NFC-SE方案的“刷手机”交易流程以及标准非接触卡片的交易流程都完全一致，用户体验完全相同;

　　兼容既有的受理终端设备，不需要做任何技术开发即可直接支持“刷手机”交易;对于纯脱机环境的终端设备来说，从安全性考虑，可能需要在黑名单中增加相应的判断规则，但也不涉及到流程的开发和调整。

　　拓展性

　　由于HCE应用技术通过智能手机上的应用(APP)来实现卡模拟的功能，因此天然就存在一个手机应用(APP)的平台，可以为持卡人提供更多的配套服务功能，也为发行方带来更多业务拓展的可能性。都只需要通过简单的APP更新，即可完成应用发布和应用推送，十分方便。

　　更多的关于HCE和SE方案的比较如下：

　　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技术的安全性可以从两个方面来考虑，一个是提供一个更安全的存储敏感信息的位置，另外一个就是提供更安全的机制来保证这个位置的信息的安全性。

　　敏感信息的存储位置

　　HCE服务虽然运行在Android系统上，但SP可以要求将敏感信息存储和处理放在在一个更安全的位置。这里有四个可以选择位置，他们都在安全性和使用代价之间有不同的平衡。图描述了这四个不同的选择。

图 HCE服务存储敏感信息的位置

　　主机

　　这是最简单但是安全性最差的实现方式，即直接将数据的存储和处理放在主机的应用上进行。除了操作系统提供的非常基本的安全机制外，没有其他附加的保护。实现起来也最容易，但是对于Root的系统没有任何防范。

　　云端SE

　　使用这种方式时，HCE服务将请求通过移动网络发送至云端，敏感信息的存储和处理都在云端服务器。安全性方面比直接在主机的应用上处理和存储要高，但是此时移动网络就变得更加重要了。网络覆盖和网络延时都会成为很大的问题，在网络没有覆盖或信号差的地方这种方式就无法使用了。一次移动支付交易的时间都在一秒以内，云端SE的方案在速度上并不能保证这点。另外云端SE还有一个认证的问题，如果将设备到云端SE的认证证书放在HCE服务里，那么云端SE方案的安全性就大打折扣了。这个问题可以通过用户去完成(如登陆)认证，但是用户体验就很差了。或者用一个单独的硬件SE去处理认证问题。目前来看，对于安全性较高的移动支付服务，这个方案还是最适合的。

　　可信执行环境(TEE)

图 可信执行环境

　　可信执行环境(TEE)是指独立于操作系统的一个执行环境，专门用于提供安全服务。TEE有自己独立的软件和硬件资源，对外提供安全服务接口，用户敏感信息的存储和处理都在这个环境里进行。由于TEE运行自己独立的系统，所以Android主系统被Root不会影响到自己。TEE提供的安全性总体上要比云端SE 高，但是还是没有达到SE提供的安全性，因为它没有SE的反篡改机制。TEE方案很像传统的基于SE的方案，所以其实现起来要更复杂，另外其标准也没有敲定。

　　UICC或嵌入式SE

　　这种方式提供最高级别的安全保证，将敏感信息的存储和处理放在一块单独的安全模块上(SE)。但是这样做HCE技术与传统的基于SE的卡模拟方案相比就毫无优越性可言，甚至增加了实现的复杂度(传统的方法是直达SE，现在是经过操作系统再到达SE)。

　　安全的机制

　　有很多方法机制来保证应用程序的安全性，原则上这些方法都可以用在上面这四种方案中来实现更安全的HCE支付方案。当然使用这些机制会增加用户使用的复杂度，同样也会增加开发者的实现难度。我们必须在安全性、用户使用的方便性和成本之间做一个权衡，来选择合适的机制。

　　关于安全机制，可供考虑的方向有以下几种：用户验证、交易限制、Android系统检查、数据加密等。

　　HCE对产业链的影响

　　HCE将有利于缩短NFC产业链，有利于解决NFC困局，有利于SP (Service Provider)服务快速部署

　　对传统的运营商、卡商和TSM提供商来说，HCE是一个挑战，应加快产品服务升级转型，适应、引导新技术的发展。

　　对于运营商来说，在采用HCE之前，必须进行细致的成本估算以确认采用HCE技术的风险是否为可控的或者可能的损失是否是可承受的。另外对于开环支付服务运营商来说，采用HCE还必须协调好参与各方的权利和责任，设计风险应对策略和规则。这对于运营商来说也是一个不小的挑战。

　　对于现有的TSM平台来说，HCE使得TSM平台需要做相应的功能更改，实现从SE上Applet的个人化，向HCE服务个人化功能的演进。

　　对 SP来说，有利于加快NFC服务部署，降低发卡也交易成本，但应权衡其与安全之间关系。HCE对于那些愿意以较低安全性去换取较大市场份额、较快部署速度和较低投入的SP来说，具有重要的意义。HCE可能会让SP们不需要过多关注于同SE的发行者们进行合作，而更加关注与利用HCE可能实现的业务本身。

　　对支付组织来说，应协调好各参与方的责任，加强风险管理，统一标准。支付组织对于HCE的态度对于HCE的推广来说也至关重要。

　　HCE展望

　　HCE 为移动支付的未来奠定了基础，同时找回了市场对NFC移动支付的兴趣。HCE建立在一个开放的架构上，它使得广义移动支付以及其他的NFC服务，包括客户积分计划、楼宇门禁和过境通行证等，无需使用安全元件就能交付。从目前看来，NFC无疑是即时连接消费者手机和商家的POS终端进行支付，以及进行其他通讯如积分活动等方面最有效的技术。HCE的出现为这些非金融支付类的O2O业务打开了一扇门，在一定程度上提供安全的模拟手段，经济地解决SE的问题，为业务的蓬勃发展大有助力。

　　至于金融级别的移动支付，HCE是否可以登堂入室，第一要看各卡组织是否能够解决本地软件、远程云端SE的安全问题，第二要看，技术上可以解决后上述机构和政府层面是否愿意接受这样的方案。目前，国内有个别运营商和银行在小规模试用类似HCE的技术手段，希望推动移动支付的发展，但是否能够成为标准，形成规模，还需要时间考验。

　　推荐微信公众号，NFC日报：nfcdaily 移动支付网：mpaypass 您值得拥有!