docs: real-hardware runs (vTPM quote, attested peer, cross-TEE Azure SNP to GCP TDX) - #68
Merged
Conversation
Captured a genuine TPM 2.0 quote from an Azure Trusted Launch VM (vTPM, secure boot, PCRs 0-7 under a fresh nonce). The verifier's parse, magic and type checks, qualifying-data binding, PCR digest and AK RSA PKCS#1 v1.5 SHA-256 signature all hold on it, and a flipped bit in the attest blob is rejected. Env-gated on CA2A_TPM_FIXTURE_DIR; the capture is not committed. What this does not close, stated in docs/hardware-validation.md rather than glossed: the AK certificate chain. Azure's pre-provisioned AK certificate certifies a different key than an in-guest tpm2_createak AK, so it does not verify against this quote, and it carries no AIA extension, so its issuing intermediate is not fetchable from it. Chain-to-vendor-root stays unexercised for TPM, which is why this verifier takes caller-supplied roots rather than pinning one. This is also a Hyper-V vTPM, not a discrete TPM chip. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…rdware Drove ca2a_runtime.attestation's verifier seam off a live SEV-SNP quote on an Azure DC2ads_v5 confidential VM. verify_offer returned assurance="hardware" rather than "none" for the first time, a payload was sealed to a channel key a hardware-verified measurement vouches for and opened inside the enclave, and both a measurement mismatch and a stale nonce were rejected. Azure SEV-SNP is paravisor-mediated, so the binding is one hop longer than bare-metal: the caller's nonce rides in the AK-signed TPM quote, the paravisor binds that AK into the SNP report's REPORT_DATA, and the report chains VCEK to ASK to ARK-Milan against AMD KDS. docs/hardware-validation.md spells that out. What this does not close is said in the same breath, in LIMITATIONS and the ROADMAP: the run had one attested peer with the caller on the same host, so cA2A is still not demonstrated attested across trust domains. That needs two independently operated attested peers. Software mode also remains the default for the reference transport; the hardware path is a validated capability, not the shipped default. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
An AMD SEV-SNP peer on Azure called an Intel TDX peer on GCP: different clouds, different operators, unrelated attestation formats. The caller appraised the callee's genuine 8KB TDX quote against the pinned Intel SGX Root CA, confirmed the quote's REPORTDATA bound the callee's channel key under a nonce the caller chose, and only then sealed a delegated task. The TDX enclave opened it, enforced a scope narrowed by a chain it did not issue, allowed tool:search, and refused tool:purchase with a denial record carrying the requested capability, the effective scope and the reason back across the trust boundary. A stale nonce was rejected. That is the four primitives holding at once across a real trust boundary, which is what the cross-operator claim rested on. Two honest limits are recorded with it: the attestation was one-directional, so the callee never appraised the caller, and both peers ran from one operator's harness. Mutual simultaneous attestation is the remaining step. The committed cross-operator example stays software-attested, because real evidence embeds per-CPU identifiers and cannot be shipped as a fixture. Also carries the two commits orphaned when #61 merged: the real Azure vTPM quote test and the assurance="hardware" live-peer run. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three hardware runs, plus the two commits orphaned when #61 merged ahead of them.
Cross-operator, cross-TEE: Azure SEV-SNP calling GCP TDX
An AMD SEV-SNP peer on Azure (
DC2ads_v5, eastus) called an Intel TDX peer on GCP (c3-standard-4, us-central1-a). Different clouds, different operators, unrelated attestation formats: an AMD VCEK chain on one side, an Intel PCK chain on the other.REPORTDATA = sha256(channel_pub || nonce)matchedtool:search[task:read, tool:search]tool:purchaseSCOPE_NOT_PERMITTEDAll four primitives held at once across a real trust boundary: a scope narrowed by a chain the callee did not issue, attestation on real hardware gating the seal, confidentiality to a measured guest, and provenance for both the allow and the deny.
Also included
verify_offerreturnedassurance="hardware"for the first time, off a real SEV-SNP quote on an Azure CVM, with measurement mismatch and stale nonce both rejected.What these runs do not establish, stated in the docs
examples/cross-operator-delegationstays software-attested. Real evidence embeds per-CPU identifiers, so it cannot ship as a fixture; the runs are recorded indocs/hardware-validation.mdinstead.Test plan
pytest tests/— 206 passed; 6 pre-existingtest_cedar.pyfailures unrelated to this change (local cedarpy binding; they pass in CI)mypy src/— clean🤖 Generated with Claude Code