Understanding the ICSF Solution
In the ICSF solution and external key store (IBM mainframe) connects to OKM over a WAN.
In this solution, the external key store resides in an IBM mainframe and is accessed using a TLS/XML protocol. This protocol is supported in the IBM mainframe with the keys stored in a Token Data Set in the IBM Integrated Cryptography Service Facility (ICSF). The figure below shows a typical configuration.
The OKM Cluster periodically issues requests to the IBM mainframe, asking to create new master keys (referred to as application keys in ICSF) and to return them to the OKM Cluster. The KMAs then use these new master keys to derive new tape keys.
Defining the ICSF System Components
The ICSF system components include the keystore, interface, transfer security, key derivation, key policy, and key recovery.
KeyStore
Master (application) keys are stored in the Token Data Set (TKDS), as defined in the IBM ICSF documentation. The TKDS is identified in the ICSF installation options data set. The z/OS system programmer can create the TKDS by using the IDCAMS utility.
Keys stored in the TKDS are not encrypted, but access to the data set itself, as well as Callable Services and Tokens (key sets), is controlled by RACF or an equivalent. Access to the TKDS can be defined by the current policy for backup and restore of Master Keys.
Interface
The StorageTek ELS software implements an ICSF Callable Services Proxy. This Proxy allows the OKM Cluster to call PKCS#11 functions to access the KeyStore. Secure communication with the OKM Cluster is implemented using the z/OS Application Transparent - Transport Layer Security (AT-TLS) on the IBM mainframe.
AT-TLS is an encryption solution for TCP/IP applications that is completely transparent to the application client and server. Packet encryption and decryption occur in the z/OS TCPIP address space at the TCP protocol level. The encrypted packet payload is unintelligible when sniffed or traced, but by the time it is delivered to the application the payload is once again readable.
Transfer Security
The OKM Cluster implements a Transport Layer Security (TLS) protocol to communicate with the Proxy on the IBM mainframe.
The z/OS system programmer generates and then exports two self-signed X.509v3 certificates and one RSA 2048-bit public key pair, and then transfers them (using FTP) off the IBM mainframe. The first certificate is a Root Certificate Authority (CA) certificate. The system programmer uses this Root CA certificate to generate the Client Certificate and Key Pair. These certificates and the key pair are manually installed in the IBM mainframe and configured using RACF and AT-TLS so that the Proxy can identify a valid OKM request. The certificates and the private key of the key pair are installed in the OKM Cluster so that it can authenticate the Proxy. As a result, only KMAs in a valid OKM Cluster can issue requests to the Proxy, and they accept a response only from a valid Proxy.
Key Derivation
The OKM Cluster accepts a Master Key Value and 18-byte Master Key ID from the Proxy. It creates a 30-byte Key ID by concatenating a 2-byte header and the 18-byte Master Key ID with an internally generated 10-byte value. It then creates a Derived Key Value by encrypting the Key ID (padded to 32 bytes) with the Master Key Value.
Key management between Drives and the OKM Cluster continue to use the current OKM strategy. Thus, no firmware upgrades are required.
Key Policy
The OKM Cluster controls the Master Key lifecycle. It requests a current Master Key value from the Proxy based on the current date. The Proxy retrieves the current Master Key from the TKDS using a sequence of PKCS#11 function calls. If there is no current Master Key Value, the OKM Cluster issues a Create Master Key request to the Proxy. The OKM can then re-submit the request for a current Master Key Value from the Proxy.
Key Recovery
The OKM Cluster retains all derived Keys and Key IDs it creates. If the Cluster does not have the Key for a specified set of written data, it can re-derive the Key by forming the Master Key ID from the Key ID and then issuing a retrieve request to the Proxy to get the Master Key Value stored in the TKDS. The OKM can then re-derive the Key Value to enable its Agent to read the data.
This key recovery mechanism allows "ground-level up" recovery of all tapes encrypted by this system, based only on availability of archived Master Keys in the TKDS.