Antonio Andres Espallardo wrote:
Hi everybody. I'm having some problems with a PKCS11 module I've developed in encrypt/decrypt methods. I can't understand the behavior when I use it with Netscape 7.2 or Thunderbind in these operations. Could anyone facilitate me a trace of his pkcs11 in which I could see the input data (and length), the cipher used and the output generated by the methods C_EncryptInit / C_DecryptInit, C_Encrypt / C_Decrypt or C_EncryptUpdate / C_DecryptUpdate?.
To get trace information, you will need to build or pull a debug version of NSS. As long as you get a version of NSS which is equal to or greater then the version of NSS in the mozilla product you are useing you should be OK (I swap in newer versions of NSS to these products all the time to test changes in NSS).
Once you have a debug version installed you can set the environment variable "NSS_DEBUG_PKCS11_MODULE" to the name you installed our PKCS #11 module as. The output will go to the NSPR Log named "nss_mod_log".
To be more concrete. If I write a mail message (using the mail manager of netscape 7.2) indicating it must be encrypted, netscape only uses my pkcs11 module to do some objects search operations and to know some attribute values, but it don't use the pkcs11 cypher operations. What cipher algorithm uses netscape by defect to do that operation?
All crypto operations for these products go through the security layer called NSS.
For almost all operations NSS has a perfectly usable PKCS #11 module to provide all the operations it needs -- the soft token. Unless you specify at install time that you want your token to take over these default operations, NSS will continue to prefer using it's own implementation. This is because 1) in most cases it's internal implementation is faster, and 2) it's more likely to provide the functionality NSS needs.
The exceptions to this rule are 1) if you register your token to take over these default operations, NSS will use your token whenever it desides to do operation XYZ, or 2) they keys needed to do the requested operation resides in your token.
Case 1 is really to make hardware accellerators work. Vendors of hardware accellerators tyically implement a complete set of PKCS #11 mechanisms, and usually do as good or better a job with those implementations as the soft token does. Most user tokens (those that would run in an application like Mozilla or Thunderbird), don't implement a full set of operations (nor do they need to). They also tend to be slower.
In the email encryption case, the public key comes from the cert. NSS then looks at the all the default RSA devices for ones that can do RSA and DES3. It chooses the first one that does all these operations, imports the public key and encrypts the message. Since your token isn't registered as the default RSA device, NSS doesn't use your token for any of these operations, but it shouldn't matter since the software is able to completely handle your encryption request.
This is the trace I obtain when I try to decrypt the previous mail message:
C_DecryptInit. --> Mechanism: CKM_DES3_CBC. --> Key length: 24 bytes. --> IV: <195> <128> <252> <112> <101> <170> <232> <250> END C_DecryptInit.
C_DecryptUpdate.
--> Input Data(16 bytes): <22> <b2> <b5> <62> <f1> <8c> <c2> <11> <78> <2d> <88> <bd> <31> <4> <33> <5e>
--> Output data(8 bytes): <43> <6f> <6e> <74> <65> <6e> <74> <2d>
END C_DecryptUpdate.
Now Netscape close the session and finalizes the decrypt operation.
Does anybody knows what can be happening?. Thanks in advance.
So now it's time to decrypt the message. The only certificate NSS found that it could use to decrypt the message had it's private key in your token (I'm presuming you have a C_Unwrap call to your PKCS #11 module before the C_DecryptInit). In this case the only way to accomplish its task is for NSS to use your CKM_RSA_PKCS mechanism with the private key in that token. Once NSS has started using a token, NSS tries to keep all the rest of the operations in that token. This is because many tokens do not give up their keys easily. NSS noticed that 1) your token had the private key, 2) your token supported unwrap, and 3) your token supported CKM_DES3_CBC. Because of all of this, NSS not only uses your token to unwrap the key, but also uses your implementation of CKM_DES3_CBC. Unfortunately you're implementation is incorrect as you can clearly see that even though NSS provided a proper multiple of the Blocksize (3 blocks) to your PKCS #11 module as input, your module only returned one block on output.
The first thing I would do would be turn off CKM_DES3_CBC in your module temporarily. This will cause NSS to use your token to decrypt the S/MIME key, then use the internal soft token to decrypt the message. It looks like everything would work since you look like you are starting to decrypt good data (the Output when converted back to ascii of this dump reads 'Content-').
The other thing you could do is fix your C_DecryptUpdate function to return the correct number of bytes.
I would try both fixes and see what the performance is for a large document. Then you can decide which you would rather ship with.
bob
_______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
smime.p7s
Description: S/MIME Cryptographic Signature
