I know this isn't Stackoverflow, but... Does anyone have a good mental model for disentangling the issues of full-disk encryption versus secure-boot? I've been badly procrastinating with my desktop's new SSD because of it.
Use-case is:
* Dual-boot where I choose in BIOS/UEFI to go to either the existing Win10 drive or new Linux drive.
* I don't need unattended boot at all, I'd rather enter a passphrase every time.
* Resistance to evil-maid attacks is nice but not top-priority compared to theft.
* I want to be able to take my drive out of a dead computer and access it elsewhere if something goes wrong, as opposed to needing to reformat and reload from backups.
* If I install a distro with secure-boot off, can I turn it on later for benefits, or vice-versa?
they are not incompatible. You can have secure boot and FDE for both linux and windows on the same system.
Just put linux's boot drive on a removable USB that has boot priority over the builtin drive. Then configure UEFI secure boot so that it works for both windows and your custom keys.
This setup has the added benefit of making it so that windows can't overwrite your linux boot drive, but from linux you can still access your disk from disklocker
You can turn the secure boot on/off at any time. The only effect from this is the loss of encryption keys that you might have bound to the measured values.
So for it to be effective against the evil maid, you really need to bind the LUKS key to it. But you can do that _and_ set a strong PIN for your LUKS key.
1. Your data on the drive/partition is encrypted by $BIGKEY, which basically never changes because that would require redoing everything.
2. The LUKS header stores one-or-more encrypted versions of $BIGKEY, generally encrypted using a more convenient $SMALLKEY that a human could memorize. Optionally, $PIN can also be part of the encryption step.
3. Unlike $BIGKEY, the $SMALLKEY and/or $PIN can be changed over time. This changes the ciphertext of $BIGKEY and rewrites the LUKS header.
4. Optionally, secure boot is capable of storing and retrieving $SMALLKEY into system chips in such a way that most tampering ought to destroy $SMALLKEY.
> So for [Secure Boot] to be effective against the evil maid, you really need to bind the LUKS key to it.
If my $SMALLKEY is not stored inside the secure-boot chips, I can see how that would be inconvenient, but I'm not sure how that is safer.
Is it because the route $SMALLKEY automatically travels bypasses tricks like a hardware keylogger?
I second slicktux's suggestion: look into OPAL, it's much more easier to setup and use compared to LUKS. The best part is, the encryption is transparent to the OS, so you could multi-boot between multiple OSes and not worry about encryption or compatibility with partitioning tools etc.
Your drive does need to support OPAL though, check out sedcli for managing SEDs.
?? OPAL is transparent to the OS, Microsoft doesn't need to see/care about it. I'm multi-booting Win11, Linux and GhostBSD on my OPAL2 encrypted drive (on a ThinkPad Z13) and I've got zero issues.
They're talking about Windows Bitlocker. It used to be able to use hardware encryption if the drive supported it, then there were sufficient vulnerabilities in implementations that it now always does software encryption.
Being that it’s an SSD it’s already encrypting by default. You just have to set the User and Admin password and you’ll have full disk encryption!
You can set HDD/SSD password via the BIOS/UEFI or (my preferred method) using HDPARM —SECURITY commands.
Then if you take the drive out you can unlock it from another computer so as long as you plug it in directly and the UEFI supports HDD/SSD unlocking during post; if not you can install a Pre-Boot authentication on the drive that runs Linux to unlock the drive and then once unlocked it with the PBA it re-boots and it works as a normal un-encrypted drive.
Look into HDPARM and OPAL standard for full disk encryption.
I can't say anything about dual-booting Windows. I have heard that Windows Updates will frequently overwrite your custom EFI vars setup and reinstate the Windows bootloader etc.
Other than that, FDE and Secure Boot are unrelated.
The board's UEFI will boot the EFI binary that is either your kernel + initramfs (UKI binary), or a bootloader of your choice that then boots your kernel + initramfs. Depending on your distro, you may have a bootloader like grub or systemd-boot that is already signed by the MS third-party CA and your board may already allow the third-party CA, in which case you don't need to generate and sign with your own keys. Otherwise generate your own keys, set up Secure Boot with them, and then figure out how to sign your UKI binary / bootloader binary with those keys.
This initramfs will then be responsible for locating and mounting your root etc partitions. For a systemd distro using the UAPI Discoverable Partitions spec (use a specific type ID for the root partition), systemd has a builtin cryptsetup target that will prompt you on tty to enter the LUKS password for that partition. Otherwise investigate your distro's initramfs options for doing that.
>* Dual-boot where I choose in BIOS/UEFI to go to either the existing Win10 drive or new Linux drive.
grub and systemd-boot both show menus to select one of the available EFI binaries to chain to. Otherwise your UEFI might give you a similar menu.
>* I want to be able to take my drive out of a dead computer and access it elsewhere if something goes wrong, as opposed to needing to reformat and reload from backups.
Any other PC can mount and decrypt the drive with cryptsetup just like your original PC could, as long as you specify the same password.
>* If I install a distro with secure-boot off, can I turn it on later for benefits, or vice-versa?
Yes. You will launch board's UEFI, set the SB status to "Setup mode", boot your OS, then generate and enroll new keys which will set the SB to "User mode" and start enforcing signatures on next boot. And if it breaks you can set it back to "Setup mode" in board's UEFI, boot the OS and troubleshoot / re-enroll keys. The OS wouldn't care that you had previously enabled SB but are now booting with SB disabled.
Note that Secure Boot != Measured Boot. With a standard Measured Boot setup the disk encryption key is protected by secure element on the board (eg TPM) measuring the boot chain, so your disk will automatically decrypt when the boot chain matches the previous measurement and automatically fail to decrypt when it doesn't match. Your concerns about failing to decrypt the disk apply to this setup, not to SB. But also LUKS-encrypted partitions can have multiple keys to unlock them, so you can have both a Measured Boot-guarded encryption key and an emergency fallback password to unlock the disk manually.
Use-case is:
* Dual-boot where I choose in BIOS/UEFI to go to either the existing Win10 drive or new Linux drive.
* I don't need unattended boot at all, I'd rather enter a passphrase every time.
* Resistance to evil-maid attacks is nice but not top-priority compared to theft.
* I want to be able to take my drive out of a dead computer and access it elsewhere if something goes wrong, as opposed to needing to reformat and reload from backups.
* If I install a distro with secure-boot off, can I turn it on later for benefits, or vice-versa?