Host Card Emulation (HCE) is a technique pioneered by SimplyTapp and integrated by Google into Android as of 4.4 KitKat that allows an Android app running in a mobile device equipped with an NFC controller to emulate the functionality of a contactless smart card. Prior to KitKat the NFC controller routed the NFC interface to a secure element, either a secure element integrated in a carrier-controlled SIM, or a different secure element embedded in the phone itself. This allowed carriers to block the use of Google Wallet, which competes with the carrier-developed NFC payment technology that used to be called ISIS and is now called SoftCard. (I’m not sure if or how they blocked Google Wallet in devices with an embedded secure element.) Using HCE, Google Wallet can run on the host CPU where it cannot be blocked by carriers. (HCE also paves the way to the development of a variety of NFC applications, for payments or other purposes, as Android apps that do not have to be provisioned to a secure element.)
But the advantages of HCE are offset by a serious disadvantage. An HCE application cannot count on a secure element to protect payment credentials if the device is stolen, which is a major concern because more then three million phones where stolen last year in the US alone. If the payment credentials are stored in ordinary persistent storage supplied by Android, a thief who steals the device can obtain the credentials by rooting the device or, with more effort, by opening the device and probing the flash memory.
Last February Visa and MasterCard declared their support for HCE. In a Visa press release and a MasterCard press release, both payment networks referred to cloud-based applications or processing, thereby suggesting that an HCE application could store the payment credentials in the cloud. But that would require authenticating to the cloud in order to retrieve the credentials or make use of them remotely; and none of the usual authentication methods is well suited to that purpose. Authenticating with a passcode requires a high entropy passcode, and asking the user to enter such a passcode would negate any convenience gained by using a mobile device for payments. Authenticating with a credential stored in the device requires protecting the credential, which brings us back to square one. Authenticating with a credential supplied to the device, e.g. via SMS, obviously doesn’t provide security when the device has been stolen. Authenticating with a credential supplied to a different device would again negate any convenience gain.
An alternative to storing the payment credentials in the cloud would be to store them in encrypted storage within the device. But secure encryption requires a secure element to store a secret that can be used in the derivation of the encryption key. Without such a secret, the encryption key would have to be derived exclusively from a passcode entered by the user. That passcode would need to have very high entropy in order to resist an offline guessing attack with a password-cracking botnet; and asking the user to enter such a password would again negate any convenience gain. If a secure element is available to Android for storing the secret, there is no reason not to use it as well for hosting the payment application itself.
But there is a solution to this puzzle. The solution is to use what we call virtual tamper resistance to protect the payment credentials (or the HCE application, or the entire Android file system). Here is how that works. The credentials are stored in ordinary persistent storage within the device, but they are encrypted with a data protection key that is entrusted to a key storage service in the cloud. To retrieve that key, the device authenticates to the service with a cryptographic device-authentication credential. But that credential is not stored in the device. Instead, it is regenerated on demand from a PIN supplied by the user and what we call a protocredential. The protocredential is such that all PINs yield well-formed credentials. Hence a thief who steals the device has no information that could be used to test guesses of the PIN in an offline attack. A PIN can only be tested online by generating a credentials and attempting to authenticate with it to the key storage service, which limits the number of attempts. Methods of regenerating the device authentication credential from a protocredential and a PIN can be found in Section 2.6 of a technical report. Methods for using a biometric sample instead of, or in addition to, a PIN can be found in Section 3 of the same report. A method for implicitly authenticating the device to the key storage service while retrieving the data protection key can be found in a recent blog post.
I have to point out that neither a secure element nor virtual tamper resistance provide full protection against malware that is able to root Android while the unsuspecting user is using the device, because such malware may be able to intercept or phish the PIN or biometric sample that is used to enable the use of the credentials if a secure element is used, or to regenerate the device authentication credential and retrieve the data protection key if virtual tamper resistance is used. Protection against such malware can be achieved by running the payment application in a Trusted Execution Environment (TEE) that features a trusted path between the user interface and the payment application. The trusted path can protect the PIN or biometric sample from being intercepted or phished by malware. Furthermore, even if malware has somehow obtained the PIN or a genuine biometric sample, the payment application can insist on the PIN or sample being submitted by the user via the trusted path, rather than by code running in the possibly infected Rich Execution Environment (REE) where ordinary apps run. On the other hand a TEE by itself does not provide full protection against physical capture of the device, because it does not usually provide physical tamper resistance. Virtual tamper resistance can be used to remedy that shortcoming.