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.
Maybe the best place for the CEK will be a private cloud service ( kind of owncloud).
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.