NSS PKCS#11 implementation
Alon Bar-Lev
I am using Mozilla applications for a long time I enjoy it,
but the PKCS#11 implementation always worried me.
1. It prompts for PIN every time the token is accessed (Does
not use the public objects if exists).
2. It does not prompt for token insert if the token is
unavailable. For example, you started SSL session using a
certificate on a token, then remove it, at next negotiation
you should be prompted to insert your token.
3. Every key negotiation there is a PIN prompt without reuse
of last credentials.
4. Every key negotiation all objects are re-read from token.
Lately, I spent time in introducing PKCS#11 to open source
projects, started with OpenVPN (merged), then OpenSSH (not
yet), lately I've finished integrating PKCS#11 into QCA (Qt
Cryptographic Architecture, merged) so that KDE 4 will be
able to use smartcards.
Now I think I am ready to help you.
If you like, I am willing to help you make the PKCS#11
implementation better. I guess this cannot be done without
making some changes in the NSS interface.
I've implemented a pkcs11-helper module that abstracts the
use of PKCS#11. It handles multiple providers, works on
Linux and Windows, supports session caching, object
serialization, PIN prompt, token prompt, PIN cache period,
protected authentication and more.
Attached is my header file so you might get an idea of what
can be done.
Best Regards,
Alon Bar-Lev.
Alon Bar-Lev
Thank you for your reply.
Bob Relyea wrote:
> Alon Bar-Lev wrote:
>> Hello,
>>
>> I am using Mozilla applications for a long time I enjoy it, but the
>> PKCS#11 implementation always worried me.
>>
>> 1. It prompts for PIN every time the token is accessed (Does not use
>> the public objects if exists).
> This is probably because the token does not keep it's login state. NSS
> does not try to remember if a particular token has been logged in or
> logged out, it will always ask to token to see if it needs to be logged
> in or not. If the token does not update and maintain it's internal login
> state, NSS will end up logging into the token every time it queries.
> Login state is returned through the C_GetSessionInfo() call. This
> allows vendors to control the login state of their tokens independent of
> NSS. NOTE: one common error in tokens is the failure to update the
> session state of *ALL* sessions on login or logout.
Well... I've found that it is better to cache session and
perform the private key operation and if fails try to
login... This works with all tokens. I deal with that in my
helper code.
>> 2. It does not prompt for token insert if the token is unavailable.
>> For example, you started SSL session using a certificate on a token,
>> then remove it, at next negotiation you should be prompted to insert
>> your token.
> Unfortunately there is no way for NSS to know that it needs your
> particular token. We are currently working on dealing with this from the
> UI level (several error messages now,
I don't think so... NSS can cache the token provider, model
and serial number for each session, then if private key
operation is done to a cached session which cannot find the
correct token it can prompt. I also deal with that in my
helper code and it works fine, without any change in UI or
application levels.
>> 3. Every key negotiation there is a PIN prompt without reuse of last
>> credentials.
> This is a bug in your pkcs #11 module (see 1 above).
No... I think this is a bug in NSS... (see 1 above). You are
relaying on too much functionality of the PKCS#11 provider.
I don't think that your interpretation of the standard is
the only one that is correct.
>> 4. Every key negotiation all objects are re-read from token.
> This looks like you are not keeping a consistent session state. NSS
> detects card insertion and removal by verifying that the global session
> it opens when it first initializes the card is still valid. If that
> session is not maintained (the token looses that session or returns an
> error on C_GetSessionInfo()), NSS can only assume that the token in the
> reader is different from the last token it was talking to, so it rereads
> all the objects off the token. This particular error will cause the pin
> prompt problems above (NSS sees that same session as logged out). You
> should examine what is happenning in your C_GetSessionInfo() call.
Again... You can say that there is a bug in every
provider... And you can make things works... From my
experience there is no reason why we cannot have a working
PKCS#11 interface which uses lest functionality model...
I've done this, and offer my help.
You can look at the code at:
http://websvn.kde.org/trunk/kdesupport/qca/plugins/qca-pkcs11/pkcs11-helper.c?rev=527220&view=auto
Best Regards,
Alon Bar-Lev.