Skip Headers
Oracle® Key Manager 3 OKM-ICSF Integration Guide
Release 3.0
E49727-01
  Go To Table Of Contents
Contents

Previous
Previous
 
Next
Next
 

1 OKM-ICSF Integration Overview

This chapter summarizes the OKM-ICSF integration solution.

Key Stores and Master Key Mode

In KMS 2.0.x and later, the KMAs in an Oracle Key Manager (OKM) Cluster generate their own keys using their Sun Cryptographic Accelerator (SCA) 6000 cards. Some customers prefer to have the KMAs use master keys that are created and stored in an external key store.

KMS 2.2 introduced a Master Key Mode feature. When this feature is enabled, the OKM Cluster derives tape keys from a set of master keys. The master keys are created and stored in an external key store. Full disaster recovery is possible with just the tapes, the master keys, and factory default OKM equipment.

Understanding the Solution

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). Figure 1-1 shows a typical configuration.

Figure 1-1 Site Configurations

Surrounding text describes Figure 1-1 .

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 System Components

The following components comprise the integration solution and are discussed in this section:

Figure 1-2 ICSF Components

Surrounding text describes Figure 1-2 .

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

You must add a module to the existing Sun Mainframe Software to implement 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 occurs 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.

System Requirements

The IBM mainframe and the OKM Cluster both have system requirements in this solution.

IBM Mainframe

The IBM z/OS mainframe must be running ICSF HCR-7740 or higher and Sun ELS 7.0 or NCS 6.2 along with associated PTFs. A CEX2C cryptographic card must also be installed on the IBM mainframe.

OKM Cluster

The OKM Cluster must be running KMS 2.2 or higher and must be using Replication Version 11 or higher. KMAs are shipped with SCA 6000 cards.