PKCS #11: Cryptographic Token Interface Standard OpenSC implements v2.11 or v2.20 of the standard. The most visible difference between the two versions is hot-plugging capabilities of v2.20.
This standard specifies an API, called Cryptoki, to devices which hold cryptographic information and perform cryptographic functions. Cryptoki, pronounced crypto-key and short for cryptographic token interface, follows a simple object-based approach, addressing the goals of technology independence (any kind of device) and resource sharing (multiple applications accessing multiple devices), presenting to applications a common, logical view of the device called a cryptographic token.
OpenSC implements this standard in "opensc-pkcs11.so" module (on Windows: opensc-pkcs11.dll). Every Software that can use cryptographic tokens such as Mozilla, Firefox and Thunderbird can simply load this module and use all smart card supported by OpenSC for authentication, signing and decryption.
Smart cards can have several pins, and make the keys available to only some of those. PKCS#11 interface however does not know about several pins. What OpenSC does is a trick: if you have more than one pin, you will see several card / slot, each with the name of that pin holder, and with the certificates/keys that pin can access. This feature is called virtual_slots and can be configured in the config file.
Example: Take a card with 2 PINs. Each PIN protects a private key and each private key has a corresponding cert chain. And then there are 3 other roots certs that have nothing to do with the other data. Now if num_slots = 4, hide_empty_tokens = false; and if you put the card your second card reader, you'll get the following:
- token in slot 4: PIN 1, key 1, cert chain 1
- token in slot 5: PIN 2, key 2, cert chain 2
- token in slot 6: the 3 other root certs
- token in slot 7: no data
If hide_empty_tokens would have been true, slot 7 wouldn't show a token.
Note: if in the example the 2 cert chain would have common certificates, those certificates would appear in the tokens in slots 4 and 5. (Which would cause a problem if those certs were deleted, this hasn't been solved yet in OpenSC).
OpenSC starting with version 0.10.0 installs all libraries and the opensc-pkcs11.so module in /usr/lib.
OpenSC up to 0.9.6 installed the module in /usr/lib/pkcs11 on Linux, also some libraries used by that module, and this cause some problems. The easiest way to fix it is to copy or symlink all files to /usr/lib.
Visibility of private objects
The PKCS11 standard requires that you provide a PIN before you can see info about the private keys that are protected by the PIN. This isn't realy needed for the OpenSC library (not sensitive things in the private key info).
Some applications (most notably NSS/Firefox/Thunderbird) take the assumption that certificates are private objects which can not be read before providing a PIN. This results in Firefox trying to log in to all slots of the PKCS#11 module and in case of OpenSC, asking all the PINs the card has, doing a C_Login() and then reads the certificates. This behavior can only be fixed with a special flag when loading the PKCS#11 module. This flag is not exposed in the GUI. See bugzilla for more information.
There's no real solution to this; perhaps the best way is to enumerate the certs, and assume that each non-CA cert has a corresponding private key on the card (this requires to parse the certs, you can't get this info from PKCS11).
Pages linking to PKCS11: