LUKS2 with TPM 2.0 auto-unlock on Ubuntu Server 24.04: what we automated and tested in a VM

You can make an encrypted Ubuntu Server unlock itself at boot by binding its LUKS2 volume to the machine's TPM 2.0 chip, for example with Clevis, and keeping a separate recovery key for when the TPM refuses. The hard choices are which TPM measurements (PCRs) to bind to, and what you are and aren't protected against once you do.

This post walks through how Havenfold's installer does it on Ubuntu Server 24.04, why it binds to PCR 7, the honest limit of that choice, and exactly what has and hasn't been tested. Havenfold is pre-alpha, and all of this has been verified only in a virtual machine.

Why a home server wants automatic unlock

A home server should come back on its own after a power cut. If its disk is encrypted with a passphrase, someone has to type it at every boot, which nobody will do at 3 a.m. Without encryption, a stolen machine hands over its disk.

Binding the disk key to the TPM is the usual middle path: the TPM releases the key only if the machine boots in an expected state, so the server unlocks itself at home, while a disk pulled out and read elsewhere stays locked.

How Havenfold's installer sets it up

The installer and its design are described in RFC-0007 §8.5 and in the installer's notes. On a machine with a TPM:

• Install with a temporary passphrase. The automated install creates LUKS2 with LVM using a temporary passphrase.
• First bind without PCRs. Because the installer itself boots from USB, the first Clevis TPM binding is made without PCRs: clevis luks bind -d <luks> tpm2 '{}'.
• On the first boot from the disk, move to PCR 7. A service makes a new binding to PCR 7 and removes the old one, adds a random recovery key in a new key slot, and deletes the temporary passphrase's slot.
• Hand the recovery key to a person. After the in-person joining ceremony, the recovery key is sent over a direct encrypted session to the phone of the parent who did the ceremony and stored in the family's vault collection (or the parents' collection until a vault exists). Once the phone confirms, the node deletes its copy; if no confirmation arrives, a warning stays on the device card and the key isn't deleted.
• No TPM, no disk encryption. On a machine without a TPM, the disk is not encrypted and there is no recovery key; the design document says so explicitly.

Why PCR 7, and what it doesn't protect against

PCR 7 measures the Secure Boot state. RFC-0007 explains the choice: on unchanged hardware, reboots and kernel updates don't break the binding, but turning Secure Boot off or changing its key database does. Adding PCR 4 as well would mean every shim, GRUB or kernel update leaves the node unable to boot unattended.

The RFC is just as clear about the limit (translated from Turkish): an attacker who boots the same computer with another Microsoft-signed system, such as any live Linux USB, with Secure Boot on can keep PCR 7 the same and open the disk. So this encryption mainly protects against the disk being removed and read in another machine, and against attacks that turn Secure Boot off. The family's content is end-to-end encrypted anyway; what could be exposed is identity and stored-envelope metadata.

When PCR 7 does change, the node asks for the passphrase at boot. A parent opens the recovery key on their phone, types it at the console, and the service rebinds to the new PCR 7 value. Package updates known to trigger this are held back from unattended upgrades and left for local approval.

What was tested, and where

All of the following was verified in a virtual machine on GitHub Actions (QEMU with a software TPM and Secure Boot on), using the install.yml workflow, in October 2026:

• The installer menu on a UEFI machine with Secure Boot on, and an automated install with LUKS2 and LVM.
• A TPM seal-and-unseal check before install, and the PCR-less Clevis binding.
• On first boot: unlocking without a passphrase through the TPM, the move to PCR 7, the recovery slot added, the temporary slot removed, and the recovery key opening the disk.
• A second boot unlocking through the PCR 7 binding, with the same device identity.
• No trace of the temporary passphrase left in the install logs.

Not verified: real hardware. The installer's own notes list what remains, including BIOS machines and UEFI with Secure Boot off, recovering after Secure Boot is turned off and on again, machines without a TPM, Wi-Fi and battery behaviour, and real-disk erase commands that QEMU doesn't offer. A virtual machine is not a substitute for real hardware, and the notes say every checked item should be repeated once on a real device.

If you want to do this yourself

You don't need Havenfold for any of this. On Ubuntu Server, Clevis with its TPM2 pin and LUKS2 can do the binding. Decide on your PCRs with the trade-off above in mind, keep a recovery key somewhere other than the machine, and test a recovery before you rely on it.

Summary

• Binding LUKS2 to a TPM 2.0 chip lets a home server unlock itself at boot while a removed disk stays locked.
• Havenfold's installer binds without PCRs during install, moves to PCR 7 on the first boot, adds a recovery key and hands it to a parent's phone.
• PCR 7 survives kernel updates, but an attacker booting another Microsoft-signed system with Secure Boot on can keep it the same; the protection is mainly against disk removal and Secure Boot being turned off.
• All of this has been verified only in a virtual machine on CI, not on real hardware. Havenfold is pre-alpha and not for real data.