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

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

I think the current layout looks OK and you can proceed. The structure
should also be usable in the minidriver.

There is "connect_exclusive" in the pcsc section. There is also
"lock_login" from the pkcs11 section to achieve something similar. Locking
the token has the disadvantage that concurrent access is very limited.

We also recently introduced the pkcs11 option "atomic", which tracks the
login state and restores this on each transaction. This has the
disadvantage that much more operations with the card are carried out, but
it assures that the card is only locked for a short period of time while
the login state is safe from misuse This option could be extended to
tracking session objects...

The topic of secure    concurrent access in PKCS#11 is a big mess... On
Windows, for example, the OS handles concurrent access for the Minidriver
so that the middleware doesn't need this complexity.

To round this up, we also have a long term project of handling card resets
(from concurrent processes) correctly...
https://github.com/OpenSC/OpenSC/projects

Regards, Frank.

2017-10-06 9:42 GMT+02:00 Aventra Development <dev...@av...>:

> Thank you for your comments, good point about multiple applications. I
> think that while in a HSM it is normal functionality, on a smart card it
> would be quite difficult to track session objects of different sessions,
> because of limited resources. For our use case, it would be sufficient to
> restrict usage of these objects to one application at a time by
> documentation, and live with the fact that they are lost if another
> application resets the card. Is it possible to run OpenSC with PS/SC flag
> SCARD_SHARE_EXCLUSIVE using some setting in opensc.conf? That would ensure
> that sessions objects stay stable.
>
> However, it would be preferable that in OpenSC we could handle such
> situations cleanly, if another application resets the card. I think it
> would be ok that the driver returns an error if trying to access a sessions
> object which was lost in a reset, and we should be careful that such object
> don't leak in memory or cause other confusion. We should also make it
> possible to handle multiple sessions, if there is a card that supports it.
> Got to look into this.
>
> There definitely is work to be done in checking attributes of the target
> key, checking if the driver supports session keys and other attributes as
> well. As a side effect of this project, we may get more functionality to
> the secret key support in general into framework-pkcs15. I think that as
> there is now support to load secret keys in pkcs15init and the PKCS#15
> structures are defined, it would be relatively easy to implement C_Encrypt
> and C_Decrypt for secret keys.
>
> If we agree on the basic structure of the unwrap implementation, the next
> steps are to implement it on MyEID card and on driver level, add lots of
> checking to handle different key lengths, types and attributes, and
> implement key wrapping with a similar pattern.
>
> - Hannu
>
>
> -----Alkuperäinen viesti-----
> Lähettäjä: Douglas E Engert [mailto:dee...@gm...]
> Lähetetty: keskiviikko 4. lokakuuta 2017 17.22
> Vastaanottaja: ope...@li...
> Aihe: Re: [Opensc-devel] Implementing C_WrapKey and C_UnwrapKey to OpenSC
>
>
>
> On 10/4/2017 7:08 AM, Aventra Development wrote:
> > 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.
>
> OpenSC can be called by multiple applications. This could cause problems
> if multiple applications need a hardware session object and especially if
> one application does a reset. depending in the timing and how the hardware
> and software keep track of these session hardware objects, the hardware ans
> software could get confused.  This is similar to losing the login state to
> a card, which is a much easier problem, solved mostly by pin caching.
>
>
>
> >
> > 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?
>
> That is more a function of what attributes are requested in the session
> key template and what the card can or can not do.
> I have not looked to see if PKCS#11 provides and help here.
> I think the code should be designed to handle either case, and if the card
> can not do it return unsupported or whatever CKR_* the specs say.
>
> > 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.
>
> As a last resort, we could always add a vendor provided attribute.
>
> Sounds like you have most of the issues in hand, other then the multiple
> application problem of doing a reset in which case the login state, and the
> hardware session key are lost. The PKCS#11 code needs to handle what
> happens to the session objects if some other application resets the card.
> If its in memory it can still be used. If in hardware, it is most likely
> lost.
>
>
>
> >
> > 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
>