2. 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
2 Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager
3. 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 3
4. 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
4 Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager
5. 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 5
6. 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 Used to hold encryption keys. Migrated to Tivoli
Key Lifecycle Manager.
TransportListener.ssl.keystore.name 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.
Admin.ssl.truststore.name Used when Encryption Key Manager is a client for
sync operations. Not migrated to Tivoli Key
Lifecycle Manager.
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
6 Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager
7. 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 7
8. 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.
8 Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager
9. 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 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 Manager
Version 2.0 and higher only.
config.keystore.file For keystores of type JCEKS, JCE4758KS, or
JCECCAKS, give READ and WRITE
Depending on the value of config.keystore.type, permissions to the keystore file and READ and
this property might be a Resource Access WRITE permissions to the full directory path in
Control Facility (RACF) keyring or a flat file. 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.
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 9
10. 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
11. 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
12. 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.
-wasPassword was_password Specifies the SSRECFG user ID password. If you do not
supply a password, you are prompted for the value in a
secure manner.
-dbPassword db_password 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.
-v Specifies sending verbose output to the console. The
migration process always sends verbose output to a
migration log.
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
13. 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 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
Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager 13
14. 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!
Here’s 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
15. 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. 16 Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager
18. 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® RACF® Tivoli®
DS8000® Redpaper™ WebSphere®
IBM® Redbooks (logo) ® 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