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.

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 wrong with my phone?

At one level, nothing. It is a superb device that can do hundreds of tasks that once upon a time you needed multiple devices to achieve… but therein lies a problem.

With that ability to do many tasks comes masses of software. The more software, the larger the number of places where there may be a security issue (a larger “attack surface”) and the higher the likelihood that vulnerabilities will be found. To work around that issue, the Trusted Execution Environment (TEE) was developed by a consortium of concerned parties; from network operators, through manufacturers, to OS vendors.

What is a Trusted Execution Environment (TEE)?

A TEE is an environment for executing code, in which those executing the code can have high levels of trust in the asset management of that surrounding environment because it can ignore threats from the “unknown” rest of the devicei. Hence TEE stands for Trusted Execution Environment and to distinguish them from the uncertain nature of applications in the REE (REE? Wait a second…), applications in the TEE are known as Trusted Applications (TAs). Generally, the rest of the device hosts a feature Rich OS like Android™, and so is generically known in this context as the REE (Rich Operating System Execution Environment).

What is a Trusted Execution Environment (TEE)?

Trust in a Trusted Execution Environment (TEE)

There are many interpretations of what is meant by Trust. In the TEE it is used to imply that you may have a higher level of trust in validity, isolation and access control in items (assets) stored in this space, when compared to more general purpose software environments. This then ripples down to an assertion that the Trusted OS and Trusted Applications executing inside that space are more trustworthy.

Why is a Trusted Execution Environment more Trustworthy?

Secure start-up

In the TEE, that Trust requires that all TEE related assets, code, the underlying Trusted OS and its support code, have been installed and started through a methodology that requires its initial state to be as expected by the designers (i.e. EVERYTHING is signature checked, immutable, or held in isolation).

Why is a Trusted Execution Environment more Trustworthy? - Only authorized code inside a TEE

TEEs only accept code for execution that has been:

  • Appropriately authorized
  • And where that authorization has been checked by other authorized code
  • And that includes everything from after ROMii boot
  • (you can consider the ROM code authorized by its presence).

TA’s can only directly access their own data (including key) assets:

  • There is no method for a TA to directly access assets of other TAs or other components of the TEE.

In an ideal world:

  • A sample TEE is tested by some lab that you could trust (maybe because the lab was itself certified by other labs and the government)
  • The TEE is able to attest to its current trustworthy state in some manner
  • And you trust the device manufacturer to have reproduced the test sample TEE in production devices so that the attestation is valid.

In the real world, few users want to pay sufficiently for that ideal, so we get:

  • The TEE attests through the services it offers that it is in a trustworthy state.
    • If the TEE boot or service signature checks fail, the TEE must not offer that service or dependent services.

And you trust the device manufacturer to have built the TEE correctly, so that such TEE or Service attestation is valid.

Note this is quite different from the original Trusted Computing model, where any code could execute, but that code was potentially verifiable after booting by remote entities. That model doesn’t work so well in devices where some trust is wanted by the local user, without reference to an external entity.

Runtime Isolation

Signature checking during installation, booting, and loading of material is great but
… what happened 1 second later?

Runtime Isolation - TEE provides isolation to protect code after validation

To maintain the Trust we must stop interference with the executing code and its assets at run-time. To do this the hardware TEE is isolated from the rest of the device, and TEE provides isolation between the Trusted Applications and other assets inside the TEE.

  • A given Trusted Application (TA) in the TEE only has to trust the Trusted OS and doesn’t have to care what other TAs are present in the TEE.
  • And it also means a TA’s assets are isolated from all other environments in the device.
    • The user of the TEE based software knows they can have confidence that their assets cannot be exposed, modified or deleted without authorization (within the isolation profile of the particular TEEiii).

Isolation example: A TA has no method to open a file owned by another TA:

  • If TA1 creates a file called “Secrets”, TA2 can also create a file called “Secrets”, but the Trusted OS treats them as two different files. TA2 can do what it likes with its file and it can make no changes to TA1s file.
  • And nothing in the REE can access the contents of either TAs file.

It is worth noting that an attacker cannot even manually copy a TA’s assets between devices to try and defeat TEE security, TEE storage is all bound to the device.

Some Trusted Execution Environments are better than others

Trustonic’s Kinibi OS for the TEE is a Microkernel design. This provides more isolation and so reduces the risk if something goes wrong in part of the Trusted OS.

Trustonic Kinibi Microkernel Design

In addition,

  • The cryptographic parts of Kinibi are resistant to execution unit utilization, branch predictor, dismiss timing and cache-based side channel attacks.
  • Kinibi also makes use of ASLR and stack protection to reduce the risk of unauthorized execution through buffer overruns and similar attacks.
  • And (predictably) yes… Kinibi’s code is vetted for Spectre and uses methodologies to guard against Meltdown

Remote Management

Some TEEs are designed to restrict themselves to a limited use case, meeting the needs of a specific manufacturer. However, because of the quality of the internal isolation, TEEs that we care about here are designed to enable a devices best security to be leveraged by developers beyond the initial production-line installers. To securely install code and assets after production requires a trustworthy remote management infrastructure, where operations are controlled through secure channels or cryptographically secured tokens. Key management provides isolation of assets, and asset control, to all but the direct owners.

Trustworthy Remote Management Infrastructure

Following the TEE isolation philosophy, TEE remote management is designed such that specific remote managers can be given control of a subset of applications but have no ability to interfere with the rest of those in the TEE. For example, an OEM may manage its TAs, and a bank may be able to manage its TAs, but neither could interfere with the other’s TAs.

What else makes an execution environment become “a TEE”?

Not all devices host a Trusted Execution Environment that is open to non-OEM applications, and not all devices host the same TEE. Not all code running in Arm® TrustZone® technology isolated environment conforms to the above ideals of a TEE, though it is a great place to build a TEE.

If you are interested in using more than one model of a device, then compliance with standards will widen the potential list of targets that will safely run your software. GlobalPlatform (well known for its work in the Secure Element standards behind UICCs, bank cards and e-passports) also defines standards for TEE isolation, manageability, and functionality. Specifically, they describe the overall architecture expected of a TEE and have a consistency compliance requirement (with associated testing lab-based testing) defined in documents such as:

Along with defining an internationally recognized Common Criteria Protection Profile to certify the security properties of the TEE against:

If you wish to remotely manage a TEE and its Trusted Applications, then there is also a standard to help you with that:

Standards allowing use of many manufacturers devices

It could be argued that if the TEE doesn’t meet these standards then it is not a TEE, but it would be more correct to say it is not a GlobalPlatform certifiable TEE, and so you are placing your Trust in a particular Manufacturers’ ideas, rather than the combination of:

  • A manufacturer,
  • Their compliance to standards defined by a consortium of security experts,
  • And (optionally as noted) the ability of test houses to certify against that standard.

Luckily most manufacturers in the Android space (i.e. all the top 10 by volume in 2018) support GlobalPlatform functionality in their TEEs, allowing security critical components of service provider software to be rolled out across that generic smartphone space.

Where is a TEE?

So, the above generally describes the usage model that is as found in Smartphones and Tablets.

TEEs appear in Smartwatches, Set-top boxes, and (prepare yourself for a huge shock) even constrained Internet of Things (IoT) devices.

In simple IoT devices, the REE and the TEE may not have a full OS but rather suites of software libraries. While such simple devices do not generally have end-user installed software, they go through a chain of manufacturing where each entity may not entirely trust the next entity. A well-managed TEE can enable those entities to work together even without that trust.

Conclusion

Trusted Execution Environment (TEE) technology enables modern devices to provide a massive range of functionality, while at the same time meeting the requirements of software developers and service providers who care about privacy, attestation, authentication, validation, manageability and all the other aspects of security.

References

http://globalplatform.org/specs-library/tee-management-framework-v1/
http://globalplatform.org/specs-library/tee-client-api-specification/
http://globalplatform.org/specs-library/tee-protection-profile-v1-2-1/
http://globalplatform.org/specs-library/globalplatform-technology-tee-trusted-user-interface-low-level-api-v1-0-1/
http://globalplatform.org/specs-library/tee-internal-core-api-specification-v1-2/
http://globalplatform.org/specs-library/tee-system-architecture-v1-2/

Footnotes

iExcept for those threats that the application exposes itself too! If you write your Trusted Application software badly the TEE cannot stop you (though it will stop you exposing someone else’s secrets)
iiROM – when we say ROM we mean ROM (Read Only Memory) and not any form of reprogrammable storage such as FLASH. ROM code is set during the design of the SOC and cannot be modified later. For this reason, it is very simple but for the TEE it has to be able to perform signature checking in some manner.
iiiSorry but these weasel words are required in security. A well-designed TEE can be VERY hard to break into, just look at the trouble one caused the FBI: https://9to5mac.com/2016/04/07/fbi-iphone-hack-method-secure-enclave/.

 

Learn More
Discover our Application Protection, Device Security and IoT Security solutions and learn about the benefits of using Trustonic’s Cybersecurity Solutions.

Related content

Back to top