From a2342f666064f6d435699137b0c0b76bb15fa249 Mon Sep 17 00:00:00 2001 From: ItsDrike Date: Fri, 12 Apr 2024 22:18:01 +0200 Subject: [PATCH] Add a guide on setting up TPM unlocking --- docs/04_TPM_UNLOCKING.md | 177 ++++++++++++++++++++++++++++++++++++++- 1 file changed, 176 insertions(+), 1 deletion(-) diff --git a/docs/04_TPM_UNLOCKING.md b/docs/04_TPM_UNLOCKING.md index c72d6c1..daed812 100644 --- a/docs/04_TPM_UNLOCKING.md +++ b/docs/04_TPM_UNLOCKING.md @@ -1,3 +1,178 @@ # TPM Unlocking -WIP +This will explain how to set up TPM (Trusted Platform Module) based automatic unlocking of your encrypted partition(s). +Encryption usually requires that you manually type the password in each time you boot. This can however be pretty +annoying (especially if you use a long password, like I do). This guide aims to fix this problem, without compromising +security. + +Once finished, this will basically store another decryption key(s) to your encrypted partition(s) in the TPM module. +During boot, while in initrd, we will request this decryption key from TPM, which will only do so under certain +conditions, to ensure safety. + +The guide assumes you have already a working NixOS system, that uses LUKS encryption. You will also need to set up +secure-boot, as described in [SECURE_BOOT](./03_SECURE_BOOT.md). This is a requirement, as while it is possible to set +up TPM unlocking without it, doing so is incredibly insecure, and might lead to unauthorized users getting TPM to +release your decryption keys. + +> [!WARNING] +> This solution will be mostly safe, however, it is technically possible to hook up wires to the motherboard, to listen +> to the communication coming from the TPM chip. In that case, the attacker would be able to observe the key as it gets +> released by the chip. They could then take out your SSD/HDD, and mount it on their machine, using these obtained keys +> to decrypt the contents. See: +> +> If you can't afford to be vulnerable to this type of attack, you can still follow through with this, however instead +> of the TPM seamlessly releasing the decryption password, you can require a password to be entered, without which TPM +> won't release the decryption password. +> +> This can be useful if you use a very long encryption passwords, and you want to be able to enter a shorter passphrase, +> or a PIN code instead (TPM has brute-force protection, so the PIN isn't actually that unsafe to use). + +## Check if you actually have the TPM module + +First, you will want to verify that your machine even has the TPM module. To do so, you can use the following command: + +```shell +bootctl status +``` + +You should see `TPM2 Support: yes` in the output. + +## Enable TPM2 support + +First, we will want to enable the TPM support in our configuration: + +```nix +# Points TPM2TOOLS_TCTI and TPM2_PKCS11_TCTI to /dev/tpmrm0 +# and allows you to read and write to /dev/tpmrm0 +security.tpm2.enable = true; + +# Tools we will need to interact with the TPM module +environment.systemPackages = with pkgs; [ tpm2-tss tpm2-tools ]; + +# Use systemd in initrd. Only systemd based initrd systems can request data from the TPM module, +# busybox based ones do not have support for this. +boot.initrd.systemd.enable = true; +``` + +## Choosing PCRs + +PCR stands for Platform Configuration Register, and all TPM v2 modules have a bunch of these registers, which hold +hashes about the system's state. These registers are read-only, and their value is set by the TPM module itself. + +The data held by the TPM module (our LUKS encryption key) can then only be accessed when all of the selected PCR +registers contain the expected values. You can find a list of the PCR registers on [Arch +Wiki](https://wiki.archlinux.org/title/Trusted_Platform_Module#Accessing_PCR_registers). + +You can look at the current values of these registers with this command: + +```bash +systemd-analyze pcrs +``` + +For our purposes, we will choose these: + +- **PCR0:** Hash of the UEFI firmware executable code (may change if you update UEFI) +- **PCR7:** Secure boot state - contains the certificates used to validate each boot application +- **PCR12:** Overridden kernel command line, credentials + +> [!IMPORTANT] +> If you're using a boot loader (rather than booting directly from the Unified Kernel Images - EFI files), it is crucial +> that we choose all 3, including PCR12, as many tutorials only recommend 0 and 7, which would however lead to a +> security hole, where an attacker would be able to remove the drive with the (unencrypted) EFI partition, and modify +> the boot loader config. (With systemd-boot, this would be `loaders/loader.conf`). +> +> From there, the attacker could simply add a kernel argument like `init=/bin/bash`, or just enable editor support, +> allowing them to edit the parameters from the boot menu on the fly (This is actually the default for systemd-boot on +> NixOS, editor support is enabled). This would then bypass systemd as the init system and instead make the kernel run +> bash executable as the PID=1 (init) program. This would mean you would get directly into bash console that is running +> as root, without any need to enter a password. +> +> This wouldn't violate secure boot, as the `.efi` image files were unchanged, and are still signed, so the attacker +> would be able to boot into the system without issues. +> +> However, with PCR12, this is prevented, as it detects that the kernel cmdline arguments which were used, and if they +> don't match the recorded parameters during enrollment, TPM will not release the key. +> +> The nice thing about also selecting PCR12 is that it will actually allow us to securely keep systemd-boot editor +> support, which can be very useful for debugging, as all that will happen if we do edit the kernel command line will be +> that the TPM module will not release the credentials, and the initrd will just ask us to enter the password manually. + +Optionally, you may also consider these: + +- **PCR1:** Hash of the UEFI firmware data (changes when you change your BIOS settings) +- **PCR4:** Boot manager (changes when you change the boot manager) + +## Enroll a new key into TPM + +The following command will enroll a new randomly generated key into the TPM module and add it as a new keyslot of the +specified LUKS2 encrypted device (make sure to use the path to your device, it might not be the same as the one I'm +using): + +```shell +sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=0+7+12 /dev/disk/by-label/NIXCRYPTFS +``` + +> [!NOTE] +> If you already had something in the tpm2 module, you'll want to add `--wipe-slot=tpm2` too. + +> [!NOTE] +> If you're extra paranoid, you can also provide `--tpm2-with-pin=yes`, to prompt for a PIN code on each boot. +> +> I have mentioned why you may want to do this in the beginning. + +You will now be prompted for an existing LUKS password (needed to add a new LUKS keyslot). + +## Reboot + +All that remains now is rebooting. The system should now get unlocked automatically, without prompting for the password. + +If you're using a bootloader, I'd recommend also trying to modify the kernel parameters, to make sure that TPM does not +release the key anymore, and you will be prompted to enter it manually. + +## Remove existing key + +Once you have confirmed that TPM unlocking is working, you can now optionally get rid of your original LUKS key. +Since the passphrase generated by systemd-cryptenroll is guaranteed to have a high encryption, getting rid of your, likely much less secure, chosen key can be a good idea, as it further improves your chances if someone attempts a brute-force decryption of your drive. + +That said, if you wish to proceed with this, I **heavily** recommend first creating an equally secure recovery key, so +that you have a way to decrypt your data from the drive in case your computer breaks. To generate a recovery key, you +can actually also just use `systemd-cryptenroll` (though you can also do it manually with `cryptsetup`): + +```shell +systemd-cryptenroll /dev/disk/by-label/NIXCRYPTFS --recovery-key +``` + +This will give you a randomized key, using characters that are easy to type. You will even be given a QR code that can +be scanned directly to save the password on your phone. + +Before proceeding with removing your own key, let's first make absolutely certain that the recovery key you saved does +in fact work. Without doing this, you may get locked out! + +```shell +cryptsetup luksOpen /dev/disk/by-label/NIXCRYPTFS crypttemp # enter the recovery key +cryptsetup luksClose crypttemp +``` + +If this worked, proceed to: + +```shell +cryptsetup luksRemoveKey /dev/disk/by-label/NIXCRYPTFS # Enter your key to be deleted +``` + +## Removing the key from TPM + +In case you'd ever want to remove the LUKS key from TPM, you can do so simply with: + +```bash +csystemd-cryptenroll --wipe-slot=tpm2 +``` + +This will actually also remove the LUKS key from the `/dev/disk/by-label/NIXCRYPTFS` device. + +## Sources / Attribution + +- +- +- +- +-