Since it's _me_ who control the disk encryption keys, I can just print them out (put on a thumb drive, etc) and store in my safe deposit box for this occasion.
No-one says that TPM should hold the only copy of encryption keys.
Posted Jul 1, 2011 13:38 UTC (Fri) by nix (subscriber, #2304)
[Link]
I thought the whole point of the TPM was that it held the only copy?
I suppose you could take the keys before feeding them into the TPM and preserve those, but it's amazing how none of the use cases anyone mentions for the TPM ever describe that.
Fedora reexamines "trusted boot"
Posted Jul 1, 2011 13:50 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
[Link]
You're confusing two issues.
It's certainly possible to use TPM to secure user-provided keys (which is what Windows uses for its BitLocker software, btw). In this mode TPM stores your symmetric encryption keys and only releases them if your boot chain is secure.
It's also possible to use TPM to generate an RSA keypair. In this mode TPM securely stores private key of the generated keypair. It's not possible to extract generated private key, so this mode can be used for remote attestation or for secure signatures.
Fedora reexamines "trusted boot"
Posted Jul 1, 2011 14:16 UTC (Fri) by nix (subscriber, #2304)
[Link]
Right. So the former mode is fine -- but as far as I can see doesn't really need more hardware support than a bit of NVRAM. The latter mode, which actually requires crypto and so on, is as far as I can see evil, because it locks keys up in opaque and failure-prone hardware, thus effectively doing a delayed deletion on any data secured by it and a delayed DoS on any access granted by it (because hardware always fails in the end).
Fedora reexamines "trusted boot"
Posted Jul 1, 2011 15:18 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
[Link]
Uhm. Private key mode is not (generally) used to encrypt data, so no worries about data loss.
It's used to make your machine 'uncloneable' and prove it to a remote party. It can be used for DRM (so you can view content only from uncloneable authorized devices) or to make sure that if your server is stolen you can make it unusable for the thief. We actually used TPM for this exact purpose - to make servers with medical data secure against physical theft.
Fedora reexamines "trusted boot"
Posted Jul 2, 2011 10:52 UTC (Sat) by Cyberax (✭ supporter ✭, #52523)
[Link]
BTW, 'a bit of NVRAM' won't work to store encryption keys. Because an attacker can just boot a LiveCD/LiveUSB and read all your keys from NVRAM.
That's where the measurement part of TPM comes handy - TPM won't release keys unless your system is secure.
Fedora reexamines "trusted boot"
Posted Jul 7, 2011 17:34 UTC (Thu) by farnz (guest, #17727)
[Link]
I've used the unknown private key mode - the point is to provide me with a way to confirm, beyond all doubt, that the accesses I'm seeing are coming from my trusted hardware, running my trusted OS. Change the OS, or change the hardware, and you need reauthorising with a new key to get on the network; similarly, you can use the hidden private key for encryption of your disk's AES key, which is also stored offline somewhere physically secure. You can thus get the key out again when the TPM fails (and recover your data), it's just hassle typing it in from your laminated printouts. In the meantime, the TPM lets you forget that there is such a key - the hardware knows what it is and ensures you always run a known-good OS.
The evil in TPM is nothing to do with the technical capabilities of the chip - they're fairly innocuous, if tricky to use well; the danger is when the TPM chip is used to store a private key that the user did not ask it to generate; in this situation, the holder of the public key has a path all the way to the machine that bypasses the user's wishes. If the user generates the key and hands the "public" section to the third party, all is well - nothing stops the user lying to the third party and giving them a public key not generated by a TPM.
Fedora reexamines "trusted boot"
Posted Jul 8, 2011 12:44 UTC (Fri) by nix (subscriber, #2304)
[Link]