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" <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
