Re: [Opensc-devel] Implementing C_WrapKey and C_UnwrapKey to OpenSC

[Douglas E E. <dee...@gm...>]

The ECDH can derive a key, which may be returned by the card or kept on the card.
A Session object is created for the derived key. The code was written for a card that would
return a secret key so the session object has CKA_TOKEN=FALSE.

So the derive code is very similar to the unwrap. You might want to start looking it.


On 9/8/2017 6:32 AM, Aventra Development wrote:
> Hi fellow OpenSC developers,
> 
> Some of you may already know me from my contributions to mostly MyEID driver. We are now starting a larger development project so I thought a brief introduction would be appropriate. I am a developer 
> at Aventra, Finland. Our target in this project is to implement C_WrapKey and C_UnwrapKey PKCS#11 functions into OpenSC and initially to the MyEID driver. At the same time we are going to implement 
> this functionality into MyEID card.
> 
> I have created a branch named "wrapping" in my OpenSC fork at https://github.com/hhonkanen/OpenSC
> 
> Before starting coding I have done some planning and split the work into sub tasks. Here are the tasks I have found:
> 
> - implement wrapping and unwarpping in pkcs#15 level (framework-pkcs15.c)
> 
>                             * sc_pkcs11_object_ops already contains unwrap_key operation. wrap_key operation must be added.
> 
>                             * implement pkcs15_skey_wrap_key, pkcs15_skey_unwrap_key etc...in framework_pkcs15.c and map the functions to                        sc_pkcs11_object_ops.
> 
>                             * changes to register_mechamisms and functions called from there (for example sc_pkcs11_new_fw_mechanism).
> 
>                               set CKF_WRAP and CKF_UNWRAP when appropriate.
> 
>                             * parse the CKA_xxxx attributes and create the needed PKCS#15 structures for the keys that will be created on card during                            unwrapping operations
> 
> - implement wrapping and unwrapping in pkcs15-sec and card driver level:
> 
>                             * add wrap/unwrap functions to sc_card_driver. In SC-HSM driver these are implemented as driver specific card_ctl commands.
> 
>                               I am not sure if we should go this way or add the new operations directly to sc_card_operations.
> 
>                             * implement them in card-myeid.c
> 
> * seems like I have to create functions like sc_pkcs15_wrap_key and sc_pkcs15_unwrap_key to do the work between pkcs15 and card layers.
> 
> - implement the functions in PKCS#11 level:
> 
>                            * implement C_WrapKey and C_UnwrapKey in pkcs11-object.c. Check mechanism and attributes and call framework_pkcs15
> 
>                             * return the handle of wrapped key (in memory) or unwrapped key (on card) to the pkcs#11 level and to the caller.
> 
> Some issues we have to think about:
> 
> - It is still not totally clear to me how to begin implementing the operations from PKCS#11 side (C_WrapKey and C_UnwrapKey in pkcs11-object.c). I think I am going to follow a similar pattern as in 
> C_SignInit and C_DecryptInit. This will probably become clearer when I get started, but any tips are more than welcome.
> 
> - Handling of secret key objects when CKA_TOKEN=FALSE. PKCS#11 doesn't define where such session objects should be stored, but leaves it up to implementation. We must have possibililty to have session 
> objects on card. With this I mean key objects that are cleaned from the card in the next reset and the key material never leaves the card. We need this kind of objects in chained key wrapping 
> operation. I am planning to implement it so that drivers could tell whether they can handle in card session objects. If a driver doesn't support them, they would be handled as in memory objects.
> 
> - in addition to RSA and AES keys, we must be able to handle CKK_GENERIC_SECRET objects which might be somewhat different to implement,  because lots of the key handling code is related to the key 
> algorithm.
> 
> Any feedback, tips and contributions in testing/code review will be greatly appreciated.
> 
> Best regards,
> 
> Hannu Honkanen
> 
> Aventra
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
> 

-- 

  Douglas E. Engert  <DEE...@gm...>