Tech blog: How to manage Trusted Application in a TEE – updated GlobalPlatform documentation

25 September 2020

The huge value of a Trusted Execution Environment [TEE] is enabling 3rd party Trusted Applications (TA’s) to be installed and run in isolation from the generic REE OS environment (and each other). To do this, you need a secure system to transfer secrets, data and code from the providers of services, to the end user devices, and a related management rights control system.

Tech blog: How to manage Trusted Application in a TEE - updated GlobalPlatform documentation

A brief history

November 2016

After 4 years of development, GlobalPlatform released a protocol standard to enable remote entities to securely install Trusted Applications into a TEE. Trusted Management Framework (TMF) v1.0 [GPD_SPE_120].

This used an ASN.1 based protocol. The TMF had the advantages of minimising the code complexity (complexity is always an issue in any secure environment) and reusing the compact GlobalPlatform concept of Security Domains (SD) from the Secure Element community. Security Domains provide a trust chain equivalent to x509 chains or other management hierarchy solutions. This use of Security Domains first appears in the GlobalPlatform Card Specification [GPD_SPE_034], and the TMF has updated the concept with a TEE focus.

January 2017

However, this was standards work and 4 years is a long time in the making. In the meantime, a consortium (the OTPA) created a protocol based on generic server infrastructure techniques and off-the-shelf libraries. This while having some security disadvantages compared to the ASN.1 version due to its size and implementation process was easier for 3^rd party “play store” like entities to implement.

This Open Trust Protocol (OTrP) specification was donated to both GlobalPlatform and to IETF. GlobalPlatform clarified some issues with OTrP and published Version 1.0 in April 2019 as TMF: OTrP Profile [GPD_SPE_123]. The IETF have revised their variant into a project with the title: Trusted Execution Environment Provisioning (TEEP).

Naming

Originally the GlobalPlatform ASN.1 system for enabling TA management was called Trusted Management Framework (TMF), but with two GlobalPlatform TA management systems, the “TMF” term becomes the general term, and the OTrP and ASN.1 variants became “profiles” under the overall title.

The original TMF document now has two roles:

Firstly, it defines the general concepts, covering such areas as factory reset, remote audit, control hierarchy roots etc.
Secondly, it still provides the guidance for implementing those concepts using the token (off-line) mode on the ASN.1 profile. There are then two supplementary documents enabling use of symmetric and asymmetric key-based online modes for the ASN.1 profile.

TMF in the real world…

Both TMF: ASN.1 Profile and TMF: OTrP Profile are currently predominantly used on smartphone class TEE enabled devices (though there is a GlobalPlatform Configuration of the TMF: ASN.1 Profile for IoT) . GlobalPlatform TMF: OTrP profile is used mainly in China, and GlobalPlatform TMF: ASN.1 Profile is used throughout the rest of the world. Actual deployment is an OEM choice.

GlobalPlatform TMF enables OTA deployment of TA’s

Management hierarchies

Both GlobalPlatform TMF ASN.1 and TMF OTrP work through enabling management hierarchies. In traditional GlobalPlatform the nodes in these hierarchies are called Security Domains (SD’s), whereas in the TMF OTrP we represent those nodes (or at least their rights) with X509 certificates relationships.

“Security Domains” in GlobalPlatform

You will have to look in the actual specifications for the details, but fundamentally a GlobalPlatform Security Domain (SD) is a remotely addressable management node. Commands sent to this node (when validated and aligned with the “rights” of the SD) perform actions on its environment, the TEE in this case.

Each Security Domain has

Isolated storage for associated keys
The option to have directly associated TA’s, which are under it (or the SD’s parents) management control
The option to have directly associated child SD’s, which are under it (or the SD’s parents) management control

For an entity outside the TEE to perform an action they need to sign, optionally encrypt, and send a command. An actor for a Security Domain representation in the device will need to validate (and optionally decrypt) with a related cryptographic key), and that Security Domain must have registered in it a “permission” to do such an action.

The permission aspect means that not all Security Domains can perform all actions, and the underlying system makes sure that a Security Domain that cannot perform an action cannot upgrade or create one that can. There is also a hierarchical aspect, in that parent domains can perform actions on (most) of its child domains, but not visa versa.

Actions are things like:

Install/update/remove a child Security Domain,
Install/update/remove a TA to be associated with the Security Domain,
Store some Keys and/or Data accessible to the Security Domain or Trusted Application.

One thing that the TEE associated TMF Security Domains do not currently do, that the Card Security Domain does currently, is enable a secure channel for the associated applications to talk to an entity outside the TEE. If you want a secure channel in TMF, you provision channel keys (using a TMF Store Data command) directly to the Trusted Application, and that TA, then creates such a channel.

One thing that TMF Security Domains can do that isn’t seen in the GlobalPlatform Card specification is create “root Security Domains”. A Root Security Domain is a domain whose parent SD’s cannot perform general management operations on it, its TA’s, or its child SD’s.

“X509 Certificate chains” in GlobalPlatform TMF OTrP Profile

Here, the presence of a valid certificate in a chain of certificates indicates the right to perform certain actions.

Again, you will have to look in the actual specifications for the details, but fundamentally an OTrP profile TMF provides a store for a chain of certificates, which reflect the management rights of an external entity which is the owner of a certificate, to act on TA’s Code and Data, as well as child certificates.

Actions such as

Install/update/remove a child X509 certificate
Install/update/remove a TA to be associated with an installed X509 certificate
Store Keys and/or Data accessible to the Trusted Application.

For an entity outside the TEE to perform an action on a part of the environment, that entity needs to sign a command with the same cryptographic key as is stored in a previously installed X509 certificate. This builds a hierarchy of signing (and where required, encryption).

Compatibility

Having published the TMF ASN.1 Profile 1.0 in 2016, and the TMF OTrP Profile 1.0 in 2017, then there came a question as to compatibility. Overall, the functionality was generally the same, with the TMF ASN.1 Profile providing a few extra features (such as an audit ability, and support for Factory Reset of the TEE).

Access to assets

It is worth noting, that neither the TMF ASN.1 nor the TMF OTrP can extract TA keys or data from the TEE. While they can inject keys and data, that is not into the primary storage area of a TA, and so a TA can be designed to ignore such changes and use other data and keys if it wishes.

“Crypto Agile”

A term that can mean many things.

Here, we mean that the Security Domains, and the protocol communicating securely to those domains, can trivially have the cryptographic functionality switched between any of the algorithms and key sizes available in the TEE. Given a Security Domain holding a set of permissions, this does not require a new “certificate” of those permissions to be generated and installed, just a change of keys and key types for the domain already holding those permissions.

This question of compatibility leads us to….

Recent releases

If you had been following the area, you will have seen a flurry of TEE related releases over the last few months from GlobalPlatform:

Finishing with a new version of the GlobalPlatform TMF ASN.1 document in its “General Concept” role. TEE Management Framework including ASN.1 Profile v1.1. | GPD_SPE_120 Published Aug 2020

The reason for this set of new documents, was not due to any major change, but from a desire in GlobalPlatform membership to show the compatibility of the two technologies at command, as well as key/data/TA management levels.

To enable this, GlobalPlatform has created a “mapping” document ([GPD_SPE_124] above) which clarifies how an entity in the TEE may receive OTrP profile commands and convert them internally into ASN.1 profile commands. This document shows that all OTrP Profile commands have ASN.1 equivalent and that the permissions implied by the X509 certificates can be mapped into an ASN.1 system.

This potentially also enables an OTrP profile server to install such a mapping component (a mapping TA) into an ASN.1 profile enabled TEE and then that component can create equivalent management trees under control of that key hierarchy. Alternatively, the command and key conversion might also be done at the originating server end (or some other secure location) rather than in the device.

In the process of doing this work, the TEE Specification Working Group in GlobalPlatform had one minor addition to the ASN.1 protocol, to support the OTrP protocols lack of independent TA and Data Provisioning commands. This meant adding an additional ASN.1 command that would perform installation of TA and Data as a single atomic operation.

Conclusions

With the current set of specifications, it is possible to provide systems that can support either or both the ASN.1 Profile or the OTrP profile.

The result of the mapping work in GlobalPlatform, is that we can now clearly see that the features of the TMF: OTrP profile can be mapped as a compatible sub-set of the features and capabilities of the TMF: ASN.1 profile.

Whilst the ASN.1 profile is richer and can offer several features that OTRP cannot, the core functionality has been shown to be equivalent – great minds clearly think alike!

Resources

For further information on GlobalPlatform, please visit https://globalplatform.org/

Click here for further information on Trustonics’ Application Security or get in touch at: info@trustonic.com