How Software Based Card Emulation (HCE) Guarantees NFC Security?

Question

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?

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?

Answer 1

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) Provide more secure location for sensitive data

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) Implement security mechanism to make existing location more secure

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.

The best is to combine A and B.

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.

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.

Answer 2

I just want to know how android fixes this issue?

Simple answer: it does not. Google Wallet stores the card-related data (card number, validity information, dynamic card verification code, etc) on the mobile phones memory (RAM, partly flash?). Note that there is no balance information stored on a credit card. Neither does Google Wallet (it's actually a MasterCard) store a CVC2 or a card PIN.

Where the sensitive information of apps should be stored? Does Google Wallet uses this technology?

Should ... well ... It does store the (temporary) card data in RAM and possibly on the phone's (internal) flash memory. No secure memory is typically involved here.

If yes, how the sensitive information are kept secure?

That's the tricky part. This is where the cloud-based SE comes in. Cloud SE means that the sensitive card data is stored "in the cloud" and not (or only temporarly) on the end-user's device. In practice, this could be implemented in two ways:

1. The cloud SE acts just like a normal smartcard/secure element. In this case, the HCE app on the end-user's device would immediately redirect all received smartcard commands (APDUs) to the "cloud". The cloud SE would process the command and generate a response. The app then sends this reponse back to the payment terminal through the NFC interface (HCE). The main disadvantage of this scenario is that HCE communication requires a stable (and relatively fast) connection to the "cloud" throughout the communication.

2. [This is somewhat the way Google Wallet works.] The cloud SE acts as a token service that generates temporary card data (temporary card number and temporary dynamic verification codes) that is only valid for a limited number of transactions and during a very limited timeframe. Whenever this temporary information expires, the HCE app requests a new set of temporary card data and stores it in the phone's memory. When a payment terminal establishes a connection to the HCE app (emulated credit card), the app communicates with the payment card protocol (EMV) and embedds the temporary information in the emulated card data.

Answer 3

I don't think Android "fixes this issue" or that it even intends to: it is more of a task for the application designers. Possible approaches are:

• Store sensitive information outside the phone: "SE in the cloud". An obvious drawback is that the phone needs to be online for the transaction to suceed.
• Generate the sensitive information processing some secret input (for example, the user enters a password or a PIN) and validate it outside the phone, for example by the contactless infrastructure.

Answer 4

Android OS doesn't provide secure storage to store sensitive data which are used in HCE transaction.

In case of HCE(Cloud Based SE) mobile application doesn't store sensitive data as Secure Element.

Sensitive data PAN, Symmetric Card Master Key, etc. which are used for generating payment cryptogram protected by the following ways:-

Protecting PAN

EMV's Tokenization specification is employed to replace PAN using Tokenized PAN where Tokenized PAN is restricted to certain domain.

Protecting Symmetric Key

Symmetric Card Master Key is replaced with restricted version of symmetric key.

VISA's HCE specification defines Limited Use Key(LUK) which is restricted to use for limited period of time and transactions.

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

Other HCE specifications follows similar mechanism.

So on the Cloud sensitive data(PAN, Symmetric Key) are stored and Mobile application stores limited version of the sensitive data. Thus it minimizes risks.

Mobile Application uses White Box Cryptography to stop data from being stolen as suggested by VISA, MasterCard and others. White Box Cryptography is difficult to break.

By the way it is called Cloud Based SE because sensitive data are stored on the Cloud instead of Mobile Application which differs the way with Secure Element(In SE/Mobile SE sensitive data are stored with in SE).

Answer 5

Use Tokenization in combination with "SE in the cloud" ... this can avoid the dependency of "Phone needs to be online".