What really is the difference between firmware TPM and a discrete one and should it be trusted more?

Question

What really is the difference between a physical TPM and any implementation of a fTPM?

I get that both adhere to the same specification and in my mind should be the same thing, but then, I don't understand why there even are 5 or so different types of TPM - discrete, integrated, firmware, virtual, and, well, software, though here the distinction is a little bit more clear - having used one, it really is more like a simulator.

The advantage of a hardware device makes sense in theory -> the EK is literally etched in stone, so as the presence of a EK is required by specification I suppose fTPM just have the key saved somewhere.

Can the claim, that "a physical TPM offers most security" be backed up?

Let's imagine I put 100% trust in a system with a discrete TPM and in this hypothetical world such system is 100% secure. Do I have any reason to trust iTPM/fTPM/vTPM any less and is their purpose by definition the same?

Answer 1

It is very hard to quantify security and justify trust. Before you read on: think about what you want to protect against whom. Make a risk analysis.

I have heard mainly two justifications why physical TPMs are more secure.

1) Separation/Isolation

Generally, the better two systems are isolated, the harder it is to spread compromisation. For example, you can hardly attack network #2 from network #1 if they are not physically connected. If they were connected via a firewall, it might be possible, but still hard. The least secure option would be no separation at all.

The same applies to the isolation of the host machine and its TPM. A user-space TPM simulator would hardly be isolated at all and the least secure option. A fTPM is isolated much better, but it's still running on the same chip. A hardware TPM is much more isolated and therefore presumably better protected against software attacks from host malware.

Of course there is a whole variety of hardware attacks which is not affected by this isolation. Again, think about your assets and risks.

2) Certification

Physical TPMs are usually certified. That alone is not a guarantee for security. However, it ensures that certain requirements are met verifiably. Therefore it is evidence at least some level of security.

In particular, the Common Criteria Evaluation takes hardware security against e.g. timing, glitching and side-channel attacks into account. Currently, there are only physical TPMs which are Common Criteria evaluated (see here under Trusted Computing).

Answer 2

Indeed an appropriately designed and tested discreet TPM (dTPM), utilising a secure cryptoprocessor might be more secure against software attacks, in large due to the separation of function and smaller attack surface.

A recent concern of mine though, is about malicious hardware. In particular, the TPM relies on the CPU to provide the necessary measurements that the TPM then utilises. But, how can these measurement be authenticated to be true? There have been various spoofing attacks through probing the communication bus. Moreover, someone could, hypothetically, even replace the CPU with a malicious one that spoof measurements etc. (a proof-of-concept has been published in an academic paper).

While the TPM's primary purpose might not be to protect against hardware attachs (the well known "if they own the hardware, it's game over"), there could be some ways to provide some mitigations, by somehow "binding" a TPM so the system's configuration, the CPU in particular.

One way would be to utilise Physically Unclonable Functions and extend then into one of the dTPM's PCRs. This has, too, been shown as proof-of-concept in an academic article.

Another way, that doesnt require changes to the current specifications, would be firmware TPM. Assuming that the fTPM actually functions correctly, with the fTPM functions independently from the rest of the CPU etc., then I would say that an fTPM is actually MORE secure than a dTPM, since the Measurement Agent that provides the PCR valus is actually on the same chip and the verifier that verifies said PCRs. Basically, if someone tampers with the CPU, they also tamper with the fTPM inside said CPU, which should, ideally, destroy the secrets.

Answer 3

An interesting discussion. There are definitely different levels of assurance that can be calculated and used in a risk assessment related to the type of TPM (i.e., discrete, integrated, firmware, virtual, and, software. What certification is important to that negotiation as well. In the case of FIPS or EAL LOA, there are discrete assurances one can use to measure risk and apply a level of trust. It is not binary, especially in the case of TPM. I have yet to see a reliable assertion wrt to the TPM level(s) of protection(s). So if you a software TPM meets your risk profile, any TPM should be adequate. But what if your risk tolerance demands more assurance, say a discrete HW TPM certified at a particular LOA? I have not witnessed a real-time solution to confirm a particular TPMs LOA.