Bug#814798: debian-installer: enable encrypting /boot using GRUB cryptomount
I would also like to express a vote for true full disk encryption within the Debian installer. The current form of FDE leaves the /boot partition unencrypted. This can be fixed and has been tested on Debian Stretch to work. The process should be as so:
* Create RAID / DM / MD devices (if necessary to combine multiple physical devices)
* Create one encrypted base volume, and utilize LVM2 for each desired partition on top of the encrypted volume (eg. /boot, /home, /, swap, etc).
The installer will run fine in this configuration, but the final grub install will fail. This is because of the following needs to be added:
/etc/default/grub
GRUB_ENABLE_CRYPTODISK=y
Upon that, grub-install / update-grub should work fine and become bootable. Since the encrypted volume is the first volume to be unlocked upon reboot, you will be asked for your crypto disk unlock key twice, and I am not sure of a secure way around that. Using an external key added to the LUKS slot to automatically boot, as some have suggested, allows decryption of all partitions if that key is lost or stolen. The device needs to be unlocked twice since first time is for /boot to load the kernel, and the second time is to load the standard partitions previously defined.
The debian-installer needs to enable support for the Grub cryptodisk option in order to make any progress in a true FDE configuration where the /boot partition is protected. Currently, Debian's "FDE" is slightly more vulnerable to the "Evil Maid" attacks if the attacker modifies the kernel boot image, which is unencrypted. They may even do so in a way that waits until all partitions are unlocked before planting a backdoor post-boot in the user's decrypted environment. Eg. stealing local keys from /home. As such, at the present time, the Debian "Full Disk Encryption" should actually be called "Partial Disk Encryption".
Reply to: