Attested Builds

Attested builds are a new approach to verifiable software distribution. Source code is compiled inside hardware-isolated environments that produce cryptographic proof linking binaries to their exact inputs.Powered by Kettle, Lunal's open-source implementation.

Building Software

In the context of Kettle, a software build is any transformation of inputs into outputs. Building can include preprocessing, compilation, linking, copying, packaging, or any kind of file generation. The specific aspects of a build that matter when creating builds that offer high confidence that the stated inputs map to a given output are:

  • Inputs: source repositories, dependencies, toolchains, configuration files
  • Process: build scripts run, tool options, environment variables
  • Environment: operating system, kernel and its parameters, filesystems and other devices
  • Outputs: binaries, containers, tarballs, or other resulting artifacts

     ┌────────────────┐
     │     Source     │ ───╮
     └────────────────┘    │
                           │
                           │
                           │
     ┌────────────────┐    │
     │      Deps      │ ───┤
     └────────────────┘    │
                           │       ┌──────────────────┐            ┌────────────┐
                           ├──────►│ Build execution  │───────────►│  Artifact  │
                           │       └──────────────────┘            └────────────┘
     ┌────────────────┐    │
     │   Toolchain    │ ───┤
     └────────────────┘    │
                           │
                           │
                           │
     ┌────────────────┐    │
     │  Environment   │ ───╯
     └────────────────┘

A build is a many-input transformation. Source identity is necessary but incomplete because dependencies, toolchains, build scripts, and execution state also affect the final bytes.

SLSA Software Provenance

As described by the SLSA project at the Linux Foundation, "SLSA is a specification for describing and incrementally improving supply chain security, established by industry consensus". Among other things, the SLSA specification offers a concrete format for provenance, which is defined as verifiable information that can be used to track an artifact back, through all the moving parts in a complex supply chain, to where it came from. It is the verifiable information about software artifacts describing where, when, and how something was produced.

By using the SLSA v1.2 build provenance format, Kettle is able to provide industry-standard and machine-readable information that connects an artifact back to the source and tools that were used to create that artifact.

Trusted Execution Environments (TEEs)

A Trusted Execution Environment (TEE) is a hardware-enforced isolation boundary that provides four security properties:

  • Confidentiality. Private memory within the TEE is encrypted at the hardware level. Memory pages are encrypted with keys managed by the CPU's secure processor, so the hypervisor, host operating system, and DMA-capable devices cannot decrypt private TEE memory contents through software access.
  • Integrity. Once software is initialized in a TEE, modifications to protected guest state by external software are detected. Replay attacks, data corruption, and memory remapping trigger hardware-level faults within the platform's threat model.
  • Verifiability. The TEE produces a cryptographic measurement (a digest) of the software loaded at launch. This measurement covers firmware, kernel, initial filesystem state, and user space, and is computed by the CPU's secure processor before the guest operating system begins execution.
  • Attestation. The TEE generates signed attestation reports binding the launch measurement to guest-supplied report data. These reports are signed by keys that chain to the hardware manufacturer's root of trust and cannot be forged by any software on the host.
  Outside:  Hypervisor   Host OS   BIOS   Device drivers   Cloud operator

  ╔═══════════════════════ CVM boundary ════════════════════╗
  ║                                                         ║
  ║    ┌────────────────────────────────┐  ╮                ║
  ║    │  Firmware                      │  │                ║
  ║    └────────────────────────────────┘  │                ║
  ║    ┌────────────────────────────────┐  │                ║
  ║    │  initrd                        │  │                ║      ┌──────────────────┐
  ║    └────────────────────────────────┘  │                ║      │   Attestation    │
  ║    ┌────────────────────────────────┐  │                ║      │     report       │
  ║    │  Kernel                        │  ├──── digest ────╫─────►├──────────────────┤
  ║    └────────────────────────────────┘  │                ║      │   Measurement    │
  ║    ┌────────────────────────────────┐  │                ║      │   Signature      │
  ║    │  User space                    │  │                ║      └──────────────────┘
  ║    └────────────────────────────────┘  │                ║
  ║    ┌────────────────────────────────┐  │                ║
  ║    │  Deployed workload             │  ╯                ║
  ║    └────────────────────────────────┘                   ║
  ║                                                         ║
  ╚═════════════════════════════════════════════════════════╝

Implementations. Current commercial TEEs from AMD and Intel implement all four properties at the boundary of a virtual machine. The resulting environments are referred to as Confidential Virtual Machines (CVMs), where private guest memory is encrypted with keys the hypervisor never possesses. The four properties reinforce one another. Host software can no longer directly read private CVM memory or silently rewrite measured guest state, which prevents software-level data exfiltration and tampering by the host. As long as the hardware manufacturers can be trusted and firmware vulnerabilities can be patched as they are found, the trust surface contracts to the CPU vendor and the cryptographic primitives the platform relies on, replacing administrators, hypervisors, and host operating systems on the trusted side of the boundary.

References