Issues/Vulnerabilities that TPM 2.0 aims to enhance/solve comparing to TPM 1.2

Question

I have read some documents that comparing TPM 1.2 and TPM 2.0 (e.g. more supported algorithms like SHA-2, reduced code size, or even symmetric keys seems added, etc.)

I want to ask that what are the objectives to develop a non-compatible TPM 2.0? Actually in other words, what are the key issues that TPM 2.0 aims to solve / enhance by comparing to TPM 1.2? (just like TPM 1.2 solved vulnerabilities in TPM 1.1.)

E.g. solve the vulnerabilities that existed in TPM 1.2, enhancements to prevent certain attacks, support more algorithms so fit more platforms, etc.

(Another small question: after TPM 2.0 become mature, what could be the possible trend of TPM 1.2, replaced?)

Answer 1

The UEFI made a small presentation describing why we need to get to the TPM 2.0 and forget the 1.2.

First the SHA-1 algorithm is considered unsafe, and as they say, just jumping to SHA-2 is not long-term efficient. So TPM 2.0 supports in theory every kind of hash algorithm. Here is the NIST's policy on hash function. SHA-1 should not be used for any cryptographic uses. (as forest said, sha-1 is only weak against collision, using SHA-1 with HMAC is not really impacted)

Considering the asymmetric cryptography, the RSA is not so much obsolete(while we stay with decent length keys), but maybe one day, the problem of the integer factorization will not be a problem anymore thanks to Shor's algorithm. We need to have any kind of public-key cryptography. So there are all the Elliptic Curve Cryptography algorithms, the discrete logarithms algorithms, and obviously the Integer Factorization.(Apparently, the elliptic curves should be more vulnerable to Shor's algorithm). Before TPM 2.0, the only choice we had was the RSA. The available algorithms depend on what the vendor wanted to implement.

Finally considering the symmetric cryptography, with TPM 1.2 we have the XOR and especially AES. There is no known attack against AES, but having the choice is nice. There are alternatives to AES like Blowfish. And there must be some kind of political choices(AES is approved by the NSA, some people/countries may think this is a bad indicator: « If the NSA approves it, they must know how to decrypt it »)

It is supposed to be easier to use. I will quote the UEFI presentation :

Removed the confusing enabled/activated/disabled/deactivated states – It’s either there or not there (ACPI table) – If present, it can be used by firmware even if not exposed to the OS

Finally, TPM 2.0 contains 3 permanent hierarchy keys (Platform, Storage, Privacy) against only one for TPM 1.2.

The Privacy hierarchy uses the endorsementAuth and can be used to generate EK(endorsement Key just like in TPM 1.2), and thus generate easily AIK(Attestation Identity Key), which can be used in Direct Anonymous Attestation(Authentication with a Zero-Knowledge Proof)

The security hierarchy uses the ownerAuth and is used to encrypt/decrypt datas.

The platform hierarchy uses the PlatformAuth and can be used to initialize the TPM, and enable/disable the use of the other hierarchies.

So basically, with 3 hierarchies instead of 1, you can do the same thing, but the authorizations are more clever.