Support for Secret Key Objects both session and on card

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

Support for Secret Key Objects both session and on card

Douglas E. Engert
Victor,
Martin points out that both your branch and my ecdh branch
at dengert/OpenSC define a struct sc_pkcs15_skey_info.
https://github.com/viktorTarasov/OpenSC/commit/819bd829563020c2abad7537a245d57604951aec

See my note of 8/5 "Mods to add C_DeriveKey and Session
based Secret Key Objects at GitHub"

In order to support C_DeriveKey, PKCS#11 session based secret
key objects, are needed, even if the card can not support
secret keys or even if the card is not a PKCS#15 card.
An skey_info structure is needed, and it also needs to
store the value, key-type and length.

Much of the code needed for session based objects, is provided
by the code controlled by #ifdef USE_PKCS15_INIT. (I only
needed secret key objects, so did not attempt to provide
support of other session based objects, but in the future
someone may want these too.

This code then assumes that a profile is required but a
session based object does not need a profile and the object
is never written to the card. For example in framework-pkcs15.c
pkcs15_create_objects it checks for a profile:
  rc = sc_pkcs15init_bind(p11card->card, "pkcs15", NULL, &profile);
then goes on to create the object calling one of the
pkcs15_create_* functions, assuming the object will be on
created on the card.

I have added a pkcs15_create_secret_key function, that
will create session based objects, and has the hooks to
allow one to write a sc_pkcs15init_store_secret_key.

Note that in my pkcs15_create_secret_key function, I have
initialized a skey_info structure, which in all the other
objects are initialized in the sc_pkcs15init_store_* functions.
The creation of the *_info structures for the other objects
could also be moved up a level.

This is what I found I needed in libopensc/pkcs15.h


struct sc_pkcs15_skey_info {
         struct sc_pkcs15_id id;
         unsigned int usage, access_flags;
         int native, key_reference;
         size_t value_len;
         unsigned long key_type;
         int algo_refs[SC_MAX_SUPPORTED_ALGORITHMS];
         struct sc_path path; /* if on card */
         struct sc_pkcs15_der data;
};
typedef struct sc_pkcs15_skey_info sc_pkcs15_skey_info_t;

#define sc_pkcs15_skey sc_pkcs15_data
#define sc_pkcs15_skey_t sc_pkcs15_data_t

--


  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: Support for Secret Key Objects both session and on card

Viktor Tarasov-3
Le 11/08/2011 16:49, Douglas E. Engert a écrit :
> Victor,
> Martin points out that both your branch and my ecdh branch
> at dengert/OpenSC define a struct sc_pkcs15_skey_info.
> https://github.com/viktorTarasov/OpenSC/commit/819bd829563020c2abad7537a245d57604951aec

I will look it more carefully a little bit later.


But the first impression that the intersection of our codes if quite limited.
My code mainly concerns the 'secretKey' pkcs15 object as it defined by standard and it's using as 'authenticationKey'.
Afais, you don't need it and intersection is limited by the definition of 'secret_key_info' data type.

Your definition is wider and en-globes the mine, so I propose to go ahead with your patches,
and I will later update my branch.


> See my note of 8/5 "Mods to add C_DeriveKey and Session
> based Secret Key Objects at GitHub"
>
> In order to support C_DeriveKey, PKCS#11 session based secret
> key objects, are needed, even if the card can not support
> secret keys or even if the card is not a PKCS#15 card.
> An skey_info structure is needed, and it also needs to
> store the value, key-type and length.
>
> Much of the code needed for session based objects, is provided
> by the code controlled by #ifdef USE_PKCS15_INIT. (I only
> needed secret key objects, so did not attempt to provide
> support of other session based objects, but in the future
> someone may want these too.
>
> This code then assumes that a profile is required but a
> session based object does not need a profile and the object
> is never written to the card. For example in framework-pkcs15.c
> pkcs15_create_objects it checks for a profile:
>    rc = sc_pkcs15init_bind(p11card->card, "pkcs15", NULL,&profile);
> then goes on to create the object calling one of the
> pkcs15_create_* functions, assuming the object will be on
> created on the card.
>
> I have added a pkcs15_create_secret_key function, that
> will create session based objects, and has the hooks to
> allow one to write a sc_pkcs15init_store_secret_key.
>
> Note that in my pkcs15_create_secret_key function, I have
> initialized a skey_info structure, which in all the other
> objects are initialized in the sc_pkcs15init_store_* functions.
> The creation of the *_info structures for the other objects
> could also be moved up a level.
>
> This is what I found I needed in libopensc/pkcs15.h
>
>
> struct sc_pkcs15_skey_info {
>           struct sc_pkcs15_id id;
>           unsigned int usage, access_flags;
>           int native, key_reference;
>           size_t value_len;
>           unsigned long key_type;
>           int algo_refs[SC_MAX_SUPPORTED_ALGORITHMS];
>           struct sc_path path; /* if on card */
>           struct sc_pkcs15_der data;
> };
> typedef struct sc_pkcs15_skey_info sc_pkcs15_skey_info_t;
>
> #define sc_pkcs15_skey sc_pkcs15_data
> #define sc_pkcs15_skey_t sc_pkcs15_data_t
>

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

Re: Support for Secret Key Objects both session and on card

Douglas E. Engert


On 8/11/2011 11:19 AM, Viktor Tarasov wrote:

> Le 11/08/2011 16:49, Douglas E. Engert a écrit :
>> Victor,
>> Martin points out that both your branch and my ecdh branch
>> at dengert/OpenSC define a struct sc_pkcs15_skey_info.
>> https://github.com/viktorTarasov/OpenSC/commit/819bd829563020c2abad7537a245d57604951aec
>
> I will look it more carefully a little bit later.
>
>
> But the first impression that the intersection of our codes if quite limited.
> My code mainly concerns the 'secretKey' pkcs15 object as it defined by standard and it's using as 'authenticationKey'.
> Afais, you don't need it and intersection is limited by the definition of 'secret_key_info' data type.

In my ecdh branch, there is a hook to call a sc_pkcs15init_store_secret_key
routine that should allow for storing a secret key on a card.
I did not address the generation of a secret key other then via derive.

I believe my skey_info contains all the fields that your version needs.

>
> Your definition is wider and en-globes the mine, so I propose to go ahead with your patches,
> and I will later update my branch.

Thanks. That's up to Martin.

>
>
>> See my note of 8/5 "Mods to add C_DeriveKey and Session
>> based Secret Key Objects at GitHub"
>>
>> In order to support C_DeriveKey, PKCS#11 session based secret
>> key objects, are needed, even if the card can not support
>> secret keys or even if the card is not a PKCS#15 card.
>> An skey_info structure is needed, and it also needs to
>> store the value, key-type and length.
>>
>> Much of the code needed for session based objects, is provided
>> by the code controlled by #ifdef USE_PKCS15_INIT. (I only
>> needed secret key objects, so did not attempt to provide
>> support of other session based objects, but in the future
>> someone may want these too.
>>
>> This code then assumes that a profile is required but a
>> session based object does not need a profile and the object
>> is never written to the card. For example in framework-pkcs15.c
>> pkcs15_create_objects it checks for a profile:
>> rc = sc_pkcs15init_bind(p11card->card, "pkcs15", NULL,&profile);
>> then goes on to create the object calling one of the
>> pkcs15_create_* functions, assuming the object will be on
>> created on the card.
>>
>> I have added a pkcs15_create_secret_key function, that
>> will create session based objects, and has the hooks to
>> allow one to write a sc_pkcs15init_store_secret_key.
>>
>> Note that in my pkcs15_create_secret_key function, I have
>> initialized a skey_info structure, which in all the other
>> objects are initialized in the sc_pkcs15init_store_* functions.
>> The creation of the *_info structures for the other objects
>> could also be moved up a level.
>>
>> This is what I found I needed in libopensc/pkcs15.h
>>
>>
>> struct sc_pkcs15_skey_info {
>> struct sc_pkcs15_id id;
>> unsigned int usage, access_flags;
>> int native, key_reference;
>> size_t value_len;
>> unsigned long key_type;
>> int algo_refs[SC_MAX_SUPPORTED_ALGORITHMS];
>> struct sc_path path; /* if on card */
>> struct sc_pkcs15_der data;
>> };
>> typedef struct sc_pkcs15_skey_info sc_pkcs15_skey_info_t;
>>
>> #define sc_pkcs15_skey sc_pkcs15_data
>> #define sc_pkcs15_skey_t sc_pkcs15_data_t
>>
>
>

--

  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