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

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.?

Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network.
? Original Message ?
From: Juha-Matti Tapio
Sent: Wednesday, November 16, 2016 04:35
To: openssh-unix-dev at mindrot.org
Subject: [PATCH] ssh-pkcs11: allow providing unconditional pin code for PKCS11

Some HSM's such as Safenet Network HSM do not allow searching for keys
unauthenticated. To support such devices provide a mechanism for users
to provide a pin code that is always used to automatically log in to
the HSM when using PKCS11.

The pin code is read from a file specified by the environment variable
SSH_PKCS11_PINFILE if it is set.

Tested against Safenet Network HSM.
---
ssh-pkcs11.c | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)

diff --git a/ssh-pkcs11.c b/ssh-pkcs11.c
index aaf712d..f75b201 100644
--- a/ssh-pkcs11.c
+++ b/ssh-pkcs11.c
@@ -42,6 +42,8 @@
#include "ssh-pkcs11.h"
#include "xmalloc.h"

+#define SSH_MAX_PKCS11_PIN_BYTES 128
+
struct pkcs11_slotinfo {
CK_TOKEN_INFO	 token;
CK_SESSION_HANDLE	session;
@@ -216,6 +218,36 @@ pkcs11_find(struct pkcs11_provider *p, CK_ULONG slotidx,
CK_ATTRIBUTE *attr,
return (ret);
}

+/* read pin from a file specified in SSH_PKCS11_PINFILE if one exists */
+char *
+pkcs11_read_pinfile()
+{
+	FILE *f;
+	char *pinfilename;
+	char buf[SSH_MAX_PKCS11_PIN_BYTES];
+	int i;
+
+	if ((pinfilename = getenv("SSH_PKCS11_PINFILE")) == NULL)
+	 return NULL;
+	if ((f = fopen(pinfilename, "r")) == NULL) {
+	 debug("failed to read SSH_PKCS11_PINFILE");
+	 return NULL;
+	}
+	if (fgets(buf, SSH_MAX_PKCS11_PIN_BYTES, f) == NULL)
+	 return NULL;
+	fclose(f);
+
+	/* truncate first line and ignore the rest */
+	for (i = 0; buf[i] && i < SSH_MAX_PKCS11_PIN_BYTES; i++) {
+	 if (buf[i] == '\n' || buf[i] == '\r') {
+	 buf[i] = '\0';
+	 break;
+	 }
+	}
+
+	return xstrdup(buf);
+}
+
/* openssl callback doing the actual signing operation */
static int
pkcs11_rsa_private_encrypt(int flen, const u_char *from, u_char *to, RSA *rsa,
@@ -575,6 +607,9 @@ pkcs11_add_provider(char *provider_id, char *pin, struct
sshkey ***keyp)
CK_TOKEN_INFO *token;
CK_ULONG i;

+	if (!pin)
+	 pin = pkcs11_read_pinfile();
+
*keyp = NULL;
if (pkcs11_provider_lookup(provider_id) != NULL) {
debug("%s: provider already registered: %s",
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4350 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20161116/612a394b/attachment-0001.bin>

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.

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>