fix(verify): authenticate TPM quotes and let evidence reach the verifier (#370)

[zohebk8s]

Contributes to #370, the TPM half of the residual scope. Does not close it; see Not covered.

Why

A TPM quote was unauthenticated. The tpm2 branch of verify_trace_claim called only verify_tpm_measurement, which takes no signature parameter. verify_tpm_quote_chained already existed and was tested, but nothing in the production path called it.

A/B on byte-identical input, only verify.py and tpm.py differing:

forged TPMS_ATTEST: correct magic, matching qualifying_data, no signature, no chain
  before:  hardware_attestation in verified_fields = True
  after :  hardware_attestation in verified_fields = False

VERIFIED is gated on hardware_attestation not being unverified, so this is what enforces the issue's "status must not claim hardware-backed verification". Before this change the forgery was held below VERIFIED only by an unrelated failure, not by any check of the evidence.

Evidence also could not reach the verifier. RuntimeInfo in agentrust-trace is extra="forbid", so a claim carrying raw_evidence / quote_signature / cert_chain under trace.runtime was CLAIM_MALFORMED before the platform branch ran.

Both halves land together deliberately. Transport on its own would remove the CLAIM_MALFORMED that was incidentally masking the hole, turning a reporting bug into acceptance of a forged attestation.

What

Verifier. New verify_ak_ek_chain() in cmcp_verify/tpm.py, mirroring verify_vcek_chain(). trusted_tpm_ca_pem threaded through verify_trace_claim alongside trusted_ark_pem, at the sites named in the issue. Signature verified with the AK pub taken from the chain leaf. Supplied-but-invalid material is fatal (HARDWARE_ATTESTATION_FAILED); absent material degrades to unverified, as SNP does.

Transport. Signed evidence travels as gateway.attestation_evidence. GatewayAddenda is cmcp's own model, documented for fields outside the canonical TRACE spec, so no upstream release is needed. trace.runtime is still read as a fallback for older claims.

base64. The gateway wrote base64url unpadded, the verifier used standard b64decode, so the two halves could not have interoperated. The reader now accepts both. Nothing caught this because no test carried evidence through both sides.

A claim built through the claim builder, with evidence populated the way the gateway populates it, now reaches status: verified with failure_reason: None.

Decisions worth reviewing

Back-compatibility is broken in one direction. Measured both:

new verifier + old claim (no evidence)  ->  OK, fields optional, trace.runtime fallback
old verifier + new claim (evidence)     ->  CLAIM_MALFORMED: gateway.attestation_evidence

This is not caused by the choice of gateway. GatewayAddenda and RuntimeClaim are both extra="forbid", so any additive field anywhere in the claim is rejected by a verifier built before it, and verify_trace_claim never reads cmcp_version, so there is no negotiation path. "Evidence travels with the claim" and "old verifiers keep working" cannot both hold under the current models. Options are laid out in the issue comment; this PR implements the first, minus the version bump, which is not mine to decide.

AK->EK is not attempted. An EK is a restricted decryption key: it cannot sign, cannot issue an AK certificate, and cannot appear in the AK's issuance path. verify_cert_chain rejects the shape. Only EK->manufacturer-CA is a certificate path, implemented as a separately supplied chain. This matches the #431 pivot to the platform-certified AK at 0x81000003.

EK identification needs the EKU and ca=False. The TCG EK EKU 2.23.133.8.1 appears on Azure's issuing CAs (Azure Cloud Virtual TPM CA - 11, ... CA 2025), where it means "may issue EK certificates". Matching on the EKU alone credited ek_cert_chain for a chain containing no EK. Regression test included.

_cert_signed_by no longer exists. #447 replaced it with agent_manifest.verify_cert_chain, so this mirrors verify_vcek_chain() rather than reviving a deleted helper.

verify_tpm_quote_chained is left uncalled. The EK chain is a separate path and the links need naming individually, so the wiring uses verify_ak_ek_chain plus verify_quote_signature. Happy to collapse the two into one entry point if preferred.

Not covered

• The producer still does not capture an EK certificate.
• SEV-SNP has the same transport defect: verify_sev_snp_measurement reads cert_chain from trace.runtime, which RuntimeInfo forbids, so the VCEK verification merged in fix(verify): verify SNP report signature + VCEK chain (cmcp#370) #386 does not engage for a schema-valid claim either. Not migrated here since it touches merged code. Worth its own issue.
• Manufacturer-root pinning is security(tee): source and pin the Global Virtual TPM CA - 03 root, or Azure provenance is host-dependent #453.
• SessionManager.close_session() is not driven end to end with real evidence bytes. Both sides of that seam are unit tested; the existing session tests use mocks.

The first three are recorded in LIMITATIONS.md.

Tests

Mirrors test_snp_signature_verify.py: synthetic chains plus a signed attest, exercised valid / tampered / wrong-root / missing-chain, plus an end-to-end claim through the producer path.

full suite   1041 passed, 22 skipped   (baseline 1020, 22 on main)
added           21 tests, all new; no existing test changed behaviour
ruff         All checks passed
mypy         no issues, 16 source files
bandit       no findings

[github-actions]

🟡 Contributor Check: MEDIUM

Check	Result
Profile	MEDIUM
Credential	LOW
Overall	MEDIUM

Automated check by AgenTrust Contributor Check.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 84.09091% with 21 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/cmcp_verify/tpm.py	69.64%	17 Missing ⚠️
src/cmcp_verify/verify.py	93.10%	4 Missing ⚠️

📢 Thoughts on this report? Let us know!

[imran-siddique]

Reviewed the diff and the reasoning. This closes a real hole: the tpm2 branch called only verify_tpm_measurement, which takes no signature, so a forged TPMS_ATTEST with correct magic and matching qualifying_data reached hardware_attestation verified. The A/B in the description is the right way to demonstrate that.

What I checked and agree with:

• Fail-closed shape matches the SNP path. Absent material degrades to unverified, supplied-but-invalid is fatal with HARDWARE_ATTESTATION_FAILED, and hardware_attestation is only credited when both the measurement and the chain check out.
• ek_cert_chain requiring the TCG EKU and ca=False is correct and non-obvious. Azure carries 2.23.133.8.1 on its issuing CAs, so EKU-only matching would have reported ek_cert_chain verified for a chain holding no EK. Good that there is a regression test on it.
• Not attempting AK to EK as a certificate path is right. An EK is a restricted decryption key and cannot appear in the AK issuance path. Credential activation is the real binding and is correctly left out of scope.
• Carrying evidence in gateway.attestation_evidence rather than trace.runtime is the correct call given RuntimeInfo is extra="forbid" upstream.
• The base64 mismatch catch is a good find. The gateway wrote base64url unpadded while the verifier used standard b64decode, so the two halves could never have interoperated.

Two non-blocking notes:

1. _decode_evidence returns None on undecodable input, so corrupt base64 in quote_signature is classified as absent rather than supplied-but-invalid. That takes the non-fatal path, which is inconsistent with the principle stated elsewhere in this PR. It cannot lift a forged claim to VERIFIED, since the field still lands in unverified, so it is a reporting nit rather than a hole. Worth distinguishing decode failure from absence in a follow-up.
2. _b64's docstring says a report object that does not carry these fields at all must not break claim construction, but report.quote_signature and report.attestation_key_chain_pem are plain attribute reads. Both exist with defaults on AttestationReport, so real providers are fine; only a hand-rolled test double would raise. Either tighten the docstring or use getattr.

Approving the code. Holding the merge for one decision that is not mine: this breaks old verifiers in the forward direction, since a new claim carrying gateway.attestation_evidence fails extra="forbid" on any verifier built before the field. That needs a version bump and a release note before it ships, which is the piece you correctly flagged as not yours to decide.