Attestation and Key-Release Flow#

Attestation is the point where the business agreement becomes enforceable. The model provider doesn’t release the key because a VM asked for it; the key is released because the workload proved it’s the approved image, on approved hardware, with approved policy state.

_images/cvm-attestation-and-key-release-workflow.png

Figure 5 Attestation and Key Release Workflow#

The end-to-end flow:

  • The model provider builds (and signs) the guest image, encrypts model artifacts and defines key-release policy. They update the keys to an on-prem KMS along with the key-release policy.

  • The platform operator configures firmware, host OS, CVM launch stack, device assignment, and GPU CC mode.

  • The platform operator launches the CVM using the CVM image provided by the model provider with the approved image and devices.

  • The verifier issues a fresh nonce; the guest attestation client collects CPU TEE evidence, GPU evidence, and guest measurements bound to that nonce.

  • The attestation verifier checks that evidence against reference values and policy.

  • The Key Broker Service (KBS) part of the KMS confirms the requester’s identity and the verifier’s outcome.

  • The model key is released into the CVM over a secure channel.

  • The workload reads model artifacts inside protected memory.

  • The inference service starts accepting approved HTTPS traffic.

The verifier rejects stale evidence, unexpected firmware, unexpected guest measurements, disabled security features, revoked collateral, or unapproved GPU state. The verifier-provided nonce is part of the evidence check, so a captured response can’t be replayed.