Re: 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 <[email protected]>:

> 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:[email protected]]
> Lähetetty: perjantai 8. syyskuuta 2017 15.26
> Vastaanottaja: [email protected]
> 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
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/opensc-devel
> >
>
> --
>
>   Douglas E. Engert  <[email protected]>
>
>
> ------------------------------------------------------------
> ------------------
> 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
> [email protected]
> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensc-devel