If we need it it's usually for all keys, both RSA and EC. Cheers, Tomas
"Michael StJohns" <mstjo...@comcast.net> wrote: >At 04:34 AM 4/19/2010, Tomas Gustavsson wrote: > >>Hi, >>Sorry being late, I was away on vacation. >> >>Yes in most cases we do use a custom PKCS11 config fil, with token=yes. If we >>specify token=false would it still be a token object on the HSM finally? > >Yes. The C_CopyObject turns the Session object into a Token object. and that >happens as a side effect of the KeyStore.store operation. > >>For most HSMs we need to use a cusom PCKS11 config file, otherwise it is not >>possible to generate key because the HSM will throw an error, usually >>invalid_template. > >Does this happen for all keys or just for EC keys? > > >>Cheers, >>Tomas >> >> >>Valerie (Yu-Ching) Peng wrote: >>>If the default PKCS11 config is used, I'd expect that KeyPairGenerator to >>>generate a "session" key and then SunPKCS11 keystore impl will do a >>>C_CopyObject(...) w/ the desired alias. >>>Is a custom PKCS11 config file used here? If yes, perhaps it specifies that >>>token key be generated for key generation? >>>Valerie >>>On 03/31/10 17:51, Michael StJohns wrote: >>>>KeyPairGenerator should be generating a "Session" key pair. >>>> >>>>When you write the key store object, the underlying function should do a >>>>C_CopyObject from the Session object to a Token object. (Or from a >>>>software key to a Token object). At that point, the template provided to >>>>C_CopyObject should be able to reset the CKA_LABEL attribute to the alias. >>>> >>>>Let me look at the code and see what's going on and make further comments >>>>tomorrow. >>>> >>>>Mike >>>> >>>> >>>>At 03:26 AM 3/31/2010, Tomas Gustavsson wrote: >>>> >>>> >>>>>Hi, >>>>> >>>>>Sorry if I misunderstood you. That is actually exactly how we do it, >>>>> >>>>>1. Use KeyPairGenerator with P11 provider to generate key pair. >>>>>2. Create a keystore with the P11 provier. >>>>>3. Generate a self signed certificate. >>>>>4. keystore.setKeyEntry(myalias, privateKey, null, cert). >>>>> >>>>>The keys work fine to use in java. The issue is that in the HSM three >>>>>objects are generated/stored. >>>>>1. Private key - no alias >>>>>2. Public key - no alias >>>>>3. Certificate - myalias >>>>> >>>>>The reason for this is that the alias of the private and public keys are >>>>>set in the HSM when the keys are generated (with the KeyPairGenerator). >>>>>The HSMs do not allow an alias of a private key (in particular) to be >>>>>changed after generation, so setKeyEntry can not change the empty alias of >>>>>the private key object. >>>>>This has been confirmed by technicians at AEP, but it works the same in >>>>>nCipher, SafeNet and Utimaco, i.e. no alias on the private key object. >>>>> >>>>>If we want to use HSM vendors tools to manipulate objects this usually >>>>>causes problems because they mostly rely on an alias. >>>>> >>>>>So finally :-) this is why an alias parameter to KeyPairGenerator would be >>>>>useful. >>>>> >>>>>Cheers, >>>>>Tomas >>>>> >>>>> >>>>>On 03/30/2010 08:34 PM, Valerie (Yu-Ching) Peng wrote: >>>>> >>>>>>Why do you assume that the key is generated in software? >>>>>>You use the KeyGenerator API to generate a key, this key can be >>>>>>generated on the HSM if you have SunPKCS11 provider configured to be the >>>>>>most preferred provider. This key should actually just encapsulate the >>>>>>native key handle (not the actual value/encoding) which you can then >>>>>>pass it to the KeyStore API and specify an alias. The PKCS11 keystore >>>>>>impl would then take this key object (with the native key handle) and >>>>>>create a persistent copy on the HSM with the specified alias. >>>>>> >>>>>>Regards, >>>>>>Valerie >>>>>> >>>>>>On 03/29/10 22:57, Tomas Gustavsson wrote: >>>>>> >>>>>>>Hi, thanks for the answer. >>>>>>> >>>>>>>Generating a key in software and trying to store it on the HSM violates >>>>>>>the whole idea of using an HSM. Which is to generate and maintain the >>>>>>>keys in the HSM at all times. >>>>>>>Most high security policies *requires* that the keys are generated by >>>>>>>the HSM, inside the HSM. >>>>>>>I also doubt that it would work to store software generated keys using >>>>>>>the keytool API. Many HSMs even forbid this, at least when running in >>>>>>>strict FIPS mode. >>>>>>> >>>>>>>Regards, >>>>>>>Tomas >>>>>>> >>>>>>>Valerie Peng wrote: >>>>>>> >>>>>>> >>>>>>>>Have you tried saving that key through the KeyStore API which allows you >>>>>>>>to specify an alias? >>>>>>>>Thanks, >>>>>>>>Valerie >>>>>>>> >>>>>>>>On 03/26/10 00:05, Tomas Gustavsson wrote: >>>>>>>> >>>>>>>> >>>>>>>>>Slightly off topic. >>>>>>>>>Something I would like to see is API support for setting aliases when >>>>>>>>>using the KeyPairGenerator. This is due to the fact that many HSMs do >>>>>>>>>not allow changing an alias of private keys after they have been >>>>>>>>>generated. Since the key pair generator sets a blank alias when using >>>>>>>>>PKCS#11, HSM key pairs are left with no alias. >>>>>>>>> >>>>>>>>>You can set an alias by providing it using pkcs11 attributes through >>>>>>>>>the provider, but that alias is provider global (for all generated key >>>>>>>>>pairs) which is not very usable. >>>>>>>>> >>>>>>>>>Regards, >>>>>>>>>Tomas >>>>>>>>> >>>>>>>>>On 03/26/2010 12:17 AM, Valerie Peng wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>>Probably not. Unless explicitly specified through KeyStore APIs, >>>>>>>>>>aliases >>>>>>>>>>are constructed using the attributes values associated with the >>>>>>>>>>keys/certs. Thus, this is probably due to some problem with the native >>>>>>>>>>library which generated the keys/certs. >>>>>>>>>>Valerie >>>>>>>>>> >>>>>>>>>>On 03/18/10 19:03, Weijun Wang wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>Hi Valerie >>>>>>>>>>> >>>>>>>>>>>As described inhttp://forums.sun.com/thread.jspa?threadID=5432248, >>>>>>>>>>>customer's pkcs11 keystore has aliases ended with '\0'. >>>>>>>>>>> >>>>>>>>>>>Is this something we should fix on the Java side? >>>>>>>>>>> >>>>>>>>>>>Thanks >>>>>>>>>>>Max >>>>>>>>>>> >>>>>>>>>>> >>>> >>>> >>>> > -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.