tpm2 disk encryption with systemd-cryptenroll

[osresearch]

The problem you're addressing (if any)

When enabling TPM2 sealed disk encryption keys with systemd-cryptenroll (available as of systemd 248] it is fairly easy to seal the key (other than requiring that the user know the partition that is encrypted with LUKS):

systemd-cryptenroll \
  --wipe-slot=tpm2 \
  --tpm2-device=auto \
  --tpm2-pcrs=1+2+3+7 \
  --tpm2-with-pin=T \
  /dev/nvme0n1p3

There are three additional steps that need to be done once and are somewhat tricky. The first is that tpm2-tss has to be included in the initrd by creating a new dracut config file:

echo 'add_dracutmodules+=" tpm2-tss "' \
  | sudo tee /etc/dracut.conf.d/tpm2.conf

And the second is that /etc/crypttab has to specify that the tpm2 slot in LUKS should be used. Some guides suggest editing the file to add the option or use sed to try to do so automatically. If they get this wrong, the system might not be bootable.

sudo sed -i '/^luks-/s/$/,tpm2-device=auto' /etc/crypttab

And finally the user must rebuild the initrd with sudo dracut -f to pick up the new crypttab and include the tpm2-tss module in the image. If they are booting a signed UKI, they must also rebuild and re-sign their unifed Xen and dom0 vmlinux image.

The solution you'd like

The Qubes initrd could include the tpm2-tss module by default since hopefully many users will choose to use hardware protected keys.

The /etc/crypttab generation can include the tpm2-device=auto option for encrypted partitions even if no TPM2 sealed keys are created. The fallback behaviour is to ask for the passphrase anyway, so it does not change the boot time or user experience to have it included. Many of the guides also include the PCR list in the crypttab, although the default behaviour is to use the ones specified in the LUKS header (along with a PIN if used) so there is no need to do more than add the tpm2-device option.

The value to a user and who that user might be

Guides for enabling hardware sealed keys for new users can be as simple as running systemd-cryptenroll with the users choice of PCRs, without requiring extra steps to reconfigure dracut, hand editing the crypttab that could risk breaking the boot, or rebuilding the initrd.

Completion criteria checklist

No response

[marmarek]

Is there an equivalent variant for crypttab change but using kernel cmdline? We try to distribute pre-generated unified Xen, without host-specific settings, and provide those via cmdline. Current version allows any cmdline to be set, but we plan to add some filtering to allow only some option.

[osresearch]

Adding the tpm2-device=auto to the crypttab doesn't need to be a host-specific setting -- if there is no systemd-tpm2 token in the LUKS header then systemd-cryptsetup will ignore it. So a generic system install can include the option on its encrypted partitions without causing any change to the user experience.

The dracut changes can not be done via the kernel command line since the tpm2 tools need to be included in the initrd.

(This is not necessarily about unified images; these steps are necessary to enable tpm2 sealed keys even if you're booting via grub or other means)

[marmarek]

I mean I want bundled initramfs without /etc/crypttab included at all (as it would need to include LUKS partition UUID) - in that case, there is no place to add that option.
Including tpm2-tss module by default is fine.

[osresearch]

I might be mistaken about part of my request -- is tpm2-tss included in the Qubes 4.2.3 initrd by default? I just tried removing my extra file from /etc/dracut.conf.d/ and the tpm2 tools are still being built in. I copied that from someone's tutorial without checking before to see if it is already present.

It does appear that options can be specified in the kernel command line to systemd-cryptsetup: https://www.freedesktop.org/software/systemd/man/latest/systemd-cryptsetup-generator.html#luks.options=

[marmarek]

I might be mistaken about part of my request -- is tpm2-tss included in the Qubes 4.2.3 initrd by default?

Currently it isn't, but this one I'm okay with changing.

It does appear that options can be specified in the kernel command line to systemd-cryptsetup: https://www.freedesktop.org/software/systemd/man/latest/systemd-cryptsetup-generator.html#luks.options=

Thanks, this is exactly what I'm asking for :)

[DemiMarie]

Is there an equivalent variant for crypttab change but using kernel cmdline? We try to distribute pre-generated unified Xen, without host-specific settings, and provide those via cmdline. Current version allows any cmdline to be set, but we plan to add some filtering to allow only some option.

Where will the filtering happen? In a pre-boot script that wraps xen.efi?

[marmarek]

Where will the filtering happen? In a pre-boot script that wraps xen.efi?

No, in xen.efi itself, probably based on an allowlist set in the embedded xen.cfg. At least that's the current idea, we will see how it will go once we get to try implementing it.

[DemiMarie]

Where will the filtering happen? In a pre-boot script that wraps xen.efi?

No, in xen.efi itself, probably based on an allowlist set in the embedded xen.cfg. At least that's the current idea, we will see how it will go once we get to try implementing it.

That will need to handle not only Xen arguments but also Linux arguments.

[marmarek]

That will need to handle not only Xen arguments but also Linux arguments.

Yes, that's exactly the point - we can do both in the same place.