Re: [PATCH 03/14] protectors: Add TPM2 Key Protector

[Gary Lin]

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);
> 
> Hang on, we've spend ages standardising the format of TPM key files: 
> 
> https://www.hansenpartnership.com/draft-bottomley-tpm2-keys.html
> 
> 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.
> 
Thanks for the spec. I'm not aware of that such format already existed.
Hernan's patch intuitively combines the public the private parts into
one file and provides the tool, util/grub-protect.c, to seal the
password. This certainly can be improved.

> 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.
> 
The sealed key file would be in be in ESP which is accessible to the
normal users. For safety, the key will be sealed against the PCR state
before loading the kernel, and the key file cannot be unsealed in OS.
Instead, we plan to synthesize an initrd with the unsealed key in
"/etc/cryptsetup-keys.d/" and prepend it, so that the crypttab daemon
can decrypt the disk right the way.

Gary Lin