Redpaper

William C. Johnston Axel Buecker

Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager
Introduction
IBM Tivoli Key Lifecycle Manager (TKLM) delivers simplified key life-cycle management capabilities in a solution that is easy to install, deploy, and manage. Tivoli Key Lifecycle Manager allows you to create, back up, and manage the life cycle of keys and certificates that an organization uses, including the management of symmetric keys, asymmetric key parts, and certificates. Tivoli Key Lifecycle Manager also provides a graphical user interface (GUI) and a command-line interface (CLI) to manage keys and certificates. Tivoli Key Lifecycle Manager provides these functions: Key serving with life-cycle management, using a GUI and CLI to manage keys and certificates Support for encryption-enabled IBM 3592 and Linear Tape-Open (LTO) tape drives, as well as IBM DS8000 Turbo drives Encrypted backup and recovery to protect the critical keystore and other Tivoli Key Lifecycle Manager data, such as the configuration file System Management Facility (SMF)-based audit records that are based on selected events that are occurring as a result of successful operations, unsuccessful operations, or both Debug for additional information about the Tivoli Key Lifecycle Manager problems In this IBM Redpaper publication, we discuss the actions that are required to migrate an existing IBM Encryption Key Manager (EKM) installation on z/OS to Tivoli Key Lifecycle Manager for z/OS.

Copyright IBM Corp. 2010. All rights reserved.

ibm.com/redbooks

Differences between the products

Although IBM Encryption Key Manager and Tivoli Key Lifecycle Manager both serve encryption keys to tape drives, the ways in which they do so differ. For example, Encryption Key Manager accesses an existing keystore that is managed independently from the key manager. Tivoli Key Lifecycle Manager manages the keystore internally. Figure 1 depicts an architectural comparison diagram.

Figure 1 Product comparison

Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager

Encryption Key Manager operations

Encryption Key Manager is a Java process that accesses a keystore through Java Cryptography Extension (JCE) interfaces. Encryption Key Manager keeps track of its drives, metadata, and logs in UNIX System Services files. The keystore is managed through processes that are external to Encryption Key Manager. Encryption Key Manager uses a configuration or properties file to maintain attributes about the installation. The systems programmer usually manages this properties file. Specific attributes, such as default key labels, are maintained in this property file. During migration, the configuration, keystore file, as well as drive and metadata information, are moved into the Tivoli Key Lifecycle Manager environment. Typically, on z/OS, Encryption Key Manager runs as a started task in a JzOS environment. Commands are issued to Encryption Key Manager through the z/OS MODIFY operator command. Figure 2 shows the architectural components of an Encryption Key Manager infrastructure.

Figure 2 Encryption Key Manager components

Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager

Tivoli Key Lifecycle Manager operations

Tivoli Key Lifecycle Manager is a System Services Runtime Environment (SSRE) application Java process that accesses a keystore through Java JCE interfaces. Tivoli Key Lifecycle Manager keeps track of its drives and metadata using IBM DB2 tables, and logs in UNIX System Services files. The keystore is managed internally through the Tivoli Key Lifecycle Manager interfaces. Tivoli Key Lifecycle Manager runs under the management of SSRE, which is a WebSphere Application Server on z/OS for especially entitled applications; Tivoli Key Lifecycle Manager is one of these entitled applications. Tivoli Key Lifecycle Manager manages its configuration files internally. Administrators of Tivoli Key Lifecycle Manager access changeable properties through the Integrated Solutions Console (ISC) Web-based interface. The ISC creates and manages the keys. Figure 3 shows the architectural components of a Tivoli Key Lifecycle Manager infrastructure.

Figure 3 Tivoli Key Lifecycle Manager components

Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager

Planning the migration

Moving from an Encryption Key Manager environment to the Tivoli Key Lifecycle Manager environment enables you to have more control over your key management infrastructure. Encryption Key Manager only reads keys from a preexisting and separately managed keystore; however, Tivoli Key Lifecycle Manager creates and manages the keystore, as well as the keys that it contains. When Encryption Key Manager is migrated to Tivoli Key Lifecycle Manager, the keys in the existing keystore, drive table information, and metadata are brought into the new Tivoli Key Lifecycle Manager environment. Tivoli Key Lifecycle Manager uses DB2, as well as system files, to manage metadata.

Important considerations
Before you begin, consider the following issues. Ensure that your organization allows a time interval for a temporary halt to key serving activity. While the migration runs, no key serving activity can occur. A window of testing in a test environment is also required to ensure that the new Tivoli Key Lifecycle Manager has the expected keys and other configuration attributes that you intended to migrate. Back up the Encryption Key Manager server that has the configuration data that you intend to migrate. Migrated data includes these types of information: A configuration properties file. Keys and certificates that are referenced by the configuration properties file. Drive tables. An optional metadata file to which the configuration properties file points. An optional key groups file. Migrate only one Encryption Key Manager server to one Tivoli Key Lifecycle Manager server. To migrate a second Encryption Key Manager server, use a second Tivoli Key Lifecycle Manager server. Both the Encryption Key Manager server and the Tivoli Key Lifecycle Manager server that receives the migrated data must be on the same z/OS system, which must be at Version 1, Release 9 or later. After migration, the Tivoli Key Lifecycle Manager server uses the keystore, TCP port, and Secure Sockets Layer (SSL) port that the Encryption Key Manager server previously used. Before you migrate, refresh and stop the Encryption Key Manager server to ensure that there is no data loss. Encryption Key Manager cannot be active when you perform the actual migration.

Migration restrictions
Encryption Key Manager supports a separate set of keystores and manages keys differently than Tivoli Key Lifecycle Manager. There are certain restrictions on what information will be migrated: The migration of Administrator SSL keystores and truststores is not supported. The Tivoli Key Lifecycle Manager server does not support the Administrator synchronization capability. The migration of PKCS11Impl keystores and truststores is not supported. The Tivoli Key Lifecycle Manager server does not support PKCS11Impl keystores. Because this migration is on z/OS, no PKCS11Impl keystore exists. So, this restriction does not apply.
Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager

Tivoli Key Lifecycle Manager does not support the use of a key in multiple groups, unlike Encryption Key Manager, which allows the use of a key in multiple groups. Keygroups are sets of symmetrical keys that are used for LTO-4 drive-based encryption. This restriction only becomes an issue if the keystore that is being migrated is of the JCEKS type (a flat UNIX file). When you migrate key data in the KeyGroup.xml file from Encryption Key Manager to Tivoli Key Lifecycle Manager, each key is attached to one group. A key that was previously in multiple groups in Encryption Key Manager is created in only one group in Tivoli Key Lifecycle Manager. This restriction only becomes an issue if the keystore being migrated is of the type JCEKS.

Migrating data objects and properties

The following data objects are migrated.

Keystores
Encryption Key Manager has several types of keystores, each with a separate purpose. These keystores are listed in the Encryption Key Manager properties file: config.keystore.file TransportListener.ssl.keystore.name Used to hold encryption keys. Migrated to Tivoli Key Lifecycle Manager. Used for Encryption Key Manager server authentication. Migrated to Tivoli Key Lifecycle Manager.

TransportListener.ssl.truststore.name Used for Encryption Key Manager client authentication. Not migrated to Tivoli Key Lifecycle Manager. Admin.ssl.keystore.name Used when Encryption Key Manager is a target server for sync operations. Not migrated to Tivoli Key Lifecycle Manager. Used when Encryption Key Manager is a client for sync operations. Not migrated to Tivoli Key Lifecycle Manager.

Admin.ssl.truststore.name

Note that Encryption Key Manager uses the term truststore to denote keystores from certificates that are used by clients. Because the Tivoli Key Lifecycle Manager clients authenticate to the WebSphere Application Server environment, either through the ISC or the CLI using wsadmin, no client side keystore or truststore is necessary. Tivoli Key Lifecycle Manager supports only one keystore, which is identified by the config.keystore.name property in the TKLMgrConfig.properties file. This keystore is equivalent to the Encryption Key Manager Config keystore (config.keystore.file). During migration, the two Encryption Key Manager keystores, config.keystore.file and TransportListener.ssl.keystore.name, are merged into the single Tivoli Key Lifecycle Manager keystore. The resulting keystore is created with a default name of Tivoli Key Lifecycle Manager Keystore. That is, this entry is in the TKLMgrConfig.properties file: config.keystore.name = Tivoli Key Lifecycle Manager Keystore

Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager

All certificates from the Encryption Key Manager config.keystore.file keystore are added to the Tivoli Key Lifecycle Manager keystore. All the certificates from the TransportListener.ssl.truststore.name truststore are added to the Tivoli Key Lifecycle Manager keystore, and one of the certificates is set as an SSL certificate. The config.keystore.ssl.certalias property is updated with the alias of this certificate. This certificate is used to secure communications between the ISC GUI and the Tivoli Key Lifecycle Manager server. Other Encryption Key Manager keystores are not used.

Devices
All the device information is read from the drive table pointed at by the config.drivetable.file.url property, and it is entered in a Tivoli Key Lifecycle Manager database. If the drive has the symalias property defined, the drive type is set to LTO. If the drive has aliases defined, the drive type is set to 3592. If the drive does not have any of these properties defined and the type cannot be determined during migration, the type is set to UNKNOWN.

Keygroups
The keygroup.xml file, to which the config.keygroup.xml.file property points, is parsed, and the keygroup information is stored in a Tivoli Key Lifecycle Manager database. All the group members and group relationships are also migrated. The group member and group relationship migration only applies to Encryption Key Manager Version 2.1.

Metadata
All the metadata information, to which the audit.metadata.file.name property points, is migrated to a Tivoli Key Lifecycle Manager database. This metadata migration only applies to Encryption Key Manager versions 2.0 and 2.1.

Properties
The following properties are migrated from the Encryption Key Manager configuration file to the TKLMgrConfig.properties file: audit.eventQueue.max audit.handler.file.size audit.event.outcome audit.event.types config.keystore.name (set to Tivoli Key Lifecycle Manager Keystore) cert.valiDATE drive.acceptUnknownDrives drive.default.alias1 drive.default.alias2 fips symmetricKeySet (set to DefaultMigrationGroup if it was not a symmetricKeySet, otherwise, set to the groupName) TransportListener.ssl.ciphersuites TransportListener.ssl.clientauthentication TransportListener.ssl.port TransportListener.ssl.protocols

Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager

TransportListener.ssl.timeout TransportListener.tcp.port TransportListener.tcp.timeout useSKIDefaultLabels zOSCompatibility

When to migrate
It is important that you understand when to migrate Encryption Key Manager to Tivoli Key Lifecycle Manager. Because Tivoli Key Lifecycle Manager manages the keys life cycles, it needs to track more than just the existence of the keys. Tivoli Key Lifecycle Manager manages this information in several DB2 tablespaces. Although Encryption Key Manager can continue to serve keys after its data is migrated to Tivoli Key Lifecycle Manager, it is important to know that you can only migrate Encryption Key Manager one time. Any keys that are added to the Encryption Key Manager keystore after migration will not be recognized by Tivoli Key Lifecycle Manager. Tivoli Key Lifecycle Manager will take control of the Encryption Key Manager keystore. For example, if the keystore is a JCERACFKS RACF keyring, that same keyring and user ID will be used by Tivoli Key Lifecycle Manager. Data is not moved to a new keyring. Also, Tivoli Key Lifecycle Manager will take control of the Encryption Key Manager keystore in the same way if the keystore is a JCEKS UNIX file. Tivoli Key Lifecycle Manager will read the keystore and create metadata in DB2 for its contents. You can only migrate Encryption Key Manager to Tivoli Key Lifecycle Manager at one of these times: During the Tivoli Key Lifecycle Manager installation process After the Tivoli Key Lifecycle Manager installation completes, but before the creation of the Tivoli Key Lifecycle Manager master keystore Master keystore: After Tivoli Key Lifecycle Manager has created a master keystore, you cannot migrate Encryption Key Manager to Tivoli Key Lifecycle Manager.

Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager

Preparing for the migration

You must complete the following tasks, if applicable, before starting the migration from Encryption Key Manager to Tivoli Key Lifecycle Manager on z/OS: 1. Set the required permissions for the Encryption Key Manager files. This discussion uses the Encryption Key Manager property values (Table 1) to denote the files to which SSRECFG requires READ access. Refer to the Encryption Key Manager properties file for installation-specific filenames.
Table 1 Required file permissions for migration Property config.drivetable.file.url config.keygroup.xml.file Use Drivetable: The tracking of drives to keys used by Encryption Key Manager. Keygroups file: Information about what symmetric keys are grouped together. Used by LTO-4 drives. Audit metadata file: Encryption Key Manager Version 2.0 and higher only. For keystores of type JCEKS, JCE4758KS, or JCECCAKS, give READ and WRITE permissions to the keystore file and READ and WRITE permissions to the full directory path in which the keystore is located. For a RACF keystore (that is, of type JCERACFKS, JCE4578RACFKS, or JCECCARACFKS), give the SSREGRP group ID permissions to the Encryption Key Manager keyring, keys, and certificates.

audit.metadata.file.name config.keystore.file Depending on the value of config.keystore.type, this property might be a Resource Access Control Facility (RACF) keyring or a flat file.

2. Ensure that the following values in the Encryption Key Manager properties file are defined as absolute paths: audit.metadata.file.name config.drivetable.file.url config.keygroup.xml.file

Setting up permissions to RACF keyrings and certificates

You must perform the following preparations for the System Services Runtime Environment configuration ID, such as SSRECFG, and for the user ID to which the System Services Runtime Environment-started task is associated, such as SSREADM. These IDs must be able to create and access keyrings before you select and configure the RACF keyring using the GUI panels in Tivoli Key Lifecycle Manager. From the directory where the tklm.jar file was expanded, edit the racfpermissions.rexx exec: oedit samples/racfpermissions.rexx

Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager

You must review the set of variables that follows the prolog in the racfpermissions.rexx script: groupid This variable is the ID of the group of Tivoli Key Lifecycle Manager users. By default, the permissions in this sample script are granted at the group level (that is, SSREGRP). This value can be any RACF ID (either user ID or group ID) that needs access to the keyring. Default groupid = SSREGRP userid This variable is the user ID. It is only used one time in this script. The user ID must be the SSRE-started task user ID, which defaults to SSREADM. Default userid = SSREADM ownerid This variable is the user ID of the owner of the EKM master keystore keyring. A typical Encryption Key Manager installation might have used user ID EKMSERV. Default ownerid = OWNERID keyring This variable is the name of the Encryption Key Manager keyring to which the SSRE group is being granted access. A typical Encryption Key Manager installation might have used a ring name of EKMRing. Default keyring = KEYRING You can use a REXX script by running the script directly in OMVS. Or, you can copy the script into a dataset and run the script in the TSO command line by using the following command: To execute from the UNIX System Services environment: Insure that the correct UNIX permissions are set for accessing the file: chmod 755 racfpermissions.rexx Run the executable (this example shows the executable being run from the samples directory): . ./racfpermissions.rexx To execute from the Time Sharing Option Extensions (TSO)/E environment: Copy the executable to a partitioned dataset (for example, HLQ.REXX(sample)) cp racfpermissions.rexx "//''HLQ.REXX(sample)' " We describe the RACF commands that are issued from the racfpermissions.rexx script in Appendix: RACF commands on page 13.

10

Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager

Running the migration

Perform these steps to migrate Encryption Key Manager on a z/OS system to Tivoli Key Lifecycle Manager: 1. Ensure that Encryption Key Manager is stopped: If running Encryption Key Manager under a started task, stop the Encryption Key Manager started task (that is, EKMPROC) by issuing the following z/OS operator STOP command: STOP EKMPROC If running Encryption Key Manager from a UNIX System Services shell, stop the Encryption Key Manager process with the following tasks: Start the CLI client from the UNIX System Services shell: java com.ibm.keymanager.KMSAdminCmd CLIconfiglfile_name -i Before submitting any commands, you must log the CLI client in to the key manager server with the following command: #login ekmuser EKMAdmin ekmpassword changeME Finally, you can issue the stopekm command: stopekm Another method is to send a sigterm command to the key manager process, which allows the server to shut down and end cleanly. Note: Do not send a sigkill command to the key manager process. The sigkill command does not shut down the process cleanly. Configuration options and other data might be lost. 2. Insure that the SSRE user ID has READ WRITE access to the following Encryption Key Manager resources: Drivetable as noted by the config.drivetable.file.url property in the Encryption Key Manager properties file. Keygroups file as noted by the config.keygroup.xml file. Skip this step if the Encryption Key Manager that is being migrated does not serve LTO devices. Audit metadata file as noted by the audit.metadata.file.name property in the Encryption Key Manager configuration file. Give the SSREGRP group ID permissions to read and write to the Encryption Key Manager keystore. Locate the keystore and the type of keystore to migrate from Encryption Key Manager. Examine the config.keystore.file and config.keystore.type properties in the Encryption Key Manager properties file. Then, take one of these steps based on the keystore type: For keystores of type JCEKS, JCE4758KS, or JCECCAKS, give READ and WRITE permissions to the keystore file and READ and WRITE permissions to the full directory path in which the keystore is located. The migration process requires the WRITE permission to back up the keystore before the migration begins. For a RACF keystore (that is, of type JCERACFKS, JCE4578RACFKS, or JCECCARACFKS), give the SSREGRP group ID permissions to the Encryption Key Manager keyring, keys, and certificates. For an example of how to give these permissions, see Appendix: RACF commands on page 13.

Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager

11

3. Run the migration manually, after you have successfully installed Tivoli Key Lifecycle Manager. Run the migration script by using this shell script from the directory where the tklm.jar file was expanded: ./bin/migrateEKM.sh Specify these optional parameters: -responseFile response_file Specifies the response file that is created during the createResponseFile.sh step that the Tivoli Key Lifecycle Manager installation program provides. If you do not specify this option, the migration process looks for the default response file name, which is the POST_SMPE_TKLM_HOME/bin/tklmInstall.response file. In this example, the value is the /etc/tklm/bin/tklmInstall.response file. Specifies the SSRECFG user ID password. If you do not supply a password, you are prompted for the value in a secure manner. Specifies the password of the Tivoli Key Lifecycle Manager database owner. If you do not supply a password, you are prompted for the value in a secure manner. Specifies sending verbose output to the console. The migration process always sends verbose output to a migration log.

-wasPassword was_password

-dbPassword db_password

-v

The output in Example 1 occurs when you run the migrateEKM.sh shell script with no specified parameters.
Example 1 Migration command sample output

Log file "/etc/tklm/logs/migrateEKM_100808_163341.log" will be used for this run No response file passed. Defaulting to "/etc/tklm/bin/tklmInstall.response" Enter the fully qualified path name of the EKM configuration file: /home/suimglb/bin/KeyManagerConfig.properties.JCERACFKS Accepted input: ["/home/suimglb/bin/KeyManagerConfig.properties.JCERACFKS"] Stopping SSRE... SSRE stopped Running Migration API Starting SSRE... SSRE started TKLM Migration has succeeded Script completed with exit code: 0(SUCCESS) Note that SSRE is stopped and restarted during this process.

12

Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager

Summary
By following these instructions, you can upgrade the existing Encryption Key Manager solution with a new look, new capabilities, and an easier to use interface. After migrating the Encryption Key Manager environment to Tivoli Key Lifecycle Manager, you can perform key management for tape and disk devices at a GUI from a Web-based portal. Key management for Encryption Key Manager was performed at a terminal using sophisticated and complex commands. Device management was performed at libraries or from within data management routines. Tivoli Key Lifecycle Manager allows the user to assign keys to devices from a streamlined interface. Key management is simplified by providing rollover schedules for default keys and certificates. As the need for encryption key management evolves and grows, Tivoli Key Lifecycle Manager is positioned to take advantage of simplified key life-cycle management capabilities in a solution that is easy to manage.

Appendix: RACF commands

The racfpermissions.rexx script executes the following commands to use RACF keyrings from Tivoli Key Lifecycle Manager: 1. Define the RACF profiles: RDEFINE RDEFINE RDEFINE RDEFINE RDEFINE RDEFINE RDEFINE RDEFINE RDEFINE FACILITY FACILITY FACILITY FACILITY FACILITY FACILITY FACILITY FACILITY FACILITY IRR.DIGTCERT.LISTRING UACC(NONE) IRR.DIGTCERT.LIST UACC(NONE) IRR.DIGTCERT.ADD UACC(NONE) IRR.DIGTCERT.DELETE UACC(NONE) IRR.DIGTCERT.ADDRING UACC(NONE) IRR.DIGTCERT.CONNECT UACC(NONE) IRR.DIGTCERT.GENCERT UACC(NONE) IRR.DIGTCERT.GENREQ UACC(NONE) IRR.DIGTCERT.ALTER UACC(NONE)

2. Grant the proper authorizations to both user IDs: PERMIT PERMIT PERMIT PERMIT PERMIT PERMIT PERMIT PERMIT PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ID(SSRE_USERID) ACC(UPDATE) IRR.DIGTCERT.LIST CLASS(FACILITY) ID(SSRE_USERID) ACC(UPDATE) IRR.DIGTCERT.ADD CLASS(FACILITY) ID(SSRE_USERID) ACC(CONTROL) IRR.DIGTCERT.DELETE CLASS(FACILITY) ID(SSRE_USERID) ACC(CONTROL) IRR.DIGTCERT.ADDRING CLASS(FACILITY) ID(SSRE_USERID) ACC(CONTROL) IRR.DIGTCERT.CONNECT CLASS(FACILITY) ID(SSRE_USERID) ACC(CONTROL) IRR.DIGTCERT.GENCERT CLASS(FACILITY) ID(SSRE_USERID) ACC(CONTROL) IRR.DIGTCERT.GENREQ CLASS(FACILITY) ID(SSRE_USERID) ACC(CONTROL) IRR.DIGTCERT.ALTER CLASS(FACILITY) ID(SSRE_USERID) ACC(CONTROL)

ALTUSER SSRE_USERID CLAUTH(DIGTCERT) SETROPTS RACLIST(FACILITY) SETROPTS RACLIST(FACILITY) REFRESH

Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager

13

For more information about RACF keyrings, syntax, and commands, see the z/OS Security Server RACF Security Administrator Guide, SA22-7683-11, and z/OS Security Server RACF Command Language Reference, SA22-7687-11.

The team who wrote this IBM Redpaper

This paper was produced by specialists from around the world working at the International Technical Support Organization, Austin Center. William C. Johnston, CISSP, is a Master Certified IT Specialist with experience working with large system installations to deploy encryption key management solutions. He has performed enterprise system security assessments. A large part of his duties include educating clients about security-related topics and bringing best practices to client processes. For over a decade, he was responsible for the design and implementation of the test approach definitions for security-related elements of the z/OS operating system, including their interaction with other components, the base OS, and other platforms, such as Linux and Windows XP. In the past, he has performed code development, functional and system-level testing, and project management duties. William is an adjunct professor at Marist College in Poughkeepsie, New York. Axel Buecker is a Certified Consulting Software IT Specialist at the ITSO, Austin Center. He writes extensively and teaches IBM classes worldwide about areas of software security architecture and network computing technologies. He holds a degree in Computer Science from the University of Bremen, Germany. He has 23 years of experience in a variety of areas related to workstation and systems management, network computing, and e-business solutions. Before joining the ITSO in March 2000, Axel worked for IBM in Germany as a Senior IT Specialist in Software Security Architecture. Thanks to the following people for their contributions to this project: Jonathan M. Barney, Steven R. Hart, and John Petreshock of IBM, without whose help, developing this Redpaper would not have been possible.

Now you can become a published author, too!

Heres an opportunity to spotlight your skills, grow your career, and become a published author - all at the same time! Join an ITSO residency project and help write a book in your area of expertise, while honing your experience using leading-edge technologies. Your efforts will help to increase product acceptance and customer satisfaction, as you expand your network of technical contacts and relationships. Residencies run from two to six weeks in length, and you can participate either in person or as a remote resident working from your home base. Find out more about the residency program, browse the residency index, and apply online at: ibm.com/redbooks/residencies.html

14

Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager

Stay connected to IBM Redbooks and Redpapers

Find us on Facebook: http://www.facebook.com/pages/IBM-Redbooks/178023492563?ref=ts Follow us on twitter: http://twitter.com/ibmredbooks Look for us on LinkedIn: http://www.linkedin.com/groups?home=&gid=2130806 Explore new Redbooks publications, residencies, and workshops with the IBM Redbooks weekly newsletter: https://www.redbooks.ibm.com/Redbooks.nsf/subscribe?OpenForm Stay current on recent Redbooks publications with RSS Feeds: http://www.redbooks.ibm.com/rss.html

Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager

15

16

Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager

Notices
This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs.

Copyright International Business Machines Corporation 2010. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

17

This document REDP-4646-00 was created or updated on April 12, 2010. Send us your comments in one of the following ways: Use the online Contact us review Redbooks form found at: ibm.com/redbooks Send your comments in an e-mail to: redbooks@us.ibm.com Mail your comments to: IBM Corporation, International Technical Support Organization Dept. HYTD Mail Station P099 2455 South Road Poughkeepsie, NY 12601-5400 U.S.A.

Redpaper

Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. These and other IBM trademarked terms are marked on their first occurrence in this information with the appropriate symbol ( or ), indicating US registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at http://www.ibm.com/legal/copytrade.shtml The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both:
DB2 DS8000 IBM RACF Redpaper Redbooks (logo) Tivoli WebSphere z/OS

The following terms are trademarks of other companies: Java, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others.

18

Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager