How does Veracruz compare to...

Several other commercial and academic projects exist in the broad area of privacy-preserving compute, using hardware-enclaves and remote attestation. In this section, we draw comparisons between these other projects and Veracruz.

Microsoft's OpenEnclave

Veracruz and OpenEnclave differ quite markedly, both in their design goals and in their implementation.

OpenEnclave is intended as a thin layer over different low-level APIs, such as Intel's SGX SDK, which allows programmers to develop enclave-oriented applications, across multiple enclave implementations, using a consistent and uniform API and a single set of associated tools. Programmers using OpenEnclave still need to design communication, provisioning, and attestation protocols on top of OpenEnclave, as these are application-specific.

In contrast, Veracruz is a platform for facilitating secure multi-party computations amongst a range of mutually distrusting principals. To support this, Veracruz fixes a particular communication and attestation protocol that is made to support the use-cases that we care about. Moreover, whilst Veracruz also provides a uniform programming model across multiple strong container technologies, this programming model is far more restrictive than that offered by OpenEnclave, as this is again optimized for the particular use-cases that we have in mind.

Lastly, we observe that Veracruz could be built on top of OpenEnclave. At present, we use a range of different low-level APIs when developing Veracruz — including Baidu SDKs for SGX and TrustZone. Instead, Veracruz could make use of OpenEnclave as a hardware-abstraction layer.

Enarx

Enarx is perhaps the closest project to Veracruz in terms of both design goals and implementation. Both projects make use of WASM code running inside a strong container. However, there are still differences both in the design and implementations of the two projects.

First, the Enarx project's focus is on providing confidentiality for existing workloads on third-party computing services. In contrast, the Veracruz project's focus is providing a framework for developing secure, collaborative computations between mutually untrusting principals. These two differing visions have an effect on design decisions taken in the two projects: for instance, Veracruz requires a notion of global policy, and a defined provisioning protocol built around the idea that multiple parties will be provisioning code and data into the trusted Veracruz runtime, that is unneccessary in Enarx.

Moreover, note that Veracruz has a relative paucity of services provided to the WASM program by the trusted Veracruz runtime. This is a key design decision in enabling secure multi-party computations wherein principals may be actively trying to steal the secrets of others. In contrast, Enarx's plan of record is to support the WASI host interface, which is implemented on top of a syscall-proxying mechanism wherein syscalls are handled by the host operating system. This latter observation also highlights another point of departure between the two projects: Enarx is built around the idea of protecting existing code, and therefore needs to provide a comprehensive syscall interface to support the full breadth of deployed programs, whereas Veracruz aims to protect a single WASM application that for the most part will be written specifically for use with Veracruz.

Aside from broader design differences between the two projects, there also exist implementation differences. First, Enarx at the time of writing supports deployment on top of AMD Secure Encrypted Virtualization (or SEV, henceforth) protected virtual machines as its containerization technology. In contrast, Veracruz uses Intel SGX, Arm TrustZone, and hypervisor-based containerization through seL4. In theory, Veracruz on AMD SEV could be supported, though at the time of writing we have no concrete plans to do so. Note that these implementation differences also have an effect on the trusted computing base of the two projects: Enarx under AMD SEV needs a trusted micro-kernel hosting the WASM/WASI runtime inside the SEV container. For some backends, e.g. Intel SGX, Veracruz does not need this trusted micro-kernel at all, and simply relies on the hardware's security guarantees to protect the Veracruz runtime. In contrast, Veracruz on Arm TrustZone is indeed running under a trusted operating system, in OP-TEE.