verify_attestation_chain routes unsupported platform labels through the SNP verifier

[altrudev]

Current behavior

verify_attestation_chain() documents platform-specific hardware-signature dispatch. At current main (eb747f5fd610a8d7fa360e52faaea5db578e6b34) the dispatch is:

platform = getattr(report, "platform", "") or ""
if platform == "intel-tdx":
    signature = _verify_tdx_signature_step(...)
elif platform in ("tpm", "aws-nitro"):
    signature = _verify_tpm_signature_step(...)
else:
    signature = _verify_snp_signature_step(...)

The else is therefore not "SEV-SNP"; it is every other string, including typos, unsupported future values, opaque, and an empty/unknown label.

That matters because the backend does not independently re-check the report's platform label. Given otherwise valid SNP report bytes, VCEK material, matching report_data, and no rejecting measurement policy, changing only AttestationReport.platform from "amd-sev-snp" to an unsupported value still selects the SNP verification path.

The existing full-pass SNP test provides a direct mutation control: its cryptographic evidence does not depend on the Python platform string, so the label and the verification backend are currently separable.

Why this is security-relevant

The result object reports one overall passed boolean and signature status. A caller can therefore receive a successful SNP cryptographic appraisal attached to a report whose declared platform says something else.

This is a platform-dispatch/binding problem, not a claim that the SNP signature itself can be forged.

It is also inconsistent with the repository's own provider boundary:

• SEVSNPProvider emits platform="amd-sev-snp";
• TDXProvider emits platform="intel-tdx";
• Azure has its own azure-cvm-sev-snp path because its manifest binding is vTPM-rooted rather than direct guest-controlled SNP REPORT_DATA;
• OPAQUEProvider is documented as not implemented and fail-closed at construction.

An unsupported platform label should not silently inherit the SNP verifier merely by falling through the dispatch.

Expected invariant

The selected verification procedure must be authorized by the declared platform/profile. Unknown or unsupported platform values must fail closed rather than be interpreted as a known backend.

I am intentionally not choosing whether the result should use FAILED, NOT_IMPLEMENTED, or a distinct unsupported-platform status. That result vocabulary is a maintainer decision.

Suggested narrow direction

Use explicit platform-to-verifier dispatch for every supported platform and an explicit fail-closed branch for everything else. Keep Azure's distinct binding model distinct from direct SEV-SNP rather than folding it into the same default.

Also update the AttestationReport.platform field comment, whose current illustrative values ("tpm" | "sev-snp" | "tdx" | "opaque") no longer match the concrete labels emitted by the providers.

Regression matrix

• valid amd-sev-snp + valid SNP evidence -> existing result;
• same exact evidence with platform="opaque" -> must not pass as SNP;
• same with unknown/empty/future platform label -> fail closed;
• valid intel-tdx -> existing TDX path unchanged;
• valid TPM/AWS Nitro -> existing TPM path unchanged;
• Azure label remains governed by its vTPM-rooted verification semantics rather than direct SNP fallback.

No hardware signature algorithm, certificate chain, manifest hash pre-image, or platform trust root is changed by this issue. The correction is explicit backend selection and platform/evidence binding.

[github-actions]

🟡 Contributor Check: MEDIUM

Check	Result
Profile	MEDIUM
Credential	LOW
Overall	MEDIUM

Automated check by AgenTrust Contributor Check.

[rajnisht7]

as checked and found out that the bug is in verify_attestation_chain()'s platform dispatch: where it checks if platform == "intel-tdx", then elif platform in ("tpm", "aws-nitro"), and then everything else falls into a bare else that runs full AMD SEV-SNP verification. hence any unrecognized platorm label (a typo, "opaque", an empty string, a future value) still gets treated as SNP and can still pass with valid SNP evidence attached to a report whose declared platform says something totally different.

The fix tested is replacing that catch-all else with an explicit allow-list: amd-sev-snp and azure-cvm-sev-snp (both real SNP hardware reports) get their own named branch to the SNP backend, tpm/aws-nitro keep going to the TPM backend, intel-tdx keeps going to the TDX backend, and anything not on that list now fails closed (SignatureStatus.NOT_IMPLEMENTED, with a reason naming the bad label) instead of silently inheriting SNP's verifier. Nothing about the actual crypto (signatures, cert chains, trust roots) changes this is purely fixing which backend gets picked for which label.

[carloshvp]

Confirmed against current main at 37af1568edef023acf626f2deedb4378627bf41e. This is a real platform-to-verifier binding defect, and the explicit-dispatch direction is correct.

I used the existing full-pass synthetic SNP evidence as the mutation control and changed only AttestationReport.platform. Current results:

declared platform	signature	passed
amd-sev-snp	VERIFIED	True
opaque	VERIFIED	True
future-tee	VERIFIED	True
empty string	VERIFIED	True
stale illustrative label sev-snp	VERIFIED	True

Those rows use identical report bytes, VCEK, certificate chain, report-data binding, and measurement. The unsupported label is the only mutation, so the current default branch demonstrably lets a declaration select a verifier it does not name.

Accepted fix boundary

Use explicit dispatch with no cryptographic default:

• intel-tdx -> TDX DCAP verifier;
• tpm, aws-nitro -> TPM verifier;
• amd-sev-snp, azure-cvm-sev-snp -> SNP signature/VCEK-chain verifier;
• every other value, including empty, opaque, stale aliases, and future values -> SignatureStatus.NOT_IMPLEMENTED, a reason naming the unsupported declared platform, and passed=False.

NOT_IMPLEMENTED is the right existing vocabulary here: no signature backend was authorized or run for that platform. FAILED should remain available for a supported backend that actually appraised supplied evidence and rejected it.

Azure needs one precise distinction in the patch description. azure-cvm-sev-snp legitimately uses the SNP backend for the underlying hardware signature, but it does not share direct SNP manifest-binding semantics. Azure's manifest binding is vTPM-rooted. Routing both labels to the same signature primitive must not be described as making them one attestation profile.

PR #373 currently changes Azure's separate report-data/manifest-binding handling in this same function. Keep #363 limited to backend selection. If #373 lands first, rebase and preserve its binding branch; do not fold that policy into this dispatch patch.

Regression evidence required

1. Keep the valid amd-sev-snp full-pass control.
2. Reuse those exact bytes with opaque, empty, an unknown future label, and sev-snp; each must avoid the SNP backend and fail closed.
3. Preserve the existing TDX and TPM/AWS Nitro routing controls.
4. Preserve Azure's explicit SNP-signature route while testing its binding semantics separately.
5. Update the AttestationReport.platform comment so its illustrative values match concrete provider labels rather than the stale sev-snp / tdx aliases.

I ran python/tests/test_attestation_chain.py on the pinned main before this review: 12 tests pass. The new mutation matrix is what makes this correction load-bearing.

@rajnisht7, your allow-list direction is right. Please take this as the scoped PR if you want it; coordinate with @altrudev so the issue does not produce duplicate patches.

[altrudev]

@rajnisht7 Carlos’s accepted boundary assigns #363 to your allow-list lane and explicitly asks us to coordinate. I’m taking #364 separately and will avoid opening a duplicate #363 patch. If you open the scoped dispatch PR, I’m happy to review it against the exact mutation matrix (unsupported labels must never reach the SNP backend, Azure signature routing preserved, #373 binding semantics kept separate).

[imran-siddique]

Recording the implementation owner from Carlos’s accepted scope and the coordination above. Keep explicit platform dispatch separate from #373’s Azure manifest-binding work; unsupported labels must not fall through to the SNP verifier.