Secure Boot & LUKS Auto-Unlock

Tying UEFI, TPM, and LUKS together

UEFI Secure Boot Recap

Secure Boot is a UEFI feature that enforces signature checks on every boot-time EFI binary. Before executing anything, the firmware verifies the binary's PE/COFF Authenticode signature against a database of trusted keys and hashes stored in NVRAM. Unsigned or unknown binaries simply won't run.

The Key Hierarchy in NVRAM

On every stage-transition (firmware → bootloader, bootloader → kernel when using a shim-linked chain), the previous stage checks the next binary's signature against db and ensures it is not in dbx. Failure aborts the boot.

The Linux Signed Boot Chain

Microsoft's UEFI CA is present in almost every OEM's db. Linux distros exploit this via a tiny first-stage bootloader called shim that Microsoft has signed. Shim then gets to decide what it will load — effectively delegating trust from Microsoft to each distro.

1. UEFI

   Verifies shimx64.efi against db (signed by MS UEFI CA)

2. shim

   Embeds distro CA; verifies GRUB against it + user-enrolled MOK list

3. GRUB

   (Signed) verifies kernel & initramfs signatures before handoff

4. Kernel

   Enforces signed modules (module.sig_enforce=1)

5. initramfs

   Unlocks root (TPM unseal or passphrase) → switch_root → init

• shim ships with every major distro (Ubuntu, Debian, Fedora, RHEL, SUSE). It embeds a distro-specific certificate used to verify the next stage.
• MOK (Machine Owner Key): a user-enrolled certificate held in a UEFI variable. Useful for self-compiled kernels or third-party drivers (NVIDIA, ZFS DKMS). Enrolled via the MokManager UI on the next reboot.
• GRUB: the signed build of GRUB ships with a configuration that requires --pubkey to verify further artifacts. Distros configure it to verify kernel and initrd.
• Kernel lockdown (lockdown=integrity or confidentiality) is typically auto-enabled when booted with Secure Boot — blocks kexec of unsigned kernels, restricts /dev/mem, etc.

Measured Boot vs Secure Boot — Orthogonal

Sealing a LUKS Key to PCRs

This is the mechanism that replaces typed passphrases on boot. Storage 06 showed that a LUKS2 volume has up to 32 key slots, each holding an encrypted copy of the master volume key (MK). Any slot's unwrap-key can open the volume. Adding a TPM slot means: one key slot is unlocked by a TPM-sealed secret instead of a user passphrase.

1. Generate a random 256-bit key K. Add it to a new LUKS2 key slot with cryptsetup luksAddKey.
2. Seal K with a TPM policy bound to the current values of chosen PCRs (e.g. PCR 7 only).
3. Store the sealed blob in the LUKS header token area (systemd-cryptenroll does this automatically — the blob lives in the LUKS2 JSON metadata).
4. On next boot, the initramfs asks the TPM to unseal the blob. If the current PCR values match the sealed policy, K is released, the slot opens, the volume unlocks, root mounts — no passphrase typed.
5. If anything in the measured chain differs (malicious bootloader, altered kernel, different firmware), PCRs differ, the TPM refuses to release K, and the initramfs falls back to prompting for a passphrase.

systemd-cryptenroll --tpm2-device

systemd-cryptenroll is the distro-native tool for managing LUKS2 key slots backed by TPM, FIDO2, or PKCS#11 tokens. It handles all the sealing mechanics, stores the blob as a LUKS2 token, and integrates with systemd-cryptsetup at boot.

Basic Enrollment

# systemd-cryptenroll --tpm2-device=auto \
      --tpm2-pcrs=7 \
      /dev/nvme0n1p3
Please enter current passphrase for /dev/nvme0n1p3:
New TPM2 token enrolled as key slot 1.
  

Options

Inspecting and Removing

# systemd-cryptenroll /dev/nvme0n1p3
SLOT TYPE
   0 password
   1 tpm2
   2 recovery

# systemd-cryptenroll --wipe-slot=tpm2 /dev/nvme0n1p3
Wiped slot 1.
  

/etc/crypttab Entry

# <name>    <device>                               <keyfile> <options>
root-crypt  UUID=a1b2c3d4-...                      none      tpm2-device=auto,discard
  

The tpm2-device=auto option tells systemd-cryptsetup to try the TPM token first. Failure falls through to interactive passphrase entry.

PCR Selection — The Critical Trade-off

Which PCRs you bind to determines two things: what kinds of tampering will block unseal, and what routine events will accidentally block unseal. There is no single right answer — the choice depends on the platform's update cadence and the threat model.

Handling Updates

If the PCR selection includes anything that changes with system updates (firmware, bootloader, kernel, initramfs), the sealed policy will not match current PCRs after the update, and the TPM will refuse to unseal. The machine reboots to a passphrase prompt. You must re-enroll.

# # After a kernel update that invalidated PCR 9 binding:
# systemd-cryptenroll --wipe-slot=tpm2 \
      --tpm2-device=auto --tpm2-pcrs=7+9 \
      /dev/nvme0n1p3
  

Automating Re-seal

• Distro hooks: Ubuntu's full-disk encryption, Fedora Silverblue, and systemd-boot UKI setups precompute expected PCR values for the new kernel/initrd and re-seal automatically as part of the update transaction. dracut-install-kernel-style hooks trigger this.
• Signed PCR policies (--tpm2-public-key): instead of sealing to a concrete PCR value, seal to "any PCR value signed by this public key". The vendor ships a signature alongside each update that authorises the new expected PCRs. No re-enroll needed on the machine. This is how modern "stable auto-unlock across updates" is built.

Unified Kernel Images (UKI)

A UKI is a single PE executable containing the kernel, initramfs, cmdline, microcode, and os-release — all signed as one artifact. UEFI loads it directly (often via systemd-boot); no GRUB, no initramfs generation on the target host.

Clevis + Tang (Network-Bound Disk Encryption)

TPM sealing binds unlock to local state. NBDE binds unlock to network presence: the disk only decrypts when the server can reach a particular internal service. Stolen hardware off-site = cannot unlock.

# clevis luks bind -d /dev/nvme0n1p3 tang \
      '{"url":"http://tang.internal.example"}'
# # M-of-N with Shamir: need 2 of (TPM, tang1, tang2)
# clevis luks bind -d /dev/nvme0n1p3 sss '{
      "t": 2,
      "pins": {
        "tpm2": {"pcr_ids":"7"},
        "tang": [
          {"url":"http://tang1.internal"},
          {"url":"http://tang2.internal"}
        ]
      }
    }'
  

Recovery Planning

Putting It All Together — Secure Server Recipe

The full configuration a modern DevOps/SRE would deploy on a Proxmox host, bare-metal node, or VM with a virtual TPM:

1. UEFI: Secure Boot enabled with the default distro keys. Optionally enroll a site MOK for signing custom kernel modules (ZFS, OpenVSwitch DKMS).
2. Boot chain: shim → GRUB (or systemd-boot + UKI) → signed kernel. Kernel lockdown at integrity mode via Secure Boot auto-detection.
3. LUKS2 root with three slots:
   · slot 0: strong passphrase (emergency / updates)
   · slot 1: TPM-sealed under PCR 7 (7+11 if UKI)
   · slot 2: recovery key printed at install, stored in a password manager
4. Measured boot records the actual boot path into PCRs. tpm2_eventlog available for incident response.
5. Boot behaviour: clean boot → TPM unseals silently → root mounts, no console interaction. Tampered chain or post-update PCR change → initramfs falls back to passphrase prompt → admin investigates or re-enrolls.
6. Optional: Clevis + Tang with SSS threshold "TPM AND tang" for on-prem racks — disks only unlock while plugged into the internal network.
7. Operational hygiene: document which hosts are enrolled against which PCR selections; automate re-seal in the post-update hook; test the passphrase fallback after every major kernel or firmware bump.