Industry Interviews
 
 
 
 
 
 

    Media & Resource Center  > Industry Interviews 

> Back to Industry Interviews



Francisco Corella, CTO at Pomcor, explains the concept of ‘derived credentials’ and how the Trusted Execution Environment (TEE) can be used to implement them.

  1. Could you please define ‘derived credentials’?

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 initially coined by the National Institute of Standards and Technology (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. Some examples include:

  • 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.

 

  1. What are the main security considerations for 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. In 2013 for example, more than three million smart phones were stolen in the US alone (http://www.consumerreports.org/cro/news/2014/04/smart-phone- thefts-rose-to-3-1-million-last-year/index.htm). If no precautions are taken, an adversary who captures the device may be able to physically extract 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.

 

  1. How can the TEE support the implementation of derived credentials?

The TEE, is ideally suited to protect derived credentials against the threat of malware. Credentials stored in the TEE are protected by the secure operating system (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 (TUI). A credential-enabling PIN can be entered through the TUI, 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.

It is also possible, however, 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.