Secure key considerations

Creating and managing secure keys depends on your security policies. You can use the zkey command to generate a secure key and store it in a secure key repository or in a specified binary secure key file.

As a prerequisite, the pkey kernel module must be loaded, and an AES master key must exist on a domain of the cryptographic coprocessor. Refer to How to set an AES master key for information about setting a CCA master key. For setting an EP11 master key, refer to Exploiting Enterprise PKCS #11 using openCryptoki.

For comprehensive information about the TKE refer to:

z/OS Cryptographic Services ICSF Trusted Key Entry Workstation User’s Guide, 
shown in the list of z/OS Cryptograohic Services

The zkey command issues a request to a domain of a cryptographic coprocessor to generate a secure key by wrapping a randomly generated plain text key with an existing master key. Or, you can pass a binary input file containing a clear key to the zkey command for secure key generation.

Using the --key-type parameter of the zkey command, you can decide between various types of secure keys: a CCA AES DATA key, a CCA AES CIPHER key, or an EP11 AES key or an PVSECRET-AES key for use with pervasive volume encryption. An AES DATA secure key is generated as the default, if you omit this parameter.

With an AES CIPHER secure key, certain attributes are cryptographically bound to the key. These attributes may limit the usage of the key, for example, restrict the export or the usability scope. So this key type is assumed to be even more secure than the default AES DATA key. To generate an AES CIPHER secure key, a CEX6C or later coprocessor is required. If more than one domain or cryptographic coprocessors are used, the master key setup needs to be identical for each APQN.

If your installation uses cryptographic coprocessors configured in EP11 mode, you can work with EP11 AES secure keys starting with CEX7P adapters (see the following note).

Do not explicitly generate a clear key into a binary file to subsequently transform it into a secure key, unless you can perform this operation in a safe clean room environment. Otherwise you risk being observed during the clear key generation, or some software components still contain some remains of the generated clear key.

When providing the clear key in an input file, this file should be kept at a secure place (clean room), or it should be securely erased after creation of the secure key, for example, with the shred command. The secure key itself does not need to be kept securely, because it can only be processed within a cryptographic coprocessor that contains the adequate AES master key.

The clear keys themselves are never stored persistently on the cryptographic coprocessor, but can only be reconstructed by decrypting the secure key with the pertaining master key within the cryptographic coprocessor.

For safety and security reasons, protect the secure key file as described in Managing a secure key repository.

If you format a volume with LUKS2 and a secure key, the secure key is encrypted and stored in a key slot of the LUKS2 header. During secure key generation, you can decide to additionally store the secure key in a secure key repository for archive purposes. For more information, see Managing a secure key repository.

For more information about the zkey command, read zkey - Managing secure keys and also see the zkey man page.