Your browser doesn't support the features required by impress.js, so you are presented with a simplified version of this presentation.

For the best experience please use the latest Chrome, Safari or Firefox browser.

Extending TPM Trust
from the Kernel to Userspace

James Bottomley
jejb@HansenPartnership.com
@jejb@mastodon.online
About Me

 

Container evangelist

Open Source Advocate

Kernel Developer

  • SCSI Subsystem Maintainer
  • PA-RISC architecture Maintainer
  • Containers
  • TPM
History and Background

TPM is often a discrete chip in a system sitting on a system bus (LPC I2C)

Can also be "firmware" but often run on separate chips (Management Engine, AMD Security Processor)

Threats to the TPM include man-in-the-middle or Interposer attacks

Passive Interposer : Only snoops

Active Interposer : inserts and alters

Solution is something called encryption and HMAC with sessions

Sessions in the Kernel

Need to encrypt session salt to a hierarchy key (EK, ...)

Problem: Kernel asks the TPM for the key but has no means of verifying it

Could use the EK cert

But not all TPMs have one in the right NV index

And we'd have to program the kernel with the growing list of manufacturer CA certs to verify it.

Plus EK won't defend against reset attacks

Solution is to use null key

https://docs.kernel.org/security/tpm/tpm-security.html

And verify post boot using the EK signing key stored in the encrypted filesystem.

User TPM Trust Problems

All TPM using applications also have session salting problems

Pretty much the same as the kernel

Apps have a richer environment

but most don't bother to verify hierarchy keys

mainly because it's still a lot of hassle

So all security is mostly an illusion

can we reuse the null key certification the kernel did on boot?

Using the Null Seed

The kernel publishes the null seed name in sysfs

So that boot verification can confirm it

This can also be simply consumed by an application as a file

The application can ask the TPM for the null key

and calculate the name to compare against the one in sysfs

If they match the application needs do nothing further

because the null name should already have been certified on boot

Which is much simpler than the application trying to attest or certify a TPM key

Plus the application now also inherits reset protection

What Needs to Happen in Distros?

The openssl_tpm2_engine project contains the tools

https://git.kernel.org/pub/scm/linux/
kernel/git/jejb/openssl_tpm2_engine.git/

On install, the distro should collect the signing EK name and save it to an ideally immutable file.

attest_tpm2_primary --eksign > /etc/eksign.name

Then it should attest with the EK certificate (if the TPM has one)

If the TPM has no EK certificate then we stop here and have TOFU security, otherwise ...

tssnvread -ha 01c00002 -ocert tpm.crt

Then tpm.crt needs to be verified against the manufacturere certificate

and finally use a makecredential/activatecredential round trip to attest the signing EK

attest_tpm2_primary --attest tpm.crt --name /etc/eksign.name

Then on every boot the null seed name can be certified using the signing EK

attest_tpm2_primary --certify null --name /etc/eksign.name /sys/class/tpm/tpm0/null_name

Once this last step happens, the null name sysfs file is authoritative for the entire boot cycle

So any application can now simply use it without having to run any attest/certify.

Conclusions

Using null seed salted sessions protects data in-flight from interposers

Using the NULL seed also fully protects the kernel from reset attacks

After boot verification proves the boot was fully secure

Any user TPM tool can also use the NULL key for salting

And simply verify its easily calculated name against the sysfs file

Meaning full safety is easily extended to every TPM tool

Presented using impress.js by Bartek Szopka


https://hansenpartnership.com/Impress-Slides/LSS-2026/
Thank You!
Questions?