AI
Key Storage and the TPM’s Core Functions
The TPM stores private keys that never leave the chip. Eric generated an ECDSA key. The private key stays in TPM memory while API calls produce signatures. The TPM also holds arbitrary secrets like disk encryption keys and measures boot processes: firmware hashes, bootloader hashes, and secure boot keys. It provides remote attestation to prove key residency and boot state to other servers. The Go package opens /dev/tpmrm0 to send command packets through the Linux kernel.
Attestation: Proving a Key Lives on the TPM
The endorsement key is derived from a deterministic seed. Feeding the same template parameters to the same TPM always produces the same key pair. Manufacturers sign EK certificates stored in NVRAM, chaining device identity back to the factory. Credential activation lets a server encrypt a challenge to a decryption-only key, returning the challenge and key metadata. A simpler form, credential certification, just asks the key to sign some data. Platform certificates chain EK certificates to a specific laptop serial number, in theory.
Boot State: PCRs and the Event Log
The TPM has 24 platform configuration registers that store rolling hashes during boot. Each component extends PCRs by concatenating the old state with a new digest and hashing. The process is one-way. No going back to an old state. Remote verifiers request a quote: a signature over both the PCR state and a challenge, signed by an attestation identity key. The event log records every boot event in order. Replaying the log should match the quoted PCR values.
Disk Encryption and TPM Policies
BitLocker binds disk encryption keys to PCR 7 and 11. PCR 7 captures the secure boot state. PCR 11 falls in the operating system range of 8 through 15. During boot, the UEFI writes secure boot data to PCR 7. The boot manager accesses the disk encryption key if PCR 7 matches. It immediately extends PCR 11, preventing any future program from reading the key. Eric noted Microsoft’s own documentation suggests adding a user PIN. Discrete TPMs leak BitLocker keys over the bus, an article that resurfaces every few years.
Linux TPM Standardization Through systemd
Google’s internal Linux distribution, GLinux, required custom secure boot certificates and custom PCR data. The work never generalized to upstream Debian. In 2022, systemd maintainer Lennart Pottering published a call for standardized TPM boot across Linux distributions. The UAPI group now defines unified kernel images. These combine the bootloader, initramfs, and kernel into a single signed binary. The group is also defining standard Linux TPM PCR assignments so event logs become consistent across distributions.
Notable Quotes
the TPM is an API specification. it’s not, you know, one specific piece of hardware. Eric Chiang · ▶ 3:11
300 400 milliseconds totally normal Eric Chiang · ▶ 7:59
if I just change all the event types to something your parser doesn’t understands then append my own malicious events uh that totally passes all the replay Eric Chiang · ▶ 18:33
I see a lot of companies reaching out for TPMs as like a solution to their problems and it’s very much like a now you have two problems kind of world Eric Chiang · ▶ 26:55
Key Takeaways
- The TPM is an API specification, not a single hardware device.
- BitLocker binds disk encryption keys to PCR 7 and 11 with no user PIN required.
- Linux boot measurement is standardizing through systemd and the UAPI group.
About the Speaker(s)
Eric Chiang is the co-founder and CTO of Oblique, an IGA startup. He has 10+ years experience in cloud identity, OS security, and hardware attestation. He worked in Google’s Security org for over six years, wrote Dex at CoreOS, and co-lead the Kubernetes Auth Special Interest Group.