[svsm-devel] vTPM service attestation format update

[Geoffrey Ndu]

Since the single_service_manifest call for the vTPM effectively certifies EKs,
why don’t the “selector” be the handle values for EK certificates, as specified
by the TCG in 2.2.2.5.1 of “TCG EK Credential Profile For TPM Family
2.0; Level 0”?
This approach would simplify the user experience, as every SVSM would
function identically,
and  SVSM vTPMs would exhibit analogous behaviour to physical TPMs.

Geoffrey

On Wed, Mar 5, 2025 at 4:17 PM Dionna Amalie Glaze
<dionnaglaze at google.com> wrote:
>
> 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)
> --
> Svsm-devel mailing list
> Svsm-devel at coconut-svsm.dev
> https://mail.8bytes.org/cgi-bin/mailman/listinfo/svsm-devel