298488 - Unable to request a certificate on signature key (no decryption physically available).

Status: RESOLVED INACTIVE

(NSS :: Libraries, defect, P5)

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 smartcard with keys that only allow signature (for security reasons 
they are restricted to signature only, the decrypt cannot be performed). 
Because Mozilla (NSS) verifies the keys after generation by asking to decrypt 
something and then sign something, we are unable to request the certificate 
(the key verification fails).
We’ve set CKA_DECRYPT to false for the generated key, so Mozilla knows that the 
key is not meant for decryptions. Mozilla only ask a signature for verification 
but the key is not considered valid (the signature is ok). This must be a bug 
in NSS (the decryption is always necessary for key validation?).
We’ve conducted some tests by setting CKA_decrypt to true and then directly 
return “Known Crypto Message” (this is always the decrypted message) from 
C_Decrypt when the decrypt test is required, and then after the signature 
verification is made, the key is verified and everything works fine (we make 
another signature for actual certificate request and then the certificate is 
loaded). This seems to confirm that there is a bug in NSS and a decrypt 
operation is always required for key verification.


Reproducible: Always

Steps to Reproduce:
1. Smartcard with signature only keys. (Decryption is not physically possible)
2. Request a certificate ->
3. Generate keys step.

Actual Results:  
The key verification fails (Mozilla wants a decrypt as the first step of 
verification!).
Even if we tell Mozilla the key is not meant for decryption (CKA_Decrypt 
attribute) the key is not verified (only signature as verification, but key NOT 
validated).


Expected Results:  
Don’t verify the key after generation. (the fact that the key is bad can be 
shown in other ways)
Or
Verify a key that is not meant for decryption with a signature (actually this 
validation fails, it seems that a decryption is also needed, even if not 
required by Mozilla).

Comment 1

[Wan-Teh Chang]

Could you do a debug build of Mozilla and
find out why pk11_PairwiseConsistencyCheck
fails?

In Mozilla 1.7.8, pk11_PairwiseConsistencyCheck
is defined as follows:
http://lxr.mozilla.org/mozilla1.7/source/security/nss/lib/pk11wrap/pk11skey.c#1590

Comment 2

[Wan-Teh Chang]

Another thing to look at, which does not require a debug
Mozilla build, is whether NSS passes a CKA_DECRYPT of true
or false to C_GenerateKeyPair for your smartcard.  See
http://lxr.mozilla.org/mozilla1.7/source/security/nss/lib/pk11wrap/pk11skey.c#2281
http://lxr.mozilla.org/mozilla1.7/source/security/nss/lib/pk11wrap/pk11skey.c#2296

Comment 3

[Wan-Teh Chang]

Looking at the NSS code, I found that NSS calls
C_GetMechanismInfo on the mechanism CKM_RSA_PKCS.

See
http://lxr.mozilla.org/mozilla1.7/source/security/nss/lib/pk11wrap/pk11skey.c#2173
http://lxr.mozilla.org/mozilla1.7/source/security/nss/lib/pk11wrap/pk11skey.c#2225

What flags do you return?

Comment 4

[Ionut Marasescu]

Mozilla Passes a CKA_DECRYPT false in C_GenerateKeyPair. Here is our trace:
C_GenerateKeyPair(hSession=2)
mech(0000(CKM_RSA_PKCS_KEY_PAIR_GEN), len=0, ptr=00000000) 
PublicKey count=8
type=00000121(CKA_MODULUS_BITS) len=4 {[ 00 04 00 00]}
type=00000122(CKA_PUBLIC_EXPONENT) len=3 {[ 01 00 01]}
type=00000001(CKA_TOKEN) len=1 {[ 01]}
type=0000010C(CKA_DERIVE) len=1 {[ 00]}
type=00000106(CKA_WRAP) len=1 {[ 00]}
type=0000010A(CKA_VERIFY) len=1 {[ 00]}
type=0000010B(CKA_VERIFY_RECOVER) {[ 00]}
type=00000104(CKA_ENCRYPT) len=1 {[00]}
PrivateKey count=7
type=00000103(CKA_SENSITIVE) len=1 {[01]}
type=00000001(CKA_TOKEN) len=1 {[ 01]}
type=00000002(CKA_PRIVATE) len=1 {[ 01]}
type=0000010C(CKA_DERIVE) len=1 {[ 00]}
type=00000107(CKA_UNWRAP) len=1 {[ 00]}
type=00000108(CKA_SIGN) len=1 {[ 01]}
type=00000105(CKA_DECRYPT) len=1 {[ 00]}

Comment 5

[Ionut Marasescu]

In C_GetMechanismInfo we pass the following flags for CKM_RSA_PKCS mechanism: 
CKF_SIGN | CKF_HW.
We have tried other variants (CKF_SIGN , CKF_HW , CKF_DECRYPT, CKF_ CKF_UNWRAP 
in various combinations) with the same result (key not validated without 
succesful decrypt).
Shouldn't NSS also call C_GetMechanismInfo for the CKM_RSA_PKCS_KEY_PAIR_GEN 
since this is the mechanism for C_GenerateKeyPair?. We observed that 
C_GetMechanismInfo is not called for this one.

Comment 6

[Ionut Marasescu]

This bug is related to bug 298340 "When using a secure smartcard device the key 
verification after generation requires annoying multiple PIN entries". 
If the verification of the signature key after generation is eliminated, the 
decrypt will be no more necessary, and it will also solve the current bug.
See "https://bugzilla.mozilla.org/show_bug.cgi?id=298340"

Comment 7

[Ionut Marasescu]

- Analyzing a bit the Mozilla code indicated I’ve found out were the bug is. 
The problem is that NSS does not check CKA_VERIFY attribute before calling 
C_VerifyInit (from NSS PK11_Verify function). We have this attribute set to 
false (the key cannot do the verification) and are returning 
CKR_FUNCTION_NOT_SUPPORTED from both C_VerifyInit and C_Verify functions. 
- I don’t know why everything works fine with the signature verification 
(C_VerifyInit is not called) when NSS also verifies the decrypt (we set 
CKA_DECRYPT to true and return “Known Crypto Message” in C_Decrypt to do this 
test): I’ve presumed that NSS takes CKA_VERIFY attribute into account, and 
internally performs the verification if the attribute is false. Why it works 
different when the decrypt verification is also performed?
- Anyway we have a workaround for the moment: to implement C_VerifyInit and 
CVerify. It would have been easier if NSS checked CKA_VERIFY or working exactly 
the same as when the decrypt verification is also involved. 

Comment 8

[Wan-Teh Chang]

Thank you very much for tracking down this bug and I agree
with your findings.  I can also answer your question why
everything works fine with the signature verification
(C_VerifyInit is not called) when NSS also verifies the decrypt.

The reason is that when NSS verifies the decrypt, it moves
the public key from your smartcard to a token that is the "best"
for RSA.  Usually this token is NSS's softoken.  See lines
1626-1637 in pk11skey.c:
http://lxr.mozilla.org/mozilla1.7/source/security/nss/lib/pk11wrap/pk11skey.c#1626

If this is done, when NSS does the signature verification, the
public key is already in that "best" token for RSA, so NSS will
call C_VerifyInit on the "best" token rather than your smartcard.

On the other hand, if NSS doesn't verify the decrypt, the
public key is still in your smartcard, so when NSS does the
signature verification, it will call C_VerifyInit on your
smartcard.

A possible fix is to add the following code to the beginning
of the "if (canSignVerify)" block:

        /* Find a module to verify against */
        slot = PK11_GetBestSlot(pk11_mapSignKeyType(privKey->keyType),wincx);
        if (slot == NULL) {
            PORT_SetError( SEC_ERROR_NO_MODULE );
            return SECFailure;
        }

        id = PK11_ImportPublicKey(slot,pubKey,PR_FALSE);
        PK11_FreeSlot(slot);
        if (id == CK_INVALID_HANDLE) {
            return SECFailure;
        }

Do you have the setup to build Mozilla with this change?

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months and this bug has severity 'major'.
:beurdouche, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:beurdouche, could you have a look please?

For more information, please visit BugBot documentation.