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

[James Bottomley]

On Fri, 2020-01-31 at 18:43 +0100, Jakub Jelen wrote:
> On Thu, 2020-01-30 at 16:24 +0100, 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.
> 
> There is already tpm2-pkcs11 module which addresses the same use case
> in a standard way for TPM2:
> 
> https://github.com/tpm2-software/tpm2-pkcs11

Well, there's no need for anything that specific.  This project can
provide a pkcs11 provider for any engine:

https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl-pkcs11-export.git

I wrote it to make engines work with NSS since there are some things
that don't have a pkcs11 module.

But the more fundamental problem is pkcs11 is not a good interface for
file based keys ... as I think you know, otherwise the openssl U2F
support would be implemented via pkcs11.

pkcs11 is a great interface if the key resides within the token, as it
does for a lot of them because it's got a search function and a URI
expression for the token (if you use p11-kit).  However, when the key
is file based it's not good because the URI doesn't have an expression
for the file location meaning you have to add extra configuration glue
to get the pkcs11 emulation to work. Essentially the glue tells the
engine where to find the key files and how to export them.

Fundamentally the ssh user experience is file based: you have a public
and a private key file in the .ssh directory that are your identity. 
The engine paradigm matches that exactly, so it's far easier for
consumers simply to convert the openssl private key to an engine one
and use it in the same way than it is for them to construct the two
layers of indirection necessary to use the key via a pkcs11 token
interface.  It's also consonant with our job of making security simpler
for the users not more complex.

> I do not think all the applications that want support for
> TPM2/engines should need to implement support for engines.

Well, yes, what should happen is that openssl should try all the import
formats it knows about instead of having one API for PEM, one for DER
and one for engines ... however, I lost that battle a long time ago.

>  Especially when the engines are to be replaced by a new providers
> interface in future OpenSSL releases:
> 
> https://www.openssl.org/docs/OpenSSLStrategicArchitecture.html

A provider is simply a fancy name for an engine, there's no huge
architectural difference.  I and several other people who lost the "why
three different file loading interfaces" battle the last time around
will be nudging openssl to couple the provider and the store, so that
if a provider exists, the key file gets loaded through a single API ...
if that happens, the engine code in openssl can go away, assuming we
win the battle this time around ... but I wouldn't rule out that the
engine file API will get reborn as the provider file API and the same
problem will exist.

James