Trusted Platform Module

The Trusted Platform Module (TPM) is an international standard for a secure cryptoprocessor, which is a dedicated microprocessor designed to secure hardware by integrating cryptographic keys into devices.

In practice a TPM can be used for various different security applications, for example in conjunction with Secure Boot, encryption key storage and random number generation.

To start using a TPM, it has to be present on your hardware (an fTPM or a dedicated device connected to a header on your mainboard) and enabled in the device's firmware settings.

List of Platform Configuration Registers

Platform Configuration Registers (PCRs) hold cryptographic hashes that record the precise state of the system. While these registers can be read at any time, they can only be modified via an "extend" operation, blending new data with the preceding hashes to create an unalterable, cumulative cryptographic chain.

By verifying these measurements between boots, the system can detect unauthorized hardware or software tampering, for example in the scenario of an Evil Maid attack. If any component has been tampered with(i.e. the hash chain deviates from a previously known good configuration), the TPM will not release its secrets. Once the PCRs prove that the correct, untampered operating system has booted, they can be safely trusted to automatically unlock your disk encryption keys.

The UAPI Group describes the TPM PCRs as follows:

PCR	Measured Component	Notes
PCR0	Core System Firmware	BIOS/UEFI executable code; changes on firmware update.
PCR1	System Firmware Config	Firmware settings, hardware config, and boot order.
PCR2	Extended Executable Code	Option ROMs of PCIe cards, GPUs, RAID controllers, etc.
PCR3	Extended Configuration	Device data from the UEFI Boot Device Select (BDS) phase.
PCR4	Boot Manager Code	Bootloader binary (e.g. GRUB, systemd-boot) and boot attempts.
PCR5	Boot Manager Config	Bootloader configuration and the GPT partition table.
PCR6	State Transitions	ACPI power states and S4/S5 suspend/resume events.
PCR7	Secure Boot State	Secure Boot status and database keys (PK, KEK, db, dbx).
PCR8	Kernel Command Line	Literal kernel parameters passed by the bootloader.
PCR9	Initramfs / Initrd	External initramfs/initrd image passed by the bootloader.
PCR10	IMA	Linux Integrity Measurement Architecture (IMA) log.
PCR11	Unified Kernel Image (UKI)	UKI components (kernel, initrd, cmdline) via systemd-stub.
PCR12	Boot Credentials / Overrides	Systemd boot credentials and UKI command-line extensions.
PCR13	System Extensions	System extension (sysext) and config (confext) overlays.
PCR14	Shim / MOK	Shim bootloader binary and Machine Owner Key (MOK) certificates.
PCR15	System Identity	Operating system state (machine ID, LUKS keys, root UUID).

For further details on how PCR 11-13 are used, see systemd-stub(7).

Usage

TPM2-based LUKS key

YouThe canmost usecommon practical application for a TPM on Linux is securing LUKS disk encryption. Integrating the TPM inchip yourdirectly computer asinto a keyLUKS storesetup ties the security of the encrypted volume to unlockthe LUKSphysical encryptedintegrity volumesof withthe them.hardware. This integration is handled via systemd-cryptenroll, which offers the option to either fully automate decryption at boot or require a hardware-backed PIN.

ArchDuring Linux comes with systemd which itself comes withenrollment, systemd-cryptenroll allowinggenerates youa unique, secure unlock key and sends it to specifythe TPM alongside a TPM2policy devicetied forto specific PCR states which record the boot configuration of the system. The TPM encrypts (or "seals") this key storage.using its own unique hardware, producing a protected data blob. This blob is then stored directly inside the LUKS volumes's metadata header.

UsingAt boot, systemd-cryptsetup passes this blob back to the TPM. The TPM immediately measures the current, real-time PCR values to ensure no firmware, bootloader files, or core configurations have been altered. If the TPM PCR values match the ones stored alongside the blob, the TPM decrypts the blob and unlocks the LUKS partition; either instantly or upon the entry of a TPMdesignated forPIN. thisIf purposea automatesmismatch is detected, indicating the processboot path has been tampered with, the TPM will deny the decryption request, making the system fall back to other configured methods of unlocking your LUKS volumes, given that certain conditions are met, e.g. the firmare of the machine and the Secure Boot state.volume.

Enrolling a new key

Certain preconditions are necessary to use TPM2 in conjunction with a LUKS encrypted volume:

• tpm2-tss must be installed
• the volume uses LUKS2 encryption (default when using cryptsetup)
• the initramfs must be systemd-based (mkinitcpio hooks: systemd and sd-encrypt)

Install the tpm2-tss package from the repositories to provice necessary TPM software stack tooling:

pacman -S tpm2-tss

List the TPM2 devices available on your machine:

systemd-cryptenroll --tpm2-device=list

TIP:NOTE: If there are no devices are listed, make sure the TPM is enabled in your device's firmware.firmware settings. Devices from 2016 onwards usually have a TPM 2.0, as it is a requirement from Microsoft for Windows 10 certification for hardware manufacturers.

systemd-cryptenroll --tpm2-device=list

To enroll a new TPM-based key into a LUKS slot, specify the TPM device and the PCRs to seal against, followed by the LUKS volume to save a new slot to:

ATTENTION: TheWhile more PCRs you bind to, the more hardened your setup becomes. But at the same time you can also end up withbinding a less flexible setup. Binding your TPM LUKS key to a broader set of PCRs 8,increases 9system and/security by verifying more stages of the boot process, this hardening comes at the direct expense of system flexibility. On a rapid rolling-release distribution like Arch Linux, an overly restrictive PCR policy is virtually guaranteed to cause regular boot-time breakages. For instance, in a standard modern setup utilizing systemd-boot, UKIs, and Secure Boot, binding to volatile registers like PCR 4 (bootloader binary) or PCR 11 harden(hash yourof UKI) means that routine system againstupdates attemptswill constantly alter these measurements, invalidating the automated decryption policy and reverting the boot process to boot a kernel image which's hashes aren't measured into these PCRs but the moment your kernel changes (i.e. you update your kernel, change initramfs or UKI generation, etc.) the PCRs stop validating and trigger amanual passphrase or recovery key prompt!prompt.

TIP:NOTE: IfIn the unlikely event that your device onlymachine has onemore than 1 TPM (which is usually the case) you candevice, supply its resource manager device node, e.g. --tpm2-device=auto/dev/tpmrm0 to use the only device available..

systemd-cryptenroll --tpm2-device=/path/to/tpm2_deviceauto --tpm2-pcrs=7 --tpm2-with-pin=yes /dev/disk/by-label/cryptroot

Itsystemd-cryptenroll will askrequire youto authenticate the addition of a TPM2 token by prompting for an existing passphrase, followed by asking to enter a new TPM2 PIN. This PIN towill enter,become whichthe younew authentication method at boot. If validation fails for whatever reason, it will befall askedback to puta inregular every time you boot the system.passphrase.

Recovery key

ItWhen planning to rely only on TPM unlocking of LUKS volumes, it is also generally advisableadvised to let systemd-cryptenroll generateadd a recovery key, in case the key stored in the TPM doesn'tvalidation validate anymorefails for whatever reason.

A recovery key is generated automatically with a character set that's easy to type in while still having high entropy (brute force mitigation).

To generate a recovery key and have it saved to a slot in the LUKS device:

systemd-cryptenroll --recovery-key /dev/disk/by-label/cryptroot

Unlocking at boot

Making systemd use the TPM to unlock the volume can be done in one of two ways:

1. add kernel parameters, telling systemd which device to unlock with the TPM
2. use a /etc/crypttab.initramfs file to be included in the initramfs to point systemd to the correct volume

For the kernel command line, add the following:

TIP:NOTE: Again,In ifthe unlikely event that your device onlymachine has onemore than 1 TPM you candevice, supply its resource manager device node, e.g. tpm2-device=auto/dev/tpmrm0 to use the only device available..

rd.luks.options=tpm2-device=/path/to/tpm2_deviceauto

If you'd rather use a crypttab.initramfs file, add tpm2-device=auto to the syntax<options> is as follows:field:

# <name>	<device>									<passphrase>	<options>
root		UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX	none			tpm2-device=auto