[RFC 1/2] Add support for openssl engine based keys

[James Bottomley]

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