Hardware-Aided Trusted Computing

An Open-Source Framework for Developing Heterogeneous Distributed Enclave Applications

D.hardware.trusted
In this talk, we present an open-source framework to develop heterogeneous, distributed enclaved applications. The main feature of our framework is to provide a high level of abstraction over the platform-specific TEE layer and over the secure communication between different modules, leaving to a developer only the task to write the application’s logic. We provide a notion of event-driven programming to develop distributed enclave applications in Rust and C for heterogeneous TEEs, including Intel SGX, ARM TrustZone and the open-source Sancus. This heterogeneity brings our work to a broad range of use cases, which include cloud processing, mobile devices and lightweight IoT. Our framework ensures strong security guarantees based upon mutual attestation of security-critical software components.
A Trusted Execution Environment (TEE) is a relatively new technology that allows to run an application in a special hardware-protected environment called enclave. Enclaves are cryptographically isolated and protected from the rest of the world, ensuring strong confidentiality and integrity guarantees. Moreover, a mechanism called Remote Attestation is used to obtain a proof that an application running on a remote server is loaded inside an enclave and was not tampered with at loading time. There are several TEEs available in both industry and research worlds, each of them is platform-specific, come with different system footprint, and provide slightly different security guarantees: open-source developments include Sancus and Keystone; proprietary options are, e.g., SGX for Intel processors, SEV for AMD, TrustZone for ARM, etc. Therefore, developing a heterogeneous, distributed application that uses different TEEs is non-trivial for a developer, who needs to adapt the code of each component (or module) to a specific platform. Open-source projects such as Open Enclave SDK and Google Asylo aim to bridge the development gap between different TEEs. However, software engineers still need to account for the communication between different modules, which has to be properly secured with cryptographic operations for data encryption and authentication. After the development phase, a system operator is responsible for deploying this distributed application on the (potentially shared) infrastructure: each module has to be properly initialized and attested (e.g., using Remote Attestation), and connections have to be established (e.g., by creating and distributing session keys). In summary, ensuring strong confidentiality and integrity guarantees in such a situation is difficult and error-prone. The framework we are developing automatically handles all of this work: deployment, attestation, configuration, provisioning of communication APIs. Therefore, it provides the developer an abstraction layer in which they only need to implement the application’s logic. The idea behind our implementation is based on the concept of Authentic Execution, which aims to ensure a strong integrity guarantee over the whole execution of an application. The following citation from our previous paper describes the goal of Authentic Execution: "Roughly speaking, our notion of authentic execution is the following: if the application produces a physical output event (e.g.,turns on an LED), then there must have happened a sequence of physical input events such that that sequence, when processed by the application (as specified in the high-level source code), produces that output event." (from https://people.cs.kuleuven.be/~jantobias.muehlberg/stm17/paper.pdf) Note that this concept focuses mainly on the integrity of an application: however, confidentiality comes for free in our implementation, thanks to confidential computing provided by the TEEs and authenticated encryption of the data. Currently, our framework supports Intel SGX, ARM TrustZone and Sancus (an open-source, embedded TEE for lightweight microcontrollers), allowing the development of applications that can be used in a broad range of use cases, which include cloud processing, mobile devices and lightweight IoT. Our purpose is to provide end-to-end security from low-end systems that include I/O devices to high-end computation nodes. In the presentation, we will demonstrate the use of our framework on the example of a prototypic secure smart irrigation system, a typical use-case for Smart Environments. This example combines SGX and Sancus together to build a secure, heterogeneous system composed of data processing servers and low-power microcontrollers. Our work also focuses on code quality, especially in order to ensure absence of memory-corruption vulnerabilities. This is essential for enforcing the security guarantees we are aiming for: TEEs and crypto are not helpful if the code is bugged. Hence, the SGX part of our framework was entirely written in Rust, a modern and fast programming language that provides by nature protection against all low-level memory-corruption vulnerabilities. Work for ARM TrustZone is currently ongoing. We are exploring the use of Rust and C in this implementation as well. Sancus is based on the embedded MSP430 processor with a 16-bit CPU, and therefore its implementation was written in C and assembly. Testing and verification techniques are to be applied here to ensure the absence of memory-corruption vulnerabilities. Our framework aims to minimize the developer’s effort as much as possible: only the application’s logic should be implemented by them, leaving all the details about enclaved execution, secure inter-module communication and Remote Attestation to our framework. To ensure this, the system operator writes a configuration file called deployment descriptor, which includes information about the nodes where the modules will be deployed to, as well as the declaration of connections between two different modules. We implemented a tool that takes as input the source code of all the modules and the deployment descriptor, and it automatically deploys the distributed application according to the information provided in the descriptor. In addition, Remote Attestation is automatically performed to verify the correctness of each module and to exchange session keys for the inter-module communications. Work is in progress to provide complete abstraction over the underlying platform where a module is executed: the ultimate goal is to write an application’s module without having prior knowledge about whether it will be executed on e.g. a SGX or a TrustZone platform. However this is a non-trivial challenge, since two platforms might present huge differences (e.g., Sancus and SGX), and since many features are only available on specific implementations (e.g., Secure I/O).

Additional information

Type devroom

More sessions

2/6/21
Hardware-Aided Trusted Computing
Jo Van Bulck
D.hardware.trusted
A brief introduction to the room and to the sessions.
2/6/21
Hardware-Aided Trusted Computing
D.hardware.trusted
If you’re designing a project where security is uppermost, but you want to make it easy to use and compatible with multiple platforms (existing and future), what principles should you follow, and how do they translate into an architecture and actual code. We’ll present the 10 security design principles of the Enarx project, and discuss why they led us to where we are today: a Rust-based open source project with a WebAssembly run-time.
2/6/21
Hardware-Aided Trusted Computing
Dominic Mulligan
D.hardware.trusted
In this presentation we will introduce Veracruz, a project recently adopted by the Confidential Compute Consortium, exploring how efficient, collaborative computations between mutually distrusting parties can be developed using a mixture of hardware- and software strong isolation mechanisms. Veracruz uses Arm TrustZone, Intel SGX, AWS Nitro Enclaves, or the high-assurance seL4 microvisor, to provide a "neutral ground" within which a collaborative computation takes place, shielded from prying or ...
2/6/21
Hardware-Aided Trusted Computing
Dmitrii Kuvaiskii
D.hardware.trusted
Graphene is a lightweight library OS, designed to run a single Linux application in an isolated environment. Currently, Graphene runs on Linux and Intel SGX enclaves on Linux platforms. With Intel SGX support, Graphene can secure a critical application in a hardware-encrypted memory region and protect the application from a malicious system stack with minimal porting effort. This talk will discuss the design, implementation, features, lessons learned, and the current status of the project. The ...
2/6/21
Hardware-Aided Trusted Computing
Christoph M. Wintersteiger
D.hardware.trusted
Existing attestation schemes require pre-signed enclave images and provide few means of including runtime-dependent configuration data (like report data, enclave held data, configid). In multi-party settings in which the parties may not always fully trust each other, attestation of multiple pieces of code or data images via these means is cumbersome and inefficient. For example, consider the case of a secure cloud service running a JavaScript interpreter, which interprets a third-party script, ...
2/6/21
Hardware-Aided Trusted Computing
D.hardware.trusted
Enclave technologies such as SGX generally have a relatively high context-switching cost. This is particularly noticeable when doing (network) I/O. In this talk we'll present the first non-LibOS implementation of an asynchronous I/O model for SGX. This gives you a language-native async I/O programming experience in Rust, outperforming any other way to build SGX network services.
2/6/21
Hardware-Aided Trusted Computing
ZITAI CHEN
D.hardware.trusted
Previous work such as Plundervolt has shown that software-based undervolting can induce faults into Intel SGX enclaves and break their security guarantees. However, Intel has addressed this issue with microcode updates. We later discovered that there is a physical connection on the motherboard which allows us to control the voltage and conduct fault injection. In this talk, we will present a low-cost device: Voltpillager, which use this physical connection to break the guarantees provided by SGX ...