Common Cryptographic Architecture functional overview

Figure 1 provides a conceptual framework for positioning the CCA security API, which you use to access a common cryptographic architecture. Application programs make procedure calls to the CCA security API to obtain cryptographic and related I/O services. You can issue a call to the CCA security API from essentially any high-level programming language. The call, or request, is forwarded to the cryptographic services access layer and receives a synchronous response. Your application program loses control until the access layer returns a response after processing your request.

The products that implement the CCA support consist of both hardware and software components.

CCA software support: The software consists of application development and runtime software components.

• The application development software primarily consists of language bindings that can be included in new applications to assist in accessing services available at the API. Language bindings are provided for the C and Java™ programming languages.
• The runtime software can be divided into the following categories:
  • Service-requesting programs, including application and utility programs.
  • The security API, an agent function that is logically part of the calling application program or utility.
  • The cryptographic services access layer: an environment-dependent request routing function, key-storage support services, and device driver to access one or more hardware cryptographic engines.
  • The cryptographic engine software that gives access to the cryptographic engine hardware.

    The cryptographic engine is implemented in the hardware of the CEX*C coprocessor. Security-sensitive portions of CCA are implemented in the cryptographic engine software running in the protected coprocessor environment.

  • Utility programs and tools provide support for administering CCA secret keys, interacting with CCA managed symmetric and public key cryptography key storage, and configuring the software support.

You can create application programs that employ the CCA security API or you can purchase applications from IBM or other sources that use the products. This document is the primary source of information for designing systems and application programs that use the CCA security API with the cryptographic coprocessors.

Cryptographic engine: The CCA architecture defines a cryptographic subsystem that contains a cryptographic engine operating within a protected boundary. The coprocessor's tamper-resistant, tamper-responding environment provides physical security for this boundary and the CCA architecture provides the logical security needed for the full protection of critical information.

CEX4C Coprocessor: The coprocessor provides a secure programming and hardware environment wherein AES, DES, RSA, Elliptic Curve, and HMAC processes are performed. Each cryptographic coprocessor includes a general-purpose processor, non-volatile storage, and specialized cryptographic electronics. These components are encapsulated in a protective environment to enhance security. The IBM CCA Support Program enables applications to employ a set of AES, DES, RSA, Elliptic Curve, and HMAC-based cryptographic services utilizing the coprocessor hardware. Services include:

• DES, AES, RSA, Elliptic Curve, and HMAC key-pair generation
• DES, AES, RSA, Elliptic Curve, and HMAC host-based key record management
• Digital signature generation and verification
• Cryptographic key wrapping and unwrapping
• Data encryption, decryption and MAC generation/verification
• PIN processing for the financial services industry
• Other services, including DES key-management based on control-vector-enforced key separation.

CEX5C Coprocessor: The coprocessor provides the same functions as the CEX4C coprocessor with more algorithms moved from hardware-enhanced to fully hardware-accelerated. CMAC, VFPE, AESKW, and other algorithms are added.

CEX6C Coprocessor: The coprocessor provides domain support for up to 85 logical partitions. When configured as a CCA coprocessor, it includes secure key functions with emphasis on the specialized functions required for banking and payment card systems. It is optionally programmable to add custom functions and algorithms by using User Defined Extensions (UDX). A new mode, called Payment Card Industry (PCI) PIN Transaction Security (PTS) Hardware Security Module (HSM), shortened to PCI-HSM 2016 compliance mode, is available exclusively for Crypto Express6S in CCA mode. Exploitation of PCI-HSM 2016 mode with compliance-tagged secure key tokens simplifies compliance with PCI requirements for hardware security modules.

CEX7C Coprocessor: This coprocessor provides domain support for up to 85 logical partitions. When configured as a CCA coprocessor, it includes secure key functions with emphasis on the specialized functions required for banking and payment card systems. It is optionally programmable to add custom functions and algorithms by using user defined extensions (UDX). The special PCI-HSM 2016 compliance mode is also available for Crypto Express7S in CCA mode. The CEX7S begins introduction of Quantum Safe algorithms with CRYSTALS-Dilithium key management and digital signature availability.

CEX8C Coprocessor: This coprocessor provides domain support for up to 85 partitions, and builds on the function of the CEX7C. PCI-HSM 2016 compliance mode is supported, including updates for DES key wrapping to match PCI-HSM 2021 changes. Quantum-safe algorithm (QSA) support is expanded, adding CRYSTALS-Dilithium Round 3 keys, as well as hardware support for Dilithium keys, improving performance when using Dilithium keys greatly. In addition for QSA, CRYSTALS-Kyber keys for encryption and key exchange are supported.

CCA: Common Cryptographic Architecture (CCA) is the basis for a consistent cryptographic product family. Applications employ the CCA security API to obtain services from, and to manage the operation of, a cryptographic system that meets CCA specifications.

CCA access control: Each CCA node has an access-control system enforced by the hardware and protected software. The robust UNIX style access controls integrated into the Linux operating system are used to protect the integrity of the underlying CCA hardware environment. The specialized processing environment provided by the cryptographic engine can be kept secure because selected services are provided only when certain requirements are met or a Trusted Key-Entry console is used to enable access. The access-control decisions are performed within the secured environment of the cryptographic engine and cannot be subverted by rogue code that might run on the main computing platform.

Coprocessor certification: After quality checking a newly manufactured coprocessor, IBM loads and certifies the embedded software. Following the loading of basic, authenticated software, the coprocessor generates an RSA key-pair and retains the private key within the cryptographic engine. The associated public key is signed by a certification key securely held at the manufacturing facility and then the certified device key is stored within the coprocessor. The manufacturing facility key has itself been certified by a securely held key unique to the CEX*C product line.

The private key within the coprocessor, known as the device private key, is retained in the coprocessor. From this time on, if tampering is detected or if the coprocessor batteries are removed or lose power in the absence of bus power, the coprocessor sets all security-relevant keys and data items to zero. This process is irreversible and results in the permanent loss of the factory-certified device key, the device private key, and all other data stored in battery-protected memory. Security-sensitive data stored in the coprocessor flash memory is encrypted. The key used to encrypt such data is itself retained in the battery-protected memory.

CCA verbs: An application or utility program obtains service from the CCA Support Program by issuing service requests (verb calls or procedure calls) to the runtime subsystem (see Sample verb call routines). To fulfill these requests, the Support Program in turn obtains service from the coprocessor software and hardware.

The available services are collectively described as the CCA security API. All the software and hardware accessed through the CCA security API should be considered an integrated subsystem. A command processor performs the verb request within the cryptographic engine.

Commands and access control, roles, profiles: In order to ensure that only designated individuals (or programs) can run commands such as master-key loading, each command processor that performs sensitive processing interrogates one or more access control point values within the cryptographic engine access-control system for permission to perform the request.

The access-control system includes one or more roles. Each role defines the permissible control points for users of that role. In the IBM Z® environment, all application programs run using the permissions defined in the default role for their domain. The default role can only be modified using the TKE workstation. For a description of the functions that are permitted by the default version of the default role, see z/OS® Cryptographic Services ICSF Trusted Key Entry Workstation User’s Guide.