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