​

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.

​

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, an enclave does the following:

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 eachother.

​

Which mode should I use?

The only reason not to 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.

Tinfoil Chat for example, does not support connection-time verification and relies only on transparency for audit-time verification.

All production Tinfoil enclaves publish their attestation to CT, so attestations are auditable regardless of if you are using connection-time verification.