CCA Master Key administration: choosing the right method or tool

Edit online

Read the provided information why it is important to choose the correct tool to administer your cryptographic coprocessors.

There are several factors that influence the procedure of CCA master key administration:

  • security requirements
  • regulatory requirements
  • characteristics of your environment
Available methods are listed in Table 1.
Table 1. Tools and methods for CCA master key administration
Method Description Security Environment
TKE
  • A TKE can be used to change the master keys for all the CEX*C adapters in a group, across multiple domains and IBM Z®.
  • TKE administration is a fully tested and supported solution for CCA for Linux® on IBM® Z installations.
  • The TKE workstation is typically deployed in a secure location.
  • A TKE can leverage smart card credentials for a fully standards compliant remote administration solution.
  • The TKE and catcher daemon can be configured to communicate through a TLS connection for added security (for more details see TKE catcher configuration for a TLS connection).
  • No extra pieces are needed to support TKE administration, the required daemon is installed by default from the CCA rpm as an automated service.
  • However, if you want to use the TLS connection option, then you need to modify the /etc/cca/catcher.conf file that is part of this installation. See TKE catcher configuration for a TLS connection for more details.
  • TKE administration does not conflict with any key storage approach you might use, but application use of key storage should be taken into account as you update keys.
z/OS® exchange method An operator temporarily assigns the domains to a z/OS partition, where ICSF user IDs and configuration panels are used to configure the master keys. Since the z/OS tool is a host utility the users' key parts are potentially exposed:
  • in host memory on the system where they are entered
  • on the network channel for communication to the z host
  • in host memory for the z/OS partition
 There is no conflict with any key storage approach you might use, but application use of key storage should be taken into account as you update keys and re-assign domains.
user application A user application built to use the libcsulccamk.so library for this purpose, which can be programmed to: Security features would depend on the implementation, but may have host memory or communication channel exposures. Environment considerations would depend on the implementation.
panel.exe (included in RPM or DEB) A general purpose simple utility that can be used to set the master keys. Keys are set one part at a time to one card at a time, which has some implications.
Note: If a domain on a cryptographic coprocessor is set to PCI-HSM 2016 compliance mode, you can perform master key changes only on a TKE. You cannot use panel.exe for this purpose.
 Since panel.exe is a host utility that runs natively on the Linux instance, a local terminal and communication session are required. The users' key parts are potentially exposed:
  • in host memory on the system where they are entered
  • on the network channel for communication to the z host
  • in host memory for the Linux partition
 While panel.exe is installed by default from the CCA RPM, because of the simple nature of panel.exe, conflicts can occur in a multi-card environment. Especially, key storage conflicts occurred in prior releases when loading a master key to multiple adapters. This has been fixed as of CCA 6.0 (see Changing the master key for two or more adapters that have the same master key, with shared CCA key storage ).