Hi Alon,First, I appreciate your enthusiasm for extending the reach of the PKCS #11 standard. I think there may be some areas that you may be able to contribute to make NSS a better platform in the respect of PKCS #11. If that is to happen, however, you will need to understand about PKCS #11.
Let me preface this discussion with an important point:All the behaviors you describe will only happen with a poorly designed PKCS #11 module. NSS has been supporting PKCS #11 for over 10 years. There are literally hundreds of tokens out there that function correctly in NSS, (not just smart cards, but hardware accelerators, high security tokens which implement full FIPS semantics, etc.). These tokens do not display the problems you describe. In fact, for many vendors, proper functionality in NSS has been the benchmark for how well your PKCS #11 module implements the spec (though there are some features NSS does not exercise and often tokens which have depended on NSS as an acceptance test have suffered when used in other libraries like Peter Gutman's toolkit). Furthermore, there are other applications out there that use PKCS #11. Those that are more than just trivial "open the token, get a random key, sign with it" will require these semantics as well.
Alon Bar-Lev wrote:
This will break if you pull a token out and replace it with a different token which happens to use the same handles (which is quite likely in simple tokens). In your case we would end up silently signing with the wrong key. More importantly your view of what certs are available will be wrong. Proper session usage is a fundamental requirement for any PKCS #11 token in anything as complicated as a Firefox or Thunderbird. Proper session management is ESSENTIAL in the PKCS #11 spec. Just about everything hangs off of it. Yes I can build a PKCS #11 application that doesn't need it, but such a PKCS #11 application would be severely limited in the functionality it provides. That is why there is a PKCS #11 spec, and a large portion of the text of that spec is devoted to proper session management.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.1. It prompts for PIN every time the token is accessed (Does not use the public objects if exists).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.
Again, this may work in a very simple application. This becomes much more questionable in an SSL Session. In that case you don't know the key you want to use. You need to separate it out from a bunch. I'm not saying it's not doable, and I would certainly entertain more discussion on this (taking into account it's affect on more complicated applications like Firefox and Thunderbird). Caching the key information, for instance, probably not the best as in most PKI systems, you don't identify the key, but the certificate associated with it. It may be interesting to start caching that a particular certificate lives on a particular token. There is a lot of up front design work with this, however, to make sure it does not break existing usages. What needs to be handled first is what the UI should look like to the user, then we can figure out where best to put the knowledge that implements that UI look at http://wiki.mozilla.org/PSM:CertPrompt to see my first cut at thinking about this.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.
No, this is not a bug in EVERY provider. This does not happen in *ANY* of the PKCS #11 modules I have from vendors which support tokens.... Unless I am unclear about what you are saying is happening here. NSS will not re-read the objects from the token on every operation.... only if the token has been removed and reinserted. In this case it's necessary. Tokens can change (even a token with the same issuer serial number... even a 'read only' token). There is nothing worse than building a enrollment system, getting your PKCS #11 module correct, your token correct, etc. only to have the application or toolkit blindy ignore your token's changes because it has cached them somewhere without the ability to determine that the token has changed.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.4. Every key negotiation all objects are re-read from token.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.
As you can imagine, it is very unlikely that NSS will pick up wholesale yet another PKCS #11 toolkit. The toolkit NSS provides have been tuned over the years to handle a number non-intuitive cases which would cause headaches to existing and deployed PKCS #11 modules. NSS does such things as automatic key management (moving keys between tokens when necessary to complete a crypto operation), using the token's internal key unwrap and PBE processing when available, and doing it's own key unwrap when it's not, doing keygen for the token when the token can't do keygen. Since PKCS #11 is the core engine of NSS crypto, you really can't just "swap out another toolkit". What would be interesting is taking some of your ideas (properly vetted) and put them into NSS.You can look at the code at:http://websvn.kde.org/trunk/kdesupport/qca/plugins/qca-pkcs11/pkcs11-helper.c?rev=527220&view=auto
Go ahead an ping me offline if you are interested on working on this. bob
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
