5 ms·

It's more the implications of accepting TPM and thereby enabling future changes to it that make me uneasy.

pgeorgi 13y ago
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.
- eliasmacpherson 13y ago
  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.
  - pgeorgi 13y ago
    TXT uses the TPM to run a system state hash in a special TPM register (that can't be modified from x86 code) - no other relation there. Anchor Cove can seal (against TPM) or verify (against a hard coded value in the CPU, probably using efuses). Given that choice, I'd prefer the TPM-way - at least that key can be replaced. The recent spread of TPM is mostly motivated by Windows 8 and its Connected Standby feature. CS requires a TPM 2.0 (by Logo Requirements, ie. "spec", not necessarily by implementation).

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.

eliasmacpherson 13y ago
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.
- pgeorgi 13y ago
  TXT uses the TPM to run a system state hash in a special TPM register (that can't be modified from x86 code) - no other relation there. Anchor Cove can seal (against TPM) or verify (against a hard coded value in the CPU, probably using efuses). Given that choice, I'd prefer the TPM-way - at least that key can be replaced. The recent spread of TPM is mostly motivated by Windows 8 and its Connected Standby feature. CS requires a TPM 2.0 (by Logo Requirements, ie. "spec", not necessarily by implementation).