Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tpm2 disk encryption with systemd-cryptenroll #9756

Open
osresearch opened this issue Feb 6, 2025 · 5 comments
Open

tpm2 disk encryption with systemd-cryptenroll #9756

osresearch opened this issue Feb 6, 2025 · 5 comments
Labels
C: boot Boot-related issues (e.g., system failing to boot) cryptography This issue pertains to cryptography. hardware support P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. security This issue pertains to the security of Qubes OS.

Comments

@osresearch
Copy link

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

@osresearch osresearch added the P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. label Feb 6, 2025
@marmarek
Copy link
Member

marmarek commented Feb 6, 2025

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
Copy link
Author

osresearch commented Feb 6, 2025

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
Copy link
Member

marmarek commented Feb 6, 2025

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
Copy link
Author

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
Copy link
Member

marmarek commented Feb 6, 2025

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 :)

@andrewdavidwong andrewdavidwong added cryptography This issue pertains to cryptography. security This issue pertains to the security of Qubes OS. hardware support C: boot Boot-related issues (e.g., system failing to boot) labels Feb 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: boot Boot-related issues (e.g., system failing to boot) cryptography This issue pertains to cryptography. hardware support P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. security This issue pertains to the security of Qubes OS.
Projects
None yet
Development

No branches or pull requests

3 participants