Security Model
Relevant source files
The following files were used as context for generating this wiki page:
The security model of Tinfoil Verifier is centered around hardware-rooted remote attestation and cryptographic binding of identities. It ensures that a client is communicating with a specific, unmodified piece of code running inside a Trusted Execution Environment (TEE), such as AMD SEV-SNP or Intel TDX. By verifying hardware-generated evidence and comparing it against known-good "Ground Truth," the system establishes a secure channel where the TLS connection is pinned to the enclave's unique hardware identity.
The model operates on a zero-trust principle regarding the network and the host OS, relying instead on the TEE's isolation and the integrity of the signature chains provided by hardware vendors (AMD/Intel) and provenance systems (Sigstore).
Sources: README.md:9-16, client/client.go:142-160
Core Components and Verification Layers
The security architecture is divided into three distinct layers of verification: Hardware Integrity, Code Provenance, and Connection Binding.
1. Hardware-Rooted Attestation
The system verifies that the runtime environment is a genuine TEE. This is achieved by validating the signature chain of the attestation report back to the hardware vendor's root CA.
- AMD SEV-SNP: Validates VCEK certificates and SNP reports. It uses the Genoa certificate chain to verify the authenticity of the hardware report.
- Intel TDX: Validates TDX quotes and TD reports. It relies on Intel's Provisioning Certification Service (PCS) collateral, including QE Identity, TCB Info, and PCK CRLs.
Sources: README.md:104-110, attestation/sev.go:49-106, attestation/tdx.go:176-218
2. Code Provenance (Sigstore Integration)
To ensure the enclave is running the correct software, the system fetches reference measurements from Sigstore. This process verifies the code's digest and its association with a specific GitHub repository, preventing the execution of unauthorized or malicious binaries.
Sources: README.md:14-15, client/client.go:145-165
3. TLS Pinning and HPKE Binding
Security is maintained during the communication phase by pinning the TLS session to a fingerprint derived from the enclave's hardware report. The enclave includes its TLS public key and an HPKE public key in the "Report Data" section of the attestation document, creating a cryptographic bond between the hardware identity and the network session.
Sources: README.md:12-13, attestation/attestation.go:94-101, client/client.go:217-230
Verification Flow
The following diagram illustrates the sequence of operations required to establish a secure, verified connection to an enclave.
Data Structures and Measurements
Verification relies on comparing various "Registers" or measurement types depending on the platform and version.
Measurement Types
| Type | Description | File Reference |
|---|---|---|
https://tinfoil.sh/predicate/sev-snp-guest/v2 | SEV-SNP runtime measurement. | attestation/attestation.go:24 |
https://tinfoil.sh/predicate/tdx-guest/v2 | Intel TDX runtime measurement (MRTD + RTMRs). | attestation/attestation.go:25 |
https://tinfoil.sh/predicate/snp-tdx-multiplatform/v1 | Combined source measurement for cross-platform matching. | attestation/attestation.go:27 |
Measurement Registers
| Platform | Registers Tracked | Description |
|---|---|---|
| AMD SEV-SNP | Measurement | SHA-384 of the guest launch state. |
| Intel TDX | MRTD, RTMR0-3 | Build-time and runtime measurements of the Trust Domain. |
Sources: attestation/attestation.go:23-40, attestation/tdx.go:207-215, attestation/sev.go:142-148
Trust Roots
The system maintains embedded trust roots to prevent man-in-the-middle attacks during the verification process itself.
- Sigstore Trusted Root: A JSON file containing Rekor public keys and Fulcio certificate authorities used to verify software provenance.
- Intel SGX Root CA: Embedded PEM certificate used to verify the Intel TDX collateral chain.
- AMD Genoa Cert Chain: Embedded chain for verifying SEV-SNP VCEK certificates.
Sources: client/trusted_root.json:1-120, attestation/tdx.go:23-25, attestation/sev.go:23-25
Single-Request Verification (Bundled Verification)
For environments with restricted network access or performance requirements (like WASM/Browsers), the security model supports "Bundled Verification." This flow utilizes Tinfoil ATC (Air Traffic Control) to aggregate all necessary proofs into a single bundle.
The client still performs the final cryptographic validation of the bundle locally using its embedded trust roots; it simply offloads the fetching of collateral to the ATC service.
Sources: README.md:123-146, attestation/attestation.go:226-233, client/client.go:233-277
Conclusion
The Tinfoil Verifier security model ensures end-to-end integrity by strictly coupling the network identity of a service to its physical hardware state and software provenance. By validating Intel TDX and AMD SEV-SNP reports against vendor trust roots and comparing them to Sigstore-verified code measurements, the system provides strong guarantees that sensitive data is only ever processed by authorized code within a secure enclave.
Sources: README.md:9-16, client/client.go:142-210