3 ms·

Warning as potentially misleading: despite the large CESG logo, this is hosted at ubuntu.com. The PDF summary is written by a Sales Engineer at Canonical Ltd.

by ronaldx 13y ago

Warning as potentially misleading: despite the large CESG logo, this is hosted at ubuntu.com. The PDF summary is written by a Sales Engineer at Canonical Ltd. The original CESG security guidance has a rather different perspective: https://www.gov.uk/government/collections/end-user-devices-security-guidance--2 https://www.gov.uk/government/collections/end-user-devices-s...

StavrosK 13y ago
Care to summarize? Each OS is a different document.
- baxter001 13y ago
  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.
        13y ago

by ronaldx 13y ago

StavrosK 13y ago

Care to summarize? Each OS is a different document.

baxter001 13y ago
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.
        13y ago