> If attacker have physical access, the discrete TPM is an attack surface anyway and even a known attack already.
If you're wondering what they mean by this, [1] has been around since 2018. It's not unusual for a motherboard to put the TPM on a removable module, so you don't even have to desolder the chip to MITM the communications.
The most recent Intel and AMD CPUs have "firmware TPMs" that run in the CPU's so-called "trusted execution environment" so there's no I2C to interpose. Of course, that doesn't mean you're protected against attackers who have physical access to the machine; they can simply install a keylogger.
Funnily enough, in TPM 2.0 there's way around MITM attacks like that - you can establish encrypted connection between TPM and CPU, which outside first-time configuration (which should happen in controlled environment anyway) should provide reasonable roadblock to successful MITM attack.
But CPU-side software needs to use it, and without default well-known keys...
Doesn't work either: To establish the secure connection, you need some way to verify the other end (through public keys, certificates). That verification happens before any measurements can be done securely, so it can be bypassed.
The PIN is the important part there, encrypted sessions (and/or EK cert verification) without PIN are not much more then obfuscation, and defeated by both the interposer attack, and the tweezer attack. (Or the TPM hack to rule them all, e.g. desoldering the chip and connecting it to a microcontroller you control)
I supposse a PIN is a slight improvement over a regular password, but a big appeal of TPM FDE in my opinion is unattended unlock.
I think discrete TPMs don't really have a future in systems that need robust system state attestation (both local and remote) against attackers with physical access. TPMs should be integrated into the CPU/SoC to defend against such attacks.
Problem is that the BCM and the BIOS/UEFI and every component talking to the TPM all need to store one (or more) public keys for it (and the corresponding templates and/or save files) in order to set up encrypted sessions to the TPM.
I'd buy you an replacement laptop of the same model and then install a rendering of your boot process and password prompt on it. Doing a switcheroo and waiting in my bunker until the fake sends me the password you entered.
The screen/keyboard is not authenticated to the user, and TPM is not capable of fixing that.
It doesn't require some state actor to do that. Just money.
I doubt your physical keyboard's connection to the motherboard is encrypted (I'd guess USB, I2C or maybe even PS/2 internally). I would also not be surprised if you can get small in-line sniffers that an attacker, with physical access for half an hour, could hide in your laptop.
All bets are off if your attacker is determined and has physical access.
and by recent, TPM was external last in gen 8 of intels, so this attack works on cpus released last in October 2017. That's almost 7 years ago. Most organizations have a 3-5 year replacement schedule.
TPM seems beyond useless to me. I wanted to protect a certificate and private key for a Java application, so that you can't just copy the pkcs12 file and use it elsewhere, but there is no decent API in Java to use a TPM 2 chip. So the road ends there... The only protection now is a hardcoded passphrase in the application but you don't have to be a genius to figure that out...
Discrete (i.e., chip) TPMs (dTPMs) are slow. They are way too slow to use as HSMs.
Firmware TPMs (fTPMs) are faster, but I doubt they're really fast enough to use as an HSM.
There are TPM APIs for Java, so you can do this, but it's not surprising that the Java keystore providers lack builtin support because of the performance issues.
Ideally fTPMs should come with EKcerts and platform certificates and they would be very fast and as secure as (more so than) dTPMs. Then using fTPMs as HSMs might take off.
its meant for secureboot, but i suppose the rest of the platform, built usually by other ppl than ones who designed the TPM, needs to also implement it correctly. an d as this article shows, this is not an easy feat. (this attack seems silly but it's really clever tbh. good inspired idea likely based in lots of domain expertise). - if you can protect the boot-chain with secureboot, what you can do for your private key, what for example AV vendors do, is have a (efi?)driver that contains the certificate, which is a boot-driver protected by secure-boot. - for windows this might require Microsoft cooperation to assign you a driver level so other stuff can't disable it (otherwise it's still tricky and possible to get around your protections likely). (windows -> process protection light / telam drivers). Optionally you could also have the certificate provided by an EFI applcation somehow that's signed / secured by secureboot. (could drop it on disk somewhere, efi partition is easily accessible...).
If the chain is protected by the tpm, this method if implemented correctly through the whole chain should protect your cert and pkey.
that being said _should_ is the keyword,. i dont think any platform really managed to escape all attacks, though a lot in this area do need hw access (the tweezers previously implemented by the author :)).
Heh I always thought that TPM was there to secure anything. If it's only meant for secure boot then I understand the poor tooling and absence of APIs to use the thing properly inside applications.
It's used to establish a root of trust. If your operating system is modified, it fails to validate and the TPM doesn't release the secrets. If your BIOS is modified, it fails to validate and the TPM doesn't release the secrets. If your CPU is modified, it can tell the TPM what it wants to hear and get the secrets even if the BIOS or OS is modified.
For some people, this is a useful increase in security. Those people set up their own TPM according to their own rules. For the rest of us, who had one forced on us by Microsoft, it's just more anti-right-to-repair.
Each TPM having an unique certificate, you may use that to trace a specific machine to a specific user. Game developers could use that to ban (toxic) players from an online service, for example.
Not the only uses, but certainly all of the widespread implementations of trusted hardware just haven't been able to avoid that temptation of privileging the manufacturer while securing against the user themselves. Every little hole is another setback that keeps the designers/implementers working on this layer instead of starting to tighten the noose on the next one.
TPMs are a cryptographic coprocessor with added platform state attestation functionality. That can for example be used locally for secure secret storage that is only available in certain platform states, or remotely to certify the state of a device trying to access a corporate network.
Of course TPMs can be (ab)used for DRM, but the same property in general to many ideas in cryptography. We still don't say AES or RSA are tools designed to restrict your rights.
In reality TPMs are almost always used to (attempt to) protect the user's data over restricting them.
I would argue that the discrete chip variation of them aren't very good at this (and even less good at DRM), but a lousy implementation doesn't mean the concept is bad. (As Foxboron mentioned earlier in this thread, discrete TPMs can still act as reasonably good "discounted" SmartCards, but they are bad at platforms state attestation.)
In fact I would have much preferred if the industry embraced the measured boot idea more instead of mainly pushing stricter verified boot schemes.
Of course TPMs can be (ab)used for DRM, but the same property in general to many ideas in cryptography. We still don't say AES or RSA are tools designed to restrict your rights.
AES and RSA are just algorithms, not implementations. I'd compare TPMs to HDCP, AACS, or CSS (the DVD one) instead.
A bit tangential, but it’s a bit shocking how consistently bad firmware for x86 motherboards and laptops is, as is most visible in the UEFI configuration screen. It makes me wonder if a new entrant in the motherboard/laptop space couldn’t make a name for themselves by simply caring about the quality of their firmware and trying to make it good.
I have to believe there are hardware engineers out there who know locking people out of their devices is essentially bad, and so they leave in those tweezer based attacks on purpose.
Although, designing against physical attacks is very difficult, so I guess there’s no need to imagine a good-hearted conspiracy of conscientious hardware folks.
The fundamental operation in hardware engineering is the digital signal, pulling a pin to one or zero - which is all the tweezer attack does. It's comparable to writing a byte of memory. Imagine how hard software security would be if your adversaries could write arbitrary data to your process: there's no ASLR or even an MMU to randomize trace layouts on physical circuit boards.
Ok, I understand how a TPM gets attached to a muxable GPIO block.
But, did no one stop and question whether a TPM should have been on a dedicated block that couldn't be reprogrammed rather than assuming there wouldn't be bugs or whatever in the GPIO pin muxing? Never mind all the additional complexity of assuming page permissions access/etc to shared purpose MMIO regions?
The CPUs and OSs (other than Windows 11) support operation without any TPM.
So either the pin is configurable, or you've wasted a pin that could otherwise be used for decorating the motherboard with RGB LEDs.
Also, the pin layout has to be standardized by the socket specification (eg "LGA 2011"), which may have to retain compatibility for a decade or more. This strongly favors defining reconfigurable over fixed-function pins.
Readit News
If you're wondering what they mean by this, [1] has been around since 2018. It's not unusual for a motherboard to put the TPM on a removable module, so you don't even have to desolder the chip to MITM the communications.
The most recent Intel and AMD CPUs have "firmware TPMs" that run in the CPU's so-called "trusted execution environment" so there's no I2C to interpose. Of course, that doesn't mean you're protected against attackers who have physical access to the machine; they can simply install a keylogger.
[1] https://github.com/nccgroup/TPMGenie
But CPU-side software needs to use it, and without default well-known keys...
You either need an interactively provided PIN, or a TPM integrated into the CPU/SoC to be secure in such a scenario.
Bitlocker is traditionally the implementation susceptible for this attack, but for that I'll just defer to Chris Fenner.
https://www.dlp.rip/tpm-genie
I supposse a PIN is a slight improvement over a regular password, but a big appeal of TPM FDE in my opinion is unattended unlock.
I think discrete TPMs don't really have a future in systems that need robust system state attestation (both local and remote) against attackers with physical access. TPMs should be integrated into the CPU/SoC to defend against such attacks.
How would that attack work if someone stole my Ryzen powered laptop with full disk encryption, TPM2.0 and secure boot with firmware password enabled?
The screen/keyboard is not authenticated to the user, and TPM is not capable of fixing that.
It doesn't require some state actor to do that. Just money.
All bets are off if your attacker is determined and has physical access.
Firmware TPMs (fTPMs) are faster, but I doubt they're really fast enough to use as an HSM.
There are TPM APIs for Java, so you can do this, but it's not surprising that the Java keystore providers lack builtin support because of the performance issues.
Ideally fTPMs should come with EKcerts and platform certificates and they would be very fast and as secure as (more so than) dTPMs. Then using fTPMs as HSMs might take off.
I know it's awful, but probably not as awful as a hardcoded passphrase.
If the chain is protected by the tpm, this method if implemented correctly through the whole chain should protect your cert and pkey.
that being said _should_ is the keyword,. i dont think any platform really managed to escape all attacks, though a lot in this area do need hw access (the tweezers previously implemented by the author :)).
It's just not widely used for other applications.
For some people, this is a useful increase in security. Those people set up their own TPM according to their own rules. For the rest of us, who had one forced on us by Microsoft, it's just more anti-right-to-repair.
Also, I'd be pretty frustrated if I was sharing a PC with someone and they got me banned from a game.
Stallman was right: https://www.gnu.org/philosophy/can-you-trust.en.html
(Last few paragraphs.)
See also: https://gabrielsieben.tech/2022/07/29/remote-assertion-is-co...
Of course TPMs can be (ab)used for DRM, but the same property in general to many ideas in cryptography. We still don't say AES or RSA are tools designed to restrict your rights.
In reality TPMs are almost always used to (attempt to) protect the user's data over restricting them.
I would argue that the discrete chip variation of them aren't very good at this (and even less good at DRM), but a lousy implementation doesn't mean the concept is bad. (As Foxboron mentioned earlier in this thread, discrete TPMs can still act as reasonably good "discounted" SmartCards, but they are bad at platforms state attestation.)
In fact I would have much preferred if the industry embraced the measured boot idea more instead of mainly pushing stricter verified boot schemes.
AES and RSA are just algorithms, not implementations. I'd compare TPMs to HDCP, AACS, or CSS (the DVD one) instead.
Ah, the tweezers strike again, just not for Nintendo this time. Truly the most universal hardware hacking tool.
Although, designing against physical attacks is very difficult, so I guess there’s no need to imagine a good-hearted conspiracy of conscientious hardware folks.
Deleted Comment
But on essentially all existing UEFI systems you can trivially overwrite the "db" keystore in flash and install anything you please.
Also most (all?) UEFI systems are not locked to Windows and allow customizing the keystore via the firmware console interface anyhow.
All of them.
The Secured Core machines still allows you to reset Secure Boot into user mode as mandated by the spec.
But, did no one stop and question whether a TPM should have been on a dedicated block that couldn't be reprogrammed rather than assuming there wouldn't be bugs or whatever in the GPIO pin muxing? Never mind all the additional complexity of assuming page permissions access/etc to shared purpose MMIO regions?
So, IMHO this starts as a hardware bug.
So either the pin is configurable, or you've wasted a pin that could otherwise be used for decorating the motherboard with RGB LEDs.
Also, the pin layout has to be standardized by the socket specification (eg "LGA 2011"), which may have to retain compatibility for a decade or more. This strongly favors defining reconfigurable over fixed-function pins.