On Thu, 2 Nov 2017, James Bottomley wrote:> On Fri, 2017-11-03 at 13:11 +1100, Damien Miller wrote: > > On Thu, 26 Oct 2017, James Bottomley wrote: > > > > > > > > Engine keys are keys whose file format is understood by a specific > > > engine rather than by openssl itself.??Since these keys are file > > > based, the pkcs11 interface isn't appropriate for them because they > > > don't actually represent tokens. > > > > What sort of keys do you have in mind here that can't be represented > > via PKCS#11? > > Well, the engine keys are flat files, so the usual use case is to take > the private key file and replace it with an engine key file in the .ssh > directory so the private key becomes tied to the hardware platform and > cannot be usefully exfiltrated.Let me rephrase my question: what does using OpenSSL engines enable that we can't already do via PKCS#11? -d
On Fri, 2017-11-03 at 19:25 +1100, Damien Miller wrote:> On Thu, 2 Nov 2017, James Bottomley wrote: > > > > > On Fri, 2017-11-03 at 13:11 +1100, Damien Miller wrote: > > > > > > On Thu, 26 Oct 2017, James Bottomley wrote: > > > > > > > > > > > > > > > Engine keys are keys whose file format is understood by a > > > > specific engine rather than by openssl itself.??Since these > > > > keys are file based, the pkcs11 interface isn't appropriate for > > > > them because they don't actually represent tokens. > > > > > > What sort of keys do you have in mind here that can't be > > > represented via PKCS#11? > > > > Well, the engine keys are flat files, so the usual use case is to > > take the private key file and replace it with an engine key file in > > the .ssh directory so the private key becomes tied to the hardware > > platform and cannot be usefully exfiltrated. > > Let me rephrase my question: what does using OpenSSL engines enable > that we can't already do via PKCS#11?It allows you to use the TPM2 as a secure key store, because there's no current PKCS11 code for it. The essential difference is that Engine files are just that: flat files where the key is stored in a form only decodeable by the engine. ?PKCS11 tokens are supposed to be represented by tokens and slots which is an active entity storing the key. ?So, provided I wrap it correctly, I can create a TPM representation on one system (I have to know one of the hierarchy seeds on the target) transfer the file to the target system and use it; because the file can only be read by the TPM on the target system, the transfer is secure against eavesdropping on the private key. ?To do the same thing with PKCS11 I'd have to transfer the physical token. ?The use case for this for me is to allow the secure transfer of private keys into the cloud without having to use a specific HSM, but there are others. James
Blumenthal, Uri - 0553 - MITLL
2017-Nov-03 14:34 UTC
[RFC 1/2] Add support for openssl engine based keys
>> Let me rephrase my question: what does using OpenSSL engines enable>> that we can't already do via PKCS#11? > > It allows you to use the TPM2 as a secure key store, because there's no > current PKCS11 code for it. > > The essential difference is that Engine files are just that: flat files > where the key is stored in a form only decodeable by the engine. > PKCS11 tokens are supposed to be represented by tokens and slots which > is an active entity storing the key. So, provided I wrap it correctly, > I can create a TPM representation on one system (I have to know one of > the hierarchy seeds on the target) transfer the file to the target > system and use it;? What I don?t get is ? why not transfer those keys to the target machine ?somehow?, load them to the TPM there ?somehow?, and then treat TPM as a PKCS#11 device? If there?s no PKCS#11 ?driver? for TPM ? then that?s what needs to be added, IMHO. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5211 bytes Desc: not available URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20171103/323ceb30/attachment.p7s>