[lsb-discuss] PKCS#11 standardisation

[Philipp Gühring]

Hi!

PKCS#11 is an API standard for any kind of Crypto Token. (SmartCards, Crypto 
Tokens, USB Tokens, HSM´s, TPM´s, ...)

PKCS#11 defines the API (for the C language), where any application (or crypto 
framework) can use any crypto hardware for encryption, signature, key 
management.
PKCS#11 aware applications are Mozilla Firefox, Thunderbird, KMail, 
OpenSSL, ...
There are PKCS#11 drivers for specific SmartCards, USB Tokens, a general one 
for TPM´s, ...

The problem of the PKCS#11 standard is that it just defines the C language 
based API, but it does not define, where the drivers (shared libraries) are 
stored, or registered, and how you could find them

The problem that came out of this is that everyone has put his drivers 
somewhere else, and that users have to guess/know/... where the drivers are 
on the system, and specify their location for every application.
Some drivers are in /usr/lib, some are in /usr/lib/pkcs11, some are 
in /opt/VENDOR/... they are spread across the whole filesystem.

(RSA Security took for granted that someone else would specify that or create 
the necessary profiles)

The result is a catastrophy for the usability of crypto hardware under Linux.


This is the usecase:
Setup a fresh computer with a normal Linux distribution.
Have Firefox installed on it.
Now take any SmartCard+Reader, attach it to the computer.
Install the necessary PKCS#11 driver (if it isn´t installed from your 
distribution).
Now start Firefox, go to the Settings.
Go to the Crypto Modules.
Now configure Firefox to use the PKCS#11 driver that matches your 
hardware.
(You can also try it with one of the Software-Simulations (GPKCS11 or 
soft-pkcs11) if you don´t want to buy the hardware)
Then try to use it to create a certificate on the SmartCard, and sign an Email 
with it.



Most applications need the user to specify the exact path of all the PKCS#11 
drivers that he wants to use. (Sometimes in plain textboxes, sometimes in 
configuration files, sometimes in nice file-open dialogs)
I have seen driver installation programs, that automatically detected specific 
versions of standard software, and have rewritten the 
configuration of that software, to "know" the location of the driver.
(It worked for just that single version of that single software (Netscape 
4.7), the risk that something breaks is given)

I even found step-by-step HowTo´s on the Internet with nice screenshots that 
showed clearly how to do it. Unfortunately the driver is in a different 
directory on my machine, so the HowTo doesn´t work.

I don´t expect a normal user to solve such a problem. And I don´t 
see a need for a user to care about the path of the driver anyway.

The user currently has no easy way to find all the drivers that are already 
installed on his system. (I am stumbling about new drivers that I didn´t knew 
about before from time to time)
The only way to find all the drivers on a system now would be to go through 
all libraries (*.so) on the system (anywhere, not just in /lib and /usr/lib), 
and test for the existance of the defined API:

for a in `locate .so`
do
  (objdump -t $a 2>/dev/null | grep C_GetInfo) && echo $a ; 
done

I saw several distributions that came with both PKCS#11 drivers and PKCS#11 
applications, but the distributors didn´t had the idea to correctly configure 
the applications to be able to use the drivers.
(So the user had to do it on it´s own)

So I started to think about possible solutions, and started discussing it with 
the vendors and distributors. 
I tried to find an easy solution, that should not have any overhead, and 
should be easy to migrate, and worked out a proposal.

http://wiki.cacert.org/wiki/Pkcs11TaskForce

My idea is to just define a specific directory, where all the PKCS#11 drivers 
should be put into: /usr/lib/pkcs11/

Then the applications can list all the files there 
grep("/usr/lib/pkcs11/*.so") and display them to the user, the user only has 
to choose the right one, instead of writing a complete path.

Or the software may stay with the already existing method of manually 
specifying the location.
But even in that case, it is a huge advantage for the user/administrator, 
because he just has to look in one directory (/usr/lib/pkcs11/) for find the 
drivers.




Now there are three things that I would like to discuss with LSB:


* Regarding the migration to the new system: When a vendor already has a 
defined places for his driver somewhere else, I see three possibilities:
Make a copy in /usr/lib/pkcs11, Make a symlink in /usr/lib/pkcs11 pointing to 
the old location, Move it to /usr/lib/pkcs11 (that could break existing 
configurations)

Someone told me that making a symlink in /usr/lib/pkcs11 is forbidden 
according to LSB, if the original location is under /opt for example.
Can anyone confirm that, point me to the section in the specification, where 
that is defined, and perhaps tell me what the preferred alternative is?


* Next question: /lib/pkcs11 vs. /usr/lib/pkcs11
Someone pointed out that there are PAM modules that depend on PKCS#11 drivers 
for root to be able to login.
If /usr isn´t mounted at that point in time, root would not be able to login.
So his suggestion was to move the standard directory to /lib/pkcs11
The problem he also found out, is that many PKCS#11 drivers depend on other 
libraries from /usr/lib, so they would also have to be moved to /lib

* The third question I have is whether it is possible to add this 
specification to FHS and/or LSB, to have that standardized here.





Now a copy of the discussion on #lsb (modified for readability):

<stew> if the libraries are provide by the distribution, they should be 
in /lib, /usr/lib
<sourcerer> PKCS#11 drivers aren´t normal libraries, but they are drivers. 
(they are in user-space, not in kernel space)
Perhaps you should think of them as Plugins to the applications, not as 
libraries.
They all provide the same interface. So it doesn´t make much sense in my 
opinion to put them into /lib or /usr/lib.

<sourcerer> Yes, the drivers are normally provided by the distribution, or 
installed afterwards by the administrator.
<sourcerer> (At least they should be distributed by the distributions, that´s 
another task to make the distributors distribute all available drivers)
<sourcerer> There are a couple of different types of applications using 
PKCS#11:
<sourcerer> Browser, Email clients. (most important one, I would say)
<sourcerer> Any other application using crypto
<sourcerer> PAM modules for login
<sourcerer> For Browsers and Email clients a Plug&Play usability for common 
SmartCards on common distributions is very necessary.
<sourcerer> PAM modules might want to specifically configure only one specific 
kind of SmartCards that are acceptable for the system.
<sourcerer> And other applications might want to use them automatically or 
not, depending on their usecases.
<sourcerer> My aim is for standard software (browsers, email clients) in 
standard office situations. (normal PC, normal Linux distro, normal SmartCard 
Reader and SmartCards). That should be easily possible out of the box in my 
opinion.

<stew> so these "drivers", you say .so and .dll on the wiki
<sourcerer> Yes.

<stew> they aren't kernel modules to access the hardware?
<sourcerer> No.
<sourcerer> Those .so or .dll´s might depend on kernel modules themself, but 
that´s their problem.
<sourcerer> (And that´s not a practical problem at the moment. All necessary 
kernel modules are available and normally installed quite well)
<stew> so it's the user-space interface to the functionality
<sourcerer> Yes.


<stew> I don't see that as much different than many other libraries
<sourcerer> Some of the drivers are installed in /usr/lib at the moment. But 
there are thousands of files in /usr/lib, so it´s nearly impossible to find 
all the PKCS#11 drivers in there.
<sourcerer> Well, the big problem is that there is no registry for the 
drivers.
<sourcerer> Theoretically it would be also possible to have a different kind 
of registry.
<sourcerer> Perhaps a textfile with all the drivers-pathes on each line
<sourcerer> Someone proposed a XML file to do the same.
<sourcerer> Or perhaps some database.
<sourcerer> But all those other methods are more complex than just deciding 
upon a directory.
<sourcerer> I don´t see a necessity to have the drivers spread across the 
whole filesystem. It doesn´t help anything.
<sourcerer> And having a different registry means redundancy and more 
maintenance work.
<sourcerer> Putting a driver into a specific directory is the only thing 
really every installation system (RPM, dpkg, ...) can do.


<stew> I guess I don't really understand the problem. Usually an app linked to 
a library knows where to find it's files

<sourcerer> Don´t think of it as a library.
<sourcerer> PKCS#11 drivers are very very seldomly statically linked to the 
application. PKCS#11 drivers are normally loaded dynamically with dlopen().
<sourcerer> Think of it as a Plugin.
<sourcerer> The problem ist that PKCS#11 is a standard, but the standard just 
defines the interface (which C functions the driver has to export).


<stew> ok, so the point is to isolate these drivers/libs/plugins from the 
other system libs, I didn't understand what your issue was
<sourcerer> Yes, I think it is the best way to isolate the PKCS#11 drivers 
from the other system libs. I don´t see any good reason to mix them.
<sourcerer> And having them all in one specific directory is the easiest way 
to "register" them.

<mats> So the request is for a directory that would contain plugins of a 
particlar type?
<sourcerer> Yes.

<stew> I don't read in FHS anything that says you can't 
use /lib/pkcs11, /usr/lib/pkcs11
<sourcerer> Yes, that´s the problem, that FHS does not say, where exactly it 
should go, and PKCS#11 does not say either.


Regards,
Philipp Gühring