Table of Contents
Fetching ...

Attestable Builds: Compiling Verifiable Binaries on Untrusted Systems using Trusted Execution Environments

Daniel Hugenroth, Mario Lins, René Mayrhofer, Alastair Beresford

TL;DR

The paper tackles the challenge of verifying that a binary artifact was faithfully built from a given source snapshot in environments where the build pipeline is untrusted. It introduces Attestable Builds (A-Bs), a paradigm that uses modern TEEs and nested sandboxing to ensure integrity of the build process, while leveraging a transparent log to publish attestations and facilitate verification. The authors provide an architecture, threat model, and a formal verification (via Tamarin) showing security properties like code, asset, infrastructure, and repository integrity, and demonstrate practicality through a prototype built on AWS Nitro Enclaves with evaluation on diverse targets including LLVM Clang and the Linux kernel. They also show how A-Bs can compose with Reproducible Builds (R-Bs) to realize an anytrust model, discuss deployment considerations, and present case studies illustrating mitigations against real-world supply-chain attacks. Overall, A-Bs offer a pragmatic, scalable enhancement to software provenance and trust, enabling verification by downstream consumers even when the primary build infrastructure is untrusted.

Abstract

In this paper we present attestable builds, a new paradigm to provide strong source-to-binary correspondence in software artifacts. We tackle the challenge of opaque build pipelines that disconnect the trust between source code, which can be understood and audited, and the final binary artifact which is difficult to inspect. Our system uses modern trusted execution environments (TEEs) and sandboxed build containers to provide strong guarantees that a given artifact was correctly built from a specific source code snapshot. As such it complements existing approaches like reproducible builds which typically require time-intensive modifications to existing build configurations and dependencies, and require independent parties to continuously build and verify artifacts. In comparison, an attestable build requires only minimal changes to an existing project, and offers nearly instantaneous verification of the correspondence between a given binary and the source code and build pipeline used to construct it. We evaluate it by building open-source software libraries - focusing on projects which are important to the trust chain and have proven difficult to be built deterministically. The overhead (42 seconds start-up latency and 14% increase in build duration) is small in comparison to the overall build time. Importantly, our prototype can build complex projects such as LLVM Clang without requiring any modifications to their source code and build scripts. Finally, we formally model and verify the attestable build design to demonstrate its security against well-resourced adversaries.

Attestable Builds: Compiling Verifiable Binaries on Untrusted Systems using Trusted Execution Environments

TL;DR

The paper tackles the challenge of verifying that a binary artifact was faithfully built from a given source snapshot in environments where the build pipeline is untrusted. It introduces Attestable Builds (A-Bs), a paradigm that uses modern TEEs and nested sandboxing to ensure integrity of the build process, while leveraging a transparent log to publish attestations and facilitate verification. The authors provide an architecture, threat model, and a formal verification (via Tamarin) showing security properties like code, asset, infrastructure, and repository integrity, and demonstrate practicality through a prototype built on AWS Nitro Enclaves with evaluation on diverse targets including LLVM Clang and the Linux kernel. They also show how A-Bs can compose with Reproducible Builds (R-Bs) to realize an anytrust model, discuss deployment considerations, and present case studies illustrating mitigations against real-world supply-chain attacks. Overall, A-Bs offer a pragmatic, scalable enhancement to software provenance and trust, enabling verification by downstream consumers even when the primary build infrastructure is untrusted.

Abstract

In this paper we present attestable builds, a new paradigm to provide strong source-to-binary correspondence in software artifacts. We tackle the challenge of opaque build pipelines that disconnect the trust between source code, which can be understood and audited, and the final binary artifact which is difficult to inspect. Our system uses modern trusted execution environments (TEEs) and sandboxed build containers to provide strong guarantees that a given artifact was correctly built from a specific source code snapshot. As such it complements existing approaches like reproducible builds which typically require time-intensive modifications to existing build configurations and dependencies, and require independent parties to continuously build and verify artifacts. In comparison, an attestable build requires only minimal changes to an existing project, and offers nearly instantaneous verification of the correspondence between a given binary and the source code and build pipeline used to construct it. We evaluate it by building open-source software libraries - focusing on projects which are important to the trust chain and have proven difficult to be built deterministically. The overhead (42 seconds start-up latency and 14% increase in build duration) is small in comparison to the overall build time. Importantly, our prototype can build complex projects such as LLVM Clang without requiring any modifications to their source code and build scripts. Finally, we formally model and verify the attestable build design to demonstrate its security against well-resourced adversaries.
Paper Structure (44 sections, 8 equations, 12 figures, 7 tables)

This paper contains 44 sections, 8 equations, 12 figures, 7 tables.

Figures (12)

  • Figure 1: Developers (DEVs) commit to a source code repository at a repository hosting provider (RHP). Changes trigger the CI/CD pipeline at a build service provider (BSP) and generate new binary artifacts. RHP and BSP typically run on servers provided by a cloud service provider (CSP).
  • Figure 2: Overview of the protocol steps during build and verification. Dashed borders indicate separate or sandboxed execution environment. Only the TEE and the hardware trust anchor are fully trusted. $\vcenter{}$ The build process is triggered manually or as a result of code changes. Either will cause a webhook call to the Instance Manager. $\vcenter{}$ The Instance Manager starts an fresh enclave from a publicly known .eif file with the measurements PCR0-2. $\vcenter{}$ Once booted, the Enclave Client starts the inner sandbox. $\vcenter{}$ The sandbox executes the action runner which fetches the repository snapshot. That snapshot includes both the source code and build instructions. $\vcenter{}$ A hash of the snapshot is reported to the Enclave Client for safeguarding. Now the build process is started which is untrusted. $\vcenter{}$ Once it finishes, the sandbox reports the hash of the produced artifact. $\vcenter{}$ The Enclave Client then requests an attestation document from the Nitro Card covering PCR0-2, the repository snapshot hash, and the artifact hash. $\vcenter{}$ The results are shared with both the build process and the outer Instance Manager. $\vcenter{}$ The build process can now publish the artifact and certificate. And the Instance Manager publishes the attestation. $\vcenter{}$ When a user downloads the artifact, it can contain a certificate specifying how it was build. $\vcenter{}$ The user can verify this certificate by checking that it is included in the public transparency log.
  • Figure 3: Three attestable builders using different hardware vendors (e.g., Intel, AMD, Arm) perform the same R-B resulting in identical artifacts. The user is then hedged against up to two backdoored TEEs (§\ref{['sec:stamp:composing']}).
  • Figure 4: The duration of individual steps for the evaluated projects including the five unreproducible Debian packages and other artifacts. HS represents the baseline with a sandbox running directly on the host, ES (using containerd) and ES+ (using gVisor) are variants of our A-B prototype executing a sandboxed runner within an enclave.
  • Figure 5: Impact of number of jobs for make -j (left) and cargo build -j (right) with 4 available CPUs.
  • ...and 7 more figures