By Ao Sakurai

Intro

In this article, we’ll go over the background of the technology known as a Trusted Execution Environment, or TEE, take a look at the various types of TEEs, and discuss the pros and cons of TEEs.

This article will start with an explanation that self-references materials and documents [1] and [3], which are contents that I had previously created for other occasions.

The Essence of TEE

In order to explain the thinking behind TEEs, it might be smoother to start with the history and philosophy of the technology. Even still, suddenly starting from that step might still prove to be confusing, so we’ll take a look at a brief overview of TEEs first.

TEE is short for Trusted Execution Environment. Think of it like an environment that makes reliability possible. It’s a relatively new technology, having gained a lot of traction in recent years.

In a nutshell, TEE can be described as a hardware-assisted technology designed to place data that needs to be kept secret in a trusted area and to complete the processing using that data within this trusted area.

This brief explanation might leave some uncertainty about how exactly this is achieved, but the details will be explained in the latter part of this article.

It’s worth mentioning that TEEs are one type of technology known as an HIEE, or Hardware-assisted Isolated Execution Environment.

One of the key features of a TEE, especially when compared to other HIEE technologies like Intel TPM, is that users can define the operations within the execution environment. [2]

The Philosophy of TEE

TEE is one of many promising technologies available for secure computation, and among these, it has relatively stricter criteria for what can be considered trustworthy.

For example, current widely-used cloud servers are generally not considered trustworthy environments within the context of TEE.

This is because if the cloud provider itself is malicious, there is a possibility that the information handled within that cloud environment could be intercepted. Additionally, there is also the risk that the operating system provided could be compromised or malicious.

Therefore the notion that an environment is "safe" because the system is protected by firewalls or outside access management is completely out of the question.

Similarly, it doesn't matter how large or reputable the cloud provider is, even if they are a major hyper-scaler; within the context of TEE, this is irrelevant. To put it bluntly, no matter how big the provider is, the cloud server environment remains a "black box," and as long as that is the case, the idea that "it's safe because it's a big company" is an unfounded myth.

This point marks a significant philosophical difference from secret sharing technologies, where if all the servers distributing the shares (*1) are compromised or colluded, the original information can be reconstructed.

(*1: These are meaningless fragments of secret information divided through secret sharing. When all the shares are combined, the original information can be restored.)

Establishing that background might make a TEE seem like something out of a wild conspiracy theory, but to rephrase what a TEE does, its purpose is to achieve a level of security that rigorously eliminates security concerns dependent on humans—even those concerns that are commonly accepted in the broader public. TEE is designed to provide exceptionally strict security.

In essence, the philosophy of TEE is to not rely on "human goodwill” or “human reliability" at all, but instead to ensure absolute security through cryptographic and mathematical guarantees. TEE achieves this through the power of hardware-assisted technology.

TEE Mechanism

Although there are various implementations of TEEs, making it rather difficult to generalize, I will explain the mechanism using Intel SGX, which is one of the most hardware-centric examples, as a basis.

In TEE, the first step in providing a trusted execution environment is to divide the computer resources into a "trusted area" and an "untrusted area".

By handling sensitive information within the trusted area, a TEE enables the execution of programs while protecting the data.

Now, this brings us to the question of how exactly the "trusted area" and "untrusted area" are separated.

• Trusted Area: The trusted components and the protected memory area generated by those components. 

• Untrusted Area: Everything else.

Depending on the threat model and design assumed by the technology, even the OS or VMM could be considered untrusted areas, as this aligns with the aforementioned philosophy of TEE.

You might be wondering what exactly constitutes a "trusted component" and whether this concept is too abstract. To give a concrete example, in Intel SGX, the CPU serves as this trusted component (hardware).

Taking this into account, in the case of SGX:

• The CPU, which is the trusted hardware component.

• The protected memory area generated by the CPU.

• The communication channels between the CPU and the protected memory area.

These three components are the specific areas classified under TEE.

RISC-V Keystone and ARM TrustZone, which have architectures somewhat similar to SGX, differ from SGX in that they do not rely primarily on hardware-based encryption and boundary management for their protected areas. Instead, they achieve the isolation of protected areas through very strict access control enforced by software that is tightly integrated with hardware functions (encryption is not the default). Therefore, the architecture differs slightly from the one depicted above.

For example, in the case of RISC-V Keystone, while the CPU and protected memory area are considered trusted (similar to SGX), the management and access control of the protected memory area are handled by a privileged class of software called the Security Monitor. Therefore, the central component is not the CPU itself but rather the Security Monitor. [7]

By the way, the untrusted area outside of the TEE is sometimes referred to as the REE (Rich Execution Environment).

The reason why the external environment is referred to as the REE is likely because, from the perspective of the TEE, the programs running within it often face strict limitations (such as the amount of resources available or the libraries that can be used). Therefore, the term "rich" is a relative designation, emphasizing the broader and less constrained resources available outside the TEE.

Types of TEE Technology

There are already several implementations of TEE in the world, and they can be broadly categorized into two types: partial isolation and complete protection. (These terms are entirely my own coinage, so there's no need to remember them.)

The partial isolation model is the standard TEE model, as mentioned earlier, where specific sections of memory are isolated and protected.

Examples of implementations that fall under the partial isolation model include Intel SGX, ARM TrustZone, and RISC-V Keystone.

In contrast, the complete protection model is a new approach to TEE that, as the name suggests, protects the entire memory (or VM) as a whole.

Specific examples of this implementation include AMD SEV and Intel TDX.

Both partial isolation and complete protection models have their own pros and cons.

The advantages of the partial isolation model include:

• Ability to address stricter threat models 

• Higher security

The partial isolation model considers only certain areas within the CPU, specific regions of memory, privileged software in cases like KeyStone, and their communication paths as trustworthy. This allows for secure processing even in extremely hostile environments, where elements such as the machine owner, cloud vendors, BIOS, OS, and VMM are potentially compromised.

According to Intel’s claims [4], the smaller the TCB (Trusted Computing Base; a term very similar to TEE, but if TEE is used in a more conceptual way, TCB is closer to the physical area), the greater the security. From this perspective as well, the partial isolation model offers enhanced security.

The reason for this, according to Reference [5], is that from the standpoint of executable code, reducing the code within the TCB purely minimizes the potential for unnecessary (and potential) vulnerabilities.

From the perspective of data, the more data you include in the TCB, the greater the potential data leakage if an attack is successful. Additionally, in some cases, increased processing time could provide more opportunities for side-channel attacks, such as timing attacks, as I’ll discuss later.

As a result, partial isolation TEE, which inherently limits the data and code included in the TCB, further enhances security from this perspective.

The disadvantages of the partial isolation model include:

• the need to fundamentally change the code design philosophy, 

• limitations on available resources (such as memory) 

• exceptionally high difficulty of code implementation.

The partial isolation model protects specific regions of memory and treats them as trustworthy, processing within trusted and untrusted parts (and sometimes interacting with each other). As a result, it is generally not possible to proceed with a conventional design philosophy.

Furthermore, because a portion of memory is reserved as a protected area, the trusted part cannot utilize memory as freely as a standard application would.

For example, in the case of Intel SGX, when running on Windows, the effectively usable maximum size of the protected area called the Enclave is generally limited to 96MB.
Editor’s note: this article was originally published in 2022. As of press time, up to 512 GB with the current Scalable-SGX (SGX-TEM)

Additionally, based on my experience with SGX, there are several drawbacks that contribute to an abnormally high development difficulty, such as limited functionality that can operate within the protected area, subpar dedicated APIs, and the presence of uniquely formatted configuration files.

For example, Reference [6] reports that modifying 412 LOC to make it compatible with SGX resulted in the code expanding to 3,523 LOC.

In contrast, the advantages of the full protection model include: 

• the absence of limitations on resources, functionality, and design philosophy when using TEE

thus effectively eliminating all the challenges associated with the partial isolation model.

In short, it’s incredibly easy for developers.

However, in the case of the full protection model, since it protects the entire memory, including its contents, the OS and applications residing in the memory are unconditionally trusted.

This means that the operation style, which was originally a benefit of TEE—not trusting even the OS or cloud vendors—cannot be achieved. Therefore, it cannot be used in scenarios where the underlying threat model is stricter.

Pros & Cons of TEE

Having explained the basics of TEE in the previous sections, we will now introduce the advantages and disadvantages of TEE technology. 

Let’s start by listing the advantages.

Time complexity and space complexity are very low (extremely fast and minimal memory usage)

TEE achieves data protection in protected areas through access control enforced by hardware (or software closely tied to it) and encryption methods with low computational costs, such as AES. As a result, it is highly efficient in terms of execution time and memory consumption compared to other methods often considered for secret computation, such as secret sharing and homomorphic encryption.

Fully homomorphic encryption is a technology expected to be applied to secret computation and can handle threat models as stringent as or even stricter than those addressed by TEE. However, with current computational resources and algorithms, its performance is still far from practical.

Additionally, unlike secret sharing, TEE does not require multiple machines, nor does it incur the communication overhead associated with secret sharing.

Therefore, this high efficiency is a significant advantage of TEE among the leading candidates in modern technology.

Can handle a wide range of threat models (in the case of the partial isolation model)

In the case of the partial isolation model, developers (users) can decide which data and code to include in the protected area. As mentioned earlier, this allows it to operate even in environments where the machine owner, cloud vendor, BIOS, OS, and VMM are compromised.

This advantage is a clear benefit over secret sharing, which is also a strong candidate for secret computation applications, as secret sharing can have its shares restored when all machines are compromised by the same attacker.

On the other hand, the disadvantages include the following:

Necessity to trust the hardware vendor.

Now, although we have extensively explained how TEE can handle various threat models, there remains one significant disadvantage.

The issue is that, since TEE relies on hardware support to achieve isolated execution within the protected area, you must unconditionally trust the hardware vendor.

While emphasizing that cloud vendors are not to be trusted, TEE requires trusting the hardware vendor, which, depending on one's perspective or philosophy, can be seen as a significant problem.

Additionally, technologies developed by a hardware vendor will only work on that vendor’s machines, and if the vendor’s product has vulnerabilities, those can be exploited in attacks.

Vulnerable to side-channel attacks if not properly mitigated

As a general rule, TEE is powerless against side-channel attacks if no countermeasures are implemented.

Side-channel attacks do not attempt to directly decode the protected information but instead infer and steal the information by analyzing surrounding environmental data, such as execution time in the simplest case.

SGX has been a target for numerous side-channel attacks, such as controlled-channel attacks that exploit page faults and attacks like SgxPectre that exploit speculative execution.

Of course, some platforms like KeyStone have certain side-channel attack countermeasures implemented by default, and in SGX, multiple technologies, such as SGX-LAPD [8], have been developed to address such attacks. However, there are still situations where developers may need to take side-channel attacks into particular consideration.

Limitations on resources and functionality, possible changing of the application's design philosophy (in the case of the partial isolation model)

As previously mentioned, in the case of SGX for example, the size of the protected area and the functions (such as libraries and APIs) available within it are significantly limited.

Moreover, developing with constant awareness of the trusted and untrusted areas while deciding where to run or place code and data is an uncommon scenario in other contexts and can be quite taxing, especially for those who are not used to it.

It cannot be definitively said to be quantum resistant

SGX’s protected areas are encrypted by default, and similar plugins for encrypting protected areas also exist in KeyStone and TrustZone. However, since they are all based on AES encryption, it cannot be said that they are quantum resistant.

Regarding AES encryption, 256-bit is considered quantum resistant, and even 128-bit is believed to be safe for the foreseeable future [9].

Therefore, Intel SGX, which uses a 128-bit AES/CTR variant for protected area encryption, is considered safe for the time being. However, it is uncertain how long this safety can be maintained.

As outlined above, while the benefits of TEE are substantial, there are also several significant disadvantages that cannot be ignored. The adoption of a TEE must be carefully considered based on the specific environment and use case.

Summary

It ran a bit long, but this blog has covered the following points:

• TEE is a technology that creates a protected, isolated environment with hardware support, providing security by handling secrets within that environment.

• Depending on the technology used, TEE can ensure safety even in environments where the OS or cloud vendors are not trustworthy.

• Among technologies expected to be applied to secret computation, TEE is highly efficient.

• That being said, it requires unconditional trust in the hardware vendor.

• The decision to use TEE should be made carefully, considering both its advantages and disadvantages.

In a future TEE blog, I plan to discuss the challenges of applying Intel SGX, a specific TEE technology, to secret computation.

References

[1] “TEE and Intel SGX Guide”, Self-reference (Japanese), https://speakerdeck.com/hello31337/teetointel-sgxru-men

[2] “Can TEE (Trusted Execution Environment) Become the Second Virtualization Technology?” by Kuniyasu Suzaki (Japanese), http://www.ipsj.or.jp/sig/os/index.php?plugin=attach&refer=ComSys2020&openfile=ComSys2020-Suzaki.pdf

[3] “Intel SGX Guide - SGX Basics, Self-reference (Japanese), https://qiita.com/Cliffford/items/2f155f40a1c3eec288cf

[4] “Size limitation for EPC in SGX”, https://community.intel.com/t5/Intel-Software-Guard-Extensions/Size-limitation-for-EPC-in-SGX/td-p/1130830?profile.language=en

[5] “Implementation of Trusted Execution Environments and Supporting Technologies” by Kuniyasu Suzaki (Japanese), https://www.jstage.jst.go.jp/article/essfr/14/2/14107/pdf/-char/ja

[6] “SgxElide: Enabling Enclave Code Secrecy via Self-Modification” by Erick Bauman et al., https://dl.acm.org/doi/pdf/10.1145/3168833

[7] “Keystone: An Open Framework for Architecting Trusted Execution Environments" by Dayeol Lee et al., https://n.ethz.ch/~sshivaji/publications/keystone_eurosys20.pdf

[8] Fu, Yangchun & Bauman, Erick & Quinonez, Raul & Lin, Zhiqiang. (2017). Sgx-Lapd: Thwarting Controlled Side Channel Attacks via Enclave Verifiable Page Faults. 357-380. 10.1007/978-3-319-66332-6_16.

[9] ”Post-Quantum Cryptography”, NIST, as viewed on 2023/11/16, https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization/evaluation-criteria/security-(evaluation-criteria)

Note: This blog was originally published on October 14th, 2022.