Re: [PATCH 0/5] Automatic TPM Disk Unlock
On Thu, 27 Jan 2022 06:03:21 -0800 (PST) Hernan Gatta wrote: > > > On Tue, 25 Jan 2022, Glenn Washburn wrote: > > > On Mon, 24 Jan 2022 06:12:13 -0800 > > Hernan Gatta 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 > >> >
Re: [PATCH 0/5] Automatic TPM Disk Unlock
On Tue, 25 Jan 2022, Glenn Washburn wrote: On Mon, 24 Jan 2022 06:12:13 -0800 Hernan Gatta 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. 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? Signed-off-by: Hernan Gatta 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
Re: [PATCH 0/5] Automatic TPM Disk Unlock
On Mon, 24 Jan 2022 06:12:13 -0800 Hernan Gatta 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 > > Signed-off-by: Hernan Gatta > > 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
Re: [PATCH 0/5] Automatic TPM Disk Unlock
Hi, Le 24/01/2022 à 15:12, Hernan Gatta a écrit : > 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. Sorry for a newbie question (I plan to allow installing Slint on a Secure Boot enabled machine if/when I can but know almost nothing yet on this topic). Currently we allow in the "auto" mode of installation to install Slint in a fully encrypted drive (minus the ESP and the BIOS Boot partition), the user typing then a passphrase only once when politely requested by GRUB before displaying its menu (without using LVM as we store a LUKS key in the initramfs). The main purpose is to forbid access to the system when the machine is powered off, for instance in case of a laptop stolen during a travel. Would the feature you describe possibly allow to circumvent this protection? Thanks, Didier -- Didier Spaier Slint maintainer ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 0/5] Automatic TPM Disk Unlock
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. Signed-off-by: Hernan Gatta 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 -- 1.8.3.1 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
