Clarification on SEV SNP Extended Attestation Architecture

[v-thakkar]

Firstly, thank you for the comprehensive document here. I had a question about the extended attestation architecture. The diagram and the description doesn't specify the relationship between AMD Secure Processor and AMD Key Distribution Service. Is it possible to extend this document to include it? Do I understand correctly that ASP has the certificate chain leaf but KDS is still involved at least initially to retreive the keys? Where can I find more information on that?

[tylerfanelli]

The ASP contains a key to sign attestation reports in order to authenticate the report. In order to verify that the ASP signed a report, that chip's public key is required to verify the signature came from an authenticated AMD secure processor. These public keys are made available through the KDS.

Yes, the ASP has the certificate chain leaf (being the attestation report signature), but the KDS has access to other validation certs. This also depends on the underlying key details (for example, on cloud systems the VLEK is used to sign reports, which is signed by the cloud providers themselves AFAIU).

[tylerfanelli]

@DGonzalezVillal can this be illustrated in some way in the docs?

[hyperfinitism]

The current documentation for the Extended Attestation does not clearly show the role of the AMD KDS, which may lead to confusion about the Root of Trust. In practice, the RoT depends on how the provider handles certificate caching.

Google Cloud

The host caches the whole VCEK cert chain (i.e. VCEK, ASK, and ARK), so after snpguest certificates the RoT is the cloud provider (since ARK/ASK came from the host cache). To reach AMD as the RoT, the guest must run snpguest fetch ca and re-validate the chain against the AMD-issued ARK.

Extended Attestation Flow for Google Cloud

sequenceDiagram
autonumber
participant Guest as Guest VM
participant SP as ASP
participant Host as Host
participant KDS as AMD KDS

Host->>KDS: `snphost fetch vcek`
KDS-->>Host: VCEK
Host->>KDS: `snphost fetch ca`
KDS-->>Host: ASK, ARK
Host->>Host: Cache VCEK, ASK, ARK

Guest->>SP: `snpguest report`
SP-->>Guest: Attestation Report
Note right of Guest: Attestation Report

Guest->>SP: `snpguest certificates`
SP->>Host: Get Host's Cache
Host-->>SP: VCEK, ASK, ARK
SP-->>Guest: VCEK, ASK, ARK
Note right of Guest: Attestation Report<br>VCEK<br>ASK<br>ARK

Guest->>Guest: `snpguest verify certs`
Note right of Guest: Attestation Report<br>✅️ VCEK<br>✅️ ASK<br>✅️ ARK
Guest->>Guest: `snpguest verify attestation`
Note right of Guest: ✅️Attestation Report<br>✅️ VCEK<br>✅️ ASK<br>✅️ ARK

Loading

AWS

The host caches only the leaf VLEK cert. The guest then fetches ASVK and ARK certs directly from AMD KDS via snpguest fetch ca, so verification can anchor on the AMD ARK without relying on provider-cached roots.

Extended Attestation Flow for AWS

sequenceDiagram
autonumber
participant Guest as Guest VM
participant SP as ASP
participant Host as Host
participant KDS as AMD KDS

Host->>Host: Cache VLEK

Guest->>SP: `snpguest report`
SP-->>Guest: Attestation Report
Note right of Guest: Attestation Report

Guest->>SP: `snpguest certificates`
SP->>Host: Get Host's Cache
Host-->>SP: VLEK
SP-->>Guest: VLEK
Note right of Guest: Attestation Report<br>VLEK

Guest->>KDS: `snpguest fetch ca`
KDS-->>Guest: ASVK, ARK
Note right of Guest: Attestation Report<br>VLEK<br>ASVK<br>ARK

Guest->>Guest: `snpguest verify certs`
Note right of Guest: Attestation Report<br>✅️ VLEK<br>✅️ ASVK<br>✅️ ARK
Guest->>Guest: `snpguest verify attestation`
Note right of Guest: ✅️Attestation Report<br>✅️ VLEK<br>✅️ ASVK<br>✅️ ARK

Loading

In other words, provider-cached ARK should never be trusted as the root of trust. Final verification should always pin to the AMD ARK obtained from KDS.

Would it make sense to extend the documentation with a section that explains these provider-specific trust models (e.g. GCP vs AWS) more explicitly, so that users do not mistakenly assume the RoT is always AMD after the Extended Attestation?

References

• https://www.amd.com/content/dam/amd/en/documents/developer/58217-epyc-9004-ug-platform-attestation-using-virtee-snp.pdf
• https://github.com/virtee/snphost/blob/df623ee6e67bfc6a484fc06c66986b626c2c84c6/README.md#3-extended-attestation-flow
• https://docs.aws.amazon.com/en_en/AWSEC2/latest/UserGuide/snp-attestation.html