On Wed, Feb 22, 2023 at 07:41:38AM -0500, James Bottomley wrote:
> On Wed, 2023-02-22 at 15:00 +0800, Gary Lin via Grub-devel wrote:
> > +GRUB_MOD_INIT (tpm2)
> > +{
> > +  grub_tpm2_protector_init_cmd =
> > +    grub_register_extcmd ("tpm2_key_protector_init",
> > +                         grub_tpm2_protector_init_cmd_handler, 0,
> > +                         N_("[-m mode] "
> > +                            "[-p pcr_list] "
> > +                            "[-b pcr_bank] "
> > +                            "[-k sealed_key_file_path] "
> > +                            "[-s srk_handle] "
> > +                            "[-a asymmetric_key_type] "
> > +                            "[-n nv_index]"),
> > +                         N_("Initialize the TPM2 key protector."),
> > +                         grub_tpm2_protector_init_cmd_options);
> > +  grub_tpm2_protector_clear_cmd =
> > +    grub_register_extcmd ("tpm2_key_protector_clear",
> > +                         grub_tpm2_protector_clear_cmd_handler, 0,
> > NULL,
> > +                         N_("Clear the TPM2 key protector if
> > previously initialized."),
> > +                         NULL);
> > +  grub_key_protector_register (&grub_tpm2_key_protector);
> 
Hi James,

> Hang on, we've spend ages standardising the format of TPM key files: 
> 
> https://www.hansenpartnership.com/draft-bottomley-tpm2-keys.html
> 

Per the spec, the type OIDs are defined as the following:

  id-tpmkey OBJECT IDENTIFIER ::=
    {joint-iso-itu-t(2) international-organizations(23) 133 10}

  id-loadablekey OBJECT IDENTIFIER ::=
    {id-tpmkey 3}

  id-importablekey OBJECT IDENTIFIER ::=
    {id-tpmkey 4}

  id-sealedkey OBJECT IDENTIFIER ::=
    {id-tpmkey 5}

Then I assume that the sealed key OID is 2.23.133.10.5. However, I found
that the sealed key OID in openssl-tpm2-engine and linux kernel is
2.23.133.10.1.5, and it doesn't match the tpm 2.0 key spec.

Did I miss anything in the spec?

Cheers,

Gary Lin

> And every major TPM based key system uses this format, so a key file
> created by any TPM2 cryptosystem can be read by any other (meaning you
> can use any crypotosystem tools to manage the key).  What you're doing
> here just reinvents a non-standard format and creates a load of
> parameters that the user needs to know here, but are part of the key
> format standard, so you not only need to remember a load of information
> not in your key file, but you have to have a non-standard tool to
> create the key in the first place.
> 
> Even if you want to keep your own tool to create keys, what about
> interoperability with the kernel?  The kernel's TPM key subsystem
> (trusted keys) also speaks the above format
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/security/keys/trusted-keys/tpm2key.asn1
> 
> so  you wouldn't be able to send this key down to day dm-crypt as a
> trusted key, you'd have to create two separate key files to do that.
> 
> James
> 

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Reply via email to