TPMs and the Linux Kernel: unlocking a better path to hardware security
summary
A Python request_key plugin demonstrates reproducible, per‑application keys derived from the TPM seed and application metadata, removing the need to store wrapped blobs; symmetric and asymmetric keys can be rederived on demand and signatures match after recreation. Integration relies on Linux key retention service and kernel crypto sockets (available since Linux 6.2 for symmetric use), performs remotely on real TPM hardware, and surfaces limits: TPM latency, current symmetric‑only kernel path, and a proof‑of‑concept implementation that works but needs kernel hardening for key‑namespace protection.
AI-written summary · about
chapters (19)
- 0:00Introduction
- 1:05Understanding TPMs
- 2:31Challenges of using TPMs
- 5:38Resource manager and libraries
- 8:11Integration hurdles
- 10:49Access and permission issues
- 13:02Linux kernel key store
- 15:26Key store example
- 19:01Key types in the kernel
- 20:52Trusted and wrapped keys
- 22:59Linux crypto API and patches
- 26:16Asymmetric TPM keys
- 27:45Key management limitations
- 30:16Derived keys approach
- 33:19Implementing custom modules
- 36:15Proof of concept demo
- 39:39Advanced key binding
- 42:59Future kernel development
- 45:44Conclusions and Q&A
related talks
47mTPMs and the Linux Kernel: unlocking a better path to hardware security
45mTPMs & The Linux Kernel: Unlocking A Better Path To Hardware Security
43mTPMs and the Linux Kernel: unlocking a better path to hardware security
42mTPMs and the Linux Kernel: unlocking a better path to hardware security
51mApplications of TPM 2.0
42mRecent TPM Security Enhancements to the Linux Kernel
53mWhat is Linux kernel keystore and why you should use it in your next application
28mThe TPM as an everyday security tool