nCipherKM JCA JCE CSP
The nCipherKM JCA/JCE CSP (Cryptographic Service Provider) allows Java applications and services to access the secure cryptographic operations and key management provided by Entrust nShield hardware. This provider is used with the standard JCE (Java Cryptographic Extension) programming interface.
To use the nCipherKM JCA/JCE CSP, you must install:
-
the nShield Java package which includes the nShield Java jars and Keysafe.
For more information about the bundles and components supplied on your Security World Software installation media, see the User Guide.
The following versions of Java have been tested to work with, and are supported by, your nShield Security World Software:
-
Java7 (or Java 1.7x)
-
Java8 (or Java 1.8x).
-
Java11
We recommend that you ensure Java is installed before you install the Security World Software. The Java executable must be on your system path.
If you can do so, please use the latest Java version currently supported by Entrust that is compatible with your requirements. Java versions before those shown are no longer supported. If you are maintaining older Java versions for legacy reasons, and need compatibility with current nShield software, please contact Entrust nShield Support, https://nshieldsupport.entrust.com.
To install Java you may need installation packages specific to your operating system, which may depend on other pre-installed packages to be able to work.
Suggested links from which you may download Java software as appropriate for your operating system:
Detailed documentation for the JCE interface can be found on the Oracle Technology web page here. |
Softcards are not supported for use with the nCipherKM JCA/JCE CSP in Security Worlds that are compliant with FIPS 140-2 Level 3. |
Installing the nCipherKM JCA/JCE CSP
To install the nCipherKM JCA/JCE CSP:
-
In the hardserver configuration file, ensure that:
-
priv_port
(the port on which the hardserver listens for local privileged TCP connections) is set to 9001 -
nonpriv_port
(the port on which the hardserver listens for local nonprivileged TCP connections) is set to 9000.If you need to change either or both of these port settings, you restart the hardserver before continuing the nCipherKM JCA/JCE CSP installation process. For more information, see the User Guide.
-
-
For Java 7 and 8 only. Copy the
nCipherKM.jar
file to the extensions folder of your local Java Virtual Machine installation from the following directory:-
%NFAST_HOME%\java\classes
(Windows) -
/opt/nfast/java/classes
(Linux)
The location of the extensions folder depends on the type of your local Java Virtual Machine (JVM) installation:
JVM type Extensions folder (Windows) Extensions folder (Linux) Java Developer Kit (JDK)
%JAVA_HOME%\jre\lib\ext
$JAVA_HOME/jre/lib/ext
Java Runtime Environment (JRE)
%JAVA_HOME%\lib\ext
$JAVA_HOME_/lib/ext
In these paths,
%JAVA_HOME%
(Windows) and$JAVA_HOME
(Linux) are the home directory of the Java installation (commonly specified in theJAVA_HOME
environment variable).If you are using Java11 you do not need to copy the jar file.
-
-
Add
%JAVA_HOME%\bin
(Windows) or$JAVA_HOME/bin
(Linux) to yourPATH
system variable. -
For Java 7 and 8 only. Install the unlimited strength JCE jurisdiction policy files that are appropriate to your version of Java. JDK 9 and later ship with, and use by default, the unlimited policy files.
The Java Virtual Machine imposes limits on the cryptographic strength that may be used by default with JCE providers. Replace the default policy configuration files with the unlimited strength policy files.
The Java Virtual Machine imposes limits on the cryptographic strength that may be used by default with JCE providers. Replace the default policy configuration files with unlimited strength policy files.
To install the unlimited strength JCE jurisdiction policy files:
-
If necessary, download the archive containing the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files from your Java Virtual Machine vendor’s Web site. Be sure to download a file appropriate for your version of Java.
The Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files are covered and controlled by U.S. Export Control laws and may be subject to the export or import laws in other countries. We recommend that you take legal advice before downloading these files from your Java Virtual Machine vendor. -
Extract the files
local_policy.jar
andUS_export_policy.jar
from Java Virtual Machine vendor’s Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy File archive. -
Copy the extracted files
local_policy.jar
andUS_export_policy.jar
into the security directory for your local Java Virtual Machine (JVM) installation:JVM type Extensions folder (Windows) Extensions folder (Linux) Java Developer Kit (JDK)
%JAVA_HOME%\jre\lib\security
$JAVA_HOME/jre/lib/security
Java Runtime Environment (JRE)
%JAVA_HOME%\lib\security
$JAVA_HOME_/lib/security
In these paths,
%JAVA_HOME%
(Windows) and$JAVA_HOME
(Linux) are the home directory of the Java installation (commonly specified in theJAVA_HOME
environment variable).Copying the files local_policy.jar
andUS_export_policy.jar
into the appropriate folder must overwrite any existing files with the same names.
-
-
Add the nCipherKM provider to the Java security configuration file
java.security
(located in the security directory for your local Java Virtual Machine (JVM) installation).The
java.security
file contains a list of providers in preference order that is used by the Java Virtual Machine to decide from which provider to request a mechanism instance. Ensure that the nCipherKM provider is registered in the first position in this list, as shown in the following example:# # List of providers and their preference orders (see above): # security.provider.1=com.ncipher.provider.km.nCipherKM security.provider.2=sun.security.provider.Sun security.provider.3=sun.security.rsa.SunRsaSign security.provider.4=com.sun.net.ssl.internal.ssl.Provider security.provider.5=com.sun.crypto.provider.SunJCE security.provider.6=sun.security.jgss.SunProvider security.provider.7=com.sun.security.sasl.Provider
For Java 11 you do not need to specify the fully qualified class name for the provider. Instead you can just use the provider name.
security.provider.1=nCipherKM
Placing the nCipherKM provider first in the list permits the nCipherKM provider’s algorithms to override the algorithms that would be implemented by any other providers (except in cases where you explicitly request another provider name).
The nCipherKM provider cannot serve requests required for the SSL classes unless it is in the first position in the list of providers. Do not change the relative order of the other providers in the list.
If you add the nCipherKM provider as security.provider.1
, ensure that the subsequent providers are re-numbered correctly. Ensure you do not list multiple providers with the same number (for example, ensure your list of providers does not include two instances ofsecurity.provider.1
, bothcom.ncipher.provider.km.nCipherKM
and another provider). -
Save your updates to the file
java.security
.When you have installed the nCipherKM JCA/JCE CSP, you must have created a Security World before you can test or use it. For more information about creating a Security World, see the User Guide.
If you have a Java Enterprise Edition Application Server running, you must restart it before the installed nCipherKM provider is loaded into the Application Server virtual machine and ready for use.
Testing the nCipherKM JCA/JCE CSP installation
After installation, you can test that the nCipherKM JCA/JCE CSP is functioning correctly by running the command.
For Java 7 and Java 8:
java com.ncipher.provider.InstallationTest
For Java 11 (Windows):
java --module-path %NFAST_HOME%\java\classes com.ncipher.provider.InstallationTest
For Java 11 (Linux):
java --module-path /opt/nfast/java/classes com.ncipher.provider.InstallationTest
For these commands to work, you must have added %JAVA_HOME% (Windows) or $JAVA_HOME (Linux) to your PATH system variable.
|
If the nCipherKM JCA/JCE CSP is functioning correctly, output from this command has the following form:
Installed providers:
1: nCipherKM
2: SUN
3: SunRsaSign
4: SunJSSE
5: SunJCE
6: SunJGSS
7: SunSASL
Unlimited strength jurisdiction files are installed.
The nCipher provider is correctly installed.
nCipher JCE services:
Alg.Alias.Cipher.1.2.840.113549.1.1.1
Alg.Alias.Cipher.1.2.840.113549.3.4
Alg.Alias.Cipher.AES
Alg.Alias.Cipher.DES3
....
If the nCipherKM
provider is installed but is not registered at the top of the providers list in the java.security
file, the InstallationTest
command produces output that includes the message:
The nCipher provider is installed, but is not registered at the top of the providers list in the java.security file.
See the user guide for more information about the recommended system configuration.
In such a case, edit the java.security
file (located in the security directory for your local JVM installation) so that the nCipherKM provider is registered in the first position in that file’s list of providers.
For more information about the java.security
file, see Installing the nCipherKM JCA/JCE CSP.
If the nCipherKM provider is not installed at all, or you have not created a Security World, or if you have not configured ports correctly in the hardserver configuration file, the InstallationTest
command produces output that includes the message:
The nCipher provider is not correctly installed.
In such case:
-
Check that you have configured ports correctly, as described in Installing the nCipherKM JCA/JCE CSP. For more information about hardserver configuration file settings, see the User Guide.
-
Check that you have created a Security World. If you have not created a Security World, create a Security World. For more information, see the User Guide.
-
If you have already created a Security World, repeat the nCipherKM JCA/JCE CSP installation process as described in Installing the nCipherKM JCA/JCE CSP.
After making any changes to the nCipherKM JCA/JCE CSP installation, run the InstallationTest
command again and check the output.
Whether or not the nCipherKM provider is correctly installed, if the unlimited strength jurisdiction files are not installed or (not correctly installed), the InstallationTest
command produces output that includes the message:
Unlimited strength jurisdiction files are NOT installed.
The InstallationTest command can only detect this situation if you are using JRE/JDK version 1.6 or later.
|
This message means that, because the Java Virtual Machine imposes limits on the cryptographic strength that you can use by default with JCE providers, you must replace the default policy configuration files with the unlimited strength policy files. For information about how to install the unlimited strength jurisdiction files, see Installing the nCipherKM JCA/JCE CSP.
Named Modules in Java 11
The nCipherKM Provider has been implemented as a named module. THis means that, for Java 11, if you have added the provider to your java.security
file, then you can run your application with the nCipherKM.jar
on the module-path and the Java ServiceLoader class will automatically find it, for example:
In Linux:
java --module-path /opt/nfast/java/classes com.ncipher.provider.InstallationTest
In Windows:
java --module-path %NFAST_HOME%\java\classes com.ncipher.provider.InstallationTest
Alternatively, you can specify the location of the nCipherKM jar on the classpath:
In Linux:
java --class-path /opt/nfast/java/classes/nCipherKM.jar com.ncipher.provider.InstallationTest
In Windows:
java --class-path %NFAST_HOME%\java\classes\nCipherKM.jar com.ncipher.provider.InstallationTest
System properties
You can use system properties to control the provider. You set system properties when starting the Java Virtual Machine using a command such as:
java -D<property>=<value> <MyJavaApplication>
In this example command, <property>
represents any system property, <value>
represents the value set for that property, and <MyJavaApplication>
is the name of the Java application you are starting.
You can set multiple system properties in a single command, for example:
java -Dprotect=module -DignorePassphrase=true MyJavaApplication
The available system properties and their functions as controlled by setting different values for a property are described in the following table:
Property | Function for different values |
---|---|
|
This property is a bit mask for which different values specify different debugging functions; the default value is |
|
This property specifies a path to the file to which logging output is to be written.
Set this property if the In a production environment, we recommend that you disable debug logging to prevent sensitive information being made available to an attacker. |
|
This property specifies the type of protection to be used for key generation and nCipherKM KeyStore instances.
You can set the value of this property to one of |
|
This property lets you override the default module and select a specific module to use for module and OCS protection. Set the value of this property as the ESN of the module you want to use. |
|
This property lets you override the default slot for OCS-protection and select a specific slot to use. Set this the value of this property as the number of the slot you want to use. |
|
If the value of this property is set to |
|
Setting the value of this property to the name of an SEE integrity key causes the provider to generate SEE application keys. These keys may only be used by an SEE application signed with the named key. |
|
The default value for this property is |
|
For the value of this property, you supply a comma-separated list of mechanism names that are to be forced on, regardless of the announce mode selected. |
|
For the value of this property, you supply a comma-separated list of mechanism names that are to be forced off, regardless of the announce mode selected.
Any mechanism supplied in the value for the |
JCECSP_DEBUG property values
The JCECSP_DEBUG
system property is a bit mask for which you can set different values to control the debugging functions.
The following table describes the effects of different values that you can set for this property:
JCECSP_DEBUG value |
Function |
---|---|
|
If this property has no bits set, no debugging information is reported. This is the default setting. |
|
If this property has the bit 1 set, minimal debugging information (for example, version information and critical errors) is reported. |
|
If this property has the bit 2 set, comprehensive debugging information is reported. |
|
If this property has the bit 3 set, debugging information relating to creation and destruction of memory and module resources is reported. |
|
If this property has the bit 4 set, |
|
If this property has the bit 5 set, |
|
If this property has the bit 6 set, context information is reported with each debugging message (for example, the |
|
If this property has the bit 7 set, the time elapsed during each logged function is calculated, and information on the number of times a function is called and by which function it was called is reported. |
|
If this property has the bit 8 set, debugging information for NFJAVA is reported in the debugging file. |
|
If this property has the bit 9 set, the call stack is printed for every debug message. |
To set multiple logging functions, add up the JCECSP_DEBUG
values for the debugging functions you want to set, and specify the total as the value for JCECSP_DEBUG
. For example, if you want to set the debugging to use both function tracing (bit 4) and function tracing with parameters (bit 5), add the JCECSP_DEBUG
values shown in the table for these debugging functions (8
+ 16
= 24) and specify this total (24
) as the value to use for JCECSP_DEBUG
.
Compatibility
The nCipherKM JCA/JCE CSP supports both module-protected keys and OCS-protected keys. The CSP currently supports 1/N OCSs and a single protection type for each nCipherKM JCE KeyStore.
You can use the nCipherKM JCA/JCE CSP with Security Worlds that comply with FIPS 140‑2 at either Level 2 or Level 3.
In a Security World that complies with FIPS 140-2 Level 3, it is not possible to import keys generated by other JCE providers. |
The nCipherKM JCA/JCE CSP supports load-sharing for keys that are stored in the nCipherKM KeyStore. This feature allows a server to spread the load of cryptographic operations across multiple connected modules, providing greater scalability.
We recommend that you use load-sharing unless you have existing code that is designed to run with multiple modules. To share keys with load-sharing, you must create a 1/N OCS with at least as many cards as you have modules. All the cards in the OCS must have the same passphrase. |
Keys generated or imported by the nCipherKM JCA/JCE CSP are not recorded into the Security World until:
-
The key is added to an nCipherKM KeyStore (by using a call to
setKeyEntry()
orsetCertificateEntry()
). -
That nCipherKM KeyStore is then stored (by using a call to
store()
).
The passphrase used with the KeyStore must be the passphrase of the card from the OCS that protects the keys in the KeyStore.
Architecture
The nCipherKM JCA/JCE CSP implements its functionality using two underlying nShield APIs:
-
the KM Java library (
kmjava
) -
the Java Generic Stub (
nfjava
).
These libraries relay commands generated by the JCE provider to the underlying hardserver and modules.
Available functions
The module firmware automatically detects which algorithms it can support. These algorithms are advertised when the provider first starts up. The provider conservatively advertises only those mechanisms that are supported by all installed modules in the system.
Certain algorithms are not supported by older versions of firmware. We recommend that you ensure that your module is upgraded to the most recent version of firmware appropriate for your environment. |
The following table indicates the cipher modes available for each cipher.
Cipher | CBC | CFB | CTR | ECB | OFB | GCM |
---|---|---|---|---|---|---|
AESWrap |
X |
|||||
ArcFour |
||||||
CAST256 |
X |
X |
X |
X |
X |
|
DES2 |
X |
X |
X |
X |
X |
|
DES |
X |
X |
X |
X |
X |
|
DESede |
X |
X |
X |
X |
X |
|
DESedeWrap |
X |
|||||
ECIES1 |
||||||
Rijndael |
X |
X |
X |
X |
X |
X |
RSA |
X |
In the table above, annotations with the following numbers indicate:
1 These ciphers support key wrap and unwrap only.
The following table indicates the padding types available for each cipher.
Cipher | ANSI X9.23 | ISO 10126 | ISO 7816 | None | OAEP | PKCS #1 | PKCS #5 | Zero byte |
---|---|---|---|---|---|---|---|---|
AESWrap |
X |
|||||||
ArcFour |
||||||||
CAST256 |
X |
X |
X |
X |
X |
X |
||
DES2 |
X |
X |
X |
X |
X |
X |
||
DES |
X |
X |
X |
X |
X |
X |
||
DESede |
X |
X |
X |
X |
X |
X |
||
DESedeWrap |
X |
|||||||
ECIES1 |
||||||||
Rijndael |
X |
X |
X |
X |
X |
X |
||
RSA |
X |
X |
In the table above, annotations with the following numbers indicate:
1 These ciphers support key wrap and unwrap only.
Algorithm | Key length in bits for generation or signing | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
AESWrap |
Y |
||||||||||
Arcfour |
8, 16 to 2048 |
Y1 |
Y1 |
||||||||
CAST256 |
128, 192, 256 |
Y1 |
Y1 |
||||||||
DES |
64 |
Y1 |
Y1 |
||||||||
DESede |
192 |
Y |
Y |
||||||||
DES2 |
128 |
Y |
Y |
||||||||
DESedeWrap |
Y |
||||||||||
DH |
Y |
Y |
Y |
||||||||
DSA |
1024 |
Y |
Y |
||||||||
ECDH |
Y |
Y |
Y |
||||||||
ECDHwithSHA1KDF |
Y |
||||||||||
ECDHwithSHA224KDF |
Y |
||||||||||
ECDHwithSHA256KDF |
Y |
||||||||||
ECDHwithSHA384KDF |
Y |
||||||||||
ECDHwithSHA512KDF |
Y |
||||||||||
ECDSA |
Y |
Y |
|||||||||
EdDSA |
256 |
Y1 |
Y1 |
||||||||
Ed25519 |
256 |
Y1 |
Y1 |
||||||||
Ed25519ph |
Y1 |
||||||||||
HmacMD5 |
Y1 |
Y1 |
|||||||||
HmacRIPEMD160 |
8, 16 to 2048 |
Y1 |
Y1 |
||||||||
HmacSHA1 |
8, 16 to 2048 |
Y |
Y |
||||||||
HmacSHA224 |
8, 16 to 2048 |
Y |
Y |
||||||||
HmacSHA256 |
8, 16 to 2048 |
Y |
Y |
||||||||
HmacSHA384 |
8, 16 to 2048 |
Y |
Y |
||||||||
HmacSHA512 |
8, 16 to 2048 |
Y |
Y |
||||||||
HmacTiger |
8, 16 to 2048 |
Y1 |
Y1 |
||||||||
MD5 |
Y1 |
||||||||||
MD5andSHA1withRSA |
Y |
||||||||||
MD5withRSA |
Y |
||||||||||
nCipher.sworld |
Y |
||||||||||
Rijndael |
Y |
Y |
|||||||||
RawRSA |
Y |
||||||||||
RIPEMD160 |
Y1 |
||||||||||
RIPEMD160withRSA |
Y1 |
||||||||||
RIPEMD160withRSAandMGF1 |
322+ |
Y1 |
|||||||||
RNG |
Y |
||||||||||
RSA |
512+ |
Y |
Y |
Y |
|||||||
SHA1 |
Y |
||||||||||
SHA1withDSA |
Y |
||||||||||
SHA1withECDSA |
Y |
||||||||||
SHA1withRSA |
Y |
||||||||||
SHA1withRSAandMGF1 |
322+ |
Y |
|||||||||
SHA224 |
Y |
||||||||||
SHA224withDSA |
Y |
||||||||||
SHA224withECDSA |
Y |
||||||||||
SHA224withRSA |
Y |
||||||||||
SHA224withRSAandMGF1 |
450+ |
Y |
|||||||||
SHA256 |
Y |
||||||||||
SHA256withDSA |
Y |
||||||||||
SHA256withECDSA |
Y |
||||||||||
SHA256withRSA |
Y |
||||||||||
SHA256withRSAandMGF1 |
514+ |
Y |
|||||||||
SHA384 |
Y |
||||||||||
SHA384withDSA |
Y |
||||||||||
SHA384withECDSA |
Y |
||||||||||
SHA384withRSA |
Y |
||||||||||
SHA384withRSAandMGF1 |
770+ |
Y |
|||||||||
SHA512 |
Y |
||||||||||
SHA512withDSA |
Y |
||||||||||
SHA512withECDSA |
Y |
||||||||||
SHA512withRSA |
Y |
||||||||||
SHA512withRSAand MGF1 |
1026+ |
Y |
|||||||||
Tiger |
8, 16 to 256 |
Y |
Y |
Y1 |
In the table above, annotations with the following numbers indicate:
1 These algorithms are not supported in FIPS 140-2 Level 3 Security Worlds.
The KeyStore API
You can load and store nShield module-protected keys by using the standard KeyStore API.
This interface allows access to a KeyStore data file by means of a passphrase and an InputStream
or OutputStream
.
nShield KeyStore data files contain only the name-space identifier of the keys stored in them; the actual keys are stored in the Security World regardless of the stream used.
The name-space identifier is the hash of the root key of the individual KeyStore.
The ident
of the KeyStore keys in the Security World begins with this hash and is followed by key-specific characters.
This naming hierarchy allows you to identify the relevant key in Security World tools (such as KeySafe) and remove keys from a KeyStore.
To use an existing KeyStore on another machine in the same Security World, copy both its KeyStore data file and the Security World’s Key Management Data directory to the other machine. |
Initialization
You create a new KeyStore by passing a null InputStream
to the KeyStore load method.
When you create a new KeyStore, the nCipherKM provider generates a KeyStore key that is used to sign trusted public certificate entries.
The relevant signature is verified when public certificates in the KeyStore are used; this functionality prevents an attacker inserting new certificates into a KeyStore without the protection token that is needed to use the KeyStore key.
By default, the KeyStore protection key is OCS-protected.
Ensure that the passphrase argument used with the KeyStore interface matches the passphrase of that OCS.
When the KeyStore method is called, you must present a card with a matching passphrase from the required OCS.
You can use the protect
system property to change the protection type used for the KeyStore key; for more information about the protect
property, see System properties.
An existing KeyStore file is not overwritten if the KeyStore store method is called on an OutputStream
directed at the same file path.
Instead, the KeyStore at the existing path is used to store the keys in the new KeyStore.
This operation fails if the passphrases for the two KeyStores do not match.
Loading and storing keys
We recommend that separate KeyStores are used for separate purposes; for example, you can use one KeyStore to hold private keys and a different KeyStore for Certifying Authorities. With this approach, you need separate OCSs to operate separate KeyStores. However, you can also use different OCSs to protect keys within the same KeyStore.
You require a certificate chain to store private keys. The Virtual Machine JCE implementation enforces this requirement, not the nCipherKM provider.
keytool
You can use either the Oracle keytool
utility or the IBM keytool
utility to read and edit an nShield KeyStore.
These utilities are shipped with the Oracle and IBM JVMs.
You must specify the correct nCipher.sworld
KeyStore type when you run the keytool
utility, and you must specify the correct package name for the Oracle or IBM keytool
utility.
To generate a new key in an OCS-protected KeyStore with the Oracle or IBM keytool
utility, run the appropriate command:
-
Sun Microsystems
keytool
utility:For Java 11, use the following command:
java --module-path /opt/nfast/java/classes sun.security.tools.keytool.Main -genkey - storetype nCipher.sworld -keyalg RSA -sigalg SHA1withRSA -storepass <KeyStore_passphrase> -keystore <KeyStore_path>
For Java 8, use the following command:
java sun.security.tools.keytool.Main -genkey -storetype nCipher.sworld -keyalg RSA - sigalg SHA1withRSA -storepass <KeyStore_passphrase> -keystore <KeyStore_path>
For Java 7, use the following command:
java sun.security.tools.KeyTool -genkey -storetype nCipher.sworld -keyalg RSA - sigalg SHA1withRSA -storepass <KeyStore_passphrase> -keystore <KeyStore_path>
-
IBM keytool utility:
java com.ibm.crypto.tools.KeyTool -genkey -storetype nCipher.sworld -keyalg RSA - sigalg SHA1withRSA -storepass <KeyStore_passphrase> -keystore <KeyStore_path>
In these example commands, <KeyStore_passphrase>
is the passphrase for the OCS that protects the KeyStore and <KeyStore_path>
is the path to that KeyStore.
To generate a new key in a module-protected KeyStore with the Oracle or IBM keytool
utility, run the appropriate command:
-
Sun Microsystems
keytool
utility:For Java 11, use the following command:
java --module-path /opt/nfast/java/classes -Dprotect=module -DignorePassphrase=true sun.security.tools.keytool.Main -genkey -storetype nCipher.sworld -keyalg RSA - sigalg SHA1withRSA -keystore <KeyStore_path>
For Java 8, use the following command:
java -Dprotect=module -DignorePassphrase=true sun.security.tools.keytool.Main - genkey -storetype nCipher.sworld -keyalg RSA -sigalg SHA1withRSA -keystore <KeyStore_path>
For Java 7, use the following command:
java -Dprotect=module -DignorePassphrase=true sun.security.tools.KeyTool -genkey - storetype nCipher.sworld -keyalg RSA -sigalg SHA1withRSA -keystore <KeyStore_path>
-
IBM
keytool
utility:java -Dprotect=module -DignorePassphrase=true com.ibm.crypto.tools.KeyTool -genkey - storetype nCipher.sworld -keyalg RSA -sigalg SHA1withRSA -keystore <KeyStore_path>
In these example commands, <KeyStore_path>
is the path to the KeyStore.
By default, the keytool
utilities use the MD5withRSA
signature algorithm to sign certificates used with a KeyStore.
This signature mechanism is unavailable on modules with firmware version 2.33.60 or later.
Using keys
Only the nCipherKM provider can use keys stored in an nShield KeyStore because the underlying key material is held separately in the Security World.
You can always store nShield keys in an nShield KeyStore. You can also store keys generated by a third-party provider into an nShield KeyStore if both of the following conditions apply:
-
the key type is known to the nCipherKM provider
-
the Security World is not compliant with FIPS 140-2 Level 3.
When you generate an nShield key (or create it from imported key material), that key is associated with an ACL (Access Control List). This ACL prevents the key from being used for operations for which it is unsuited and enforces requirements that certain tokens be presented; for example, the ACL can specify that signing key cannot be used for encryption.