Anders Rundgren wrote, On 2008-08-25 03:01: > Thank you very much Nelson! > > Yes, it seems that P11's C_InitPIN only talks about tokens > which apparently is not the same thing as a key.
Right. A token is analogous to a "smart card" or "HSM". It may have storage for multiple keys and certificates, but all of its contents are protected by a single PIN. Actually two PINS are defined, a user PIN and an SO PIN, but either PIN protects the entire token. When a user authenticates to the token through C_Login, the token enters a logged in state (called a read/write state in the spec). It typically stays in that state until the user logs out with C_Logout, or the token is physically removed from the slot, or some time elapses. That time may be very short (a single use). Because of the desire, in some countries, for private keys associated with "non repudiation" certs to require authentication with every use, and because a token may contain both NR and non-NR keys, PKCS#11 v2.20 defines a settable private key attribute that forces the user to login again each time he wishes to use that private key. (See pages 83-84.) The CKA_ALWAYS_AUTHENTICATE attribute, when set to true, causes operations (function calls) that would use that key to return CKR_USER_NOT_LOGGED_IN unless a successful C_Login with userType set to CKU_CONTEXT_SPECIFIC was performed after the operation was initialized and before it was finished. The sequence of operations is typically something like: C_SignInit, C_Login, C_Sign. The context specific login does not affect the token's overall state of being logged in. Attempting to use a private key with the CKA_ALWAYS_AUTHENTICATE attribute set to true does not log the user out of the token, but merely requires an additional login to use that key. This feature MIGHT be used to implement separate PINS for each key that has this attribute set to true, however, the PKCS#11 API defines no method by which to set the PIN on individual key objects. In PKCS#11 v2.20, key objects have no password attribute, and there is no C_SetKeyPin function. There may have been some additions to PKCS#11 since v2.20 was published, and it is possible that there is already a proposed and accepted way to setting PINS on keys, of which I am simply unaware. But if not, then it would be necessary to use some method outside of PKCS#11 (or a "vendor extension" of PKCS#11) to accomplish the key PIN management. The PKCS#11 working group has historically been very open to proposed additions, so if there is not already one, you might write up a proposed addition to PKCS#11 to provide for key PINs. Finally, I would add that, presently, NSS does not support CKU_CONTEXT_SPECIFIC logins, either inside NSS's PKCS#11 module or in the "PK11wrap" code that calls the PKCS#11 modules. So, if a PKCS#11 module that supported that feature was loaded by the browser, and it had a key with that attribute, NSS would not be able to use that key, presently. > Although a bit on the slimy side, do you think that an extension > to the softtoken implementation would be rejected by the > owner(s) of the code? Contributions are accepted. There is precedent for NSS accepting a contribution that added mechanisms to NSS's PKCS#11 module, and code that uses them to pk11wrap and even to libSSL. The Japanese group that defined the Camellia cipher did that, going so far as to write an RFC, define the PKCS#11 mechanism, and do the entire implementation in NSS and PSM. I would add, however, that a contribution to add features to the softoken, but that did not also add the code necessary to make use of it in higher layers, probably would not be accepted, at least not until the higher layer work was also done. That was the fate of the SRP contribution. The work to add it to softoken was done, but there was no browser support for it, and so the softoken contribution languishes to this day. > But of course such an idea goes nowhere unless there is a > way to store PINs as well. True. I think it would not be difficult to add them to the new sqlite- based cert9.db supported in NSS 3.12. Support for that new DB format is present in FF3 but is not enabled by default. > I would be interested in upgrading the soft token but I can't fund > such a development and it would also be of little interest unless > there are some other features added to the Mozilla core such > as XML security. Others have expressed a desire for per-key PINs in the past, and I don't think their requirements included XMLSEC support. > Another possibility would be to create a > new P11 provider that through JNI wraps to Java which > has excellent support for just about anything you want. Yes, I think one could do that, but first the API must be extended to facilitate per-key PINs. > I guess that FireFox uses very few P11 functions for TLS > client-auth which is really the only existing mechanism > associated with client keys, right? libSSL does client authentication by calling PK11_Sign, (see <http://mxr.mozilla.org/security/source/security/nss/lib/pk11wrap/pk11obj.c#742> That is the PK11wrap function that would need to be enhanced to handle the CKU_CONTEXT_SPECIFIC logins, I think. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
