465926 - During import of PKCS #12 files, key usage attributes are not set correctly

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P2)

Description

[Helge Bragstad]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; MS-RTC LM 8)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3

During PKCS #12 import, NSS first creates a (typically) 3DES-key session object. On this key, it sets CKA_WRAP to TRUE, but fails to set CKA_UNRWAP. Should probably be other way around. When the default values of key usage attributes are FALSE for this token, it means that this key can not be used for the subsequent C_UnwrapKey to unwrap the private key, it fails with CKR_KEY_FUNCTION_NOT_PERMITTED.

At this point, NSS decrypts the private key itself and stores the key using C_CreateObject. Now however, unlike when it did C_UnwrapKey, it doesn't set any of the key usage attributes on the private key. Again, if the default values are FALSE, the private key has no key usages and all subsequent usage fails.

Default values of key usages are not defined in PKCS #11 spec, so they should each be set explicitly to reflect the desired usage. The most reasonable default value from a security standpoint is FALSE.

Reproducible: Always

Steps to Reproduce:
1. Assign a PKCS #11 module where key usage default values are always FALSE
2. Import a PKCS #12 file.
3. Use the private key, for instance for SSL authentication.
Actual Results:  
Signature, authentication or decryption operation fails.

Expected Results:  
The operation should succeed.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Helge, Thanks for the bug report.  
Please tell us the name of at least one product or vendor with a PKCS#11 
module that defaults all attributes to FALSE.

I suspect that PKCS#12 doesn't store any clues about what usages are 
intended or desired.  I'm concerned that a fix for this bug might create
a situation where in the act of exporting a signing-only private key and 
re-importing it would turn it into a key for signing and encryption.
Perhaps we could and should attempt to infer the key usage from the 
cert'(s) KU and EKU extensions (if any) corresponding to the key?

Bob, I'm giving this to you, because I think you'll know what code needs
to be changed off the top of your head, where I would have to trace through
to find the code paths that have these issues.  But I'm willing to take this
bug if you can't.  Even some tips on where to start would be helpful.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

OK, I figured a lot of this out.  
When pk12util gets to the point that it's actually trying to unwrap the 
private key, it calls PK11_UnwrapPrivKey.  There can be several reasons
why the slot into which we want the private key to go cannot be used to 
unwrap the key directly.  Perhaps it does not support unwrapping with 
the mechanism with which the key was wrapped.  Whatever the reason, when
we cannot directly unwrap the private key into its target slot, we 
instead unwrap it into the internal slot, and then try to move/copy the
key from the internal slot to the target slot.  

PK11_UnwrapPrivKey calls itself to do the unwrap in the internal slot.
	if (int_slot && (slot != int_slot)) {
	    SECKEYPrivateKey *privKey = PK11_UnwrapPrivKey(int_slot,
			wrappingKey, wrapType, param, wrappedKey, label,
			idValue, PR_FALSE, PR_FALSE, 
			keyType, usage, usageCount, wincx);

In that inner call, If it needs to to copy the unwrapping key to the 
internal slot, it calls
    if (wrappingKey->slot != slot) {
	newKey = pk11_CopyToSlot(slot,wrapType,CKA_WRAP,wrappingKey);

Notice that it passes CKA_WRAP as the sole operation.  pk11_CopyToSlotPerm 
calls PK11_ImportSymKeyWithFlags with that operation.  This is undoubtedly
the first issue that Helge reported.  It's trying to copy the (un)wrapping
key into the slot that will use it to unwrap the private key, but when it 
creates that unwrapping key, it gives it the CKA_WRAP attribute, rather 
than CKA_UNWRAP.  I think it might be best if the relevant functions took
a word of flags representing different operations, as we do elsewhere, so
that we could specify both wrap and unwrap.  

The second problem reported in this bug is that when the private key finally
gets copied from the internal slot to the target slot in function 
pk11_loadPrivKeyWithFlags, only the actual key contents are copied.  None
of the additional attributes, such as the various operation/usage attributes 
is copied.  This fault appears to be in pk11_loadPrivKeyWithFlags, however,
I am not certain that those usage/operation attributes are correct in the 
internal slot where the private key was unwrapped, so even if they were 
copied, the problem might not be completely solved.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Helge, in what product is this PKCS#12 import being done?  Firefox 3?  
some other version of Firefox?  Some other product?
If not Firefox, please tell us what version of NSS is being used in the 
product that has the problem.  We need to know which version of NSS to fix.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

I was trying to put together a list of the usage attributes we should copy,
and came up with this list.

CKA_ENCRYPT           
CKA_DECRYPT           
CKA_WRAP              
CKA_UNWRAP            
CKA_SIGN              
CKA_SIGN_RECOVER      
CKA_VERIFY            
CKA_VERIFY_RECOVER    
CKA_DERIVE             

But then I wondered, why only the usage attributes?  
Why not attempt to copy ALL the standard-defined attributes?
(or, at least, the subset that might apply to private keys)

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Attachment: proposed patch v1 (checked in)

Bob, I think this small patch addresses the issues reported in this bug.
I've done a simple test where I forced the first C_UnwrapKey to fail so
that it would go through the path that this bug describes.  It seems to 
pass, but I'm not sure it's necessarily correct.  You judge.

Comment 6

[Helge Bragstad]

(In reply to comment #3)
> Helge, in what product is this PKCS#12 import being done?  Firefox 3?  
> some other version of Firefox?  Some other product?
> If not Firefox, please tell us what version of NSS is being used in the 
> product that has the problem.  We need to know which version of NSS to fix.

Nelson, Thank you for adressing this issue. Now I used both Firefox 3.0.3 and Thunderbird 2.0.0.14, but I know that this problem has been around for quite some time. My own recording of the issue was April 2006.

Comment 7

[Robert Relyea]

Comment on attachment 349702 [details] [diff] [review]
proposed patch v1 (checked in)

r+

with one comment, the ecKey does not need to copy the CKA_DECRYPT and CKA_UNWRAP attributes.. This does not hurt. In fact it's OK to copy all the private key specific attributes (DECRYPT, DERIVE, UNWRAP, SIGN, SIGN_RECOVER) for all the key types.

bob

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 349702 [details] [diff] [review]
proposed patch v1 (checked in)

Checking in pk11akey.c; new revision: 1.23; previous revision: 1.22
Checking in pk11obj.c;  new revision: 1.20; previous revision: 1.19
I made one change that Bob suggested, and did not set unnecessary 
attributes on EC keys.

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

I'm marking this fixed, but I'd like the reporter to verify that it is
fixed by testing with a build with NSS 3.12.3 Beta.

Comment 10

[Helge Bragstad]

I confirm the problem is fixed. I tested using:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090209 Minefield/3.2a1pre.   
NSS version is 3.12.3.0

A PKCS #12 import that previously failed now works OK. I inspected traces of the calls to PKCS #12 and usage attributes are set as needed by this library.

Thanks again for fixing this problem.

- Helge