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

[Didier Spaier]

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