Blog
A look at the open-source confidential computing landscape
This blog post is the first in our spotlight series, where we'll feature some of the most interesting open-source projects in the confidential computing ecosystem. To start things off, we're going to take a look at the Veracruz project by Arm.
Veracruz is a framework for defining flexible and efficient multi-party computations. It allows programmers to develop collaborative computation between mutually distrusted parties and aims to support common use cases for advanced cryptographic techniques like homomorphic encryption.
Veracruz addresses the shortcomings of homomorphic encryption or secure multi-party computation by focusing on delivering a fast, efficient, and familiar experience. It aims to allow programmers to develop multi-party computations using standard programming languages and standard tool sets. The Veracruz project wants to be general and reusable. The framework seamlessly supports a broad range of collaborative computations. It's reusable in the sense that the levels of configuration required to design a new collaborative computation should be kept to a minimum, and whatever configuration is needed should be straightforward and easy to understand for programmers. In common with those techniques, the Veracruz team hopes to use hardware-based trusted execution environments (TEEs) to provide strong security and privacy guarantees.
Veracruz is open source and an adopted project of the Confidential Computing Consortium. The project is mostly written in Rust. Its cryptography is based on Rustls and Ring. WebAssembly is used to facilitate cross-platform support, which currently includes Intel SGX, Arm TrustZone and AWS Nitro Enclaves.
Next, we'll provide a high-level overview of Veracruz. The Veracruz runtime executes inside a TEE, which also includes a policy (written in JSON) with all the roles and identities of everyone involved in the computation. The policy describes who can receive the results of the computation. It also contains hashes of the expected Veracruz runtime, and the expected hash of the program being loaded.
Veracruz accepts multiple data inputs. These can originate from different agents, which may or may not distrust each other. They only thing they need is a shared trust in the platform everything is being executed on, including an audit of the Veracruz runtime software. Additionally, we have the program input --- this may originate from another agent. One of the key points of Veracruz is that this program is allowed, but not required, to be confidential. This program is compiled to WebAssembly. The program and the data are provisioned securely using a TLS that is terminated inside the TEE into Veracruz, and then inside Veracruz the result is computed. Finally, the result can be retrieved by an entity specified in the policy file.
Supported Hardware
Currently, Veracruz supports Arm TrustZone, Intel SGX, AWS Nitro Enclaves and the seL4 Microkernel. Each of these comes with its requirements and limitations, e.g. when it comes to the amount of memory available in each enclave. The following example is how a stack operating on Arm TrustZone might look:
The light boxes are what we refer to as the non-secure world, with the Rich OS boxes being any OS you may want to run, e.g. a Linux distribution. All dark boxes are what we refer to as the secure world, including the Firmware / Secure Monitor (EL3), a secure partition manager, the trusted OS, and the trusted services.
WebAssembly on Veracruz
Most programs that are usually run in Veracruz are written in WebAssembly, which has become somewhat of an unofficial standard for most confidential computing projects. WebAssembly is a binary instruction format for a stack-based virtual machine --- one way to think about it is as an improved java byte code. It's primarily intended as a replacement for JavaScript for performance-critical applications, but WebAssembly has also been gaining traction on server side for various other reasons:
Veracruz uses WebAssembly for the following reasons:
1. SGX 1.0 does not let you easily load software after the enclave start. Unless you are comfortable with writable/executable page flags, the entire program which is supposed to run needs to be known on enclave start. This prevented runtime loading of encrypted programs under SGX.
2. To protect the enclave environment from un-inspectable, possibly malicious programs loaded at runtime. This is where the sandboxing of WASM is helpful, since it can be used to protect the Veracruz execution code from any bugs encountered in program handling.
3. Because the supported enclaves run on x86 and aarch64, this adds portability of the enclave program.
Currently, Veracruz uses a custom interface for applications, but the team is working on support for the WebAssembly System Interface (WASI). WASI is a POSIX-like standard for WASM programs. It is going to be included as a limited WASI layer so programs can interact with their data sources and destinations. Usually, this is focused on the file interfaces, where the Veracruz team is creating a file in memory file system, kept in ephemeral RAM inside the enclave.
If you're interested in more details, just visit the Github repository or the Veracruz project homepage. Veracruz is an adopted project of the Confidential Computing Consortium (CCC), Copyright 2020--2021 Veracruz, a series of LF Projects, LLC.
This blog post is based on a talk by Derek Miller (Principal Security Researcher, Arm) at the Open Confidential Computing Conference 2021 You can watch the full recording on YouTube.
