Menu
▾
▴
Re: [Opensc-devel] Implementing C_WrapKey and C_UnwrapKey to OpenSC
|
From: Aventra D. <dev...@av...> - 2017-09-14 15:44:59
|
Thank you for your comments! I have got quite far in implementing the first case of C_UnwrapKey that we need, which is unwrapping a secret key using an RSA key. During coding I have also realized that at least the part that creates the PKCS#15 object for the unwrapped key, adds it to SKDF and updates it to the card belongs naturally to pkcs15init. However, the part that performs the crypto operation to unwrap the key is very similar to decrypt and derive operations, so I ended up adding sc_pkcs15_unwrap() to pkcs15-sec.c. So in my current implementation what happens is: 1. The call to C_UnwrapKey is first handled in pkcs#11 level (pkcs11-object.c and mechanism.c) 2. Via sc_pkcs11_object_ops we get into framework_pkcs15, I have added a function named pkcs15_prkey_unwrap() 3. I use sc_pkcs15init_bind like in some other framework_pkcs15 functions, and call pkcs15init. I have added a new function sc_pkcs15init_unwrap_key() 4. sc_pkcs15init_unwrap_key() creates the new key object (key EF) into card, updates SKDF, and calls sc_pkcs15_unwrap() in pkcs15-sec.c to perform the actual crypto operation on card. 5. The card performs a decrypt operation and places the result into the key EF created by pkcs15init. (we don’t have this feature on card yet). In driver level I initially added wrap and unwrap operations to sc_card_operations. I don’t have a strong opinion on which is better, this way or using sc_card_ctl. Still I think they fit quite well on the same level with decipher and compute_signature operations. But in the whole job this is actually a minor detail and can still be changed easily. I am still not sure, can we do this in a way that is card independent enough in pkcs15-sec, or would it be better to implement a new pkcs15init operation (a new function pointer to sc_pkcs15init_operations) which each card vendor could implement in their own way. We’ll see how it looks as I progress. When I get my code in buildable and more solid state, I’ll commit it into my fork and you could take a look. Got to keep the minidriver spec in mind. I am not very familiar on how the OpenSC minidriver interacts with rest of OpenSC, and I hope this doesn’t add too much complexity into my implementation. Probably the important thing is to make the low level implementation on card driver level usable with both minidriver and PKCS#11 way, because in higher level a parallel implementation could be added for the minidriver. - Hannu Lähettäjä: Frank Morgner [mailto:fra...@gm...] Lähetetty: torstai 14. syyskuuta 2017 11.16 Vastaanottaja: Aventra Development <dev...@av...> Kopio: ope...@li... Aihe: Re: [Opensc-devel] Implementing C_WrapKey and C_UnwrapKey to OpenSC 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...<mailto: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...<mailto:dee...@gm...>] Lähetetty: perjantai 8. syyskuuta 2017 15.26 Vastaanottaja: ope...@li...<mailto: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...<mailto:Ope...@li...> > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- Douglas E. Engert <DEE...@gm...<mailto: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...<mailto: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...<mailto:Ope...@li...> https://lists.sourceforge.net/lists/listinfo/opensc-devel |
