​
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 Inference Orchestrator Architecture

All model inference requests go through the confidential inference orchestrator, which securely routes requests to the appropriate model enclave based on the requested model parameter. This orchestrator architecture provides several key benefits:
  1. Request Routing: The orchestrator 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 orchestrator automatically load balances requests across available instances.
  3. Chain of Trust: Both the confidential inference orchestrator 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 orchestrator and enclaves use the same attestation framework:
  • Orchestrator Attestation: The confidential inference orchestrator 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 inference orchestrator 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 only reason to not rely on connection-time verification is in environments where the client cannot support it. JavaScript in a browser context, for example, doesn’t expose an API to inspect TLS connection information and therefore cannot rely on connection-time verification. This is why the Tinfoil Chat does not support connection-time verification and relies only on transparency for audit-time verification. To facilitate auditing of the TLS connection, we publish the certificate fingerprint in the Verification Center of the chat interface. Because all production Tinfoil certificates (both the confidential inference orchestrator and model enclaves) use public TLS, their attestations are recorded by TLS certificate transparency logs, so the entire inference pipeline is auditable regardless of if you are using connection-time verification.