Trusted execution environments

• What is a trusted execution environment and what does it do?
• How do TEEs assist with data protection compliance?
• What are the risks associated with using TEEs?

What is a trusted execution environment and what does it do?

A trusted execution environment (TEE) is a secure area inside a computing device’s central processing unit (CPU). It runs code and accesses information in a way that is isolated from the rest of the system.

As defined by the Confidential Computing Consortium, a TEE is an environment that provides a level of assurance that unauthorised entities cannot:

• view information while it is in use within the TEE ("data confidentiality;
• add, remove or alter information while it is in use in the TEE ("data integrity"); and
• add, remove, or alter code executing in the TEE ("code integrity").

TEEs are made up of software and hardware components. TEEs are isolated from the rest of the system. This means that the operating system or hypervisor (a process that separates a computer’s operating system and applications from the underlying physical hardware) cannot read the code in the TEE.

TEEs provide security services including:

• integrity of execution;
• secure communication with the applications running in the main operating system;
• trusted storage;
• key management; and
• cryptographic algorithms.

Applications running in the TEE can access information outside the TEE, but applications outside the TEE cannot access information in the TEE.

Using a TEE gives you a higher level of trust in validity, isolation and access control in the information and code stored in this space, when compared to the main operating system. Therefore, this makes the applications running inside that space more trustworthy.

TEEs do not suffer from a loss of utility or additional overhead due to encryption. This is because the actual computation is performed on unencrypted information, and you do not need to add any noise to it.

You could use TEEs for many applications, including:

• supporting biometric authentication methods (facial recognition, fingerprint sensor and voice authorisation). A TEE is used to run the matching engine and the associated processing required to authenticate the user. The TEE protects the biometric data, essentially forming a buffer against any non-secure apps located in mobile OSes;
• providing the ability for relying parties (eg clients) to attest attributes of a TEE remotely and cryptographically (including initial code deployed in the TEE) before sharing secrets, such as encryption keys with the TEE. This ensures that TEE providers are meeting desired security and privacy properties;
• in a cloud context, to ensure that the computation is securely outsourced. This means that the provider cannot learn anything about this information, while being able to prove that certain processing occurred and that the systems were not compromised;
• enabling secure multi-party computation on untrusted platforms;
• privacy in large scale data analytics and in enabling more privacy-aware machine learning ‘as a service’; and
• Internet of Things (IoT) devices.

How do TEEs assist with data protection compliance?

TEEs ensure processing is limited to a specific part of a CPU with no access available to external code which provides input privacy. This ensures that the information is protected from disclosure and provides a level of assurance of data integrity, data confidentiality, and code integrity. Therefore, this can help you to comply with both the security principle and the requirements of data protection by design, depending on your context.

In addition, TEEs can assist with your data governance. For example, they can provide evidence of the steps you take to mitigate risks and enable you to demonstrate that these were appropriate. This can help you to comply with the accountability principle.

TEEs also have wider benefits. For example, they can provide strong manufacturing and supply chain security. This is because TEE implementations embed devices with unique identities via roots of trust (ie a source that can always be trusted within a cryptographic system). These enable key stakeholders in the supply chain to identify whether the device they are interacting with is authentic.

What are the risks associated with using TEEs?

Scalability can be an issue for large-scale processing due to a lack of available memory. However, this is becoming less of an issue with the latest TEE implementations. The combined use of TEEs with other PETs (eg machine learning using SMPC), is still an open research topic.

Processing in shared environments may pose higher risks. You should be aware of published security flaws on TEEs. Vulnerabilities are often unique to specific TEE types, so you should conduct your own research of threats and mitigations in each case. Possible attacks include, but are not limited to:

• ‘Side-channel’ attacks – an attack based on extra information that can be gathered from way the TEE communicates with other parts of a computer. The most common in the context of TEEs are timing attacks. Attackers can learn information about processes sharing the same CPU, such as memory access patterns of the program that are revealed whenever data is transferred from the TEE to the main memory; and
• timing attacks can leak cryptographic keys or infer information about the underlying operation of the TEE. These attacks measure the access times to a series of specific locations in the computer’s memory and use this to infer whether or not a user has accessed information in related memory locations.

TEE implementation can introduce several risks, for example:

• Hardware TEEs only provide certain security properties. You must not assume that TEEs provide a complete security solution for the processing;
• other risks arise from poor architectural, design and implementation choices. For example, isolated Virtual Machines (VMs) can increase the size of the attack surface; and
• code within the TEE can also pose a risk, both in terms of the programs and their configuration. Insecure or buggy code cannot mitigate security risks.

In order to mitigate these risks, you must:

• ensure that you put in place the security properties that are available and configure them appropriately to mitigate potential security risks;
• use well-reviewed and analysed code implementations, such as low-level firmware and secure operating systems; and
• avoid writing your own software stacks for TEEs (but if you have to write your own code, make sure that the programs are written carefully and audited to ensure nothing observable about their execution could leak information, eg memory access patterns to personal information).

TEEs protect inputs and data during the computation but do not provide output privacy unless the code running within the TEE includes specific computations that provide that feature.

TEEs rely on the public key infrastructure (PKI) of the manufacturer for verification (eg making attestations that code is running on genuine compatible hardware before input is decrypted). This means that the manufacturer's cryptographic PKI must also be trusted (in addition to their implementation of TEE hardware).