On Fri, 2017-11-03 at 14:34 +0000, Blumenthal, Uri - 0553 - MITLL wrote: > >> 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. James _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
