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

Status: RESOLVED FIXED

(NSS :: Libraries, defect)

Description

[Ionut Marasescu]

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
3.

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.

Comment 1

[Frank Wein [:mcsmurf]]

->NSS i think...

Comment 2

[Wan-Teh Chang]

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
C_GenerateKeyPair.

Comment 3

[Wan-Teh Chang]

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.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 5

[Wan-Teh Chang]

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.