2013年10月31日，Google发布了最新的Android4.4 操作系统，这其中提到了一个新的NFC特性，即所谓的HCE(Host Card Emulation)。 自诞生之初，HCE就赚足了人们的眼球，这不仅仅因为这项令人耳目一新的新技术本身，更因为它让业界的所有人都看到了一种脱离安全载体(SE)而部署NFC的可能性。作者相信，HCE的出现会使得NFC服务的部署更加的容易和便捷，这是因为HCE提供了一种简单但是安全性稍差的模拟NFC卡片的能力。HCE对于Service Providers来说，具有着重大的意义，它使得SP们可以选择一种较低安全性但是开发成本更低、更能在短时间内推向市场的技术。SP们需要在安全性和便捷性之间做一个权衡，以确定是否要采用HCE技术，完成产品向用户的推广。本文的内容选自多家安全实验室的报告，Google开发者文档以及各安卓开发者论坛中的讨论。作者汇总以上的所有信息，希望从安全、部署和商业的角度分析HCE技术带来的相关影响。

　　1.简单回顾一下现有的NFC技术：

　　NFC是进场通信技术的简称，主要有三种模式：点对点，读卡器和卡模拟。前面两种模式目前在市面上的应用还是比较多的，比如通过两个手机对对碰后建立连接传输文件采用的是点对点模式，而把公交卡贴在手机背面就可以读出余额和交易记录采用的即是读卡器模式。卡模拟模式则是我们所说的将手机模拟成为一张卡片，对于卡模拟模式来说，目前基于将所有敏感信息存放在一个叫做SE的安全芯片里，以确保整个环境的安全性。也正因为如此，产业的各方都意识到SE本身是通向“手机钱包”的一扇门，通过掌握SE，可以占据支付、会员卡、优惠券、身份识别、交通和门禁等多种使用场景。

　　目前SE存在着三种方式，UICC(基于手机SIM卡，例如国内移动的方案)，嵌入式SE(Embeded SE，在手机中植入专门的SE芯片，主要由手机制造商所支持和采用)，还有一种就是SD卡方案。

　　SD卡方案被证明是比较难于实施的，是因为SD卡经常是由第三方SP提供的，SD卡方案需要支持SWP-SD方案的手机支持，而市面上相关款式的机型还是太少。另外如果用户希望能使用多种服务的话，还必须在不同的SD卡中间切换。

　　对于UICC和eSE来说，虽然解决了多应用的问题，但SP是没有占有SE的能力的。这意味着SP们必须要同SE的发行者们进行沟通(多为移动通信运营商及设备制造商)，而这已被证明是相当复杂和耗时的。

　　因此，HCE的出现，让大家看到了一丝解决这些问题的曙光。

　　2.HCE的技术特点：

　　正如第一部分钟提到的，NFC有三种模式：读卡器、点对点和卡模拟。为了增强安全性，卡模拟技术中使用到了SE。在移动设备中存在着一个叫做NFC控制器的芯片，该芯片的作用是根据NFC模式来做路由的决定。在卡模拟和点对点模式中，信息会被路由到主机CPU中，然而在卡模拟模式中，信息是被路由到SE芯片的。而在安卓4.4系统中，HCE的出现改变了这种传统的路由方式。卡模拟模式中的命令可以被路由到CPU中所谓的HCE服务上，这就脱离了传统的SE载体的限制，使得一个可以调动HCE服务的软件就可以作为SE存在。如下图所示，需要说明的是，即使采用了HCE技术，传统的路由到SE的通道，也是保留的。

　　不管是HCE也好，基于SE的服务也罢，都需要把应用标识符(AID)进行注册，而AID是在安装的时候就已经确定的。在安卓4.4系统中，默认的NFC路由是到Host CPU。这意味着如果要采用基于SE的NFC服务，就需要在NFC控制器的的所谓路由表中注册一个新的AID。当终端选择AID的时候，通信数据就根据路由表中的记录被路由至Host或者是SE。作为这种机制的一个影响，现有的已经部署了SE的设备在升级至安卓4.4的过程中必须要做一次重新适配，这也意味着用户可能需要到柜台等地方去重新做一次升级。

　　安卓4.4定义了两种NFC服务的类型，支付服务和其它服务。对于支付服务，不管是基于HCE的还是基于SE的，都需要在操作系统中注册为支付服务的类别。在安卓设置菜单里，有一个Tap&Pay的选项，在这里可以选择默认的支付应用。需要注意的是这个设置选项的位置和钱包应用中选择默认支付应用的位置是不一样的，这意味着开发者需要特别注意这点而避免不必要的默认应用选择的冲突。

　　3.HCE安全性的一些讨论：

　　HCE场景下交易的路由还是通过了整个安卓系统，这使得HCE的安全性基本是可以保证的。但是如果是一部终端已经被root的终端，这种基本的安全性就被破坏了。相对于传统的基于SE的方案来说，HCE具有如下一些可能的安全性风险：

　　3.1 用户可以对终端进行Root操作，通过Root用户可以取得所有储存在应用中的信息，包括类似于支付凭证之类的敏感数据，这就使得恶意软件也有了获取敏感信息的可乘之机。从统计数量上来说，只有很少一部分的安卓终端进行了Root操作，但是这仍然意味着数百万级别的终端数量。

　　3.2 恶意软件可以自行Root操作系统。对于前期安卓系统来说，由于存在着一些漏洞，导致不少的恶意软件可以直接Root系统。虽然这些漏洞看起来影响范围不是特别的大(比如如果用户不安装未知来源的安卓软件就不会有这个问题)，但在分析的过程中仍然需要考虑到这个问题。安卓系统的一个已知漏洞的弥补是很难的，这是因为安卓系统冗长的更新过程，需要花费很长的时间才能使得市面上的大部分终端都更新到最新的系统版本。如果在支持HCE的系统版本中也出现了缺陷，也需要花费足够长的时间去解决现有终端上的缺陷问题;

　　3.3 如果手机丢失或者被盗取，一个恶意用户可以Root终端或者通过其它方式访问终端的存储系统，并且获取各种存储于应用中的信息。这可能带来致命的问题，比如恶意用户可以使用这些敏感数据去完成一些伪卡的交易。

　　但是总的来说，如果手机不被Root的话，基本信息的安全还是可以保证的;

　　3.4 上面提到的三点主要是从操作系统和应用层面本身来论证HCE是不安全的，但在作者看来，将支付数据存储在云端并且采用一些技术(如Token或者非对称密钥等)确保从HCE Host到云端服务器的数据传输通道是安全的，HCE的安全性是可以得到提高和增强的，但采用这种方式会对交易的速度产生一定的影响。

　　4. HCE对于NFC生态的影响：

　　HCE提供了一种简单但并非安全的可以替代现有NFC格局的方式，这有可能使得HCE成为加快NFC服务部署的一个因素。HCE对于那些愿意以较低安全性去换取较大市场份额、较快部署速度和较低投入的SP来说，具有重要的意义。HCE可能会让SP们不需要过多关注于同SE的发行者们进行合作，而更加关注与利用HCE可能实现的业务本身。同时对于现有的TSM平台来说，HCE的出现也使得TSM平台需要做相应的功能更改，从可以完成在SE上Applet的个人化，向实现HCE服务个人化功能的演进。

　　由于没有采用基于硬件的SE芯片，HCE的风险会更大。我们可以考虑一个提供大金额服务并且使用范围很广的开环支付服务商采用HCE后可能产生的场景。使用了HCE意味着服务商可以更快并且更灵活的将自己的支付服务提供给广大的用户，但与此同时大量的用户也意味着潜在的风险非常之高。因此在采用HCE之前，服务商必须进行细致的成本估算以确认采用HCE技术的风险是否为可控的或者可能的损失是否是可承受的。另外对于开环支付服务运营商来说，采用HCE还必须协调好参与各方的权力和责任，设计在出现可能风险时应当采取的策略和规则。这对于运营商来说也是一个不小的挑战。支付组织对于HCE的态度对于HCE的推广来说也至关重要。

　　对于闭环服务运营商来说，上面这些提到的这些问题所产生的影响就相对较小，闭环服务运营商的所有支付和结算过程均留存在体系的内部，在规则设定和风险策略上灵活性会更大。同时，如果闭环服务运营商主要运营小额交易的话，采用HCE的风险就可能是可以接受的。

　　不可否认的一点是HCE的出现为NFC服务的进一步拓展提供了一个快捷但是不安全的方案。HCE能否得到发展需要找到合适的应用场景，并且需要有较好的风险控制机制，以确保服务的安全。同时，由于需要和云端服务器进行通讯和授权，在采用了HCE技术以后，能否还保持传统的基于SE的NFC技术在交易场景中快捷和迅速的特点，也是值得观望的。HCE的出现，对于传统的卡厂、运营商来说都产生了一定的威胁和挑战，能否实现产业的共赢，亦是产业各方需要去权衡和考虑的。不管怎样，我们会继续关注HCE技术的发展，期待着这项技术对于NFC的普及所产生的积极作用。