Cryptography
This chapter describes the hardware cryptographic functions that are available on the IBM z13. The CP Assist for Cryptographic Function (CPACF) with the Peripheral Component Interconnect Express (PCIe) cryptographic coprocessors offer a balanced use of resources and unmatched scalability.
IBM z13 introduces the new PCI Crypto Express5S feature, which is composed of a redesigned CPACF Coprocessor, an enhanced IBM Common Cryptographic Architecture (CCA), and managed by the new Trusted Key Entry (TKE) workstation. The new function supports new standards and meets the following compliance requirements:
•National Institute of Standards and Technology (NIST) through the Federal Information Processing Standard (FIPS) standard to implement guidance requirements
•Emerging banking standards to strength the cryptographic standards for attack resistance
•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 further in this chapter.
The z13 includes both 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, that is, FIPS 140-2 Level 4.1
The cryptographic functions include the full range of cryptographic operations that are necessary for e-business, e-commerce, and financial institution applications. User Defined Extensions (UDX) allow you to add custom cryptographic functions to the functions that the z13 offers.
Secure Sockets Layer/Transport Layer Security (SSL/TLS) is a key technology for conducting secure e-commerce through web servers. It has been adopted by a rapidly increasing number of applications, demanding new levels of security, performance, and scalability.
This chapter includes the following sections:
6.1 Cryptographic synchronous functions
Cryptographic synchronous functions are provided by the CPACF. The CPACF must be explicitly enabled by using an enablement feature (feature code (FC) 3863) that is available for no additional charge. For IBM and client-written programs, CPACF functions can be started by instructions that are described in z/Architecture Principles of Operation, SA22-7832. As a group, these instructions are known as the Message-Security Assist (MSA). z/OS Integrated Cryptographic Service Facility (ICSF) callable services on z/OS, in-kernel crypto APIs, and a libica cryptographic functions library running on Linux on z Systems also can start CPACF synchronous functions.
The CPACF coprocessor in z13 is redesigned for improved performance compared to the zEC12 by more than two times for large block data, depending on the function that is being used. Here are the tools that 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 Systems: Kernel, openSSL, openCryptoki, and GSKIT
The z13 hardware includes the implementation of algorithms as hardware synchronous operations. This configuration holds the processor unit (PU) processing of the instruction flow until the operation completes. The z13 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 support for SHA-224, SHA-256, SHA-384, and SHA-512
•Message authentication code (MAC):
– Single-length key MAC
– Double-length key MAC
•Pseudo-random Number Generation (PRNG) for cryptographic key generation
|
Requirement: The keys must be provided in clear form only.
|
SHA-1, and SHA-2 support for SHA-224, SHA-256, SHA-384, and SHA-512, are shipped enabled on all servers and do not require the CPACF enablement feature. The CPACF functions are supported by z/OS, z/VM, z/VSE, zTPF, and Linux on z Systems.
6.2 Cryptographic asynchronous functions
Cryptographic asynchronous functions are provided by the optional PCIe cryptographic coprocessors Crypto Express5S (new feature that is available only on z13).
6.2.1 Secure key functions
The following secure key functions are provided as cryptographic asynchronous functions. System internal messages are passed to the cryptographic coprocessors to initiate the operation. The messages then are passed back from the coprocessors to signal completion of the operation:
•Data encryption and decryption algorithms for data protection
Data Encryption Standard (DES):
– Single-length key DES
– Double-length key DES
– Triple-length key DES (Triple-DES)
•DES key generation and distribution
•Personal identification number (PIN) generation, verification, and translation functions
•Random number generator
•Public Key Cryptography Standards (PKCS) #11 functions2
z/OS Integrated Cryptographic Service Facility (ICSF) implements callable services in support of the PKCS #11 standard. Secure IBM Enterprise PKCS #11 (EP11) coprocessor mode implements secure keys for PKCS #11 functions.
•Public key algorithm (PKA) functions
The following supported callable services are intended for application programs that use PKA:
– Importing Rivest-Shamir-Adleman algorithm (RSA) public-private key pairs in clear and encrypted forms
– Rivest-Shamir-Adleman algorithm (RSA):
• Key generation, up to 4096 bit
• Signature generation and verification, up to 4096 bit
• Import and export of DES keys under an RSA key, up to 4096 bit
– Public key encryption (PKE)/Public key decryption (PKD): The PKE and PKD callable services are provided to assist with the SSL/TLS handshake. They are used to offload compute-intensive portions of the protocol onto the cryptographic adapters.
– Europay, MasterCard and Visa (EMV) standard: Applications can be written to comply with the EMV standard for financial transactions between heterogeneous hardware and software. EMV standards were updated to use the improved security properties of EMV contact and contactless cards. ICSF HRC770A improved support of EMV card applications that support American Express cards.
6.2.2 Additional functions
Other key functions of the Crypto Express features serve to enhance the security of the cryptographic processing:
•Remote loading of initial automated teller machine (ATM) keys
This function remotely loads the initial keys for capable ATMs and point-of-sale (POS) systems. Remote key loading is the process of loading DES keys to the ATM from a central administrative site without requiring manually loading keys on each machine. The ANSI X9.24-2 standard3 defines the acceptable methods of performing this task through public key cryptographic techniques. The process uses ICSF callable services with the Crypto Express5S features to perform the remote load.
Trusted Block Create (CSNDTBC) is a callable service that is used to create a trusted block that contains a public key and certain processing rules. The rules define the ways and formats in which keys are generated and exported. Remote Key Export (CSNDRKX) is a callable service that uses the trusted block to generate or export DES keys for local use, and for distribution to an ATM or other remote device. The PKA Key Import (CSNDPKI), PKA Key Token Change (CSNDKTC), and Digital Signature Verify (CSFNDFV) callable services support the remote key loading process.
•Key exchange with non IBM Common Cryptographic Architecture (CCA) cryptographic systems
This function allows the exchange of operational keys between the Crypto Express5S coprocessors and non-CCA systems, such as ATMs. CCA employs control vectors to control the usage of cryptographic keys. Non-CCA systems use other mechanisms, or can use keys that have no associated control information. Enhancements to key exchange functions allow the CCA to exchange keys between CCA systems and systems that do not use control vectors. It allows the CCA system owner to define permitted types of keys to be imported and exported while preventing uncontrolled key exchange that can open the system to an attack.
•Elliptic Curve Cryptography (ECC) Digital Signature Algorithm support
Elliptic Curve Cryptography is an emerging public-key algorithm that is intended to replace RSA cryptography in many applications. ECC provides digital signature functions and key agreement functions. The CCA functions provide ECC key generation and key management. They also provide digital signature generation and verification functions that are compliant with the Elliptic Curve Digital Signature Algorithm (ECDSA) method. For more information, see ANSI X9.624 “Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)”. ECC uses keys that are shorter than RSA keys for equivalent strength-per-key-bit. So, the strength-per-key-bit is substantially greater in an algorithm that uses elliptic curves.
This cryptographic function is supported by z/OS, z/VM, and Linux on z Systems.
•Elliptic Curve Diffie-Hellman (ECDH) algorithm support
The Common Cryptographic Architecture is extended to include the ECDH algorithm.
ECDH is a key agreement protocol that allows two parties, each having an elliptic curve public-private key pair to establish a shared secret over an insecure channel. This shared secret can be used directly as a key. It also can be used to derive another key that can then be used to encrypt subsequent communications that use a symmetric key cipher, such as AES key-encrypting key (KEK).
ECDH includes these enhancements:
– Key management function to support AES KEK
– Generating an ECC private key that is wrapped within an AES KEK
– Importing and exporting an ECC private key that is wrapped within an AES KEK
– Support for ECDH with a new service
•User-Defined Extensions (UDX) support
UDX allows the user to add customized operations to a cryptographic coprocessor. User-Defined Extensions 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 CryptoCards 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. The contract is 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 z Systems is tied to specific versions of the CCA card code and the related host code. UDX is available for the Crypto Express5S (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 z13, you can import up to four UDX files. These files can be imported only from a DVD. The UDX configuration window is updated to include a Reset to IBM Default button.
|
Consideration: CCA has a new code level at z13, and the UDX clients require a new UDX.
|
For more information, see the IBM CryptoCards website:
6.3 CPACF protected key
The z13 supports the protected key implementation. Since PCIXCC5 deployment, secure keys are processed on the PCI-X and PCIe cards. This process requires an asynchronous operation to move the data and keys from the general-purpose central processor (CP) to the crypto cards. Clear keys process faster than secure keys because the process is done synchronously on the CPACF. Protected keys blend the security of Crypto Express5S coprocessors and the performance characteristics of the CPACF. This process allows it to run closer to the speed of clear keys.
An enhancement to CPACF facilitates the continued privacy of cryptographic key material when used for data encryption. In Crypto 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. There is no customizable option available at SE or HMC that permits or avoids the wrapping key generation. Figure 6-1 shows this function flow.
Figure 6-1 CPACF key wrapping
If a Crypto 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 using the PCKMO instruction to wrap the key. ICSF is not called by the application if the Crypto Express5S 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 described in Figure 6-1 considers a secure key as being the source of a protected key.
The source key in this case already is stored in the ICSF Cryptographic Key Data Set (CKDS) as a secure key (encrypted under the master key). This secure key is sent to Crypto Express5S to be deciphered, and 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/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 HCR7770 as a minimum release.
6.4 PKCS #11 overview
Public Key Cryptography Standards (PKCS) #11 is one of the industry-accepted standards. It is provided by RSA Laboratories of RSA Security Inc. PKCS #11 specifies an application programming interface (API) to devices, referred to as tokens, that hold cryptographic information and run cryptographic functions. PKCS #11 provides an alternative to IBM CCA.
PKCS #11 describes the cryptographic token interface standard and its API, which also is known as the Cryptographic Token Interface (Cryptoki). It is a de facto industry standard on many computing platforms today. It is a higher-level API compared to CCA, and it is easier to use by C language-based applications. The persistent storage and retrieval of objects are part of the standard. The objects are certificates, keys, and application-specific data objects.
6.4.1 PKCS #11 model
On most single-user systems, a token is a smart card or other plug-installed cryptographic device that is accessed through a card reader or slot. Cryptoki provides a logical view of slots and tokens. This view makes each cryptographic device look logically like every other device regardless of the technology that is used. The PKCS #11 specification assigns numbers to slots, which are known as slot IDs. An application identifies the token that it wants to access by specifying the appropriate slot ID. On systems that have multiple slots, the application determines which slot to access.
The PKCS #11 logical view of a token is a device that stores objects and can run cryptographic functions. PKCS #11 defines three types of objects:
•A data object that is defined by an application.
•A certificate object that stores a digital certificate.
•A key object that stores a cryptographic key. The key can be a public key, a private key, or a secret key.
Objects also are classified according to their lifetime and visibility:
•Token objects are visible to all applications that are connected to the token that have sufficient permission. They remain on the token even after the sessions are closed and the token is removed from its slot. Sessions are connections between an application and the token.
•Session objects are more temporary. When a session is closed by any means, all session objects that were created by that session are automatically deleted. Furthermore, session objects are visible only to the application that created them.
Attributes are characteristics that distinguish an instance of an object. General attributes in PKCS #11 distinguish, for example, whether the object is public or private. Other attributes are specific to a particular type of object, such as a Modulus or exponent for RSA keys.
The PKCS #11 standard was designed for systems that grant access to token information based on a PIN. The standard recognizes two types of token user:
•Security officer (SO)
•Standard user (USER)
The role of the SO is to initialize a token (zeroize the content) and set the user’s PIN. The SO can also access public objects on the token but not private ones. The USER can access private objects on the token. Access is granted only after the user is authenticated. Users can also change their own PINs. However, users cannot re-initialize a token.
The PKCS #11 general model components are represented in Figure 6-2:
•Token: Logical view of a cryptographic device, such as a smart card or hardware security module (HSM)
•Slot: Logical view of a smart card reader
•Objects: Items that are stored in a token, such as digital certificates and cryptographic keys
•User: The owner of the private data on the token, who is identified by the access PIN
•Security Officer: Person who initializes the token and the USER PIN
Figure 6-2 The PKCS #11 general model
6.4.2 z/OS PKCS #11 implementation
ICSF supports the PKCS #11 standard, increasing the number of cryptographic applications that use z Systems cryptography. PKCS #11 support was introduced in ICSF FMID HCR7740 within z/OS V1R9. ICSF has full support for the Crypto Express5S in the ICSF FMID of HCR77B0. Toleration support for HCR7780 through HCR77A1 is through APAR OA45547. APAR OA42011 introduces migration health checks to help with HCR77A1 migration and updates ICSF documentation. See APAR OA43493 for information about IBM Enhanced RMF™ support for Crypto Express5S.
On z/OS, PKCS #11 tokens are not physical cryptographic devices, but virtual smart cards. New tokens can be created at any time. The tokens can be application-specific or system-wide, depending on the access control definitions that are used instead of PINs. The tokens and their contents are stored in a new ICSF VSAM data set, the Token Key Data Set (TKDS). The TKDS serves as the repository for cryptographic keys and certificates that are used by PKCS #11 applications.
z/OS provides several facilities to manage tokens:
•A C language API that implements a subset of the PKCS #11 specification.
•Token management ICSF callable services, which are also used by the C API.
•The ICSF ISPF window, called Token Browser, that allows you to see a formatted view of TKDS objects and make minor, limited updates to them.
•The RACF RACDCERT command supports the certificate, public key, and private key objects, and provides subfunctions to manage these objects together with tokens.
•The gskkyman command supports management of certificates and keys similar to the way that RACFDCERT does.
ICSF supports PKCS #11 session objects and token objects. Session objects exist in memory only. They are not maintained on the direct access storage device (DASD). An application has only one session objects database, even if the application creates multiple PKCS #11 sessions.
Token objects are stored in the TKDS with one record per object. They are visible to all applications that have sufficient permission to the token. The objects are persistent and remain associated with the token even after a session is closed.
The PKCS #11 standard was designed for systems that grant access to token information based on a PIN. z/OS does not use PINs. Instead, profiles in the SAF CRYPTOZ class control access to tokens. Each token has two resources in the CRYPTOZ class:
•The resource USER.token-name controls the access of the user role to the token.
•The resource SO.token-name controls the access of the SO role to the token.
A user’s access level to each of these resources (read, update, and control) determines the user’s access level to the token. Figure 6-3 shows the concepts that were introduced by the PKCS #11 model to the z/OS PKCS #11 implementation.
Figure 6-3 Mapping the PKCS #11 model to the z/OS PKCS #11 implementation
Tokens
The PKCS #11 tokens on z/OS are virtual, and are similar to RACF (SAF) key rings. An application can have one or more z/OS PKCS #11 tokens, depending on its requirements. z/OS PKCS #11 tokens are created by using system software, such as RACF, the gskkyman utility, or applications that use the C API. Also, ICSF windows can be used for token management with limited usability.
Each token has a unique token name or label that is specified by the user or application when the token is created. Like z/OS PKCS #11 token creation, the PKCS #11 tokens can be deleted by using the same system software tools that are used to create them.
Token Key Data Set (TKDS)
The TKDS is a VSAM data set that serves as the repository for cryptographic keys and certificates that are used by z/OS PKCS #11 applications. Before an installation can run PKCS #11 applications, the TKDS must be created. The ICSF installation options data set must then be updated to identify the name of the TKDS data set. To optimize performance, ICSF creates a data space that contains an in-storage copy of the TKDS.
|
Important: Until ICSF FMID HCR7790, keys in the TKDS were not encrypted. Therefore, the RACF profile must be created to protect the TKDS from unauthorized access.
|
6.4.3 Secure IBM Enterprise PKCS #11 (EP11) Coprocessor
The IBM Enterprise PKCS #11 Licensed Internal Code (LIC) implements an industry standardized set of services. These services adhere to the PKCS #11 specification V2.20 and more recent amendments. It is designed to meet the Common Criteria (EAL 4+) and FIPS 140-2 Level 4 certifications. It conforms to the Qualified Digital Signature (QDS) Technical Standards that are mandated by the European Union.
The PKCS #11 secure key support is provided by the Crypto Express5S card that is configured in Secure IBM Enterprise PKCS #11 (EP11) coprocessor mode. Before EP11, the ICSF PKCS #11 implementation supported only clear keys, and the key protection was provided only by RACF CRYPTOZ class protection. In EP11, keys now can be generated and securely wrapped under the EP11 Master Key. The secure keys never leave the secure coprocessor boundary unencrypted.
The Crypto Express5S firmware has a unique code for EP11 that is separate from the CCA code. Crypto Express5S with EP11 configuration is known as CEX5P. There is no change in the domain configuration in the LPAR activation profiles. The configuration selection is run in the Cryptographic Configuration window on the Support Element (SE). A coprocessor in EP11 mode is configured off after being zeroized.
|
Important: The TKE workstation is required for the management of the Crypto Express5S features when defined as an EP11 coprocessor.
|
6.5 Cryptographic feature codes
Table 6-1 lists the cryptographic features that are available.
Table 6-1 Cryptographic features for zEnterprise CPC
|
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 Crypto Express features.
|
|
0890
|
Crypto Express5S feature:
A maximum of 16 features can be ordered (minimum of two adapters). This is an optional feature, and each feature contains one PCI Express cryptographic adapters (adjunct processors). This feature is supported only in z13,
|
|
0847
|
TKE workstation:
This feature is optional. TKE provides basic key management (key identification, exchange, separation, update, and backup) and security administration. 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 z13 can be installed.
|
|
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. Smart card part 74Y0551 is required to support CEX5P.
|
|
0892
|
TKE additional smart cards:
When one feature code is ordered, 10 smart cards are shipped. The order increment is 1 - 99 (990 blank smart cards). Smart cards 74Y0551 and 54D3338 can be used. A new card 00JA710 will be released because of the end of life of 74Y0551.
|
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 Express features in a z13, a TKE workstation with the TKE 8.0 LIC is required. For more information, see 6.9, “TKE workstation feature” on page 217.
|
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.
|
6.6 CP Assist for Cryptographic Function (CPACF)
The CPACF offers a set of symmetric cryptographic functions that enhance the encryption and decryption performance of clear key operations. These functions are for Secure Sockets Layer (SSL), virtual private network (VPN), and data-storing applications that do not require Federal Information Processing Standard (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.3, “CPACF protected key” on page 202.
The CPACF feature provides hardware acceleration for DES, Triple-DES, MAC, AES-128, AES-192, AES-256, SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 cryptographic services. It provides high-performance hardware encryption, decryption, and hashing 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 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 functions of the CPACF must be explicitly enabled by using FC 3863 during the manufacturing process or at the client site as an MES installation. The exceptions are SHA-1, and SHA-2 support for SHA-224, SHA-256, SHA-384, and SHA-512, which are always enabled.
6.7 Crypto Express5S
The Crypto Express5S feature (FC 0890) is an optional z13 exclusive feature. Each feature has one PCIe cryptographic adapter. The Crypto Express5S feature occupies one I/O slot in a z13 PCIe I/O drawer. This feature 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 Express5S feature provides tamper-sensing and tamper-responding, high-performance cryptographic operations.
|
Firmware version: Crypto Express5S is running the new CCA V5.0 firmware.
|
Each Crypto Express5S PCI Express adapter can be in one of these configurations:
•Secure IBM CCA coprocessor (CEX5C) 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.
•Secure IBM Enterprise PKCS #11 (EP11) coprocessor (CEX5P) implements an industry-standardized set of services that adhere 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.
A TKE workstation is required to support the administration of the Crypto Express5S when it is configured in EP11 mode.
•Accelerator (CEX5A) for acceleration of public key and private key cryptographic operations that are used with SSL/Transport Layer Security (TLS) processing.
These modes can be configured by using the SE, and the PCIe adapter must be configured offline to change the mode.
|
Remember: Switching between configuration modes erases all card secrets. The exception is when you are switching from Secure CCA to accelerator, and vice versa.
|
The Crypto Express5S uses the IBM 4765 PCIe Coprocessor.6 The Crypto Express5S feature does not have external ports and does not use fiberoptic 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 card 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 have no CHPID type and are not identified as external channels, all logical partitions (LPARs) in all channel subsystems have access to the adapter. There are up to 85 LPARs per adapter. Having access to the adapter requires a setup in the image profile for each partition. The adapter must be in the candidate list.
|
Each z13 supports up to 16 Crypto Express5S features. Table 6-2 shows configuration information for Crypto Express5S.
Table 6-2 Crypto Express5S features
|
Feature
|
Quantity
|
|
Minimum number of orderable features for each server1
|
2
|
|
Order increment above two features
|
1
|
|
Maximum number of features for each server
|
16
|
|
Number of PCIe cryptographic adapters for each feature
(coprocessor or accelerator)
|
1
|
|
Maximum number of PCIe adapters for each server
|
16
|
|
Number of cryptographic domains for each PCIe adapter2
|
85
|
1 The minimum initial order of Crypto Express5S features is two. After the initial order, more Crypto Express5S 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 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 CPs in the partition.
When installed non-concurrently, Crypto Express5S features are assigned PCIe cryptographic adapter numbers sequentially during the power-on reset (POR) that follows the installation. When a Crypto Express5S feature is installed concurrently, the installation can select an out-of-sequence number from the unused range. When a Crypto Express5S 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:
•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 85). For example, you might define a configuration for backup situations. However, only one of the LPARs can be active at a time.
6.8 Tasks that are run by PCIe Crypto Express5S
The Crypto Express features running in a z13 support all cryptographic functions that were introduced on zEnterprise CPC:
•Expanded key support for the AES algorithm
CCA supports the AES algorithm so that AES keys can encrypt data. Expanded key support for AES adds a framework to support a much broader range of application areas. It also lays the groundwork for future use of AES in areas where standards and client applications are expected to change.
As stronger algorithms and longer keys become increasingly common, security requirements dictate that these keys must be wrapped by using KEKs of sufficient strength. This feature adds support for AES KEKs. These AES wrapping keys have adequate strength to protect other AES keys for transport or storage. This support introduced AES key types that use the variable length key token. The supported key types are EXPORTER, IMPORTER, and for use in the encryption and decryption services, CIPHER.
•Enhanced ANSI TR-31 interoperable secure key exchange
ANSI TR-31 defines a method of cryptographically protecting Triple Data Encryption Standard (3DES) cryptographic keys and their associated usage attributes. The TR-31 method complies with the security requirements of the ANSI X9.24 Part 1 standard. However, use of TR-31 does not require you to comply with that standard. CCA has added functions that can be used to import and export CCA TDES keys in TR-31 formats. These functions are designed primarily as a secure method of wrapping TDES keys for improved and more secure key interchange between CCA and non-CCA devices and systems.
•PIN block decimalization table protection
To help avoid a decimalization table attack, which can be used to learn a PIN, a solution is now available in the CCA to thwart this attack by protecting the decimalization table from manipulation. PINs are most often used for ATMs, but are increasingly used at point-of sale (POS) devices for debit and credit cards.
•ANSI X9.8 PIN security
This function facilitates compliance with the processing requirements that are defined in the new version of the ANSI X9.8 and ISO 9564 PIN Security Standards. It provides added security for transactions that require PINs.
•Enhanced CCA key wrapping to comply with ANSI X9.24-1 key bundling requirements
This support allows that CCA key token wrapping method to use cipher block chaining (CBC) mode in combination with other techniques to satisfy the key bundle compliance requirements. The standards include ANSI X9.24-1 and the recently published Payment Card Industry Hardware Security Module (PCI HSM) standard.
•Secure key hashed message authentication code (HMAC)
HMAC is a method for computing a message authentication code by using a secret key and a secure hash function. It is defined in the standard FIPS 198, “The Keyed-Hash Message Authentication Code (HMAC)”7. The CCA function supports HMAC by using SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 hash algorithms. The HMAC keys are variable length and are securely encrypted so that their values are protected. This Crypto function is supported by z/OS, z/VM, and Linux on z Systems.
6.8.1 PCIe Crypto Express5S as a CCA coprocessor
The PCIe Crypto Express5S coprocessors enable the user to perform the following tasks:
•Encrypt and decrypt data by using secret-key algorithms. Triple-length key DES, double-length key DES, and AES algorithms are supported.
•Generate, install, and distribute cryptographic keys securely by using both public and secret-key cryptographic methods that generate, verify, and translate PINs.
•Crypto Express5S coprocessors support 13-digit through 19-digit personal account numbers (PANs).
•Ensure the integrity of data by using message authentication codes (MACs), hashing algorithms, and RSA PKA digital signatures, and ECC digital signatures
The Crypto Express5S coprocessors also provide the functions that are listed for the Crypto Express5S accelerator. However, they provide a lower performance than the Crypto Express5S accelerator can provide.
Three methods of master key entry are provided by ICSF for the Crypto Express5S feature coprocessors:
•A passphrase initialization method, which generates and enters all master keys that are necessary to fully enable the cryptographic system in a minimal number of steps
•A simplified master key entry procedure that is provided through a series of Clear Master Key Entry windows from a TSO terminal
•A TKE workstation, which is available as an optional feature in enterprises that require enhanced key-entry security
Linux on z Systems also permits the master key entry through windows or through the TKE workstation.
The security-relevant portion of the cryptographic functions is run inside the secure physical boundary of a tamper-resistant card. Master keys and other security-relevant information are also maintained inside this secure boundary.
The Processor Resource/System Manager (PR/SM) fully supports the Crypto Express5S coprocessor features to establish a logically partitioned environment on which multiple LPARs can use the cryptographic functions. The following keys are provided for each of the
85 cryptographic domains that a cryptographic adapter can serve:
85 cryptographic domains that a cryptographic adapter can serve:
•A 128-bit data-protection symmetric master key
•A 256-bit AES master key
•A 256-bit ECC master key
•One 192-bit PKA master key
Use the dynamic addition or deletion of an LPAR name to rename an LPAR. Its name can be changed from NAME1 to * (single asterisk) and then changed again from * to NAME2. The LPAR number and multiple image facility (MIF) ID are retained across the LPAR name change. The master keys in the Crypto Express feature coprocessor that were associated with the old LPAR NAME1 are retained. No explicit action is taken against a cryptographic component for this dynamic change.
|
Coprocessors: Cryptographic coprocessors are not tied to LPAR numbers or MIF IDs. They are set up with PCIe adapter numbers and domain indexes that are defined in the partition image profile. You can dynamically configure them to a partition, and change or clear them when needed.
|
6.8.2 PCIe Crypto Express5S as an EP11 coprocessor
A Crypto Express5S card that is configured in Secure IBM Enterprise PKCS #11 (EP11) coprocessor mode provides PKCS #11 secure key support. 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 unencrypted.
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, SHA224, SHA256, SHA384, and SHA512)
•Digest (SHA1, SHA224, SHA256, SHA384, and SHA512)
•Wrap and unwrap keys
•Random number generation
•Get mechanism list and information
•Attribute values
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 Express5S feature.
6.8.3 PCIe Crypto Express as an accelerator
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. This reconfiguration has the following characteristics:
•It is done through the SE.
•It is done at the PCIe cryptographic adapter level. A Crypto Express3 feature can host a coprocessor and an accelerator, two coprocessors, or two accelerators.
•It works both ways, from coprocessor to accelerator and from accelerator to coprocessor. Master keys in the coprocessor domain can be optionally preserved when it is reconfigured to be an accelerator.
•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 Express 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 bits to 4,096 bits, in the Modulus-Exponent (ME) and Chinese Remainder Theorem (CRT) formats.
6.8.4 IBM Common Cryptographic Architecture enhancements
A new set of cryptographic functions and callable services are provided by the IBM CCA LIC to enhance the functions that secure financial transactions and keys:
•Greater than 16 domains support, up to 85 LPARs, and exclusive to z13
•Visa Format Preserving Encryption (FPE) support, exclusive to z13 and Crypto Express5S
•AES PIN support for the German banking industry
•PKA Translate UDX function into CCA
Greater than 16 domains support
z13 has support for up to 85 LPARs. The z Systems crypto architecture was designed to support 16 domains (which matched the LPAR maximum at the time). In current customer environments where the number of LPARs is larger than 16, crypto workload separation can be complex. These customers must map a large set of LPARs to a small set of crypto domains.
Now, in z13, with the adjunct processor (AP) extended addressing (APXA) facility that is installed, the z Systems crypto architecture can support up to 256 domains in an AP. As such, the Crypto Express cards are enhanced to handle 256 domains, and the z Systems firmware provides up to 85 domains to customers (to match the current LPAR maximum). Customers have the flexibility of mapping individual LPARs to unique crypto domains or continuing to share crypto domains across LPARs.
Here are the requirements to support 85 domains:
•Hardware requirements:
– zNext with the following CCA Support on the following features:
• Crypto Express 4 (CEX4) with CCA V4.5 firmware
• Crypto Express 5 (CEX5) with CCA V5.0 firmware
•Software requirements:
– z/OS V2.1 and z/OS V1.13 with the Cryptographic Support for z/OS V1R13-z/OS V2R1 web deliverable (Function Module ID (FMID) HCR77B0)
– Also available with HCR7780, HCR7790, HCR77A0, and HCR77A1 (previous WDs with PTFs)
– z/VM V6.2 and Version 6.3 with PTFs for guest use
Visa Format Preserving Encryption (FPE)
Visa FPE refers to a method of encryption where the resulting cipher text has 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 using FPE to encrypt a credit card number, the resulting cipher text is another 16-digit number. This helps legacy databases contain encrypted data of sensitive fields without having to restructure the database or applications.
FPE 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 the above example, if the credit card number is FPE-encrypted at the point of entry, the cipher text still behaves like a credit card number. It can flow through business logic until it meets that back-end transaction server that can FPE-decrypt it to get the original credit card number to process the transaction.
Here are the FPE requirements:
•CCA V5.0, which is available on Crypto Express5S on z13.
•Software requirements:
– 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 V6.2 and Version 6.3 with PTFs for guest use
AES PIN support for the German banking industry
The German banking industry organization, DK, has 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.
Here are the requirements for AES PIN support:
•CCA V4.4:
– Available on Crypto Express5S (on z13)
– Available on Crypto Express4S (on zEC12 and zBC12)
– Available on Crypto Express3 (on zEC12, zBC12, z196, and z114)
•Software requirements:
– z/OS V2.1 with the Cryptographic Support for z/OS V1R13-z/OS V2R1 web deliverable (FMID HCR77A1) with PTFs
– z/OS V2.1 (FMID HCR77A0) with PTFs
– z/OS V1.13 with the Cryptographic Support for z/OS V1R13-z/OS V2R1 web deliverable (FMID HCR77A1) with PTFs
– z/OS V1.12 or z/OS V1.13 with the Cryptographic Support for z/OS V1R12-V1R13 web deliverable (FMID HCR77A0) with PTFs
– z/VM Version 6.2, and Version 6.3 with PTFs for guest use
PKA Translate UDX function into CCA
UDX is custom code that allows the client to add unique operations/extensions to the CCA firmware. Certain UDX functions are integrated into the base CCA code over time to accomplish the following tasks:
•Removes headaches and pain points that are associated with UDX management and currency.
•Popular UDX functions are made available 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 either CBC or ECB mode. In addition, AES CMAC Support is delivered.
Here are the requirements for this function:
•CCA V4.4:
– Crypto Express5S (on z13)
– Crypto Express4S (on zEC12 and zBC12)
– Crypto Express3 (on zEC12, zBC12, z196, and z114)
•Software requirements:
– z/OS V2.1 with the Cryptographic Support for z/OS V1R13-z/OS V2R1 web deliverable (FMID HCR77A1) with PTFs
– z/OS V2.1 (FMID HCR77A0) with PTFs
– z/OS V1.13 with the Cryptographic Support for z/OS V1R13-z/OS V2R1 web deliverable (FMID HCR77A1) with PTFs
– z/OS V1.12 or V1.13 with the Cryptographic Support for z/OS V1R12-V1R13 web deliverable (FMID HCR77A0) with PTFs
– z/OS V1.12 or V1.13 with the Cryptographic Support for z/OS V1R11-V1R13 web deliverable (FMID HCR7790) with PTFs
– z/VM Version 6.2, and Version 6.3 with PTFs for guest use
6.9 TKE workstation feature
The TKE workstation is an optional feature that offers key management functions. A new TKE workstation feature (FC 0847) is required for z13 to manage the new Crypto Express5S feature, which supports the new CCA enhancements.
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 (FC 0847) requires a new crypto adapter, IBM 4767.
|
Adapters: The TKE workstation supports Ethernet adapters only when connecting to a LAN.
|
A TKE workstation is part of a customized solution for using 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 z13 that has Crypto Express features installed. It is configured for DES, AES, ECC, and PKA cryptographic keys.
The TKE provides a secure, remote, and flexible method of providing Master Key Part Entry, and to manage remotely PCIe cryptographic coprocessors. The cryptographic functions on the TKE are run by one PCIe cryptographic coprocessor. The TKE workstation communicates with the z Systems server through a TCP/IP connection. The TKE workstation is available with Ethernet LAN connectivity only. Up to 10 TKE workstations can be ordered. TKE FC 0847 can be used to control the z13. It also can be used to control the zEC12, zBC12, z196, z114, z10 EC, z10 BC, z9 EC, z9 BC, z990, and z890 servers.
6.9.1 TKE workstation with Licensed Internal Code 7.0
The TKE workstation (FC 0841) with LIC 7.0 offers many enhancements:
•ECC master key support
ECC keys are protected by using a new ECC master key (256-bit AES key). From the TKE workstation, administrators can generate key material, load or clear the new ECC master key register, and clear the old ECC master key register. The ECC key material can be stored on the TKE workstation or on a smart card.
•CBC default settings support
The TKE workstation provides a function that allows the TKE user to set the default key wrapping method that is used by the host Crypto module.
•TKE Audit Record Upload Configuration Utility support
The TKE Audit Record Upload Configuration Utility allows TKE workstation audit records to be sent to a z Systems host. They are then saved on the host as z/OS System Management Facilities (SMF) records. The SMF records have a record type of 82 (ICSF) and a subtype of 29. TKE workstation audit records are sent to the same TKE Host Transaction Program that is used for TKE operations.
•USB flash memory drive support
The TKE workstation now supports a USB flash memory drive as a removable media device. When a TKE application displays media choices, you can choose a USB flash memory drive if the IBM supported drive is plugged into a USB port on the TKE. The drive must be formatted for the specified operation.
•Stronger PIN strength support
TKE smart cards that are created on TKE 7.0 require a 6-digit PIN rather than a 4-digit PIN. TKE smart cards that were created before TKE 7.0 continue to use 4-digit PINs, and work on TKE 7.0 without changes. Take advantage of the stronger PIN strength by initializing new TKE smart cards and copying the data from the old TKE smart cards to the new smart cards.
•Stronger password requirements for TKE passphrase user profile support
New rules are required for the passphrase that is used for the passphrase logon to the TKE workstation crypto adapter. The passphrase must meet the following requirements:
– Be 8 - 64 characters long
– Contain at least two numeric and two non-numeric characters
– Not contain the user ID
These rules are enforced when you define a new user profile for passphrase logon, or when you change the passphrase for an existing profile. Your current passphrases continue to work.
•Simplified TKE usability with Crypto Express migration wizard
A wizard is now available to allow users to collect data, including key material, from a Crypto Express coprocessor and migrate the data to a different Crypto Express coprocessor. The target Crypto Express coprocessor must have the same or greater capabilities. This wizard helps migrate from Crypto Express2 to Crypto Express3. Crypto Express2 is not supported on the zEC12, IBM zEnterprise 196 (z196), and z114. The following benefits are obtained when you use this wizard:
– Reduces migration steps, minimizing user errors
– Minimizes the number of user clicks
– Reduces migration task duration significantly
6.9.2 TKE workstation with Licensed Internal Code 7.1
The TKE workstation (FC 0841) with LIC 7.1 offers these enhancements:
•New access control support for all TKE applications
Every TKE application and the ability to create and manage the crypto module and domain groups now require the TKE local cryptographic adapter profile to have explicit access to the TKE application or function that you want to run. This change was made to provide more control of the functions that TKE users are allowed to perform.
•New migration utility
During a migration from a lower release of TKE to TKE 7.1 LIC, you must add access control points to the existing roles. The new access control points can be added through the new Migrate Roles Utility or by manually updating each role through the Cryptographic Node Management Utility. The IBM-supplied roles that are created for TKE 7.1 LIC have all of the access control points that are needed to run the functions that are permitted in TKE releases before TKE 7.1 LIC.
•Single process for loading an entire key
The TKE workstation now has a wizard-like feature that takes users through the entire key loading procedure for a master or operational key. The feature preserves all of the existing separation of duties and authority requirements for clearing, loading key parts, and completing a key. The procedure saves time by guiding users through the key loading procedure. However, this feature does not reduce the number of people that are required to perform the key load procedure.
•Single process for generating multiple key parts of the same type
The TKE workstation now has a wizard-like feature that allows a user to generate more than one key part at a time. The procedure saves time because the user must start the process only once, and the TKE workstation efficiently generates the wanted number of key parts.
•AES operational key support
CCA V4.2 for the Crypto Express feature includes three new AES operational key types. From the TKE workstation, users can load and manage the new AES EXPORTER, IMPORTER, and CIPHER operational keys from the TKE workstation crypto module notebook.
•Decimalization table support
CCA V4.2 for the Crypto Express feature includes support for 100 decimalization tables for each domain on a Crypto Express feature. From the TKE workstation, users can manage the decimalization tables on the Crypto Express feature from the TKE workstation crypto module notebook. Users can manage the tables for a specific domain, or manage the tables of a set of domains if they are using the TKE workstation Domain Grouping function.
•Host cryptographic module status support
From the TKE workstation crypto module notebook, users can display the status of the host cryptographic module that is being managed. If they view the Crypto Express feature module information from a crypto module group or domain group, they see only the status of the group’s master module.
•Display of active IDs on the TKE console
A user can be logged on to the TKE workstation in privileged access mode. In addition, the user can be signed onto the TKE workstation’s local cryptographic adapter. If a user is signed on in privileged access mode, that ID is shown on the TKE console. With this new support, both the privileged access mode ID and the TKE local cryptographic adapter ID are displayed on the TKE console.
•Increased number of key parts on smart card
If a TKE smart card is initialized on a TKE workstation with a 7.1 level of LIC, it can hold up to 50 key parts. Previously, TKE smart cards held only 10 key parts.
•Use of ECDH to derive shared secret
When the TKE workstation with a 7.1 level of LIC exchanges encrypted material with a Crypto Express card at CCA level V4.2, ECDH is used to derive the shared secret. This process increases the strength of the transport key that is used to encrypt the material.
6.9.3 TKE workstation with Licensed Internal Code 7.2
The TKE workstation (FC 0841) with LIC 7.2 offers even more enhancements:
•Support for the Crypto Express4S feature when configured as an EP11 coprocessor
The TKE workstation is required to manage a Crypto Express4S feature that is configured as an EP11 coprocessor. Domain grouping between Crypto Express4S features that are defined only as EP11 is allowed. The TKE smart card reader (FC 0885) is mandatory.
EP11 requires the use of the new smart card part 74Y0551 (FC 0884 and FC 0885). The new smart card can be used for any of the six types of smart cards that are used on TKE. Two items must be placed on the new smart cards:
– Master key material: The Crypto Express4S feature has master keys for each domain. The key material must be placed on a smart card before the key material can be loaded.
– Administrator signature keys: When commands are sent to the Crypto Express4S feature, they must be signed by administrators. Administrator signature keys must be on smart cards.
•Support for the Crypto Express4S feature when configured as a CCA coprocessor
Crypto Express4S (defined as a CCA coprocessor) is managed the same way as any other CCA configured coprocessor. A Crypto Express4S can be in the same crypto module group or domain group as a Crypto Express4S, Crypto Express3, and Crypto Express2 feature.
•Support for 24-byte DES master keys
CCA supports both 16-byte and 24-byte DES master keys. The DES master key length for a domain is determined by a new domain control bit that can be managed by using the TKE.
Two Access Control Points (ACPs) allow the user to choose between warning about or prohibiting the loading of a weak master key. The latest CCA version is required.
•Protection of generated RSA keys with AES importer keys
TKE-generated RSA keys are encrypted by AES keys before they are sent to z Systems. It allows the generation of 2046-bit and 4096-bit RSA keys for target crypto card use.
•New DES operational keys
Four new DES operational keys can be managed from the TKE workstation (FC 0841). The DES keys can be any of the following types:
– CIPHERXI
– CIPHERXL
– CIPHERXO
– DUKPT-KEYGENKY
The new keys are managed the same way as any other DES operational key.
•New AES CIPHER key attribute
A new attribute, “key can be used for data translate only,” can be specified now when you create an AES CIPHER operational key part.
•Creation of corresponding keys allowed
In certain cases, operational keys must be loaded to different host systems to serve an opposite purpose. For example, one host system needs an exporter KEK, and another system needs a corresponding importer KEK with the same value. The TKE workstation now allows nine types of key material to be used for creating a corresponding key.
•Support for four smart card readers
The TKE workstation supports two, three, or four smart card readers when smart cards are used. The additional readers are added to help reduce the number of smart card swaps that are needed when you manage EP11-configured coprocessors. EP11 can be managed with only two smart card readers. CCA-configured coprocessors can be managed with three or four smart card readers.
6.9.4 TKE workstation with Licensed Internal Code 7.3
The following functions are supported in TKE workstations with LIC 7.3:
•Full-function migration wizard for EP11: The full-function migration wizard is designed to collect and quickly and accurately apply data to the Crypto Express features that are configured as EP11 coprocessors. This wizard previously supported CCA, and now is enhanced also to support EP11.
•Workstation setup wizard: The setup wizard performs the most common TKE workstation initialization functions, ensuring speed and accuracy of new TKE hardware deployment. It simplifies the process while greatly reducing errors. The wizard also can be run to verify that the TKE workstation is configured correctly.
•Allow Set Master Key from the TKE workstation: Initially setting or changing any type of master key on a Crypto Express feature must be done carefully. If a master key is set or changed when keystores are not properly prepared for the new master key, the keys in the store become unusable. In an initial setup or recovery situation, establishing or changing the master key quickly is critical. You can use the TKE workstation to set any master key from the TKE workstation. The Crypto Express feature is intended for initial setup or recovery situations where keystores are prepared for the master key that will be set by the TKE workstation.
•Restricted PIN support: The latest CCA enhancements are designed to allow users to prevent the automatic generation of certain PIN values, or the replacement of existing PINs with certain PIN values. The TKE LIC 7.3 includes a new tab for specifying restricted PIN values. This enhancement is exclusive to the TKE LIC 7.3.
•New AES operational keys: Five new AES operational keys can be managed from the TKE workstation with LIC 7.3. The key types are MAC, PINCALC, PINPROT, PINPRW, and DKYGENKY.
•Close Host and Unload Authority Signature Key: You can use the Close Host enhancement to sign explicitly off a host. You can use the Unload Authority Signature Key enhancement to remove explicitly the current authority signature key without ending the TKE application. When you have many users with different roles, users no longer must end the TKE application before the TKE workstation is used by another user.
•New access control for managing host list entries: The TKE workstation profile role has a new access control point that you can use to create, change, or delete a host list entry. This feature provides stronger separation of duties between users of a host list entry and users that manage the entries.
•Domain Group changes: When creating or changing a domain group, a domain can be included in the group only once. This ensures that domain commands are sent to a domain only once. If you manage a host crypto module role from a domain group, the user must explicitly select which Domain Access Control Points are set. The user either specifies that every domain access control point is selected for every crypto module in the group, or that only the domain access control points for the domains in the group are selected. You can use this enhancement to manage a 'module-scoped role' from inside a domain group.
•User-defined CCA and EP11 Domain Control lists: When managing CCA or EP11 Domain Control Points, the user can save the settings to a file that can then later be applied to other domains. You can use this enhancement for fast and accurate deployment of new or recovered domains.
•Increased session key strength: When using the latest version of smart cards on a TKE workstation with LIC 7.3, a 256-bit AES session key is used for all smart card operations. For more information, see the TKE Workstation User's Guide, TKE Version 7.3, SC14-7511, or in the Library, Hardware products for servers, TKE workstation section of Resource Link for further information.
6.9.5 TKE workstation with Licensed Internal Code 8.0
TKE workstation (FC 0847) with LIC 8.0 is available to order with z13. It has the following enhancements:
•TKE workstation with LIC 8.0 is required to manage a Crypto Express5S host.
•Only a TKE workstation with LIC 8.0 can be used to manage domains higher than 16 on a Crypto Express5S feature.
•The Full Function Migration Wizard is required when data is applied to a
Crypto Express5S host. If data is applied to a Crypto Express5S host, the collection must be done by using Key Part Holder Certificates from Key Part Holder (KPH) smart cards that are created on a TKE workstation with LIC 8.0.
Crypto Express5S host. If data is applied to a Crypto Express5S host, the collection must be done by using Key Part Holder Certificates from Key Part Holder (KPH) smart cards that are created on a TKE workstation with LIC 8.0.
|
Recommendation: During a migration, if data is applied to a Crypto Express5S, collect the source module from the TKE workstation with LIC 8.0.
|
6.9.6 Logical partition, TKE host, and TKE target
If one or more LPARs are configured to use Crypto Express 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 either a TKE host or a 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 TKE target.
6.9.7 Optional smart card reader
You can add an optional smart card reader (FC 0885) to the TKE workstation. One FC 0885 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.
Access to and use of confidential data on the smart card are protected by a user-defined PIN. Up to 990 additional smart cards can be ordered for backup. The additional smart card feature code is FC 0884. When one feature code is ordered, 10 smart cards are shipped. The order increment is 1 - 99 (10 - 990 blank smart cards).
6.9.8 TKE hardware support and migration information
On z13, if a TKE workstation is required, a TKE workstation with LIC 8.0 must be used.
For more information about TKE hardware support, see Table 6-3.
Table 6-3 TKE Compatibility Matrix
|
TKE Workstation
|
TKE Release LIC
|
7.2
|
7.31
|
8.0
|
|
HW Feature Code
|
0814
|
0842
|
0847
|
|
|
LICC
|
0850
|
0872
|
0877
|
|
|
Smart Card Reader
|
0885
|
0885
|
0891
|
|
|
Smart Card
|
0884
|
08842
|
0892
|
|
|
Server supported
|
z196
|
Yes
|
Yes
|
|
|
z114
|
Yes
|
Yes
|
|
|
|
zEC12
|
Yes
|
Yes
|
Yes
|
|
|
zBC12
|
|
Yes
|
Yes
|
|
|
z13
|
|
|
Yes
|
|
|
Manage Host Crypto Module
|
CEC3C (CCA)
|
Yes
|
Yes
|
|
|
CEX4C (CCA)
|
Yes
|
Yes
|
Yes
|
|
|
CEX4c (EP11)
|
Yesc
|
Yesc
|
Yes3
|
|
|
CEX5C (CCA)
|
|
|
Yes
|
|
|
CEX5C (EP11)
|
|
|
Yes
|
1 TKE workstation (FC 0842) with LIC 7.3 can be upgraded to TKE workstation (FC 0847) with LIC 8.0. The MES generates FC 0894 to add the IBM 4767 adapter.
2 Older smart cards 45D3398 (FC 0884) and 74Y0551 (FC 0884) can be used on TKE workstation with LICK 8.0 (available from System z10)
3 A Crypto Express4S running in EP11 mode requires smart cards to hold administrator certificates and master key material. The smart card must be P/N 74Y0551.
|
Attention: The TKE is unaware of the CPC type where the host crypto module is installed. That is, the TKE does not care whether a Crypto Express is running on a z13, z196, z114, zEC12, or zBC12. Therefore, the LIC can support any CPC where the coprocessor is supported, but the TKE LIC must support the specific crypto module.
|
6.10 Cryptographic functions comparison
Table 6-4 lists the functions or attributes on z13 for the two cryptographic hardware features. In the table, X indicates that the function or attribute is supported.
Table 6-4 Cryptographic functions on z13
|
Functions or attributes
|
CPACF1
|
CEX5Ca
|
CEX5Pa
|
CEX5Aa
|
|
Supports z/OS applications using ICSF
|
X
|
X
|
X
|
X
|
|
Supports Linux on z Systems CCA applications
|
X
|
X
|
-
|
X
|
|
Encryption and decryption 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
|
-
|
|
Disruptive process to enable
|
-
|
Note2
|
Noteb
|
Noteb
|
|
Requires IOCDS definition
|
-
|
-
|
-
|
-
|
|
Uses CHPID numbers
|
-
|
-
|
-
|
-
|
|
Uses PCHIDs (one PCHID)
|
|
X
|
X
|
X
|
|
Requires CPACF enablement (FC 3863)
|
X3
|
Xc
|
Xc
|
Xc
|
|
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 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
|
-
|
X4
|
X
|
Xd
|
|
Designed for FIPS 140-2 Level 4 certification
|
-
|
X
|
X
|
X
|
|
Supports Linux applications performing SSL handshakes
|
-
|
-
|
-
|
X
|
|
RSA functions
|
-
|
X
|
X
|
X
|
|
High-performance SHA-1 and SHA2
|
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
|
-
|
|
Pseudorandom number generator (PRNG)
|
X
|
X
|
X
|
-
|
|
Clear key RSA
|
-
|
-
|
-
|
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 (384,512), HMAC
|
-
|
X
|
-
|
-
|
|
Visa Format Preserving Encryption
|
-
|
X
|
-
|
-
|
|
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 This configuration requires CPACF enablement feature code 3863. CEX4 is available only as a carry-forward on z13.
2 To make the addition of the Crypto Express features nondisruptive, the logical partition must be predefined with the appropriate PCI Express cryptographic adapter number. This number must be selected in its candidate list in the partition image profile.
3 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.
4 This feature is physically present but is not used when configured as an accelerator (clear key only).
6.11 Software support
The software support levels are listed in 7.4, “Cryptographic support” on page 281.
1 Federal Information Processing Standards (FIPS)140-2 Security Requirements for Cryptographic Modules
2 Requires Crypto Express5S and a TKE workstation
3 http://ansi.org/ - Note that documents MUST be purchased
4 http://ansi.org/ - Note that documents MUST be purchased.
5 IBM 4764 PCI-X cryptographic coprocessor
6 For more information, see http://www-03.ibm.com/security/cryptocards/pciecc/overview.shtml
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.