How does software-based card emulation (HCE) guarantee NFC security?

Question

With the implementation of HCE, a protected element (SE) is not required to emulate a card. As a result, there is no storage for storing confidential information of an application simulating a card, for example, balance, CVV2, PIN, etc.

I just want to know how android fixes this problem? Where is confidential application information stored? Does Google Wallet use this technology? if so, how is sensitive information kept secure?

Update 1: Some links on the Internet refer to Cloud-Based SE (Cloud SE) when using HCE, but I can’t understand EXACTLY that it is Cloud SE. Any links, documents or additional materials on this topic?

Answer 1

A key feature of HCE is that when the NFC device is in card emulation (CEM) mode, all data coming from the NFC controller is sent to the processor processor by default (see Android OS). This was not the case before - when the default routing in CEM was directed to a secure element (SE). Storing confidential data in OS memory causes serious security problems — the ones you specified — when the device is “rooted”. There are two ways to mitigate these security risks:

A) Provide a more secure location for sensitive data

This "safer place" may be a trusted runtime (TEE). A special part of the processor that launches its own OS and therefore is not compromised when the main OS is implemented. In the field of security, TEE provides more security than the OS and "SE in the cloud", but less than SE. If TEE is not enough (this applies to services such as open-loop payments, authentication services - identification cards, passports), no one forbids you to use SE on the phone that provides the HCE service. In this case, the default routing to the CPU (OS HCE service for Android) can be prevented using routing tables (data destined for the application with a specific AID is sent in the SE direction).

B) Implement a security mechanism to make your existing location more secure.

If you don’t have TEE and you can’t use SE, you can make things safer by using methods such as: checking the user (something “that user knows” as a PIN, or even better if possible, “this” - biometrics ", transaction restrictions (transactions with a low value, a limited number of transactions per time interval, etc.), tokenization when the Android OS checks the previous transaction (i.e. does the user have root privileges), etc.

It is best to combine A and B.

What you need to understand is that HCE is not intended for high security services. See HCE as a simpler but less secure solution designed to accelerate the implementation of NFC services . This has a great added value for SPs that can accept a reduced level of security in exchange for improving other factors such as time to market, development costs, and the need for collaboration with other parties.

You can read more about this in a document written by Tom Janssen and Mark Zandstra, people from UL-TS (formerly Collis), entitled "HCE Security Consequences." You can download it here: http://www.ul-ts.com/downloads/whitepapers/finish/6-whitepapers/289-hce-security-implications .

Answer 2

I just want to know how android fixes this problem?

The simple answer is no. Google Wallet stores data related to the card (card number, validity information, dynamic card confirmation code, etc.) in the memory of mobile phones (RAM, partially flash?). Please note that there is no balance information on the credit card. Google Wallet (actually MasterCard) does not store CVC2 or the card’s PIN.

Where is confidential application information stored? Does Google Wallet use this technology?

It should ... well ... It saves (temporary) card data in RAM and, possibly, on the phone’s flash memory (internal). No protected memory is involved here.

If so, how is sensitive information kept secure?

This is the hard part. This means that SE is cloudy. Cloud SE means that the confidential card data is stored “in the cloud” and not (or only temporarily) on the end user’s device. In practice, this can be implemented in two ways:

• The SE cloud acts like a regular smartcard / secure element. In this case, the HCE application on the end-user device will immediately redirect all received smart card commands (APDUs) to the cloud. Cloud SE will process the command and generate a response. The application then sends this response back to the payment terminal via the NFC interface (HCE). The main disadvantage of this scenario is that the HCE connection requires a stable (and relatively fast) connection to the "cloud" during the connection.

• [This is similar to how Google Wallet works.] Cloud SE acts as a token service that generates temporary card data (temporary card number and temporary dynamic verification codes), which is valid only for a limited number of transactions and for a very limited period of time. Whenever this temporary information expires, the HCE application requests a new set of temporary card data and stores it in the phone’s memory. When the payment terminal establishes a connection with the HCE application (emulated credit card), the application communicates with the payment card protocol (EMV) and inserts temporary information into the data of the emulated card.

Answer 3

I don’t think that Android “fixes this problem” or that it even intends: it is more a task for application developers. Possible approaches:

• Store confidential information outside the phone: "SE in the cloud". The obvious drawback is that for a successful transaction, the phone must be online.
• Generate confidential information by processing some secret data (for example, the user enters a password or PIN) and checks it outside the phone, for example, using a contactless infrastructure.

Answer 4

Android OS does not provide secure storage for the storage of sensitive data that is used in an HCE transaction.

In the case of HCE (Cloud Based SE), the mobile application does not store sensitive data as a Secure Element.

Sensitive PAN data, Symmetric primary key of the card , etc., which are used to create a payment cryptogram protected by the following methods: -

PAN Protection

The Tokenization EMV specification is used to replace a PAN using a Tokenized PAN, where the Tokenized PAN is limited to a specific domain.

Symmetric Key Protection

The symmetric primary key of the card is replaced by a limited symmetric key.

The VISA HCE specification defines a Limited Use Key (LUK), which is limited to a limited time period and transactions.

The MasterCard HCE specification defines a Single Use Key (SUK) to restrict use for a single transaction.

Other HCE specifications follow a similar mechanism.

Thus, cloud data (PAN, Symmetric Key) is stored, and the Mobile application stores a limited version of sensitive data. Thus, this minimizes the risks.

The mobile application uses White Box Cryptography to prevent data theft, as suggested by VISA, MasterCard, and others. The white box of cryptography is hard to break.

By the way, it is called Cloud Based SE , because sensitive data is stored in the cloud instead of the Mobile Application, which differs in the way with a secure element (in SE / Mobile SE sensitive data is stored in SE).

Answer 5

Use tokens in conjunction with "SE in the cloud" ... this can avoid the dependency "The phone must be online."