6

通过引入 HCE，无需安全元件 (SE) 即可模拟卡。因此，没有存储空间来保存模拟卡的应用程序的敏感信息，例如余额、CVV2、PIN 等。

我只想知道android如何解决这个问题？应用程序的敏感信息应该存储在哪里？Google 电子钱包是否使用了这项技术？如果是，如何保护敏感信息的安全？

更新 1： 网络上的一些链接在使用 HCE 时引用了基于云的 SE (Cloud SE)，但我无法理解这个 Cloud SE 到底做了什么。有关此主题的任何链接、文档或其他材料？

4

5 回答 5

8

HCE 带来的关键特性是，当 NFC 设备处于卡仿真模式 (CEM) 时，来自 NFC 控制器的所有数据默认路由到设备的 CPU（读取 Android OS）。以前不是这种情况 - 当 CEM 中的默认路由针对安全元件 (SE) 时。将敏感数据存储在操作系统内存中会引发严重的安全问题 - 您所询问的问题 - 在设备“植根”的情况下。有两种方法可以减轻这些安全风险：

A) 为敏感数据提供更安全的位置

这个“更安全的位置”可能是可信执行环境 (TEE) - CPU 的特殊部分，它运行自己的独立操作系统，因此在主操作系统被植根时不会受到损害。在安全尺度上，TEE 提供的安全性高于 OS 和“云中的 SE”，但不如 SE。如果 TEE 还不够（开环支付、身份验证服务 - 身份证、护照等服务就是这种情况），没有人会禁止您在提供 HCE 服务的手机上使用 SE。在这种情况下，可以通过使用路由表来阻止默认路由到 CPU（Android OS HCE 服务）（用于具有特定 AID 的应用程序的数据被路由到 SE）。

B) 实施安全机制，使现有位置更安全

如果您没有 TEE 并且无法使用 SE，则可以使用以下技术使事情更安全：用户验证（“用户知道”的东西，如 PIN，或者如果可能的话，甚至更好的“用户的东西” -生物识别）、交易限制（低价值交易、一个时间框架内的交易数量有限等）、标记化、做 Android 操作系统检查之前的交易（即用户是否有 root 权限）等。

最好是结合A和B。

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

您可以在 UL-TS（前 Collis）人员 Thom Janssen 和 Mark Zandstra 编写的名为“HCE 安全性影响”的文档中阅读有关此内容的更多信息。您可以从这里下载：http ://www.ul-ts.com/downloads/whitepapers/finish/6-whitepapers/289-hce-security-implications 。

于 2014-05-03T10:17:25.507 回答
3

我只想知道android如何解决这个问题？

简单的回答：它没有。Google Wallet 将卡相关数据（卡号、有效性信息、动态卡验证码等）存储在手机内存（RAM，部分闪存？）中。请注意，信用卡上没有存储余额信息。Google Wallet（它实际上是 MasterCard）也不存储 CVC2 或卡PIN。

应用程序的敏感信息应该存储在哪里？Google 电子钱包是否使用了这项技术？

应该……好吧……它确实将（临时）卡数据存储在 RAM 中，也可能存储在手机的（内部）闪存中。这里通常不涉及安全存储器。

如果是，如何保护敏感信息的安全？

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

  1. 云 SE 的作用就像普通的智能卡/安全元件一样。在这种情况下，最终用户设备上的 HCE 应用程序会立即将所有收到的智能卡命令 (APDU) 重定向到“云”。云 SE 将处理命令并生成响应。然后应用程序通过 NFC 接口 (HCE) 将此响应发送回支付终端。这种场景的主要缺点是 HCE 通信需要在整个通信过程中与“云”建立稳定（且相对快速）的连接。

  2. [这有点像 Google Wallet 的工作方式。] Cloud SE 充当令牌服务，生成仅对有限数量的交易和非常有限的时间范围内有效的临时卡数据（临时卡号和临时动态验证码） . 每当此临时信息过期时，HCE 应用程序就会请求一组新的临时卡数据并将其存储在手机内存中。当支付终端与 HCE 应用程序（模拟信用卡）建立连接时，应用程序与支付卡协议 (EMV) 进行通信，并将临时信息嵌入模拟卡数据中。

于 2014-04-28T23:17:58.790 回答
2

我不认为 Android “解决了这个问题”，或者它甚至打算这样做：它更多的是应用程序设计人员的任务。可能的方法是：

  • 将敏感信息存储在手机外：“SE in the cloud”。一个明显的缺点是手机需要在线才能使交易成功。
  • 生成敏感信息，处理一些秘密输入（例如，用户输入密码或 PIN）并在电话外验证它，例如通过非接触式基础设施。
于 2014-04-28T15:58:57.280 回答
1

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

在 HCE（基于云的 SE）移动应用程序不将敏感数据存储为安全元素的情况下。

敏感数据PAN，对称卡主密钥等，用于生成受以下方式保护的支付密码：-

保护 PAN

EMV 的 Tokenization 规范用于使用 Tokenized PAN 替换 PAN，其中 Tokenized PAN 仅限于特定域。

保护对称密钥

对称卡主密钥被限制版本的对称密钥取代。

VISA 的 HCE 规范定义了有限使用密钥 (LUK)，它仅限于在有限的时间段和交易中使用。

MasterCard 的 HCE 规范定义了单次使用密钥 (SUK) 限制以用于单次交易。

其他 HCE 规范遵循类似的机制。

所以在云上存储敏感数据（PAN，对称密钥），移动应用程序存储敏感数据的有限版本。因此，它最大限度地降低了风险。

正如 VISA、MasterCard 和其他公司所建议的那样，移动应用程序使用白盒加密 技术来阻止数据被盗。白盒密码学很难破解。

顺便说一句，它被称为基于云的 SE，因为敏感数据存储在云端而不是移动应用程序上，这与安全元素的方式不同（在 SE/Mobile SE 中，敏感数据存储在 SE 中）。

于 2017-01-05T08:54:01.203 回答
0

将Tokenization与“SE in the cloud”结合使用……这样可以避免“Phone需要在线”的依赖。

于 2015-05-22T17:51:49.097 回答