How verification works in Tinfoil

​

Overview

This page explains the basics of how Tinfoil provides verifiable privacy on each connection. Tinfoil uses confidential computing enabled by secure hardware enclaves to create a verifiably private runtime environment in the cloud. The hardware measures and attests the code running in the enclave and we connect these measurements to open source code using transparency logs to ensure end-to-end supply chain security. To make it easier to understand the different components involved, we must first cover the three main parts that make up the Tinfoil system. We have:

• a trusted client that runs one of the Tinfoil SDKs and makes requests,
• an untrusted host machine operated by Tinfoil, and
• a secure hardware enclave that runs a server in isolation from the host.

Client requests get sent using the Tinfoil SDK to the server running in the enclave. Before sending any data, the SDK automatically verifies that:

1. The enclave server is running code that is auditable and immutable
2. The enclave server computation is isolated from the host operator
3. The client request data is end-to-end encrypted to the enclave (only the enclave can decrypt it)

​

Example: Private Inference

To provide a concrete example, consider our Private Inference service. Simplifying slightly, we have an enclave with an AI model loaded inside of it. This enclave is running an open-source inference server (we use vLLM) that serves the model and exposes the /v1/chat/completions API endpoint. A client sends encrypted requests to this endpoint. The enclave decrypts these requests (only the enclave has the decryption key) and forwards them to the inference server running inside. The response is then encrypted and sent back to the client.

​

The problem of code transparency and confidentiality

How can the client be convinced that the enclave is running vLLM as the inference server and not some other (potentially evil) code? Additionally, how can the client verify the end-to-end encryption is enforced to the enclave and isn’t man-in-the-middled by the host? You can easily imagine a scenario where the host pretends to be the enclave and decrypts the clients request, violating confidentiality. We answer these questions in two parts.

​

Part I: Verifying code transparency with remote attestation

The first thing the client needs to be able to do is verify that the enclave is configured correctly and running the expected code. This is achieved with remote attestation. The hardware manufacturer provides a root of trust which is used to prove what’s running its own hardware using a signing key embedded at manufacture time. In a nutshell, the CPU comes with a secret key fused into it by the manufacturer (e.g., Intel or AMD). This key is used to sign the initial configuration and state of the CPU and memory at boot time. The host cannot access this signing key and extraction of the key is assumed impossible. At boot time, the hardware measures the initial state, generating a signed attestation report of the exact launch configuration, such as the firmware, kernel, security parameters, and the application binary running in the enclave. The attestation report can be seen as a cryptographic fingerprint of this entire launch configuration. If the same configuration is loaded twice, the fingerprints match. However, if any component differs (e.g., a firmware change, a modified kernel, or a different binary) then the fingerprints won’t match. This gets us part of the way towards full code transparency. The missing link is connecting the fingerprint to human-readable code that can be inspected for correctness and audited for security.

​

Linking fingerprints to code

All the code running inside the enclave is published to our GitHub and made open source. In theory, you could rebuild the binary and derive the corresponding expected cryptographic measurements or “fingerprint” yourself. Upon connection, if the fingerprint you derived matches the one presented by the secure enclave through remote attestation, then you can be convinced that the code running in the enclave was built from the open-source code published on our GitHub repo. However, rebuilding is expensive: you need to download the code, build it, and derive the expected measurements before you can compare fingerprints. That is fine for an occasional audit but too slow to run on every connection.

​

Leveraging transparency logs

Instead we use GitHub CI to build the byte-for-byte reproducible binary, derive and publish the expected measurements to an immutable transparency log (we use Sigstore, managed by the Linux Foundation). The log independently attests that GitHub produced the “ground truth” fingerprint from isolated GitHub workers, and anyone can compare it to the one received from the Tinfoil enclave. The transparency log proves which binary was built; it does not by itself prove that the binary matches the published source. To close that gap, the CVM image is built reproducibly, so an auditor can rebuild it and confirm the logged measurement is the measurement of the public code. See CVM image: TCB and reproducible builds.

​

Pinning the expected workload

The Go V3 verifier and Tinfoil CLI support beta workload release pinning. They accept a repository reference that specifies which workload releases you trust: The digest is the SHA-256 of the deployment artifact authenticated by the release’s provenance statement, written as 64 lowercase hexadecimal characters. Choose the tag and digest from the release you intend to trust. A digest pin fixes the artifact’s contents as well as requiring the expected repository identity. A repository reference without a tag accepts currently witnessed releases from that repository; it does not require the latest GitHub release. Every form retains the normal hardware, provenance, and freshness checks. Code and platform freshness witnesses have a maximum age of seven days by default. Use a workload pin to control which code you accept. A TLS or SSH key pin then binds your connection to a key endorsed by that verified workload. An enclave reboot can change its connection keys while the workload release stays the same. See CLI release pinning and Attested SSH.

​

Part II: Providing end-to-end encryption

The second problem is ensuring that the connection from the client is encrypted directly to the enclave. How can the client verify that the public key it is encrypting all the requests with was generated by the enclave and not the host? This requires tying the public key to the signed attestation report, proving it was generated by the enclave itself. At boot time, the enclave generates an encryption key pair, consisting of a public key and a secret key. The secret key is stored in the enclaves encrypted memory while the public key is made part of the attestation report. When the client connects to the enclave, all data sent over that connection is encrypted using the enclave’s attested public key. We additionally hash the attestation report ad store the hash in the certificate issued to the enclave. We do this to bind the attestation report to a *.tinfoil.sh domain and prevent any third party enclave from cosplaying as a Tinfoil controlled enclave.

​

How our SDKs automatically verify everything

Our SDKs are all open-source and run all verification logic client side. We do not use any proprietary or third party attestation services to verify attestation reports since doing so results in circular security and defeats the point of doing any verification in the first place. On each connection, our SDKs automatically fetch the expected enclave measurements from GitHub and Sigstore and then proceed to verify the enclave attestation report. The whole client-side verification proceeds by first assembling the necessary bundles, validating the configuration of the enclave, and verifying the cryptographic signatures. First, the SDK verifies the code’s Sigstore bundle against the expected repository and any release pin. Second, it obtains the attestation report generated by the remote enclave. In our SDKs, these values are assembled and provided by Tinfoil to minimize the number of requests made to to GitHub, Sigstore, and the enclave. Proxying and caching this verification material on Tinfoil servers does not harm security because each component is signed independently by Sigstore and the hardware manufacturer. Once all the verification material is assembled, the SDK compares the expected Sigstore-provided measurements to the enclave-attestation measurements, if these don’t match, the SDK throws an error and stops all connections from being established. On the other hand, if the measurements match, then the client creates an encrypted connection to the enclave using the public key from the attestation report.

​

Chaining enclaves

The process described above is essentially what happens when you connect to inference.tinfoil.sh using one of our SDKs and do inference requests. However, in our production deployment, we use multiple enclaves to serve the same model (this allows us to load balance requests) and additionally, for convenience, we need a model router server. Without a model router, we’d need to have all models running on the same machine associated with inference.tinfoil.sh which is not reasonable to do in production.
The model router is responsible for proxying requests to the right enclave. The solution is to chain enclaves. The router runs inside its own enclave. The client-side SDKs verify the router enclave and ensure the transparency of the router code. The router server then does the same verification for each enclave it routes to. Similarly, all data from the router to the inference server is encrypted with an attested key, ensuring that the whole pipeline from client to model keeps data encrypted from the point of view of the host. By chaining the attestations, we get end-to-end code transparency and confidentiality, even though the client-side SDKs only need to verify the first enclave in this chain.

Figure 1: Simple view of model router and inference attestation.

​

In-band vs. out-of-band verification

The verification described above is connection-time (in-band) verification: the client verifies the enclave’s attestation before exchanging any data. This is what our SDKs do automatically on every connection. Tinfoil records the evidence needed for audit-time (out-of-band) verification in append-only transparency logs. Tinfoil does not provide a supported tool for querying these records and reconstructing the verification, so use an SDK’s connection-time verification for real-time guarantees.

​

Attestation evidence in certificate transparency

Audit-time verification relies on embedding attestation evidence into TLS certificates, which are then recorded in public certificate transparency (CT) logs. This serves two purposes: (1) it creates a public audit trail of every enclave boot, and (2) it binds the attestation to a *.tinfoil.sh domain, preventing a third-party enclave from impersonating a Tinfoil-controlled enclave. At boot time, each enclave generates a fresh ECDSA key pair for TLS and an HPKE key pair for application-layer encryption (used by EHBP). It then requests a CPU attestation report that covers both the TLS key fingerprint and the HPKE public key, cryptographically binding them to the measured enclave state. The attestation report is hashed and embedded in the Subject Alternative Name (SAN) field of a standard x509 TLS certificate. To obtain this certificate, the enclave registers an ACME identity and submits a certificate signing request to a public certificate authority, including the attestation-bearing SAN extension. The CA issues the certificate, which is automatically recorded in public CT logs. The resulting certificate ties together the enclave’s TLS and HPKE public keys, its CPU attestation report, and its *.tinfoil.sh domain into a single publicly logged artifact.