One of the main things that put people off having a LUKS encrypted system is having to input the LUKS password on every boot, even if it brings a lot more safety to your system to do so. So, what if I told you that there’s a way to have your encryption cake and eat it too? TPM2 is the answer.

Using it you can have your system be automatically decrypted at boot with no need for inputting your password without losing on the security, as it detects if there are any significant changes to your system in order to block it (although I’m not technical enough to explain it properly).

There’s a relatively easy way to do so in other distros that use mkinitcpio for building the system’s initramfs (I even have an Arch Linux install guide using it), but fedora uses dracut for the same task, and I couldn’t find a way to do so with it. Until now.

Thanks to u/ditto for pointing me out to the mailing list page with the steps provided here and to Ulf Volmer in said mailing list for the step-by-step guide on how to do it.

So, are you ready?


First of all, you need to check if you actually have a TPM2 chip, just to make sure. To do that, run cat /sys/class/tpm/tpm0/device/description or cat /sys/class/tpm/tpm0/tpm_version_major. You’ll get a result showing your TPM2 chip if you have one working. So, if you do, time to use it.

After that, run lsblk to make sure which partition houses your LUKS container.

  • Run systemd-cryptenroll --tpm2-device=auto /dev/$DEVICE, where $DEVICE is your partition where your LUKS encryption rests (in my case /dev/sda3).

  • After that, edit /etc/crypttab, making it look something like this:

luks-$UUID UUID=$UUID - tpm2-device=auto,discard

I’ll reference it as (part1) (part2) (part3) (part4) for an easier understanding of the file’s contents

The changes you’ll do in this case is changing part3 to - and adding tpm2-device=auto to part4.

After that, make dracut aware of the tpm2 by creating the /etc/dracut.conf.d/tss2.conf file, with its contents being the following:

install_optional_items+=" /usr/lib64/libtss2* /usr/lib64/libfido2.so.* "

After that, recreate the initramfs by running sudo dracut -f and reboot your system. If everything went correctly, your system should automatically boot without the need to input your LUKS password.

  • @Thann
    link
    4
    edit-2
    2 years ago

    doesn’t automatically decrypting kinda defeat the purpose?

    EDIT: It makes sense to use tpm in combination with a password to ensure your unencrypted bootloader hasn’t been tampered with

    • @joojmachineOP
      link
      22 years ago

      Not at all, it’s just a balance between convenience and security.

      While having both your LUKS password and your user password is techincally more secure when it comes to physical access to your system, since an invader wouldn’t be able to avoid the LUKS password prompt, this approach still gets most of the benefits from it.

      • An invader wouldn’t be able to have access to your files even in a live boot/external system, since they’d have to wipe the drive out to be able to use it without the LUKS password;
      • They’d still have to crack your user/root password anyways, so if they don’t have that they wouldn’t get very far, unless there’s some ultra powerful unpatched vulnerability out there that allows privilege escalation with no access to any account, which is unlikely;
      • They’d still wouldn’t be able to use your system even if they managed to temper with your firmware/bootloader, since the TPM chip detects that and secure boot deals with unsigned kernels and kernel modules.

      Also it’s more convenient for people that want to shave some seconds of their boot and don’t like having to type two passwords instead of one. This doesn’t affect a lot for people that leave their desktops turned on for days and days, but for people that usually turn their PC/laptop off before sleep, those extra seconds start to pile up really fast.