Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.turnkey.com/llms.txt

Use this file to discover all available pages before exploring further.

This page walks through the full lifecycle of a TVC deployment, from submitting your container image to verifying a signed response. It is intended for developers who want to understand the security guarantees at each step.

​
Deployment Setup

Deployments can be done through the Turnkey dashboard or the tvc CLI. To deploy, you provide Turnkey with:
  • Your container registry URL (any OCI-compliant registry: GHCR, Docker Hub, ECR, ACR, etc.)
  • The expected executable digest, the SHA256 hash of your binary (the pivot hash)
  • The binary path within the container image
  • Arguments and port configuration
You can verify the binary hash yourself at any time by pulling the container image, extracting the binary, and computing its SHA256 hash. Turnkey uses these inputs to generate a QOS manifest containing the pivot hash, arguments, ports, and expected PCR values. The manifest must be cryptographically signed by your configured Manifest Set operators before deployment proceeds. No deployment can happen without Manifest Set approval.

​
Enclave Boot

When the deployment runs, Turnkey’s infrastructure boots an AWS Nitro enclave from an EIF (Enclave Image File). The Nitro hypervisor measures the enclave image into Platform Configuration Registers (PCRs) as part of this process. These measurements are hardware-rooted and cannot be forged. See Claims and verification for how PCR values are used to verify a specific enclave. Immediately after boot, QOS generates an ephemeral key pair. This key is created fresh on every enclave boot and never leaves the enclave.

​
Binary Verification

In parallel with boot, your container image is pulled from the registry and the binary is extracted. QOS receives this binary and hashes it, then compares the hash against the pivot hash inside the manifest. If they match, the binary is accepted and execution continues. If they don’t match, boot fails. Your binary cannot run unless it exactly matches what Manifest Set operators approved in the manifest.

​
Attestation

QOS requests an attestation document from the Nitro Security Module (NSM), embedding the ephemeral public key and the manifest hash into the document. The NSM produces a document containing:
  • The PCR values (hardware measurements of the enclave image)
  • The ephemeral public key
  • The manifest hash
The NSM signs this document with its own hardware key. This signature cryptographically binds the manifest and the ephemeral key to the measured enclave, so an external verifier can confirm that a specific binary is running inside a specific enclave. See Boot Proofs for the full set of claims this enables and how to verify them.

​
Quorum Key Provisioning

After attestation, the enclave receives its Quorum Key, the long-lived key shared across all replicas of a deployment. See Quorum Deployments for a deeper look at the provisioning flow. For the first enclave boot, key provisioning requires N-of-M Share Set members to participate based on a configured threshold. For subsequent replicas (or when a replica is replaced), an already-running healthy enclave exports the quorum key encrypted to the new enclave’s ephemeral public key. Only the target enclave can decrypt it. This key forwarding mechanism means Share Set members don’t need to intervene for routine scaling or replica replacement.
Turnkey handles quorum key provisioning automatically for TVC deployments. Support for custom quorum keys is actively being developed.
Once provisioning is complete, the pivot process starts. A boot proof containing the NSM attestation document, the manifest envelope, and the ephemeral public key is posted to the boot proof database and is available for verification.

​
Runtime & App Proofs

Incoming requests are forwarded to your pivot application, which executes its logic and returns a result. Applications can choose how to sign their responses:
Signing approachWhen to use
Ephemeral keyFull verifiability. Proves the result came from a specific enclave instance running a specific binary.
Quorum keyAuthentication, encryption, or data that must persist across enclave instances and upgrades
No signatureRead-only or non-sensitive responses
The recommended approach for full verifiability is to sign with the ephemeral key. An app proof contains the signature scheme, the ephemeral public key, the payload, and a signature over the SHA256 of that payload. See App Proof structure for the full schema and a worked example.

​
Verifying the Full Chain

To independently verify that a result came from a specific, unmodified binary running inside a genuine Nitro enclave, a verifier needs four things:
  1. Source code that compiles to a binary whose SHA256 matches pivot hash within the manifest
  2. Manifest envelope confirming the pivot hash, expected PCR values, and Manifest Set signatures
  3. Boot proof containing the NSM-signed attestation document, whose PCRs match the manifest and which embeds the ephemeral public key and manifest hash
  4. App proof whose signing key matches the ephemeral key in the boot proof, confirming the result was produced inside that specific enclave instance
For step-by-step verification instructions, see Claims and verification. Turnkey has also published verification tooling in Rust, JavaScript, and Go.