On Wed, Nov 16, 2016 at 12:54:44PM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > I find this approach very bad in general. > > PKCS#11 standard says that *private* keys should not be accessible without authentication. *Public* keys and certificates of course can and should be accessible with no authentication. > > SoftHSM misinterpreted this originally (older pkcs11 documents were less clear :), but they rectified this mistake. We should not repeat it. I do agree that requiring authentication to access public keys is not a very pleasant way to do PKCS11. For example having to provide authentication for ssh-keygen -D is a slight pain. I am happy to listen to any alternative solutions given that we are unable to modify the HSM itself. We solved the issue this way because we had a customer requirement to support using Safenet Network HSM for some critical automated connections. Unfortunately we have no way to influence how the HSM in our case works as all we have to work with is a binary PKCS11 library and a hardware box with closed source firmware. Btw as a response to other comments, the justification for using an environment variable to point to a pin code file instead of environment variable with a pin code is that there is a risk that runtime environment might be inadvertently leaked in some debug outputs or verification scripts. Distinct files are less likely to be leaked by accident. In the case of Safenet Network HSM there are three layers of "authentication" (or rather security checks): Certificates authenticate the host and the HSM to each other, IP addresses are checked and all operations must provide the pin to the HSM partition. The main justification for the customer organization to use a network HSM instead of local passwordless private keys is to prevent the key from leaking. I believe this is a somewhat rare case but we feel it might be useful to people other than us. Safenet HSM products seem fairly popular with enterprises and I believe Amazon CloudHSM is really close to it. Oh and we do appreciate the feedback. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
