Arch Linux

guavayo

Member

Registered: 2026-04-15

Posts: 1

Secure Boot + LUKS detached header?

I've been going through the wiki articles on dm-crypt and Secure Boot and I'm a bit puzzled as to whether it is possible to combine Secure Boot and a detached LUKS header.

From what I gather:

In order to preserve the integrity of the boot chain when using Secure Boot, the boot loader, kernel and initramfs must all be signed and the only way to do that is by generating an Unified Kernel Image (UKI) because the initramfs itself can't be signed (https://wiki.archlinux.org/title/Unifie … I_binaries).

On the other hand, if plausible deniability is desired the LUKS header must be detached when encrypting the drive and of course it shouldn't be added to the initramfs or it will end up in the UKI where its existence will be revealed.

Now the wiki presents two methods to make initramfs support a detached header, either via the sd-encrypt mkinitcpio hook or /etc/crypttab.initramfs or by modifying the encrypt hook (see also the AUR package mkinitcpio-encrypt-detached-header):

- in the first case, an UUID is passed for the volume where the detached header is located is passed to the initramfs so that it can access it, so if the header is stored on an external drive like a USB stick plausible deniability is indeed guaranteed;

- in the second case, it seems that the detached header is added directly into the initramfs with the FILES option so it ends up in the UKI which defeats plausible deniability.

Can someone please tell me if my reasoning is correct?

Last edited by guavayo (2026-04-16 02:45:21)

-thc

Member

Registered: 2017-03-15

Posts: 1,123

Re: Secure Boot + LUKS detached header?

Secure Boot is a concept introduced by Microsoft for an uninterrupted chain of signed software components ensuring nothing in that process has been tampered with. Regarding Arch it is the job of the signed bootloader to ensure that kernel options and the kernel image haven't been tampered with. The booted kernel (having been handed the "Secure Boot baton" by the bootloader) now has to implement it's own method of securing all following steps - like e.g. only loading signed modules.

That's independent of the "packaging" of the modules (UKI/initramfs).

AFAIK plausible deniability requires portions of your data ("unimportant data") to be encrypted with a key that you can and will surrender to the authorities. The authorities then need to be satisfied with that data, satisfied with your explanation that you have no other key (to your important data) and satisfied with the fact that there is still encrypted data that they can't access.

That's a lot of "ifs" and I don't see that with either variant of LUKS header storage.