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

Attachment: 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

Reply via email to