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 "sessions"

How Do Sessions Work?

Establish a secret shared key (SessionKey) between the TPM and the user

Derive rolling encryption and HMAC keys from this and exchanged nonces

Initial SessionKey is either bound (shared secret)

or salted (encrypted secret)

Sessions were added to all Linux Kernel TPM transactions in 6.10

How do you get the public key to encrypt the salt to?

Most toolkits (TSS) simply ask the TPM

Problem: An Active interposer can intercept the ask

And supply its own public key

meaning it can decrypt the salt and thus decrypt all the sessions

So all security is gone

Most TSSs don't make it at all obvious to the User that this has happened

None provides any verification of the key

By sitting on the same bus at the TPM the interposer can toggle the reset line

TPM policies for things like key release rely on PCR values

but a fundamental assumption here is that PCRs never reset until the machine does

Toggling the reset line causes all PCRs to go back to zero

Allowing a malicious entity to rebuild the PCR with the policy required values

discrete TPMs ship with a manufacturer signed certificate that validates the Endorsement Key

But the key it certifies cannot be used to certify other TPM objects

TPMs generate primary keys from seeds using a KDF

Allows for crypto agility and keys with different properties

One property is whether keys are signing or encryption keys

The TPMs can only certify objects with signing keys

The EK certificate always certifies an encryption (not signing) key

So Why don't EK certificates certify signing keys?

The Trusted Computing Group (TCG) got badly burned by backlash against TPMs tracking users

FSF called it "Treacherous Computing"

and criticised the TPM as an agent in your PC acting on behalf of others

To counter this the TCG tried to introduce privacy preserving features

Not allowing manufacturers to ship signing certificates was one of these

Because signing attestations with a single well known key uniquely identifies you

The TCG allowed for the creation of arbitrary numbers of signing keys (called AKs) per TPM

Each AK would be certified by a PrivacyCA using the EK certificate

Only the PrivacyCA could link the EK cert to the AK, and thus track the user

So the PrivacyCA would have to be trusted by both the user and the party receiving the attestation

They introduced special TPM operations (MakeCredential ActivateCredential) just for this

So the PrivacyCA would have to be trusted by both the user and the party receiving the attestation

Problems

The PrivacyCA idea never caught on, so none exists today.

Even if it did exist, early boot can't use it (no internet)

Early boot also can't validate EK certificates (every manufacture is their own CA)

Plus firmware TPMs often don't even have EK certificates

So given all the issues need a new scheme

Use the NULL primary for session salting

TPM2 has four hierarchies

Interesting property: NULL seed changes on every reset

so any key in the NULL hierarchy is invalidated on a reset

Save NULL key once at boot and use it for every session

If there's ever a reset the session salt will fail decryption (because the seed changed)

So we can detect a reset attack immediately

Also export the NULL primary name in a sysfs file

A TPM name is simply the hash of the public area of the key

so a short(ish) unique id for a key

Which can be verified by more sophisticated means after boot

Meaning the kernel doesn't know if it's safe at boot

But we have enough information to completely verify safety after the fact

So I've developed a tool in the openssl_tpm2_engine toolkit to do all this easily

attest_tpm2_primary

 --eksign export the name of the signing EK

 --attest verify the signing EK from the certificate

 --certify certify other TPM objects

https://git.kernel.org/pub/scm/linux/ kernel/git/jejb/tpm2-interposer.git

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

Using the NULL seed 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