This is kind of a strange error message. It generally gets issued when a key
type and a mechanism don't agree. Moving the key from a session key to a token
key basically changes the key from ephemeral to permanent - so not sure what's
going on here.
I note that you have more than just CKA_TOKEN=true going on here. Do you still
have the exact problem if you delete just the CKA_TOKEN=true line/attribute
group? It's possible that the thing that solved the problem is the
CKA_SIGN=true in the private key space.
There's a useful module that's part of opensc www.opensc-project.org -
pkcs11-spy. (Browse source to trunk/src/pkcs11/pkcs11-spy. It acts as a shim
between a program and a real PKCS11 module to allow you to wiretap the
interactions. I'd be interested in seeing exactly what the differences are in
the PKCS11 arguments between the with and without CKA_TOKEN=true.
With respect to matching up the keys and certs - look at the CKA_ID attribute.
The value for that attribute should be common across the cert, private and
public key after a store.
Mike
[Should we take this offline? May be out of scope for security-dev]
At 04:06 AM 4/20/2010, 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" <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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>>
