Managing a secure key repository
You should keep the generated secure keys in a repository because each time the master key changes on the cryptographic coprocessor, you must re-encipher the secure keys with the new master key. The zkey command supports all tasks in the context of secure key management. These tasks are introduced and presented with an example.
For detailed information refer to the zkey man page or to zkey - Managing secure keys.
When storing the secure key in a key repository, additional information, such as a description of the key, can be associated with a secure key. You can associate a secure key with one or multiple cryptographic coprocessors (APQNs) that are set up with the same CCA AES or EP11 AES master key. You can also associate a secure key with one or multiple volumes (block devices), which are encrypted using dm-crypt with the secure key. The volume association also contains the device-mapper name, separated by a colon, used with dm-crypt. A specific volume can only be associated with one secure key.
Keep a copy of the secure keys used for disk encryption in a secure key repository. That way, you can easily re-encipher the secure keys in case of a master key change even for archived disks. LUKS2 disks contain the secure key in the LUKS2 header. You would normally re-encipher these volume keys when the master key changes. When the disk is already in the archive, this might be cumbersome. If you have a valid secure key in the repository, that has been re-enciphered with every master key change, you can still recover such an archived volume, even after multiple master key changes. For details, refer to Recovering secure key encrypted volumes.