Skip to content

Raspberry Pi 5 TPM 2.0 Security Guide

A Raspberry Pi 5 does not include a discrete TPM. An external TPM 2.0 module can protect keys, record measurements, and enforce policies, but it does not automatically encrypt storage or make the boot chain trusted. Start with a threat model, choose a kernel-supported module, and keep recovery credentials outside the device.

Choose the control by security goal

Goal Primary control What it does not do
Prevent unsigned boot files from running Raspberry Pi signed/secure boot Encrypt user data
Detect unexpected boot state Measured boot plus TPM PCRs and event log Block execution by itself
Keep data unreadable when storage is removed LUKS2 encryption Prove boot integrity
Unlock only in an approved state LUKS2 plus TPM policy Replace a recovery key
Detect modified root filesystem blocks dm-verity Hide data or make /data writable
Protect an application key from export TPM-sealed or TPM-backed key Prevent an authorized process from using it
Recover after an update or TPM failure Offline recovery key and tested backup Add security if stored beside the Pi

These controls are complementary. “TPM enabled” is not a complete architecture.

  1. Complete ordinary Raspberry Pi OS security hardening.
  2. Write down the attacker, assets, physical-access assumptions, and acceptable recovery time.
  3. Select and detect a TPM using the TPM module selection and verification guide.
  4. Test key sealing or LUKS2 auto-unlock on a disposable data partition.
  5. Keep a passphrase or recovery key enrolled before relying on the TPM.
  6. Add boot measurement or signed boot only after documenting update and rollback procedures.
  7. Test failure cases: changed boot files, removed TPM, cleared TPM, damaged storage, and lost network access.

Do not begin by programming OTP. Raspberry Pi secure-boot provisioning can include irreversible steps. Use Raspberry Pi's current official boot-security documentation and a disposable board during development.

Threat model worksheet

Question Example decision
What must remain secret? Database credentials and recorded sensor data
Can an attacker remove storage? Yes, device is installed in a public location
Can an attacker replace boot files? Yes, enclosure can be opened
Must unattended boot continue? Yes, but only after an expected software update
What is the recovery-time objective? Restore service within two hours
Where is the recovery credential stored? Offline password manager and sealed operations record
Who may authorize a new boot state? Two administrators through a documented change

If an attacker can use the whole running device, unattended decryption makes data available to that running system. TPM-bound unlock primarily addresses removed storage and changed measured state; it does not replace application authorization or physical controls.

TPM 2.0 components

Device nodes and resource manager

After the kernel binds a supported TPM, Linux normally exposes:

1
ls -l /dev/tpm* 2>/dev/null
  • /dev/tpm0 is the raw TPM character device.
  • /dev/tpmrm0 is the in-kernel resource-manager interface and is preferred by many modern tools.

The device node is stronger evidence than seeing an SPI or I2C controller. A visible /dev/spidev* interface alone does not prove that the TPM driver claimed the module.

Platform Configuration Registers

PCRs hold values extended by measurements. They are not general storage locations and are not simply overwritten with a desired hash. Read the allocated banks and values with:

1
2
3
4
sudo apt update
sudo apt install tpm2-tools
tpm2_getcap pcrs
tpm2_pcrread sha256

The tpm2_pcrread documentation explains bank and PCR selection syntax. A PCR value is meaningful only with an event log or a documented measurement pipeline explaining what extended it.

Keys and policies

A TPM can create keys whose private material is not exported in ordinary operation. It can also seal a secret so it is released only when an authorization policy succeeds. A PCR policy is one possible condition, but updates can legitimately change PCR values.

Avoid hard-coding “golden PCR hashes” before proving that the Raspberry Pi boot flow actually measures the components you intend to trust.

Secure boot, measured boot, and verified root

Raspberry Pi secure boot

On supported Raspberry Pi models, signed boot restricts boot code to images signed by the customer's key. The public-key digest and configuration can be tied to OTP/EEPROM state. This is independent of a discrete TPM.

Before considering it:

  • secure the offline signing key
  • create separate development and production keys
  • document image signing and update rollout
  • retain a tested recovery/provisioning process
  • understand which steps are irreversible on the target model

This guide deliberately does not provide a copy-and-paste OTP programming command.

Measured boot

Measured boot records hashes of boot components into PCRs and normally produces an event log. A verifier can compare the signed TPM quote, nonce, PCR values, and event log against an approved policy. Merely reading a PCR locally is not remote attestation.

Check whether an event log exists before designing around one:

1
2
find /sys/kernel/security -maxdepth 3 -type f -iname '*measurement*' -o -iname '*event*'
mount | grep securityfs

Availability depends on the firmware, boot stack, kernel, TPM integration, and measurement implementation. Do not assume a PC-style UEFI event log exists on every Raspberry Pi OS setup.

dm-verity

dm-verity checks read-only block data against a hash tree rooted in a trusted hash. The root hash must itself be authenticated through the boot chain or another trusted channel. dm-verity detects corruption or unauthorized changes; it does not encrypt the data.

Use it for immutable system images with a separate writable data design. For simpler kiosks where reset-on-reboot is sufficient, OverlayFS may be operationally easier, though it provides a different security property.

LUKS2 and TPM-backed unlocking

LUKS2 encrypts a block device. systemd-cryptenroll can add a TPM2 token to a LUKS2 header, while retaining a passphrase or recovery key in another slot. Follow the focused TPM2 LUKS2 auto-unlock guide on a disposable data partition before considering root encryption.

Key principles:

  • inventory device names with lsblk; never copy /dev/sdX blindly
  • back up data and the LUKS header before enrollment
  • retain and test a non-TPM recovery credential
  • start with a data volume, not the current root filesystem
  • prove unlock, rejection, update, rollback, TPM removal, and recovery
  • bind only to measurements that the platform reliably produces

An empty PCR selection makes the TPM token device-bound but not boot-state-bound. A narrow PCR policy can be fragile across legitimate updates. Choose from evidence, not a generic PCR number copied from a PC tutorial.

dm-verity and LUKS solve different problems

Property dm-verity LUKS2 TPM policy
Confidentiality No Yes Protects release/use of key material
Block integrity Yes, read-only verified mapping Encryption includes sector integrity only with an explicitly designed integrity mode No filesystem/block verification by itself
Writable data Separate writable path required Yes after unlock Not applicable
Update model Replace/rebuild verified image and hash tree Normal filesystem update after unlock May require policy re-enrollment
Recovery need Known-good image and trusted root hash Passphrase/recovery key and header backup Non-TPM credential and TPM replacement plan

A common appliance design uses signed boot, dm-verity for an immutable OS, and LUKS2 for a writable data partition. It is more complex than a general-purpose Raspberry Pi OS installation and requires an image-building pipeline.

Validate a detected TPM

Install the minimum diagnostic tools:

1
2
sudo apt update
sudo apt install tpm2-tools

Record non-secret identity and capability information:

1
2
3
4
5
6
ls -l /dev/tpm*
tpm2_getcap properties-fixed
tpm2_getcap algorithms
tpm2_getcap pcrs
tpm2_pcrread sha256
tpm2_selftest --fulltest

Save the kernel binding and current boot log:

1
2
readlink -f /sys/class/tpm/tpm0/device/driver 2>/dev/null
journalctl -k -b --no-pager | grep -i tpm

Do not run tpm2_clear as a connectivity test. Clearing removes TPM-managed state and can make sealed keys or auto-unlock tokens unusable.

Recovery design

Before enrolling any production secret, write and test these runbooks:

Normal software update

  1. Confirm backups and recovery credentials.
  2. Record current PCRs and package/boot versions.
  3. Apply the update to a test device.
  4. Determine whether the policy accepts the new state.
  5. Authorize or re-enroll through the documented change process.
  6. Roll out gradually and monitor failures.

TPM failure or replacement

  1. Unlock with the offline recovery credential.
  2. Verify storage integrity and device identity.
  3. Remove the stale TPM token only after recovery succeeds.
  4. Install and validate the replacement module.
  5. Enroll it as a new token.
  6. Test both TPM and recovery unlock again.

Lost recovery credential

Stop and create a new tested recovery path while the volume remains accessible. TPM auto-unlock is not a substitute for escrow; if both the TPM state and remaining key slots are lost, the encrypted data is intentionally unrecoverable.

Benchmark without invented results

TPM operations are usually control-plane events, not bulk data encryption. LUKS data encryption runs through the kernel's cryptographic implementation; the TPM protects or releases key material.

Measure these separately:

Metric Baseline TPM/LUKS design
Power-on to application ready, seconds
Manual unlock time, seconds
TPM auto-unlock time, seconds n/a
Sequential read/write throughput
Random I/O p95 latency
Update acceptance/re-enrollment time n/a
Recovery drill time, minutes
Failed-state correctly rejected

Use the benchmark methodology, publish raw data, and identify the exact module, interface, kernel, firmware, storage, cipher, and test job.

Common mistakes

  • Assuming Raspberry Pi 5 contains a built-in TPM
  • Buying a module before confirming voltage, bus, Linux driver, and Device Tree support
  • Treating /dev/spidev0.0 as proof that a TPM works
  • Clearing a TPM that already protects keys
  • Binding LUKS to arbitrary PCRs without an event log or update plan
  • Removing the final passphrase after auto-unlock works once
  • Storing recovery material on the encrypted device
  • Claiming dm-verity encrypts data
  • Programming secure-boot OTP during an initial experiment
  • Claiming compliance from installing a TPM

FAQ

Does Raspberry Pi 5 have a TPM?

No discrete TPM is built in. Add an external TPM 2.0 module with a supported interface and Linux driver if the threat model requires one.

Is a TPM the same as Raspberry Pi secure boot?

No. Raspberry Pi signed/secure boot authenticates boot code using the platform bootloader and provisioned key. A TPM provides keys, PCRs, policies, and attestation functions.

Can a TPM encrypt an NVMe drive directly?

The normal Linux design uses LUKS/dm-crypt for bulk encryption. The TPM protects or releases the LUKS key; it is not the high-throughput data-encryption engine.

Does TPM auto-unlock protect a stolen running Raspberry Pi?

It mainly protects against storage removal or a policy-rejected boot state. An attacker controlling an already-unlocked system may access data through that system, so application access control and physical protection still matter.

Which PCRs should Raspberry Pi use?

There is no universal list. Choose PCRs only after identifying the measurement source, event log, normal update behaviour, and recovery process for the exact boot stack.