I'm redoing my laptop installation from scratch, and this time I want a full secure boot chain.

Here's what I did so far :

  • Enroll my own keys in the UEFI firmware
  • Sign my grub bootloader
  • Full disk encryption (implying /boot is encrypted as well)

Many tutorials on the internet (not to say all tutorials) suggest that to accomplish a full secure boot, the kernel (initramfs I guess) should be signed, and the bootloader must make sure it's valid.

So my question is as follow : why sign the kernel/initramfs if the disk is already fully encrypted ?

According to cryptsetup's FAQ, AES-XTS seems to be used by default to manage disk encryption.

As far as I know, unlike GCM, XTS does not provide any way to ensure data integrity. And this is probably why people on the internet suggest that the kernel should be signed to ensure a full secure boot.

Here's an interesting paragraph from this Wikipedia page on disk encryption theory :

XTS mode is susceptible to data manipulation and tampering, and applications must employ measures to detect modifications of data if manipulation and tampering is a concern: "...since there are no authentication tags then any ciphertext (original or modified by attacker) will be decrypted as some plaintext and there is no built-in mechanism to detect alterations. The best that can be done is to ensure that any alteration of the ciphertext will completely randomize the plaintext, and rely on the application that uses this transform to include sufficient redundancy in its plaintext to detect and discard such random plaintexts.

Even if an attacker were able to tamper with my encrypted kernel, grub would decrypt it into complete gibberish, therefore making it unbootable. Or at least it would break at some point, but it would be impossible (AFAIU) for an attacker to ensure its malicious cipher will turn into plaintext executable code. The goal of the secure boot being not to boot on untrusted software, why bother with kernel signature when full disk encryption already seems to meet those requirements ?

  • Rootkit can tamper with the kernel and kernel modules during the runtime of the OS. If it is signed, tampering will be detected on next boot.
    – defalt
    Dec 1, 2022 at 12:05
  • True, but if a rootkit is running on my machine, I consider it's too late already. I guess it all depends on your threat model, but to me the secure boot only aims to protect against physical attacks. Considering I would need my private signing key available on my filesystem to sign the kernel+bootloader automatically on update, a potential rootkit could do the same.
    – ShellCode
    Dec 1, 2022 at 12:12
  • Not always. Some malwares quietly compromise update manager to patch kernel and removes itself to avoid detection.
    – defalt
    Dec 1, 2022 at 12:18
  • I'm not sure I understand what you mean. If a rootkit manages to patch my kernel it means it already has root privileges on my machine, therefore it would also be able to access the private key I would use to sign the kernel on update. Maybe signing the kernel would prevent dumb rootkits from patching the kernel/bootloader, but an advanced one would sign its malicious patched kernel with my private key available in my /root folder and I would not realise it (because it's signed).
    – ShellCode
    Dec 1, 2022 at 12:25
  • 2
    If you're concerned about userspace tampering with the initrd, you've got no redemption basically. Userspace may as well tamper with everything else (systemd init scripts, libraries, binaries, user autorun scripts, etc. etc. etc. etc.). And if you're really paranoid a person with physical access may install a HW keylogger and all your protections are worth nothing. And then there are laptops/PCs with spare DMA ports which allow to clandestinely install additional HW not detectable by your OS which is capable of reading your entire RAM which is enough to own your completely. Dec 1, 2022 at 13:59


You must log in to answer this question.

Browse other questions tagged .