Trusted Platform Module

This article or section needs expansion.

Reason: Needs clarification about usage difference between TPM 1.2 and 2.0, Evil Maid attack defense and Trusted boot. PCR registers sealing and using in combination with LUKS. (Discuss in Talk:Trusted Platform Module)

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 such as secure boot, key storage and random number generation.

TPM is naturally supported only on devices that have TPM hardware support. If your hardware has TPM support but it is not showing up, it might need to be enabled in the BIOS settings.

Note: There are two very different TPM specifications: 2.0 and 1.2, which also use different software stacks. This article only describes TPM 2.0, for the older TPM 1.2 see /1.2.

Checking TPM support

Most modern computers support TPM 2.0, as it has been required for Windows 10 certification since 2016. To check support on your system, either:

check the logs, e.g., by running journalctl -k --grep=tpm as root
read the value of /sys/class/tpm/tpm0/device/description[1] or /sys/class/tpm/tpm0/tpm_version_major:

$ cat /sys/class/tpm/tpm0/device/description
TPM 2.0 Device

TPM 2.0 allows direct access via /dev/tpm0 (one client at a time), kernel-managed access via /dev/tpmrm0, or managed access through the tpm2-abrmd resource manager daemon. According to a systemd project member, using tpm2-abrmd is no longer recommended. There are two choices of userspace tools, tpm2-tools by Intel and ibm-tss^AUR by IBM.

TPM 2.0 requires UEFI boot; BIOS or Legacy boot systems can only use TPM 1.2.

Some TPM chips can be switched between 2.0 and 1.2 through a firmware upgrade (which can be done only a limited number of times).

Usage

Many informative resources to learn how to configure and make use of TPM 2.0 services in daily applications are available from the tpm2-software community.

LUKS encryption

It is possible to encrypt volumes using keys securely stored in the TPM. This approach ensures that your drives remain locked unless the TPM is present and specific conditions are met, such as the integrity of the firmware or Secure Boot state (see #Accessing PCR registers).

This mechanism can be used to automatically decrypt the root volume during the boot process, similarly to how BitLocker works on Windows or FileVault on macOS. While this provides strong protection if the drive is removed from the computer with the TPM, data protection will only rely on basic measures like user passwords and system settings if the entire PC is stolen. To mitigate this, you can:

Consider encrypting user data, such as individual home folders, with a different mechanism.
Use a TPM pin to benefit from the security properties of the TPM, while avoiding completely unattended unlocking.

Warning: Be aware that this method makes you more vulnerable to cold boot attacks.

systemd-cryptenroll and Clevis allow locking LUKS volumes with a key stored in the TPM. Additionally, systemd-cryptenroll enables tying the encryption to signed policies instead of static PCR values (See systemd-cryptenroll(1)).

SSH

For TPM sealed SSH keys, there are two options:

ssh-tpm-agent — ssh-agent compatible agent using TPM backed keys.

https://github.com/Foxboron/ssh-tpm-agent || ssh-tpm-agent

See Store ssh keys inside the TPM: ssh-tpm-agent.

tpm2-pkcs11 — PKCS#11 interface for Trusted Platform Module 2.0 hardware.

https://github.com/tpm2-software/tpm2-pkcs11 || tpm2-pkcs11

See SSH configuration and Using a TPM for SSH authentication (2020-01).

GnuPG

This article or section needs expansion.

Reason: Add instructions for probing the TPM to find out which keys it supports. (Discuss in Talk:Trusted Platform Module)

GnuPG, since version 2.3, supports moving compatible keys into the TPM. See Using a TPM with GnuPG 2.3 for the instructions.

Other good examples of TPM 2.0 usage

Configuring Secure Boot + TPM 2 (2018-06, Debian)
Using the TPM - It's Not Rocket Science (Anymore) - Johannes Holland & Peter Huewe (2020-11, Youtube): examples for OpenSSL with tpm2-tss-engine

Accessing PCR registers

This article or section is being considered for removal.

Reason: This section replicates The Linux TPM PCR Registry. We should only keep info which is not available there instead of duplicating (parts of) the table. (Discuss in Talk:Trusted Platform Module#PCR register table)

Platform Configuration Registers (PCR) contain hashes that can be read at any time but can only be written via the extend operation, which depends on the previous hash value, thus making a sort of blockchain. They are intended to be used for platform hardware and software integrity checking between boots (e.g. protection against Evil Maid attack). They can be used to unlock encryption keys and proving that the correct OS was booted.

The TCG PC Client Specific Platform Firmware Profile Specification defines the registers in use, and The Linux TPM PCR Registry assigns Linux system components using them.

The registers are:

PCR	Use	Notes
PCR0	Core System Firmware executable code (aka Firmware)	May change if you upgrade your UEFI
PCR1	Core System Firmware data (aka UEFI settings)
PCR2	Extended or pluggable executable code
PCR3	Extended or pluggable firmware data	Set during Boot Device Select UEFI boot phase
PCR4	Boot Manager Code and Boot Attempts	Measures the boot manager and the devices that the firmware tried to boot from
PCR5	Boot Manager Configuration and Data	Can measure configuration of boot loaders; includes the GPT Partition Table
PCR6	Resume from S4 and S5 Power State Events
PCR7	Secure Boot State	Contains the full contents of PK/KEK/db, as well as the specific certificates used to validate each boot application[2] When used, shim additionally extends it with its own MokList, MokListX, and MokSBState.
PCR8¹	Hash of the kernel command line	Supported by grub and systemd-boot
PCR9¹	Hash of the initrd and EFI Load Options	Linux measures the initrd and EFI Load Options, essentially the kernel cmdline options.
PCR10¹	Reserved for Future Use
PCR11¹	Hash of the Unified kernel image	see systemd-stub(7)
PCR12¹	Overridden kernel command line, Credentials	see systemd-stub(7)
PCR13¹	System Extensions	see systemd-stub(7)
PCR14¹	shim's MokList, MokListX, and MokSBState.	[3]
PCR15¹		Unused
PCR16¹	Debug	May be used and reset at any time. May be absent from an official firmware release.
PCR23	Application Support	The OS can set and reset this PCR.

Use case defined by the OS and might change between various Linux distros and Windows devices.

On Windows, BitLocker uses PCR8-11 (Legacy) or PCR11-14 (UEFI) for its own purposes. Documentation from tianocore[4].

tpm2-totp facilitates this check with a human observer and dedicated trusted device.

The current PCR values can be listed with systemd-analyze(1):

$ systemd-analyze pcrs

Or, alternatively with tpm2_pcrread(1) from tpm2-tools:

# tpm2_pcrread

Troubleshooting

TPM2 LUKS2 unlocking still asking for password

If you followed the instruction described above for automatically unlocking luks2 devices with enrolled keys in a TPM2 hardware module, but still receive a prompt to input a password during the initramfs boot stage. You may need to early load the kernel module (you can obtain its name with systemd-cryptenroll --tpm2-device=list) that is responsible for handling your specific TPM2 module.