4 ms·
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 at
by cryptonector 4y ago
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.
- amluto 4y agoI 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.)
- cryptonector 4y agoTPM 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.