Skip to content

TPM and Measured Boot

Technical Overview

The Trusted Platform Module (TPM) is a dedicated security chip (or firmware component) that provides cryptographic services, secure key storage, and — most critically for boot security — a tamper-evident measurement log of the boot process. TPM enables a class of security properties that are impossible to achieve with software alone: the ability to prove to a remote party what software is running on a machine, and the ability to bind secrets (like disk encryption keys) to a specific, known-good boot configuration.

Measured boot is the process of recording a cryptographic hash of each component in the boot chain — firmware, bootloader, kernel, kernel modules — into TPM registers in a one-way, append-only fashion. These records cannot be erased without rebooting, and rebooting resets them, making it impossible to retroactively forge a clean measurement log. The combination of measurement, attestation, and sealing provides the foundation for cloud security, full-disk encryption automation, and hardware-rooted trust.

Prerequisites

  • UEFI boot phases (see 02-uefi.md)
  • Secure Boot and PKI concepts (see 03-secure-boot.md)
  • LUKS disk encryption basics
  • Asymmetric cryptography (RSA, ECC): key pairs, signing, verification
  • Hash functions: SHA-1, SHA-256 properties

Historical Context

The Trusted Computing Group (TCG), originally called the Trusted Computing Platform Alliance, was founded in 1999 by Compaq, HP, IBM, Intel, and Microsoft. The first TPM specification (version 1.1) was published in 2001, and the first TPM chips shipped in enterprise laptops around 2003.

TPM 1.2, published 2003, became the widely deployed version through the 2000s and early 2010s. It used SHA-1 for PCR (Platform Configuration Register) hashing and RSA-2048 for cryptographic operations. SHA-1's weaknesses made TPM 1.2 increasingly problematic.

TPM 2.0, published 2014 and massively revised in 2016, was a complete redesign: algorithm-agnostic (SHA-256 default, with support for multiple hash algorithms simultaneously), improved key hierarchy, better NV storage, and enhanced authorization. Windows 11 mandates TPM 2.0, effectively forcing hardware upgrades and ending TPM 1.2's relevance.

AMD and Intel both offer firmware TPM implementations: Intel Platform Trust Technology (PTT) and AMD fTPM, which implement the TPM 2.0 specification in firmware (inside the Management Engine or Platform Security Processor respectively) rather than a dedicated chip. These are ubiquitous on modern consumer hardware.

TPM Architecture

TPM Hardware Architecture

  +------------------------------------------+
  |  TPM Chip (or firmware implementation)   |
  |                                          |
  |  +-------------------+                   |
  |  | PCRs (24 × SHA-256|                   |
  |  |  registers)       |                   |
  |  | PCR[0]: FW code   |                   |
  |  | PCR[1]: FW config |                   |
  |  | PCR[2]: option ROM|                   |
  |  | PCR[3]: option ROM|                   |
  |  | PCR[4]: bootloader|                   |
  |  | PCR[5]: GPT/MBR   |                   |
  |  | PCR[6]: resume    |                   |
  |  | PCR[7]: SB state  |                   |
  |  | PCR[8]: kernel    |                   |
  |  | PCR[9]: initrd    |                   |
  |  | PCR[10]: kernel   |                   |
  |  | PCR[11-15]: OS    |                   |
  |  | PCR[16-23]: debug |                   |
  |  +-------------------+                   |
  |                                          |
  |  +-------------------+                   |
  |  | Key Hierarchy     |                   |
  |  | EK (Endorsement)  |                   |
  |  | SRK (Storage Root)|                   |
  |  | AK (Attestation)  |                   |
  |  | User keys         |                   |
  |  +-------------------+                   |
  |                                          |
  |  +-------------------+                   |
  |  | NV Storage        |                   |
  |  | (persistent data) |                   |
  |  +-------------------+                   |
  |                                          |
  |  +-------------------+                   |
  |  | Crypto Engine     |                   |
  |  | RSA, ECC, AES     |                   |
  |  | HMAC, SHA-256     |                   |
  |  | DRBG (RNG)        |                   |
  |  +-------------------+                   |
  +------------------------------------------+
  | TPM Interface Layer (TIS / CRB)          |
  +------------------------------------------+
  | Host Bus (LPC / SPI / I2C)               |
  +------------------------------------------+

Platform Configuration Registers (PCRs)

PCRs are the core mechanism of measured boot. Each PCR is a fixed-size register (32 bytes for SHA-256) with a specific property: it can only be extended, never written directly.

Extend operation:

PCR_new = Hash(PCR_old || new_measurement)

This means each PCR is a running digest of all measurements made into it. The initial value at boot is a fixed constant (all zeros for SHA-256 banks). Once a measurement is extended into a PCR, the only way to "reset" it is to reboot (which reinitializes all PCRs to their boot-time values).

This property is critical: a malicious piece of software cannot retroactively change what was measured. It can extend new values, but it cannot undo previous extensions. The final PCR value at any point represents the cumulative hash of all measurements up to that point.

PCR allocation (x86, TCG PC Client Platform Firmware Profile):

PCR Contents
0 SRTM (Static Root of Trust Measurement): firmware code
1 Firmware configuration data
2 Firmware option ROM code
3 Firmware option ROM configuration
4 IPL (Initial Program Loader): boot manager + bootloader code
5 Boot manager configuration + GPT partition table
6 State transitions and wake events
7 Secure Boot state (Secure Boot enabled/disabled, db, dbx, PK, KEK)
8 Kernel (set by GRUB2 or UEFI stub)
9 initrd, kernel cmdline (set by GRUB2 or UEFI stub)
10 Managed by OS (IMA — Integrity Measurement Architecture)
11-15 OS-defined
16 Debug PCR (resettable in debug mode)
23 Application-specific

Measured Boot Sequence

Measured Boot: Component → PCR Measurement

  CPU Reset
      |
      v
  UEFI SEC Phase
      | Measures: UEFI firmware code → PCR[0]
      |           Platform firmware configuration → PCR[1]
      v
  UEFI DXE Phase
      | Measures: Option ROM code → PCR[2]
      |           Option ROM config → PCR[3]
      |           Secure Boot policy state → PCR[7]
      |             (enabled/disabled, db contents, dbx, PK, KEK)
      v
  UEFI BDS Phase (Boot Device Selection)
      | Measures: Boot manager code (BDS itself) → PCR[4]
      |           Boot entry variables (BootOrder, Boot####) → PCR[5]
      v
  GRUB2 (or systemd-stub) loaded from ESP
      | UEFI measures GRUB2 (as loaded EFI app) → PCR[4]
      | GRUB2 measures:
      |   kernel image → PCR[8]
      |   initrd image → PCR[9]
      |   kernel cmdline → PCR[8] or [9]
      v
  Linux kernel
      | Kernel reads TPM event log (passed by UEFI via ACPI table)
      | IMA subsystem extends PCR[10] as files are accessed
      v
  OS Running
      | PCR[0-9] immutable until next reboot
      | PCR[10] continues accumulating IMA measurements

Accessing the TPM event log:

# View TPM event log (what was measured, when)
cat /sys/kernel/security/tpm0/ascii_bios_measurements

# Or using tpm2-tools:
tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements

TPM Key Hierarchy

TPM 2.0 organizes keys in a hierarchy with three roots:

TPM 2.0 Key Hierarchy

  Endorsement Hierarchy
  +--------------------------------+
  |  EK (Endorsement Key)          |
  |  - Created at manufacture      |
  |  - RSA-2048 or ECC-P256        |
  |  - Certificate from TPM vendor |
  |  - Private key NEVER leaves    |
  |    TPM                         |
  |  - Used to prove TPM identity  |
  +--------------------------------+

  Storage Hierarchy
  +--------------------------------+
  |  SRK (Storage Root Key)        |
  |  - Created by OS/owner         |
  |  - RSA-2048 or ECC-P256        |
  |  - Parent of all storage keys  |
  |  - Sealed objects hang here    |
  +--------------------------------+
       |
       +-- LUKS2 Sealing Key (sealed to PCRs)
       +-- Application keys
       +-- etc.

  Platform Hierarchy
  +--------------------------------+
  |  Platform keys                 |
  |  - Used by firmware only       |
  |  - Not accessible to OS        |
  +--------------------------------+

  Attestation Keys (AK, child of EK hierarchy):
  +--------------------------------+
  |  AK (Attestation Identity Key) |
  |  - Asymmetric signing key      |
  |  - Used to sign PCR quotes     |
  |  - Provably linked to EK       |
  |    (via Privacy CA or Direct   |
  |     Anonymous Attestation)     |
  +--------------------------------+

TPM Attestation

Attestation allows a remote party to verify what software is running on a machine. The process:

Remote Attestation Flow

  Machine Under Attestation           Remote Verifier
  ─────────────────────────           ───────────────
                                       1. Challenge with nonce
  2. TPM_Quote(PCR selection,
               nonce,
               AK private key)
     → Returns: quoted PCRs,
                AK signature,
                event log
                                       3. Verify:
                                          - AK signature valid
                                          - AK linked to genuine EK
                                          - PCR values match expected
                                            (golden values for this SW)
                                          - Nonce prevents replay
                                       4. If valid: release secret
                                          (config, key material, etc.)

Using tpm2-tools for attestation:

# On attesting machine: generate AK
tpm2_createek --ek-context ek.ctx \
              --key-algorithm rsa \
              --public ek.pub

tpm2_createak --ek-context ek.ctx \
              --ak-context ak.ctx \
              --key-algorithm rsa \
              --hash-algorithm sha256 \
              --signing-algorithm rsassa \
              --public ak.pub \
              --private ak.priv

# Create quote (sign PCR values)
tpm2_quote --key-context ak.ctx \
           --pcr-list sha256:0,1,2,3,4,7,8,9 \
           --message nonce.bin \
           --signature quote.sig \
           --pcrs pcr_values.bin \
           --qualification $(openssl rand -hex 16)

# Verify quote (on verifier)
tpm2_checkquote --public ak.pub \
                --message nonce.bin \
                --signature quote.sig \
                --pcrs pcr_values.bin \
                --qualification <nonce>

TPM Sealing

Sealing binds a secret (like a disk encryption key) to a specific PCR state. The secret can only be unsealed if the PCRs contain the expected values — meaning the system booted through the exact same software chain that existed when the secret was sealed.

TPM Sealing Concept

  Seal (enrollment):
    Secret (LUKS key) + PCR policy (expected values)
      ↓ TPM encrypts secret with sealing key
    Sealed blob stored on disk

  Unseal (boot time):
    Sealed blob → TPM verifies current PCR[0..9]
    If PCR values match policy: TPM decrypts and returns secret
    If any PCR mismatch: TPM refuses to unseal (returns error)

  Attacker scenario:
    Attacker replaces kernel with malicious one
      ↓
    PCR[8] = Hash(old_PCR[8] || Hash(malicious_kernel)) ← different
    PCR values no longer match sealing policy
    TPM refuses to unseal LUKS key
    Disk remains encrypted
    ✓ Attack foiled

systemd-cryptenroll — LUKS2 + TPM2:

# Enroll TPM2 as LUKS2 keyslot
systemd-cryptenroll --tpm2-device=auto \
                    --tpm2-pcrs=0+7 \    # PCR0 (firmware) + PCR7 (Secure Boot state)
                    /dev/sda2

# More comprehensive PCR binding:
systemd-cryptenroll --tpm2-device=auto \
                    --tpm2-pcrs=0+1+7 \
                    /dev/sda2

# /etc/crypttab entry for automatic unlock:
luks-<uuid>  UUID=<uuid>  -  tpm2-device=auto

# Test unlock:
systemd-cryptsetup attach luks-test /dev/sda2 - tpm2-device=auto,headless=1

When PCRs match the sealed policy, the LUKS partition opens automatically at boot without a passphrase prompt. When PCRs don't match (tampered bootloader, different kernel, disabled Secure Boot), the passphrase is required.

fTPM — Firmware TPM

Firmware TPM implementations execute the TPM specification in firmware rather than a dedicated chip:

Intel PTT (Platform Trust Technology): Runs in Intel ME (Management Engine), a dedicated microcontroller on Intel platforms. Enabled/disabled in UEFI firmware settings. Available on Intel platforms since Skylake (2015).

AMD fTPM: Runs in AMD PSP (Platform Security Processor), ARM Cortex-A5 core integrated in the CPU die. Available since AMD Ryzen (Zen, 2017).

fTPM advantages: - No additional chip cost - Available on virtually all modern consumer CPUs - Same TCG 2.0 API as discrete TPM

fTPM disadvantages: - Trust depends on firmware (Intel ME, AMD PSP) security - Vulnerabilities in ME/PSP can compromise fTPM: CVE-2023-20569 (AMD Inception) and CVE-2023-20588 (AMD Divide By Zero) affect AMD PSP - If firmware is compromised, the TPM root of trust is also compromised - Performance: software-based crypto slower than dedicated TPM ASICs

Discrete TPM chips (Infineon, STMicroelectronics, NationZ) provide stronger isolation — the TPM is a separate processor with its own power and clock, making physical attacks harder and ensuring firmware compromise of the CPU does not directly compromise TPM.

Cloud vTPM

Cloud providers offer virtual TPM implementations for VMs:

AWS Nitro TPM: Hardware-backed TPM 2.0 for EC2 instances. Backed by Nitro Security Chip (physically separate from host CPU). Available with --launch-template tpm-version=2.0.

Azure vTPM: Virtual TPM for Azure VMs, backed by Microsoft Pluton technology. Part of Trusted Launch VMs. Enables LUKS with TPM sealing in cloud VMs.

GCP vTPM: Virtual TPM for Google Cloud Shielded VMs. Backed by secure enclaves in Google's infrastructure.

The key question for cloud vTPM: if the hypervisor is compromised, is the vTPM compromised? Generally yes — vTPM is software running on the host. The threat model is "protect against compromised guest OS", not "protect against compromised hypervisor." For the latter, confidential computing (AMD SEV-SNP, Intel TDX) is the answer.

TPM Attacks

PCR Reset via DMA (Before Measurement)

The classical TPM attack: PCRs are reset to zero at power-on. If an attacker can trigger a DMA read of TPM-sealed data before the firmware has extended the expected values into PCRs, the PCRs will be at their reset values and the TPM will unseal the data.

Attack vector: cold-boot attack. Physical access to a running system, cool DRAM to retain state, reboot with attacker firmware that reads sealed data before PCRs are extended.

Mitigation: TPM locality — only measurements at locality 0 (CPU directly, not software-accessible) can extend PCR[0-7]. Kernel cannot reset PCR[0-7]. The window between power-on and PCR extension is protected by the firmware's security architecture.

Evil Maid Attack

Attacker replaces bootloader on disk while owner is away. On next boot: - PCR[4] extends with measurement of malicious bootloader - PCR[4] value changes - TPM-sealed LUKS key cannot be unsealed - System prompts for passphrase - If user enters passphrase, attacker's malicious bootloader captures it

Mitigation: Secure Boot prevents loading unsigned bootloaders. TPM sealing without Secure Boot (PCR7 not bound) is insufficient — PCR4 binding alone does not prevent a swap to different signed bootloaders.

TPM Sniffing (Discrete TPM Only)

The LPC/SPI bus between CPU and discrete TPM chip is observable with a logic analyzer. Data on this bus includes TPM responses, which may include sealed key data. Several researchers have demonstrated extracting BitLocker keys from TPM 1.2 chips using this technique.

CVE-2021-1234 (not a real CVE — illustrative): Intel i915 laptop: LUKS key extracted via TPM SPI bus sniffing in ~30 minutes with ~$27 of hardware.

Mitigation: TPM 2.0 with parameter encryption (sessions with HMAC auth), which encrypts the command/response payload so the bus sniffer sees only ciphertext. Must be explicitly enabled by the TPM caller — systemd-cryptenroll and tpm2-tools support this.

Firmware Attacks on fTPM

Since fTPM runs in ME/PSP firmware, firmware vulnerabilities can expose fTPM secrets:

  • AMD fTPM vulnerability (2023): Researchers demonstrated fTPM key extraction via voltage glitching on AMD platforms
  • Intel ME vulnerabilities: Multiple CVEs in Intel ME allow arbitrary code execution in ME, which can read fTPM internal state

IMA — Integrity Measurement Architecture

IMA is the Linux kernel's in-OS measurement subsystem, extending PCR[10]:

# Enable IMA in kernel config: CONFIG_IMA=y
# Policy file: /etc/ima/ima-policy

# IMA rules (measure files before execution):
measure func=FILE_MMAP mask=MAY_EXEC uid=0
measure func=BPRM_CHECK mask=MAY_EXEC uid=0
measure func=MMAP_CHECK mask=MAY_EXEC uid=0

# View IMA measurements
cat /sys/kernel/security/ima/ascii_runtime_measurements
# Format: PCR# template-hash template-name file-hash filename

# Appraise (verify) files against stored hashes:
# CONFIG_IMA_APPRAISE=y
# Store expected hash in file xattr:
setfattr -n security.ima -v <hash> /path/to/file

IMA extends PCR[10] with the hash of every file executed or mapped with execution permission. This creates an OS-level audit log that is as tamper-evident as firmware measurements.

systemd-cryptenroll + TPM2

Full example of TPM2-based disk encryption with systemd:

# Setup (enrollment time):

# 1. Check TPM2 device
ls /dev/tpm0 /dev/tpmrm0

# 2. List current LUKS keyslots
cryptsetup luksDump /dev/sda2

# 3. Enroll TPM2 with PCR binding
# PCRs: 0 (firmware), 7 (Secure Boot state), 11 (future: kernel image)
systemd-cryptenroll \
  --tpm2-device=auto \
  --tpm2-pcrs=0+7 \
  /dev/sda2
# Prompts for existing LUKS passphrase to authorize enrollment

# 4. Update /etc/crypttab
# luks-<uuid> UUID=<uuid> - tpm2-device=auto,tpm2-pcrs=0+7

# 5. Update initramfs (must include TPM2 support)
dracut --force

# Recovery:
# If PCR mismatch: cryptsetup luksOpen /dev/sda2 -- (enter passphrase)
# Then re-enroll if system has legitimately changed

# Reset TPM enrollment (remove TPM keyslot):
systemd-cryptenroll --wipe-slot=tpm2 /dev/sda2

Debugging Notes

TPM not detected:

ls /dev/tpm* /dev/tpmrm*
# If missing: check BIOS/UEFI settings (TPM may be disabled)
# AMD: "AMD fTPM" setting in UEFI Security section
# Intel: "Intel Platform Trust Technology (PTT)" or "TPM Device"
dmesg | grep -i tpm

PCR values unexpected:

# Read all PCRs:
tpm2_pcrread sha256

# Compare against expected (from event log):
tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | \
  python3 -c "import json,sys; log=json.load(sys.stdin); ..."

Sealed secret won't unseal (PCR mismatch):

# Determine which PCR changed:
# - Read current PCRs
# - Compare against PCRs from last successful boot (stored by systemd-pcrmachine-id)
cat /var/lib/systemd/pcrs.json  # if systemd-pcrlock is configured

# systemd 255+: systemd-pcrlock for PCR policy management
systemd-pcrlock log

Passphrase prompt after BIOS update: Firmware updates change PCR[0] (firmware measurement). LUKS key sealed to PCR[0] will not unseal after firmware update. Solution: re-enroll after each BIOS update, or exclude PCR[0] from binding (use PCR[7] only — Secure Boot state).

Security Implications

TPM is not a magic bullet: - TPM prevents offline attacks (disk stolen from powered-off machine) - TPM does not prevent: attacks after successful boot, hypervisor compromise, social engineering - TPM sealing with weak PCR policy (e.g., PCR[1] only) is easily bypassed

PCR selection tradeoffs: - More PCRs = stronger binding but more fragile (breaks on firmware updates, kernel updates) - Fewer PCRs = more permissive but weaker security - PCR[7] (Secure Boot state) is the minimum recommended binding for general use - PCR[0] binding breaks on every BIOS update

Endorsement Key privacy: EK is a permanent identifier for a TPM. Sharing raw EK identity leaks hardware identity. TPM 2.0 Direct Anonymous Attestation (DAA) allows attestation without revealing EK identity. Privacy CA is an alternative: a trusted third party certifies that an AK belongs to a legitimate TPM without revealing which TPM.

Performance Implications

TPM 2.0 operation latency: - PCR Extend: 1–5ms (discrete), 0.5–2ms (fTPM) - PCR Read (one register): 1–3ms - RSA-2048 sign (quote generation): 100–500ms (discrete), 50–200ms (fTPM) - AES-128 encrypt (1KB): 1–5ms

Boot time impact with TPM sealing: - Firmware measurements: transparent (done by firmware) - GRUB PCR extension: ~10ms per extension (PCR 8, 9) - LUKS unsealing at initramfs: 200–600ms (includes TPM communication)

For disk encryption with systemd-cryptenroll, the TPM unseal adds ~300ms to boot time — acceptable for servers, noticeable but tolerable for desktops.

Failure Modes

TPM lockout: After too many failed authorization attempts, the TPM enters dictionary-attack protection and becomes unavailable for a period. tpm2_dictionarylockout can reset this with owner authorization.

Sealed blob corruption: Corrupted sealed blobs cannot be recovered — the sealed secret is lost. Always maintain a backup passphrase keyslot in LUKS when using TPM sealing.

Firmware update + PCR[0] binding: Every BIOS update changes PCR[0]. If LUKS is sealed to PCR[0], disk becomes unreadable after BIOS update without pre-planning (re-sealing before update, or having recovery passphrase).

vTPM state loss: Cloud VMs that are migrated, snapshotted, or cloned may have vTPM state inconsistency. vTPM state must be preserved with the VM. Snapshotting and restoring a VM with TPM-sealed disk may prevent unsealing.

Modern Usage

TPM has moved from an enterprise-only feature to standard consumer hardware: - Windows 11: Requires TPM 2.0; uses TPM for BitLocker, Windows Hello, Credential Guard - Linux LUKS + systemd-cryptenroll: Increasingly the default for full-disk encryption on Fedora, Ubuntu, and Arch systems with LUKS2 - Confidential Computing: AMD SEV-SNP and Intel TDX use TPM-like attestation at the VM boundary — the guest VM can attest its state to a cloud owner

Future Directions

  • systemd-pcrlock (systemd 255+): Advanced PCR policy management that handles firmware updates gracefully by predicting future PCR values and creating flexible policies
  • DICE (Device Identifier Composition Engine): Alternative to TPM for embedded devices, using CPU-internal secrets and key derivation to achieve similar guarantees without a separate chip
  • Post-quantum TPM: NIST PQC algorithms need to be integrated into TPM firmware; current RSA/ECC will be vulnerable to quantum computers
  • TPM + Confidential VMs: The combination of hardware TPM (in the CPU) + confidential execution environment (SEV-SNP, TDX) provides end-to-end integrity from firmware to application

Exercises

  1. PCR Inspection: On a system with TPM 2.0, read all PCRs with tpm2_pcrread sha256. Reboot and read again. Identify which PCRs changed and which remained the same. Correlate changed PCRs with events in the TPM event log. Explain why PCR[4] or PCR[8] might differ between two clean boots.

  2. Measured Boot Event Log Parsing: Using tpm2_eventlog, parse the binary event log from /sys/kernel/security/tpm0/binary_bios_measurements. For each event type, identify the component being measured, the hash value, and the PCR bank. Manually compute one PCR's expected value by replaying the extend operations.

  3. TPM2 Sealing Lab: Using tpm2_create and tpm2_unseal, seal a secret string to PCR[7] (Secure Boot state). Verify unsealing succeeds. Then change the Secure Boot state in UEFI firmware settings. Reboot and attempt to unseal. Confirm the unseal fails.

  4. systemd-cryptenroll Integration: On a VM with a LUKS2-encrypted disk, enroll the vTPM as a LUKS keyslot using systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7. Update /etc/crypttab and rebuild initramfs. Verify automated unlock works on reboot. Then deliberately modify a measured component (e.g., add test_kernel_param to cmdline) and verify that TPM unsealing fails and the system falls back to passphrase.

  5. Remote Attestation Simulation: Set up a minimal attestation workflow using tpm2-tools. On the "attesting" machine: create an EK, create an AK, create a quote over PCRs 0,4,7,8. On a "verifier" machine: verify the quote signature against the AK public key, compare PCR values against expected reference values. Simulate an attack by modifying one PCR value in the quote and confirm verification fails.

References

  • TCG TPM 2.0 Specification: https://trustedcomputinggroup.org/tpm-library-specification/
  • TCG PC Client Platform Firmware Profile Specification (PCR usage): https://trustedcomputinggroup.org/
  • tpm2-tools: https://github.com/tpm2-software/tpm2-tools
  • tpm2-tss (TCG Software Stack): https://github.com/tpm2-software/tpm2-tss
  • systemd-cryptenroll man page: https://systemd.io/CRYPTENROLL/
  • systemd-pcrlock: https://www.freedesktop.org/software/systemd/man/latest/systemd-pcrlock.html
  • "A Practical Guide to TPM 2.0" — Will Arthur, David Challener (Apress 2015)
  • Intel PTT documentation: https://www.intel.com/content/www/us/en/support/articles/000055786/
  • AMD fTPM vulnerability: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3002.html
  • TPM SPI sniffing (BitLocker): https://dolosgroup.io/blog/2021/7/9/from-stolen-laptop-to-inside-the-company-network
  • DICE specification: https://trustedcomputinggroup.org/work-groups/dice-architectures/
  • Linux kernel drivers/char/tpm/ — TPM driver implementation
  • security/integrity/ima/ — IMA subsystem