4 ms·

There's not going to be any one line answers but the section https://www.gov.uk/government/publications/end-user-devices-security-guidance-ubuntu-1204/end-user-

There's not going to be any one line answers but the section https://www.gov.uk/government/publications/end-user-devices-security-guidance-ubuntu-1204/end-user-devices-security-guidance-ubuntu-1204#significant-risks https://www.gov.uk/government/publications/end-user-devices-... is illuminating. Not least for recommending the use of TPMs for disk encryption

eliasmacpherson 13y ago
Maybe I am a crank but I distrust TPM.
- pgeorgi 13y ago
  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.
  - eliasmacpherson 13y ago
    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).

eliasmacpherson 13y ago

Maybe I am a crank but I distrust TPM.

pgeorgi 13y ago
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.
- eliasmacpherson 13y ago
  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).