On 15 November 2013 14:54, Ken Goldman <[email protected]> wrote: > On 11/15/2013 4:24 AM, Thomas Habets wrote: >> I'm concerned with any cryptography done in software, including >> generating keys that actually matter in the trust chain or for key >> storage. Storing on disk is just the biggest concern. Even having them >> in RAM seems wrong. > The TPM key is not generated in software. The key pair is generated on > the TPM. The private key is returned encrypted.
I'm not great with TPM terminology. The keys generated in software that I'm referring to are the root keys. From http://trousers.sourceforge.net/pkcs11.html: "The keys which form the roots of these trees are the Private Root Key and the Public Root Key as depicted above. Both of these keys are generated in software. " >> I'm also concerned about *any* way to extract the keys from the TPM, >> even for attackers that have the user or SO PIN, or even the owner >> password and SRK (and the SRK needs to be well known for pkcs11, it >> seems). > The key is always 'extracted from the TPM' when it is created, then > loaded for use by the TPM. I mean in a usable form. There is course no problem with supplying an opaque blob and a crypto operation to the TPM chip, if the private key inside the opaque blob is not available for the CPU to use, and the crypto operation is never "turn this blob into the private key", which a migration effectively is, as I understand it. >> So in other words: How do "migratable" keys not enable a bypass of the >> whole reason for having a TPM chip in the first place? > There are controls on migration. It requires the authorization password > of the parent and the migration authorization password of the key. For keys under the private root key, does this mean the SRK password (20 null bytes) and the user PIN? > The owner password authorizes where it can be migrated. So one more password to migrate than to use, correct? To me this sounds like the single protection against copying keys, assuming the pem files can be retrieved from either the file system, undeleted files, fs journals, or remapped sectors (bad blocks or wear levelling). The pem files can be offline cracked. > All these controls are certainly far better than just having the private > key on your disk. But yes, if everyone cooperates, you could migrate > the key to a software TPM and get the private key. That's the price you > pay for backups. Right. I'd like to sacrifice backups for the benefit of knowing that all crypto operations now and in the future involve this one particular piece of hardware. Not a copy or successor of it. > You must, however, have a plan that's better than, "If the TPM > fails, my business fails." I do. Everything breaks eventually, and this would not be a problem. For one, the TPMs would probably not fail on all client machines at once. -- typedef struct me_s { char name[] = { "Thomas Habets" }; char email[] = { "[email protected]" }; char kernel[] = { "Linux" }; char *pgpKey[] = { "http://www.habets.pp.se/pubkey.txt"; }; char pgp[] = { "A8A3 D1DD 4AE0 8467 7FDE 0945 286A E90A AD48 E854" }; char coolcmd[] = { "echo '. ./_&. ./_'>_;. ./_" }; } me_t; ------------------------------------------------------------------------------ DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk _______________________________________________ TrouSerS-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/trousers-users
