TPM Is No Silver Bullet: Pitfalls in Embedded Device Security
summary
TPM 2.0 gives ECC, RNG and sealed storage and systemd already supports TPM-backed disk encryption, but real devices must move keys into RAM for performance so secrets become extractable; bus snooping and simple interposer attacks can read or fake TPM traffic unless encrypted authenticated sessions are used, and pulling the TPM reset line or exploiting firmware/hardware bugs lets an attacker replay PCRs to bypass measured-boot seals. Use UEFI/verified boot, measured boot, IMA/EVM or SELinux, per-device keys, and consider fTPM in TrustZone or vendor HSMs where performance or physical tamper-resistance matters.
AI-written summary · about
chapters (16)
- 0:00TPM limitations on embedded devices
- 1:28Why TPM is not a universal security solution
- 3:55Core TPM features
- 7:33Three TPM use cases
- 11:30TPM implementation challenges
- 13:37Embedded threat models
- 16:23TPM performance limits
- 18:07Runtime integrity measures
- 20:38Physical TPM attacks
- 23:47Bus snooping attacks
- 25:36TPM reset attacks
- 26:19TPM firmware flaws
- 28:01Software TPM trade-offs
- 29:27Alternatives to TPM
- 30:33Summary for embedded TPM
- 31:15Q&A
related talks
51mSecuring Embedded Linux Systems with TPM 2.0
51mApplications of TPM 2.0
25mOverview and Recent Developments: TPM
33mfTPM: A Software-Only Implementation of a TPM Chip
28mThe TPM as an everyday security tool
42mRecent TPM Security Enhancements to the Linux Kernel
42mTPMs and the Linux Kernel: unlocking a better path to hardware security
29mThe Trusted Platform Module