There's a number of issues with discrete TPMs and physical security. Before I describe them, there is good news: some CPUs can run a firmware TPM in an ME or a secure enclave, and using it does not involve a bus on a motherboard that could be hacked into. The problems with discrete TPMs:
- the BMC and BIOS don't use encrypted sessions -- their communications with the TPM can be snooped (read: bitlocker keys can be stolen) and tampered with (read: malware can be excluded from PCR measurements with the help of a physical attacker)
- to authenticate the TPM when using encrypted sessions the BMC and BIOS would need to be able to store a public key for the TPM somewhere that isn't easy for malware to tamper with -- this means that even with encryption there would be a TPM impersonation / MITM attack
- even using encrypted sessions, if the attacker can force the TPM to reset without also resetting the CPU, then the attacker can make the PCRs match golden state (i.e., without the malware measured into the PCRs)
The first point is easy enough to address -- it's just a matter of code.
The second point is very difficult to address.
The third point would probably require changes to the CPU and additional design and standardization. It's just very difficult to strongly bind the TPM's resetCount to the CPU's state to ensure that both always reset together.
The only current solution to all three problems is to use firmware TPMs (fTPMs) where available.
Of course, for things like servers in secure racks in secure data centers, this is all really not a problem. But for laptops, it is.
If an fTPM is not available, there's always the possibility of adding physical protection to the bus (burying it deeper in the PCB, using resin, etc.).
You can authenticate to a TPM via HMAC and a shared secret key, so also the two other points can be addressed with code.
The catch is that the other elements need to be able to store the secret, and they need to "pair" to the TPM when the motherboard is assembled. Also, scenarios concerning the legitimate replacement of the CPU need to be addressed. Those are all key management tasks that manufacturers are not good at in general... so here we are with unauthenticated sessions...
> You can authenticate to a TPM via HMAC and a shared secret key, ...
> The catch is that the other elements need to be able to store the secret...
Yes, that catch is the problem.
You can also authenticate the TPM to the host w/o authenticating the host to the TPM -- all you need is to be able to record the public key of a suitable primary (say, the EK) on the TPM that has fixedTPM and fixedParent set. Less messy than having to store a secret on the host, but not really enough to solve the reset issue.
- the BMC and BIOS don't use encrypted sessions -- their communications with the TPM can be snooped (read: bitlocker keys can be stolen) and tampered with (read: malware can be excluded from PCR measurements with the help of a physical attacker)
- to authenticate the TPM when using encrypted sessions the BMC and BIOS would need to be able to store a public key for the TPM somewhere that isn't easy for malware to tamper with -- this means that even with encryption there would be a TPM impersonation / MITM attack
- even using encrypted sessions, if the attacker can force the TPM to reset without also resetting the CPU, then the attacker can make the PCRs match golden state (i.e., without the malware measured into the PCRs)
The first point is easy enough to address -- it's just a matter of code.
The second point is very difficult to address.
The third point would probably require changes to the CPU and additional design and standardization. It's just very difficult to strongly bind the TPM's resetCount to the CPU's state to ensure that both always reset together.
The only current solution to all three problems is to use firmware TPMs (fTPMs) where available.
Of course, for things like servers in secure racks in secure data centers, this is all really not a problem. But for laptops, it is.
If an fTPM is not available, there's always the possibility of adding physical protection to the bus (burying it deeper in the PCB, using resin, etc.).