Re:AMD's Firmware TPMs Vulnerable to Hardware Attacks, Defea...
by amluto on Tuesday May 02, 2023 @03:00PM
(#35792503)
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.)
Re:AMD's Firmware TPMs Vulnerable to Hardware Attacks, Defea...
by cryptonector on Tuesday May 02, 2023 @04:03PM
(#35793339)
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.
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.