openssh unix dev - Nov 2016 - [PATCH] ssh-pkcs11: allow providing unconditional pin code for PKCS11

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>

On Wed, Nov 16, 2016 at 03:58:23PM +0000, Blumenthal, Uri - 0553 - MITLL
wrote:
> 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:
>     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.
The patch does not change any existing functionality. It only adds a
mechanism that allows users to force providing a pin code even if one
is not asked by default. Nothing happens if the users do not trigger
the mechanism and I am not sure why anything would break even if they
did provide a pin 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??
The software is upgradeable but it is not something we can influence.
We are mainly concerned about interoperability with existing
installations.
>     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.
If the pin is not provided using our mechanism, then it is NULL and
C_Login is not called, just as without our patch. So no change there
to existing behaviour.

On 11/16/16, 2:11 PM, "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:
    The patch does not change any existing functionality. It only adds a
    mechanism that allows users to force providing a pin code even if one
    is not asked by default. Nothing happens if the users do not trigger
    the mechanism and I am not sure why anything would break even if they
    did provide a pin code.

OK, that makes things better.

    
      > 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.
    
    If the pin is not provided using our mechanism, then it is NULL and
    C_Login is not called, just as without our patch. So no change there
    to existing behavior.

The mechanism might require some more thinking. But based on the above, I
(reluctantly ? I still don?t like it) withdraw my 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/407fd458/attachment.bin>