Skip to main content

​
Prerequisites

This page assumes some familiarity with the different parts of the Tinfoil system and the goals associated with attestation and supply chain transparency verification. We recommend reading the technical overview first to familiarize yourself.

​
Backend infrastructure

The backend architecture is illustrated in Figure 1. All security-critical components are open source and available on GitHub. Tinfoil Attestation Architecture

Figure 1: Overview of Tinfoil’s backend infrastructure and attestation architecture.

For simplicity, we omit backend components that are not part of the security-critical path, such as billing and user account management. These are closed-source orchestration-layer components that do not need to be attested since they do not touch user requests.

​
The Secure Enclave Components

The secure enclave consists of the OVMF firmware that boots the confidential VM (CVM) image. The CVM serves the attestation and terminates the TLS connection from clients.

​
Confidential VM Image

A confidential VM (CVM) is a virtual machine whose memory is encrypted by the CPU so that the host operator (including the hypervisor and any privileged software) cannot read or tamper with its contents. This is the foundation of confidential computing. Tinfoil’s CVM image is based on Ubuntu with an AMD SEV-SNP compatible kernel, which enables the CPU’s hardware memory encryption and attestation capabilities. We chose to use Ubuntu because it provides broad driver and package support needed for GPU workloads. At runtime, the CVM runs a reverse proxy that terminates TLS and serves the attestation document, the user’s workload (e.g., an inference server), and any supporting services like model weight verification. All virtual disks are mounted read-only. The firmware, kernel, and initrd are measured into the attestation report at boot time, while read-only model weight volumes are verified separately with dm-verity and checked against the expected values from the Sigstore bundle during verification.

​
OVMF Firmware

When a confidential VM starts, the very first code that runs is its boot firmware. This firmware is essentially the “BIOS” of the confidential VM and initializes the hardware, sets up memory encryption, and hands off to the Linux kernel. The firmware is the first thing measured by the CPU for the attestation report. To ensure reproducibility, Tinfoil uses a pinned version of the OVMF firmware. Each build is attested to Sigstore and the exact firmware binary running in the enclave can be verified against the build log.

​
Supply Chain Security Architecture

Outside of the secure enclave, we have a release pipeline that provides supply chain security for all components that become part of the enclave. This starts with pinned releases of the firmware, CVM image, and model weights. The sha256 hash of each of these is configured inside a tinfoil-config.yml which is then committed to a public GitHub repo. A GitHub action runs to create a release consisting of the build and hardware measurements. These measurements are then committed to a public append-only transparency log.

​
Modelwrap - ensuring model weights are attested

One challenge we need to address in our supply chain security story is the problem of loading model weights into the secure enclave at runtime. We get around this by generating a read-only volume with the model weights and computing a cryptographic commitment to it that is pinned inside the configuration file. At runtime, the enclave loads the read-only model weights and rejects any disk that doesn’t correspond to the exact attested commitment. We built a utility we called modelwrap, which is used both to generate a pinned version of Hugging Face model weights and at runtime to verify that the pinned model-weight volume mounted in the enclave matches its attested commitment. You can read more about this in our technical blog post on the subject.

​
tinfoil-config.yml

The Tinfoil configuration file is a manifest specifying the model commitment (generated via modelwrap), container images, CVM version, and resource allocation. It is committed to a deployment repo and its SHA256 hash is embedded in the kernel command line, creating a cryptographic link between the config and the running enclave. This config file is used by the pri-build-action GitHub action to generate hardware measurements that get pinned to the transparency log.

​
pri-build-action

The pri-build-action is our GitHub Actions workflow that converts a tinfoil-config.yml into a deployment config. When a new release is tagged and pushed to the config repo, this workflow builds the enclave image and publishes a signed Sigstore bundle containing the expected measurements, linking the open source code to the attested binary. This bundle is signed with a Sigstore keyless certificate issued for the GitHub Actions workflow and committed to the Sigstore transparency log making it impossible for us to change the code without also changing the expected attestation measurements.

​
Hardware Attestation

Hardware attestation is the process by which the CPU and GPU produce cryptographic proof of what code is running inside the enclave. This proof is what clients verify, in tandem to the bundles committed to the transparency log at build time, before sending any data.

​
Boot sequence and CPU measurement

When a confidential VM starts, the CPU measures each stage of the boot process — hashing the code and configuration at each step — and records the results in a hardware-signed attestation report. Here is the sequence of what happens during boot:
  1. Firmware: The OVMF firmware initializes the VM. Because it is the very first code to execute, it is also the first thing the CPU measures and includes in the attestation report.
  2. Kernel: The OS kernel and initrd load from the read-only root filesystem. These are also measured by the CPU.
  3. Configuration verification: The boot process checks that the tinfoil-config.yml on disk matches the attested hash embedded in the kernel command line. This ensures the enclave is running the exact configuration that was committed to during the build.
  4. Model weight verification: Read-only model weight volumes are mounted and verified against their modelwrap commitments using dm-verity. dm-verity is a Linux kernel subsystem that intercepts every disk read and validates it against a Merkle tree root hash, ensuring that no block of data has been tampered with. See our blog post on proving model identity for a deeper explanation.
  5. Service startup: The reverse proxy and workload containers start using the configuration from the attested config.
The CVM is designed to be entirely stateless, meaning that all virtual disks are mounted read-only, and ephemeral data uses a ramdisk created at boot. There is no persistent state that could be modified between boots.

​
GPU verification

For GPU workloads, the boot process includes an additional step: it queries each NVIDIA GPU to verify it is running in confidential compute mode using NVIDIA’s local-gpu-verifier. This creates a chain of trust from the CPU to the GPU. If the CPU fails to verify the GPU’s attestation, it aborts the boot process and the enclave does not start. Because the GPU attestation is linked to the CPU attestation report, clients verifying the CPU attestation are also transitively verifying the GPU configuration.

​
Client-side verification

Before exchanging application data (e.g., chat completions) with an enclave, the Tinfoil SDK verifies the enclave’s identity and integrity. The SDK fetches the attestation document from the enclave, which includes signed runtime measurements, and verifies the certificate chain back to the CPU’s hardcoded root certificate (AMD). It then fetches the Sigstore bundle, verifies its signatures against Sigstore’s root trust anchor, and checks the measurement predicates to ensure the source code and runtime enclave measurements match. Finally, it opens a TLS connection and confirms the server’s public key matches the one in the attestation document, binding TLS to the attested key and guaranteeing that the connection terminates inside a verified enclave.

​
Attestation Proxies

The client-side verification process requires data from several external sources: the enclave’s attestation document, hardware manufacturer’s certificate chain, and the Sigstore bundle from GitHub. Fetching each of these directly can hit rate limits, add latency, and complicate client implementations. Tinfoil operates three caching proxies to address this. Importantly, none of these proxies are trusted — every piece of data they serve is independently verified by the client against hardcoded root certificates or Sigstore’s trust anchor. Attestation Bundle Proxy Tinfoil runs a proxy that returns everything the verifier needs in a single request: the enclave’s attestation report, the cert chain, the Sigstore bundle, and the enclave’s TLS certificate. This avoids multiple round-trips to different services during connection-time verification. The JavaScript SDK, for example, uses this proxy by default. This makes the actual verification code stateless — it’s just a utility that takes a Tinfoil attestation bundle and verifies everything. GitHub Proxy github-proxy.tinfoil.sh caches GitHub release data, including the Sigstore bundles published by the pri-build-action. The cached data is verified through Sigstore’s transparency log and cannot be forged without Sigstore’s signing keys. AMD KDS Proxy kds-proxy.tinfoil.sh caches AMD Key Distribution Service (KDS) certificates used to validate the CPU attestation. The root AMD certificate is embedded in the verifier code, so the proxy cannot forge certificates — full chain validation is always performed by the client.

​
Transport Security

Tinfoil uses two complementary mechanisms to ensure data is encrypted end-to-end to verified enclaves: TLS key binding and the Encrypted HTTP Body Protocol (EHBP).

​
TLS Key Binding

TLS key binding ensures all TLS sessions terminate inside a verified enclave, never on a non-enclave host. The enclave’s attestation includes an enclave-generated TLS public key tied to the measured runtime, and terminates TLS inside the enclave (inside the CVM) with a non-exportable private key that never leaves enclave memory. The client verifier compares the server’s TLS key to the attested key — if they differ, verification fails and no data is sent. This guarantees that only verified enclaves can decrypt traffic; intermediaries can forward TCP but cannot terminate or read plaintext.

​
Encrypted HTTP Body Protocol (EHBP)

In environments where TLS certificate pinning is not available (such as browsers), or where the connection needs to pass through an intermediate server for billing, authentication, or rate limiting, Tinfoil uses EHBP to encrypt HTTP request and response bodies end-to-end. The SDK fetches the enclave’s attested HPKE public key and encrypts all message bodies directly to that verified key using HPKE (RFC 9180). HTTP headers remain in the clear for routing, but the payload is only decryptable by the attested enclave. This provides the same data confidentiality guarantee as TLS key binding for request and response bodies, for clients that cannot pin certificates. A common pattern is to run a proxy server on your backend that adds your API key and handles user authentication, while EHBP ensures the proxy never sees the plaintext request or response bodies. See the proxy server guide for a complete walkthrough with code examples.

​
Chaining Enclaves

In some deployments, multiple enclaves work together to serve a single request. Each enclave in the chain verifies the next one before forwarding data, extending the same attestation guarantees across the entire pipeline. For example, in our inference API backend, verification is chained across two enclaves. The client SDK verifies the confidential model router, which runs in its own enclave. The router then verifies the target model enclave before forwarding the request. Data is encrypted end-to-end at each hop using attested keys, so neither the host nor the router can read plaintext outside of a verified enclave.