Smart Cards, TEEs and Derived Credentials


This post has also been published on the
blog of the GlobalPlatform TEE Conference.

Smart cards and mobile devices can both be used to carry cryptographic
credentials. Smart cards are time-tested vehicles, which provide the
benefits of low cost and widely deployed infrastructures. Mobile
devices, on the other hand, are emerging vehicles that promise new
benefits such as built-in network connections, a built-in user
interface, and the rich functionality provided by mobile apps.

Derived Credentials

It is tempting to predict that mobile devices will replace smart
cards, but this will not happen in the foreseeable future. Mobile
devices are best used to carry credentials that are derived
from primary credentials stored in a smart card. Each user may choose
to carry derived credentials on zero, one or multiple devices in
addition to the primary credentials in a smart card, and may obtain
derived credentials for new devices as needed. The derived
credentials in each mobile device are functionally equivalent to the
primary credentials, and are installed into the device by a device
registration process that does not need to duplicate the user proofing
performed for the issuance of the primary credentials.

The term derived credentials was coined by NIST in connection
with credentials carried by US federal employees in Personal Identity
Verification (PIV) cards and US military personnel in Common Access
Cards (CAC); but the concept is broadly applicable. Derived
credentials can be used for a variety of purposes, and can be
implemented by a variety of cryptographic means. A credential for
signing email could consist of a private key and a certificate that
binds the corresponding public key to the user’s email address, the
private-public key pair pertaining to a digital signature
cryptosystem. A credential to provide email confidentiality could
consist of a certified public key used by senders to encrypt messages
and the corresponding private key used to decrypt them. A credential
for user authentication could consist of a certified or uncertified key
pair pertaining to any of a variety of cryptosystems.

An important class of derived credentials are payment credentials.
Credentials carried in Google Wallet, in apps that take advantage of
Host Card Emulation, or in Apple Pay devices, are examples of derived
credentials.

Using a TEE to Protect Derived Credentials

Derived credentials carried in a mobile device must be protected
against two threats: the threat of malware running on the device, and
the threat of physical capture of the device.

If no precautions are taken, malware running on a mobile device may be
able to exfiltrate derived credentials for use on a different device,
or make malicious use of the credentials on the device itself.
Malware may also be able to capture a PIN and/or a biometric sample
used to authenticate the user to the device and enable credential use,
and use them to surreptitiously enable the credentials and make use of
them at a later time.

Mobile devices are frequently lost or stolen. More than three million
smart phones were stolen in the US alone in 2013. If no precautions
are taken, an adversary who captures the device may be able to
physically exfiltrate the credentials for use in a different device,
even if the credentials are not enabled for use in the device itself
when the device is captured. The exfiltrated credentials should be
revocable, but there may be a time lag before they are revoked, and a
further time lag before revocation is recognized by relying parties.
Moreover, some relying parties may not check for revocation, and some
credential uses are not affected by revocation. For example,
revocation of a key pair used for email encryption and decryption
cannot prevent the private key from being used to decrypt messages
sent before revocation, which may have been collected over time by the
adversary.

A TEE is ideally suited to protect derived credentials against the
threat of malware. Credentials stored in the TEE are protected by the
Secure OS and cannot be read by malware running in the Rich Execution
Environment (REE), even if such malware has taken control of the Rich
OS. REE-originated requests to make use of the credentials can be
subjected to user approval through a Trusted User Interface. A
credential-enabling PIN can be entered through the Trusted User
Interface, and a biometric sample can be entered through a sensor
controlled by the TEE through a Trusted Path.

A TEE can also provide protection against physical capture by storing
credentials in a Secure Element (SE) as specified in the TEE Secure
Element API Specification. However, it is also possible to provide
protection against physical capture without recourse to a SE, using
Virtual Tamper Resistance (VTR) mediated by the credential-enabling
PIN and/or biometric sample.

Virtual Tamper Resistance

PIN-mediated VTR protects credentials by encrypting them under a
symmetric credential-encryption key (CEK). It would be tempting to
derive the CEK from the PIN, but that does not work because an
adversary who captured the device and extracted the encrypted
credentials could mount an offline brute-force attack against the PIN
that would easily crack it. Instead, the CEK is stored in the cloud,
where it is entrusted to a key storage service. The CEK, however,
must be retrieved securely. That requires authentication of the
mobile device to the key storage service, using a device
authentication credential (DAC) which must itself be protected. This
is again a credential-protection problem, but a simpler one, because
the DAC is a single-purpose authentication credential. Protection of
the DAC is achieved by not storing it anywhere. Instead, it is
regenerated before each use from a protocredential stored in the
mobile device and the PIN. An adversary who captures the device
cannot mount an offline attack against the PIN because all PINs
produce well-formed credentials. Each PIN guess can only be tested by
attempting to authenticate against the key storage service, which
limits the number of guesses.

Virtual tamper resistance mediated by a biometric sample works
similarly, using a biometric key instead of a PIN. The biometric key
is consistenly derived from a genuine-but-variable biometric sample
and helper data using a known method based on error correction
technology. The helper data is stored in the mobile device as part of
the protocredential, but it does not reveal biometric information to
an adversary who captures the mobile device because it is computed by
performing a bitwise exclusive-or operation on a biometric feature
vector and a random error-correction codeword, the exclusive-or
operation being deemed to effectively hide the biometric information
in the feature vector from the adversary.

Using virtual tamper resistance instead of physical tamper resistance
realizes the cost-saving benefits of a TEE by protecting the derived
credentials without requiring a separate tamper-resistant chip. If
desired, however, security can be maximized by combining virtual and
physical tamper resistance, which have overlapping but distinct
security postures. To defeat virtual tamper resistance, the adversary
must capture the device, and also breach the security of the key
storage service. To defeat physical tamper resistance, the adversary
must reverse-engineer and circumvent physical countermeasures such as
meshes and sensors that trigger zeroization circuitry, using equipment
such as a Focused Ion Beam workstation. To defeat their combination
the adversary must achieve three independent security breaches by
capturing the device, defeating the physical countermeasures, and
breaking into the online key storage service.

Beyond Derived Credentials

Virtual tamper resistance and protocredentials are versatile tools
that can be used for many security purposes besides protecting derived
credentials.

Virtual tamper resistance can be used to implement a cryptographic
module within a TEE, protecting the keys and data kept in the module.
It can also be used for general-purpose data protection within the
REE, by encrypting the data under one or more keys stored in a
VTR-protected cryptographic module within the TEE.

A credential regenerated within a TEE from a protocredential in
conjunction with a PIN and/or a biometric sample can be used to
authenticate a mobile device in the context of Mobile Device
Management (MDM) or, more broadly, Enterprise Mobility Management
(EMM).

A protocredential can be used in conjunction with a hardware key
produced by a Physical Unclonable Function (PUF) to regenerate a
device credential that an autonomous device can use for authentication
in a cyberphysical system.

Comments

2 responses to “Smart Cards, TEEs and Derived Credentials”

  1. Rainer Avatar
    Rainer

    Maybe the best place for the CEK will be a private cloud service ( kind of owncloud).

    1. Francisco Corella Avatar
      Francisco Corella

      Yes, indeed, it would make a lot of sense for a private cloud service such as ownCloud to provide the key storage service that would store the CEK. Other options include the MNO, the phone manufacturer, the mobile OS provider, the MDM provider in an enterprise setting, or a government agency in the case of government employee credentials. But a private cloud service is an attractive option from the point of view of user privacy in many cases.