On Sat, 2017-11-04 at 07:57 -0500, Douglas E Engert wrote: > 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. I ran this thought experiment here: https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-November/036435.html Nothing you say above alters my opinion that it's simply adding complexity for no benefit. As I said in that email: "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." > 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. Although I've worked on the engine for both, 2.0 is my target because that's what my primary laptop has. However, even when I had a 1.2 laptop, PKCS11 just didn't work because I have too many keys. The Infineon in the laptop could load up with 6 keys before it got full, and my standard use case is 9 (two openvpn, four ssh, one secure boot and one openconnect and one X509 web cert). When I TPM enable gpg, I'll have another three. The bottom line is that PKCS11 *only* makes sense for things which only work with internal keys. Anything that uses file based keys should be used via engine methods otherwise you run into scaling problems like the above. I can fully sympathise with the position that engine file keys should be fully transparent to applications, but that's not the view taken by the openssl developers and we have to deal with the world as it is not as we might wish it to be. James > 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 > > > _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
