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

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

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

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

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

“付钱啦!

”没错!

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

　　美好的移动支付!

美好的移动支付?

　　等下，手机?

刷手机支付?

没错，确切的说，是刷具有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