LUKS2 encrypted boot on Fedora - how to set up correctly?

ovaloakpost · July 25, 2024, 3:46pm

Hi all,

I’m in the process of setting up current Fedora with LUKS2 encrypted boot and root partition on my Framework 13 AMD.

But I always end up with the problem when entering the second passphrase (for the root partition) it doesn’t accept the (correct) passphrase anymore and I’m stuck on the GRUB emergency console (GRUB version 2.06).

Though, after the initial setup of the encrypted root partition (“/” and “/home”) with the official Anaconda installer everything works fine. But when I apply this unofficial guide to also encrypt the boot partition (see below) it doesn’t accept the passphrase of the root partition anymore.

Maybe one of you is familiar with GRUB and LUKS encryption and knows how to do this correctly. Your help would be really appreciated. If we get this working we would also have a working guide for everyone.

Here’s my approach based on the guide for Fedora 37 with FDE by Sysguides:

Initial installation of Fedora

First install Fedora as usual via live image on USB stick, enable drive encryption, so that root partition is LUKS2 encrypted.

The initial partition layout looks like this:

lsblk -pf

├─/dev/nvme0n1p1
│       vfat   FAT32         D532-C407                             581,4M     3% /boot/efi
├─/dev/nvme0n1p2
│       ext4   1.0           e029e25d-d9ae-4251-8942-bd1c8369f027  702,7M    21% /boot
└─/dev/nvme0n1p3
        crypto 2             ddc0ea5f-c32a-4845-90b0-bfc96efb5e56                
  └─/dev/mapper/luks-ddc0ea5f-c32a-4845-90b0-bfc96efb5e56
        btrfs        fedora  ccdc409e-b2b3-4264-a0aa-228849f64e9b    932G     0% /home
                                                                                 /

Now, when initial setup is done proceed to manually encrypting the boot partition.

Encrypt /boot partition with LUKS2

Unmount /boot partition

sudo umount -vR /boot

Examine the ext4 file system for any issues

sudo e2fsck -f /dev/nvme0n1p2

Shrink the ext4 file system to make some room for the LUKS header

The minimum size recommended by cryptsetup is twice the default LUKS2 header size, i.e. 32 MiB.

As the /dev/nvme0n1p2 partition is set to 1 GiB, I’m going to reduce the ext4 file system to 992 MiB (1024-32).

sudo resize2fs -p /dev/nvme0n1p2 992M

Encrypt the shrinked boot partition with LUKS

GRUB currently only supports LUKS with the pbkdf2 algorithm.

For pbkdf2, the minimum iteration count is 1000 and the maximum is 4294967295.

The lower the iterations, the faster the GRUB boots, but it also reduces the security.

I chose a different passphrase here. So there is one passphrase for the boot partition and one for the root partition.

sudo cryptsetup reencrypt \
	--encrypt \
	--verbose \
	--type luks2 \
	--pbkdf pbkdf2 \
	--pbkdf-force-iterations 500000 \
	--reduce-device-size 32m \
	/dev/nvme0n1p2

Open encrypted boot partition

BOOTUUID="$(sudo cryptsetup luksUUID /dev/nvme0n1p2)"
sudo cryptsetup open /dev/nvme0n1p2 luks-"${BOOTUUID}"

Mount all back

sudo mount -va

Restore the SELinux labels to the /boot directory

sudo restorecon -RFv /boot

Create a permanent entry into the /etc/crypttab file for the newly created encrypted block device

echo "luks-${BOOTUUID} UUID=${BOOTUUID} none discard" \
    | sudo tee -a /etc/crypttab
sudo cat /etc/crypttab

Enable the CRYPTODISK option in GRUB

When enabled, it will check the encrypted disks and generate the additional commands needed to access them during boot.

echo 'GRUB_ENABLE_CRYPTODISK=y' | sudo tee -a /etc/default/grub
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Set up access to the encrypted boot device by adding the cryptomount command

sudo sed -i "1i cryptomount -u ${BOOTUUID//-/}" /boot/efi/EFI/fedora/grub.cfg

Final partition layout now looks like this:

lsblk -pf

/dev/nvme0n1
                                                                                 
├─/dev/nvme0n1p1
│        vfat   FAT32        D532-C407                                           
├─/dev/nvme0n1p2
│        crypto 2            e029e25d-d9ae-4251-8942-bd1c8369f027                
└─/dev/nvme0n1p3
         crypto 2            ddc0ea5f-c32a-4845-90b0-bfc96efb5e56                
  └─/dev/mapper/luks-ddc0ea5f-c32a-4845-90b0-bfc96efb5e56
         btrfs        fedora ccdc409e-b2b3-4264-a0aa-228849f64e9b    932G     0% /home
                                                                                 /

Reboot the computer now to ensure that everything is working correctly.

sudo reboot

When booting, you will be prompted for the passphrase twice.

The first time is before loading GRUB, and the second time is before mounting the root file system.

When you input your passphrase in the first LUKS prompt, no cursor indication appears, just enter the passphrase blindly.

Additional notes

I’m aware that my approach is based on a guide for Fedora 37 but the available guides for Fedora 38/39 and 40 from Sysguides are not utilizing the Ananconda installer anymore. Instead all partitioning is done manually via command line, boot is located on the root partition and the whole root partition is only encrypted with LUKS2 pbkdf2, which is weaker than only encrypting boot as a separate partition with pbkdf2 and leave the root partition encrypted with stronger LUKS2 argon2id which is the case when using Ananconda installer.

James3 · July 25, 2024, 6:16pm

I don’t know if this helps or not, but I only encrypt the root and not the boot partition.
I don’t think encrypting the boot partition adds any security, whereas encrypting the root partition obviously does. All assuming one is also using secure boot.

Antonio_Mignogna · July 26, 2024, 11:49am

One problem I had in the past is: The keyboard layout in for the first prompt is English no matter what I configured. By the time the second prompt arrives, keyboard configuration seems to have occurred so there I had a different one. And of course my password had letters which differ between the two layouts

ovaloakpost · July 26, 2024, 4:34pm

Sure, encrypting the root partition is better than no encryption at all. But could you maybe elaborate on why exactly you think encrypting the boot partition does no add any security?

I don’t think UEFI secure boot is to be trusted and many IT security analysts agree on that. Exploits like BootHole and BlackLotus have shown in the past that secure boot has fundamental flaws, and recent PKfail has shown this once more. So what’s left if Framework does not support something like Coreboot and one wants to make it harder for attackers with physical access to the laptop?

ovaloakpost · July 26, 2024, 4:38pm

Yeah, keyboard layout is always to consider when entering passphrases. I guess in case of the frist prompt from GRUB there is no way to change the keyboard layout, it’s always US keyboard layout. The second prompt from Fedora itself does recognize the keyboard layout you have set in Fedora.
In my case, I can rule out that this issue is related to keyboard layout. When I keep it to the encrypted root partition as offered by the official Fedora installer (= only one passphrase prompt by Fedora itself) it all works fine when entering the passphrase. But when I add boot partition encryption (= 2 passphrase prompts) the entering of the passphrase at the second prompt (prompt by Fedora itself) does not work anymore and just keeps asking for entering the passphrase over and over again, and this loop ultimately keeps me stuck in GRUB emergency console. Entering the first passphrase in the prompt from GRUB does work fine, though.
Thanks for your thought, anyway.

James3 · July 26, 2024, 5:01pm

Security is all about identifying the threat profile and mitigating those threats.
The main threats I see are:

Stolen Laptop
Failed SSD disposal.
Tampering
In those scenarios, I wish to make it hard to access my private data stored on the SSD.
Secure boot provides some evidence of tampering (3) but as you say, its not full proof.
But, encrypting the root/data partition protects from 1, 2 and 3.
So, for my use case, encrypting the boot partition does not improve the mitigation enough for me to accept the extra inconvenience of an extra password during boot.
Now, I have over simplified the threat profile here, but there is enough here to make my point.