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

James Bottomley James.Bottomley at HansenPartnership.com
Sat Nov 4 03:33:19 AEDT 2017

On Fri, 2017-11-03 at 14:34 +0000, Blumenthal, Uri - 0553 - MITLL
>          >>  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?

You can always make a process more complex than necessary.  For Engine
files, the somehow already exists (it's the file which you transfer
using existing techniques for transferring files, which are well
understood) for the PKCS11 method, the somehow depends on the token and
for a lot of tokens the assumption is locality is secure, so there's no
secure remote update mechanism.

> If there’s no PKCS#11 “driver” for TPM – then that’s what needs to be
> added, IMHO.

OK, let's do a thought experiment: if you advocate for using PKCS11
tokens instead of flat files, you should presumably want this for the
ordinary ssh key files as well (we can easily construct a software
pkcs11 token to handle them ... again, it's what gnome-keyring has
already done, so an exemplar exists).  Now in ssh, you only have one
option in ssh-add: the token shared object and you can only specify one
password for each token shared object, so you'd need a way of
constructing one token shared object for each key in the directory
(because they could all have different passwords).  We'd need some
build infrastructure to rebuild the token shared objects each time a
key were added or changed.  Presumably the shared object would be named
similarly to the existing keys, so you don't get confused, so you'd do

ssh-add -s /home/jejb/.ssh/id_rsa.so

instead of

ssh-add /home/jejb/.ssh/id_rsa

And by the time I've done all the above, I'm back to what I had
originally (plus a load of complexity):  It's pretty much the
engineering equivalent of applying sufficient force to get the round
peg into the square hole.

The reason it's such a pain is that PKCS11 is designed for active
"things" which store keys internally.  The file method (either engine
or PEM) is for passive files that can be decoded by something (either
the internal openssl method or the engine) either can be used for the
other's use case (with sufficient glue) but the result is very messy if
you don't do internally stored keys via PKCS11 and file based keys via
file mechanisms.


More information about the openssh-unix-dev mailing list