class: center, middle ### Secure Computer Architecture and Systems *** # Trusted Execution Environments ??? - Hi everyone, welcome to this brief introduction to trusted execution environments - These represent hardware assisted isolated computing environments, which enforce an particular trust model that is particularly strong --- # Introduction <div style="text-align:center"><img src="include/intro-1.svg" width=650 /></div> ??? - Imagine a server sitting in a data center and used for cloud computing - It is owned by a cloud provider - This cloud provider executes several virtual machines on top of that server - And each of these machines is rented to a different client - In the context of cloud these clients are named tenants --- # Introduction <div style="text-align:center"><img src="include/intro-2.svg" width=650 /></div> ??? - Let's try to reason a bit about the trust model of such a scenario - From the cloud provider point of view, the hardware is trusted to work properly - Same thing for the cloud provider's software handling the virtualisation: that is the virtual machine monitor, some host-level software, and so on - All of that is trusted by the cloud provider - What the cloud provider does not trust is everything ran by tenants within the virtual machines - That is tenants applications and guest operating system: the provider has no idea what the tenants will run in their VMs, and needs to assume that software may be malicious - If you take the point of view of one of the tenants, they trust their own software - Tenants also trust the cloud provider's hardware and software such as the virtual machine monitor - Tenants distrust each other: processes running on the same OS, we don't want a VM belonging to one tenant accessing the memory of a VM belonging to another tenant --- # Introduction <div style="text-align:center"><img src="include/intro-3.svg" width=650 /></div> - TEEs allow maintaining **confidentiality** and **integrity** for software executing on a (possibly remote) machine which **host software is not trusted** ??? - Trusted execution environment target the enforcement of a stronger trust model - They still consider that the cloud provider distrusts tenants and that tenants distrust each others - But there is an additional component which is: tenants do not trust the cloud provider - This makes sense today: a lot of companies are reluctant to move their workloads to the cloud because they don't want the big cloud providers to get access to their code and data - So the objective of TEEs is to create an isolated execution environment and maintain confidentiality and integrity for software executing in it, in the presence of untrusted privileged software - Here untrusted privileged software concretely means that we consider a process that does not trust the operating system it runs on top of - Or that we consider a VM that does not trust the hypervisor managing it --- # What is a TEE? - A **Trusted Execution Environment (TEE)** is: - An isolated execution context enforced by the CPU hardware - Resistant to information disclosure and tampering by the host OS or hypervisor ??? - In that context, a TEE is a hardware-enforced isolated execution context in the CPU - The isolation is strong enough so that the privileged layers, namely the OS or the hypervisor, can neither read nor write within that environment -- - Ensures: - **Confidentiality**: code and data within the TEE cannot be read by the host - **Integrity** code and data within the TEE can’t be altered by the host - Availability is out of scope (too hard to maintain) ??? - Because they protect against read and write accesses, TEEs enforce confidentiality and integrity - They cannot really enforce availability - That is too difficult in the presence of such a strong attacker that can run privileged software - For example because the attacker can run OS code in supervisor mode on the CPU, nothing prevent them from simply shutting down the machine -- - Threat model assumes attacker may control: - All host software outside the TEE, including privileged layers such as OS / Hypervisor - I/O devices ??? - Speaking about the attacker, the threat model associated with TEEs assume that the attacker controls all privileged software - As well as I/O devices --- # Key Characteristics - **Isolation mechanism** from normal execution environments - Outside world cannot read/write memory allocated to the TEE ??? - We are going to see next 3 different implementations of trusted execution environments - They all share the following key characteristics - First, as previously mentioned, they all enforce strong isolation for the software running within the TEE - The outside world, including the privileged software like the OS, cannot read and write memory allocated to the TEE -- - **Controlled interaction** with outside world - New interfaces with the outside world vs. more traditional trust models - They need to be secured ??? - This isolation implies controlled interaction between the TEEs and the outside world - Indeed the TEE is not entirely self-sufficient and needs to interact with the OS our hypervisor for things like I/O - These interactions needs to be secured as contrary to traditional trust models, the OS and hypervisor are not trusted anymore -- - **Secure storage** using encryption with keys that never leave the TEE, for sensitive data e.g. keys, passwords ??? - TEEs also provide some secure storage for sensitive data such as crypto keys or passwords -- - **Attestation** to prove trustworthiness remotely - Need to prove that the TEE runs on the right hardware - Need to provide that software inside the TEE has not been tampered with before being loaded ??? - Finally, because most TEEs are accessed by their users remotely, the users need a way to make sure the TEE invoked remotely runs on the right hardware, that is a CPU with support for trusted execution environment - And that the untrusted owner of that hardware has loaded the right software within the TEE - Making sure of that is done with what is called attestation --- # Use Cases - **Remove computation environments**, e.g. cloud computing, where the provider is not trusted - **Secure vaults**: crypto keys, passwords managers, cryptocurrency wallets, personal data e.g. fingerprints - **Confidential computations scenarios** where code and/or data must be hidden in hostile environments: - Digital Right Management - Confidential ML computations - Healthcare applications ??? - TEEs are useful in many scenarios - We mentioned cloud computing, where the cloud provider may not be trusted - They also play a key role for secure data storage applications, things like password managers or personal data storage software such as your fingerprints being stored on your smartphone - More generally, they are useful in scenarios where trusted code needs to run and process trusted data in hostile environments, where the rest of the system is almost entirely untrusted: DRM systems, confidential data processing such as ML training/inference, healthcare applications, and so on --- # Intel Software Guard Extensions (SGX) .leftcol[ <div style="text-align:center"><img src="include/sgx-1.svg" width=350 /></div> ] .rightcol[ - **Part of an application** runs within the TEE, named an **enclave** - At any time the CPU runs either within our outside the enclave - Enclaves' memory pages are **encrypted** in DRAM, cannot be accessed from outside ] ??? - One of the earliest implementations of TEEs was made by Intel, it is named Software Guard Extensions - SGX places the trusted code and data in user space within what is called an enclave - At any time the CPU runs either within our outside of the enclave - The enclave's memory pages are encrypted and cannot be accessed from outside - Memory decryption is done transparently when the CPU runs within the enclave --- # Intel Software Guard Extensions (SGX) .leftcol[ <div style="text-align:center"><img src="include/sgx-2.svg" width=350 /></div> ] .rightcol[ - **Part of an application** runs within the TEE, named an **enclave** - At any time the CPU runs either within our outside the enclave - Enclaves' memory pages are **encrypted** in DRAM, cannot be accessed from outside - Transition out/in the enclave for e.g. system calls - Slow, attack vector ] ??? - The enclave still needs to go through the untrusted OS if it wants to perform system calls - This requires transitions outside the enclave - Not only that is slow, but it is also an attack vector because the OS could be malicious and return bad data --- # Intel Software Guard Extensions (SGX) .leftcol[ <div style="text-align:center"><img src="include/sgx-3.svg" width=350 /></div> ] .rightcol[ - **Part of an application** runs within the TEE, named an **enclave** - At any time the CPU runs either within our outside the enclave - Enclaves' memory pages are **encrypted** in DRAM, cannot be accessed from outside - Transition out/in the enclave for e.g. system calls - Slow, attack vector - Try to handle as many syscalls as possible within the enclave ] ??? - So most of the frameworks that help develop enclave applications will embed within the enclave a small operating system which aims to manage as many system calls as possible within the enclave, avoiding some of the costly and dangerous enclave exits - Still, for disk and network I/Os, the untrusted host OS still needs to be invoked --- # AMD Secure Encrypted Virtualisation .leftcol[ - SEV places an entire **virtual machine** within the TEE: **confidential VM** - VM's memory is similarly encrypted to the outside world - Benefit vs. SGX: **application compatibility** - Drawbacks: large TCB (guest OS) - Interface with the outside world: virtual hardware, hard to secure ] .rightcol[ <div style="text-align:center"><img src="include/sev.svg" width=350 /></div> ] ??? - One problem with Intel SGX is that existing applications need to be modified to run as enclaves - They need to be plugged with an enclave framework that generally include the small OS I was mentioning - Everything returned by I/O system calls also needs to be sanitised because it comes from the untrusted host OS - So AMD came up with another implementation that is called Secure Encrypted Virtualisation - SEV places an entire virtual machine, called a confidential VM, within the TEE - The VM's memory is isolated and encrypted similarly to what SGX does - The advantage here is that existing applications do not need to be ported, they can run as is - The drawbacks are first a large trusted computing base, which includes the application but also the entire guest operating system - Also, for I/Os the VM still needs to go through the untrusted hypervisor, and that interface has proven very hard to secure --- # ARM TrustZone .leftcol[ - CPU execution mode dissociated between **normal world** and **secure world** (TEE) - Orthogonal to privilege levels - Hardware prevents software running in non-secure world from accessing secure world memory - In the secure world, a **small dedicated OS** executes **trusted applications** - These can be invoked from applications in the normal world ] .rightcol[ <div style="text-align:center"><img src="include/trustzone.svg" width=350 /></div> ] ??? - A third implementation, done by ARM this time, is TrustZone - With TrustZone the CPU execution mode is dissociated between the normal world, and the secure world, which is the TEE - These modes are orthogonal to privilege levels like supervisor or user, which are available in both modes - Once again the hardware prevents the normal world from accessing the memory allocated for the secure world -- although this time there is no memory encryption - In the secure world you have a small, secure OS on top of which trusted applications running user code can execute - In the normal world, regular applications can invoke trusted applications - For example if you are running android and use your fingerprint to unlock your screen, access to your bank or NHS app, - The app in question will invoke the execution of the fingerprint check trusted application within a TrustZone environment to verify your identity - This way, even if your phone gets stolen and the thief manages to root it, it is still very difficult to steal your fingerprints --- # Remote Attestation .leftcol[ <div style="text-align:center"><img src="include/attestation.svg" width=350 /></div> ] .rightcol[ - In remote scenario a client connecting to a TEE needs to check that: - Enclave runs on the expected hardware (genuine SGX CPU) - Software in the enclave has not been tampered with before being loaded - **Remote attestation**: enclave sends a measurement that attests hardware/software environment is as expected ] ??? - A last thing regarding TEEs is the concept of attestation - Most TEEs are accessed remotely, recall the cloud computing scenarios - So the user needs to make sure that the host is equipped with the proper hardware, and that it has loaded the proper TEE software too - This will generally be achieved with the exchange of some form of measurement, hashes identifying the hardware and software used - For example with SGX, the enclave will send a measurement to the client, that can check that the software loaded looks OK - Intel also offers an attestation service that will validate the hardware --- # Summary - Trusted Execution Environments: - Aim to maintain confidentiality and integrity for software executing on a machine which host software is not trusted - Various flavours: Intel SGX, AMD SEV, ARM TrustZone - Local use cases: protecting security critical code and data (e.g. DRM) when the attacker may be privileged - Remote use cases: multi-tenant environments (e.g., cloud) where the service provider is not trusted ??? - To sum up, TEEs aim to maintain confidentiality and integrity for software executing on a machine which host software is not trusted - We have discussed key TEE concepts and seen 3 different implementations: SGX, SEV, and TrustZone - We also covered TEE use cases