In this article I am going to talk about the Trusted Execution Environment, or TEE. This is a relatively little understood subsystem on many different types of device which can help to protect security assets rather better than they can be protected by the main device operating system.
It is my intention to include some much more developer-focussed material in future articles with guidance on how to develop Trusted Applications to run on a TEE.
There are many different types of TEE, and quite a number of different hardware architectures that can support them. While some of what I will discuss is applicable to most systems, some is quite specific to the most commonly deployed form of TEE: the GlobalPlatform TEE running on ARM TrustZone.
In the interest of fair disclosure, I should mention that I am active in GlobalPlatform as well as being employed by a company which sells devices that support ARM TrustZone. It is perhaps unsurprising that my expertise is in this architecture.
Security Levels
It is worth starting any discussion by thinking about how the security provided by an environment can be described. The Common Criteria define a complete methodology for evaluating the security of information systems which looks at almost every aspect of the development of a product in terms of its impact on security. An in-depth introduction to the methodology is in the Common Criteria Evaluation Methodology document (CEM).
The usual approach to evaluating a product under the Common Criteria to to develop a Protection Profile – a generic document describing how a particular class of products provides security (and what is secured – which is equally important). If a particular product is to be evaluated, a Security Target is developed which shows how the product meets the requirements for the chosen Protection Profile. For a formal certification, an independent security lab will perform an evaluation of the product based on its Security Target and will write a report. If all is well, this report is submitted to a Certifying Body (which is usually a Government security agency such as ANSSI in France) which will issue a certificate.
The traditional way to “measure” security under this methodology is the EAL (Evaluation Assurance Level). Typical Secure Elements (SIM Cards, chip cards used in credit cards and the like) are evaluated at a level of EAL4+ or better (the “+” indicates that they go beyond the EAL4 requirements in some respects). For products evaluated according to the same Protection Profile, this is a useful comparison – a Secure Element evaluated according to the usual Protection Profile for such devices (the so-called PP084 developed by the German BSI) at EAL6+ should be more secure than a product evaluated at EAL4+.
However, it is not meaningful – indeed it can be extremely misleading – to compare EAL levels for products evaluated according to different Protection Profiles. As a result, many in the industry have tried to find a simpler way of describing the type of security offered by an environment. One approach which is becoming increasingly accepted is to define essentially three types of environment (there is not yet broad agreement on there exact terms to use):
- “Unrestricted” – these are environments which are designed to support a wide range of applications and have a broad functionality. While such environments usually provide security functionality, it is not the main purpose of the environment. Linux, Windows, OSX, iOS, Android and the like are typical examples.
- “Restricted” – these are environments which are designed primarily to provide security functionality and generally little else. Such environments are normally intended to protect against attacks by remote attackers. A TEE is an example of such an environment.
- “Tamper Resistant” – these are environments which are designed primarily to provide security functionality, with protection from sophisticated local attackers as well as remote attackers. Secure Elements and TPMs are examples of such environments.
When I talk about TEE, I hope it is therefore clear that I am describing an environment that is designed primarily to protect certain assets against disclosure to attackers who are using software techniques (e.g. malware) as their attack vector.
What is a TEE
At the simplest level, a TEE is a code execution environment in which:
- All code executing is trusted for authenticity and integrity.
- Other assets are protected in confidentiality.
Broken down further, this means that any executing code comes from a known source, and has not been tampered with, and that the TEE takes measures to ensure that protected information (“assets” in the security sense – usually secret or private keys, although you could protect almost any information using the mechanisms available) cannot be easily extracted from the TEE by an attacker.
In the TEE security model, the main attacker is assumed to be the REE (this is GlobalPlatform-speak for “Rich Execution Environment”) which is typically a Linux or Windows OS that is running a range of complex applications. The TEE therefore does not trust the REE, and assumes that it is potentially malicious.
This is not to say that Windows or Linux are insecure – far from it – it is simply a model in which we choose to prevent disclosure of TEE assets to the REE. It is much better to think of the security model as resembling a castle.
The image of Alnwick castle shows how castles were designed with multiple layers of defence. There might be a moat (although not here), some outer walls and a central keep which was usually built on a hill. The castle designers assumed that each layer of castle defences was breached when designing the next layer.
The TEE security model is similar: the REE provides an outer layer of security – process separation, well designed general IPC mechanisms, permissions and the like. The TEE is then isolated and provides its own additional strong defences in an environment designed to provide security at the expense of comfort. The TEE does not trust the REE simply because it assumes that an attacker has penetrated the REE, because this is the worst-case scenario.
What Mechanisms does a TEE use to protect itself
There are many potential ways to implement a TEE – the GlobalPlatform TEE System Architecture describes a number of options. Generally the architectural starting point is either a separation mechanism allowing the TEE to be isolated from the REE while running on the same CPU (architectures such as ARM Trustzone do this), or the provisioning of a separate CPU dedicated to running the TEE. There are several characteristics of the security mechanisms used by a GlobalPlatform TEE which are common:
- The TEE is protected from the REE by hardware mechanisms that the REE cannot control. This means that an attacker compromising the REE cannot reconfigure hardware so as to make the TEE more vulnerable to attack. The statement “cannot” is an extremely challenging requirement in practice, and many of the successful attack vectors on TEEs find unexpected (by the system designer) routes to change hardware behaviour.
- The TEE is booted by secure mechanisms which strongly bind the TEE to the hardware it runs on. In practice this means that the core of the TEE code is digitally signed by the device vendor or an entity trusted by the device vendor (e.g. SoC vendor, TEE vendor). This guarantee of code integrity and authenticity extends over the lifetime of the TEE including any upgrades. The stronger TEE implementations provide protection against rollback of TEE code to older versions which might have security vulnerabilities using hardware mechanisms.
- The TEE provides mechanisms for securely storing data and keys which are at least as strongly protected as the TEE environment itself. These prevent an attacker from accessing or modifying the stored assets. In most cases this storage is actually provided by the REE (e.g. on the main REE storage), but it is encrypted using keys known only to the TEE and thus an attacker can only access the encrypted and integrity protected data.
- The TEE provides mechanisms which limit the ability of debuggers and loggers to observe sensitive parts of the system. This means, for example, that if an attacker is using a debugger to trace execution of REE code, once control transfers to the TEE the debugger will be unable to observe system operation until control is transferred back to the REE.
- The interface between the REE and the TEE needs to be designed in such a way that the TEE has the opportunity to verify (and potentially reject) requests to perform operations from the REE.
There is one aspect of the TEE that sometimes surprises those unfamiliar with the security architecture and it is this: the TEE usually does not offer very much protection against denial of service attacks. It is, for example, fairly straightforward for an attacker with control of the REE to delete any files on the REE storage that are used for Trusted Storage. This sounds much worse than it is in practice – since the purpose of the TEE is to perform security-sensitive operations on behalf of the REE, it follows that if the REE is compromised, we may not care very much that the TEE operation has been impacted provided that the protected assets are not revealed.
Anatomy of an application using a TEE
The TEE allows application developers to separate the most security sensitive parts of their applications and to execute these as Trusted Applications (TAs) on the TEE while retaining the bulk of the application functionality in the REE.
The diagram above, taken from the GlobalPlatform TEE System Architecture, shows how this works in practice. An application running in the REE, which GlobalPlatform calls a Client Application (or CA – a term which is unfortunately rather overloaded in information security) communicates with its associated Trusted Application (TA) using the TEE Client API. The TA owns security assets – keys and other secrets. The TA performs operations which use these on behalf of the CA. The TEE provides a library of functions – the TEE Internal API (now renamed the TEE Internal Core API) which support many of the operations a TA might wish to perform.
To make this more concrete, let’s imagine that I am developing a mobile payment application. I want to ensure a few things in my security model.
- Only the authorised registered user of a payment account can authorise a payment. This is intended to make it difficult for an attacker who has stolen a device from the authorised user to make fraudulent payments.
- Only devices that have been enrolled in the service by the authorised user can be used to authorise payments. This is intended to ensure that an attacker who somehow obtains credentials (e.g. PIN, password) of the authorised user – e.g. using malware – cannot make fraudulent payments using a different device.
In Part 2 of this article we will take a high-level view of how the TEE can help to achieve these goals.
Credit for the image of Alnwick Castle to Gary Danvers Collection on Flickr.
Credit for images of the TEE System Architecture to GlobalPlatform (they are drawn from the TEE System Architecture document).