Workload description

Edit online

The workload and the steps needed to run the workload for the JSSE study are described in detail.

The workload consists of Java™ programs (classes) that are invoked on the JSSE client and JSSE server IBM® System z® LPAR. Different programs are invoked, depending on whether hardware or software encryption is requested by the test program. For hardware encryption, the hardware provider com.ibm.crypto.pkcs11impl.provider.IBMPKCS11Impl and its associated functions are invoked. The IBMJSSE2 provider is also used. For software encryption, only the IBMJSSE2 provider is used.

After the providers are established, other parameters are processed to establish an SSL session between the JSSE client and server. The keystore name and password are passed into the program for both hardware and software encryption. For hardware encryption, different keystores and certificates are used than for software encryption. For software encryption, the previously created self-signed JKS certificate from the keystore, named testkeys.jks, is used. See Define a keystore for software encryption using the iKeyman utility.

For hardware encryption, the PKCS11 configuration file is specified, which provides the placeholder keystore name /usr/lib/pkcs11/PKCS11_API.so64. The provider understands that this library is only a placeholder for the hardware-based keystore. The passwords submitted are the same passwords established using the iKeyman utility for the hardware or software keystores. See Define a keystore for hardware encryption using the iKeyman utility.

The test programs start 20 client threads on the client. Each thread establishes an SSL session with the server. An SSL handshake is performed and the session or connection is established. Data of varying byte lengths is written to input socket streams by the client and then returned bytes are read back from the server. Except in the case of cached connections, the session is invalidated and the process is repeated beginning with a new SSL handshake and a new exchange of data.

Each of the twenty client threads runs for a designated time period. Thus, the speed and efficiency of running with hardware or software encryption can be measured by how many connections and data exchanges are made within that time period. A high-speed network using HiperSockets™ is used so that performance is not impacted by network latency.

The performance of these two operations is analyzed in the JSSE study:
  • The SSL handshakes when running with hardware encryption are performed on the IBM Crypto Express2 feature. While the data exchanged is encrypted with symmetric keys, the communication with the negotiation of the symmetric keys is then encrypted with asymmetric keys. The key generation and exchange is a high-CPU load operation that takes place during the SSL handshake. This operation runs on the IBM Crypto Express2 feature when hardware encryption is requested.
  • The data encryption with symmetric keys takes place as the data is sent to and read from the input and output buffers for the open socket. When hardware encryption is requested and the cipher used is supported, the data is encrypted and decrypted by the Central Processor Assist for Cryptographic Function (CPACF). Hashing of data is also performed by the CPACF.

Thus, the performance characteristics of hardware encryption are affected by two different devices or functions, the IBM Crypto Express2 feature and the CPACF.