Tivoli Key Lifecycle Manager for Z-OS Migration Guide for the IBM Encryption Key Manager Redp4646

7/31/2019 Tivoli Key Lifecycle Manager for Z-OS Migration Guide for the IBM Encryption Key Manager Redp4646

1/18

Copyright IBM Corp. 2010. All rights reserved. ibm.com/redbooks 1

Redpaper

Tivoli Key Lifecycle Manager for z/OS:

Migration Guide for the IBM EncryptionKey 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 KeyLifecycle Manager data, such as the configuration file

System Management Facility (SMF)-based audit records that are based on selectedevents 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 anexisting IBM Encryption Key Manager (EKM) installation on z/OS to Tivoli Key Lifecycle

Manager for z/OS.

William C. Johnston

Axel Buecker
http://www.redbooks.ibm.com/http://www.redbooks.ibm.com/http://www.redbooks.ibm.com/http://www.redbooks.ibm.com/


2/18

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

Differences between the products

Although IBM Encryption Key Manager and Tivoli Key Lifecycle Manager both serveencryption keys to tape drives, the ways in which they do so differ. For example, EncryptionKey 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


3/18

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

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 aboutthe 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 operatorcommand.

Figure 2 shows the architectural components of an Encryption Key Manager infrastructure.

Figure 2 Encryption Key Manager components


4/18


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 LifecycleManager 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 isone of these entitled applications.

Tivoli Key Lifecycle Manager manages its configuration files internally. Administrators of TivoliKey Lifecycle Manager access changeable properties through the Integrated SolutionsConsole (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


5/18


Planning the migration

Moving from an Encryption Key Manager environment to the Tivoli Key Lifecycle Managerenvironment 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 LifecycleManager, the keys in the existing keystore, drive table information, and metadata are broughtinto 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 timeinterval for a temporary halt to key serving activity. While the migration runs, no key servingactivity 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 attributesthat 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, andSecure 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 thatthere 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 bemigrated:

The migration of Administrator SSL keystores and truststores is not supported. The Tivoli

Key Lifecycle Manager server does not support the Administrator synchronizationcapability.

The migration of PKCS11Impl keystores and truststores is not supported. The Tivoli KeyLifecycle Manager server does not support PKCS11Impl keystores. Because thismigration is on z/OS, no PKCS11Impl keystore exists. So, this restriction does not apply.


6/18


Tivoli Key Lifecycle Manager does not support the use of a key in multiple groups, unlikeEncryption Key Manager, which allows the use of a key in multiple groups.Keygroups aresets of symmetrical keys that are used for LTO-4 drive-based encryption. This restrictiononly 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 inmultiple groups in Encryption Key Manager is created in only one group in Tivoli KeyLifecycle 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.

KeystoresEncryption 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 Used to hold encryption keys. Migrated to TivoliKey Lifecycle Manager.

TransportListener.ssl.keystore.name Used for Encryption Key Manager serverauthentication. Migrated to Tivoli Key Lifecycle

Manager.

TransportListener.ssl.truststore.name Used for Encryption Key Manager clientauthentication. Not migrated to Tivoli Key Lifecycle

Manager.

Admin.ssl.keystore.name Used when Encryption Key Manager is a targetserver for sync operations. Not migrated to Tivoli

Key Lifecycle Manager.

Admin.ssl.truststore.name Used when Encryption Key Manager is a client for

sync operations. Not migrated to Tivoli KeyLifecycle Manager.

Note that Encryption Key Manager uses the term truststore to denote keystores fromcertificates that are used by clients. Because the Tivoli Key Lifecycle Manager clientsauthenticate to the WebSphere Application Server environment, either through the ISC or the

CLI usingwsadmin, no client side keystore or truststore is necessary.

Tivoli Key Lifecycle Manager supports only one keystore, which is identified by theconfig.keystore.name property in the TKLMgrConfig.properties file. This keystore isequivalent to the Encryption Key Manager Config keystore (config.keystore.file).

During migration, the two Encryption Key Manager keystores, config.keystore.file andTransportListener.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 LifecycleManager Keystore. That is, this entry is in the TKLMgrConfig.properties file:

config.keystore.name = Tivoli Key Lifecycle Manager Keystore


7/18


All certificates from the Encryption Key Manager config.keystore.file keystore are added tothe Tivoli Key Lifecycle Manager keystore. All the certificates from the

TransportListener.ssl.truststore.name truststore are added to the Tivoli Key LifecycleManager 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. Thiscertificate is used to secure communications between the ISC GUI and the Tivoli Key

Lifecycle Manager server.

Other Encryption Key Manager keystores are not used.

DevicesAll the device information is read from the drive table pointed at by the config.drivetable.file.urlproperty, 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, thedrive type is set to 3592. If the drive does not have any of these properties defined and thetype cannot be determined during migration, the type is set to UNKNOWN.

KeygroupsThe keygroup.xml file, to which the config.keygroup.xml.file property points, is parsed, andthe keygroup information is stored in a Tivoli Key Lifecycle Manager database. All the groupmembers and group relationships are also migrated. The group member and group

relationship migration only applies to Encryption Key Manager Version 2.1.

MetadataAll 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 toEncryption Key Manager versions 2.0 and 2.1.

PropertiesThe 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


8/18


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 KeyLifecycle 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. AlthoughEncryption Key Manager can continue to serve keys after its data is migrated to Tivoli KeyLifecycle 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 willnot be recognized by Tivoli Key Lifecycle Manager.

Tivoli Key Lifecycle Manager will take control of the Encryption Key Manager keystore. Forexample, if the keystore is a JCERACFKS RACF keyring, that same keyring and user ID willbe 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 ifthe 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 thesetimes:

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, youcannotmigrate Encryption Key Manager to Tivoli Key Lifecycle Manager.


9/18


Preparing for the migration

You must complete the following tasks, if applicable, before starting the migration fromEncryption 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 whichSSRECFG requires READ access. Refer to the Encryption Key Manager properties file for

installation-specific filenames.

Table 1 Required file permissions for migration

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 Environmentconfiguration ID, such as SSRECFG, and for the user ID to which the System ServicesRuntime 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 usingthe 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

Property Use

config.drivetable.file.url Drivetable: The tracking of drives to keys used

by Encryption Key Manager.

config.keygroup.xml.file Keygroups file: Information about what

symmetric keys are grouped together. Used by

LTO-4 drives.

audit.metadata.file.name Audit metadata file: Encryption Key ManagerVersion 2.0 and higher only.

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.

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.


10/18


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 (thatis, SSREGRP). This value can be any RACF ID (either user ID or group ID) thatneeds 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 IDEKMSERV.

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 Managerinstallation 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 scriptinto 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 samplesdirectory):

. ./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 inAppendix: RACF commands on page 13.


11/18


Running the migration

Perform these steps to migrate Encryption Key Manager on a z/OS system to Tivoli KeyLifecycle Manager:

1. Ensure that Encryption Key Manager is stopped:

If running Encryption Key Manager under a started task, stop the Encryption KeyManager started task (that is, EKMPROC) by issuing the following z/OS operator STOPcommand:

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 managerserver 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, whichallows the server to shut down and end cleanly.

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 theEncryption 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 WRITEpermissions to the keystore file and READ and WRITE permissions to the full

directory path in which the keystore is located. The migration process requires theWRITE permission to back up the keystore before the migration begins.

For a RACF keystore (that is, of type JCERACFKS, JCE4578RACFKS, orJCECCARACFKS), give the SSREGRP group ID permissions to the Encryption

Key Manager keyring, keys, and certificates. For an example of how to give thesepermissions, see Appendix: RACF commands on page 13.

Note: Do not send a sigkill command to the key manager process. Thesigkill command does not shut down the process cleanly. Configuration

options and other data might be lost.


12/18


3. Run the migration manually, after you have successfully installed Tivoli Key LifecycleManager.

Run the migration script by using this shell script from the directory where the tklm.jar filewas 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 notspecify this option, the migration process looks for thedefault response file name, which is thePOST_SMPE_TKLM_HOME/bin/tklmInstall.response file.In this example, the value is the/etc/tklm/bin/tklmInstall.response file.

-wasPassword was_password Specifies the SSRECFG user ID password. If you do not

supply a password, you are prompted for the value in asecure manner.

-dbPassword db_password Specifies the password of the Tivoli Key LifecycleManager database owner. If you do not supply apassword, you are prompted for the value in a secure

manner.

-v Specifies sending verbose output to the console. Themigration process always sends verbose output to a

migration log.

The output in Example 1 occurs when you run the migrateEKM.sh shell script with nospecified parameters.

Example 1 Migration command sample output

Log file "/etc/tklm/logs/migrateEKM_100808_163341.log"will be used for this runNo 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.JCERACFKSAccepted input: ["/home/suimglb/bin/KeyManagerConfig.properties.JCERACFKS"]Stopping SSRE...SSRE stoppedRunning Migration APIStarting SSRE...SSRE startedTKLM Migration has succeededScript completed with exit code: 0(SUCCESS)

Note that SSRE is stopped and restarted during this process.


13/18


Summary

By following these instructions, you can upgrade the existing Encryption Key Managersolution 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 usingsophisticated and complex commands. Device management was performed at l ibraries or

from within data management routines.

Tivoli Key Lifecycle Manager allows the user to assign keys to devices from a streamlinedinterface. 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 Manageris 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 fromTivoli Key Lifecycle Manager:

1. Define the RACF profiles:

RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE)RDEFINE FACILITY IRR.DIGTCERT.LIST UACC(NONE)RDEFINE FACILITY IRR.DIGTCERT.ADD UACC(NONE)RDEFINE FACILITY IRR.DIGTCERT.DELETE UACC(NONE)

RDEFINE FACILITY IRR.DIGTCERT.ADDRING UACC(NONE)RDEFINE FACILITY IRR.DIGTCERT.CONNECT UACC(NONE)RDEFINE FACILITY IRR.DIGTCERT.GENCERT UACC(NONE)RDEFINE FACILITY IRR.DIGTCERT.GENREQ UACC(NONE)RDEFINE FACILITY IRR.DIGTCERT.ALTER UACC(NONE)

2. Grant the proper authorizations to both user IDs:

PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ID(SSRE_USERID) ACC(UPDATE)PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ID(SSRE_USERID) ACC(UPDATE)PERMIT IRR.DIGTCERT.ADD CLASS(FACILITY) ID(SSRE_USERID) ACC(CONTROL)PERMIT IRR.DIGTCERT.DELETE CLASS(FACILITY) ID(SSRE_USERID) ACC(CONTROL)PERMIT IRR.DIGTCERT.ADDRING CLASS(FACILITY) ID(SSRE_USERID) ACC(CONTROL)PERMIT IRR.DIGTCERT.CONNECT CLASS(FACILITY) ID(SSRE_USERID) ACC(CONTROL)

PERMIT IRR.DIGTCERT.GENCERT CLASS(FACILITY) ID(SSRE_USERID) ACC(CONTROL)PERMIT IRR.DIGTCERT.GENREQ CLASS(FACILITY) ID(SSRE_USERID) ACC(CONTROL)PERMIT IRR.DIGTCERT.ALTER CLASS(FACILITY) ID(SSRE_USERID) ACC(CONTROL)

ALTUSER SSRE_USERID CLAUTH(DIGTCERT)

SETROPTS RACLIST(FACILITY)SETROPTS RACLIST(FACILITY) REFRESH


14/18


For more information about RACF keyrings, syntax, and commands, see the z/OS SecurityServer 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 InternationalTechnical 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 performedenterprise system security assessments. A large part of his duties include educating clientsabout 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 approachdefinitions 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 andWindows 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 inPoughkeepsie, 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 securityarchitecture and network computing technologies. He holds a degree in Computer Sciencefrom 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-businesssolutions. 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 yourarea of expertise, while honing your experience using leading-edge technologies. Your efforts

will help to increase product acceptance and customer satisfaction, as you expand yournetwork of technical contacts and relationships. Residencies run from two to six weeks inlength, 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
http://www.redbooks.ibm.com/residencies.htmlhttp://www.redbooks.ibm.com/residencies.htmlhttp://www.redbooks.ibm.com/residencies.htmlhttp://www.redbooks.ibm.com/residencies.html


15/18


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
http://www.facebook.com/pages/IBM-Redbooks/178023492563?ref=tshttp://twitter.com/ibmredbookshttp://www.linkedin.com/groups?home=&gid=2130806https://www.redbooks.ibm.com/Redbooks.nsf/subscribe?OpenFormhttp://www.redbooks.ibm.com/rss.htmlhttp://www.redbooks.ibm.com/rss.htmlhttps://www.redbooks.ibm.com/Redbooks.nsf/subscribe?OpenFormhttp://www.linkedin.com/groups?home=&gid=2130806http://twitter.com/ibmredbookshttp://www.facebook.com/pages/IBM-Redbooks/178023492563?ref=ts


16/18



17/18

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

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. Consultyour local IBM representative for information on the products and services currently available in your area. Anyreference 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 notinfringe any IBM intellectual property right may be used instead. However, it is the user's responsibility toevaluate 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. Thefurnishing of this document does not give you any license to these patents. You can send license inquiries, inwriting, 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 suchprovisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATIONPROVIDES 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 ofexpress 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 madeto the information herein; these changes will be incorporated in new editions of the publication. IBM may makeimprovements and/or changes in the product(s) and/or the program(s) described in this publication at any timewithout notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in anymanner serve as an endorsement of those Web sites. The materials at those Web sites are not part of thematerials 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 incurringany obligation to you.

Information concerning non-IBM products was obtained from the suppliers of those products, their publishedannouncements or other publicly available sources. IBM has not tested those products and cannot confirm theaccuracy of performance, compatibility or any other claims related to non-IBM products. Questions on thecapabilities 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 themas 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 businessenterprise is entirely coincidental.

COPYRIGHT LICENSE:

This information contains sample application programs in source language, which illustrate programmingtechniques 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 applicationprograms conforming to the application programming interface for the operating platform for which the sampleprograms 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.


18/18

Redpaper

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:

[email protected] Mail your comments to:

IBM Corporation, International Technical Support OrganizationDept. HYTD Mail Station P0992455 South RoadPoughkeepsie, NY 12601-5400 U.S.A.

Trademarks

IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business MachinesCorporation in the United States, other countries, or both. These and other IBM trademarked terms aremarked on their first occurrence in this information with the appropriate symbol ( or ), indicating USregistered or common law trademarks owned by IBM at the time this information was published. Suchtrademarks 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, othercountries, 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.
http://www.redbooks.ibm.com/http://www.ibm.com/redbooks/http://www.redbooks.ibm.com/contacts.htmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://www.redbooks.ibm.com/contacts.htmlhttp://www.ibm.com/redbooks/http://www.ibm.com/redbooks/http://www.redbooks.ibm.com/

Documents

Tivoli Key Lifecycle Manager for Z-OS Migration Guide for the IBM Encryption Key Manager Redp4646