For an encrypted tape cartridge, the cartridge stores not only the encrypted user data, but also critical key management-related information needed to interact with the Encryption Key Manager (EKM). The Encryption Key Manager (EKM) communicates over TCP/IP connections with the tape drive (in-band or out-of-band) to provide the key information required by the tape drive to encrypt or decrypt the data. This TCP/IP connection needs to be secure, and the security can be achieved either by physical security or with IP security protocols, such as VPN. The method for securing this TCP/IP connection relies on existing system capabilities and is outside the scope of the key management system.

The Encryption Key Manager (EKM) is a common platform application written in JAVA that runs under the Java Virtual Machine (JVM). The EKM then interfaces with an existing key store, which under z/OS may be one of the hardware based key stores (JCE4758KS (JCECCAKS) or JCE4758RACFKS (JCECCARACFKS)) that work with the Integrated Cryptographic Service Facility (ICSF), or it may be one of the software based key stores (JCEKS or JCERACFKS). If the EKM resides outside of the z/OS environment, then the JCEKS and IBMi5OSkeystore software based key stores or the PKCS11IMPLKS hardware based key store may be used.

When the encryption capable tape drive needs a key to perform an encrypted write, a data key is generated by the EKM. The data key used to encrypt the data on a tape cartridge is itself encrypted (using the public key of a public/private key pair) with either one or two key encrypting keys (KEKs) stored in the key stores. The KEKs are maintained by the EKM through an existing key store and are pointed to by the appropriate KEK label, also referred to as the key label. The EEDKs are then passed from the EKM to the drive and stored in the tape cartridge. The drive cannot decrypt the EEDKs (it can only store them), so the data key it is to use for decryption is also passed to the drive in another encrypted form that the drive can decrypt. On a subsequent mount of the cartridge, the drive passes the EEDKs to the EKMs so the Encryption Key Manager can extract the data key that was used. The EKM then passes that data key back to the drive in another encrypted form the drive can decrypt. The EEDKs can only be decrypted by an Encryption Key Manager that is connected to a key store that possesses the right key information (the private keys associated with the KEK labels).

You may use multiple encrypting tape drives and configure a single key management server to be used across these tape drives. Conversely, for redundancy, an encrypting tape drive may be configured to communicate with more than one tape key management server (both a primary and a secondary key management server). In this case, both key management servers are assumed to be capable of handling key requests from the tape drive. This implies that the key management servers are configured identically and are using the same set of public/private key pair information to encrypt and decrypt the data key.

When writing from load point, if two different key labels are specified, both key labels must be defined to the key store and accessible to the Encryption Key Manager (EKM). This ensures that both EEDK structures can be properly built by the EKM and stored on the tape cartridge. When reading a volume, only one of the two EEDK structures previously stored on the tape cartridge needs to be able to be unwrapped by the Encryption Key Manager. As part of this process the EKM will communicate with the key store to unwrap the encrypted data key stored on the cartridge in the EEDK structure.

The encoding mechanism (label or public key hash), provides instructions that the Encryption Key Manager (EKM) will use to build the EEDKs that are stored on the tape cartridge. The "Label" encoding mechanism indicates that the key label itself is to be stored as part of the EEDK structure on the tape cartridge, whereas the "public key hash" encoding mechanism indicates that a hash of the public key referenced by the key label is to be stored on the cartridge rather than the key label itself. Storing the hash value rather than the key label itself allows for greater flexibility when tape cartridges are exported to another location, especially if that location may be using a different key label (than the originating site) to refer to the same key.

The role of DFSMS and policy management is to indicate to the drive, during OPEN processing (file sequence 1, DISP=NEW) that the mounted tape volume is to be encrypted (as indicated through the SMS data class policy and the specification of EEFMT2 for the recording format). OPEN processing will also pass to the drive critical key management-related information such as the key encrypting key (KEK) labels and the encoding mechanism (label or public key hash) specified through data class or through the DD statement (JCL, dynamic allocation or TSO ALLOCATE). The values specified through the DD statement will override any data class specification. If the key-management-related information is not specified through the DD statement or data class, Encryption Key Manager established defaults will be used that can be specified on both a global and a drive level.

The drive's request for the data key and the passing of key management-related information can be done in-band between the drive and the Encryption Key Manager (through the control unit and host across ESCON/FICON) or it can be done out-of-band (through the control unit across TCP/IP). However, because the Encryption Key Manager (EKM) only has a TCP/IP interface, in-band communication to the EKM is handled by a new z/OS proxy interface. The proxy interface receives the request from the drive across ESCON/FICON and then interfaces with the established EKM for that system across TCP/IP. The z/OS proxy then communicates back to the drive (through the control unit across ESCON/FICON) providing the key management-related information that the drive needs. Under z/OS, the recommended communication path to the EKM is in-band across ESCON/FICON under the same system that initiated the read or write request. The EKM itself, however, can reside on that same z/OS system, on another z/OS system, or even on another platform's server. Out-of-band key management, from the control unit across TCP/IP, can be used to communicate with an EKM running under a z/OS system or somewhere else. By default, the control unit will use out-of-band key management unless otherwise changed by default or by explicit host command. With the interface to the EKM being across TCP/IP, you have, based on your TCP/IP infrastructure and key management requirements, a number of different configuration options available, for both in-band and out-of-band key management. If in-band key management is to be used, the existing IOS PARMLIB member IECIOSxx (or the SETIOS EKM command) must be updated to specify the TCP/IP-related information needed to direct the z/OS proxy to the desired Encryption Key Manager (primary and secondary).