3 ms·

Compared to Windows+Bitlocker, using full disk encryption on Ubuntu (the most user friendly distro) is bizarrely difficult. By default the boot partition is not

Compared to Windows+Bitlocker, using full disk encryption on Ubuntu (the most user friendly distro) is bizarrely difficult. By default the boot partition is not encrypted (so evil maid attacks are easier) and the KDF iteration counts are way too low, as can be seen here. When I setup FDE with LUKS on my Ubuntu laptop I had to go the manual route since I noticed that the default iteration counts don't make any sense, and it was so incredibly difficult to change them, pages upon pages of instructions. Anyone has any insight why the state of FDE is so bad on Linux? Nobody uses it?

Gasp0de 4y ago
I'm using it on Linux (Ubuntu and Arch Linux) and it wasn't so difficult. The default kdf settings are also sensible in Ubuntu 22.04. the biggest problem afaik is that the kdf isn't changed when there is a new default. E.g. when you installed your system in 2018 and upgraded all the way you still have the defaults from 2018.
adriancr 4y ago
Even if you encrypt boot partition someone could modify grub to grab password for boot partition used there. Then with that password they can evil maid again and change your boot partition. (unless you have same password on root/boot or password is embedded in boot partition in which case win for attacker) You could detect evil maid if you add a script that does a hash over grub used to load with a salt from boot sector, show on screen for user to decide against memorised hash... Prevent perhaps secure boot with custom keys?, but then that's one more layer. And you could probably use secure boot to avoid boot partition encryption entirely.
- vladvasiliu 4y ago
  You can use an unencrypted /boot and have UEFI boot a unified kernel image with the kernel command line built in. And have secure boot verify the signature of that image. A TPM could possibly be helpful: you can't be sure that the PC you're booting up is actually yours and not a clone or has somehow had secure boot disabled that's booting a tampered kernel image. So if the TPM usually unlocks your drive (and a PIN, for added security) and it suddenly asks for your password, then something could be going on.
Avery3R 4y ago
Not exactly sure how the desktop Linux boot process is structured, but on windows with bitlocker the boot partition isn't encrypted either. UEFI has to be able to load a boot manager somehow, and unless you're going to splice in a DXE driver to your mobo's fw, which has the risk of bricking, to decrypt a partition, then you're always going to need a cleartext partition somewhere. On windows the default way it's set up when you have a TPM though is that it locks the decryption keys against a hash of all of the code that has run during the boot process.
jeroenhd 4y ago
TL;DR: secure boot is hard, TPM security is a challenge. FDE works fine with encrypted boot, it's just not the default for Ubuntu. I just ticked the "encrypt my install" box as far as I know, I only found out that my /boot wasn't encrypted after the fact. For evil maid attacks, encrypting /boot or not shouldn't really matter unless there's a known exploit for your bootloader. IMO it doesn't matter much because before you can decrypt the main drive, you'll have to deal with either a rewriteable boot sector, a rewriteable EFI:/boot/grub, or a rewriteable /boot. Each step should verify the hashes of the next loader and of any of the loaded modules, so an attacker would need to inject themselves into your boot process before the verification chain can start. You need to keep secure boot on, though. Setting this up right involves enrolling keys into your UEFI (every time the bootloader updates), securing your UEFI with a good password, and assuring nobody can reflash your motherboard firmware somehow. All of that isn't necessary if you trust that Microsoft's keys don't leak and if you use the pre-signed shims, but that approach tends to break kernel modules (i.e. when you use Nvidia's driver). Microsoft can get around this problem because their root keys are preloaded into almost every secure boot capable device you can find. They can pre-sign a bootloader and distribute it to hundreds of millions of computers, whereas every Linux distro has to jump through hoops and use the Microsoft-signed loader as an inbetween stage or have the user set up their own keys and signature system. Then there's the challenge of TPMs. Windows uses the TPM to verify nothing has changed or demand a recovery key, and can use TPM+PIN to unlock a Bitlocker partition. On Linux, there is a wide variety of tools, but as far as I can tell, you can only choose between "unlock the disk from the TPM" or "unlock the disk with your passphrase". I suppose it's possible to set up a multi stage boot process in which initramfs is loaded from a TPM-based key and the main system is decrypted using a password, but I'm not aware of any easy to use installers for that purpose. I find proper GUI support for TPM configuration sorely lacking compared to other operating systems. The iteration count LUKS defaults to depends on your CPU's performance. By default, LUKS takes 1000ms (or 2000ms in modern versions) of hashing to determine the amount of iterations. I can definitely see why, because at some point I put my iterations up to 10 seconds and the preboot environment, lacking the necessary acceleration instructions, took forever to unlock the disk. Anyone trying out encryption on their new install would probably wipe and retry without encryption with those parameters, which is obviously worse. Getting secure boot set up right is the biggest challenge in my experience. The tools are all there, but there's no real GUI for configuring any of this and with how many Linux enthusiasts will decree that secure boot is Microsoft conspiracy and TPMs are instruments of the devil, I'm not sure that'll change any time soon.

Gasp0de 4y ago

I'm using it on Linux (Ubuntu and Arch Linux) and it wasn't so difficult. The default kdf settings are also sensible in Ubuntu 22.04. the biggest problem afaik is that the kdf isn't changed when there is a new default. E.g. when you installed your system in 2018 and upgraded all the way you still have the defaults from 2018.

adriancr 4y ago

Even if you encrypt boot partition someone could modify grub to grab password for boot partition used there. Then with that password they can evil maid again and change your boot partition. (unless you have same password on root/boot or password is embedded in boot partition in which case win for attacker) You could detect evil maid if you add a script that does a hash over grub used to load with a salt from boot sector, show on screen for user to decide against memorised hash... Prevent perhaps secure boot with custom keys?, but then that's one more layer. And you could probably use secure boot to avoid boot partition encryption entirely.

vladvasiliu 4y ago
You can use an unencrypted /boot and have UEFI boot a unified kernel image with the kernel command line built in. And have secure boot verify the signature of that image. A TPM could possibly be helpful: you can't be sure that the PC you're booting up is actually yours and not a clone or has somehow had secure boot disabled that's booting a tampered kernel image. So if the TPM usually unlocks your drive (and a PIN, for added security) and it suddenly asks for your password, then something could be going on.

Avery3R 4y ago

Not exactly sure how the desktop Linux boot process is structured, but on windows with bitlocker the boot partition isn't encrypted either. UEFI has to be able to load a boot manager somehow, and unless you're going to splice in a DXE driver to your mobo's fw, which has the risk of bricking, to decrypt a partition, then you're always going to need a cleartext partition somewhere. On windows the default way it's set up when you have a TPM though is that it locks the decryption keys against a hash of all of the code that has run during the boot process.

jeroenhd 4y ago

TL;DR: secure boot is hard, TPM security is a challenge. FDE works fine with encrypted boot, it's just not the default for Ubuntu. I just ticked the "encrypt my install" box as far as I know, I only found out that my /boot wasn't encrypted after the fact. For evil maid attacks, encrypting /boot or not shouldn't really matter unless there's a known exploit for your bootloader. IMO it doesn't matter much because before you can decrypt the main drive, you'll have to deal with either a rewriteable boot sector, a rewriteable EFI:/boot/grub, or a rewriteable /boot. Each step should verify the hashes of the next loader and of any of the loaded modules, so an attacker would need to inject themselves into your boot process before the verification chain can start. You need to keep secure boot on, though. Setting this up right involves enrolling keys into your UEFI (every time the bootloader updates), securing your UEFI with a good password, and assuring nobody can reflash your motherboard firmware somehow. All of that isn't necessary if you trust that Microsoft's keys don't leak and if you use the pre-signed shims, but that approach tends to break kernel modules (i.e. when you use Nvidia's driver). Microsoft can get around this problem because their root keys are preloaded into almost every secure boot capable device you can find. They can pre-sign a bootloader and distribute it to hundreds of millions of computers, whereas every Linux distro has to jump through hoops and use the Microsoft-signed loader as an inbetween stage or have the user set up their own keys and signature system. Then there's the challenge of TPMs. Windows uses the TPM to verify nothing has changed or demand a recovery key, and can use TPM+PIN to unlock a Bitlocker partition. On Linux, there is a wide variety of tools, but as far as I can tell, you can only choose between "unlock the disk from the TPM" or "unlock the disk with your passphrase". I suppose it's possible to set up a multi stage boot process in which initramfs is loaded from a TPM-based key and the main system is decrypted using a password, but I'm not aware of any easy to use installers for that purpose. I find proper GUI support for TPM configuration sorely lacking compared to other operating systems. The iteration count LUKS defaults to depends on your CPU's performance. By default, LUKS takes 1000ms (or 2000ms in modern versions) of hashing to determine the amount of iterations. I can definitely see why, because at some point I put my iterations up to 10 seconds and the preboot environment, lacking the necessary acceleration instructions, took forever to unlock the disk. Anyone trying out encryption on their new install would probably wipe and retry without encryption with those parameters, which is obviously worse. Getting secure boot set up right is the biggest challenge in my experience. The tools are all there, but there's no real GUI for configuring any of this and with how many Linux enthusiasts will decree that secure boot is Microsoft conspiracy and TPMs are instruments of the devil, I'm not sure that'll change any time soon.