Cryptographic features
This chapter describes the hardware cryptographic functions that are available on IBM z14 ZR1. The CP Assist for Cryptographic Function (CPACF), together with the Peripheral Component Interconnect Express (PCIe) cryptographic coprocessors, offer a balanced use of processing resources and unmatched scalability for fulfilling pervasive encryption demands.
The z14 ZR1 is designed for delivering a transparent and consumable approach that enables extensive (pervasive) encryption of data in flight and at rest, with the goal of substantially simplifying data security and reducing the costs that are associated with protecting data while achieving compliance mandates.
This chapter also introduces the principles of cryptography and describes the implementation of cryptography in the hardware and software architecture of IBM Z. It also describes the features that IBM z14 ZR1 offers. Finally, the chapter summarizes the cryptographic features and required software.
|
Naming: The IBM z14 server generation is available as the following machine types and models:
•Machine Type 3906 (M/T 3906), Models M01, M02, M03, M04, and M05 → further identified as IBM z14 Model M0x, or z14 M0x, unless otherwise specified.
•Machine Type 3907 (M/T 3907), Model ZR1 → further identified as IBM z14 Model ZR1, or z14 ZR1, unless otherwise specified.
In the remainder of this chapter, IBM z14 (z14) refers to both machine types.
|
This chapter includes the following topics:
6.1 Cryptography enhancements on IBM z14 ZR1
IBM z14 introduced the new PCI Crypto Express6S feature, together with an improved CPACF Coprocessor, that is managed by a new Trusted Key Entry (TKE) workstation. In addition, the IBM Common Cryptographic Architecture (CCA) and the IBM Enterprise PKCS #11 (EP11) Licensed Internal Code (LIC) were enhanced.
The new functions support new standards and are designed to meet the following compliance requirements:
•Payment Card Industry (PCI) Hardware Security Module (HSM) certification to strength the cryptographic standards for attack resistance in the payment card systems area.
PCI HSM certification is exclusive for Crypto Express6S.
•National Institute of Standards and Technology (NIST) through the Federal Information Processing Standard (FIPS) standard to implement guidance requirements.
•Common Criteria EP11 EAL4.
•German Banking Industry Commission (GBIC).
•VISA Format Preserving Encryption (VFPE) for credit card numbers.
•Enhanced public key Elliptic Curve Cryptography (ECC) for users such as Chrome, Firefox, and Apple’s iMessage.
These enhancements are described in this chapter.
IBM z14 ZR1 includes standard cryptographic hardware and optional cryptographic features for flexibility and growth capability. IBM has a long history of providing hardware cryptographic solutions. This history stretches from the development of the Data Encryption Standard (DES) in the 1970s to the Crypto Express tamper-sensing and tamper-responding programmable features.
Crypto Express is designed to meet the US Government’s highest security rating of FIPS 140-2 Level 41. It also meets several other security ratings, such as the Common Criteria for Information Technology Security Evaluation, the PCI HSM, criteria, and the criteria for German Banking Industry Commission (formerly known as Deutsche Kreditwirtschaft evaluation).
The cryptographic functions include the full range of cryptographic operations that are necessary for local and global business and financial institution applications. User Defined Extensions (UDX) allow you to add custom cryptographic functions to the functions that z14 systems offer.
6.2 Cryptography overview
From the early beginning of human history, when two people were communicating with each other, the demand always existed to keep certain messages secret so that a third person cannot understand what the sender is telling to the receiver.
Also, it is necessary to ensure that a message cannot be corrupted, while ensuring that the sender and the receiver really are the persons who they claim to be. Over time, several methods were used to achieve these objectives, with more or less success. Many procedures and algorithms for encrypting and decrypting data were developed that are increasingly complicated and time-consuming.
6.2.1 Modern cryptography
With the development of computing technology, the encryption and decryption algorithms can be performed by computers, which enables the use of complicated mathematical algorithms. Most of these algorithms are based on the prime factorization of large numbers.
Modern cryptography involves the following purposes for protecting information:
•Data protection
The protection of data usually is the main concept that is associated with cryptography. Only authorized persons should be able to read the message or get information about it. Data is encrypted by using a known algorithm and secret keys, such that the intended party can de-scramble the data, but an interloper cannot. This concept is also referred to as confidentiality.
•Authentication (identity validation)
This process decides whether the communication partners are who they claim to be, which can be done by using certificates and signatures. It must be possible to clearly identify the owner of the data or the sender and the receiver of the message.
•Integrity
The verification of data ensures that what was received is identical to what was sent. It must be proven that the data is complete and was not altered during the moment it was transmitted (by the sender) and the moment it was received (by the receiver).
•Non-repudiation
It must be impossible for the owner of the data or the sender of the message to deny authorship. Non-repudiation ensures that both sides of a communication know that the other side agreed to what was exchanged, and not someone else. This specification implies a legal liability and contractual obligation, which is the same as a signature on a contract.
These goals should all be possible without unacceptable overhead to the communication. The goal is to keep the system secure, manageable, and productive.
The basic method data protection is to encrypt and decrypt it, while hash algorithms, message authentication codes (MACs), digital signatures, and certificates are used for authentication, integrity, and non-repudiation.
When encrypting a message, the sender transforms the clear text into a secret text. Doing so requires the following main elements:
•The algorithm is the mathematical or logical formula that is applied to the key and the clear text to deliver a ciphered result, or to take a ciphered text and deliver the original clear text.
•The key ensures that the result of the encrypting data transformation by the algorithm is only the same when the same key is used. That decryption of a ciphered message results only in the original clear message when the correct key is used. Therefore, the receiver of a ciphered message must know which algorithm and which key must be used to decrypt the message.
6.2.2 Kerckhoffs’ principle
In modern cryptography, the algorithm is published and known to everyone, whereas the keys are kept secret. This configuration corresponds to Kerckhoffs’ principle, which is named after Auguste Kerckhoffs, a Dutch cryptographer, who formulated it in 1883:
“A system should not depend on secrecy, and it should be able to fall into the enemy’s hands without disadvantage.”
In other words, the security of a cryptographic system should depend on the security of the key, so the key must be kept secret. Therefore, the secure management of keys is the primal task of modern cryptographic systems.
Adhering to Kerckhoffs’ Principle is done for the following reasons:
•It is much more difficult to keep an algorithm secret than a key.
•It is harder to exchange a compromised algorithm than to exchange a compromised key.
•Secret algorithms can be reconstructed by reverse engineering software or hardware implementations.
•Errors in public algorithms can generally be found more easily, when many experts look into it.
•In history, most secret encryption methods proved to be weak and inadequate.
•When a secret encryption method is used, it is possible that a back door was built in.
•If an algorithm is public, many experts can form an opinion about it. Also, the method can be more thoroughly investigated for potential weaknesses and vulnerabilities.
6.2.3 Keys
The keys that are used for the cryptographic algorithms often are sequences of numbers and characters, but can also be any other sequence of bits. The length of a key influences the security (strength) of the cryptographic method. The longer the used key, the more difficult it is to compromise a cryptographic algorithm.
For example, the DES (symmetric key) algorithm uses keys with a length of 56 bits, Triple-DES (TDES) uses keys with a length of 112 bits, and Advanced Encryption Standard (AES) uses keys of 128, 192, 256, or 512 bits. The asymmetric key RSA algorithm (named after its inventors Rivest, Shamir, and Adleman) uses keys with a length of 1024 - 4096 bits.
In modern cryptography, keys must be kept secret. Depending on the effort that is made to protect the key, keys are classified into the following levels:
•A clear key is a key that is transferred from the application in clear text to the cryptographic function. The key value is stored in the clear (at least briefly) somewhere in unprotected memory areas. Therefore, the key can be made available to someone under certain circumstances who is accessing this memory area.
This risk must be considered when clear keys are used. However, many applications exist where this risk can be accepted. For example, the transaction security for the (widely used) encryption methods Secure Sockets Layer (SSL) and Transport Layer Security (TLS) is based on clear keys.
•The value of a protected key is stored only in clear in memory areas that cannot be read by applications or users. The key value does not exist outside of the physical hardware, although the hardware might not be tamper-resistant. The principle of protected keys is unique to IBM Z systems. For more information, see 6.4.2, “CPACF protected key” on page 185.
•For a secure key, the key value does not exist in clear format outside of a special hardware device (HSM), which must be secured and tamper-resistant. A secure key is protected from disclosure and misuse, and can be used for the trusted execution of cryptographic algorithms on highly sensitive data. If used and stored outside of the HSM, a secure key must be encrypted with a master key, which is created within the HSM and never leaves the HSM.
Because a secure key must be handled in a special hardware device, the use of secure keys usually is far slower than the use of clear keys, as shown in Figure 6-1.
Figure 6-1 Three levels of protection with three levels of speed
6.2.4 Algorithms
The following algorithms of modern cryptography are differentiated based on whether they use the same key for the encryption of the message as for the decryption:
•Symmetric algorithms use the same key to encrypt and to decrypt data. The function that is used to decrypt the data is the opposite of the function that is used to encrypt the data. Because the same key is used on both sides of an operation, it must be negotiated between both parties and kept secret. Therefore, symmetric algorithms are also known as secret key algorithms.
The main advantage of symmetric algorithms is that they are fast and therefore can be used for large amounts of data, even if they are not run on specialized hardware. The disadvantage is that the key must be known by both sender and receiver of the messages, which implies that the key must be exchanged between them. This key exchange is a weak point that can be attacked.
Prominent examples for symmetric algorithms are DES, TDES, and AES.
•Asymmetric algorithms use two distinct but related key: the public key and the private key. As the names imply, the private key must be kept secret, whereas the public key is shown to everyone. However, with asymmetric cryptography, it is not important who sees or knows the public key. Whatever is done with one key can be undone by the other key only.
For example, data that is encrypted by the public key can be decrypted by the associated private key only, and vice versa. Unlike symmetric algorithms, which use distinct functions for encryption and decryption, only one function is used in asymmetric algorithms. Depending on the values that are passed to this function, it encrypts or decrypts the data. Asymmetric algorithms are also known as public key algorithms.
Asymmetric algorithms use complex calculations and are relatively slow (about 100 - 1000 times slower than symmetric algorithms). Therefore, such algorithms are not used for the encryption of bulk data.
Because the private key is never exchanged between the parties in communication, they are less vulnerable than symmetric algorithms. Asymmetric algorithms mainly are used for authentication, digital signatures, and for the encryption and exchange of secret keys, which in turn are used to encrypt bulk data with a symmetric algorithm.
Examples for asymmetric algorithms are RSA and the elliptic curve algorithms.
•One-way algorithms are not cryptographic functions. They do not use keys, and they can scramble data only, not de-scramble it. These algorithms are used extensively within cryptographic procedures for digital signing and tend to be developed and governed by using the same principles as cryptographic algorithms. One-way algorithms are also known as hash algorithms.
The most prominent one-way algorithms are the Secure Hash Algorithms (SHA).
6.3 Cryptography on IBM z14 ZR1
In principle, cryptographic algorithms can run on processor hardware. However, these workloads are compute-intensive, and the handling of secure keys also requires special hardware protection. Therefore, IBM Z offer several cryptographic hardware features, which are specialized to meet the requirements for cryptographic workload.
The cryptographic hardware that is supported on IBM z14 ZR1 is shown in Figure 6-2. These features are described in this chapter.
Figure 6-2 Cryptographic hardware that is supported in IBM z14 ZR1
Implemented in every processor unit (PU) or core in a central processor complex (CPC) is a cryptographic coprocessor that can be used2 for cryptographic algorithms that uses clear keys or protected keys. For more information, see 6.4, “CP Assist for Cryptographic Functions” on page 182.
The Crypto Express6S adapter is an HSM that is placed in the PCIe+ I/O drawer of z14 ZR1. It also supports cryptographic algorithms by using secret keys. For more information, see 6.5, “Crypto Express6S” on page 188.
Finally, a TKE workstation is required for entering keys in a secure way into the Crypto Express6S HSM, which often also is equipped with smart card readers. For more information, see 6.6, “TKE workstation” on page 200.
The feature codes and purpose of the cryptographic hardware features that are available for IBM z14 ZR1 are listed in Table 6-1.
Table 6-1 Cryptographic features for IBM z14 ZR1
|
Feature code
|
Description
|
|
3863
|
CP Assist for Cryptographic Function (CPACF) enablement
This feature is a prerequisite to use CPACF (except for SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512) and the Crypto Express6S and Crypto Express5S feature.
|
|
0893
|
Crypto Express6S adapter
A maximum of 16 features can be ordered (minimum of two features). This feature is optional and each feature of which contains one PCI Express cryptographic adapter (adjunct processor). This feature is supported only in z14.
|
|
0890
|
Crypto Express5S adapter
This feature is available as a carry forward MES from z13s. The maximum supported number of Crypto Express5S and Crypto Express6S together is 16. This feature is optional and each feature of which contains one PCI Express cryptographic adapter (adjunct processor). This feature is supported only in z14, z13, and z13s systems.
|
|
0086
|
TKE tower workstation
A TKE provides basic key management (key identification, exchange, separation, update, and backup) and security administration. It is optional for running a Crypto Express6S or Crypto Express5S adapter in CCA mode and required for running it in EP11 mode. The TKE workstation has one Ethernet port, and supports connectivity to an Ethernet local area network (LAN) operating at 10, 100, or 1000 Mbps. Up to 10 features per z14 ZR1 can be ordered.
|
|
0085
|
TKE rack-mounted workstation
The rack-mounted version of the TKE, which needs a customer-provided standard 19-inch rack or the use of the new 16U Reserved feature (FC 0617) for the z14 ZR1 rack. It features a 1u TKE unit and an (optional) 1u console tray (screen, keyboard, and pointing device). When smart card readers are used, another customer-provided tray is needed. Up to 10 features per z14 ZR1 can be ordered.
|
|
0880
|
TKE 9.1 Licensed Internal Code (LIC)
Included with the TKE tower workstation FC 0847 and the TKE rack-mounted workstation FC 0085 for z14 ZR1. Earlier versions of TKE features (feature codes: 0080, 0081, 0081, 0085, 0086, and 0849) can also be upgraded to TKE 9.1 LIC.
|
|
0879
|
TKE 9.0 Licensed Internal Code (LIC)
Included with the TKE tower workstation FC 0847 and the TKE rack-mounted workstation FC 0085 for z14. Earlier versions of TKE features (feature codes 0080, 0081, 0081, 0085, 0086, and 0849) can also be upgraded to TKE 9.0 LIC.
|
|
0891
|
TKE Smart Card Reader
Access to information in the smart card is protected by a PIN. One feature code includes two smart card readers, two cables to connect to the TKE workstation, and 20 smart cards.
|
|
0900
|
New TKE smart cards
This will allow the TKE to support zones with EC 521 key strength (EC 521 strength for Logon Keys, Authority Signature Keys, and EP11 signature keys). |
|
0892
|
More TKE smart cards
When one feature code is ordered, 10 smart cards are included. The order increment is 1 - 99 (990 blank smart cards).
|
A TKE includes support for the AES encryption algorithm with 256-bit master keys and key management functions to load or generate master keys to the cryptographic coprocessor.
If the TKE workstation is chosen to operate the Crypto Express5S adapter in a z14 ZR1, TKE workstation with the TKE 9.x LIC is required. For more information, see 6.6, “TKE workstation” on page 200.
|
Important: Products that include any of the cryptographic feature codes contain cryptographic functions that are subject to special export licensing requirements by the United States Department of Commerce. It is your responsibility to understand and adhere to these regulations when you are moving, selling, or transferring these products.
|
To access and use the cryptographic hardware devices that are provided by z14 ZR1, the application must use an application programming interface (API) that is provided by the operating system. In z/OS, the Integrated Cryptographic Service Facility (ICSF) provides the APIs and is managing the access to the cryptographic devices, as shown in Figure 6-3.
Figure 6-3 z14 ZR1 cryptographic support in z/OS
ICSF is a software component of z/OS. ICSF works with the hardware cryptographic features and the Security Server (IBM Resource Access Control Facility [IBM RACF®] element) to provide secure, high-speed cryptographic services in the z/OS environment. ICSF provides the APIs by which applications request the cryptographic services, and from the CPACF and the Crypto Express6S and Crypto Express5S adapter.
ICSF transparently routes application requests for cryptographic services to one of the integrated cryptographic engines (CPACF or a Crypto Express6S/Crypto Express5S adapter), depending on performance or requested cryptographic function. ICSF is also the means by which the secure Crypto Express6S/Crypto Express5S adapters are loaded with master key values, which allows the hardware features to be used by applications.
The cryptographic hardware that is installed in z14 ZR1 determines the cryptographic features and services that are available to the applications.
The users of the cryptographic services call the ICSF API. Some functions are performed by the ICSF software without starting the cryptographic hardware features. Other functions result in ICSF going into routines that contain proprietary IBM Z crypto instructions. These instructions are run by a CPU engine and result in a work request that is generated for a cryptographic hardware feature.
6.4 CP Assist for Cryptographic Functions
Attached to every PU (core) of a z14 ZR1 system are two independent engines, one for compression and one for cryptographic functions, as shown in Figure 6-4.
Figure 6-4 The cryptographic coprocessor CPACF
This cryptographic coprocessor, known as the CPACF, is not qualified as an HSM; therefore, it is not suitable for handling algorithms that use secret keys. However, the coprocessor can be used for cryptographic algorithms that use clear keys or protected keys. The CPACF works synchronously with the PU, which means that the owning processor is busy when its coprocessor is busy. This setup provides a fast device for cryptographic services.
CPACF supports pervasive encryption. Simple policy controls allow business to enable encryption to protect data in mission-critical databases without the need to stop the database or re-create database objects. Database administrators can use z/OS Dataset Encryption, z/OS Coupling Facility Encryption, z/VM encrypted hypervisor paging, and z/TPF transparent database encryption, which use performance enhancements in the hardware.
The CPACF offers a set of symmetric cryptographic functions that enhances the encryption and decryption performance of clear key operations. These functions are for SSL, virtual private network (VPN), and data-storing applications that do not require FIPS 140-2 Level 4 security.
CPACF is designed to facilitate the privacy of cryptographic key material when used for data encryption through key wrapping implementation. It ensures that key material is not visible to applications or operating systems during encryption operations. For more information, see 6.4.2, “CPACF protected key” on page 185.
The CPACF feature provides hardware acceleration for the following cryptographic services:
•DES
•Triple-DES
•AES-128
•AES-192
•AES-256 (all for clear and protected keys)
•SHA-1
•SHA-256 (SHA-2 or SHA-3 standard)
•SHA-384 (SHA-2 or SHA-3 standard)
•SHA-512 (SHA-2 or SHA-3 standard)
•SHAKE-128
•SHAKE-256
•PRNG
•DRNG
•TRNG
It provides high-performance hardware encryption, decryption, hashing, and random number generation support. The following instructions support the cryptographic assist function:
•KMAC: Compute Message Authentic Code
•KM: Cipher Message
•KMC: Cipher Message with Chaining
•KMF: Cipher Message with CFB
•KMCTR: Cipher Message with Counter
•KMO: Cipher Message with OFB
•KIMD: Compute Intermediate Message Digest
•KLMD: Compute Last Message Digest
•PCKMO: Provide Cryptographic Key Management Operation
These functions are provided as problem-state z/Architecture instructions that are directly available to application programs. These instructions are known as Message-Security Assist (MSA). When enabled, the CPACF runs at processor speed for every CP, IFL, and zIIP. For more information about MSA instructions, see z/Architecture Principles of Operation, SA22-7832.
The CPACF must be enabled by using an enablement feature (feature code 3863), which is available for no extra charge. The exception is support for the hashing algorithms SHA-1, SHA-256, SHA-384, and SHA-512, which is always enabled.
6.4.1 Cryptographic synchronous functions
Because the CPACF works synchronously with the PU, it provides cryptographic synchronous functions. For IBM and client-written programs, CPACF functions can be started by using the MSA instructions. z/OS ICSF callable services on z/OS, in-kernel crypto APIs, and a libica cryptographic functions library that is running on Linux on Z can also start CPACF synchronous functions.
The CPACF coprocessor in z14 ZR1 is redesigned for improved performance compared to the z13s, depending on the function that is being used. The following tools might benefit from the throughput improvements:
•Db2/IMS encryption tool
•Db2 built-in encryption
•z/OS Communication Server: IPsec/IKE/AT-TLS
•z/OS System SSL
•z/OS Network Authentication Service (Kerberos)
•DFDSS Volume encryption
•z/OS Java SDK
•z/OS Encryption Facility
•Linux on Z: Kernel, openSSL, openCryptoki, and GSKIT
The z14 ZR1 hardware includes the implementation of algorithms as hardware synchronous operations. This configuration holds the PU processing of the instruction flow until the operation completes.
z14 ZR1 offers the following synchronous functions:
•Data encryption and decryption algorithms for data privacy and confidentially:
– Data Encryption Standard (DES):
• Single-length key DES
• Double-length key DES
• Triple-length key DES (also known as Triple-DES)
– Advanced Encryption Standard (AES) for 128-bit, 192-bit, and 256-bit keys
•Hashing algorithms for data integrity, such as SHA-1 and SHA-2. New for z14 ZR1 is SHA-3 support for SHA-224, SHA-256, SHA-384, and SHA-512 and the two extendable output functions as described by the standard SHAKE-128 and SHAKE-256.
•Message authentication code (MAC):
– Single-length key MAC
– Double-length key MAC
•Pseudo-Random Number Generator (PRNG), Deterministic Random Number Generation (DRNG), and True Random Number Generation (TRNG) for cryptographic key generation.
•Galois Counter Mode (GCM) encryption, which is enabled by a single hardware instruction.
For the SHA hashing algorithms and the random number generation algorithms, only clear keys are used. For the symmetric encryption and decryption DES and AES algorithms and clear keys, protected keys can also be used. Protected keys require a Crypto Express6S or a Crypto Express5S adapter that is running in CCA mode. For more information, see 6.5.2, “Crypto Express6S as a CCA coprocessor” on page 191.
The hashing algorithms SHA-1, SHA-2, and SHA-3 support for SHA-224, SHA-256, SHA-384, and SHA-512, are enabled on all systems and do not require the CPACF enablement feature. For all other algorithms, the no-charge CPACF enablement feature (FC 3863) is required.
The CPACF functions are implemented as processor instructions and require operating system support for use. Operating systems that use the CPACF instructions include z/OS, z/VM, z/VSE, zTPF, and Linux on Z.
6.4.2 CPACF protected key
z14 ZR1 supports the protected key implementation. Since PCIXCC3 deployment, secure keys are processed on the PCI-X and PCIe adapters. This process requires an asynchronous operation to move the data and keys from the general-purpose central processor (CP) to the crypto adapters.
Clear keys process faster than secure keys because the process is done synchronously on the CPACF. Protected keys blend the security of Crypto Express6S or Crypto Express5S coprocessors and the performance characteristics of the CPACF. This process allows it to run closer to the speed of clear keys.
CPACF facilitates the continued privacy of cryptographic key material when used for data encryption. In Crypto Express6S or Express5S coprocessors, a secure key is encrypted under a master key. However, a protected key is encrypted under a wrapping key that is unique to each LPAR.
Because the wrapping key is unique to each LPAR, a protected key cannot be shared with another LPAR. By using key wrapping, CPACF ensures that key material is not visible to applications or operating systems during encryption operations.
CPACF code generates the wrapping key and stores it in the protected area of the hardware system area (HSA). The wrapping key is accessible only by firmware. It cannot be accessed by operating systems or applications. DES/T-DES and AES algorithms are implemented in CPACF code with the support of hardware assist functions. Two variations of wrapping keys are generated: One for DES/T-DES keys and another for AES keys.
Wrapping keys are generated during the clear reset each time an LPAR is activated or reset. No customizable option is available at Support Element (SE) or Hardware Management Console (HMC) that permits or avoids the wrapping key generation. This function flow for the Crypto Express6S adapter is shown in Figure 6-5.
Figure 6-5 CPACF key wrapping for Crypto Express6S
The key wrapping for Crypto Express5S is similar to Crypto Express6S; however, the Data Key that is exchanged between the Crypto Express5S and the CPACF is not wrapped by way of a Transport Key.
The CPACF Wrapping Key and the Transport Key for use with Crypto Express6S, are in a protected area of the HSA that is not visible to operating systems or applications.
The function flow for Crypto Express5S is shown in Figure 6-6.
Figure 6-6 CPACF key wrapping for Crypto Express5S
If a Crypto Express6S coprocessor (CEX6C) or Express5S coprocessor (CEX5C) is available, a protected key can begin its life as a secure key. Otherwise, an application is responsible for creating or loading a clear key value, and then uses the PCKMO instruction to wrap the key. ICSF is not called by the application if the CEX6C or CEX5C is not available.
A new segment in the profiles of the CSFKEYS class in IBM RACF restricts which secure keys can be used as protected keys. By default, all secure keys are considered not eligible to be used as protected keys. The process that is shown in Figure 6-5 considers a secure key as the source of a protected key.
The source key in this case is stored in the ICSF Cryptographic Key Data Set (CKDS) as a secure key, which was encrypted under the master key. This secure key is sent to CEX6C or CEX5C to be deciphered and then, sent to the CPACF in clear text. At the CPACF, the key is wrapped under the LPAR wrapping key, and is then returned to ICSF. After the key is wrapped, ICSF can keep the protected value in memory. It then passes it to the CPACF, where the key is unwrapped for each encryption or decryption operation.
The protected key is designed to provide substantial throughput improvements for a large volume of data encryption and low latency for encryption of small blocks of data. A high-performance secure key solution, also known as a protected key solution, requires the ICSF HCR7770 as a minimum release.
6.5 Crypto Express6S
The Crypto Express6S feature (FC 0893) is an optional feature that is exclusive to z14 systems. Each feature has one PCIe cryptographic adapter. The Crypto Express6S (CEX6S) feature occupies one I/O slot in a z14 ZR1 PCIe+ I/O drawer. This feature is an HSM and provides a secure programming and hardware environment on which crypto processes are run.
Each cryptographic coprocessor includes a general-purpose processor, non-volatile storage, and specialized cryptographic electronics. The Crypto Express6S feature provides tamper-sensing and tamper-responding, high-performance cryptographic operations.
Each Crypto Express6S PCI Express adapter is available in one of the following configurations:
•Secure IBM CCA coprocessor (CEX6C) for FIPS 140-2 Level 4 certification. This configuration includes secure key functions. It is optionally programmable to deploy more functions and algorithms by using UDX. For more information, see 6.5.2, “Crypto Express6S as a CCA coprocessor” on page 191.
•Secure IBM Enterprise PKCS #11 (EP11) coprocessor (CEX6P) implements an industry-standardized set of services that adheres to the PKCS #11 specification V2.20 and more recent amendments. It was designed for extended FIPS and Common Criteria evaluations to meet public sector requirements. This new cryptographic coprocessor mode introduced the PKCS #11 secure key function. For more information, see 6.5.3, “Crypto Express6S as an EP11 coprocessor” on page 196.
A TKE workstation is required to support the administration of the Crypto Express5S when it is configured in EP11 mode.
•Accelerator (CEX6A) for acceleration of public key and private key cryptographic operations that are used with SSL/TLS processing. For more information, see 6.5.4, “Crypto Express6S as an accelerator” on page 197.
These modes can be configured by using the SE. The PCIe adapter must be configured offline to change the mode.
|
Attention: Switching between configuration modes erases all adapter secrets. The exception is when you are switching from Secure CCA to accelerator, and vice versa.
|
The Crypto Express6S feature was released for enhanced cryptographic performance. Clients who migrated to variable-length AES key tokens cannot take advantage of faster encryption speeds by using CPACF. Support is being added to translate a secure variable-length AES CIPHER token to a protected key token (protected by the system wrapping key). This support allows for faster AES encryption speeds when variable-length tokens are used while maintaining strong levels of security.
The Crypto Express6S feature does not include external ports and does not use optical fiber or other cables. It does not use channel path identifiers (CHPIDs), but requires one slot in the PCIe I/O drawer and one physical channel ID (PCHID) for each PCIe cryptographic adapter. Removal of the feature or adapter zeroizes its content. Access to the PCIe cryptographic adapter is controlled through the setup in the image profiles on the SE.
|
Adapter: Although PCIe cryptographic adapters include no CHPID type and are not identified as external channels, all logical partitions (LPARs) in all channel subsystems can access to the adapter. In z14 systems, up to 85 LPARs (40 LPAR for z14 ZR1) are available per adapter. Accessing the adapter requires a setup in the image profile for each partition. The adapter must be in the candidate list.
|
Each z14 ZR1 supports up to 16 Crypto Express6S and Crypto Express 5S features in total. Crypto Express5S features are not orderable for a new build system, but can be carried forward from a z13s by using an MES. Configuration information for Crypto Express6S is listed in Table 6-2.
Table 6-2 Crypto Express6S features
|
Feature
|
Quantity
|
|
Minimum number of orderable features for z14 ZR11
|
2
|
|
Order increment above two features
|
1
|
|
Maximum number of features for z14 ZR1 (CEX6S and CEX5S in total)
|
16
|
|
Number of PCIe cryptographic adapters for each feature
(coprocessor or accelerator)
|
1
|
|
Number of cryptographic domains at z14 ZR1 for each PCIe adapters2
|
40
|
1 The minimum initial order of Crypto Express6S features is two. After the initial order, more Crypto Express6S features can be ordered one feature at a time, up to a maximum of 16.
2 More than one partition, which is defined to the same channel subsystem (CSS) or to different CSSs, can use the same domain number when assigned to different PCIe cryptographic adapters.
The concept of dedicated processor does not apply to the PCIe cryptographic adapter. Whether configured as a coprocessor or an accelerator, the PCIe cryptographic adapter is made available to an LPAR. It is made available as directed by the domain assignment and the candidate list in the LPAR image profile. This availability is not changed by the shared or dedicated status that is given to the PUs in the partition.
When installed non-concurrently, Crypto Express6S features are assigned PCIe cryptographic adapter numbers sequentially during the power-on reset (POR) that follows the installation. When a Crypto Express6S feature is installed concurrently, the installation can select an out-of-sequence number from the unused range. When a Crypto Express6S feature is removed concurrently, the PCIe adapter numbers are automatically freed.
The definition of domain indexes and PCIe cryptographic adapter numbers in the candidate list for each LPAR must be planned to allow for nondisruptive changes. Consider the following points:
•Operational changes can be made by using the Change LPAR Cryptographic Controls task from the SE, which reflects the cryptographic definitions in the image profile for the partition. With this function, adding and removing the cryptographic feature without stopping a running operating system can be done dynamically.
•The same usage domain index can be defined more than once across multiple LPARs. However, the PCIe cryptographic adapter number that is coupled with the usage domain index that is specified must be unique across all active LPARs.
The same PCIe cryptographic adapter number and usage domain index combination can be defined for more than one LPAR (up to 40 for z14 ZR1). For example, you might define a configuration for backup situations. However, only one of the LPARs can be active at a time.
For more information, see 6.5.5, “Managing Crypto Express6S” on page 197.
6.5.1 Cryptographic asynchronous functions
The optional PCIe cryptographic coprocessors Crypto Express6S provides asynchronous cryptographic functions to z14 ZR1. Over 300 Cryptographic algorithms and modes are supported, including the following algorithms and modes:
•DES/TDES w DES/TDES MAC/CMAC: The Data Encryption Standard is a widespread symmetrical encryption algorithm. DES, along with its double-length and triple length variations, TDES today are considered to be not sufficient secure for many applications. They were replaced by the AES as the official US standard, but it is still used in the industry with the MAC and the Cipher-based Message Authentication Code (CMAC) for verifying the integrity of messages.
•AES, AESKW, AES GMAC, AES GCM, AES XTS, AES CIPHER mode, and CMAC: AES replaced DES as the official US standard in October 2000. The enhanced standards for AES Key Warp (AESKW), the AES Galois Message Authentication Code (AES GMAC) and Galois/Counter Mode (AES GCM), the XEX-based tweaked-codebook mode with ciphertext stealing (AES XTS), and CMAC are supported.
•MD5, SHA-1, SHA-2, or SHA-34 (224, 256, 384, 512), and HMAC: The Secure Hash Algorithm (SHA-1 and the enhanced SHA-2 or SHA-3 for different block sizes), the older message-digest (MD5) algorithm, and the advanced keyed-hash method authentication code (HMAC) are used for verifying the data integrity and the authentication of a message.
•Visa Format Preserving Encryption (VFPE): A method of encryption in which the resulting cipher text features the same form as the input clear text, which is developed for use with credit cards.
•RSA (512, 1024, 2048, and 4096): RSA was published in 1977. It is widely used asymmetric public-key algorithm, which means that the encryption key is public whereas the decryption key is kept secret. It is based on the difficulty of factoring the product of two large prime numbers. The number describes the length of the keys.
•ECDSA (192, 224, 256, 384, and 521 Prime/NIST): ECC is a family of asymmetric cryptographic algorithms that are based on the algebraic structure of elliptic curves. ECC can be used for encryption, pseudo-random number generation, and digital certificates. The Elliptic Curve Digital Signature Algorithm (ECDSA) Prime/NIST method is used for ECC digital signatures, which are recommended for government use by NIST.
•ECDSA (160, 192, 224, 256, 320, 384, and 512 BrainPool): ECC Brainpool is a workgroup of companies and institutions that collaborate on developing ECC algorithms. The ECDSA algorithms that are recommended by this group are supported.
•ECDH (192, 224, 256, 384, and 521 Prime/NIST): Elliptic Curve Diffie-Hellman (ECDH) is an asymmetric protocol that is used for key agreement between two parties by using ECC-based private keys. The recommendations by NIST are supported.
•ECDH (160, 192, 224, 256, 320, 384, and 512 BrainPool): ECDH according to the Brainpool recommendations.
•Montgomery Modular Math Engine: The Montgomery Modular Math Engine is a method for fast modular multiplication. Many crypto systems, such as RSA and Diffie-Hellman key Exchange, can use this method.
•Random Number Generator (RNG): The generation of random numbers for cryptographic key generation is supported.
•Prime Number Generator (PNG): The generation of prime numbers is also supported.
•Clear Key Fast Path (Symmetric and Asymmetric): This mode of operation gives a direct hardware path to the cryptographic engine and provides high performance for public-key cryptographic functions.
Several of these algorithms require a secure key and must run on an HSM. Some of these algorithms can also run with a clear key on the CPACF. Many standards are supported only when Crypto Express6S is running in CCA mode. Others are supported only when the adapter is running in EP11 mode.
The three modes for Crypto Express6S are described next. For more information, see 6.7, “Cryptographic functions comparison” on page 205.
6.5.2 Crypto Express6S as a CCA coprocessor
A Crypto Express6S adapter that is running in CCA mode supports IBM CCA. CCA is an architecture and a set of APIs. It provides cryptographic algorithms, secure key management, and many special functions that are required for banking. Over 129 APIs with more than 600 options are provided, with new functions and algorithms always being added.
The IBM CCA provides functions for the following tasks:
•Encryption of data (DES/TDES/AES)
•Key management:
– Using TDES or AES keys
– Using RSA or Elliptic Curve keys
•Message authentication for MAC/HMAC/AES-CMAC
•Key generation
•Digital signatures
•Random number generation
•Hashing (SHA, MD5, and others)
•ATM PIN generation and processing
•Credit card transaction processing
•Visa Data Secure Platform (DSP) Point to Point Encryption (P2PE)
•Europay, MasterCard, and Visa (EMV) card transaction processing
•Card personalization
•Other financial transaction processing
•Integrated role-based access control system
User-defined extensions support
User-defined extension (UDX) allows a developer to add customized operations to IBM’s CCA Support Program. UDXs to the CCA support customized operations that run within the Crypto Express features when defined as a coprocessor.
UDX is supported under a special contract through an IBM or approved third-party service offering. The Crypto Cards website directs your request to an IBM Global Services location for your geographic location. A special contract is negotiated between IBM Global Services and you for the development of the UDX code by IBM Global Services according to your specifications and an agreed-upon level of the UDX.
A UDX toolkit for IBM Z systems is tied to specific versions of the CCA code and the related host code. UDX is available for the Crypto Express6S (Secure IBM CCA coprocessor mode only) features. An UDX migration is no more disruptive than a normal Microcode Change Level (MCL) or ICSF release migration.
In z14 ZR1, up to four UDX files can be imported. These files can be imported from a DVD only. The UDX configuration window is updated to include a Reset to IBM Default button.
|
Consideration: CCA features a new code level starting with z13 systems, and the UDX clients require a new UDX.
|
On z14 ZR1, Crypto Express6S is delivered with CCA Level 6.0 firmware. A new set of cryptographic functions and callable services is provided by the IBM CCA LIC to enhance the functions that secure financial transactions and keys. The Crypto Express6S includes the following features:
•Greater than 16 domains support up to 40 LPARs on z14 ZR1
•Payment Card Industry (PCI) PIN Transaction Security (PTS) HSM Certification exclusive to CEX6S and z14
•Visa Format Preserving Encryption (VFPE) support, which was introduced with z13/z13s systems
•AES PIN support for the German banking industry
•PKA Translate UDX function into CCA
•Verb Algorithm Currency
Greater than 16 domains support
z14 ZR1 supports up to 40 LPARs. The IBM Z crypto architecture was designed to support 16 domains, which matched the LPAR maximum at the time. Before z13 systems, crypto workload separation can be complex in customer environments where the number of LPARs was larger than 16. These customers mapped a large set of LPARs to a small set of crypto domains.
Now in z14 systems, the IBM Z crypto architecture can support up to 256 domains in an adjunct processor (AP) with the AP extended addressing (APXA) facility that is installed. As such, the Crypto Express adapters are enhanced to handle 256 domains. The IBM Z firmware provides up to 85 domains for z14 Mxx and 40 domains for z14 ZR1 to customers (to match the current LPAR maximum). Customers can map individual LPARs to unique crypto domains or continue to share crypto domains across LPARs.
The following requirements must be met to support 40 domains:
•Hardware: z14 ZR1 and Crypto Express6S (or Crypto Express5S)
•Operating systems:
– z/OS all functions require ICSF WD17 (HCR77C1), unless otherwise noted. WD17 supports z/OS V2R1, V2R2, and V2R3.
– z/VM Version 6.4 with PTFs or newer for guest use.
Payment Card Industry-HSM certification
Payment Card Industry (PCI) standards are developed to help ensure security in the PCI. PCI defines their standards as a set of security standards that is designed to ensure that all companies that accept, process, store, or transmit credit card information that is maintained a secure environment.
Compliance with the PCI-HSM standard is valuable for customers, particularly those customers who are in the banking and finance industry. This certification is important to clients for the following fundamental reasons:
•Compliance is increasingly becoming mandatory.
•The requirements in PCI-HSM make the system more secure.
Industry requirements for PCI-HSM compliance
The PCI organization cannot require compliance with its standards. Compliance with PCI standards is enforced by the payment card brands, such as Visa, MasterCard, American Express, JCB International, and Discover.
If you are a bank, acquirer, processor, or other participant in the payment card systems, the card brands can impose requirements on you if you want to process their cards. One set of requirements they are increasingly enforcing is the PCI standards.
The card brands work with PCI in developing these standards, and they focused first on the standards they considered most important, particularly the PCI Data Security Standard (PCI-DSS). Some of the other standards were written or required later, and PCI-HSM is one of the last standards to be developed. In addition, the standards themselves were increasing the strength of their requirements over time. Some requirements that were optional in earlier versions of the standards are now mandatory.
In general, the trend is for the card brands to enforce more of the PCI standards and to enforce them more rigorously. The trend in the standards is to impose more and stricter requirements in each successive version. The net result is that companies subject to these requirements can expect that they eventually must comply with all of the requirements.
Improved security through use of PCI-HSM
PCI-HSM was developed primarily to improve security in payment card systems. It imposes requirements in key management, HSM API functions, and device physical security. It also controls during manufacturing and delivery, device administration, and several other areas. It prohibits many things that were in common use for many years, but are no longer considered secure.
The result of these requirements is that applications and procedures often must be updated because they used some of the things that are now prohibited. While this issue is inconvenient and imposes some costs, it does truly increase the resistance of the systems to attacks of various kinds. Updating a system to use PCI-HSM compliant HSMs is expected to reduce the risk of loss for the institution and its clients.
The following requirements must be met to use PCI-HSM:
•Hardware: z145 systems and Crypto Express6S
•Operating systems:
– z/OS - ICSF WD17 (HCR77C1), unless otherwise noted. WD17 supports z/OS V2R1, V2R2, and V2R3
– z/VM Version 6.4 with PTFs or newer for guest use
VISA Format Preserving Encryption
VFPE refers to a method of encryption in which the resulting cipher text features the same form as the input clear text. The form of the text can vary according to use and application. One of the classic examples is a 16-digit credit card number. After VFPE is used to encrypt a credit card number, the resulting cipher text is another 16-digit number. This process helps older databases contain encrypted data of sensitive fields without having to restructure the database or applications.
VFPE allows customers to add encryption to their applications in such a way that the encrypted data can flow through their systems without requiring a massive redesign of their application. In our example, if the credit card number is VFPE-encrypted at the point of entry, the cipher text still behaves as a credit card number. It can flow through business logic until it meets a back-end transaction server that can VFPE-decrypt it to get the original credit card number to process the transaction.
|
Note: VISA Format Preserving Encryption (VFPE) technology forms part of Visa, Inc.'s Data Secure Platform (DSP). The use of this function requires a service agreement with Visa. You must maintain a valid service agreement with Visa when you use DSP/FPE.
|
The FPE features the following requirements:
•Hardware: z14 systems and Crypto Express 6S (or Crypto Express5S with CCA V5.2 firmware).
•Operating systems:
– z/OS: All functions require ICSF WD17 (HCR77C1), unless otherwise noted. WD17 supports z/OS V2R1, V2R2, and V2R3.
– z/OS V2.1 and z/OS V1.13 with the Cryptographic Support for z/OS V1R13-z/OS V2R1 web deliverable (FMID HCR77B0).
– z/VM Version 6.4 with PTFs or newer for guest use.
AES PIN support for the German banking industry
The German banking industry organization, DK, defined a new set of PIN processing functions to be used on the internal systems of banks and their servers. CCA is designed to support the functions that are essential to those parts of the German banking industry that are governed by DK requirements. The functions include key management support for new AES key types, AES key derivation support, and several DK-specific PIN and administrative functions.
This support includes PIN method APIs, PIN administration APIs, new key management verbs, and new access control points support that is needed for DK-defined functions.
The following requirements must be met to use AES PIN support:
•Hardware:
– z14 systems and Crypto Express6S with CCA V6.0 firmware or Crypto Express5S with CCA V5.2 firmware
– z13s systems and Crypto Express5S with CCA V5.2 firmware
– z13 systems and Crypto Express5S with CCA V5.0 or later firmware
– zEC12 or zBC12 and Crypto Express4S with CCA V4.4 firmware
– zEC12, zBC12, z196 or z114 and Crypto Express3 with CCA V4.4 firmware
•Operating systems requirements for z14:
– z/OS: All functions require ICSF WD17 (HCR77C1), unless otherwise noted. WD17 supports z/OS V2R1, V2R2, and V2R3.
– z/VM Version 6.3, and Version 6.4 with PTFs for guest use.
Support for the updated German Banking standard (DK)
Update support requires ICSF WD18 (HCR77D0) for z/OS V2R2 and V2R3 for:
•CCA 5.4 & 6.16:
– ISO-4 PIN Blocks (ISO-9564-1)
– Directed keys: A key can encrypt or decrypt data, but not both.
– Allow AES transport keys to be used to export/import DES keys in a standard ISO 20038 key block. This features helps with interoperability between CCA and non-CCA systems.
– Allow AES transport keys to be used to export/import a small subset of AES keys in a standard ISO 20038 key block. This feature helps with interoperability between CCA and non-CCA systems.
– Triple-length TDES keys with Control Vectors for increased data confidentiality
•CCA 6.2: PCI HSM 3K DES: Support for triple length DES keys (standards compliance).
PKA Translate UDX function into CCA
UDX is custom code that allows the client to add unique operations or extensions to the CCA firmware. Certain UDX functions are integrated into the base CCA code over time to accomplish the following tasks:
•Remove headaches and challenges that are associated with UDX management and currency.
•Make available popular UDX functions to a wider audience to encourage adoption.
UDX is integrated into the base CCA code to support translating an external RSA CRT key into new formats. These new formats use tags to identify key components. Depending on which new rule array keyword is used with the PKA Key Translate callable service, the service TDES encrypts those components in CBC or ECB mode. In addition, AES CMAC support is delivered.
The following requirements must be met to use this function:
•Hardware:
– z14 systems and Crypto Express6S (or Crypto Express5S with CCA V5.2 firmware)
– z13s systems and Crypto Express5S with CCA V5.2 firmware
– z13 systems and Crypto Express5S with CCA V5.0 or later firmware
•Operating systems requirements:
– z/OS: ICSF WD17 (HCR77C1), otherwise noted. WD17 supports z/OS V2R1, V2R2, and V2R3.
– z/VM Version 6.3, and Version 6.4 with PTFs for guest use.
|
Note: Although older IBM Z systems and operating systems also are supported, they are beyond the scope of this IBM Redbooks publication.
|
Verb Algorithm Currency
Verb Algorithm Currency is a collection of CCA verb enhancements that are related to customer requirements, with the intent of maintaining currency with cryptographic algorithms and standards. It is also intended for customers who want to maintain the following latest cryptographic capabilities:
•Secure key support AES GCM encryption
•Key Check Value (KCV) algorithm for service CSNBKYT2 Key Test 2
•Key derivation options for CSNDEDH EC Diffie-Hellman service
The following requirements must be met to use this function:
•Hardware:
– z14 systems and Crypto Express6S (or Crypto Express5S with CCA V5.2 firmware)
– z13s or z13 systems and Crypto Express5S with CCA V5.2 firmware
•Software:
– z/OS: ICSF WD17 (HCR77C1), otherwise noted. WD17 supports z/OS V2R1, V2R2, and V2R3.
– z/VM 6.3, and 6.4 with PTFs for guest use.
6.5.3 Crypto Express6S as an EP11 coprocessor
A Crypto Express6S adapter that is configured in Secure IBM Enterprise PKCS #11 (EP11) coprocessor mode provides PKCS #11 secure key support for public sector requirements. Before EP11, the ICSF PKCS #11 implementation supported only clear keys. In EP11, keys can now be generated and securely wrapped under the EP11 Master Key. The secure keys never leave the secure coprocessor boundary decrypted.
The secure IBM Enterprise PKCS #11 (EP11) coprocessor runs the following tasks:
•Encrypt and decrypt (AES, DES, TDES, and RSA)
•Sign and verify (DSA, RSA, and ECDSA)
•Generate keys and key pairs (DES, AES, DSA, ECC, and RSA)
•HMAC (SHA1, SHA2 or SHA3 [SHA224, SHA256, SHA384, and SHA512])
•Digest (SHA1, SHS2 or SHA3 [SHA224, SHA256, SHA384, and SHA512])
•Wrap and unwrap keys
•Random number generation
•Get mechanism list and information
•Attribute values
•Key Agreement (Diffie-Hellman)
The function extension capability through UDX is not available to the EP11.
When defined in EP11 mode, the TKE workstation is required to manage the Crypto Express6S feature.
z/OS V2.2 and V2.3 require ICSF Web Deliverable WD18 (HCR77D0) to support the following new features:
•EP11 Stage 4:
– New elliptic curve algorithms for PKCS#11 signature, key derivation operations
• Ed448 elliptic curve
• EC25519 elliptic curve
– EP11 Concurrent Patch Apply: Allows service to be applied to the EP11 coprocessor dynamically without taking the crypto adapter offline (already available for CCA coprocessors).
– eIDAS compliance: eIDAS: Cross-border EU regulation for portable recognition of electronic identification.
6.5.4 Crypto Express6S as an accelerator
A Crypto Express6S adapter that is running in accelerator mode supports only RSA clear key and SSL Acceleration. A request is processed fully in hardware. The Crypto Express accelerator is a coprocessor that is reconfigured by the installation process so that it uses only a subset of the coprocessor functions at a higher speed. Reconfiguration is disruptive to coprocessor and accelerator operations. The coprocessor or accelerator must be deactivated before you begin the reconfiguration.
FIPS 140-2 certification is not relevant to the accelerator because it operates with clear keys only. The function extension capability through UDX is not available to the accelerator.
The functions that remain available when the Crypto Express6S feature is configured as an accelerator are used for the acceleration of modular arithmetic operations. That is, the RSA cryptographic operations are used with the SSL/TLS protocol. The following operations are accelerated:
•PKA Decrypt (CSNDPKD) with PKCS-1.2 formatting
•PKA Encrypt (CSNDPKE) with zero-pad formatting
•Digital Signature Verify
The RSA encryption and decryption functions support key lengths of 512 - 4,096 bits in the Modulus-Exponent (ME) and Chinese Remainder Theorem (CRT) formats.
6.5.5 Managing Crypto Express6S
With zEC12 and older systems, each cryptographic coprocessor has 16 physical sets of registers or queue registers. Starting with z13 systems, this number was raised to 85. This increase corresponds to the maximum number of LPARs that are running on a z14 Mxx, which is also 85 (40 LPARs for z14 ZR1). Each of these sets belongs to the following domains:
•A cryptographic domain index, in the range of 0 - 39 for z14 ZR1, is allocated to a logical partition in its image profile. The same domain must also be allocated to the ICSF instance that is running in the logical partition that uses the Options data set.
•Each ICSF instance accesses only the Master Keys or queue registers that correspond to the domain number that is specified in the logical partition image profile at the SE and in its Options data set. Each ICSF instance sees a logical cryptographic coprocessor that consists of the physical cryptographic engine and the unique set of registers (the domain) that is allocated to this logical partition.
The installation of CP Assist for Cryptographic Functions (CPACF) DES/TDES enablement (FC 3863) is required to use the Crypto Express6S feature.
Each Crypto Express6S feature includes one PCI-X adapter. The adapter is available in the following configurations:
•IBM Enterprise Common Cryptographic Architecture (CCA) Coprocessor (CEX6C)
•IBM Enterprise Public Key Cryptography Standards #11 (PKCS) Coprocessor (CEX6P)
•IBM Crypto Express6S Accelerator (CEX6A)
During the feature installation, the PCI-X adapter is configured by default as the CCA coprocessor.
The configuration of the Crypto Express6S adapter as EP11coprocessor requires a TKE tower workstation (FC 0086) or a TKE rack-mounted workstation (FC 0085) with TKE 9.0 (FC 0879) LIC.
The Crypto Express6S feature does not use CHPIDs from the channel subsystem pool. However, the Crypto Express6S feature requires one slot in a PCIe I/O drawer, and one PCHID for each PCIe cryptographic adapter.
For enabling an LPAR to use a Crypto Express6S adapter, the following cryptographic resources in the image profile must be defined for each partition:
•Usage domain index
•Control domain index
•PCI Cryptographic Coprocessor Candidate List
•PCI Cryptographic Coprocessor Online List
This task is accomplished by using the Customize/Delete Activation Profile task, which is in the Operational Customization Group, from the HMC or from the SE. Modify the cryptographic initial definition from the Crypto option in the image profile, as shown in Figure 6-7 on page 198.
|
Important: After this definition is modified, any change to the image profile requires a DEACTIVATE and ACTIVATE of the logical partition for the change to take effect. Therefore, this cryptographic definition is disruptive to a running system.
|
Figure 6-7 Customize Image Profiles: Crypto
The following cryptographic resource definitions are used:
•Control Domain
Identifies the cryptographic coprocessor domains that can be administered from this logical partition if it is set up as the TCP/IP host for the TKE.
If you are setting up the host TCP/IP in this logical partition to communicate with the TKE, the partition is used as a path to other domains’ Master Keys. Indicate all the control domains that you want to access (including this partition’s own control domain) from this partition.
•Control and Usage Domain
Identifies the cryptographic coprocessor domains that are assigned to the partition for all cryptographic coprocessors that are configured on the partition. The usage domains cannot be removed if they are online. The numbers that are selected must match the domain numbers that are entered in the Options data set when you start this partition instance of ICSF.
The same usage domain index can be used by multiple partitions, regardless to which CSS they are defined. However, the combination of PCIe adapter number and usage domain index number must be unique across all active partitions.
•Cryptographic Candidate list
Identifies the cryptographic coprocessor numbers that can be accessed by this logical partition. From the list, select the coprocessor numbers (in the range 0 - 15) that identify the PCIe adapters to be accessed by this partition.
•Cryptographic Online list
Identifies the cryptographic coprocessor numbers that are automatically brought online during logical partition activation. The numbers that are selected in the online list must also be part of the candidate list.
After they are activated, the active partition cryptographic definitions can be viewed from the SE only. Select the CPCs, and click View LPAR Cryptographic Controls in the CPC Operational Customization window. The resulting window displays the definition of Usage and Control domain indexes, and PCI Cryptographic candidate and online lists, as shown in Figure 6-8 on page 200. Information is provided only for active logical partitions.
Figure 6-8 SE: View LPAR Cryptographic Controls
Operational changes can be made by using the Change LPAR Cryptographic Controls task from the SE, which reflects the cryptographic definitions in the image profile for the partition. With this function, the cryptographic feature can be added and removed dynamically, without stopping a running operating system.
For more information about the management of Crypto Express6S, see IBM 14 Model ZR1 Configuration Setup, SG24-8560.
6.6 TKE workstation
The TKE workstation is an optional feature that offers key management functions. It can be a TKE tower workstation (FC 0085) or TKE rack-mounted workstation (FC 0086) for z14 systems to manage Crypto Express6S or Crypto Express5S.
The TKE contains a combination of hardware and software. A mouse, keyboard, flat panel display, PCIe adapter, and a writable USB media to install the TKE LIC are included with the system unit. The TKE workstation requires an IBM 4768 crypto adapter.
A TKE workstation is part of a customized solution for the use of the Integrated Cryptographic Service Facility for z/OS (ICSF for z/OS) or Linux for z Systems. This program provides a basic key management system for the cryptographic keys of a z14 system that has Crypto Express features installed.
The TKE provides a secure, remote, and flexible method of providing Master Key Part Entry, and to remotely manage PCIe cryptographic coprocessors. The cryptographic functions on the TKE run by one PCIe cryptographic coprocessor. The TKE workstation communicates with the IBM Z system through a TCP/IP connection. The TKE workstation is available with Ethernet LAN connectivity only. Up to 10 TKE workstations can be ordered.
TKE FCs 0085 and 0086 can be used to control Crypto Express6S or Crypto Express5S on z14 ZR1. They also can be used to control the Crypto Express5S on z13 and z13s systems, and the Crypto adapters on older still supported systems.
The new TKE 9.1 LIC (FC 0880) features the following enhancements:
•TKE 9.1 License Internal Code enhancements for support EC521 strength TKE and Migration zones. An EC521 Migration zone is required if you want to use the migration wizard to collect and apply PCI-compliant domain information.
•TKE 9.1 also has a new family of wizards that makes it easy to create EC521 zones on all of its smart cards. This feature simplifies the process of deploying a TKE for the first time or moving data from a weaker TKE zone to a new EC521 zone.
•A new smart card for the Trusted Key Entry (TKE) allows stronger Elliptic Curve Cryptography (ECC) levels. Other TKE Smart Cards (FC 0900, packs of 10, FIPS certified blanks) require TKE 9.1 LIC.
The TKE 9.0 LIC (FC 0879) features the following enhancements:
•Key material copy to alternative zone
By using TKE 9.0, key material can be copied from smart cards in one TKE zone to smart cards in another zone. You might have old 1024-bit strength TKE zones, and might want to move or copy the key material in those zones into a new, stronger TKE zone. To use this new feature, you create TKE or EP11 smart cards on your TKE 9.0 system. You then enroll the new TKE or EP11 smart cards in an alternative zone. This process allows you to copy smart card content from a smart card that is enrolled in the alternative zone.
•Save TKE data directory structure with files to USB
TKE data can be saved to, or restored from, removable media in the same directory structure they were found on the TKE.
•Create key parts without opening a host
Administrators can now use the TKE application to create key parts without opening a host. This ability allows the key administrator to create key parts while being offline or before any hosts are defined. This feature can be found in the TKE application under the Utilities → Create CCA key parts pull-down menu.
•New TKE Audit Log application
A new TKE Audit Log application is available for the Privileged Mode Access ID of AUDITOR. This application provides an easy-to-use interface to view the TKE workstation security audit records from the TKE workstation.
•Heartbeat audit record
TKE workstations cut an audit record when the TKE starts or when no audit events occurred during a client-configured duration. The record shows the serial number of the TKE local crypto adapter and indicates whether the local crypto adapter was changed since the last check.
•Performance improvements for domain groups
Depending on the size of a domain group, you might experience performance improvements with CCA version 5.3 when a Load, Set, or Clear operation is performed from inside a domain group. For example, if you group all 85 domains on a Host Crypto Express 5 and issue a Clear New Master Key register operation, the number of commands that is issued to the module drops from 85 to 1.
•Secure key entry on EP11
TKE 9.0 EP11 smart card applet now supports secure key entry of EP11 master key parts.
•New certificate manager for domains
Every domain now can manage a set of parent X.509 certificates for validating operating X.509 certificates that are used by applications that are running in the domain.
The following features are related to support for the Crypto Express6S with CCA 6.0. The Crypto Express6S with CCA 6.0 is designed to meet the PCI-HSM PIN Transaction Security v3.0, 2016 standard:
•Domain mode management
With CCA 6.0, individual domains are in one of thefollowing modes:
– Normal Mode
– Imprint Mode
– Compliant Mode
Imprint and compliant mode were added to indirectly and directly meet the PCI-HSM PIN Transaction Security v3.0, 2016 requirement. TKE is required to manage Host Crypto Module domains in imprint and compliant mode.
•Set clock
With TKE 9.0, the host crypto module’s clock can be set. The clock must be set before a domain can be placed in imprint mode.
•Domain-specific Host Crypto Module Audit Log management
Domains in imprint mode or compliant mode on a Crypto Express6S maintain a domain-specific module audit log. The TKE provides a feature for downloading the audit records so they can be viewed.
•Domain-specific roles and authorities
Domains in imprint mode or compliant mode on a Crypto Express6S must be managed by using domain-specific roles and authorities. The TKE provides new management features for the domain-specific roles and authorities. The roles are subject to forced dual control policies that prevent roles from issuing and co-signing a command. For information about how to manage imprint and compliant mode domains, see the TKE User’s Guide.
•Setup PCI Environment Wizard
To simplify the management of a compliant domain, the TKE provides a setup wizard that creates a minimum set of forced dual control roles and authorities that are needed to manage a compliant domain. For more information about how to manage imprint and compliant mode domains, see the TKE User’s Guide.
|
Tip: For more information about handling a TKE, see the TKE Introduction video that is available on YouTube.
|
6.6.1 Logical partition, TKE host, and TKE target
If one or more LPARs are configured to use Crypto Express6S or Crypto Express5 S coprocessors, the TKE workstation can be used to manage DES, AES, ECC, and PKA master keys. This management can be done for all cryptographic domains of each Crypto Express coprocessor feature that is assigned to the LPARs that are defined to the TKE workstation.
Each LPAR in the same system that uses a domain that is managed through a TKE workstation connection is a TKE host or TKE target. An LPAR with a TCP/IP connection to the TKE is referred to as the TKE host; all other partitions are TKE targets.
The cryptographic controls that are set for an LPAR through the SE determine whether the workstation is a TKE host or a TKE target.
6.6.2 Optional smart card reader
An optional smart card reader (FC 0895) can be added to the TKE workstation. One FC 0895 includes two smart card readers, two cables to connect them to the TKE workstation, and 20 smart cards. The reader supports the use of smart cards that contain an embedded microprocessor and associated memory for data storage. The memory can contain the keys to be loaded into the Crypto Express features. These readers can be used with smart cards only that have applets that were loaded from a TKE 8.1 or later. These cards are FIPS certified.
Smart card readers from feature code 0885 or 0891 can be carried forward. Smart cards can be used on TKE 9.0 with these readers. Access to and use of confidential data on the smart card are protected by a user-defined PIN. Up to 990 other smart cards can be ordered for backup. (The extra smart card feature code is FC 0892.) When one feature code is ordered, 10 smart cards are included. The order increment is 1 - 99 (10 - 990 blank smart cards).
If smart cards with applets that are not supported by the new smart card reader are reused, new smart cards on TKE 8.1 or later must be created and the content from the old smart cards to the new smart cards must be copied. The new smart cards can be created and copied on a TKE 8.1 system. If the copies are done on TKE 9.0, the source smart card must be placed in an older smart card reader from feature code 0885 or 0891.
A new smart card for the Trusted Key Entry (TKE) allows stronger Elliptic Curve Cryptography (ECC) levels. More TKE Smart Cards (FC 0900, packs of 10, FIPS certified blanks) require TKE 9.1 LIC.
6.6.3 TKE hardware support and migration information
The new TKE 9.0 LIC (FC 0879) is originally shipped with a new z14 server. As of December, 2018, a new level of TKE LIC, 9.1 (FC 0880) is available and shipped with any new z14 server. If a new TKE is purchased, the following versions are available:
•TKE 9.1 tower workstation (FC 0086)
•TKE 9.1 rack-mounted workstation (FC 0085)
|
Note: Several options for ordering the TKE with or without ordering Keyboard, Mouse, and Display are available. Ask your IBM Representative for more information about which option is the best option for you.
|
The TKE 9.x7 LIC requires the 4768 crypto adapter. The TKE 8.0 and TKE 8.1 workstations can be upgraded to the TKE 9.x tower workstation by purchasing a 4768 crypto adapter.
The Omnikey Cardman 3821 smart card readers can be carried forward to any TKE 9.x workstation. Smart cards 45D3398, 74Y0551, and 00JA710 can be used on TKE 9.0
When performing a MES upgrade from TKE 7.3, TKE 8.0, or TKE 8.1 to a TKE 9.x installation, the following steps must be completed:
1. Save Upgrade Data on an old TKE to USB memory to save client data.
2. Replace the 4767 crypto adapter with the 4768 crypto adapter.
3. Upgrade the firmware to TKE 9.0.
4. Install the Frame Roll to apply Save Upgrade Data (client data) to the TKE 9.1 system.
5. Run the TKE Workstation Setup wizard.
TKE upgrade considerations
If you are migrating your configuration with Crypto Express5S and TKE Release 8.x to a z14 ZR1, you do not need to upgrade the TKE LIC.
|
Note: A workstation that was upgraded to TKE V8.x includes the 4767 cryptographic adapter that is required to manage Crypto Express5S; however, it cannot be used to manage the Crypto Express6s.
If your z14 ZR1 includes Crypto Express6S, you must upgrade to TKE V9.0, which requires the 4768 cryptographic adapter.
|
Upgrading to TKE V9.0 requires that your TKE hardware is compatible with the 4768 cryptographic adapter. The following older TKE hardware features are compatible 4768 cryptographic adapters:
• FC 0842
• FC 0847
• FC 0097
|
Important: TKE workstations that are at FC 0841 or older do not support the 4767 or 4768 cryptographic adapters.
|
For more information about TKE hardware support, see Table 6-3. For some functionality, requirements must be considered; for example, the characterization of a Crypto Express adapter in EP 11 mode always requires the use of a TKE.
Table 6-3 TKE Compatibility Matrix
|
TKE workstation
|
TKE Release LIC
|
7.2
|
7.3
|
8.0
|
8.1
|
9.0
|
9.1
|
|
HW Feature Code
|
0814
|
08421
|
0847
|
0847 or
0097
|
0085 or
0086
|
0085 or
0086
|
|
|
LICC
|
0850
|
0872
|
0877
|
0878
|
0879
|
0880
|
|
|
Smart Card Reader
|
0885
|
0885
|
0891
|
0891
|
0895
|
0895
|
|
|
Smart Card
|
0884
|
0884
|
0892
|
0892
|
0892
|
0892
|
|
|
Supported systems
|
z14 (any model)
|
|
Seea
|
Yes
|
Yes
|
Yes
|
Yes
|
|
z13
|
|
Seea
|
Yes
|
Yes
|
Yes
|
Yes
|
|
|
z13s
|
|
Seea
|
Yes
|
Yes
|
Yes
|
Yes
|
|
|
zEC12
|
Yes
|
Yes
|
Yes
|
Yes
|
Yes
|
Yes
|
|
|
zBC12
|
|
Yes
|
Yes
|
Yes
|
Yes
|
Yes
|
|
|
Manage Host Crypto Module
|
CEC3C (CCA)
|
Yes
|
Yes
|
Yes
|
Yes
|
Yes
|
Yes
|
|
CEX4C (CCA)
|
Yes
|
Yes
|
Yes
|
Yes
|
Yes
|
Yes
|
|
|
CEX4P (EP11)
|
Yes
|
Yes
|
Yes
|
Yes
|
Yes
|
Yes
|
|
|
CEX5C (CCA)
|
|
Seea
|
Yes
|
Yes
|
Yes
|
Yes
|
|
|
CEX5P (EP11)
|
|
Seea
|
Yes
|
Yes
|
Yes
|
Yes
|
|
|
CEX6C (CCA)
|
|
Seea
|
Yes
|
Yes
|
Yes
|
Yes
|
|
|
CEX6P (EP11)
|
|
Seea
|
Yes
|
Yes
|
Yes
|
Yes
|
1 The TKE workstation FC 0842 that is running LIC V7.3 can be upgraded to TKE LIC V8.x by adding a 4767 cryptographic adapter or to TKE LIC V9.0 by adding a 4786 cryptographic adapter.
|
Attention: The TKE is unaware of the CPC type where the host crypto module is installed. That is, the TKE does not consider whether a Crypto Express is running on a zEC12, zBC12, z13, 13s, or z14 system. Therefore, the LIC can support any CPC where the coprocessor is supported, but the TKE LIC must support the specific crypto module.
|
6.7 Cryptographic functions comparison
The functions or attributes on z14 ZR1 for the two cryptographic hardware features are listed in Table 6-4, where “X” indicates that the function or attribute is supported.
Table 6-4 Cryptographic functions on z14 ZR1
|
Functions or attributes
|
CPACF
|
CEX6C
|
CEX6P
|
CEX6A
|
|
Supports z/OS applications that use CSF
|
X
|
X
|
X
|
X
|
|
Supports Linux on Z CCA applications
|
X
|
X
|
-
|
X
|
|
Encryption and decryption by using secret-key algorithm
|
-
|
X
|
X
|
-
|
|
Provides the highest SSL/TLS handshake performance
|
-
|
-
|
-
|
X
|
|
Supports SSL/TLS functions
|
X
|
X
|
-
|
X
|
|
Provides the highest symmetric (clear key) encryption performance
|
X
|
-
|
-
|
-
|
|
Provides the highest asymmetric (clear key) encryption performance
|
-
|
-
|
-
|
X
|
|
Provides the highest asymmetric (encrypted key) encryption performance
|
-
|
X
|
X
|
-
|
|
Nondisruptive process to enable
|
-
|
X1
|
Xa
|
Xa
|
|
Requires IOCDS definition
|
-
|
-
|
-
|
-
|
|
Uses CHPID numbers
|
-
|
-
|
-
|
-
|
|
Uses PCHIDs (one PCHID)
|
-
|
X
|
X
|
X
|
|
Requires CPACF enablement (FC 3863)
|
X2
|
Xb
|
Xb
|
Xb
|
|
Requires ICSF to be active
|
-
|
X
|
X
|
X
|
|
Offers UDX
|
-
|
X
|
-
|
-
|
|
Usable for data privacy: Encryption and decryption processing
|
X
|
X
|
X
|
-
|
|
Usable for data integrity: Hashing and message authentication
|
X
|
X
|
X
|
-
|
|
Usable for financial processes and key management operations
|
-
|
X
|
X
|
-
|
|
Crypto performance IBM RMF™ monitoring
|
-
|
X
|
X
|
X
|
|
Requires system master keys to be loaded
|
-
|
X
|
X
|
-
|
|
System (master) key storage
|
-
|
X
|
X
|
-
|
|
Retained key storage
|
-
|
X
|
-
|
-
|
|
Tamper-resistant hardware packaging
|
-
|
X
|
X
|
X3
|
|
Designed for FIPS 140-2 Level 4 certification
|
-
|
X
|
X
|
X
|
|
Supports Linux applications that perform SSL handshakes
|
-
|
-
|
-
|
X
|
|
RSA functions
|
-
|
X
|
X
|
X
|
|
High-performance SHA-1, SHA-2, and SHA-3
|
X
|
X
|
X
|
-
|
|
Clear key DES or triple DES
|
X
|
-
|
-
|
-
|
|
Advanced Encryption Standard (AES) for 128-bit, 192-bit, and 256-bit keys
|
X
|
X
|
X
|
-
|
|
True random number generator (TRNG)
|
X
|
X
|
X
|
-
|
|
Deterministic random number generator (DRNG)
|
X
|
X
|
X
|
-
|
|
Pseudo random number generator (PRNG)
|
X
|
X
|
X
|
-
|
|
Clear key RSA
|
-
|
-
|
-
|
X
|
|
Payment Card Industry (PCI) PIN Transaction (PTS) Hardware Security Module (HSM) PCI-HSM
|
|
X
|
|
|
|
Europay, MasterCard, and Visa (EMV) support
|
-
|
X
|
-
|
-
|
|
Public Key Decrypt (PKD) support for Zero-Pad option for clear RSA private keys
|
-
|
X
|
-
|
-
|
|
Public Key Encrypt (PKE) support for Mod_Raised_to Power (MRP) function
|
-
|
X
|
X
|
-
|
|
Remote loading of initial keys in ATM
|
-
|
X
|
-
|
-
|
|
Improved key exchange with non-CCA systems
|
-
|
X
|
-
|
-
|
|
ISO 16609 CBC mode triple DES message authentication code (MAC) support
|
-
|
X
|
-
|
-
|
|
AES GMAC, AES GCM, AES XTS mode, CMAC
|
-
|
X
|
-
|
-
|
|
SHA-2, SHA-3 (384,512), HMAC
|
-
|
X
|
-
|
-
|
|
Visa Format Preserving Encryption
|
-
|
X
|
-
|
-
|
|
AES PIN support for the German banking industry
|
|
|
|
|
|
ECDSA (192, 224, 256, 384, 521 Prime/NIST)
|
-
|
X
|
-
|
-
|
|
ECDSA (160, 192, 224, 256, 320, 384, 512 BrainPool)
|
-
|
X
|
-
|
-
|
|
ECDH (192, 224, 256, 384, 521 Prime/NIST)
|
-
|
X
|
-
|
-
|
|
ECDH (160, 192, 224, 256, 320, 384, 512 BrainPool)
|
-
|
X
|
-
|
-
|
|
PNG (Prime Number Generator)
|
-
|
X
|
-
|
-
|
1 To make adding the Crypto Express features nondisruptive, the logical partition must be predefined with the appropriate PCI Express cryptographic adapter number. This number must be selected from its candidate list in the partition image profile.
2 This feature is not required for Linux if only RSA clear key operations are used. DES or triple DES encryption requires CPACF to be enabled.
3 This feature is physically present, but is not used when configured as an accelerator (clear key only).
6.8 Cryptographic operating system support for z14 ZR1
The following section gives an overview of the operating systems requirements in relation to cryptographic elements.
Crypto Express6S (0893) Toleration
Crypto Express6S (0893) Toleration treats Crypto Express6S cryptographic coprocessors and accelerators as Crypto Express5 coprocessors and accelerators. The following minimum prerequisites must be met:
•z/OS V2.3 with PTFs
•z/OS V2.2 with PTFs
•z/OS V2.1 with PTFs
•z/VM V7.1 for guest use
•z/VM V6.4 with PTFs for guest use
•z/VSE V6.2 with PTFs
•z/VSE V6.1 with PTFs
•z/VSE V5.2 with PTFs
•zTPF V1.1 with PTFs
•Linux on Z: IBM is working with its Linux distribution partners to provide support by way of maintenance or future releases for the following distributions:
– SUSE Linux Enterprise Server 12 and SLES 11
– Redhat Enterprise Linux (RHEL) 7 and Redhat Enterprise Linux 6
– Ubuntu 16.04 LTS (or higher)
•The KVM hypervisor, which is offered with SLES 12 SP2 with service, RHEL 7.5 with kernel-alt package (kernel 4.14) and Ubuntu 16.04 LTS with service and Ubuntu 18.04 LTS with service Linux distributions. For more information about minimal and recommended distribution levels, see the Tested platforms for Linux webpage of the IBM IT infrastructure website.
Crypto Express6S (0893) support of VISA Format Preserving Encryption
The following minimum prerequisites must be met to use this element:
•z/OS V2.3 with PTFs
•z/OS V2.2 with the Enhanced Cryptographic Support for z/OS V1.13-V2.2 web deliverable installed
•z/VM V7.1 for guest use
•z/VM V6.4 with PTFs for guest use
•The KVM hypervisor, which is offered with the following Linux distributions:
– SLES-12 SP2 or higher
– Ubuntu 16.04 LTS or higher
– RHEL 7.5 or higher
For more information about minimal and recommended distribution levels, see the Tested platforms for Linux page of the IBM IT infrastructure website.
Crypto Express6S (0893) support of greater than 16 domains
The following prerequisites must be met to support more than 16 domains:
•z/OS V2.3 with PTFs
•z/OS V2.2 with the Enhanced Cryptographic Support for z/OS V1.13-V2.2 Web deliverable installed
•z/VM V7.1 for guest use
•z/VM V6.4 with PTFs for guest use
•z/VSE V6.2 with PTFs
•z/VSE V6.1 with PTFs
•z/VSE V5.2 with PTFs
•Linux on Z: IBM is working with its Linux distribution partners to provide support by way of maintenance or future releases for the following distributions:
– SLES 12 and SLES 11
– RHEL 7 and RHEL 6
– Ubuntu 16.04 LTS (or higher)
For more information about the software support levels for cryptographic functions, see Chapter 7, “Operating system support” on page 209.
1 FIPS 140-2 Security Requirements for Cryptographic Modules.
2 CPACF enablement feature must be ordered (FC 3863).
3 IBM 4764 PCI-X cryptographic coprocessor.
4 SHA-3 was standardized by NIST in 2015. SHA-2 is still acceptable and no indication exists that SHA-2 is vulnerable or that SHA-3 is more or less vulnerable than SHA-2.
5 Always check the latest information about security certification status for your specific model.
6 CCA 5.4 and 6.1 enhancements are also supported for z/OS V2R1 with ICSF HCR77C1 (WD17) with Small Program Enhancements (SPEs) (z/OS continuous delivery model).
7 TKE 9.x represents 9.0 and 9.1 LIC.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.