openssh unix dev - Nov 2017 - [RFC 1/2] Add support for openssl engine based keys

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?

-d

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.

PKCS11 is used to represent tokens, so with TPM 1.2 you could load up
the TPM with keys and then address them via the uuid as an effective
PKCS11 token instead of using key files. ?With TPM 2.0 you can't do
this because the transient key space is so tiny, so you have to use key
files which are loaded as needed. ?It would be possible to write some
glue daemon to take all the keys in the .ssh directory and export them
via PKCS11 (that's what gnome-keyring-daemon does, after all) but it's
adding an additional layer that doesn't need to be there, so the
natural format for TPM 2.0 is an engine key file.

James

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

James,
Another way to look at PKCS#11 and tokens it so consider
the token as consisting of the TPM itself and a set of flat engine
files associated with it. The PKCS#11 module internally would then load
as needed a flat engine file to the TPM for a one time use.
So to the PKCS#11 caller it looks like any other PKCS#11 token. This would
also be useful for applications other then OpenSSH.

This approach then does not need to modify OpenSSL either, as the code
is contained in the PKCS#11 module and OpenSSL can use PKCS#11 via
the OpenSC libp11 with its engine.

A place to start might be the softHSM or other software based PKCS#11 module,
then add support for the TPM to load one key and use it.
Googling for TPM PKCS#11 shows others have developed PKCS#11 and TPM
modules but maybe not for TPM 2.0 with its limited memory.


On 11/3/2017 12:59 AM, 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.
> 
> PKCS11 is used to represent tokens, so with TPM 1.2 you could load up
> the TPM with keys and then address them via the uuid as an effective
> PKCS11 token instead of using key files. ?With TPM 2.0 you can't do
> this because the transient key space is so tiny, so you have to use key
> files which are loaded as needed. ?It would be possible to write some
> glue daemon to take all the keys in the .ssh directory and export them
> via PKCS11 (that's what gnome-keyring-daemon does, after all) but
it's
> adding an additional layer that doesn't need to be there, so the
> natural format for TPM 2.0 is an engine key file.
> 
> James
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 
-- 

  Douglas E. Engert  <DEEngert at gmail.com>