Re: [PATCH 0/5] Automatic TPM Disk Unlock

[Glenn Washburn]

On Thu, 27 Jan 2022 06:03:21 -0800 (PST)
Hernan Gatta
<hegatta@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
wrote:

> 
> 
> On Tue, 25 Jan 2022, Glenn Washburn wrote:
> 
> > On Mon, 24 Jan 2022 06:12:13 -0800
> > Hernan Gatta <hegatta@linux.microsoft.com> wrote:
> >
> >> This patch series adds support for automatically unlocking fully-encrypted 
> >> disks
> >> using a TPM 2.0.
> >>
> >> Currently, when GRUB encounters a fully-encrypted disk that it must 
> >> access, its
> >> corresponding cryptodisk module (LUKS 1, LUKS2, or GELI) interactively 
> >> prompts
> >> the user for a passphrase. An improvement to the boot process would be for 
> >> GRUB
> >> to automatically retrieve the unlocking key for fully-encrypted disks from 
> >> a
> >> protected location and to unlock these transparently. To this end, a TPM 
> >> may be
> >> used to protect the unlocking key to a known-good state of the platform. 
> >> Once
> >> the key is protected in this way, assuming that the platform remains
> >> trustworthy, GRUB can then utilize the TPM to release the key during boot 
> >> and
> >> thus unlock fully-encrypted disks without user interaction. Such a model 
> >> would
> >> not only be more convenient for end-users but also for virtual machines in 
> >> cloud
> >> environments where no user is ever present.
> >>
> >> Design
> >> ------
> >>
> >> This patchset first adds a key protectors framework. This framework allows 
> >> for
> >> key protector modules to register when loaded. A key protector is defined 
> >> as a
> >> module that knows how to retrieve an unlocking key from a specific source. 
> >> This
> >> patchset adds a single such key protector module that understands how to
> >> retrieve an unlocking key from a TPM 2.0 by unsealing a sealed key file 
> >> via a
> >> Storage Root Key (SRK).
> >>
> >> Additionally, this patchset expands the cryptomount command to accept a key
> >> protector parameter. This parameter carries the information necessary to 
> >> select
> >> and parameterize a key protector to be used to retrieve an unlocking key 
> >> for the
> >> disk in question. That is, given an invocation of cryptomount to mount a
> >> specific disk (e.g., "cryptomount (hd0,gpt2)", "cryptomount -u UUID"), a 
> >> key
> >> protector can be used to automatically retrieve an unlocking key without an
> >> interactive prompt.
> >>
> >> Lastly, this patchset also includes a new tool, grub-protect, that allows 
> >> the
> >> user to seal a key file against a set of Platform Configuration Registers 
> >> (PCRs)
> >> using an SRK. This sealed key file is expected to be stored in an 
> >> unencrypted
> >> partition, such as the EFI System Partition (ESP), where GRUB can read it. 
> >> The
> >> sealed key is then unsealed by the TPM2 key protector automatically, 
> >> provided
> >> that the PCRs selected match on subsequent boots.
> >
> > This series should include a documentation patch at a minimum. I would
> > also like to see a QEMU test added. But it should use my cryptomount
> > test series, which hasn't made it to master yet. So this shouldn't be a
> > hard requirement. It would be nice for someone more familiar with
> > Secure boot and TPM to figure out how to get it working in QEMU so we/I
> > can easily add it to the tests. It looks like this should work with
> > the required software[1].
> >
> > Glenn
> >
> > [1] https://en.opensuse.org/Software_TPM_Emulator_For_QEMU
> >
> 
> Agreed. I wanted to get feedback on the feature as a whole first before 
> writing documentation for it since, I figured, the way it functions may 
> change as a result of your comments. Once we settle on how it should work 
> and, more importantly, on how a user might use it (I'm thinking of James' 
> comment on separating the cryptomount command from the configuration of a 
> key protector), then I'll add documentation.

Works for me.

> With respect to your comment about adding tests, it should indeed be 
> possible to test this using QEMU and a software TPM such as swtpm. I'm 
> happy to take a look at that.
> 
> Would it be alright for me to submit a patch series for tests 
> separately from this series?

I prefer strongly suggesting patches for testing be included in the
patch series for new features they test. To my knowledge, this isn't
something that has been stressed much for GRUB in the past, but I would
like to change that. And having said that, I don't think it need be
applied so strenuously for new features for cryptomount because the
infrastructure for testing cryptomount isn't fully baked (IMO). I've
got some patches to help address that, but they aren't the priority for
reviewing at the moment (but hopefully will become more so after the
detached headers patch series goes through). So yes, I think a separate
patch series would be fine.

As for implementation, ideally it would be leveraging my
"cryptomont-test" patch series, for which I'll need to submit an updated
version. I should do that soon. I'm also open to other ideas on the
implementation.

Glenn

> >>
> >> Signed-off-by: Hernan Gatta <hegatta@linux.microsoft.com>
> >>
> >> Hernan Gatta (5):
> >>   protectors: Add key protectors framework
> >>   tpm2: Add TPM Software Stack (TSS)
> >>   protectors: Add TPM2 Key Protector
> >>   cryptodisk: Support key protectors
> >>   util/grub-protect: Add new tool
> >>
> >>  .gitignore                             |    1 +
> >>  Makefile.util.def                      |   17 +
> >>  configure.ac                           |    1 +
> >>  grub-core/Makefile.am                  |    1 +
> >>  grub-core/Makefile.core.def            |   10 +
> >>  grub-core/disk/cryptodisk.c            |   21 +-
> >>  grub-core/kern/protectors.c            |   98 +++
> >>  grub-core/tpm2/buffer.c                |  145 ++++
> >>  grub-core/tpm2/module.c                |  742 ++++++++++++++++++
> >>  grub-core/tpm2/mu.c                    |  807 +++++++++++++++++++
> >>  grub-core/tpm2/tcg2.c                  |  143 ++++
> >>  grub-core/tpm2/tpm2.c                  |  711 +++++++++++++++++
> >>  include/grub/protector.h               |   55 ++
> >>  include/grub/tpm2/buffer.h             |   65 ++
> >>  include/grub/tpm2/internal/functions.h |  117 +++
> >>  include/grub/tpm2/internal/structs.h   |  675 ++++++++++++++++
> >>  include/grub/tpm2/internal/types.h     |  372 +++++++++
> >>  include/grub/tpm2/mu.h                 |  292 +++++++
> >>  include/grub/tpm2/tcg2.h               |   34 +
> >>  include/grub/tpm2/tpm2.h               |   38 +
> >>  util/grub-protect.c                    | 1344 
> >> ++++++++++++++++++++++++++++++++
> >>  21 files changed, 5688 insertions(+), 1 deletion(-)
> >>  create mode 100644 grub-core/kern/protectors.c
> >>  create mode 100644 grub-core/tpm2/buffer.c
> >>  create mode 100644 grub-core/tpm2/module.c
> >>  create mode 100644 grub-core/tpm2/mu.c
> >>  create mode 100644 grub-core/tpm2/tcg2.c
> >>  create mode 100644 grub-core/tpm2/tpm2.c
> >>  create mode 100644 include/grub/protector.h
> >>  create mode 100644 include/grub/tpm2/buffer.h
> >>  create mode 100644 include/grub/tpm2/internal/functions.h
> >>  create mode 100644 include/grub/tpm2/internal/structs.h
> >>  create mode 100644 include/grub/tpm2/internal/types.h
> >>  create mode 100644 include/grub/tpm2/mu.h
> >>  create mode 100644 include/grub/tpm2/tcg2.h
> >>  create mode 100644 include/grub/tpm2/tpm2.h
> >>  create mode 100644 util/grub-protect.c
> >>
> >
> 
> Thank you,
> Hernan