Closed Bug 298340 Opened 15 years ago Closed 15 years ago

When using a secure smartcard device the key verification after generation requires annoying multiple PIN entries


(NSS :: Libraries, defect)

Windows 2000
Not set


(Not tracked)



(Reporter: im, Assigned: wtc)



User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 2.0.40607; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511

We have a secure smartcard device that needs the PIN entry for every 
cryptographic operation. When the user requests a certificate and a new key is 
generated Mozilla wants to validate the key by asking us to decrypt and sign 
something. This is very disturbing since the user has to enter the PIN 3 times 
(once for test decrypt, once for test sign, and once for the actual sign 
certificate request). Can Mozilla avoid this key verification, maybe by 
checking the CKM_RSA_PKCS_KEY_PAIR_GEN mechanism with a C_GetMechanismInfo 
function and test the mechanism flags? We set the flags to 
CKF_GENERATE_KEY_PAIR | CKF_HW, so Mozilla can be able to see from the flags 
that the key is hardware generated, anyway I don’t see a reason to verify it 
(we can always return an error in C_GenerateKeyPair, if something goes wrong 
with the key generation).

Reproducible: Always

Steps to Reproduce:
1. Use a secure smartcard device that doesn’t memorize the PIN, but ask the PIN 
for every crypto-operation 
2. Request a certificate

Actual Results:  
Because Mozilla verifies the keys asking to decrypt (“Known Crypto Message”) 
and to sign (“Mozilla Rules World!”), the user has to enter the PIN two 
additional times.

Expected Results:  
Don't verify a hardware key after generation, or any key at all. If an error 
occurs the PKCS11 module can return an error from C_GenerateKeyPair.
->NSS i think...
Assignee: dveditz → wtchang
Component: Security → Libraries
Product: Mozilla Application Suite → NSS
QA Contact: seamonkey → jason.m.reid
Ever confirmed: true
The key verification is done by the pk11_PairwiseConsistencyCheck
function.  This pairwise consistency test is necessary for the NSS
software crypto module to conform to the FIPS 140-2 standard.

Strictly speaking, we only need to perform the pairwise consistency
test on our own crypto module.  So we are considering moving the
pairwise consistency test into our software crypto module (bug 298513
and bug 298514).  Once we have done that, this bug will be fixed as
a byproduct.

I urge you to perform this pairwise consistency test in your
Depends on: 298513, 298514
Fellow NSS developers: how do you suggest we fix this bug?

One idea I have is to not perform the pairwise consistency
check if the private key object's CKA_ALWAYS_AUTHENTICATE
attribute is CK_TRUE.
I think we need to establish what requirement(s) exist to do pairwise 
consistency checks, if any, other than the FIPS 140-2 requirements for 
our own self softoken.  If none, then this bug will be fixed as a side
effect of the fixes for the bugs that "blocK" this one.
At this NSS meeting yesterday, we decided that we don't
need to perform the FIPS 140-2 pairwise consistency tests
on other vendors' tokens.  So we're not going to add
pk11_PairwiseConsistencyCheck back.

This bug has been fixed as a side effect of fixing
bug 298514.

The Mozilla clients will get this bug fix when they
upgrade to the upcoming NSS 3.11 release.  I estimate
the upgrade will happen in September or October.
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → 3.11
You need to log in before you can comment on or make changes to this bug.