JAVA Toolkit
| home | contact




Errors

 

Q:

When I try to sign or decrypt with my PKCS#11 RSA private key I get an java.lang.UnsupportedOperationException exception with the message "Private Exponent value is sensitive." What is the problem?

A:

This normally means that the application tries to use the PKCS#11 private key with the Signature or Cipher implementation of another (software) provider. The software implementations try to get the private exponent value from the key object to do the operation. This fails, because for most PKCS#11 tokens the private exponents and other sensitive key values are not accessible from outside the token to protect the key. These keys can only be used on the token itself. Thus you must always ensure that the application uses PKCS#11 keys only with the PKCS#11 JCE provider. Otherwise the operation will fail. For ciphers and symmetric keys (secret keys) the situation is the same (see next question).

Q:

When I try to encrypt or decrypt with my PKCS#11 secret key I get an java.lang.UnsupportedOperationException exception with the message "Value is sensitive." What is the problem?

A:

This normally means that the application tries to use the PKCS#11 secret key with the Cipher implementation of another (software) provider. The software implementations try to get the key value from the key object to do the operation. This fails, because for most PKCS#11 tokens the key material of secret keys is not accessible from outside the token to protect the key. These keys can only be used on the token itself. Thus you must always ensure that the application uses PKCS#11 keys only with the PKCS#11 JCE provider. Otherwise the operation will fail. For signatures and ciphers with asymmetric keys (private and public keys) the situation is the same (see previous question).

Q:

 When reading the key store, after entering the PIN, I always get an exception like "java.lang.IllegalArgumentException: Argument "keySpec" must be of instance iaik.pkcs.pkcs11.provider.keyfactories.PKCS11KeySpec". What is wrong?
 

A:

This is usually caused by the certificate parsing of the first JCE provider that supports a key factory suitable for the public key in the certificate (e.g. RSA). The certificate parsing normally uses the first suitable key factory that supports this algorithm. You have several options to solve this problem. First, you can simply install a software provider (e.g. IAIK-JCE) that supports this key factory at a lower index (i.e. with a higher priority). In this case, this provider will be asked for a key factory. Second, if you have a newer version of the PKCS#11 JCE Provider than version 1.0 (e.g. 1.1), you can configure a delegate provider for the key factory using the delegation mechanism of the PKCS#11 JCE Provider. See the Using/Delegate Provider part of the documentation for details about this feature. Third, you can remove the corresponding key factory algorithms from the IAIKPkcs11Algorithm.properties of your PKCS#11 provider. In this case, you should have at least one software provider (e.g. IAIK-JCE) installed that provides the required key factory.

Q:

I try to sign XML using the XSECT library from IAIK. I got the key from the PKCS#11 keystore, but when I try to sign I get an exception including a message saying "Prime P value is sensitive". I used the same code as for signing with a software key, so what is wrong?

A:

The problem is that XSECT tries to use the first JCA provider which supports the requested signature algorithm, no matter if the private key is a PKCS#11 key. If the selected provider is a software JCA provider, it will try to use the PKCS#11 key with its software implementation of the signature algorithm. When it tries to read the key material it fails and gets this exception message, because for most PKCS#11 tokens the key material of private keys is not accessible from outside the token to protect the key.

You can solve this by inserting a single line of code, where you tell XSECT what JCA provider to use for signing. When you register the XSECT Provider, specify the PKCS11-Provider as delegate provider for the used signature algorithm:

XSecProvider xsecProvider = new XSecProvider();
// configure delegation for RSA signature with SHA-1
XSecProvider.setDelegationProvider("Signature.SHA1withRSA", pkcs11Provider_.getName());
Security.addProvider(xsecProvider); 

 Where pkcs11Provider_ is the instance of the PKCS#11 provider to use (you may also use other means the get the name of your PKCS#11 provider instance).
 

Q:

 I use the PKCS#11 provider in an applet. Everything works as expected, but when I reload the applet in the browser the PIN dialog hangs and the complete browser freezes. What is the problem?
 

A:

 The problem is that the VM destroys the PIN dialogs of the PKCS#11 provider when it destroys the applet, even though these dialogs haven't been created by the applet itself. Thus, when the browser reloads the applet the PIN dialogs have been disposed, or at least most of the internal resources of the dialogs. When the provider wants to prompt the PIN using these dialogs, this causes an exception to be thrown somewhere in the event queue of the windowing toolkit (AWT/Swing). To avoid this problem, you must tell the PKCS#11 provider to create new instances of PIN dialogs next time it needs such a dialog. You can do this by simply adding the following lines to the destroy() method of your applet:
 

public void destroy() { 
   ... 
   if (iaikPkcs11Provider_ != null) { 
     DefaultLoginManager loginManager = 
      (DefaultLoginManager) iaikPkcs11Provider_.getLoginManager();
     loginManager.setPassphrasePrompt(null);
     loginManager.setPassphraseChangePrompt(null);
   }
}

 Assuming that iaikPkcs11Provider_ is a reference to your PKCS#11 provider instance. If you have implemented your own PIN dialogs, you have to ensure that you create new instances of these dialogs when the browser reloads the applet.
 

Q:

 When I try to use the PKCS#11 provider in my application or with a demo, I get iaik.pkcs.pkcs11.provider.IAIKPkcs11Exception: iaik.pkcs.pkcs11.wrapper.PKCS11Exception: CKR_CANT_LOCK. How can I solve this problem?
 

A:

This may happen if the PKCS#11 module of your cryptographic hardware does not support access from multiple threads simultaneously. Per default, the PKCS#11 provider initializes the PKCS#11 module for multi-threaded access. If the module does not support this, it will cause an exception. However, you can configure the PKCS#11 provider to initialize the PKCS#11 module for single-threaded access. You can do this by setting the MULTI_THREAD_INIT to false. It is true by default.

If you do so and it works, be aware of the fact that your PKCS#11 module does not allow concurrent access of the module from different threads. Your application has to take care not to use this PKCS#11 provider instance from multiple threads simultaneously.

Q:

 I configured the PKCS#11 module for my hardware, but the provider initially throws iaik.pkcs.pkcs11.provider.IAIKPkcs11Exception: iaik.pkcs.pkcs11.wrapper.PKCS11Exception: CKR_ARGUMENTS_BAD. What can be the problem?
 

A:

Some PKCS#11 modules do not accept any initialization parameters, but per default the PKCS#11 provider tries to initialize the module for multi-threaded access. You can disable this behavior by setting the MULTI_THREAD_INIT entry in your configuration properties to false. Please read the section about the configuration properties in the usage documentation of the provider.

Q:

 My application throws an iaik.pkcs.pkcs11.provider.IAIKPkcs11Exception: iaik.pkcs.pkcs11.wrapper.PKCS11Exception: CKR_RANDOM_SEED_NOT_SUPPORTED. What is wrong?
 

A:

 This can happen if a token does not support setting a random seed value. For example some Schlumberger cards do not support this feature. If an application instantiates a SecureRandom using e.g.
 

  SecureRandom random = new SecureRandom();

 the JCA framework uses the first SecureRandom implementation it can find amongst all registered providers. If the PKCS#11 provider is installed before other providers, the SecureRandom implementation called PKCS11 is normally used (see Features table for details).
 In the IAIKPkcs11Algorithms.properties file, you can disable the SecureRandom implementations which may cause problems. The last few lines of the resulting file may look like this:
 

 # generate random, get seed and set seed operates on token
 # SecureRandom.PKCS11 = iaik.pkcs.pkcs11.provider.random.PKCS11RandomSpi

 # get seed from token; get random and set seed to software delegate
 # SecureRandom.PKCS11Seeded = iaik.pkcs.pkcs11.provider.random.PKCS11SeededRandomSpi

 # generate random and get seed operates on token, set seed bytes are ignored if no software delegation used
 SecureRandom.PKCS11NoSetSeed = iaik.pkcs.pkcs11.provider.random.PKCS11RandomNoSetSeedSpi

 Notice the commented out implementations PKCS11 and PKCS11Seeded. The only SecureRandom implementation left is the PKCS11NoSetSeed. It has been designed to solve this problem. It does not pass any seed values to the token.
 

Q:

My application throws an iaik.pkcs.pkcs11.provider.IAIKPkcs11Exception: Required PKCS11_NATIVE_MODULE property has not been configured. What is wrong?

A:

The PKCS#11 Provider will throw this exception if the application did not configure the PKCS11_NATIVE_MODULE property of the provider. If the application uses properties files for the provider configuration, there may be two reasons for this exception. First, it may be that the directory structure which contains the configuration properties files is not included in the CLASSPATH. For example, if the configuration properties are in the resources/iaik/pkcs/pkcs11/provider directory, the resources directory must be in the CLASSPATH. Second, if the properties files are in the CLASSPATH, the IAIKPkcs11.properties file may not contain a PKCS11_NATIVE_MODULE entry, or that entry may be commented out.

Q:

My application throws an java.lang.UnsatisfiedLinkError: no pkcs11wrapper in library path or jar file. What is wrong?

A:

The PKCS#11 Provider will throw this exception if the application could not find the native PKCS#11 wrapper library.
Since PKCS#11 wrapper version 1.4 the native libraries are included in the wrapper's jar file. They are copied to a local directory
and loaded from there. If you get the given exception you may use a system not supported by us or the library could not be
copied to the local directory.

You can also configure which library to use. Please see the Installation guide for further details.

Q:

 What can be the reason for getting a iaik.pkcs.pkcs11.wrapper.PKCS11Exception: CKR_OBJECT_HANDLE_INVALID exception?
 

A:

This can happen for private objects (e.g. private keys) due to a log out of the user from the token. According to the PKCS#11 specification, when a user logs in to a token, private objects get visible and become a handle each. If the user logs out from the token, the specification says that the private key handles become invalid and remain invalid even after another login. The same private objects then get new handles. This means, after a log out and login, the application should read the token contents again to avoid referring to the correct objects.

 Many PKCS#11 module implementations keep the private objects handles stable after log out/login operations, however, applications cannot rely on this behavior in general. If an application rely on this, the developer should get assurance from the module manufacturer.
 Also, this can happen for session objects if the session has been closed which has been used for creating the object. Usually, the PKCS#11 provider cares about this. Thus, this should not happen unless the application explicitly closes sessions.
 

Q:

When using the PKCS#11 Provider with JSSE, my program gets an exception including Caused by: java.lang.UnsupportedOperationException: Prime P value is sensitive. What can be the problem?

A:

 Most likely, your user application uses the unsigned JAR files when it should use the signed JAR files. This refers to iaikPkcs11Provider.jar and iaik_jce.jar (or iaik_jce_full.jar). Use the signed versions of these files. The installation instructions describe this in more detail.
 This problem can also happen if you use Java™ 1.5 with an version prior to Java™ 1.5.0 Update 4 in combination with a PKCS#11 Provider version 1.1.7 or older. The JCA/JCE framework in these Java™ versions had a bug which can cause this problem (Java™ bug database ID 2113627 and 5097015).
 


 
print    tip a friend
back to previous page back  |  top to the top of the page