faulTPM: Exposing AMD fTPMs' Deepest Secrets

Games for sure, the exam software is disappointing.

This isn't a TPM spec vulnerability. This is a CPU (SP) vulnerability, and it's devastating regardless of whether you use a TPM or not.

TFA is fine, but thinking that this is specifically a vulnerability because of TPM is a serious mistake. Not using a TPM won't make you safer.

> If you could replace all the vendor keys [...]

You very much can. It's trivial.

TPMs have four key "hierarchies" each of which has a seed. Of those four, one (the "null" hierarchy) gets a random seed each time the TPM is reset, while the other three (the platform, endorsement, and owner hierarchies) have their seeds stored in EEPROM/NVRAM, and there are functions in the spec for replacing those with new, randomly generated seeds.

All primary keys in a TPM are derived from seeds, and the derived keys are not stored anywhere -- they are always derived as needed from the hierarchy's seed and a given template. Therefore changing a hierarchy's seed loses all access to primary keys previously used in that hierarchy.

All other keys are saved off-chip encrypted to a primary key. Thus rotating a hierarchy's see loses all access to all keys previously used in that hierarchy (not just the primary keys).

The only thing here that is remotely problematic here is that you have to trust the TPM's RNG. If you're paranoid you might believe that the RNG is itself a PRNG with a hidden seed and that the manufacturer knows it. But if you roll the endorsement hierarchy seed and delete the endorsement key certificate from the TPM, then how will the manufacturer identify the TPM in order to look up its putative hidden RNG seed? Even if they could find it, how would they know which RNG output was used as the hierarchy's new seed?

So, yes, you can "replace all the vendor keys". It really is trivial. However, before you do it you may want to use the existing keys and certificates to bootstrap (enroll) the host into your organization's network and then change the seeds and certify various public keys as derived after the seeds are changed so that you can continue using the TPM for attestation.

Is a non removable TPM actually the right level of security? It feels like the same level of security I would get by having one of those realtor lock boxes permanently affixed to my front door and always keeping my house key in it.

Maybe the key itself is "more secure" because it only lives in the lockbox and is only taken out to unlock the front door and then put back right away. Is this the right system for actually securing access to my home, though?

The first link said nothing about TPMs. The second link is nonsense. The third link says the NSA "teams" with the TCG, which could be concerning indeed, but there's no details there. The fourth link is light on details and full of FUD. The fifth link says roughly the same as the third, and is equally light on details. The sixth link is like the fourth but it does have some actually useful information that says you're wrong:

> It is also important to note that any user concerns about TPM 2.0 are addressable. The first concern, generally expressed as "lack of user control," is not correct as OEMs have the ability to turn off the TPM in x86 machines; thus, purchasers can purchase machines with TPMs disabled (of course, they will also be unable to utilize the security features enabled by the technology). The second concern, generally expressed as "lack of user control over choice of operating system," is also incorrect. In fact, Windows has been designed so that users can clear/reset the TPM for ownership by another OS of they wish. Many TPM functions can also be used by multiple OSes (including Linux) concurrently.

This refers to the fact that you can:

- disable the TPM if you don't want to use it

- change the platform/endorsement/owner hierarchies' seeds, delete all the platform and endorsement certificates, and thus render any agreements between the NSA and the TPM manufacturers useless to backdooring the host (unless the agreement involves voluntary vulnerabilities in the TPM's firmware)

The last article you link to is much more interesting because it actually involves thinking about how the NSA (or other such agency) could have a backdoor inserted into the TPM:

> However, such “trust” can be easily misused to break security. In the talk, I used TPM as an example. Suppose TPM is used to implement secure data encryption/decryption. A standard-compliant implementation will be trivially subject to the following attack, which I call the “trap-door attack”. The TPM first compresses the data before encryption, so that it can use the saved space to insert a trap-door block in the ciphertext. The trap-door block contains the decryption key wrapped by the attacker’s key. The existence of such a trap-door is totally undetectable so long as the encryption algorithms are semantically secure (and they should be).

Er, well, this fails because there is no way to compress cryptographic material, and we're talking about random or pseudo-random keys being compressed (which, you can't) then encrypted. So this particular idea fails immediately.

That doesn't mean that there aren't other backdoors. For example, the ciphertext could be larger than necessary rather than use a compression of the plaintext. But this too fails because the sizes of the ciphertexts are easy to determine from the plaintext sizes.

The best way to add a backdoor is to have secret commands that use public keys for authentication (and even encryption) so that you have to know the backdoor in order to be able to use it. I cannot prove that there is no such backdoor, but if you have the means to decap and reverse engineer a dTPM then you can do this.