OCKC utilizes OpenSSL as its foundational library for performing underlying cryptographic operations on all supported platforms, including z/OS, thereby benefiting from the extensive capabilities and optimizations that OpenSSL offers. By integrating OpenSSL, OCKC can access a wide range of well-established cryptographic algorithms, including symmetric and asymmetric encryption, hashing functions, and digital signatures, all critical for secure data processing. This integration allows OCKC to leverage OpenSSL's performance enhancements and security features, ensuring that cryptographic operations are executed efficiently and reliably. When OpenJCEPlus connects to OCKC through its native layer, it indirectly taps into OpenSSL's robust implementation, enabling high-performance cryptographic functions essential for enterprise applications. This layered approach enhances the overall security posture of applications using OpenJCEPlus and ensures compliance with industry standards, as OpenSSL is widely recognized and trusted in the cryptographic community.
OCKC on z/OS and zLinux takes advantage of the Central Processor Assist for Cryptographic Function (CPACF) [8] hardware acceleration features to enhance the performance of certain cryptographic algorithms, particularly Advanced Encryption Standard (AES). CPACF is a specialized hardware component designed to offload cryptographic processing from the main CPU, allowing for faster execution of encryption and decryption operations. When OCKC is invoked to perform AES operations, it can leverage CPACF to execute these tasks more efficiently, significantly reducing the time required for processing large volumes of data. This hardware acceleration not only improves throughput but also optimizes resource utilization on the z/OS platform, enabling applications to handle cryptographic workloads with greater speed and efficiency. By integrating CPACF capabilities, OCKC ensures that organizations can achieve high levels of security without compromising performance, making it an ideal choice for enterprise environments that demand robust encryption and rapid processing times.
OpenJCEPlus is included by default in the IBM Semeru Runtime Certified Edition and the IBM Semeru Runtime Open Edition for various platforms. This integration allows developers to leverage enhanced cryptographic functionalities seamlessly within their applications. To utilize OpenJCEPlus as the primary cryptographic provider, users can modify the java.security file, typically located in the JDK's conf/security directory. By adding OpenJCEPlus as the first provider in the list of security providers within this file, developers can ensure that their applications prioritize the cryptographic algorithms and features offered by OpenJCEPlus, thereby enhancing security and performance in cryptographic operations.
OpenJCEPlus is the default and first security provider in the JDK java.security file on z/OS for the IBM Semeru Runtime Certified Edition 11+, which is as follows:
#
# List of providers and their preference orders in java.security file:
#
security.provider.1=OpenJCEPlus
security.provider.2=IBMZSecurity
security.provider.3=SUN
security.provider.4=SunRsaSign
security.provider.5=SunEC
security.provider.6=SunJSSE
security.provider.7=SunJCE
security.provider.8=SunJGSS
security.provider.9=SunSASL
security.provider.10=XMLDSig
security.provider.11=SunPCSC
security.provider.12=JdkLDAP
security.provider.13=JdkSASL
security.provider.14=SunPKCS11
Another way to install the OpenJCEPlus provider is through Java code, which offers a programmatic approach to adding the provider at runtime. This can be accomplished using the Security.insertProviderAt() and Security.addProvider() methods. By invoking this method and passing an instance of the OpenJCEPlus provider, developers can dynamically register it as a security provider during the execution of their application. This approach is useful for applications that require flexibility in managing security providers or for those that may not have access to modify java.security file. By adding OpenJCEPlus programmatically, developers can ensure that their applications utilize cryptographic capabilities without altering the underlying configuration files. The following code snippet shows how to insert OpenJCEPlus as the first provider.
// Insert OpenJCEPlus as the first provider
Security.removeProvider("OpenJCEPlus");
Security.insertProviderAt(new com.ibm.crypto.plus.provider.OpenJCEPlus(), 1);
Users of z/OS can also configure java.security file to utilize the IBMJCEHYBRID [9] as a failover provider and IBMJCECCA [10] as a hardware-based security provider in conjunction with OpenJCEPlus as a software-based security provider to access both software and hardware-based cryptographic operations with built-in failover capabilities. This configuration ensures reliable and robust security solutions, enabling seamless transitions between different cryptographic implementations while maintaining high availability and performance for sensitive operations.
#
# List of providers and their preference orders in java.security file on z/OS:
#
security.provider.1=IBMJCEHYBRID
security.provider.2=IBMJCECCA
security.provider.3=IBMZSecurity
security.provider.4=OpenJCEPlus
security.provider.5=SUN
security.provider.6=SunRsaSign
security.provider.7=SunEC
security.provider.8=SunJSSE
security.provider.9=SunJCE
security.provider.10=SunJGSS
security.provider.11=SunSASL
security.provider.12=XMLDSig
security.provider.13=SunPCSC
security.provider.14=JdkLDAP
security.provider.15=JdkSASL
security.provider.16=SunPKCS11
4. Performance
To evaluate performance, we conducted a comparative analysis of OpenJCEPlus against IBMJCECCA in Java 17.0.16.0 and IBMJCE in Java 8.0.8.50 on z/OS. This comparison focused on the AES cipher in Galois/Counter Mode (AES-GCM) and ECDSA signature (SHA256withECDSA-secp256r1) algorithms. By assessing the efficiency and speed of these implementations, we aimed to provide insights into the performance characteristics under various encryption, signing, and verification scenarios for each cryptographic provider in different Java versions. To run the methods for each provider, the provider must be installed as the first provider, as described in the previous section, to be picked as the default provider for all the required crypto operations.
We used the following methods to run the AES/GCM encryption, ECDSA sign, and verify operations:
private static void encryptAesGcm(int iteration, int payloadSize) throws Exception {
SecureRandom random = new SecureRandom();
// Create the AES cipher in GCM mode
Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
// Generate random plaintext data
byte[] plainData = new byte[payloadSize];
random.nextBytes(plainData);
// Generate a random initialization vector (IV)
byte[] iv = new byte[16];
random.nextBytes(iv);
// Create Secret Key
SecretKeySpec keySpec = new SecretKeySpec(new byte[16], "AES");
// Encrypt data
for (int i = 0; i < iteration; i++) {
// Modify IV for each iteration
byte temp = iv[1];
iv[1] = iv[0];
iv[0] = temp;
// Initialize the cipher for encryption
cipher.init(Cipher.ENCRYPT_MODE, keySpec, new GCMParameterSpec(128, iv));
// Perform encryption
cipher.doFinal(plainData);
}
}
private static void signEcDsa(int iteration, int payloadSize) throws Exception {
SecureRandom random = new SecureRandom();
// Generate EC key pair
KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance("EC");
keyPairGenerator.initialize(new ECGenParameterSpec("secp256r1"));
KeyPair keyPair = keyPairGenerator.generateKeyPair();
// Generate random plaintext data
byte[] data = new byte[payloadSize];
random.nextBytes(data);
// Create signature instance
Signature signature = Signature.getInstance("SHA256withECDSA");
// Initialize the signature object for signing
signature.initSign(keyPair.getPrivate());
// Update the signature object with the original data for signing
for (int i = 0; i < iteration; i++) {
signature.update(data); // Update with data for each iteration
signature.sign();
}
}
private static void verifyEcDsa(int iteration, int payloadSize) throws Exception {
SecureRandom random = new SecureRandom();
// Generate EC key pair
KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance("EC");
keyPairGenerator.initialize(new ECGenParameterSpec("secp256r1"));
KeyPair keyPair = keyPairGenerator.generateKeyPair();
// Generate random plaintext data
byte[] data = new byte[payloadSize];
random.nextBytes(data);
// Create signature instance
Signature signature = Signature.getInstance("SHA256withECDSA");
// Sign the data
signature.initSign(keyPair.getPrivate());
signature.update(data);
byte[] sigBytes = signature.sign();
// Verify the signature
signature.initVerify(keyPair.getPublic());
// Update the signature object with the original data for verification
for (int i = 0; i < iteration; i++) {
signature.update(data); // Update with data for each iteration
signature.verify(sigBytes);
}
}
Figure 2 shows the performance results for AES/GCM/NoPadding encryption, evaluated over 1 million iterations using a 128-bit key on the z/OS s390x platform. At a payload size of 32 bytes, OpenJCEPlus achieved the fastest time of 1080 ms, representing an improvement of approximately 21.2% compared to IBMJCE at 1370 ms and about 6.1% faster than IBMJCECCA at 1150 ms. For a payload size of 128 bytes, OpenJCEPlus performed admirably with a time of 1090 ms, showing a 21.5% improvement over IBMJCE at 1390 ms and 7.6% faster than IBMJCECCA at 1180 ms. When evaluating the 512-byte payload, OpenJCEPlus recorded 1100 ms, indicating a 22.3% enhancement over IBMJCE at 1415 ms and approximately 8.7% quicker than IBMJCECCA at 1205 ms. Overall, these results suggest that utilizing the newer Java version (17+) enhances performance, particularly with OpenJCEPlus, which consistently outperformed the other options across all tested payload sizes.
Considering the geometric mean of 1386.22 for IBMJCE, 1185.45 for IBMJCECCA, and 1094.25 for OpenJCEPlus over different payload sizes, OpenJCEPlus delivers approximately 21.1% faster average throughput for AES/GCM encryption compared to IBMJCE and around 7.7% faster compared to IBMJCECCA.
Figure 3 shows the performance comparison of SHA256WithECDSA Sign, executed over 10,000 iterations on z/OS s390x. For a 32B payload, IBMJCE took 7525 ms, while IBMJCECCA performed marginally better at 5706 ms with a 24.36% improvement. However, OpenJCEPlus excelled with an extraordinary time of 304 ms, demonstrating a remarkable 95.95% improvement compared to IBMJCE. In the 128B category, IBMJCE again lagged at 7450 ms, while IBMJCECCA achieved 5672 ms, marking a 23.83% improvement. OpenJCEPlus continued its leading performance at just 301 ms, representing a 95.96% improvement over IBMJCE. Similar trends were observed with the 512B payload, where IBMJCE took 7290 ms, and IBMJCECCA improved slightly to 5695 ms at 21.79% better performance. Once more, OpenJCEPlus dominated with 302 ms, resulting in a 95.86% improvement over IBMJCE. Overall, OpenJCEPlus showcased exceptional efficiency across all payload sizes, underscoring its superiority in cryptographic operations compared to both IBMJCE and IBMJCECCA.
Considering the geometric mean of 7425.65 for IBMJCE, 5691.60 for IBMJCECCA, and 302.00 for OpenJCEPlus over different payload sizes, OpenJCEPlus delivers approximately 95.9% faster average throughput for ECDSA sign compared to IBMJCE and around 94.7% faster compared to IBMJCECCA.
Figure 4 shows the performance comparison of SHA256WithECDSA Verify, executed over 10,000 iterations on z/OS s390x. For a 32B payload, OpenJCEPlus completed the verification in 622 ms, which is approximately 6.6% faster than IBMJCECCA's 670 ms and 95.1% faster than IBMJCE's 12650 ms. In the 128B category, OpenJCEPlus maintained its leading position with a time of 620 ms, making it 6.7% faster than IBMJCECCA's 664 ms and 95.1% faster than IBMJCE's 12680 ms. Similarly, for a 512B payload, OpenJCEPlus clocked in at 624 ms, outperforming IBMJCECCA by about 6.6% and IBMJCE by an impressive 95.2%.
Considering the geometric mean of 12660.9 for IBMJCE, 667.7 for IBMJCECCA, and 622.2 for OpenJCEPlus over different payload sizes, OpenJCEPlus delivers approximately 95.1% faster average throughput for ECDSA verify compared to IBMJCE and around 6.8% faster compared to IBMJCECCA.