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
