[security-dev 01750]: Re: alias in KeyPairGenerator - was: '\0' in alias name of a pkcs11 keystore
Valerie (Yu-Ching) Peng
valerie.peng at oracle.com
Tue Apr 20 11:57:08 PDT 2010
Hmm, can you log the exact PKCS11 calls as well as setting this
debugging option "-Djava.security.debug=pkcs11keystore" when launching
your program w/ both (2) and (3)?
Thanks,
Valerie
On 04/20/10 01:06, Tomas Gustavsson wrote:
>
> Hi here are some more detailed testing results.
>
> Tested on one of the most common HSMs, a SafeNet Luna SA.
>
> If it would be of interest for you I could use pkcs11-spy to log the
> exact PKCS11 calls that are passed.
>
> 1)
> When simply generating keys without a PKCS11 config file, the key
> generation works but when we try to use the key to create a self
> signed certificate (so use in setKeyEntry and keyStore.store) the
> following error is thrown.
> -----
> Caused by: sun.security.pkcs11.wrapper.PKCS11Exception:
> CKR_KEY_TYPE_INCONSISTENT
> at sun.security.pkcs11.wrapper.PKCS11.C_SignFinal(Native Method)
> at sun.security.pkcs11.P11Signature.engineSign(P11Signature.java:462)
> ... 14 more
> -----
>
> 2)
> We have earlier resolved this by using a PKCS11 config file:
> -----
> name=Luna
> library=/usr/lunasa/lib/libCryptoki2_64.so
> slot = 1
>
> attributes(generate,*,*) = {
> CKA_TOKEN = true
> }
> attributes(generate,CKO_PUBLIC_KEY,*) = {
> CKA_ENCRYPT = true
> CKA_VERIFY = true
> CKA_WRAP = true
> }
> attributes(generate, CKO_PRIVATE_KEY,*) = {
> CKA_EXTRACTABLE = false
> CKA_DECRYPT = true
> CKA_SIGN = true
> CKA_UNWRAP = true
> }
>
> -----
>
> This results in everything working, but only the certificate entry
> gets an alias when we list the objects on the HSM.
>
> 3)
> I modified the PKCS11 config file to remove the CKA_TOKEN, according
> to your recommendation.
> -----
> name=Luna
> library=/usr/lunasa/lib/libCryptoki2_64.so
> slot = 1
>
> attributes(generate,CKO_PUBLIC_KEY,*) = {
> CKA_ENCRYPT = true
> CKA_VERIFY = true
> CKA_WRAP = true
> }
> attributes(generate, CKO_PRIVATE_KEY,*) = {
> CKA_EXTRACTABLE = false
> CKA_DECRYPT = true
> CKA_SIGN = true
> CKA_UNWRAP = true
> }
> -----
>
> The results are the same as in 2. Only the certificate has a label
> when listing the objects in the HSM (with 'cmu list').
>
> Kind regards,
> Tomas
>
>
> Valerie (Yu-Ching) Peng wrote:
>>
>> You can use your custom PKCS11 config and as long as you call the
>> KeyStore API to store the key (generated as session key) under the
>> desired alias, it will be saved as a token key as a result.
>>
>> Have you tried it and see if this solves your problem?
>> Valerie
>>
>> On 04/19/10 08:08, Tomas Gustavsson wrote:
>>> If we need it it's usually for all keys, both RSA and EC.
>>>
>>> Cheers,
>>> Tomas
>>>
>>> "Michael StJohns" <mstjohns at 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>>
>>
More information about the security-dev
mailing list