Fatal编程技术网
  • android/
  • Android 基于软件的卡仿真（HCE）如何保证NFC安全？

Android 基于软件的卡仿真（HCE）如何保证NFC安全？

android security

Android 基于软件的卡仿真（HCE）如何保证NFC安全？,android,security,nfc,android-pay,hce,Android,Security,Nfc,Android Pay,Hce,通过引入HCE，不需要安全元件（SE）来模拟卡。因此，没有存储来保存模拟卡的应用程序的敏感信息，如余额、CVV2、PIN等 我只是想知道android是如何解决这个问题的？应用程序的敏感信息应存储在何处？谷歌钱包使用这种技术吗？如果是，如何确保敏感信息的安全 更新1: 在使用HCE时，web上的一些链接提到了基于云的SE（Cloud SE），但我无法理解此Cloud SE的确切功能。有关于这个主题的链接、文档或其他资料吗？我不认为Android“解决了这个问题”，也不认为它打算解决这个问题：它更

通过引入HCE，不需要安全元件（SE）来模拟卡。因此，没有存储来保存模拟卡的应用程序的敏感信息，如余额、CVV2、PIN等

我只是想知道android是如何解决这个问题的？应用程序的敏感信息应存储在何处？谷歌钱包使用这种技术吗？如果是，如何确保敏感信息的安全

更新1: 在使用HCE时，web上的一些链接提到了基于云的SE（Cloud SE），但我无法理解此Cloud SE的确切功能。有关于这个主题的链接、文档或其他资料吗？

我不认为Android“解决了这个问题”，也不认为它打算解决这个问题：它更像是应用程序设计者的任务。可能的办法是：

  • 在手机外存储敏感信息：“SE在云中”。一个明显的缺点是，手机需要在线才能成功进行交易
  • 通过一些秘密输入（例如，用户输入密码或PIN）生成敏感信息，并在手机外部（例如通过非接触式基础设施）对其进行验证
我只是想知道android是如何解决这个问题的？

简单的回答是：事实并非如此。谷歌钱包将卡相关数据（卡号、有效性信息、动态卡验证码等）存储在手机存储器（RAM，部分闪存？）中。请注意，信用卡上没有存储余额信息。谷歌钱包（实际上是万事达卡）也没有存储CVC2或卡片PIN

应用程序的敏感信息应该存储在哪里？谷歌钱包使用这种技术吗？

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

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

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

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

  • [这在某种程度上是谷歌钱包的工作方式。]云SE作为一种代币服务，生成临时卡数据（临时卡号和临时动态验证码），该数据仅在有限的交易数量和时间范围内有效。每当此临时信息过期时，HCE应用程序将请求一组新的临时卡数据并将其存储在手机存储器中。当支付终端与HCE应用程序（模拟信用卡）建立连接时，该应用程序与支付卡协议（EMV）通信，并将临时信息嵌入模拟卡数据中

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

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

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

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

    如果您没有TEE且无法使用SE，您可以通过使用以下技术使事情更加安全：用户验证（用户知道的东西，如PIN，或更好的，如果可能的话，是“用户知道的东西”-生物特征）、交易限制（低值交易、一个时间范围内的有限交易数量等）、标记化，执行Android操作系统检查之前的事务（即用户是否具有根权限），等等

    最好是把A和B结合起来

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

    您可以在UL-TS（前Collis）人员Thom Janssen&Mark Zandstra编写的名为“HCE安全影响”的文档中阅读更多关于此的信息。您可以从这里下载：。

    将标记化与“云中的SE”结合使用。。。这可以避免“手机需要在线”的依赖性