移动支付很美好 但基于SEHCE的NFC支付的安全更加重要.docx

移动支付很美好 但基于SEHCE的NFC支付的安全更加重要.docx

《移动支付很美好 但基于SEHCE的NFC支付的安全更加重要.docx》由会员分享，可在线阅读，更多相关《移动支付很美好 但基于SEHCE的NFC支付的安全更加重要.docx（13页珍藏版）》请在冰点文库上搜索。

移动支付很美好但基于SEHCE的NFC支付的安全更加重要

在商场，挑选完商品后的下一个动作是什么?

“付钱啦!

”没错!

在挑选完商品后，我们需要拿出钱包、打开、掏钱、支付，或者拿出钱包、打开、取出信用卡、刷卡支付，再或者拿出手机、刷手机支付。

　　美好的移动支付!

美好的移动支付?

　　等下，手机?

刷手机支付?

没错，确切的说，是刷具有NFC功能的智能移动设备——智能手机、智能手环、智能手表等等。

NFC，NearFieldCommunication，也就是所谓的“近场通信”，是一种短距高频的无线电技术。

XX百科上对NFC的解读是“由非接触式射频识别（RFID）及互联互通技术整合演变而来，在单一芯片上结合感应式读卡器、感应式卡片和点对点的功能，能在短距离内与兼容设备进行识别和数据交换。

”

　　其实，使用拥有NFC功能的手机进行移动支付早已不是什么新鲜事儿了。

在日本，NFC移动支付产业就获得了很大的成功，对于很多日本人来说，手机就是他们的钱包。

去商场，刷手机买衣服;到影院，刷手机买门票;在餐厅，刷手机来买单……刷、我刷、刷刷刷——没钱了!

这意味着你的手机钱包被刷爆了，但也可能是你手机钱包里的钱被人给偷光了。

　　移动支付很美好，移动支付的安全更头疼。

　　实现近场支付的软硬双模式

　　如今的移动支付（近场支付）主要通过两种不同的卡模拟方式来实现支付，即SE方式和HCE方式。

　　安全模块SE（SecureElement）是一种基于硬件的卡模拟方式，能够提供对敏感信息的安全存储，并为交易事务提供一个安全的执行环境。

NFC芯片将从外部读写器接收到的命令转发到SE，SE进行处理后，再通过NFC控制器回复。

　　HCE（Host-basedCardEmulation），即基于主机的卡模拟方式。

HCE方式不需要SE安全模块，由在手机中运行的一个应用或云端的服务器完成SE的功能，也就是说NFC芯片所接收到的数据会由操作系统发送至手机应用里，或者通过移动网络发送至云端服务器中来完成交互。

无论是本机应用还是云端服务器都绕过了手机内置SE的限制。

　　基于硬件的SE方式具有很高的安全性，不过从SE发卡、使用、管理等角度来看，其应用复杂，推广较慢。

实际上，正是由于各个相关机构对SE控制权的争夺，导致了NFC移动支付的发展缓慢。

　　基于软件的HCE方式，很明显拥有较易实现，易于推广的优势。

但同时，其也面临着来自各个方面的安全威胁。

　　面临重重安全危机的HCE

　　HCE方式之所以面临重重安全问题，与其实现机制有着很大的关系。

例如HCE的云端实现模式，在其云中发卡过程里，用户的卡数据等信息会被保存在云端，NFC手机开启HCE服务，并安装电子钱包（由HCE发行者提供，如银行等），而替代个人银行主账号信息的支付令牌Token则保存在本地，云端实现Token与主账号的对应。

在进行交易验证过程里，用户在电子钱包中选择支付账户后，将手机靠近POS机实现支付，此时通常会要求用户输入PIN码确认，Token及交易信息会传递给POS机，再由POS机提交信息给后台系统进行认证和交易授权。

另外，HCE方式还需要安卓4.4以上手机操作系统的支持。

　　看看，问题来了!

从数据安全、代码安全到传输安全，基于HCE的支付业务所面临的安全挑战实在是够多。

　　如果模拟卡数据是保存在手机本地，那么脆弱的安卓系统很容易被黑客利用其弱点和漏洞进行攻击获得Root权限，进而轻松获取支付凭证、交易密码、加密密钥等敏感信息，劫持交易，将用户银行里的钱划到黑客的腰包里。

如果手机丢失，那就更惨啦，由于不具备SE的抗攻击特性，手机里的敏感数据存在“被看到、被拿走”的安全风险。

　　而且，支付流程本身的业务逻辑代码也面临着被反编译和逆向分析的威胁。

近期爆发的Xcode事件，更让人们惊讶的发现，其实在软件应用诞生之初就可能已经感染病毒。

　　如果模拟卡数据保存在了云端服务器，那么云端自身的可用性、安全性，以及第三方的可信性问题就不得不需要提前考虑了。

在本地与云端进行数据通讯时所使用的加密密钥更要极好的予以保管。

　　保卫HCE需要从“始”到“终”

　　现在许多的HCE支付方案会采用Token、一次一密、多重认证等安全机制来实现对业务的安全保护，但很显然，这还远远不够。

既然HCE是基于软件的方式，那么自然需要基于软件生命周期维度的全方位安全防护：

从应用规划阶段即开始，到应用设计、应用开发、应用发布，甚至是应用运维都需要将不同的安全能力融入其中。

　　具体到HCE实现的关键组件和环节，首先需要对Token、LUK、报文秘钥、通讯证书等关键数据实施白盒加密，在身份认证方面加入设备、应用、用户等多维度认证环节。

通过对涉及支付核心逻辑的SO库的源代码进行一重加固，防止源码在内存运行中被窃取后进行逆向分析;然后对编译后产生的支付SDK进行二重加固，防止SDK被反编译和非法调用;最后对电子钱包APP进行三重加固，防止APP被非法破解和篡改。

而且为了在安全的前提下保证用户体验，还要对应用本身的静态数据及运行过程中产生的动态数据进行透明加密，对运行环境进行安全检测，例如检查系统安全、TEE安全、存储安全、运行安全等等。

　　采取这些安全措施就够了么?

当然……还不够，除此之外，HCE的健康运行还需要相应的安全服务支撑。

比如，对HCE客户端进行安全测评，规范Visa云端支付。

还要对NFC手机进行适配测试，包括适用主流NFC机型、系统版本及CPU架构等。

　　移动支付极大的便利了人们的生活，而为了让人们能够快乐的享受移动支付，需要为其提供从“始”至“终”的安全防护。

威胁无孔不入，安全更要无处不在。

HCE知识盘点 大事记、NFC卡模拟、与SE兼容

2016-04-07 中钞研究院 NFC日报

　　NFC技术发展

　　NFC是“近场通讯”的简称，采用短距离RF（射频）通讯技术。

NFC 工作频率为13.56Hz，有效范围为500px 以内，其传输速度有106 Kbit/秒、212 Kbit/秒或者424 Kbit/秒三种，能够应用在手机/平板、电脑/游戏机、印表机、电子产品，甚至家电设备中。

　　NFC技术已经有十来年历史，在过去的几年里一直被称为很有前景的便利移动支付技术。

但即使在NFC手机日渐成为智能机标配的今天，基于NFC 的移动支付却没有在消费者群体中形成气候。

一个重要的原因在于：

所有人都在争着控制NFC 技术的安全元件（the Secure Element）。

安全元件，顾名思义，是保证财产信息安全的，控制这个就可以控制每一笔交易的费用。

SE导致了金融机构、OEM和运营商之间无休止的争斗，没办法联合起来，这使得NFC移动支付发展缓慢。

　　HCE概念

　　HCE（host-based cardemulation），即基于主机的卡模拟。

　　在一部配备NFC功能的手机实现卡模拟，目前有两种方式：

一种是基于硬件的，称为虚拟卡模式（Virtual Card Mode）;一种是基于软件的，被称为主机卡模式（Host Card Mode）。

　　在虚拟卡模式下，需要提供安全模块SE（Secure Elemen），SE提供对敏感信息的安全存储和对交易事务提供一个安全的执行环境。

NFC芯片作为非接触通讯前端，将从外部读写器接收到的命令转发到SE，然后由SE处理，并通过NFC控制器回复。

　　在主机卡模式下，不需要提供SE，而是由在手机中运行的一个应用或云端的服务器完成SE的功能，此时NFC芯片接收到的数据由操作系统或发送至手机中的应用，或通过移动网络发送至云端的服务器来完成交互。

两种方式的特点都是绕过了手机内置的SE的限制。

这一标准的妙处在于，它不需要整个行业为了控制安全元件而争斗。

　　使用基于主机的卡模拟时（HCE），NFC 控制器从外部读写终端接收到的数据将直接被发送到主机系统上，而不是安全模块。

上图描述了这个过程。

　　HCE技术的关键大事记

　　2012/09/19,SimplyTapp在Android第三方CyanogenMod固件中实现主机卡模拟技术HCE;

　　2013/11/01,Google发布最新的Android4.4操作系统，支持主机卡模拟HCE技术，目前已通过谷歌钱包将HCE应用到Nexus 5手机中，可支持Paypass;

　　2013/12/13,美国连锁咖啡TimHortons在北美4000多家门店推出基于HCE的NFC支付应用;

　　2014/02/17,西班牙银行Bankinter发布基于HCE技术的虚拟卡手机钱包;

　　2014/02/19,Visa和万事达卡同时宣布将基于HCE技术推动云端移动支付;

　　2014/02/20,全球智能卡制造商ABnote与SimplyTapp合作，将HCE技术加入到其TSM平台中。

　　NFC标准对Android支持

　　NFC标准对很多智能卡通讯协议提供了支持，而Android4.4系统也支持包括主流智能卡应用在内的很多非接触智能卡协议，因此使用NFC手机和HCE应用，就可以方便的模拟出不同类型的智能卡应用。

　　同样市场上很多NFC读卡终端也支持这些协议，包括一部支持NFC的Android设备作为读卡器本身。

这样通过HCE技术我们只用Android设备就可以部署一个端对端的NFC解决方案。

　　Android4.4系统使用NFC论坛制定的的ISO-DEP标准协议（基于ISO/IEC14443-4（ISO-DEP）标准）进行数据传输，传输的数据单元被称为应用协议数据单元（APDUs）。

　　另外，在数字协议方面（相当于MAC层协议）Android系统只要求对顶层的NFC-A（ISO/IEC 14443-3 Type A）技术提供支持，而对NFC-B技术的（ISO/IEC 14443-3 Type B）的支持则是可选的，这些技术提供了包括初始化、冲突检测等解决方案。

　　Android系统上的HCE技术是通过系统服务实现的（HCE服务）。

使用服务的一大优势是它可以一直在后台运行而不需要有用户界面。

这个特点就使得HCE技术非常适合像会员卡、交通卡、门禁卡这类的交易，当用户使用时无需打开程序，只需要将手机放到NFC读卡器的识别范围内，交易就会在后台进行。

当然更推荐为用户提供配套的HCE应用UI界面，这样除了像普通的智能卡片一样刷卡使用以外，还可以通过UI界面为用户提供更多的在线服务功能，包括查询、充值和信息推送等。

　　当用户将手机放到NFC读卡器的识别范围时,Android系统需要知道读卡器真正想要和哪个HCE服务交互，这样它才能将接收到的数据发送到相应的HCE应用。

HCE参考ISO7816规范，定义了一种通过应用程序AID来选择相应应用的方法。

因此，如果要为自己的新的读卡设施部署NFC应用，就需要定义自己的AID。

　　HCE技术实现NFC模拟

　　在手机上用HCE技术实现NFC卡模拟，首先要创建一个处理交易事务的HCE 服务，Android4.4为HCE服务提供了一个非常方便的基类，我们可以通过继承基类来实现自己的HCE服务。

如果要开发已存在的NFC系统，我们只需要在 HCE 服务中实现NFC 读卡器期望的应用层协议。

反之如果要开发自己的新的NFC 系统，我们就需要定义自己的协议和APDU 序列。

一般而言我们应该保证数据交换时使用很少的APDU包数量和很小的数据量，这样用户就不必花很长时间将手机放在NFC 读卡器上。

　　HCE 技术只是实现了将NFC 读卡器的数据送至操作系统的HCE 服务或者将回复数据返回给NFC 读卡器，而对于数据的处理和敏感信息的存储则没有具体实现细，所以说到底HCE 技术是模拟NFC 和SE 通信的协议和实现。

但是HCE 并没有实现SE，只是用NFC 与SE 通信的方式告诉NFC 读卡器后面有SE的支持，从而以虚拟SE 的方式完成NFC 业务的安全保证。

既然没有SE，那么HCE 用什么来充当SE 呢，解决方案要么是本地软件的模拟，要么是云端服务器的模拟。

负责安全的SE如何通过本地化的软件或者远程的云端实现，并且能够保障安全性，需要HCE厂商自己考虑和实现。

　　HCE方案与SE方案的路由和兼容

　　支持HCE功能的Android4.4手机，很多也同时支持SWP-SIM或者SWP-SD之类的SE模式实现手机支付功能，因此存在一个应用 AID路由的问题，通常是由CLF芯片中的AID路由表来负责进行相关的路由工作，由手机生产厂商负责开发实现具体的规则。

具体系统架构和指令流向如下图：

　　因为CLF芯片的路由表，是通过读卡终端发送的Select指令中的应用AID来进行区分和路由的，因此对于SE（SWP-SIM）和手机 HOSTCPU中的HCE应用，如果各自支持的具体智能卡应用的AID均不相同，则不会出现任何路由和兼容性的问题，所有的应用均能够被正确识别和分别路由到SE（SWP-SIM）或者HCE应用，并正常完成交易的实现和处理。

　　如果SE（SWP-SIM）和手机HOST CPU中的HCE应用，支持的智能卡应用中有相同的AID，则存在一个路由优先级的问题，同时涉及到支持SE（SWP-SIM）的设备升级到Android4.4之后，对于SWP-SIM中原有的应用的兼容问题。

　　按照google提供的Android API的要求，HCE APP的路由优先级更高，表示说如果存在相同的AID的应用，则会被优先路由到HCE应用来处理，那么SWP-SIM中的相同AID的应用将无法被调用和使用，会出现系统升级到4.4版本后，无法兼容既有应用使用的问题，除非不安装HCE 应用。

　　因此运营商的定制手机，通常会要求修改一下路由的优先级，使SE（SWP-SIM）的路由优先级更好，即如果存在相同的AID的应用，则会被优先路由到SWP-SIM来处理，确保对于旧时发行的支持SE的设备，在系统升级到4.4之后的兼容性。

阅读原文阅读 3332 投诉

HCE方案全面解析：

特点、安全及展望

2016-04-07 中钞研究院 NFC日报

　　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的技术手段，希望推动移动支付的发展，但是否能够成为标准，形成规模，还需要时间考验。