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

[Frank M. <fra...@gm...>]

I think I now understand your choice of adding this functionality to
framework-pkcs15.c instead of framework-pkcs15init.c. I think it's OK to do
so, though in general, the design decision to draw such a sharp line
between both frameworks is not very desirable.

I'm not convinced that adding new boilerplate is a good idea, if it's
unused. In case of SC_CARD_CAP_ONCARD_SESSION_OBJECTS we could simply say
that only one way is implemented and the other yields an error.

What I'm a bit puzzled about, is that the current version (and the old one)
of `sc_pkcs15_unwrap ` is functionally almost equivalent to
`sc_pkcs15_derive`. The only difference is that sc_pkcs15_derive directly
calls sc_decipher (via use_key), whereas sc_pkcs15_unwrap calls the driver
specific method unwrap, which then calls myeid_decipher. I don't understand
why you're adding the extra boiler plate on the card driver level and not
just go with use_key and an adjusted security environment. Maybe I don't
fully understand the use of C_Unwrap... do you have an example use case for
that?

ISO 7816-8 (2004) Annex C gives a small example on how to use a combination
of PUT DATA and MSE to import a key. Maybe that would also be possible for
unwrapping a key.

Regards,
Frank.

2017-10-04 14:08 GMT+02:00 Aventra Development <dev...@av...>:

> On 22. September 17, Douglas E Engert wrote:
> >I assume the above is just for testing. In either case if you can support
> both token and session objects that would be good. Also keep in mind some
> card drivers emulate some of the PKCS#15 operations, which usually means
> they can support session objects but not token objects.
> >(The may support token objects but not via PKCS#11 or PKCS#15 but some
> other means.
> >The OpenSC C_DeriveKey was written for such a card to support ECDH.)
>
> Back to wrapping after doing some other work for a while. Yes, at this
> point this is just to demonstrate the logic I have planned.
>
> Regarding session objects, we want to support both software and hardware
> session objects. By PKCS#11 spec, they can be either implemented completely
> in software or stored in the token for the lifetime of the session. So we
> need to distinguish between software and on-card session objects. I added
> SC_CARD_CAP_ONCARD_SESSION_OBJECTS flag to let drivers tell if they can
> handle session objects on card.
> For a hardware session object, we need to create the key object on card,
> but it is not needed to update the P15 directory file. With MyEID we are
> going to implement session objects so that the card will clean them out in
> the next reset. For us it is important to be able to create a temporary key
> object on card as a result of C_UnwrapKey, and be able to use that key
> using PKCS#11.
>
> I think the new features shouldn't affect cards that emulate PKCS#15
> operations. The code could be used to enable accessing these operations
> using PKCS#11 in future. Well, one thing to consider is that should we
> allow the unwrap function in the card driver to return the unwrapped key as
> a memory buffer, if the card cannot unwrap in hardware? For now I didn't
> add a return buffer, because I think the whole point of unwrapping is to do
> it in hardware to keep the key safe, and if someone wants to unwrap keys to
> PC memory, it can be done using decrypt.
>
> >> We haven’t yet decided how to tell driver and card, which key file
> >> should receive the unwrapped key. We have thought of using manage
> security environment, but haven’t yet find a card independent way to set it
> in pkcs15-sec.c.
> >You could use the CKA_LABEL, or even a vendor supplied attribute for
> OpenSC, that could be used to pass info to pkcs15init when creating a key
> on the card.
> >Side issue:OpenSC needs to fix how it assigns CKA_VENDOR_DEFINED
> attributes. see:
> >https://github.com/OpenSC/OpenSC/pull/1131#issuecomment-323335738
> >For session keys, the handle to the key is good enough since the handle
> is unique for the session.
>
> The empty target key is created in beginning of the operation (like in
> derive) and we get the object handle, containing file path if it's a token
> object, to the pkcs11-object.c level. I don't see problems here. Then we
> call sc_pkcs11_unwrap and go thru many function calls. Another thing is to
> transmit a reference in form of a file path or ID to the card driver for
> the actual crypto operation. For signing and decrypt operations the file
> ref to the key that performs the operation is transmitted to the driver in
> sc_security_env.file_ref. With many cards the driver transmits it to the
> card in an MSE:SET command APDU. We'd like to use the same logic for
> setting the target key for unwrapping. I added target_file_ref to
> sc_security_env struct to hold this file reference. ISO7816-4 or 8 don't
> clearly define how to use MSE:SET to prepare wrapping and unwrapping, but
> with this method drivers and cards could implement it in their own way.
>
> Just pushed a new version to https://github.com/hhonkanen/
> OpenSC/tree/wrapping
> You can see there how I'm doing it.  This version can create a permanent
> target key object on card for a secret key using pkcs15init, in case
> CKA_TOKEN=TRUE.
>
> If you would like to run the code, I added a little test program to GitHub.
> https://github.com/hhonkanen/WrapTest
> You can run it with a normal MyEID card and it can do all other parts of
> the wrapping operation with these parameters, except actually decrypting
> the key to the target file. You have to generate or import an RSA key pair
> to the card first and encrypt some data with the public key, then put the
> encrypted data to CK_BYTE wrappedKey[] before calling C_UnwrapKey.
>
> I think we have to concentrate on the card implementation next to get
> further, but I am open to discussion and ideas about the OpenSC
> implementation. Especially I would like to hear what you like about passing
> the target file ref in sc_security_env_t and would there be some
> alternative ways.
>
> - Hannu
>
> -----Alkuperäinen viesti-----
> Lähettäjä: Douglas E Engert [mailto:dee...@gm...]
> Lähetetty: perjantai 22. syyskuuta 2017 21.30
> Vastaanottaja: ope...@li...
> Aihe: Re: [Opensc-devel] Implementing C_WrapKey and C_UnwrapKey to OpenSC
>
> On 9/22/2017 8:32 AM, Aventra Development wrote:
> > Hi,
> >
> > I have committed the first version of C_UnwrapKey implementation to my
> > branch at https://github.com/hhonkanen/OpenSC/tree/wrapping
> >
> > I hope you would have time to take a look.
> >
> > As we don’t yet even have a card that could perform the actual
> > unwrapping operation, this code is not yet complete and it currently
> > emulates unwrapping by doing a normal decrypt operation. It can be run
> and it goes all the way to the card driver when target object template has
> CKA_TOKEN=FALSE, but the code to store the pkcs#15 object is not yet
> complete. Anyway, from this commit you can see the logic I am planning to
> use.
>
> I assume the above is just for testing. In either case if you can support
> both token and session objects that would be good. Also keep in mind some
> card drivers emulate some of the PKCS#15 operations, which usually means
> they can support session objects but not token objects.
> (The may support token objects but not via PKCS#11 or PKCS#15 but some
> other means.
> The OpenSC C_DeriveKey was written for such a card to support ECDH.)
>
>
> CKA_TOKEN=FALSE says the object is a session object which does not require
> any code to store the pkcs#15 object.
> CKA_TOKEN=TRUE says the object is a token object, so you would need to
> tell the token what to do with it.
>
>
> >
> > This implementation follows the same pattern as C_DeriveKey. The call
> goes for PKCS#11 to the driver like this:
> >
> >  1. C_UnwrapKey --> sc_create_object->pkcs15_create_object, to create
> the target PKCS#15 object to receive the key.
> >
> >                               pkcs15_create_secret_key calls pkcs15init
> to create the PKCS#15 structure and key EF on card.
> >
> >  2. We have a handle to the target object. From now on the calls go in
> very similar way like a decrypt or key derivation operation:
> >
> > C_UnwrapKey --> sc_pkcs11_unwrap->sc_pkcs11_unwrap_operation->pkcs15_
> prkey_unwrap->sc_pkcs15_unwrap.
> >
> > Here we format and set security environment and call card:
> >
> > use_key->sc_set_security_env
> >
> > use_key->sc_unwrap->myeid_unwrap_key.
> >
> > Before I started coding, I thought of two alternative ways:
> >
> >  1. Implement most of the stuff in pkcs15init as you suggested and
> > create new pkcs15init operations  2. Go C_DeriveKey style.
> >
> > It was not an easy decision, but the main motives to go C_DeriveKey way
> were:
>
> Good choice I like the C_DeriveKey choice especially for cards that are
> not true PKCS#15 cards.
> >
> >   * I noticed that after we have a target key object, the rest of the
> operation is actually similar to decrypt. The unwrapping operation is
> performed with a PKCS#11 key object, which supports specific
> >     mechanisms. This initial version supports only RSA, but in future we
> could have several mechanism for each supported key type, for example
> CKM_AES_ECB, CKM_AES_CBC, CKM_RSA_PKCS, CKM_RSA_X_509
> >     etc. The logic to handle a crypto operations with a specific object
> and a mechanism was already there.
> >   * there already was unwrap_key method defined in sc_pkcs11_object_ops.
> >   * there already was the working C_DeriveKey code. I thought it would
> be good to be consistent with it, because it does nearly the same thing.
> >   * I think this model fits for C_WrapKey as well. As a crypto operation
> it has the same characteristics, the data just goes into other direction.
> >
> > We haven’t yet decided how to tell driver and card, which key file
> > should receive the unwrapped key. We have thought of using manage
> security environment, but haven’t yet find a card independent way to set it
> in pkcs15-sec.c.
> >
>
> You could use the CKA_LABEL, or even a vendor supplied attribute for
> OpenSC, that could be used to pass info to pkcs15init when creating a key
> on the card.
>
> Side issue:OpenSC needs to fix how it assigns CKA_VENDOR_DEFINED
> attributes. see:
> https://github.com/OpenSC/OpenSC/pull/1131#issuecomment-323335738
>
> For session keys, the handle to the key is good enough since the handle is
> unique for the session.
>
>
> > Another thing we have to think about is do we need to implement a new
> > function in pkcs15init/pkcs15-lib.c to create an empty secret key file
> to receive the unwrapped key. There is a function to store a secret key:
> sc_pkcs15init_store_secret_key, but it doesn’t currently work without key
> data.
> >
> > I am really looking forward to find such architecture that the
> > community can accept and to have the code merged into master when it’s
> functional. Hoping to hear opinions on is this as good way to go or should
> we take a different approach.
> >
> > - Hannu
> >
> > *Lähettäjä:*Frank Morgner [mailto:fra...@gm...]
> > *Lähetetty:* maanantai 18. syyskuuta 2017 0.27
> > *Vastaanottaja:* Aventra Development <dev...@av...>
> > *Kopio:* ope...@li...
> > *Aihe:* Re: [Opensc-devel] Implementing C_WrapKey and C_UnwrapKey to
> > OpenSC
> >
> > 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...
> <mailto: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... <mailto:
> fra...@gm...>]
> >     *Lähetetty:* torstai 14. syyskuuta 2017 11.16
> >     *Vastaanottaja:* Aventra Development <dev...@av...
> <mailto:dev...@av...>>
> >     *Kopio:* ope...@li...
> > <mailto: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:Opensc-devel@lists.
> sourceforge.net>
> >         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:Opensc-devel@lists.
> sourceforge.net>
> >         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:Opensc-devel@lists.
> sourceforge.net>
> >     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
> >
>
> --
>
>   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
>