Thomas, I think your concerns are ungrounded. The way TPM works is that private key never leaves hardware unencrypted. This applies to migrateable key too. When you create a migration blob it will be encrypted inside the TPM chip with the public key you provide.
Of course, the security of migrateable key depends on knowledge of migration password. Keep in mind though that migrateable keys are designed for secure key backups and if you employ non-migrateable keys then your system have to be designed in the way that it can survive loss of that key because there will be absolutely no way to recover it. In respect to your original question about changing migrateability of the key here is an idea - you can try exporting migrateable key and importing it back into the same TPM as non-migrateable (under a different key chain perhaps where none of the parent keys is migrateable). I'm not sure if it's gonna work or not, I'm experimenting with it myself right now but maybe someone else could comment on this. Hope this helps. ----- Original Message ----- > From: "Thomas Habets" <[email protected]> > To: [email protected] > Sent: Friday, November 15, 2013 4:24:48 AM > Subject: Re: [TrouSerS-users] Can you set NON_MIGRATABLE after generating > the keys? > > Richard wrote: > > Let me understand better your concern: you don't want TrouSerS to > > write > > keys on disk, because they can be retrieved by someone? > > 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. > 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). > > > If yes, then you don't need to worry about it, since the keys are > > ciphered by strong criptography before they're written on disk. > > Yes, but encrypted with what key? > http://trousers.sourceforge.net/pkcs11.html seems to tell me that if > I > know the user PIN, and have the PRIVATE_ROOT_KEY.pem file, then I can > extract the keys actually used for authentication (or whatever I use > my pkcs11 for), by telling the TPM chip to "migrate" my keys. > > 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? > > -- > 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 > ------------------------------------------------------------------------------ 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
