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. > 1) The aplication generates a key pair > 2) The card import the public key generated by the aplication > 3) The card generates a secret key (i.e, DES3) > 4) The card wraps the secret key with the public key obtained from the > aplication. > 5) The aplication unwraps the secret key with the private key generated in 1. > 6) The application now wraps its private key with the secret key. > 7) The card unwraps aplication's private key with the secret key. This is a more reasonable approach. Yet this will require support a) in the on-card application (not very available nor standard) b) OpenSC card driver (not available in any of existing drivers) c) OpenSC PKCS#11 module As wrapping and unwrapping makes sense between two "equally secure" systems (like two smart cards or a smart card and a HSM) it is not a very common application. Either way it requires specially designed support from both ends and the exact requirements will vary quite a lot. In fact, I'd suggest bypassing PKCS#11 in such situation altogether. PKCS#11 is mostly for interoperability and (generic) application use. You can accomplish what you'd want with much thinner and flexible API-s than PKCS#11. Another option would be deploying the plaintext key material with secure channel. Again - that would have nothing to do with PKCS#11. Martin _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
