Small TPM with a Power of Big HSM

The talk opens with how hardware-backed encryption has been used in payments and enterprise settings, from a card in an isolated room to shared backend appliances. These systems are costly and shared across many services, so the speaker argues that a small TPM 2.0 chip, often already present on modern boards, is a better fit for medical devices. Secrets worth protecting include service passwords, web server and SSH keys, and public keys used to verify signed updates.

The middle covers the TPM 2.0 stack on Linux: user-space tools, the access broker and resource manager daemon, kernel drivers, the hardware layer, and encrypted context files on disk. The speaker explains how primary keys anchor a key hierarchy and why persisting them raises a chicken-and-egg problem for their own protection. File permissions per principal are proposed for granular access, since Linux policy frameworks do not map cleanly onto the TPM stack. Platform configuration registers can bind keys to boot integrity.

The takeaways stress process as much as technology: work with product teams to decide what truly needs protection, avoid putting everything under one primary key, and give each service, application and user its own key. Code obfuscation is treated only as an added layer. In the Q&A, the speaker suggests crypto abstraction layers so post-quantum algorithms can be adopted later.