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@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
--
Douglas E. Engert <DEEngert@xxxxxxxxx>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
