Cryptographic Services
This chapter examines the Crytographic Services that are available on System z9® servers.
5.1 Introduction to cryptography
Figure 5-1 Introduction to cryptography
Introduction to cryptography
The word cryptography literally means secret writing. Throughout history, information has been an asset that provides the owner a competitive advantage.
Failure to adequately protect information has had significant consequences for countries. Today, If an enterprise does not exercise due care in protecting sensitive information about others, it risks losing its competitive advantage and market share through industrial espionage or losses due to law suits.
Confidentiality important. In addition, the integrity (the assurance of validity) of information is critical to business success around the world. Commercial enterprises send contracts, private documents, money orders, and other legal documents across communication networks, all of which must arrive with the same content with which they were dispatched. Before the electronic age, paper, signatures, and seals were used to guarantee the integrity of a document. With electronic communication, another mechanism is required.
Cryptography is the only known practical method of protecting information that is transmitted electronically through communication networks. It can also be an economical way to protect stored information. As computing systems become increasingly exposed through increased computer literacy and reliance on distributed computing, the pervasiveness of cryptography will increase as industry seeks ways to protect their information assets.
5.2 Cryptographic capabilities
Figure 5-2 Cryptographic capabilities
Cryptographic capabilities
The use of cryptography provides many data-handling capabilities, such as data confidentiality, data integrity, authentication, and electronic signatures.
Data confidentiality
Traditionally, cryptography is a data scrambling method used to conceal the information content of a message. When a message is encrypted, the input plain text (unencrypted text) is transformed by an algorithm into enciphered text that hides the meaning of the message. This process involves a secret key that is used to encrypt and (later) decrypt the data. Without this secret key, the encrypted data is meaningless. To conceal a message without using cryptography, a secure physical communication line is required. With cryptography, only the secret data encryption key has to be transmitted by a secure method. The encrypted text can be sent using any public mechanism.
Data integrity
Although cryptography is best known for its ability to protect the confidentiality of data, it is also used to protect the integrity of data. For example, a cryptographic checksum, such as a message authentication code (MAC), can be calculated on arbitrary user-supplied text. The text and MAC are then sent to the receiver. The receiver of the message can verify the MAC appended to a message by recalculating the MAC for the message using the appropriate secret key and verifying that it matches the received MAC exactly.
Authentication and Identification
Another use of cryptography is in personal identification where the user knows a secret that can serve to authenticate his or her identity. For example, the user of an automatic teller machine (ATM) enters a magnetic stripe card to identify the account and the corresponding correct PIN to authenticate the user. An unauthorized person acquiring the card and attempting to use it is reduced to guessing the correct PIN. Because a PIN is typically four digits and because a user typically gets only three attempts to enter the correct PIN, this is very unlikely to happen.
Electronic signature
In normal business, a legal transaction is completed by a verifiable authorized signature (just sign on the dotted line). An analogous process is required by new electronic applications, such as Electronic Data Interchange (EDI). A digital signature is a means of achieving this by using cryptographic mechanisms. It assures the recipient that the message is authentic and that only the owner of the key could have produced the digital signature. A digital signature, such as the Rivest-Shamir-Adleman (RSA) algorithm, is well-suited for message non-repudiation. Non-repudiation is the ability of a party to sign a message, such that he or she is unable to later deny having signed the message.
5.3 Symmetric and asymmetric encryption algorithms
Figure 5-3 Symmetric and asymmetric encryption algorithms
Symmetric and asymmetric encryption algorithms
Today, two distinct classes of encryption algorithms are in use:
•Symmetric encryption algorithms
•Asymmetric encryption algorithms
Their fundamental difference is in how keys are used with these encryption methods.
5.4 Symmetric encryption algorithms
Figure 5-4 Symmetric encryption algorithms
Symmetric encryption algorithms
An encryption algorithm is called symmetric when the same key that is used to encrypt the data is also used to decrypt the data and recover the plain text (see Figure 5-4). The cipher and decipher processes are usually mathematically-complex non-linear permutations.
Most symmetric ciphers are block ciphers. They operate on a fixed number of characters at a time, usually eight bytes. Some frequently-used algorithms are:
•Data Encryption Standard (DES): Developed in the 1970s by IBM scientists, DES uses an 8-byte key; however, one bit in each byte is used as a parity bit; so, the key length is 56 bits. Stronger versions called Triple DES, which use three operations in sequence, have been developed:
 – 2-key Triple DES encrypts with key 1, decrypts with key 2, and encrypts again with key 1. The effective key length is 112 bits.
 – 3-key Triple DES encrypts with key 1, decrypts with key 2, and encrypts again with key 3. The effective key length is 168 bits.
•Advanced Encryption Standard (AES): Sometimes known as Rijndael, AES is a block cipher adopted as an encryption standard by the US government. It is considered the successor to DES and TDES and is expected to be used worldwide. AES uses a larger block size than DES and TDES do. While DES uses a block size of 8 bytes (64 bits), AES uses a block size of 16 bytes (128 bits) along with the capability of using longer keys than DES or TDES. This block size should be acceptable for messages of up to 256 exabytes of data, and the bigger length of the keys delays for quite a few years the possibility of finding the key value using brute force.
•Commercial Data Masking Facility (CDMF): A version of the DES algorithm that is used for export from the U.S. and uses 56-bit keys; however, 16 bits of the key are known. So, the effective key length is 40 bits.
•RC2: Developed by Ron Rivest for RSA Data Security, Inc., RC2 is a block cipher with variable key length operating on 8-byte blocks. Key lengths of 40 bits, 64 bits, and 128 bits are used.
•RC4: Developed by Ron Rivest for RSA Data Security, Inc., RC4 is a stream cipher with variable key length. Stream ciphers operate on each byte, not on blocks of data. Key lengths of 40 bits, 64 bits, and 128 bits are used.
 
Note: Both RC2 and RC4 are proprietary confidential algorithms that have never been published. They have been examined by a selected number of scientists working under non-disclosure agreements.
With these ciphers, it can be assumed that a brute-force attack is the only means of breaking the cipher; therefore, the work factor depends on the length of the key. If the key length is n bits, the work factor is proportional to 2**(n-1).
5.5 Asymmetric encryption algorithms
Figure 5-5 Asymmetric encryption algorithms
Asymmetric encryption algorithms
An encryption algorithm is called asymmetric when the key that is used to encrypt the data cannot be used to decrypt the data. A different key is needed to recover the plain text (see Figure 5-5). This key pair is called a public key and a private key. If the public key is used to encrypt the data, the private key must be used to recover the plain text. If data is encrypted with the private key, it can only be decrypted with the public key.
Asymmetric encryption algorithms, commonly called Public Key Cryptosystems (PKCS), are based on mathematical algorithms. The basic idea is to find a mathematical problem that is very hard to solve. Only one algorithm, RSA, is in widespread use today. However, some companies have begun to implement public-key cryptosystems based on so-called elliptic curve algorithms. The following list provides a brief overview of asymmetric algorithms:
•RSA: RAS was invented in 1977 by Rivest, Shamir, and Adleman (who formed RSA Data Security, Inc.). The idea behind RSA is that integer factorization of very large numbers is extremely hard to do. Key lengths of public and private keys are typically 512 bits, 1024 bits, or 2048 bits.
•Elliptic Curve: Public-key cryptosystems based on elliptic curves use a variation of the mathematical problem to find discrete logarithms. It has been stated that an elliptic curve cryptosystem implemented over a 160-bit field has roughly the same resistance to attack as RSA with a 1024-bit key length.
Elliptic curve cryptosystems are said to have performance advantages over RSA in decryption and signing.
While the possible differences in performance between the asymmetric algorithms are somewhere in the range of a factor of 10, the performance differential between symmetric and asymmetric cryptosystems is far more dramatic. It takes about 1000 times longer to encrypt the same data with RSA as it does with DES, and implementing both algorithms in hardware does not change the odds in favor of RSA.
5.6 Use of cryptosystems: Data privacy
Figure 5-6 Uses of cryptosystems
Uses of cryptosystems
Cryptosystems, both symmetric and asymmetric, are used for data privacy, data integrity, and digital signatures.
Cryptosystems for data privacy
Encrypting and decrypting large amounts of data with asymmetric cryptosystems is expensive (in reference to time and resources). Therefore, symmetric algorithms, such as AES, DES, RC2, or RC4, are used for bulk data encryption. The disadvantage of symmetric algorithms, however, is that both partners (the party that encrypts the data and the party that decrypts the data) must be in possession of the same key. Key management or safe distribution of keys in insecure networks is a problem with symmetric cryptosystems, even more so because data encryption keys need to be changed frequently in order to make an adversary’s task more difficult and limit the potential damage if a key is compromised.
Different solutions exist in different environments, and we list a few of these solutions in the following sections.
Key management in a closed environment
In high-security environments using cryptographic hardware that is installed and managed by a centralized security facility, Master Keys and key-exchange keys can be installed centrally, and the hardware facility can be delivered to the users with the necessary keys installed.
If tamper-resistant hardware is used, this solution can fulfill the highest security requirements and can also be made secure against insider attacks. The amount of administrative effort and cost, however, would be prohibitive for many environments.
Distributed Computing Environment
Distributed Computing Environment (DCE) is designed to provide secure client-server computing in insecure networks. It uses DES, a symmetric cryptosystem.
Users (principals) are authenticated by a central authentication server (the DCE Security Server) using the Kerberos V.5 third-party authentication method. All client and server principals must be defined in the registry (the authentication server’s database). Client users have a password that they must remember, and servers have a key that is normally stored in a keyfile on the server’s computer. The passwords and server keys are stored in the registry as the principals’ Master Keys.
During authentication, the security server can send information to the client encrypted under the client's Master Key (password). A client who wants to communicate with an application server needs a ticket for this application server from the security server. A ticket is a collection of information about the client, encrypted by the security server with the Master Key of the application server. The client cannot read or modify the ticket, which can be compared to a sealed envelope that the client can forward to the server as a method for identify but which the user cannot open, read, or modify.
The security server creates a random session key that the client and the application server can use to encrypt the data that they send to each other. This session key is included in the ticket and is also sent to the client encrypted under the client’s Master Key.
The authentication and key management method used by DCE can create a highly-secure client-server environment. If all security features provided by DCE are used, a network can be made impenetrable even to sophisticated intruders. A hacker would need a computer that is defined in the registry with a valid Master Key to even be able to attempt to log in and make a guess at a principal's password.
The use of symmetric encryption causes the overhead for the security functions, although too large to be neglected, to be tolerable.
The downside is that all clients need to be defined and administered in the registry. This is adequate for client-server computing within an enterprise but does not scale well into a user population made up of large numbers of suppliers and customers on the Internet.
Public key infrastructure
Public key cryptosystems can be used to transmit the DES, RC2, or RC4 keys used to encrypt data to the recipient. Data that has been encrypted with the public key of the recipient can only be decrypted using the recipient’s private key. If someone makes the public key publicly known, everybody can send that person’s encrypted data by using the following procedure:
1. Create a random DES, RC2, or RC4 key to encrypt the data.
2. Encrypt the data using this key.
3. Encrypt the key with the RSA PKCS using the recipient's public key.
4. Append the encrypted key before or after the encrypted data.
5. Send to recipient.
The recipient uses the private key to decrypt the DES, RC2, or RC4 key and uses this key to decrypt the data and recover the plain text. This method works very well and has reasonable performance because RSA is used to encrypt or decrypt only small amounts of data. The length of symmetric keys is typically between 8 and 32 bytes.
The problem with this method arises from the question: How can someone publish a public key in a secure manner? If I send you my public key, pretending it is the public key of someone else (for example, Jack Jones), and trick you into believing me, you will then send encrypted data to the person who you believe is Jack Jones, and I can decrypt that data. This situation is one where Digital Certificates and a public key infrastructure (PKI), a hierarchy of authorities that issue certificates and attest to their authenticity, can help.
5.7 Use of cryptosystems: Data integrity
Figure 5-7 Data integrity
Cryptosystems for data integrity
Data integrity is the ability to assert that the data that is received over a communication link is identical to the that is data sent. Data integrity in an insecure network requires the use of cryptographic algorithms, but it does not imply that only the receiver can read the data, as is the case with data privacy. Data can be compromised not only by an attacker, but it can also be damaged by transmission errors (although these are normally handled by the transmission protocols).
Message authentication codes
Symmetric cryptographic algorithms, such as DES, can be used for data integrity. Using a variation of the DES algorithm and a secret key, an 8-byte Message Authentication Code (MAC) is created from the data. The MAC is sent with the message. The receiver performs the same operation using the same key and compares the resulting MAC with the MAC that was sent with the data. If both match, the integrity of the data is assured.
MACs rely on the same secret key that is used by both the sender (to create the MAC) and the receiver (to verify the MAC). Since the MAC is derived from a secret key known only to the sender and receiver the MAC can be sent in the clear. An adversary sitting between the sender and the receiver (a so-called “person-in-the-middle” attack) can alter the message but cannot forge the MAC because the key to create the MAC is unknown. The mathematical principle behind using the MAC is that finding a message that fits a certain MAC is as difficult as breaking DES encryption.
A disadvantage to this method is that, as in symmetric cryptosystems, secret keys must be shared by sender and receiver. Furthermore, because the receiver has the key that is used in MAC creation, it is very difficult to make it impossible for the receiver to forge a message and claim it was sent by the sender.
Message digest algorithms
Message digesting algorithms are a different approach to data integrity. These are algorithms that digest (condense) a block of data into a shorter string (usually 128 or 160 bits) called a Message Digest, Secure Hash, or Message Integrity Code (MIC).
The principles behind message digesting algorithms are:
•The message cannot be recovered from the message digest.
•It is very hard to construct a block of data that has the same message digest as another given block.
Some common message-digesting algorithms are:
•MD2: This algorithm was developed by Ron Rivest of RSA Data Security, Inc. The algorithm is used mostly for PEM certificates. MD2 is fully described in RFC 1319. Because weaknesses have been discovered in MD2, its use is discouraged.
•MD5: This algorithm was developed in 1991 by Ron Rivest. The algorithm takes a message of arbitrary length as input and produces as output a 128-bit message digest of the input. The MD5 message digest algorithm is specified by RFC 1321, The MD5 Message-Digest Algorithm.
•SHA-1 SHA-1: This algorithm was developed by the U.S. Government. The algorithm takes a message of arbitrary length as input and produces as output a 160-bit hash of the input. SHA-1 is fully described in standard FIPS 180-1.
•SHA-2: SHA-256 is an improved algorithm and generates a 32-byte hash value. SHA-256 is considered to generate message digest values that are less likely to yield collisions.
•MDC-4: The MDC-4 algorithm calculation is a one-way cryptographic function that is used to compute the hash pattern of a key part. MDC uses encryption only, and the default key is 5252 5252 5252 5252 2525 2525 2525 2525. It is used by the TKE.
The sender of a message (block of data) uses an algorithm (for example SHA-1) to create a message digest from the message. The message digest is sent together with the message. The receiver runs the same algorithm over the message and compares the resulting message digest to the one sent with the message. If both match, the message is unchanged.
The message digest cannot be sent in the clear. Because the algorithm is well known and no key is involved, a person-in-the-middle can forge the message and can also replace the message digest with that of the forged message, making it impossible for the receiver to detect the forgery. Depending on the application and the key management used, either symmetric cryptosystems or public-key cryptosystems can be used to encrypt the message digest.
Because a message digest is a relatively small amount of data, it is especially well-suited for public-key encryption.
5.8 Use of cryptosystems: Digital signatures
Figure 5-8 Digital signatures
Digital signatures
Digital signatures are an extension of data integrity. While data integrity only ensures that the data received is identical to the that is data sent, digital signatures go a step further. They provide non-repudiation, which means that the sender of a message (or the signer of a document) cannot deny authorship (similar to signatures on paper).
The creator of a message or electronic document that is to be signed uses a message digesting algorithm, such as MD5 or SHA-1, to create a message digest from the data. The message digest and some information that identifies the sender are then encrypted with the sender's private key. This encrypted information is sent together with the data.
The receiver uses the sender’s public key to decrypt the message digest and sender’s identification. The receiver then uses the message digesting algorithm to compute the message digest from the data. If this message digest is identical to the one recovered after decrypting the digital signature, the message is authentic, and the signature is recognized as valid.
With digital signatures, only public-key encryption can be used. If symmetric cryptosystems are used to encrypt the signature, it is very difficult to make sure that the receiver (having the key to decrypt the signature) could not misuse this key to forge a signature of the sender. The private key of the sender is not known to anyone else. So, nobody can forge the sender’s signature.
The difference between encryption using public key cryptosystems and digital signatures includes:
•With encryption, the sender uses the receiver’s public key to encrypt the data, and the receiver decrypts the data with a private key. Thus, everybody can send encrypted data to the receiver that only the receiver can decrypt.
•With digital signatures, the sender uses the private key to encrypt the signature, and the receiver decrypts the signature with the sender’s public key. Thus, only the sender can encrypt the signature, but anyone who receives the signature can decrypt and verify it.
The tricky thing with digital signatures is the trustworthy distribution of public keys.
5.9 IBM Common Cryptographic Architecture
Figure 5-9 IBM CCA
IBM Common Cryptographic Architecture
The IBM Common Cryptographic Architecture (CCA), defines a set of cryptographic functions, external interfaces, and key management rules that pertain both to the DES-based symmetric algorithms and the Public Key Algorithm (PKA) asymmetric algorithms. These provide a consistent, end-to-end cryptographic architecture across different platforms that conforms to American and International Standards.
Functions of the CCA define services for:
•Key management, which includes generation and exchange of keys securely across networks and between application programs. The exchanged key is encrypted securely using either DES or a PKA used in the context of symmetric key management.
•Data integrity, with the use of a Message Authentication Code (MAC), Modification Detection Code (MDC), or digital signature.
•Data confidentiality, with the use of encryption and decryption capabilities accessible at all levels of a network protocol stack.
•Personal authentication, with PIN generation, verification, and translation.
CCA was introduced in October 1989 with the IBM Transaction Security System and the IBM Integrated Cryptographic Facility (IBM ICSF) with its supporting Integrated Cryptographic Services Facility/MVS (ICSF/MVS).
These products and their follow-ons conform to the IBM CCA Application Programming Interface.
CCA key management functions
Key management is essential to successful cryptography. Because the algorithm is usually public knowledge, the security of the data depends on the security of the key that is used to encipher the data. Enciphered data can be obtained by an adversary, but without access to the cryptographic key, the data remains secure.
Key management in the IBM CCA includes the following:
•Master Key concept: Each cryptographic system has a Master Key that is kept in the clear inside the cryptographic facility, which is a highly secured physical repository. Each operational DES key is encrypted under the appropriate Master Key variant (see 5.15, “DES key management” on page 269), allowing an installation to protect many keys while providing physical protection for only one key.
•PKA keys: The concept of Master Key is also applied to PKA keys that are encrypted under the PKA Master Key.
•Key separation: Cryptographic keys should be used only for their intended function. For DES keys, the IBM CCA enforces key separation through the use of control vectors (CV).
A control vector is a fixed pattern defined for each key type that the cryptographic facility exclusively ORs with the Master Key to produce a Master Key variant that is used to encrypt the key. Effectively, this produces a unique Master Key for each key type. The Master Key variants protect keys operating on the system; these are called operational keys.
The control vector concept also applies to the secure transportation of symmetric keys, where the transported key is encrypted under a variant of the key-encrypting-key. For example, when a key is stored with a file or sent to another system, the key is encrypted under a key-encrypting key.
CCA API
The IBM CCA cryptographic API definition uses a common key management approach and contains a set of consistent callable services. (A callable service is a routine that receives control when an application program issues a CALL statement.)
Common key management ensures that all products that conform to the architecture allow users to share cryptographic keys in a consistent manner. The definition of key management provides methods for initializing keys on systems and networks, and also supports methods for the generation, distribution, exchange, and storage of keys.
Table 5-1 shows most of the categories of CCA callable services and some of the services in each category. The service pseudonym is the descriptive name for a service, while the service name is the formal name for the service and the name by which the service is called from a program.
Table 5-1 Some CCA callable services
Service pseudonym
Service name
Managing DES cryptographic keys
 
Clear key import
CSNBCKI
Data key export
CSNBDKX
Data key import
CSNBDKM
Key export
CSNBKEX
Key generate
CSNBKGN
Key import
CSNBKIM
Random number generate
CSNBRNG
Symmetric key export
CSNDSYX
Symmetric key generate
CSNDSYG
Symmetric key import
CSNDSYI
Protecting data
 
Decipher
CSNBDEC
Encipher
CSNBENC
Symmetric key decipher
CSNBSYD
Symmetric key encipher
CSNBSYE
Verifying data integrity/authenticity
 
MAC generate
CSNBMGN
MAC verify
CSNBMVR
One-way hash generate
CSNBOWH
Financial services
 
Clear PIN encrypt
CSNBCPE
Clear PIN generate
CSNBPGN
Encrypted PIN generate
CSNBEPG
Encrypted PIN verify
CSNBPVR
Using digital signatures
 
Digital signature generate
CSNDDSG
Digital signature verify
CSNDDSV
Managing PKA cryptographic keys
 
PKA key generate
CSNDPKG
PKA key import
CSNDPKI
PKA key token build
CSNDPKB
PKA public key extract
CSNDPKX
5.10 IBM System z9: Cryptographic overview
Figure 5-10 IBM System z9: Cryptographic overview
IBM System z9: Cryptographic overview
Two types of cryptographic hardware features are available on System z9.
•CP Assist for Cryptographic Function (CPACF)
•Crypto Express 2 feature configurable as a Crypto Express 2 Coprocessor (CEX2C) or as a Crypto Express 2 Accelerator (CEX2A).
These features are usable only when explicitly enabled through Feature Code 3863, except for the CPACF SHA-1 and SHA-256 functions, which are always enabled.
To fully exploit the z9 Cryptographic features requires the Integrated Cryptographic Service Facility (ICSF), which is the support program for the cryptographic features CPACF, CEX2C, and CEX2A. ICSF is integrated into z/OS.
Additionally, the optional (TKE) Trusted Key Entry workstation feature is part of a customized solution for using the Integrated Cryptographic Service Facility for z/OS program product to manage cryptographic keys of a System z9 that has CEX2C features installed and intended for the use of DES and PKA with secure cryptographic keys.
The TKE workstation provides secure control of the CEX2C features, including loading of master keys.
Figure 5-10 on page 256 describes the overall hardware and software layout of the hardware cryptography in System z9 and z/OS, as follows:
•The exploiters of the cryptographic services call the ICSF API. Some functions are performed by the ICSF software without invoking the cryptographic coprocessor; other functions result in ICSF going into routines containing the cryptographic instructions. The cryptographic instructions to drive CEX2C are IBM proprietary and are not disclosed; the cryptographic instructions to interface with CPACF are published in z/Architecture Principles of Operation, SA22-7832.
•These instructions are executed by a CPU engine and, if not addressing the CPACF functions, result in a work request being generated for a cryptographic coprocessor.
The cryptographic coprocessor is provided with the following:
•Data to encrypt or decrypt from the system memory.
•The key used to encrypt or decrypt provided by ICSF as per the exploiter’s request.
 
Note: The encryption or decryption keys are themselves encrypted and, therefore, unusable when residing outside of the cryptographic coprocessor.
Physically, these keys can be stored in ICSF-managed VSAM data sets and pointed to by the application using the label they are stored under. The Cryptographic Key Data Set (CKDS) is used to store the symmetric keys in their encrypted form, and the Public Key Data Set (PKDS) is used to store the asymmetric keys. The application also has the capability of providing an encrypted encryption key or a clear encryption key directly in memory (that is, to use as is) to the coprocessor.
For high-speed access to symmetric cryptographic keys, the keys in the CKDS are duplicated into an ICSF-owned data space.
5.11 CP Assist for Cryptographic Functions (CPACF)
Figure 5-11 CPACF hardware implementation
CPACF hardware implementation
CP Assist for Cryptographic Functions (CPACF) was first introduced on the z990 and z890. CPACF provides for hash functions and clear key encryption and decryption functions. Each system Central Processor (CP) has an assist processor on the chip in support of cryptography.
CPACF operates with a specific set of machine instructions, the Message-Security Assist (MSA) instructions, which are problem state instructions and therefore available to all applications. Alternatively, these functions can also be called through the Integrated Cryptographic Service Facility (ICSF) component of z/OS by an ICSF-aware application.The MSA instructions are described in z/Architecture Principles of Operation, SA22-7832.
The MSA instructions are all executed synchronously with respect to the CP instruction stream, contrary to the operations executed on the Crypto Express 2 cards, which execute asynchronously. The CPACF operations are therefore quite fast and can be used to support a high volume of cryptographic requests. Because the CPACF instructions are available on every PU within System z9, as they are for the zSeries® z990 or z890, and because the CPACF operates with clear keys only, there is no notion of logical partition sharing or cryptographic domains with CPACF.
The CPACF provides the MSA instruction set on every central processor (CP) of a z9 109, z9 BC, and z9 EC server.
MSA provides the following instructions:
•CIPHER MESSAGE (KM)
•CIPHER MESSAGE WITH CHAINING (KMC)
•COMPUTE INTERMEDIATE MESSAGE DIGEST (KIMD)
•COMPUTE LAST MESSAGE DIGEST (KLMD)
•COMPUTE MESSAGE AUTHENTICATION CODE (KMAC)
Each of these instructions can perform several functions. Therefore, the MSA basic facility supplies a query function with each instruction so that the programmer can determine whether a given function is available on a given processor. If a programmer attempts to use a function that is not available, his program will get a program interruption with interruption code 6 (specification exception). In z/OS this is normally presented as an 0C6 abend.
On the z9 109, z9 BC, and z9 EC, the MSA instruction set always includes the following functions:
•KIMD-SHA-1 and KIMD-SHA-256
•KLMD-SHA-256 and KLMD-SHA-256
With feature 3863, it also includes the following functions:
•KM-DEA, KM-TDEA-128, KM-TDEA-192, and KM-AES-128
•KMC-DEA, KMC-TDEA-128, KMC-TDEA-192, KMC-AES-128, and KMC-PRNG
•KMAC-DEA, KMAC-TDEA-128, and KMAC-TDEA-192
Because the CPACF cryptographic functions are implemented in each CP, the potential throughput scales with the number of CPs in the server.
The hardware of the CPACF that performs encryption operations and SHA functions operates basically synchronous to the CP operations. The CP cannot perform any other instruction execution while a CPACF cryptographic operation is being executed. The CP internal code performs data fetches and stores resultant data while cryptographic operations are executed in the CPACF hardware on a unit basis as defined by the hardware.
5.12 Crypto Express 2 feature
Figure 5-12 Crypto Express 2 feature
Crypto Express 2 Feature
The Crypto Express 2 (CEX2) feature combines the functions of a coprocessor (for secure key encrypted transactions) with the functions of an accelerator (for acceleration of transactions using SSL) into a single optional feature with two PCI-X adapters. Using the HMC console of a z9 system, the PCI-X adapters can be customized as having either two coprocessors, two accelerators, or one of each. Figure 5-12 shows the layout of a CEX2 feature.
The CEX2 in coprocessor mode (CEX2C) provides specialized hardware that performs DES, TDES, SHA-1, RSA, PIN and key management operations. The CEX2C is designed to protect the cryptographic keys. Security relevant cryptographic keys are encrypted under a Master Key when outside of the secure boundary of the CEX2C card. The Master Keys are always kept in battery backed-up memory within the tamper-protected boundary of the CEX2C, and are destroyed if the hardware module detects an attempt to penetrate it. The tamper-responding hardware has been certified at the highest level under the FIPS 140-2 standard, namely, Level 4. The CEX2C also supports the clear key PKA operations that are often used to provide SSL protocol communications.
When configured in accelerator mode (CEX2A), the CEX2 feature provides hardware support to accelerate certain cryptographic operations that occur in the e-business environment. Compute intensive public key operations as used by the SSL/TLS protocol can be offloaded from the CP to the CEX2A, potentially increasing system throughput. The CEX2 in accelerator mode works in clear key mode only.
A z9 109, z9 BC, or z9 EC server can support a maximum of eight CEX2 features. Because each feature provides two coprocessors or accelerators, a System z9 server can support a maximum of 16 cryptographic coprocessors or accelerators.
The connection of the CEX2 feature to the System z9 CPs through the PCI-X bus incurs latency and data transmission time. Because of this connection to the z9 CPs, the CEX2 executes its cryptographic operations asynchronously to a CP operation. A CP requesting a cryptographic operation from the CEX2 uses a message queuing protocol to communicate with the CEX2. After enqueueing a request to the CEX2, the host operating system suspends the task that has enqueued the cryptographic operation and dispatches another task. Thus, processing of the cryptographic operation in the CEX2 works in parallel to other tasks that are executed in the z9 CP. A special CP task polls at fixed time intervals for finished operations of the CEX2, dequeues them, and executes the Resume function to cause the redispatch of the application that is waiting for the result of the cryptographic operation. For each PCI-X adapter in the CEX2, up to eight requests can be waiting in the queue either for execution or for dequeueing of the result of a cryptographic operation by a CP. In the CEX2, several operations can be performed in parallel.
The CEX2A is actually a CEX2C that has been reconfigured by the user to only provide a subset of the CEX2C functions at enhanced speed. This reconfiguration is a manual process performed at the System z9 Support Element.
Note that:
•The reconfiguration is done at the coprocessor level, that is, a CEX2C feature can host a CEX2C coprocessor and a CEX2A accelerator, or two CEX2C coprocessors or two CEX2A accelerators.
•The reconfiguration is working both ways, that is, from CEX2C to CEX2A, and from CEX2A to CEX2C. Master keys in the CEX2C domains can be optionally preserved when reconfiguring from CEX2C to CEX2A.
•The reconfiguration process is disruptive to the involved coprocessor or accelerator operations. The coprocessor or accelerator must be deactivated using ICSF on all LPARS where it is being used before engaging the manual reconfiguration process.
•The FIPS 140-2 certification is not relevant to CEX2A because it is operating with clear keys only.
•The function extension capability through UDX is not available to CEX2A.
•A System z9 can support up to eight Crypto Express2 features (depending on the other features are installed), and each engine can be configured independently as either a coprocessor or accelerator.
Each PCIXCC has an 8-character serial number and a 2-digit Adjunct Processor (AP) number or ID. The number of APs is limited to 16 on System z9, and a CEX2C is, therefore, given an AP number between 0 and 15.
Crypto Express 2 Coprocessor functions
The optional Crypto Express 2 Coprocessor (CEX2C) comes as a Peripheral Component Interconnect Extended (PCI-X) pluggable feature that provides a high performance and secure cryptographic environment. The CEX2C Cryptographic Coprocessor consolidates the functions previously offered on the z900 by the Cryptographic Coprocessor feature (CCF), the PCI Cryptographic Coprocessor (PCICC), and the PCI Cryptographic Accelerator (PCICA) feature. These features are not available on System z9.
The CEX2C feature performs the following functions:
•Data encryption or decryption algorithms
 – Data Encryption Standard (DES)
 – Double length-key DES
 – Triple length- key DES
•DES key generation and distribution
•PIN generation, verification, and translation functions
•Pseudo Random Number (PRN) Generator
•Public Key Algorithm (PKA) Facility
These commands are intended for application programs using public key algorithms, including:
 – Importing RSA public-private key pairs in clear and encrypted forms
 – Rivest-Shamir-Adelman (RSA)
 • Key generation, up to 4096-bit
 • Signature Verification, up to 4096-bit
 • Import and export of DES keys under an RSA key, up to 4096-bit
 – Public Key Encrypt (CSNDPKE)
Public Key Encrypt service is provided for assisting the SSL/TLS handshake, and when used with the Mod_Raised_to Power (MRP) function it can be used to offload compute intensive portions of the Diffie-Hellman protocol onto the CEX2C features of System z9.
 – Public Key Decrypt (CSNDPKD)
Public Key Decrypt supports a zero-pad option for clear RSA private keys. PKD is used as an accelerator for raw RSA private operations such as required by the SSL/TLS handshake and digital signature generation. The zero-pad option is exploited on Linux® to allow use of the CEX2C features of System z9 for improved performance of the SSL/TLS handshake and digital signature generation.
 – Derived Unique Key Per Transaction (DUKPT)
This service is provided to write applications that implement the DUKPT algorithms as defined by the ANSI X9.24 standard. DUKPT provides additional security for point-of-sale transactions that are standard in the retail industry. DUKPT algorithms are supported on the CEX2C feature for triple-DES with double-length keys.
 – Europay Mastercard VISA (EMV) 2000 standard
Applications can be written to comply with the EMV 2000 standard for financial transactions between heterogeneous hardware and software. Support for EMV 2000 applies only to the CEX2C feature of System z9.
Other key functions of CEX2C serve to enhance the security of public/private key encryption processing include:
•Retained key support (RSA private keys generated and kept stored within the secure hardware boundary)
•Support for 4753 Network Security Processor migration
•User-Defined Extensions (UDX)
User-Defined Extensions to the Common Cryptographic Architecture (CCA) support custom algorithms that execute within the CEX2C Cryptographic Coprocessor. The UDX customized algorithm is added as specific coprocessor code built by IBM or by an approved third party. Building a UDX is an IBM service offering performed under contract.
Crypto Express 2 Accelerator functions
Actually, the only functions that remain available when reconfigured into a Crypto Express 2 Acceloerator (CEX2A) are the former PCICA functions. These functions are used for the acceleration of modular arithmetic operations, that is, the RSA cryptographic operations used with the SSL/TLS protocol:
•PKA Decrypt (CSNDPKD), with PKCS-1.2 formatting
•PKA Encrypt (CSNDPKE), with ZERO-PAD formatting
•Digital Signature Verify
The Encrypt and Decrypt RSA functions support key lengths of 512 to 4096-bit, in the Modulus Exponent (ME) and Chinese Remainder Theorem (CRT) formats.
The maximum number of SSL transactions per second that can be supported on a System z9 by any combination of CPACF and CEX2A coprocessors is limited by the amount of cycles available to perform the software portion of the SSL/TLS transactions. When both PCI-X coprocessors on a Crypto Express2 feature are configured as accelerators, the Crypto Express 2 feature is designed to perform up to 6000 SSL handshakes per second. This represents, approximately, a 3X performance improvement compared to z990 when using either a PCI Cryptographic Accelerator (PCICA) feature or the current CEX2C feature.
 
Note: These performance values indicate a throughput. That is, it is necessary to initiate several threads of parallel requests to the CEX2A to achieve this performance.
5.13 PCIXCC hardware overview
Figure 5-13 PCIXCC hardware overview
PCIXCC hardware overview
The PCIXCC hardware is implemented as an adapter card for a PCI-X bus. Figure 5-13 shows the components that are on the card. The numbers in the figure correspond to the following numbers:
1. IBM PowerPC® 405GPr microprocessor operating at 266 MHz.
The microprocessor serves as the primary controller of card operations. It orchestrates operation of the special-purpose hardware in the card and implements communications with the host and the IBM Common Cryptographic Architecture (CCA) API functions that comprise the external interface from host application programs to the card.
2. 64 MB of dynamic random-access memory (DRAM).
3. 16 MB of flash-erasable programmable read-only memory (flash EPROM) for storage of persistent data.
4. 128 KB of static CMOS RAM backed up with battery power when the card is powered off.
Because cryptographic algorithms such as DES, TDES, and AES are controlled by keys, the security of protected data depends on the security of the cryptographic key. Master keys are used to protect (encrypt) the cryptographic keys that are active on your system. The symmetric-keys master key (SYM-MK) protects symmetric keys such as DES keys, and the asymmetric-keys master key (ASYM-MK) protects RSA keys. Because master key protection is essential to the security of the other keys, the master keys are stored within the secure hardware of the PCIXCC in an area that is unaffected by system power outages because it is protected by a battery power unit.
5. IBM-developed custom cryptographic chip called Otello.
The Otello chip is divided into two cryptographic algorithm sections.
 – The symmetric-key cryptography and hashing unit
 – The public-key unit
In addition, Otello contains an add-on interface, an interface to the PowerPC microprocessor, an interface to communicate with the Atmel AVR security microcontroller, and an interface to the hardware random-number source.
6. Hardware-based cryptographic-quality random number source.
7. Field-programmable gate array (FPGA) called Rigoletto.
The Rigoletto FPGA contains the logic for all interfaces between the host server, the PowerPC microprocessor, and the Otello cryptographic chip. Because both the host server and the PowerPC microprocessor interface directly with the FPGA in order to talk to each other or to request cryptographic services, the FPGA is the key component for all internal and external programming interfaces. The Rigoletto FPGA provides two fundamentally different communication paths for host-to-card transactions:
 – Normal path
In this mode, host requests are transferred directly into DRAM memory in the card. When a request is in the card, software in the PowerPC microprocessor determines what function has been requested and executes that function with a combination of PowerPC software and calls to the on-card hardware.
 – Fast path
The fast path provides very high performance for public-key cryptographic functions. It gives the host server a direct hardware path to the Otello public-key unit so that data does not have to stop in the PowerPC memory and no software is involved. The fast path design supports operations using clear RSA keys, or using wrapped RSA keys that are encrypted under a TDES fast path master key securely stored inside the module.
8. Real-time clock module.
This module maintains the date and time for use by the PowerPC microprocessor.
9. AVR security microcontroller.
Higher layers in the software hierarchy must not be able to modify operation of the lower layers or tamper with security-related data owned by those lower layers. To accomplish this, the card uses a separate microcontroller that keeps track of the security state of the card and blocks access by higher layers to the memory they must not be allowed to access.
10. Tamper-detection circuitry.
The secure module on the PCIXCC card is designed with industry-leading tamper-detection features. The security-related electronic components are wrapped in a flexible mesh with narrow, imbedded, overlapping conductive lines that prevent any physical intrusion by drilling, mechanical abrasion, chemical etching, or other means. Circuits inside the module detect damage to the conductive lines, and all sensitive data is immediately destroyed. This is done by zeroizing the battery-backed static RAM—all sensitive data is stored either directly in the static RAM or in flash memory and encrypted under a 192-bit TDES key that is itself stored in that static RAM. If that key is destroyed, all encrypted data in the flash memory is rendered unusable.
Other special circuits sense attacks that can cause imprinting in the static RAM. Imprinting is a process that can permanently burn data into the RAM, so that the same data appears each time the RAM chip is powered on. Different data can be written to the chip while it is operating. but the next time it is powered on, the originally imprinted data appears again as the initial memory content. Imprinting can be caused by exposing the memory to either very low temperatures or X-rays, and the tamper circuitry detects either of these and zeroizes the memory before imprinting can occur.
Finally, there are attacks that are driven by manipulating the power-supply voltages to the card, and these conditions are also detected to prevent the attacks from succeeding.
5.14 PCIXCC software overview
Figure 5-14 PCIXCC software overview
PCIXCC software overview
The software that runs on the PowerPC 405GPr microprocessor is divided into four separate components as shown in Figure 5-14:
•Segment 0 contains power-on self-test (POST) 0 and Miniboot 0, stored in a region of flash EPROM that is unalterable once the card leaves the factory. POST 0 contains the small, low-level hardware self-test and setup. Miniboot 0 is the lowest level software for control of loading software into segments 1, 2, and 3.
•Segment 1 contains POST 1 and Miniboot 1. These are extensions to the POST and Miniboot in Segment 0, but have the important distinction that they can be securely reloaded after the card has been manufactured. Thus, Segment 0 holds the minimum required POST and Miniboot functions, while Segment 1 contains the majority. This is done to minimize the chances that a critical error will occur in code that cannot be updated in the field.
•Segment 2 contains the operating system and device drivers. The PCIXCC card uses an open-source imbedded Linux operating system that provides a subset of the features normally found in desktop or server Linux systems. Special device drivers have been written to allow the operating system and application program to use the unique hardware inside the card.
•Segment 3 contains the application program that runs on the PowerPC 405GPr to give the card the cryptographic API functions seen by host programs. This application program implements the IBM CCA cryptographic API, which provides the functions accessible to application programs and administrative software running in the host system.
The purpose of POST is to test and initialize all hardware in the coprocessor card, including the PowerPC 405GPr processor, the cryptographic engines, the communications interfaces, and all other logic. It prevents use of the card if there are serious faults.
The purpose of Miniboot is to control the secure loading of new software into Segments 1, 2, and 3. The Miniboot code-loading architecture provides assurance that any software executing in the card has not been tampered with, and that it was created by IBM or someone approved by IBM to do so. Each segment has control over what software can be loaded into the next segment, and all segments are protected with digital signatures that can be verified back to a root key securely managed by IBM.
5.15 DES key management
Figure 5-15 DES key management
DES key management
Because the DES and TDES algorithms are controlled by keys, the security of protected data depends on the security of the cryptographic key. The CCA uses a master key to protect other keys. Keys are active on a system only when they are encrypted under a variant of the master key, so the master key protects all keys that are used on the system. A master key always remains in a secure area in the cryptographic hardware. In a z/OS environment, an ICSF administrator initializes and changes master keys using the ICSF panels or a Trusted Key Entry (TKE) workstation.
All other keys that are encrypted under a master key are stored outside the protected area of the cryptographic hardware; they cannot be attacked because the master key used to encrypt them is itself secure inside the tamper-protected cryptographic hardware and is zeroized if there is any attempted attack. This is an effective way to protect a large number of keys while needing to provide physical security for only a master key.
When the cryptographic hardware is a PCIXCC/CEX2C, the master key is called the Symmetric-keys Master Key (SYM-MK). In a z/OS environment, the SYM-MK is 128 bits (16 bytes) long.
Cryptographic key separation
An important concept used in the CCA cryptographic API is cryptographic key separation. This concept provides for the creator of a cryptographic key (for example, using the Key Generate service) to declare the intended usage of the key through a key type specification. The cryptographic subsystem then enforces this specification by denying requested services that are inappropriate for the declared key type. For example, a key that is used to encrypt data cannot be used to encrypt a key. Likewise, a key that is designated a key-encrypting key cannot be employed in a decryption operation, thereby preventing the use of a key-encrypting key to obtain a cleartext key.
Table 5-2 shows some of the key types supported by the CCA.
Table 5-2 Some CCA key types
Key type
Attributes
CIPHER
A 64-bit or 128-bit key used in the Encipher or Decipher callable service.
DATA
A 64-bit, 128-bit, or 192-bit key used in the Encipher, Decipher, MAC generate, or MAC verify callable service.
DATAC
A 128-bit key used in the Encipher or Decipher callable service, but not in the MAC generate or MAC verify callable service.
DATAM
128-bit key used in the MAC generate or MAC verify callable service.
DATAMV
128-bit key used in the MAC verify callable service.
DECIPHER
A 64-bit or 128-bit key used only to decrypt data. DECIPHER keys cannot be used in the Encipher callable service.
ENCIPHER
A 64-bit or 128-bit key used only to encrypt data. ENCIPHER keys cannot be used in the Decipher callable service.
EXPORTER
A 128-bit key-encrypting key used to convert a key from the operational form into exportable form.
IMPORTER
A 128-bit key-encrypting key used to convert a key from the importable form into operational form.
MAC
A 64-bit or 128-bit key used in the MAC generate or MAC verify callable service.
MACVER
A 64-bit or 128-bit key used in the MAC verify callable service but not in the MAC generate callable service.
Each type of key (except the master key) has a unique control vector associated with it. The bits in a control vector specify the possible uses of the key in great detail. For example, there are bits which specify the key type, the key subtype, whether the key can be exported, and whether the key can be used in encryption, decryption, MAC generation, and MAC verification. This prevents the many attacks that are otherwise possible by using a key for an inappropriate function.
Whenever the master key is used to encrypt a key, the cryptographic hardware produces a variation of the master key according to the type of key that is being enciphered. These variations are called master key variants. The cryptographic hardware creates a master key variant by exclusive ORing a control vector with the master key. For example, when the master key is used to encipher a DATA key, the cryptographic hardware produces the master key DATA variant by XORing the master key with the control vector for DATA keys. After creating the master key DATA variant, the cryptographic hardware encrypts the DATA key by using the master key DATA variant as the key for the encryption algorithm. See Figure 5-15.
5.16 DES encryption
Figure 5-16 DES encryption
DES encryption
In Figure 5-16, we formulate a request to encrypt some plaintext using a DATA key K that has already been encrypted under the SYM-MK master key of the CEX2C (1). K has an associated control vector C. C is examined to see if it has attributes that qualify it to be used in the called service in the requested way (2). If it does not, the service invocation fails. If C is valid, execution of the requested service continues. The CEX2C XORs the master key with the DATA Control Vector to produce a master key variant (3). Next it uses the master key variant to decrypt our DATA key K (4). Finally it performs the requested encryption using the decrypted DATA key (5).
Notice that each key K is encrypted in such a way that the value of the master key and the control vector C (associated with K) must be specified to recover the key.
If a caller alters the value of the control vector to permit use of the key in a command, the correct value of the key is not recovered by the key decryption process and any resulting output of the service is invalid, that is, any output is equivalent to that resulting from using a random unknown key value in that service.
5.17 DES key forms
Figure 5-17 DES key forms
DES key forms
The CCA specifies that a DES key must be in one of three forms:
•Operational
An operational key is a key that is encrypted under the master key at a particular system and can be used in a service at that system.
•Exportable
An exportable key is a key that is encrypted under an exporter key-encrypting key. In this form, a key can be sent outside the system to another system. A key in exportable form cannot be used in a cryptographic function.
•Importable
An importable key is a key that is encrypted under an importer key-encrypting key. A key is received from another system in this form. A key in importable form cannot be used in a cryptographic function.
The conversion from one key form to another key form is considered to be a one-way flow: importable → operational → exportable. An operational key form cannot be turned back into an importable key form, and an exportable key form cannot be turned back into an operational or importable key form.
Operational keys are accessed either directly by value in an internal key token or indirectly by a key label.
•Internal key token
As shown in Figure 5-17 on page 272, an internal key token contains an encrypted cryptographic key and its associated control vector. It is typically used for a key with a short life, as for example, a key that is used for a session and is disposed of when the session is over.
•Key label
A key label indirectly identifies an internal key token stored in key storage. (An example of key storage in the z/OS environment is the ICSF Cryptographic Key Data Set, a VSAM data set often called the CKDS). An operational key is a candidate for being kept in key storage if it is a key with a long life, if it is appropriate to control access to this key, or if many users need access to this key.
The key_identifier parameter, which is found in most of the cryptographic API callable services, allows the programmer to pass keys to the service either directly by value or indirectly through a key label.
A key in importable or exportable form is kept in an external key token. The external key token contains the encrypted key and its associated control vector; see Figure 5-17 on page 272.
5.18 Key distribution: Key export
Figure 5-18 Key export
Key distribution: Key export
The CCA uses the exportable and importable key forms to support electronic key distribution with minimal manual key installation. Suppose Alice wants to send a key K to Bob. An initial exporter key-encrypting key is installed on Alice’s system by a courier, and an initial importer key-encrypting key is installed on Bob’s system. The exporter key and the importer key have the same value but different control vectors.
After the manual installation of these initial key-encrypting keys, all subsequent key distribution can be done electronically. For example, Alice can execute the Key Export service to convert the information for K found in its internal key token to an exportable key in an external key token. The external key token contains K encrypted under the exporter key (instead of the master key) and Ks that are associated control vector. The key is encrypted under the key-encrypting key that exists on Alice’s sending system as an exporter key and on Bob’s receiving system as an importer key. See where Alice sends a DATA key to Bob.
 
Note: Because the key-export service is performed in the CEX2C, the clear value of the key to be exported is not revealed. Also note that if the content of the control vector is changed either accidentally or intentionally, the correct key value will not be recovered because the value of the encrypted key is cryptographically coupled to the control vector.
5.19 Key distribution: Key import
Figure 5-19 Key import
Key distribution: Key import
Bob’s system considers the key to be in importable form. An application on Bob’s system can execute the Key Import service to perform the cryptographic transformations to convert the information in the external key token to an operational key in an internal key token. The intended usage of the key (that is, its type) is maintained through the control vector mechanism. When the key is re-enciphered from under the importer key to under the master key for Bob’s system, it is in operational form and can be used again.
5.20 PKA key management
A public key algorithm (PKA) is an asymmetric cryptographic process in which a public key is used for encryption of secret (symmetric) keys and digital signature verification and a private key is used for decryption of secret keys and digital signature generation. RSA and DSA are two public key algorithms. The security of data protected by a PKA depends on the security of the private key. The CCA uses a master key to protect private keys. Private keys are active on a system only when they are encrypted under the master key, so the master key protects all private keys that are used on the system. A master key always remains in a secure area in the cryptographic hardware. In a z/OS environment, an ICSF administrator initializes and changes master keys using the ICSF panels or a Trusted Key Entry (TKE) workstation.
Almost all private keys that are encrypted under a master key are stored outside the protected area of the cryptographic hardware; they cannot be attacked because the master key used to encrypt them is itself secure inside the tamper-protected cryptographic hardware and will be zeroized if there is any attempted attack.
There is one exception to the rule that private keys are stored outside the cryptographic hardware. CCA supports retained RSA keys, in which the RSA key pair is generated inside the secure cryptographic hardware, and only the public key is ever allowed to leave the secure environment. The private key remains inside the secure hardware and is never allowed to leave in any form. This key is designed to meet the strict demands of some standards, which require assurance that the private key can exist only in a single cryptographic module. This rule greatly strengthens non-repudiation. If a private key can exist only in one cryptographic device, it provides assurance that any digital signature computed using that private key can have originated only at the system in which that device is installed. In the PCIXCC, retained RSA private keys are stored in the flash memory inside the secure module. Similar to all CCA data stored in that memory, they are securely encrypted under a TDES key that is destroyed if there is any attempt to tamper with the device.
Conceptually, the master key used to protect DES keys could have also been used to protect PKA private keys. However, the CCA designers chose to use a different master key as follows:
•When the cryptographic hardware is a PCICC or PCIXCC/CEX2C, the 192-bit master key is called the Asymmetric-keys Master Key (ASYM-MK).
•When the cryptographic hardware is a CCF, there are two PKA master keys.
 – The Key Management Master Key (KMMK) is a 192-bit key that is used to protect private keys that are used in both digital signature generation and decryption of secret (symmetric) keys.
 – The Signature Master Key (SMK) is a 192-bit key that is used to protect private keys that are used only in digital signature generation.
Key forms
As was the case with DES keys, the CCA specifies that a PKA private key must be in one of three forms:
•Operational
An operational private key is a key that is encrypted under a PKA master key at a particular system and can be used in a service at that system.
•Exportable
An exportable private key is a key that is either in cleartext or is encrypted under a DES exporter key-encrypting key. In this form, a key can be sent outside the system to another system. A private key in exportable form cannot be used in a cryptographic function.
•Importable
An importable private key is a key that is either in cleartext or is encrypted under a DES importer key-encrypting key. A key is received from another system in this form. A private key in importable form cannot be used in a cryptographic function.
Operational keys are accessed either directly by value in an internal key token or indirectly by a key label:
•Internal key token
The format of an RSA private internal key token differs from the format of a DSS private internal key token; we only discuss the former. As shown in Figure 5-20 an RSA private internal key token contains several sections:
 – R indicates that the section is required
 – O indicates that the section is optional
In Figure 5-20 and succeeding figures:
 – d represents the RSA private exponent
 – e represents the public exponent
 – n represents the modulus
Figure 5-20 RSA private key: Internal key token
An access control system can use the private key name to verify that the calling application is entitled to use the key.
The RSA private key section can have three forms:
 – 1024-bit modulus exponent form for the CCF.
 – 2048-bit Chinese Remainder Theorem form.
 – 1024-bit modulus exponent form for the PCICC, PCIXCC, or CEX2C. See Figure 5-21.
Figure 5-21 1024-bit modulus exponent form for CEX2C
•Key label
A key label indirectly identifies an internal key token stored in key storage. (An example of key storage in the z/OS environment is the ICSF Public Key Data Set, a VSAM data set often called the PKDS).
The key_identifier parameter found in most of the cryptographic API callable services allows the programmer to pass keys to the service either directly by value or indirectly through a key label.
A private key in importable or exportable form is kept in an external key token. The format of an RSA private external key token differs from the format of a DSS private external key token; we only discuss the former. As shown in Figure 5-22, an RSA private external key token contains several sections. Again, R indicates that the section is required and O indicates that the section is optional.
Figure 5-22 RSA private key: external key token
The RSA private key section can have two forms:
 – 1024-bit modulus exponent form for the CCF and PCICC.
 – 2048-bit Chinese Remainder Theorem form for the PCICC, PCIXCC, or CEX2C. See Figure 5-23.
Figure 5-23 Chinese Remainder Theorem form
You can use the PKA Key Import callable service to do either of the following tasks:
•Get a private key deciphered from an importer key and enciphered by the ASYM-MK.
•Get a clear, unenciphered private key enciphered by the ASYM-MK.
So far we have only discussed tokens for RSA private keys. The CCA also defines a token for RSA public keys. Because public keys are meant to be shared, the format of an RSA public key token is rather simple:
•Header containing a token identifier of X’1E’ (indicating an external token)
•RSA public key section containing the public exponent e and the modulus n in cleartext.
CCA callable services can use PKA public key tokens directly in the external form.
5.21 ICSF
Figure 5-24 ICSF
ICSF
In the z/OS environment, it is the Integrated Cryptographic Service Facility (ICSF) that provides access to cryptographic functions through callable services. The ICSF callable services comply with the IBM CCA cryptographic API and are available for programs written in assembler or high-level languages. IBM CCA supports a hierarchical structure of keys where keys can be encrypted by other keys (key-encrypting keys, KEKs), the master key being at the top of the hierarchy.
ICSF provides cryptographic coprocessors administration facilities for those coprocessors that require a master key to be set.
ICSF also provides key repositories in the form of two VSAM data sets where keys can be kept in key tokens in clear value or encrypted under a KEK or under the coprocessors master keys. The VSAM data sets are the Cryptographic Key Data Set (CKDS) and the Public Key Data Set (PKDS). The key tokens in the CKDS and the PKDS are given a user- or system-defined label that is used for their retrieval and maintenance.
Figure 5-24 is a schematic view of the hardware cryptography implementation in the System z environment.
 
Note: The hardware cryptography technology that we discuss here is available on the IBM System z9 and eServer™ zSeries 990 and 890 platforms. The zSeries 800 and 900 host other, although functionally compatible, types of cryptographic coprocessors.
In the Figure 5-24, an application program has issued a CCA cryptographic API call on a System z9. The call is routed to the ICSF started task. The ICSF started task invokes RACF to determine whether the user ID associated with the request is authorized to use the requested cryptographic service and any keys associated with the request. If the user ID has the proper authority, the ICSF started task decides whether it should perform the request using ICSF software or cryptographic hardware.
If ICSF decides to use cryptographic hardware, it will give control to its routines that contain the crypto instructions. (The cryptographic instructions that drive the CPACF are listed in 5.11, “CP Assist for Cryptographic Functions (CPACF)” on page 258.) ICSF routes the request to the CEX2C and if the request is, say, a request to encrypt data, the ICSF started task provides the CEX2C with the data to be encrypted and the key to be used by the encryption algorithm. Recall that the key is encrypted, in this case under a variant of the Symmetric Keys Master Key(SYM-MK) stored in the CEX2C. The request proceeds as shown previously in Figure 5-16 on page 271.
The interactions between the functional blocks shown in Figure 5-24 are as follows:
•ICSF is a z/OS started task that offers cryptographic APIs to applications and drives the requests to the Crypto Express2 Coprocessors (CEX2C).
•The CEX2C is a “secure” coprocessor in that it contains a master key used to encrypt keys to be kept in storage or in the PKDS data set. The master key resides in the coprocessor hardware only and is used to decrypt internally to the coprocessor the secure keys that are provided so that they can be used to encrypt or decrypt data.
•ICSF needs other data sets to operate. The CKDS for the use of cryptographic hardware, and an options data set that contains the ICSF started task startup parameters. ICSF requires a PKDS as well. The PKDS doesn’t need to contain any records, or even be initialized, but it does need to be allocated by ICSF.
•Installing and maintaining the secret master key is a task that security officers can perform from TSO/E terminals or from an optional Trusted Key Entry (TKE) workstation, the latter for a very high security level of the interactions between the security officers and the CEX2C.
If there is more than one secure coprocessor to which ICSF has access, all coprocessors must have been set with the same master key value.
•The CPACF operates only with clear keys.
The keys can be stored in ICSF-managed VSAM data sets and pointed to by the application program by using the label under which they are stored. The Cryptographic Key Data Set (CKDS) is used to store the symmetric keys in their encrypted form, and the Public Key Data Set (PKDS) is used to store the asymmetric keys. If the level of ICSF that you are using is HCR7720 or higher, you can also store keys in the CKDS in clear (unencrypted) form.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.117.78.237