Confidential Computing Concepts

Relevant source files

The following files were used as context for generating this wiki page:

• README.md
• attestation/attestation.go
• attestation/tdx.go
• attestation/sev.go
• attestation/cert.go
• examples/verifier/main.go

Tinfoil Verifier provides a portable remote-attestation framework designed to verify the integrity of enclave-backed services. By leveraging hardware-rooted trust, the system ensures that code is running on genuine, secure hardware (Intel TDX or AMD SEV-SNP) and that the environment has not been tampered with.

The project implements a hardware-rooted verification flow that binds the hardware identity to TLS connections, effectively creating a "secure tunnel" where the client can be certain of both the identity and the integrity of the remote server.

Sources: README.md:1-10, attestation/attestation.go:10-30

Remote Attestation Architecture

Remote attestation is the process by which a hardware platform proves its identity and software state to a remote party. In this project, this is achieved by fetching an attestation report from the hardware, which contains cryptographic measurements of the enclave's memory and configuration.

Supported Platforms

The project supports two primary Confidential Computing platforms:

• AMD SEV-SNP (Secure Nested Paging): Uses VCEK certificates and SNP report validation to ensure memory encryption and isolation.
• Intel TDX (Trust Domain Extensions): Validates TDX quotes and Trust Domain (TD) reports to ensure the integrity of the virtualized environment.

Sources: README.md:65-71, attestation/sev.go:133-140, attestation/tdx.go:175-185

Verification Flow

The following diagram illustrates the high-level remote attestation sequence:

The client fetches a report from the enclave, validates the signature against hardware-specific roots (AMD or Intel), and compares the reported measurements against known good values (reference measurements).

Sources: README.md:73-82, examples/verifier/main.go:80-110

Attestation Documents and Measurements

Central to the system is the Document and Measurement data structures, which encapsulate the hardware's state.

Measurement Types

Measurements are categorized by PredicateType to identify the hardware platform and version of the attestation logic:

Predicate Type	Platform	Description
https://tinfoil.sh/predicate/sev-snp-guest/v2	AMD SEV-SNP	Contains SNP measurement registers.
https://tinfoil.sh/predicate/tdx-guest/v2	Intel TDX	Contains MRTD and RTMR 0-3 registers.
https://tinfoil.sh/predicate/snp-tdx-multiplatform/v1	Generic	A source-code measurement that can be compared against both platforms.

Sources: attestation/attestation.go:21-30, attestation/attestation.go:215-225

Implementation of Comparison Logic

The Measurement.EqualsDisplay function handles the complex logic of comparing runtime measurements (what the hardware says) against source measurements (what is expected). For TDX, this involves checking the MRTD (Measurement of the Trust Domain) and various RTMRs (Runtime Measurement Registers).

// From attestation/attestation.go
if m.Type == SnpTdxMultiPlatformV1 {
    switch other.Type {
    case TdxGuestV2:
        actualRtmr1 := other.Registers[2] // 0 is MRTD, 1 is RTMR0
        actualRtmr2 := other.Registers[3]
        actualRtmr3 := other.Registers[4]
        // ... comparison logic ...
    }
}

Sources: attestation/attestation.go:94-130

Hardware-Rooted Trust (Intel TDX)

For Intel TDX, the system utilizes a series of collateral files (CRL, QE Identity, TCB Info) to verify the validity of the hardware's quote.

Collateral Management

The tdxGetter handles the retrieval of Intel's Provisioning Certification Service (PCS) collateral. This ensures that the hardware is up-to-date and not revoked.

The verification checks critical fields such as MinimumTeeTcbSvn (3.1.2) and TdAttributes to ensure the enclave environment meets security policies.

Sources: attestation/tdx.go:175-220, attestation/tdx.go:235-255

TLS Binding and Certificate Verification

A core security feature is binding the remote attestation to a TLS connection. This prevents "man-in-the-middle" attacks where a valid attestation from a secure enclave is presented by a malicious proxy.

SAN-based Verification

The project embeds the HPKE (Hybrid Public Key Encryption) public key and the attestation hash within the Subject Alternative Names (SANs) of the TLS certificate.

• HPKE Key: Encoded in SANs with the .hpke. prefix.
• Attestation Hash: Encoded in SANs with the .hatt. prefix.

The VerifyCertificate function extracts these values from the certificate and ensures they match the values computed during the attestation process.

Sources: attestation/cert.go:24-60, attestation/cert.go:76-85

Single-Request Bundled Verification

To simplify client implementation, the project supports "Bundled Verification" via Tinfoil Air Traffic Control (ATC).

Bundle Components

A Bundle aggregates all data required for verification into a single JSON structure, reducing the number of round-trips the client must perform.

Field	Description
EnclaveAttestationReport	The hardware report (SNP or TDX).
SigstoreBundle	Data for verifying code provenance.
VCEK	(AMD specific) The Versioned Chip Endorsement Key.
Digest	The SHA-256 digest of the expected code.

Sources: attestation/attestation.go:247-254, README.md:84-95

Summary

Confidential Computing in this project is implemented as a multi-layered verification system. It starts with hardware-rooted reports (Intel TDX or AMD SEV-SNP), progresses through software integrity checks using measurement registers, and culminates in a cryptographic binding between the hardware state and the TLS communication channel. This ensures that data is processed in a verifiable and isolated environment.

Sources: README.md:12-20, attestation/attestation.go:193-210