The Unclear Impact

jookia reads about TPMs

as someone who hangs around in the embedded land, TPMs are kinda weird to me. secure boot and keys fused in to a die that can't be tampered with easily make more sense, with vulnerable software running outside trustzone. it's not a TPM, but it does the job

so why x86 different? well today i l read the TPM 2 standard. or at least the part 1: architecture. i'm not too interested in all the details

jookia reads about TPMs

from what i gather beforehand is that TPMs are big and complex beause it's intended for dealing with trust between multiple vendors. for instance, if you can secure boot linux and secure boot windows, you still want to be able to partition secrets between them. you don't want a specific vendor controlling a system's key store

jookia reads about TPMs

so the system will build sets of chains of measurements using one-way hashes the accumulate. this accumulated hash becomes the key to unlock a secret that requires these hashes.

it's a bit strange since these hashes aren't based on secret information, like it's no secret that you boot windows with secure boot. the security comes from being forced to hash with data from trusted parties that aren't going to put up with your shit

jookia reads about TPMs

i can't shim between UEFI and windows because UEFI will snitch on me to the TPM. i can't remove measurements, only add them.

another way to look at it is how things would work without a TPM. UEFI could have a 'getmysecret' resident function that would check your settings and give you your secret if the settings and loaded executable are correct.

then the bootloader would have its own secret store, and the kernel would have its own secret store, and so on

jookia reads about TPMs

none of this would be tamperproof, so you'd need a hardware security module that somehow lets multiple vendors do the same thing of only revealing secrets based on the chain of software that's loaded. using measurements and hashes does that

jookia reads about TPMs

so for example if you create a secret bound to your current system's boot chain and use something like full disk encryption, you'd be protected against rootkits that slip in between UEFI and your decryption process.

but uh, wait. isn't that what secure boot is for? i just described how to lock a key to hardware with tamper protection without secure boot enabled.

jookia reads about TPMs

so why have secure boot at all? well... it turns out locking to booted executables sucks if you want to update. say you download a new kernel. if you reboot, the TPM wouldn't unlock the secret for you. and TPMs explicitly prevent you from guessing what another boot's hashes would be, so you can't unlock now and lock it with your future boot's code. the only solution is to unlock now, reboot and lock again.

jookia reads about TPMs

this isn't great because there's a gap of time where you could have tampering. but this is only a problem if you measure the boot using hashes of executable binaries. you could instead use signed binaries and measure the signer instead. so if you don't change between vendors, you'll be fine. but that kind of implies keeping signing keys around ... forever?

jookia reads about TPMs

so secure boot will handle all the key management and just report that the system securely booted. it means instead of measuring against executables, you're trusting UEFI to stop tampering using some cryptographic means.

secure boot can be good for other reasons such as authentication, but with a TPM this is how you handle ensuring secrets are unlocked by trusted software

jookia reads about TPMs

this all sounds a little dicey when you think about it. if someone changes your BIOS settings, you can't boot any more. that's not great. but never fear, things are more granular than that. TPMs profile fat stacks of individual registers. so let's go through a few of them

PCRs 0 measures your machine's hardware firmware on the motherboard and expansions, so this includes ACPI, UEFI drivers, your system's POST code. so your hardware status

jookia reads about TPMs

PCR 1 measures your UEFI CPU microcode update, UEFI boot options and order, static SMBIOS tables, security-relevant UEFI settings, security-relevant CMOS data, table of devices, chassis intrusion, EFI variables that impact configuration.

it does NOT measure serial numbers, automatically updated registers like clocks

jookia reads about TPMs

PCR 2 measures extra UEFI boot services, run time drivers, firmware for things that don't run on the CPU. so this is intended for all the junk that runs in UEFI
PCR 3 measures the settings for these services and drivers
PCR 4 measures how your went. what devices were booted from, etc.
PCR 5 measures shit to do with PCR 4. so partition tables

jookia reads about TPMs

PCR 6 is reserved for motherboard manufacturers, with the spec suggesting vendors will have to brawl over it (in different words)

PCR 7 contains secure boot details, such as the secure boot variable, the public keys, other security databases. basically all your secure boot settings.

PCRs 8-15 are for the OS, PCR 23 is for application support, and 16 is for debug

jookia reads about TPMs

the TPM also supports being shared, it has multiple 'localities'. these are pretty cool as they aren't reset across soft resets.

though, once you've gotten to your OS, your PCR registers are already fairly hardware-dependent. there's no real way to say as an app 'i trust the hardware, but i want to tie my secrets to measurements by the kernel or core OS configuration.

intel TXT/AMD SVM let you create a dynamic root of trust for this which is pretty great

jookia reads about TPMs

TPMs require maintenance of an event log, so you can verify the values that were actually hashed (by re-hashing them yourself to see that they're not made up). this kind of stuff is used for attestation, not hiding or storing secrets. so you can prove to someone online that your TPM has had certain values set, by the trusted stacks of your system. this could be used for example to show you're running a vendor kernel or OS

jookia reads about TPMs

all in all TPMs mean the software running on your machine has the ability to prove it's running in a certain configuration to a remote party, and store secrets that require a specific configuration to gather those secrets

jookia reads about TPMs, THE GOOD NEWS

what is this useful for in practice? well, TPMs aren't really meant to stop malware. that's what things like secure boot and friends are for.

TPMs are mainly meant to authenticate your system. for instance, authenticating to the TPM that you're running correct software to get a secret, for key signing or disk encryption.

jookia reads about TPMs, THE BAD NEWS

that's at least the best angle i can think for good use of TPMs: a hardware security token.

the reality is, TPMs have always been intended to lock down systems and prove they're locked down remotely so services can trust you with secrets. this doesn't authenticate the user, it authenticates the system, or at least the software running on it, defined by a few vendors.

jookia reads about TPMs, THE BAD NEWS

How this actually gets used depends on the APIs the OS provides to applications. If say, Windows 11 provides a way to authenticate running untampered executables in a secure environment to servers, it might be game over for things like third party clients or cheats for online services.

jookia reads about TPMs, THE BAD NEWS

If you think of secure boot being required as a bastard move, imagine that being checked remotely and OSes having more cool details to attest/snitch on your behalf.

re: jookia reads about TPMs, THE BAD NEWS

@jookia If I hold my own SecureBoot keys (and removed the authorization of Microsoft’s key), that’d render the TPM useless for vendors to validate my computer, while making it useful for me to validate my own computer, wouldn’t it? I mean, my own bootloader/kernel could hash arbitrary data into the higher numbered PCRs (not necessarily the hash of the code it is about to run), so if the SecureBoot keys are not intact, all bets are off for everyone but the party who signed the bootloader (and therefore trusts what it does). Of course, windows doesn’t boot after that, but that seems like a minor loss (it can probably still boot inside a VM).

replies
0
announces
0
likes
0

jookia reads about TPMs, opinions

Don't get me wrong, I like TPMs and secure boot. They're tools and all they do is provide guarantees strong about your system. The problem here is the mismatch between what users want to do and what developers want to let users do.

I don't think anyone would object to their computers proving their video game client isn't running disallowed modifications if it meant there weren't any more aimbots.

But that probably won't happen.

re: jookia reads about TPMs, THE BAD NEWS

@kristof Yep. You wouldn't need to remove the authorization of Microsoft's key, you can just show using a TPM it was your key that signed your bootloader, things like that.

You could run Windows in a VM, but it couldn't attest to remote services that it's Windows on real hardware.

jookia reads about TPMs, opinions

@jookia
The PCR thing is pretty clever. In theory you could skip secure boot entirely and know you're not rootkitted via the fact that your harddrive decrypts.

Ideally, all of this kernel update signature check stuff would be implemented in a static chainloader which gets the secrets from the TPM, sig checks the kernel, and then loads it, handing the secrets over.

And ideally you'd just have 1 PCR, "the code", if config can make the code insecure, fix the code

jookia reads about TPMs, opinions

yeah

jookia reads about TPMs, opinions

@jookia
And a TPM would be so simple if it was stateless except 1 secret and 1 PCR.

But I think all of this complexity is just a reflection of the organizational insecurities of these companies and the split-mind between the "security" they claim they want and the social control they actually want.

jookia reads about TPMs, opinions

@cjd @jookia
in the end of the day you can hash whatever you load and sig check whatever you load, but the chain of trust has to start somewhere.

It can start either in an on-die one-time programmable ROM (eg. e-Fuses), in which case when you the signature/hash doesn't check out, your device is bricked

Or it can start in a TPM, in which case when the signature/hash doesn't check out, you don't get to decrypt the keys, but you can start over with fresh ones.

jookia reads about TPMs, opinions

@jookia
side note:
to my best knowledge,
1. if you can reset the TPM without resetting the CPU, you can tell it any lies and it will know no better
2. the TPM is connected to the motherboard with a regular header, not unlike the one raspi uses for GPIOs

jookia reads about TPMs, opinions

@wolf480pl well the CPU can't attest for you since its secrets are in the die

jookia reads about TPMs, opinions

@jookia it can?
1. put private key in the die
2. put a hardware signing engine in the die
3. never allow software to access the key, only sign stuff with it
4. never run untrusted software (secureboot) or have a flag that locks out the keys until a reboot before you run untrusted software
5. sign proofs with that key using hardware engine and send it to Nintendo

jookia reads about TPMs, opinions

@jookia wait, was this a reply to the "TPM is connected weakly" post, or to the other one about root of trust?

I don't see how "cpu can't attest for you" makes sense in the context of the post it's replying to...

jookia reads about TPMs, opinions

@wolf480pl the one about root of trust, sorry

jookia reads about TPMs, opinions

@jookia oh, ok, then yeah, I think it can attest the way I described.

jookia reads about TPMs, opinions

@wolf480pl @cjd @jookia You can't really 'start in the TPM' - you've got to be measuring from the first non-ROM code that you run, otherwise someone could insert some code that did something evil, and then perform standard measurements into the TPM - only if the 'chain of trust' is anchored somewhere knownare you safe.

jookia reads about TPMs, opinions

@penguin42 @cjd @jookia
the point is, the ROM doesn't need to know what a valid 2nd stage bootloader looks like. It doesn't contain a master hash of any sorts.

jookia reads about TPMs, opinions

@wolf480pl @penguin42 @jookia
I think the idea is you want to have a minimal boot rom which is actually e-fuse'd and truly read only, and then that rom should hash the next thing to boot, pass the hash to the TPM and then boot it.

Or, I mean, you could put the actual boot rom ON the TPM, it would be a different interface to the motherboard but it could be done...

jookia reads about TPMs, opinions

@wolf480pl @penguin42 @jookia
Nice thing about integrating TPM and boot ROM is that you don't need the CPU to be not-an-idiot before you've loaded in it's management engine, because you have another CPU which knows exactly the hash of said management engine.

jookia reads about TPMs, opinions

@cjd @penguin42 @jookia
> have a minimal boot rom which is actually e-fuse'd

No, usually you have a minimal boot rom which is actually mask ROM. I.e. hardwired in the fab.

> that rom should hash the next thing to boot, pass the hash to the TPM and then boot it.

yes

jookia reads about TPMs, opinions

@cjd @penguin42 @jookia
At that point you could as well have a service processor like a SPARC.