feat(tee): seal the TRACE signing key to the gateway measurement (RFC P3)

[imran-siddique]

RFC section 5 P3, promoted ahead of the event log (P4) on 2026-08-01 because the event log is 0 bytes on every cloud vTPM we can provision while this is reachable today. This is the step that converts measurement into enforcement.

Why it matters

#432 now measures the gateway into a TPM_NT_EXTEND NV index and has the TPM certify the value either side of the extend, so a relying party can verify what code was running. But that is detection: a modified gateway still starts, still signs TRACE Claims, and is only caught if someone appraises the evidence afterwards.

Sealing closes that. If the TRACE signing key can only be unsealed under a policy that includes the measurement, a modified gateway cannot sign a claim at all. The failure becomes structural rather than something a verifier has to notice.

docs/spec/attestation.md section 4.2 already describes this as Phase 2 design. It is not implemented, and section 4.5 of the RFC says so explicitly so a reader does not assume otherwise.

Shape of the work

1. Create the signing key as a sealed TPM object (TPM2_Create under a parent) rather than the in-process SigningKey() generated at startup step 3.
2. Bind the unseal policy to the measurement. TPM2_PolicyNV against the gateway measurement index is the direct route, and it composes with TPM2_PolicyPCR over non-resettable SRTM PCRs if we want boot state in the policy too.
3. Handle the ordering problem. The current sequence generates the signing key before the measurement, because the certify calls commit a nonce derived from that key (feat(tee): certify the gateway measurement so it is signed evidence (#432) #459). Sealing to the measurement inverts that dependency: the key cannot exist until the index holds the right value, but the index's certify commits a nonce from the key. This needs resolving, and it is the main design question here rather than an implementation detail. Options include deriving the certify nonce from something other than the signing key, or sealing a long-lived key and using a separate per-session key for the nonce.
4. Decide the reseal story. The measurement changes on every legitimate upgrade, so the sealed blob must be re-created on deploy. A gateway that cannot unseal after a legitimate upgrade is an outage, so this needs an explicit operational path, not just a happy-path implementation.

Constraints already established

• The measurement index is tamper-evident, not tamper-proof: TPM2_NV_UndefineSpace with owner authorization erases it, and guest root holds owner auth on Azure. Sealing to it inherits that ceiling. An adversary who can undefine the index can also destroy the seal, which is a denial of service rather than a forgery, but it should be stated rather than discovered.
• Only the platform attestation key has provenance, and on some Azure hosts even its certificate is not chainable (security(tee): source and pin the Global Virtual TPM CA - 03 root, or Azure provenance is host-dependent #453). Sealing does not depend on the chain, so this is not blocking, but the overall assurance claim still is.

Definition of done

Implemented, unit tested, and validated on real hardware before the claim is made anywhere. The #460 run found two defects in code that had merged with green CI, so a sealing implementation that has never unsealed on a real TPM should not be described as working. docs/testing/hardware-validation.md is where the run gets recorded.

Refs #432, #439 (RFC section 5 P3 and section 4.5), #453.