Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

One card driver, 2 applets, 2 slots. #1476

Closed
BakulinD opened this issue Sep 12, 2018 · 6 comments
Closed

One card driver, 2 applets, 2 slots. #1476

BakulinD opened this issue Sep 12, 2018 · 6 comments
Labels

Comments

@BakulinD
Copy link

Problem Description

I develop driver for token with 2 applets.
1st applet already work anyway and compatible with vendor driver via PKCS#15 emulation
(btw, found that any (most?) OpenSC card drivers incompatible with vendors PKCS#11 drivers because OpenSC works mainly via PKCS#15. e.g. RuToken-ECP driver).

Card respond once on ATR. So, kernel(openSC) create 1 card object.
Then called sc_pkcs15_emulator_handler function.
It creates 2 sc_pkcs15_auth_info objects and kernel create 2 slots too.
It seems strange, because if applet is one, it has 2 users: user and s/o. But anyway I need 2 slots, maybe for user only per applet.

When application call PKCS#11 function C_OpenSession with any of 2 slots it cause in further all calls come to one same card object.

Questions are how:

  1. create 2 card objects with one card_match and different functions for each applets?
  2. In card functions get any slot characteristic to recognize which applet should be used?
@frankmorgner
Copy link
Member

I don't know if I understand your question correctly, but I can say that

  1. OpenSC is not limited to PKCS#15. Look, for example, at pkcs15-piv.c or pkcs15-openpgp.c, which are mapping the internal PIV/PGP structures to something the PKCS#15 layer of OpenSC understands and exports to PKCS#11, Minidriver and Tokend.
  2. Currently, OpenSC can only handle a single internal card driver per card, see Concurrent access to multiple applications on card - Yubico, MyEID and others  #962
  3. If you want to support more than one internal card driver per card, try Experimental: PKCS#11 Support for Multiple Applications on One Card #1263
  4. You're free to implement your own internal card driver, which performs the mapping to your two applets. This will work without changes to OpenSC outside of your card driver.
  5. slot handling in PKCS#11 is different from the card driver level. For example, if you have multiple PINs on your card, you will see them as multiple slots in PKCS#11.

@dengert
Copy link
Member

dengert commented Sep 12, 2018

In addition to looking at pkcs15-piv.c and pkcs15-openpgp.c look at pkcs15-cac.c and card-pkcs15.c the CAC driver switches AIDs, in effect switching applets. Look for AID, applet and SC_PATH_TYPE_DF_NAME.

If your driver can support two applets it will have to keep track of which applet is active and will have to select the AID of the applet it wants to use. Depending on the applets on the card, switching applets can lose a login state, or other temporary information in the deselected applet. This is a big problem with independent applets.

To make the two applets visible to PKCS]#11 can be done by PKCS#11 slots. To force OpenSC to create multiple slots for the same device the driver can list two (or more) PINs, one for each applet and create objects for each slot. Your own pkcs15-card.c will then create objects and assigned to a PIN. Each slot would have its own PKCS#11 objects. Your driver will have to look at an object to figure out slot/applet is being used. You may be seeing that OpenSC may not provide your driver with enough information to keep them seperate.

As Frank said: "If you want to support more than one internal card driver per card, try #1263."
This is experimental code so each applet can be handled by a different driver when used with PKCS#11. There is one reader/PCSC connection shared between the drivers, and each driver creates its own session to its own applet.

Depending on what you want to do with the two applets, for example one applications only want to use applet 1 and another applet only want to use applet2, you can provide each with a different opensc.conf`` and add a card_atr block for your card to each and specify atype = card-type` to distinguish what your driver should do.

@BakulinD
Copy link
Author

Thank you for detailed explanation!

Depending on the applets on the card, switching applets can lose a login state, or other temporary information in the deselected applet. This is a big problem with independent applets.

It will be single-thread EFI-application. Only selected applet of card will used. I already ported OpenSC to EFI. Stripped (under define) reading of configuration files (inserted default values), added <reader-efi.c>.
Now adding drivers. Unfortunately, I cannot contribute code to OpenSC project, because work for employer's comercial project. And with NDA information. But can report any bugs.

To make the two applets visible to PKCS]#11 can be done by PKCS#11 slots. To force OpenSC to create multiple slots for the same device the driver can list two (or more) PINs, one for each applet and create objects for each slot. Your own pkcs15-card.c will then create objects and assigned to a PIN. Each slot would have its own PKCS#11 objects. Your driver will have to look at an object to figure out slot/applet is being used. You may be seeing that OpenSC may not provide your driver with enough information to keep them seperate.

I already used this way (pkcs15 emulator and init functions in other card driver). So, seems I will to implement 2-nd applet card driver and try link to 2-nd slot.
Thanks!

@dengert
Copy link
Member

dengert commented Sep 12, 2018

OK.
Rather than 2 opensc.conf see in opensc.conf.example the card_drivers = and add just your 2 drivers.
Then use env OPENSC_DRIVER=driver before your pkcs11 application to select the one you want.

@frankmorgner
Copy link
Member

@BakulinD Please have the license restrictions of OpenSC in mind.

@BakulinD
Copy link
Author

OK. I will keep it in mind.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants