On 11/01/2010 12:33 AM, Matej Kurpel wrote: > Hello, > I am implementing a PKCS#11 module. Today I tried to send encrypted > e-mail to my second gmail account, and it works perfectly (in fact, > nothing is needed from my token to support this). However, when the > message arrives and I try to read it, Thunderbird calls C_UnwrapKey > (which, of course, I don't have implemented) and then C_DecryptInit (I > will implement this in the near future). So it's OK that the > decryption fails. > But, why does TB need to unwrap some key? What is this key and where > does it come from? It's trying to unwrap that key no matter what, > despite the fact that the key for unwrapping has CKA_UNWRAP set to > FALSE, the mechanism doesn't have its CKF_UNWRAP flag set and the > token is read only. Is this a bug of some sort? Short answer: don't worry about it, just return an error and implement C_DecryptInit/C_Decrypt and you will be fine.
Long answer: NSS wants to keep keys in the same token. At the very top, S/MIME is doing an unwrap because under certain conditions it's difficult to impossible to move the key. Under the high level unwrap, NSS calls the token to do the unwrap, then it would call the token to do the decrypt. (NOTE: if your token can do all the appropriate symmetric algorthims, you can just implement the unwrap and not the decrypt -- some tokens do this). If the unwrap fails, NSS implments the unwrap by calling decrypt and importing the key into a token that can do the rest of the S/MIME operation. bob > (I am attaching the pkcs11-spy log) > > > 78: C_GetMechanismInfo > [in] slotID = 0x0 > CKM_RSA_PKCS > [out] pInfo: > CKM_RSA_PKCS : min:256 max:4096 flags:0xA01 > Returned: 0 CKR_OK > > ... > ... > > 83: C_UnwrapKey > [in] hSession = 0x2 > pMechanism->type=CKM_RSA_PKCS > [in] hUnwrappingKey = 0x2 > [in] pWrappedKey[ulWrappedKeyLen] [size : 0x80 (128)] > A19820CD 6DC92728 62A54066 7F06ABFD 33164AB2 2B8FD6AE D16BF51B > 0610038F > 766ACC79 464A7097 36254469 AB6F0508 3D96F701 244C86B9 8E7DD4B8 > E6BF5679 > 2EF5FA9D F70E0205 CAC8D16F 650F2D55 C4ACF796 549AA9A4 5CDFD506 > 29F7916C > D47E83A2 B9C58030 C975802E 2584D6CC 7D08C6C3 4A4FBFBB 26463FBA > FC010C37 > [in] pTemplate[3]: > CKA_CLASS CKO_SECRET_KEY > CKA_KEY_TYPE CKK_DES3 > CKA_DECRYPT True > Returned: 226 CKR_TOKEN_WRITE_PROTECTED > > > M. Kurpel
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
