通过引入 HCE，无需安全元件 (SE) 即可模拟卡。因此，没有存储空间来保存模拟卡的应用程序的敏感信息，例如余额、CVV2、PIN 等。
我只想知道android是如何解决这个问题的？应用程序的敏感信息应该存储在哪里？ Google 电子钱包是否使用了这项技术？如果是，如何保护敏感信息的安全？
更新 1： 网络上的一些链接在使用 HCE 时引用了基于云的 SE（Cloud SE），但我无法理解这个 Cloud SE 到底做了什么。有关此主题的任何链接、文档或其他材料？
【问题讨论】：
标签： android security nfc android-pay hce
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，或者如果可能更好的话“用户的东西is" - 生物识别）、交易限制（低价值交易、在一个时间范围内的交易数量有限等）、标记化、Android OS 检查之前的交易（即用户是否具有 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。
【讨论】：
我只是想知道 android 是如何解决这个问题的？
简单的答案：它确实不是。 Google Wallet 将卡相关数据（卡号、有效性信息、动态卡验证码等）存储在手机内存（RAM，部分闪存？）中。请注意，信用卡上没有存储余额信息。 Google Wallet（它实际上是 MasterCard）也不存储 CVC2 或 card PIN。
应用的敏感信息应该存储在哪里？ Google 电子钱包是否使用这项技术？
应该 ...好吧...它确实将（临时）卡数据存储在 RAM 中，也可能存储在手机的（内部）闪存中。这里通常不涉及安全内存。
如果是，如何保护敏感信息的安全？
这是棘手的部分。这就是基于云的 SE 的用武之地。云 SE 意味着敏感的卡数据存储在“云中”，而不是（或仅临时）存储在最终用户的设备上。在实践中，这可以通过两种方式实现：
云 SE 就像普通的智能卡/安全元件一样。在这种情况下，最终用户设备上的 HCE 应用程序会立即将所有收到的智能卡命令 (APDU) 重定向到“云”。云 SE 将处理命令并生成响应。然后应用程序通过 NFC 接口 (HCE) 将此响应发送回支付终端。这种场景的主要缺点是 HCE 通信需要在整个通信过程中与“云”建立稳定（且相对快速）的连接。
[这有点像 Google Wallet 的工作方式。] Cloud SE 充当令牌服务，生成仅对有限数量的交易有效的临时卡数据（临时卡号和临时动态验证码）在非常有限的时间范围内。每当此临时信息过期时，HCE 应用程序都会请求一组新的临时卡数据并将其存储在手机内存中。当支付终端与 HCE 应用（模拟信用卡）建立连接时，应用会与支付卡协议 (EMV) 进行通信，并将临时信息嵌入模拟卡数据中。
【讨论】：
我认为 Android 不会“解决这个问题”，甚至没有打算这样做：这更多是应用程序设计人员的任务。可能的方法是：
【讨论】：
Android 操作系统不提供安全存储来存储 HCE 交易中使用的敏感数据。
如果 HCE（基于云的 SE）移动应用程序不将敏感数据存储为安全元素。
敏感数据PAN、对称卡主密钥等，用于生成支付密码，受以下方式保护：-
保护 PAN
EMV 的 Tokenization 规范用于使用 Tokenized PAN 替换 PAN，其中 Tokenized PAN 仅限于特定域。
保护对称密钥
对称卡主密钥已替换为受限版本的对称密钥。
VISA 的 HCE 规范定义了有限使用密钥 (LUK)，仅限于在有限的时间段和交易中使用。
万事达卡的 HCE 规范定义了单次使用密钥 (SUK) 限制以用于单次交易。
其他 HCE 规范遵循类似的机制。
因此，敏感数据（PAN、对称密钥）存储在云端，移动应用程序存储敏感数据的有限版本。从而将风险降至最低。
移动应用程序使用 白盒密码术 来阻止数据被盗，正如 VISA、MasterCard 和其他人所建议的那样。白盒密码学很难破解。
顺便说一下，它被称为基于云的 SE，因为敏感数据存储在云端而不是移动应用程序上，这与安全元素的方式不同（在 SE/Mobile SE 中，敏感数据存储在SE）。
【讨论】：
结合“云端SE”使用Tokenization ...这样可以避免“电话需要在线”的依赖。
【讨论】：