Wrap and unwrap in softoken are not compatibles with its corresponding functions with externals HSMs?

[NACHO SAAVEDRA]

Hi Dina, thanks again for your email.
In general the items you mention are followed by my programs. The only
difference is the CKA_PRIVATE attribute is set to false because when the
programs connect to PKCS11 I'm not using login. I know this is a hole of
security because anybody could create, deletete or manipulate the keys but
now we need to see working the crypto functions and in the immediate future
we are going to establish a secure session.

My answers are followed by the -> indicator in red color.

I did test between 2 different Solaris (10 and open) machines and worked
succesfully because both use PKCS11. In the procedures I could transport via
binary files copied to a usb pendrive the public key from one side to the
other; and when it applies the wrapped key and symetric crypto data.

If not abuse your trust I'm going to email you my programs in order you can
see clearly the problem. Please try to test with one external HSM different
from PKCS11. This is because my tests need to run with spyrus or java
cryptoAPI not based in pkcs11.
Please read the howtest.txt file.

Best regards,

Ignacio

2009/3/5 Dina <dina.nimeh at sun.com>

> Hi,
>
> Let me suggest breaking the problem down into something smaller.
> Put aside for a minute the part about encrypting and decrypting
> any data with the symmetric key.  The first thing to verify is
> whether the symmetric key is being transferred correctly from
> the encrypting side to the decrypting side.
>
> Can you confirm a few things for me please?  I'm writing a test
> program to see if I can recreate the problem you describe.  I
> have an 1024-bit RSA key pair and a 128-bit AES secret key for
> my test program.
>
> 1.  I have the following things set in my public key template:
>        CKA_CLASS - set to CKO_PUBLIC_KEY
>        CKA_KEY_TYPE - set to CKK_RSA
>        CKA_MODULUS_BITS - set to the key length, I used 1024
>        CKA_TOKEN - set to true to make it persistent
>        CKA_LABEL - I used a label for my convenience

-> All is ok.

>
>    and in my private key template:
>        CKA_CLASS - set to CKO_PRIVATE_KEY
>        CKA_KEY_TYPE - set to CKK_RSA
>        CKA_PRIVATE - set to true -> different, it's false
>        CKA_TOKEN - set to true
>        CKA_LABEL - I used a label for convenience

-> All same with the private attribute exception commented.

>
> 2.  I have these things set in the template for my AES secret key:
>        CKA_CLASS - set to CKO_SECRET_KEY
>        CKA_KEY_TYPE - set ot CKK_AES
>        CKA_TOKEN - set to true to make it persistent
>        CKA_PRIVATE - set to true -> not set
>        CKA_VALUE_LEN - set the key length, I used 16 bytes
>        CKA_LABEL - I used a label for convenience
>
-> All same with the private attribute exception commented.

>
> 3.  When I exported the RSA public key to the other side, I only
>    wrote CKA_MODULUS and CKA_PUBLIC_EXPONENT to the file.

      -> ok! I´m doing the same thing.

>
>    I did not write CKA_MODULUS_BITS because I do not need that
>    one when calling C_CreateObject() to import the RSA public key
>    object for wrapping the AES secret key.

     -> ok, I suppose you're refering to the import public key procedure.

>
>    I believe you said you had an "attribute invalid" error if you
>    tried to use CKA_MODULUS_BITS.  The PKCS#11 specification says
>    that CKA_MODULUS_BITS must be used for C_GenerateKeyPair(), but
>    it must not be used for C_CreateObject() -- Sections 10.2 and
>    12.1.2.  That is why.

      -> ok, I agree.

>
>
> 4.  When I imported the RSA public key on the other side, I used a
>    template that sets again:
>        CKA_CLASS - set to CKO_PUBLIC_KEY
>        CKA_KEY_TYPE - set to CKK_RSA
>        CKA_TOKEN - set to true to save public key on this side too
>        CKA_LABEL - I used something for convenience
>   and leaves space for:
>        CKA_MODULUS - from the exported public key file
>        CKA_PUBLIC_EXPONENT - from the exported public key file


-> The import public key procedure at the template in Softoken has the same
attributes you mention with the following exceptions: I import data from
files to set the modulus and public exponent. I don't understand why you
left spaces for this two attributes. First I read from files the modulus and
exponent and when I create the template for the Public Key imported the
values are set in CKA_MODULUS and CKA_PUBLIC_EXPONENT.

-> In my case I'm testing outside with 2 types of hsms:
   4.1 Softoken. Wrap and unwrap between Solaris10 and Open Solaris
succesfully (it's logic because the programs are the same and the virtual
hsm over PKCS11 or softoken too).

   4.2 My own Java's CryptoAPI (SW). The CKA attributes don't apply. Of
course I have methods to get the modulus and exponent to import the public
key of Softoken. Then I build a java's Public Key Object with Header plus
Modulus plus Trailer (in the trailer the exponent is included). According to
the UNIV 16 sequence or standard. I'm using exponent 3 or 010001.

>
> 5.  So now I have the AES secret key and the RSA public on the same
>    side, and I wrapped the AES key with C_WrapKey and mechanism
>    CKM_RSA_PKCS.

      -> ok! I´m doing the same thing.

   After the wrap operation, I wrote the buffer with wrapped key
>    data to a file and send it over to the first side where I started.

   -> ok! I´m doing the same thing.

>
>
> 6.  Back on the first side, I read the wrapped data from the file.
>    I used C_FindObjectsInit/C_FindObjects/C_FindObjectsFinal to
>    locate the RSA private key object.

     -> yes, with the assert library according the examples.

>
>
>    Then my test program calls C_UnwrapKey using the wrapped data
>    buffer and the RSA private key object to create a new object
>    with this template:
>        CKA_CLASS - set to CKO_SECRET_KEY
>        CKA_KEY_TYPE - set to CKK_AES
>        CKA_TOKEN - set to true
>        CKA_PRIVATE - set to true -> different, it's false
>        CKA_LABEL - something here for convenience

-> All same with the private attribute exception commented.

>
>
>    This new object should be recovered AES secret key, from the
>    opposite side, now on this side on the token.
>
> 7.  Are we together so far?  So what happens for you when you call
>    call C_UnwrapKey()?  Is this where you get the error
>    CKR_OBJECT_HANDLE_INVALID?

-> Yes, code 0000082.

>
> 8.  What are the values for the following attributes for the RSA
>    public key?
>        CKA_WRAP - true or false? -> true
>        CKA_ENCRYPT - true or false? -> true
>
>    for the RSA private key?
>        CKA_UNWRAP - true or false? -> true
>        CKA_DECRYPT - true or false? -> true
>
>    for the AES secret key
>        all of the above attributes - true or false?

      -> all in true

>
>
>    If the implementation doesn't automatically set these values
>    to some reasonable defaults, you may have to set them in the
>    key/key-pair generation templates, create-object templates
>    for importing, and the unwrap-key templates too.

-> I'm setting the CKA attributes at the moment of symmetric key generation
and RSA key pair generation.
For Publick key the wrap and encrypt attributes are true.
For Private key the unwrap and decrypt attributes are true.

>
>
> Please let me know if your program can get through these steps.
> If it can, then we know the secret key has a good chance of
> being transferred correctly and can move onto to see if the
> problem is somewhere in the encryption/decryption of the data.
>
> Thanks,
> D.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.opensolaris.org/pipermail/crypto-discuss/attachments/20090306/c0f97cb6/attachment.html>