Skip to main content

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 applicationsapplications, suchfor asexample in conjunction with secureSecure bootBoot, encryption key storage and random number generation.

TPMTo isstart naturallyusing supporteda onlyTPM, it has to be present on devices that have TPM hardware support. If your hardware has(an TPMfTPM supportor buta itdedicated isdevice not showing up, it might needconnected to bea header on your mainboard) and enabled in the BIOSdevice's firmware settings.

List of Platform Configuration Registers

Platform Configuration Registers (PCR)PCRs) containhold cryptographic hashes that record the precise state of the system. While these registers can be read at any timetime, butthey can only be writtenmodified via thean extend"extend" operation, whichblending dependsnew ondata with the previouspreceding hashhashes value,to thuscreate makingan aunalterable, sortcumulative cryptographic chain.

By verifying these measurements between boots, the system can detect unauthorized hardware or software tampering, for example in the scenario of blockchain. They are intended to be used for platform hardware and software integrity checking between boots (e.g. protection againstan Evil Maid attack). TheyIf 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 usedsafely trusted to automatically unlock your disk encryption keys and proving that the correct OS was booted.keys.

The UAPI Group describes the:the TPM PCRs as follows:

PCR UsedMeasured byComponent Notes
PCR0 Core System Firmware
BIOS/UEFI executable codecode; Maychanges change if you upgrade youron firmware update. PCR1 System Firmware settingsConfig SettingsFirmware likesettings, hardware config, and boot order, etc.order. PCR2 Extended executableExecutable codeCode ExtendedOption orROMs pluggableof executablePCIe codecards, (akaGPUs, OpROMs)RAID controllers, etc. PCR3 Extended executable dataConfiguration SetDevice duringdata from the UEFI Boot Device Select UEFI(BDS) boot phasephase. PCR4 Boot Manager Code + Boot Attempts MeasuresBootloader binary (e.g. GRUB, systemd-boot) and boot manager the devices the firmware tried to boot fromattempts. PCR5 Boot Manager Configuration + DataConfig Can measureBootloader configuration ofand boot loaders; includesthe GPT Partitionpartition Tabletable. PCR6 State Transitions ACPI power states and S4/S5 Resumesuspend/resume + Power State Events events. PCR7 Secure Boot State FullSecure contentsBoot ofstatus PK/KEK/dband todatabase validatekeys each(PK, bootKEK, applicationdb, dbx). PCR8 HashKernel ofCommand Line Literal kernel cmdlineparameters Supportedpassed by grubthe and systemd-bootbootloader. PCR9 HashInitramfs of/ initrd + EFI Load OptionsInitrd KernelExternal 6.1initramfs/initrd mightimage measurepassed by the kernel cmdlinebootloader. PCR10 IMA ProtectionLinux of the Integrity Measurement Architecture measurement(IMA) loglog. PCR11 Hash of Unified kernelKernel imageImage (UKI) ELFUKI kernelcomponents image,(kernel, embeddedinitrd, initrdcmdline) andvia other payload of the PE imagesystemd-stub. PCR12 OverriddenBoot kernelCredentials cmdline/ Overrides WillSystemd beboot disregarded if Secure Boot is enabledcredentials and UKI hascommand-line embedded kernel cmdlineextensions. PCR13 System extension imagesExtensions System extensionsextension built(sysext) toand extendconfig a(confext) base system via overlay imagesoverlays. PCR14 shimShim / MOK MOKShim certificatesbootloader binary and hashesMachine Owner Key (MOK) certificates. PCR15 LUKSSystem key,Identity Operating system state (machine ID, mountLUKS points Root FS encryption key, machine ID, UUID ofkeys, root volume, FS mounts, UUIDs, etc.UUID).

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

Packages

Package Usage tpm2-tss Implementation of the TCG Trusted Platform Module 2.0 Software Stack (TSS2) tpm2-tools Trusted Platform Module 2.0 tools based on tpm2-tss tpm2-abrmd Access Broker and Resource Management Daemon tpm2-tss-engine OpenSSL engine for Trusted Platform Module 2.0 devices tpm2-pkcs11 PKCS#11 interface for Trusted Platform Module 2.0 hardware tpm2-totp Attest the trustworthiness of a device against a human using time-based one-time passwords

Configuration

    Add user to the tss group 
    sudo usermod -aG tss $USER
    Enable access broker 
    sudo systemctl enable --now tpm2-abrmd
    Logout and login again

    Usage

    TPM2-based LUKS key

    You can use the trusted platform moduleTPM in your computer as a key store to unlock LUKS encrypted volumes with them.

    Arch Linux comes with systemd which itself comes with systemd-cryptenroll and allowsallowing you to specify a TPM2 device for key storage.

    Using a TPM for this purpose automates the process of unlocking your LUKS volumes, given that certain conditions are met, e.g. the firmare of the machine and the Secure Boot state.

    WARNING: When using this method on your root volume, there are a few caveats to be aware of.

    Provided the PCR slots you chose to seal against are considered valid by the system, the TPM will automatically unlock the LUKS volume at boot without the need to enter a password.passphrase.

    However, this also means that in case of theft, theit's dataas isif noyou longerdidn't protected byencrypt the encryption. Furthermore, this also makes you more vulnerablesystem to coldbegin bootwith. attacks, sinceSince the computer just has to be booted up to gain access to the decrypted data, withoutall evenbenefits theof needdata-at-rest toencryption tamperare with the device in order to crack the encryption.nullified.

    It is therefore strongly recommended to at least pass the --tpm2-with-pin=yes option to systemd-cryptenroll to still have a mechanism for user verificationauthentication. (availableDespite withthe systemdname versionof 251).the option, alphanumeric values can be supplied during interactive enrollment.

    Also, make sure the system is in the exact state it should be for normal booting, i.e. the entire system is exactly set up the way you want it and there will be no further changes to core components, especially Secure Boot keys.

    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-systemd-based (mkinitcpio hooks: systemd and sd-encrypt)

    StartInstall bythe gettingtpm2-tss apackage listfrom ofthe repositories to provice necessary TPM software stack tooling:

    pacman -S tpm2-tss

    List the TPM2 devices available inon your machine:

    TIP: If there are no devices listed, make sure the TPM is enabled in your device's firmware. 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 slotslot, specify the TPM device to generate the key from and the PCRs to seal against, followed by the LUKS volume to save a new slot to (using /dev/nvme0n1p2 as an example):to:

    ATTENTION: The more PCRs you bind to, the more hardened your setup becomes. But at the same time you can also end up with a less flexible setupsetup. — e.g. bindingBinding your TPM LUKS key to PCRs 8, 9 and/or 11 harden your system against attempts 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 initrdinitramfs or UKI generation, etc.) the PCRs stop validating and trigger a passphrase or recovery key prompt!

    TIP: If your device only has one TPM (which is usually the case) you can supply --tpm2-device=auto to use the only device available.

    systemd-cryptenroll --tpm2-device=/path/to/tpm2_device --tpm2-pcrs=0+7 --tpm2-with-pin=yes /dev/nvme0n1p2disk/by-label/cryptroot

    It will ask you for a PIN to enter, which you will be asked to put in every time you boot the system.

    Recovery key

    It is also generally advisable to let systemd-cryptenroll generate a recovery key, in case the key stored in the TPM doesn't validate anymore for whatever reason.

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

    To generate a recovery key and have it saved to a slot in the LUKS device (using /dev/nvme0n1p2 as an example):device:

    systemd-cryptenroll --recovery-key /dev/nvme0n1p2disk/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: Again, if your device only has one TPM you can supply tpm2-device=auto to use the only device available.

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

    If you'd rather use a crypttab.initramfs file, the syntax is as follows:

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