软件基础的卡模拟（HCE）如何保证NFC安全？

Question

软件基础的卡模拟（HCE）如何保证NFC安全？

androidsecuritynfcandroid-payhce

6

通过引入HCE技术，模拟卡片时不需要安全元素(SE)。因此，没有存储敏感信息的位置，例如应用程序模拟卡片的余额、CVV2、PIN等。

我只是想知道安卓如何解决这个问题？应用程序的敏感信息应该存储在哪里？Google Wallet是否使用了这项技术？如果是，那么敏感信息是如何保持安全的？

更新1：一些网络链接在使用HCE时提到了基于云的安全元素(Cloud SE)，但我无法理解这个Cloud SE具体是做什么的。对于这个话题，有没有链接、文件或更多资料？

- TonySalimi

5个回答

3

我只想知道安卓是如何解决这个问题的？

简单的回答：它根本没有解决。Google钱包将与卡相关的数据（卡号、有效期信息、动态卡验证码等）存储在移动电话的存储器（RAM，部分闪存）中。请注意，信用卡上没有余额信息。 Google Wallet（实际上是MasterCard）也不存储CVC2或卡PIN。

应用程序的敏感信息应该存储在哪里？Google Wallet使用了这项技术吗？

“应该”...嗯...它确实在RAM和可能存在于手机（内部）闪存中存储（临时）卡数据。通常不涉及安全存储器。

如果是，那么敏感信息是如何保持安全的？

这就是棘手的部分。这就是所谓的基于云的SE的作用。 Cloud SE意味着敏感的卡数据存储在“云”中，而不是（或仅是临时的）存储在最终用户的设备上。在实践中，这可以通过两种方式实现：

云SE的功能与普通的智能卡/安全元件完全相同。在这种情况下，最终用户设备上的HCE应用程序将立即将所有接收到的智能卡命令（APDU）重定向到“云”中。云SE会处理该命令并生成响应。然后该应用将通过NFC接口（HCE）将此响应发送回支付终端。这种场景的主要劣势是，HCE通信需要在整个通信期间与“云”保持稳定（且相对快速的）连接。
（这在某种程度上就是Google Wallet的工作方式。）云SE充当令牌服务，生成临时卡数据（临时卡号和临时动态验证代码），仅在有限数量的交易期间内有效并在非常有限的时间范围内有效。每当此临时信息过期时，HCE应用程序都会请求一组新的临时卡数据并将其存储在手机存储器中。当支付终端建立与HCE应用程序（模拟信用卡）的连接时，该应用程序将与支付卡协议（EMV）进行通信，并将临时信息嵌入模拟的卡数据中。

- Michael Roland

感谢Michael。鉴于您在NFC和安全方面的专业知识，能否介绍一些关于此主题的技术文件或链接给我呢？我对NFC安全、移动钱包和移动安全也很感兴趣。非常感谢您提前的帮助。 :) - TonySalimi

2

我认为Android并没有“解决这个问题”，甚至也没有打算去解决它：这更多是应用程序设计者的任务。可能的方法有：

将敏感信息存储在手机之外：“云中安全元件”。一个明显的缺点是手机需要在线才能成功进行交易。
通过某些秘密输入（例如，用户输入密码或PIN码）生成敏感信息，并在手机之外验证，例如通过非接触式基础设施。

- mictter

1

Android操作系统不提供安全存储来存储HCE交易中使用的敏感数据。

在HCE（基于云的SE）移动应用程序中，敏感数据不会作为安全元素存储。

用于生成付款加密术语的敏感数据PAN、对称卡主密钥等受以下方式保护：

保护PAN

采用EMV令牌化规范替换PAN，其中令牌化PAN仅限于某些域。

保护对称密钥

对称卡主密钥被替换为受限版本的对称密钥。

VISA的HCE规范定义了限制使用密钥（LUK），该密钥仅限于一定时间和交易使用。

MasterCard的HCE规范定义了单次使用密钥（SUK），仅限于一次交易使用。

其他HCE规范采用类似机制。

因此，在云中存储敏感数据（PAN、对称密钥），移动应用程序存储敏感数据的有限版本。这样可以最大程度地减小风险。

移动应用程序使用白盒密码术，以防止数据被盗，这是VISA、MasterCard和其他人建议的。白盒密码术很难破解。顺便说一下，它被称为“基于云的SE”，因为敏感数据存储在云上，而不是移动应用程序中，这与安全元素（在SE /移动SE中，敏感数据存储在SE内部）的方式不同。

- Shahidul

0

使用Tokenization与“云中的SE”相结合...这可以避免“手机需要在线”的依赖。

- Pavan

Pavan，你能详细描述一下你的解决方案吗？ - TonySalimi

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- borko.lepojevic · Accepted Answer

HCE带来的关键特性是，当NFC设备处于卡模拟模式(CEM)时，默认情况下所有来自NFC控制器的数据都会路由到设备的CPU(即Android操作系统)。在此之前并非如此——当默认路由在CEM中指向安全元素(SE)时，存储敏感数据在操作系统内存中会引发严重的安全问题——就像你提出的这些问题一样——如果设备被“rooted”。有两种方法可以减轻这些安全风险：

A）提供更安全的位置来存储敏感数据。

这个“更安全的位置”可以是可信执行环境(TEE)，即运行其自己独立操作系统的CPU的特殊部分，因此当主操作系统被rooted时不会受到影响。在安全等级上，TEE提供比操作系统和“云中SE”更高的安全性，但比SE低。如果TEE不够用（例如开放式循环支付、认证服务-身份证、护照等服务），则可以在提供HCE服务的手机上使用SE。在这种情况下，可以使用路由表（将针对特定AID的数据路由到SE），以防止默认路由到CPU（Android OS HCE服务）。

B）实现安全机制，使现有位置更安全。

如果您没有可信执行环境（TEE）并且无法使用安全元素（SE），则可以通过使用以下技术使事物更加安全：用户验证（例如“用户知道”的PIN码，或者如果可能的话，“用户是”-生物识别），交易限制（低价值交易，在一个时间框架内限制交易次数等），令牌化，进行Android操作系统检查（即用户是否具有root权限）等。最好的方法是将A和B结合起来。

需要理解的是，HCE不适用于高安全性服务。将HCE视为更简单但不太安全的解决方案，旨在加速NFC服务的采用。对于可以接受降低安全级别以换取其他因素（如上市时间、开发成本和与其他方的合作需求）改善的SPs，它具有很大的附加价值。

您可以阅读由Thom Janssen和Mark Zandstra编写的文档，这两位都是来自UL-TS（前Collis）的人员，名为“HCE安全性影响”。您可以从此处下载：http://www.ul-ts.com/downloads/whitepapers/finish/6-whitepapers/289-hce-security-implications。