Skip to main content

​
Verification Types

Tinfoil implements two distinct verification approaches with their own set of security assumptions and tradeoffs.
  1. Clients may verify at connection time by checking security proofs before proceeding with exchanging sensitive data, AND/OR:
  2. Auditors may verify an enclave out of band, using material committed to an append-only immutable log by an enclave.

​
Confidential Model Router Architecture

All model inference requests go through the confidential model router, which securely routes requests to the appropriate model enclave based on the requested model parameter. This router architecture provides several key benefits:
  1. Request Routing: The router examines incoming requests to determine the target model (e.g., from the model parameter in chat completions, or special handling for audio/document processing endpoints) and routes the request to the correct enclave.
  2. Load Balancing: Multiple enclaves can serve the same model, and the router automatically load balances requests across available instances.
  3. Chain of Trust: Both the confidential model router and the model enclaves run the same tfshim framework, creating a consistent chain of trust throughout the entire inference pipeline.

​
Inference Chain of Trust

The chain of trust is established because both the router and enclaves use the same attestation framework:
  • Router Attestation: The confidential model router runs the shim and generates its own attestation, proving it’s running unmodified code in a secure enclave
  • Inference Enclave Attestation: Each model enclave also runs the shim and generates CPU attestations for their inference workloads.
Since both components use the same underlying attestation technology, clients can verify the entire pipeline from the initial request through to the final model inference. This means that not only is the model inference happening in a verified enclave, but the routing and load balancing logic is also verifiably running the expected open-source code in a secure environment.

​
Connection Time Verification

Connection time verification (aka in-band verification) occurs when a client checks the integrity of a service before exchanging application data. All of our client SDKs support this mode when running in an environment that supports it.

​
Audit Time Verification

Audit time verification involves collecting attestation evidence out of band of an enclave connection and verifying it at a later time. This approach does not ensure in-band verification of the connection but rather relies on a verifiable audit trail that ensures Tinfoil or cloud providers can’t secretly tamper with the service without leaving a trace. All enclaves support audit time verification via attestation transparency.

​
Audit time verification through attestation transparency

Tinfoil implements audit time verification through attestation transparency. At boot time, both the confidential model router and each model enclave perform the following attestation process:
  1. Generate a user identity for ACME registration
  2. Generate an ECDSA key for the TLS certificate
  3. Request a CPU attestation over the ECDSA public key
  4. Serialize the CPU attestation into a format that fits in the SAN field of an x509 TLS certificate
  5. Order a TLS certificate from a public CA using the enclave-specific ACME user and ECDSA key, embedding the CPU attestation into the SAN field
These TLS certificates are covered by certificate transparency, which means any connection tampering on the public Internet is detectable at audit time. The attestation format can be decoded with our tfshim utility. Attestation transparency provides stronger security than standard HTTPS by creating an immutable audit trail in CT logs, where both valid and malicious certificates would otherwise be indistinguishable from each other.

​
Which mode should I use?

The verification mode depends on your environment’s capabilities: Native applications (Go, Python, Swift, etc.): Use connection-time verification via our SDKs. These environments can inspect TLS certificate information and verify attestations before exchanging sensitive data. Browser applications: Browsers don’t expose APIs to inspect TLS connection information, so connection-time TLS verification isn’t possible. However, browsers can use the Encrypted HTTP Body Protocol (EHBP) for application-layer encryption. EHBP encrypts request and response bodies directly to the enclave’s attested HPKE public key, providing end-to-end encryption without relying on TLS inspection. Tinfoil Chat uses EHBP to encrypt all prompts and completions end-to-end to the verified enclave. The browser fetches the enclave’s attested public key and encrypts all request bodies using that key—your data is encrypted before it leaves the browser and can only be decrypted inside the attested enclave. For additional assurance, all production Tinfoil certificates (both the confidential model router and model enclaves) are recorded in TLS certificate transparency logs, making the entire inference pipeline auditable.