Ubuntu scores highest in UK Gov security assessment

Since they're so slow, they're typically only used as "safe" data storage for keys, with all crypto happening in the CPU.

The main appeal of a TPM is then that data stored inside it is "sealed" (bound) to a defined system state (which only protects against the most crude attacks, but still) and somewhat protected from access.

You could just store a password encrypted key in there, like the one created for regular disk crypto. Worst case (TPM fully broken) it's as good as a no-TPM setup. In all other cases, the TPM provides another line of defense.

The future change so far is that the more complex parts of TPM are emulated in software on the CPU (TPM 2.0 in "firmware TPM" mode).

Vendors can introduce other crypto misfeatures without riding the TPM wave, and they can do so more easily by bypassing the TCG, which standardizes TPM (standardization is expensive).

For example (using Intel names and products as examples, some of these exist in similar fashion in other platforms):

- RDRAND (the in-cpu random number generator you may or may not want to trust)

- AESNI (the in-cpu AES implementation you may or may not want to trust)

- Anchor Cove ("only start the computer with 'correctly' signed firmware" - that is, stop owning your machine, no matter the effort)

- TXT ("run 'trusted' code that can control more of the machine than even your firmware - after you passed through Intel code, which is sometimes faulty and exploitable")

- SGX ("encrypt memory ranges in-CPU, so even the OS or TXT code can't make sense of them anymore" - but maybe Intel can?)

- AMT ("a coprocessor running several megabytes of code, with access to RAM, network, input and output devices" - what could possibly go wrong?)

Many of these ship already, some can't be disabled. Some are in the "won't hurt, won't help" department (eg SGX), some might be actively harmful (eg AMT, TXT, RDRAND). Most features look like Intel was mostly concerned with building the "Protected AV Path" Hollywood longs for so much (and they're usually advertised with that angle, too).

In that light I don't fear the TPM (a passive chip that does nothing unless some code running on the CPU asks it to) whose main issue is that it might be ineffective.

Thanks for your reply. I had heard what is called Anchor Cove and TXT framed as possible implications of TPM catching on, I will have to do some reading on what you say.

On x86, Microsoft caved in and mandated (in Windows 8 Logo Requirements) that it must be possible to deactivate Secure Boot. My guess is that they were more concerned with Windows 7 using customers or hardware vendors that didn't want to build two lines of devices, one Windows 7, one Windows 8.

On ARM, the Secure Boot rules are unchanged: mandantory, must not be deactivated.

I somewhat expect Microsoft to switch the x86 side requirements back after Windows 7 support ends.

Since this part of the behaviour isn't specified in UEFI specs but only in Windows Logo requirements, there's also exactly 0 leverage other market participants have over what's going on in that part of the PC platform, except maybe antitrust complaints - that easily take 5-10 years before there are any consequences.