Full-Disk Encryption simply means that all the OS components are encrypted, with the unavoidable exception of the bootloader (and of the content of /boot/EFI if we are in a UEFI system). That is, a system is FDE as long as directories like /, /boot, /var, etcetera are stored within LUKS volume(s).
Then there are several approaches to do that and, as a consequence, several possible ways to unlock the volumes during boot.
Our image is an FDE system in which everything is contained in a LUKS2 volume. During first boot, an interactive wizard runs and, apart from re-encrypting the LUKS2 volume to make it secure, it configures it to be unlocked during subsequent boots using:
- (a) A passphrase that must be entered by the user
- (b) A secret stored in the system's TPM that is only accessible when booting with exactly the same Grub binary and exactly the same
grub.cfg
Depending on the user's choices during the wizard and on the availability of a functional TPM, the system can be configured to do (a), (b) or both.
There is a third option "CCID capable token" offered by the wizard but it's very likely just a leftover from previous experiments since it's not really implemented and Grub2 can't currently use such tokens to unlock LUKS devices.
In a matter of days, D-Installer will be perfectly capable of installing the system in a newly created LUKS2 volume protected by a passphrase provided by the user during the installation process.
That means the FDE scenario with (a) will be already fully covered since the very first boot after installation. So, strictly speaking FDE will be addressed out-of-the-box without using any intermediate well-known password and without needing any extra step like running the wizard mentioned at section 1.
If the user wants (b) in addition to (a), that can be done at any point from the new system. It cannot be done during installation for technical reasons that go beyond D-Installer. Running the current wizard described at section 1 is clearly overkill in this case. It would be better to offer a simple tool that simply performs that concrete task: adding a new TPM-based unlocking mechanism to the otherwise already fully-functional FDE system.
That's simpler for all the involved parts. There is no need to modify the wizard to act differently in case of image-based vs installation-based because it will only be used in image-based scenarios.
Sounds like a sane approach to me.
It would be nice if d-installer would also ask the user whether they want to use the TPM to protect the OS partition - and if the user selects this, I would attempt an automatic TPM enrollment on first boot.