Go to content Phone human-readable description of the message we trying to accomplish. Search human-readable description of the message we trying to accomplish. Map pin human-readable description of the message we trying to accomplish.

New clarifications and detail in the document describing the Trusted Execution Environment (TEE). Secure Boot, and Remote Management, Root Of Trust along with TEE Biometrics architectures.

Back in the dawn of time (well 2004), a group of people (including myself) got together at the behest of mobile network operators (MNO) in an organisation called Open Mobile Terminal Platform (OMTP) and defined the basic characteristics of a TEE (then called an ATE). Those original documents are now hosted by the GSMA

Having defined the basic capabilities from the MNO point of view, a wider section of industry became interested in the security provided by the TEE functionality, and since 2010, GlobalPlatform has been the core location for driving the development of standardised functionality, and security validation for the TEE (and, very importantly, driving independent TESTS to prove real devices pass these standards!)

Over the years, new enabling API’s have been added to the TEE (such as a real Trusted User Interface, isolated from access by other parts of a device) as more advanced capability has appeared in hardware.

To introduce all this work and place it in context, GlobalPlatform has a TEE System Architecture document. The latest version of which has been released in December 2018.

While this provides a good introduction to traditional TEE design, those of you only moderately familiar with proper TEE’s may find a few surprises in the basic document, such as support for TEE’s based on hardware backed isolation models beyond ARM TrustZone Technology.

What is new in 1.2?

Root of Trust

In the past, GlobalPlatform TEE’s have been used to implement Trusted Computing Group (TCG) Trusted Platform Module (TPM) functionality. The TPM is a well-known component of Rich Operating Systems Root of Trust (RoT) and GlobalPlatform have wanted to clarify how RoT works in TEE.

Unlike a traditional PC, running a single operating system (e.g. Microsoft Windows), a mobile device tends to have many independent platforms, each with a potential Root of Trust. Think about a cellphone, which typically contains a BaseBand OS, a Rich OS (e.g. Android) … as well as other sub-platforms such as TEE and Secure Element).

This TEE System Architecture release adds clarity on potential Roots-Of-Trust, using the GlobalPlatform definitions for the terminology.

What makes a GlobalPlatform Root OF Trust?

From the GlobalPlatform point of view, any code that cannot be attested to in some way by other code on the platform, is a Root of Trust. And that is a gross oversimplification, so read the GlobalPlatform definition document.

Secure Boot and Root of Trust

Secure Boot and Root of Trust

Perhaps surprisingly to the uninitiated, there are a number of models for how a TEE may boot alongside all the other operating systems found in a typical mobile device. This document has provided some illustrative examples in the latest versions and in this release clarifies how these different Roots of Trust may interoperate with each other.

Remote Management and Root of Trust

Remote Management and Root of Trust

The one formalised place the state of the TEE platform is exposed to the outside world is when it interacts during remote management actions such as installation and secure data provisioning. This leads to an explanation in the document of Root Of Trust models in remote management protocols like the GlobalPlatform TEE Management Framework (TMF).

Multiple TEE’s

Multiple TEE’s

If two environments exist alongside the Rich OS environment (REE) in one device, and both meet the isolation and functionality qualities of a TEE (See GlobalPlatform TEE Protection Profile, GlobalPlatform functional certification), then we have two GlobalPlatform TEE’s in the device. Impractical in the early days of TEE development, the document acknowledges this growing possibility. Intentionally neither TEE has a reason to trust the other TEE and so such trust relationships have to be built at an application level. Clearly, an area where more clarity can be added alongside future technology developments.

Biometrics

Biometrics

GlobalPlatform TEE biometrics struggle a little alongside Androids idea of biometrics because, unlike Androids interface to Biometrics, GlobalPlatform TEE acknowledges the possibility of multiple users of a device. This is a stricter trust model that then needs to be limited when helping the standard android systems outside the TEE. Anyway, the document introduces the new architecture.

And Trusted Application sizes!

Because GlobalPlatform believe in 3rd party testing to bring trustable functionality assurance, a GlobalPlatform qualified TEE must be able to at least load the test TA’s. So, this document tries (in a tool chain and architecturally agnostic manner) to define the required size a TEE must handle. A tricky challenge, and the document attempt is not a perfect solution, but at least it provides some guidance as to what might fit. Generally, this is still a question to check with the TEE vendor.

Overall

The GlobalPlatform TEE System Architecture 1.2 document is an overview. It takes high-level architecture snapshots of the various TEE components. To understand the detail, you will need to look at the individual component specifications.

Related content

What is a Trusted Execution Environment (TEE)?

A Trusted Execution Environment (TEE) is an environment for executing code, in which those executing the code can have high levels of trust in that surrounding environment, because it can ignore threats from the rest of the device.


What is TrustZone?

Arm® TrustZone® technology provides a cost-effective methodology to isolate security critical components in a system, by hardware separating a rich operating system, from a much smaller, secure operating system.


Back to top