On 4/18/2011 9:42 PM, Felipe Blauth wrote:
>
>
> 2011/4/16 Martin Paljak <mar...@martinpaljak.net 
> <mailto:mar...@martinpaljak.net>>
>
>     Hello,
>     On Apr 14, 2011, at 17:43 , Felipe Blauth wrote:
>      > 2011/4/14 Martin Paljak <mar...@martinpaljak.net 
> <mailto:mar...@martinpaljak.net>>
>      > Hello,
>      > On Apr 14, 2011, at 02:21 , Felipe Blauth wrote:
>      > >  I just wanted to make a simple protocol to import a private key to 
> a card in a secure way (the aplication runs in a secure container):
>      > > I was thinking about 2 ways:
>      > >
>      > > 1) The card generates a key pair
>      > > 2) The card exports the public key generated in 1 to the aplication( 
> I think this can be done with C_GetAttributeValue and openssl)
>      > > 3) The aplication generates another key pair and wraps it's private 
> with the public  it got from the card (this part I don't know if it is 
> possible).
>      > > 4) The card unwraps, with private key generated in 1,  and obtain 
> the private key generated by the aplication.
>      >
>      > What exactly would be the point of this? If your application would be 
> written with OpenSSL, you'd be generating a plaintext key in a normal host 
> application (I assume). If you had a HSM or
>     equivalent for central key generation it would be a different story.
>      >
>      > You guessed the environment. I have an HSM as a central key generation 
> and it uses OpenSC cards to authentic its users. The HSM is currently beeing 
> developed, it is a project of the University
>     I study. The HSM does not implement PKCS#11 interface, it is all OpenSSL, 
> and that's because I've asked that. Since the key has to be generated in the 
> HSM, I was just trying to make it goes from
>     the HSM to the card in a secure way, because the physical protection of 
> the HSM does not cover the Smart Card reader wire (which is just a Gemplus 
> GemPC Twin ccid reader).
>
>     You'll need card support either way. Maybe secure messaging is more 
> available than other options.
>
>
>     How will your interfere with your HSM if it does not provide an API?
>
> It is an apliance HSM and it has  an OpenSSL engine. It runs a freeBSD inside 
> and the comunication is done via tcp and https.
>
> Next is a question out of OpenSC scope, but if someone could help I would be 
> very thankful...
>
> Here it goes: I managed to negociate a DES key between the aplication and the 
> card using vendor module (libaetpkss.so, wich i can download for free here
> <http://icp.caixa.gov.br/_downloads/safesign_linux.zip>) and wrapping. Now I 
> want to unwrap
> the key that I "wraped" using OpenSSL.  What I did to "wrap" was first encode 
> the private key in PKCS#8 format and then encrypt it with the DES key I've 
> already negotiated
> (that is what is said in PKCS#11 standard to wrap private keys).

I don't see where PKCS#11 is being used? So why are you trying to use PKCS#11?

OpenSC does not support the C_UnwrapKey operation at this time,
so what PKCS#11 are you using in your example?

Even if it did, it looks like what you are trying to do is to send the
wrapped key to the card, and have the card use a DES key the is on the card
to unwrap it so it stays on the card. (You used CKA_TOKEN true which
says the  private  key should be on the card.)

>
> But, whenever I try to call C_unwrap, I allways get CKR_TEMPLATE_INCOMPLETE. 
> Just don't know if my template is really wrong or if my card does not support 
> that. Piece of the code follows. I can send
> all my code if someone is interested too.
>
>      CK_BYTE iv[] = {0xD2, 0xD3, 0x9A, 0xDB, 0x49, 0x90, 0xE9, 0x61};
>      CK_MECHANISM mechanism_unwrapping = {CKM_DES_CBC_PAD, iv, sizeof(iv)};
>
>      CK_OBJECT_HANDLE newPrivateKey;
>      CK_BYTE subject_private[] = "wraped_private_key";
>      CK_BYTE wraped_id[] = {0xa2};
>
>      CK_OBJECT_CLASS wraped_key_class = CKO_PRIVATE_KEY;
>      CK_KEY_TYPE wraped_key_type = CKK_RSA;
>
>
>      CK_ATTRIBUTE privateKeyTemplate[] = {
>              {CKA_CLASS, &wraped_key_class, sizeof(wraped_key_class)},
>              {CKA_KEY_TYPE, &wraped_key_type, sizeof(wraped_key_type)},
>              {CKA_SIGN, &true, sizeof(true)},
>              {CKA_UNWRAP, &true, sizeof(true)},
>              {CKA_ID, wraped_id, sizeof(wraped_id)},
>              {CKA_LABEL, subject_private, strlen((char *)subject_private)},
>              {CKA_TOKEN, &true, sizeof(true)},
>              {CKA_DECRYPT, &true, sizeof(true)},
>              {CKA_VERIFY, &true, sizeof(true)},
>              {CKA_SIGN, &true, sizeof(true)}
>
>      };
>
> C_UnwrapKey(session_handler, &mechanism_unwrapping, h_des_key, 
> ptr_wraped_key,  size_wraped_key, privateKeyTemplate, 10, &newPrivateKey);
> .
> .
>
>
> The iv (initialization vector) I used there is the same i used to encrypt 
> outside.
>
> Thank you
>
>
>
>     Martin
>
>
>
>
> _______________________________________________
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-devel

-- 

  Douglas E. Engert  <deeng...@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Reply via email to