TPMs and the Linux Kernel: unlocking a better path to hardware security - Ignat Korchagin

This talk was recorded at NDC TechTown in Kongsberg, Norway. #ndctechtown #ndcconferences #developer #softwaredeveloper
Attend the next NDC conference near you:
ndcconferences...
ndctechtown.com/
Subscribe to our TH-cam channel and learn every day:
/ ‪@NDC‬
Follow our Social Media!
/ ndcconferences
/ ndc_conferences
/ ndc_conferences
#platform #security #linux #api
TPMs have been present in modern laptops and servers for some time now, but their adoption is quite low. While operating systems do provide some security features based on TPMs (think of BitLocker on Windows or dm-verity on Linux) third party applications or libraries usually do not have TPM integrations.
One of the main reasons of low TPM adoption is that interfacing with TPMs is quite hard: there are competing TPM software stacks, lack of key format standardization and many operating systems are not set up from the start to make TPM easily available (TPM device file is owned by root or requires privileged group for access). Even with a proper software stack the application may have to deal with low-level TPM communication protocols, which are hard to get right.
In this presentation we will explore a better integration of TPMs with some Linux Kernel subsystems, in particular: kernel keystore and cryptographic API. We will see how it allows the Linux Kernel to expose hardware-based security to third party applications in an easy to use manner by encapsulating the TPM communication complexities as well as providing higher-level use-case based security primitives.

[@MarekKnapek]

Authenticated symmetric encryption (for example AES-GCM) is not needed to be done all at once. The kernel would need to hold small amount of state between chunk encryption request (like 16 or 32 bytes or so).