Virtual Tamper Resistance Is the Answer to the HCE Conundrum
Virtual Tamper Resistance is the Answer to the HCE Conundrum – Pomcor

	
		

	

	
	
	
		
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.

	

	




	
		Post navigation
		
	
	

	

