When the first file sequence on a tape is written and encryption
is requested, up to two key encrypting key (KEK) labels can be specified,
enabling the data key to be encrypted with two different keys. One
of the keys may be used for local (on-site) usage and the second may
be used for export (off-site) purposes.
Note: When the specified
key labels are being used for export purposes, remember that the encryption
key manager requires that at least one of the key encrypting key (KEK)
labels specified has to have a private key associated with it. This
allows the creator of the tape to also decrypt the data key (and the
data) in case of an emergency.
Key label specifications can be specified by:
- Data class (using new ISMF panel fields)
- DD statement (JCL or dynamic allocation, using new keywords KEYLABL1,
KEYENCD1 and KEYLABL2, KEYENCD2)
- TSO ALLOCATE command (using new keywords KEYLABL1, KEYENCD1 and
KEYLABL2, KEYENCD2)
However specified, key label specifications consist of either one
or two key labels, and their associated encoding mechanisms. The
key label specifies the label for the key encrypting
key used by the Encryption Key Manager. The key encrypting key is
used to encrypt the data encryption key. The
encoding
mechanism specifies how the label for the key encrypting key
specified by the key label (input) is encoded by the Encryption Key
Manager and stored on the tape cartridge. The two encoding mechanisms
are:
- H
- the label for the key encrypting key is to be encoded as a hash
of the public key
- L
- the label for the key encrypting key is to be encoded as the
specified label
Rules for key labels : - Specification of the key labels are optional and are only applicable
with DISP=NEW, file sequence 1 and are otherwise ignored. If the
key labels are not specified, either through the DD statement or through
data class, externally specified Encryption Key Manager defaults will
be used.
- Specification of the key labels does not by itself enable encryption.
Encryption must be enabled by a data class that specifies the encryption
format EEFMT2. Whether the data on a tape cartridge is encrypted
or not is then determined when an encryption capable device is allocated
and the first file sequence on the tape is written.
Note: In
the system-managed environment, specification of the encryption format
EEFMT2 will not only request that the encryption format be used, but
will also steer allocation to an encryption capable device. In the
stand-alone (non-system managed) environment, encryption capable devices
must be specified through the UNIT parameter to ensure that an encryption
capable device is allocated, with specification of the encryption
format EEFMT2 then being used to request the encryption format.
- One or both key labels may be specified. If a key label is specified,
then its encoding mechanism must also be specified and if an encoding
mechanism is specified, then its corresponding key label must also
be specified. If only one key label is specified, specification of
key label 1 or key label 2 is allowed; it doesn't have to be specified
as key label 1.
- If only one key label is specified, the same key label and encoding
mechanism is used to generate both EEDKs that are stored on the tape.
- The key labels must come from the same source; either the DD statement,
data class, or the externally specified Encryption Key Manager defaults.
The key labels specified on the DD statement will override the key
labels specified through data class which will then override any externally
specified Encryption Key Manager defaults.
- The key label can be up to 64 characters, with blanks padding
the field on the right. The character string supported is a subset
of EBCDIC code page 037. The characters supported are those that
map to the portable ASCII characters represented in international
standard ISO 646-IRV (US ASCII), which includes numeric, alphabetic,
national, and special characters, along with additional punctuation-type
characters. National variants of ISO 646 provide for internationalization
of the character string. ISO 646-IRV (US ASCII) is a subset of ISO
8859-1 (Latin Alphabet No. 1). The translation from EBCDIC to ASCII
and syntax validation of the character string specified occurs at
the control unit, and as such, the character set supported stays within
the boundaries of 7-bit ASCII and can be successfully handled by the
Encryption Key Manager and key store, which both use UTF-8 encoding.
From a host perspective, the key label is considered a free form
field (binary token) with no validation checking other than to remove
leading blanks. The key label syntax is not validated until it is
sent to the control unit on a mount request using the specified key
label with the control unit then removing trailing blanks. The specified
alphabetic characters will be treated as case insensitive by the key
store and, therefore, in order for key labels to be unique, they should
differ by more than just their case. Refer to the key store documentation
and the tooling available for creating the key labels for any additional
requirements or restrictions.