Confidential VM Attestation Policy, TCB Updates, and Key Release for Fraud Scoring
A bank wants to move its fraud-scoring service into confidential VMs on a public cloud using AMD SEV-SNP. Three subsidiaries will submit sensitive transaction data; the bank’s on-premises HSM will release a data-encryption key only after verifying an attestation report. The pilot works, but two problems emerge. A microcode update changes the reported TCB version on 40% of hosts, and the HSM policy-which pins the exact TCB value-refuses key release, so those VMs fail. Also, the fraud model takes 22% longer inside the confidential VM, and the business wants to disable memory encryption for the feature store to recover throughput. The compliance team asks whether the attestation report proves the host is free of vulnerabilities and whether live migration is allowed under the bank’s data-residency rules.
1. Explain what the SEV-SNP attestation report proves and does not prove. Why did exact TCB pinning break key release?
Read the worked answer
The report is signed by AMD’s VCEK and binds the guest’s launch measurement, the guest policy, the platform identity, and the reported TCB version. It proves that the guest was launched with that measurement on a genuine AMD platform at that TCB level and that the report was produced by the PSP. It does not prove that the host administrator is honest, that the guest image is free of vulnerabilities, that side channels are absent, or that the host firmware has no known flaws. Exact TCB pinning broke because TCB is a versioned security state, not a constant: a microcode update raised the reported TCB on 40% of hosts, and the HSM policy treated a newer, patched platform as untrusted. That is the wrong direction-newer TCB is generally better. The policy should require a minimum TCB level and check against AMD’s revocation list, not equality. It should also allow a range of known-good versions and force re-attestation after updates.
2. Design the key-release policy so it survives TCB updates and supports or blocks live migration according to data-residency rules.
Read the worked answer
Use a key broker that evaluates a signed attestation report against a policy:
- guest measurement must match an approved image digest;
- guest policy must disable debug and set the required migration policy;
- TCB must be at or above a minimum and not revoked;
- the report must include a fresh nonce from the broker;
- identity must match the expected workload. For TCB updates, publish a new minimum and allow a transition window; never pin exact values. For migration, decide by data classification: if residency requires no cross-border movement, set the guest policy to disable migration, or allow migration only to hosts in the approved region with re-attestation and key re-release. Do not release a long-lived key that survives migration; use short-lived keys bound to the session and re-wrap after destination attestation. If migration is allowed, the migration agent must be in the trust boundary and the policy must record source and destination. Test the policy with a simulated TCB rollback and a revoked version.
3. The business wants to disable memory encryption for the feature store to recover the 22% throughput loss. What is your advice, and how should the compliance team interpret the attestation evidence?
Read the worked answer
Do not disable memory encryption for the sensitive transaction data or the feature store. SEV-SNP’s memory encryption and integrity protection are the core controls that keep the host hypervisor from reading or tampering with the workload. Turning it off for performance turns the confidential VM into a normal VM for that data and invalidates the confidentiality claim. Recover performance by optimizing the model, using CPU features, batching, or accepting the overhead. If the feature store contains only non-sensitive derived data, isolate it in a separate non-confidential service, but do not mix it with the protected workload. For compliance: the attestation report is evidence of platform state, not a certification that the host is vulnerability-free or that the provider is compliant. The bank still needs a data-processing agreement, residency controls, audit rights, and a vulnerability-management process. Live migration should be disabled or region-restricted if residency rules require it. Document the TCB policy, key-release policy, and residual risk.