> voltage fault injection attacks

What's old is new again!

Amateur-me thinks that it would not be too hard to prevent such an attack: Have a voltage fault detection circuit at all (TPM-relevant) supply pins that hard-locks the chip until it gets power cycled, and have those circuits be powered by on-chip capacitors that survive just a little longer than their time-to-trigger. Would that be feasible?

Your idea roughly goes into the direction of what the industry has started implementing: Tunable Replica Circuits:

https://www.intel.com/content/www/us/en/newsroom/news/the-st...

This mitigation helps until the attackers stop confining themselves to the supply pins. You can do voltage fault injection through any exposed metal (or metal that can be made exposed), and the attacker can be entirely happy with attacks where they don't actually pull the voltage plane down, but instead just make some specific circuit a bit iffy by injecting an opposite voltage at some specific point and with low enough current that it's undetectable when looking at the chip as whole.

Approaches such as yours do make the attack require a lot more skill to accomplish.

If you spike the voltage on other pin you'd most likely trigger ESD protection which is just a diode that's connected to one of the power rails, and spike the chip's power supply.

Which would be detected if internal watchdog monitors voltages. But if spikes are short enough they might be pretty hard (or just expensive) to detect.

Note that the SPI bus sniffing attacks on dTPMs are simpler to mount (being passive) but also require direct access to the bus (motherboard), and unlike this attack can be prevented in software by knowing the public key of a primary key object on the TPM (e.g., the endorsement key) and using it to authenticate the TPM to the host.

That said, even a host using a dTPM with proper authentication of the dTPM has a problem if the SP is vulnerable to voltage fault injection attacks, because even though SPI bus sniffing wouldn't yield the unlocked FDE keys, the attacker presumably could get full control of the CPU and recover the unlocked FDE keys there.

In other words, the problem here is the voltage fault injection vulnerabilities in general. The fTPM part of it is not as big a deal as the total compromise of the whole system due to those voltage fault injection vulnerabilities.

I haven't looked closely at the TPM protocols lately, but I think this doesn't help against active bus attacks against a dTPM. The host can (I think) reboot the dTPM and send an arbitrary sequence of PCR changes to the dTPM, and the dTPM will believe it. And then the host can ask the dTPM to unseal something, and it will.

This won't help break a PIN that is protected by the dTPM, but it will fully break any protection relying on the host to verify a PIN. (Which is the default BitLocker behavior.)

TPM 2.0 Extended Access policies can be very complex. You can make it so that in order to unlock key objects in the TPM you have to have more than matching PCRs, but also a PIN, and the software on the host shouldn't provide the PIN if the PCRs don't match what it expects. Of course, TPM-using software is still too simple in this regard so that you're correct right now, but it doesn't have to be that way.