Menu
▾
▴
Re: [Opensc-devel] Implementing C_WrapKey and C_UnwrapKey to OpenSC
|
From: Frank M. <fra...@gm...> - 2017-09-17 21:27:15
|
OK, we'll see when you're fine with some working code. One more pointer I'd like to give is ISO 7816-8, which gives some example on how to import a private key using PUT DATA with DO 7F48 (card holder private key template). As far as I know, OpenSC used to implement the ISO style of card interactions first, which then got mapped to other type of cards as well. So using the existing get_data and put_data hooks of the card driver would also be usable for key import. That being said, I know that the concept has been softened. There is the read_public_key callback, which following the ISO style should have been implemented with get_data... 2017-09-14 14:10 GMT+02:00 Aventra Development <dev...@av...>: > 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...>: > > 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 > > > > ------------------------------------------------------------ > ------------------ > 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 > > |
