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).