| id | title | team | created | status |
|---|---|---|---|---|
33 |
Attestation Stack for TEE-based Protocols |
Andrew Miller (hbcl), Sylvain Bellemare (hbcl) |
2023-06-14 |
stagnant |
auditee, as a starting point, aims at giving a single script that carries out
the entire end-to-end auditing task, including the reproducible build, as well as
verifying all intermediate signatures in the certificate chain. A more comprehensive
solution would provide data availability and a visible public repository for all of the
evidence associated with attestations. This is an ecosystem wide problem, since
TEE-based private smart contracts, non-blockchain TEE applications like Signal or
enterprise applications also do not do a thorough job at this. There is a need for an
orchestrator to elevate this playing field. Perhaps this could evolve as a dashboard.
We are often interested in small self-contained enclaves that do a small task but are amenable to software analysis. This can include small Python / Go programs using Gramine, as well as low-level implementations via the Rust SGX SDK. The appeal of low level implementations especially is that we have a better chance of carefully studying and mitigating the side channels, i.e. to account for the side channels we have to tolerate, and to help check if a mitigation (constant time implementation) is working.
Since running EVM within an enclave is necessary anyway, the concrete proposal here is to develop a small reproducible enclave that evaluates EVM directly in Rust SGX SDK, and a Python demo in Gramine where the build is not guaranteed reproducible. We will include a write-up to the forum summarizing the process involved in making this reproducible package.
If we really want to use Gramine in a production system, we should include reproducible builds for Gramine itself. The previous effort to do this via Nix packages didn't get the Gramine upstream authors to agree to support it. What's left is the straightforward but tedious task of porting it ourselves as well as tracking upstream patches. Nix is the basis of reproducible builds. So there's no special knowledge needed to adapt Gramine to Nix, just need to systematically make a Nix pinned build package for each dependency.
Don't know how to automate this better, but Gramine is bounded so this is estimated to take about 1 month. We will conclude this effort with a writeup to the forum explaining the process in as clear detail as we can, in order to estimate the effort required to continuously apply upstream Gramine patches. (Early work-in-progress implementation of a nix flake for gramine.)
Part of this work could also help bringing more clarity about what it takes to support reproducible builds. Different projects use different tools, and it's somehow difficult to be certain whether the different tools do in fact achieve reproducible builds over a reasonable span of time. In the context of enclave applications, it has yet to be clarified how important reproducible builds are, and how far out in the future should a given enclave binary should be reproducible from its source code. Currently, multiple projects rely on docker images, and although this may work for a limited amount of time, would this work for multiple months? This is not clear at all.
Some examples of projects where the topic of reproducible builds is still an open issue:
Is considered resolved with Nix:
Is considered resolved via Docker:
Right now it is a straightforward but tedious task, but the skill for doing it and handling edge cases is not really portable either. Let's document this process so we can at least outsource it more effectively? The next question is to pursue automation.
In the context of Intel SGX, remote attestation relies on prebuilt architectural enclaves. Although the code of these enclaves is open source, when deployed their binary form must be signed by Intel. Thus, using SGX implies one is trusting Intel for their architectural enclaves as well as their chips, etc. It's nevertheless possible to audit the code, and furthermore some verification mechanism could perhaps be implemented such that combined with reproducible builds, a remote attestation flow would somehow be verifiable such that the generated quote would be proven to be from the expected quoting enclave. This verification flow would also apply to custom enclaves that are used in DCAP-based attestation flows.
To kickstart the discussion of how to orchestrate the Attestation Stack, and build towards the vision of Enclave Transparency, a proposed starting point is Enclave Hub. Basically this would be a dashboard website that provides data availability for all the source code dependencies needed to rebuild the attestation stack.
auditee- Nix-based reproducible builds for Intel's C++ SGX SDK
- Intel's nix-based tooling to verify the reproducibiliy of its architectural enclaves
- Open issue for reproducible builds for the Rust SGX SDK
- Open issue for reproducible builds for Oasis Protocol
- Open issue for reproducible builds for Secret Network
- Open issue for reproducible builds for Gramine