Java

Java

Java

Topics on Semeru (Java) on IBM Z

 View Only

Accelerating Cryptographic Performance: How IBM Semeru Runtimes Harness CPACF on IBM Z

By Farshad Rahimi Asl posted Sun January 25, 2026 04:50 AM

  

1. CPACF: A Technical Overview

Pervasive encryption is no longer an optional luxury but a core standard for enterprise data protection. On the z/OS and Linux on IBM Z, this is typically achieved through the CP Assist for Cryptographic Function (CPACF).

CPACF is a set of hardware-integrated cryptographic instructions (part of the Message Security Assist facility) designed to provide extreme performance for symmetric encryption and hashing. Unlike adapter-based Hardware Security Modules (HSMs) such as Crypto Express cards, CPACF is an on-chip facility integrated directly into every central processor (CP) core, eliminating the latency associated with transferring data to an external card, improving performance vs software-based implementations.[1]

Tracing the path from hardware to application, this blog explores the evolution and architecture of CPACF, detailing how it integrates with foundational components like OpenSSL to provide hardware acceleration for Semeru Runtimes on z/OS and Linux on IBM Z. Availability of CPACF in other OpenJDK distributions is also explored.

1.1. Platform Availability

CPACF is a core cryptographic component available across z/OS and Linux on IBM Z. Starting with the IBM z9 and continuing through newer generations, the CPACF hardware is integrated directly into the CP core of every IBM Z. [2] Because it is a standard feature on all engine types, including CPs, IFLs, and zIIPs, its throughput scales linearly as more processors are added to a configuration. While non-reversible functions like SHA hashes (SHA-1/2/3) are generally enabled by default, high-performance symmetric encryption (such as AES and DES) requires the activation of the no-charge feature code #3863 via the Support Element (SE) to comply with export regulations. [1] [3] [4]

1.2. Evolution

CPACF has evolved through the Message Security Assist (MSA) facility extensions across multiple IBM Z generations. MSA is the formal name for the cryptographic facility within the IBM Z. While CPACF is the physical hardware unit on the chip, MSA is the architectural definition, essentially the “rulebook”, that specifies the instructions the applications use to talk to that hardware. [3] [4] [5] Table A in the Appendix outlines the history of CPACF evolution on the IBM Z platform.

1.3. CPACF Instructions

CPACF instructions are categorized under the MSA facility in the IBM Z platform. While there are a handful of core instructions (like the ones we discussed), each instruction uses a Function Code to determine which specific algorithm (like AES-256 vs. SHA-512) to execute.

The CPACF instructions listed in Table B in the Appendix are native CPU mnemonics that execute synchronously, providing low-latency and predictable cryptographic operations without offload to external hardware. [6]

2. Harnessing CPACF in IBM Semeru Runtimes

Java applications on z/OS and Linux on IBM Z can leverage CPACF in Semeru Runtime through three primary security providers, OpenJCEPlus, SunJCE, and IBMJCECCA, each tailored to different performance and security requirements using OpenSSL and ICSF. Semeru Runtimes are available to download through IBM Semeru Runtime Certified Edition [7] and IBM Semeru Runtime Open Edition [8] for various platforms.

2.1. OpenJCEPlus

OpenJCEPlus serves as the premier cryptographic provider for modern Java applications running on IBM Semeru Runtime 11 and later (including Java 17, 21, and 25). Engineered specifically for high-performance, clear-key operations on z/OS and Linux on IBM Z, it facilitates a specialized execution chain where the Java layer calls OpenJCEPlus, which interfaces via JNI with the Open Crypto Kit for C (OCKC), the open-source successor to the IBM Crypto for C (ICC) library used in Java 21 and older. OCKC leverages OpenSSL as its cryptographic engine to directly access the underlying CPACF hardware instructions. For key algorithms such as AES and SHA, OCKC interfaces directly with the CPACF hardware, significantly shortening the call path. As the default provider in Semeru Runtimes, OpenJCEPlus ensures that enterprise workloads, from standard TLS handshakes to bulk data encryption, benefit from hardware acceleration "out of the box." By leveraging the CPU's synchronous instructions, it minimizes latency and frees up processor cycles for core application logic, making it ideal for high-volume transaction environments, such as CICS or WebSphere. Figure 1 shows the OpenJCEPlus architecture. OpenJCEPlus is included with the IBM Semeru Runtime Certified Edition and the IBM Semeru Runtime Open Edition for various platforms. [9] [10]

Figure 1. OpenJCEPlus Architecture

Figure 1. OpenJCEPlus Architecture

2.2. SunJCE

The SunJCE provider in IBM Semeru Open Edition on Linux on IBM Z acts as a high-performance bridge, routing cryptographic operations through OpenSSL to reach the underlying CPACF hardware. Instead of executing the encryption logic in pure Java, the JVM utilizes native wrappers, such as AES/GCM, to call OpenSSL's native EVP APIs via the Java Native Interface (JNI). OpenSSL then serves as the critical intermediary, employing platform-specific assembly code to trigger the CPACF instructions directly on the IBM Z processor. This architecture ensures that Java applications benefit from the same industrial-strength encryption speeds and hardware-level security as native C applications, seamlessly transparent to the developer. Table C in the Appendix shows native cryptographic acceleration control properties. [11]

As mentioned in Sections 2.1 and 2.2, on z/OS and Linux on IBM Z, OpenSSL serves as the gateway for OpenJCEPlus (indirectly through the OCKC) and SunJCE security providers to exploit CPACF through clear-key encryption. Modern versions of OpenSSL (1.1.1 and later) provide implicit acceleration, automatically detecting the underlying hardware and utilizing CPACF for symmetric ciphers such as AES and hash functions like SHA-256 without requiring complex configuration. This integration offers a significant architectural advantage; by utilizing the CPU's synchronous instructions, such as KM (Cipher Message), KMC (Cipher Message with Chaining), and KIMD (Compute Intermediate Message Digest), OpenSSL effectively offloads bulk encryption tasks. This direct hardware execution minimizes overhead and frees up vital CPU cycles for core application logic, ensuring high throughput and efficiency. Table D in the Appendix shows the CPACF instructions used in OpenSSL that are used in OpenJCEPlus and SunJCE native layers. [12]

2.3. IBMJCECCA

The IBMJCECCA provider serves as a versatile cryptographic solution for z/OS applications, offering a tiered execution model optimized for both security and speed. For Clear Keys, the provider implements a high-performance fast path that bypasses the ICSF service layer overhead, utilizing a direct JNI-to-Assembly bridge to execute CPACF instructions on the CPU core for maximum throughput. To balance speed with enhanced security, it supports Protected Keys, which are routed through ICSF to be wrapped by a system-unique master key, ensuring the material is only usable by the CPACF and never appears in plain text within the JVM or OS memory. Finally, for the highest security level, IBMJCECCA utilizes Secure Keys (stored in the CKDS or as ICSFToken); these keys never leave the secure boundary of the Crypto Express (HSM) card. While this off-core operation introduces PCIe latency compared to CPACF, it provides the ultimate hardware-enforced protection against key material exposure. Figure 2 shows the IBMJCECCA architecture. [13]

Figure 2. IBMJCECCA Architecture

Figure 2. IBMJCECCA Architecture

On z/OS, the Integrated Cryptographic Service Facility (ICSF) acts as the centralized software interface for managing the full lifecycle of cryptographic keys and coordinating hardware acceleration. ICSF provides a robust abstraction layer that allows applications to access CPACF for high-speed synchronous operations and Crypto Express (HSM) adapters for secure, sensitive tasks. ICSF on z/OS serves as the gateway for IBMJCECCA security provider to utilize CPACF through clear and protected key encryption. By utilizing specialized data sets such as the CKDS (Common Key Data Set) for symmetric keys and the PKDS (Public Key Data Set) for asymmetric keys, ICSF ensures that key material is stored securely and indexed for easy administrative access. This architecture enables a unique tiered security model where ICSF can dynamically transition keys between “Secure”, “Protected”, and “Clear” states, ensuring that enterprise workloads maintain the optimal balance between maximum hardware performance and rigorous cryptographic isolation. Table E in the Appendix compares IBM Z cryptographic processing paths for CPACF and Crypto Express. [14] [15]

2.4. Performance

To measure the performance improvement from using CPACF acceleration, we run benchmarks with the SunJCE provider on Linux on IBM Z, IBM Semeru Runtime Open Edition 21.0.9.0, under two distinct configurations: Native-Enabled (With CPACF) and Native-Disabled (Without CPACF), for the AES/GCM/NoPadding and MessageDigest SHA-256 services. When the system properties jdk.nativeGCM (for AES/GCM) and jdk.nativeDigest (for SHA-256) are set to true, the JVM offloads processing to specialized z/Architecture hardware instructions, specifically KMA (Cipher Message with Authentication) for AES/GCM and KIMD/KLMD (Compute Intermediate/Last Message Digest) for digest, which operate synchronously with the processor to deliver high-throughput encryption and message integrity. Conversely, setting these flags false forces the JVM to rely on software-based implementations or vectorized CPU intrinsics. We run the code below for AES/GCM/NoPadding and MessageDigest SHA-256 services on Linux on IBM Z s390x.

    /**
     * Benchmarks AES-GCM performance for SunJCE on Linux on IBM Z.
     * Performance Modes:
     * 1. SunJCE-Native-True (CPACF KMA Accelerated):
     * Uses the KMA instruction for simultaneous AES and GHASH.
     * System Property: -Djdk.nativeGCM=true
     * 2. SunJCE-Native-False (Pure Java/Intrinsics):
     * Uses the standard software implementation.
     * System Property: -Djdk.nativeGCM=false
     *
     * @param iteration   Number of encryption cycles
     * @param payloadSize Size of the plaintext to encrypt
     */
    private static void encryptAesGcm(int iteration, int payloadSize) throws Exception {
        SecureRandom random = new SecureRandom();
        Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");

        byte[] plainData = new byte[payloadSize];
        random.nextBytes(plainData);

        // GCM recommended IV size is 12 bytes (96 bits)
        byte[] iv = new byte[12];
        random.nextBytes(iv);

        SecretKeySpec keySpec = new SecretKeySpec(new byte[16], "AES");

        long startTime = System.currentTimeMillis();

        for (int i = 0; i < iteration; i++) {
            // Modify IV for each iteration
            byte temp = iv[1];
            iv[1] = iv[0];
            iv[0] = temp;

            // Initialization: Prepares the KMA parameter block (KMA-GCM)
            cipher.init(Cipher.ENCRYPT_MODE, keySpec, new GCMParameterSpec(128, iv));

            // doFinal: Invokes KMA to process data and generate the authentication tag
            cipher.doFinal(plainData);
        }

        long endTime = System.currentTimeMillis();
        System.out.println("Execution Time: " + (endTime - startTime) + "ms");
    }

    /**
     * Benchmarks SHA-256 MessageDigest performance for SunJCE on Linux on IBM Z.
     * Performance Modes:
     * 1. SunJCE-Native-True (CPACF Accelerated):
     * Uses KIMD/KLMD mnemonics for hardware-speed hashing.
     * System Property: -Djdk.nativeDigest=true
     * 2. SunJCE-Native-False (Pure Java/JIT):
     * Uses standard Java software implementation.
     * System Property: -Djdk.nativeDigest=false
     * 
     * Note: 'jdk.nativeCrypto' acts as a global toggle for all native crypto
     * (Signatures, Ciphers, Digests), while 'jdk.nativeDigest' is specific to hashing.
     *
     * @param iteration   Number of hashing cycles
     * @param payloadSize Size of the data to hash
     */
    private static void testDigest(int iteration, int payloadSize) throws Exception {
        byte[] data = new byte[payloadSize];
        new SecureRandom().nextBytes(data);

        // Instance from SunJCE provider
        MessageDigest digest = MessageDigest.getInstance("SHA-256");

        System.out.println("Benchmark started: " + digest.getAlgorithm());
        System.out.println("Provider: " + digest.getProvider().getName());

        long startTime = System.currentTimeMillis();

        for (int i = 0; i < iteration; i++) {
            // Triggers KIMD (Compute Intermediate Message Digest)
            digest.update(data);
            // Triggers KLMD (Compute Last Message Digest)
            byte[] hash = digest.digest();
        }

        long endTime = System.currentTimeMillis();
        System.out.println("Execution Time: " + (endTime - startTime) + "ms");
    }

For the AES-GCM benchmark, Figure 3, the Native-Enabled mode (using the CPACF KMA mnemonic) shows an extraordinary scaling advantage. The performance improvement percentages demonstrate that as the workload becomes heavier, the Native-Enabled becomes more efficient at absorbing the computational cost.

  • 32-Byte Payload: The Native-Enabled mode achieved a 3.33x speedup ratio. In terms of throughput, this represents a 233% performance increase over the Native-Disabled (pure Java implementation).

  • 128-Byte Payload: As the data size quadrupled, the speedup ratio grew to 6.00x, resulting in a 500% performance increase.

  • 512-Byte Payload: At this level, the gap is most profound. The Native-Enabled provided an 18.66x speedup ratio. This translates to a massive 1,766% performance increase, showing that the Native-Disabled (pure Java implementation) is nearly 19 times slower than the Native-Enabled (CPACF-accelerated path).

  • Ratio of Geomeans (Method A): Consider the geometric mean of 84.04ms for Enabled mode and 605.09ms for Disabled mode over different payload sizes, which translates “Average Speedup" of 7.20x.

  • Geomean of Ratios (Method B): If we also consider speedup ratios for different payload sizes, that also results in a geometric mean of 7.20x (Average Speedup) for Native-Enabled (CPACF) mode.

Figure 3. Performance Benchmark for AES/GCM/NoPadding

Figure 3. Performance Benchmark for AES/GCM/NoPadding

The MessageDigest SHA-256 benchmark, Figure 4, illustrates how the KIMD/KLMD CPACF mnemonics handle hashing much more gracefully than Native-Disabled (software). While Native-Disabled time scales linearly with data size, the Native-Enabled time remains relatively flat.

  • 32-Byte Payload: Utilizing the hardware (CPACF) resulted in a 3.74x speedup ratio, which is a 274% performance increase compared to the software mode.

  • 128-Byte Payload: The efficiency gap widened to a 5.38x speedup ratio, or a 438% performance increase.

  • 512-Byte Payload: For the largest payload tested, the Native-Enabled mode achieved a 9.66x speedup ratio. This represents an 866% performance increase, effectively reducing the processing time to approximately one-tenth of the software execution time.

  • Ratio of Geomeans (Method A): Consider the geometric mean of 236.69ms for Enabled mode and 1370.14ms for Disabled mode over different payload sizes, which results in a “Average Speedup" of 5.79x.

  • Geomean of Ratios (Method B): Considering speedup ratios for different payload sizes, which also results in a geometric mean of 5.79x (Average Speedup) for Native-Enabled (CPACF) mode.

Figure 4. Performance Benchmark for MessageDigest SHA-256
Figure 4. Performance Benchmark for MessageDigest SHA-256

Disclaimer:

The benchmarks were conducted on an IBM z17 (Machine Type 9175, Model ME1) server, powered by Telum II processors clocked at 5.5 GHz with a hierarchical cache structure featuring a 360 MB virtual L3 cache. The software environment consisted of Red Hat Enterprise Linux 8.10 (Ootpa) running as a guest on an IBM z/VM 7.3.0 hypervisor. The specific virtual machine was provisioned with 4 virtual CPUs (vCPUs) and utilized the IBM Semeru Runtime Open Edition 21.0.9.0. Results may vary.

3. CPACF in other OpenJDK Distributions

Across the ecosystem of OpenJDK distributions for IBM Z, the integration of CPACF hardware acceleration is primarily defined by the underlying Java Virtual Machine (JVM) architecture. While all distributions aim to exploit the high-performance cryptographic capabilities of the Z platform, they diverge in their implementation strategy: HotSpot-based distributions (like Red Hat and Eclipse Temurin) generally favor a "direct-to-hardware" approach using JIT Intrinsics, whereas OpenJ9-based runtimes (like IBM Semeru) utilize a provider-driven model that bridges Java calls to native cryptographic libraries.

3.1. Red Hat build of OpenJDK

On Red Hat Enterprise Linux (RHEL) for IBM Z, the Red Hat build of OpenJDK maximizes performance by using JIT Intrinsics as its primary path, where the HotSpot compiler automatically replaces Java cryptographic calls with native CPACF instructions for ultra-fast, clear key encryption without any JNI overhead. However, when the system is switched to FIPS mode, the JVM shifts to a compliance-first strategy by using the SunPKCS11 provider to delegate all cryptographic work to the RHEL OpenSSL library; this path utilizes the ibmca engine to access both the on-chip CPACF and the Crypto Express HSM cards, ensuring all operations occur within a FIPS-validated boundary. Table F in the Appendix shows Red Hat OpenJDK cryptographic acceleration modes on RHEL for IBM Z. [16] [17] [18]

3.2. Eclipse Temurin

Eclipse Temurin on Linux on IBM Z follows a pure Java architectural approach by utilizing the HotSpot JVM's JIT Intrinsics to communicate directly with the CPACF hardware. Unlike OpenJ9-based distributions, Temurin does not require or use an OpenSSL native bridge for its cryptographic operations; instead, the JIT compiler identifies standard Java security calls and translates them into native IBM Z machine instructions (like KMC or KLMD). This design minimizes external dependencies and eliminates the performance overhead associated with JNI context switching, ensuring that high-speed hardware acceleration for AES and SHA is baked directly into the runtime's execution stream. [16]

3.3. IBM Semeru Runtimes vs. OpenJDK Distributions

On IBM Z, the choice of distribution determines the cryptographic strategy. IBM Semeru Runtimes utilize the OpenJCEPlus provider, which acts as a bridge to a native OpenSSL engine that is bundled in OCKC. This allows Java applications to benefit from a common, FIPS-validated cryptographic library shared across the enterprise. IBM Semeru Runtimes also offer two other primary providers, SunJCE and IBMJCECCA, that bring extensive flexibility to the users for different cryptographic contexts and key types. In contrast, HotSpot-based runtimes (such as Red Hat OpenJDK) use JIT Intrinsics, where the JVM compiles CPACF opcodes directly into the application's machine code. While JIT intrinsics offer a self-contained "no-dependency" path, the IBM Semeru Runtimes approach provides superior flexibility through its diverse ecosystem of security providers, catering to organizations that require enterprise-grade cryptography, regulatory compliance, and high-performance hardware offloading. Table G in the Appendix shows the CPACF code path and cryptographic context comparison between IBM Semeru Runtimes and HotSpot Distributions such as Red Hat OpenJDK.

References

[1] https://www.ibm.com/docs/en/linux-on-systems?topic=hw-cpacf

[2] https://en.wikipedia.org/wiki/IBM_Z

[3] https://www.ibm.com/docs/en/linux-on-systems?topic=support-cp-assist-cryptographic-function-cpacf

[4] https://www.ibm.com/docs/en/zos/3.2.0?topic=icsf-cp-assist-cryptographic-functions-cpacf

[5] https://www.ibm.com/docs/en/linux-on-systems?topic=concepts-crypto-hw-categories

[6] https://www.ibm.com/docs/en/linux-on-systems?topic=statistics-monitoring-cpacf-activity

[7] https://www.ibm.com/support/pages/java-sdk-products-zos

[8] https://developer.ibm.com/languages/java/semeru-runtimes/downloads/

[9] https://community.ibm.com/community/user/blogs/farshad-rahimi-asl/2025/11/14/complete-guide-to-openjceplus

[10] https://github.com/IBM/OpenJCEPlus

[11] https://github.com/ibmruntimes/openj9-openjdk-jdk25

[12] https://www.ibm.com/docs/en/linux-on-systems?topic=linuxone-openssl-ibmz

[13] https://www.ibm.com/docs/en/semeru-runtime-ce-z/21.0.0?topic=guide-ibmjcecca

[14] https://www.ibm.com/docs/en/zos/3.2.0?topic=management-protected-key-cpacf

[15] https://www.ibm.com/docs/en/SSLTBW_3.1.0/pdf/csfb400_icsf_apg_hcr77e0.pdf

[16] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/s390/assembler_s390.hpp

[17] https://www.ibm.com/support/pages/how-installconfigure-openssl-ibmca-red-hat-enterprise-linux-ibm-z

[18] https://docs.redhat.com/en/documentation/red_hat_build_of_openjdk/11/html-single/configuring_red_hat_build_of_openjdk_11_on_rhel_with_fips/index

Appendix

Table A. CPACF Evolution on the IBM Z Platform: This table outlines the history of CPACF evolution on the IBM Z platform.

Model Name (Year)

MSA Level

Key Hardware Cryptography Additions

z990 / z890 (2003)

MSA 1

Initial CPACF introduction. Supported DES, TDES, and SHA-1 hashing.

z9 EC / z9 BC (2005)

MSA 2

Added AES-128 and SHA-256.

z10 EC / z10 BC (2008)

MSA 3

Added AES-192, AES-256, SHA-384, and SHA-512.

z196 / z114 (2010)

MSA 4

Introduced Protected Key support; added AES-CTR, OFB, and CFB modes.

zEC12 / zBC12 (2012)

MSA 5

Introduced PRNO instruction for Pseudorandom Number Generation.

z13 / z13s (2015)

MSA 6/7

Optimized for SIMD architecture; added SHA-512 variants and improved performance.

z14 / z14 ZR1 (2017)

MSA 8

Added SHA-3 (224-512), SHAKE, AES-GCM via the KMA instruction, and a hardware-integrated True Random Number Generator (TRNG)

z15 T01 / T02 (2019)

MSA 9

Added KDSA instruction for Elliptic Curve (ECC), supporting NIST curves (P-256, P-384, P-521), Edwards curves (Ed25519, Ed448), and Montgomery curves (X25519, X448)

z16 A01 / Rack (2022)

MSA 10

Quantum-Safe focus: Hardware acceleration for Dilithium (ML-DSA) and lattice-based signatures.

z17 (2025)

MSA 11

Introduced HMAC hardware acceleration and enhanced AES-XTS for disk encryption.

Table B. CPACF Instructions: This table shows the list of native CPU mnemonics and their functions.

Mnemonic

Official Name

Supported Algorithms / Functions

Triggering Example Code Path

KM

Cipher Message

AES-128, AES-192, AES-256, DES, TDES.

Cipher.getInstance(

"AES/ECB/NoPadding");

…

cipher.doFinal();

KMC

Cipher Message with Chaining

Same as KM, but supports CBC (Chaining) mode.

Cipher.getInstance(

"AES/CBC/PKCS5Padding");

…

cipher.doFinal();

KMA

Cipher Message with Authentication

AES-GCM

Cipher.getInstance(

"AES/GCM/NoPadding");

…

cipher.doFinal();

KIMD

Compute Intermediate Message Digest

SHA-1, SHA-2 (224, 256, 384, 512), SHA-3, SHAKE.

MessageDigest.getInstance(

"SHA-256");

…

digest.update(input);

KLMD

Compute Last Message Digest

Finalizes hashes for all KIMD algorithms.

MessageDigest.digest();

KMAC

Compute Message Authentication Code

HMAC and standard MAC functions.

Mac.getInstance(

"HmacSHA256");

…

mac.doFinal();

KMF

Cipher Message with CFB

Cipher Feedback (CFB) mode for AES/DES.

Cipher.getInstance(

"AES/CFB/NoPadding");

…

cipher.doFinal();

KMO

Cipher Message with OFB

Output Feedback (OFB) mode for AES/DES.

Cipher.getInstance(

"AES/OFB/NoPadding");

…

cipher.doFinal();

KMCTR

Cipher Message with Counter

AES-CTR mode (used heavily in modern TLS).

Cipher.getInstance(

"AES/CTR/NoPadding");

…

cipher.doFinal();

KDSA

Key Digital Signature Assist

ECDSA, EdDSA (Ed25519, Ed448) signing/verification.

Signature.getInstance(

"SHA256withECDSA");

…

signature.doFinal();

PRNO

Perform Random Number Operation

TRNG (True Random) and Deterministic (DRNG).

SecureRandom.

getInstanceStrong();

random.nextBytes(array);

Table C. SunJCE Native Cryptographic Acceleration Control Properties: This table shows the list of properties to control SunJCE native mode operation in IBM Semeru Runtime on Linux on IBM Z.

The default value for these flags is true in IBM Semeru Open Edition on Linux on IBM Z.

To verify hardware usage, set -Djdk.nativeCryptoTrace=true. If it's working, you will see messages like NativeCrypto: OpenSSL library loaded.

Category

Flag

Valid Values

Description

Master Toggle

jdk.nativeCrypto

true/false

Global switch to enable or disable the entire OpenSSL native bridge.

Symmetric Cipher

jdk.nativeGCM

true/false

Toggles native acceleration for AES-GCM (used heavily in TLS 1.2/1.3).

Symmetric Cipher

jdk.nativeCBC

true/false

Toggles native acceleration for Cipher Block Chaining (CBC) modes.

Hashing

jdk.nativeDigest

true/false

Toggles native acceleration for Message Digests (SHA-256, SHA-512, etc.).

Asymmetric

jdk.nativeRSA

true/false

Toggles native offloading for RSA operations (Sign/Verify/Encrypt).

Asymmetric

jdk.nativeEC

true/false

Toggles native offloading for Elliptic Curve (ECDSA/ECDH).

Library Management

jdk.native.openssl.lib

[Path to .so]

Specifies a custom path to a specific libcrypto.so file.

Library Management

jdk.native.openssl.skipBundled

true/false

Forces the JVM to use the OS system OpenSSL instead of one bundled with the JDK.

Diagnostic

jdk.nativeCryptoTrace

true/false

Prints a trace to stdout confirming when native libraries are loaded and used.

Table D. CPACF Instructions used in OpenSSL: This table shows the list of CPACF instructions that are used in OpenSSL, which are called by OpenJCEPlus and SunJCE native layers.

OpenSSL Functionality

Instruction Used

Benefit

AES (ECB, CBC, CTR, OFB, CFB)

KM, KMC, KMCTR, KMO, KMF

High-speed bulk data encryption.

AES-GCM (Most web traffic)

KMA

Modern authenticated encryption (z14+).

SHA-2 / SHA-3 / SHAKE

KIMD, KLMD

Massive speedup for hashing and data integrity.

HMAC

KMAC

Accelerated message authentication (z17+).

ECDSA / EdDSA (Sign/Verify)

KDSA

Accelerates TLS handshakes (z15+).

Random Number Generation

PRNO (as an entropy source to seed)

High-entropy hardware-seeded random numbers.

Table E. Comparison of IBM Z Cryptographic Processing Paths: This table shows a comparison of IBM Z cryptographic processing paths for CPACF and Crypto Express.

Feature

CPACF (On-Chip)

Crypto Express (PCIe Card)

Physical Location

Integrated into every CPU core.

Dedicated PCIe adapter (HSM).

Supported Keys

Clear, Protected

Clear, Secure, Protected (via re-wrap)

Execution Mode

Synchronous (CPU waits for the result).

Asynchronous (CPU hands off the task).

Best For

Bulk Encryption (AES, SHA), TLS data.

Asymmetric (RSA), PINs, Master Keys.

Latency

Extremely Low (Instruction speed).

Higher (Requires PCI bus travel).

Security Level

High (Keys not in clear RAM).

Highest (FIPS 140-2 Level 4).

Table F. Red Hat OpenJDK Cryptographic Acceleration Modes on RHEL for IBM Z: This table shows different modes of cryptographic acceleration for Red Hat OpenJDK on RHEL for IBM Z.

Mode

Technology Path

Hardware Used

Primary Benefit

Standard

JIT Intrinsics (Built-in)

CPACF (On-CPU)

Maximum Throughput

FIPS

SunPKCS11 → OpenSSL → ibmca

CPACF & Crypto Express

Regulatory Compliance

Table G. CPACF Code Path & Cryptographic Context Comparison: This table compares the CPACF code path execution and cryptographic context between IBM Semeru Runtimes and HostSpot OpenJDK distributions that support the CPACF, such as Red Hat OpenJDK.

Feature

IBM Semeru Runtimes

HotSpot Distributions

CPACF Path Diversity

Multi-Path Optimization: Uses FastJNI/OCKC/OpenSSL for OpenJCEPlus and SunJCE, and ICSF for IBMJCECCA.

Single-Path Only: Relies almost exclusively on JIT Intrinsics for clear keys.

Provider Selection

Dynamic Choice: Includes OpenJCEPlus (Performance), SunJCE (Standard), and IBMJCECCA (High Security).

Fixed: Primarily limited to the standard SunJCE provider.

Key Protection

Multi-Key Support: Handles Clear and Protected Keys (via CPACF) and Secure Keys (via ICSF/Crypto Express cards).

Clear Key Only: Lacks native integration for hardware-protected Secure Keys (HSM).

Extended Offloading

Full MSA Support: Offloads complex operations such as KMAC and KDSA via the native OCKC/OpenSSL layer.

Subset Offloading: Only offloads ciphers/hashes that have been specifically "intrinsified" in the JVM source code.

Compliance Layer

Bundled OCKC: Includes a FIPS-certified native module that guarantees CPACF usage for all certified algorithms.

External Reliance: Requires the user to configure the OS-level libraries to achieve similar hardware offloading.

0 comments
33 views

Permalink

https://community.ibm.com/community/user/blogs/farshad-rahimi-asl/2026/01/25/ibm-semeru-runtimes-acceleration-via-cpacf