Re: SVSM vTPM specification

[Dov Murik <dovmurik@linux.ibm.com>]

On 13/10/2022 18:30, James Bottomley wrote:
> On Thu, 2022-10-13 at 10:14 -0500, Tom Lendacky wrote:
>> On 10/12/22 13:44, James Bottomley wrote:
>>> On Wed, 2022-10-12 at 18:33 +0100, Dr. David Alan Gilbert wrote:
>>>> * Tom Lendacky (thomas.lendacky@amd.com) wrote:
>>> [...]
>>>> It's important that the VMPL level in the attestation report
>>>> reflects the side asking for the attestation; in particular one
>>>> TPM story goes that the firmware (in VMPL0) would ask for an
>>>> attestation and the attestor would return the vTPM stored
>>>> state.  It's important that the state could only be returned to
>>>> the vTPM not the guest, so the attestor would check that the VMPL
>>>> level in the attestation was 0; any guest attestation would have
>>>> a VMPL>0 and so the attestor wouldn't hand it the vTPM state.
>>>> Hmm or are you saying such a report would be triggered by the
>>>> guest rather than the firmware, but it would be protected by
>>>> VMPCK0 so the guest wouldn't be able to read it?
>>
>> No, the VMPCK0 key is just used for communication with the PSP.
>>
>> While the SVSM would request the attestation report from the PSP,
>> the guest would need to request it from the SVSM.
> 
> I think this is fine.  The SVSM would do the attestation as it starts
> the TPM but the guest would be able to retrieve it at any time. 
> Essentially, if you use something like keylime, the agent would request
> it on start up to prove it should trust the vTPM, but that could occur
> way after VM boot.
> 
>>
>>>> I think one of the vTPMs keys should be in the SNP attestation
>>>> report (the EK???) - I think that would allow you to attest that
>>>> the vTPM you're talking to is a vTPM running in an SNP protected
>>>> firmware.
>>>
>>> Traditionally the TPM identity is the public EK, so that should
>>> definitely be in the report.  Ideally, I think the public storage
>>> root key (key derived from the owner seed) should be in there two
>>> because it makes it easy to create keys that can only be read by
>>> the TPM (keys should be in the owner hierarchy which means they
>>> have to be encrypted to the storage seed, so we need to know what a
>>> public key corresponding to it is).
>>>
>>> One wrinkle of the above is that, when provisioned, the TPM will
>>> only have the seeds, not the keys (the keys are derived from the
>>> seeds via a TPM2_CreatePrimary command).  The current TPM
>>> provisioning guidance:
>>>
>>> https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/
>>>
>>> Says that the EK should be at permanent handle
>>>
>>> 81010001
>>>
>>> And there's an update saying that should be the RSA-2048 key and
>>> there should be an EC (NIST-P256) one at 81010002.  The
>>> corresponding storage keys should be at 81000001 and 81000002
>>> respectively.  I think when the SVSM provisions the TPM, it should
>>> run TPM2_CreatePrimary for those four keys and put them into the
>>> persistent indexes, then insert the EC keys only for EK and SRK
>>> into the attestation report.
>>
>> We only have 512 bits to work with for the SVSM-provided data, so
>> would hashes of the keys be ok?
> 
> Well, if you put the hashes in, the consuming entity would then have to
> find out via an additional channel what the actual keys were because
> you can't reverse the hash (it's possible, just more effort).  If you
> use point compression, an EC key (for the NIST p-256 curve) is only 32
> bytes anyway, so it's the same size as a sha256 hash, so I'd say place
> the actual public keys into the report to give complete and usable
> information
> 

Do we need to leave room for a Guest-Owner-provided nonce?  Guest owner
will provide it to the guest OS which will provide it to the SVSM to be
included in REPORT_DATA of the VMPL0 attestation report.

If we don't add a nonce not, how can the guest owner verify the
freshness of the report?  Maybe the pub-EK is enough because it signs
the rest of the TPM-report and the guest-owner can somehow verify its
freshness?


It looks like REPORT_DATA needs to be

SHA512(guest_owner_nonce || pub_EK || pub_SRK)

And the guest does this:

1. Receive nonce from guest owner
2. Calls SVSM_GET_TPM_PUB_KEYS
3. Constructs report_data=sha512(guest_owner_nonce || pub_EK || pub_SRK)
4. Calls SVSM_GET_SNP_ATTESTATION_REPORT(report_data)
5. Send back both the report and pub_* to guest owner


-Dov