Security

Once this is done, you must set up openCryptoki by rerunning pkcs11_startup to discover the CCA library. Once the slot containing the CCA token is located, set its SO pin, user pin and label. Finally, you will need to modify the configuration file of the IBMPKCS11Impl provider to refer to the slot that contains the CCA token.

If the sample program is rerun, the AES functions from the CCA library are used, resulting in requests to the Crypto Express coprocessor. Issuing the lszcrypt command with the verbose option (-VV) will verify that requests are issued by the Java program and serviced by the crypto hardware.

Instead of using CCA via the standard JCA/JCE interface, you could use the Java Native Interface (JNI) that comes with CCA. This proprietary IBM interface provides a Java API to the CCA functions needed by many financial institutions. An introduction on how to use this interface can be found in the article “Secure Key Cryptography,” which appeared in the June/July 2008 issue of z/Journal (available at http://esmpubs.com/a0yf6).

Explicit Provider Selection
So far, the JCA has selected the best provider based on the priority defined for the providers in the java.security file. Alternatively, a programmer can specify a specific provider for all objects JCA providers implement. To do this, you must add the provider name as an argument to the getInstance() method in the program. For the IBMPKCS11Impl provider, the optional provider argument starts with the string, “IBMPKCS11Impl-” followed by the name attribute from the IBMPKCS11Impl configuration file. For the earlier example, a call to Cipher.getInstance() with explicit provider specification would look like:

aesCipher=Cipher.getInstance(“AES/ECB/NoPadding”,”IBMPKCS11Impl-Sample”);
Now the getInstance() method will always use the implementation provided by the IBMPKCS11Impl provider—using the token in the slot defined in the configuration file specified in java.security.

Using Persistent Objects in openCryptoki Tokens
Some applications require storing persistent objects (e.g., keys) in cryptographic tokens. A user pin is used to secure these objects from unauthorized use. This pin is chosen during openCryptoki token initialization. A Java program that needs to access a persistent token must log-in to the token (see Figure 6). The nullprompter function used appears on developerWorks at www.ibm.com/developerworks/java/jdk/security/60/secguides/pkcs11implDocs/IBMJavaPKCS11/ImplementationProvider.html.

If the token stores objects persistently, existing software using a software provider for the JCE API may not simply be reconfigured to use the IBMPKCS11Imp provider. The program may need some small code changes to allow a pin to be entered with a log-in to the token.

 

Conclusion
The Java Cryptography Architecture provides a flexible framework to support multiple implementations of cryptographic algorithms. This framework lets you plug in a PKCS#11 API to access hardware cryptographic implementations. You can then use a simple program to configure Java to access System z cryptographic hardware via the IBMPKCS11Impl provider and openCryptoki. Once the Java code accesses openCryptoki using either clear key or secure key cryptography, it’s a simple matter of redirecting IBMPKCS11Impl request to a specific slot. This will bring the speed and offloading advantages of hardware cryptography to the world of Java applications.

5 Pages