SPI is a communication protocol for embedded systems and is extremely common amongst virtually all hardware. Due to its simplicity, there is no encryption option for SPI. Any encryption must be handled by the devices themselves. At the time of this writing BitLocker does not utilize any encrypted communication features of the TPM 2.0 standard, which means any data coming out of the TPM is coming out in plaintext, including the decryption key for Windows
And apparently Linux is not doing too hot on this regard either:
As we can see, parameter encryption simply isn’t used in practice, and except for safeboot none of the solutions enforce PIN/MFA by default.
CPU doesn’t have any secure storage, so it can’t encrypt or authenticate comms to the TPM. The on-CPU fTPMs are the solution, the CPU then has the secure storage.
LUKS is still vulnerable to this attack if you enable autodecrypt using TPM.
This attack is based on the vulnerability that the CPU and TPM communicates uses plain text. This attack is not new:
https://dolosgroup.io/blog/2021/7/9/from-stolen-laptop-to-inside-the-company-network
And apparently Linux is not doing too hot on this regard either:
https://www.secura.com/blog/tpm-sniffing-attacks-against-non-bitlocker-targets
Because of course
CPU doesn’t have any secure storage, so it can’t encrypt or authenticate comms to the TPM. The on-CPU fTPMs are the solution, the CPU then has the secure storage.
That make sense, CPU has no place to store private keys, since that is the functionality of TPM…
Unless there is a firmware solution, which defeats the purpose of a standalone tpm.