Proofs and Verification

TVC enclaves emit two kinds of cryptographic proofs that, taken together, let a third party verify that a specific response was produced by a specific piece of code running inside a specific enclave instance:

• A Boot Proof, generated once per enclave boot, that attests to the code and configuration running inside the enclave.
• An App Proof, generated by the running application, that signs over a structured payload describing some fact about a request or response.

The security model is: the Boot Proof binds an enclave’s Ephemeral Key to a specific QOS manifest and application binary, and the App Proof’s signature over its payload chains back to that Ephemeral Key. If both verify, the payload provably came from that exact code running in that exact enclave.

This page describes what each proof contains, how they relate, and the steps required to verify a response end-to-end. For the customer-facing summary of Turnkey Verified (the dashboard- and SDK-level feature built on top of these proofs), see Turnkey Verified.

Boot Proof

A Boot Proof is a bundle of artifacts that a verifier can use to establish what code an enclave is running. It contains:

• The AWS Nitro attestation document (DER-encoded COSE Sign1), which contains PCR measurements, the AWS certificate chain, the enclave’s Ephemeral public key (in the public_key field), and arbitrary user data.
• The QOS manifest and manifest envelope, which describe the application binary and arguments, the operator quorum, the quorum public key, and other deployment configuration. The AWS attestation document’s user_data is set to the digest of this manifest, which is what binds the two together.
• Operator approvals of the manifest.

Boot Proofs are produced from outside the enclave (everything in the bundle is observable from outside) and are published once per enclave boot. Verifiers fetch them through Turnkey’s public API — see Fetching proofs as a verifier.

App Proof

An App Proof is a signed, strictly-typed payload produced by an enclave application. It contains:

• A proof payload (JSON), which has a typed schema per proof type. Examples today include APP_PROOF_TYPE_ADDRESS_DERIVATION (a wallet address was derived from a specific path on a specific wallet) and APP_PROOF_TYPE_POLICY_OUTCOME (a policy decision evaluated to a specific outcome against specific organization data).
• A signature over the JSON payload bytes, produced by the enclave’s Ephemeral Key (P-256).
• The Ephemeral public key that produced the signature.
• The signature scheme identifier (currently SIGNATURE_SCHEME_EPHEMERAL_KEY_P256).

App Proofs are produced inside the enclave, because the enclave is the only place that has access to the Ephemeral private key. The private half of the Ephemeral key never leaves the enclave by design; only the public half is exposed (via the attestation document’s public_key field).

The App Proof embeds the Ephemeral public key it was signed with. The Boot Proof’s attestation document also pins that same Ephemeral public key (in public_key). A verifier links the two by matching the App Proof’s public key to a valid Boot Proof’s attested key — see Verification flow below.

Open-source reference verifier implementations, which also serve as a reference for the exact bytes that get signed, live in the Rust SDK and the TypeScript SDK.

Why the Ephemeral Key and not the Quorum Key

A reasonable question is: Turnkey enclaves already have a Quorum Key, which is the long-lived key associated with the application’s identity. Why don’t App Proofs use that?

The answer is a trust-boundary distinction.

The Quorum Key is not attested by AWS, because it cannot be. The Quorum Key is provisioned via Turnkey’s share-set protocol: the key is split into shares held by operators, and reconstructed inside an approved enclave when needed. There are layers of operational and cryptographic controls around this, but at the end of the day the share set is the root of trust — and the share set could collude to reconstruct the Quorum Key somewhere other than an approved enclave. AWS has no way to attest “this private key only exists inside this enclave” for the Quorum Key, because that statement isn’t true at the cryptographic layer.

The Ephemeral Key is attested by AWS. It is generated inside the enclave at boot and never leaves it. The Nitro attestation document signs over the QOS measurement (PCR0/PCR1/PCR2), the AWS account/role measurement (PCR3), the QOS manifest digest (user_data), and the Ephemeral public key (public_key) — all in a single signed document produced by the Nitro hypervisor. That binding is what gives the Ephemeral Key its property: it is unique to this specific enclave instance running this specific code. Neither the share set nor anyone else can collude to obtain that Ephemeral private key anywhere else.

This is the property that makes App Proofs meaningful. Because that Ephemeral Key only exists inside that specific enclave running that specific code, anything signed by that Ephemeral Key must have been produced by that enclave — and therefore by that exact code. An App Proof signature is, transitively, proof of what code generated the output.

Caveat on the trust boundary: AWS itself could in principle collude to sign a false attestation document. That’s a separate, well-understood trust assumption inherent to using AWS Nitro Enclaves, and it applies to any system that relies on Nitro attestation — not just Turnkey.

Verification flow

To verify a response that comes with an App Proof, a verifier needs both the App Proof and the Boot Proof that the App Proof’s Ephemeral Key was attested in. The full flow is five steps:

1. Verify the Boot Proof’s attestation document. Check the COSE Sign1 signature against the AWS Nitro root certificate. Confirm PCR3 matches Turnkey’s parent instance role and PCR0/PCR1/PCR2 match a known-good QOS measurement.
2. Verify the Boot Proof’s manifest. Parse the QOS manifest and check the application binary digest against a known-good value (see tkhq/core-enclaves). Validate operator approvals as required.
3. Verify that the Boot Proof’s manifest is bound to the attestation document. The attestation document’s user_data must equal the digest of the QOS manifest verified in step 2.
4. Verify that the App Proof’s Ephemeral public key matches the attestation document’s public_key field. This is what binds the App Proof to a specific, attested enclave instance.
5. Verify the App Proof signature. Standard P-256 signature verification over the JSON proofPayload bytes, using the Ephemeral public key.

If all five checks pass, the App Proof’s payload was produced inside a legitimate Nitro Enclave, in Turnkey’s AWS account, running a known-good QOS image and a known-good application binary, signed by an Ephemeral Key that only that specific enclave instance has ever had access to.

Once the proofs verify, the verifier interprets the typed payload — for example, an addressDerivationProof payload commits to a specific organization, wallet, derivation path, and address, so verifying the proof verifies that exact derivation happened in that exact enclave.

Fetching proofs as a verifier

An App Proof arrives as part of an enclave response — it is the response signature plus the typed payload. The Boot Proof needs to be fetched separately, keyed by the Ephemeral public key embedded in the App Proof.

Turnkey exposes public endpoints for this:

• get_boot_proof — fetch the Boot Proof for a specific Ephemeral public key. This is what a verifier will use after extracting the Ephemeral key from an App Proof.
• get_latest_boot_proof — fetch the most recent Boot Proof for a given enclave application name. Useful for sanity-checking what’s currently deployed.
• list_app_proofs_for_an_activity — fetch all App Proofs associated with an activity.

See also

• Turnkey Verified — the user-facing feature built on these proofs, including supported App Proof types and example payloads.
• Deployment Lifecycle — how an enclave gets from a container image to a running, attested instance.
• Whitepaper: Boot Proofs and App Proofs.