Protected-key CPACF

Protected-key CPACF provides both high performance and high security by taking advantage of the high speed of CPACF while utilizing encrypted keys. It does this by using CPACF wrapping keys to protect the key during CPACF processing instead of passing a clear key. These wrapping keys (one for Advanced Encryption Standard (AES) keys and one for Data Encryption Standard (DES) keys) are analogous to the coprocessor master keys and are visible only to licensed internal code (LIC) and never to operating system storage.

Two callable services are enhanced to support protected-key CPACF: For many releases, both of these services have accepted labels for the key_identifier parameter when the KEYIDENT keyword is provided in the rule_array. Before protected-key CPACF, this label was restricted to refer to a clear DATA key in the CKDS. With protected-key CPACF enabled, the label may now refer to an encrypted DATA key as well.

ICSF processes a secure key usable by a coprocessor (a CCA encrypted key token) into a secure key usable by CPACF (a CPACF-wrapped key). Each CPACF wrapped key is kept on hand after the first use so it can be used again for a subsequent encryption or decryption request.

To transform a CCA-encrypted key token into a CPACF-wrapped key, ICSF does the following:
  1. Determines if the key has already been wrapped for use with CPACF. ICSF maintains a cache of CPACF-wrapped DATA keys. When a label is specified on a call to the Symmetric Key Encipher or Symmetric Key Decipher service, ICSF retrieves the key from the in-storage copy of the CKDS. If it is an encrypted DATA key, ICSF looks for a cached copy and uses it if one is present.
  2. Determines if this key is a candidate for wrapping. If the key has not been wrapped for CPACF and cached, ICSF inspects a field in the covering CSFKEYS profile to check for permission. A CSFKEYS profile can contain an ICSF segment, which specifies rules for key use. The SYMCPACFWRAP field of the ICSF segment indicates whether ICSF can rewrap the encrypted key using the CPACF wrapping key. If there is no covering profile, or ICSF(SYMCPACFWRAP(NO)) is set, ICSF does not allow the operation.
  3. Requests the wrapping operation. ICSF builds a request to a Crypto Express3 Coprocessor (CEX3C) or later coprocessor. In the coprocessor, the encrypted DATA key is recovered from under the card master key. The clear form is presented back to the LIC layer, which wraps the clear key value under the corresponding CPACF wrapping key (either AES or DES) before returning the key to operating system storage. At no point during this operation is the clear key value visible in operating system storage.
  4. Caches the returned CPACF-wrapped key for future use.
Figure 1 shows how ICSF transforms a CCA-encrypted key token into a CPACF-wrapped key.
Figure 1. Transforming a CCA-encrypted key token into a CPACF-wrapped key
Transforming a CCA-encrypted key token into a CPACF-wrapped key

For more information about the Symmetric Key Encipher and Symmetric Key Decipher callable services, see z/OS Cryptographic Services ICSF Application Programmer's Guide.

For more information on the SYMCPACFWRAP field of the ICSF segment of CSFKEYS profiles, see z/OS Cryptographic Services ICSF Administrator's Guide.