Menu
▾
▴
Re: [Opensc-devel] Implementing C_WrapKey and C_UnwrapKey to OpenSC
|
From: Frank M. <fra...@gm...> - 2017-09-14 08:16:13
|
In general your approach sounds good! But I have objections regarding the software architecture. Historically, key generation and key import has been done in pkcs15init. There are some other cards besides sc-hsm that are calling some control command in the card driver from pkcs15init. Basically, what you're asking for is to use pkcs15init functionality in PKCS#11. Instead of implementing everything in PKCS#11, it would be better to make pkcs15init available as DLL/LIB that can be loaded into OpenSC's PKCS#11 library. With this approach you would implement key wrapping in your card's operations in pkcs15init (possibly redirecting it to the driver in libopensc with a control command). One more thing I'd like to throw in is that Microsoft also has its view of key wrapping. Have a look at Smart Card Minidriver Specification, v7.07 Figure B1. Process for key generation and insertion ( https://msdn.microsoft.com/en-us/library/windows/hardware/dn631754(v=vs.85).aspx). Please make sure that your implementation has this spec in mind so that key wrapping can also be added to the minidriver. Regards, Frank. 2017-09-11 10:11 GMT+02:00 Aventra Development <dev...@av...>: > Thanks for the tip. Yes, the ECDH code looks like it can be used with > slight modifications and expanded to perform unwrap. Some more work is > needed in the card/driver level to set up properties of the new key in the > key EF on card according to the PKCS#11 attributes in the template. > > What do you think about adding wrap and unwrap into sc_card_operations in > opensc.h? Is there a risk of causing some trouble or should all go fine as > long they're just set to NULL on cards that don't support them? If more > cards would support these operations in future, this way each card wouldn't > need to add new card specific SC_CARDCTL_xxx values. > > - Hannu > > -----Alkuperäinen viesti----- > Lähettäjä: Douglas E Engert [mailto:dee...@gm...] > Lähetetty: perjantai 8. syyskuuta 2017 15.26 > Vastaanottaja: ope...@li... > Aihe: Re: [Opensc-devel] Implementing C_WrapKey and C_UnwrapKey to OpenSC > > 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...> > > > ------------------------------------------------------------ > ------------------ > 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 > ------------------------------------------------------------ > ------------------ > 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 > |
