TPM Sniffing
blog.scrt.ch
blog.scrt.ch
Obviously you'd never use something like this for trusted boot, but with Windows 11 requiring a TPM, and applications moving in the direction of "we refuse to run unless the environment is pristine" (e.g. video games with anti-cheat features, banking apps), it seems that something like this might eventually be useful for getting around DRM and restoring our ability to run whatever we want on machines that we own.
Ever since the beginning I have maintained the strong and unchanging opinion that everything TPM and "trusted computing" related is ultimately user-hostile and a threat to freedom, and it's disturbing to see that the worst nightmares are slowing becoming reality. It used to be drugs and terrorism. Now it's "security".
This whole "trusted computing" thing is treachery to the highest degree.
One of those primary keys is the Endorsement Key (EK). The EK is generally certified by the TPM vendor, and they include that certificate in the TPM.
You can generate your own EKs and certify them. All you need to trust them is: a computer, a TPM chip you trust is legit (probably because you validated its factory EKcert), and physical security while extracting the public key of your EK'.
> If any particular manufacturer would give you the option to just buy the keypair or make it possible to dump it somehow, they would surely get blacklisted.
Yes, well, Internet-scale security (e.g., TLS) relies on the reputation of trusted third parties. The problem is that the too-big-to-fail phenomenon applies here too: what are you gonna do, stop using the one CA everyone uses, the three or four browsers everyone uses, the three OSes everyone uses?
> This whole "trusted computing" thing is treachery to the highest degree.
Oh, it's hard.
The lack of end-to-end security between the CPU and the TPM is pretty nasty. The solution is to use an on-CPU/ME firmware TPM that runs in the ME or in a secure enclave like solution -- no bus to tap there!
But even then, there's just no way to attest to the security of a long-running host. Yes, there's things like dynamic root of trust measurement, but by and large it's hard even to establish what would be a trusted state since, among other things, there's no authoritative list of trusted firmware ROMs or anything like that.
And, oh, right, you meant far beyond the realm of TPMs. Yes, "trust" is really weak.
Is RSA "decryption" key a thing? It should be a key pair that allows for both encryption and decryption (though you may just care about one use case).
You can sign with an RSA private key, then validate the signature with the public key.
The two pairs of operations are very similar, but not quite the same due to differences in how padding is handled.
Nobody uses TPMs for DRM and nobody will start to, because TPM modules have a terrible security record for getting breached, and your GPU already does anything a DRM vendor would want with more widespead support and a better track record for hiding the keys and integrating it with control of the display path.
- the BMC and BIOS don't use encrypted sessions -- their communications with the TPM can be snooped (read: bitlocker keys can be stolen) and tampered with (read: malware can be excluded from PCR measurements with the help of a physical attacker)
- to authenticate the TPM when using encrypted sessions the BMC and BIOS would need to be able to store a public key for the TPM somewhere that isn't easy for malware to tamper with -- this means that even with encryption there would be a TPM impersonation / MITM attack
- even using encrypted sessions, if the attacker can force the TPM to reset without also resetting the CPU, then the attacker can make the PCRs match golden state (i.e., without the malware measured into the PCRs)
The first point is easy enough to address -- it's just a matter of code.
The second point is very difficult to address.
The third point would probably require changes to the CPU and additional design and standardization. It's just very difficult to strongly bind the TPM's resetCount to the CPU's state to ensure that both always reset together.
The only current solution to all three problems is to use firmware TPMs (fTPMs) where available.
Of course, for things like servers in secure racks in secure data centers, this is all really not a problem. But for laptops, it is.
If an fTPM is not available, there's always the possibility of adding physical protection to the bus (burying it deeper in the PCB, using resin, etc.).
The catch is that the other elements need to be able to store the secret, and they need to "pair" to the TPM when the motherboard is assembled. Also, scenarios concerning the legitimate replacement of the CPU need to be addressed. Those are all key management tasks that manufacturers are not good at in general... so here we are with unauthenticated sessions...
> The catch is that the other elements need to be able to store the secret...
Yes, that catch is the problem.
You can also authenticate the TPM to the host w/o authenticating the host to the TPM -- all you need is to be able to record the public key of a suitable primary (say, the EK) on the TPM that has fixedTPM and fixedParent set. Less messy than having to store a secret on the host, but not really enough to solve the reset issue.
LOL.
“I mean it’s low speed interface, Michael. How fast could it go? 25MHz?”
A query of "ThinkPad L440" on btdig yields the schematics and denies the scammers $20 - further denying funds to the DDoS SaaS or botnet rental they'd eventually have spend it on.
further denying funds to the DDoS SaaS or botnet rental they'd eventually have spend it on.
That is unfounded fearmongering. I suspect at least some of the funds go to paying neighbourly employees working at said OEMs so they'll share more schematics. Most if not all the schematics you see available are leaks, after all.
[1] Maybe if they do come across companies leaking them, they'll be do-gooding and closing those "holes" (and effectively fighting against right-to-repair), so perhaps it's better that they didn't.
That is easier... now you just need to magically know the OEM name of the board!
> That is unfounded fearmongering.
No, it is pretty solidly founded in logic: these operations have nearly zero operating expenses - profit is a function of visibility. What other scumbag activities shares that same model? You think some of the viagra spam proceeds are getting reinvested into medical research as well? These sites always lag availability elsewhere - they aren't the source for anything.
If there's an option to use TPM+PIN, then there should be an option to use smartcard+PIN.
It's not like TPM detects that there are hardware changes, Windows itself does and it can lock it down. Or if there is some mechanism it doesn't seem to help in this case, so who is it stopping?
Smartcards lack that data (they wouldn't know that somebody attached a Thunderbolt device that pretends to be a GPU but also comes with its own option ROM that installed a backdoor), so they serve a different threat model.
Smartcard readers can use any number of protocols (e.g. random USB readers implementing custom handshakes) until you finally get to the smartcard while TPMs have a select few number of protocols until you're talking to the TPM.
Arbitrary smartcard terminal drivers in your (secure) preboot software? maybe not.
libccid.so is 111KB, UsbccidDriver.dll is 81KB, I'm sure they would've managed if they wanted to.
It does mean that your average attacker won't be able to decrypt your laptop, but you could have easily done that without a TPM.
Lol, hilarious.
https://www.digikey.com/en/products/detail/pomona-electronic...
Great write up.
Short of a physically sealed path from the chip to all components that benefit from its knowledge (impossible on a desktop?), that can only be destructively accessed (triggering an alarm; like case-open switches) - I don't see how this can be defended against.
Newer CPUs (since about 5 years ago) have the TPM embedded in the CPU. Intel calls this PTT and AMD calls it fTPM.
You can also use a shared secret, but storing a secret on the host side is even harder than storing a write-once (at factory), read-only PK.
That would make it much harder as you'd have to MITM the communication, not just sniff it. Maybe impossible to decrypt if both the TPM and the chip it's communicating with use keys signed by the manufacturer.
Sounds pretty similar to TLS to me, in my non-expert opinion.
I don’t really see how it is possible to defend against that. But I don’t quite understand how the TPM checks what the CPU is doing either.
I don't think it checks what the CPU is doing at all. It just makes software able to check if the platform is signed by the manufacturer.
The way I understand it is that the keys are burned into the TPM at time of manufacture, and there is no way to extract those keys, software can only ask the TPM to encrypt/decrypt/sign/verify certain data using the keys.
The TPM can then be used to verify certain operations, eg to retrieve the key for an encrypted hard drive.
But it's all a trojan horse because the manufacturer is the one who controls the keys, not the user.
It's "trusted" in the sense that the platform is "trusted" by the manufacturer, not the user.
0: Know the public key of a fixedTPM+fixedParent primary key (e.g., the "endorsement key") on the TPM ahead of time[0].
1: call TPM2_CreatePrimary() in the clear to "create" that key (this is deterministic given a public template and factory seed secret to the TPM) -- you need the "handle" for this key
2: call TPM2_StartAuthSession() with that handle as the bindKey, and various other parameters
3: use that session in all subsequent commands.
Note: only one parameter of every command can be encrypted: the first parameter (command or response parameter) of type TPM2B_PRIVATE. The rest can be authenticated but are otherwise exchanged in plaintext. This is mostly just fine.
[0] Well, you could validate the EK's certificate, and then you only need to know the trust anchors for the TPM's vendor. It's roughly the same thing, but with more steps, and it lets you replace the TPM w/o having to re-learn a public key for it (which might be important).
What’s preventing an attacker from changing that key? Or is this just to change the attack from passive to active?
You can read the public key from the TPM. If you're using the endorsement key, it comes with a certificate issued by the vendor.
You can also pair the chip and the CPU at the factory or on initial powerup and have them communicate encrypted from thereon. This is a bit like the iPhone 13 display having some FaceID chip on it where a replacement with a wholly new display will leave FaceID non-functioning.
People will find a way. In the end, if a target gets big enough, someone will do it.
For the T2, at least macOS uses a key derived from useryou need both chip control _and_ user password to get in)
Windows does not, relying instead on TPM only in a default BitLocker configuration. (with a PIN option via Group Policy, not part of the regular flow)
As of why that's bad: https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...
https://scholar.google.com/scholar?as_q=%22Differential+Powe...