luks: automatic tpm unlocking

[cwyc]

Motivation for this change

This is an attempt to implement TPM unlocking for LUKS volumes.

The method is based on this guide: https://threat.tevora.com/secure-boot-tpm-2/

Set it up by generating a keyfile, registering it in a LUKS keyslot, and storing it in the TPM sealed with your selected PCRs:

dd if=/dev/urandom of=secret.bin bs=1 count=32

cryptsetup luksAddKey /dev/my-disk secret.bin #or cryptsetup luksFormat /dev/my-disk --key-file secret.bin

tpm2_pcrread sha256:0,2,3,7 -o pcrs.bin
tpm2_createpolicy --policy-pcr -l sha256:0,2,3,7 --pcr pcrs.bin --policy policy.digest
tpm2_createprimary -g sha256 -G rsa --key-context primary.context
tpm2_create -g sha256 --public obj.pub --private obj.priv --parent-context primary.context --policy policy.digest -i secret.bin
tpm2_load --parent-context primary.context --public obj.pub --private obj.priv --key-context load.context
tpm2_evictcontrol --object-context load.context 
# This will output a handle such as "0x81000000", which points to where our keyfile is saved in the TPM's non-volatile memory.
# Don't forget to delete secret.bin.

Then, specify the handle and PCRs in your system configuration:

{
  boot.initrd.luks.devices.root = {
    device = "/dev/my-disk";
    tpm2KeyFile = {
      authString = "pcr:sha256:0,2,3,7";
      persistentObject = "0x81000000";
    };
  };
}

Once the system is rebuilt, it should unseal the volume without any intervention if the PCR values check out, or fall back to a password prompt.

I also have a version that supports transient keyfiles (stored on a disk but encrypted by the TPM) https://github.com/cwyc/nixpkgs/commits/tpmluks, but it's not working.

It's not a very elegant solution. Ideally, it should use systemd-cryptsetup, which can handle TPM unlocking without directly messing around with tpm commands, as well as replace the existing GPG, FIDO2, and Yubikey code. But it doesn't have a standalone executable.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• 21.11 Release Notes (or backporting 21.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module should do
• Fits CONTRIBUTING.md.

[flokli]

@cwyc reading through http://0pointer.net/blog/unlocking-luks2-volumes-with-tpm2-fido2-pkcs11-security-hardware-on-systemd-248.html, could we also use systemd-cryptenroll (depends on #131618) for this?

[cwyc]

@Floki I also think systemd-cryptsetup is an ideal solution.
But as I understand it, it's not as simple as copy_bin_and_libs-ing an executable to the initrd, and then calling it from the script generated in luksroot.nix.
Rather, the decryption functionality is embedded in systemd, which automatically reads volume configurations in a /etc/crypttab using systemd-cryptsetup-generator, and carries out what it specifies.
So, to use systemd-cryptsetup we would have to transition all our boot-time functions from a initrd based on a script generated by nixos running on busybox utils, to one managed by systemd, which is out of my scope.

[zhaofengli]

I also think systemd-cryptsetup is an ideal solution.
But as I understand it, it's not as simple as copy_bin_and_libs-ing an executable to the initrd, and then calling it from the script generated in luksroot.nix.
Rather, the decryption functionality is embedded in systemd, which automatically reads volume configurations in a /etc/crypttab using systemd-cryptsetup-generator, and carries out what it specifies.
So, to use systemd-cryptsetup we would have to transition all our boot-time functions from a initrd based on a script generated by nixos running on busybox utils, to one managed by systemd, which is out of my scope.

This is what #120015 is doing. What's proposed here seems reasonable as a stop-gap solution before we switch to systemd for stage-1 (which may be a while).

[flokli]

I'm a bit hesitant to add this now.

Are we sure we do use the TPM the same way systemd-cryptenroll uses it? So could we switch to /etc/crypttab and all the systemd bits if systemd ended up in initrd?

[cwyc]

@Floki Yeah, it's not going to be a smooth transition from this method to systemd-cryptenroll. Here the user has to specify the handle and pcrs, with systemd I believe it's stored in the LUKS header. You'd have to remove the key and re-register it to convert from one to the other.

Though I've noticed archwiki mentions that systemd-cryptsetup actually does have an executable:

To test that the key works, run the following command while the LUKS volume is closed:
/usr/lib/systemd/systemd-cryptsetup attach mapping_name /dev/sdX - tpm2-device=/path/to/tpm2_device

So theoretically we can use that in the boot script now, and transition to the function built into systemd when we get a systemd initrd.

But I can't find *any* other documentation on how to use this program. Running it with "--help" just gives me This program requires at least two arguments.. So I feel like they really don't want us calling this executable directly, and its behaviour could change in weird ways later. Though I could take a peek in the source code.

[flokli]

I don't think we should introduce our own TPM LUKS way of doing things, especially considering we want to switch to systemd-in-initrd. If we can use systemd-cryptsetup to do most of this already today (and migrate to using it more natively later), we should.

Also, even without systemd in initrd, we can probably even make use of other (non-boot disks) being encrypted with keys stored in the TPM, similarly to how we already now support systemd-cryptsetup's /etc/crypttab. See https://github.com/NixOS/nixpkgs/blob/master/nixos/tests/systemd.nix#L154-L163, which exercises this feature.

If we're worried about regressions, we can probably even add a VM test for this, considering QEMU does support emulating a TPM2.

[cwyc]

Sounds good. I've already been using TPM with QEMU to develop this patch. Once it's ready I'll open another PR.

[aviallon]

@cwyc I believe there isn't any support for LUKS encrypted root + TPM yet.
Couldn't this be added back again?

[cwyc]

I'm not sure my code can be merged. It's sort of hacky, and systemd already has a pretty good implementation of this feature. Too bad we can't use it until the OS transitions to a systemd-managed boot environment A while ago I tried running the systemd-cryptenroll tools in initrd independently of systemd, but I was stuck on some linker issue. Maybe this could be refactored into a standalone module, that can be easily dropped into a configuration.