The IBM Integrated Cryptography Service Facility (ICSF) is an encryption solution where the external key store resides in an IBM mainframe and is accessed using a TLS/XML protocol.
In KMS 2.0.x and later, the Key Management Appliances (KMAs) in an OKM Cluster generate their own keys using either a Hardware Security Module (such as the Sun Cryptographic Accelerator 6000 card) or the Solaris Cryptographic Framework. 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 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.
Note:
The original product name, Key Management System (KMS), changed to Oracle Key Manager (OKM) at release 2.3.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 C-1 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.
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.
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.
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.
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.
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.
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.
The IBM z/OS mainframe must be running ICSF HCR-7740 or later and StorageTek ELS 7.0 along with associated PTFs or later. A CEX2C cryptographic card must be installed on the IBM mainframe.
The OKM Cluster must be running KMS 2.2 or higher and must be using Replication Version 11 or later. The FIPS Mode Only security parameter should be set to off.
Various steps are required to configure a z/OS system to be used as an external key store for a OKM Cluster.
Refer to documentation that accompanies this card.
For ELS 7.0, the OKM-ICSF function is provided through ELS PTF L1H150P that can be downloaded from:
http://www.oracle.com/technetwork/indexes/downloads/index.html
The OKM-ICSF function is in the base code for subsequent releases. The OKM-ICSF proxy is an SMC HTTP server CGI routine. The SMC HTTP server must be active on a system with the ICSF PKCS11 function active. The KMS command is valid from the SMCPARMS data set only.
The command name.
tokenname
Specifies the PKCS11 token name for the OKM-ICSF interface. The first character of the name must be alphabetic or a national character (#, $, or @). Each of the remaining characters can be alphanumeric, a national character, or a period (.). The maximum length is 32 characters.
Specifies the default PKCS11 token name.
The following items activate the ICSF PKCS#11 function:
Ensure that ICSF is at HCR7740 or higher.
Define the Token Data Set (TKDS) in MVS. The TKDS is the repository for the keys used by PKCS#11. The TKDS is a key-sequenced VSAM data set.
Keys within the Token Data Set are not encrypted. Therefore, it is important that the security administrator create a RACF profile to protect the Token Data Set from unauthorized access.
The ICSF installation options data set contains two options related to the Token Data Set:
TKDSN(datasetname)
Identifies the VSAM data set that contains the token data set. It must be specified for ICSF to provide PKCS#11 services.
SYSPLEXTKDS(YES|NO,FAIL(YES|NO)
Specifies whether the token data set should have sysplex-wide data consistency.
See the IBM z/OS Cryptographic Services ICSF System Programmer's Guide (SA22-7520) for additional information on ICSF initialization.
ICSF uses profiles in the SAF CRYPTOZ class to control access to PKCS#11 tokens. The user ID of the HTTP Server started task must have the following SAF access level for the defined PKCS#11 token:
SO.token_name CONTROL
USER.token_name UPDATE
The document Using AT-TLS with HSC/SMC Client/Server z/OS Solution, Implementation Example (http://docs.oracle.com/cd/E21457_01/en/E27193_01/E27193_01.pdf
) shows examples for configuring AT-TLS on the IBM mainframe.
AT-TLS is an encryption solution for TCP/IP applications that is completely transparent to the application server and client. Packet encryption and decryption occurs in the z/OS TCPIP address space at the TCP protocol level.
To implement AT-TLS encryption for the OKM to NCS/ELS HTTP server connection, the minimum level needed for the Communication Server is z/OS 1.9. The following available IBM PTFs (for APAR PK69048) should be applied for best performance:
Release 1A0: UK39417 available 08/10/07 z/OS 1.10
Release 190: UK39419 available 08/10/07 z/OS 1.9
See the following IBM publications for detailed information about the IBM z/OS Communications Server Policy Agent configuration and RACF definitions for AT-TLS:
IP Configuration Guide, SC31-8775
IP Configuration Reference, SC31-8776
Security Server RACF Security Administrator's Guide, SA22-7683
Security Server RACF Command Language Reference, SA22-7687
IBM Redbook Communications Server for z/OS V1R7 TCP/IP Implementation, Volume 4, Policy-Based Network Security, SG24-7172
Specify the following parameter in the TCPIP profile data set to activate the AT-TLS function:
TCPCONFIG TTLS
This statement may be placed in the TCP OBEY file.
The Policy Agent address space controls which TCP/IP traffic is encrypted. A sample PAGENT configuration follows.
PAGENT started task JCL:
//PAGENT PROC //* //PAGENT EXEC PGM=PAGENT,REGION=0K,TIME=NOLIMIT, // PARM='POSIX(ON) ALL31(ON) ENVAR("_CEE_ENVFILE=DD:STDENV")/-d1' //* //STDENV DD DSN=pagentdataset,DISP=SHR//SYSPRINT DD SYSOUT=* //SYSOUT DD SYSOUT=* //* //CEEDUMP DD SYSOUT=*,DCB=(RECFM=FB,LRECL=132,BLKSIZE=132)
The pagentdataset data set contains the PAGENT environment variables.
This is a sample PAGENT environment variable file:
LIBPATH=/lib:/usr/lib:/usr/lpp/ldapclient/lib:. PAGENT_CONFIG_FILE=/etc/pagent.conf PAGENT_LOG_FILE=/tmp/pagent.log PAGENT_LOG_FILE_CONTROL=3000,2 _BPXK_SETIBMOPT_TRANSPORT=TCPIP TZ=MST7MDT
/etc/pagent.conf contains the PAGENT configuration parameters.
This is a sample PAGENT configuration:
TTLSRule KMS-TO-ZOS { LocalAddr localtcpipaddress RemoteAddr remotetcpipaddress LocalPortRange localportrange RemotePortRange remoteportrange Jobname HTTPserverJobname Direction Inbound Priority 255 TTLSGroupActionRef gAct1~KMS_ICSF TTLSEnvironmentActionRefeAct1~KMS_ICSF TTLSConnectionActionRef cAct1~KMS_ICSF } TTLSGroupAction gAct1~KMS_ICSF { TTLSEnabled On Trace 2 } TTLSEnvironmentAction eAct1~KMS_ICSF { HandshakeRole Server EnvironmentUserInstance 0 TTLSKeyringParmsRef keyR~ZOS } TTLSConnectionAction cAct1~KMS_ICSF { HandshakeRole ServerWithClientAuth TTLSCipherParmsRef cipher1~AT-TLS__Gold TTLSConnectionAdvancedParmsRefcAdv1~KMS_ICSF CtraceClearText Off Trace 2 } TTLSConnectionAdvancedParmscAdv1~KMS_ICSF { ApplicationControlled Off HandshakeTimeout 10 ResetCipherTimer 0 CertificateLabel certificatelabel SecondaryMap Off } TTLSKeyringParms keyR~ZOS { Keyring keyringname } TTLSCipherParms cipher1~AT-TLS__Gold { V3CipherSuites TLS_RSA_WITH_3DES_EDE_CBC_SHA V3CipherSuites TLS_RSA_WITH_AES_128_CBC_SHA }
where:
localtcpipaddress — local TCP/IP address (address of HTTP server)
remotetcpipaddress— remote TCP/IP address (address of OKM client) can be ALL for all TCP/IP addresses
localportrange — local port of HTTP server (specified in the HTTP or SMC startup)
remoteportrange — remote port range (1024-65535 for all ephemeral ports)
HTTPserverJobname — jobname of the HTTP Server
certificatelabel — label from certificate definition
keyringname — name from RACF keyring definition
Activate the following RACF classes. Either the RACF panels or the CLI may be used.
DIGTCERT
DIGTNMAP
DIGTRING
The SERVAUTH class must use RACLIST processing to prevent PORTMAP and RXSERV from abending TTLS. See "RACF Commands" below.
The RACF commands to achieve the above:
SETROPTS RACLIST(SERVAUTH)
RDEFINE SERVAUTH ** UACC(ALTER) OWNER (RACFADM)
RDEFINE STARTED PAGENT*.* OWNER(RACFADM) STDATA(USER(TCPIP) GROUP(STCGROUP)
RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE) OWNER(RACFADM)
RDEFINE FACLITY IRR.DIGTCERT.LIST UACC(NONE) OWNER(RACFADM)
RDEFINE FACILITY IRR.DIGTCERT.GENCERT UACC(NONE) OWNER (RACFADM)
The IBM Communications Server for z/OS V1R10 TCP/IP Implementation Volume 4: Security and Policy-Based Networking document outlines the procedure required to create and export digital certificates on the z/OS system.
The RACDCERT utility creates and manages digital certificates within RACF. Verify that RACDCERT is in the AUTHCMD section of the IKJTSOxx member in SYS1.PARMLIB.
The following RACF commands to create Keyrings and certificates for use by the AT-TLS function:
RACDCERT ID(stcuser) ADDRING(keyringname)
where:
stcuser — RACF user ID associated with the SMC started task
keyringname — Name of keyring, must match the Keyring specified in the PAGENT configuration
RACDCERT GENCERT CERTAUTH SUBJECTSDN(CN('serverdomainname') O('companyname') OU('unitname') C('country')) WITHLABEL('calabel') TRUSTSIZE(1024) KEYUSAGE(HANDSHAKE,DATAENCRYPT,CERTSIGN)
where:
serverdomainname — Domain name of the z/OS server (for example, mvsa.company.com)
companyname — Organization name
unitname — Organizational unit name
country — Country
calabel — Label for certificate authority (for example, CAKMSSERVER). This is the CA certificate for the OKM system.
RACDCERT ID(stcuser) GENCERT SUBJECTSDN(CN('serverdomainname') O('companyname') OU('unitname') C('country')) WITHLABEL('serverlabel') TRUST SIZE(1024) SIGNWITH(CERTAUTH LABEL('calabel'))
where:
stcuser — RACF user ID associated with the SMC started task
serverdomainname — Domain name of the z/OS server (for example, MVSA.COMPANY.COM)
companyname — Organization name
unitname — Organizational unit name
country — Country
serverlabel — Label for the server certificate (for example, KMSSERVER)
calabel — Label for certificate authority, specified in the CA certificate definition. This is the SERVER certificate
RACDCERT ID(stcuser) GENCERT SUBJECTSDN(CN('clientdomainname') O('companyname') OU('unitname') C('country')) WITHLABEL('clientlabel') TRUST SIZE(1024) SIGNWITH(CERTAUTH LABEL('calabel'))
where:
stcuser — RACF user ID associated with the SMC started task
serverdomainname — Domain name of the z/OS server (for example, MVSA.COMPANY.COM)
companyname — Organization name
unitname — Organizational unit name
country — Country
clientlabel — Label for the client certificate (for example, KMSCLIENT)
calabel — Label for certificate authority, specified in the CA certificate definition. This is the CLIENT certificate.
The following commands connect the CA, SERVER and CLIENT certificates to the keyring specified in the PAGENT configuration:
RACDCERT ID(stcuser) CONNECT(CERTAUTH LABEL('calabel') RING('keyringname') USAGE(CERTAUTH))
where:
stcuser — RACF user ID associated with the SMC started task.
calabel — Label for certificate authority, specified in the CA certificate definition
keyringname — Name of keyring, must match the Keyring specified in the PAGENT configuration
RACDCERT ID(stcuser) CONNECT(ID(stcuser) LABEL('serverlabel') RING('keyringname') DEFAULT USEAGE(PERSONAL)
where:
stcuser — RACF user ID associated with the SMC started task
serverlabel — Label for server certificate
keyringname — Name of keyring, must match the Keyring specified in the PAGENT configuration
RACDCERT ID(stcuser) CONNECT(ID(stcuser) LABEL('clientlabel') RING('keyringname') USEAGE(PERSONAL)
where:
stcuser — RACF user ID associated with the SMC started task
clientlabel — Label for client certificate
keyringname — Name of keyring, must match the Keyring specified in the PAGENT configuration
The following commands export the CA and client certificates for transmission to the OKM:
RACDCERT EXPORT (LABEL('calabel')) CERTAUTH DSN('datasetname') FORMAT(CERTB64)
where:
calabel — Label for certificate authority, specified in the CA certificate definition
datasetname — Data set to receive the exported certificate
RACDCERT EXPORT (LABEL('clientlabel')) ID(stcuser) DSN('datasetname') FORMAT(PKCS12DER) PASSWORD('password')
where:
clientlabel — Label for the client certificate
stcuser — RACF user ID associated with the SMC started task
datasetname — Data set to receive the exported certificate
password — Password for data encryption. Needed when the certificate is received on the OKM. The password must 8 characters or more.
The export data sets are now transmitted to the OKM, and FTP can be used. The CA certificate is transmitted with an EBCDIC to ASCII conversion. The CLIENT certificate is transmitted as a BINARY file and contains both the client certificate and its private key.
The following RACF commands list the status of the various RACF objects:
RLIST STARTED PAGENT.* STDATA ALL
RLIST DIGTRING * ALL
RLIST FACILITY IRR.DIGTCERT.LISTRING ALL
RLIST FACILITY IRR.DIGCERT.LST ALL
RLIST FACILITY IRR.DIGCERT.GENCERT ALL
RACDCERT ID(stcuser) LIST
RACDCERT ID(stcuser) LISTRING(keyringname)
RACDCERT CERTAUTH LIST
After configuring the IBM mainframe, the z/OS systems programmer must provide the following information to the administrator of the OKM Cluster:
Host name or IP address of the mainframe
Port number (such as 9889)
Web application path (such as "/cgi/smcgcsf")
File containing the client "user certificate" (exported and transferred off of the mainframe)
File containing the client private key (exported and transferred off of the mainframe)
Password that was used when the client private key was created
File containing the Root CA certificate (exported and transferred off of the mainframe)
The administrator of the OKM Cluster enters this information as the Master Key Provider settings in the Security Parameters panel of the OKM GUI.
The client "user certificate" and the client private key might appear in the same file when they are exported from the IBM mainframe. If so, then the administrator should specify the same file in the OKM Certificate File Name and OKM Private Key File Name fields in the Master Key Provider settings.
The fields and their descriptions are given below:
Select "Off," "All Keys," or "Recover Keys Only." A value of "Off" means that the KMAs in this OKM Cluster create their own keys and do not derive keys from a Master Key Provider. A value of "All Keys" means that the KMAs in this OKM Cluster contact the Master Key Provider defined in the settings on this screen in order to create and retrieve master keys, and then use these master keys to derive keys for Agents. A value of "Recover Keys Only" means that the KMAs in this OKM Cluster contact the Master Key Provider defined in the settings on this screen to retrieve (but not create) master keys and then use these master keys to derive keys for Agents. The "All Keys" and "Recover Keys Only" values can be set only if the Replication Version is at least 11.
Type the amount of time that defines how often this KMA should contact the Master Key Provider to create and retrieve new master keys. The default is 1 day. The minimum value is 1 day; maximum value is 25,185 days (approximately 69 years).
Type the host name or IP address of the host where the Master Key Provider resides.
Type the port number on which the Master Key Provider listens for requests from the KMAs in this OKM Cluster.
Type the web application path that forms part of the URL for contacting the Master Key Provider (for example, "/cgi/smcgcsf").
Specify the name of the file that contains the OKM certificate that was exported from the Master Key Provider host. The Master Key Provider uses this certificate to verify requests from KMAs in this OKM Cluster.
Specify the name of the file that contains the OKM private key that was exported from the Master Key Provider host. The Master Key Provider uses this private key to verify requests from KMAs in this OKM Cluster.
Type the OKM private key password as it was generated on the Master Key Provider host. The Master Key Provider uses this private key password to verify requests from KMAs in this OKM Cluster.
Specify the name of the file that contains the CA (Certificate Authority) certificate that was exported from.