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

Juha-Matti Tapio jmtapio at ssh.com
Thu Nov 17 06:11:51 AEDT 2016


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.


More information about the openssh-unix-dev mailing list