Re: SVSM vTPM specification

[James Bottomley <jejb@linux.ibm.com>]

On Wed, 2022-10-19 at 12:21 +0100, Dr. David Alan Gilbert wrote:
> * Christophe de Dinechin (cdupontd@redhat.com) wrote:
> > > On 18 Oct 2022, at 22:22, Dov Murik <dovmurik@linux.ibm.com>
> > > wrote:
> > > 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:
> > > > > > [...]
> > > > > > > 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.
> > > 
> > I think it’s a good idea, but I’m not clear on which component in
> > the guest would be responsible for that exchange.
> 
> Hang on; we're mixing a few levels here.
> 
> To go back to Dov's question; the only reason to worry about 'leaving
> room' for a nonce is James's idea of including actual keys and taking
> all the space up.

Actually I didn't say I'd take up all the space.  I said including an
EC EK would take up half the space.  I asked AMD the question of where
the nonce goes separately and it does seem it has to go in here as
well, so that would rule out including the EC SRK.  That being the case
I'm fairly ambivalent whether the keys are hashed or not because you'll
need to know the SRK to wrap a key to the TPM, so you'd have to ask the
TPM to certify the SRK with the EK before you wrap.  I was interested
in providing full information in the report so you could wrap simply by
seeing it without asking for additional values, but it looks like that
isn't possible.

If the ECEK and the nonce are in the report, the sequence is

request report from SVSM and return it

verify report

TPM2_Certify(ECSRK with ECPRIMARY)

return certification data which guest owner verifies
Wrap key to ECSRK and send to guest

If the nonce and a sha256(ECPRIMARY|ECSRK) are in the report, the
sequence is

request report from SVSM
TPM2_ReadPublic(81010002)
TPM2_ReadPublic(81000002)
return both keys and report

recreate hash and verify report
Wrap key to ECSRK and send to guest

I don't think there's much in it.

>   IMHO that sounds delicate, and dependent on the key type etc -
> where as if you include a hash, then you can mix a nonce in as well.

Half nonce half information (32 bytes each) sounds about right.  I have
a slight preference for including a nonce directly rather than hashed
because for durable attestation you can prove independent nonces simply
from the report.  If you hash the nonce you need both it and the report
in the durable attestation.

James