344179 - ECC Keygen on ncipher HSM sets CKA_SIGN to false

Status: RESOLVED INACTIVE

(NSS :: Libraries, defect, P5)

Description

[Chandrasekar Kannan]

I'm using an nCipher HSM that supports ECC. I was attempting to generate
a self-signed CA certificate using certutil. 

I'm using NSS version:
./libnss3.so:
     $Header: NSS 3.11.1 ECC Beta  Apr  5 2006 15:06:19 $

Here's my certutil command:

certutil -S -d . -n cacert-ecc- -h ncipher  -s CN=cacert-ecc
 -x  -t CTu,CTu,CTu  -g 1024  -m   -v 48  -z ./noise  -k ec
 -q secp256r1  -2  -1  -5

certutil fails with the following messages:

Generating key.  This may take a few moments...
certutil: signing of data failed: An I/O error occurred during security authorization.

It looks like the private key template is setting CKA_SIGN to false:

Here's the nCipher log file snippet:

2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >>   C_GenerateKeyPair
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >    hSession 0x000008D3
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >    pMechanism->mechanism 0x00001040 (CKM_EC_KEY_PAIR_GEN)
2006-07-10 10:56:58 p8515: pkcs11: 00000000 D    NFC__hash_session 0x000008D3
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 D    hashmap lookup hash 46969AEA188 probe 8 step 67
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 D    lookup try hashmap[8] hash 46969AEA188 value 0x599290
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 D    found hashmap[8] value 0x599290
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 D    find_existing_key
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 D    NFC__create_common_attrs
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 D    NFC__create_common_attrs module 1
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 D    NFC__create_common_attrs
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 D    NFC__create_common_attrs private in template 1
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 D    NFC__create_common_attrs module 1
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 D    EC
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >    pPublicKeyTemplate[7]
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 D    NFC__check_attributes class 0x00000002 (CKO_PUBLIC_KEY) type 0x00000003 ulCount 7
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >    CKA_EC_PARAMS
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >      pAtt->pValue 10
  pAtt->pValue= 10 bytes
                                                      06082a86 48ce3d03 0107

2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >    CKA_TOKEN
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >     true
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >    CKA_DERIVE
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >     true
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >    CKA_WRAP
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >     false
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >    CKA_VERIFY
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >     false
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >    CKA_VERIFY_RECOVER
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >     false
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >    CKA_ENCRYPT
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >     false
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >    pPrivateKeyTemplate[7]
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 D    NFC__check_attributes class 0x00000003 (CKO_PRIVATE_KEY) type 0x00000003 ulCount 7
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >    CKA_TOKEN
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >     true
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >    CKA_PRIVATE
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >     true
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >    CKA_SENSITIVE
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >     true
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >    CKA_DERIVE
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >     true
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >    CKA_UNWRAP
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >     false
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >    CKA_SIGN
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >     false
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >    CKA_DECRYPT
2006-07-10 10:56:58 p8515: pkcs11: 000008D3 >     false

Comment 1

[armb]

http://lxr.mozilla.org/seamonkey/source/security/nss/lib/pk11wrap/pk11akey.c#897
sets the test mechanism for ECC keys to CKM_ECDH1_DERIVE.
http://lxr.mozilla.org/seamonkey/source/security/nss/lib/pk11wrap/pk11akey.c#927
will then set CKF_DERIVE and not set CKA_SIGN.

The underlying nCipher keys support either ECDH1 or ECDSA, but not both, and use CKF_DERIVE and CKA_SIGN to decide which underlying key type to generate.

Comment 2

[Robert Relyea]

Hmm, we don't always know what the purpose for the ECC key is. There are cases where we generate dual use keys.

The code at 927 is ran when the token does not return the flags for the ECC keys. I'm surprised the nCipher doesn't set the Capability flags, which forces NSS to guess what the flags are.

NSS should be setting both flags... so we have 2 issues:

1) NSS needs to set both flags when the capability are not presented.
2) We need a version of nCipher that can support dual use keys.

bob

Comment 3

[armb]

Actually we do set the mechanism info flags and I should have pointed at line 911 not 927. The effect is the same at the moment, but it does mean setting both flags in the "not presented case" won't help.
And at the moment if you did set both sign and derive flags, we'd return CKR_TEMPLATE_INCONSISTENT.
Even if we did support dual use keys, then the flags for the two different mechanisms would be different (hence the comment at http://lxr.mozilla.org/seamonkey/source/security/nss/lib/pk11wrap/pk11akey.c#897).

Comment 4

[Chandrasekar Kannan]

So, whats the solution to this bug ?. 

Comment 5

[David Stutzman]

After speaking with nCipher support, it seems this is actually an issue with nCipher's PKCS#11 library.  I was told there is a known bug involving SHA-2 hashes and CKM_ECDSA.  The fix should be available in v11.10 of the support software/firmware (current is v11.00).

Comment 6

[armb]

This has nothing to do with SHA-2 hashes, and V11.10 won't change the fact that nCipher nCore keys are either ECDSA or ECDH but not both. I'll have a word with support.

Comment 7

[armb]

Incidentally, the SECKEYPrivateKey code does seem to have changed to test both mechanisms, but I haven't checked to see if certutil will now use the "/* We've explicitly turned on both flags, use both mechanism */" case.
But if it has, we'll now return CKR_TEMPLATE_INCONSISTENT because, while we do support both mechanisms so the C_GetMechanismInfo tests will show both flags working, we don't support them on the same key.
I'm afraid I can't say when that might change.