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

[James Bottomley]

On Fri, 2020-01-31 at 10:02 +1100, Damien Miller wrote:
> On Thu, 30 Jan 2020, 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.  The current most useful engine
> > for
> > openssh keys are the TPM engines, which allow all private keys to
> > be
> > stored in a form only the TPM hardware can decode, making them
> > impossible to steal.
> 
> I think this is similar enough to the FIDO key support that we
> recently added to OpenSSH that it would be best to reuse those
> interfaces for these keys. FIDO keys are file based as well - the
> enrollment/generation process returns a "key handle" that we bundle
> up in a private key and that needs to be supplied when signing.
> 
> Have a look at regress/misc/sk-dummy/sk-dummy.c in portable OpenSSH
> for a dummy version of the API that just calls out to libcrypto.

OK, I did look at this.  However, engine keys and FIDO keys are
completely different.  An engine key is simply a regular openssl key
that can only be loaded and handled by an engine.  This means that most
ordinary openssh keys can be converted to engine keys and the public
key (and any authorized_keys entries) remains the same.

FIDO keys are completely new: they require a new file format and a new
public key, so you can't just seamlessly load an old private key into
one.  The other thing is the FIDO key does carry all the components in
the keyhandle, so it can be serialised.

I think the ultimate goal of engine keys should be as seamless as
possible.  The only thing required of openssl is to fallback to the
engine API if the PEM loader fails and to add an extra SSH_ADD_AGENTC_
command for them because they can't be transmitted as public/private
components as openssh otherwise assumes for standard RSA/ECDSA keys.

However, this conclusion does mean that the user of ssh should never
have to know if an engine is being used, so the '-o' flag is redundant.
 I'll redo the patch set to unify all of this into the PEM loader path.

James