[svsm-devel] vTPM service attestation format update

[Claudio Siqueira de Carvalho]

On Fri, 2025-02-21 at 08:31 -0500, James Bottomley wrote:
> On Thu, 2025-02-20 at 17:17 -0800, Dionna Amalie Glaze wrote:
> > I'd like to propose a new version to the vTPM protocol that is
> > clearer
> > about its EK information.
> > It's possible to create multiple primary endorsement keys with
> > different algorithms.
> > 
> > For manifest version 1, we have a list of created primary keys in
> > TPM_ALG enum order, not creation order.
> > 
> > 0x000 uint32 Number of primary endorsement keys
> > 0x004 Variable Number-many TPMT_PUBLIC structures
> > 
> > I don't want to try to load a lot into this change request. For
> > reducing pain with make/activatecredential, there's more to discuss.
> 
> I'm not sure I exactly understand the proposal, but I think it's that
> the type of endorsement key should be part of the input data to the
> vTPM protocol attestation?  In which case I agree.
> 
> However, the last sentence about make/activate credential makes me
> think you're being too traditional about this.  That protocol is really
> only required because physical TPMs are only shipped with encryption EK
> certificates to force the privacy preserving algorithms.  Since there's
> no privacy concerns about the vTPM in a confidential system, we can
> just produce a signing EK, which can itself certify TPM objects without
> the need for doing the AK creation dance.
> 
> That argues that there should be two input arguments: algorithm and key
> type.

I am also not sure I fully understand the proposal.

Providing algorithm and key type may not be enough to identify an EK as we need
to provide multiple parameters to create one, for example:

RSA2048 primary key
https://github.com/cclaudio/svsm/commit/d3fb0bb5756e69f71ce01f3fb4c0b1b3a0d3eaec#diff-50751d6df54bc336e47e1d5907bf31e0fc3491e287d202bf6149df05b582e0b6R80-R108

ECC_P256 primary key
https://github.com/cclaudio/svsm/commit/d3fb0bb5756e69f71ce01f3fb4c0b1b3a0d3eaec#diff-50751d6df54bc336e47e1d5907bf31e0fc3491e287d202bf6149df05b582e0b6R141-R170

In addition to that, the number of permutations of algorithms and types could be
relatively big as well.

Here is another idea. Maybe we can agree on a few TPM memory slots that could be
used for primary keys and then the attestation request could just refer to one
of those.

Regards,
Claudio

> 
> Reegards,
> 
> James
>