What is the Veracruz proxied attestation service?

As mentioned, Veracruz supports a number of different containerization technologies, and in some cases a container technology and a remote attestation protocol are intimately linked. This is the case with Intel SGX, for instance, which is deeply tied to Intel's attestation protocol, EPID, and uses the Intel Attestation Service — a web-service for authenticating EPID attestation tokens. Arm, too, has its own attestation protocol in PSA Attestation, which we use for attestation on Arm TrustZone (though this is not yet fully implemented). More generally, if Veracruz adds another supported containerization technology the chances of having to support another attestation protocol are quite high. This poses a few problems for Veracruz:

1. Client code interacting with Veracruz containers becomes more complicated, as it needs to support multiple attestation protocols. Aside from bloating the client, this also breaks the abstraction over containerization technology that Veracruz aims to provide.
2. For Intel SGX Enclaves, for example, multiple calls to Intel's Attestation Service are needed when working with multiple enclaves. Whilst the EPID protocol is designed with anonymity in mind, there are still several reasons why this may be undesirable.
3. Changes in policy require an update of all client code, at present. Here we have in mind changes in trust relationships between developers of client code and particular hardware manufacturers, or models of hardware, either driven by security disclosures, geopolitical trends, or shifting business attitudes/contexts.

Our solution to these problems is to introduce a proxy attestation service. This attestation service presents a uniform protocol interface to client code, no matter which underlying containerization technology is in use on the delegate's machine, through the use of Arm's PSA attestation protocol.

The introduction of this proxied service solves all three problems identified above.

First, note that this attestation service must still use the native attestation protocol — for example, EPID, in the case of Intel SGX — at some point, but client code never sees this, instead only ever interacting with the proxy attestation service using PSA Attestation. Note that, as our attestation service essentially "translates" one attestation protocol into another, or mediates between protocols, we sometimes refer to it as a hybrid proxy. This hybrid proxying significantly simplifies client code interacting with Veracruz: now, it need only support Arm's PSA Attestation protocol, rather than a panoply of differing protocols, depending on the particular containerization technology in use.

Second, the mechanism by which the proxied attestation process works reduces the number of calls to any external attestation service to one when authenticating containers on a delegate's machine. A single distinguished container, the root container, is authenticated using the native attestation protocol associated with that container technology — EPID, in the case of Intel's SGX — by the proxied attestation service itself. This root container is enrolled by the service by the establishment of a shared secret between the two, the equivalent of a root attestation key in more standard attestation schemes. This root container is then used to authenticate any other container, started on the same machine, by the proxied attestation service. Client code of Veracruz never observes the enrollment process of the root container: it's assumed to happen before any container is launched on the delegate's machine.

Without the proxied attestation service, a delegate launching E enclaves on their machine, each started for the purposes of hosting a single Veracruz computation involving Di data providers for 1 <= i <= E, required sum Di + 1 for 1 <= i \<= E calls to the native external attestation service (the 1 in the expression corresponds to the program provider in each Veracruz computation). Now, this is reduced to a single call: the authentication of the root enclave.

Lastly, observe that the introduction of this proxied service now allows client code using it to specify precisely what they are willing to trust, through the use of an attestation policy. In standard attestation schemes, this decision must be made in the client, and if, for example, a particular bit of hardware is revealed to be fundamentally broken, especially prone to leaking secrets from its strong container implementation due to microarchitectural weaknesses, after client code is deployed, then working around this requires an update to all client code deployed in the field. Instead, the introduction of this proxy allows clients, or a third party, to inform the proxy of which containers they are willing to trust, which can be taken into account by the proxy itself when authenticating or rejecting attestation tokens on the client's behalf. (Note, we have not yet got around to implementing this feature in Veracruz.)

What's the downside?

The major downside of the introduction of our hybrid proxied attestation service is that it increases the trusted compute base of the Veracruz framework. Principals in a Veracruz computation now need to explicitly trust the proxied attestation service, and also need to carefully vet the source code (assumed open, and auditable) of the software running inside the root enclave, launched on the delegate's machine. This is reflected in the Veracruz threat model — further discussed in What is the Veracruz threat model? — which explicitly states that all principals must trust this service.