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:
- Symmetric Key Encipher (CSNBSYE, CSNBSYE1, CSNESYE, CSNESYE1).
- Symmetric Key Decipher (CSNBSYD, CSNBSYD1, CSNESYD, CSNESYD1).
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:
- 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.
- 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.
- 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.
- 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
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.