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. Note that Firefox on Windows can only use the 32-bit version of OpenSC as Firefox itself is a 32-bit application. Both OpenSC 32-bit and 64-bit can be installed without conflicting with each other.
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.
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).
[[BackLinks]]