Some ambiguities and missing steps in the vTPM guidelines for CVMs on SEV-SNP

[paulhowardarm]

A few uncertainties arose for me while reviewing and understanding this document:

• In step 3 it isn't clear what the difference is between the snp_report.bin and guest_report.bin artefacts. The former appears to be an Azure artefact and is understood/parsed by the Azure Attestation Service. The latter appears to be the actual SEV-SNP hardware report that is understood by sevtool. The steps are correct but the explanation is lacking, and therefore the {32, 1184} byte range extraction seems arbitrary.
• Again in step 3, it is not clear where the "report data JSON" comes from. The step is described as dumping out this file, but in fact the given script doesn't do so. The piece that's missing is that the snp_report.bin needs to be transacted against the Azure Attestation Service in order to obtain a JWT, in which the given properties/claims are nested. But this essential step is not described, so the narrative doesn't join up.
• No mention is made of the vTPM's endorsement cert or its role in trust establishment. Is the vTPM provisioned with an EK and EK cert? If so, what is the CA?
• Step 5 shows how to obtain the public AK from the vTPM by reading the key at index 0x81000003. The quote signature can then be validated against this key. However, no mention is made of needing to check that this key is equal to the HCLAkPub obtained in step 3. Isn't this check critical to the trust chain? If the keys do not match, then the vTPM is not necessarily linked with the hardware platform. Such trust establishment appears to be the purpose of this documentation, so it seems surprising that this seemingly-critical check is not mentioned.

---

Document Details

⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

• ID: da0931c0-467f-a30d-7571-5c842869ef3d
• Version Independent ID: 4d3cb2ce-d1ba-3489-19e9-e5045d13eb59
• Content: Leverage virtual TPMs in Azure confidential VMs
• Content Source: articles/confidential-computing/how-to-leverage-virtual-tpms-in-azure-confidential-vms.md
• Service: virtual-machines
• GitHub Login: @simranparkhe
• Microsoft Alias: simranparkhe

[AjayBathini-MSFT]

@paulhowardarm Thanks for your feedback! We will investigate and update as appropriate.

[paulhowardarm]

@AjayBathini-MSFT Thanks for the prompt response. I am happy to take part in further conversations if any of my feedback is unclear.

[ManoharLakkoju-MSFT]

@paulhowardarm Thanks for bringing this to our attention. I'm going to assign this to the document author so they can take a look at it accordingly

@simranparkhe Can you please check and add your comments on this doc update request as applicable.

[simranparkhe]

ACK. I will work on replying to these questions and updating the doc accordingly.

[simranparkhe]

Hi @paulhowardarm , thanks for your questions. I will work on updating the document to bring more clarity

1&2) The snp_report.bin is the entire SNP hardware report while the guest_report.bin is just the report data JSON. First, we retrieve the entire SNP report and then just extract the portion report data JSON from the SNP report. The report data JSON is everything included in the "x-ms-runtime" field. This field contains AKpub, whether secure boot is enabled etc. Our goal is to make sure this field was indeed signed by the VCEK (the hardware) therefore as intended when provisioning the CVM. 3) vTPM is provisioned with an AK and AKcert rather than the EK and EK cert. AKcert is a certificate associated with the Attestation Key. It is used in attestation processes to prove the identity of the TPM and to provide evidence of the configuration and state of the platform and is rooted to the Azure CA. 4) Thank you for pointing this out. I will add in step 5 to make sure the key read from this index is equivalent to the key seen in step 3.