docs: explain app proofs and boot proofs

docs.json

@@ -264,7 +264,8 @@
                 "pages": [
                   "products/verifiable-cloud/overview",
                   "products/verifiable-cloud/lifecycle",
-                  "products/verifiable-cloud/onboarding"
+                  "products/verifiable-cloud/onboarding",
+                  "products/verifiable-cloud/proofs-and-verification"
                 ]
               }
             ]

products/verifiable-cloud/proofs-and-verification.mdx

@@ -0,0 +1,81 @@
+---
+title: "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](/security/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](#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](#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](https://github.com/tkhq/rust-sdk/tree/main/proofs) and the [TypeScript SDK](https://github.com/tkhq/sdk/tree/main/packages/crypto/src/proof.ts).
+
+## 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`](https://github.com/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`](/api-reference/queries/get-a-specific-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`](/api-reference/queries/get-the-latest-boot-proof-for-an-app) — 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`](/api-reference/queries/list-app-proofs-for-an-activity) — fetch all App Proofs associated with an activity.
+
+## See also
+
+- [Turnkey Verified](/security/turnkey-verified) — the user-facing feature built on these proofs, including supported App Proof types and example payloads.
+- [Deployment Lifecycle](/products/verifiable-cloud/lifecycle) — how an enclave gets from a container image to a running, attested instance.
+- [Whitepaper: Boot Proofs and App Proofs](https://whitepaper.turnkey.com/foundations#boot-proofs-and-app-proofs).

security/turnkey-verified.mdx

@@ -8,6 +8,8 @@ As outlined in our [Whitepaper](https://whitepaper.turnkey.com/foundations#boot-
 
 For the first time we're exposing proofs produced by our TEEs to the outside world. Turnkey's infrastructure produces two types of proofs: **Boot Proofs** and **App Proofs**.
 
+For a deeper architectural walkthrough — including why App Proofs are signed by the enclave's Ephemeral Key rather than the Quorum Key, and the end-to-end verification flow — see [TVC: Proofs and Verification](/products/verifiable-cloud/proofs-and-verification).
+
 ### Boot Proofs
 
 A Boot Proof is a proof that a particular AWS Nitro Enclave has booted with a particular configuration. A Boot Proof contains: