PKCS#11 standardisation

Hi!

PKCS#11 is an API standard for any kind of Crypto Token. (SmartCards, Crypt=
o=20
Tokens, USB Tokens, HSM=B4s, TPM=B4s, ...)

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

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

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

(RSA Security took for granted that someone else would specify that or crea=
te=20
the necessary profiles)

The result is a catastrophy for the usability of crypto hardware under Linu=
x.


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=B4t installed from your=20
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=20
hardware.
(You can also try it with one of the Software-Simulations (GPKCS11 or=20
soft-pkcs11) if you don=B4t want to buy the hardware)
Then try to use it to create a certificate on the SmartCard, and sign an Em=
ail=20
with it.



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

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

I don=B4t expect a normal user to solve such a problem. And I don=B4t=20
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=
=20
installed on his system. (I am stumbling about new drivers that I didn=B4t =
knew=20
about before from time to time)
The only way to find all the drivers on a system now would be to go through=
=20
all libraries (*.so) on the system (anywhere, not just in /lib and /usr/lib=
),=20
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 ;=20
done

I saw several distributions that came with both PKCS#11 drivers and PKCS#11=
=20
applications, but the distributors didn=B4t had the idea to correctly confi=
gure=20
the applications to be able to use the drivers.
(So the user had to do it on it=B4s own)

So I started to think about possible solutions, and started discussing it w=
ith=20
the vendors and distributors.=20
I tried to find an easy solution, that should not have any overhead, and=20
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 drive=
rs=20
should be put into: /usr/lib/pkcs11/

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

Or the software may stay with the already existing method of manually=20
specifying the location.
But even in that case, it is a huge advantage for the user/administrator,=20
because he just has to look in one directory (/usr/lib/pkcs11/) for find th=
e=20
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=20
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=20
the old location, Move it to /usr/lib/pkcs11 (that could break existing=20
configurations)

Someone told me that making a symlink in /usr/lib/pkcs11 is forbidden=20
according to LSB, if the original location is under /opt for example.
Can anyone confirm that, point me to the section in the specification, wher=
e=20
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 drive=
rs=20
for root to be able to login.
If /usr isn=B4t mounted at that point in time, root would not be able to lo=
gin.
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=
=20
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=20
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=20
in /lib, /usr/lib
<sourcerer> PKCS#11 drivers aren=B4t normal libraries, but they are drivers=
=2E=20
(they are in user-space, not in kernel space)
Perhaps you should think of them as Plugins to the applications, not as=20
libraries.
They all provide the same interface. So it doesn=B4t make much sense in my=
=20
opinion to put them into /lib or /usr/lib.

<sourcerer> Yes, the drivers are normally provided by the distribution, or=
=20
installed afterwards by the administrator.
<sourcerer> (At least they should be distributed by the distributions, that=
=B4s=20
another task to make the distributors distribute all available drivers)
<sourcerer> There are a couple of different types of applications using=20
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=
=20
SmartCards on common distributions is very necessary.
<sourcerer> PAM modules might want to specifically configure only one speci=
fic=20
kind of SmartCards that are acceptable for the system.
<sourcerer> And other applications might want to use them automatically or=
=20
not, depending on their usecases.
<sourcerer> My aim is for standard software (browsers, email clients) in=20
standard office situations. (normal PC, normal Linux distro, normal SmartCa=
rd=20
Reader and SmartCards). That should be easily possible out of the box in my=
=20
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=B4s might depend on kernel modules themself, =
but=20
that=B4s their problem.
<sourcerer> (And that=B4s not a practical problem at the moment. All necess=
ary=20
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. Bu=
t=20
there are thousands of files in /usr/lib, so it=B4s nearly impossible to fi=
nd=20
all the PKCS#11 drivers in there.
<sourcerer> Well, the big problem is that there is no registry for the=20
drivers.
<sourcerer> Theoretically it would be also possible to have a different kin=
d=20
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=
=20
upon a directory.
<sourcerer> I don=B4t see a necessity to have the drivers spread across the=
=20
whole filesystem. It doesn=B4t help anything.
<sourcerer> And having a different registry means redundancy and more=20
maintenance work.
<sourcerer> Putting a driver into a specific directory is the only thing=20
really every installation system (RPM, dpkg, ...) can do.


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

<sourcerer> Don=B4t think of it as a library.
<sourcerer> PKCS#11 drivers are very very seldomly statically linked to the=
=20
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 ju=
st=20
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=20
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=
=20
from the other system libs. I don=B4t see any good reason to mix them.
<sourcerer> And having them all in one specific directory is the easiest wa=
y=20
to "register" them.

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

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


Regards,
Philipp G=FChring