[PATCH] ssh-pkcs11: allow providing unconditional pin code for PKCS11

[Blumenthal, Uri - 0553 - MITLL]

On 11/16/16, 8:55 AM, "openssh-unix-dev on behalf of Juha-Matti Tapio" <openssh-unix-dev-bounces+uri=ll.mit.edu at mindrot.org on behalf of jmtapio at ssh.com> wrote:

    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. 

The point is not as much of being “not very pleasant”. The point is to avoid breaking it for everything and everybody else (like, forcing them to authenticate for public key operations – which would break all the existing scripts), for the sake of one screwed-up HSM device.

    I am happy to listen to any alternative solutions 

I’m OK with a hack to take care of one non-compliant device. I am not OK with having that hack as part of the mainstream code.

    …given that we are unable to modify the HSM itself.

Are you so sure? Does SafeNet maybe have a firmware upgrade? Did your people talk to SafeNet, with PKCS#11 v2.40 document in hand? Perhaps they can be convinced…?
    
    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.

Understood. But see above.
    
    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. 

Yes, very valid concern and approach. As I said, *my* concern is avoiding the need to provide a PIN for non-private keys and certs.

    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.

This cannot be argued with. I’m doing something similar.

    
    I believe this is a somewhat rare case but we feel it might be useful
    to people other than us. Oh and we do appreciate the feedback.

The question is how to accommodate your needs without breaking it for everybody else. This is my main concern/objection.
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20161116/6e741b88/attachment.bin>