android – 基于软件的卡仿真(HCE)如何保证NFC安全？

通过引入HCE,不需要安全元件(SE)来模拟卡.因此,没有存储空间来保存模拟卡的应用程序的敏感信息,如余额,CVV2,PIN等.

我只是想知道android如何解决这个问题？应该存储应用程序的敏感信息？ Google电子钱包是否使用此技术？如果是,敏感信息如何保密？

更新1：
网络上的某些链接在使用HCE时会引用基于云的SE(Cloud SE),但我无法理解这个Cloud SE的确实做什么.有关此主题的任何链接,文档或其他材料？

解决方法

HCE带来的主要特点是,当NFC设备处于卡仿真模式(CEM)时,来自NFC控制器的所有数据默认路由到设备的CPU(读取 Android OS).事实并非如此 – 当CEM中的默认路由已经转向安全元素(SE)时.在设备“植根”的情况下,将敏感数据存储在操作系统内存中会引发严重的安全问题 – 您提出的问题.有两种方法可以缓解这些安全风险：

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

这个“更安全的位置”可能是可信执行环境(TEE) – CPU的特殊部分,它运行自己独立的操作系统,因此在主操作系统植根时不会受到损害.在安全级别上,TEE提供了比OS和“SE in the cloud”更高的安全性,但低于SE.如果TEE不够(对于诸如开环支付,身份验证服务 – 身份证,护照等服务的情况),没有人禁止您在提供HCE服务的电话上使用SE.在这种情况下,可以通过使用路由表来防止到CPU(Android OS HCE服务)的默认路由(用于具有特定AID的应用的数据被路由到SE).

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

如果您没有TEE且无法使用SE,您可以通过以下技术使事情变得更加安全：用户验证(用户知道“像PIN这样的东西,或者如果可能的话甚至更好”“用户是” – 生物识别技术),交易限制(低价值交易,一个时间范围内有限的交易数量等),标记化,在事先交易时做Android OS检查(即用户是否拥有root权限)等.

最好的是结合A和B.

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

您可以在Thom Janssen& Sons撰写的文档中阅读更多相关信息.来自UL-TS(前Collis)的人员Mark Zandstra将其命名为“HCE安全隐患”.你可以从这里下载：http://www.ul-ts.com/downloads/whitepapers/finish/6-whitepapers/289-hce-security-implications.