Fwd: patch for pkcs11-tool - write pubkey objects

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Fwd: patch for pkcs11-tool - write pubkey objects

Andreas Jellinghaus-2
Hi everyone,

here is a bug report with a patch for pkcs11-tool.

I'm no expert on this subject, so feedback is very welcome.
it looks good in general, except maybe more return codes/
error checking etc., and a different code path if
pkcs11-tool is compiled without openssl.

the author asks about two attributes where he isn't
sure what to do best. I don't know either, so if anyone
can take care of the bug&patch, that would be great.

Thanks, Andreas

----------  Weitergeleitete Nachricht  ----------

Betreff: patch for pkcs11-tool - write pubkey objects
Datum: Montag 15 März 2010
Von: Jaroslav Benkovský <[hidden email]>
An: [hidden email]

Hello,
the attached patch allows pkcs11-tool to write RSA public keys to a
device. I am not sure why it was left out at all, but I need it to get
opendnssec working with externally generated keys and SCA6000 and this
patch allows me to do that.

I am not sure with CKA_WRAP=FALSE & CKA_ENCRYPT=FALSE, but I set it to
be the same as device generated keys I have there.

If you have any comments, questions, etc, write me.

Regards,
Jarda Benkovsky

-------------------------------------------------------------

--- pkcs11-tool.c.orig 2010-03-12 17:00:58.002129280 +0100
+++ pkcs11-tool.c 2010-03-15 16:08:56.113081803 +0100
@@ -1178,30 +1178,47 @@
  RSA_GET_BN(exponent_2, r->dmq1);
  RSA_GET_BN(coefficient, r->iqmp);
 }
+
+static void parse_rsa_public_key(struct rsakey_info *rsa,
+ unsigned char *data, int len)
+{
+ RSA *r = NULL;
+ const unsigned char *p;
+
+ p = data;
+ r = d2i_RSA_PUBKEY(NULL, &p, len);
+
+ if (!r) {
+ r = d2i_RSAPublicKey(NULL, &p, len);
+ }
+
+ if (!r) {
+ /* ERR_print_errors_fp(stderr); */
+ util_fatal("OpenSSL error during RSA public key parsing");
+ }
+ RSA_GET_BN(modulus, r->n);
+ RSA_GET_BN(public_exponent, r->e);
+}
 #endif
 
 #define MAX_OBJECT_SIZE 5000
 
-/* Currently only for certificates (-type cert),
-   private keys (-type privkey) and data objetcs (-type data).
+/* Currently for certificates (-type cert), private keys (-type privkey),
+   public keys (-type pubkey) and data objects (-type data).
    Note: only RSA private keys are supported. */
 static int write_object(CK_SLOT_ID slot, CK_SESSION_HANDLE session)
 {
  CK_BBOOL _true = TRUE;
+ CK_BBOOL _false = FALSE;
  unsigned char contents[MAX_OBJECT_SIZE];
  int contents_len = 0;
  unsigned char certdata[MAX_OBJECT_SIZE];
  int certdata_len = 0;
  FILE *f;
- CK_OBJECT_HANDLE cert_obj, privkey_obj, data_obj;
- CK_ATTRIBUTE cert_templ[20], privkey_templ[20], data_templ[20];
- int n_cert_attr = 0, n_privkey_attr = 0, n_data_attr = 0;
+ CK_OBJECT_HANDLE cert_obj, privkey_obj, pubkey_obj, data_obj;
+ CK_ATTRIBUTE cert_templ[20], privkey_templ[20], pubkey_templ[20], data_templ[20];
+ int n_cert_attr = 0, n_privkey_attr = 0, n_pubkey_attr = 0, n_data_attr = 0;
  struct sc_object_id oid;
-#if 0
- CK_ATTRIBUTE pubkey_templ[20];
- CK_OBJECT_HANDLE pubkey_obj;
- int n_pubkey_attr = 0;
-#endif
  CK_RV rv;
  int need_to_parse_certdata = 0;
 #ifdef ENABLE_OPENSSL
@@ -1249,6 +1266,13 @@
  util_fatal("No OpenSSL support, cannot parse RSA private key\n");
 #endif
  }
+ if (opt_object_class == CKO_PUBLIC_KEY) {
+#ifdef ENABLE_OPENSSL
+ parse_rsa_public_key(&rsa, contents, contents_len);
+#else
+ util_fatal("No OpenSSL support, cannot parse RSA public key\n");
+#endif
+ }
 
  if (opt_object_class == CKO_CERTIFICATE) {
  CK_OBJECT_CLASS clazz = CKO_CERTIFICATE;
@@ -1338,6 +1362,49 @@
 #endif
  }
  else
+ if (opt_object_class == CKO_PUBLIC_KEY) {
+ CK_OBJECT_CLASS clazz = CKO_PUBLIC_KEY;
+ CK_KEY_TYPE type = CKK_RSA;
+ CK_ULONG modulus_bits = rsa.modulus_len * 8;
+
+ FILL_ATTR(pubkey_templ[0], CKA_CLASS, &clazz, sizeof(clazz));
+ FILL_ATTR(pubkey_templ[1], CKA_KEY_TYPE, &type, sizeof(type));
+ FILL_ATTR(pubkey_templ[2], CKA_TOKEN, &_true, sizeof(_true));
+ FILL_ATTR(pubkey_templ[3], CKA_PRIVATE, &_true, sizeof(_true));
+ n_pubkey_attr = 4;
+
+ if (opt_object_label != NULL) {
+ FILL_ATTR(pubkey_templ[n_pubkey_attr], CKA_LABEL,
+ opt_object_label, strlen(opt_object_label));
+ n_pubkey_attr++;
+ }
+ if (opt_object_id_len != 0) {
+ FILL_ATTR(pubkey_templ[n_pubkey_attr], CKA_ID,
+ opt_object_id, opt_object_id_len);
+ n_pubkey_attr++;
+ }
+#ifdef ENABLE_OPENSSL
+ if (cert.subject_len != 0) {
+ FILL_ATTR(pubkey_templ[n_pubkey_attr], CKA_SUBJECT,
+ cert.subject, cert.subject_len);
+ n_pubkey_attr++;
+ }
+ FILL_ATTR(pubkey_templ[n_pubkey_attr], CKA_WRAP, &_false, sizeof(_false));
+ n_pubkey_attr++;
+ FILL_ATTR(pubkey_templ[n_pubkey_attr], CKA_ENCRYPT, &_false, sizeof(_false));
+ n_pubkey_attr++;
+ FILL_ATTR(pubkey_templ[n_pubkey_attr], CKA_MODULUS,
+ rsa.modulus, rsa.modulus_len);
+ n_pubkey_attr++;
+ FILL_ATTR(pubkey_templ[n_pubkey_attr], CKA_MODULUS_BITS,
+ &modulus_bits, sizeof (modulus_bits));
+ n_pubkey_attr++;
+ FILL_ATTR(pubkey_templ[n_pubkey_attr], CKA_PUBLIC_EXPONENT,
+ rsa.public_exponent, rsa.public_exponent_len);
+ n_pubkey_attr++;
+#endif
+ }
+ else
  if (opt_object_class == CKO_DATA) {
  CK_OBJECT_CLASS clazz = CKO_DATA;
  FILL_ATTR(data_templ[0], CKA_CLASS, &clazz, sizeof(clazz));
@@ -1392,7 +1459,6 @@
  show_object(session, cert_obj);
  }
 
-#if 0
  if (n_pubkey_attr) {
  rv = p11->C_CreateObject(session, pubkey_templ, n_pubkey_attr, &pubkey_obj);
  if (rv != CKR_OK)
@@ -1401,7 +1467,6 @@
  printf("Generated public key:\n");
  show_object(session, pubkey_obj);
  }
-#endif
 
  if (n_privkey_attr) {
  rv = p11->C_CreateObject(session, privkey_templ, n_privkey_attr, &privkey_obj);

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: patch for pkcs11-tool - write pubkey objects

Douglas E. Engert


Andreas Jellinghaus wrote:

> Hi everyone,
>
> here is a bug report with a patch for pkcs11-tool.
>
> I'm no expert on this subject, so feedback is very welcome.
> it looks good in general, except maybe more return codes/
> error checking etc., and a different code path if
> pkcs11-tool is compiled without openssl.
>
> the author asks about two attributes where he isn't
> sure what to do best. I don't know either, so if anyone
> can take care of the bug&patch, that would be great.

Just looking at the code with no way to test it, do you want
the pubkey private?

FILL_ATTR(pubkey_templ[3], CKA_PRIVATE, &_true, sizeof(_true));

>
> Thanks, Andreas
>
> ----------  Weitergeleitete Nachricht  ----------
>
> Betreff: patch for pkcs11-tool - write pubkey objects
> Datum: Montag 15 März 2010
> Von: Jaroslav Benkovský <[hidden email]>
> An: [hidden email]
>
> Hello,
> the attached patch allows pkcs11-tool to write RSA public keys to a
> device. I am not sure why it was left out at all, but I need it to get
> opendnssec working with externally generated keys and SCA6000 and this
> patch allows me to do that.
>
> I am not sure with CKA_WRAP=FALSE & CKA_ENCRYPT=FALSE, but I set it to
> be the same as device generated keys I have there.

CKA_WRAP, CKA_VERIFY, CKA_VERIFY_RECOVER, CKA_WRAP are token specific,
and/or maybe should match any attributes of a certificate that may contain
the same public key? Should these be options, as well as CKA_PRIVATE?

>
> If you have any comments, questions, etc, write me.
>
> Regards,
> Jarda Benkovsky
>
> -------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: patch for pkcs11-tool - write pubkey objects

Rickard Bellgrim
In reply to this post by Andreas Jellinghaus-2
Hi

A quick comment is that OpenDNSSEC will, probably in May, only need the private part of the key. Since you can derive the public part from the private object. This will save space in the HSM and make our code faster.

//  Rickard

On 15 mar 2010, at 21.39, Andreas Jellinghaus wrote:

> Hello,
> the attached patch allows pkcs11-tool to write RSA public keys to a
> device. I am not sure why it was left out at all, but I need it to get
> opendnssec working with externally generated keys and SCA6000 and this
> patch allows me to do that.

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: patch for pkcs11-tool - write pubkey objects

Andreas Jellinghaus-2
Am Dienstag 16 März 2010 07:20:31 schrieb Rickard Bellgrim:
> Hi
>
> A quick comment is that OpenDNSSEC will, probably in May, only need the
>  private part of the key. Since you can derive the public part from the
>  private object. This will save space in the HSM and make our code faster.

hu? a smart card will never give you its private key. you can use it for
signing or decryption, but you can't download the private key. that
is the whole point of the card/HSM. so not sure what opendnssec will need
in detail.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: patch for pkcs11-tool - write pubkey objects

Rickard Bellgrim
But you still have access to the "public parts" of the private key.

16 mar 2010 kl. 08.10 skrev "Andreas Jellinghaus" <[hidden email]>:

> Am Dienstag 16 März 2010 07:20:31 schrieb Rickard Bellgrim:
>> Hi
>>
>> A quick comment is that OpenDNSSEC will, probably in May, only need  
>> the
>> private part of the key. Since you can derive the public part from  
>> the
>> private object. This will save space in the HSM and make our code  
>> faster.
>
> hu? a smart card will never give you its private key. you can use it  
> for
> signing or decryption, but you can't download the private key. that
> is the whole point of the card/HSM. so not sure what opendnssec will  
> need
> in detail.
>
> Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: patch for pkcs11-tool - write pubkey objects

Andreas Jellinghaus-2
Am Dienstag 16 März 2010 08:28:32 schrieb Rickard Bellgrim:
> But you still have access to the "public parts" of the private key.

ok, I'm no expert here, so I can't say yes or know.

But I know that some cards hide their private keys, so you need
to login first, to see if some private key is on the card.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: patch for pkcs11-tool - write pubkey objects

Andreas Jellinghaus-2
In reply to this post by Douglas E. Engert
Am Montag 15 März 2010 22:08:28 schrieb Douglas E. Engert:

> Andreas Jellinghaus wrote:
> > Hi everyone,
> >
> > here is a bug report with a patch for pkcs11-tool.
> >
> > I'm no expert on this subject, so feedback is very welcome.
> > it looks good in general, except maybe more return codes/
> > error checking etc., and a different code path if
> > pkcs11-tool is compiled without openssl.
> >
> > the author asks about two attributes where he isn't
> > sure what to do best. I don't know either, so if anyone
> > can take care of the bug&patch, that would be great.
>
> Just looking at the code with no way to test it, do you want
> the pubkey private?

no, I guess that doesn't make sence.

> CKA_WRAP, CKA_VERIFY, CKA_VERIFY_RECOVER, CKA_WRAP are token specific,
> and/or maybe should match any attributes of a certificate that may contain
> the same public key? Should these be options, as well as CKA_PRIVATE?

not sure what people want here. what do you think is best?

a public key is not meant to be used. with a software token, maybe it is.
but with opensc I guess we don't implement public key operations at all.
so if those set the useage of the key, we should default to none of
that - software can download the public key, and do whatever they want
themself in software.

does this sound reasonable? what is your preference?

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: patch for pkcs11-tool - write pubkey objects

Martin Paljak-2
In reply to this post by Andreas Jellinghaus-2
On Mar 16, 2010, at 09:09 , Andreas Jellinghaus wrote:

> Am Dienstag 16 März 2010 07:20:31 schrieb Rickard Bellgrim:
>> Hi
>>
>> A quick comment is that OpenDNSSEC will, probably in May, only need the
>> private part of the key. Since you can derive the public part from the
>> private object. This will save space in the HSM and make our code faster.
>
> hu? a smart card will never give you its private key. you can use it for
> signing or decryption, but you can't download the private key. that
> is the whole point of the card/HSM. so not sure what opendnssec will need
> in detail.
A smart card usually never gives out the key *generated* in the card. If supported by the card it sometimes makes sense to extract the key, but not in clear. And vice versa (keys generated somewhere else are unwrapped inside the card).

From PKCS#15:
The semantics of the accessFlags field’s sensitive, extractable, alwaysSensitive, neverExtractable and local identifiers is the same as in PKCS #11. This field is not required to be present in cases where its value can be deduced by other means.
And from PKCS#11:
Additional protection can be given to private keys and secret keys by marking them as “sensitive” or “unextractable”. Sensitive keys cannot be revealed in plaintext off the token, and unextractable keys cannot be revealed off the token even when encrypted (though they can still be used as keys).

So the whole wraping/extractable/sensitive flagging is currently arbitrary and does not follow neither standard. See http://www.opensc-project.org/opensc/ticket/198 for some extra information and a patch that fixes at least one issue with the topic.

The unwrapping that *is* supported happens in software and could be done elsewhere (PKCS#11 module for smart cards should only operate with hardware based objects, if possible)


--
Martin Paljak
http://martin.paljak.pri.ee
+3725156495

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: patch for pkcs11-tool - write pubkey objects

Martin Paljak-2
In reply to this post by Andreas Jellinghaus-2
On Mar 16, 2010, at 10:18 , Andreas Jellinghaus wrote:

> Am Montag 15 März 2010 22:08:28 schrieb Douglas E. Engert:
>> Andreas Jellinghaus wrote:
>>> Hi everyone,
>>>
>>> here is a bug report with a patch for pkcs11-tool.
>>>
>>> I'm no expert on this subject, so feedback is very welcome.
>>> it looks good in general, except maybe more return codes/
>>> error checking etc., and a different code path if
>>> pkcs11-tool is compiled without openssl.
>>>
>>> the author asks about two attributes where he isn't
>>> sure what to do best. I don't know either, so if anyone
>>> can take care of the bug&patch, that would be great.
>>
>> Just looking at the code with no way to test it, do you want
>> the pubkey private?
>
> no, I guess that doesn't make sence.
>
>> CKA_WRAP, CKA_VERIFY, CKA_VERIFY_RECOVER, CKA_WRAP are token specific,
>> and/or maybe should match any attributes of a certificate that may contain
>> the same public key? Should these be options, as well as CKA_PRIVATE?
Configurable CKA_PRIVATE makes sense.

> a public key is not meant to be used. with a software token, maybe it is.
> but with opensc I guess we don't implement public key operations at all.
> so if those set the useage of the key, we should default to none of
> that - software can download the public key, and do whatever they want
> themself in software.

Having support of CKA_WRAP is admirable but right now the whole wrap/unwrap for *hardware* operations (what should be the task of OpenSC) is broken. So the usage could be reviewed but AFAIK currently no card driver implements the wrapping that would be expected when using a hardware token.

--
Martin Paljak
http://martin.paljak.pri.ee
+3725156495

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: patch for pkcs11-tool - write pubkey objects

Rickard Bellgrim
In reply to this post by Andreas Jellinghaus-2

On 16 mar 2010, at 09.15, Andreas Jellinghaus wrote:

> Am Dienstag 16 März 2010 08:28:32 schrieb Rickard Bellgrim:
>> But you still have access to the "public parts" of the private key.
>
> ok, I'm no expert here, so I can't say yes or know.
>
> But I know that some cards hide their private keys, so you need
> to login first, to see if some private key is on the card.

I read some more in the PKCS#11 specification, and it actually says that only the CKA_MODULUS and CKA_PRIVATE_EXPONENT is required to be stored by the token. It is then up to the token if it wants to store the other attributes of the private key object.

You need CKA_MODULUS and CKA_PUBLIC_EXPONENT in order to create a public key from the data in the private key. You can access these attributes if:
- The private key object is public.
- If the object is private, then the user needs to be logged in.
- And the token needs to store the attributes.

OpenDNSSEC always login into the token, so that is no problem. But the conclusion is that you cannot guarantee that the CKA_PUBLIC_EXPONENT of the private key object is available.

Is there any implementation that does not store the CKA_PUBLIC_EXPONENT?

If so, then it clearly is a need of the public key object. The key might not be generated on the same machine as it is used.

Or another solution is that the application also writes the public key to disc, when it is still available. And then you make sure that you have your private key on a smartcard and the public key written on a paper.

// Rickard
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: patch for pkcs11-tool - write pubkey objects

Tomas Gustavsson-3

If using PKCS#11 I would personally not go down a path that is not
commonly used. The common usage of smart cards and hardware security
modules always stores both the private (as a sensitive object) and the
public key (either as a public key or as an x.509 certificate).
This works and is well tested and is sure to work across a wide range of
smart cards and hardware security modules.

Why is this not suitable for OpenDNSSEC.

Cheers,
Tomas

On 03/16/2010 01:40 PM, Rickard Bellgrim wrote:

>
> On 16 mar 2010, at 09.15, Andreas Jellinghaus wrote:
>
>> Am Dienstag 16 März 2010 08:28:32 schrieb Rickard Bellgrim:
>>> But you still have access to the "public parts" of the private key.
>>
>> ok, I'm no expert here, so I can't say yes or know.
>>
>> But I know that some cards hide their private keys, so you need
>> to login first, to see if some private key is on the card.
>
> I read some more in the PKCS#11 specification, and it actually says that only the CKA_MODULUS and CKA_PRIVATE_EXPONENT is required to be stored by the token. It is then up to the token if it wants to store the other attributes of the private key object.
>
> You need CKA_MODULUS and CKA_PUBLIC_EXPONENT in order to create a public key from the data in the private key. You can access these attributes if:
> - The private key object is public.
> - If the object is private, then the user needs to be logged in.
> - And the token needs to store the attributes.
>
> OpenDNSSEC always login into the token, so that is no problem. But the conclusion is that you cannot guarantee that the CKA_PUBLIC_EXPONENT of the private key object is available.
>
> Is there any implementation that does not store the CKA_PUBLIC_EXPONENT?
>
> If so, then it clearly is a need of the public key object. The key might not be generated on the same machine as it is used.
>
> Or another solution is that the application also writes the public key to disc, when it is still available. And then you make sure that you have your private key on a smartcard and the public key written on a paper.
>
> // Rickard
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: patch for pkcs11-tool - write pubkey objects

Tomas Gustavsson
In reply to this post by Rickard Bellgrim

If using PKCS#11 I would personally not go down a path that is not
commonly used. The common usage of smart cards and hardware security
modules always stores both the private (as a sensitive object) and the
public key (either as a public key or as an x.509 certificate).
This works and is well tested and is sure to work across a wide range of
smart cards and hardware security modules.

Why is this not suitable for OpenDNSSEC.

Cheers,
Tomas

On 03/16/2010 01:40 PM, Rickard Bellgrim wrote:

>
> On 16 mar 2010, at 09.15, Andreas Jellinghaus wrote:
>
>> Am Dienstag 16 März 2010 08:28:32 schrieb Rickard Bellgrim:
>>> But you still have access to the "public parts" of the private key.
>>
>> ok, I'm no expert here, so I can't say yes or know.
>>
>> But I know that some cards hide their private keys, so you need
>> to login first, to see if some private key is on the card.
>
> I read some more in the PKCS#11 specification, and it actually says that only the CKA_MODULUS and CKA_PRIVATE_EXPONENT is required to be stored by the token. It is then up to the token if it wants to store the other attributes of the private key object.
>
> You need CKA_MODULUS and CKA_PUBLIC_EXPONENT in order to create a public key from the data in the private key. You can access these attributes if:
> - The private key object is public.
> - If the object is private, then the user needs to be logged in.
> - And the token needs to store the attributes.
>
> OpenDNSSEC always login into the token, so that is no problem. But the conclusion is that you cannot guarantee that the CKA_PUBLIC_EXPONENT of the private key object is available.
>
> Is there any implementation that does not store the CKA_PUBLIC_EXPONENT?
>
> If so, then it clearly is a need of the public key object. The key might not be generated on the same machine as it is used.
>
> Or another solution is that the application also writes the public key to disc, when it is still available. And then you make sure that you have your private key on a smartcard and the public key written on a paper.
>
> // Rickard
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: patch for pkcs11-tool - write pubkey objects

Andreas Jellinghaus-2
In reply to this post by Rickard Bellgrim
hmm. my vague memory tells me with some cards you generate a private key,
and only then - right after generating - you get the public key as response.
so it needs to be saved right away as rsa public key object or a certificate
signing requests needs to be generated, else you can't download the public
key again.

but maybe was only a very strange card or library, and I guess usualy
it is not the case.

I too expect that most software library + card combinations will have
rsa public keys, and even if not, that you can get the public parts from
the private key object (maybe a login is required first).

I only wanted to note that some strange software/card might be quite
limited and cause problems.

my advice would be: if people had a certificate on the card, the
public key can be read from that. if not, maybe there is a rsa public
key that can be used as source. if not maybe the rsa secret key will
give you the public key details.

I'm not sure if the extra work for those two "if not" is worth the work,
but our pam_p11 bug we had these days shows that users expect a card to
work without certificates, even though that is very strange for us
developers.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: patch for pkcs11-tool - write pubkey objects

Douglas E. Engert


Andreas Jellinghaus wrote:
> hmm. my vague memory tells me with some cards you generate a private key,
> and only then - right after generating - you get the public key as response.
> so it needs to be saved right away as rsa public key object or a certificate
> signing requests needs to be generated, else you can't download the public
> key again.

The PIV card works like this. The piv-tool can tell the card to generate a
key pair the returns the pubkey that is saved to a file.  The pubkey can then
be used in a certificate request, and the piv-tool can write the certificate
to the card. The pkcs15-piv.c will then emulate a public key object by reading
the certificate.

>
> but maybe was only a very strange card or library, and I guess usualy
> it is not the case.
>
> I too expect that most software library + card combinations will have
> rsa public keys, and even if not, that you can get the public parts from
> the private key object (maybe a login is required first).
>
> I only wanted to note that some strange software/card might be quite
> limited and cause problems.
>
> my advice would be: if people had a certificate on the card, the
> public key can be read from that. if not, maybe there is a rsa public
> key that can be used as source.

This is what the PIV driver does when signing the certificate request.
It get the pub key from the file saved by piv-tool.

> if not maybe the rsa secret key will give you the public key details.
>
> I'm not sure if the extra work for those two "if not" is worth the work,
> but our pam_p11 bug we had these days shows that users expect a card to
> work without certificates, even though that is very strange for us
> developers.

To bad. If they are trying to use these cards for SSH the certificate
could be self signed, just used to hold the public key.

>
> Regards, Andreas
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: patch for pkcs11-tool - write pubkey objects

Rickard Bellgrim
In reply to this post by Tomas Gustavsson-3

On 16 mar 2010, at 13.50, Tomas Gustavsson wrote:

>
> If using PKCS#11 I would personally not go down a path that is not
> commonly used. The common usage of smart cards and hardware security
> modules always stores both the private (as a sensitive object) and the
> public key (either as a public key or as an x.509 certificate).
> This works and is well tested and is sure to work across a wide range of
> smart cards and hardware security modules.
>
> Why is this not suitable for OpenDNSSEC.

We currently do use both the private and public key object. It is just that we have heard different stories. E.g. when I tried to get a similar patch into pkcs11-tool one year ago. And from others saying that it is important to save the space in the HSM due to licensing or limited space.

And your recommendation from the smarcard industry is to use both the private and public key object?

// Rickard
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: patch for pkcs11-tool - write pubkey objects

Martin Paljak-2
In reply to this post by Tomas Gustavsson
On Mar 16, 2010, at 15:31 , Tomas Gustavsson wrote:
>
> If using PKCS#11 I would personally not go down a path that is not
> commonly used. The common usage of smart cards and hardware security
> modules always stores both the private (as a sensitive object) and the
> public key (either as a public key or as an x.509 certificate).
> This works and is well tested and is sure to work across a wide range of
> smart cards and hardware security modules.
>
> Why is this not suitable for OpenDNSSEC.


IMO as well, either a key or a certificate is the atomic object dealt with by most software. I would not suggest breaking this without a specific requirement (I don't think that saving space in HSM would be one - a greater HSM would fix the problem ;))


--
Martin Paljak
http://martin.paljak.pri.ee
+3725156495

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: patch for pkcs11-tool - write pubkey objects

Tomas Gustavsson-6
In reply to this post by Rickard Bellgrim
On 03/16/2010 11:16 PM, Rickard Bellgrim wrote:

> On 16 mar 2010, at 13.50, Tomas Gustavsson wrote:
>
>    
>> If using PKCS#11 I would personally not go down a path that is not
>> commonly used. The common usage of smart cards and hardware security
>> modules always stores both the private (as a sensitive object) and the
>> public key (either as a public key or as an x.509 certificate).
>> This works and is well tested and is sure to work across a wide range of
>> smart cards and hardware security modules.
>>
>> Why is this not suitable for OpenDNSSEC.
>>      
> We currently do use both the private and public key object. It is just that we have heard different stories. E.g. when I tried to get a similar patch into pkcs11-tool one year ago. And from others saying that it is important to save the space in the HSM due to licensing or limited space.
>
> And your recommendation from the smarcard industry is to use both the private and public key object?
>    

Definately my recommendation. I'm also working with all the big HSM
vendors and you don't have to save space on any of them, at a minimum
you can store about one hundred objects in a single slot. So for PKI
purposes there is vast space available. None of the big HSM vendors
license per storage, it's simple one-time purchase price of the HSM
hardware (+ support costs that are a percentage of the price).

Keep it simple :-)

Cheers,
Tomas

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: patch for pkcs11-tool - write pubkey objects

Martin Paljak-2
On Mar 17, 2010, at 08:31 , Tomas Gustavsson wrote:
> None of the big HSM vendors
> license per storage, it's simple one-time purchase price of the HSM
> hardware (+ support costs that are a percentage of the price).

Just curious: what does the support cost include and am I disallowed to use the hardware or software if I don't pay the support cost?

--
Martin Paljak
http://martin.paljak.pri.ee
+3725156495

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: patch for pkcs11-tool - write pubkey objects

Tomas Gustavsson-6
On 03/18/2010 09:07 AM, Martin Paljak wrote:
> On Mar 17, 2010, at 08:31 , Tomas Gustavsson wrote:
>> None of the big HSM vendors
>> license per storage, it's simple one-time purchase price of the HSM
>> hardware (+ support costs that are a percentage of the price).
>
> Just curious: what does the support cost include and am I disallowed to use the hardware or software if I don't pay the support cost?
>

Usually you can use the HSM fine without support (if you can stand the
sales persons constant calls :-)).
Support includes firmware and software updates as well as
phone/email/etc support for issues about the usage that you may encounter.
We have run across the occasional bug in HSMs...

Cheers,
Tomas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: patch for pkcs11-tool - write pubkey objects

Rickard Bellgrim
In reply to this post by Tomas Gustavsson-6

Definately my recommendation. I'm also working with all the big HSM
vendors and you don't have to save space on any of them, at a minimum
you can store about one hundred objects in a single slot. So for PKI
purposes there is vast space available. None of the big HSM vendors
license per storage, it's simple one-time purchase price of the HSM
hardware (+ support costs that are a percentage of the price).

Keep it simple :-)

The SafeNet Luna HSM has a limitation to 1000 objects according to one of our project member. We use the Sun SCA6000 and it has a bug in its software the limits it to around 600 objects.

DNSSEC is used as an security extension to DNS. In DNSSEC there are two types of keys. KSK (Key Signing Key) and ZSK (Zone Signing Key). The KSK is a stronger key and used for creating trust between the parent zone and the current zone. ZSK is smaller which makes it faster to sign the rest of the zone. You typically roll the KSK every other year. And the ZSK every quarter.

We have no problem since we are only signing one DNS zone, which means at a maximum 10 objects (Rolling the ZSK and rolling one of the overlapping KSKs. All with both private and public key objects).

However, the one using the SafeNet is responsible for a national university network with around 300 zones. And if they decide to not share the keys between the zones (there is a debate in the DNSSEC community on whether you should do this or not), then they will have 1200 objects (each zone has a KSK and ZSK, both with private and public key object).

So you see, it is worth saving space.

The same person is also a PKCS#11-expert. And he says that he has never seen an implementation, which does not store the CKA_PUBLIC_EXPONENT in the private key object. To save space in the smartcard, vendors usually store the private and public key material in one space. If you remove the public key object, then you still have the key material left for the private key object. Thus making it possible to only have the private key object. Which complies to the arguments that this list had one year ago, to let the pkcs11-tool only save the private key object.

// Rickard

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
12