[svsm-devel] vTPM service attestation format update

[Dionna Amalie Glaze]

On Wed, Mar 5, 2025 at 7:29 AM Claudio Siqueira de Carvalho
<cclaudio at ibm.com> wrote:
>
> 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:

This is not what I'm saying. In implementing this I found a
simplification that we can use the manifest version for the selector
version.
The "selector" can be as rich as the entire command to CreatePrimary.
To make it simpler, I'm making 2 initial selector variants.

The first is a TPM2B_PUBLIC that will behind the scenes use an empty
auth block, insensitve, outsidedata, and pcrselection in the creation.

I'd revise the single service attestation extension to just take 2
additional arguments: the selector gpa and selector length.

manifest = single_service_manifest_ex(guid, manifest_version, selector)
magic = u8[b'S', b'S', b'M', b'2']
selector_context = guid || manifest_version.to_le_bytes() || magic || selector
The report_data used in the attestation report becomes SHA-512(nonce
|| selector_context || manifest).

>
> 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.
>

Yes, this is the second selector variant, which is to provide an NV
index for an EK template that will serve as the selector to the
implementation of the first variant.
RSA EK template for EK provisioning is from "TCG TPM v2.0 Provisioning
Guidance" - v1r1 - Table 2, 0x8101_0001 and ECC is 0x8101_0002.

For Google's RSA AK template (signing EK), the NV index is
0x01c1_0001, and ECC is 0x01c1_0003.
I believe Geoffrey's L-1 key template ought to be from the EK
credential profile's low range 0x01c0_0004 for RSA EK template.

Note that 0x8101_0001 is the platform's prerogative to define, so we
should expect different Coconut-SVSM distributions to populate it
differently.

> Regards,
> Claudio
>
> >
> > Reegards,
> >
> > James
> >
>


-- 
-Dionna Glaze, PhD, CISSP, CCSP (she/her)