This topic provides information about encryption key management.
IBM addresses encryption key management in its self-encrypting
tape storage solutions with these
encryption
key servers:
These three encryption solutions are collectively referred to
as the
"encryption
key server" (EKS)
unless a specific product is being discussed.
The EKS operates on supported operating systems and is designed
to be a shared resource, deployed in several locations within an enterprise.
For example, the EKS can serve encrypting tape drives in tape library
subsystems, connected to mainframe systems through Fibre Channel connections,
or installed in other computing systems.
The EKS acts as a daemon process, serving requests for key generation
and key retrieval. Requests are sent through a TCP/IP communication
path between the EKS and the tape library, tape controller, tape subsystem,
device driver, or tape drive. The EKS uses a keystore to hold the
certificates and keys (or pointers to the certificates and keys) required
for all encryption tasks. Refer to the appropriate EKS documentation
for detailed information about the EKS and the keystores it supports.
There are three methods of encryption management to choose from.
These methods differ in where the encryption policy engine resides,
where key management is performed, and how the EKS is connected to
the drive.
Note: Although the EKS supports the following three environmental
layers, the 3592-C07 controller and System z® support only system-managed
encryption.
Figure 1. Three possible locations for encryption
policy engine and key management.
- Application Layer
- Initiates data transfer for tape storage, for example TSM.
- System Layer
- Everything between the application and the tape drives, for example
the operating system, z/OS DFSMS, device
drivers, and FICON® controllers.
- Library Layer
- The IBM System Storage™ TS3500 Tape Library,
which contains an internal interface to each tape drive within it.