What is the Veracruz threat model?

We now specify precisely what a principal taking part in a Veracruz computation needs to trust, and what is left untrusted. Some aspects of the Veracruz threat model are common to all of Veracruz's supported strong containerization technologies, so we handle these cases first.

In every Veracruz computation principals must carefully check the global policy, and evaluate this with respect to any pre-existing trust relationships that they may have with other principals, as discussed in What are Veracruz computations?. Moreover, in every Veracruz computation principals must trust:

• The trusted Veracruz runtime. This is assumed to be open, and auditable by everybody prior to enrollment in the computation. Note that principals must convince themselves that the trusted Veracruz runtime:
  • Only loads and executes whatever WASM program is provisioned into it by the Program Provider, and nothing else.
  • Only provides data sets as input to the WASM program that are explicitly provisioned into it by the Data Providers, and nothing else.
  • Correctly enforces the global policy describing the computation, namely that it enforces the described roles for the named principals, including the role of Results Receiver.
  • Correctly sandboxes the execution of the WASM program, providing only the host services detailed in What is the Veracruz programming model? and nothing more.
  • Correctly implements the Veracruz host-call API.
  • Correctly implements the Veracruz state transition system so that, e.g. two different programs cannot be provisioned into the trusted Veracruz runtime, or that a second Veracruz computation cannot be scheduled by the Veracruz runtime without the explicit consent of all parties to the computation.
  • Only returns the result registered by the WASM program, when run on the data sets provisioned by the Data Owners, and nothing else.
  • Faithfully executes the WASM program, on its inputs, according to the formal operational semantics of WebAssembly, and does not diverge from these published semantics.
  • Is free of memory corruption errors, that could be exploited by an attacker to gain control of a container using e.g. Return Oriented Programming techniques. To mitigate this problem, the trusted Veracruz runtime is written in the Rust programming language, which aims to provide enhanced levels of memory-safety for systems code. Notably, all "unsafe" memory accesses are explicitly marked using an unsafe keyword, making them easier to audit.
• The attestation protocol. Principals must be able to trust that if the attestation protocol certifies an attestation token as being issued from an authentic strong container C and corresponds to code with a given measurement (a cryptographic hash of the binary loaded into C), M, then a binary with measurement M is indeed loaded inside container C.
• The Veracruz proxied attestation service.
• The security and integrity guarantees of the TLS protocol.

In every Veracruz computation principals need not trust:

• Any other principal to the computation.
• The untrusted Operating System, Hypervisor, or other system software running on the delegate's machine which is not explicitly marked as part of the trusted compute base in the subsections below.
• Any networking stack: for every supported strong containerization technology supported by Veracruz, the networking stack is handled in untrusted code.

Side-channel attacks against the trusted Veracruz runtime are explicitly outside of the Veracruz threat model, at the time of writing. Various controlled side-channel attacks have been used by a number of academic research labs to break the security of Intel SGX and Arm TrustZone containerization. We do not explicitly defend against these, at present.

Note also that the trusted Veracruz runtime does not provide liveness guarantees. Namely, a principal to the computation could try to perform a denial of service attack against an ongoing Veracruz computation. This is especially easy for the delegate, who is capable of denying scheduled execution time to computations running inside an e.g. Intel SGX enclave. Defending against this is, again, outside of the Veracruz threat model. In situations where this matters, e.g. in collaborative computations wherein mutually distrusting parties are both Results Receivers, principals should ensure that the computation is structured in such a way that one party cannot receive the result of the computation whilst denying the result to the other party.

...for Intel SGX?

For Veracruz computations using Intel SGX as the containerization technology principals must trust:

• The security guarantees of the Intel SGX architecture/implementation on a given Intel microprocessor model. Namely, the inability of code executing outside of the enclave to break the confidentiality and integrity of the code executing inside the enclave boundary, without explicit declassification on the part of the enclaved code.
• The Apache Teaclave Rust-SGX SDK (formerly: Baidu Rust SGX SDK) which is used to develop Veracruz, and forms part of the trusted base of the trusted Veracruz runtime.
• The Intel Attestation Service, a web-service operated by Intel and used to authenticate attestation tokens issued by Intel SGX Secure Enclaves.

For computations using Intel SGX, principals need not trust any other software other than the trusted Veracruz runtime and the attestation service, mentioned above.

...for Arm TrustZone?

For Veracruz computations using Arm TrustZone as the containerization technology principals must trust:

• The OP-TEE operating system, and its implementation of relevant GlobalPlatform APIs. Specifically, principals should trust that the OP-TEE operating system correctly isolates trusted applications from each other.
• The security guarantees of the Arm TrustZone architecture. Namely, the inability of code executing in the non-secure world to break the confidentiality and integrity of the code executing in the secure world, without explicit declassification on the part of secure code.
• The implementation of Arm TrustZone on the Delegate's machine is a faithful implementation of the Arm TrustZone architecture.
• The Baidu Rust TrustZone/OP-TEE SDK which is used to develop Veracruz, and forms part of the trusted base of the trusted Veracruz runtime.

Note that, at present, the remote attestation flow for Arm TrustZone is not fully implemented in Veracruz. To do so, requires implementing a trusted boot mechanism for OP-TEE, which we leave for future work as it seems fairly straightforward to implement. When attestation for TrustZone is implemented, principals must additionally trust:

• The native attestation service used to authenticate attestation tokens issued by a TrustZone trusted application under OP-TEE.

...for hypervisor-based containerization with seL4?

For Veracruz computations using seL4 as the containerization technology principals must trust:

• The security guarantees of the seL4 micro-kernel, acting as a hypervisor, on Arm AArch64.

Note, again, that at present the remote attestation flow for seL4 is not fully implemented in Veracruz. To do so, requires implementing a trusted boot mechanism, which we leave for future work as it seems fairly straightforward to implement along with an identity key provisioning service for seL4 protected virtual machines. When attestation for seL4 is implemented, principals must additionally trust:

• The native attestation service used to authenticate attestation tokens issued by an seL4-protected virtual machine.
• The identity key provisioning service, used to provision globally unique identity keys into an seL4-protected virtual machine for attestation purposes.