opensc pkcs11 and random numbers

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

opensc pkcs11 and random numbers

Nils Larsch
Moin,

[a continuation of the discussion started in the "compatibility" thread]

currently the opensc pkcs11 lib offers a stub for the
C_GenerateRandom which internally uses the openssl rng
seeded with 20 bytes from the card (via GET CHALLENGE) and
some data from scrandom (why ?). I think this is somewhat
misleading as a user should expect that a pkcs11 lib
returns 100% hardware generated random numbers. Furthermore
the iso7816 command GET CHALLENGE used for getting random data
from the card is intented to be used for a mutual (or external)
authentication and not as a general purpose source of random
data (at least this is not documented in iso7816), hence we
are currently using it in a way not it's not intended to
be used (not so good).

Personally I think we should either remove the support for
C_GenerateRandom or only return data from GET CHALLENGE
(this will be terrible slow but smartcards are slow). I
don't think the current behaviour is really acceptable.

Comments are welcome.

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

Re: opensc pkcs11 and random numbers

Martin Paljak
On 7/15/05, Nils Larsch <[hidden email]> wrote:
 
> Personally I think we should either remove the support for
> C_GenerateRandom or only return data from GET CHALLENGE

Why should we remove it? Basically applications care about: good
random numbers as fast as possible as many as requested. Smartcard
random sources do matter IMHO only if they are used internally by the
card - applications on the host side should not care about it. So for
applications using pkcs11 it would be quite natural to use the same
module for random.

> (this will be terrible slow but smartcards are slow). I
> don't think the current behaviour is really acceptable.

I'd prefer random numbers in the host environment from a good and fast
random source available - usually available via /dev/random  or some
platform api (cryptoapi on windows).


About scrandom in the source - i'd suggest to put it into libopensc as
it is now. It doesn't hurt to have an API call like sc_random_bytes
that could just do what expected: good random numbers as fast as
possible as many as requested - if it uses windows crypto api,
/dev/random or is just a wrapper for openssl calls doesn't matter that
much.

--
Martin Paljak
[hidden email]
http://martin.paljak.pri.ee/
+372.5156495 - phone
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: opensc pkcs11 and random numbers

Nils Larsch
Martin Paljak wrote:
> On 7/15/05, Nils Larsch <[hidden email]> wrote:
>  
>
>>Personally I think we should either remove the support for
>>C_GenerateRandom or only return data from GET CHALLENGE
>
>
> Why should we remove it?

perhaps because smartcard are no (good) source for random numbers
(and after all a pkcs11 lib should offer an api to use the services
the hardware token offers and not more)

> Basically applications care about: good
> random numbers as fast as possible as many as requested. Smartcard
> random sources do matter IMHO only if they are used internally by the
> card - applications on the host side should not care about it. So for
> applications using pkcs11 it would be quite natural to use the same
> module for random.

but then the calling application should wait until GET CHALLENGE
has collected enough bytes (and this _is_ as fast as possible a
smartcard can collect random data). If this is too slow the
user/application should use another source of random data.

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

Re: opensc pkcs11 and random numbers

Nils Larsch
Martin Paljak wrote:

>>>Why should we remove it?
>>
>>perhaps because smartcard are no (good) source for random numbers
>>(and after all a pkcs11 lib should offer an api to use the services
>>the hardware token offers and not more)
>
> I guess nothing will stop working if we remove it. So we can remove it
> as needed.
>
>
>>>Basically applications care about: good
>>>random numbers as fast as possible as many as requested. Smartcard
>
> ...
>
>>>applications using pkcs11 it would be quite natural to use the same
>>>module for random.
>>
>>but then the calling application should wait until GET CHALLENGE
>>has collected enough bytes (and this _is_ as fast as possible a
>>smartcard can collect random data). If this is too slow the
>>user/application should use another source of random data.
>
>
> What i want to say - it doesn't _have_ to be a smartcard. Actually
> there's no difference at all what is the source of the randomness as
> long as it is good enough or as good as it could be. So i see no real
> and practical difference in /dev/random and a smartcard as a random
> source to the pkcs11 library call (one could argue of course)

I think that would be even worse; pkcs11 provides an api to use a
specific hardware token so I think it's reasonable to assume that
the actual cryptographic operations are carried out by underlying
hardware token and not in software (this is not unimportant from
security point of view).

If applications using pkcs11 assume that every pkcs11 lib can
supply random data then these applications are broken and should
be fixed.

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

Re: opensc pkcs11 and random numbers [u]

Andreas Jellinghaus-2
In reply to this post by Nils Larsch
Two questions from my side:
 - are we aware of any application that breaks, if we remove C_GetRandom?
 - if we remove that, can we also remove scrandom and related code, or
   do we still need it somewhere?

scrandom looks small, but there is quite a lot of code related to it,
like configure code for prngd, configure code for the random source,
and that way networking code inside sc_random.

also, if we want to or need to keep scrandom functionality, can we
make it depend on openssl or would that harm is in the non-openssl
case? (openssl can give us random bytes, that way we could drop
the configure code and networking code, too).

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

Re: opensc pkcs11 and random numbers [u]

Andreas Jellinghaus-2
In reply to this post by Nils Larsch
On Friday 15 July 2005 20:08, Nils Larsch wrote:
> I think that would be even worse; pkcs11 provides an api to use a
> specific hardware token so I think it's reasonable to assume that
> the actual cryptographic operations are carried out by underlying
> hardware token

what smart cards have apdu's to give us random data?
can we implement the whole chain from C_GetRandom to those
apdu? lots of work or easy?

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

Re: opensc pkcs11 and random numbers [u]

Nils Larsch
Andreas Jellinghaus [c] wrote:
> On Friday 15 July 2005 20:08, Nils Larsch wrote:
>
>>I think that would be even worse; pkcs11 provides an api to use a
>>specific hardware token so I think it's reasonable to assume that
>>the actual cryptographic operations are carried out by underlying
>>hardware token
>
>
> what smart cards have apdu's to give us random data?

afaik only GET CHALLENGE (smartcards are simply too slow to be
good usable source of random data)

> can we implement the whole chain from C_GetRandom to those
> apdu? lots of work or easy?

should be easy using GET CHALLENGE

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

Re: opensc pkcs11 and random numbers [u]

David Corcoran
Most of those already supported by OpenSC should support random  
generation.  As most of those
cards support external authentication, there must be a nonce  
generation capability, Get Challenge.

Thanks,
Dave



On Jul 15, 2005, at 2:14 PM, Nils Larsch wrote:

> Andreas Jellinghaus [c] wrote:
>
>> On Friday 15 July 2005 20:08, Nils Larsch wrote:
>>
>>> I think that would be even worse; pkcs11 provides an api to use a
>>> specific hardware token so I think it's reasonable to assume that
>>> the actual cryptographic operations are carried out by underlying
>>> hardware token
>>>
>> what smart cards have apdu's to give us random data?
>>
>
> afaik only GET CHALLENGE (smartcards are simply too slow to be
> good usable source of random data)
>
>
>> can we implement the whole chain from C_GetRandom to those
>> apdu? lots of work or easy?
>>
>
> should be easy using GET CHALLENGE
>
> Nils
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
>
>

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

Re: opensc pkcs11 and random numbers [u]

Nils Larsch
In reply to this post by Andreas Jellinghaus-2
Andreas Jellinghaus [c] wrote:
> Two questions from my side:
>  - are we aware of any application that breaks, if we remove C_GetRandom?

that would surprise me

>  - if we remove that, can we also remove scrandom and related code, or
>    do we still need it somewhere?

afaik it's not needed somewhere else.

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

Re: opensc pkcs11 and random numbers

Peter Stuge
In reply to this post by Nils Larsch
On Fri, Jul 15, 2005 at 08:08:05PM +0200, Nils Larsch wrote:
> Martin Paljak wrote:
> >>>Why should we remove it?
> >>
> >>perhaps because smartcard are no (good) source for random numbers
> >>(and after all a pkcs11 lib should offer an api to use the
> >>services the hardware token offers and not more)

I agree with Nils 100% about PKCS#11 providing access to a token.
Whether the token is a good source or not is up to each application
developer, but it is certainly not a _fast_ source of random numbers.
I'd assume the random numbers to be of fairly good quality however.


> >>>Basically applications care about: good random numbers as fast
> >>>as possible as many as requested.

Good and fast are probably exclusive. :)


> >>>applications using pkcs11 it would be quite natural to use the same
> >>>module for random.
> >>
> >>but then the calling application should wait until GET CHALLENGE
> >>has collected enough bytes (and this _is_ as fast as possible a
> >>smartcard can collect random data). If this is too slow the
> >>user/application should use another source of random data.
> >
> >
> >What i want to say - it doesn't _have_ to be a smartcard. Actually
> >there's no difference at all what is the source of the randomness as
> >long as it is good enough or as good as it could be. So i see no real
> >and practical difference in /dev/random and a smartcard as a random
> >source to the pkcs11 library call (one could argue of course)
>
> I think that would be even worse; pkcs11 provides an api to use a
> specific hardware token so I think it's reasonable to assume that
> the actual cryptographic operations are carried out by underlying
> hardware token and not in software (this is not unimportant from
> security point of view).

I don't think there's any point in discussing this, I'm 100% with
Nils, and so is the standard. See 11.15, "Random number generation
functions":

"C_SeedRandom mixes addition seed material into the token's random
number generator."

C_GenerateRandom doesn't say where the generated random or
pseudo-random data comes from, but several of the return values
indicate are related to the token, which would not make much sense if
the implementation was expected to reside in the PKCS#11 library.

Absolutely a bad thing<tm> to implement PKCS#11 functionality in
software IMHO, if it's there and I can use it, it must be done in
the token.


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

Re: opensc pkcs11 and random numbers [u]

Andreas Jellinghaus-2
In reply to this post by Nils Larsch
On Friday 15 July 2005 21:24, Nils Larsch wrote:

> Andreas Jellinghaus [c] wrote:
> > Two questions from my side:
> >  - are we aware of any application that breaks, if we remove C_GetRandom?
>
> that would surprise me
>
> >  - if we remove that, can we also remove scrandom and related code, or
> >    do we still need it somewhere?
>
> afaik it's not needed somewhere else.

In that case I'm all for removing it.
Or implement it via get challenge command.
Or at least make it dependend on openssl and remove the prng support&friends.

If you dislike this idea, please let me know soon, and I want
to work on configure code and it might be too late otherwise.

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

Re: opensc pkcs11 and random numbers [u]

Nils Larsch
Andreas Jellinghaus [c] wrote:

> On Friday 15 July 2005 21:24, Nils Larsch wrote:
>
>>Andreas Jellinghaus [c] wrote:
>>
>>>Two questions from my side:
>>> - are we aware of any application that breaks, if we remove C_GetRandom?
>>
>>that would surprise me
>>
>>
>>> - if we remove that, can we also remove scrandom and related code, or
>>>   do we still need it somewhere?
>>
>>afaik it's not needed somewhere else.
>
>
> In that case I'm all for removing it.
> Or implement it via get challenge command.
> Or at least make it dependend on openssl and remove the prng support&friends.
>
> If you dislike this idea, please let me know soon, and I want
> to work on configure code and it might be too late otherwise.

I vote for the GET CHALLENGE option. And if we agree on that I will
patch the code to use GET CHALLENGE only.

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

Re: opensc pkcs11 and random numbers [u]

Damien Sauveron
Nils Larsch a écrit :

> Andreas Jellinghaus [c] wrote:
>> In that case I'm all for removing it.
>> Or implement it via get challenge command.
>> Or at least make it dependend on openssl and remove the prng
>> support&friends.
>>
>> If you dislike this idea, please let me know soon, and I want
>> to work on configure code and it might be too late otherwise.
>
>
> I vote for the GET CHALLENGE option. And if we agree on that I will
> patch the code to use GET CHALLENGE only.
I do not use OpenSC but I read you with interest.
IMHO GET CHALLENGE seems more consistent with the PKCS#11 philosphy.

My 2 cents!

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

Re: opensc pkcs11 and random numbers [u]

Peter Stuge
In reply to this post by Nils Larsch
On Fri, Jul 15, 2005 at 10:33:42PM +0200, Nils Larsch wrote:
> Andreas Jellinghaus [c] wrote:
> >If you dislike this idea, please let me know soon, and I want
> >to work on configure code and it might be too late otherwise.
>
> I vote for the GET CHALLENGE option. And if we agree on that I will
> patch the code to use GET CHALLENGE only.

If there's no more generic APDU for getting random data, I would like
that behavior too.


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

Re: opensc pkcs11 and random numbers [u]

Andreas Jellinghaus-2
In reply to this post by Nils Larsch
On Friday 15 July 2005 22:33, Nils Larsch wrote:
> I vote for the GET CHALLENGE option. And if we agree on that I will
> patch the code to use GET CHALLENGE only.

I agree that is the best option (except that I wouldn't know well
how to do it myself). Thanks a lot.

so there is no harm if I remove scrandom/ and the configure
code the next time I touch that area (maybe tomorrow)?

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

Re: opensc pkcs11 and random numbers [u]

Stef Hoeben
In reply to this post by Andreas Jellinghaus-2
Andreas Jellinghaus [c] wrote:

>On Friday 15 July 2005 20:08, Nils Larsch wrote:
>  
>
>>I think that would be even worse; pkcs11 provides an api to use a
>>specific hardware token so I think it's reasonable to assume that
>>the actual cryptographic operations are carried out by underlying
>>hardware token
>>    
>>
>
>what smart cards have apdu's to give us random data?
>can we implement the whole chain from C_GetRandom to those
>apdu? lots of work or easy?
>

All cards that have a GET CHALLENGE command should return a number a decent
to very good random bytes (e.g. Belgian eID card has a HW random
generator on board).

That's what our current OpenSC implementation is using (and personally I
would like
to keep it this way.)

 > If applications using pkcs11 assume that every pkcs11 lib can
 > supply random data then these applications are broken and should
 > be fixed.

There's a flag that applications have to check first to see whether they
can ask randomness.
So if the token says it has randomness, the app can take it from there;
otherwise it has
to look elsewhere (possibly slower or with user-interaction).
Our pkcs11 lib supports the "random flag" nicely, AFAIK.

Cheers,
Stef

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

Re: opensc pkcs11 and random numbers [u]

Nils Larsch
Stef Hoeben wrote:

> Andreas Jellinghaus [c] wrote:
>
>> On Friday 15 July 2005 20:08, Nils Larsch wrote:
>>  
>>
>>> I think that would be even worse; pkcs11 provides an api to use a
>>> specific hardware token so I think it's reasonable to assume that
>>> the actual cryptographic operations are carried out by underlying
>>> hardware token
>>>  
>>
>>
>> what smart cards have apdu's to give us random data?
>> can we implement the whole chain from C_GetRandom to those
>> apdu? lots of work or easy?
>>
>
> All cards that have a GET CHALLENGE command should return a number a decent
> to very good random bytes (e.g. Belgian eID card has a HW random
> generator on board).
>
> That's what our current OpenSC implementation is using (and personally I
> would like to keep it this way.)
the current code uses the card generated random data to seed a software
prng and it does not directly return the card random data to the user.
As I already said: pkcs11 should supply an api to access a crypto
token, if a specific service (e.g. random number generation) is
terrible slow it's not the job of the pkcs11 lib to supply a workaround
(if the application wants faster random data it should do the prng stuff
itself).

Attached is a patch to correct this. If there a no objections I will
commit it.

Nils

Index: src/pkcs11/framework-pkcs15.c
===================================================================
--- src/pkcs11/framework-pkcs15.c (Revision 2426)
+++ src/pkcs11/framework-pkcs15.c (Arbeitskopie)
@@ -1413,6 +1413,17 @@
 }
 #endif
 
+static CK_RV pkcs15_get_random(struct sc_pkcs11_card *p11card,
+ CK_BYTE_PTR p, CK_ULONG len)
+{
+ int rc;
+        struct pkcs15_fw_data *fw_data = (struct pkcs15_fw_data *) p11card->fw_data;
+        struct sc_card *card = fw_data->p15_card->card;
+
+ rc = sc_get_challenge(card, p, (size_t)len);
+ return sc_to_cryptoki_error(rc, p11card->reader);
+}
+
 struct sc_pkcs11_framework_ops framework_pkcs15 = {
  pkcs15_bind,
  pkcs15_unbind,
@@ -1428,8 +1439,11 @@
  pkcs15_gen_keypair,
 #else
  NULL,
+ NULL,
  NULL
 #endif
+ NULL, /* seed_random */
+ pkcs15_get_random
 };
 
 static CK_RV pkcs15_set_attrib(struct sc_pkcs11_session *session,
Index: src/pkcs11/pkcs11-object.c
===================================================================
--- src/pkcs11/pkcs11-object.c (Revision 2426)
+++ src/pkcs11/pkcs11-object.c (Arbeitskopie)
@@ -918,8 +918,8 @@
    CK_BYTE_PTR       pSeed,     /* the seed material */
    CK_ULONG          ulSeedLen) /* count of bytes of seed material */
 {
-#ifdef NEW_IMPLEMENTATION_COMPLETE
  struct sc_pkcs11_session *session;
+ struct sc_pkcs11_slot    *slot;
  int rv;
 
  rv = sc_pkcs11_lock();
@@ -927,22 +927,24 @@
  return rv;
 
  rv = pool_find(&session_pool, hSession, (void**) &session);
- if (rv == CKR_OK)
- rv = sc_pkcs11_openssl_add_seed_rand(session, pSeed, ulSeedLen);
+ if (rv == CKR_OK) {
+ slot = session->slot;
+ if (slot->card->framework->seed_random == NULL)
+ rv = CKR_FUNCTION_NOT_SUPPORTED;
+ else
+ rv = slot->card->framework->seed_random(slot->card, pSeed, ulSeedLen);
+ }
 
  sc_pkcs11_unlock();
  return rv;
-#else
- return CKR_FUNCTION_NOT_SUPPORTED;
-#endif
 }
 
 CK_RV C_GenerateRandom(CK_SESSION_HANDLE hSession,    /* the session's handle */
        CK_BYTE_PTR       RandomData,  /* receives the random data */
        CK_ULONG          ulRandomLen) /* number of bytes to be generated */
 {
-#ifdef NEW_IMPLEMENTATION_COMPLETE
  struct sc_pkcs11_session *session;
+ struct sc_pkcs11_slot    *slot;
  int rv;
 
  rv = sc_pkcs11_lock();
@@ -950,14 +952,16 @@
  return rv;
 
  rv = pool_find(&session_pool, hSession, (void**) &session);
- if (rv == CKR_OK)
- rv = sc_pkcs11_openssl_add_gen_rand(session, RandomData, ulRandomLen);
+ if (rv == CKR_OK) {
+ slot = session->slot;
+ if (slot->card->framework->get_random == NULL)
+ rv = CKR_FUNCTION_NOT_SUPPORTED;
+ else
+ rv = slot->card->framework->get_random(slot->card, RandomData, ulRandomLen);
+ }
 
  sc_pkcs11_unlock();
  return rv;
-#else
- return CKR_FUNCTION_NOT_SUPPORTED;
-#endif
 }
 
 CK_RV C_GetFunctionStatus(CK_SESSION_HANDLE hSession) /* the session's handle */
Index: src/pkcs11/sc-pkcs11.h
===================================================================
--- src/pkcs11/sc-pkcs11.h (Revision 2426)
+++ src/pkcs11/sc-pkcs11.h (Arbeitskopie)
@@ -174,9 +174,12 @@
  CK_ATTRIBUTE_PTR pPubKeyTempl, CK_ULONG ulPubKeyAttrCnt,
  CK_ATTRIBUTE_PTR pPrivKeyTempl, CK_ULONG ulPrivKeyAttrCnt,
  CK_OBJECT_HANDLE_PTR phPubKey, CK_OBJECT_HANDLE_PTR phPrivKey);
+ CK_RV (*seed_random)(struct sc_pkcs11_card *p11card,
+ CK_BYTE_PTR, CK_ULONG);
+ CK_RV (*get_random)(struct sc_pkcs11_card *p11card,
+ CK_BYTE_PTR, CK_ULONG);
 };
 
-
 /*
  * PKCS#11 Slot (used to access card with specific framework data)
  */
@@ -419,8 +422,6 @@
 
 #ifdef HAVE_OPENSSL
 /* Random generation functions */
-CK_RV sc_pkcs11_openssl_add_seed_rand(struct sc_pkcs11_session *, CK_BYTE_PTR, CK_ULONG);
-CK_RV sc_pkcs11_openssl_add_gen_rand(struct sc_pkcs11_session *, CK_BYTE_PTR, CK_ULONG);
 CK_RV sc_pkcs11_gen_keypair_soft(CK_KEY_TYPE keytype, CK_ULONG keybits,
  struct sc_pkcs15_prkey *privkey, struct sc_pkcs15_pubkey *pubkey);
 CK_RV sc_pkcs11_verify_data(unsigned char *pubkey, int pubkey_len,
Index: src/pkcs11/openssl.c
===================================================================
--- src/pkcs11/openssl.c (Revision 2426)
+++ src/pkcs11/openssl.c (Arbeitskopie)
@@ -120,43 +120,6 @@
  op->priv_data = NULL;
 }
 
-CK_RV
-sc_pkcs11_openssl_add_seed_rand(struct sc_pkcs11_session *session,
- CK_BYTE_PTR pSeed, CK_ULONG ulSeedLen)
-{
- if (!(session->slot->card->card->caps & SC_CARD_CAP_RNG))
- return CKR_RANDOM_NO_RNG;
-
- if (pSeed == NULL || ulSeedLen == 0)
- return CKR_OK;
-
- RAND_seed(pSeed, ulSeedLen);
-
- return CKR_OK;
-}
-
-CK_RV
-sc_pkcs11_openssl_add_gen_rand(struct sc_pkcs11_session *session,
- CK_BYTE_PTR RandomData, CK_ULONG ulRandomLen)
-{
- unsigned char seed[20];
- int r;
-
- if (!(session->slot->card->card->caps & SC_CARD_CAP_RNG))
- return CKR_RANDOM_NO_RNG;
-
- if (RandomData == NULL || ulRandomLen == 0)
- return CKR_OK;
-
- r = sc_get_challenge(session->slot->card->card, RandomData, ulRandomLen);
- if (r != 0) {
- sc_error(context, "sc_get_challenge() returned %d\n", r);
- return sc_to_cryptoki_error(r, session->slot->card->reader);
- }
-
- return r == 1 ? CKR_OK : CKR_FUNCTION_FAILED;
-}
-
 static int
 do_convert_bignum(sc_pkcs15_bignum_t *dst, BIGNUM *src)
 {

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

Re: opensc pkcs11 and random numbers [u]

Stef Hoeben
Nils Larsch wrote:

> Stef Hoeben wrote:
>
>> Andreas Jellinghaus [c] wrote:
>>
>>> On Friday 15 July 2005 20:08, Nils Larsch wrote:
>>>  
>>>
>>>> I think that would be even worse; pkcs11 provides an api to use a
>>>> specific hardware token so I think it's reasonable to assume that
>>>> the actual cryptographic operations are carried out by underlying
>>>> hardware token
>>>>  
>>>
>>>
>>>
>>> what smart cards have apdu's to give us random data?
>>> can we implement the whole chain from C_GetRandom to those
>>> apdu? lots of work or easy?
>>>
>>
>> All cards that have a GET CHALLENGE command should return a number a
>> decent
>> to very good random bytes (e.g. Belgian eID card has a HW random
>> generator on board).
>>
>> That's what our current OpenSC implementation is using (and
>> personally I would like to keep it this way.)
>
>
> the current code uses the card generated random data to seed a software
> prng and it does not directly return the card random data to the user.
> As I already said: pkcs11 should supply an api to access a crypto
> token, if a specific service (e.g. random number generation) is
> terrible slow it's not the job of the pkcs11 lib to supply a workaround
> (if the application wants faster random data it should do the prng stuff
> itself).
>
> Attached is a patch to correct this. If there a no objections I will
> commit it.

On the one hand, we're now rid of scrandom and the openssl dependency,
so that's nice.

On the other hand,
- you now neglect the randomness supplied by the app (less secure)
- using a SW algo to derive randomness from a good seed (called a PRNG
   or pseudo random number generator) is nothing dirty or insecure. It's
a basic
   crypto 'building block' and almost as good to 'real' randomness.
  (Compare it to a hash function: you don't feed a 1 MB doc to a card,
   instead you hash it in SW give the hash to the card.)

Just my idea, but don't let it stop you: I'm not that paranoid and don't
need 10000 random bytes:-)

Cheers,
Stef

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

Re: opensc pkcs11 and random numbers [u]

Nils Larsch
Stef Hoeben wrote:
...

>> the current code uses the card generated random data to seed a software
>> prng and it does not directly return the card random data to the user.
>> As I already said: pkcs11 should supply an api to access a crypto
>> token, if a specific service (e.g. random number generation) is
>> terrible slow it's not the job of the pkcs11 lib to supply a workaround
>> (if the application wants faster random data it should do the prng stuff
>> itself).
>>
>> Attached is a patch to correct this. If there a no objections I will
>> commit it.
>
>
> On the one hand, we're now rid of scrandom and the openssl dependency,
> so that's nice.
>
> On the other hand,
> - you now neglect the randomness supplied by the app (less secure)

there's no standardize way to supply additional random data to the
card. I don't even think it's less secure (with normal id cards) as
a good card rng shouldn't depend on external input to produce good
random data.

> - using a SW algo to derive randomness from a good seed (called a PRNG
>   or pseudo random number generator) is nothing dirty or insecure. It's
> a basic
>   crypto 'building block' and almost as good to 'real' randomness.

agree, but that's not the point here. The point is that a pkcs11 library
should act as an interface to the crypto token, so it should return
whatever the card returns. Whether there are more effective ways to do
something (equally secure) is not something the pkcs11 library should
care about, that's the job of whoever write an application using pkcs11.

>  (Compare it to a hash function: you don't feed a 1 MB doc to a card,
>   instead you hash it in SW give the hash to the card.)
>
> Just my idea, but don't let it stop you: I'm not that paranoid and don't
> need 10000 random bytes:-)

sorry for being paranoid/pedantic :-)

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

Re: opensc pkcs11 and random numbers [u]

Andreas Jellinghaus-2
In reply to this post by Stef Hoeben
On Monday 18 July 2005 10:15, Stef Hoeben wrote:
> On the one hand, we're now rid of scrandom and the openssl dependency,
> so that's nice.

opensc as whole still needs openssl in many places.

> On the other hand,
> - you now neglect the randomness supplied by the app (less secure)
> - using a SW algo to derive randomness from a good seed (called a PRNG
>    or pseudo random number generator) is nothing dirty or insecure.
>    It's a basic crypto 'building block' and almost as good to 'real'
>    randomness. (Compare it to a hash function: you don't feed a 1 MB
>    doc to a card, instead you hash it in SW give the hash to the card.)

I agree with you that it is ok to do that, but I also agree with nils:
our API should not. that functionality should be in the user space api.
people expect pkcs#11 api to interact with the smart card. lets do what
people expect, no more, no less.

I like nils patch.

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