Two weeks ago, I asked some questions about NSS and ECDSA in a thread "OpenSC PKCS#11 and Session Objects" Both Andre Zepezauer and Robert Relyea responded with comments and questions.
Since then I have built NSS-3.12.7 (which is used by Thunderbird 3.1.4) on Solaris 10 and have been testing using Thunderbird and a modified OpenSC. NSS 3.12 has some ECC support, controlled by two defines: NSS_ENABLE_ECC (On in production Thunderbird 3.1.4) and NSS_ECC_MORE_THAN_SUIT_B (off in the production Thunderbird.) In the "Basic ECC" only 3 named curves are usable. In "MORE_THAN_SUIT_B" it looks like a lot more of ECC is supported. But the code is not complete, so the NSS "soft token" is not registering its mechanisms for ECC, and some tests to see if EC keys can be used was required NSS_ECC_MORE_THAN_SUIT_B=1 when NSS_ENABLE_ECC=1 would have been good enough. These bugs caused NSS to try and use the OpenSC for all EC operations, and the OpenSC code and the PIV card are not (and should not be) setup to handle it. With some modifications to NSS, I can now use Thunderbird with OpenSC to sign E-mail using OpenSC with a PIV card. The Card is an Oberthur ID-ONE V7 with the PIV applet. The certificate was generated with OpenSSL and the CA is using RSA. I intend to send these modifications to Mozilla, but there are still issues: o The PIV NIST 800-73-3 standards say the PIN must be presented immediately before any crypto for the 9C and 9D keys used for signing and key exchange, and the newer ID-ONE V7 card enforce this. But NSS does not check CKA_ALWAYS_AUTHENTICATE attribute, and so the crypto may fail. (PIN caching by OpenSC is not an acceptable solution and I have not tried it!) o NSS does a C_FindObjects for CKA_VALUE where the value is a certificate it has found earlier. It does not add the CKA_TYPE=CKO_CERTIFICATE to the template, so OpenSC ends up searching every object on the card. This can trigger the situation above if an object has to be read. I have a mod to NSS to add the CKA_TYPE to the search, and thus avoid this. This is also a performance improvement. (Reading all the objects before the C_Login is also not an option, as some objects require the pin to have be presented.) o Without NSS processing the CKA_ALWAYS_AUTHENTICATE, the card has to be removed and reinserted before another signing operation can be done. o I have only looked at ECDSA, ECDH is still needed. Even with these limitations, I can sign and verify E-Mail, and even Entrust clients, and Outlook 2007 appear to accept the signature. So I am getting close to committing EC changes for OpenSC. On 11/10/2010 11:37 AM, Andre Zepezauer wrote:
Hello Douglas, you should check if NSS does support ECDSA. If it does, then it should verify the users certificate on its own. Calling a PKCS#11 provider for doing it, is some kind of abuse. (See quotation below) But if NSS tries to offload the verification to OpenSC, because it doesn't has support for ECDSA, then you are in trouble. This is because the recipient of your signed e-mail also would need OpenSC for verification. Not practical I think. PKCS#11 Section "6.2 Design goals": "Cryptoki was intended from the beginning to be an interface between applications and all kinds of portable cryptographic devices [...] It is not the goal of Cryptoki to be a generic interface to cryptographic operations or security services [...]" Regards Andre On Wed, 2010-11-10 at 10:56 -0600, Douglas E. Engert wrote:Does OpenSC PKCS#11 support the creation of session objects? Has anyone looked at doing this? I bring this up as I am testing EC mods to OpenSC using Thunderbird to sign e-mail as a test. In my case, the user certificate is using ECDSA with a named curve, and the test CA is also using ECDSA to sign the user's certificate. Thunderbird 3.1.4 with NSS-3.12.x (x is at least 3) on Solaris 10 tries to create a session public key, where the key is the public key of the CA. I think NSS is going to use this public key to verify the signature of the user's certificate asking the OpenSC PKCS#11 ECDSA to do the verify. Depending on the card, this may have to be done in software. See the attached edited PKCS11-SPY output, showing mechanisms, open session, session info, and failed create object. Not shown are pin/login, and retrieval of the user certificate. PKCS#11 2.20 says : Table 4 "R/O Public Session" "The application has opened a read-only session. The application has read-only access to public token objects and read/write access to public session objects." I don't think NSS does this if the CA is using RSA to sign the certificates, and I will try that next. (But eventually some CA will start using ECDSA to sign certificates.) Even if the ECDSA verify was to be added to OpenSC PKCS11, to be done in software, I would expect it might have to use OpenSSL to do the verification. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
-- Douglas E. Engert <deeng...@anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
