所引进的HCE的，没有安全元件（SE）是需要的模拟卡。其结果是，不存在存储保持该应用的敏感信息仿效卡如余额，CVV2，PIN码等

By the introduction of the HCE, no secure element (SE) is needed to emulate a card. As a result, there is no storage to keep the sensitive information of the app emulating the card such as balance, CVV2, PINs, etc.

我只是想知道如何机器人修复此问题？当应用程序的敏感信息应该被储存在哪里？难道谷歌钱包使用这种技术？如果是，如何在敏感信息仍然是安全的？

I just want to know how android fixes this issue? Where the sensitive information of apps should be stored? Does Google Wallet uses this technology? if yes, how the sensitive information are kept secure?

更新1： 在网络上的某些链接是指基于云的SE（云SE），而使用HCE，但我不明白究竟是什么这个云SE做。关于这个主题的任何链接，文档或其它材料？

Update 1: Some links on the web refer to the Cloud-Based SE (Cloud SE) while using HCE, but I cannot understand what EXACTLY this Cloud SE do. Any links, documents or further materials on this topic?

推荐答案

由HCE带来的主要特点是，当NFC设备在卡仿真模式（CEM），从NFC控制器未来的所有数据路由到设备的CPU（读Android操作系统）默认情况下。此情况并非如此前 - 当在CEM默认路由是朝向安全元件（SE）。在操作系统内存中存储的敏感数据引发严重的安全问题 - 那些你问 - 的情况下，当设备是根。有两种方法可以减轻这些安全风险：

Key feature brought by HCE is that, when NFC device is in Card Emulation Mode (CEM), all data coming from NFC controller are routed towards device's CPU (read Android OS) by default. This was not the case before - when default routing in CEM had been towards secure element (SE). Storing sensitive data in OS memory raises severe security issues - the ones you asked - in the case when device is "rooted". There are two ways to mitigate those security risks:

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

这更安全的地方可以被可信执行环境（TEE） - CPU的特殊组成部分运行其自己独立的操作系统，因此不会受到损害时，主操作系统是植根。上的安全性尺度，发球提供了更多的安全性则OS和SE在云，但小于SE。如果TEE是不够的（这是对服务的情况下，如开环支付，身份认证服务 - 身份证，护照），没有人禁止你使用SE提供HCE服务在手机上。在这种情况下，默认路由到CPU（Android操作系统HCE服务）可以通过使用路由表（用于应用与特定的AID被路由向SE数据）pvented $ P $。

This "more secure location" could be Trusted Execution Environment (TEE) - Special part of CPU that runs its own separate OS and therefore is not compromised when the main OS is rooted. On the security scale, TEE provides more security then OS and "SE in the cloud", but less than SE. If TEE is not enough (which is the case for services such as open loop payments, authentication services - ID cards, passports) nobody forbids you to use SE on the phone that provides HCE service. In that case, default routing to CPU (Android OS HCE service) can be prevented by using routing tables (data intended for application with specific AID is routed towards SE).

b）实施保障机制，使现有的位置更安全

如果您还没有TEE，不能使用SE，可以使事情更安全的使用方法，例如：用户验证（东西，用户知道之类的密码，甚至更好，如果可能的的东西，用户是 - 生物识别技术），交易限制（低价值交易，在一个时间框架的交易数量有限，等等），符号化，做Android操作系统检查前交易（IE浏览器的用户都具有超级用户权限）等。

If you don't have TEE and can't use SE, you can make things more secure by using techniques such as: user verification (something "that user knows" like PIN, or even better if possible "something that user is" - biometrics), transaction constraints (low value transactions, limited number of transactions in one time-frame, etc), tokenization, doing Android OS checks prior transaction (i.e. does user have root priviledges), etc.

最好是结合A和B

您有什么需要了解的是，HCE不适合高安全性的服务。看在 HCE作为更简单而不太安全的解决方案，旨在加快采用NFC服务。它有SP的巨大增值，可以接受的安全性，以换取其他因素的改善较低水平，如上市时间，开发成本，有必要与其他各方合作。

What you need to understand is that HCE is not intended for high security services. Look on HCE as more-simple-but-less-secure solution, intended to accelerate adoption of NFC services. It has great added value for SPs that can accept a reduced level of security in exchange for an improvement of other factors such as time to market, development costs and the need to cooperate with other parties.

您可以了解更多有关这方面写的汤姆·扬森和放文件;马克Zandstra，从UL-TS（前科利斯），人们命名为HCE安全隐患。你可以从这里下载：的http://www.ul-ts.com/downloads/whitepapers/finish/6-whitepapers/289-hce-security-implications.

You can read more about this in document written by Thom Janssen & Mark Zandstra, people from UL-TS (former Collis), named "HCE security implications". You can download it from here: http://www.ul-ts.com/downloads/whitepapers/finish/6-whitepapers/289-hce-security-implications.