Ibm system storage tape encryption solutions sg247320

Front cover

IBM System Storage
Tape Encryption
Solutions
Learn about IBM TS1130 Tape Drive
and Tivoli Key Lifecycle Manager

Encrypt data on LTO and TS1100
series cartridges

Discover usability
enhancements

Babette Haeusser
Jonathan Barney
Arthur Colvig

ibm.com/redbooks

International Technical Support Organization

IBM System Storage Tape Encryption Solutions

May 2009

SG24-7320-02

Note: Before using this information and the product it supports, read the information in “Notices” on
page xiii.

Third Edition (May 2009)

This edition applies to the introduction of the IBM TS1130 Tape Drive and Tivoli Lifecycle Manager (TKLM)

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

Contents

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
The team that wrote this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
May 2009, Third Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix

Part 1. Introducing IBM tape encryption solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter 1. Introduction to tape encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 How tape data encryption works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 What to encrypt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Why use tape data encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.1 Why encrypt data in the drive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.2 Fundamental to encryption: Policy and key management . . . . . . . . . . . . . . . . . . . 8
1.3.3 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 Concepts of tape data encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.1 Symmetric key encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4.2 Asymmetric key encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.3 Hybrid encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.4.4 Digital certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Chapter 2. IBM tape encryption methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1 IBM Encryption Key Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.1.1 Encryption Key Manager components and resources . . . . . . . . . . . . . . . . . . . . . 25
2.1.2 Encryption keys and 3592 and LTO4 differences . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1.3 Key exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2 Tivoli Key Lifecycle Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2.1 Tivoli Lifecycle Key Manager components and resources . . . . . . . . . . . . . . . . . . 30
2.2.2 Key exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3 Methods of managing IBM tape encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.1 System-Managed Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.2 Library-Managed Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.3.3 Encrypting and decrypting with SME and LME . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.3.4 Application-Managed Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.3.5 Mixed mode example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Chapter 3. IBM System Storage tape and tape automation for encryption . . . . . . . . . 45
3.1 IBM System Storage TS1130 and TS1120 Tape Drive . . . . . . . . . . . . . . . . . . . . . . . . 46
3.1.1 Tape data encryption support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.1.2 TS1120 characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.1.4 3592 cartridges and media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2 IBM System Storage TS1120 Tape Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.2.1 IBM TS1120 Tape Controller characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

© Copyright IBM Corp. 2008, 2009. All rights reserved. iii

3.2.2 IBM TS1120 Tape Controller encryption support . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.2.3 Installation with an IBM TS3500 Tape Library . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.2.4 Installation with an IBM TS3400 Tape Library . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.2.5 Installation with an IBM 3494 Tape Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.2.6 IBM TotalStorage 3592 Model J70 Tape Controller . . . . . . . . . . . . . . . . . . . . . . . 59
3.3 IBM Virtualization Engine TS7700 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.4 IBM LTO Ultrium tape drives and libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.4.1 LTO overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.4.2 LTO media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.4.3 IBM System Storage TS2240 Tape Drive Express Model . . . . . . . . . . . . . . . . . . 66
3.4.4 IBM System Storage TS2340 Tape Drive Express Model . . . . . . . . . . . . . . . . . . 67
3.4.5 IBM System Storage TS1040 Tape Drive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.4.6 IBM System Storage TS2900 Tape Autoloader . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.4.7 IBM System Storage TS3100 Tape Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.5 IBM System Storage TS3400 Tape Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.6 IBM System Storage TS3500 Tape Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.6.1 TS3500 frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.7 IBM TotalStorage 3494 Tape Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Chapter 4. Planning for software and hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.1 Encryption planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.2 Planning assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.3 Encryption planning quick-reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.4 Choosing encryption methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.4.1 Encryption method comparison. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.4.2 System z encryption methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.4.3 Open Systems encryption methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.4.4 Decision time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.5 Solutions available by operating system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.5.1 The z/OS solution components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.5.2 z/VM, z/VSE, and z/TPF solution components for TS1120 drives . . . . . . . . . . . 102
4.5.3 IBM System i encryption solution components . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.5.4 AIX solution components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.5.5 Linux on System z. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.5.6 Linux on System p, System x, and other Intel or AMD Opteron servers. . . . . . . 109
4.5.7 HP-UX, Sun, and Windows components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
4.5.8 Tivoli Storage Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
4.6 Ordering information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.6.1 TS1120 tape drive prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.6.2 Tape controller prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
4.6.3 LTO4 tape drive prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
4.6.4 Tape library prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
4.6.5 Other library and rack Open Systems installations . . . . . . . . . . . . . . . . . . . . . . . 120
4.6.6 TS7700 Virtualization Engine prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
4.6.7 General software prerequisites for encryption . . . . . . . . . . . . . . . . . . . . . . . . . . 121
4.6.8 TS1120 and TS1130 supported platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
4.6.9 IBM LTO4 tape drive supported platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
4.7 Other planning considerations for tape data encryption . . . . . . . . . . . . . . . . . . . . . . . 124
4.7.1 In-band and out-of-band . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
4.7.2 Performance considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

iv IBM System Storage Tape Encryption Solutions

4.7.3 Encryption with other backup applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
4.7.4 ALMS and encryption in the TS3500 library . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
4.7.5 TS1120 and TS1130 rekeying considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 127
4.8 Upgrade and migration considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
4.8.1 Look out for potential problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
4.8.2 TS1120 and TS1130 compatibility considerations . . . . . . . . . . . . . . . . . . . . . . . 129
4.8.3 DFSMSdss host-based encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
4.8.4 Positioning TS1120 Tape Encryption and Encryption Facility for z/OS . . . . . . . 134

Part 2. Implementing and operating the EKM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Chapter 5. Planning for EKM and its keystores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
5.1 EKM planning quick-reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
5.2 Ordering information and requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
5.2.1 EKM on z/OS or z/OS.e requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
5.2.2 EKM on z/VM, z/VSE, and z/TPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
5.2.3 EKM on IBM System i5 requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
5.2.4 EKM on AIX requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
5.2.5 EKM on Linux requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
5.2.6 EKM on Hewlett-Packard, Sun, and Windows requirements . . . . . . . . . . . . . . . 143
5.3 EKM and keystore considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
5.3.1 EKM configuration planning checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
5.3.2 Best security practices for working with keys and certificates. . . . . . . . . . . . . . . 147
5.3.3 Acting on the advice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
5.3.4 Typical EKM implementations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
5.3.5 Multiple EKMs for redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
5.3.6 Using Virtual IP Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
5.3.7 Key Manager backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
5.3.8 FIPS 140-2 certification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
5.4 Other EKM considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
5.4.1 EKM Release 1 to EKM Release 2 migration . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
5.4.2 Data exchange with business partners or different platforms . . . . . . . . . . . . . . . 154
5.4.3 Disaster recovery considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
5.4.4 i5/OS disaster recovery considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
5.4.5 EKM performance considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Chapter 6. Implementing EKM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
6.1 Implementing the EKM in z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
6.1.1 z/OS UNIX System Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
6.1.2 Installing the EKM in z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
6.1.3 Security products involved: RACF, Top Secret, and ACF2. . . . . . . . . . . . . . . . . 161
6.1.4 Create a JCE4758RACFKS for EKM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
6.1.5 Setting up the EKM environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
6.1.6 Starting EKM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
6.1.7 Additional definitions of hardware keystores for z/OS. . . . . . . . . . . . . . . . . . . . . 172
6.1.8 Virtual IP Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
6.1.9 EKM TCP/IP configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
6.2 Installing EKM on AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
6.2.1 Install the IBM Software Developer Kit (SDK). . . . . . . . . . . . . . . . . . . . . . . . . . . 175
6.3 Installing EKM on a Windows platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
6.3.1 EKM setup tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
6.3.2 Installing the IBM Software Developer Kit on Windows . . . . . . . . . . . . . . . . . . . 182
6.3.3 Starting EKM on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
6.3.4 Configuring and starting EKM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Contents v

6.4 Installing the EKM in i5/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
6.4.1 New installation of the Encryption Key Manager. . . . . . . . . . . . . . . . . . . . . . . . . 194
6.4.2 Upgrading the Encryption Key Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
6.4.3 Configuring EKM for tape data encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
6.5 LTO4 Encryption implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
6.5.1 LTO4 EKM implementation checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
6.5.2 Download the latest EKM software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
6.5.3 Create a JCEKS keystore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
6.5.4 Off-site or business partner exchange with LTO4 compared to 3592. . . . . . . . . 210
6.5.5 EKM Version 2 installation and customization on Windows . . . . . . . . . . . . . . . . 211
6.5.6 Start EKM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
6.5.7 Starting EKM as a windows Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
6.6 LTO4 Library-Managed Encryption implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 215
6.6.1 Barcode Encryption Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
6.6.2 Specifying a Barcode Encryption Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
6.6.3 TS3500 Library-Managed Encryption differences from TS3310, TS3200, TS3100,
and TS2900 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
6.7 LTO4 System-Managed Encryption implementation. . . . . . . . . . . . . . . . . . . . . . . . . . 223
6.7.1 LTO4 SME implementation checklist for Windows . . . . . . . . . . . . . . . . . . . . . . . 224

Chapter 7. Planning and managing your keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
7.1 Keystore and SAF Digital Certificates (keyrings) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
7.2 JCEKS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
7.2.1 Examples of managing public-private key pairs . . . . . . . . . . . . . . . . . . . . . . . . . 227
7.2.2 Managing symmetric keys in a JCEKS keystore. . . . . . . . . . . . . . . . . . . . . . . . . 230
7.2.3 Example using IKEYMAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
7.3 JCE4758KS and JCECCAKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
7.3.1 Script notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
7.3.2 Symmetric keys in a JCECCAKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
7.4 JCERACFKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
7.5 JCE4758RACFKS and JCECCARACFKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
7.5.1 RACDCERT keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
7.5.2 Best practice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
7.6 PKCS#11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
7.7 IBMi5OSKeyStore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
7.7.1 Digital Certificate Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
7.7.2 How to set up an IBMi5OSKeyStore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
7.8 ShowPrivateTool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
7.9 MatchKeys tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
7.10 Hardware cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

Chapter 8. EKM operational considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
8.1 EKM commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
8.1.1 The EKM sync command and EKM properties file . . . . . . . . . . . . . . . . . . . . . . . 274
8.1.2 EKM command line interface and command set. . . . . . . . . . . . . . . . . . . . . . . . . 275
8.2 Backup procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
8.2.1 EKM file system backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
8.2.2 Identifying DFSMShsm to z/OS UNIX System Services . . . . . . . . . . . . . . . . . . . 281
8.2.3 Keystore backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
8.2.4 RACF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
8.3 ICSF disaster recovery procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
8.3.1 Key recovery checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
8.3.2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

vi IBM System Storage Tape Encryption Solutions

8.3.3 Pre-key change: All LPARs in the Sysplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
8.3.4 Check the ICSF installation options data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
8.3.5 Disable all services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
8.3.6 Entering Master Keys for all LPARs in the Sysplex . . . . . . . . . . . . . . . . . . . . . . 289
8.3.7 Post-key change for all LPARs in the Sysplex . . . . . . . . . . . . . . . . . . . . . . . . . . 294
8.3.8 Exiting disaster recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
8.4 Business partner tape-sharing example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
8.4.1 Key-sharing steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
8.4.2 Exporting a public key and certificate to a business partner . . . . . . . . . . . . . . . . 296
8.4.3 Exporting a symmetric key from a JCEKS keystore . . . . . . . . . . . . . . . . . . . . . . 300
8.4.4 Importing a public key and a certificate from a business partner . . . . . . . . . . . . 301
8.4.5 Tape exchange and verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
8.4.6 Importing symmetric keys to a JCEKS keystore . . . . . . . . . . . . . . . . . . . . . . . . . 304
8.5 RACF export tool for z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
8.6 Audit log considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
8.6.1 Audit overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
8.6.2 Audit log parsing tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

Part 3. Implementing and operating the TKLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

Chapter 9. Planning for TKLM and its keystores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
9.1 TKLM planning quick-reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
9.2 TKLM and keystore considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
9.2.1 TKLM configuration planning checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
9.2.2 Best security practices for working with keys and certificates. . . . . . . . . . . . . . . 319
9.2.3 Acting on the advice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
9.2.4 Multiple TKLMs for redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
9.3 Other TKLM considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
9.3.1 Database selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
9.3.2 EKM to TKLM migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
9.3.3 Data exchange with business partners or different platforms . . . . . . . . . . . . . . . 321
9.3.4 Disaster recovery considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

Chapter 10. Implementing TKLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
10.1 Implementation notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
10.2 Installing TKLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
10.3 Configuring TKLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
10.4 Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345

Chapter 11. TKLM operational considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
11.1 Scripting with TKLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
11.1.1 Simple Linux backup script example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
11.2 Synchronizing primary TKLM configuration data. . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
11.2.1 Setting up primary and secondary TKLM servers . . . . . . . . . . . . . . . . . . . . . . . 349
11.2.2 Synchronizing the primary and secondary TKLM servers. . . . . . . . . . . . . . . . . 350
11.3 TKLM maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
11.3.1 Adding and removing drives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
11.3.2 Scheduling key group rollover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
11.3.3 Scheduling certificate rollover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
11.4 TKLM backup and restore procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
11.4.1 Backup by using the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
11.4.2 Restore by using the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
11.4.3 Backup by using the command line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
11.4.4 Restore by using the command line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364

Contents vii

11.5 Data sharing with business partners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
11.5.1 Sharing TS1100 certificate data with a business partner . . . . . . . . . . . . . . . . . 365
11.5.2 Sharing LTO key data with a business partner . . . . . . . . . . . . . . . . . . . . . . . . . 368
11.6 Removing TKLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
11.6.1 Backing up the keystore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
11.6.2 Removing TKLM from a Windows system . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
11.7 Fixing the security warnings in your Web browser . . . . . . . . . . . . . . . . . . . . . . . . . . 375
11.7.1 Fixing the security warning in Internet Explorer browser . . . . . . . . . . . . . . . . . 375
11.7.2 Fixing the security warning in Firefox 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376

Part 4. Implementing tape data encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377

Chapter 12. Implementing TS1100 series Encryption in System z. . . . . . . . . . . . . . . 379
12.1 Implementation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
12.2 Implementation prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
12.2.1 Initial tape library hardware implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
12.2.2 Initial z/OS software definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
12.3 EKM implementation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
12.4 Tape library implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
12.4.1 Implementation steps for the IBM TS3500 Tape Library. . . . . . . . . . . . . . . . . . 384
12.4.2 Implementation steps for the IBM 3494 Tape Library . . . . . . . . . . . . . . . . . . . . 387
12.4.3 Implementation steps for the IBM TS3400 Tape Library. . . . . . . . . . . . . . . . . . 391
12.5 Tape control unit implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
12.6 z/OS implementation steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
12.6.1 z/OS software maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
12.6.2 Update PARMLIB member IECIOSxx. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
12.6.3 Define or update Data Class definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
12.6.4 Considerations for JES3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
12.6.5 Tape management system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
12.6.6 DFSMSrmm support for tape data encryption. . . . . . . . . . . . . . . . . . . . . . . . . . 399
12.6.7 DFSMSdfp access method service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
12.6.8 Data Facility Data Set Services considerations . . . . . . . . . . . . . . . . . . . . . . . . 403
12.6.9 DFSMS Hierarchal Storage Manager considerations . . . . . . . . . . . . . . . . . . . . 404
12.7 z/VM implementation steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
12.7.1 Tape library and tape control unit implementation . . . . . . . . . . . . . . . . . . . . . . 406
12.7.2 Out-of-band encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
12.7.3 Define key aliases to z/VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
12.7.4 Using ATTACH and DETACH to control encryption . . . . . . . . . . . . . . . . . . . . . 411
12.7.5 Using SET RDEVICE to control encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
12.7.6 QUERY responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
12.7.7 z/VM DASD Dump Restore (DDR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
12.8 Miscellaneous implementation considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
12.8.1 Data exchange with other data centers or business partners . . . . . . . . . . . . . . 414
12.8.2 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
12.9 TS1120 and TS1130 tape cartridge rekeying in z/OS. . . . . . . . . . . . . . . . . . . . . . . . 414
12.9.1 TS1120 Model E05 rekeying support in z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . 415
12.9.2 IEHINITT enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
12.9.3 Security considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
12.9.4 Packaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
12.9.5 Rekeying exits and messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418

Chapter 13. Implementing TS7700 Tape Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . 419
13.1 TS7700 Encryption overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
13.2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421

viii IBM System Storage Tape Encryption Solutions

13.2.1 Tape drives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
13.2.2 TS7700 Virtualization Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
13.2.3 Library Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
13.2.4 Encryption Key Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
13.3 Implementation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
13.3.1 Initial Tape Library hardware implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 422
13.3.2 Initial TS7700 implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
13.3.3 Initial z/OS software definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
13.3.4 EKM implementation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
13.4 Tape library implementation and setup for encryption . . . . . . . . . . . . . . . . . . . . . . . 423
13.4.1 Enabling drives for encryption in the IBM TS3500 Tape Library. . . . . . . . . . . . 424
13.4.2 Enabling drives for encryption in the IBM 3494 Tape Library . . . . . . . . . . . . . . 426
13.4.3 Encryption-enabled drives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
13.5 Software implementation steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
13.5.1 z/OS software maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
13.5.2 EKM installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
13.5.3 Basic z/OS DFSMS implementation steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
13.6 TS7700 implementation steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
13.6.1 Configuring the TS7700 for encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
13.6.2 Creating TS7700 Storage Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
13.6.3 Creating TS7700 Management Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
13.6.4 Activate the TS7700 Encryption Feature License . . . . . . . . . . . . . . . . . . . . . . . 435
13.6.5 EKM addresses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
13.6.6 Testing EKM connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
13.6.7 Configuring Pool Encryption Settings for the TS7700. . . . . . . . . . . . . . . . . . . . 438
13.7 Implementation considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
13.7.1 Management construct definitions and transfer . . . . . . . . . . . . . . . . . . . . . . . . 440
13.7.2 Changing storage pool encryption settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
13.7.3 Moving data to encrypted storage pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
13.7.4 EKM operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
13.7.5 Tracking encryption usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
13.7.6 Data exchange with other data centers or business partners . . . . . . . . . . . . . . 444
13.8 TS7700 Encryption with z/VM, z/VSE, or z/TPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444

Chapter 14. Implementing TS1120 and TS1130 Encryption in an Open Systems
environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
14.1 Encryption overview in an Open Systems environment . . . . . . . . . . . . . . . . . . . . . . 448
14.2 Adding drives to a logical library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
14.2.1 Advanced Library Management System considerations . . . . . . . . . . . . . . . . . . 449
14.3 Managing the encryption and business partner exchange . . . . . . . . . . . . . . . . . . . . 450
14.3.1 Disaster recovery considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
14.3.2 Keeping track of key usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
14.4 Encryption implementation checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
14.4.1 Planning your EKM environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
14.4.2 EKM setup tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
14.4.3 Application-Managed Encryption setup tasks . . . . . . . . . . . . . . . . . . . . . . . . . . 454
14.4.4 System-Managed (Atape) Encryption setup tasks . . . . . . . . . . . . . . . . . . . . . . 455
14.4.5 Library-Managed Encryption setup tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
14.5 Implementing Library-Managed Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
14.5.1 LME implementation tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
14.5.2 Upgrading firmware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
14.5.3 Add EKM or TKLM IP addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
14.5.4 Enable Library-Managed Encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464

Contents ix

14.5.5 Barcode Encryption Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
14.5.6 Testing encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
14.6 Implementing System-Managed Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
14.6.1 System-Managed Encryption tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
14.6.2 Atape device driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
14.6.3 Update Atape EKM proxy configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
14.6.4 System-Managed Encryption Atape device entries . . . . . . . . . . . . . . . . . . . . . 477
14.6.5 Updating the Atape device driver configuration . . . . . . . . . . . . . . . . . . . . . . . . 478
14.6.6 Enabling System-Managed Encryption using the TS3500 Web GUI . . . . . . . . 480
14.6.7 Using SMIT to enable System-Managed Encryption . . . . . . . . . . . . . . . . . . . . 481
14.6.8 Using tapeutil functions to verify EKM paths. . . . . . . . . . . . . . . . . . . . . . . . . . . 488
14.6.9 Managing System-Managed Encryption and business partner exchange . . . . 488
14.7 Application-Managed Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
14.7.1 IBM Tivoli Storage Manager overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
14.7.2 ITSM support for 3592 drive encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
14.7.3 Implementing Application-Managed Encryption . . . . . . . . . . . . . . . . . . . . . . . . 493
14.7.4 ITSM Encryption considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
14.8 IBM 3494 with TS1120 or TS1130 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
14.8.1 Review the 3494 encryption-capable drives . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
14.8.2 Specifying a Barcode Encryption Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
14.8.3 Entering the EKM IP address and key labels . . . . . . . . . . . . . . . . . . . . . . . . . . 503
14.8.4 ILEP key label mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504

Chapter 15. Tape data encryption with i5/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
15.1 Planning for tape data encryption with i5/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
15.1.1 Hardware prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
15.1.2 Software prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
15.1.3 Disaster recovery considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
15.1.4 EKM keystore considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
15.1.5 TS1120 Tape Encryption policy considerations . . . . . . . . . . . . . . . . . . . . . . . . 510
15.1.6 Considerations for sharing tapes with partners. . . . . . . . . . . . . . . . . . . . . . . . . 511
15.1.7 Steps for implementing tape encryption with i5/OS . . . . . . . . . . . . . . . . . . . . . 512
15.2 Setup and usage of tape data encryption with i5/OS . . . . . . . . . . . . . . . . . . . . . . . . 513
15.2.1 Creating an EKM keystore and certificate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
15.2.2 Configuring the TS3500 library for Library-Managed Encryption . . . . . . . . . . . 526
15.2.3 Importing and exporting encryption keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
15.2.4 Working with encrypted tape cartridges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
15.2.5 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552

Part 5. Appendixes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553

Appendix A. z/OS planning and implementation checklists . . . . . . . . . . . . . . . . . . . . 555
DFSMS Systems Managed Tape planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556
DFSMS planning and the z/OS encryption planning checklist . . . . . . . . . . . . . . . . . . . 556
Storage administrator stand-alone environment planning. . . . . . . . . . . . . . . . . . . . . . . 557
Storage administrator tape library environment planning . . . . . . . . . . . . . . . . . . . . . . . 558
DFSMS Systems Managed Tape implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559
Object access method planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560
Storage administrator OAM planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561
OAM implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
DFSMShsm tape environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562

Appendix B. z/OS Java and Open Edition tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
JZOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564

x IBM System Storage Tape Encryption Solutions

Console communication with batch jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564
EKM and JZOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565
MVS Open Edition tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568
Exporting a variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568
Setting up an alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568
Copying the escape character . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569
Advantages of VT100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569
Advanced security hwkeytool and keytool scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
Complete keytool example for JCEKS using hidden passwords . . . . . . . . . . . . . . . . . 571
Complete hwkeytool example for JCE4758KS using hidden passwords . . . . . . . . . . . 573
Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575
Security and providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575
Garbage Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576
Verifying the installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577
z/OS region size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577
Policy files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577

Appendix C. Asymmetric and Symmetric Master Key change procedures. . . . . . . . 579
Asymmetric Master Key change ceremony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
Encryption and decryption test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
Pre-key change: Disable PKA services for all images in the Sysplex. . . . . . . . . . . . . . 580
Key change: First LPAR in the Sysplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582
Key change: Subsequent LPARs in the Sysplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
Post-key change: All LPARs in the Sysplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
ICSF tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
Creating a PKDS VSAM data set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
Symmetric Master Key change ceremony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
Encryption and decryption test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
Disable dynamic CKDS updates for all images in the Sysplex . . . . . . . . . . . . . . . . . . . 599
Key change: First LPAR in the Sysplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
Reencipher the CKDS under the new SYM-MK Master Key . . . . . . . . . . . . . . . . . . . . 604
Change the new SYM-MK Master Key and activate the reenciphered CKDS . . . . . . . 606
Key change: Subsequent LPARs in the Sysplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607
Post-key change: All LPARs in the Sysplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610

Appendix D. z/OS tape data encryption diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . 617
EKM problem determination when running z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
Error scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
Diagnostic scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621
Encryption Key Manager error codes and recovery actions. . . . . . . . . . . . . . . . . . . . . . . . 623
Drive error codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
Control unit error codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
IOS628E message indicates connection failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628

Appendix E. IEHINITT exits and messages for rekeying . . . . . . . . . . . . . . . . . . . . . . . 629
Dynamic Exits Service Facility support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
Error conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
Programming considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
REKEY messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632
New messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632
Modified messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633

Contents xi

Appendix F. TS1100 and LTO4 SECURE key EKM on z/OS . . . . . . . . . . . . . . . . . . . . 635
Implementing the EKM in z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636
z/OS UNIX System Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636
Installing the Encryption Key Manager in z/OS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
Create a JCECCAKS for EKM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639
Setting up the EKM environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640
Starting EKM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643
EKM TCP/IP configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
Enterprise-wide key management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651
IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651
Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
How to get IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655

xii IBM System Storage Tape Encryption Solutions

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 IBM Corp. 2008, 2009. All rights reserved. xiii

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:
AIX 5L™ OS/400® System z9®
AIX® POWER® System z®
alphaWorks® pSeries® Tivoli®
AS/400® RACF® TotalStorage®
CICS® Rational® VTAM®
DB2® Redbooks® WebSphere®
developerWorks® Redbooks (logo) ® xSeries®
ESCON® RS/6000® z/OS®
FICON® S/390® z/VM®
i5/OS® System i5® z/VSE™
IBM® System i® z9®
iSeries® System p® zSeries®
Language Environment® System Storage™
Netfinity® System x®

The following terms are trademarks of other companies:

AMD, AMD Opteron, the AMD Arrow logo, and combinations thereof, are trademarks of Advanced Micro
Devices, Inc.

SUSE, the Novell logo, and the N logo are registered trademarks of Novell, Inc. in the United States and other
countries.

ACS, Red Hat, and the Shadowman logo are trademarks or registered trademarks of Red Hat, Inc. in the U.S.
and other countries.

VMware, the VMware "boxes" logo and design are registered trademarks or trademarks of VMware, Inc. in the
United States and/or other jurisdictions.

J2SE, Java, JDK, JNI, JRE, JVM, S24, Solaris, StorageTek, Sun, ZFS, and all Java-based trademarks are
trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

Internet Explorer, Microsoft, Windows Server, Windows, and the Windows logo are trademarks of Microsoft
Corporation in the United States, other countries, or both.

Intel Itanium, Intel, Itanium, Intel logo, Intel Inside logo, and Intel Centrino logo are trademarks or registered
trademarks of Intel Corporation or its subsidiaries in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

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.

xiv IBM System Storage Tape Encryption Solutions

Preface

This IBM® Redbooks® publication gives a comprehensive overview of the IBM System
Storage™ Tape Encryption solutions that started with the TS1120 Tape Drive in 2006 and
have been made available in the TS7700 Virtualization Engine in early 2007. Also in 2007,
the IBM Ultrium Linear Tape-Open (LTO) Generation 4 Tape Drive was announced including
its support for tape data encryption. In 2008, additional enhancements to the tape drives that
support encryption and to key management have been made. This edition of the book has
been updated with information about the TS1130 Tape Drive and the IBM Tivoli® Key
Lifecycle Manager (TKLM).

This publication is intended for System Programmers, Storage Administrators, Hardware and
Software Planners, and other IT personnel involved in planning, implementing, and operating
IBM tape data encryption solutions, and anyone seeking details about tape encryption.

This book also provides practical guidance for how to implement an enterprise-wide
encryption solution. We describe the general concepts of encryption and the implementation
options that are available when using IBM Tape to encrypt tape data. We explain the key
management options, including the Encryption Key Manager, which is a Java™ application
that allows for enterprise-wide keystores and key management across a wide variety of
platforms. We also provide detailed information for planning, implementation, and operation
of tape data encryption for IBM z/OS® and Open Systems hosts.

The team that wrote this book
This book was produced by a team of specialists from around the world working at the
International Technical Support Organization (ITSO), Austin Center.

Babette Haeusser is an IBM Certified IT Specialist and Tape Server Support Specialist at
IBM Deutschland GmbH, Germany. She writes extensively and teaches IBM classes
worldwide on all areas of Enterprise and Open Systems Tape and Tape Virtualization.
Babette joined IBM in 1973 as an application programmer. In 1987, she became an MVS
Systems Engineer and specialized in IBM Storage hardware and software, which she has
supported in various job roles since then. Before joining the ITSO in early 2005, Babette
worked in the Advanced Technical Sales Support team Europe. She led a team of specialists
for Enterprise Storage, while she focused on Enterprise Tape, including tape libraries and
Virtual Tape Servers.

Jonathan Barney is an Enterprise Security Architect with STG Lab Services, and CISSP.
He works extensively on tape encryption customer implementations, and z/OS security
solutions including PKI, TKE, and hardware cryptography. Jonathan joined IBM in August
2000 in the IBM System z® System Test Group. He has held various System z development
and testing roles until moving to Lab Services.

Arthur Colvig is an Advisory Software Engineer with IBM Tivoli in Beaverton, Oregon. He
has 7 years of experience as a Firmware Engineer on the IBM System Storage TS3500 Tape
Library (TS3500 tape library). He currently works on the IBM SAN Volume Controller SMI-S
API. Art joined IBM in 2001 as a Firmware Engineer on the TS3500. His areas of expertise
include storage management, tape libraries and drives, network protocols, and robotics. He
has patents in the areas of tape library virtualization, management security and distributed
system firmware management.

© Copyright IBM Corp. 2008, 2009. All rights reserved. xv

The team: Babette, Arthur, and Jonathan

Thanks to the following people for their contributions to this project:

Alex R. Osuna,
IBM International Technical Support Organization, Tucson Arizona

Emma Jacobs, Ann Lund, Sangam Racherla,
IBM International Technical Support Organization

Arthur Bariska, Erika Dawson, Dan Estelle, MaYan Wilt,
IBM Tucson

Timothy Hahn,
IBM Software Architect IBM Rational® Enterprise Tools

Brian Goodman, Steven Hart, Sara Hughes, Khan V. Ngo,
IBM Systems &Technology Group, Systems Software Development

John Peck
IBM Software Group, Tivoli

Jeff Ziehm
IBM LTO/3592, Tape Performance - ATS Americas

xvi IBM System Storage Tape Encryption Solutions

Thanks to the authors of the previous editions of this book:
Authors of the first edition, IBM System Storage TS1120 Tape Encryption: Planning,
Implementation, and Usage Guide, published in December 2006:
Anthony Abete, Arthur Bariska, Jonathan M. Barney, Babette Haeusser, Ulrich Nowotny
Authors of the second edition, IBM System Storage Tape Encryption Solutions, published
in March 2008:
Anthony Abete, Babette Haeusser, Burt Loper, Axel Melber

Become a published author
Join us for a two- to six-week residency program! Help write a book dealing with specific
products or solutions, while getting hands-on experience with leading-edge technologies. You
will have the opportunity to team with IBM technical professionals, Business Partners, and
Clients.

Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you
will develop a network of contacts in IBM development labs, and increase your productivity
and marketability.

Find out more about the residency program, browse the residency index, and apply online at:
ibm.com/redbooks/residencies.html

Comments welcome
Your comments are important to us!

We want our books to be as helpful as possible. Send us your comments about this book or
other IBM Redbooks 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

Preface xvii

xviii IBM System Storage Tape Encryption Solutions

Summary of changes

This section describes the technical changes made in this edition of the book and in previous
editions. This edition also includes minor corrections and editorial changes that are not
identified.

Summary of Changes
for SG24-7320-02
for IBM System Storage Tape Encryption Solutions
as created or updated on February 15, 2011.

May 2009, Third Edition
This revision reflects the addition, deletion, or modification of new and changed information.

New information
New information includes:
IBM TS1130 Tape Drive
Tivoli Key Lifecycle Manager

Changed information
Changed information includes:
Updates for TS7700 Encryption
Updates for the Open Systems Tape Library
Updates for System z Software support

© Copyright IBM Corp. 2008, 2009. All rights reserved. xix

xx IBM System Storage Tape Encryption Solutions

Part 1

Part 1 Introducing IBM tape
encryption solutions
In this part, we introduce you to the IBM data encryption solutions and describe the
underlying concepts and the components that are required for tape encryption. We also
provide you with general planning information.

© Copyright IBM Corp. 2008, 2009. All rights reserved. 1

2 IBM System Storage Tape Encryption Solutions

1

Chapter 1. Introduction to tape encryption
IBM has three tape drives that are capable of encrypting the data that is written on the tape
cartridge:
IBM System Storage TS1130 Model E06 and Model EU6 Tape Drive
IBM System Storage TS1120 Model E05 Tape Drive
IBM System Storage Linear Tape-Open (LTO) Ultrium Generation 4 Tape Drive

In this document, we use abbreviations and refer to the drives as the TS1130 Tape Drive,
TS1120 Tape Drive, and the LTO4 Tape Drive.

The IBM System Storage TS1130 Tape Drive Model E06 and Model EU6 have the capability
to encrypt data on tape cartridges. This encryption capability is standard on all TS1130 Tape
Drives and is available as a chargeable upgrade feature for existing installed TS1120 Model
E05 Tape Drives shipped prior to 8 September 2006. The encryption capability includes drive
hardware, and microcode additions and changes.

The IBM System Storage TS1120 Tape Drive Model E05 shown in Figure 1-1 has the
capability to encrypt data on tape cartridges. The TS1120 Tape Drive Model E05 has been
enhanced to support data encryption. Starting with shipments beginning 8 September 2006,
this encryption capability is standard on all TS1120 Model E05 Tape Drives and is available
as a chargeable upgrade feature for existing installed TS1120 Model E05 Tape Drives
shipped prior to 8 September 2006. The encryption capability includes drive hardware, and
licensed internal code additions and changes.

Figure 1-1 IBM System Storage TS1120 Model E05 Tape Drive


The IBM System Storage LTO Ultrium Generation 4 Tape Drive shown in Figure 1-2 has the
capability to encrypt data on tape cartridges. The LTO4 Tape Drive was originally designed to
support data encryption, and therefore, all LTO4 Tape Drives come standard with the data
encryption capability. The encryption capability includes drive hardware, and licensed internal
code additions and changes.

Although the LTO4 drive can read LTO2 and LTO3 cartridges and can write to LTO3
cartridges, LTO Ultrium Generation 4 cartridges are required to support encryption.

Figure 1-2 IBM System Storage LTO Ultrium Generation 4 Tape Drive

Although other encryption solutions require hardware resources or processor power when
using software encryption, tape data encryption is done with little or no impact on the
performance of the TS1130 Tape Drive, TS1120 Tape Drive or the LTO4 Tape Drive. You
can easily exchange encrypted tapes with your business partners or data centers that have
the necessary key information to decrypt the data.

With the original encryption announcement for the TS1120 Tape Drive, IBM also introduced
an IBM Encryption Key Manager (EKM) component for the Java platform feature and is
designed to generate and communicate encryption keys for tape drives across the enterprise.
The feature uses standard key repositories on supported platforms. The IBM tape data
encryption solution provides an enterprise key management solution with common software
for Open Systems and mainframe environments that allows sharing of a common keystore
across platforms. Integration with z/OS policy, key management, and security capabilities
provides a proven, highly secure infrastructure for encryption key management.

With the introduction of the Tivoli Key Lifecycle Manager (TKLM), IBM has made available the
next generation of Key Manager software to enable serving keys to the encrypting tape
drives. TKLM is intended to give a consistent look and feel for Key Management tasks across
the brand, while simplifying those same key management tasks,

The Encryption Facility for z/OS software provides a complementary encryption method for
sharing tape data with business partners who utilize different tape formats (other than
TS1130, TS1120 or LTO4). Encryption Facility for z/OS uses the same secure infrastructure
as used with the TS1130, TS1120 or LTO4, thus, providing a comprehensive solution for
z/OS clients, encrypting data for internal use, and even encrypting data to share with
business partners. Encryption Facility supports decryption of Encryption Facility encrypted
data on all platforms across the brand.

IBM tape data encryption provides high performance data encryption. Encryption is
performed at the tape drive hardware at the native speeds of the drive. It also supports
encryption of large amounts of tape data for backup and archive purposes.

The IBM tape data encryption solution, utilizing theTS1130 Tape Drive, TS1120 Tape Drive
or the LTO4 Tape Drive, offers a cost-effective solution for tape data encryption by offloading
encryption tasks from the servers, leveraging existing tape infrastructure incorporated in
standard IBM Tape Libraries, and eliminating the need for unique appliance hardware.


You can greatly simplify your tape data encryption management, because the solution
provides functions that are transparent to your applications when encryption is managed by
the operating system (system-managed encryption) or when encryption is managed by the
tape library (library-managed encryption). For TS1130 and TS1120 encryption, the cartridge
data key is stored in an encrypted form on the tape cartridge. For LTO4 encryption, a pointer
to the data key that is used to encrypt the tape is stored on the tape cartridge. Support of a
single key management approach can help reduce audit and compliance costs.

When taking a closer look at encryption, several of the most important questions that you
want answered are:
How does tape data encryption work?
What should we encrypt, and what should we not encrypt?
Why use tape data encryption? What are the benefits for my organization?

1.1 How tape data encryption works
Encryption, implemented in the tape drive, encrypts the data before it is written to the
cartridge. When tape compression is enabled, the tape drive first compresses the data to be
written and then encrypts it. This method means no loss of capacity with IBM tape data
encryption. If the encryption solution encrypts the data first and then tries to compress the
data, the encrypted data usually compresses very little, if at all.

To encrypt the data, the tape drive requires a key to use. This key is provided by the
Encryption Key Manager in an encrypted form to make the tape data encryption solution
secure.

Figure 1-3 summarizes the process for tape data encryption using TS1130 and TS1120.

1. Load cartridge, specify
encryption

Encryption 2. Tape drive requests a data key
Key
Manager Encrypted “Data Key”

5. Tape drive writes encrypted
3. Key manager 4.Encrypted keys data and stores encrypted data
generates key and transmitted to tape drive key on cartridge
encrypts it

Encrypted “Data Keys”

Figure 1-3 TS1120 and TS1130 tape data encryption process flow

Figure 1-4 on page 6 summarizes the LTO4 tape data encryption process flow.

Chapter 1. Introduction to tape encryption 5

1. Load cartridge, specify
encryption

Encryption 2. Tape drive requests a data key
Key
Manager
5. Tape drive decrypts the data
key, writes encrypted data and
3. Key manager keyid on the cartridge
4.Encrypted data key
retrieves key and transmitted to tape drive
encrypts it for
transmission

LTO 4 Encryption
Encrypted “Data Key”

Figure 1-4 LTO4 tape data encryption process

For a detailed description of these processes, refer to Chapter 2, “IBM tape encryption
methods” on page 23.

1.2 What to encrypt
Since 2005, over 250 million consumers have been notified of potential security breaches
regarding personal information. The source for this information is:
http://www.Privacyrights.org

The loss of computer backup tapes is one type of event that triggers consumer notification.
This has led to increasing data protection requirements as indicated in Figure 1-5.

Data Center

Secondary Site
Business Partners
In Transit

Figure 1-5 Client data protection requirements


What should you encrypt, and just as important, what should you not encrypt? The focus on
data security is an ever-increasing:
California is generally considered the first state to implement a law requiring disclosure of
security breaches (July, 2003).
Legislation has been enacted by 38 states that requires notification in cases of security
breaches. The source for this is:
http://www.Privacyrights.org
Similar federal legislation has been proposed. The source for this is:
http://www.epic.org/privacy/bill_track.html

Data protection requirements are driven by a variety of reasons. In addition to regulatory
requirements that are driving the need for greater data security, integrity, retention,
auditability, and privacy, the reasons for increasing data protection are:
Severe business impacts that might be caused by loss or theft of data, including financial
liability, reputation damage, legal risk, and compliance risk
Requirement to share data securely with IBM Business Partners and maintain backups at
remote locations is increasing
Requirement to reduce complexity and improve processes around enterprise encryption
management is increasing
Requirement to cost-effectively encrypt large quantities of tape data

The additional drivers for encryption in financial services are:
A riskier environment
Internet Banking, for example, relies on open networks with multiple access points to
conduct business in real time to drive down costs and improve response times to revenue
generating opportunities.
Growing regulatory burden, such as:
– Gramm-Leach-Bliley Act (GLBA) of 1999
– California Law No. SB 1386
– FCRA/FACTA amendments
– Basel II
Not all of the regulations specifically require the use of stored data encryption. However,
many organizations are implementing encryption for their protected information in
conjunction with other security layers to protect Personally-Identifiable Information.
Maturing industry standards, such as the Payment Card Industry (PCI) Data Security
Standard (DSS)

In summary, simply encrypt everything that you can encrypt and still be able to recover data
in event of a disaster. As long as system data can be separated from application data,
encrypting everything with no performance impact is easier than choosing which data falls
into which legislation for encryption, and trying to keep current on the dynamic privacy rights
rules and regulations.

1.3 Why use tape data encryption
Tape data encryption is used to hide and protect sensitive data. If tape data on cartridges
leaves data centers, the data is no longer protected through Resource Access Control Facility
(RACF®) or similar access protection mechanisms. Tape data encryption can help fulfill


security regulations. Many governmental agencies require disclosure of security breaches.
Industry organizations are also increasing their scrutiny of security procedures. Tape data
encryption uses an easy and economical way to protect data from unauthorized view.

Important and sensitive data can be protected in many ways. Data can be encrypted by
means of special software programs, hardware adapters, facilities, or outside of the device
where the data is stored. Encrypting data with software programs takes away processor
power, and encrypting data with hardware requires additional investment in hardware for the
computers.

The advantage of IBM tape data encryption is that the data is encrypted after compression,
and there are no additional software program costs. IBM tape data encryption saves space
on tape cartridges and saves additional hardware investments. In addition, outboard
encryption in the tape drives might help you protect large volumes of tape data in a
cost-effective way. Data on cartridges does not have to be degaussed or overwritten with
patterns of x’FF’ at the end of life of the cartridge. This approach is valid for Write Once Read
Many (WORM) cartridges and for normal cartridges.

The encryption key management capability is designed to manage keys across mainframes
and Open Systems environments. There is only one component to be managed across
multiple platforms.

Tape data encryption can be managed by the applications, or can be system-managed or
library-managed. The following chapters discuss the prerequisites necessary to prepare the
hardware levels and required software levels. After you complete the preparation steps, you
can start the encryption of tape data very quickly.

Additionally, a clever use of encryption is for data shredding. In effect, if you delete an
encryption key, all of the data that the encryption key protected, becomes garbage. This use
of cryptography requires extreme care to know exactly what data belongs to what key.

1.3.1 Why encrypt data in the drive
The IBM tape-drive encryption solution encrypts the data within the drive using the 256-bit
Advanced Encryption Standard (AES) algorithm, rather than receiving previously encrypted
data. This system offers several advantages. By encrypting data in the drive, the drive can
offer the most efficient data compression, because the drive first compresses the data, then
encrypts it, providing more efficient data storage and media usage.

Encrypting in the drive also eliminates having to use additional machines or appliances in the
environment by offloading the encryption processing overhead onto the drive. Because the
drive can also process unencrypted workloads, the IT environment is further simplified by
eliminating the need for separate drives to process data that does not have to be encrypted.

1.3.2 Fundamental to encryption: Policy and key management
Tape drive-based encryption using keys is only part of the solution. A complete solution must
also address encryption policy and key management. IBM recognizes that policy and key
management can vary depending on the environment, and as a result, IBM has developed a
flexible solution that allows you to tailor the implementation to your unique environment.

The IBM solution provides policy options at three levels:
Application layer
System layer
Library layer


IBM supports two methods for managing the encryption keys: through the application (in
Open Systems) or through a new key manager program called the Tivoli Lifecycle Key
Manager. Additionally the previous generation key manager called the Encryption Key
Manager (EKM) is still available. The policy implementation also depends on the
environment. For example, in a z/OS environment, the encryption policies can be managed
by Data Facility Storage Management Subsystem (DFSMS) structures; however, in the Open
Systems environments, the policy granularity is based on other methods, such as by drive or
by a range of volume serial numbers on cartridges in a library.

1.3.3 Summary
Encryption capability that is provided as a standard feature in the IBM TS1130, IBM TS1120
Tape Drive or the IBM LTO4 Tape Drive makes encrypting data stored on tape cartridges
much easier. This capability is increasingly important as legislation continues to grow,
requiring the notification of individuals when their personal information has potentially been
compromised. The tape drive-based encryption solutions developed by IBM and described
here, coupled with the new Encryption Key Manager component, enable key management
and encryption in a wide variety of environments.

IBM provides tape drive encryption support in a range of operating systems environments:
z/OS
z/VM®
z/VSE™
z/TPF
i5/OS®
AIX®
Linux® on System z
Linux on other platforms
HP-UX
Sun™ Solaris™
Windows® Server 2000, Windows 2003, or Windows 2008 Server

Support is described in detail in the following chapters.

All statements regarding IBM plans, directions, and intent are subject to change or withdrawal
without notice. Any reliance on these statements of general direction is at the relying party’s
sole risk and will not create liability or obligation for IBM.

1.4 Concepts of tape data encryption
In this section, we discuss basic encryption, cryptographic terms, and ideas. Encryption has
been used to exchange information in a secure and confidential way for many centuries.
Encryption transforms data that is unprotected, or plain text, into encrypted data, or
ciphertext, by using a key. It is very difficult to “break” ciphertext in order to change it back to
the clear text without the associated encryption key.

Computer technology has enabled increasingly sophisticated encryption algorithms. Working
with the U.S. Government National Institute of Standards and Technology (NIST), IBM
invented one of the first computer-based algorithms, Data Encryption Standard (DES), in
1974. With the advances in computer technology, DES is now considered obsolete. Today,
there are several widely used encryption algorithms, including Triple DES (TDES) and
Advanced Encryption Standard (AES).


Early encryption methods used the same key to encrypt clear text to generate cipher text and
to decrypt the cipher text to regenerate the clear text. Because the same key is used for both
encryption and decryption, this method is called symmetric encryption. All of the encryption
algorithms previously mentioned use symmetric encryption.

It was only in the 1970s that cryptographers invented asymmetric key algorithms for
encryption and decryption. These algorithms use different keys for encryption and decryption.
The keys are mathematically related, but deriving one key from the other key is practically
impossible. Encryption methods using different keys for encryption and decryption are called
asymmetric encryption.

Asymmetric encryption addresses certain drawbacks of symmetric encryption, which became
more important with computer-based cryptography. We discuss this in detail in the following
two sections about symmetric and asymmetric key encryption.

The IBM tape data encryption solution uses a combination of symmetric and asymmetric
encryption methods.This combination of symmetric and asymmetric encryption algorithms is
prevalent in many security solutions, including TLS, IPSEC, Kerberos.

1.4.1 Symmetric key encryption
Symmetric key encryption uses identical keys - or keys that can be related through a simple
transformation - for encryption and decryption. Everyone who gets knowledge of the key can
transform the ciphertext back to plain text. If you want to preserve confidentiality, you must
protect your key and keep it a secret. Therefore, symmetric encryption is also called private
or secret key encryption, which is not to be confused with the private key in an asymmetric
key system.

In Figure 1-6 on page 11, we show a sample encryption and decryption data flow path. Here,
we use the symmetric key AES_256_ITSO to encrypt plain text using the AES encryption
algorithm, which yields encrypted data. The decryption of the enciphered text uses the same
AES_256_ITSO symmetric key and the AES algorithm to decrypt the data back to its plain
text format.


Encryption Process

Algorithm
Plain Text Encrypted Data
AES

Symmetric Key
AES_256_ITSO

Decryption Process

Algorithm
Plain Text Encrypted Data
AES

Symmetric Key
AES_256_ITSO

Figure 1-6 Symmetric key encryption

Symmetric key encryption algorithms are significantly faster than asymmetric encryption
algorithms, which makes symmetric encryption an ideal candidate for encrypting large
amounts of data.

In addition, the comparable key sizes for symmetric encryption as opposed to asymmetric
encryption are significantly different. At the time of writing this book, a 128-bit secret key is
used for symmetric AES encryption, and the Rivest-Shamir-Adleman (RSA) encryption
algorithm suggests a 1024-bit key length.

Secret key algorithms can be architected to support encryption one bit at a time or by
specified blocks of bits. The AES standard supports 128-bit block sizes and key sizes of 128,
192, and 256 bits. The IBM tape data encryption solution uses an AES-256 bit key.

Other well-known symmetric key examples include Twofish, Blowfish, Serpent, Cast5, DES,
TDES, and IDEA.

Speed and short key-length are advantages of symmetric encryption, but there are two
drawbacks, which are the way that keys are exchanged and the number of keys required.

Secure exchange of keys has always been a problem with symmetric encryption. The sender
and the recipient have to share a common, secret key. The sender of a confidential message
must make sure that no one other than the intended recipient gets knowledge of the key. So,
the sender has to transfer the key to the recipient in a secure way, for example, in a
face-to-face meeting, through a trusted courier, or a secure electronic channel. This method
of transferring keys might work as long as only few people are involved in the exchange of
confidential information. When a larger number of people have to exchange keys, the
distribution of secret keys becomes difficult and inefficient with this method.

The second drawback of symmetric encryption is the large number of required keys. When a
group of people are to exchange symmetrically encrypted information, each possible pair of
two people in this group has to share a secret key. The number of required keys grows very


fast with the number of people in the group. The number of keys required in relation to the
number of people can be calculated with the following formula, where k is the number of keys,
and n is the number of people:
kn =n(n-1)/2

As you can see in Figure 1-7, the number of required keys grows very fast. For a group of 100
people, 4,950 different keys are required. A group of 1,000 people requires 499,500 keys. Key
distribution and key management are challenges.

Figure 1-7 Number of keys required for symmetric encryption

The IBM tape data encryption solution utilizes an AES algorithm with a key length of 256 bits
for the encryption on the tape drive. The AES algorithm is based on the Rijndael algorithm.
AES is an accepted standard that supports a subset of the key sizes and block sizes that the
Rijndael algorithms supports.

Note: The Rijdindael algorithm supports block sizes of 128, 160, 192, 224, and 256 bits. It
supports key sizes of 128, 160, 192, 224, and 256 bits.

The shortcomings of symmetric encryption in terms of key distribution and key management
are addressed by asymmetric key encryption, which we describe in the next section.

1.4.2 Asymmetric key encryption
Asymmetric key encryption method uses key pairs for encrypting and decrypting data. One
key is used to encrypt the data, and the other key is used to decrypt the data. Because the
key used for encrypting a message cannot be used for decrypting it, this key does not have to
be kept a secret. It can be widely shared and is therefore called a public key. Anyone who


wants to send secure data to an organization can use its public key. The receiving
organization then uses its private key to decrypt the data. The private key is the
corresponding half of the public-private key pair and must always be kept a secret. Because
asymmetric encryption uses public-private key pairs, it is also called public-private key
encryption or public key encryption.

Public-private key encryption is useful for sharing information between organizations and is
widely used on the Internet today to secure transactions, including Secure Sockets Layer
(SSL).

The concept of asymmetric encryption is relatively new. For centuries, cryptographers
believed that the sender and the recipient had to share the same secret key. In the early
1970s, British cryptographers Ellis, Cocks, and Williamson discovered a way to use different
keys for encrypting and decrypting data. Because they were working for GCHQ, a British
intelligence agency, their findings were kept secret until 1997. In 1976, Whitfield Diffie and
Martin Hellman invented a solution to the problem, which has since become known as
Diffie-Hellman key exchange. In 1977 Ron Rivest, Adi Shamir, and Leonard Adleman
published an algorithm for public-key encryption.

Well-known examples of asymmetric key algorithms are:
RSA
Diffie-Hellman
Elliptic curve cryptography (ECC)
ElGamal

Today, the Rivest-Shamir-Adleman (RSA) algorithm is the most widely used public key
technique.

Note: RSA uses trapdoor functions. Trapdoor functions are mathematical functions that
are easy to compute in one direction, but are difficult to compute in the reverse direction
without additional information. This additional information is called the trapdoor. In the case
of RSA, the private key is the trapdoor.

The advantage of asymmetric key encryption is the ability to share secret data without
sharing the same encryption key. But there are disadvantages, too. Asymmetric key
encryption is computationally more intensive and therefore significantly slower than
symmetric key encryption. In practice, you will often use a combination of symmetric and
asymmetric encryption. We describe this method in 1.4.3, “Hybrid encryption” on page 15.

The IBM tape data encryption solution utilizes the asymmetric RSA algorithm to encrypt
symmetric AES keys.

Digital Signature
You can use public-private key pairs to protect the content of a message, and also to digitally
sign a message. For example, if Tony wants to send JoHann a digitally signed message,
Tony will not use JoHann’s public key to encrypt the message, but Tony’s own private key.
The content of the encrypted message is not protected, because anyone can decrypt the
message by using Tony’s public key. But, if JoHann is able to decrypt Tony’s message with
Tony’s public key, JoHann can be sure that Tony sent the message. JoHann has proof that
the message was encrypted with Tony’s private key and JoHann knows that only Tony has
access to this key.

In practice, predominantly for efficiency reasons, a hash value of the message is signed
rather than the whole message, but the overall procedure is the same.


In the previous example, JoHann has to make sure that Tony’s public key really belongs to
Tony, and not to someone pretending to be Tony. If JoHann cannot confirm this himself,
JoHann will need a trusted third party to verify Tony’s identity. A certificate issued and signed
by a Certification Authority (CA) can confirm that the public key belongs to Tony. A
certificate binds together the identity of a person or organization and its public key. If JoHann
trusts the CA, JoHann can be sure that it really was Tony who sent the message.

We discuss certificates in detail in 1.4.4, “Digital certificates” on page 16.

Of course, you can combine public key encryption and digital signature to produce a
message that is both encryption-protected and digitally signed.

Example of public-private key encryption
Figure 1-8 shows an encryption and decryption data path when using public key encryption
algorithms. In the diagram, the plain text is enciphered using the public key and an RSA
encryption algorithm, which yields the encrypted data.

Starting with the enciphered text, a private key is used, with the RSA algorithm to decrypt the
data back to plain text.

Public/Private Key Encryption

Algorithm Encrypted
Plain Text RSA Data

Asymetric
Public Key

Decryption Process

Algorithm Encrypted
Plain Text RSA
AES Data

Asymmetric
Private Key

Figure 1-8 Public-private key encryption

In Figure 1-9 on page 15, we show a more complicated example of data protection and
sharing using an asymmetric key pair. In this example, Tony has a private key, and JoHann
has a copy of Tony’s public key. Tony sends JoHann a message that is encrypted with Tony’s
private key. JoHann then uses the public key to decrypt the message. When the message is
decrypted to clear text, this proves to JoHann that he is in fact communicating with Tony,
because only Tony has a copy of the private key. JoHann then public-key encrypts the data
that he wants to protect and sends it to Tony. Tony can use his private key to decrypt the
data.


Network

Bob Alice
Private Key
Private Key Encrypted Public Key

Message
Message Message

Public Key
Data Encrypted Data

Data

Figure 1-9 Identity verification using public-private key encryption

Both asymmetric and symmetric key encryption schemes are powerful ways to protect and
secure data. In 2.3, “Methods of managing IBM tape encryption” on page 32, we discuss how
to use these schemes in conjunction for the IBM tape data encryption solution to give us an
extremely secure way of protecting data.

1.4.3 Hybrid encryption
In practice, encryption methods often combine symmetric and asymmetric encryption. Thus,
they can take advantage of fast encryption with symmetric encryption and still securely
exchange keys using asymmetric encryption.

Hybrid methods use a symmetric data key to actually encrypt and decrypt data. They do not
transfer this symmetric data key in the clear, but use public-private key encryption to encrypt
the data key. The recipient is able to decrypt the encrypted data key and use the data key to
encrypt or decrypt a message.

Hybrid encryption methods allow you to combine secure and convenient key exchange with
fast and efficient encryption of large amounts of data.

The IBM tape data encryption solution uses a symmetric AES data key to encrypt and decrypt
data. This data key is protected by the asymmetric RSA algorithm and is not available in the
clear when tape drives and the Enterprise Key Manager (EKM) or Tivoli Key Lifecycle
Manager (TKLM) communicate. For details about EKM, refer to 2.1, “IBM Encryption Key
Manager” on page 24. For details about TKLM, refer to 2.2, “Tivoli Key Lifecycle Manager” on
page 29.

Application-Managed Encryption does not use asymmetric encryption. Refer to 2.3.4,
“Application-Managed Encryption” on page 40 for more information.


1.4.4 Digital certificates
Digital certificates are a way to bind public key information with an identity. Part of the
information that is stored in a digital certificate is:
Name of the issuer
Subject Distinguished Name (DN)
Public key belonging to the owner
Validity date for the public key
Serial number of the digital certificate
Digital signature of the issuer

In this section, we discuss the X.509 Public Key Infrastructure (PKI), certificate chains,
certificate request, and certificate responses. X.509 is a well established and accepted
standard for certificate management.

In Figure 1-10 on page 17, we have an abstract simplified version of part of the process of a
self-signed certificate. It shows that both the issuer and subject of the certificate are IBM. This
certificate has a public key, a private key, and a public key that is signed by the private key of
this certificate. Data can be encrypted using a public key, which can then be decrypted by a
private key. This situation means that only the entity with the private key can decrypt the data
and ensures that only the entity for whom the data is intended can decrypt it.

When the private key is used to encrypt data, additional aspects must be considered. In this
case, we have a copy of the public key as clear text, and a copy that is encrypted by our
private key. This case means that anyone with a copy of our freely shared public key can
decrypt the data.

This approach means that when we send copies of our public key out in a certificate format,
the entity receiving the certificate can verify that the public key they were sent was sent by us,
was not intercepted in transit, and was not tampered with.

Because we have the only copy of our private key, we are the only entity that can encrypt a
copy of the public key in the certificate. If the entity uses our public key to decrypt the
enciphered copy of the public key in the certificate, if the decrypted public key matches the
clear public key, and if the owners of the public key trust that only we have our private key,
they know that when they use that public key to encrypt data, we are the only entity with the
capability to decrypt it. Figure 1-10 on page 17 shows a sample digital certificate.

In general, using a public key to encrypt data secures that data, ensuring confidentiality.
When using a private key to encrypt data, the following is true:
Identity proof
Message integrity
Non-repudiation


Figure 1-10 Sample digital certificate

When sending information that was private key-encrypted, the receiver of the message
knows that the message must have been sent by the entity with the private key; the receiver
also can verify that the message was not tampered with. Finally, the entity receiving a
message that was private key-encrypted knows that the message that they got cannot be
denied by the sender. In other words, because only the sender has the private key, the
sender must have sent it.

Certificate authorities
A certificate authority (CA) is a company that holds and makes available trusted certificates.
Companies can send certificates to a CA to be added to the chain of trust. As long as a
company trusts the CA, certificates that are issued by that CA can be trusted.

For example, Figure 1-11 on page 18 describes what company ZABYXC does to generate a
certificate request to the JohannTonyArtCA third-party certificate authority (CA) company. In
the figure, we see that company ZABYXC already trusts JohannTonyArtCA, because
ZABYXC has a copy of the JohannTonyArtRootCA in its certificate repository. This copy of
JohannTonyArtRootCA has only the public key and an encrypted copy of the public key,
which is encrypted with JohannTonyArtRootCA’s private key.

Company ZABYXC also has a self-signed personal certificate with a public and a private key
associated with it. Using certificate managing tools, company ZABYXC exports a copy of its
self-signed personal certificate that includes only the certificate information, the public key,
and the encrypted version of the public key.


This certificate request is sent to JohannTonyArtCA.

Third Party, CA
Cert. Repository
JohannTonyArt, CA

JohannTonyArt
Root, CA
Issuer = JohannTonyArt
Subject = JohannTonyArt Company
Public Key ZABYXC
Private Key Certs
JohannTonyArt
Root, CA
Public Key
Self Signed
Personal Cert
Certificate Subject =
Request ZABYXC
Issuer =
ZABYXC
Public Key
Private Key

Figure 1-11 Certificate request

In Figure 1-12 on page 19, JohannTonyArtCA receives the certificate response from
company ZABYXC. JohannTonyArtCA then uses the private key from JohannTonyArtRootCA
to encrypt a copy of the certificate request’s public key and attaches both the clear public key
and the new encrypted copy of the public key to a certificate response. In addition, the
certificate response has the issuer changed to JohannTonyArtCA. This response is sent to
company ZABYXC.

When Company ZABYXC receives the certificate response from JohannTonyArtCA,
Company ZABYXC imports the certificate into the company’s certificate repository. The
company replaces the self-signed personal certificate in the repository, and it keeps the
private key previously associated with the personal certificate.

Company ZABYXC can verify that the certificate response came from JohannTonyArtCA,
because they have a copy of JohannTonyArtRootCA. They can use the public key from
JohannTonyArtRootCA to verify that the certificate response came from JohannTonyArtCA.


Third Party, CA
Cert. Repository
JohannTonyArt, CA

Company ZABYXC
Certs
JohannTonyArt
JohannTonyArt Root, CA
Root, CA Pub Key
Subject = JohannTonyArt
Public Key
Certificate
Private Key
Response
Company ZABXYC
Company ZABYXC Subject = ZABYXC
Subject = ZABYXC
Issuer =
JohannTonyArt
Public Key Pub Key

Encrypted Public key Encrypted Public key

Figure 1-12 Certificate response

If company ZABYXC wants another company to share data with it, the company can now
export a copy of its personal certificate, which contains its public key, and the public key
signed by JohannTonyArtRootCA. When ZABYXC sends this certificate to a business
partner, the business partner can add JohannTonyArtRootCA to its own certificate repository
and then use that to verify the personal certificate sent to it by Company ZABYXC.

Having an extended certificate chain when dealing with PKI is possible. In a longer certificate
chain, the JohannTonyArtRootCA is the root CA with a validity of several years. Next in the
chain is a ZABYXCCA signed by the JohannTonyArtRootCA. This certificate can have a
shorter validity period and might have to be re-requested. The third-party CA keeps the
private key information for these certificates. When company ZABYXC generates a certificate
request in this situation, it receives a certificate response signed by company ZABYXCCA.

Figure 1-13 on page 20 shows an extended certificate chain. To verify certificate validity in
this situation, the whole chain has to be in the certificate repository.


Certificate Chain

JohannTonyArt Root CA

Public

Encrypted Public Key

Private Key

Company ZABYXC CA

Public Key


Private Key

Company ZABYXC
Personal Cert
Public Key


Private Key

Figure 1-13 Certificate chain

Secure Sockets Layer example
Figure 1-14 on page 21 shows a simple Secure Sockets Layer (SSL) handshake with
ClientAuthentication required. When more than one Encryption Key Manager (EKM) is used
in the IBM tape data encryption solution, the primary and secondary EKMs can synchronize
information using an SSL connection. The default SSL setup for the EKM is to not do
ClientAuthentication.

In the first portion of the handshake, the client sends a “Hello” message to the server; the
server responds by sending its own “Hello” message back and sending its trusted certificate.
If the client finds that it does indeed have a trusted certificate entry to verify that the server is
in fact the correct server, the handshake continues. In this example, we perform
ClientAuthentication, which causes the server to send a certificate request to the client. After
this step, the server “Hello” response is completed.

The next portion of the handshake is related to the ClientAuth value set to true. Here, the
client sends its certificate to the server, and if the server finds that it has the matching
certificate entry in its truststore, the handshake can continue, because the client’s identity is
verified.

After the client and the server have verified that they are indeed who they claim to be, they
exchange keys and decide with which SSL cipher to communicate. Data can then be
encrypted and sent across the network. Not only does SSL allow data communication to be
protected between a client and server, it also is used to prove client and server identities.


Figure 1-14 SSL Handshake example using ClientAuth


2

Chapter 2. IBM tape encryption methods
In this chapter, we discuss the Tivoli Key Lifecycle Manager (TKLM) and the Encryption Key
Manager (EKM), which are both Java software programs that manage keys enterprise-wide
and provide encryption-enabled tape drives with keys for encryption and decryption.The
TKLM is an IBM product that adds key management functionality over the EKM.

We describe various methods of managing IBM tape encryption. These methods differ in
where the encryption policies reside, where key management is performed, whether a key
manager is required, and, if a key manager is required, how the tape drives communicate
with it.

IBM supports three methods of encrypting data on tape:
System-Managed Encryption (SME)
Library-Managed Encryption (LME)
Application-Managed Encryption (AME)

Only two of these methods, SME and LME, require the implementation of an external
component, the TKLM, to provide and manage keys. With AME, key provisioning and key
management are handled by the application.

When describing the encryption methods, we trace the flow of data and keys. We explain how
the tape drive communicates with the EKM or the application and how symmetric keys and
asymmetric keys are transferred to the drive. For AME, we describe how the application
communicates with the tape drives.

In each section, we briefly discuss the criteria that can influence your decision for or against a
specific encryption method. For more information, refer to Chapter 4, “Planning for software
and hardware” on page 91).


2.1 IBM Encryption Key Manager
In your enterprise, a large number of symmetric keys, asymmetric keys, and certificates can
exist. All of these keys and certificates need to be managed. Key management can be
handled either internally by an application, such as Tivoli Storage Manager, or externally by
an Encryption Key Manager (EKM). In this section, we discuss the EKM.

LTO4, like the encryption-capable 3592 drives TS1120 and TS1130, provides three methods
of encryption management from which to choose. These methods differ in where you choose
to locate your EKM application. Your operating environment determines which is the best
method for you, with the result that key management and the encryption policy engine might
be located in any one of the following three environmental layers as shown in Figure 2-1.

Figure 2-1 EKM architecture

The IBM Encryption Key Manager component for the Java platform is a Java software
program that assists IBM encryption-enabled TS1120 Tape Drives and Linear Tape-Open
(LTO) Ultrium 4 Tape Drives by providing, protecting, storing, and maintaining encryption
keys that are used to encrypt information being written to, and decrypt information being read
from, tape media. EKM operates on a variety of operating systems. Currently, the supported
operating systems are:
z/OS
i5/OS
AIX
Linux
Hewlett-Packard UNIX® (HP-UX)
Sun Solaris
Windows

EKM is designed to be a shared resource deployed in several locations within an enterprise.
It is capable of serving numerous IBM encrypting tape drives regardless of where those


drives reside (for example, in tape library subsystems, connected to mainframe systems
through various types of channel connections, or installed in other computing systems).

IBM supplies the EKM, free of charge on IBM operating systems. On platforms that are not
IBM platforms, TPC-BE must be purchased to gain access to the EKM. For IBM operating
systems, download the current version of the IBM Encryption Key Manager for the Java
platform, the IBM Encryption Key Manager component for the Java platform, EKM
Introduction, Planning, and User’ Guide, GA76-0418, and a sample configuration file for
EKM. To download, use either of the following methods:
Go to:
http://www.ibm.com/support/search.wss?rs=1139&tc=STCXRGL&dc=D400&dtm
Go to the IBM Web site home page:
http://www.ibm.com

2.1.1 Encryption Key Manager components and resources
The sole task of the Encryption Key Manager is to handle serving keys to the encrypting tape
drives. The EKM does not perform any cryptographic operations, such as generating
encryption keys, and it does not provide storage for keys and certificates. To perform these
tasks, EKM has to rely on external components. In the following sections, we describe the
components of EKM and resources that are used by EKM.

Figure 2-2 shows the EKM components and external resources.

Encryption
Key Manager
(EKM)

Config Drive
File Table

Keystore Crypto Services

Figure 2-2 EKM components and resources

Note: In Figure 2-2, Crypto Services can refer to either Java security providers (software),
or cryptographic hardware installed on the system.

Tape drive table
The tape drive table is used by EKM to track the tape devices that it supports. The tape drive
table contains the list of the drives that can communicate with the EKM. You can populate this

Chapter 2. IBM tape encryption methods 25

list with additional drives by using the EKM adddrive command, or you can set a variable in
the configuration file so that EKM adds unknown drives to the list automatically.

The tape drive table also stores the default key labels for TS1100 drives and the active key
set list for LTO drives.

The tape drive table is a non-editable, binary file whose location is specified in the
configuration file. A number of EKM commands are available to add, delete, modify, and view
keys and certificates. You may change the location of the tape drive table to meet your
requirements.

Tip: The option to automatically accept unknown tape drives can facilitate the task of
populating the tape drive table with your drives. For security reasons, you might want to
turn off this option as soon as all of your tape drives have been added to the table. In a
business and continuity recovery site however like Sunguard or IBM BCRS it is required to
accept unknown tape drives.

Configuration file
The configuration file is an editable file which tells your EKM how to operate. Among others,
you specify in this file where the keystore and the drive table are located.

We discuss the configuration file extensively in Chapter 5, “Planning for EKM and its
keystores” on page 139, and later in Part 2, “Implementing and operating the EKM” on
page 137 where we describe the full set of configuration options.

Java security keystore
The keystore is defined as part of the Java Cryptography Extension (JCE) and an element of
the Java Security components, which are, in turn, part of the Java Runtime Environment. A
keystore holds the certificates and keys (or pointers to the certificates and keys) used by EKM
to perform cryptographic operations. A keystore can be either hardware-based or
software-based.

EKM supports several types of Java keystores, offering a variety of operational
characteristics to meet your requirements:
JCEKS: clear symmetric keys, clear asymmetric keys
JCE4758KS/JCECCAKS: clear symmetric keys, clear asymmetric keys, secure symmetric
keys, secure asymmetric keys
JCE4785RACFKS/JCECCARACFKS: secure asymmetric keys
JCERACFKS: clear asymmetric keys
PKCS11IMPLKS: types of keys supported depends on the PKCS11 implementation
IBMi5OSKeyStore: clear asymmetric keys

We discuss the characteristics of these keystores in 5.3, “EKM and keystore considerations”
on page 146.

Note: Encryption on IBM LTO Ultrium 4 drives requires a keystore that supports symmetric
keys.

Cryptographic Services
EKM uses the IBM Java Security components for its cryptographic capabilities. EKM does not
provide cryptographic capabilities and therefore does not require, nor is allowed to obtain,


FIPS 140-2 certification. However, EKM takes advantage of the cryptographic capabilities of
the IBM Java Virtual Machine in the IBM Java Cryptographic Extension component and
allows the selection and use of the IBMJCEFIPS cryptographic provider, which has a FIPS
140-2 Level 1 certification. In the Configuration Properties file, setting the FIPS configuration
parameter to ON causes EKM to use the IBMJCEFIPS provider for all cryptographic functions.

Note: Do not use hardware-based keystore types when the FIPS parameter is set ON.

More information about the IBMJCEFIPS provider, its selection, and its use is at:
http://www.ibm.com/developerworks/java/jdk/security/50/FIPShowto.html

2.1.2 Encryption keys and 3592 and LTO4 differences
An encryption key is typically a random string of bits generated specifically to scramble and
unscramble data. Encryption keys are created using algorithms designed to ensure that each
key is unique and unpredictable. The longer the key is that was constructed this way, the
harder it is to break the encryption code. Both the IBM and T10 methods of encryption use
256-bit Advanced Encryption Standard (AES) algorithm keys to encrypt data. The 256-bit
AES is the encryption standard currently recognized and recommended by the U.S.
Government, and allows three key lengths.The 256-bit keys are the longest allowed by AES.

The two types of encryption algorithms can be used by EKM are symmetric and asymmetric.
Symmetric, or secret key encryption, uses a single key for both encryption and decryption.
Symmetric key encryption is generally used for encrypting large amounts of data in an
efficient manner. The 256-bit AES keys are symmetric keys. TS1120, TS1130 and LTO4 all
use 256-bit AES symmetric keys to encrypt user data.

Asymmetric, or public-private encryption, uses a pair of keys. Data encrypted using one key
can only be decrypted using the other key in the public-private key pair. When an asymmetric
key pair is generated, the public key is typically used to encrypt, and the private key is
typically used to decrypt.

The public-private encryption algorithm is also referred to as the RSA algorithm for public key
cryptography, which is named after the inventors, Ron Rivest, Adi Shamir, and Leonard
Adleman (Rivest-Shamir-Adleman or RSA algorithm).

EKM uses both symmetric and asymmetric keys. It uses symmetric encryption for high-speed
encryption of user or host data, and asymmetric encryption (which is necessarily slower) for
protecting the symmetric key.

The responsibility for generating AES keys and the manner in which they are transferred to
the tape drive depends on the tape drive type and the method of encryption management.
The following applies when implementing encryption using either LME or SME. EKM and all
of its supported tape drives (TS1120, TS1130, and LTO4) use symmetric, 256-bit AES keys
to encrypt user data. The keys used to encrypt client data are referred to as data keys (DKs).
Important differences exist between the way TS1120 and TS1130 Tape Drives and LTO
Ultrium 4 Tape Drives handle these DKs.


3592 and LTO4 Tape Drives
IBM encryption capable drive types use 256-bit AES keys to encrypt user data. The TS1120
and TS1130 encryption DKs are randomly generated when needed, used, and then
discarded. LTO4 encryption DKs are randomly pregenerated and then kept in the EKM
keystore.

The LTO4 Tape Drive also uses 256-bit AES symmetric data keys to encrypt user data when
writing to LTO4 cartridges; however, the LTO4 data key is pregenerated and not randomly
generated like the 3592 drives. EKM selects a pre-generated data key in a round-robin
fashion. The data key is sent to the drive in a secure manner the same as the TS1120 and
TS1130. Unlike the 3592 drives, the data key is not stored on the cartridge. On an LTO4
cartridge, a pointer to the encrypting data key (key label or alias) is stored instead. The data
key must be accessible in a keystore based on the alias or key label and available to EKM the
volume can be read. Table 2-1 reflects key usage by encryption management method.

Tip: As of IBM 31-bit SDK for z/OS, J2TE, V5.0, SDK SR9 level or later, functionality has
been added to the hwkeytool (Key and Certificate Management Tool) to generate
SECURE symmetric keys. An example of this function in a z/OS EKM using a JCECCAKS
is in Appendix F, “TS1100 and LTO4 SECURE key EKM on z/OS” on page 637.

TS1120 and TS1130 Tape Drives
In addition to 256-bit AES symmetric data keys that are randomly generated for each volume
being encrypted, EKM also uses public-private (asymmetric) key cryptography to protect the
symmetric data encryption keys that are generated and retrieved as they pass between EKM
and 3592 tape drives. Public-private (asymmetric) key cryptography is also used to protect
the data key while it is stored on the cartridge. See Table 2-1.

Table 2-1 Key usage by drive type and management method
Encryption management Keys used by
method
TS1120 drive or TS1130 LTO4 drive

System-Managed Encryption One randomly generated One pregenerated DK per
or Library-Managed Encryption unique DKa per cartridge cartridge
using EKM

Application-Managed One randomly generated One DK per cartridge
Encryption (no EKM) unique DK per cartridge
a. DK is symmetric AES 256-bit data key

2.1.3 Key exchange
EKM acts as a process awaiting key generation or key retrieval requests sent to it through a
TCP/IP communication path between EKM and the tape library, tape controller, tape
subsystem, device driver, or tape drive. When a tape drive writes encrypted data, it first
requests an encryption key from EKM. The tasks that the EKM performs upon receipt of the
request are different for the TS1100 series drives.


TS1120 and TS1130 Tape Drives
EKM requests an Advanced Encryption Standard (AES) key from the cryptographic services
and serves it to the tape drives in two protected forms:
Encrypted or wrapped, using Rivest-Shamir-Adleman (RSA) key pairs. TS1120 and
TS1130 Tape Drives write this copy of the key to the cartridge memory and three
additional places on the tape media in the cartridge for redundancy.
Separately wrapped for secure transfer to the tape drive where it is unwrapped upon
arrival and the key inside is used to encrypt the data being written to tape.

When an encrypted tape cartridge is read by a TS1120 or TS1130 Tape Drive, the protected
AES key on the tape is sent to EKM where the wrapped AES key is unwrapped. The AES key
is then wrapped with a different key for secure transfer back to the tape drive, where it is
unwrapped and used to decrypt the data stored on the tape. EKM also allows protected AES
keys to be rewrapped, or rekeyed, using different RSA keys from the original keys that were
used when the tape was written. Rekeying is useful when an unexpected need arises to
export volumes to business partners whose public keys were not included; it eliminates the
need to rewrite the entire tape and enables a tape cartridge’s data key to be reencrypted with
a business partner’s public key. For a more detailed description, refer to 2.3.3, “Encrypting
and decrypting with SME and LME” on page 38.

LTO Ultrium 4 Tape Drives
The EKM fetches an existing AES key from a keystore and wraps it for secure transfer to the
tape drive where it is unwrapped upon arrival and used to encrypt data being written to tape.

When an encrypted tape is read by an LTO Ultrium 4 Tape Drive, the EKM fetches the
required key from the keystore, based on the information in the Key ID on the tape, and
serves it to the tape drive wrapped for secure transfer.

2.2 Tivoli Key Lifecycle Manager
In your enterprise, a large number of symmetric keys, asymmetric keys, and certificates can
exist. All of these keys and certificates have to be managed. Key management can be
handled either internally by an application, such as Tivoli Storage Manager, or externally by
an Encryption Key Manager (EKM). In this section, we discuss the Tivoli Key Lifecycle
Manager (TKLM).

The TKLM product is an application that performs key management tasks for IBM hardware
that is encryption-enabled like the IBM encryption-enabled TS1120 and TS1130 Tape Drives
and Linear Tape-Open (LTO) Ultrium 4 Tape Drives. The tasks provide, protect, store, and
maintain encryption keys that are used to encrypt information being written to, and decrypt
information being read from tape media. TKLM operates on a variety of systems. Currently,
the supported operating systems are:
AIX 5.3: 64 bit
Red Hat® AS 4.0 x86: 32 bit
SUSE® Linux 9.0 and 10 x86: 32 bit
Solaris 10 Sparc: 64 bit
Windows Server® 2003: 32 bit

TKLM is designed to be a shared resource deployed in several locations within an enterprise.
It is capable of serving numerous IBM encrypting tape drives regardless of where those
drives reside (for example, in tape library subsystems, connected to mainframe systems
through various types of channel connections, or installed in other computing systems).


2.2.1 Tivoli Lifecycle Key Manager components and resources
The sole task of the Tivoli Lifecycle Key Manager is to handle the serving of keys to the
encrypting tape drives. The TKLM does not perform any cryptographic operations, such as
generating encryption keys, and it does not provide storage for keys and certificates. To
perform these tasks, TKLM has to rely on external components. In the following sections, we
describe the components of TKLM and resources that are used by TKLM. In addition to the
key-serving function the TKLM also brings the following additional functions over the EKM:
Lifecycle functions
– Notification of certificate expiration through the Tivoli Integrated Portal (TIP)
– Automated rotation of certificates
– Automated rotation of groups of keys
Usability enhancements of EKM
– Provides a graphical user interface (GUI)
– Initial configuration wizards
– Migration wizards
Integrated backup and restore of TKLM file
– One button to create and restore a single backup packaged as a JAR file
TIP installation manager
– Simple to use installation for Windows, Linux, AIX, Solaris
– Can be a silent installation

Figure 2-3 shows the TKLM components and external resources.

Figure 2-3 TKLM components and resources

DB2
In TKLM the drive table is now stored in DB2®, giving the user a more robust interface to
managing drives, and the keys and certificates that are associated with those drives. In the
EKM, the only place to find which tapes were encrypted with what keys, and similar audit
information was in the EKM audit log and the EKM metadata.xml file. In TKLM, this
information is stored in the TKLM DB2 tables enabling the user to more easily search and
query that information.


Tip: The option to automatically accept unknown tape drives can facilitate the task of
populating the tape drive table with your drives. For security reasons, you might want to
turn off this option as soon as all of your tape drives have been added to the table. In a
business and continuity recovery site however, like Sunguard or IBM BCRS, it is required
to accept unknown tape drives.

Configuration file
Similar to the EKM, the TKLM also has an editable configuration file with additional
configuration parameters that is not offered in the GUI. The file can be text-edited, however
the preferred method is to modify the file through the TKLM command-line interface (CLI).

We discuss the configuration of TKLM extensively in Chapter 10, “Implementing TKLM” on
page 325 where we describe the full set of configuration options.

Java security keystore
The keystore is defined as part of the Java Cryptography Extension (JCE) and an element of
the Java Security components, which are, in turn, part of the Java Runtime Environment
(JRE™). A keystore holds the certificates and keys (or pointers to the certificates and keys)
used by TKLM to perform cryptographic operations. A keystore can be either hardware-based
or software-based.

TKLM supports several types of Java keystores, offering a variety of operational
characteristics to meet your requirements.

TKLM Open systems
TKLM on open systems supports the JCE keystore (JCEKS). This keystore supports both
CLEAR key symmetric keys, and CLEAR key asymmetric keys. Symmetric keys are used for
LTO4 encryption drives and asymmetric keys are used for TS1100 Tape Drives.

We discuss the characteristics of these keystores in detail in 5.3, “EKM and keystore
considerations” on page 146.

Cryptographic services
TKLM uses the IBM Java Security components for its cryptographic capabilities. TKLM does
not provide cryptographic capabilities and therefore does not require, or allowed to obtain,
FIPS 140-2 certification. However, TKLM takes advantage of the cryptographic capabilities of
the IBM Java Virtual Machine (JVM™) in the IBM Java Cryptographic Extension component
and allows the selection and use of the IBMJCEFIPS cryptographic provider, which has a
FIPS 140-2 Level 1 certification. By setting the FIPS configuration parameter to ON in the
Configuration Properties file, either through text editing or by using the TKLM CLI, you can
make TKLM use the IBMJCEFIPS provider for all cryptographic functions.

You can find more information about the IBMJCEFIPS provider, its selection, and its use at:
http://www.ibm.com/developerworks/java/jdk/security/50/FIPShowto.html

2.2.2 Key exchange
TKLM acts as a process awaiting key generation or key retrieval requests sent to it through a
TCP/IP communication path between TKLM and the tape library, tape controller, tape
subsystem, device driver, or tape drive. When a tape drive writes encrypted data, it first


requests an encryption key from TKLM. The tasks that the TKLM performs upon receipt of the
request are different for the TS1100 Tape Drive.

TS1100 Tape Drives
TKLM requests an Advanced Encryption Standard (AES) key from the cryptographic services
and serves it to the tape drives in two protected forms:
Encrypted or wrapped, using Rivest-Shamir-Adleman (RSA) key pairs. TS1100 Tape
Drives write this copy of the key to the cartridge memory and three additional places on
the tape media in the cartridge for redundancy.
Separately wrapped for secure transfer to the tape drive where it is unwrapped upon
arrival and the key inside is used to encrypt the data being written to tape.

Additionally the libraries now support SSL encrypted connections between the TKLM and
library for key exchanges. However, note that when not using SSL for key exchange the key
material will be encrypted in another fashion. The transport of the keys are always secure
across the TCP/IP connection.

When an encrypted tape cartridge is read by a TS1100 Tape Drive, the protected AES key on
the tape is sent to TKLM where the wrapped AES key is unwrapped. The AES key is then
wrapped with a different key for secure transfer back to the tape drive, where it is unwrapped
and used to decrypt the data stored on the tape. TKLM also allows protected AES keys to be
rewrapped, or rekeyed, using different RSA keys from the original keys that were used when
the tape was written. Rekeying is useful when an unexpected need arises to export volumes
to business partners whose public keys were not included; it eliminates having to rewrite the
entire tape and enables a tape cartridge’s data key to be reencrypted with a business
partner’s public key. For a more detailed description, refer to 2.3.3, “Encrypting and
decrypting with SME and LME” on page 38.

LTO Ultrium 4 Tape Drives
The TKLM fetches an existing AES key from a keystore and wraps it for secure transfer to the
tape drive where it is unwrapped upon arrival and used to encrypt the data being written to
tape.

When an encrypted tape is read by an LTO Ultrium 4 Tape Drive, the TKLM fetches the
required key from the keystore, based on the information in the Key ID on the tape, and
serves it to the tape drive wrapped for secure transfer.

2.3 Methods of managing IBM tape encryption
There are three methods of tape encryption management supported by the IBM tape data
encryption solution. These methods differ in where the encryption policy engine resides,
where key management is performed, and how the EKM is connected to the drive. Encryption
policies control which volumes need to be encrypted.

Key management and the encryption policies can be located in any one of the following three
environmental layers:
System layer
Library layer
Application layer


In accordance with the layers, we call these methods:

Not all operating systems, applications, and tape libraries support all of these methods, and
where they are supported; not all of the methods are equally suitable. When you plan for tape
encryption, select the encryption method depending on your operating environment. In the
following sections, we explain the characteristics of AME, SME, and LME.

Note: For the remainder of this chapter, in all text and figures, the process flows are the
same for the EKM and TKLM. You can substitute the TKLM for the EKM for these
discussions.

2.3.1 System-Managed Encryption
In a System-Managed Encryption (SME) implementation, encryption policies reside within the
system layer. This method of tape encryption requires an EKM for key management. SME is
fully transparent to the application and library layers. Figure 2-4 on page 34 shows a
schematic illustration of SME.

SME is supported on z/OS, z/VM, z/VSE, z/TPF, Linux on zSeries®, and a number of open
systems platforms. On z/OS, z/VM, z/VSE, z/TPF, and Linux on zSeries, SME is the only
encryption method supported. SME is supported on z/OS using Data Facility Storage
Management Subsystem (DFSMS). On open systems platforms, the IBM tape device driver
is used for specifying encryption policies on a per-drive basis.

The following open systems operating systems are currently supported:
AIX
Windows
Linux
Solaris

SME offers you centralized enterprise-class key management, which facilitates tape
interchange and migration. Another advantage is its support for stand-alone drives.
Drawbacks are its policy granularity on open systems, additional responsibilities for the
storage administrator, and the dependency of data access on the availability of the EKM and
the key path.

SME shares most of its advantages and disadvantages with LME, but with two major
differences. Naturally, LME does not support stand-alone tape drives. However in an open
systems environment, LME gives you a better policy granularity than SME, because you can
control encryption on a per-volume basis with TS3500 and 3494 tape libraries. On z/OS, you
can control encryption on volume level through the use of DSMFS.

In a System z environment that does not support encryption, or in an open systems
environment with stand-alone drives and an application that does not support encryption,
SME is the only choice. In all other environments, consider LME as an alternative.


Application
Layer

Encryption
Key Manager
Policy
System
Layer

Library
Layer

Figure 2-4 System-Managed Encryption (SME)

System-Managed Encryption for open systems
Encryption policies specifying when to use encryption are set up in the IBM tape device
driver. For details about setting up System-Managed Encryption on tape drives in an Open
Systems environment, refer to the IBM Tape Device Driver Installation and User’s Guide,
GC27-2130, and the planning and operator guide for your tape library.

On Open Systems, this support can be described as in-band where tape drive requests to the
EKM component travel over the Fibre Channels to the server hosting the EKM.

System-Managed Encryption for System z
On z/OS encryption, policies specifying when to use encryption are set up in DFSMS (Data
Facility Storage Management Subsystem). You can also use additional software products,
such as IBM Integrated Cryptographic Service Facility (ICSF) and IBM Resource Access
Control Facility (RACF). Key generation and management is performed by the Encryption
Key Manager (EKM), running on the host or externally on another host. Policy controls and
keys pass through the data path between the system layer and the encrypting tape drives.
Encryption is transparent to the applications.

For TS1120 Tape Drives that are connected to an IBM Virtualization Engine TS7700,
encryption key labels are assigned using the Maintenance Interface on a per-storage-pool
basis. DFSMS storage constructs are used by z/OS to control the use of storage pools for
logical volumes, resulting in an indirect form of encryption policy management. For more
information, refer to Chapter 13, “Implementing TS7700 Tape Encryption” on page 421 or
refer to the white paper, IBM Virtualization Engine TS7700 Series Encryption Overview, which
is available at:
http://www.ibm.com/support/docview.wss?&uid=ssg1S4000504

For information about encryption, refer to DFSMS Software Support for IBM System Storage
TS1120 Tape Drive (3592), SC26-7514.


Encryption key paths
System-Managed Encryption on z/OS use either of the following key flows:
In-band encryption key flow: Tape drive requests to the Encryption Key Manager
component travel over the ESCON/FICON® channels to the server proxy that is
TCP/IP-connected to the Encryption Key Manager
Out-of-band encryption key flow: The tape controller establishes the communication to the
EKM server over a TCP/IP connection. Out-of-band support requires a router.

Out-of-band support also runs on VM, VSE, TPF, and Linux on zSeries and is your only
option on those operating system platforms. The TS7700 Virtualization Engine also uses
out-of-band support.

In-band key flow
In-band key flow, shown in Figure 2-5, occurs between EKM and the tape drive through a
FICON proxy on the FICON/ESCON® interface. The FICON proxy supports failover to the
secondary key path on failure of first-specified EKM path addresses. Impact on controller
service requirements is minimal.

The controller:
Reports drive status in SMIT displays.
Passes encryption-related errors from the drive to the host.
Reports “encryption failure unit checks” to the host.
Must be reconfigured when new encryption drives are introduced for attachment or when
an encryption-capable drive is enabled for encryption.

System z

Encryption
Key Library Manager
Manager 3953 / 3494

Library
Manager
Interface

IOS Key
Exchange
Interface
FICON Subsystem TS1120
Proxy Proxy Drive Tape Drive
Interface
Encryption ESCON/ TS1120 Tape
FICON
Control Controller
Interface
or 3592-J70

Figure 2-5 In-band encryption key flow


Out-of-band key flow

Out-of-band key flow, which is shown in Figure 2-6, occurs between the EKM and the tape
drive through a subsystem proxy, which is located in the 3592 controller or TS7700
Virtualization Engine on the EKM interface. Impact on service requirements can be greater
than for in-band key flow because of the introduction of two routers on the EKM interface, to
and from the controller.

The controller and the TS7700:
Support failover to the secondary key path on failure of the first-specified EKM path
addresses
Report drive status in SMIT displays
Pass encryption-related errors from the drive to the host
Report “encryption failure unit checks” to the host
Must be reconfigured when new encryption drives are introduced for attachment or when
an encryption-capable drive is enabled for encryption

You may enter up to two EKM IP/domain addresses (and up to two ports) for each controller,
and two domain name server IP addresses.

Encryption TS7700
EKM Interface
Key Virtualization
Manager Library Engine
Manager
EKM Library Manager Interface
Interface
3953 / 3494 Subsystem
Proxy
Library Manager
Interface

Drive
System z Interface

TS1120
Tape Drive
FICON Subsystem (Back End)
Proxy Proxy
ESCON/
Encryption FICON TS1120 Tape Drive
Control Interface Interface TS1120
Controller
or 3592-J70 Tape Drive

Figure 2-6 Out-of-band encryption key flow

2.3.2 Library-Managed Encryption
In a Library-Managed Encryption (LME) implementation, encryption policies reside within the
tape library. This method of tape encryption requires an EKM for key management. LME is
fully transparent to the application and system layers. Figure 2-7 on page 37 shows an
illustration of Library-Managed Encryption.

LME offers you the broadest range of application and operating system support. Centralized
enterprise-class key management facilitates tape interchange and migration. If you


implement LME on a TS3500 or 3494 tape library, you get policy granularity on a per-volume
basis. LME comes with additional responsibilities for the storage administrator as compared
to AME. Data access depends on the availability of the EKM and the key path.

In most Open Systems environments, LME is the preferred method for tape encryption.

Application
Layer

Encryption
Key Manager
System
Layer

Library
Policy
Layer

Figure 2-7 Library-Managed Encryption (LME)

LME can be implemented on:
Open systems-attached TS3500 tape library with TS1120 and LTO Ultrium 4 Tape Drives
Open systems-attached 3494 or TS3400 tape library with TS1120 Tape Drives
TS3310, TS3200, or TS3100 tape library with LTO Ultrium 4 Tape Drives

Key generation and management is handled by EKM, running on a host with a TCP/IP
connection to the library. Policy control and keys pass through the library-to-drive interface;
therefore, encryption is transparent to the applications.

For TS3500 and IBM 3494 tape libraries, you can use barcode encryption policies (BEPs) to
specify when to use encryption. On an IBM TS3500 Tape Library, you set these policies
through the IBM System Storage Tape Library Specialist Web interface. On a 3494 tape
library, you can use the Enterprise Automated Tape Library Specialist Web interface or the
Library Manager Console. With BEPs, policies are based on cartridge volume serial numbers.
LME also allows for encryption of all volumes in a library, independent of barcodes.

For certain applications, such as Symantec NetBackup, LME includes support for Internal
Label Encryption Policy (ILEP). When ILEP is configured, the TS1120 or LTO Ultrium 4 Tape
Drive automatically derives the encryption policy and key information from the metadata
written on the tape volume by the application. Refer to your tape library operator’s guide.

The following IBM tape libraries support Library-Managed Encryption:
IBM System Storage TS3500 Tape Library
IBM TotalStorage® 3494 Tape Library


Note: System-Managed Encryption and Library-Managed Encryption interoperate with one
another. A tape that is encrypted using SME can be decrypted using LME, and the other
way around, provided that they both have access to the same keys and certificates.

2.3.3 Encrypting and decrypting with SME and LME
Encryption and decryption with System-Managed Encryption and with Library-Managed
Encryption are identical as far as their process flow.

SME and LME encryption processes
Figure 2-8 on page 39 describes the flow of encrypted data to tape, and how keys are
communicated to the tape drive and then stored on the tape media. In this particular example,
we assume an EKM is running on an abstract server, and that the tape library and,
consequently, the tape drives are connected to another abstract server. These can be the
same server or different servers, because whether the server is the same or not does not
affect the outcome.

We assume that a certificate from a business partner had been imported into this keystore. It
only has a public key associated with it; the business partner has the corresponding private
key.

Now, our server sends a write request to the drive. Our drive is encryption-capable, and the
host has requested encryption. As part of this initial write, the drive obtains two Key
Encrypting Key (KEK) labels from the host or a proxy, which are aliases for two
Rivest-Shamir-Adleman (RSA) algorithm KEKs. The drive requests that the EKM send it a
data key (DK) and to encrypt the DK using the public KEKs aliased by the two KEK labels.

The EKM validates that the drive is in its list of valid drives. After validation, the EKM obtains
a random DK from cryptographic services. The EKM then retrieves the public halves of the
KEKs aliased by the two KEK labels. The EKM then requests that cryptographic services
create two encrypted instances of the DK using the public halves of the KEKs, therefore,
creating two Externally Encrypted Data Keys (EEDKs).

The EKM sends both EEDKs to the tape drive. The drive stores the EEDKs in the cartridge
memory (CM) and three locations on the tape. The EKM also sends the DK to the drive in a
secure manner. The drive uses the separately secured DK to encrypt the data.

The two modes for creating the EEDK are:
CLEAR or LABEL: In this mode, the KEK label is stored in the EEDK.
Hash: In this mode, a Hash of the public half of the KEK is stored in the EEDK.

When sharing business partner KEKs, we recommend using the Hash mode. The Hash mode
lets each party use any KEK label when importing a certificate into their keystore. The
alternative is to use the CLEAR or LABEL mode and then have each party agree on a KEK
label.


Obtains KEK labels/methods

Requests DK using
KEK labels/methods

Validates drive in Drive Table

Requests a Data Key (DK)

Generates a random DK

Requests KEKs using
KEK labels/method

Retrieves KEK pairs

Requests DK to be wrapped
with public half of KEKs
generating two EEDKs

Creates EEDKs

Sends EEDKs

Writes EEDKs to
three locations on
tape and into CM

Encrypts write data using DK

Keystore Crypto Services EKM TS1120

Figure 2-8 Key and data flow for encryption using SME or LME

SME and LME decryption processes for TS1120
Figure 2-9 on page 40 shows the key and data flow for decryption. In this example, we
assume that the data was encrypted at another site. For the decryption process, the tape has
two EEDKs stored in its cartridge memory. We call these EEDK1 and EEDK2. EEDK1 was
stored with the CLEAR (or LABEL) mode selected, and EEDK2 was stored with the Hash
mode selected.

An encrypted tape is mounted for a read or a write append. The two EEDKs are read from the
tape. The drive asks the EKM to decrypt the DK from the EEDKs. The EKM validates that the
drive is in its list of valid drives. After validation, the EKM requests the keystore to provide the
private halves of each KEK used to create the EEDKs. The KEK label associated with EEDK1
cannot be found in the keystore, but the Hash of the public key for EEDK2 is found in the
keystore.

The EKM asks cryptographic services to decrypt the DK from EEDK2 using the private half of
the KEK associated with EEDK2. The EKM then sends the DK to the drive in a secure
manner. The drive then decrypts the data on the tape. In our example, we described reading
from an encrypted tape. Exactly the same communication between tape drive and the EKM
takes place for a write-append.


Reads EEDKs from
tape or from CM

Requests unwrap of
DK from EEDKs

Validates drive in Drive Table

Requests KEKs
for EEDKs

Retrieves KEK pairs

Requests unwrap of DK
from EEDKs using KEKs

Unwraps DK from EEDKs

Sends DK

Encrypts/decrypts
data using DK

Keystore Crypto Services EKM TS1120

Figure 2-9 Key and data flow for decryption using SME or LME

2.3.4 Application-Managed Encryption
For Application-Managed Encryption (AME), the application has to be capable of generating
and managing encryption keys and of managing encryption policies. Tivoli Storage Manager
contains these capabilities. Policies specifying when encryption is to be used are defined
through the application interface. The policies and keys pass through the data path between
the application layer and the encrypting tape drives. Encryption is the result of interaction
between the application and the encryption-enabled tape drive and does not require any
changes to the system and library layers. Refer to Figure 2-10 on page 41.

AME is the easiest encryption method to implement and adds the fewest responsibilities for
the storage administrator. Because the data path and the key path are the same, there is no
additional risk to data and drive availability. Policy granularity depends on the application.
With Tivoli Storage Manager, you control encryption on a storage pool basis. There is no
centralized key management with AME, because the application generates, stores, and
manages the encryption keys. The lack of centralized key management makes tape
interchange and migration more difficult.

AME can be the most convenient solution when Tivoli Storage Manager is the only
application that utilizes tape encryption.

Tivoli Storage Manager does not restrict you to using AME. You can also choose SME or
LME to encrypt Tivoli Storage Manager data.

Note: Tape volumes written and encrypted using the AME method can only be decrypted
with an AME solution. In addition, because the data keys reside only in the Tivoli Storage
Manager database, the same database must be used.


Policy
Application
Layer

System
Layer

Library
Layer

Figure 2-10 Application-Managed Encryption (AME)

AME on IBM TS1120 and LTO Ultrium 4 Tape Drives can use either of two encryption
command sets, the IBM encryption command set developed for EKM or the T10 command
set defined by the International Committee for Information Technology Standards (INCITS).

AME using the TS1120 and TS1130 Tape Drives is supported in the following IBM libraries:
IBM TotalStorage 3494 Tape Library

Application-managed tape encryption using LTO Ultrium 4 Tape Drives is supported in the
following IBM tape drives and libraries:
IBM System Storage TS2340 Tape Drive Express Model S43 and Xcc/HVEC 3580S4X

For details about setting up AME, refer to your Tivoli Storage Manager documentation or the
following Web site:
http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/index.jsp

Note: EKM is not required by, or used by, AME.

Example for Application-Managed Encryption
In this section, we describe how data is encrypted to tape using Tivoli Storage Manager as
the key manager. Figure 2-11 on page 42 shows a high-level diagram depicting how data and
keys travel to and from the tape when writing from the beginning of the tape (BOT).

In the figure, a tape drive mounts a tape for encryption. The tape drive then sends its tape ID
or VOLSER to Tivoli Storage Manager. Tivoli Storage Manager then generates a 256-bit AES
data key, encrypts the data key, and stores the encrypted data key and the tape identifier in
the Tivoli Storage Manager database. Tivoli Storage Manager then sends the data key to the


tape drive. Using the AES algorithms and the data key that was sent to it, the tape drive
encrypts data to the tape.

TSM
Server
Tape
Drive
 Tape ID
 Generate Data Key
 Store Data Key in DB  Encrypt Data
 Data Key with Data Key

Database  Encrypted  Tape ID
Tape ID Data Key Data

Tape1 AES Data Key1
Tape2 AES Data Key2
Tape
Tape3 AES Data Key3
AES 256
... ... Encrypted Data

Figure 2-11 Application-Managed Encryption data flow for encryption

Figure 2-12 on page 43 depicts the flow of data and keys when using AME to read or write
append an encrypted cartridge. In this diagram, Tivoli Storage Manager is the application that
controls encryption.

In our example, an encrypted tape is mounted for decryption. The tape drive reads the tape
ID or VOLSER and sends that information to Tivoli Storage Manager. Tivoli Storage Manager
looks up that tape ID in its internal database and finds the entry associated with it. Tivoli
Storage Manager then decrypts the data key from the entry. Tivoli Storage Manager then
sends the data key to the tape drive.

Now, the tape drive can read data from the tape, decrypting the data as it reads using the
256-bit AES data key and the AES algorithms to yield clear data.


TSM
Server
 Tape ID Tape
 Search Table for  Data Key
Drive
Tape ID
 Retrieve DataKey  Decrypted  Decrypt Data
with Data Key
from Database Data

Database  Encrypted  Tape ID
Tape ID Data Key Data

Tape1 AES Data Key1
Tape2 AES Data Key2
Tape
Tape3 AES Data Key3
AES 256
... ... Encrypted Data

Figure 2-12 Application-Managed Encryption data flow for decryption

2.3.5 Mixed mode example
In the previous sections, we described how encryption works with different tape encryption
methods. This section describes a mixed environment, using different types of tape
encryption methods. In reality, an enterprise is likely to have several types of systems. The
tape solutions can commingle and allow all of those disparate setups to take advantage of
tape data encryption.

In Figure 2-13 on page 44, we introduce a picture of an enterprise taking advantage of both
in-band and out-of-band encryption. In addition, this picture shows both a System-Managed
Encryption solution and a Library-Managed Encryption solution implemented concurrently in
the same enterprise.

In our example, an EKM is running on a z/OS system, taking advantage of hardware
cryptography for its keystore. There is also a miscellaneous IBM server system with an EKM
running and an open systems server attached to a TS3500 or 3494 tape library. The z/OS
system and the open systems server are attached to two separate libraries. The IBM server,
which is running a backup EKM, is not attached to any libraries, but it is attached to the
shared LAN/WAN.

We can see that the open systems server is running LME on its library. All data is sent across
Fibre Channel to the library to be encrypted to tape. The keys that this library uses for
encryption, however, come across the network from either the z/OS EKM or the IBM server
EKM.

The library that is attached to the z/OS system shows both in-band and out-of-band
encryption. The z/OS system attached to the library is using in-band encryption. EKM
communication to the library is across the Fibre Channel, and data is also sent across the
Fibre Channel. In addition, this library is pointing to the backup EKM on the IBM server
system. The keys that are served to the library from the IBM server flow across the network
which requires the library’s control unit to have network access.


z/OS System z Open Systems
KS Server
Server
DFSMS
Uses ICSF's
(Any instance
Linux; zLinux;
ICSF crypto services
of IBM JVM)
i5/OS, AIX;
& key store Windows;
EKM
Solaris; data
HP-UX

IBM JVM
Device
FICON
proxy EKM KS Driver
Eth

IB keys OB keys FC
(z/OS) DD
DFSMS keys
tells drive Key
to encrypt req. LAN/WAN any
ATL
a given LM
OB keys
cartridge keys
(non-z/OS)

CU Library
(J70 or C06) Eth Proxy
FC
FC Key is
served if TS3500 or 3494
drive is <OB to drive>
authorized RS422
<IB to drive> 3592 3592
ATL

Figure 2-13 Encryption in a mixed environment


3

Chapter 3. IBM System Storage tape and
tape automation for encryption
A wide variety of IBM tape products support encryption. In this chapter, we introduce and
describe the IBM tape drives, the IBM tape libraries, and the IBM Tape Virtualization solution
that support tape encryption in Open Systems and System z environments. We will discuss
the characteristics of each product and how it supports tape encryption.

We describe the following products:
IBM System Storage TS1120 and TS1130 Tape Drives
IBM System Storage TS1120 Tape Controller Model C06
IBM Virtualization Engine TS7700
IBM Linear Tape-Open (LTO) Ultrium 4 Tape Drives
IBM LTO Tape Libraries:
– IBM TS2900 Tape Autoloader
– IBM TS3100 Tape Library Express Model
– IBM TS3200 Tape Library Express Model
– IBM TS3310 Tape Library
– IBM TS3400 Tape Library
IBM TotalStorage 3494 Tape Library

For more information about tape drives and libraries, refer to:
IBM System Storage Tape Library Guide for Open Systems, SG24-5946
IBM TS3500 Tape Library with System z Attachment: A Practical Guide to TS1120 Tape
Drives and TS3500 Tape Automation, SG24-6789
IBM TotalStorage 3494 Tape Library: A Practical Guide to Tape Drives and Tape
Automation, SG24-4632
IBM System Storage TS1120 and TS1130 Tape Drives and TS1120 Controller (3592
Models J1A, E05, E06, EU6, J70 and C06) Introduction and Planning Guide, GA32-0555.


3.1 IBM System Storage TS1130 and TS1120 Tape Drive
The IBM System Storage TS1130 Tape Drive (machine type 3592, Model E06) represents
the third generation of IBM 3592 Tape Drives. Made available in September 2008. The
TS1130 is designed for applications that require high capacity and fast access to data across
a wide range of environments. The IBM TS1130 Tape Drive features dual 4 Gbps Fibre
Channel (FC) interfaces, has a native data rate of up to 160 MBps, and a native physical
capacity of up to 1000 GB on the JB cartridge.

The IBM System Storage TS1120 Tape Drive (machine type 3592, Model E05) represents
the second generation of IBM 3592 Tape Drives. Announced and made available in October
2005, the TS1120 is designed for applications that require high capacity and fast access to
data across a wide range of environments. The IBM TS1120 Tape Drive features dual 4 Gbps
Fibre Channel (FC) interfaces, has a native data rate of up to 100 MBps, and a native
physical capacity of up to 700 GB on the JB cartridge. Figure 3-1 shows the front view of the
IBM TS1120 Tape Drive. The 3592-E05 may be upgraded to a TS1130 drive model
3592-EU6. Section 3.1.2, “TS1120 characteristics” on page 47 discusses this upgrade.

Figure 3-1 TS1130 Model E05

Similar to the previous 3592-J1A, and 3592-E05, the 3592-E06 includes an RS-422 library
interface port for communication with the IBM TS3400 Tape Library, IBM TS3500 Tape
Library, or the IBM 3494 Tape Library. It directly attaches to Open Systems servers through a
Fibre Channel interface. The 3592-E05 is supported for attachment to ESCON and FICON
channels on System z servers through the following tape subsystems:
TS1120 Tape Controller Model C06
TS7700 Virtualization Engine (FICON only)11
IBM 3592-J70 Tape Controller1
IBM 3494 Models B10 and B20 Virtual Tape Server1 (VTS) in J1A Emulation mode

Important: To use tape encryption on a System z server, the TS1120 has to attach to the
host through a TS1120 Model C06 Tape Controller, the IBM 3592-J70 Controller, or the
TS7700 Virtualization Engine.

The IBM TS1130 Tape Drive and IBM TS1120 Tape Drive can be installed in a rack, inside an
IBM TS3400 Tape Library, inside an IBM TS3500 Tape Library, or in an already-installed
IBM 3494 Tape Library, frame models L22, D22, or D24.

1 Withdrawn from marketing


3.1.1 Tape data encryption support
The IBM TS1130 Tape Drive and IBM TS1120 Tape Drive supports encryption of data on a
tape cartridge. All IBM TS1130 Tape Drives and IBM T1120 Tape Drives with a serial number
of 13-65000 or higher are encryption-capable. For currently installed TS1120 drives with a
serial number lower than 13-6500, a chargeable upgrade is available.

The encryption capability is implemented through tape drive hardware, and microcode
additions and changes. All 3592 media, including WORM cartridges, can be encrypted. In
addition, two applications are designed to support encryption: Tivoli Key Lifecycle Manager
(TKLM) and Encryption Key Manager (EKM). Both TKLM and EKM uses standard key
repositories on supported platforms. Either TKLM or EKM is required on a supported server
to interface with the tape drive for encryption in a System-Managed Encryption or
Library-Managed Encryption implementation. Refer to Chapter 2, “IBM tape encryption
methods” on page 23. For a detailed discussion of the EKM program and the three encryption
methods available with the IBM TS1120 and IBM TS1130 Tape Drive.

With encryption enabled, the access time to data on the tape drive increases with the bulk of
the time spent in OPEN processing when writing from load point. Also, the tape drive unload
time increases. This is because of the time necessary to retrieve, read, and write the
encryption key.

Note: When attaching to a System z server, the IBM TS1120 Tape Controller Model C06
or the IBM 3592 Tape Controller Model J70 is required to support tape data encryption.

3.1.2 TS1120 characteristics
The IBM TS1120 Tape Drive maintains the same form factor and reliability specification of the
previous 3592 Model J1A, as well as the features and technology enhancements introduced
with the Model J1A. In addition, the 3592-E05 offers several enhancements over the previous
model.

Features introduced with the 3592-J1A and incorporated in the 3592-E05 include:
Digital speed matching
Channel calibration
High resolution tape directory
Virtual Backhitch (Recursive Accumulating Backhitchless Flush or Non-Volatile Caching)
Cartridge memory (CM)
Streaming Lossless Data Compression (SLDC)
Single Field Replaceable Unit (FRU)
Error detection and reporting
Statistical Analysis and Reporting System (SARS)
Large internal buffer of 512 MB (3592 Model J1A is 128 MB)

Recording format
The TS1120 reads and writes 16 data tracks simultaneously as opposed to the 3592 Model
J1A that reads and writes eight tracks at a time. TS1120 uses the Enterprise Format 2
(EFMT2 or E2) for data that is not encrypted or the Enterprise Encrypted Format 2 (EEFMT2
or EE2) for encrypted data, but can also read and write Enterprise Format 1 (EFMT1 or E1)
used by the IBM 3592 Model J1A Tape Drive.

Chapter 3. IBM System Storage tape and tape automation for encryption 47

J1A emulation
The TS1120 has an emulation mode that enables it to emulate the previous 3592 Model J1A.
If you attach a mix of TS1120 and 3592 Model J1A Tape Drives to a TS7700 Virtualization
Engine, a VTS release 2.32.745.xx (or later), or a 3592 Model J70 or TS1120 Model C06
Tape Controller, the 3592-E05 drives will automatically operate in J1A Emulation mode, even
when set to operate as native E05 drives. In this mode, the 3592-E05 drives read and write
only in E1 format at the J1A performance and capacity ratings.

Note: The IBM TS1120 Tape Drive cannot be encryption-enabled while running in J1A
Emulation mode.

Upgrading TS1120 to TS1130
If your TS1120 is still under warranty or a service contract you can upgrade it to a
3592-EU6.Refer to Figure 3-2. This involves replacing the drive brick (on the left side) but
preserving the drive canister and electronics (on the right side).

Figure 3-2 3592 Drive and canister assembly)

Advantages of upgrading TS1120 to TS1130 (3592-EU6)
Advantages include:
The 3592-EU6 retains the same serial number as it had as a 3592-E05 (reconfiguring your
EKM or TKLM is not necessary).
Capacity and performance of the 3592-EU6 are the same as a 3592-E06.
Media formats supported are the same as the 3592-E06.

Advantages of buying a new TS1130 instead of upgrading an existing TS1120
Advantages include:
New warranty
Ethernet service port
Old TS1120 can still write E1 format cartridges if necessary

Host attachment
Each IBM TS1120 Tape Drive comes with two independent 4 Gbps Fibre Channel ports for
attachment to multiple servers or a single server with redundancy. The IBM TS1120 Tape


Drive attempts to connect at 4 Gbps but auto-negotiates down to 2 Gbps and then 1 Gbps if
the system or switch to which it is connected cannot support 4 Gb.

In an open systems environment, you can connect different systems to the two Fibre Channel
ports and use the drive alternatively from each system, but you cannot share a drive between
an open systems and a System z environment. Note the following information:
Open Systems attachment
A TS1120 can attach to IBM System i®, i5, iSeries®, AS/400®, System p®, p5, pSeries®,
RS/6000®, RS/6000 SP systems, System z9® and System z servers, System x® and
xSeries®, Netfinity®, and non-IBM servers, workstations, and personal computers that
support Fibre Channel interfaces.
System z attachment
In a System z environment, the IBM TS1120 Tape Drives do not attach directly to the host.
They either attach as back-end drives to a TS7700 Virtualization Engine or a VTS Model
B10 or B20, or they attach to a TS1120 Model C06 or an 3592 Model J70 Tape Controller.

For the latest details about specific hardware, software, and Fibre Channel support for the
IBM TS1120 Tape Drive, refer to the following Web site:
http://www.ibm.com/systems/storage/tape/pdf/compatibility/ts1120_interop.pdf

For the latest information about applications and the levels that support TS1120 Tape Drives,
refer to the Independent Software Vendor (ISV) matrixes at:
http://www.ibm.com/systems/storage/tape/pdf/compatibility/ts1120_isv_matrix.pdf

For supported host bus adapters, refer to:
http://www.ibm.com/systems/support/storage/config/hba/index.wss

For additional information about TS1120, refer to IBM System Storage TS1120 Tape Drive
and Controller Introduction and Planning Guide, GA32-0555.

The IBM TS1130 Tape Drive maintains the same form factor and reliability specification of the
previous TS1120, as well as the features and technology enhancements introduced with the
TS1120. In addition, the 3592-E06 offers several enhancements over the previous model. If
you have a TS1120 that is still under warranty or a service contract, it may be upgraded to a
3592-EU6. This drive will have all the characteristics of a 3592-E06 with the exception that it
is not eligible for any further upgrade and does not contain an Ethernet service port.

The TS1130 characteristics include:
160 MBps (up to 350 MBps with compression)
1000 GB uncompressed using JB or JX media
650 GB uncompressed using JA or JW media
128 GB uncompressed using JJ or JR media
Reads but does not write E1 formatted media
MES Upgrade from TS1120 to 3592-EU6

Recording Format
The TS1130 reads and writes 16 data tracks simultaneously as opposed to the 3592 Model
J1A that reads and writes eight tracks at a time. TS1130 uses the Enterprise Format 3
(EFMT3 or E3) for data that is not encrypted or the Enterprise Encrypted Format 3 (EEFMT3
or EE3) for encrypted data, Enterprise Format 2 (EFMT2 or E2) for data that is not encrypted


or the Enterprise Encrypted Format 2 (EEFMT2 or EE2) for encrypted data, but can also read
Enterprise Format 1 (EFMT1 or E1) used by the IBM 3592 Model J1A Tape Drive.

J1A emulation
The TS1130 does not do J1A emulation. The TS1130 can still read E1 formatted media.

Host attachment
Each IBM TS1130 Tape Drive comes with two independent 4 Gbps Fibre Channel ports for
attachment to multiple servers or a single server with redundancy. The IBM TS1130 Tape
Drive attempts to connect at 4 Gbps but auto-negotiates down to 2 Gbps and then 1 Gbps if
the system or switch to which it is connected cannot support 4 Gb.

In an Open Systems environment, you can connect different systems to the two Fibre
Channel ports and use the drive alternatively from each system, but you cannot share a drive
between an Open Systems and a System z environment. A better approach is to connect
each port to an independent fabric for redundancy and zone the fabric so both open systems
hosts can access both ports. When combined with IBM device driver on most platforms this
will provide both load balancing and path failover. For more information, see the IBM
TotalStorage Tape Device Drivers Installation and User’s Guide, GC35-0154, available at the
following ftp site:
ftp://ftp.software.ibm.com/storage/devdrvr/
Open Systems attachment
A TS1130 can attach to IBM System i, i5, iSeries, AS/400, System p, p5, pSeries,
RS/6000, RS/6000 SP systems, System z9 and System z servers, System x and xSeries,
Netfinity, and servers that are not IBM, workstations, and personal computers that support
Fibre Channel interfaces.
System z attachment
In a System z environment, the IBM TS1130 Tape Drives do not attach directly to the host.
They either attach as back-end drives to a TS7700 Virtualization Engine or a VTS Model
B10 or B20, or they attach to a TS1120 Model C06 or an 3592 Model J70 Tape Controller.

http://www.ibm.com/systems/storage/tape/ts1130/index.html

For the latest information about applications and the levels that support TS1130 Tape Drives,
refer to the Independent Software Vendor (ISV) matrixes at:
http://www.ibm.com/systems/storage/tape/pdf/compatibility/ts1120_isv_matrix.pdf

For supported host bus adapters, refer to:
http://www.ibm.com/systems/support/storage/config/hba/index.wss

For additional information about TS1130, refer to IBM System Storage TS1120 and TS1130
Tape Drives and TS1120 Controller Introduction and Planning Guide 3592 Models J1A, E05,
E06, EU6, J70 and C06, GA32-0555.

3.1.4 3592 cartridges and media
The TS1130 uses Enterprise Format 3 (E3) recording technology. The TS1130 also reads
and writes Enterprise Format 2 (E2) and reads Enterprise Format 1 (E1). A JA cartridge
formatted in E3 has an uncompressed capacity of 640GB. The TS1120 uses Enterprise


Format 2 (E2) recording technology. A JA cartridge formatted in E2 has an uncompressed
capacity of 500 GB. The 3592 Model J1A uses Enterprise Format 1 (E1). A JA cartridge
formatted in E1 has an uncompressed capacity of 300 GB. When emulating the J1A, the
TS1120 also uses the E1 format to provide a native capacity of 300 GB on a data cartridge.
Though the 3592-J1A cannot read or write using E2 or E3, it recognizes E2 or E3 and rejects
cartridges formatted in E2 or E3 with an error message indicating that E2 or E3 is not
supported. It also can reformat E2 or E3 formatted cartridges using E1.

Media types
The TS1120 and TS1130 use six media cartridge types (JA, JB, JJ, JR, JW, and JX) and the
3592-J1A uses four media types (JA, JJ, JR, and JW). All six cartridge types contain the
same dual coat advanced particle media. Capacity on four of these media types depends on
whether it is used by model 3592-J1A, 3592-E05, 3592-EU6 or 3592-E06.

Table 3-1 shows the media types and capacity options available with 3592 Tape Drives.

Table 3-1 IBM TotalStorage Enterprise 3592 media types
Name Media Usable Native Native Native Native Data Facility
type length capacity capacity capacity capacity Storage
3592-J1A 3592-E05 3592-E05 3592-E06 Management
(E1 format) emulating J1A (E2 format) or Subsystem
(E1 format) 3592-EU6 (DFSMS)
(E3 format)

Data JA 570 m 300 GB 300 GB 500 GB 640 GB MEDIA5

Extended JB 785 m N/A N/A 700 GB 1000 GB MEDIA9
Data

Economy JJ 204 m 60 GB 60 GB 100 GB 128 GB MEDIA7

WORM JW 570 m 300 GB 300 GB 500 GB 640 GB MEDIA6

Economy JR 204 m 60 GB 60 GB 100 GB 128 GB MEDIA8
WORM

Extended JX 785 m N/A N/A 700 GB 1000 GB MEDIA10
WORM

Figure 3-3 on page 52 shows four of the six media types from left to right: Economy WORM,
WORM, Economy, and Data. The WORM cartridges pictured on the left have a platinum color
shell, and the Read/Write (R/W) cartridges on the right have a black shell. The write-protect
tab, door, and label for the full length cartridges (both WORM and R/W) are dark blue. The
write protect tab, door, and label for the economy (short length) cartridges are light blue.


WORM WORM R/W R/W

Figure 3-3 IBM System Storage Enterprise 3592 WORM and R/W cartridges

Labels
The 3592 cartridges use a new media label to describe the cartridge type. Figure 3-4 shows a
3592 cartridge with a JA label.

Figure 3-4 View of the 3592 cartridge label

The VOLSER consists of six characters, which are left-aligned on the label. Fewer than six
characters are possible, but hardly ever used. The media type is indicated by the seventh and
eighth characters. For optimal library performance make sure your labels adhere to the
guidelines found in Label Specification for IBM 3592 Cartridges when used in IBM Libraries:
http://www.storage.ibm.com/media/tapecartridges/index.html

Under Enterprise storage media, select 3592 tape cartridges. Under Related information,
select Barcode Label Specification for use with 3592 Tape Media. Under Content, select the
PDF file to access the document. You can also contact your IBM Marketing Representative
for this specification.

3592 WORM functionality
The IBM 3592 Write Once Read Many (WORM) data cartridges provide unalterable,
non-rewritable tape media for long-term record retention. WORM characteristics include:
WORM cartridges are available with 1000 GB, 640 GB, or 128 GB native capacity for E3
format (3592-E06 or 3592-EU6), with 700 GB, 500 GB, or 100 GB native capacity for E2
format (3592-E05) and with 300 GB or 60 GB native capacity for E1 format.
Non-reversible screws are used to secure the media housing.


WORM and R/W cartridges can be intermixed within the same IBM TotalStorage
Enterprise Automated Tape Library 3494, IBM System Storage TS3400 or TS3500 Tape
Library, or StorageTek™ Automated Cartridge System (ACS™) solutions.
When the drive senses that a cartridge is a WORM cartridge, the microcode prohibits
changing or altering user data that is already written on the tape. The licensed internal
code keeps track of the last point on the tape to which data can be appended by means of
an overwrite-protection pointer stored in the cartridge memory (CM).
Each WORM cartridge is identified using a unique cartridge identifier (UCID).

The WORM cartridge is geometrically identical to a R/W cartridge and uses the same
rewritable media formulation. The servo format, which is mastered onto the tape at
manufacturing, is different for WORM cartridge types, however. The WORM aspect comes
not from any inherent non-reversible media characteristic, such as permanent WORM on
optical media, CD-R, or ablative optical WORM, but rather by the way that the 3592 drive’s
microcode handles a WORM cartridge. The drive microcode does not allow writing over the
data or erasure of previously written user data, such as records or file marks, however,
appending new data following existing data is supported.

Final destruction of WORM cartridges
A WORM cartridge cannot be reused after it is written to, and thus, when it is no longer of
use, it needs to be destroyed. If the WORM cartridge has sensitive data, it needs to be
bulk-erased (which erases everything on the tape, including the mastered servo pattern,
rendering it useless), before it is sent out to the landfill or the incinerator.

Tape encryption is fully supported for WORM cartridges. You can rekey WORM cartridges,
because the wrapped key structures are not stored in the data area.

Note: Instead of physically deleting or destroying the data, consider rekeying WORM
cartridges and deleting the key after the rekeying operation.

3.2 IBM System Storage TS1120 Tape Controller
The IBM System Storage TS1120 Tape Controller is the replacement to the IBM 3592 Model
J70 Tape Controller. The IBM TS1120 Tape Controller is designed to attach to ESCON and
FICON channels on System z servers or through a FICON/FC switch with appropriate levels
of system software. Figure 3-5 shows a front view of the TS1120 Model C06.

Figure 3-5 IBM System Storage TS1120 Tape Controller


The TS1120 Tape Controller is supported in the following configurations:
TS3500
Attachment is the same as the 3592-J70 using the 3953 Tape Frame Model F05. An
intermix of these controllers is allowed in the 3953-F05 expansion frames.
IBM 3494 Tape Library
The IBM TS1120 Tape Controller resides in an IBM 3952 Tape Frame Model F05.
TS3400 Tape Library
The IBM TS1120 Tape Controller resides in an industry standard 19 inch rack.
Silo
The IBM TS1120 Tape Controller resides in a rack or in a 3952-F05 frame (replaces
3590-C10 frame). This controller is then connected to the 3592 drives residing in a
3592-C20 frame.
Stand-alone
The IBM TS1120 Tape Controller resides in a rack or in a 3952-F05 frame. This controller
is then connected to the 3592 drives residing in a rack.

Note: The IBM TS1120 Tape Controller supports 3592-J1A or TS1120 Tape Drives, but
not IBM 3590 Tape Drives.

3.2.1 IBM TS1120 Tape Controller characteristics
The TS1120-C06 offers ESCON and FICON attachment to 3592-J1A and 3592-E05 drives.
IBM 3592-J1A and TS1120 Tape Drives can be intermixed behind a single controller, but the
3592-E05 drives operate in 3592-J1A Emulation mode.

Note: To support tape data encryption, the IBM TS1120 Tape Drive must run in E05 mode,
not in J1A Emulation mode. Therefore,To use tape data encryption, do not intermix
3592-J1A and TS1120 Tape Drives behind the same Model C06 Tape Controller or Model
J70 Tape Controller. With System Managed Storage (SMS) tape support, intermixing
encryption-enabled and non-encryption-enabled 3592 Model E05 drives also is not
supported behind the same control unit.

Enhancements over the 3592-J70 that have been incorporated into the IBM TS1120 Tape
Controller include:
Up to four 4 Gbps FICON attachments or 2 Gbps for 3592 Model J70 controllers
Up to eight ESCON attachments
Support for an intermix of ESCON and FICON attachments
Up to sixteen attached 3592-E05 (or 3592-J1A) Tape Drives
Two 4 Gbps Fibre Channel adapters for attaching 3592 Tape Drives or switches
Support for 3592 drive hot swap capabilities
Support for capacity scaling and segmentation with the 3592 Tape Drives


Support for WORM capabilities with the 3592 Tape Drives
Support for call home communication
Support for outboard search interface, for increased performance of certain
applications.Currently, DFSMShsm audit is the only application written to take advantage
of this support.

In a system-managed (SMStape) environment, an intermix of encryption-enabled and
non-encryption-enabled TS1120 Model E05 drives is not supported behind the same IBM
TS1120 Tape Controller.

3.2.2 IBM TS1120 Tape Controller encryption support
The IBM TS1120 Tape Controller and its predecessor, the 3592-J70, support
System-Managed Encryption (SME). SME requires an Encryption Key Manager (EKM) to
manage and provide keys.

When the IBM TS1120 Tape Controller attaches to z/OS, two ways of connecting to the EKM
are supported: The controller can communicate with the EKM residing within z/OS through
the FICON or ESCON path, or it can communicate with the EKM through a TCP/IP
connection.

When the controller communicates with the EKM through the FICON or ESCON path, we call
this in-band encryption, because data and keys travel through the same path. When the
controller externally connects to an EKM through TCP/IP, we call this out-of-band encryption,
because data and keys are transferred through separate paths. When using out-of-band
encryption, the EKM can reside on any supported platform. Operating systems z/VM, z/VSE,
and z/TPF require out-of-band encryption.

If TS1120 drives attached to a TS1120 controller reside in a TS3500, TS3400, or 3494 Tape
Library, you can encryption-enable the drives through the library’s user interface. A service
support representative (SSR) has to encryption-enable stand-alone drives and drives
installed in a Silo.

For details about System-Managed Encryption, refer to 2.3.1, “System-Managed Encryption”
on page 33.

3.2.3 Installation with an IBM TS3500 Tape Library
To support the TS1130, TS1120 or 3592-J1A drives in an IBM TS3500 Tape Library, the IBM
TS1120-C06 Tape Controller is installed in an external frame, the 3953 Model F05 Frame.
The two versions of the 3953 Tape Frame are the base frame and the expansion frame. Both
frames have the same F05 model number and can contain one to three controllers depending
on whether the frame is a base frame or an expansion frame as shown in Table 3-2.

Table 3-2 TS1120 Tape Controllers in 3953 Tape Frames
Frame Attachments

3953 Tape Frame Model F05 (base) Zero to one IBM TS1120 Tape Controllers

3953 Tape Frame Model F05 (expansion) One to three IBM TS1120 Tape Controllers

A fully configured 3953 Tape System (3953-F05 Frames and 3953-L05 Library Manager) can
have up to sixteen subsystems attached (tape controllers, TS7700 Virtualization Engines, or


Virtual Tape Servers (VTSs)). If the maximum of two TS7700 Virtualization Engines (or VTSs)
is attached, you can only have fourteen TS1120 controllers.

Figure 3-6 shows a sample of a TS1120-C06 installation and configuration in a 3953-F05
base frame with two 3953-F05 expansion frames.

Ethernet Switch Ethernet Router Ethernet Router

Ethernet Switch Ethernet Router Ethernet Router
TS7700#2 Fibre Switch C06-Fibre Switch C06-Fibre Switch

C06 Fibre Switch C06-Fibre Switch C06-Fibre Switch
C06 Fibre Switch C06 Fibre Switch C06 Fibre Switch

LMB
TS3000 Switch
Monitor/Keyboard

TS3000 System Console
C06-4 C06-7 ...
KVM Switch
P P P P P P
O O O C06-3 O O C06-6 O
W LMA W W W W W
E E E E E E
R R R R R R
C06-1 C06-2 C06-5
Router

Figure 3-6 Sample configuration of IBM TS1120 Model C06 Tape Controller in 3953 frames

Drive attachment
The TS1120-C06 can attach up to sixteen TS1130, TS1120, or 3592-J1A Tape Drives in a
TS3500 library. For this attachment, there must be at least one Fibre Channel switch per tape
controller in a 3953 Model F05 Frame to route data between the controller and its associated
tape drives. For reliability, two Fibre Channel switches can be associated with one controller.
The tape drives connected to a particular controller do not need to reside in the same frame.
They can be spread across multiple frames in the IBM TS3500 Tape Library frames as shown
in Figure 3-7 on page 57. In this picture, one IBM TS1120-C06 Tape Controller has 16 tape
drives attached: four tape drives in each of four separate frames. Another controller also has
16 drives attached, 12 of which reside in one frame and 4 in another frame.


3953-F05 L2x D2x D2x D2x
Frame Frame Frame Frame Frame

TS1120
Model C06

3953-F05 L2x D2x
Frame Frame Frame

TS1120
Model C06

Figure 3-7 Examples for drive attachment to an IBM TS1120 Tape Controller

The TS1120-C06 supports an intermix of 3592-J1A and 3592-E05; however, this intermix
results in the 3592-E05 running in J1A Emulation mode at J1A capacity and performance
ratings.

3.2.4 Installation with an IBM TS3400 Tape Library
The TS1120 controller supports attachment of up to seven TS3400 libraries. Because each
TS3400 can house up to two TS1130 or TS1120 drives, you can attach a maximum of
fourteen drives installed in TS3400 libraries to one IBM TS1120 Model C06 Tape Controller.
If an IBM TS1120 Tape Controller attaches to drives in a TS3400, all other drives attached to
this controller also must reside in TS3400s.

Both the controller and the libraries need to be rack-installed. The TS3400 Tape Library does
not support 3592-J1A drives.

Figure 3-8 on page 58 shows the maximum configuration of TS3400 Tape Libraries attached
to an IBM TS1120 Tape Controller.


TS3400 TS3400
Tape Library Tape Library

TS3400 TS3400

TS3400 TS3400

TS1120 TS3400
Tape Controller Tape Library

Figure 3-8 Maximum configuration of TS3400 attached to IBM TS1120 Tape Controller

3.2.5 Installation with an IBM 3494 Tape Library
When using a C06 controller with an IBM 3494 Tape Library, the controller resides in a 3952
Tape Frame that is detached from the library.

There are two versions of the 3952 Tape Frame for the TS1120 Model C06: the 3494
attachment frame and the silo-attached frame. A maximum of three IBM TS1120 Model C06
Tape Controllers can be installed in the frame, as detailed in Table 3-3.

Table 3-3 TS1120 Tape Controllers in 3952 Tape Frames
Frame Attachments

3952 Tape Frame Model F05 (3494 attachment) One to three IBM TS1120 Tape Controllers

3952 Tape Frame Model F05 (silo attachment) One to three IBM TS1120 Tape Controllers

The TS11200 Model C06 connects to the library through a 3494 D24 or 3494 D22 frame. The
3494 D24 frame or 3494 D22 frame contains the Fibre Channel switches that the controller
uses to communicate with the TS1130, TS1120 or 3592-J1A drives, the Ethernet router
through which the controller communicates with the Library Manager, and up to 12 IBM
TS1130, TS1120 or 3592-J1A Tape Drives. Additional drives, up to a total of 16 per TS1120
controller, can be connected in an adjacent 3494 D22 frame or 3494 L22 frame.

Table 3-4 on page 59 lists the frame capacities for drives and controllers.


Table 3-4 The 3494 maximum frame capacities for drives and controllers
Frame Number of drives and tape controllers

3494 Model L22 Up to four 3592 Tape Drives and no controller
Note:
If a Model L22 frame is installed with the adjacent frame feature FC4065,
FC4075, FC4085, or FC4086, up to four 3592 or TS1120 drives are supported
in the L22 frame.

3494 Model D22 Up to twelve 3592 Tape Drives and no controller
Note:
If a Model D22 frame is installed with the adjacent frame feature FC4065,
FC4075, FC4085, or FC4086, the maximum number of attached 3592 drives is
eight.

3494 Model D24 Up to eight 3592 Tape Drives and one 3592 Model J70 or 3590 Model A60
controller

3.2.6 IBM TotalStorage 3592 Model J70 Tape Controller
The Model J70 controller is the predecessor of the TS1120 Model C06. It has been withdrawn
from marketing, but existing installations can upgrade the microcode level of the J70 to
support tape data encryption when encryption-enabled TS1120 Tape Drives are attached.
See Figure 3-9.

The 3592 Model J70 controller supports TS1130, TS1120, 3592-J1A, and 3590 drives in a
3494 Tape Library and TS1130, TS1120 and 3592-J1A drives in a TS3500 library.

To use tape encryption, all tape drives behind the J70 must be TS1130 Model E06, TS1130
Model EU6 or TS1120 Model E05 drives, and in the system-managed (SMStape)
environment, intermixing encryption-enabled and non-encryption-enabled TS1120 Model E05
drives is not supported behind the same tape controller.

Figure 3-9 IBM 3592 Model J70 Tape Controller


3.3 IBM Virtualization Engine TS7700
The IBM System Storage Virtualization Engine TS7700 is a member of the IBM TS7000
Virtualization Family. It represents the fourth generation of IBM Tape Virtualization for
mainframe systems and replaced the highly successful IBM TotalStorage Virtual Tape Server
(VTS).

The TS7700 Virtualization Engine is designed to provide improved performance and capacity
to help lower the total cost of ownership for tape processing. It introduces a new modular,
scalable, high-performing architecture for mainframe tape virtualization. It integrates the
advanced performance, capacity, and data integrity design of the IBM TS1120 and IBM
TS1130 Tape Drives, with high-performance disk and a new advanced IBM System p server
to form a storage hierarchy managed by robust storage management firmware with extensive
self-management capabilities.

The two types of TS7700 at the time of this writing are the TS7720 and the TS7740. The
TS7720 is a disk-only virtual tape system with up to 70 TB of disk cache. Because it does not
attach to physical tape it does not take advantage of tape encryption. The TS7740 has up to
14 TB of disk cache and attaches to both IBM TS1120 or TS1130 Tape Drives.

The TS7700 Virtualization Engine integrates the following components into the virtual tape
solution:
One IBM Virtualization Engine TS7740 Server Model V06
One IBM Virtualization Engine TS7740 Cache Controller Model CC6
Up to three IBM Virtualization Engine TS7740 Cache Drawers Model CX6

Figure 3-10 shows the IBM Virtualization Engine TS7700 and a schematic layout of its
components.

Ethernet Router

Ethernet Router

IBM 3592 Tape Frame
Model F05

TS7740 Node
3957-V06

IO Drawer IO Drawer
Primary Secondary

TS7740 Cache Drawer
3956-CX6
TS7740 Cache Drawer
3956-CX6
TS7740 Cache Drawer
3956-CX6
TS7740 Cache Controller
3956-CC6

Figure 3-10 IBM Virtualization Engine TS7700


The TS7700 Virtualization Engine attaches to System z hosts through FICON connections,
either directly or through FICON directors. It supports back-end drives in a TS3500 or 3494
tape library. When the TS7700 attaches to a TS3500 library, an external library manager is no
longer required as of licensed internal code 8.5.0.xx

TS7700 characteristics
The TS7700 offers a new standards-based management interface and enhanced statistical
reporting, compared to the VTS.

Important characteristics of theTS7700 are summarized here:
The TS7700 Virtualization Engine utilizes outboard policy management to manage
physical volume pools, cache management to control selective dual copy, dual copy
across a grid network, and copy mode control.
The TS7740 Server provides host connections of up to four FICON channels and
connections to the tape library and tape drives for back-end tape processing.
A TS7700 with Grid Communication features can be interconnected with up to two other
TS7700s to provide peer-to-peer copy capability between Virtualization Engines for tape
using TCP/IP network connections.
The TS7740 Cache, comprised of the TS7740 Model CC6 and the TS7740 Model CX6,
provides from 1 TB to 14 TB of uncompressed tape volume cache (TVC) capacity.
Each TS7700 supports up to a maximum of 256 3490E virtual tape drives and up to
1,000,000 logical volumes, each with a maximum capacity of 1.2 GB to 12 GB (assuming
3:1 compression and using the 400 to 4000 MB volume sizes).
The TS7700 offers a new standards-based Management Interface (MI) and enhanced
statistical reporting, compared to the VTS.
On demand features for cache capacity and performance allow for a lower cost entry
configuration with the option to grow with minimal impact on operations.
The Copy Export Function allows for export of secondary copies of volumes for Disaster
Recovery purposes. The export operates on physical cartridge pools. The primary copy of
exported volumes stays resident in the TS7700.
The TS7700 supports the TS3500 and the 3494 tape libraries. When it attaches to a
TS3500 tape library, an external Library Manager is required.
You can attach from four to sixteen TS1130, TS1120 or 3592-J1A Tape Drives to a
TS7700. The drives can reside either in a TS3500 or a 3494 tape library. The TS7700 also
supports a mix of TS1130 and TS1120 or TS1120 and 3592-J1A drives. In a mixed
TS1120 and 3592-J1A configuration, the TS1120 drives run in J1A Emulation mode.
TS1120 drives running in J1A Emulation mode do not support encryption.
The TS7700 supports System-Managed Encryption. To utilize the encryption capability of
TS1120 and TS1130 drives, all drives attached to the TS7700 must be TS1130 or
encryption-enabled TS1120 drives.

The following operating systems support attachment of the TS7700 Virtualization Engine:
IBM z/OS V1.7 or later
IBM z/VM V5.1 or later
IBM z/VSE V3.1.2 or later
IBM z/TPF 1.1 or later
IBM TPF 4.1 or later

Earlier releases might support the basic functionality of the TS7700 Virtualization Engine.


For detailed information about the IBM Virtualization Engine TS7700, refer to IBM System
Storage Virtualization Engine TS7700, SG24-7312.

Encryption support
Encryption on the TS7700 is controlled on a storage pool basis. DFSMS Storage Group and
Management Class constructs are used to control the use of primary and secondary storage
pools for logical volumes, through mapping in the Library Manager, resulting in an indirect
form of encryption policy management. The storage pools, which were originally created for
the management of physical media, have been enhanced to include encryption
characteristics. You can set up storage pools for encryption through the TS7700
Management Interface (MI) and then direct primary and secondary copies of volumes to
these pools by using the Storage Group and Management Class constructs.

In z/OS, automatic class selection (ACS) routines assign Storage Group and Management
Class to volumes dynamically. In non-z/OS environments, you can set up encryption policies
by assigning Storage Group and Management Class statically to ranges of volume serials
using the Library Manager user interface.

Encryption key labels are assigned using the Management Interface on a per-storage-pool
basis. For more information, refer to:
IBM Virtualization Engine TS7700: Tape Virtualization for System z hosts, SG24-7312
IBM Virtualization Engine TS7700 Series Encryption Overview, which is available at:
ftp://ftp.software.ibm.com/storage/Encryption/Docs/TS7700_Encryption_Support_V11.pdf

3.4 IBM LTO Ultrium tape drives and libraries
In this section, we give an overview of LTO Ultrium tape drive and media technology and
describe IBM LTO Ultrium tape drives and automated tape libraries. We describe the
following products:
IBM System Storage TS2240 Tape Drive Express Model
IBM System Storage TS2340 Tape Drive Express Model
IBM System Storage TS1040 Tape Drive
IBM System Storage TS2900 Tape Autoloader

The System Storage TS3500 Tape Library also supports IBM LTO Ultrium tape drives, but it
is not exclusively an LTO tape library. It supports the installation of IBM LTO Ultrium, IBM
System Storage TS1120 Tape Drives and IBM System Storage TS1130 Tape Drives. Using
IBM TS1120 or IBM TS1130 Tape Drives, the TS3500 attaches not only to Open Systems,
but also to System z hosts. We discuss the TS3500 Tape Library in a separate section (3.6,
“IBM System Storage TS3500 Tape Library” on page 77).

Note: For the remainder of this book, we use the term LTO as a generic term for various
generations of the LTO Ultrium tape drives. We use LTO4 as a generic term for IBM LTO
Ultrium Generation 4 drives. These are the IBM System Storage TS2240 tape drive, IBM
System Storage TS2340 tape drive, the IBM System Storage TS1040 tape drive, the IBM
LTO Ultrium 4 tape drives installed in the System Storage TS2900 Autoloader, and the
System Storage TS3100, TS3200, and TS3310 tape libraries.


3.4.1 LTO overview
The LTO Program was formed in 1997 by IBM, Hewlett-Packard (HP), and Seagate. The
three companies, HP, IBM, and Quantum (the successor to Seagate), jointly oversee the
development and road map of Linear Tape-Open (LTO) technology.

The LTO technology objective was to establish new open-format specifications for high
capacity, high performance tape storage products for use in the midrange and network server
computing environments and to enable superior tape product options.

LTO program cooperation goes beyond the initial three companies. LTO format specifications
have been made available to all who want to participate through standard licensing
provisions. LTO program technology has attracted a number of other industry leaders, so that
LTO-specified products (tape drives and tape storage cartridges) will reach the market from
multiple manufacturers, not just the Technology Provider Companies. This is critical to
meeting an open market objective and is accomplished through open licensing of the
technology.

Cooperation is also evident in the LTO program requirement that all products produced by
licensees are technically certified annually. The primary objective of this certification is to help
determine whether LTO format cartridges will be interchangeable across drives produced by
different LTO Ultrium manufacturers. In other words, LTO compliant media from any vendor
can be read and written in LTO compliant drives from any vendor.

All three consortium members (IBM, HP, and Quantum) are shipping LTO Ultrium products,
and numerous other licensees are shipping hardware and media.

The Linear Tape-Open organization Web site is:
http://www.lto.org

For more information about LTO technology, refer to the IBM System Storage Tape Libraries
Guide for Open Systems, SG24-5946.

The IBM LTO Web site is:
http://www.ibm.com/storage/lto

The LTO Ultrium road map (Figure 3-11 on page 64) shows the evolution of LTO technology.
At the time of writing, IBM Ultrium generation 3 and 4 products are offered. The information in
the road map is given as an indication of future developments by the three consortium
members and is subject to change.


Generation Generation Generation Generation Generation Generation
1 2 3 4 5 6

Capacity
100 GB 200 GB 400 GB 800 GB 1.6 TB 3.2 TB
(Native)

Transfer
Up to Up to Up to Up to Up to Up to
Rate
20 MB/s 40 MB/s 80 MB/s 120 MB/s 180 MB/s 270 MB/s
(Native)

WORM No No Yes Yes Yes Yes

Encryption No No No Yes Yes Yes

Figure 3-11 LTO Ultrium road map

Important: Hewlett-Packard, IBM, and Quantum (the successor to Seagate) reserve the
right to change the information in this migration path without notice.

3.4.2 LTO media
Each generation of LTO Ultrium tape drives uses its own cartridge. LTO drives generally
provide backward read compatibility for the previous generations and read/write compatibility
for the previous generation. For example, LTO4 drives can read and write in LTO3 format on
LTO3 media. They can also read the LTO2 format from LTO2 media, but cannot write in
LTO2 format. The generations include:
LTO1 was the first generation of the LTO technology with an uncompressed tape capacity
of 100 GB per cartridge.
LTO2 is the second generation of the LTO technology with an uncompressed tape
capacity of 200 GB per cartridge.
LTO3 is the third generation of the LTO technology with an uncompressed tape capacity
of 400 GB per cartridge. A WORM (write-once, read-many) version of the LTO3 cartridge
is also available.
LTO4 is the fourth generation of the LTO technology with an uncompressed tape capacity
of 800 GB per cartridge. A WORM (write-once, read-many) version of the LTO4 cartridge
is also available. LTO4 is the first LTO generation that supports encryption. Encryption on
LTO drives requires the use of LTO4 media.

LTO cartridges are color-coded. The LTO Ultrium 1 data cartridge is black, the LTO Ultrium 2
data cartridge is purple, the LTO Ultrium 3 data cartridge is steel blue, and the LTO Ultrium 4
data cartridge is green. The third generation IBM WORM cartridge is a two-tone cartridge with
a steel-blue top and a platinum (silver) bottom and the fourth generation WORM is a two-tone
cartridge with a steel-green top and a platinum (silver) bottom.


WORM tape format
Beginning with LTO3, Write Once Read Many (WORM) functionality provides for
non-erasable, non-rewritable operation with tape media and is designed for long-term tamper
resistant record retention.

The IBM LTO3 specification for WORM includes the use of low-level encoding in the
Cartridge Memory (CM), which is also mastered into the servo pattern as part of the
manufacturing process. This encoding is designed to prevent tampering.

Data can be appended at the end of a WORM cartridge to which data was previously written,
allowing the full use of the high capacity tape media.

LTO3 WORM cartridges can be used with any LTO3 tape drive with the appropriate
microcode and firmware. LTO3 non-WORM and WORM cartridges can coexist in the same
library.

The same description holds for the LTO4 WORM cartridges. They can be used by any LTO4
Tape Drive and can coexist with non-WORM cartridges. Additionally, the LTO4 drive can read
and write WORM and non-WORM LTO3 cartridges.

Figure 3-12 shows IBM LTO3 and LTO4 media. The two-tone cartridges on the picture are
LTO3 WORM media.

Figure 3-12 IBM LTO Ultrium 3 and IBM LTO Ultrium 4 media

Labels
The LTO cartridge label uses the barcode symbology of USS-39. A description and definition
is available from the Automatic Identification Manufacturers (AIM) specification Uniform
Symbol Specification (USS-39) and the ANSI MH10.8M-1993 ANSI Barcode specification.

The barcode string consists of a start character, eight alphanumeric characters, and the stop
character. Quiet zones precede and follow the start and stop characters. The first six
characters can be any combination of uppercase A-Z or 0-9 (for example, ABC123) to identify
the cartridge volume. The last two characters are determined by the LTO cartridge media
type (that is, “L” for LTO and “1” for tape cartridge generation or drive manufacturer unique
identifier).

Note: No characters other than uppercase alpha A-Z or numeric 0-9 are allowed.

Human-readable characters are allowed provided that there is no conflict or interference with
the automation code. Users can specify the format, colors, and location of the
human-readable characters.


For optimal library performance make sure your labels adhere to the guidelines found in
Label Specification for IBM 3592 Cartridges when used in IBM Libraries, located at:
http://www.storage.ibm.com/media/tapecartridges/index.html

Under Enterprise storage media, select 3592 tape cartridges. Under Related information,
select Barcode Label Specification for use with 3592 Tape Media. Under Content, select the
.pdf file to access the document. You can also contact your IBM Marketing Representative for
this specification.

Figure 3-13 shows a barcode label for an LTO1 data cartridge.

Figure 3-13 LTO Ultrium 1 barcode label

3.4.3 IBM System Storage TS2240 Tape Drive Express Model
The IBM TS2240 Tape Drive is an external stand-alone or rack-mountable half high LTO4
drive. It is the entry point for the family of IBM LTO tape products and incorporates the latest
generation of LTO technology. The TS2240 is suited to handle the backup, save and restore,
and archival data storage needs of a wide range of small systems. See Figure 3-14 on
page 67.

IBM TS2240 increases the native data rate to up to 120 MBps. With the use of the LTO4 data
cartridge, it doubles the tape cartridge capacity to 800 GB uncompressed capacity (1600 GB
with 2:1 compression).

The IBM TS2240 Tape Drive uses a 3 Gbps Serial-Attached SCSI (SAS) interface for
connections to a wide spectrum of Open Systems servers. The TS2240 models attach to IBM
System p, IBM System i, IBM System x, Microsoft® Windows, HP-UX, Sun Solaris, UNIX,
and Linux servers.

The TS2240 is encryption-capable and supports Application-Managed Encryption on AIX,
Windows Server 2003, Linux, and Solaris. Encryption requires the latest device drivers, which
are available on the FTP download site:


Figure 3-14 IBM System Storage TS2240 Tape Drive Express Model

For more information about IBM TS2240 Tape Drive, see IBM System Storage Tape Library

3.4.4 IBM System Storage TS2340 Tape Drive Express Model
The IBM TS2340 Tape Drive is an external stand-alone or rack-mountable LTO4 drive. It is
the entry point for the family of IBM LTO tape products and incorporates the latest generation
of LTO technology. The TS2340 is suited to handle the backup, save and restore, and
archival data storage needs of a wide range of small systems. See Figure 3-15.

IBM TS2340 increases the native data rate to up to 120 MBps. With the use of the LTO4 data

The IBM TS2340 Tape Drive Model L43 uses a SCSI Ultra160 LVD attachment. The Model
S43 uses a 3 Gbps Serial-Attached SCSI (SAS) interface for connections to a wide spectrum
of Open Systems servers. The TS2340 models attach to IBM System p, IBM System i, IBM
System x, Microsoft Windows, HP-UX, Sun Solaris, UNIX, and Linux servers.

The TS2340 Model S43 with SAS interface is encryption-capable and supports
Application-Managed Encryption on AIX, Windows Server 2003, Linux, and Solaris.
Encryption requires the latest device drivers, which are available on the FTP download site:

Note: The IBM TS2340 Tape Drive is available as Model L43 with LVD/SCSI or as Model
S43 with SAS interface. Only SAS-attached TS2340 Tape Drives support encryption.

Figure 3-15 IBM System Storage TS2340 Tape Drive Express Model

For more information about IBM TS2340 Tape Drive, see IBM System Storage Tape Library


3.4.5 IBM System Storage TS1040 Tape Drive
The IBM System Storage TS1040 is the IBM LTO Ultrium 4 Tape Drive for installation in the
IBM TS3500 Tape Library. The drive mounts in the TS3500 Tape Library Models L53 or D53
and in previous Models L52, L32, D52, or D32.

The TS1040 increases the native data rate to up to 120 MBps. With the use of the LTO4 data
with 2:1 compression) in comparison to its predecessor, the TS1030 Tape Drive.

The drive includes a 4-Gbps Fibre Channel interface attachment.

The IBM TS1040 Tape Drive is encryption-capable and supports Library-Managed
Encryption (LME) and System-Managed Encryption (SME) on a variety of Open Systems
platforms. For a list of supported operating systems and host bus adapters (HBAs), refer to:

The TS1040 also supports Application-Managed Encryption (AME) on AIX, Windows Server
2003, Linux, Solaris, and HP-UX.

Figure 3-16 shows the IBM TS1040 Tape Drive.

Figure 3-16 IBM System Storage TS1040 Tape Drive

3.4.6 IBM System Storage TS2900 Tape Autoloader
The IBM TS2900 Tape Autoloader is a single drive entry level desktop or rack-mounted unit
(requiring one rack unit in an industry standard 19-inch rack). One half-high IBM LTO3 or
LTO4 drive may be mounted in the TS2900. The TS2900 is positioned between a standalone
tape drive and the TS3100 Tape Library. The TS2900 is well-suited to handle the backup,
save and restore, and archival data storage needs of small to medium-sized environments.
Up to nine cartridges may be mounted in the Autoloader at a time. See Figure 3-17.

Figure 3-17 IBM System Storage TS2900 Tape Autoloader


Encryption settings
The TS2900 supports Application-Managed Encryption by default when an LTO4 drive is
installed. An additional feature, Transparent LTO Encryption, is required for System-Managed
Encryption or Library-Managed Encryption. See Figure 3-18.

Figure 3-18 IBM TS2900 Tape Autoloader Encryption Settings

3.4.7 IBM System Storage TS3100 Tape Library
The IBM TS3100 Tape Library is a single or dual drive entry level desktop or rack-mounted
unit (requiring two rack units in an industry standard 19 inch rack). It is the entry point for the
family of IBM LTO tape library products and incorporates the latest generation of LTO
technology. The TS3100 is well-suited to handle the backup, save and restore, and archival
data storage needs of small to medium-sized environments. See Figure 3-21 on page 72.

The TS3100 supports either one IBM LTO3 full-high tape drive with a native capacity of
400 GB, two IBM LTO3 half-high tape drives with a native capacity of 400 GB, one IBM LTO4
Tape Drive with a native capacity of 800 GB, or up to two IBM LTO4 half-high tape drives with
a native capacity of 800 GB. The IBM LTO4 Tape Drives are available with Fibre Channel
(FC), 3 Gbps Serial Attached SCSI (SAS), or SCSI Ultra160 LVD attachment interface.

Note: Half High drives do not have Fibre Channel attachment. The TS3100 can be ordered
with LTO3 drives with LVD/SCSI or FC interface or with LTO4 drives with LVD/SCSI, SAS,
or FC interface. Only LTO4 drives with Fibre Channel or SAS attachment interface support
encryption.

A total of 24 cartridges can be stored in two removable magazines (23 cartridges with I/O
Station enabled). A single dedicated mail slot (I/O Station) is available for importing and
exporting cartridges. Using LTO4 cartridges, the library has an uncompressed capacity of
19.2 TB (38.4 TB with 2:1 compression).

The barcode reader and the remote management unit (RMU) are standard features. The
RMU provides an Ethernet port so that the library can be configured as a TCP/IP device in the
network. Library status can be sent to the network as Simple Network Management Protocol
(SNMP) traps. The IBM System Storage Tape Library Specialist enables network access
through a Web browser. You can access all library Operator Panel functions using the Tape
Library Specialist. The Specialist also provides the ability to configure logical libraries up to


the number of tape drives, providing a maximum capability of two logical libraries for the
TS3100 with two half-high drives.

The TS3100 Tape Library attaches to IBM System p, IBM System i, IBM System x, Microsoft
Windows, HP-UX, Sun Solaris, UNIX, and Linux servers.

The IBM TS3100 supports Library-Managed Encryption, System-Managed Encryption, and
Application-Managed Encryption on SAS and Fibre Channel LTO4 drives using LTO4 media.
Not all environments support all three encryption methods. For details about platform-specific
support, refer to Chapter 4, “Planning for software and hardware” on page 91.

Three policy settings are available for Library-Managed Encryption on a TS3100:
Encrypt All
All cartridges in the library will be encrypted.
Internal Label - Selective Encryption
The LTO4 drive automatically derives the encryption policy and key information from the
metadata written on the tape volume by the application. NetBackup is currently the only
backup software that supports these Internal Label Encryption Policies (ILEP).
Internal Label - Encrypt All
backup software that supports these Internal Label Encryption Policies (ILEP).

You set these policies through the Web interface.

Figure 3-19 IBM System Storage TS3100 Tape Library Express Model

For more information about IBM TS3100 Tape Library, refer to IBM System Storage Tape
Libraries Guide for Open Systems, SG24-5946.

The IBM TS3200 Tape Library is a midrange desktop or a rack-mounted unit (requiring four
rack units in an industry standard 19-inch rack).

The TS3200 supports either two IBM LTO3 full-high tape drives with a native capacity of
400 GB, four IBM LTO3 half-high tape drives with a native capacity of 400 GB, two IBM LTO4
tape drives with a native capacity of 800 GB, four IBM LTO4 half-high tape drives with a
native capacity of 800 GB, or a mix of IBM LTO3 and LTO4 full-high tape drives. The IBM
LTO4 tape drives are available with Fibre Channel, 3 Gbps Serial Attached SCSI (SAS), or
SCSI Ultra160 LVD attachment interface.


Note: Half High drives do not have Fibre Channel attachment. The TS3200 can be ordered
with LTO3 drives with LVD/SCSI or FC interface or with LTO4 drives with LVD/SCSI, SAS,
or FC interface. Only LTO4 drives with Fibre Channel or SAS attachment interface support
encryption.

A total of 48 cartridges (45 with I/O Station enabled) can be stored in four removable
magazines. Using LTO4 cartridges, the library has an uncompressed capacity of 38.4 TB
(76.8 TB with 2:1 compression). A three-cartridge I/O Station is available for importing and
exporting cartridges.

The barcode reader and the remote management unit (RMU) are standard features. The
RMU provides an Ethernet port so that the library can be configured as a TCP/IP device in the
network. Library status can be sent to the network as Simple Network Management Protocol
(SNMP) traps. The IBM System Storage Tape Library Specialist enables network access
through a Web browser. You can access all library operator panel functions by using the
Tape Library Specialist. The Specialist also provides the ability to configure logical libraries
up to the number of tape drives, providing a maximum capability of four logical libraries for the
TS3200 with four half-high drives.

The IBM TS3200 tape library attaches to IBM System p, IBM System i, IBM System x,
Microsoft Windows, HP-UX, Sun Solaris, UNIX, and Linux servers.

The IBM TS3200 supports Library-Managed Encryption, System-Managed Encryption, and
Application-Managed Encryption on SAS and Fibre Channel LTO4 drives using LTO4 media.
See Figure 3-20.

Figure 3-20 IBM System Storage TS3200 Tape Library Express Model

Encrypt All
All cartridges in the library will be encrypted. If you have two or more drives and partition
the library into two logical libraries, you can set separate encryption policies for the two
logical libraries.
backup software that supports Internal Label Encryption Policies (ILEP).

You set these policies through the Web interface, as shown in Figure 3-21 on page 72.


Figure 3-21 Sample TS3200 Encryption configuration panel

Not all environments support all three encryption methods. For details about platform-specific
support, refer to Chapter 4, “Planning for software and hardware” on page 91.

For more information about IBM TS3200 Tape Library, refer to the IBM System Storage Tape

The IBM TS3310 Tape Library is a modular, highly scalable IBM LTO library. It is designed to
address the tape requirements of companies with rapid data growth. The TS3310 expands
vertically when you add expansion modules.

The IBM TS3310 Tape Library offers a broad range of configuration options. The smallest
configuration includes a base unit model L5B with one or two tape drives, either IBM LTO3,
LTO4, or a mix of LTO3 and LTO4, 30 storage slots, and six I/O slots. The base library
module contains all of the necessary robotics and intelligence to manage the library system.
You can order the base models either as a deskside unit or for installation in an industry
standard 19-inch rack, where it requires four rack units.


As your need for tape backup expands, you can add up to four expansion modules TS3310
Model E9U to the base configuration. Each of these modules is nine rack-units high and adds
space for cartridges and tape drives to your TS3310 configuration. Configurations with more
than one expansion module require a rack for installation.

A fully configured rack-mounted library is 41 rack-units high and offers space for up to 18 LTO
drives and 396 cartridges. You can configure up to 54 I/O slots in this configuration. Using
LTO4 drives and LTO4 media results in an uncompressed capacity of 316.8 TB (633.6 TB

The IBM TS3310 Tape Library provides the ability to configure the number of logical libraries
up to the number of tape drives, which provides a maximum capability of 18 logical libraries
for the IBM TS3310.

Available as a standard feature, a Remote Management Unit (RMU) provides an Ethernet
port so that the library can be configured as a TCP/IP device in the network. Library status
can be sent to the network as Simple Network Management Protocol (SNMP) traps. The
TS3310 also supports an embedded SMI-S agent for monitoring the library using tools like
TotalStorage Productivity Center. The IBM System Storage Tape Library Specialist enables
network access (with a Web browser) to the library for more detailed status and for updating
the firmware of the library. All library Operator Panel functions can be accessed using the IBM
System Storage Tape Library Specialist.

The TS3310 tape library attaches to IBM System p, IBM System i, IBM System x, Microsoft
Windows, HP-UX, Sun Solaris, UNIX, and Linux servers.

The IBM TS3310 supports Application-Managed Encryption (AME), System-Managed
Encryption (SME) and Library-Managed Encryption (LME) on SAS and Fibre Channel LTO4
drives using LTO4 media.

Encrypt All
All cartridges in a non-partitioned TS3310 library will be encrypted. If you have partitioned
a TS3310 library into two or more logical libraries, you can set the encryption policy
separately for each logical library.

You set these policies through the Web interface.


Figure 3-22 TS3310 Encryption configuration interface

Not all environments support all of these three encryption methods. For details on
platform-specific support, refer to Chapter 4, “Planning for software and hardware” on
page 91.

For more information about IBM TS3310 Tape Library, refer to IBM System Storage Tape

Figure 3-23 on page 75 shows a TS3310 configuration with the base unit model L5B and one
expansion unit model E9U.


Figure 3-23 IBM System Storage TS3310 Tape Library

3.5 IBM System Storage TS3400 Tape Library
The IBM System Storage TS3400 Tape Library is designed to offer high performance drive
technology and automation in Open Systems and System z environments. The TS3400 is a
five unit external desktop or rack-mountable tape library that supports up to two IBM System
Storage TS1120 Tape Drives or IBM System Storage TS1130 Tape Drives. The library does
not support the predecessor of the TS1120, the IBM 3592 Model J1A Tape Drive.

The TS3400 is an excellent tape storage solution for organizations already using TS1130 or
TS1120 Tape Drives in their data centers that want to use the same technology in remote
locations. The TS3400 is also designed for organizations that have limited physical space in
their IT environments. Installed in a standard 19-inch rack, it provides up to 18 TB of
uncompressed tape storage in a 5U space. Figure 3-24 shows the IBM TS3400 Tape Library.

Figure 3-24 IBM System Storage TS3400 Tape Library

Characteristics
The TS3400 supports one or two IBM TS1130 or IBM TS1120 Tape Drives. It has two
removable cartridge magazines providing 18 data cartridge slots, including a three slot I/O
Station. You can configure the slots of the I/O Station either as normal cartridge slots or as
I/O slots. The total native storage capacity is 18 TB when using the 1000 GB data cartridges
and all 18 slots are configured as slots for data cartridges.


IBM multipath architecture allows for partitioning of the TS3400 when two IBM System
Storage TS1120 or TS1130 Tape drives are installed. You can partition the library into two
partitions to share it between different applications.

The TS3400 attaches through the Fibre Channel ports of the IBM TS1120 or TS1130 Tape
Drives to Open Systems hosts or to an ESCON/FICON tape controller in a System z
environment. Each TS1120 or TS1130 has two independent 4 Gbps switched fabric Fibre
Channel ports.

Remote management through a Web browser allows you to communicate directly with the
library and perform a wide range of user, operator, and administrator tasks without being at
the operator panel.

System z attachment requires an IBM TS1120 Tape Controller (refer to 3.2, “IBM System
Storage TS1120 Tape Controller” on page 53). Up to seven TS3400 tape libraries with a
maximum of 14 TS1120 or TS1130 drives can attach to a single TS1120 Model C06. Up to
four IBM TS1120 or TS1130 Tape Drives can be direct-attached to the IBM TS1120 Tape
Controller without the use of an external switch.

When the TS3400 attaches to an IBM TS1120 Tape Controller, you can choose between
System Mode and Auto Mode. In System Mode, cartridges are fed to the drive one after the
other under the attaching system’s command, which continues until all storage cells are
processed. Currently, only z/OS supports System Mode. In Auto Mode, the TS3400 acts like
an autoloader, and cartridges are automatically fed into the drive one after another until all
storage cells are processed.

Both the TS3400 libraries and the IBM TS1120 Tape Controller must be rack-installed.
TS1120 or TS1130Tape Drives attached to an IBM TS1120 Tape Controller cannot be
shared with Open Systems hosts. If a TS3400 attaches to an IBM TS1120 Tape Controller, all
drives attached to this controller must reside in a TS3400 library. You cannot share an IBM
TS1120 Tape Controller between drives in a TS3400 and rack-mounted drives or drives in a
TS3500 or 3494 tape library.

Standard features and capabilities of the IBM System Storage TS3400 Tape Library are
summarized in the following list:
Control path and data path failover
Two removable cartridge magazines with nine slots each
Configurable three slot I/O Station
Barcode reader
Dual power supplies
Remote management unit
Open Systems and System z attachment
Sequential or random access mode selectable for Open Systems-attached library
System Mode or Auto Mode selectable for System z-attached library
Support for tape encryption

Supported platforms
Support for the TS3400 library is provided on z/OS 1.6 or later, z/VM V5.2.0 or later, z/VSE
V3.1.2 or later, and z/TPF V1.1 or later. The z/VM, z/VSE, and z/TPF support the TS3400 as
an autoloader in Auto Mode. You might require later operating system versions to support
tape encryption. Refer to Chapter 4, “Planning for software and hardware” on page 91.

A wide variety of Open Systems platforms supports the IBM TS3400 Tape Library. For
additional information, refer to the System Storage Interoperation Center (SSIC):
http://www.ibm.com/systems/support/storage/config/ssic/


Encryption support
The IBM System Storage TS3400 Tape Library supports the IBM System Storage TS1120 or
TS1130 Tape Drive built-in encryption capabilities. The TS3400 Tape Library supports
Library-Managed Encryption (LME), System-Managed Encryption (SME), and
Application-Managed Encryption (AME).

Encrypt All
All cartridges in a non-partitioned TS3400 library will be encrypted. If you have partitioned
a TS3400 library into two logical libraries, you can set the policy separately for each logical
library.
Internal Label -Selective Encryption
The IBM TS1120 or TS1130 Tape Drive automatically derives the encryption policy and
key information from the metadata written on the tape volume by the application.
NetBackup is currently the only backup software that supports Internal Label Encryption
Policies (ILEP).
The IBM TS1120 or TS1130 Tape Drive automatically derives the encryption policy and
key information from the metadata written on the tape volume by the application.
NetBackup is currently the only backup software that supports Internal Label Encryption
Policies (ILEP).

In a System z environment, SME is the only option. You set the policies through the Web
interface.

3.6 IBM System Storage TS3500 Tape Library
The IBM TS3500 Tape Library (machine type 3584) is designed for medium to large
automated tape storage and backup solutions and is part of a whole family of tape libraries for
small to large automated tape storage and backup solutions. Originally delivered in 2000 at
the same time as Linear Tape Open (LTO) Ultrium technology, the TS3500 offers a robust
enterprise library solution available for midrange and high-end Open Systems. Since its
introduction, the library has been enhanced to accommodate different drive types and
operating platforms, more recently including the attachment of System z (mainframe) hosts
and tape controllers. Combining reliable, automated tape handling and storage with reliable,
high-performance IBM TS1130, TS1120 drives and LTO tape, the IBM TS3500 Tape Library
offers outstanding retrieval performance with typical cartridge move times of less than three
seconds.

The IBM TS3500 Tape Library can be partitioned into multiple logical libraries, making it an
excellent choice for consolidating tape workloads from multiple heterogeneous Open
Systems servers, and enables the support for System z attachment in the same library.

In addition, the IBM TS3500 Tape Library provides outstanding reliability and redundancy
through the provision of redundant power supplies in each frame, an optional second
cartridge accessor, control and data path failover, and dual grippers within each cartridge
accessor. Both library and drive firmware can now be upgraded nondisruptively, that is,
without interrupting the normal operations of the library.

Figure 3-25 on page 78 show the maximum configuration of 16 frames and the minimum
configuration of one frame of an IBM TS3500 Tape Library, which can contain from one to 192


TS1130, TS1120, or LTO Tape Drives; and from 58 to 6,260 (frames for TS1120, or TS1130
only) or 6,887 (frames for LTO only) cartridge storage cells.

Figure 3-25 Maximum and minimum IBM TS3500 Tape Library configuration

The IBM TS3500 Tape Library provides:
Modular, scalable, automated tape library, combining IBM tape and automation for Open
Systems and mainframe hosts, using a variety of IBM drive types
Attachment to IBM System z, System i, iSeries, AS/400, System p, pSeries, RS/6000, IBM
System x, Netfinity, Sun, Hewlett-Packard, and other IBM servers (that are not IBM)
Connectivity using FICON, ESCON, Fibre Channel, Low Voltage Differential (LVD) SCSI,
and High Voltage Differential (HVD) SCSI
IBM Multipath Architecture designed to support redundant control paths, mixed drive
configurations, and library sharing between multiple applications
Tape data encryption

3.6.1 TS3500 frames
Seven different frames are currently available to build an IBM TS3500 Tape Library. Each
frame is identified by a three character model number (L23, L53, D23, D53, S24™, S54, or
HA1) that describes the nature of the frame. Libraries are built of modules, as follows:
Each library requires a base frame (model Lxx) to which optional expansion frames
(model Dxx or Sxx) can be added. Only one base frame is permitted in each library
configuration.
Base and expansion Dxx frames support one of either:
– LTO drives (model x53)
– 3592 drives, 3592-J1A, TS1120 and TS1130 (model x23)
Storage frames (model Sxx) do not support drives but do support higher cartridge density.
Optional second accessor is made available through the addition of model HA1 frames.

All currently available frame models can be intermixed with each other and installed frame
models with the provision that there is only one base frame in each library. Installed frame
models include the L22, L32, L52, D22, D32, and D52.

A mix of 3592 and LTO drives within one library is supported, because frames for 3592 and
LTO drives can be mixed. TS3500 frames are dedicated to either 3592 or to LTO. Therefore,
you cannot mix these drive types in a single frame.


The following sections introduce the available frame models.

IBM System Storage TS3500 Model L23 frame for TS1120 or TS1130
The L23 frame can be installed on its own as a complete library enclosure or up to 15 model
D23s or D53s can be attached to it. The L23 frame provides the major library components for
the whole library, whether the library consists of a single frame or multiple frames. Expansion
frames must be added to the right of the L23 frame. In addition, model S24 or S54 storage
only frames may be attached.

The L23 frame provides cartridge slots for 3592 media and support for up to twelve IBM
TS1130, TS1120, or 3592-J1A (collectively referred to as 3592) Tape Drives. The number of
available 3592 cartridge storage slots ranges from 58 to 260. The minimum configuration
provides 58 slots available for actual use, although all 260 slots are already physically
installed. You can enable additional slots for use (up to the total of 260) by ordering Capacity
On Demand features. The Intermediate Capacity feature gives you a total of 117 usable
cartridge slots. This Intermediate Capacity feature is required to add a Full Capacity feature,
which gives you the capacity of 260 cartridge slots. The Full Capacity feature is required to
add an I/O slot feature or to attach the optional expansion frame models D23 or D53.

You can install a maximum of twelve 3592 drives in an L23 frame. If you install additional
drives in an L23 frame, the fifth and the ninth drive reduce the number of available cartridge
slots.

Note: ALMS is Required when installing the TS1130 Tape Drive in a TS3500 tape library.

Each L23 has a standard 16-slot 3592 cartridge I/O Station for convenient importing
cartridges into the library or exporting cartridges from the library. Optionally, you can order 16
additional I/O slots for 3592 or LTO media if the library contains frames with LTO drives.
Additional I/O slots reduce the number of available cartridge slots.

IBM System Storage TS3500 Model D23 frame for TS1130
The D23 frame is an expansion frame and cannot be installed on its own. It must be
connected to a L23 or L53 frame and optionally to other expansion frames.

The D23 frame offers space for a maximum of 400 3592 media. Up to 12 TS1130, TS1120 or
3592-J1A (collectively referred to as 3592) drives can be installed in this frame. If one or more
tape drives are installed in the D23, the Enhanced Frame Control Assembly feature is also
required. This feature provides the hardware and firmware required to support IBM 3592
drives within the D23 and provides a redundant line feed for the L23 or L53 accessor.

The installation of the first, fifth, and ninth 3592 drive reduces the number of available
cartridge slots.

Note: ALMS is Required when installing the TS1130 Tape Drive in a TS3500 tape library.

In a library with 3592 drives only, you can order an additional 64 slot I/O Station for 3592
media for the D23 frame. The additional I/O Station reduces the number of available cartridge
slots.

IBM System Storage TS3500 Model S24 frame for TS1130
The S24 frame is an expansion frame and cannot be installed on its own. It must be


The S24 frame offers space for a maximum of 1000 3592 media. By default it comes with
space for 600 3592 cartridges. The ALMS feature is required to support the S24 frame. The
High Density Capacity On Demand feature is required to unlock access to the remaining 400
slots.

IBM System Storage TS3500 Model L53 frame for LTO
The L53 frame provides cartridge slots for LTO media and supports up to 12 LTO4 or LTO3
4 Gbps Fibre Channel tape drives.

The number of available LTO cartridge storage slots ranges from 64 to 287. The minimum
configuration provides 64 slots available for actual use, although all 287 slots are already
physically installed. You can enable additional slots for use (up to the total of 287) by ordering
Capacity on Demand features. The Intermediate Capacity feature gives you a total of 129
usable cartridge slots. This Intermediate Capacity feature is required in order to add a Full
Capacity feature, which gives you the capacity of 287 cartridge slots. The Full Capacity
feature is required to add an I/O Slot feature or to attach the optional expansion frame models
D23 or D53. In addition, models S24 or S54 storage-only frames may be attached if the
ALMS feature is installed.

You can install a maximum of 12 LTO drives in an L53 frame. If you install additional drives in
an L53 frame, the fifth and the ninth drive reduce the number of available cartridge slots.

Each L23 has a standard 16-slot 3592 cartridge I/O Station for conveniently importing
cartridges into the library or exporting cartridges from the library. Optionally, you can order 16
additional I/O slots for LTO media or 3592 media if the library contains frames with 3592,
TS1120 or TS1130 drives. Additional I/O slots reduce the number of available cartridge slots.

IBM System Storage TS3500 Model D53 frame for LTO
The D53 frame is an expansion frame and cannot be installed on its own. It must be

The D53 frame offers space for a maximum of 440 LTO media. Up to 12 TS1030 or TS1040
LTO 4 Gbps Fibre Channel tape drives can be installed in this frame. If one or more tape
drives are installed in the D53, the Enhanced Frame Control Assembly feature is also
required. This feature provides the hardware and firmware required to support IBM LTO
drives within the D53 and provides a redundant line feed for the L23 or L53 accessor.

The installation of the first, fifth, and ninth LTO drive reduces the number of available
cartridge slots.

In a library with LTO drives only, you may order an additional 64 slot I/O Station for LTO
media for the D23 frame. The additional I/O Station reduces the number of available cartridge
slots.

IBM System Storage TS3500 Model S54 frame for LTO
The S54 frame is an expansion frame and cannot be installed on its own. It must be

The S54 frame offers space for a maximum of 1320 LTO media. By default it comes with
space for 660 LTO cartridges.The ALMS feature is required to support the S54 frame. The
High Density Capacity on Demand feature is required to unlock access to the remaining 660
slots.


IBM System Storage Model HA1 Frame
The TS3500 HA1 frame adds a second accessor to a TS3500 tape library in a high
availability configuration. The HA1 frame is installed left of the TS3500 Model Lxx frame
and acts as a service bay for the left accessor. A high availability configuration with an HA1
frame requires a driveless TS3500 Model Dxx expansion frame as the rightmost frame in this
configuration. This expansion frame acts as the service bay for the right accessor.

In the following sections, we describe:
Advanced Library Management System (ALMS)
Logical library partitions
System z attachment through 3953 Library Manager
Path failover
TS3500 Tape Library Specialist
High Density Frames
Encryption support

Advanced Library Management System
The Advanced Library Management System (ALMS), which is an optional extension in
existing libraries and required for new installs, to the IBM patented Multipath Architecture
(FC1690), provides enhanced flexibility and capabilities for partitioning the IBM TS3500 Tape
Library. The Advanced Library Management System (ALMS) virtualizes the SCSI element
addresses while maintaining the approach of the multipath architecture and using SCSI
Medium Changer commands. Without ALMS, everything is based on the SCSI element
address (location-centric) and partitioning is based on real cartridge slots and drive slots.
With ALMS, there is no affinity between a real slot address and a SCSI element address
reported to the server and used by the server. Instead, there is now an affinity with the
VOLSER (volume serial numbers on the barcode label of the cartridge).

With ALMS, the TS3500 virtualizes the location of cartridges (called SCSI element addresses).
Without ALMS, the Storage Element Address maps directly to a specific storage slot after the
library is configured. With ALMS enabled, each Storage Element Address is no longer
associated with a specific storage slot. Instead, storage slots are virtualized by dynamically
associating element addresses to them as required. An element address is associated to a
storage slot selected by the library as cartridges are moved and inventoried. If a Storage
Element is empty because of a move, that source element address becomes unassociated.

Capabilities of ALMS include:
Dynamic partitioning (storage slot pooling and flexible drive assignment)
Flexible drive assignment
Sharing of the physical cartridge slots by logical partitions
Ability to add or remove storage capacity with minimal or no disruption to host applications
The ability to configure drive or L frame storage capacity without taking the library offline
Virtual I/O slots to automatically manage the movement of cartridges between I/O slots
and storage slots
Cartridge Assignment Policy (CAP)
Tape System Reporter
Native SMI-S Support


The IBM TS3500 Tape Library is compliant with the SCSI Medium Changer standard whether
ALMS is enabled or not; when enabled, ALMS is completely transparent to the application.
The SCSI Medium Changer can be thought of as a location-centric interface. The application
controlling a SCSI Medium Changer device specifies a source and a destination location for
each request to move a cartridge. The traditional SCSI library does not have control of the
cartridge locations; instead, the SCSI library just acts on behalf of the server.

IBM Tape System Reporter is a windows application that monitors multiple TS3500 libraries
and allows report generation. It also tracks history for cartridges and drives in the library
allowing you to monitor tape and drive encryption over time. For more information refer to IBM
System Storage TS3500 Tape Library with ALMS Tape System Reporter User’s Guide
(GA32-0589)

ALMS is an optional feature for existing IBM TS3500 Tape Libraries; however, it is a
mandatory feature for new installs, when the library when you attach the library to a System z
server or when you install the IBM 3584 Model HA1.

Note: Though ALMS is not an absolute requirement for encryption, we strongly
recommend that you order ALMS.

Logical library partitions in a TS3500
The Multipath Architecture of the IBM TS3500 Tape Library provides the capability for sharing
library robotics by partitioning the library into logical partitions. A single IBM TS3500 Tape
Library can have Open Systems-attached partitions and System z-attached partitions, but
logical partitioning differs between Open Systems environments and System z environments.

Logical library partitions in an Open Systems environment
In an Open Systems environment, you can partition the library into as many logical partitions
as there are drives installed, that is, up to a maximum of 192 logical libraries. Each logical
library has its own separate and distinct drives, storage slots, and control paths. I/O slots are
shared on a first-come-first-served basis. The ALMS Virtual I/O function can be used to
manage sharing the I/O station. All logical libraries share the robotics of the TS3500 library.
The virtualization of the library accessor allows homogeneous and heterogeneous servers
and applications to share the library robotics independently of each other. Drives can be
shared between logical library partitions in an Open Systems environment. Cartridges are not
shared among logical libraries.

Logical library partitions in a System z environment
For System z attachment, the configuration rules for logical partitioning are different from
those for Open Systems hosts. System z-attached TS1130, TS1120 or 3592-J1A drives in a
TS3500 require an external 3953 Library Manager. This 3953 Library Manager controls a
separate logical library partition (with its own separate and distinct drives, storage slots, and
control paths) in the IBM TS3500 Tape Library. Up to four 3953 Library Managers can attach
to a TS3500, but each Library Manager requires a separate logical library partition of its own.

Note: When using TS7740 licensed internal code 8.5.0.xx and later a separate 3593
Library Manager is no longer required to attach to a TS3500 to a TS7740. This function is
integrated into the TS7740.

Each one of these 3953 logical Library Manager partitions can have up to three logical
libraries defined to it (identical to logical libraries of a 3494), two of which can be TS7700
Virtualization Engines or VTSs. The 3953 Library Manager supports the configuration of 16
subsystems per 3953 tape system. A subsystem is a TS7700 Virtualization Engine, a Virtual


Tape Server (VTS), or a TS1120 Model C06 or 3592 Model J70 controller. If two virtual
systems are defined, the remaining 14 subsystems can be 14 TS1120-C06 or 3592-J70 tape
controllers dedicated to native drive attachment (native library).

This configuration of logical Library Manager partitions and further subsystem attachment
allows a TS3500 Tape Library that is fully configured with four 3953 tape systems to house up
to eight TS7700 Virtualization Engines. With the latest version of the TS7700 a separate 3953
is no longer required as the library manger function is now part of the TS7700.

Figure 3-26 illustrates the attachment of a TS3500 library to System z hosts. The illustration
shows all of the drives belonging to a logical library in contiguous positions in the physical
library. This configuration is not a requirement. You can distribute the drives of a logical
library across several frames. In fact, drives belonging to a Library Manager-attached logical
library can share the same frame with drives belonging to an Open Systems partition.

System z System z
Host Host
LAN
Switch
ESCON FICON
FICON

Library TS1120 TS7700
Manager Model C06
Library Manager

Library Manager Complex
FC Switch (Redundant) FC Switch (Redundant)

Open
Systems
Host

Fibre Channel

Logical Library Logical Library Logical Library

Figure 3-26 TS3500 attached to System z

System z attachment with IBM 3953 Tape System
To attach System z to the IBM System Storage TS3500 Tape Library, a number of specific
hardware elements are required. Here is a summary of equipment that is either required or
installed according to client system requirements:
IBM TotalStorage 3953 Tape Frame Model F05
This is a special frame, which is independent of the TS3500 library, that is used to house
the Library Manager, switches, and controllers for mainframe-attached tape. It has:
– TS3000 System Console
– Keyboard-Video-Mouse (KVM) switch
– Ethernet switches for the internal communications between the Library Manager, tape
controllers, IBM TS7700, and the TSSC
IBM TotalStorage 3953 Library Manager Model L05
IBM TS3500 Models L23 and D23 frames


IBM TS1130, TS1120 or 3592-J1A Tape Drives

Note: IBM 3592-J1A Tape Drives are not encryption-capable; you must have TS1130
or TS1120 Tape Drives to use tape encryption.

IBM TS7700 Virtualization Engine or 3494 Virtual Tape Server models B10 or B20

Note: When using TS7740 licensed internal code 8.5.0.xx and later a separate 3593
Library Manager is no longer required to attach to a TS3500 to a TS7740. This function
is integrated into the TS7740

IBM System Storage TS1120 Model C06 or 3592 Model J70 tape controller
Fibre Channel switches to attach the IBM 3592 Tape Drives to the controllers

For detailed information about the IBM 3953 Tape System, refer to the IBM TS3500 Tape
Library with System z Attachment: A Practical Guide to TS1120 Tape Drives and TS3500
Tape Automation, SG24-6789.

Control path failover and data path failover
The TS3500 supports control path failover (CPF) and data path failover (DPF). The optional
path failover feature includes both CPF and DPF.

Control path failover
In the TS3500 Tape Library, a control path is a logical path into the library, which uses the
physical channel path to the tape drives, through which a server sends SCSI move medium
commands to control the logical library. The control path is set up as Logical Unit Number
(LUN) 1 on a drive; LUN 0 addresses the server-attached drive.

Alternate path support, which is currently available for AIX, Linux, Solaris, HP-UX, and
Windows hosts, configures multiple physical control paths to the same logical library within
the device driver and provides automatic failover to an alternate control path when a
permanent error occurs on one path. This is transparent to the running application.

Note: Best practice is to have control path drives in different library frames for increased
redundancy. See Figure 3-27 on page 85.


Li b r a r y
CON TR OLLER

DRIVE
Server
1

FC
DRIVE adapter
2

smc0
DRIVE
3
smc1
DRIVE
4

DRIVE
5

DRIVE
6

Two control paths
enabled

Figure 3-27 Redundant control paths to the library controller

Data path failover
Data path failover and load balancing exclusively support native Fibre Channel Ultrium and
IBM TS1130, TS1120 or 3592-J1A Tape Drives in the IBM TS3500 Tape Library using the
IBM device driver. Data path failover is supported for AIX, Linux, HP, Solaris, and Windows
hosts. Load balancing is supported for AIX, HP-UX, Linux, Solaris, and Windows.

Refer to the IBM Tape Device Driver Installation and User’s Guide, GC27-2130, for current
support and implementation details.

Data path failover provides a failover mechanism in the IBM device driver so that you can
configure multiple redundant paths in a SAN environment. If a path or component fails, the
failover mechanism will automatically retry the current operation using an alternate,
preconfigured path without stopping the current job in progress. When accessing a tape drive
device that has been configured with alternate pathing across multiple host ports, the IBM
device driver automatically selects a path through the HBA that has the fewest open tape
devices and assigns that path to the application. This autonomic self-optimizing capability is
called load balancing.

Data path failover and load balancing support for AIX or for IBM 3592 Tape Drives do not
require the Path Failover feature.

IBM TS3500 Tape Library Specialist
The IBM TS3500 Tape Library’s Web interface, which is also known as the IBM TotalStorage
UltraScalable Tape Library Specialist, enables operators and administrators to manage
storage devices from any location in an enterprise. The IBM TS3500 Tape Library Specialist
enables direct communication with an IBM TS3500 Tape Library and provides a full range of
user, operator, and administrator tasks, which can be executed remotely. For programmatic
remote access to the tape library the TS3500 includes Storage Management
Interface-Specification (SMI-S) support. Monitor or superuser role is required to access the
SMI-S interface.


Firmware for the library and drives can be updated nondisruptively using the Web user
interface.

Individual Web login IDs and passwords
For the IBM TS3500 Tape Library, the Web user interface (UI) supports a list of users who
can access various areas of the Web user interface. An administrator can create up to
nineteen additional user IDs. Each user has a 30-character name, a 15-character login ID, a
15-character password, and an access level. The access level defines the level of Web
access that the user is allowed.

Four access levels are available:
Monitor Can view all physical and logical library data.
Service Can perform only service-related functions, such as update firmware,
download logs, and view vital product data (VPD).
Superuser Can perform all tasks of a monitor or service role, plus change library
settings and perform library operations. This role cannot change the
passwords of other users or enable or disable security.
Administrator Can perform all user management tasks.

High-density frames
The IBM TS3500 now supports high density frames this allows more cartridges to be stored
inside the library in the same physical footprint in the data center. The ALMS feature is
required to add HD frames to your TS3500

HD slots contain tape cartridges in a tiered architecture. The cartridge immediately accessible
in the HD slot is a Tier 1 cartridge. Behind that is Tier 2 and so on. The maximum tier in an
LTO Ultirum (Model S54) HD slot is Tier 5. The maximum tier in a 3592 (Model S24) HD slot
is Tier 4 because the 3592 tape cartridge is slightly longer than the LTO cartridge. The
single-deep slots on the door-side of HD frames are referred to as Tier 0 slots. Figure 3-28
shows a top-down view of one row of an HD S54 frame with cartridges in Tiers 0 (door side),
1, 2, and 3.

Figure 3-28 Top down view of an HD Model S54 frame with Tier 0 at the bottom


As you can see, access to higher tiers is slower because of having to move cartridges out of
the way. Depending on your usage, this could be significant.

Host platforms and device drivers
The IBM TS3500 Tape Library is supported on a variety of operating systems. For a current
list of host software versions and release levels that support the TS3500 Tape Library, see:
http://www.ibm.com/servers/storage/tape/compatibility/pdf/ts3500_interop.pdf

For information about TS3500 Tape Library attachment to a System z environment, refer to
the IBM TS3500 Tape Library with System z Attachment: A Practical Guide to TS1120 Tape
Drives and TS3500 Tape Automation, SG24-6789.

Encryption support
The TS3500 Tape Library supports Library-Managed Encryption (LME), System-Managed
Encryption (SME), and Application-Managed Encryption (AME).

LME on a TS3500 includes support for Barcode Encryption Policy (BEP) and Internal Label
Encryption Policies (ILEP).

When using BEP, policies are based on ranges of cartridge volume serial numbers. You can
specify the volume serial ranges for the volumes that are to be encrypted. Alternatively, you
can exclude ranges of volume serial numbers from encryption. Library-Managed Encryption
also allows for encryption of all volumes in a library, independent of barcodes.

Note: New with the November 7, 2008 Firmware the TS3500 may be configured with
independent Key Managers for each logical library. This firmware requires the ALMS
feature be installed and enabled.

For certain backup applications, such as Symantec NetBackup, encryption policies based on
volume serials are not appropriate. When ILEP is configured, the TS1120, TS1130 or LTO
Ultrium 4 Tape Drive automatically derives the encryption policy and key information from the
metadata that is written on the tape volume by the application. NetBackup is currently the
only backup software that supports ILEP. When you select ILEP, you may choose one of the
following polices, which you set through the Tape Library Specialist Web interface:

In a System z environment, only SME is supported.

Note: SME and LME require an Encryption Key Manager (EKM) or Tivoli Lifecycle Key
Manager (TKLM). For LME, you enter the IP addresses of the primary and optionally
backup EKMs or TKLMs on the TS3500 library through the TS3500 Specialist. These
settings may refer to the physical library or be configured on a per logical library basis.
Each logical library may be configured with its own EKM, TKLM, TKLMs or EKMs.

For more information, refer to the Operator’s Guide for your tape library.


3.7 IBM TotalStorage 3494 Tape Library
An already-installed IBM 3494 Tape Library can consist of up to 16 tape library frames and
two additional high-availability tape frames (3494-HA1). IBM 3490E, IBM 3590, IBM
3592-J1A Tape Drives, TS1120, TS1130 Tape Drives can coexist within a single 3494 library.
For a detailed description of the IBM 3494 Tape Library, its components and features, refer to
the IBM 3494 Tape Library: A Practical Guide to Enterprise-Class Tape Drives and Tape
Automation, SG24-4632.

The tape library frame models of the IBM 3494 Tape Library have been withdrawn from
Marketing. You may still order 3494 Model D22 and D24 drive frames to expand an existing
3494 library. The replacement for the IBM 3494 Tape Library is the IBM System Storage
TS3500 Tape Library together with the IBM 3953 Tape System.

Note: Effective December 2006, IBM withdrew from marketing all Model Lxx Control Unit
Frames of the IBM 3494 Tape Library. You may still add selected drive unit frames to
already-installed IBM 3494 Tape Libraries, but you cannot install new libraries. The
TS3500 Tape Library with the IBM 3953 Tape System replaces the IBM 3494.

Figure 3-29 shows a 3494 Tape Library configuration consisting of a library frame, a driveless
storage frame, and two drive frames.

Figure 3-29 IBM TotalStorage 3494 Tape Library


Encryption support
The IBM 3494 Tape Library supports Library-Managed Encryption (LME), System-Managed
Encryption (SME), and Application-Managed Encryption (AME).

LME on a 3494 Tape Library includes support for Barcode Encryption Policy (BEP) and
Internal Label Encryption Policies (ILEP).

When using BEP, policies are based on ranges of cartridge volume serial numbers. You can
specify the volume serial ranges for the volumes that are to be encrypted. Alternatively, you
may exclude ranges of volume serial numbers from encryption. LME also allows for
encryption of all volumes in a library, independent of barcodes.

For certain backup applications, such as Symantec NetBackup, encryption policies based on
volume serials are not appropriate. When ILEP is configured, the IBMTS1130 or IBM TS1120
Tape Drive automatically derives the encryption policy and key information from the metadata
that is written on the tape volume by the application. NetBackup is currently the only backup
software that supports ILEP. When you select ILEP, you may select one of the following
policies, which you set through the Tape Library Specialist Web interface:

In a System z environment, only SME is supported.


4

Chapter 4. Planning for software and
hardware
In the previous chapters, we introduced the basics of encryption, how IBM tape data
encryption functions, and how Tivoli Key Lifecycle Manager (TKLM) or Encryption Key
Manager (EKM) works. We also covered the tape drives, tape control units, and tape libraries
that support encryption.

This chapter describes planning considerations for the tape hardware and the operating
systems that you should consider before implementing IBM tape data encryption.

If you plan to use System-Managed Encryption (SME) or Library-Managed Encryption (LME),
you should have TKLM or EKM implemented before you can encrypt any tapes. However,
many people plan for their tape hardware and their operating system first and then plan TKLM
or EKM implementation. These two major parts of your tape data encryption implementation
might be handled by different people in your organization.

Because the platform on which the tape drives reside can be different from the platform where
TKLM or EKM is implemented, we have separated out EKM planning and placed it in
Chapter 5, “Planning for EKM and its keystores” on page 139 Information about TKLM
planning has been placed in Chapter 9, “Planning for TKLM and its keystores” on page 317.


4.1 Encryption planning
Encryption is not your typical tape or library upgrade. Significant new function and
infrastructure must be implemented with an encryption solution. Planning is vital to a smooth
rollout of an encryption solution into your existing environment. Before you tackle this chapter,
if this is your first experience with IBM tape drives or libraries, make sure you have read
Chapter 3, “IBM System Storage tape and tape automation for encryption” on page 45.

Then, even if you have had experience with IBM Encryption Facility for z/OS or other vendor
cryptology products, you should read 1.4, “Concepts of tape data encryption” on page 9 and
Chapter 2, “IBM tape encryption methods” on page 23 to understand how the Encryption Key
Manager (EKM) or Tivoli Key Lifecycle Manager (TKLM) component ties your operating
system platforms together with your keystores.

After reading those basic topics, you are ready to use this chapter to plan the implementation
of the IBM TS1120 or TS1130 tape data encryption, or 3592 Encryption solution; and the
Linear Tape-Open (LTO) 4 or LTO4 Encryption solution.

4.2 Planning assumptions

Note: We discuss tape data encryption planning assuming that your tape drives and tape
libraries have already been installed without encryption.

Most of you are familiar with IBM tape drive or tape library implementations and upgrades of
the past. For those of you who are implementing new IBM tape drives or tape libraries, refer
to several existing IBM Redbooks publications for planning and implementation details:
IBM TS3500 Tape Library with System z Attachment: A Practical Guide to TS1120 Tape
Drives and TS3500 Tape Automation, SG24-6789
This book describes the TS1120 tape drive in a TS3500 tape library using z/OS or other
System z platforms, most concepts should map to the TS1130 as well.
IBM System Storage Tape Library Guide for Open Systems, SG24-5946
This book describes the TS1120, TS1130 and the LTO4 tape drive in Open Systems
implementations. This book also discusses Open Systems IBM tape libraries: the TS3500,
3494, TS3400, TS3310, TS3200, TS3100, TS2900.
IBM TotalStorage 3494 Tape Library: A Practical Guide to Tape Drives and Tape
Automation, SG24-4632
This book explains how to plan for and how to install the tape products and library in
enterprise platforms. It considers day-to-day operations and integration with other
products and applications and also provides information about data migration and
operational considerations.
IBM System Storage Virtualization Engine TS7700: Tape Virtualization for System z
Servers, SG24-7312
This book describes the TS7700 Virtualization Engine using 3592, TS1120, TS1130 tape
drives in a TS3500 tape library or a 3494 tape library.

The major part of this chapter focuses on the encryption aspects of this new solution,
because the underlying tape and application processing basics, with which you are familiar,
do not change.


4.3 Encryption planning quick-reference
The tables in this section compare encryption on the 3592 drive family to encryption on the
LTO4 drive:
Table 4-1 compares encryption characteristics.
Table 4-2 on page 94 compares drive, library, and controller prerequisites for encryption.
Table 4-3 on page 95 compares available encryption methods.

On Open Systems platforms, the 3592 and the LTO4 are almost identical in the encryption
methods that they support and the operating system software requirements. However, the
LTO4, and TS1130 support can require later software levels.

Table 4-1 compares encryption characteristics of the 3592 drive family and IBM LTO4 drive.

Table 4-1 Encryption implementation characteristics comparison
Description 3592 Tape drive family LTO4 Tape drive
(3592-E05, 3592-EU6,
3592-E06)

Encryption standard AES (256-bit) AES (256-bit)

Encryption process for data Symmetric AES (256) Symmetric AES (256)

Encryption key model Wrapped key Direct key

Encryption type for data keys Public-private key None
(Asymmetric)

Data keys used Unique data key for each Keylist: A list or range of
cartridge data keys used,
pregenerated in keystore

Data keys stored? Wrapped (that is, Stored in keystore
encrypted) data keys (2)
stored on cartridge, called
EEDKs

Rewriteable media required 3592 JJ, JA, or JB Ultrium 4 media only
cartridges

WORM media required 3592 JR, JW, or JX Ultrium 4 WORM media
cartridges only

Rekeying support z/OS, TS3500, and 3494 No

Chapter 4. Planning for software and hardware 93

Table 4-2 compares tape drive, library, and controller prerequisites for tape data encryption.

Table 4-2 Drive, library, and controller encryption prerequisites
Description 3592 tape drive family LTO4 tape drive

Tape drives

Drive machine type and model 3592-E05 1. TS1040 (3588-F4A)
3592-E06 2. Feature code (FC)
3592-EU6 8144 or FC8145 of
the TS3310, TS3200,
or TS3100 tape library
3. TS2340 (3580-S43)
4. TS2240 (3580E4S
5. TS2900 (3572-SH4)
With Feature Code
5901 (Transparent
LTO Encryption)

Encryption-capable FC9592 or FC5592 for Standard
3592-E05. Standard on
3592-E06 and 3592-EU6

Encryption-enabled and encryption FC9596 or FC5596 on Via library menus
method set 3592-E05 drive, FC9595
or FC5595 on controller,
or with library menus

Tape controllers (System z only)

3592-J70 tape controller with drives in a Yes, FC9595 or FC5595. N/A
TS3500 or 3494 Also, FC5593 for
out-of-band support

TS1120 Model C06 tape controller Yes, FC9595 or FC5595. N/A
(3592-C06) with drives in TS3500 or 3494 Also, FC5593 for
out-of-band support

TS1120 Model C06 tape controller Yes, FC9595 or FC5595 N/A
(3592-C06) with drives in TS3400 and feature FC5247

TS7700 Virtualization Engine (3957-V06) Yes, FC9900 N/A

Tape libraries

TS3500 Library (3584-Lxx): Yes, FC9900 Yes, FC9900 and FC1604
TS1130 requires ALMS
(Depending on
configuration FC 1690,
1692, 1693 or 1694)

Frames for drives 3584-L22, L23, D22, and 3584-L53, L52, L32, D53,
D23 D52, and D32

z/OS, z/VM, z/VSE, and z/TPF attach Requires 3953-F05 with N/A
3953-L05 Library
Manager

3494 library: Yes, FC9900 No

Frames for drives 3494-L22, D22, and D24 N/A

TS3400 library (3577-L5U) Yes, FC9900 No


Description 3592 tape drive family LTO4 tape drive

TS3310 library (3576-E9U and 3576-L5B) No Yes, FC9900 and FC5900

TS3200 library (3573-L4U) No Yes, FC9900 and FC5900

TS3100 library (3573-L2U) No Yes, FC9900 and FC5900

TS2900 autoloader (3572-SH4) No Yes, FC5901

Table 4-3 compares the Encryption Methods available for each tape drive environment.

Table 4-3 Encryption methods comparison
Encryption method or platform 3592 tape drives LTO4 tape drive


Tivoli Storage Manager TS1120 Release 5.3.4 5.3.5.1
TS1130 Release 5.4.3 or
5.5.1


IBM z/OS (controller-attached drives) z/OS V1R7a or later No

IBM z/OS (TS7700 Virtualization Engine) z/OS V1R7a or later No

IBM z/VM (controller-attached drives) z/VM V5.1 and V5.2 No

IBM z/VM (TS7700 Virtualization Engine) z/VM 4.4.0 or later No

IBM z/VSE (controller-attached drives) z/VSE V3.1 and V4.1 No

IBM z/VSE (TS7700 Virtualization Engine) z/VSE 3.1.2 or later No

IBM z/TPF (controller-attached drives) z/TPF V1.1 No

IBM z/TPF (TS7700 Virtualization Engine) TPF 4.1 and z/TPF V1.1 No

IBM AIX AIX V5.2 or later, Atape AIX V5.2 or later, Atape
device driver for TS1130 10.4.7.0 device driver
use 11.2.9.0 or later

Sun Solaris IBMTape device driver IBMTape.4.1.5.0 device
TS1130 IBMTape.4.1.8.7 driver or later
or later

IBM System i5® No No

Linux on System z Lin_Tape device driver Lin_Tape device driver

Linux on other servers Lin_Tape device driver Lin_Tape device driver

Hewlett-Packard UNIX (HP-UX) No No

Windows IBMTape device driver IBMTape device driver
For TS1130 use 6.1.9.8 or
later. At the time of this
writing there are no
WHQL drivers for the
TS1130


Encryption method or platform 3592 tape drives LTO4 tape drive


Tape Libraries providing this support TS3500, 3494, and TS3500, TS3310,
TS3400 TS3200, TS3100, TS2900

IBM z/OS, z/VM, z/VSE, z/TPF No No

IBM AIX AIX V5.2 or later AIX 5L™ V5.1,V5.2, or
V5.3

Sun Solaris Sun Solaris 8, 9, or 10 Sun Solaris 8, 9, or 10
TS1130 use
IBMTape.4.1.8.7 or later

IBM System i5 TS1120 i5/OS V5.2 or i5/OS V5.3 or later
later
TS1130 i5/OS v5.3 or
later

Linux on System z SLES9, SLES10, RHEL4, SLES9, SLES10, or
RHEL5 RHEL4, RHEL5

Linux on other servers SLES9, SLES10, RHEL4, SLES9, SLES10, RHEL4,
RHEL10, TS1130 RHEL5
requires lin_tape 1.19.0
10

HP-UX 64-bit HP-UX 11.0, 11i v1 64-bit HP-UX 11i v1,
v2, v3, or later 11i v2, 11i.v3 or later
atdd.84 or later atdd.84 or later

Windows Windows Server 2000, Windows Server 2003
Windows 2003 Server, (build 3790 or later),
Windows 2008 Server Windows 2008 Server
For TS1130 use 6.1.9.8 or use 6.1.9.5 or later
later. At the time of this
writing there are no
WHQL drivers for the
TS1130
a. Certain earlier releases that are no longer in service also provide support.

4.4 Choosing encryption methods
When starting to plan encryption management, there are several important considerations to
determine what solutions are available and what will fit in your environment. The important
steps for your planning considerations are to identify the available tape data encryption
solutions for your environment, as follows:
1. Identify which type of server is writing and reading the tape data.
Are all of the servers of one type or one operating system, or do you have multiple
operating systems that will be encrypting tape?
2. Identify encryption methods that are available for your server environments and choose
the encryption methods that you will use.
3. Identify which server or servers will host the Encryption Key Manager (EKM) or Tivoli Key
Lifecycle Manager (TKLM) component. Identifying the server or servers is really a
separate decision from where the actual tape encryption takes place, although most


people will probably implement the EKM or TKLM on the same platform where the tape
drives reside. Other important considerations are keystore and security requirements.
– We discuss EKM and keystore planning in Chapter 5, “Planning for EKM and its
keystores” on page 139.
– We discuss TKLM and keystore planning in Chapter 9, “Planning for TKLM and its
keystores” on page 317.

Depending upon your environment and your operating system platforms, you may use one or
more methods of encryption. You do not have to use the same method of encryption for all
implementations.

4.4.1 Encryption method comparison
Table 4-4 lists information about encryption policy implementation and encryption key
management for each encryption methods, which are Application-Managed Encryption
(AME), System-Managed Encryption (SME), and Library-Managed Encryption (LME).

Table 4-4 IBM tape data encryption methods, policies, and key management
Encryption Where is the policy defined Key management
method

AME Tivoli Storage Manager Tivoli Storage Manager

SME For 3592 drive family: Either:
DFSMS (z/OS) Encryption Key Manager (EKM)
R1 or later for TS1120 EKM R2
For 3592or LTO4 drives: or later for LTO4 EKM R2.1 or
Atape Device Driver (AIX) later for TS1130
IBMTape Device Driver (Sun) Tivoli Key Lifecycle Manager
IBMTape Device Driver (Linux) (TKLM)
IBMTape Device Driver (Windows)
No HP-UX support

LME For 3592 drive family: Either:
TS3500 Web Interface Encryption Key Manager (EKM)
3494 Web Interface or 3494 Library R1 or later for TS1120 and EKM
Manager User Interface R2 or later for LTO4 EKM R2.1
TS3400 Web Interface or later for TS1130
Tivoli Key Lifecycle Manager
For LTO4 drives: (TKLM)
TS3500 Web Interface

4.4.2 System z encryption methods
In System z environments (z/OS, z/VM, z/VSE, and z/TPF), you must always use
System-Managed Encryption. Application-Managed and Library-Managed Encryption are not
supported for these operating systems.


4.4.3 Open Systems encryption methods
In the Open Systems environments (including Linux on System z), you usually have a choice
of the method of encryption to use. On most operating systems, all three encryption methods
are available: AME, SME, and LME. Table 4-5 compares several of the differences and
considerations for Open Systems solutions.

Table 4-5 Comparison of Open Systems encryption methods
Method Policy granularity Advantages Disadvantages

AME Encryption policy is Fewer new Key management is not
configured at the responsibilities for centralized.
application GUI. storage administrators
Only available currently
Granularity is in Tivoli Storage
application-dependent. Manager

SME Encryption is configured Centralized Requires ISV support
(using device (on/off) at the host for enterprise-class key for IBM tape drive
drivers) each device driver management device drivers
instance, for example, the
host-to-drive relationship. Broadest library and
non-library coverage

LME Encryption is configured Centralized Not available for drives
(on/off) at the library GUI enterprise-class key outside an IBM tape
for each logical grouping management library
of drives (for example, all
drives in a TS3500 logical Broadest application and
library). operating system (OS)
coverage
One of:
Encrypt with default
EKM keys
Barcode Encryption
Policy (BEP) for
VOLSER ranges of
cartridges associated
with logical grouping
of drives
Internal Label
Encryption Policy
(ILEP) currently
supported by
NetBackup

Note: LME BEP is supported only on the TS3500 and 3494 tape libraries. The following
LME policy settings are supported on all tape libraries:
Encrypt All

Note the following considerations about the encryption methods:
Application-Managed Encryption
This method might be the most advantageous when a single application is the primary
user of tape. For example, all of the tape processing in an Open Systems environment is


related to a single software application, such as a backup and restore application (Tivoli
Storage Manager). In this case, having the backup and restore application manage the
keys might be the most convenient solution. When you consider implementing an
encryption management plan at the application layer using Tivoli Storage Manager, also
consider an important point, which is that this software has to be updated on every server
that provides data to be encrypted.
System-Managed Encryption and Library-Managed Encryption
These methods are perhaps the most logical approaches in environments where tape
assets are shared across multiple applications. This is because the transparency of
encryption offered through the use of the EKM or TKLM. As with Application-Managed
Encryption, updates might be required for certain aspects of the overall system, such as
device drivers, operating systems, DFSMS, or controllers, to fully enable encryption.

4.4.4 Decision time
You have to decide which encryption methods are best for your environments. However, in
general, we expect most clients to use System-Managed Encryption for their z/OS, z/VM,
z/VSE, and z/TPF operating systems (SME is really the only choice) and Library-Managed
Encryption for their Open Systems operating systems (including Linux on System z).

In 4.5, “Solutions available by operating system” on page 99, we indicate which encryption
methods are available for each operating system platform and tape hardware combination
and the required hardware and software prerequisites.

4.5 Solutions available by operating system
In this section, we discuss the support available for each operating system.

4.5.1 The z/OS solution components
This section summarizes the requirements for tape encryption in a z/OS environment.

Operating system support
z/OS supports System-Managed Encryption (SME) through DFSMS on the TS1120 and
TS1130 tape drive. The TS1120 and TS1130 tape drive, when encryption-enabled, is
supported for attachment to ESCON and FICON channels on System z servers with the
3592-J70 tape controller, the TS1120 tape controller (3952-C06), or the TS7700 Virtualization
Engine. This information is summarized in Table 4-6.

Table 4-6 z/OS encryption support

Tape library TS3500 3494 TS3400 TS3310 TS3200 TS3100

TS1120, TS1130 SME SME SME No No No
tape drives attached
to controller

TS1120, TS1130 SME SME No No No No
tape drives attached
to TS7700

LTO4 tape drive No No No No No No


System-Managed Encryption on z/OS requires:
z/OS and z/OS.e V1R4, or later. and program temporary fixes (PTFs) required for updates
to z/OS and DFSMS

Note: z/OS V1R4, V1R5, V1R6 and V1R7 are no longer in service.

An Encryption Key Manager component that is available to the z/OS system

z/OS support of the TS1120 tape drive with encryption is available on z/OS V1R4, V1R5,
V1R6, V1R7, and V1R8, and is included in the base support for z/OS V1R9 and later.

z/OS support of the TS1130 tape drive with encryption is available on z/OS V1R7 and later.
PTFs are required for updates to DFSMS.

Refer to these enabling APARs:
OA18111 for z/OS V1R4 and V1R5
OA17562 for z/OS V1R6 and V1R7
OA15685 for z/OS V1R8
OA22118 for TS1130 device support for new function
OA22119 for TS1130 new function

Note: Before you encryption-enable the TS1120 drives, these software levels must be
installed. If you enable the drives prior to having the software support, the drives will not
come up in z/OS because they now have device-type bytes that are not recognizable by
the previous software levels. Although compatibility support maintenance of these systems
recognizes the drive, it treats the drive as a non-encryption-enabled 3592-E05 drive.

Before using the encryption-enabled TS1120 or TS1130 tape drive in a sysplex, OAMplex,
RMMplex, or HSMplex, ensure that the appropriate support is available and installed at all of
the release levels used in the plex. In addition, as appropriate for your environment and
release level, determine what coexistence PTFs are required for your environment. For
additional information about the support provided, refer to the 3592 preventive service
planning (PSP) bucket. We also discuss additional planning details in 4.8.2, “TS1120 and
TS1130 compatibility considerations” on page 130.

Note: RACF APAR OA13030 is required on z/OS 1.4, 1.5, 1.6, and 1.7 for greater than
1024 modulus support. This APAR also provides additional support to the RACDCERT
command with respect to IBM Integrated Cryptographic Service Facility (ICSF) keys. If you
intend to generate RSA keys using RACF to be used with JCE4758RACFKS or
JCECCARACFKS keystores and your z/OS platform is z/OS 1.4 to 1.7, you must verify
that the PTF for this APAR has been applied.

Tape drives
Table 4-7 on page 101 describes tape drive combinations and feature codes.


Table 4-7 Tape drive requirements for z/OS
Tape drive Machine types and models Type of update

TS1130 3592-E06 New TS1130

TS1130 3592-EU6 TS1130 upgraded from a TS1120

TS1120 3592-E05 See TS1120 prerequisites,
encryption-capable, and
encryption-enabled.

Tape libraries
Table 4-8 describes the tape library requirements for z/OS.

Table 4-8 Tape Library requirements for z/OS
Tape library Machine types and models Type of update

TS3500 with 3584-L22, L23,D22, and D23 ALMS (Depending on model FC 1690,
TS1130 drives 1692, 1693, or 1694)
For the firmware update, visit:
http://www.ibm.com/servers/storage/su
pport/lto/3584/downloading.html
Library Firmware 8160 or later

TS3500 with 3584-L22, L23, D22, and D23 For the firmware update, visit:
TS1120 drives http://www.ibm.com/servers/storage/su

3494 with 3494-L22, D22, and D24 Library Manager must be at microcode
TS1130 drives level 536.00 or later.

3494 with 3494-L22, D22, and D24 Firmware updates shipped with FC5596
TS1120 drives and FC9596 on the 3592-E05 drive

TS3400 with 3577-L5U Library Firmware 0032.0000 or later.
TS1130 drives Order FC9900 for encryption configuration
documentation.

TS3400 with 3577-L5U Order FC9900 for encryption configuration
TS1120 drives documentation.

Control units
Table 4-9 describes control unit combinations and feature code prerequisites.

Table 4-9 Control unit requirements for z/OS
Control unit Machine types and models Type of update

3592-J70 controller 3592-J70 Firmware update shipped with
3592-J70 FC5595 or FC9595.

TS1120 tape controller 3592-C06 Firmware update shipped with
(3952-C06) 3592-C06 FC5595 or FC9595.

Router for EKM or TKLM Attach (only required on tape FC5593 or FC9593
controllers for out-of-band support)

3494-Lxx 3494-Lxx Firmware shipped for 3494 Library
Manager with 3592-J70 or
TS1120-C06 FC5595 or FC9595.


Control unit Machine types and models Type of update

3953-L05 3953-L05 Firmware shipped for TS3500 Library
Manager with 3592-J70 or
TS1120-C06 FC5595 or FC9595.

TS3400 3577-L5U Order FC9900 for Encryption
Configuration documentation.

TS7700 Virtualization Engine
Table 4-10 describes the tape library requirements for the TS7700 Virtualization Engine.
FC9900 is required on the 3957-V06 component of the TS7700 system to enable encryption
within the TS7700. FC0521 provides the latest firmware updates.

Table 4-10 TS7700 Virtualization Engine tape library requirements for z/OS

TS3500 with 3584-L22, L23, D22, and D23 ALMS (Depending on model FC 1690,
TS1130 drives 1692, 1693, or 1694)
TS7700 microcode must be at 8.5.0.xx or
later.


3494 with 3494-D22 Library Manager must be at microcode

3494 with 3494-D22 Might require FC5596 and FC9596 on the
TS1120 drives 3592-E05 drives if the Library Manager is
not at microcode level 535 or later.

4.5.2 z/VM, z/VSE, and z/TPF solution components for TS1120 drives
z/VM, z/VSE, and z/TPF support out-of-band System-Managed Encryption for TS1120 drives
through the 3592 Model J70 or TS1120 Model C06 tape controllers. Table 4-11 summarizes
the supported tape encryption methods.

Table 4-11 z/VM, z/VSE, and z/TPF Encryption methods available
Tape library TS3500 3494 TS3400

TS1120 and TS1130 tape drives SME SME SME
attached to controller

For z/OS prerequisites, refer to the tape libraries and control unit tables (Table 4-6 on page 99
through Table 4-9 on page 101).

Note System-Managed Encryption EKM does not run on z/VM, z/VSE, or z/TPF but is
supported through the out-of-band tape controller connection to an EKM server running on
z/OS or another EKM platform.


The z/VM support of System-Managed Encryption requires:
z/VM 5.1 and later with PTFs for APAR VM64063.
PTF for APAR VM64062 is also required for DFSMS/VM support for z/VSE guests.
A 3592 Model J70 or TS1120 Model C06 tape controller with routers for out-of-band
communication with EKM or TKLM.
An EKM or TKLM available to the tape controller.
One of the supported tape library and tape drive combinations from Table 4-11 on
page 102.

Refer to the latest editions of the following publications for more information:
z/VM CP Planning and Administration, SC24-6083
Search for the description of the overall usage of encryption support on z/VM.
z/VM CP Commands and Utilities, SC24-6081
This book contains specific details about each command.

The z/VSE support of System-Managed Encryption requires:
z/VSE V4.1 with APAR DY46682 (UD53141 and UD53142)
z/VSE V3.1 with APAR Dy46685 (UD53143, UD53144, and UD53146) and PK43473
(UK24398)
PTF for APAR VM64062 is also required for DFSMS/VM support for z/VSE guests.
DITTO with PK44172. With this APAR, DITTO/ESA for VSE supports tape encryption
interactively and with standard VSE JCL in BATCH mode.
page 102.

For more information, refer to the latest edition of z/VSE V4R1.0 Administration, SC33-8304.
Refer to the chapter about implementing hardware-based tape encryption.

The z/TPF support of System-Managed Encryption requires:
z/TPF with APAR PJ31479
page 102.

For more information, refer to the latest edition of z/TPF Operations on the IBM TPF Product
Information Center:
http://publib.boulder.ibm.com/infocenter/tpfhelp/current/index.jsp

TS7700 Virtualization Engine for z/VM, z/VSE, and z/TPF
Support of encrypted tapes within the TS7700 for these operating systems is totally outboard
within the TS7700. No operating system maintenance is required. At the TS7700, you can


designate the Storage Group and the Management Class to be used for a range of virtual
VOLSERS. The Storage Group and Management Class can specify the TS7700 storage
pools to be used, and encryption can be specified for a storage pool within the TS7700. Refer
to Chapter 13, “Implementing TS7700 Tape Encryption” on page 421 for more information.

Table 4-12 describes the tape library requirements for the TS7700 Virtualization Engine. The
FC9900 is required on the 3957-V06 component of the TS7700 system to enable encryption
within the TS7700. FC0521 provides the latest firmware updates.

Table 4-12 TS7700 Virtualization Engine tape library requirements for z/OS

TS3500 with 3584-L22, L23, D22, and D23 ALMS (depending on configuration FC
TS1130 drives 1690, 1692, 1693 or 1694)
TS7700 microcode must be at 8.5.0.xx or
later


3494 with 3494-D22 Library Manager must be at microcode

3494 with 3494-D22 Might require FC5596 and FC9596 on the
TS1120 drives 3592-E05 drives if the Library Manager is
not at microcode level 535 or later.

4.5.3 IBM System i encryption solution components
This section summarizes the i5/OS encryption support.

System i supports Library-Managed Encryption (LME) on the following combinations of tape
drives and tape libraries. Application-Managed Encryption, while supported, currently has no
applications that run on the System i5 platform.

Table 4-13 i5/OS Encryption support

Tape library TS3500 3494 TS3400 TS3310 TS3200 TS3100

TS1130 tape drive LME LME LME No No No

TS1120 tape drive LME LME LME No No No

LTO4 tape drive LME No No LME LME LME

System i support of LME requires:
i5/OS V5.2 or later for TS1120
i5/OS v5.3 or later for TS1130
i5/OS V5.3 or OS/400® V5.3 or later for LTO4
An Encryption Key Manager component available to the library
One of the supported tape drive and library combinations from Table 4-15 on page 105


Tape drives
Table 4-14 describes tape drive combinations and feature codes.

Table 4-14 Tape drive requirements for i5/OS

TS1130 3592-E06 No features on the drive are required
3592-EU6 for AME, SME, or LME.

encryption-capable and
encryption-enabled.

LTO4 3588-F4A or features of the No features on the drive are required
TS3310, TS3200, TS3100 tape for AME, SME, or LME.
libraries and TS2900 tape
autoloader

TS2340 (stand-alone 3580-S43 No features required for AME.
LTO4)

TS2240 (half high 3580-H4S No features required for AME.
stand-alone LTO4)

Tape libraries
Table 4-15 describes the tape library order options and firmware updates.

Table 4-15 Tape library requirements for i5/OS
Tape library and Machine types and Type of update
tape drive models

TS3500 with 3584-L22 and L23 ALMS (Depending on configuration FC 1690,
TS1130 drives 3584-D22 and D23 1692, 1693, or 1694)
Order FC9900.
http://www.ibm.com/servers/storage/support/
lto/3584/downloading.html

TS3500 with 3584-L22 and L23 Order FC9900.
TS1120 drives 3584-D22 and D23 For the firmware update, visit:
http://www.ibm.com/servers/storage/support/

3494 with 3494-L22 and D22 Order FC9900.
TS1130 drives Library Manager must be at microcode level
536.00 or later.

TS1120 drives Firmware update FC0520

TS1130 drives Order FC9900 for Encryption Configuration
documentation.

TS3400 with 3577-L5U Order FC9900 for Encryption Configuration


Tape library and Machine types and Type of update
tape drive models

TS3500 with 3584-L32, L52, and L53 Order FC9900 and FC1604.
LTO4 drives 3584-D32, D52, and For the firmware update, visit:
D53 http://www.ibm.com/servers/storage/support/

TS3310 with 3576-L5B and E9U Order FC9900 and FC5900, Transparent LTO
LTO4 drives Encryption.

TS3200 with 3573-L4U Order FC9900 and FC5900, Transparent LTO
LTO4 drives Encryption.

TS3100 with 3573-L2U Order FC9900 and FC5900, Transparent LTO
LTO4 drives Encryption

4.5.4 AIX solution components
This section summarizes the AIX support for tape data encryption.

IBM System p running AIX supports:
System-Managed Encryption (SME) through the Atape device drivers
Library-Managed Encryption (LME) in conjunction with the TS3500, 3494, TS3400,
TS3310, TS3200, TS3100 tape libraries and the TS2900 tape autoloader
Application-Managed Encryption (AME) with Tivoli Storage Manager

This information is summarized for library and drive combinations in Table 4-16.

Table 4-16 AIX encryption support
Tape library TS3500 3494 TS3400 TS3310 TS3200 TS3100 TS2900

TS1130 tape drive SME, SME, SME, No No No No
TS1120 tape drive LME, LME, LME,
AME AME AME

LTO4 tape drive SME, No No SME, SME, SME, SME,
LME, LME, LME, LME, LME,
AME AME AME AME AME

System-Managed Encryption with AIX requires:
AIX V5.1, AIX V5.2, AIX V5.3, or later.
An Encryption Key Manager component available to the AIX system.
The Atape device driver supporting encryption must be installed, updated, and utilized.
You may download it from:
ftp://ftp.software.ibm.com/storage/devdrvr/AIX/


Device driver
For AIX System-Managed Encryption only, Table 4-17 describes device driver order updates.

Table 4-17 Device driver requirements for AIX
Device driver Type of update

TS1130 tape drive Included in the device driver Web download at:
TS1120 tape drive ftp://ftp.software.ibm.com/storage/devdrvr/AIX/
LTO Ultrium 4 tape drive

Library-Managed Encryption with AIX requires:
AIX V5.1, AIX V5.2, AIX V5.3, or later.
An Encryption Key Manager component available to library.
A TS3500, 3494, or TS3400 tape library with TS1120 drives and 3592 media.
A TS3500, TS3310, TS3200, or a TS3100 tape library with LTO4 drives and Ultrium 4
media.

Tape drives
Table 4-18 describes tape drive combinations and feature codes.

Table 4-18 AIX Tape drive requirements for encryption

TS1130 3592-E06 No features on the drive are required for
3592-EU6 AME, SME, or LME.

encryption-enabled.

LTO4 3588-F4A No features on the drive are required for
AME, SME, or LME.

TS2340 3580-S43 No features required for
Application-Managed Encryption

stand-alone LTO4)

Tape libraries
Table 4-19 describes tape library order options and firmware updates.

Table 4-19 AIX tape library requirements
Tape library and Machine types and models Type of update
tape drive

TS3500 with 3584-L22 and L23 ALMS (Depending on configuration FC
TS1130 drives 3584-D22 and D23 1690, 1692, 1693 or 1694)
Order FC9900.
http://www.ibm.com/servers/storage/s
upport/lto/3584/downloading.html


tape drive

TS3500 with 3584-L22 and L23 Order FC9900 for Encryption
TS1120 drives 3584-D22 and D23 Configuration documentation.

TS1130 drives Library Manager must be at microcode
level 536.00 or later.

3494 with 3494-L22 and D22 Firmware update FC0520
TS1120 drives

TS1130 drives Order FC9900 for Encryption

TS3400 with 3577-L5U Order FC9900 for Encryption
TS1120 drives Configuration documentation.

TS3500 with 3584-L32, L52, and L53 Order FC9900 and FC1604, Transparent
LTO4 drives 3584-D32, D52, and D53 LTO Encryption.
For firmware update, visit:

TS3310 with 3576-L5B and E9U Order FC9900 and FC5900, Transparent
LTO4 drives LTO Encryption

TS3200 with 3573-L4U Order FC9900 and FC5900, Transparent

TS3100 with 3573-L2U Order FC9900 and FC5900, Transparent

TS2900 with 3572-S4H Order FC9900 and FC5901, Transparent

4.5.5 Linux on System z
When the drives are connected to System z using Fibre Channel Protocol (FCP), Linux on
System z supports:
System-Managed Encryption (SME) through the lin_tape device drivers
TS3310, TS3200, TS3100 tape libraries and TS2900 tape autoloader.

Table 4-20 on page 109 shows the encryption methods that are available on tape library and
tape drive combinations.


Table 4-20 Linux on System z supported encryption methods

TS1120 and TS1130 SME, SME, SME, No No No No
tape drive LME, LME, LME,
AME AME AME

AME AME AME AME AME

System-Managed Encryption with Linux on System z requires:
One of the following Linux on System z distributions:
– SUSE Linux Enterprise Server 9 (SLES 9) or later
– Red Hat Enterprise Linux (RHEL 4) or later
An Encryption Key Manager component available to the Linux system
A lin_tape device driver supporting encryption must be installed, updated, and utilized.
Download the lin_tape device drivers from the following Web site:
ftp://ftp.software.ibm.com/storage/devdrvr/Linux/
Download from the latest directory after looking at the Readme files to determine which
driver is appropriate for you.

Library-Managed Encryption with Linux on System z requires:
One of the following Linux on System z distributions:
– Red Hat Enterprise Linux (RHEL 4) or later
An Encryption Key Manager or Tivoli Key Lifecycle Manager available to the library
A TS3500, 3494, or TS3400 tape library with TS1120 or TS1130 drives and 3592 media
A TS3500, TS3310, TS3200, TS3100 tape library or a TS2900 tape autoloader with LTO4
drives and Ultrium 4 media.

4.5.6 Linux on System p, System x, and other Intel or AMD Opteron servers
System p, System x, and other Intel®-based or AMD™ Opteron™-based Linux servers
support:
System-Managed Encryption (SME) with lin_tape device drivers
Library-Managed Encryption (LME) on the TS3500, 3494, TS3400, TS3310, TS3200
TS3100 tape libraries and TS2900 tape autoloader.

Table 4-21 on page 110 shows the encryption methods that are available on tape library and
tape drive combinations.


Table 4-21 Linux-supported encryption methods

TS1120 and TS1130 tape SME, SME, SME, No No No No
drive LME, LME, LME,
AME AME AME

AME AME AME AME AME

System-Managed Encryption with Linux requires:
One of the following Linux distributions:
– SUSE Linux Enterprise Server 9 or 10 (SLES 9 or SLES 10)
– Red Hat Enterprise Linux 4 or 5 (REHL 4, REHL 5) or later
An Encryption Key Manager or Tivoli Key Lifecycle Manager available to the Linux system
The lin_tape device drivers supporting encryption must be installed, updated, and utilized.
Download the lin_tape device drivers from the following Web site:
ftp://ftp.software.ibm.com/storage/devdrvr/Linux

Library-Managed Encryption requires:
One of the following Linux distributions:
– Red Hat Enterprise Linux 4 (REHL 4) or later
– Asianux 2.0
An Encryption Key Manager or Tivoli Key Lifecycle Manager available to the Linux system
One of the tape drive and library combinations from Table 4-21

Tape drive
Table 4-22 describes the tape drive combinations and feature codes.

Table 4-22 Linux tape drive requirements for encryption

3592-EU6 for AME, SME, or LME.

TS1120 3592-E05 new drive order See TS1120 prerequisites,
TS1120 3592-E05 field upgrade for encryption-enabled.
encryption

TS3310, TS3200, and TS3100 for AME, SME, or LME.
tape libraries

TS2340 3580-S43 No features are required for
application-managed encryption.

TS2240 (half high 3580-H4S No features are required for AME.
stand-alone LTO4)


Tape libraries

Table 4-23 Linux tape library requirements
tape drive

TS3500 with 3584-L22 and L23 ALMS (Depending on configuration FC
TS1130 drives 3584-D22 and D23 1690, 1692, 1693, or 1694)
Order FC9900.
http://www.ibm.com/servers/storage/
support/lto/3584/downloading.html

TS3500 with 3584-L22 and L23 For the firmware update, visit:
TS1120 drives 3584-D22 and D23 http://www.ibm.com/servers/storage/

TS1130 drives Library Manager must be at microcode
level 536.00 or later.

3494 with 3494-L22 and D22 Firmware update FC 0520
TS1120 drives

TS1130 drives Order FC9900 for Encryption

TS3400 with 3577-L5U Order FC9900 for Encryption
TS1120 drives Configuration documentation.

TS3500 with 3584-L32, L52, and L53 Order FC9900 and FC1604,
LTO4 drives 3584-D32, D52, and D53 Transparent LTO Encryption.
http://www.ibm.com/servers/storage/

TS3310 with 3576-L5B and E9U Order FC5900, Transparent LTO

TS3200 with 3573-L4U Order FC5900, Transparent LTO

TS3100 with 3573-L2U Order FC5900, Transparent LTO

TS2900 with 3572-S4H Order FC9900 and FC5901,
LTO4 drives Transparent LTO Encryption

4.5.7 HP-UX, Sun, and Windows components
This section summarizes the encryption support of operating systems, and the tape drive and
tape library requirements.

This section discusses support of HP-UX, Sun Solaris, and Windows systems.


HP-UX systems
HP-UX supports the following encryption methods:
Library-Managed Encryption on the TS3500, 3494, TS3400, TS3310, TS3200, TS3100
tape libraries and TS2900 tape autoloader
Application-Managed Encryption with Tivoli Storage Manager

Library-Managed Encryption with HP-UX requires:
HP-UX 11.0, 11i v1 and v2, or later for TS1130, TS1120, and LTO4 drives
An Encryption Key Manager or Tivoli Key Lifecycle Manager available to the TS3500,
3494, TS3400, TS3310, TS3200, TS3100 tape library or TS2900 tape autoloader
drives and Ultrium 4 media

Sun Solaris systems
Sun Solaris supports the following encryption methods:
System-Managed Encryption through the IBMTape device drivers
Library-Managed Encryption in conjunction with the TS3500, 3494, TS3400, TS3310,
TS3200, TS3100 tape libraries and TS2900 tape autoloader
Application-Managed Encryption with Tivoli Storage Manager

System-Managed Encryption with Sun Solaris requires:
Sun Solaris 8, 9, and 10
An Encryption Key Manager or Tivoli Key Lifecycle Manager available to the Sun Solaris
system
The IBMTape device drivers supporting encryption must be installed, updated, and
utilized. The IBMTape device drivers can be downloaded from the following Web site:
ftp://ftp.software.ibm.com/storage/devdrvr/Solaris/

Library-Managed Encryption with Sun Solaris requires:
Sun Solaris 8, 9, and 10
An Encryption Key Manager component available to the library

Windows systems
Windows supports:
System-Managed Encryption (SME) through the IBMTape device drives
TS3310, TS3200, TS3100 tape library or a TS2900 tape autoloader.

System-Managed Encryption with Windows requires:
Windows 2000 Server, Windows Server 2003 or Windows Server 2008
An Encryption Key Manager or Tivoli Key Lifecycle Manager available to the Windows
system


The IBMTape device drivers supporting encryption must be installed, updated, and
utilized. Download the IBMTape device drivers from the following Web site:
ftp://ftp.software.ibm.com/storage/devdrvr/Windows/

Library-Managed Encryption on Windows requires:
Windows 2000 Server, Windows Server 2003, or Windows 2008
An Encryption Key Manager or Tivoli Key Lifecycle Manager available to the library

Table 4-24 and Table 4-25 describe the tape drive and the tape library order options and
firmware updates.

Tape drives
Table 4-24 lists tape drive combinations and feature codes for the operating systems.

Table 4-24 HP, Sun, and Windows tape drive requirements for encryption

3592-EU6 for SME, LME, and AME.

TS1120 3592-E05 new drive order See TS1120 prerequisites,
TS1120 3592-E05 field upgrade for encryption-enabled.
encryption

TS3310, TS3200, and TS3100 for SME, LME, and AME.
tape libraries

TS2340 3580-S43 No features are required for AME.

stand-alone LTO4)

Tape libraries

Table 4-25 HP, Sun, and Windows tape library requirements
Tape library with Machine types and Type of update
tape drive models

TS3500 with 3584-L22 and L23 ALMS (Depending on configuration FC 1690,
TS1130 drives 3584-D22 and D23 1692, 1693, or 1694)
Order FC9900.
http://www.ibm.com/servers/storage/supp
ort/lto/3584/downloading.html

TS3500 with 3584-L22 and L23 Order FC9900.
TS1120 drives 3584-D22 and D23 For the firmware update, visit:


Tape library with Machine types and Type of update
tape drive models

TS1130 drives Library Manager must be at microcode level
536.00 or later.

TS1120 drives Firmware update FC0520

TS1130 drives Order FC9900 for Encryption Configuration
documentation.

TS3400 with 3577-L5U Order FC9900 for Encryption Configuration

TS3500 with 3584-L32, L52, and L53 Order FC9900 and FC1604.
LTO4 drives 3584-D32, D52, and D53 For the firmware update, visit:

TS3310 with 3576-L5B and E9U Order FC9900 and FC5900,

TS3200 with 3573-L4U Order FC9900 and FC5900,

TS3100 with 3573-L2U Order FC9900 and FC5900,

TS2900 with 3572-S4H Order FC9900 and FC5901,

4.5.8 Tivoli Storage Manager
Currently, Tivoli Storage Manager is currently the only application that provides
Application-Managed Encryption for TS1130,TS1120 and LTO4 tape drives.

AME is best where operating environments run an application that is already capable of
generating and managing encryption policies and keys, such as Tivoli Storage Manager.
Policies that specify when to use encryption are defined through the application interface. The
policies and keys pass through the data path between the application layer and the TS1130,
TS1120, or LTO4 tape drives. Encryption is the result of interaction between the application
and the encryption-enabled tape drive and is transparent to the system and library layers.

The following tape drives and libraries are supported:
TS1130 tape drives in a TS3500 tape library, 3494 tape library, TS3400 tape library,
IBM TotalStorage 3952 Model C20 Tape Frame, or rack
TS1120 tape drives in a TS3500 tape library, 3494 tape library, TS3400 tape library,
IBM TotalStorage 3952 Model C20 Tape Frame, or rack
LTO4 tape drives in a TS3500 tape library, TS3310 tape library, TS3200 tape library,
TS3100 tape library, or TS2900 tape autoloader.

For details about setting up Application-Managed Encryption, refer to your Tivoli Storage
Manager documentation or visit the following Web site for more information:
http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/index.jsp


4.6 Ordering information
This section discusses features and microcode levels you might have to order and install to
support your encryption solution. We discuss the following prerequisites:
TS1130 tape drive
TS1120 tape drive
LTO4 tape drive
Tape libraries
Tape controllers
TS7700 Virtualization Engine
General software

4.6.1 TS1120 tape drive prerequisites
For any TS1120 drive to be able to support encryption, it must be encryption-capable before
it can enabled (encryption-enabled) with the particular encryption method (AME, SME, or
LME) to be used.

Encryption-capable
Prerequisites for the TS1120 tape drive are:
A no-charge encryption-capable feature code for new TS1120 tape drives. All TS1120
drives shipped since 8 September 2006 (serial number 13-65000 or greater) require
FC9592, which indicates that the drive is encryption-capable.
If your TS1120 drive shipped prior to 6 September 2006 (serial number 13-50000 to
13-64999), you might have to order an optional chargeable encryption feature upgrade,
FC5592, for the installed TS1120 tape drive. This feature code provides the encryption
electronics and causes the TS1120 drive to be encryption-capable. The upgrade might
contain refurbished parts.

Encryption-enabled
In most situations, the TS1120 tape drives can be encryption-enabled by using the library
Web interfaces. In that case, no prerequisite feature codes are required. The actual
procedures for encryption-enabling the drives are discussed in the implementation chapters.

The encryption-enabled environments and the prerequisite features (if any) to order are:
For System z TS1120 tape drives attached to a 3592 Model J70 or a TS1120 Model C06
tape controller, read 4.6.2, “Tape controller prerequisites” on page 116.
For Open Systems-attached TS1130 drives in a TS3500 tape library, ALMS is required
depending on the library configuration FC 1690 for L22 libraries, FC1692, 1693 or 1694
depending on the level of capacity expansion installed. Library Firmware 8160 or later is
required. You enable encryption for the drives through the Tape Library Web interface.
For Open Systems-attached TS1130 drives in a TS3400 tape library, you enable
encryption for the drives with the Tape Library Web interface. No prerequisite feature
codes are required.
For Open Systems-attached TS1120 drives in a TS3500 or TS3400 tape library, you
enable encryption for the drives with the Tape Library Web interface. No prerequisite
feature codes are required.
For Open Systems-attached or TS7700-attached TS1130 tape drives (in a 3494 tape
library with Library Manager licensed internal code level 536 or later is required), the Tape


Library Specialist or the 3494 Library Manager user interface provides the capability for
you to enable encryption for the drives. No prerequisite feature codes are required.
library with Library Manager licensed internal code level 535 or later), the Tape Library
Specialist or the 3494 Library Manager user interface provides the capability for you to
enable encryption for the drives. No prerequisite feature codes are required.
library with a Library Manager licensed internal code level lower than 535), order FC9596
(Plant) or FC5596 (Field) for each drive to be enabled. These features provide instructions
and procedures for the service support representative (SSR) to enable encryption for the
drive and set the encryption method for the drive.
For Open Systems-attached TS1120 or TS1130 tape drives in a rack or C20 Silo frame,
order FC9596 (Plant) or FC5596 (Field) for each drive to be enabled. These features
provide instructions and procedures for the SSR to enable encryption for the drive and set
the encryption method for the drive.

4.6.2 Tape controller prerequisites
Support for the TS1120 or TS1130 encryption function installed in any IBM controller
attachment requires a minimum level of firmware for the 3592-J70 tape controller, TS1120
tape controller (3592-C06), or 3590 A60 enterprise tape controller (even though the A60 does
not support encryption or TS1130) where you intend to use tape cartridges from a common
tape cartridge scratch pool.

The minimum level of firmware is 1.19.5.x for the 3592-J70 tape controller or 1.21.x.x for the
TS1120 tape controller (3592-C06), and 1.16.1.11 for the 3590-A60 enterprise tape
controller.

The level of firmware required for the TS1120 tape controller (3592-C06) and the 3592-J70
tape controller ships the first time that you order FC5595 or when you order FC9595 on a new
controller. To obtain the microcode required for the 3590-A60 enterprise tape controller, order
FC0520 (Function Enhancement Field).

For TS1120 or TS1130 drives attached to the System z platforms z/OS, z/VM, z/VSE, or
z/TPF, a TS1120 Model C06 or a 3592 Model J70 tape controller is required. These tape
controllers support encryption in the System z ESCON/FICON environment.

To configure and enable the encryption capability of the tape control unit (CU) and attached
tape drives, order CU Encryption Configuration, FC9595 (Plant) or FC5595 (Field) on the
Model J70 or C06 controllers. CU Encryption Configuration (Field FC5595) must also be
ordered when an Encryption Configuration change is required on the tape controller or
attached tape drives. One of these CU Encryption Configuration features must be installed
whether in-band or out-of-band encryption support is implemented. This feature provides
instructions and procedures for the SSR to enable encryption for the tape control unit and to
enable encryption and set the System-Managed Encryption method for all of the TS1120 or
TS1130 drives attached to the tape control unit.

Note: When one of the CU Encryption Configuration features is installed, it is not
necessary to order the Encryption Configuration/Plant or Field (FC9596 or FC5596) on the
TS1120 tape drives attached to the controller. The CU Encryption Configuration feature
enables encryption for all encryption-capable TS1120 drives attached to the controller.
Unless the TS1120 tape drives are installed in a client rack, the minimum level of Library
Manager licensed internal code will also be shipped when FC9595 is ordered or the first
time that FC5595 is ordered for the control unit.


Tape controller out-of-band support
For ESCON/FICON System z environments using out-of-band support for encryption (z/VM,
z/VSE, and z/TPF), routers are required to allow the tape controller to communicate with the
Encryption Key Managers (EKM) or Tivoli Key Lifecycle Manager (TKLM). Order FC5593
(Router for EKM Attach), which provides dual routers to allow redundant connections
between the tape controller and the EKM or TKLM. The installation of features required for
out-of-band support depends on the automation platform supporting the TS1120 or TS1130
tape drives:
For TS1120 and TS1130 tape drives in the TS3500 Tape Library:
Order one FC5593 on the 3953 Model F05 containing FC5505, Base Frame. This feature
supports up to sixteen 3592 tape controllers in a TS3500/3953 Library Manager tape
system.
For TS1120 and TS1130 tape drives in the 3494 Tape Library:
Order one FC5593, Router for EKM attach, on the 3494 Library Manager (Model L10, L12,
L14, L22, or L24). This feature supports up to seven 3592 tape controllers. FC5246, Dual
Path Concentrator, is required on the Library Manager before FC5593 can be installed. A
second FC5593, Router for EKM Attach, can be installed on the 3494 Library Manager to
support up to a total of fourteen 3592 tape controllers.

Note: The IBM 3494 Tape Library supports up to fifteen tape controllers. However, the
maximum quantity of two FC5593s in the 3494 Library Manager supports only up to
fourteen 3592 tape controllers.

For TS1120 or TS1130 tape drives in the TS3400 Tape Library:
Order FC5247, Enhanced Router, on the TS1120 Model C06 controller to which the
TS1120 drives are attached. This feature is required when attaching TS1120 drives in the
TS3400 library to a TS1120 Model C06 controller, even when no encryption is needed.
For TS1120 or TS1130 tape drives in the Storagetek 9310 Powerhorn Automated Tape
Library:
– When the tape drives are attached to the 3952 Model J70, order FC5593, Router for
EKM attach, on the 3590 Model C10 to support the first Model J70. One of FC4860,
FC4862, FC9861, or FC9862 is required on the 3590 Model C10.
To support a second 3592 Model J70 in the 3590 Model C10 frame, order FC5594,
Attach Additional CU to Router, on the Model C10. FC5593 is required on the Model
C10 to install FC5594.
– When the tape drives are attached to the TS1120 Model C06, order FC5593 on the
3952 Model F05. FC7315 is required on the 3952 Model F05.
To support more than one TS1120 Model C06 controller in the same 3952 Model F05
frame, order one of FC5594, Attach Additional CU to Router, for each additional Model
C06 to use out-of-band support. FC5593 is required on the 3952 Model F05 to install
FC5594. The maximum quantity for FC5594 on the 3952 Model F05 is two.
For TS1120 or TS1130 tape drives in a client-supplied rack:
Order one of FC5593 on the 3592 Model J70 or TS1120 Model C06 tape controller, which
is contained in 3953 Model F05 containing FC5505, Base Frame. This feature supports up
to sixteen 3592 or TS1120 tape controllers in a 3953 Tape System.

http://www-03.ibm.com/systems/storage/tape/pdf/compatibility/ts1120_interop.pdf


4.6.3 LTO4 tape drive prerequisites
For an LTO4 drive to be able to support encryption, it must be an encryption-capable drive
and then it must be enabled (encryption-enabled) with the particular encryption method
(SME, LME, or AME) to be used:
All LTO4 tape drives are encryption-capable (without any features) as long as they are
using Ultrium 4 media, therefore, meeting LTO consortium specifications.
The LTO4 tape drives will be encryption-enabled by using the library Web interfaces. No
prerequisite feature codes are required for the drive. The procedures for enabling
encryption for the drives are described in the implementation chapters.

4.6.4 Tape library prerequisites
You can configure your hardware setup to support encryption for your business in a variety of
ways. We list the tape library and tape controller requirements next.

TS3500 Tape Library prerequisites
The IBM TS1120 and TS1130 Tape Drive can be installed and is supported in the TS3500
Tape Library Models L23, L22, D23, and D22. The IBM LTO4 Tape Drive can be installed and
is supported in the TS3500 Tape Library Models L53, L52, L32, D53, D52, and D32. Support
for the tape encryption function requires a minimum level of microcode firmware, and it is the
client’s responsibility to load, configure, and maintain the TS3500 Tape Library.

Important: You must order the no-charge FC9900 (Encryption Configuration) on one of
the frames in the TS3500. We suggest ordering this feature for the L23, L22, L53, L52, or
L32 frame for consistency, because this feature code is where many other library features
are specified. This feature provides instructions and a license key for activating encryption
on the TS3500 Tape Library. Client-initiated procedures have to be completed for enabling
and configuring the TS3500 Tape Library to support encryption. No additional features are
required for TS1120 encryption.

When using an TS1130, Automated Library Management System (ALMS) is required;
depending on the library configuration, this may be FC 1690 for L32, L22 or L52 libraries,
FC1692, 1693 or 1694 depending on the level of capacity expansion installed.

If you plan to use LME or SME encryption methods for LTO4 drives in the TS3500 Tape
Library, you must also order FC1604, Transparent LTO Encryption. The AME encryption
method for LTO4 drives does not require FC1604.

The 3494 Tape Library prerequisites
TS1120 and TS1130 encryption support for tape drives in a 3494 tape library requires a
minimum level of firmware in the Library Manager. The required level of microcode firmware
ships the first time that the client orders FC5595, or when the client orders FC9595 and the
IBM 3592 Tape Controller is not located in a client-owned rack (FC4641). This feature applies
only to controller-attached TS1130 or TS1120 drives.

FC5220, Ethernet LAN Adapter, is also required on the 3494-Lxx frame in order to implement
Library-Managed Encryption in the 3494. Most 3494s already have this feature code. This
feature is not required if you plan to only use SME or AME methods in the 3494.

You must order no-charge FC9900, Encryption Configuration, on the Lxx frame of the 3494
when you plan to use encryption. This feature provides instructions for activating encryption
on the IBM 3494 Tape Library. This feature provides a level of microcode that supports a


capability known as Open Systems Library-Managed Encryption (OSLME). However,
OSLME also provides the capability to enable encryption for TS1130 or TS1120 drives for
SME and AME methods.

Client-initiated procedures need to be completed for enabling and configuring the 3494 tape
library to support OSLME. One of FC5046 (PCI Library Manager-Field), FC5047 (LAN PCI
Library Manager-Field), FC9046 (PCI Library Manager-Plant), or FC9047 (LAN PCI Library
Manager-Plant) is a required prerequisite to provide a compatible Library Manager PC.

Installation of this firmware can also update the drive microcode firmware on any installed
Open Systems-attached 3592 Model J1A tape drive, TS1120 or TS1130 tape drive. With this
support, the encryption, WORM, and standard tape cartridges in all sizes (JA, JB, JJ, JR, JW,
and JX media) can be intermixed within the same tape library and have one common scratch
pool per media type, independent of recording technology and encryption.

The minimum levels of microcode firmware are:
For OSLME, the minimum level is the Library Manager 535.xx code.
For TS1130, the minimum level is the Library Manager 536.xx code.

TS3400 tape library prerequisites
For TS1120 and TS1130 encryption support of LME or SME encryption methods within the
TS3400 tape library, order no-charge FC9900, Encryption Configuration, for machine type
and model 3577-L5U.

This feature provides publication updates with information about enabling and configuring the
IBM TS3400 Tape Library to support encryption. Client-initiated procedures need to be
completed for enabling and configuring the IBM TS3400 Tape Library to support encryption
with the TS1120 or TS1130 encryption-capable tape drive.

TS1120 drives in an IBM TS3400 Tape Library can either be Open Systems-attached or
controller-attached.

The minimum firmware level for the TS3400 to support a TS1130 tape drive is 0032.0000

IBM TS3400 Tape Library attached to IBM TS1120 Tape Controller

The minimum machine code level required on the IBM TS1120 Tape Controller (3592-C06) to
support attaching an IBM TS3400 Tape Library is 1.21.3.xx or later. You can use FC0520,
Controller Licensed internal code Update, to order the most current level of machine code.

To support attaching an IBM TS3400 Tape Library and its drives to an IBM TS1120 Tape
Controller, the TS3400 tape library (3577 Model L5U) requires the minimum machine code
level 0009.0007 or later. The client is responsible for downloading and installing machine
code updates to the IBM TS3400 Tape Library. Refer to the 3577 Sales Manual for more
details. The machine code level just described is required for the IBM TS1120 Tape
Controller.

To control IBM TS1120 Tape Drives or IBM TS1130 Tape Drives in an IBM TS3400 Tape
Library, the IBM TS1120 Tape Controller must be installed in a client-supplied rack that
usually contains the TS3400 libraries also. The TS3400 supports one or two TS1120 or
TS1130 tape drives and up to eighteen 3592 tape cartridges. A TS1120 tape controller can
attach up to seven TS3400 tape libraries. Each TS3400 tape library can only access
cartridges in its own library. Only tape drives installed in TS3400 tape libraries can be
connected to a TS1120 tape controller that has installed FC9014, Attach TS3400 to CU.


The IBM TS1120 Tape Controller (3592 Model C06) feature codes are:
FC9014, Attach TS3400 to CU, is required.
FC4641, Install Controller in Rack, is required.
FC5247, Enhanced Router, is required to provide management interface connections to
the TS3400 library and to the IBM TS3000 System Console (TSSC).
FC3478, Dual Ported Fibre Adapter, is required on the IBM TS1120 Tape Controller for
attachment of 3592 tape drives.

The IBM TS3400 Tape Library (3577 Model L5U) feature codes are:
FC9014, Attach TS3400 to CU, is required and provides an Ethernet cable to connect the
library to the enhanced router in the TS1120 tape controller configuration.
FC7004, TS3400 Rack Mount Kit, is required.

TS3310 tape library prerequisites
To support any encryption, order no-charge FC9900, Encryption Configuration. If you plan to
use LME or SME methods, also order chargeable FC5900, Transparent LTO Encryption.
AME encryption method does not require FC5900.

TS3200 or TS3100 tape library prerequisites
Encryption supported on Ultrium 5 and Ultrium 4 Fibre Channel and SAS tape drives: The
IBM System Storage TS3100 and TS3200 Tape Libraries support data encryption on the
base drive with Ultrium 5 and Ultrium 4 media meeting LTO consortium specifications and
Application Managed encryption(AME). System Managed(SME) and Library Managed
Encryption(LME) are supported with the Transparent LTO Encryption feature (Feature #5900
or SEO #45E3081). IBM Tivoli Key Lifecycle Manager v1 (TKLM) is required for encryption
key management with LTO Ultrium 5 drives.

For full functionality, the TS3100 and TS3200 Tape Libraries Driveless models require IBM
LTO Ultrium Tape Drives. IBM Linear Tape-Open (LTO) Ultrium 5 Half-High and Full High
6-Gb SAS and 8-Gb Fibre Channel Drives, enhancing tape performance over the previous
generation IBM LTO Ultrium 4 Tape Drives, with a native data transfer rate of up to 140
MB/sec. Ultrium 4 drive features are offered as 4 Gbps Fibre Channel in full-high format, or
LVD Ultra160 SCSI or 3 Gbps Serial Attached SCSI (SAS) in either full-high or half-high
formats. IBM Ultrium 4 Fibre Channel and SAS tape drives support encryption. Ultrium 3
drive features are offered as 3 Gbps Serial Attached SCSI (SAS) in half-high formats.

TS2900 tape autoloader prerequisites
To support any encryption, order no-charge FC9900, Encryption Configuration. If you plan to
use LME or SME methods, also order chargeable FC5901, Transparent LTO Encryption. The
AME methods do not require FC5901.

4.6.5 Other library and rack Open Systems installations
When you install encryption-capable TS1120 tape drives or TS1130 tape drives in either a
3592 Model C20 Silo Compatible Frame or in a 19-inch rack and if you intend to use tape
cartridges from a common scratch pool, minimum microcode levels are required for any other
3592-J1A drive or any TS1120 drive without the Encryption capability. These microcode
levels enable the non-encryption-capable drives to recognize the encrypted data format on a
cartridge.

The minimum level of microcode firmware is:


D3I0_851 for the IBM 3592-J1A Enterprise Tape Drive
D3I1_919 for the IBM TS1120 Tape Drive (3592-E05)

The minimum level of microcode firmware with TS1130 E3 formatted media is:
D3I0_C90 for the IBM 3592-J1A Enterprise Tape Drive
D3I1_DA0 for the IBM TS1120 Tape Drive (3592-E05)

You may upgrade the drive microcode levels or order these microcode levels as FC0500 on
the drive.

4.6.6 TS7700 Virtualization Engine prerequisites
This TS7700 Encryption function was initially introduced in the TS3500 tape library with the
TS7700 Virtualization Engine microcode version 8.2.0.19 in March 2007. The TS7700
Encryption function is now also supported in the 3494 tape library. Current microcode
requirements are:
If the TS1130 drives are in a TS3500 library:
– TS7700 Virtualization Engine licensed internal code level 8.5.0.xx or later
– With 8.5.0.xx the 3943 Library Manager is no longer required.
If the TS1120 drives are in a TS3500 library:
– TS7700 Virtualization Engine licensed internal code level 8.2.0.19 or later
– 3953 Library Manager licensed internal code level 534.31 or later
If the TS1130 drives are in a 3494 library:
– TS7700 Virtualization Engine microcode level 8.5.0.xx or later
– 3494 Library Microcode level 536.0 or later
If the TS1120 drives are in a 3494 library:
– TS7700 Virtualization Engine microcode level 8.2.0 27 or later
– 3494 Library Microcode level 534.31 or later

For encryption support in the TS7700 (SME only), order no-charge FC9900, Encryption
Configuration, against the 3957-V06 component of the TS7700 system. This feature provides
instructions and procedures for you to enable encryption microcode within the TS7700.

There is no host software maintenance required for the TS7700 encryption function, if
software already supports the TS7700 without encryption.

4.6.7 General software prerequisites for encryption
In this section, we describe general information about the operating system software
requirements. Specific information about the software release levels is discussed in the
following sections where each operating system is described in detail. The following list
describes support for encryption on environments and availability:
Support for encryption on the TS1120 or TS1130 in the z/OS operating system
environment is available through the 3592-J70 controller, the TS1120 tape controller
(3592-C06), or through the TS7700 Virtualization Engine (3957-V06).
Support for encryption on the TS1120 or TS1130 in the z/VM, z/VSE, or z/TPF operating
system environments is available through out-of-band encryption through the 3592-J70
controller, the IBM TS1120 Tape Controller (3592-C06), or with outboard static encryption
specifications in the TS7700 Virtualization Engine (3957-V06).


Support for encryption on TS1120 or TS1130 in Open Systems environments is provided in
i5/OS, AIX, HP-UX, Linux, Sun, Microsoft Windows Server 2000, Microsoft Windows 2003
Server or Microsoft Windows 2008 operating system environments.
Support for encryption on LTO4 in Open Systems environments is provided in i5/OS, AIX,
HP-UX, Linux, Sun, Microsoft Windows Server 2000, Microsoft Windows 2003 Server, or
Microsoft Windows 2008 Server operating system environments.

The installation of a TS1120, TS1130 or a LTO4 drive with encryption can require code
updates for System z, System i, System p, and supported Open Systems device drivers or
storage management software. The IBM account team or IBM Business Partner must confirm
that the client checks the appropriate preventive service planning (PSP) buckets for System z
environments or the equivalent support levels required for their particular software
environment prior to the installation of the TS1130, TS1120 with encryption or the LTO4 with
encryption. A solutions assurance call is required at a minimum for the installation of the first
new TS1130, TS1120 tape drive or LTO4 tape drive with encryption activated in an account.

To obtain an update of the Open Systems device drivers, use anonymous FTP from:

Then, look in the particular directories that represent your operating system environments.

For details about supported software versions and release levels for the TS1130 tape drive,
and hardware support information, refer to the following Web site and follow the link to the
System Storage Interoperation Center:
http://www.ibm.com/systems/storage/tape/ts1130/index.html

For details about supported software versions and release levels for the TS1120 tape drive,
as well as hardware support information, refer to the following Web site:

4.6.8 TS1120 and TS1130 supported platforms
The TS1120 and TS1130 tape drives are supported in the widest range of mainframe and
Open Systems environments:
Mainframe-attached:
– IBM System z running z/OS using ESCON or FICON channels
– IBM System z running z/VM using ESCON or FICON channels
– IBM System z running z/VSE using ESCON or FICON channels
– IBM System z running z/TPF using ESCON or FICON channels

Note: A tape controller is required for attachment to ESCON or FICON channels on
IBM mainframe servers.

Open Systems-attached:
– IBM System i
– IBM System p
– IBM System x
– Sun Solaris servers
– Hewlett-Packard servers
– Linux-based servers (including Linux on System z using FCP channels)
– Intel-compatible servers Microsoft Windows 2000 Server, Windows Server 2003,
Windows Server 2008


TS1120 and TS1130 tape drives are available in the TS3500, 3494, or TS3400 tape libraries.
They are also available in silos and in rack-mounted configurations. The encryption solutions
vary depending upon the location of the drives. Table 4-26 on page 124 shows the encryption
options available for the TS1120 and TS1130 in the mainframe environments while
Table 4-27 on page 124 shows the encryption options available for the TS1120 and TS1130
in Open Systems environments.


Table 4-26 Mainframe-attached TS1120 and TS1130 encryption solution options
Mainframe-attached IBM tape library Mainframe-attached rack or silo

SME in-band (z/OS only) SME in-band (z/OS only)

SME out-of-band (z/VM, z/VSE, and z/TPF) SME out-of-band (z/VM/, z/VSE, and z/TPF)

Table 4-27 Open Systems-attached TS1120 and TS130 encryption solution options
Open Systems-attached IBM tape library Open Systems-attached rack or silo

AME (Tivoli Storage Manager only) AME (Tivoli Storage Manager only)

SME (AIX, Solaris, Windows, or Linux only) SME (AIX, Solaris, Windows, or Linux only)

LME (TS3500, 3494, or TS3400 tape library)

Additional information about TS1120 and TS1130 tape drives is in the announcement letter.

4.6.9 IBM LTO4 tape drive supported platforms
The IBM LTO4 tape drive is supported in a wide range of Open Systems environments:
IBM System i
IBM System p
IBM System x
Sun Solaris servers
Hewlett-Packard servers
Linux-based servers
Intel-compatible servers Microsoft Windows 2000 Server, Windows Server 2003, or
Windows Server 2008

Encryption-capable LTO4 tape drives are available in the TS3500, TS3310, TS3200, TS3100
tape libraries and the TS2900 tape autoloader. They are also available as a drive only with the
TS2340 and TS2240. Table 4-28 shows the encryption options available for these
environments.

Table 4-28 Open Systems-attached LTO4 encryption solution options
Open Systems-attached in IBM tape library Open Systems-attached TS2340 drive

AME (Tivoli Storage Manager only) AME (Tivoli Storage Manager only)

SME (AIX, Solaris, Windows, or Linux only) SME (AIX, Solaris, Windows, or Linux only)

LME (TS3500, TS3310, TS3200, TS3100 tape
libraries and TS2900 tape autoloader)a
a. TS3310, TS3200, TS3100 and TS2900 do not support the Barcode Encryption Policy of LME.
LME on the TS3310, TS3200, TS3100, TS2900 is all or nothing (entire partition or not).

For more information:
Obtain information about the LTO4 tape drive in the announcement letter.
Obtain an update of the Open Systems device drivers through anonymous FTP from:
Look under the specific directory that reflects your operating system environment.


Refer to IBM Tape Device Driver Installation and User’s Guide, GC27-2130, available at:

4.7 Other planning considerations for tape data encryption
In this section, we describe other planning considerations for you to evaluate before
implementing tape data encryption. You must consider many factors when you plan how to
set up your encryption strategy.

4.7.1 In-band and out-of-band
System-Managed Encryption (SME) is the only encryption method available for z/OS
environments and requires the Encryption Key Manager (EKM) or Tivoli Key Lifecycle
Manager (TKLM) program. See Figure 4-1.

z/OS Java Virtual Machine
Key Manager (TCP/IP) Key Store
Another z/OS
Common Platform Java Code (or Open Systems)
TCP/IP Host
Translates -OR- TCP/IP
in-band key FICON Proxy to Key Manager
exchanges Key
In-band Key Management
Manager
Across ESCON/FICON Encrypt?
TCP/IP
Key Labels?
(out-of-band
SMS Policy
Key TCP/IP
DFSMS
Data Class
Management)

ESCON / FICON (in-band key management) TCP/IP to Key
Manager under
z/OS or
J70 or C06 Control 3592 Model elsewhere
Unit E05 Open Systems
Hosts
(VM, VSE, TPF, or even z/OS) - out-of-band Key Management (TCP/IP)
Control Unit across TCP/IP to z/OS or elsewhere

© 2003 IBM Corporation
Figure 4-1 z/OS in-band and out-of-band centralized key management

SME on z/OS has two configuration options that are shown in Figure 4-1. Which type of setup
makes sense for you?

The first key flow that we describe is in-band encryption where tape drive requests to the
EKM or TKLM component travel over the ESCON/FICON channels to the server proxy that is
TCP/IP-connected to the EKM or TKLM. The second key flow is out-of-band encryption
where the tape controller establishes the communication to the EKM or TKLM server over
TCP/IP connections between the tape controller and the EKM or TKLM server. A router is
required for out-of-band and EKM support.


In-band encryption
The in-band z/OS proxy allows key management information to be exchanged with a tape
drive over existing ESCON/FICON, instead of requiring the deployment of a secondary IP
network. The reliability and physical security of the existing I/O attachments are significant
reasons that many clients choose the in-band key management path to the EKM or TKLM.
The z/OS proxy interface communicates with the tape drive (through the control unit) in the
current data path and then uses a TCP/IP connection to communicate with the Encryption
Key Manager. Because in-band encryption is managed by the I/O supervisor (IOS), it also
allows you to display and alter EKM or TKLM primary and secondary server addresses from
the operator console.

Out-of-band encryption
With out-of-band encryption, the EKM and TKLM server addresses are only visible on the
Library Manager Console. One other consideration is that with out-of-band encryption, any
z/OS image using a drive also has to use the EKM or TKLM for which that drive was set up.
With in-band encryption, you can potentially have each z/OS image point to a different EKM
or TKLM, with each pointing to a different keystore. This allows images sharing drives to be
able to use different keystores. You might find this useful if you have to support a client or an
application where each client requires its own keystore for security or regulatory needs.

For z/OS tapes, either method allows a client to configure whether to encrypt based on Data
Class definitions. Furthermore for z/OS, a client can specify their key labels through Data
Class or through the DD statement (JCL, dynamic allocation, or TSO ALLOCATE). In addition
to this, EKM-assigned defaults can also be used if the key labels are not provided through
z/OS. For tapes that will be encrypted or decrypted, clients must define and keep track of the
key information to be used. Also, DFSMSrmm keeps track of the key labels that were used for
a given cartridge.

4.7.2 Performance considerations
Unlike software encryption or encryption appliances, the TS1130, TS1120 or the LTO4
encryption solutions can encrypt data with minimal data transfer performance impact and
without requiring additional equipment in the computing environment. You might be
concerned if encryption will impact the data transfer performance of your applications or
backup processing. Extensive testing shows little degradation to data transfer performance
with encryption-enabled drives. The data rate claims of the drive remain unchanged.

With encryption enabled, when writing from loadpoint, the access time of the first write from
the beginning of tape increases because of the time needed to retrieve, read, and write the
encryption keys. In z/OS, this added time is detected in OPEN processing, the time between
the mount message and the IEC705I “Tape On” message. Refer to Chapter 6, “Implementing
EKM” on page 159 and Chapter 9, “Planning for TKLM and its keystores” on page 317 for
more information. Reading an encrypted cartridge also increases the mount time because of
the time necessary to retrieve the encryption keys.

4.7.3 Encryption with other backup applications
All backup applications currently supported on any of the IBM tape libraries can support
Library-Managed Encryption, because the application is not involved in the encryption
process. Applications include, for example Symantec NetBackup, EMC NetWorker,
CommVault Galaxy, and BakBone NetVault.


4.7.4 ALMS and encryption in the TS3500 library
The Advanced Library Management System (ALMS) is required in a TS3500 with TS1130
drives.

Although the ALMS is not required for encryption in a TS3500 with TS1120 or LTO4 drives,
best practices suggest using it. Encryption in a TS3500 tape library with ALMS is configured
by the logical library. Encryption in a TS3500 tape library without ALMS is configured by the
physical library.

TS3500 ALMS Encryption rules
For NON-ALMS TS3500 libraries, we enforce homogeneous encryption rules for TS1120 and
earlier 3592 and all LTO drives, separately by drive type. The drive type is defined as 3592 or
LTO. ALMS is REQUIRED for TS1130 drives. This section discusses the rules. For more
information see IBM System Storage TS3500 Tape Library Advanced Library Management
System (ALMS) and Encryption, by Anthony Abete at:
http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101038

Rule 1: TS3500 non-ALMS, TS1120 drives only library
All 3592 drives in the entire library must be encryption capable for encryption to be enabled.
The entire physical library (all logical libraries if partitioned) must consist of encryption
capable TS1120 (3592-E05) drives. If encryption is to be enabled, it must be enabled for all
drives in the entire physical library, and the drives need to be all managed in the same
manner, that is, all LME, all SME, or all AME.

Rule 2: TS3500 non-ALMS, LTO drives only library
The entire physical library (all logical libraries if partitioned) must consist of LTO4 drives
before encryption can be enabled. No LTO 1, LTO 2, or LTO3 drives are allowed in the entire
physical library. If the library is partitioned, all logical libraries must have encryption enabled in
the same manner, that is, all LME, all SME, or all AME.

Rule 3: TS3500 non-ALMS, mixed TS1120 and LTO drives
In this environment, both drive types (LTO and 3592) are to be encryption-enabled. For
non-ALMS TS3500 libraries, we enforce homogeneous encryption rules for all 3592 and all
LTO drives, separately by drive type.

If you intend to enable encryption for both LTO and 3592, you must adhere to rules 1 and 2
with the following exceptions:
All LTO logical libraries must be managed in the same manner, that is, SME, LME, and
AME.
All 3592 logical libraries must be managed in the same manner, that is SME, LME, and
AME.

However, LTO and 3592 tape drives can be managed differently. For example, all LTO drives
can be LME while all 3592 drives can be SME or all AME.

Rule 3A: TS3500 non-ALMS, mixed 3592 and LTO drives
In this environment, only LTO or only TS1120 intend to have encryption enabled.

You have to adhere to the rules only if you intend to enable encryption for that drive type. If
you intend to enable 3592 encryption only and not LTO encryption, you only have to adhere to
rule 1. If you intend to enable LTO encryption only and not 3592 encryption, you have to
adhere only to rule 2.


Rule 4: TS3500 ALMS-enabled, 3592 drives only library
With ALMS enabled, all drives in the physical library do not need to be encryption-capable.
That is, the physical library can consist of both encryption-capable and 3592 drives that are
not encryption-capable.

All drives in the logical library must be encryption-capable if using LME or AME. All drives in a
SME-managed logical library do not need to be encryption-capable.

Rule 5: TS3500 ALMS-enabled, LTO drives only library
With ALMS enabled, all LTO drives (in the physical library or in the logical library) do not need
to be encryption-capable for encryption to be enabled. For example, a logical library can
consist of LTO4, LTO2, and LTO3 drives, and yet the LTO4 drives can be encryption-enabled
using SME, LME, and AME.

Rule 5A: TS3500 ALMS-enabled, mixed 3592 and LTO drives
You only need to adhere to rules 4 and 5 if you intend to enable encryption for that drive type.
If you intend to enable 3592 encryption only and not LTO encryption, only rule 4 applies. If
you intend to enable LTO encryption only and not 3592 encryption, only rule 5 applies. If you
intend to implement encryption on both 3592 and LTO, rules 4 and 5 both apply.

Note: ALMS is required with new TS3500 installations, when TS1130 tape drives are
installed in the library, or when a TS7700 is attached to the TS3500.

In summary:
On an existing TS3500 library without ALMS
Without ALMS, implementing encryption on an existing library is very inflexible. It also can
be costly, because older technology cannot coexist with newer encryption-capable
technology.
On a newly ordered library without ALMS
Without ALMS, implementing encryption is more difficult to manage and not very flexible.
This environment is useful only if you intend to implement encryption on a new library that
will not change over time. All logical libraries require the same encryption method, which
makes management an issue when you have to create non-encrypted cartridges.
On a new or existing TS3500 library with ALMS
With ALMS, implementing encryption is easily managed, flexible, and much more
cost-effective, regardless of your library configuration. This environment is cost-effective,
because older technology can coexist in the same physical library with newer
encryption-capable technology. Management is much easier, because multiple encryption
methods can be used within the same library. This environment is more flexible, because a
logical partition can consist of both old and new encryption-capable technology.

On 29 August 2006, IBM announced entry and intermediate-priced offerings of ALMS that
mesh with existing Capacity on Demand (CoD) library features. This announcement provides
full ALMS functionality for smaller libraries at a lower entry fee and lessens the impact of cost
as a barrier.

4.7.5 TS1120 and TS1130 rekeying considerations
You also have to consider rekeying requirements in your planning. Rekeying can be required
as part of sharing the same tape with your business partners.


It can also be a requirement if you have certificates or private keys that you expect have been
compromised. This compromise is analogous to losing your house keys and then calling a
locksmith to rekey all of the locks in your house. Then, the lost keys cannot be used to get into
your house.

We consider the business partner situation first. If you plan to share the same information
with multiple business partners, you have additional planning considerations. If you share
information today by sending multiple tapes at the same time, you can continue to do that, but
you have to write the tapes for each business partner using the individual business partner’s
unique public key (TS1120 and TS1130).

If you pass the same tape from one business partner to another business partner, you have to
consider certain changes if you encrypt that tape and do not want to share your private key.
The tape going to Business Partner A needs to be written using Business Partner A’s public
key. When Business Partner A finishes with the tape, they need to send the tape back to you.
At this point, you have two options. You can use the rekeying function to rewrite just the key
labels on the tape. Rekeying allows you to change the public key alias label used from
business partner A’s public key to business partner B’s public key without having to rewrite the
complete data portion of the tape. Details for performing rekeying in z/OS are provided in
12.9, “TS1120 and TS1130 tape cartridge rekeying in z/OS” on page 416.

The approach for compromised certificates is similar. You use rekeying to make the tape
unreadable by anyone possessing the compromised certificate or private key.

4.8 Upgrade and migration considerations
In this section, we provide you with important information for upgrading or migrating to tape
data encryption.

4.8.1 Look out for potential problems
We found several common errors of which you need to be aware:
Although multiple systems can be attached to a tape drive, the systems cannot use the
drive simultaneously.
TS1130 and TS1120 tape drives cannot be attached to the same 3592 Model J70
controller with 3590 tape drives.
TS1130 and TS1120 tape drives are not supported for attachment to a 3590 controller
model A60, A50, or A00.
TS1120 tape drives will operate in J1A Emulation mode when they are attached to the
same 3592-J70 or C06 controller with 3592 Model J1A tape drives. This mode is set
automatically by the microcode. In this mode, the TS1120 tape drives read and write only
in the J1A format at the J1A capacity and approximate performance ratings. This
configuration requires J70 code level 1.19.1.xx or later and Library Manager 532.xx or
later. Encryption is not allowed in J1A Emulation mode.
Under z/OS system-managed tape support, TS1120 tape drives that are
encryption-enabled are not supported under the same 3592-J70 or C06 controller with
TS1120 tape drives that are not encryption-enabled. With z/OS system-managed tape
support, although a mix of TS1120 tape drives can exist in the library, the TS1120 tape
drives under the same control unit need to be homogeneous and support the same
capabilities. Mixed capabilities require encryption-enabled TS1120 drives under one
controller and non-encryption-enabled drives under a different controller.


TS1120 tape drives attached to a 3494 VTS Model B10 or B20 operate in J1A Emulation
mode. This mode is set automatically by the microcode. In this mode, the TS1120 tape
drives read and write only in the J1A format at the J1A capacity and approximate
performance ratings. This configuration requires VTS code 2.32.745.x or later and Library
Manager 532.xx or later.
3592-J1A drives attached to the 3494 VTS Models B10 or B20 cannot be replaced by
TS1120 tape drives. You can however add TS1120 tape drives to already installed J1A
drives (up to a total of 12). The TS1120 drives when attached to a VTS operate in J1A
Emulation mode.
The B10 and B20 VTS do not support the enabled IBM TS1120 Tape Drive encryption
feature.

4.8.2 TS1120 and TS1130 compatibility considerations
Several compatibility considerations exist, from both a hardware and a software perspective.

IBM TS1130 Tape Drive modes
The TS1130 can operate in one of 5 modes:
EEFMT3 Enterprise Tape Format 3with encryption enabled
EFMT3 Enterprise Tape Format 3
EEFMT2 Enterprise Tape Format 2 with encryption enabled
EFMT1 Read-only Enterprise Tape Format 1(note that the TS1130 does not
emulate a 3592-J1A drive)

The TS1130 is read and write compatible with the IBM TS1120 Tape Drive and is read
compatible with the IBM 3592 Model J1A tape drive:
The IBM TS1130 Tape Drive cannot read cartridges written by the 3590 or 3490.
Cartridges written by the IBM TS1130 Tape Drive cannot be read by the 3590 or 3490.
Even though the cartridges are similar in size, they contain different media and thus are
not interchangeable.
The 3592-J1A cannot read or append to cartridges that were created on an IBM TS1130
Tape Drive in EFMT3, EEFMT3, EFMT2 or EEFMT2 mode.
The TS1120 cannot read or append to cartridges that were created on an IBM TS1130
Tape Drive in EFMT3 or EEFMT3 mode.

IBM TS1120 Tape Drive modes
The TS1120 can operate in one of three modes:
EEFMT2 Enterprise Tape Format 2 with encryption enabled
EFMT1 Enterprise Tape Format 1, which is also called J1A Emulation mode

In J1A Emulation mode, the TS1120 cannot be enabled for Encryption, but it is read and write
compatible with the IBM 3592 Model J1A tape drive:
The IBM TS1120 Tape Drive can read and append to cartridges written by the IBM 3592
Model J1A tape drive.
The IBM TS1120 Tape Drive can write cartridges in a 3592 Model J1A format that can be
read and appended to by the IBM 3592 Model J1A tape drive.
The IBM TS1120 Tape Drive cannot read cartridges written by the 3590 or 3490.
Cartridges written by the IBM TS1120 Tape Drive cannot be read by the 3590 or 3490.


Even though the cartridges are similar in size, they contain different media and thus are
not interchangeable.
The 3592-J1A cannot read or append to cartridges that were created on an IBM TS1120
Tape Drive in either EFMT2 or EEFMT2 mode.
The IBM TS1120 Tape Drive can be attached to the same 3592 Model J70 or C06
controller, TS7700 Virtualization Engine, or 3494 VTS Models B10 or B20 with 3592
Model J1A tape drives, but this configuration is only supported when the TS1120 is
running in J1A Emulation mode. When TS1120 drives are set to run in E05 native mode,
intermixing is not supported.

Upgrade and migration considerations exist when you move from an existing environment to
an encryption environment.

Coexistence support for the encryption-enabled IBM TS1120 Tape Drive is provided at z/OS
V1R4 and later by installing the necessary full-support program temporary fixes (PTFs)
without the device services enabling PTF. In addition to this, existing device services support
prevents the encryption-enabled TS1120 tape drives from coming online on a system that
does not have all of the full-support PTFs installed. Installation of the device services enabling
PTF brings in all of the required full-support PTFs.

Device services provides coexistence support to allow the encryption-enabled IBM TS1120
Tape Drive to come online, but until the full support is installed, it appears to the host as a
3592-2 without encryption capability. You must install the needed coexistence support on
systems that will not have all of the encryption-enabled IBM TS1120 Tape Drive support
installed.

DFSMSdss
DFSMSdss, a z/OS functional component, allows you to copy, move, dump, and restore data
sets and volumes. DFSMSdss is the primary data mover of DFSMS/MVS.

Using encryption-enabled TS1120 tape drives does not require changes to your installation’s
DFSMSdss jobs. It does, however, require changes to your installation’s Data Classes and
DFSMShsm dump classes. We briefly summarize these considerations here for DFSMSdss
administrators.

Using an encryption-enabled IBM TS1120 Tape Drive requires changes to your SMS Data
Class definitions. For tapes that require software (or host-based) encryption, ensure that your
dump-requesting jobs use only tape drives that are not enabled for hardware encryption. To
do so, check the Data Classes of the output ddnames to ensure that the jobs do not specify a
Data Class that requests encryption from the encryption-enabled tape drives.

Stand-alone drives
z/OS DFSMS and related program products provide full support for the encryption-enabled
IBM TS1120 Tape Drive and MEDIA5, MEDIA6, MEDIA7, and MEDIA8 with z/OS V1R4 and
later, with support for media types MEDIA9 and MEDIA10 provided with z/OS V1R5 and later.

The encryption-enabled IBM TS1120 Tape Drive support enables the tape drives to operate
in a stand-alone environment in 3590 Model B1x Emulation mode and to coexist with other
emulated tape drives. However, prior to using the encryption-enabled IBM TS1120 Tape
Drive, ensure that all existing 3592 Model J1A and all existing (base support) 3592 Model E05
tape drives have their microcode upgraded to recognize and enable the EEFMT2-formatted
cartridges to be relabelled and reused on the 3592 Model J1A and the base 3592 Model E05.
Also, ensure that VOLNSNS=YES is in the DEVSUPxx member of PARMLIB. Otherwise, job
failures can occur with a drive with the incorrect microcode load allocated.


In the stand-alone (non-system-managed) environment, all of the TS1120 Model E05 devices
under the same control unit should be homogeneous for easier separation and management,
even though the control unit allows a mix of TS1120 Model E05 devices (encryption-capable
and non-encryption-capable).

IBM tape library
z/OS DFSMS and related program products provide full support for the encryption-enabled
IBM TS1120 Tape Drive and MEDIA5, MEDIA6, MEDIA7, and MEDIA8, with z/OS V1R4 and
later, with support for media types MEDIA9 and MEDIA10 provided with z/OS V1R5 and later.
The system-managed tape library support allows the tape drives to operate in an ATL or MTL
environment as 3590 Model B1x devices, providing device allocation and tape media
management support. As appropriate for the library type and model, this support allows the
encryption-enabled IBM TS1120 Tape Drive to coexist with other emulated 3590-1 tape
drives in the same tape library. However, prior to using the encryption-enabled IBM TS1120
Tape Drive, ensure that all existing 3592 Model J1A and all existing (base support) 3592
Model E05 tape drives have their microcode upgraded to recognize and enable the
EEFMT2-formatted cartridges to be relabelled and reused on the 3592 Model J1A and the
base 3592 Model E05. Also, ensure that VOLNSNS=YES is in the DEVSUPxx member of
PARMLIB. Otherwise, job failures can occur with a drive with the incorrect microcode load
allocated.

In addition, in the system-managed tape library environment, all TS1120 Model E05 drives
under the same control unit must have the same recording format capabilities and report
under the same ERDS physical identifier (EPI). So, if one of the TS1120 Model E05 devices
is encryption-enabled, all of the TS1120 Model E05 devices under that same control unit
must also have encryption enabled. This setup ensures that all of the devices under the same
control unit are homogeneous and that each device under the same control unit is capable of
handling the request.

A tape configuration database (TCDB) with EEFMT2 volume records can coexist with lower
level systems. Coexistence support is provided at z/OS V1R4 and later to enable, during job
processing, a scratch volume that was previously written with an up-level recording format to
be used by a lower level system that does not recognize the recording format. Because there
is only one scratch pool per media type and that scratch pool can be used across systems at
different levels of support, this support ignores the recording format in which the volume was
previously written and enables the scratch volume to be used on the lower level system.

DFSMSdfp Device Services/Asynchronous Operations Manager
Coexistence is provided in the Device Services Exit for z/OS V1R4 and later. This capability
allows an encryption-enabled 3592 Model E05 drive to come online as a
non-encryption-capable 3592 Model E05 with the EPI value stored as X’12’ in the UCB
class extension (the UCBCXEPI field in the IECUCBCX mapping macro). This setup allows
an encryption-enabled drive to be used as a non-encryption-capable drive on systems that do
not have the full function support installed.

When the Device Services full function support APAR is installed, the Device Services Exit
checks whether the enabling APAR is also installed. If it is, the Device Services Exit records
the EPI value in the UCB class extension as X’13’.

The coexistence support recognizes the new EPI value and displays the real device type as
3592-2 for the DS QTAPE,MED command, because the new encryption-enabled 3592 Model
E05 drive looks and acts exactly the same as a non-encryption-capable drive in coexistence
systems that do not have the full function support installed.


HSMplex
In an HSMplex, all systems in the HSMplex must have full support for the TS1120 tape
subsystem before any instance of DFSMShsm uses tape hardware encryption. If any system
does not fully support tape hardware encryption in an HSMplex with tape hardware-encrypted
tapes, a request for tape input can fail because an encryption-enabled 3592 device is not
available on that system.

OAMplex
For object access method’s (OAM) object support, coexistence considerations exist that you
must take into account for your installation before you install the software in an OAMplex:
For the encryption-enabled IBM TS1120 Tape Drive support, OAM object tape
coexistence support is provided at z/OS V1R4 and later through the installation of the full
support PTF without the Device Services enabling PTF.
OAM coexistence support prevents lower level systems from selecting volumes with
ERDS Physical Identifier (EPI) values for object write requests that are not supported on
that system.
OAM object support has coexistence considerations when running in an OAMplex
environment with at least one system with the full support installed and enabled and at
least one system at a release level where the new devices are supported, however, all of
the support is not installed and enabled. In this mixed environment, it is possible for a
retrieve request to be received for an object that resides on a tape cartridge volume
written in the EEFMT2 format by a system that does not have the encryption-enabled IBM
TS1120 Tape Drive support installed. Coexistence support is provided that allows OAM to
attempt to locate an instance of OAM in the OAMplex where the full support is installed
and enabled. If an instance of OAM is located where the request can be processed, the
OAM on the system where the request originated will ship the retrieve request, if the
object is not greater than 50 MB, to the target system using XCF messaging services.
After encryption-enabled IBM TS1120 Tape Drive devices are used in an OAMplex
environment and objects are written to tape volumes with the new EPI value recorded, it is
expected that any OAM on a system where the full support is installed and enabled is
eligible for processing requests using that volume. Therefore, encryption-enabled IBM
TS1120 Tape Drive devices must be available to all instances of OAM where the full
support is installed.

Open/Close/End-of-Volume (OCE)
The FILEE parameter list is now longer to accommodate the possible key encryption key
(KEK) labels and their encoding mechanism. The version of the FILEE parameter list
(TEPEVER) has been updated (to a 2) to reflect the longer FILEE parameter list. Before
referencing the key label-related fields in the FILEE parameter list, ensure that either the
version is set to 2 or the TEPMCRYP bit is “ON”. When the TEPMCRYP bit is “ON”, the key
label-related fields contain pertinent data; otherwise, these fields contain binary zeroes.

Coexistence support is added at z/OS V1R4 and later to prevent an encrypted tape from
being used on a lower level system. If an encrypted volume is detected during OPEN
processing on a system that does not have all of the encryption support installed, abend code
613-84 is issued:
no software support for the media type or the recording technology

RMMplex
For the encryption-enabled IBM TS1120 Tape Drive support, DFSMSrmm coexistence
support is provided at z/OS V1R4 and later, either through installation of the full support RMM


PTF without the Device Services enabling PTF or using installation of the PTFs for the
toleration APAR OA16524.

This allows the coexisting system to tolerate tapes written by the encryption-enabled IBM
TS1120 Tape Drive in EEFMT2 format and their associated key labels. If you have any
systems sharing a control data set (CDS) with a system that installs the new RMM function
(you do not need to have encryption in use), you must install the toleration PTFs for APAR
OA16524, whether client/server is used or not. If client/server is used, the PTFs for APAR
OA16523 (preconditioning) are also required. If you plan to fall back from any z/OS release
RMM with encryption function to any z/OS release RMM without encryption function,
toleration is required on that fallback system also.

RMM provides a toleration APAR OA16524 for an RMM Sysplex. With this APAR, systems in
the Sysplex where the encryption code is not yet installed are enabled to keep (not to use) the
key encryption key label fields (1 and 2). If the encrypted tape belongs to a system-managed
tape library, the processing of this tape on a toleration system is limited: RMM’s internal call to
OAM fails with the message:
unsupported recording format

RMM provides a preconditioning APAR OA16523 and a toleration APAR OA16524 for a
client/server RMMplex. The way that data is transmitted between a client system and a server
system has changed. Transmission of CDS records is now release independent. A system
where only the preconditioning APAR OA16523 is installed accepts lower and higher level
systems. A system where the toleration APAR OA16524 is installed accepts preconditioning
and higher level systems only, but also tolerates CDS records containing encryption key
labels.

Important: For the installation on a client/server RMMplex, installing the preconditioning
PTF on all systems of the RMMplex is mandatory. Then, install the toleration PTF on all
systems, and only then, can you install the RMM Tape Encryption PTF. Preconditioning
and Toleration APARs contain a ++HOLD(MULTSYS) text, which describes this
dependency.

This process ensures that for a client/server RMMplex, you only need to update a single
system at a time depending on your enterprise change control process.

4.8.3 DFSMSdss host-based encryption
If your DFSMShsm dump classes are currently defined to use host-based encryption (and
possibly, host-based compression before encryption), we recommend that you remove the
host-based encryption requests from any dump classes for which you plan to use hardware
encryption. Over time, as you migrate your DFSMShsm dump classes to use hardware
encryption, you might still have dump classes that are defined to use host-based encryption,
while their associated Data Classes are defined to use hardware encryption. Here,
DFSMSdss ignores requests for host-based encryption for tape volumes and, instead, uses
hardware encryption. This processing allows you to complete the migration to hardware
encryption without having to modify your DFSMSdss jobs.

If you no longer require host-based encryption for any of your tape volumes, remove the
host-based encryption requests from all of your DFSMShsm dump classes. Thereafter, your
jobs can write to a mixture of encrypting tape devices and non-encrypting tape devices
without incurring informational messages. This setup allows you to encrypt tapes to send
off-site for disaster recovery purposes, while retaining unencrypted tapes on-site.


4.8.4 Positioning TS1120 Tape Encryption and Encryption Facility for z/OS
The z/OS implementation of this product leverages z/OS security and availability features for
key management.

The Encryption Facility for z/OS program product provides a complementary encryption
solution for software encrypting non-TS1120 tape cartridge data. In a z/OS environment, the
IBM Encryption Key Manager component for the Java platform can utilize the same hardware
and software cryptographic features available on z/OS.

Figure 4-2 compares the areas that you should consider when implementing the
complementary solutions of TS1120 Tape Encryption and the Encryption Facility for z/OS.

Depends on Customer Business Partner
Requirements Archival Backup/Restore
Satisfies requirement Exchange

IBM Encryption
Facility for z/OS  Compatibility Performance
(Business Partner  Key Distribution/  Key retention  Key failover
Exchange) manageability/ Enterprise wide key Performance
security mgmt.  Audit and access
 Audit and access  Audit and access control
control control

IBM Encryption
Capable TS1120 Tape
Drive Compatibility  Performance  Key failover
(Archive and  Key Distribution/  Key retention
backup/restore) manageability/  Enterprise wide key  Performance
 Audit and access
security management
control
 Audit and access  Audit and access
control control

Can use the same mainframe centralized key management
Figure 4-2 Encryption Facility for z/OS and TS1120 Tape Encryption solution comparison


Part 2

Part 2 Implementing and
operating the EKM
In this part, we provide detailed information about planning for, implementing, and operating
the Encryption Key Manager (EKM).


5

Chapter 5. Planning for EKM and its
keystores
In this chapter, we discuss the planning for the Encryption Key Manager (EKM). EKM must be
implemented in at least one of the Java Runtime Environments before you can encrypt any
tape using System-Managed Encryption (SME) or Library-Managed Encryption (LME).
Application-Managed Encryption (AME) does not require an EKM implementation. This
planning can occur even before your hardware arrives. Chapter 6, “Implementing EKM” on
page 159 completely describes the implementation of EKM.

EKM is part of the IBM Java environment and uses the IBM Java Security components for its
cryptographic capabilities. The keystore used by EKM is defined as part of the Java
Cryptography Extension (JCE) and an element of the Java Security components, which are,
in turn, a part of the Java Runtime Environment.

EKM Release 1 or later is required for TS1120 encryption support. EKM Release 2 or later is
required for Linear Tape-Open (LTO) 4 or LTO4 encryption support. Install the latest release
available whether you are implementing for TS1120 and TS1130 encryption or for LTO4
encryption.

You must decide on what platform (or platforms) the EKM will run. In this chapter, we first
provide an EKM planning quick-reference, then we describe requirements for each of the
platforms where EKM can run. Then, we discuss various EKM and keystore implementation
considerations.


5.1 EKM planning quick-reference
Table 5-1 compares the encryption characteristics of the TS1120 and TS1130 drives to the
LTO4 drive. Table 5-2 on page 141 compares the Encryption Key Manager (EKM) software
prerequisites for each platform. On Open Systems platforms, the TS1120 and the LTO4 are
almost identical as to which encryption methods they support and the operating system
software requirements. However, the LTO4 support might require later software levels, and
fewer keystores are supported for LTO4.

Table 5-1 compares encryption characteristics of the TS1120 and TS1130 drives to the IBM
LTO4 drive.

Description TS1120 and TS1130 tape drive LTO4 tape drive

Encryption standard AES (256-bit) AES (256-bit)

Encryption process for data Symmetric AES (256) Symmetric AES (256)

Encryption key model Wrapped key Direct key

Encryption type for data Public-private key (Asymmetric) None
keys

Data keys used Unique data key for each Keyset: A list or range of data
cartridge keys used, pregenerated in
keystore

Data keys stored? Wrapped (that is, encrypted) data Stored in keystore
keys (2) stored on cartridge,
called EEDKs

Keystore Contains private keys and Contains data keys that have
certificates representing public been pregenerated
keys.
Preloaded in keystore

Keystores types supported JCEKS (All platforms) JCEKS (All platforms)
JCE4758KS/JCECCAKS JCECCAKS (z/OS)
(z/OS) PCKS11IMPLKS (Open)
JCE4758RACFKS/
JCECCARACFKS (z/OS)
JCERACFKS (z/OS)
IBMi5OSKeyStore (i5)
PCKS11IMPLKS (Open)
DCMKS (Open)


Table 5-2 compares the software prerequisites for each EKM platform.

Table 5-2 Encryption Key Manager platform software prerequisites
Description TS1120 tape drive LTO4 tape drive

Encryption Key Manager Requires EKM Release 1 or Requires EKM Release 2 or
platform: later later

IBM z/OS IBM SDKa for z/OS, J2TEb, IBM SDK for z/OS, J2TE, V1.4,
V1.4, 5655-I56 (at the SDK 5655-I56 (at the SDK 1.4.2 SR8
1.4.2 SR6c level or later) level or later)

IBM 31-bit SDK for z/OS, J2TE, IBM 31-bit SDK for z/OS, J2TE,
V5.0, (z/OS 1.6 and later only), V5.0, (z/OS 1.6 and z/OS.e 1.6
order 5655-N98 (at the SDK 1.5 and later only), order 5655-N98
SR3 level or later) (at the SDK 1.5 SR5 level or
later)

IBM z/VM, z/VSE, and z/TPF Not available Not available

IBM AIX Java 5 SR2 (32-bit or 64-bit) Java 5 SR2 (32-bit or 64-bit)

Java 1.4.2 SR5 (32-bit or 64-bit) Java 1.4.2 SR5 (32-bit or 64-bit)

IBM System i5 i5/OS V5.3, IBM Developer Kit i5/OS V5.3, IBM Developer Kit
for Java- Java Developer Kit 5.0 for Java- Java Developer Kit 5.0

i5/OS V5.4, IBM Developer Kit i5/OS V5.4, IBM Developer Kit
for Java - J2SE™d 5.0 32-bit for Java - J2SE 5.0 32-bit

Linux on System z J2SE 5.0 SR2 or J2SE 1.4.2 J2SE 5.0 SR2 or J2SE 1.4.2
SR5 SR8

Linux on other servers J2SE SDK 5 or J2SE SDK 1.4.2 J2SE 5.0 SR5 or J2SE 1.4.2
SR8

Sun Solaris 8, 9, and 10 TPC-LE (5608-VC6) and IBM TPC-LE (5608-VC6) and IBM
Runtime Environment for Runtime Environment for
Solaris, J2TE, Version 5.0 SR2 Solaris, J2TE, Version 5.0 SR5
(Solaris SPARC 64-bit) (Solaris SPARC 64-bit)

HP-UX 11.0, 11i v1 or v2 TPC-LE (5608-VC6) and one of TPC-LE (5608-VC6) and one of
the following Java Runtime the following JREs
Environments (JREs)

HP Runtime Environment for HP Runtime Environment for
J2SE HP-UX platform, adapted J2SE HP-UX platform, adapted
by IBM for IBM Software, by IBM for IBM Software,
Version 5.0, SR2 for 64-bit Version 5.0, SR5 for 64-bit
Itanium64 Itanium64

HP Runtime Environment for HP Runtime Environment for
J2SE HP-UX platform, adapted J2SE HP-UX platform, adapted
by IBM for IBM Software, by IBM for IBM Software,
Version 5.0, SR2 for 64-bit Version 5.0, SR5 for 64-bit
PA-RISC PA-RISC

Chapter 5. Planning for EKM and its keystores 141

Description TS1120 tape drive LTO4 tape drive

Windows Server 2000 or TPC-LE (5608-VC6) and one of TPC-LE (5608-VC6) and one of
Windows 2003 Server the following JREs the following JREs

IBM 64-bit Runtime IBM 64-bit Runtime
Environment for Windows on Environment for Windows on
AMD64/EM64T architecture, AMD64/EM64T architecture,
J2TE, Version 5.0 J2TE, Version 5.0, SR5

IBM 32-bit Runtime IBM 32-bit Runtime
Environment for Windows, Environment for Windows,
J2TE, Version 5.0 J2TE, Version 5.0, SR5

IBM 64-bit SDK for Windows on IBM 64-bit SDK for Windows on
Intel Itanium® architecture, Intel Itanium architecture,
J2TE, Version 1.4.2 J2TE, Version 1.4.2, SR8
a. Software Developers Kit (SDK)
b. Java 2 Technology Edition (J2TE)
c. Service Refresh (SR)
d. Java 2 Standard Edition (J2SE)

5.2 Ordering information and requirements
In this section, we list the supported EKM platforms and indicate the requirements for EKM on
each of the supported operating system platforms. In this section, the level of software that
must be installed is given for a Service Refresh (SR) that supports both TS1120 or TS1130
and LTO4. If you have to know the minimum SR level that will support just the TS1120 and
TS1130, refer to the tables in 5.1, “EKM planning quick-reference” on page 140. These tables
contain information from the IBM Encryption Key Manager component for the Java platform,
EKM Introduction, Planning, and User’s Guide, GA76-0418.

5.2.1 EKM on z/OS or z/OS.e requirements
If the EKM is run on the z/OS system, one of the IBM SDKs for Java 2 in Table 5-3 must be
installed. They are available from:
http://www.ibm.com/servers/eserver/zseries/software/java

Table 5-3 EKM minimum software requirements for z/OS and z/OS.e
IBM Software Developer’s Kit (SDK) Model and PID number

IBM SDK for z/OS, Java 2 Technology Edition, 5655-I56 (at the SDK 1.4.2 SR8 level or later)
V1.4.2 SR8

IBM 31-bit SDK for z/OS, Java 2 Technology 5655-N98 (at the SDK 1.5 SR5 level or later)
Edition, V1.5.0 SR5 (z/OS and z/OS.e 1.6 and
later only)


Note: Regardless of which IBM SDK version you use, you must replace the
US_export_policy.jar and local_policy.jar files in your $java_home/lib/security
directory with an unrestricted version of these files. These unrestricted policy files are
required by the EKM in order to serve AES keys.

The preferred method to replace these files on z/OS is to copy the unrestricted policy files
that are shipped in the z/OS Java SDK build under the jce demo directory. You only have
to copy them to the lib/security directory, for example:
cp /usr/Lapp/java/J1.4/demo/Joyce/policy-files/unrestricted/*
/usr/Lapp/java/J1.4/lib/security

Alternatively, you can download the unrestricted policy files from the following Web site:
https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?source=jcesdk

After you log in, select the Unrestricted JCE Policy files for SDK 1.4.2, which works for
both Java 1.4.2 and Java 5.0 SDKs. Do not select the 1.4.1 version, because these files
are incompatible.

Secure symmetric key support on z/OS is through 5655-N98 (at the SDK 1.5 SR9 level or
later).

As you plan for production deployment of the EKM on z/OS, note that there is a difference in
the cryptographic capabilities between the SDK 1.4.2 SR8 and SDK 5.0 SR5 Java products.
SDK 5.0 SR5 and later allow for stronger keys that can reside in host storage in an
unencrypted fashion (that is, keys that are not encrypted by the IBM Integrated Cryptographic
Service Facility (ICSF) host master key.

Another consideration is what platforms and SDK levels will be used by your partners reading
the tapes written from your z/OS system. Their environments have to be understood to
ensure that the cryptographic capabilities of the reader are compatible with the SDK level that
you have chosen for the z/OS deployment.

Note: RACF APAR OA13030 is required on z/OS 1.4, 1.5, 1.6, and 1.7 for greater than
1024 modulus support. This APAR also provides additional support to the RACDCERT
command with respect to ICSF keys. If you intend to generate RSA keys using RACF to be
used with JCE4758RACFKS or JCECCARACFKS keystores and your z/OS platform is
z/OS 1.4 to 1.7, you need to verify that the PTF for this APAR has been applied.

5.2.2 EKM on z/VM, z/VSE, and z/TPF
EKM does not run on z/VM, z/VSE, or z/TPF, but EKM can be used with these operating
systems through the out-of-band tape controller connection to an EKM server running on
z/OS or another supported EKM platform.

5.2.3 EKM on IBM System i5 requirements
The EKM is supported on i5/OS V5.3 or later. If the EKM component is run on i5/OS, IBM
Developer Kit for Java is required: Java Developer Kit 5.0 (5722-JV1).

If the EKM is run on the i5/OS system, then one of the following IBM SDKs for Java 2 in
Table 5-4 on page 144 must be installed.


Table 5-4 EKM minimum software requirements for i5/OS
i5/OS IBM software developer kit Model and PID number

V5R3 IBM Developer Kit for Java - 5722-JV1 option 7 plus PTF
Java Developer Kit 5.0 SI25093 for 5722-SS1 option 3.
5722-AC3 is also required.

V5R4 IBM Developer Kit for Java - 5722-JV1 option 8 plus SR3,
J2SE 5.0 32-bit and PTF SI25094 for 5722-SS1
option 3.

Note: Regardless of which IBM JDK™ version you use, you must replace the
US_export_policy.jar and local_policy.jar files in your $JAVA_HOME/lib/security
directory with an unrestricted version of these files. These unrestricted policy files are
required by the EKM in order to serve AES keys. For details about installing the
unrestricted policy files, refer to the information about installing the IBM Software
Developer Kit (i5/OS) in the IBM Encryption Key Manager component for the Java
platform, EKM Introduction, Planning, and User’s Guide, GA76-0418.

5.2.4 EKM on AIX requirements
If the EKM is run on a System p server with AIX, the requirements is to have AIX V5.2 or later.
Table 5-5 lists the options for IBM Java SDKs to update in order to include the latest version of
the EKM.

Table 5-5 AIX EKM minimum software requirements
IBM Software Developer Kit Type of update

Java 5 SR5 (32-bit) IBM AIX Developer Kit and Runtime, Java
Java 5 SR5 (64-bit) Technology Edition AIX Software Update Web
Java 1.4.2 SR8 (32-bit)
Java 1.4.2 SR8 (64-bit)

Download available from: http://www.ibm.com/developerworks/java/jdk/aix/service.html

Updates to the AIX Java SDK can be obtained at the following Web site:
http://www.ibm.com/developerworks/java/jdk/aix/index.html

Note: Regardless of the version of IBM SDK that you use, you must replace the
US_export_policy.jar and local_policy.jar files in your
java_home/usr/java5/jre/lib/security directory with new files that you can download
from:

These files install the unrestricted policy files that EKM requires in order to serve AES
keys. After you log in, select Unrestricted JCE Policy files for SDK 1.4.2, which works
for both Java 1.4.2 and Java 5.0 SDKs. Do not select the 1.4.1 version, because these files
are incompatible.


5.2.5 EKM on Linux requirements
If the EKM is run on a Linux system, one of the IBM SDKs for Java 2 (listed in Table 5-6) must
be installed.

Table 5-6 Linux EKM minimum software requirements
Platform IBM Software Developer Kit

64-bit AMD/Opteron/EM64T J2SE 5.0 SR2 or J2SE 1.4.2 SR5 for TS1120 drives
32-bit xSeries (Intel -compatible) J2SE 5.0 SR5 or J2SE 1.4.2 SR8 for LTO4 drives
32-bit pSeries
64-bit pSeries
31-bit zSeries (S/390®)
64-bit zSeries (S/390)

Available at: http://www.ibm.com/developerworks/java/jdk/linux/download.html

Note: Regardless of the version of the IBM SDK that you use, you must replace the
US_export_policy.jar and local_policy.jar files in your directory
java_home/usr/java5/jre/lib/security with new files that you can download from:
https://www.software.ibm.com/webapp/iwm/web/preLogin.do?source=jcesdk

These files install the unrestricted policy files that EKM requires in order to serve AES
keys. After you log in, select Unrestricted JCE Policy files for SDK 1.4.2, which works
for both Java 1.4.2 and Java 5.0 SDKs. Do not select the 1.4.1 version, because these files
are incompatible.

Updates to the Linux Java SDK can be obtained at the following Web site:
http://www.ibm.com/developerworks/java/jdk/linux/download.html

5.2.6 EKM on Hewlett-Packard, Sun, and Windows requirements
To run the EKM component on Hewlett-Packard UNIX (HP-UX), Sun Solaris, or Windows, the
IBM TotalStorage Productivity Center - Limited Edition (TPC-LE), licensed program product
5608-VC6, is required.

If the EKM is run on HP, Sun, or Windows platforms, you must install one of the Java Runtime
Environments listed in Table 5-7.

Table 5-7 EKM minimum software requirements for HP, Sun, or Windows
Platform Operating system Runtime environment bundled with TPCa

HP HP-UX 11.0, 11i v1 or v2 One of the following items:
HP Runtime Environment for J2SE HP-UX
platform, adapted by IBM for IBM Software,
Version 5.0 for 64-bit Itanium
SR2 or later for TS1120, SR5 or later for LTO4
HP Runtime Environment for J2SE HP-UX
platform, adapted by IBM for IBM Software,
Version 5.0 for 64-bit PA-RISC

Sun Sun Solaris 8, 9, or 10 IBM Runtime Environment for Solaris, Java 2
Technology Edition, Version 5.0


Platform Operating system Runtime environment bundled with TPCa

System x Windows 2000 Server or IBM 64-bit Runtime Environment for Windows on
Windows Server 2003 AMD64/EM64T architecture, Java 2 Technology
Edition, Version 5.0
Base for TS1120, SR5 or later for LTO4

IBM 32-bit Runtime Environment for Windows, Java
2 Technology Edition, Version 5.0

IBM 64-bit SDK for Windows on Intel Itanium
architecture, Java 2 Technology Edition, Version
1.4.2
a. TPC: IBM TotalStorage Productivity Center - Limited Edition (TPC-LE) - licensed program product 5608-VC6

5.3 EKM and keystore considerations
We begin with questions for you to consider:
On what platforms will you run EKMs? The EKM is currently supported on:
– z/OS 1.4 and later
– AIX 5.2 and later
– i/5OS 5.2 and later
– Linux (Red Hat Enterprise Linux 4 and SUSE Linux Enterprise Server 9)
– HP-UX 11.0, 11i v1 and v2, or later
– Sun Solaris 8, 9, and 10
– Windows 2000 Server and Windows Server 2003
You might want to run the EKM on more than one of these platforms. In all cases, you
want EKM to be running on a highly available platform that is available any time you
require access to the drives.
If you have z/OS systems, we expect you will probably implement at least one instance of
the EKM on the z/OS platform. If you also have Open Systems tape encryption
requirements, you can use the z/OS EKM or you can decide that you want a separate and
additional EKM implementation on one or more of your Open Systems platforms. Section
5.3.4, “Typical EKM implementations” on page 149 has more detail about various EKM
platform considerations.
What keystore deployment model will you employ? Options include:
– For z/OS, possible keystore options are:
• JCEKS (file-based)
• JCE4758KS/JCECCAKS (ICSF secure hardware)
• JCE4758RACFKS/JCECCARACFKS (RACF with secure hardware)
• JCERACFKS (RACF/SAF)
– For distributed Open Systems, possible keystore options are:
• PCKS11IMPLKS (PKCS11 hardware crypto)


– For i5, possible keystore options are:
• IBMi5OSKeyStore (i5 platform capabilities)
– For LTO4 encryption, only the JCEKS or the PCKS11IMPLKS keystore types are
currently supported.
Table 5-8 indicates the supported keystores for drives. If you want to support both TS1120
and TS1130 encryption and LTO4 encryption from the same keystore, your choices are
limited.

Table 5-8 Comparison of supported keystores
Keystore type Platforms TS1120, LTO4 TS1120, Symmetric
supported TS1130 (stores TS1130 key tools
(stores symmetric and LTO4 available
keypairs and keys)
certificates)

JCEKS ALL Yes Yes Yes keytool

PKCS11Impl Open Yes Yes Yes keytool

IBMi5OS System i Yes No No No

JCE4758KS System z Yes Yes Yes Yes keytool
JCECCAKS (clear keys)
hwkeytool
(securekeys)a

JCERACFKS System z Yes No No No

JCE4758RACFKS System z Yes No No No
JCECCARACFKS
a. Java 1.5 SR9 and later

Do you want to use secure hardware cryptographic services?
This consideration is driven by the regulations and requirements your business needs to
meet. You can start simple, implementing a software JCEKS. If you later decide to move
to a hardware solution, all you need to do is point your EKM at this new keystore. All of
your other application setup stays the same. If you use this approach, remember that you
must import the keys from the JCEKS to the new keystore to be able to decrypt previously
encrypted data. This topic is discussed in 7.1, “Keystore and SAF Digital Certificates
(keyrings)” on page 228.
Do you want to use ICSF/RACF keyrings/keystores?
Again, you may start simple with JECKS and move to ICSF/RACF keyrings/keystores.
Chapter 8, “EKM operational considerations” on page 275 has an in-depth discussion
about why you might choose this over another keystore implementation.
Is your EKM behind a firewall?
As part of your centralized key management strategy, the EKM that your platform needs to
access might be behind a firewall. Our EKM was behind a firewall in our internal cross-site
testing (Example 5-1 on page 148), and we solved this issue by working with our network
support team to create exceptions in the firewall.


Example 5-1 Firewall exception process sample form
Requester's Name :Your Name
Requester's Email Address :yourid@us.ibm.com
Requester's Manager Name :Your Manager
Requested Site :Poughkeepsie
Application :IBM Tape Encryption
IP Address of Source :9.11.214.32, 9.11.214.187,
9.11.214.184, 9.11.214.190,
IP Address of Destination :9.12.17.104
Protocol of Ports :TCPIP / 3801
Length of Access :YE06
Bus. Justification :The Tape Team is developing a new Key
Serving Encryption Software Application that can be installed on any
available host that supports Java. A significant design of this solution is the
ability to support remote hosts running this application along with various
hardware configurations.
Impact if not approved :Unable to validate important simulations
of supported encryption solutions and the concepts of centralized key
management.

In our case, resolving this issue meant providing the source and destination IP addresses and
protocol of the ports as seen in Example 5-1. If your solution requires dealing with your
company’s firewall, plan to obtain this type of access as part of your implementation. For z/OS
solutions, this is where the use of Virtual IP Addressing (VIPA) can reduce the number of
exceptions required, because one VIPA address can provide access to any number of EKM
addresses behind it.

5.3.1 EKM configuration planning checklist
Make sure you:
Know the recipients for the tapes to be written and to be read. For each recipient:
– An associated X.509 certificate must exist when using TS1120.
– A key or range of keys must be pregenerated within the keystore when using LTO4.

Note: If you are only going to encrypt tapes for use within your own organization, you
can start with only a single certificate in the keystore for TS1120 encryption and a
single symmetric key in the keystore for LTO4 encryption.

Know the tape drives that will be used.
For each tape drive, you have to determine the drive serial number for input into the EKM
drive table. However, if you use the EKM acceptunknown function, this step is handled
automatically for you. Refer to Chapter 6, “Implementing EKM” on page 159 for details.
Have existing keys and certificates that you plan to use.
With this information, you can import and create keys and certificates into the keyring and
keystore to be used.
Determine the keystore type that you will employ:
– The keystore holds the public-private keys and certificates used by the TS1120
encryption method or the pregenerated symmetric data keys used by the LTO4
encryption method. These keystores are used by the EKM in assisting the tape drives
in generating, providing, protecting, and retrieving encryption keys.


– Depending on the keystore chosen, a keystore might be shareable between EKM
servers, such as RACF, Sysplex, and so forth.
– If EKM servers are running on separate systems, you are likely to use separate
keystores.
I

Note: For EKM servers that typically handle requests from the same set of tape drives, the
information in the associated keystores must be kept the same.

This consistency is required so that no matter which EKM server is contacted, the
necessary information is available for the EKM server to use to support the requests that
the EKM server receives from the tape drives.

We do not expect that this requirement to keep your keystores in synch will require much
time, because we expect only occasional changes to the keystores after your initial
implementation. Changing encryption keys at least once each year is a good practice.

5.3.2 Best security practices for working with keys and certificates
Best practices are:
Do not lose your keys and certificates.
Do not leave your keys and certificates available for other users to see.
Make sure to back up your keys and certificates

Important: Although IBM has services that can help you to recover data from a damaged
tape, if the damaged tape is encrypted, what you receive from the recovery will still be
encrypted data. So, if you lose your keys, you have lost your data.

5.3.3 Acting on the advice
Maintenance, backup, and restoration of key and certificate information depend on the
keyring and keystore implementation that you use. One method is to:
1. Create copies of the keystores that the EKM will use.
2. Retain a PKCS12 format file for each key/certificate combination and store this file in a
secure location, for example, on read-only media in a locked cabinet.
3. Retain a copy of the PKCS12 format and the keystore at your DR sites.

This method allows you to re-create keystores if absolutely necessary. Also, refer to the
documentation for each keystore (keyring) management tool in Chapter 7, “Planning and
managing your keys” on page 227 for more information.

5.3.4 Typical EKM implementations
You can run the EKM on a different platform from where your data is being encrypted. This
section summarizes several typical scenarios.


Data transfer and EKM both on z/OS
Figure 5-1 is a simple illustration of encryption enablement, using TS1120 as an example. In
this scenario, the client requests the encryption of data through the DFSMS Data Class
attribute. The IBM TS1120 Tape Drive requests a key from the EKM through the tape control
unit. Over the FICON channel, the EKM provides the key. The data is then encrypted on the
IBM TS1120 Tape Drive.

zOS 3494 or TS3500 Tape Library
LXX DXX
Encryption SMS
Key Manager F16
Policy
LM TS1120 TS1120

DFSMS TS1120 TS1120
ICSF TS1120 TS1120

TS1120 TS1120

TS1120 TS1120
RACF TS1120 TS1120
TS1120-C06

Figure 5-1 Single z/OS system key management

Data transfer on Open Systems with EKM on z/OS
Now, let us extend this concept to include the management on z/OS of the encryption keys
associated with Open Systems tape data. In Figure 5-2 on page 151, the Open Systems
server, System C, is using the library-managed approach for its tape data. When a key is
required on the AIX system, the request travels from the tape drive to the tape library to the
z/OS system over IP. The key manager and keystore are located on z/OS. This topology
leverages the zSeries and System z9 infrastructure to manage the keys for an enterprise,
including the ability to store the keys, using ICSF, in the unique zSeries or System z
hardware-enabled keystore. This method provides a highly secure environment for the
keystore and integration with RACF for tight control of the enterprise keystore, and allows the
primary and secondary key managers to share the same keystore using z/OS Sysplex data
sharing. The primary EKM and secondary EKM can also have different keystores that are
kept synchronized using mirroring technology or administrative processes.

Note: No requirement exists to change the applications on the Open Systems.


3494 Tape Library
F16

LM TS112
0
TS112
0

z/OS1 TS112
0
TS112
TS112
0
TS112
0 0

Primary c TS112
0
TS112
0
SMS a
Key
Policy
b FICON for z/OS data
TS112
0
TS112
TS112
0
TS112 J70
Manager and key transfer 0 0

DFSMS

Java JCE 2
IP for Key Requests TS3500 Tape Library
RACF ICSF F16

LM TS112 TS112

CEX2C 0
TS112
0
TS112
0 0
TS112 TS112
0 0
TS112 TS112

z/OS2 FCP Data and TS112 TS112
0 0

Control Paths 0
TS112
0
TS112 J70
Secondary 0 0

Key
Manager
1

Open OS TS112
TS1120 Tape Drive
Java JCE 0

RACF ICSF
CEX2C

Figure 5-2 Example z/OS system central key management

Data transfer on Open Systems with EKM on AIX
The Open Systems environment supports the concept of a centralized key manager. In
Figure 5-3, the Library-Managed Encryption methodology is used in combination with the
keystore on AIX to support keys across multiple servers. Remember, no requirement exists to
change the applications on the attached Open Systems servers. You might use this approach
when key management for the enterprise resides on one of the supported Open Systems
platforms. Again, this approach allows you to have a central keystore that is used by multiple
platforms within your enterprise. In this case, the application on another Open Systems
platform requests a cartridge mount on a library with encryption policy set to ON for the
VOLSER range requested. The library then routes the drive key request to the EKM on AIX,
which provides the key to the library. The key is then provided to the drive by the library, and
the application on another Open Systems server begins to write.

TS3500 Tape Library
Keys
EKM
IP TS1120 TS1120

TS1120 TS1120
AIX TS1120 TS1120

TS1120 TS1120

TS1120 TS1120
FCP Data / Control Paths
TS1120 TS1120

Other OS

Other OS

Figure 5-3 Example of Open Systems central key management with Library-Managed Encryption


Multiple-site EKM implementations
Figure 5-4 shows a multi-site tape data encryption environment where multiple platforms
across the sites can all interoperate. Figure 5-4 is an example from the solution test
environment used by the tape data encryption test team to validate the interoperability of all
the supported combinations that are possible for the initial support that was released.

This setup included the need to access EKMs through a firewall as well as leveraging Virtual
IP Addressing (VIPA) to add additional redundancy within a z/OS environment. By using
shared common keys, it was possible to run jobs on any of these environments, writing a tape
from an EKM on one platform and then reading that tape by pointing to any other EKM within
this enterprise.

Poughkeepsie Poughkeepsie SW Tucson Open Tucson SW Austin
Consolidated
Service Test IN-BAND OUT-OF-BAND IN-BAND OUT-OF-BAND
EKM ONLY z/OS 1.6 i/Series
z/OS 1.6 & 1.7 p/Series
5.0 31 bit 5.0 31 bit
1.4.2 31 bit 1.4.2 32 bit
z/OS 1.5 JCERACFKS DCMKS
(EKM Sysplex) PKCS11IMPLKS
1.4.2 31 bit Shared PDKS
p/Series JCE4758KS
JCEKS 4 way VIPA plex
1.4.2 / 5.0 32/64 bit Shared PKDS
JCEKS 2 way VIPA plex
Rochester
Poughkeepsie POK Integration x/Series z/OS 1.6 & 1.7 OUT-OF-BAND
Crypto Plex Test 1.4.2 / 5.0 32 bit 1.4.2 31 bit
JCEKS JCEKS i/Series
EKM ONLY IN-BAND
2 way VIPA plex 1.4.2 31 bit
z/OS 1.4 DCMKS
SUN/HP
1.4.2 31 bit z/OS 1.8 5.0 64 bit
JCE4758KS 1.4.2 31 bit JCEKS TUC HW
Shared PDKS/CKDS JCE4758RACFKS
MIXED
Shared PDKS z/Linux
z/OS 1.7 10 way VIPA plex 1.4.2 64 bit z/OS 1.6
5.0 31 bit
JCEKS 1.4.2 31 bit
JCE4758RACFKS
Shared PDKS JCEKS

Supported Keystores Supported Java Levels
SW - JCEKS, JCERACFKS, DCMKS Java SDK 1.4.2 SR5/SR6
HW - JCE4758KS, JCE4758RAFKS, PKCS11 Java SDK 5.0 SR3

Figure 5-4 Sample multiple site tape data encryption environment

This setup is obviously an extreme example that facilitated testing various platforms and
stress levels, but it gives you an idea of the unlimited options that are available and aspects of
planning that you need to consider.

5.3.5 Multiple EKMs for redundancy
A number of solutions are available that you can use to provide redundancy. The certificates
and keys stored in EKM’s keystore are the point of control allowing a tape drive or library to
decrypt the data on the tape. This approach makes the information in the keystore vital,
because without it, the tape cannot be read. Therefore, although protecting this information
so that others cannot obtain the private keys from the keystore is important, this information
must also always be available to you so that you can read the tapes when necessary.

The following considerations are related to the type of keystore that you might select to meet
your security needs, as well as your business needs, with regard to performance, backup,
and archival.


EKM is designed to work with tape drives and libraries to allow redundancy, and thus high
availability, so you can have more than one EKM servicing the same tape drives and libraries.
Moreover, these EKMs do not need to be on the same systems as the tape drives and
libraries. Refer to Figure 5-5. The only requirement is that the EKMs are available to the tape
drives through TCP/IP connectivity. This approach allows you to have two EKMs that are
mirror images of each other with built-in backup of the critical keystore information and a
failover, if an EKM becomes unavailable.

When you configure your device (or system, library, or control unit, as appropriate), you can
point it to multiple EKMs. If one EKM becomes unavailable for any reason, your device simply
uses the alternate EKM. You also have the capability to keep the two EKMs synchronized.
Taking advantage of this important function when needed is crucial, both for its inherent
backup of critical data and also for its failover capability to avoid any outages in your tape
operations.

Keystore and Keystore and
Crypto Services Crypto Services

EKM EKM

Drive Table Drive Table

Configuration Configuration

Figure 5-5 Keystore redundancy example

5.3.6 Using Virtual IP Addressing
The basic design of the Sysplex Distributor provides an advisory mechanism that checks the
availability of applications, such as the EKM, running on different z/OS servers in the same
Sysplex and then selects the best-suited EKM for a new connection request. The Sysplex
Distributor bases its selections on real-time information from sources, such as Workload
Manager (WLM) and quality of service (QoS) data from the Service Policy Agent. Sysplex
Distributor also measures the responsiveness of target servers in accepting new TCP
connection setup requests, favoring those servers that are more successfully accepting new
requests. Internal workload balancing within the Sysplex ensures that a group or cluster of
application server instances can maintain optimum performance by serving EKM requests
simultaneously. High availability considerations suggest that at least two EKM instances have
to exist, both providing the same service to request for keys. If one EKM instance fails, the
other EKM instance carries on providing service. Multiple EKM instances minimize the
number of requests affected by the failure of a single EKM instance. Thus, load balancing and
availability are closely linked.

Virtual IP Addressing (VIPA) can be used to automatically maintain continuous availability in
your Sysplex environment and add another layer of redundancy. See Figure 5-6 on page 154.
We have configured an 8-way z/OS Sysplex where we have set up EKMs running on four of


the images in this plex. Hosts running tape data encryption can point to the VIPA address of
this z/OS Sysplex and allow the Sysplex Distributor to route the request to an available EKM
within the plex. This provides the advantage that if one of the EKMs is down because of an
image IPL, the Sysplex distributor is aware of this situation and, acting as a primary EKM
address, can still route traffic to the remaining images still available where an EKM is actively
listening.

Plex 1 Plex 2
* IMG -A * IMG-J
* IMG -B * IMG -K
* IMG -C * I MG-L
* IMG -D * I MG-M
(VIPA Add r V1) (VIPA Ad dr V2)

IMG -A Prim EKM V1 IMG-J Prim EKM V2
Sec EKM V2 Sec EK M V1
Running EKM Running EK M

IMG -B Prim EKM V1 IMG -K Prim EKM V2
Running EKM Running EK M

IMG -C Prim EKM V1 IMG-L Prim EKM V2

IMG -D Prim EKM V1 IMG-M Prim EKM V2

Figure 5-6 VIPA Sysplex Distributor

The Sysplex Distributor example in Figure 5-6 requires that all systems have access to a
common keystore, or that if the keystores are separate, they have the same keys and EKM
configuration setup.

You have to set up procedures to keep PLEX1 and PLEX2 EKMs in sync. On PLEX1, use
SETIOS command to use the V1 address; on PLEX2 you SETIOS to use the V2 address. For
large enterprises, it is best if PLEX1 and PLEX2 are in different data centers. If there are
other Sysplexes or systems performing tape data encryption, they can all use V1 and V2 and
have uninterrupted key management capability.

When running on PLEX1, the only time you ever need to go to PLEX2 for keys is if every EKM
in PLEX1 is down. This is very rare. The benefit of this setup is after you get it up and running,
you no longer need to worry about key manager access during planned and unplanned
outages, especially outages completely unrelated to the key manager (for example, a
planned window to POWER® ON RESET (POR) a CEC that houses the z/OS image on
which the key manager runs).

Note: In an open systems environment, a common approach is to use network load
balancers and similar network hardware to enable the ability to have more available EKM
addresses than the tape libraries and virtual tape systems support.


5.3.7 Key Manager backup
Because of the critical nature of the keys in your keystore, make sure to back up this data so
that you can recover it as necessary and be able to read the tapes that were encrypted using
the certificate associated with that tape drive or library. There are many ways to back up this
keystore information. Each keystore type has its own unique characteristics, but these
general guidelines apply to all:
Use system backup capabilities, such as RACF, to create a backup copy of the keystore
information. Be careful not to encrypt this copy using the encrypting tape drives, because
it is impossible to decrypt it for recovery.
If you are using crypto hardware, be sure to copy the PKDS.
Maintain a primary and secondary EKM and keystore copy (for backup as well as failover
redundancy).
If you are using a JCEKS keystore, simply copy the keystore file and store the clear
(unencrypted) copy in a secure location, such as a vault. Be careful not to encrypt this
copy using the encrypting tape drives, because it is impossible to decrypt it for data
recovery.
Keep a copy of all certificates loaded into the keystore (usually a PKCS12 format file).

Important: Backups must not be encrypted. If the backup with the data you are recovering
is encrypted, you do not have the keystore (that is damaged) with which to get the data
back.

5.3.8 FIPS 140-2 certification
EKM does not provide cryptographic capabilities, and therefore, it does not require, nor is it
allowed to obtain, FIPS 140-2 certification. However, EKM takes advantage of the
cryptographic capabilities of the IBM JVM in the IBM Java Cryptographic Extension (IBMJCE)
component and allows the selection and use of the IBMJCEFIPS cryptographic provider,
which has a FIPS 140-2 level 1 certification. By setting the FIPS configuration parameter to
ON in the Configuration Properties file, you make EKM use the IBMJCEFIPS provider for all
cryptographic functions.

In addition to setting the FIPS parameter in the Configuration Properties file, the following
provider must be added to the java.security file in $JAVA_HOME/lib/security/:
security.provider.?=com.ibm.crypto.fips.provider.IBMJCEFIPS

You must add this provider before adding the IBMJCE provider. Renumber the providers
accordingly.

Note: You must not use hardware-based keystore types with FIPS.


5.4 Other EKM considerations
This section summarizes additional EKM implementation and migration considerations.

5.4.1 EKM Release 1 to EKM Release 2 migration
If you already have EKM Release 1 installed, you must upgrade to EKM Release 2 in order to
support LTO4 encryption. To upgrade:
1. After shutting down the EKM server, replace the Release 1 IBMKeyManagementServer.jar
with the Release 2 version.
2. Add the required Audit.metadata.file.name property to the configuration file.
3. If you are planning to support LTO4 encryption:
a. Generate and add the required symmetric keys to the keystore specified in the
config.keystore.file.name property in the configuration file. This action assumes that
the keystore that you are using will support symmetric keys.
b. Add the symmetricKeySet property to the configuration file.
4. Restart the EKM.

5.4.2 Data exchange with business partners or different platforms
A common practice is to share tapes with other organizations for joint development,
contracting services, or other purposes. To facilitate this, EKM can store two sets of wrapped
encryption keys on the tape, allowing another organization to read that specific tape without
you having to provide them any shared secret information or having to compromise the
security of your certificates and keys. This process is done by adding the public part of the
other organization’s public-private certificate and keys to your EKM’s keystore using a second
alias (or key label).

When the tape is written, the encryption keys are stored on the tape in several places and
protected by two sets of public-private keys, yours and the other organization’s. The other
organization is then able to use their EKM and their private key to unwrap the data key that
allows them to read that specific tape. To reiterate, your EKM must have the certificate of the
partner organization. The other organization must have the associated private key in the
keystore used by the other organization’s EKM. This gives you the flexibility to make a
specific tape readable by both your own organization and another organization. If you want to
take advantage of this capability, you must add that other organization’s certificate and public
key to your keystore.

5.4.3 Disaster recovery considerations
If you plan to use a disaster recovery (DR) site, EKM provides a number of options to enable
that site to read and write encrypted tapes:
Create a duplicate EKM at the DR site with the same information as your local EKM
(configuration file, tape drive table, and keystore). This EKM is then in place and capable
of taking over for one of your existing production EKMs to read and write encrypted tapes.
Create a backup copy of the three EKM data files to be able to recover as needed. If you
create a current copy of the three data elements needed by EKM (configuration file, tape
drive table, and keystore), you are able to start an EKM at any time to act as a duplicate at
the DR site. If your DR site uses different tape drives from your primary site, the
configuration file and tape drive table must contain the correct information for the DR site.


Note: Remember that you must not use the EKM to encrypt the EKM data files,
because you cannot decrypt them without a functioning EKM.

When going to DR it is standard practice to set the EKM variable
drive.acceptUnknownDrives in the configuration file to true. Refer to Chapter 6,
“Implementing EKM” on page 159 for more information.

5.4.4 i5/OS disaster recovery considerations
The following considerations apply for i5/OS disaster recovery:
The i5/OS support requires the EKM server to run on a different partition or system other
than where the encrypted save is performed. Failure to do so can result in data loss.
Prior to recovering encrypted data, the EKM must be running or recovered on another
system.
Maintaining primary and secondary EKM servers is desired for maximum availability of
encrypted backup and recovery.
The EKM and its associated data must be saved regularly without encryption.
If the keystore password is specified on the strEKM script call (and not stored in the
KeyManagerConfig.properties file), you must keep a copy of the password in a secure
location. The keystore password must be available to recover the EKM.
Encrypted save or archive operations must not be performed on the partition or system
where the EKM server is running. If data is encrypted on the system where EKM is
running, EKM cannot be recovered without the availability of a secondary EKM server.

5.4.5 EKM performance considerations
With System-Managed or Library-Managed Encryption enabled, when writing from loadpoint,
the access time to the first write from the beginning of tape increases because of the time
needed to retrieve, read, and write the encryption keys. In z/OS, this added time (which is the
time between the mount message and the IEC705I “Tape On” message) is detected in OPEN
processing.

If your EKM is on a z/OS platform, insure EKM has a Workload Manager (WLM) job priority
similar to other system services, such as VTAM® or TCP/IP. You do not want situations
where the EKM has to wait for CP cycles to return keys to access and return keystore
information, because this wait can delay processing across your enterprise.

Using Virtual IP Addressing (VIPA) in your z/OS setup can contribute to both better
performance and redundancy when running with a z/OS-based EKM. Refer to 5.3.6, “Using
Virtual IP Addressing” on page 153 for more information about this topic.

With z/OS, you might also see a longer delay when using in-band encryption if your primary
key manager is unavailable. In this case, the I/O Supervisor (IOS) Proxy Retry Logic first
attempts to communicate with the primary key manager. The IOS proxy interface might retry
several times before switching over to the secondary key manager. While the retries are
occurring, the job can appear to have stopped.

Before cancelling a job, ensure that enough time is allowed for the retry attempts that can be
occurring on the primary key manager and also the secondary key manager. Typically, each
attempt can take approximately three minutes with two retry attempts on the primary key
manager before attempting to connect to the secondary key manager.


Similar logic is then in place with the secondary key manager. After the proxy interface has
switched to the secondary key manager, it always attempts to communicate with the primary
key manager on subsequent communications; however, in this case only one (shortened)
attempt is made to communicate with the primary key manager before going back to the
secondary key manager. If the IOS proxy interface cannot communicate with the primary key
manager, even though the job might have been successful, message IOS627E is issued in
the joblog and in the system log alerting you to a potential problem with the primary key
manager.


6

Chapter 6. Implementing EKM
In this chapter, we describe the steps to take to install the Encryption Key Manager on
different host platforms.


6.1 Implementing the EKM in z/OS
The Encryption Key Manager (EKM) is a common platform application written in Java that
runs under the Java Virtual Machine (JVM). The EKM can also reside outside of the z/OS
environment. If the EKM resides within z/OS, it is part of the UNIX System Services, which is
part of the Open MVS (OMVS) address space.

The EKM interfaces with the associated keystores using application programming interfaces
(APIs). Secure TCP/IP connections are used to communicate with the tape drives (in-band or
out-of-band).

The following keystores are possible for z/OS:
JCEKS (file-based)
JCE4758KS/JECCAAKS (ICSF secure hardware)
JCE478RACKFKS/JCECCARACFKS (RACF with secure hardware)
JCERACFKS (RACF/SAF)

Software-based keystores are JCEKS and JCERACFKS. The hardware-based keystores
work with the Integrated Cryptographic Service Facility (ICSF). If the EKM resides outside of
the z/OS environment, the JCEKS software-based keystores or the PKCS11IMPLKS
hardware-based keystore will be used.

We recommend that you use more than one EKM because of redundancy. EKMs can either
share keystores or use separate keystores. For example, it is possible to have a primary EKM
running on z/OS and a secondary EKM that resides on a System p server under AIX. A
connection between them is only necessary for synchronization purposes. For more detailed
information about EKMs, refer to the IBM Encryption Key Manager component for the Java
platform, EKM Introduction, Planning, and User’s Guide, GA76-0418.

6.1.1 z/OS UNIX System Services
The System Control Program (SCP) of z/OS contains address spaces for general Multiple
Virtual Storage (MVS) and address spaces for open MVS, which is also called UNIX System
Services. When a Time Sharing Option (TSO) user logs on to the system and tries to use
UNIX System Services, the appropriated UNIX System Services address space will be
created.

In-band tape data encryption requires that the I/O Supervisor (IOS) address space has
security permissions for a UNIX System Service segment. Security permissions can be
obtained in RACF by issuing the following command:
ADDUSER IOSSAS OMVS(UID(0) HOME(’/’))

If a UNIX System Services segment is unavailable at the time of tape data encryption, the
following message appears:
IOS628E ENCRYPTION ON DEVICE dddd HAS FAILED DUE TO OMVS SEGMENT FAILURE

Note: The UID does not need to be 0, but this user ID does need an OMVS segment.
Changes to the IOSAS user ID require an IPL to be recognized. IOSAS is only used by the
I/O Supervisor (IOS) component and must be defined as protected, so giving it UID(0)
works fine.

It is assumed that the UNIX System Services address space is already present. Refer to
UNIX System Services z/OS Version 1 Release 7 Implementation, SG24-7035, for more


information about how to install and tailor UNIX System Services in z/OS.
To ensure that an UNIX System Services address space is up and running, use the /D A,L
MVS command as shown in Figure 6-1.

Figure 6-1 The OMVSEX address space is present

If the UNIX System Services address space is present, the OMVSEX for OMVS is shown.

6.1.2 Installing the EKM in z/OS
The EKM is automatically installed as part of the IBM Java Developer Kit (JDK).

To download the latest version of the IBM EKM, go to either:
http://www.ibm.com/servers/storage/support/tape/ts1120/downloading.html
http://www-947.ibm.com/systems/support/supportsite.wss/brandmain?brandind=5000034

You may download the IBM 31-bit Software Developer Kit (SDK) for z/OS Java 2 Technology
Edition from the following Web site:
http://www.ibm.com/servers/eserver/zseries/software/java/j5pcont31.html

Note: Before you can download the latest version of the IBM SDK, you must register your
company or yourself to give IBM statistics for a comparative look at which SDKs are being
downloaded.

In ISPF or TSO, use either of the following steps:
Select Option 6, select Commands, and type OMVS, and then press Enter.
Run the telnet/rlogin, ssh command into an OMVS session.

Chapter 6. Implementing EKM 161

Use a File Transfer Protocol (FTP) and copy the file into file system. Then, extract the file into
/usr/lpp/java by using the following command:
pax -rf UK17593.PAX.Z

To verify that the correct version of the EKM was installed, use the following command at the
OMVS command prompt:
/u/st6t25c>java -version

The information shown in Example 6-1 appears.

Example 6-1 Output from java -version
JVMHP030: Unable to switch to IFA processor - issue "extattr +a libhpi.so"
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2)
Classic VM (build 1.4.2, J2RE 1.4.2 IBM z/OS Persistent Reusable VM build
cm142-20060921 (JIT enabled: jitc))

The following error has to do with the way that we executed the pax command:

JVMHP030: Unable to switch to IFA processor - issue "extattr +a libhpi.so"

The command did not keep all the file attributes upon inflating the JDK pax file. This error
means that the JDK does not have authority to run on the zAAP processor. To fix the
problem, issue:
extattr +a $JAVA_HOME/bin/libhpi.so

Issuing the java -version command gives you output similar to Example 6-2.

Example 6-2 Output from java version with fixed libhpi.so attributes
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2)
Classic VM (build 1.4.2, J2RE 1.4.2 IBM z/OS Persistent Reusable VM build
cm142-20060921 (JIT enabled: jitc))

Download and install the latest EKM server code. Obtain the EKM code and documentation
from:

After downloading the new EKM code, place it in the $JAVA_HOME/lib/ext folder. If your
environment variables are set up correctly and the EKM program code is in the working
directory, simply enter the following command to copy it:
cp IBMKeymanagerServer.jar $JAVA_HOME/lib/ext

At this point, the installation of the EKM for z/OS is already complete.

Note: You cannot start the EKM without an associated keystore.

The IBM Encryption Key Manager component for the Java platform, EKM Introduction,
Planning, and User’s Guide, GA76-0418, provides additional information.

To perform the installation steps necessary to use EKM, special authorization rights are
required; for example, the RACDCERT command must be enabled for the OMVS segment. In


the following sections, we create hardware-related keystores as well as software-based
keystores. In Chapter 8, “EKM operational considerations” on page 275, you can read about
types of keystores and their usage. In the following sections, we create a hardware keystore.

EKM does not provide cryptographic capabilities and therefore it does not require and is not
allowed to obtain FIPS 140-2 certification. However, EKM takes advantage of the
cryptographic capabilities of the IBM JVM in the IBM Java Cryptographic Extension
component and allows the selection and use of the IBMJCEFIPS cryptographic provider,
which has a FIPS 140-2 level 1 certification. By setting the FIPS configuration parameter to
ON in the Configuration Properties file, you make EKM use the IBMJCEFIPS provider for all
cryptographic functions.

In addition to setting the FIPS parameter in the Configuration properties file, the following
provider must be added to the java.security file:
$JAVA_HOME/lib/security/security.provider.?=com.ibm.crypto.fips.provider.IBMJCEFIPS

Add this line before the IBMJCE provider. Renumber the providers accordingly.

Note: We do not recommend that you use hardware-based keystore types with FIPS.

6.1.3 Security products involved: RACF, Top Secret, and ACF2
In-band tape data encryption requires that the I/O Supervisor (IOS) address space has
security permissions for the UNIX System Services segment.

Note: The user ID (UID) in the following command examples does not have to be 0 (zero),
but it does require an OMVS segment. Changes to the IOSAS user ID require an IPL to be
recognized. IOSAS is only used by the IOS component and must be defined as protected,
so giving it UID(0) works fine.

RACF
Security permissions can be obtained from RACF by issuing the following command:
ADDUSER IOSAS OMVS(UID(0) HOME('/'))

Top Secret
Top Secret is a security product provided by Computer Associates. Security permissions can
be obtained from Top Secret by issuing the following command:
TSS ADD(IOSAS) UID(0) HOME(’/’)

Refer to the appropriate documentation for eTrust CA-Top Secret Security for z/OS.

ACF2
ACF2 is a security product provided by Computer Associates. Security permissions can be
obtained from ACF2 by issuing the following command:
INSERT IOSAS NAME(ID IOSAS) UID(0) HOME

Refer to the appropriate documentation for eTrust CA-ACF2 Security for z/OS.


6.1.4 Create a JCE4758RACFKS for EKM
In this section, we create a JCE4758RACFKS. We use it later as the keystore for EKM
initialization. This is the most secure of the keystores. Access to the keyring is protected by
RACF administration, and private key material is stored in a PKDS that is protected by
cryptographic hardware.

Chapter 7, “Planning and managing your keys” on page 227 discusses this keystore type.

The RACF commands in Example 6-3 define the FACILITY classes necessary to use the
RACDCERT commands to create and work with keyrings and certificates.

Example 6-3 Defining irr.digtcert facility classes
RDEFINE FACILITY IRR.DIGTCERT.ADD UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.ADDRING UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.DELRING UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.CONNECT UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.REMOVE UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.LIST UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.ALTER UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.DELETE UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.GENCERT UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.GENREQ UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.EXPORT UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.EXPORTKEY UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.MAP UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.ALTMAP UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.DELMAP UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.LISTMAP UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.ROLLOVER UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.REKEY UACC(NONE)

The commands in Example 6-4 give user CONTROL access to all the FACILITY classes that
deal with the RACDCERT command. The CONTROL access gives the user full access to
administer everything that concerns the RACDCERT command.

To develop a more restrictive security policy, refer to the description of the RACDCERT
command in 6.1.7, “Additional definitions of hardware keystores for z/OS” on page 174.

Example 6-4 PERMIT commands

PERMIT IRR.DIGTCERT.ADD CLASS(FACILITY) ID(user) ACCESS(CONTROL)
PERMIT IRR.DIGTCERT.ALTER CLASS(FACILITY) ID(user) ACCESS(CONTROL)
PERMIT IRR.DIGTCERT.DELETE CLASS(FACILITY) ID(user) ACCESS(CONTROL)
PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ID(user) ACCESS(CONTROL)
PERMIT IRR.DIGTCERT.ADDRING CLASS(FACILITY) ID(user) ACCESS(CONTROL)
PERMIT IRR.DIGTCERT.DELRING CLASS(FACILITY) ID(user) ACCESS(CONTROL)
PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ID(user) ACCESS(CONTROL)
PERMIT IRR.DIGTCERT.CONNECT CLASS(FACILITY) ID(user) ACCESS(CONTROL)
PERMIT IRR.DIGTCERT.REMOVE CLASS(FACILITY) ID(user) ACCESS(CONTROL)
PERMIT IRR.DIGTCERT.MAP CLASS(FACILITY) ID(user) ACCESS(CONTROL)
PERMIT IRR.DIGTCERT.LISTMAP CLASS(FACILITY) ID(user) ACCESS(CONTROL)
PERMIT IRR.DIGTCERT.ALTMAP CLASS(FACILITY) ID(user) ACCESS(CONTROL)
PERMIT IRR.DIGTCERT.DELMAP CLASS(FACILITY) ID(user) ACCESS(CONTROL)
PERMIT IRR.DIGTCERT.REKEY CLASS(FACILITY) ID(user) ACCESS(CONTROL)
PERMIT IRR.DIGTCERT.ROLLOVER CLASS(FACILITY) ID(user) ACCESS(CONTROL)


Example 6-5 shows how to export a certificate reply and how to import the certificate
response back into a keyring. RACDCERT commands used in Example 6-5 perform the
following actions:
Creates a new self-signed certificate authority (CA) with a key size of 2048, private key
information created with crypto-hardware, and that is stored in the active PKDS. The label
of this CA is CAexample.
Creates two personal certificates with labels of ITSOCert1 and ITSOCert2, size of 2048,
signed with our CA, with private keymaterial created with crypto-hardware, and stored in
the active PKDS.
Imports a PKCS12 certificate from the data set johann.private.key1 and store its private
keymaterial in a PKDS. The PCICC keyword cannot be used, because we are only
importing keys and not generating them.
Creates a new keyring ITSOring.
Connects the CA to the ring and the three personal certificates.

If a third-party certificate verification and response are required, refer to:
7.5, “JCE4758RACFKS and JCECCARACFKS” on page 248
http://publibz.boulder.ibm.com/epubs/pdf/ichza460.pdf

Example 6-5 RACDCERT commands to create and import certificates and add them to a keyring
RACDCERT CERTAUTH GENCERT SUBJECTSDN(CN('ITSOEX')O('IBM')C('US')) PCICC
WITHLABEL('CAexample') SIZE(2048)

RACDCERT GENCERT SUBJECTSDN(CN('ITSO') O('IBM') C('US')) PCICC
WITHLABEL('ITSOCert1') SIZE(2048) SIGNWITH(CERTAUTH LABEL('CAexample'))

RACDCERT GENCERT SUBJECTSDN(CN('ITSO') O('IBM') C('US')) PCICC
WITHLABEL('ITSOCert2') SIZE(2048) SIGNWITH(CERTAUTH LABEL('CAexample'))

RACDCERT ADD('johann.private.key1') TRUST
WITHLABEL('ITSOImport')password('password') ICSF

RACDCERT ADDRING(ITSOring)
RACDCERT CONNECT(CERTAUTH LABEL('CAexample') RING(ITSOring))

RACDCERT CONNECT(LABEL('ITSOCert1') RING(ITSOring) USAGE(PERSONAL) DEFAULT)
RACDCERT CONNECT(LABEL('ITSOCert2') RING(ITSOring) USAGE(PERSONAL))
RACDCERT CONNECT(LABEL('ITSOImport') RING(ITSOring) USAGE(PERSONAL))

These commands associate the keyring and personal certificates with the user executing
them. To associate them with another user, append the ID(user) keyword after the
RACDCERT command.

Tip: Be careful when cutting and pasting commands into a TSO session. When we tested
cutting and pasting commands into a TSO session, the single quotation marks were
stripped off.


6.1.5 Setting up the EKM environment
For this example, we assume that the user ID EKM is going to run on EKMSERV and that the
UNIX System Services home directory for this user is /u/ekmserv. To create this user, issue
the following command:
AU EKMSERV DFLTGRP(SYS1) OMVS(AUTOUID HOME(/u/ekmserv)PROGRAM(/bin/sh))
NOPASSWORD NOOIDCARD

This command creates the user ID EKMSERV, sets up its home directory to /u/ekmserv, sets
the default shell to /bin/sh, and associates it with the next available UID. If a more strict
security policy is in effect, the RACF administrator must replace the AUTOUID with
UID(UserIDNumber). Avoid using UID 0.

In addition, this user will need access to the IRR.DIGTCERT.* facility classes as described in
Example 6-4 on page 164 in section 6.1.4, “Create a JCE4758RACFKS for EKM” on
page 164.

Before continuing, download and save the following items to /u/ekmserv/:
IBM EKM application
IBM EKM sample configuration file
JZOSEKM files for z/OS batch

Download them from:
http://www-1.ibm.com/support/docview.wss?rs=0&dc=D400&q1=ekm&uid=ssg1S4000504&loc=
en_US&cs=utf-8&cc=us&lang=en

We first have to make sure that the ekmserv ID has an acceptable profile file. In /u/ekmserv,
edit the .profile file so it looks like the sample profile shown in Example 6-6 on page 167.

In the example, note the following process:
1. The stty quit ^V line must be included in a profile when logging on to OMVS using
Secure Shell (SSH). The export PS1 line is setting up this user’s command line. In this
case, we are setting up the command line to always list the current working directory. This
setting is useful to have when navigating around an OMVS file system.
2. After that, we set up the JAVA_HOME environment variable. This variable has to point to the
Java home on your system. Next, we add JAVA_HOME/bin to our path in addition to other
useful directories. Notice that we are careful to keep our original path here by appending it
to our new PATH.
3. We create an environmental shorthand. When using OMVS as the shell, and not logging
on using Telnet, rlogin, or SSH, we have a limited length command line. The arguments to
start EKM and perform Java hwkeytool commands might be longer than the command
line; by setting some of these long parameters as environment variables, we can save
space on our limited command line.


Example 6-6 Sample .profile
stty quit ^V
export PS1='$PWD>';
export JAVA_HOME=/u/java/J1.4
export PATH=.:${JAVA_HOME}/bin:/usr/sbin:$PATH
export DJ='-J-Djava.protocol.handler.pkgs=com.ibm.crypto.provider -v'
export DH='-J-Djava.protocol.handler.pkgs=com.ibm.crypto.hdwrCCA.provider -v'
export DT='-Djava.protocol.handler.pkgs=com.ibm.crypto.hdwrCCA.provider'
export JS='-Djava.protocol.handler.pkgs=com.ibm.crypto.hdwrCCA.provider'
alias kt="keytool -debug -list -storetype JCERACFKS -keystore"
alias hw="hwkeytool -debug -list -storetype JCE4758RACFKS -keystore"
export keyFile=KeyManagerConfig.properties
export EKM=com.ibm.keymanager.KMSAdminCmd

After setting up the profile, we can reread it with either of the following methods:
Type the following command:
. ./.profile
Log out and log in again, which executes the .profile again.

Now, we must copy the updated EKM. This command copies the EKM program code into
JAVA_HOME/lib/ext. The JARs in the lib/ext directory are all loaded into the JVM’s
classpath. A simple listing of that directory reveals security provider JAR files among other
things:
cp IBMKeyManagementServer.jar $JAVA_HOME/lib/ext

The JZOS EKM files have to be extracted. Enter the command:
pax -rf JZOSEKMFiles.pax.Z

This command extracts the files:
PROCLIB.EKM2ENV
README
jzosekm.jar
PROCLIB.EKM2

The file jzosekm.jar contains Java wrapper code for the EKM. To interact with the EKM
using write to operator (WTO), we must register a callback using APIs from the JZOS toolkit.
The program code contained in this JAR does that for us. To ensure that this code is in our
classpath, we copy it to lib/ext:
cp jzosekm.jar $JAVA_HOME/lib/ext

The EKM config file KeyManagerConfig.properties is now edited with our information. In
Example 6-7 on page 168, we have turned on extra tracing and debugging information.


Example 6-7 Sample EKM config

TransportListener.ssl.port = 4430
TransportListener.tcp.port = 38010
fips = Off
Admin.ssl.keystore.name = safkeyring://ST6T25B/ITSOring
config.keystore.provider = IBMJCE4758
Admin.ssl.truststore.password = passphrase
TransportListener.ssl.clientauthentication = 0
config.keystore.password = password
TransportListener.ssl.ciphersuites = JSSE_ALL
Audit.handler.file.size = 500
zOSCompatibility = true
drive.acceptUnknownDrives = true
TransportListener.ssl.truststore.name = safkeyring://ST6T25B/ITSOring
Audit.handler.file.directory = keymanager/audit
TransportListener.ssl.protocols = SSL_TLS
debug.output = simple_file
TransportListener.ssl.truststore.type = jce4758racfks
config.keystore.file = safkeyring://ST6T25B/ITSOring
TransportListener.ssl.keystore.name = safkeyring://ST6T25B/ITSOring
TransportListener.ssl.keystore.password = passphrase
TransportListener.ssl.truststore.password = passphrase
Audit.event.outcome.do = success,failure
Audit.eventQueue.max = 0
debug.output.file = keymanager/debug/ekmdebug.jce
Audit.handler.file.name = ekm.audit.log
TransportListener.ssl.keystore.type = jce4758racfks
config.keystore.type = jce4758racfks
requireHardwareProtectionForSymmetricKeys = true
Audit.event.types.backup = authentication,authorization,data
synchronization,runtime,audit management,authorization terminate,configuration
management,resource management,none
drive.default.alias2 = itsocert1
drive.default.alias1 = itsocert2
Audit.event.outcome = success,failure
debug = all
Audit.event.types = all
Admin.ssl.truststore.name = safkeyring://ST6T25B/ITSOring
config.drivetable.file.url = FILE:////keymanager/drivetab
Admin.ssl.keystore.password = passphrase

At this point, we must create several directories. Example 6-8 on page 169 shows the
commands and directories that we have to create. These commands and directories are
relative to the path where we are starting the EKM server. In this case, they are relative to
/u/ekmserv/.

The debug.output.file option points to a file. You will get java.io.permission errors if the
assumption is made that it points to a directory. If the file does not exist, EKM creates it, but
the file cannot point to a directory.


Example 6-8 Create directories

mkdir keymanager
mkdir keymanager/debug/
mkdir keymanager/audit

After setting this up, we can verify that our EKM can be started and load keys from our keyring
by issuing the following command (use this command if you use the .profile from Example 6-6
on page 167):
java $DT $EKM $keyFile

The expanded command is:
java -Djava.protocol.handler.pkgs=com.ibm.crypto.hdwrCCA.provider
com.ibm.keymanager.KMSAdminCmd KeyManagerConfig.properties

If this command is too long, refer to “MVS Open Edition tips” on page 570.

Tip: To verify that the EKM server has sufficient authority, the following hwkeytool
command can be issued from OMVS:
hwkeytool -debug -J-Djava.protocol.handler.pkgs=com.ibm.crypto.hdwrCCA.provider -list
-keystore safkeyring://USERID/ITSOring -storetype JCE4758RACFKS

The provider list in the java.security file located in the path
$JAVA_HOME/lib/security/java.security must contain the following providers:
security.provider.1=com.ibm.jsse.IBMJSSEProvider
security.provider.2=com.ibm.crypto.hdwrCCA.provider.IBMJCE48758
security.provider.3=com.ibm.crypto.provider.IBMJCE
security.provider.4=com.ibm.security.cert.IBMCertPath

6.1.6 Starting EKM
You can start the EKM by using a procedure or through commands. We discuss both options
in the following sections.

Starting EKM with JZOS as a started task
A z/OS started task is a procedure that consists of a set of job control language statements
that are frequently used together to achieve a certain result. Procedures usually reside in the
system procedure library, SYS1.PROCLIB, which is a partitioned data set. A started
procedure is usually started by an operator, but it can be associated with a functional
subsystem.

We suggest that the EKM run as a started procedure on z/OS using the JZOS batch
launcher, which is shipped as part of the z/OS Java product. Refer to “EKM and JZOS” on
page 567 for more information.

To define the EKM as a started procedure, update the started class table with the z/OS user
ID of the EKM. Previously in this section, we created EKMSERV as the user ID to be used
with the EKM and the group associated with that started procedure will be SYS1. Details of
RACF processing and the definition of started procedures are discussed in the z/OS Security
Server RACF Security Administrator’s Guide, SA22-7683.

To set up the STARTED class, enter the commands in Example 6-9 on page 170.


Example 6-9 Define EKM as a started task

SETROPTS GENERIC(STARTED)
RDEFINE STARTED EKM*.* STDATA(USER(EKMSERV) GROUP(STCGROUP) TRACE(YES))
SETROPTS CLASSACT(STARTED) SETROPTS RACLIST(STARTED)

The JZOSEKMFiles.pax.Z file downloaded in the beginning of this section consists of
jzosekm.jar, sample JCL, the STDENV file for the sample JCL, and a EKMConsoleWrapper.
Use the readme file that explains where each file must be located and the installation-specific
customization that might be required.

To extract the contents of the download file, issue the following command:
pax -rf JZOSEKMFiles.pax.Z

Place the jzosekm.jar file in the $JAVA_HOME/J1.4/lib/ext path.

The EKM can create audit records, which wrap the log to three files. When the last file is full,
the first file is rewritten. On z/OS, you need to allocate file system space for the EKM audit
logs, and possibly, the EKM debug log.

You may choose to allocate a file system specifically for use by the EKM for audit and debug
file storage. Assume 500 cylinders of space to allocate to the EKM’s audit and debug log file
system until you have observed, based on tape and EKM activity, how quickly the audit logs
wrap. The file system must not be shared by the EKM instances running in a Sysplex
environment, but the files must be private to each EKM instance. This setup prevents any
possible interleaving of audit or debug logs between EKM instances.

Mount the ekmlogs filesystem and create a directory for each system on which EKM will run.
For example, the two file systems created can be ekmlogs with JA0 and JB0 for two system
names of two images within a Sysplex:
/ekmlogs/JA0
/ekmlogs/JB0

Create a new partitioned data set (PDS) to contain the STDENV environment variables. In
this example, a partitioned data set was allocated with the name EKMSERV.ENCRYPT.CONFIG
that has the following attributes:
Organization PO
Record format FB
Record length 80
Block size 6160
First extent cylinders 3
Secondary cylinders 1

Create a member in EKMSERV.ENCRYPT.CONFIG named EKM2ENV. Create or Edit the shell
script contents as shown in Example 6-10.

Example 6-10 EKM environment script

# This is a shell script which configures
# any environment variables for the Java JVM.
# Variables must be exported to be seen by the launcher.

#Set these variables to the installation unique values
# EKM_HOME = directory from where EKM runs
# JAVA_HOME = directory where Java is mounted


#Update to point to your EKM Home directory
export EKM_HOME="/u/ekmserv"
#Update to point to your JDK
export JAVA_HOME="/u/java/J1.4"
export PATH=/bin:"${JAVA_HOME}"/bin:

LIBPATH=/lib:/usr/lib:"${JAVA_HOME}"/bin:"${JAVA_HOME}"
LIBPATH="$LIBPATH":"${JAVA_HOME}"/bin/classic

export LIBPATH="$LIBPATH":

# Customize your CLASSPATH here
CLASSPATH=${JAVA_HOME}/lib
CLASSPATH=$CLASSPATH:"${EKM_HOME}"

export CLASSPATH="$CLASSPATH":

# Set JZOS specific options
#Update with location of config data
export keyFile="KeyManagerConfig.properties"
#The EKM main class
export ekmClass="com.ibm.keymanager.KMSAdminCmd"
export JZOS_MAIN_ARGS="$XXXX $ZZZZ"

# Configure JVM options (if any)
#Uncomment this only for JCERACFKS
#IJO="-Djava.protocol.handler.pkgs=com.ibm.crypto.hdwr.provider"
#Uncomment this only for JCE4758RACFKS
IJO="-Djava.protocol.handler.pkgs=com.ibm.crypto.hdwrCCA.provider"
# for jceks and jce4758ks/jceccaks, no IJO definition is required.
# comment them out

export IBM_JAVA_OPTIONS="$IJO "

#export JAVA_DUMP_HEAP=false
#export JAVA_PROPAGATE=NO
#export IBM_JAVA_ZOS_TDUMP=NO
env

Customize the sample procedure in Example 6-11 for your system.

Example 6-11 Start procedure

//EKM PROC JAVACLS=’com.ibm.jzosekm.EKMConsoleWrapper’,
// ARGS=, < Args to Java class
// LIBRARY=’SYS1.SIEALNKE’, < STEPLIB FOR JVMLDM module
// VERSION=’14’, < JVMLDM version: 14, 50, 56
// LOGLVL=’+T’, < Debug LVL: +I(info) +T(trc)
// REGSIZE=’0M’, < EXECUTION REGION SIZE
// LEPARM=’’
//*********************************************************************
//*
//* Stored procedure for executing the JZOS Java Batch Launcher
//* Specifically, to execute the Enterprise Key Manager under JZOS
//*
//*********************************************************************
//EKM EXEC PGM=JVMLDM&VERSION,REGION=&REGSIZE,
// PARM=’&LEPARM/&LOGLVL &JAVACLS &ARGS’
//STEPLIB DD DSN=&LIBRARY,DISP=SHR


//SYSPRINT DD SYSOUT=* < System stdout
//SYSOUT DD SYSOUT=* < System stderr
//STDOUT DD SYSOUT=* < Java System.out
//STDERR DD SYSOUT=* < Java System.err
//CEEDUMP DD SYSOUT=*
//ABNLIGNR DD DUMMY
//*********************************************************************
//* The following member contains the JVM environment script
//*********************************************************************
//STDENV DD DSN=EKMSERV.ENCRYPT.CONFIG(EKM2ENV),DISP=SHR
//*

Starting EKM with a command
The EKM process can now be started with the operator start command as a started task.
The following command starts the EKM server:
S EKMSERV

In Figure 6-2, we have started the EKM as a job using JZOS. We can see the “Loaded drive
keystore” message and that EKM is in fact up, running, and communicating with the console.

Figure 6-2 EKM Start message

If we execute the following command, the message shown in Figure 6-3 on page 173
displays:
f EKMSERV,appl=’status’


Figure 6-3 EKM Status

We can also list how many certificates were loaded into the EKM by executing:
f EKMSERV,appl=’listcerts’

The output from this command is listed in Figure 6-4 on page 174.


Figure 6-4 EKM certificate list

For a complete listing of EKM commands, refer to 8.1, “EKM commands” on page 276.

Note: A RACF keyring must have a CA certificate and a personal certificate connected to it
in order for EKM to load the keystore. If it does not a CertPath error occurs and EKM fails
to start. The personal certificate does not need the whole certificate chain; however, it is
good practice to always connect the whole chain to the ring.

In this example, note that our EKM is running its SSL listener on port 4430. WebSphere®
might use port 4430 for SSL processing, so we changed the port so EKM does not collide
with WebSphere SSL processing.

The following section describes the use of keystores.

6.1.7 Additional definitions of hardware keystores for z/OS
This section describes the most secure keystore with a keyring using JCE4758RACFKS or
JCECCARACFKS.

The following additional examples show sequences of RACF commands where certificates
and keystores are created. The keyring is named ULIRING and the certificate is named
ULICERT1.

In Example 6-12 on page 175, we create a keyring with the name ULIRING.


Example 6-12 Creating a keyring
RACDCERT ADDRING(ULIRING)

In Example 6-13, we create a self-signed certificate authority (CA) called ULICA.

Example 6-13 Creating a self-signed certificate authority

RACDCERT GENCERT CERTAUTH SUBJECTSDN(CN('ULICA') OU('ITSO')O('IBM') L('TUCSON')
SP('AZ') C('USA')) ICSF WITHLABEL('ULICA')

In Example 6-14, we allow the generation of a personal certificate signed to the CA that was
previously generated.

Example 6-14 Generating a personal certificate
RACDCERT GENCERT SUBJECTSDN(CN('ULICERT1') OU('ITSO') O('IBM')L('TUCSON') SP('AZ')
C('USA')) ICSF WITHLABEL('ULICERT1') SIGNWITH(CERTAUTH LABEL('ULICA') )

In Example 6-15, we connect the certificate authority to the keyring.

Example 6-15 Connecting the certificate authority to the keyring
RACDCERT CONNECT(CERTAUTH LABEL('ULICA') RING(ULIRING) USAGE(CERTAUTH))

In Example 6-16, you find the definition for a key label called ULICERT1.

Example 6-16 Defining a key label
RACDCERT CONNECT(LABEL('ULICERT1') RING(ULIRING) USAGE(PERSONAL) DEFAULT)

In Example 6-17, we create an additional key label with the name ULICERT2, which is
needed later for a second key label statement in the JCL.

Example 6-17 Creating an additional key label
RACDCERT CONNECT(LABEL('ULICERT2') RING(ULIRING) USAGE(PERSONAL) DEFAULT)

In Example 6-18, we show an RACF command where we delete a key label with the name
ULICERT3.

Example 6-18 Deleting a key label
RACDCERT DELETE (LABEL('ULICERT3'))

In Example 6-19, the command deletes a keyring.

Example 6-19 Deleting a keyring
RACDCERT DELRING(ULIRING)

6.1.8 Virtual IP Addressing
In TCP/IP networking, Internet Protocol (IP) addresses are typically assigned to physical
network interfaces. If a server has two physical interfaces, a separate IP address is assigned
to each of them. IBM introduced the concept of Virtual IP Addressing (VIPA) for its z/OS
environment in order to support the use of IP addresses representing TCP/IP stacks,


applications, or clusters of applications that are not tied to any specific physical interface. The
association between a VIPA and an actual physical interface is subsequently accomplished
using either the Address Resolution Protocol (ARP) or dynamic routing protocols (such as
OSPF). For details, refer to Communications Server for z/OS V1R7 TCP/IP Implementation,
Volume 3 High Availability, Scalability, and Performance, SG24-7171.

The TCP/IP infrastructure, including any VIPA definitions, is transparent to the EKM. That is,
the EKM does not have to know that it was reached using a VIPA. So, the only place that has
to be configured to take advantage of a VIPA installation is IECIOSxx by using the VIPA IP
address instead of the system host name. In an out-of-band solution, the device is configured
to the VIPA address instead of the direct host name of the EKM. Therefore, it is probably a
good idea to ensure that the EKMs that are behind the VIPA addresses in a Sysplex all point
to the same keystore, or at the very least, that the same keys under the same labels exist in
the keystores that you are using.

Note: We show an example of the IECIOS PARMLIB member that includes the EKM
definitions in 12.6.2, “Update PARMLIB member IECIOSxx” on page 395.

6.1.9 EKM TCP/IP configuration
Most often, the definitions described in 6.1.8, “Virtual IP Addressing” on page 175 are
sufficient. However, if you have a large environment and want to use automatic backup
solutions for EKM in a complex Sysplex environment, the hints appended to the commands
can help give you an idea of how to define a solution. TCP/IP experienced and trained
personnel will be able to define this type of structure.

All of the TCP/IP configuration, including VIPAs, is done in the TCP/IP profile. For all images
that are running the EKM, the following information is required in the profile:
Ports 3801 and port 1443 must be reserved in the PORT section:
PORT
1443 TCP EKM ;Key Manager SSL
3801 TCP EKM ;Key Manager
If a port is already being used, the option SHAREOPT must be added to each of the
applications using the port. For example:
PORT
1443 TCP EKM SHAREOPT ;Key Manager
1443 TCP IMWEB SHAREOPT ;Web Server
EKM can also be started when TCP/IP starts up by adding it to the AUTOLOG section.
For example:
AUTOLOG
EKM ;Key Manager
ENDAUTOLOG

The following description is for a 10-way Sysplex with EKM running on most of the images.
A Sysplex Distributor was configured using distributed VIPAs. The Sysplex Distributor
distributes each key request based on the Workload Manager (WLM), if configured that way,
to the appropriate stack/image. In case of a stack failure, WLM moves the Sysplex Distributor
to another image where the requests will be handled. The backup stack has to be configured
in the TCP/IP profile.


To set up a Sysplex Distributor:
1. Ensure you have a dynamic cross-system coupling facility (XCF) component; it is
required. This is the path that is used for the requests through the Sysplex Distributor:
IPCONFIG DYNAMICXCF 192.168.49.30 255.255.255.03
Do this on all images where the Sysplex Distributor might be the backup.
2. Define the required DVIPA parameters in the VIPADYNAMIC section of the profile:
VIPARANGE DEFINE 255.255.255.255 9.xxx.xxx.xxx;keystore
3. Define where the requests will be distributed that are sent to the DVIPA 9.xxx.xxx.xxx.
This definition might look like the following example:
VIPADEFINE MOVEABLE IMMED 255.255.255.0 9.xxx.xxx.xxx
VIPADISTRIBUTE DEFINE SYSPLEX DISTM ROUNDROBIN 9.xxxxxxxxx PORT 3801 1443
DESTIP ALL
ENDVIPADYNAMIC
The described definitions tell you that all requests that come to DVIPA address
9.xxx.xxx.xxx Port 3801 or Port 1443 are to be sent to all images in the Sysplex that are
configured to accept requests (dynamic XCF setup).
4. For the images that were configured as backup, you should have dynamic XCF EKM
running. The following example, tells the Sysplex which DVIPAs you are backing up:
VIPADYNAMIC
VIPABACKUP 9.xxx.xxx.xxx
ENDVIPADYNAMIC

Example 6-20 shows a complete definition example.

Example 6-20 Definition example
IPCONFIG SYSPLEXROUTING DYNAMICXCF 193.9.200.4 255.255.255.240.1
VIPADYNAMIC
VIPADEFINE 255.255.255.192 9.67.240.02
VIPADISTRIBUTE DEFINE 9.67.240.02 PORT 3801 1443 DESTIP
193.9.200.2
193.9.200.4
193.9.200.6
ENDVIPADYNAMIC

6.2 Installing EKM on AIX
In this section, we describe the steps necessary to install the EKM in the AIX environment.
We refer to the IBM Encryption Key Manager component for the Java platform, EKM
Introduction, Planning, and User’s Guide, GA76-0418, to install the EKM on our AIX server.

6.2.1 Install the IBM Software Developer Kit (SDK)
In the following section, we describe how to install the IBM Software Developer Kit (SDK) for
AIX and other UNIX operating systems. We downloaded the Java Runtime Environment from
the IBM developerWorks® Web site. And, we created the required directories and installed
the Java Runtime Environment.


To install the SDK:
1. Download the SDK from the following Web site (which is reflected in Figure 6-5):
http://www.ibm.com/developerworks/java/jdk/aix/service.html

Figure 6-5 Java code Web site

We selected and downloaded the Java 5, 32-bit Runtime Environment to our personal
computer.
2. Create a new directory.
We created a directory named /usr/lpp/java5 and used FTP to get the j532redist.tar
file to that directory, as shown in Example 6-21.

Example 6-21 New directory with Java code
/usr/lpp/java5>ls
j532redist.tar
/usr/lpp/java5>

3. Run the tar -xvf j532redist.tar command. The remainder of the Java runtime
directory tree is built as shown in Example 6-22.

Example 6-22 After tar of Java runtime library
/usr/lpp/java5>ls
j532redist.tar license sdk

/usr/lpp/java5>ls sd*
COPYRIGHT bin docs fixes.html include jre lib


4. Edit the /home/root/.profile file, so that the JAVA_HOME, P8, P9, and CLASSPATH
statements reflect the correct directories. Refer to Example 6-23.

Example 6-23 .profile file
/home/root>vi .profile
#NAME .profile
JAVA_HOME=/usr/lpp/java5/sdk/jre
#JAVA_HOME=/usr/java14/sdk/jre
P8=/usr/lpp/java5/sdk/jre/bin
P9=/usr/lpp/java5/sdk/bin
CLASSPATH=/usr/lpp/java5/sdk/jre/lib
PATH=$JAVA_HOME:$P1:$P2:/etc:$P3:$HOME:$P4:$P5:$P6:$P7:$P8:$P9:.

5. Ensure that JAVA_HOME was set correctly. Because we use BASH as a shell, we
checked the .bashrc file to ensure that JAVA_HOME was set correctly, as shown in
Example 6-24.

Example 6-24 .bashrc profile
export JAVA_HOME=/usr/lpp/java5/sdk

6. Log off and log in again.
7. Determine the Java version.
We issued the java-version command, the results of which are in Example 6-25. In
addition to the logout and login process, you can also execute the profile using the
following command:
. ./.profile

Example 6-25 Java version command results
/home/root>java -version
Java(TM) 2 Runtime Environment, Standard Edition (build pap32dev-20060511 (SR2))
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 AIX ppc-32 j9vmap3223-20060504 (JIT enabled)
J9VM - 20060501_06428_bHdSMR
JIT - 20060428_1800_r8
GC - 20060501_AA)
JCL - 20060511a
/home/root>

8. Ensure the correct directories are used.
We used the echo $JAVA_HOME command, the results of which are in Example 6-26, to
ensure that the correct directories are used.

Example 6-26 The echo command results
/home/root>echo $JAVA_HOME
/usr/lpp/java5/sdk
/home/root>

9. Install policy files.
At this point in the installation, we installed only the restricted policy files. However, the
EKM requires that the unrestricted policy files are installed in the JVM, before the EKM is
able to generate keys. You must do this installation step after the installation of the Java
code, otherwise, EKM is not able to serve keys.


10.Use the JRE 1.4.2 files. These files are different from the JRE 1.4.1 files. The JRE 1.4.2
files can also be used for JRE 5. The .zip file must be unpacked and the two JAR files
placed in the JRE’s jre/lib/security/ directory, replacing the existing files of the same name.
These policy files are for use with Software Developer Kits (SDKs) that were developed by
IBM.
Here are the steps we followed to replace the policy files. Begin by pointing your browser
to the following Web site:
a. Sign in. You are directed to a location where you can download the Unrestricted JCE
Policy files for SDK 1.4.
b. Download the unrestricted policy files for 1.4.2 SDK (these are also the files for SDK
5.0). The result is a file called unrestrict.zip. You can unzip this using the pkzip, tar,
or jar command.
c. Remove the files local_policy.jar and US_export_policy.jar from the
jrelibsecurity directory.
d. Put the new files from the .zip file into the jrelibsecurity directory. The files have
the same names as the files removed in step c.
See Example 6-27.

Example 6-27 EKM policy location
/usr/lpp/java5/sdk/jre/lib/security>ls -l
total 112
-rw-r----- 1 root system 2199 Sep 22 07:39 US_export_policy.jar
-rw-r--r-- 1 root sys 29731 May 11 2006 cacerts
-rw-r--r-- 1 root sys 2646 May 11 2006 java.policy
-rw-r--r-- 1 root sys 9609 May 11 2006 java.security
-rw-r----- 1 root system 2212 Sep 22 07:39 local_policy.jar

Creating a keystore using keytool
Now that Java is installed, create the files that are required by the Encryption Key Manager.
The keystore is the first file to be created and populated. For this step, we use a command
line utility called keytool. Additional information about the keytool is available at:
ftp://ftp.software.ibm.com/s390/java/jce/keytool.html

Use the Keytool User Guide as a reference. The guide is located at:
http://www.ibm.com/developerworks/java/jdk/security/142/secguides/keytoolDocs/KeyT
oolUserGuide-142.html

Example 6-28 shows the script that we used to create our keystore.

Example 6-28 Keystore create keytool commands
keytool -genkey
-alias cert1
-dname CN=myCo
-keystore tonyskeys.jcks
-provider IBMJCE
-keyalg RSA
-keysize 2048
-keypass "passphrase"
-storepass "passphrase"


-storetype JCEKS
-validity 999

keytool -genkey
-alias cert2
-dname CN=myCo
-provider IBMJCE
-keyalg RSA
-keysize 2048
-storetype JCEKS
-validity 999

keytool -export
-file rsa2048Cert1.cer
-alias cert1
-storepass passphrase
-storetype JCEKS
-provider IBMJCE
-keypass passphrase

keytool -import
-alias cert1ca
-storetype JCEKS
-provider IBMJCE
-keypass passphrase

Importing and exporting certificates and why
The last two commands in the script keytool export and keytool import are there to
establish a trusted certificate. You import a certificate for one of the following reasons:
To add it to the list of trusted certificates
To import a certificate reply received from a CA as the result of submitting a Certificate
Signing Request to that CA

A trusted certificate is required for an SSL connection. The SSL protocol is described in detail
in the “Secure Sockets Layer example” on page 20.

When more than one EKM is used in the IBM tape data encryption solution, the primary and
secondary EKMs synchronize information using an SSL connection.
The value of the -alias option indicates which type of import is intended:
If the alias points to a key entry, keytool assumes that you are importing a certificate reply.
Keytool checks whether the public key in the certificate reply matches the public key
stored with the alias and exits if they are different.
If the alias does not point to a key entry, keytool assumes you are adding a trusted
certificate entry. In this case, the alias does not already exist in the keystore.


If the alias does already exist, keytool outputs an error, because there is already a trusted
certificate for that alias, and keytool does not import the certificate. If the alias does not exist
in the keystore, keytool creates a trusted certificate entry with the specified alias and
associates it with the imported certificate.

Important: Be sure to very carefully check a certificate before importing it as a trusted
certificate.

Listing a keystore using keytool
You can use the script listed in Example 6-29 to list a keystore.

Example 6-29 List keystore script
keytool -list
-storetype jceks

The results of the list keystore script reflect that the import did indeed create a trusted
certificate. See Example 6-30.

Example 6-30 List keystore script results
Keystore type: jceks
Keystore provider: IBMJCE

Your keystore contains 3 entries

cert1ca, Sep 22, 2000, trustedCertEntry,
Certificate fingerprint (MD5): A9:A9:74:F7:FD:A4:27:88:39:28:DF:E4:47:25:33:E7
cert2, Sep 22, 2000, keyEntry,
Certificate fingerprint (MD5): FF:4E:3F:73:B6:26:79:A7:69:11:B1:6E:63:67:0D:91
cert1, Sep 22, 2000, keyEntry,
Certificate fingerprint (MD5): A9:A9:74:F7:FD:A4:27:88:39:28:DF:E4:47:25:33:E7
/home/root/ekmserv>

6.3 Installing EKM on a Windows platform
In this section, we describe the installation of EKM in the Windows environment.

The Java Runtime Environment is bundled with IBM TotalStorage Productivity Center -
Limited Edition (TPC-LE) - 5608-VC6. This version of TPC is available without charge.


Important: Regardless of which version of IBM SDK you use, you must replace the
java_home/usr/java5/jre/lib/security with new files that you can download for Java 5.0
on Sun, System x, and Hewlett-Packard UNIX (HP-UX) from this Web site:

These files install the unrestricted policy files that EKM requires in order to serve Advanced
Encryption Standard (AES) keys.

Be sure to select the “Unrestricted JCE Policy files for SDK 1.4.2”, which works for both
Java 1.4.2 and Java 5.0 SDKs. Do not select the 1.4.1 version, because these files are
incompatible.

6.3.1 EKM setup tasks
Before you can encrypt tapes, EKM must first be configured and running so that it can
communicate with the TS1120 tape drives. EKM does not need to be running while tape
drives are being installed, but it must be running in order to perform encryption. You do not
have to set up EKM if you are implementing Application-Managed Encryption.

Perform the following tasks before using EKM:
1. Decide what system or systems to use as EKM servers.
2. Upgrade the server operating system if necessary.
3. Install or upgrade IBM Java Virtual Machine if necessary.
4. Install IBM Java Unrestricted Policy Files.
5. Upgrade EKM JAR if necessary, which you can obtain at the IBM Web site at:
Or visit the following Web site:
Click Downloads and look for IBM Encryption Key Manager for the Java platform.
6. Decide on keystore type.
The type of keystore that you select depending on your environment can affect your future
flexibility for encryption implementation. Refer to 7.1, “Keystore and SAF Digital
Certificates (keyrings)” on page 228 for more details.
7. Define and create a keystore and certificates (AIX and other operating systems) as shown
in Example 6-28 on page 180.
8. Import or create keys and certificates into the keystore.
Refer to “Importing and exporting certificates and why” on page 181.
9. Define the EKM configuration file. See Example 6-35 on page 191.
10.Define the tape drives to the EKM or set the drive.acceptUnknownDrives EKM
configuration property value to ON.
11.Start EKM.


Important: Ensure that you use the forward slash character (/) in the Java properties EKM
configuration file when defining file locations. Because KeyManagerConfig.properties is a
Java properties file, only forward slashes are recognized in pathnames, even in Windows.
If you use the back slash character () in the KeyManagerConfig.properties file, errors will
occur.

6.3.2 Installing the IBM Software Developer Kit on Windows
In this section, we guide you through the steps to install the IBM Software Developer Kit
(SDK).

Installation steps
To install the IBM SDK on Windows:
1. Insert the correct CD from the IBM TotalStorage Productivity Center - Limited Edition
(TPC-LE) - LPP 5608-VC6 and select your IBM Java Runtime Environment:
– Java 5.0 Service Release 2 (Windows/AMD64/EM64T)
– Java 5.0 Service Release 2 (Windows/IA32)
– Java 1.4.2 Service Release 5 (Windows/IA64)
2. Select a setup language. See Figure 6-6.

Figure 6-6 Language choice

3. Click OK. The installation wizard opens, as shown in Figure 6-7 on page 185.


Figure 6-7 InstallShield Wizard

4. Click Next. The License Agreement window opens. See Figure 6-8.

Figure 6-8 License agreement

5. Read the License Agreement and if acceptable, click Yes.
The Choose Destination Location window opens. See Figure 6-9 on page 186.


Figure 6-9 Java installation destination location

6. Either confirm or choose a folder and make note of it. You will need this Java path to
launch EKM. Click Next.
A confirmation window opens, asking if you want this Java Runtime Environment as the
default System JVM. See Figure 6-10.

Figure 6-10 Do you want this version for your default System JVM

7. Click No.
A window opens prompting you to review the target directories that Java will use. See
Figure 6-11 on page 187.


Figure 6-11 Review target directory

8. If acceptable, click Next to start the installation.
9. The last window that opens confirms that Java was installed successfully. See
Figure 6-12. Click Finish to complete the installation.

Figure 6-12 Installation complete


At a Windows C: prompt, typing Java -version results in Example 6-31.

Example 6-31 After Java installation
C:Documents and SettingsAdministrator>java -version
Java(TM) 2 Runtime Environment, Standard Edition (build pwi32devifx-20060124)
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223ifx-2006
0124 (JIT enabled)
J9VM - 20051027_03723_lHdSMR
JIT - 20051027_1437_r8
GC - 20051020_AA)
JCL - 20060120

Replacing the Java JAR files
Regardless of the version of IBM SDK that you use, you must replace the
java_home/usr/java5/jre/lib/security with new files that you can download from:

These files install the unrestricted policy files that EKM requires in order to serve AES keys.
See Figure 6-13.

Figure 6-13 Replacing Jar files

The location of the JAR files that have to be replaced are shown in Figure 6-13.

Upgrade EKM Jar
Download the latest IBMKeyManagementServer.jar and KeyManagerConfig.properties files
from the IBM Web site at:

Or, visit the following Web site and click downloads and look for IBM Encryption Key
Manager for the Java platform. Then, download it into a directory of your choice:

In our example, we created a directory named C:$$$$ekm and copied the
KeyManagerConfig.properties file into it.


The IBMKeyManagementServer.jar file must be copied into the C:Program
FilesIBMJava50jrelibext directory, which was created during the Java SDK
installation. The directory is shown in Figure 6-14.

Figure 6-14 Jar file copied

Editing the EKM config file
The Java SDK uses forward slashes (/), even when running on Windows. When specifying
paths in the KeyManagerConfig.properties file, be sure to use forward slashes. When
specifying a fully-qualified path name in the command window, use back slashes () in the
normal manner for Windows. An example of using forward slashes in relevant
KeyManagerConfig parameters is shown in Example 6-32.

Example 6-32 Java Config forward slash example
config.drivetable.file.url = FILE:///keymanager/drivetable
debug.output.file = keymanager/debug

We discuss KeyManagerConfig.properties parameters in 6.3.4, “Configuring and starting
EKM” on page 190.

6.3.3 Starting EKM on Windows
We updated the Windows PATH parameter with the Java directory information, so that we do
not have to enter C:Program FilesIBMJava50bin when starting EKM.

Starting EKM is a two-step process. To get to the Java command prompt, you enter:
java com.ibm.keymanager.KMSAdminCmd KeyManagerConfig_full_file_path_name

Here are the steps we used:
1. So that we do not have to fully qualify all the configuration parameters, we ensure that we
start in the correct directory that contains our KeyManagerConfig.properties file.
At the C: prompt, we changed the Windows directory to the directory to which we copied
the KeyManagerConfig.properties file, which in our example is C:$$$$EKM, and enter the
following command to start EKM:
java com.ibm.keymanager.KMSAdminCmd KeyManagerConfig.properties.jce4758
2. At the # prompt, we entered startekm, as shown in Example 6-33 on page 190.


Example 6-33 starting EKM
C:$$$$ekm>java com.ibm.keymanager.KMSAdminCmd KeyManagerConfig.properties.jce4758
# startekm
Loaded drive key store successfully
Starting the Encryption Key Manager 1.0
Processing Arguments
Processing
Server is started
#

6.3.4 Configuring and starting EKM
In this section, we discuss coding the EKM configuration file, we start EKM, and then we look
at several of the more interesting EKM commands.

Configure EKM
To configure EKM:
1. Download a sample configuration file that you can use as a model from:
http://www-1.ibm.com/support/docview.wss?&uid=ssg1S4000504
2. Scroll to the IBM EKM Sample Configuration File section identified in Figure 6-15.

Figure 6-15 Location of sample EKM configuration file

3. Click FTP to get the sample KeyManagerConfig.properties configuration file. Edit it to suit
your environment. Example 6-34 on page 191 shows the KeyManagerConfig.properties
file that was downloaded from the Web site that you can use as a example to get started.


Example 6-34 Sample EKM KeyManagerConfig.properties file
Audit.handler.file.name = kms_audit.log
Admin.ssl.keystore.name = testkeys
Admin.ssl.truststore.name = testkeys
config.drivetable.file.url = FILE://keymanager/drivetable
debug = none
fips = Off
TransportListener.ssl.keystore.name = keymanager/testkeys
TransportListener.ssl.keystore.type = jceks
TransportListener.ssl.truststore.name = testkeys
TransportListener.ssl.truststore.type = jceks
config.keystore.file = keymanager/testkeys
config.keystore.provider = IBMJCE
config.keystore.type = jceks

We changed several entries to match the naming conventions that we used. We changed
very little. Example 6-35 is the file that we used to start EKM.

Example 6-35 Our edited KeyManagerConf.properties file
/home/root/ekmserv>cat startj.sh
java com.ibm.keymanager.KMSAdminCmd KeyManagerConfig.properties
/home/root/ekmserv>cat KeyManagerConfig.properties
fips = Off
Admin.ssl.keystore.name = tonyskeys.jcks
config.keystore.provider = IBMJCE
config.keystore.password = passphrase
TransportListener.ssl.truststore.name = tonyskeys.jcks
config.keystore.file = tonyskeys.jcks
TransportListener.ssl.truststore.type = jceks
TransportListener.ssl.keystore.name = tonyskeys.jcks
TransportListener.ssl.keystore.type = jceks
config.keystore.type = jceks


debug = none
config.drivetable.file.url = FILE://keymanager/drivetable
Admin.ssl.truststore.name = tonyskeys.jcks

Important: Regarding the FIPS parameter, EKM does not provide cryptographic
capabilities and therefore, EKM does not require and not allowed to obtain FIPS 140-2
certification. However, EKM takes advantage of the cryptographic capabilities of the
IBM JVM in the IBM Java Cryptographic Extension component and allows the selection
and use of the IBMJCEFIPS cryptographic provider, which has a FIPS 140-2 level 1
certification. By setting the FIPS configuration parameter to ON in the Configuration
Properties file, you make EKM use the IBMJCEFIPS provider for all cryptographic
functions.

In addition to setting the FIPS parameter in the Configuration properties file, the
following provider must be added to the java.security file in $JAVA_HOME/lib/security/:
security.provider.?=com.ibm.crypto.fips.provider.IBMJCEFIPS

This provider must be added before the IBMJCE provider. Renumber the providers
accordingly.

4. If you want to, create a script that tests EKM.
To save effort, we created the script in Example 6-36 so that we did not have to retype the
entire command every time that we wanted to test the EKM. This script also proved helpful
to keep track of the correct version of the keymanagerconfig.properties file that we wanted
to use, because we had several versions in different states for testing purposes.

Example 6-36 startj.sh script
/home/root/ekmserv>cat startj.sh

Start EKM
You are now ready to start the EKM, which is a two-step process.

To start EKM:
1. Get to the command prompt of EKM, which you do with the following command:
We used the startj.sh script as shown in Example 6-37 to get to the command prompt.

Example 6-37 EKM command prompt
/home/root/ekmserv>startj.sh
Sep 29, 2000 9:14:03 AM com.ibm.keymanger.config.ConfigImpl get
FINER: ENTRY
ALL: debug.output = simple_file
FINER: RETURN
# <<<< -----EKM command prompt

2. At the EKM command prompt, enter startekm. The results are shown in Example 6-38.


Example 6-38 Starting EKM
# startekm
Starting the Encryption Key Manager 1.0-20060823
Processing
Server is started
#

EKM commands
After EKM is running, entering help at the # command prompt provides a list of valid
commands as shown in Example 6-39.

Example 6-39 EKM command examples
# help
EKMAdmin usage:

adddrive -drivename <name> [-rec1 <alias>] [-rec2 <alias>]

deldrive -drivename <name>
equivalent command is rmdrive or deletedrive or removedrive

exit or quit

export -drivetab|-config -url <url name>

import -merge|-rewrite -drivetab|-config -url <url name>

listcerts [-alias <alias>] [-verbose|-v]

listconfig

listdrives [-drivename <drive_name> [-verbose|-v]]

logout - equivalent command is logoff
Only useful when LoginModule is enabled

modconfig -set -property <name> -value <value> | -unset -property <name>
equivalent command is modifyconfig

moddrive -drivename <name> [-rec1 alias] [-rec2 alias]
equivalent command is modifydrive

refresh

startekm

status

stopekm

version

sync -all|-config|-drivetab -ipaddr <ip address:ssl port> [-merge|-rewrite]


Note that dashes and spaces must be contained in quotes for either to show up
as part of an argument value.

And, because we neglected to code the drive.accept.unknown.drives parameter in the EKM
configuration, we modified the running configuration using the EKM modconfig command as
shown in Example 6-40.

Example 6-40 The modconfig command
# modconfig -set -property drive.acceptUnknownDrives -value true

A listconfig of the configuration file “in use” reflects that the drive.acceptUnknownDrives
parameter is now specified correctly. See Example 6-41.

Example 6-41 Config after modconfig command
# listconfig
debug.output=simple_file
config.drivetable.file.url=FILE://keymanager/drivetable
config.keystore.password=passphrase
Admin.ssl.keystore.name=tonyskeys.jcks
Audit.handler.file.directory=keymanager/audit
Audit.event.types=all
Admin.ssl.truststore.name=tonyskeys.jcks
debug.output.file=keymanager/debug
TransportListener.ssl.protocols=SSL_TLS
Audit.handler.file.name=kms_audit.log
TransportListener.ssl.keystore.name=tonyskeys.jcks
Audit.eventQueue.max=0
TransportListener.tcp.port=3801
TransportListener.ssl.truststore.name=tonyskeys.jcks
Audit.handler.file.size=10000
config.keystore.file=tonyskeys.jcks
config.keystore.type=jceks
TransportListener.ssl.ciphersuites=JSSE_ALL
TransportListener.ssl.clientauthentication=0
TransportListener.ssl.port=443
TransportListener.ssl.keystore.type=jceks
debug=none
config.keystore.provider=IBMJCE
TransportListener.ssl.truststore.type=jceks
Audit.event.outcome=success,failure
drive.acceptUnknownDrives=true
fips=Off

Example 6-42 on page 195 shows a few examples of sample output provided by EKM
commands. Note that the tape drive we used to test writing an encrypted tape is now
reflected in the drive table output of the listdrives command.


Example 6-42 Command responses
# listdrives
Drive entries: 1
SerialNumber = 000001365109
# version
build-level = -20060823
# status
Server is running. TCP port: 3801, SSL port: 443

To verify that EKM was using our keystore and our certificates, we issued the listcerts
command as reflected in Example 6-43.

Note: The listcerts command on a production keystore results in a very large display.
We shortened the certificate’s listing in this display example.

Example 6-43 The listcerts command results
# listcerts
Keystore entries: 3
Keystore type:jceks
Keystore provider:IBMJCE

cert1ca, Fri Sep 22 09:07:15 MST 2000, trustedCertEntry
Certificate fingerprint (MD5withRSA):
57:b8:78:50:65:c5:17:e8:7c:66:b8:c1:42:5e:98:78:cf:ec:89:36:2:f3:ff:55:36:82:7:e4:
4:16:54:42:b4:c3:6d:2a:e6:6b:9c:f0:8:15:a4:66:ec:a2:c6:c9:90:c0:24:2b:61:69:3f:ad:
:e:f4:a1:80

cert2, Fri Sep 22 09:06:54 MST 2000, keyEntry
:9f:37:1a:43:3c:3c:e4:fb:8e:9:d2:11:4b:1c:11:bb:15:70:c4:c6:79:30:40:a4:4e:f2:ce:7
3:3:e3:6d:a1

cert1, Fri Sep 22 09:06:01 MST 2000, keyEntry
57:b8:78:50:65:c5:17:e8:7c:66:b8:c1:42:5e:98:78:cf:ec:89:36:2:f3:ff:55:36:82:7:e4:
:67:4a:47:70:7:d1:e7:44:c7:e6:f1:62:9:c7:5a:12:14:3f:4f:b3:46:e2:71:f1:79:5f:45:65
:e:f4:a1:80

Drive tables, configuration properties, and so forth
EKM carries over changes made to its drive table and configuration.

Prior to testing encryption, we checked the VOLSERs in our logical library to verify that these
VOLSERs had not been encrypted:
# adddrive -drivename 000001365109 -rec1 cert3 -rec2 cert4
# listdrives
Drive entries: 1
SerialNumber = 000001365109

As shown in Figure 6-16 on page 196, VOLSER J1S357 is mounted but has not yet been
encrypted.


Figure 6-16 J1S357 prior to being encrypted

If, during your testing, you want to reset the 3584 Web GUI encryption indicator for a
cartridge, you can do that in one of two ways:
Change the indicator to NOT ENCRYPTED by ensuring that the cartridge is outside of a
Barcode Encryption Policy (BEP) and issuing a write from beginning of tape.
Change the indicator to UNKNOWN by physically removing the cartridge from the library
and then reinserting it.

6.4 Installing the EKM in i5/OS
Refer to the following corresponding sections to either newly install or to upgrade an installed
EKM:
To newly install the IBM Encryption Key Manager component for the Java platform (EKM)
on i5/OS as a primary or secondary EKM server, refer to 6.4.1, “New installation of the
Encryption Key Manager” on page 196
To upgrade an installed EKM release to a newer service release, refer to 6.4.2, “Upgrading
the Encryption Key Manager” on page 199.

6.4.1 New installation of the Encryption Key Manager
For a new installation of IBM EKM component for the Java platform, do the following:
1. Install EKM as a primary or single EKM server on an i5/OS server by following the steps
in “New installation of a primary EKM Server” on page 197.
2. If you want to set up a secondary EKM server on an i5/OS system, follow the steps in “New
installation of a secondary EKM Server (optional)” on page 198.


New installation of a primary EKM Server
To install a primary EKM server:
1. Refer to 5.2.3, “EKM on IBM System i5 requirements” on page 143 to verify that you have
all software prerequisites for either i5/OS V5R3 or V5R4 installed.
2. Install the unrestricted JCE policy files local_policy.jar and US_export_policy.jar
Version 1.4.2, which can be downloaded from the IBM Web site:
Install the files to the following IFS directories:
– For V5R4, install to:
/QOpenSys/QIBM/ProdData/JavaVM/jdk50/32bit/jre/lib/security/
– For V5R3, install to:
/QIBM/ProdData/Java400/jdk15/lib/security/

Note: Make to sure to replace the existing policy files with the unrestricted ones
downloaded in the previous step. The unrestricted JCE policy files Version 1.4.2 are the
same for Java Version 1.4.2 and 1.5 or 5.0.

3. Edit the java.security file to include the following providers if they are not already
included:
– security.provider.6=com.ibm.jsse2.IBMJSSEProvider2
– security.provider.7=com.ibm.i5os.jsse.JSSEProvider

Note: The unique number to be used for adding these security providers depends on
which providers are already specified in your java.security file.

The java.security file is located in the following IFS directory:
– For V5R4, the file is in:
/QOpenSys/QIBM/ProdData/JavaVM/jdk50/32bit/jre/lib/security/
– For V5R3, the file is in:
/QIBM/ProdData/Java400/jdk15/lib/security/
4. Create an IFS directory for EKM to hold the EKM keystore, configuration file, drive table,
and so forth with a subdirectory for the EKM auditlogs using the i5/OS commands:
CRTDIR DIR('/EKM')
CRTDIR DIR('/EKM/auditlogs')
5. Copy the default EKM configuration file to the previously created EKM directory to make
sure it will not be overwritten by an i5/OS Java software update; use the command:
CPY OBJ('/QIBM/ProdData/OS400/Java400/ext/KeyManagerConfig.properties')
TODIR('/EKM')
6. Proceed to section 15.2.1, “Creating an EKM keystore and certificate” on page 515 to
create a keystore and corresponding certificates for EKM on i5/OS.
7. Complete the EKM configuration for 3592 Tape Encryption and Linear Tape-Open
(LTO) 4 or LTO4 Tape Encryption described in the section 6.4.3, “Configuring EKM for tape
data encryption” on page 201.
8. Set up the Encryption Key Manager address in the IBM TS3xxx library and enable
Library-Managed Encryption by referring to section 15.2.2, “Configuring the TS3500
library for Library-Managed Encryption” on page 528.


9. After completing the EKM configuration, submit the EKM server as a batch job by using
the command:
SBMJOB CMD(QSH CMD('strEKM -server -propfile /EKM/KeyManagerConfig.properties
1> /EKM/stdout.log 2> /EKM/stderr.log')) JOB(EKMBCH) JOBQ(QSYS/QUSRNOMAX)
The strEKM script on i5/OS in /usr/bin explicitly refers to the correct Java version for
starting the EKM server so there is no further specification required if multiple Java
versions are installed on i5/OS.

Note: Add an autostart job entry for the subsystem in which the EKM server will be
running to guarantee that the EKM server is automatically started when the
corresponding subsystem gets started, for example, after IPL. To add an autostart job
entry, create a job description for the EKM server job and add an autostart job entry to
your subsystem using the following job description:
CRTJOBD JOBD(library/EKMJOBD) JOBQ(QSYS/QUSRNOMAX) USER(userid)
RQSDTA('STRQSH CMD(''strEKM -server -propfile
/EKM/KeyManagerConfig.properties 1> /EKM/stdout.log 2> /EKM/stderr.log'')')

ADDAJE SBSD(library/subsystem) JOB(EKMBCH) JOBD(library/EKMJOBD)

10.Back up the EKM keystore, EKM configuration file, drive table, and audit logs without
using encrypted saves, that is, transfer to a system that is not using tape encryption for
backup.

New installation of a secondary EKM Server (optional)
These steps describe a new installation of an optional secondary EKM server on another
i5/OS system.

To install and setup an optional secondary EKM server:
1. Follow the steps 1 to 4 for the installation of the primary EKM server.
2. When using solely LTO4 Tape Encryption, ensure that a public-private key certificate
exists in the EKM server’s JCEKS keystore for SSL communication to be used for
synchronization with the secondary EKM server. Refer to “Creating a JCEKS keystore and
certificate” on page 526 to list the certificates in a JCEKS keystore and create a
public-private key if needed.
3. Copy the keystore file, such as EKM.KDB or EKM.JCK, the configuration file
KeyManagerConfig.properties, and the drivetable file from your primary EKM server IFS
directory (that is, /EKM) to the same directory on your i5/OS system with the secondary
EKM server, for example, by using the iSeries Navigator or FTP transfer.
4. On your i5/OS system that is used for the secondary EKM server, start the EKM server as
a batch job by referring to step 9.
5. Refer to the section “Setting up Encryption Key Manager addresses” on page 528 to set
up the secondary EKM server IP address in the tape library.
6. On your i5/OS system that is used for the primary EKM server, end the EKM batch job
(see step 1 on page 199) and start the EKM admin console from QShell by running the
command:
strEKM -propfile /EKM/KeyManagerConfig.properties


Note: Currently, the EKM admin console knows nothing about the EKM server started
as batch job, so for any configuration changes to an EKM server started in a batch job,
this batch job must be ended prior to the changes. Otherwise, the configuration
changes are lost when the batch job is ended and the EKM server writes its current
configuration from memory to its file.

7. Use the following commands from the primary EKM server’s admin console to set up
automatic synchronization between the primary and secondary EKM server:
modconfig -set -property sync.ipaddr -value 9.11.202.6:443
modconfig -set -property sync.type -value all
modconfig -set -property sync.timeinhours -value 24
This example sets up automatic synchronization between the primary EKM server and the
secondary EKM server, which has the IP address 9.11.202.6, using the EKM default SSL
port 443, as specified in the EKM configuration file TransportListener.ssl.port parameter.
The specified sync.type parameter value of all means that the EKM configuration file,
which is rewritten from the primary to the secondary server, and the EKM drive table,
which is merged by sending new updates from the primary to the secondary server, are
synchronized. Synchronization is started every 24 hours as specified by the
sync.timeinhours parameter value of 24.
To verify your changes in the EKM configuration, run the listconfig command.
For additional information about synchronization of the EKM server, refer to the IBM
Encryption Key Manager component for the Java platform, EKM Introduction, Planning
and User’s Guide, GA76-0418.

Note: The EKM admin console sync command, for example, sync -all -ipaddr
9.11.202.6:443, can be used to manually synchronize or test the synchronization
between the primary and secondary EKM server; however, it requires that the primary
EKM server be started interactively.

8. Exit from the primary EKM admin console by using the command exit.
9. Start the primary EKM server as a batch job by again referring to step 9 on page 198.

6.4.2 Upgrading the Encryption Key Manager
Use the procedure in this section to upgrade an existing IBM Encryption Key Manager
component for the Java platform (EKM) installation on i5/OS to a newer EKM service release.

Note: EKM Release 2 is the official IBM service path for EKM Release 1, that is, no new
EKM Release 1 maintenance releases will be made available.

To upgrade EKM:
1. Shut down the EKM server:
– If the EKM server was started as a batch job, use the i5/OS command WRKACTJOB to
locate the EKM batch job, which usually runs in the QUSRWRK subsystem, and end it
either using the option 4 as shown in Figure 6-17 on page 200 or by using the following
command:
ENDJOB JOB(EKMBCH)


Note: Do not use the *IMMED option to end the EKM batch job immediately, because
this option prevents a proper shutdown of EKM and does not update its
configuration file, drive table, and XML metadata file.

Figure 6-17 i5/OS WRKACTJOB panel showing the EKM batch job

– If the EKM server was started interactively, run the command exit from the EKM
admin console in i5/OS Qshell to stop the EKM server and exit from the EKM admin
console.
2. Update the EKM code to the new release by replacing the following
IBMKeyManagementServer.jar Java extension file with its newer version:
– For i5/OS V5R4:
/QOpenSys/QIBM/ProdData/JavaVM/jdk50/32bit/jre/lib/ext/IBMKeyManagementServer.jar
– For i5/OS V5R3:
/QIBM/ProdData/OS400/Java400/ext/IBMKeyManagementServer.jar

Note: Ensure that you delete or overwrite the old IBMKeyManagementServer.jar
version. Do not rename the file from the old version because Java will still find its class
information from the old renamed file and the new EKM code is not used.

3. If upgrading from EKM Release 1 to a newer release, add the required
Audit.metadata.file.name parameter to the EKM configuration file by referring to step 2
on page 202 (in “Customizing the EKM Configuration File” on page 202).
4. If you will be newly using LTO4 Tape Drive Encryption after this EKM upgrade:
a. Ensure that the required IBM Java 5.0 Service Release 5 is installed with the
enhanced keytool for support of symmetric key management (refer to 15.1.2, “Software
prerequisites” on page 509).
b. Generate the required symmetric keys in a JCEKS-type EKM keystore by referring to
“Symmetric key generation for LTO4 encryption” on page 526.


c. Add the symmetricKeySet parameter to the EKM configuration file and make sure that
the keystore file, its type, password, and provider are adjusted if migrating from an
IBMi5OSKeyStore to a JCEKS keystore for LTO4 Tape Encryption. Refer to step 3 on
page 203, step 4 on page 203, and step 8 on page 204 (all in “Customizing the EKM
Configuration File” on page 202).
5. Verify that the upgraded EKM server starts without errors by first starting and stopping it
interactively from the i5/OS Qshell by using the following commands and check that the
reported build level matches the new version:
strEKM -propfile /EKM/KeyManagerConfig.properties
startekm
exit
6. Finally, start the newly upgraded EKM server as a batch job by using the command:
SBMJOB CMD(QSH CMD(’strEKM -server -propfile /EKM/KeyManagerConfig.properties
1> /EKM/stdout.log 2> /EKM/stderr.log’)) JOB(EKMBCH) JOBQ(QSYS/QUSRNOMAX)

6.4.3 Configuring EKM for tape data encryption
In this section, we describe the EKM configuration for TS1120 and LTO4 Tape Encryption
assuming that you have completed steps 1 - 6 in section 6.4.1, “New installation of the
Encryption Key Manager” on page 196.

Default EKM configuration file
The default EKM configuration file KeyManagerConfig.properties, which still has to be
customized for a specific environment, is shown in Example 6-44.

Example 6-44 Default EKM configuration file
# Note that the file is sorted by property name. EKM shutdown automatically
# reorders the values in the properties file.
# Need to change the following directory value or create the directories
Audit.handler.file.directory = /EKM/auditlogs
Audit.handler.file.name = ekm_audit.log
# Need to change the following 2 pathnames to the correct pathnames for
# the keystores being used on your system
Admin.ssl.keystore.name = /EKM/EKM.kdb
Admin.ssl.truststore.name = /EKM/EKM.kdb
# Need to change the following pathname value or create the directories
config.drivetable.file.url = FILE:///EKM/drives/drivetable
# Need to change the following pathname to the correct pathname for
# the keystore being used on your system
config.keystore.file = /EKM/EKM.kdb
config.keystore.provider = IBMi5OSJSSEProvider
config.keystore.type = IBMi5OSKeyStore
debug = all
# Need to change the following pathname value or create the directory
debug.output.file = /EKM/debug.log
# Change this to 'false' if you do not want new tape drives automatically
# added to the EKM drive table


fips = Off
TransportListener.ssl.keystore.name = /EKM/EKM.kdb
TransportListener.ssl.keystore.type = IBMi5OSKeyStore
# Need to specify the ssl port being used on your system
TransportListener.ssl.protocols = TLSv1
TransportListener.ssl.truststore.name = /EKM/EKM.kdb
TransportListener.ssl.truststore.type = IBMi5OSKeyStore
# Need to specify the tcp/ip port being used on your system
# Need to specify the passwords for the keystores being used
Admin.ssl.keystore.password = kspwd
Admin.ssl.truststore.password = kspwd
config.keystore.password = kspwd
TransportListener.ssl.keystore.password = kspwd
TransportListener.ssl.truststore.password = kspwd

Customizing the EKM Configuration File
Use the following i5/OS command to edit the EKM configuration file and customize it for your
environment:
EDTF STMF('/EKM/KeyManagerConfig.properties')

To change the following configuration parameters according to your environment:
1. Adjust the Audit.handler.file.directory parameter value to match your audit log directory
that was created in section step 4 on page 197 (in 6.4.1, “New installation of the
Encryption Key Manager” on page 196), which must exist. For example:
Audit.handler.file.directory = /EKM/auditlogs
2. Add the Audit.metadata.file.name parameter that is newly supported with EKM Release 2
for the tracking of key usage requests for volume serial numbers in a XML metadata file,
which is an abbreviated version of the EKM audit log and especially useful for LTO4
Encryption (see “Example of the EKM audit metadata XML file” on page 553). For
example:
Audit.metadata.file.name = /EKM/auditlogs/metadata.xml
The audit metadata XML file can be queried for specific volume serial numbers or key
aliases with the EKMDataParser Java tool using the following syntax:
EKMDataParser [-filename metadatafile] [-volser VOLSER] [-keyalias keyalias]

Note: New XML metadata entries are generated with each key usage request. By
default, 100 entries are cached in memory before they are written to the XML metadata
file. You can use the optional Audit.metadata.file.cachecount parameter to set the value
of the maximum cached entries; however for performance reasons, we do not
recommend that you turn off caching by setting this parameter to 0 (zero).


3. Modify the values for the following parameters to match your name, type, and the provider
of the EKM keystore if it differs from the default name /EKM/EKM.kdb, type
IBMi5OSKeyStore, and provider IBMi5OSJSSEProvider. For example, the name for a
JCEKS keystore might be /EKM/EKM.jck, the type might be JCEKS, and the provider might
be IBMJCE:
Admin.ssl.keystore.name
Admin.ssl.truststore.name
config.keystore.file
config.keystore.provider
config.keystore.type
TransportListener.ssl.keystore.name
TransportListener.ssl.keystore.type
TransportListener.ssl.truststore.name
TransportListener.ssl.truststore.type

Note: The truststore and keystore are used for optional EKM to EKM server
synchronization using SSL communication, not for communication between the EKM
and the tape library.

4. Modify the values for the following parameters to match your password for the defined
keystore:
Admin.ssl.keystore.password
Admin.ssl.truststore.password
config.keystore.password
TransportListener.ssl.keystore.password
TransportListener.ssl.truststore.password
5. Modify the config.drivetable.file.url parameter value to reflect your preferred location of the
EKM drive table, which is used to validate drives by their serial numbers for usage with
EKM. For example:
config.drivetable.file.url = FILE:///EKM/drivetable
6. Modify the debug.output.file parameter value to indicate the file used for the output of
EKM debug information. For example (default value):
debug.output.file = /EKM/debug.log
7. The parameter drive.acceptUnknownDrives is set to true in the sample EKM configuration
file so that any new tape drive that contacts EKM through the IBM tape library is
automatically added with its serial number to the EKM drive table. The EKM drive table
contains the list of valid drives for usage with EKM. If instead, you prefer to control which
drives are valid for usage with EKM, you can set this parameter to its default value of
false so that new drives must be manually added to the drive table using the adddrive
command from the EKM admin console.
When the default parameter value of true is used with 3592 Tape Encryption, you must
also set two default key aliases for the drives by adding the drive.default.alias1 and
drive.default.alias2 parameters to make sure that an EEDK1 and EEDK2 can be
generated for the new drive. For example:
drive.default.alias1 = Tape_Certificate
drive.default.alias2 = Tape_Certificate2


Note: If you only use one public key/certificate for 3592 Tape Encryption because
sharing tapes with a business partner is currently not an issue, still make sure that if
you use default aliases that both alias1 and alias2 are defined even if they are both set
to the same key label. Otherwise, the IBM library EKM configuration test might fail.
The default key aliases can still be overruled by explicit key aliases specified with the
rec1 and rec2 parameters for a drive in the drive table or by the IBM TS3500 Tape
Library Barcode Encryption Policy.

8. For LTO4 encryption, add the parameter symmetricKeySet that specifies that all
symmetric keys are to be used for LTO4 Tape Encryption; single key aliases and
aliasranges can both be specified at one time and delimited by commas. For example:
symmetricKeySet = AES00-0F
9. Save the changed EKM configuration file KeyManagerConfig.properties.

Additional information
For additional information about the EKM configuration file parameters and the EKM admin
console command line interface, refer to the IBM Encryption Key Manager component for the
Java platform, EKM Introduction, Planning, and User’s Guide, GA76-0418, available at:
http://www-1.ibm.com/support/docview.wss?rs=1139&context=STCXRGL&dc=D400&uid=ssg1S
4000504

6.5 LTO4 Encryption implementation
When setting up encryption for LTO4 drives and media, unless you are using
Application-Managed Encryption (AME), you will have to select a key manager. For a
complete discussion of the two key management solutions see 6.6, “LTO4 Library-Managed
Encryption implementation” on page 217 or 6.7, “LTO4 System-Managed Encryption
implementation” on page 225. At this time, if you want to run your key manager on System z
your only option is to use the EKM version 2 or later. For other key server platforms, you may
use TKLM. Your key server can run on any supported platform independent of the host
systems you are using to access the tape drive.

Advanced Library Management System effect on encryption
If your TS3500 does not have the Advanced Library Management System (ALMS) feature, be
aware that your ability to implement and manage encryption will be much more inflexible than
if you have ALMS installed. If you intend to implement encryption on an existing library
without ALMS, older technology cannot coexist with newer encryption-capable technology. If
the non-ALMS library consists entirely of LTO4 technology, all logical partitions will have to be
managed using the same encryption method, that is, all LME or all SME, and so forth.

Also be aware that many new features of the TS3500 such as High Density Frames, Tape
System Reporter, the TS1130 Tape Drive and embedded SMI-S support are only available
when the ALMS feature is installed and enabled.

Refer to 14.2.1, “Advanced Library Management System considerations” on page 451 for
more details.


6.5.1 LTO4 EKM implementation checklist
This checklist is what we used to implement encryption using LTO4 drives located within a
TS3500 library with EKM V2 running on a Windows system. We show the steps necessary for
installing EKM V2 as well as how to implement encryption using LME and SME. The basic
steps are:
1. Download the latest version of EKM software.
Download unrestricted policy files to enable AES key generation by EKM.
2. Create a JCEKS Keystore.
Generate encryption keys.
3. Start the EKM Admin Session.
4. Start EKM.

In this section, we describe how to enable LME on a TS3500 for LTO4 drives. For our testing
purposes, we installed EKM on our personal computer under Windows. We already had Java
1.5.0 installed as shown in Example 6-45.

Example 6-45 Java version already installed
C:Documents and SettingsAdministrator>java -version
Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20070201 (SR4))

IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-2007020
1 (JIT enabled)
J9VM - 20070131_11312_lHdSMR
JIT - 20070109_1805ifx1_r8
GC - 200701_09)
JCL - 20070131

Ensure that a minimum of Software Developer Kit (SDK) 1.4.2 SR8 or SDK 5.0 SR5 is
installed. If you have an earlier SDK, refer to IBM Encryption Key Manager component for the
Java platform, EKM Introduction, Planning, and User’s Guide, GA76-0418, to learn how to get
the latest service refresh for your software platform.

6.5.2 Download the latest EKM software
Download the EKM JAR and verify the directory:
1. Download the latest version of the EKM JAR file (IBMKeyManagementServer.jar) and
configuration files (KeyManagerConfig.properties) from the following Web site (also
shown in Figure 6-18 on page 206):


Figure 6-18 EKM Web site

2. In addition to the EKM code and sample EKM configuration, download the latest version of
the IBM Encryption Key Manager component for the Java platform, EKM Introduction,
Planning, and User’s Guide, GA76-0418.
3. Determine whether there is a copy of the IBMKeyManagementServer.jar file in the
<JAVA_INSTALL>/lib/ext directory. If so, delete it and copy in the version just
downloaded. Example 6-46 displays the directory after we copied in the newest version of
the IBMKeyManagementServer.jar to the correct directory. (We downloaded the JAR file in
step 1.)

Example 6-46 Our Java directory
Directory of C:Program FilesIBMJava50jrelibext
07/01/2007 12:15 PM <DIR> .
07/01/2007 12:15 PM <DIR> ..
02/01/2007 05:28 AM 183,719 CmpCrmf.jar
02/01/2007 05:28 AM 15,621 dtfj-interface.jar
02/01/2007 05:28 AM 201,824 dtfj.jar
02/01/2007 05:28 AM 1,110,163 gskikm.jar
02/01/2007 05:28 AM 179,050 ibmcmsprovider.jar
02/01/2007 05:28 AM 186,317 ibmjcefips.jar
04/11/2007 03:55 PM 860,283 ibmjceprovider.jar
02/01/2007 05:28 AM 213,991 ibmkeycert.jar
07/01/2007 12:13 PM 362,585 IBMKeyManagementServer.jar
02/01/2007 05:28 AM 82,640 ibmpkcs11.jar
02/01/2007 05:28 AM 253,282 ibmpkcs11impl.jar
02/01/2007 05:28 AM 64,506 ibmsaslprovider.jar
02/01/2007 05:28 AM 65,709 indicim.jar
02/01/2007 05:28 AM 50,129 jaccess.jar
02/01/2007 05:28 AM 15,661 JawBridge.jar
02/01/2007 05:28 AM 241,618 jdmpview.jar
16 File(s) 4,087,098 bytes
2 Dir(s) 20,393,205,760 bytes free


Download unrestricted policy files to enable AES keys
To enable AES keys:
1. Open a command window and create an EKM directory where all of the EKM-related files
will be stored. On Windows, use the mkdir c:ekmekm1 command; the results of which
are shown in Example 6-47.

Example 6-47 Windows EKM directory
C:ekm>dir
Volume in drive C has no label.
Volume Serial Number is 6806-ABBD

Directory of C:ekm

07/11/2007 01:14 PM <DIR> .
07/11/2007 01:14 PM <DIR> ..
07/11/2007 01:14 PM <DIR> ekm1
0 File(s) 0 bytes

2. Copy the sample KeyManagerConfig.properties file to the EKM1 directory. In our
example, on Windows, use the following command:
copy KeyManagerConfig.properties c:ekmekm1KeyManagerConfig.properties
3. Because of governmental export regulations, JDKs are set up with the ability to do limited
function cryptography. For full function cryptography, you must install the unrestricted
policy files. Download the US_export_policy.jar and local_policy.jar files from:

After identifying yourself by signing in at the Web site, the panel shown in Figure 6-19 on
page 208 appears.


Figure 6-19 Web site for downloading the unrestricted policy files

Be sure to select Unrestricted JCE Policy files for SDK 1.4.2, which works for both Java
1.4.2 and Java 5.0 SDKs.

Important: Do not rename the JAR files, replace them. Do not select the 1.4.1 version,
because it is incompatible with Java 1.4.2 or Java 5.0 SDKs.

Replace the files in your <JAVA_INSTALL>/lib/security directory. These are the unrestricted
policy files that EKM requires in order to serve AES keys. Example 6-48 shows how our
directory looked after replacing the two files.

Example 6-48 Directory after replacing the two JARs
Directory of C:Program FilesIBMJava50jrelibsecurity

07/01/2007 12:25 PM <DIR> .
07/01/2007 12:25 PM <DIR> ..
02/01/2007 05:28 AM 40,624 cacerts
02/01/2007 05:28 AM 2,706 java.policy
02/01/2007 05:28 AM 9,864 java.security
02/01/2007 05:28 AM 568 javaws.policy
05/12/2004 04:41 PM 2,212 local_policy.jar
05/12/2004 04:41 PM 2,199 US_export_policy.jar
6 File(s) 58,173 bytes


6.5.3 Create a JCEKS keystore
EKM uses standard and operating system-specific Java keystore methods to store the
public-private key and certificate information. Although EKM supports six keystore types,
currently only the JCEKS keystore type supports both symmetric (LTO4) and asymmetric
(3592) keys. We use a JCEKS keystore in our examples.

In order for EKM to operate correctly, it requires a keystore with a certificate and a private key.
The keytool command in Example 6-49 creates a new JCEKS keystore called
mykeystore.jck and populates it with a certificate and a private key with the alias of
myprivcert.

This command prompts you for a password to access the keystore.

Note: Remember the keystore password you enter here, because you will need it later
when you start EKM. When prompted for a key password, press Enter. Do not enter a new
or different password.

Example 6-49 Create private certificate
C:ekmekm1>keytool -keystore mykeystore.jck -storetype jceks -genkey -alias myp
rivcert -keyalg RSA -keysize 2048
Enter keystore password: mykeystorepword
What is your first and last name?
[Unknown]: key administrator
What is the name of your organizational unit?
[Unknown]: tape encryption
What is the name of your organization?
[Unknown]: IBM
What is the name of your City or Locality?
[Unknown]: Tucson
What is the name of your State or Province?
[Unknown]: Arizona
What is the two-letter country code for this unit?
[Unknown]: US
Is CN=administrator, OU=tape encryption, O=IBM, L=Tucson, ST=Arizona, C=US corre
ct? (type "yes" or "no")
[no]: yes

Enter key password for <myprivcert>
(RETURN if same as keystore password):

C:ekmekm1>

At this time, if you issue the following command, you receive the display shown in
Example 6-50 on page 210:
keytool -ekmhelp


Example 6-50 keytool -ekmhelp display
C:ekmekm1>keytool -ekmhelp
-exportseckey [-v]
[-alias <alias> | aliasrange <aliasRange>] [-keyalias <keyalias>]
[-keystore <keystore>] [-storepass <storepass>]
[-storetype <storetype>] [-providerName <name>]
[-exportfile <exportfile>]

-genseckey [-v] [-protected]
[-alias <alias> | aliasrange <aliasRange>] [-keypass <keypass>]
[-keyalg <keyalg>] [-keysize <keysize>]
[-providerClass <provider_class_name> [-providerArg <arg>]] ...
[-providerPath <pathlist>]

-importseckey [-v]
[-keyalias <keyalias>] [-keypass <keypass>]
[-importfile <importfile>]

Important: If implementing both LTO4 and 3592 encryption, ensure that the keystore that
you select supports both symmetric (LTO4) and asymmetric (3592) keys. At this time, only
the JCEKS keystore supports both symmetric and asymmetric key types.

As you can see from Example 6-50, the Keytool utility has been enhanced to generate aliases
and symmetric keys for encryption on LTO Ultrium 4 tape drives using LTO4 tape. Use the
keytool -genseckey command to generate one or more secret keys (genseckey = generate
secret keys) and to store them in a specified keystore. Most of the keytool -genseckey
parameters are obvious, so we describe only the parameters that merit more interest. The
two parameters of interest for the -genseckey command for LTO4 are:
-alias
The alias parameter generates a single data key. Specify an alias value for a single data
key with up to 12 printable characters (for example, lto, abcfrg, or ibm123tape).
-aliasrange
The -aliasrange parameter generates multiple data keys; this parameter specifies both
the number of data keys to generate and the labels to assign to each key.

The -aliasrange parameter is specified as a three-character alphabetic prefix followed by
lower and upper limits for a series of 16-character (hexadecimal) strings with leading zeroes
filled in automatically to construct aliases that are 21 characters in length. For example:
Specifying ekm1-a yields a series of aliases from EKM000000000000000001 through
EKM00000000000000000A.
Specifying an aliasrange value of xyz01-FF yields a series of aliases from
XYZ000000000000000001 through XYZ0000000000000000FF.

Examples of acceptable aliases that can be associated with symmetric keys are:
abcfrg Acceptable for a single key
ibm123tape Acceptable for a single key


abc000000000000000001 Acceptable for range specification
LTO00000000000000001 Acceptable and our favorite
abc00a0120fa000000001 Acceptable for a single key

Examples of aliases that are not accepted by the EKM are:
abcefghij1234567 Greater than 12 characters for a single key
abcg0000000000000001 The range specification is acceptable because it is less than the
maximum number of characters allowed; however, the prefix
(abcg) is longer than three characters.

If an alias already exists in the keystore, the keytool program issues an exception message
and stops.

The -genseckey command parameter that we used is shown in Example 6-51. In this
example, note the number of characters needed for the keystore password. We cannot use
pword, because the password must be at least six characters, so instead we used
mykeystorepword as our keystore password. Note that we are using the same password for
the keys. We specified a range of aliases by specifying lto00-1f. This generates 32
individual data keys: the first data key starts with the label lto000000000000000001 (21
characters) and the last data key ends with the label lto00000000000000001f (also 21
characters).

Example 6-51 keytool -genseckey parameters
C:ekmekm1>keytool -keystore mykeystore.jck -storetype jceks -genseckey -keyalg
aes -keysize 256 -aliasrange lto00-1f
Enter keystore password: pword
Keystore password is too short - must be at least 6 characters
Enter keystore password: mykeystorepword
Enter key password for <keys>
(RETURN if same as keystore password):
KeyTool is generating batch keys. This process will take a while, be patient ...

32 secret keys have been generated

Let us follow up the -genseckey command with a list of the keystore entries, which is shown in
Example 6-52. Note that we had to specify the keystore password in the command, so if you
decide to create a bat file to do this regularly, you must protect the bat file, because it contains
your keystore password.

Example 6-52 keytool -list command
C:ekmekm1>keytool -list -keystore mykeystore.jck -storepass mykeystorepword
-storetype jceks



lto000000000000000009, Jul 16, 2007, SecretKeyEntry,
lto00000000000000000f, Jul 16, 2007, SecretKeyEntry,


lto00000000000000000e, Jul 16, 2007, SecretKeyEntry,
lto00000000000000000d, Jul 16, 2007, SecretKeyEntry,
lto00000000000000000c, Jul 16, 2007, SecretKeyEntry,
lto00000000000000000b, Jul 16, 2007, SecretKeyEntry,
lto00000000000000000a, Jul 16, 2007, SecretKeyEntry,
lto00000000000000001f, Jul 16, 2007, SecretKeyEntry,
lto00000000000000001e, Jul 16, 2007, SecretKeyEntry,
lto00000000000000001d, Jul 16, 2007, SecretKeyEntry,
myprivcert, Jul 17, 2007, keyEntry,
Certificate fingerprint (MD5): 5D:F7:A5:1F:27:47:23:17:C9:13:56:8F:34:53:57:BB
lto00000000000000001c, Jul 16, 2007, SecretKeyEntry,
lto00000000000000001b, Jul 16, 2007, SecretKeyEntry,
lto00000000000000001a, Jul 16, 2007, SecretKeyEntry,

C:ekmekm1>

6.5.4 Off-site or business partner exchange with LTO4 compared to 3592
In 2.1.2, “Encryption keys and 3592 and LTO4 differences” on page 27, we explained a few
basic differences between LTO4 and 3592 encryption. In this section, we investigate how
off-site or business partner (BP) exchanges of encrypted tapes are accomplished.

The 3592 encryption makes cartridge exchange easy, because the Data Key (DK) that was
used to encrypt the cartridge is included on each cartridge. The encrypted DK on the
cartridge is protected by using the public key of the intended recipient of the tape cartridge.

The cartridge recipient simply needs to use their private key to unlock or decrypt the DK that
was used to encrypt the user data on the cartridge.

So how do you handle off-site or BP exchange with LTO4, because the DK is not included on
the data cartridge? Obviously, you have to provide the recipient with the DK that was used to
encrypt the data. You can do this in one of two ways:
Use a specific key or keys that are already known to the recipient
Send the DK that was used to encrypt the cartridge data to the recipient

Using a specific key or keys that are already known
Clearly, the easiest way to exchange encrypted cartridges is to ensure that you encrypt the
cartridge using a key already known by the recipient. This involves importing the recipient’s


key prior to cartridge creation, and using a BEP, a ILEP, or even SME to use the imported
data key to encrypt the data that is going off-site.

Sending the DK that was used to encrypt the cartridge data
Another method is to send the DK to the recipient after cartridge is created. You need to
identify the DK that was used to encrypt the cartridge so that you share the correct DK with
the encrypted cartridge recipient.

Regardless of which method you select, you still must decide how to securely transport the
DK either from or to the cartridge recipient.

Keytool has been enhanced with two commands to handle this dilemma: -exportseckey and
-importseckey. We show examples of the command and its parameters in Example 6-50 on
page 210. The commands have been designed to use public-private cryptography to ensure
secure key transportation. Each command has a parameter called -keyalias. When
importing keys, -keyalias specifies the alias of a private key in the keystore that will be used
to unlock or encrypt the data being imported. When exporting keys, -keyalias specifies the
alias of a public key that will be used to encrypt the key or keys that are being exported with
the intent that the export recipient will have the correct private key that will be needed to
decrypt the data keys.

Using our keystore as the source, we use keytool -exportseckey as shown in Example 6-53
to export the lto000000000000000001 data key. The command will use the private key located
within myprivcert to encrypt or wrap the lto(shortened)01 DK so that transport security is
not an issue. The recipient of the file keytobp will use the keytool -importseckey and our
public key to unwrap or decrypt the package, yielding the datakey lto000000000000000001.

Example 6-53 export example
C:ekmekm1>keytool -exportseckey -v -alias lto000000000000000001 -keyalias mypr
ivcert -keystore mykeystore.jck -storepass mykeystorepword -storetype jceks -exp
ortfile keytobp
1 secret keys have been successfully exported

C:ekmekm1>

6.5.5 EKM Version 2 installation and customization on Windows
In Example 6-54, you see the EKM/EKM1 directory structure that we created. At this point,
we are ready to customize the keymanagerconfig.properties file that we downloaded earlier.

Example 6-54 Our EKM directory
C:ekmekm1>dir
Volume in drive C has no label.
Volume Serial Number is 6806-ABBD

Directory of C:ekmekm1

07/17/2007 07:39 PM <DIR> .
07/17/2007 07:39 PM <DIR> ..
07/06/2007 04:56 PM 946 KeyManagerConfig.properties
07/16/2007 09:45 AM 12,224 mykeystore.jck
07/01/2007 04:22 PM 63 sekm.bat


Example 6-55 is what our KeyManagerConfig.properties file looked like after making the
minimum number of changes. The changes that we made to the original file are highlighted.

Example 6-55 Our EKM config after minimal changes
C:ekmekm1>type KeyManagerConfig.properties
TransportListener.tcp.timeout = 0
Admin.ssl.keystore.name = mykeystore.jck
config.keystore.password = mykeystorepword
Audit.metadata.file.name = metadata/EKMData.xml
TransportListener.ssl.truststore.name = mykeystore.jck
Audit.handler.file.directory = logs
config.keystore.file = mykeystore.jck
TransportListener.ssl.keystore.name = mykeystore.jck
TransportListener.ssl.keystore.password = mykeystorepword
symmetricKeySet = lto0000-1f
config.drivetable.file.url = FILE:filedrive.table
Admin.ssl.truststore.name = mykeystore.jck
Admin.ssl.keystore.password = mykeystorepword

C:ekmekm1>

After generating keys and aliases, be sure to update the symmetricKeySet property in the
KeyManagerConfig.properties file to specify the new alias or range of aliases and the
filename under which the symmetric keys are stored. Only those keys named in the
symmetricKeySet are validated (checked for an existing alias and a symmetric key of the
proper size and algorithm). If an invalid key is specified in this property, EKM does not start
and an audit record is created.

The management of EKM keys is expected to be performed using existing keystore
management utilities and manual synchronization (that is, extract/export, send, receive, or
import/insert) of the keys into the keystore that is used by the EKM. Note that with this feature
or capability, the names (key IDs and key aliases or labels) of the symmetric keys are much
more apparent to the EKM administrators. The key IDs are not meant to be private or
sensitive information.

The expected administrative steps to populating a keystore are:
1. Import a certificate and private key for EKM-to-EKM communications.
2. Generate a set of symmetric encryption keys.

For each EKM that you employ, change the EKM configuration to refer to the key aliases and
ranges of the newly created keys by using the new config environment variable,
symmetricKeySet.


Although the symmetricKeySet parameter that we used for our EKM reflects a single range of
keys, the parameter can also specify a value for a single keyalias as shown in Example 6-56
where we specify, in addition to the keyrange LTO0000-1f, two single key aliases redbook123
and IBMtape01

Example 6-56 SymmetricKeySet
symmetricKeySet = lto0000-1f, redbook123, IBMtape01

6.5.6 Start EKM
Now, you can start the EKM. Starting the EKM is a two-step process:
1. Start the EKM Admin Console. Because we have our Windows path statement set
correctly to find the correct version of Java, we issue the command from the EKM
directory that we created earlier. When it starts, EKM creates any additional files that it
needs within this directory. The command that we used to start the EKM Admin Console is
shown in Example 6-57. Because the command to start the EKM Admin console is long,
we created a SEKM.BAT file.

Example 6-57 Starting EKM Admin Console
C:ekmekm1>sekm

C:ekmekm1>java com.ibm.keymanager.KMSAdminCmd KeyManagerConfig.properties
#

2. Start the EKM server by issuing the startekm command, which results in Example 6-58.

Example 6-58 Starting the EKM server with the startekm command
# startekm
Starting the Encryption Key Manager 2.0-20070503
Processing
Server is started
#

Figure 6-20 shows our EKM directory after the server has been started.

Figure 6-20 Our EKM directory after the server has been started

6.5.7 Starting EKM as a windows Service
On Windows, EKM server can be installed as a Windows Service or can be started from a
command line as described above. To run the server as a Windows Service, manually
download the binaries for LaunchEKMService.exe from the EKM Web site at:


Refer to the readme file on this Web site for instructions.

Set the system variables JAVA_HOME and PATH:
1. Create a system variable called JAVA_HOME:
a. From the Start menu, select Control Panel.
b. Double-click System.
c. Click the Advanced tab.
d. Click Environment Variables.
e. Under the list of System Variables click New.
f. Specify JAVA_HOME as the variable name and enter the IBM JVM directory, for
example C:ibm-sdk1.4.2.
g. Click OK.
2. Edit the system PATH variable using the following procedure. Setting the PATH variable
from the command line will not work.
a. From the Start menu, select Control Panel.
b. Double-click System.
c. Click the Advanced tab.
d. Click Environment Variables.
e. Scroll the list of System Variables for the Path variable and click Edit.
f. Add the IBM JVM to the beginning of the Path variable and click OK.

Note: You must start the EKM Windows Service manually the first time it is used by
using the control panel.

The LaunchEKMService.exe command has the following format (see Example 6-59):
LaunchEKMService [-help | -i config_file | -u] -help

The options include:
-help Displays this usage information.
-i Installs the key manager Windows Service using the properties specified in
config_file, which should contain full path names for all properties listed either
as files or URLs. After the service is installed, you can start and stop the EKM
Windows Service from Control Panel. The configuration file has to be specified
with this option. If the configuration file does not have all keystore passwords
specified, you are prompted for them. When the Windows Service is started, all
the passwords are obfuscated and stored in the configuration file so no password
is stored in clear text in the configuration file after the first run.
-u Uninstalls the key manager Windows Service.

Example 6-59 The LaunchEKMService command example
LaunchEKMService -i KeyManagerConfig.properties

Be sure to specify properties with full path names in the KeyManagerConfig.properties file if
EKM will be installed and used as a Windows Service. After EKM is installed as a windows
service with the above command, it can be started and stopped from the Control Panel. If you
are attempting to put your keystores on networked drives, you must change the user under


which the EKM Windows Service runs to a network user. By default, the EKM Windows
Service is created to run under the LocalSystem use, which has no access to the network.

To make the change:
1. Log in as Administrator or a user that is a member of the Administrator’s group.
2. Open Services located in the Administrative Tools.
3. Right-click EKM Service and select Properties.
4. Click the Log On tab.
5. Select this account.
6. Enter the user name or browse for user.
7. Enter user passwords in Password and Confirm Password text fields.
8. Click Apply to apply changes.
9. Click OK to close EKMServer properties.

The EKM Windows Service starts successfully.

Tip: The registry keys that the EKM uses as properties when it starts as a service are
located in:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesEKMServerParameters

Example 6-60 shows an example of the EKMDataParser command.

Example 6-60 EKMDataParser metadata report command
C:eekmekm1metadata>java com.ibm.keymanager.tools.EKMDataParser -filename
EKMData.xml -volser ATS015 >file1

Figure 6-21 shows the metadata file report from the EKMDataParser command that was issued
in Example 6-60.

Figure 6-21 Metadata file report from EKMDataParser

6.6 LTO4 Library-Managed Encryption implementation
In this section, we describe how to implement Library-Managed Encryption (LME) on a
TS3500 with LTO4 drives to illustrate the differences between 3592 and LTO4. We use the
EKM and keystore that we created and installed in the preceding sections.

6.6.1 Barcode Encryption Policy
You can implement LME on the TS3500 in one of two methods: a Barcode Encryption Policy
(BEP) or an Internal Library Encryption Policy (ILEP). We provide detail about the BEP.


The logical library that we use is called LTO4 4Gb Fibre and is shown as the last logical
library in the list in Figure 6-22. Note that in the encryption method column, our logical library
reflects none.

Figure 6-22 Our LTO4 logical library prior to any changes

Note that our logical library, LTO4 4Gb Fibre, has two drives and 20 cartridges assigned to it.

To view the encryption method for your library, on the left, select Library  Logical
Libraries and press Enter.

To change the encryption method for your library from the pull-down list:
1. Refer to Figure 6-23. Select Modify Encryption Method and press Enter.

Figure 6-23 Modify the encryption method for a logical library

2. Refer to Figure 6-24 on page 219. From the pull-down list, you choose the Encryption
Method, select Library-Managed and then select Apply. Note that from the TS3500, you
can enable encryption for all three encryption methods: LME, SME, or AME. This TS3500
function eliminates the need for the IBM SSR to enable encryption on tape drives that are
encryption-capable but not encryption-enabled.


Figure 6-24 Setting the encryption method

3. Refer to Figure 6-25. After selecting Apply to enable Library-Managed Encryption, you
then select the scratch encryption policy to implement. Select Barcode (Default), and
then click Apply.

Figure 6-25 Setting the scratch encryption policy

4. Take note of the warning shown in Figure 6-26 on page 220. You might have to restart
your operating system so it can rediscover your tape devices. We did not have to do this in
our testing; however, you might receive the message shown.


Figure 6-26 Rediscovery warning

5. If you receive that message, click OK. Then, you see the panel shown in Figure 6-27,
which reflects that the logical library encryption setting change request has completed.

Figure 6-27 Logical library encryption change completed

Taking another look at our logical library, as shown in Figure 6-28, note that it is now
configured to use Library-Managed Encryption by using Barcode Encryption Policies.

Figure 6-28 Our LME ready logical library


6.6.2 Specifying a Barcode Encryption Policy
Now that our logical library, LTO4 4GB Fibre, is set to encrypt data using a barcode policy, it
is time to set up the BEPs that we use.

A Barcode Encryption Policy (BEP) is a range of cartridge volume serial numbers
(VOLSERs), and it specifies which scratch cartridges to encrypt on the next attempt to write
from the beginning of the tape. It does not indicate which cartridges are currently encrypted.
When used with Library-Managed Encryption (LME), a Barcode Encryption Policy controls
cartridge encryption by VOLSER ranges in all logical libraries that have LME with BEP
selected. If you have defined multiple policies (overlap is not allowed), they all are effective
simultaneously, and they affect which cartridges are to be encrypted in every defined
library-managed logical library in a TS3500 that is enabled to encrypt using BEPs. All BEPs
are shared.

When implementing a Library-Managed BEP with LTO4 drives, you specify which cartridges
to encrypt and which key to use to encrypt the data.

Important: Determining by VOLSER range which cartridges to encrypt works the same for
both LTO4 and 3592 cartridges. Note however, that the key labels within BEPS are used
differently for LTO4 than for 3592. For 3592, the BEPs determine what key is used to
encrypt the data key that was used to encrypt client data. For LTO4, the BEPs determine
what data key is used to encrypt client data.

Both 3592 and LTO4 BEPs are managed similarly in that by using VOLSER ranges, you direct
tape allocations to certain Barcode Encryption Policies. The BEPs that you select depend on
the intended cartridge destination.

Let us review which cartridges are available to our library before we create a BEP. Select
Cartridges  Data Cartridges, and then by using the pull-down menu, we select our logical
library and click Search to produce the list of VOLSERs that you see in Figure 6-29 on
page 222.


Figure 6-29 The cartridges in our logical library

We have 18 cartridges in our logical library, which are VOLSERs ATS000 through ATS017.
Note that in the Encryption column, all of the cartridges reflect an unknown status. The
encryption column contains one of three types of status: Encrypted, Not Encrypted, or
Unknown. An Unknown cartridge has not been previously mounted in a 3592 tape drive or an
Ultrium 4 tape drive.

Select Cartridges  Barcode Encryption Policy, which results in the display shown in
Figure 6-30 on page 223. In this example, you see four BEPs that are already defined. The
first BEP is for TS1120 and the last three BEPs, which refer to ATS cartridges, are for LTO4. If
you did not know which VOLSERs were TS1120 compared to LTO4, how can you know which
BEP refers to which drive type, TS1120 or LTO4?

Notice that the first BEP for VOLSERs JAG000-JAG999 has two key-labels defined and that the
ATS VOLSER BEPs only have one key label defined. Because 3592 wraps the data key and
using two key labels, which point to public keys, uses the two keys to create two EEDKS on
each cartridge; therefore, there are two key labels specified in this example.

Directing your attention to the ATS BEPs, you notice that the first BEP, which is for
ATS000-ATS003, is defined with a mode of Direct-Default Set while the BEP for ATS015-ATS017
has a mode of Direct-Specific. The Direct-Default Set setting calls for EKM to select a key
from a pregenerated key alias range, which we defined as LTO0000-LTO001f in 6.5.3, “Create
a JCEKS keystore” on page 209 and was specifically shown in Example 6-51 on page 211.
The ATS015 BEP actually refers to the key label for EKM to use to obtain the necessary DK in
which to encrypt client data.


Figure 6-30 Existing Barcode Encryption Policies

Let us take a look at how to define a new BEP, which is shown in Figure 6-31.

Figure 6-31 How to define a BEP

In Figure 6-31, select either 3592 or LTO from the All/Other Volsers drop-down list box. In our
example, we select LTO. When LTO is selected, you do not select a Key Label 2, because that
option is grayed out.

Enter the volume serial numbers of the scratch cartridges that begin and end the range to
which you want to assign the barcode encryption policy. Because we cannot have BEP
overlap, we select ATS020-ATS029.

Select the key mode from the drop-down list box. The choices are:
Wrapped-Default Default key label from either the Device drive table or the EKM
configuration file. This is for 3592 cartridges only.
Wrapped-Clear The externally encoded data key (EEDK) is referenced by the
specified key label. This is for 3592 cartridges only.


Wrapped-Hash The EEDK is referenced by a computer value, which corresponds to
the public key that is referenced by the specified key label. This is also
for 3592 cartridges only. For a good explanation of clear label
compared to hash label, refer to “Creating a BEP using Hash values”
on page 472.
Direct-Default Set Select a key in a round-robin manner from the alias range defined to
the keystore. This is for LTO cartridges only and, in our example,
results in a key referenced through a label from LTO0000-LTO001f. We
select this key mode for our example.
Direct-Specific The specified key label references a predefined symmetric data key.
This is also LTO only and used to select a specific key instead of using
a round-robin selection from a range of keys.

If this scenario were a TS1120 BEP instead, you would select two key modes for the policy.
The key mode is the method by which public-private key pairs encrypt a data key to form an
externally encoded data key.

Our selections are shown in Figure 6-32. After selecting APPLY, the new BEP is created.

Figure 6-32 Creating a BEP

The new BEP we created is shown in Figure 6-33 on page 225.


Figure 6-33 New BEP created

6.6.3 TS3500 Library-Managed Encryption differences from TS3310, TS3200,
TS3100, and TS2900
The TS3500 is capable of managing significantly more cartridges than the other IBM LTO
tape libraries because of this it offers more fine grained control over what cartridges to
encrypt. When using library managed encryption with the TS3310, TS3200, TS3100 or
TS2900 encryption is either on or off by Library. However, because of the partitioned nature
of the TS3310, TS3200, and TS3100, you can still maintain a pool of unencrypted cartridges
and a pool of encrypted cartridges. This may be accomplished by configuring the tape library
into multiple library partition’s.
TS3310, TS3200, TS3100, and TS2900 do not support a library managed barcode
encryption policy library managed encryption done on all cartridges in the logical library or
as in the case of the TS2900 the whole library.
For the TS3310, TS3200, TS3100 and TS2900 Library Managed Encryption is a licensed
feature.
The TS3310, TS3200, TS3100 and TS2900 support an SSL connection to the key
manager.
When ALMS is enabled, the TS3500 can be configured to use different key managers for
each logical library.

6.7 LTO4 System-Managed Encryption implementation
In this section, we describe the implementation for System-Managed Encryption (SME) on
the TS3500 library with LTO4 drives on the Windows platform. At this time, on Open
Systems, SME is available on Windows, Linux, AIX, and Solaris platforms.

Note: At the time of this writing Library-Managed Encryption is the current best practice for
Open Systems hosts

Encryption policies specifying when to use encryption are set up in the IBM tape device
driver. System-Managed Encryption (SME) and Library-Managed Encryption (LME)
interoperate with each other. A tape encrypted using SME can be decrypted using LME, and


the reverse is also true provided that they both have access to the same keys and
certificates. Otherwise, this might not be feasible. For details about setting up SME, refer to
IBM Tape Device Drivers Installation and User’s Guide, GC27-2130, and the Planning and
Operator Guide for your tape library.

6.7.1 LTO4 SME implementation checklist for Windows

Note: Best practice is to use Library-Managed Encryption on Windows unless using a
drive not mounted in a tape library or autoloader.

To implement LTO4 SME for Windows on each host that will be accessing the drive:
1. Install the version of the device driver that supports encryption on the Windows operating
system.
2. Configure the device driver encryption configuration file.
3. Edit the Windows registry for drives to be System-Managed.
4. At the TS3500, modify the encryption method for the logical library.


7

Chapter 7. Planning and managing your
keys
In this chapter, we outline the keystores than you can use in conjunction with the Encryption
Key Manager (EKM) to complete a tape data encryption solution.

We intend that the discussions of keystores in this chapter be used as supplements to the
implementation chapters. Here, we outline the steps and commands for configuring
keystores. In Part 4, “Implementing tape data encryption” on page 379, we show you how to
use a specific keystore. If the keystore used in the implementation chapters does not fit with
your particular environmental requirements, the information that this chapter provides might
be sufficient to help you create a keystore that suits your requirements.


7.1 Keystore and SAF Digital Certificates (keyrings)
A keystore is a database that stores a collection of symmetric and asymmetric keys protected
by triple Data Encryption Standard (TDES or triple DES). Key entries hold sensitive
cryptographic key information. Typically, key entries are secret keys or a private key and the
certificate chain for the corresponding public key. Private keys and certificate chains are used
by a given entity for self-authentication. A Trusted Certificate Entry contains a single public
key certificate belonging to another party. A trusted certificate means that the keystore owner
trusts that the public key in the certificate belongs to the identity specified in the subject of the
certificate. This entry can be used to authenticate other parties.

System Authorization Facility (SAF) Digital Certificates are created and stored in the System
Authorization Facility. It is common to refer to a SAF Digital Certificate as a keystore or
keyring.

Storing certificate and keymaterial in a SAF provider adds another layer of security with which
to protect keys in addition to implementing SAF interfaces for certificate and key
management.

Certificates stored in a RACF keyring are always accompanied by a public key and optionally
accompanied by a private key to create an asymmetric key pair. Symmetric key is not
supported in SAF; Digital Signature Algorithm (DSA) keymaterial is not supported.

SAF Digital Certificates can also take advantage of IBM Integrated Cryptographic Service
Facility (ICSF) and hardware cryptographic functions.

Refer to “MVS Open Edition tips” on page 570 and “Advanced security hwkeytool and keytool
scripts” on page 573 for UNIX and UNIX System Services tips and advanced shell scripts for
creating keystores with an added level of security.

7.2 JCEKS
Java Cryptographic Extension Keystore (JCEKS) is a UNIX System Services Java file-based
keystore that is supported on all platforms where the EKM runs. This keystore is
password-protected and TDES-encrypted. Several ways exist to transport and share a
JCEKS, including but not limited to FTP and e-mail. Public and private keys can be exported
from a JCEKS keystore and imported into a JCEKS or RACF keyring, JCE4758KS, or
JCECCAKS. JCEKS also supports symmetric keys for encryption on LTO4 tape drives.

To manipulate a JCEKS keystore, use:
Java keytool utility: The keytool utility (key and certificate management tool) has been
enhanced to generate aliases and symmetric keys for encryption on LTO4 tape drives
using LTO4 media. It also provides for the import and export of symmetric keys to and
from a JCEKS keystore. For more information about keytool, go to:
ftp://ftp.software.ibm.com/s390/java/jce/keytool.html
iKeyman utility: Currently, iKeyman cannot generate, import, or export symmetric keys.
You can use iKeyman to list and delete symmetric keys, though.

We discuss the management of symmetric keys in 7.2.2, “Managing symmetric keys in a
JCEKS keystore” on page 232.

The next section provides examples for generating key-pairs, creating a certificate, using a
CA, and importing the certificate back into JCEKS keystore.


7.2.1 Examples of managing public-private key pairs
In this section, we generate a public-private key, create a self-signed certificate, and export a
self-signed certificate. The exported self-signed certificate can be submitted to a third-party
certificate authority. When the certificate authority sends back a certificate response, it can
then be imported back into the JCEKS keystore.

You may cut and paste the following examples into script files and execute them. If you plan
to run them from the command line, make sure to strip out the backslash characters (). If you
plan to enter these commands in the OMVS command line, you might run out of space. If that
happens, either run the commands from a script or create environment variables to shorten
the commands. The UNIX System Services environment, when entered using a Telnet
daemon, rlogin daemon, or SSH daemon, does not present these problems. Refer to “MVS
Open Edition tips” on page 570 for more information about working in the UNIX System
Services environment.

Example of creating a public-private key pair
In Example 7-1, we generate an Rivest-Shamir-Adleman (RSA) algorithm public-private key
pair. The keypass flag is used to protect the private key with a password and the storepass
value flag is used to set the password of the keystore itself. In Example 7-1, the key alias is
rsa2048Cert, the distinguished name of the subject is IBM, and the keystore file name is
testkeys.jcks. The password used to protect this keystore is “passphrase”, and the expiration
of the certificate is 999 days. The key size generated is 2048 bits in length.

Example 7-1 Keytool generating public-private key pair
keytool -genkey
-alias rsa2048Cert
-dname "CN=IBM"
-keystore testkeys.jcks
-provider IBMJCE
-keyalg RSA
-keysize 2048
-storetype JCEKS
-validity 999

Tip: Keytool commands must be typed on a single line. If you choose to copy these
examples into a script file, the backslash character () can be used to span lines and
improve readability. In OMVS when you use OEDIT, watch out for hidden characters that
might break the script. You can use the hex on command to view all hidden characters.

The caveat, however is that hex on does not show whether spaces exist at the end of the
line. If you use Telnet, rlogin, or ssh to connect to OMVS vi or emacs, make sure that no
characters, including spaces, exist after the backslash character.

Example of exporting a certificate
In Example 7-2 on page 230, the certificate with an alias of rsa2048Cert1 is exported to the
file rsa2048Cert1.cer. This is a binary certificate format and does not include private key
information. If the -rfc flag is used, the certificate is exported in a printable encoding format,
as defined by the Internet RFC 1421 standard. If the -pkcs12 flag is used, the certificate that
is created conforms to the pkcs12 file format, and both public and private keymaterial are
exported and symmetrically encrypted.

Chapter 7. Planning and managing your keys 229

Example 7-2 Export public key into a file
keytool -export
-alias rsa2048Cert1
-storetype JCEKS
-provider IBMJCE
-keypass passphrase

Example of importing a certificate
In Example 7-3, we import our certificate back into the keystore as a trusted certificate entry.
If we had sent the exported certificate to a third-party certificate authority (CA), we import the
fulfilled certificate that was returned to us here. This certificate file can be imported into other
keystores.

Example 7-3 Import a trusted certificate
keytool -import
-alias CArsa2048
-storetype JCEKS
-provider IBMJCE
-keypass passphrase

Example of the keytool -list command
Example 7-4 shows the command to list a JCEKS keystore. This command does not list
private key information. Use the program in 7.8, “ShowPrivateTool” on page 267 to list private
key information.

Example 7-4 List a keystore
keytool -list
-storetype jceks

Output from the list command looks similar to Example 7-5.

Example 7-5 Output from keytool list


rsa2048Cert1, Sep 18, 2006, keyEntry,
Certificate fingerprint (MD5): 93:CB:BB:04:B4:A5:9B:42:D6:C9:3C:05:FF:8B:E8:15
CArsa2048, Sep 18, 2006, trustedCertEntry,
Certificate fingerprint (MD5): E0:BD:75:2B:50:06:EA:C9:F7:BE:5E:8D:EC:4B:11:A3


Example of the keytool using pkcs12 format
PKCS12 is a standard format defined by RSA that describes a file for moving public and
private keymaterial. A PKCS12 file is used to store an X.509 certificate, the public and private
keys associated with that certificate, the chain of Certificate Authorities that signs that
certificate. The file is encrypted with a symmetric key based on a passphrase. You use
PKCS12 files to move your keys from site to site, or to backup keys in situations where
moving a complete JCEKS does not satisfy the key management procedures.

In Example 7-6, we show the keytool commands to export out a certificate with an alias of
TestCert from our keystore SourceKeys.jck into a PKCS12 file. We are using a password of
CLEARTEXTPASS.

Example 7-6 export pkcs12 file
keytool -export -alias "TestCert"
-file export.p12
-keypass "CLEARTEXTPASS"
-storepass "CLEARTEXTPASS"
-pkcs12
-keystore SourceKeys.jck
-storetype JCEKS
-provider IBMJCE

In Example 7-7, we take the PkCS12 file we created in Example 7-6 and store it with an alias
of TestCert into our destinationKeys.jck keystore. If our certificate had been signed by a
certificate authority (CA) instead of being a self-signed certificate, this import would have also
imported the CA certificates into the keystore. When moving certificates into a JCEKS
keystore, if you do not have the signing certificates already in the keystore, you will not be
able to import a non-self-signed certificate into the keystore because the trust status of the
certificate would not be known.

Example 7-7 Import PKCS12 file into JCEKS keystore
keytool -import -noprompt -trustcacerts
-alias "TestCert"
-file export.p12
-pkcs12
-keystore destinationKeys.jck
-storetype JCEKS
-provider IBMJCE

Example 7-8 on page 232 shows the commands we used to list both the source keystore and
the destination keystore.


Example 7-8 Listing the keystore
keytool -list
-keystore SourceKeys.jck
-storetype JCEKS
-provider IBMJCE

keytool -list
-keystore destinationKeys.jck
-storetype JCEKS
-provider IBMJCE

Finally, in Example 7-9, we have a listing of our source keystore, and in Example 7-10 we
have the destination keystore that now has two certificates and keypairs in it. If we were to run
the ShowPrivate utility from 7.8, “ShowPrivateTool” on page 267, it would show that both
entries in the destination keystore have private keys.

Example 7-9 Source Keystore listing

Your keystore contains 1 entry

testcert, Nov 19, 2008, keyEntry,
Certificate fingerprint (MD5): 00:51:A8:93:CD:49:EA:4C:2D:E3:55:2B:55:68:00:5D

Keystore type: JCEKS

Example 7-10 Destination keystore listing

gumbycert, Nov 19, 2008, keyEntry,
Certificate fingerprint (MD5): 80:AD:0A:AC:C0:76:AD:7E:B1:88:4E:38:26:C6:1C:E2
testcert, Nov 19, 2008, keyEntry,
Certificate fingerprint (MD5): 00:51:A8:93:CD:49:EA:4C:2D:E3:55:2B:55:68:00:5D

7.2.2 Managing symmetric keys in a JCEKS keystore
The keytool utility has been enhanced with three command parameters:
keytool -genseckey Generate symmetric key.
keytool -importseckey Import a symmetric key.
keytool -exportseckey Export a symmetric key.

Each data key in the keystore is accessed through a unique alias. An alias is a string of
characters, such as ibm123tape. In JCEKS as in most other keystores, aliases are not case-
sensitive. IBM123Tape is equivalent to ibm123tape and allows access to the same entry in
the keystore. When you use the keytool -genseckey command to generate a data key, you
specify a corresponding alias in the same command. The alias enables you to identify the
correct key for use in writing and reading encrypted data on LTO4 tape.


In the following sections, we detail the commands to generate, import, and export keys. We
discuss the command parameters and provide examples for their usage.

Generating aliases and data keys using keytool -genseckey
Use the keytool -genseckey command to generate one or more secret keys and store them
in a specified keystore. The keytool -genseckey command takes the following parameters:
keytool -genseckey
[-v] [-protected]
[-alias <alias> | aliasrange <aliasRange>]
[-keypass <keypass>] [-keyalg <keyalg>]
[-keysize <keysize>] [-keystore <keystore>]
[-storepass <storepass>] [-storetype <storetype>]
[-providerName <name>]
[-providerClass <provider_class_name> [-providerArg <arg>]] ...
[-providerPath <pathlist>]

The following parameters are of particular importance when generating data keys for EKM to
serve to the LTO4 drives for tape encryption:
-alias Specifies an alias value for a single data key with up to 12 printable
characters (for example, abcfrg or ibm123tape).
-aliasrange When generating multiple data keys, aliasrange is specified as a
3-character alphabetic prefix followed by lower and upper limits for a series
of 16-character (hexadecimal) strings with leading zeroes filled in
automatically to construct aliases that are 21 characters in length. For
example, specifying an aliasrange value of ekm1-a yields a series of aliases
from ekm000000000000000001 through ekm00000000000000000a. Specifying
an aliasrange value of ekm01-ff yields ekm000000000000000001 through
ekm0000000000000000ff.
-keypass Specifies a password used to protect the data key. This password must be
identical to the keystore password. If no password is specified, you are
prompted for it. If you press Enter at the prompt, the key password is set to
the same password as that used for the keystore. The keypass must be at
least six characters long.
-keyalg Specifies the algorithm to be used to generate the data key. On a
distributed platform, the key algorithm must be specified as AES. If the
encrypted tape will be shared with systems on the z/OS platform (the
zOSCompatibility property is set to true), the key algorithm must be
specified as DESede.
-keysize Specifies the size of the data key to be generated. For Open Systems
platforms, key size must be specified as 256. Do not use this parameter
when the zOSCompatibility property is set to true.

You do not have to specify the parameters -providerClass and -providerArg when
generating symmetric keys for a JCEKS keystore. The IBMJCE provider is used by default.
You have to set these parameters when you are using a hardware-based keystore rather
than JCEKS.

Example of generating a range of symmetric keys
You may cut and paste Example 7-11 on page 234 into a script file and execute it. If you plan
to run it from the command line, make sure to strip out the backslash characters ().

In this example, we generate ten symmetric keys from ekm000000000000000001 through
ekm00000000000000000a.


Example 7-11 Generating a range of symmetric keys
keytool -genseckey
-aliasrange ekm1-a
-keyalg AES
-keysize 256
-keystore EKMKeys.jceks
-storetype jceks

After generating keys and aliases, be sure to update the symmetricKeySet property in the
KeyManagerConfig.properties file to specify the new alias or range of aliases. To specify the
ten symmetric keys generated in the previous example as the active key set, you set the
symmetricKeySet parameter in the configuration file:
symmetricKeySet = ekm01-a

You may add aliases of key ranges and specific keys to the symmetricKeySet parameter. Add
the aliases at the end of the symmetricKeySet statement separating them by a comma.

If the symmetricKeySet statement is missing or the syntax is wrong, EKM prints the following
message when starting:

No symmetric keys in symmetricKeySet, LTO drives cannot be supported.

Only those keys named in the symmetricKeySet are validated (checked for an existing alias
and a symmetric key of the proper size and algorithm). If an invalid key is specified in this
property, EKM does not start, an audit record is created, and you get an error message:

Error: Unable to find Secretkey in the config keystore with alias: ekm1-a
Server failed to start

EKM uses the keys in the active key set in a round robin fashion for encrypting data. Though
EKM only uses keys in the active key set for encrypting data, keys for decrypting data do not
have to be in the active key set. EKM uses symmetric keys to decrypt data that was
previously encrypted with these keys regardless of the active key set, as long as the keys are
in the keystore.

Note: For EKM to use the new alias or range of aliases, you have to to update the
symmetricKeySet property in the KeyManagerConfig.properties file.

Importing symmetric keys using keytool -importseckey
Use the keytool -importseckey command to import a symmetric key from an import file. The
keytool -importseckey command takes the following parameters:
keytool -importseckey
[-v] [-keyalias <keyalias>] [-keypass <keypass>]
[-importfile <importfile>]

The following parameters are of particular importance when importing data keys for EKM to
serve to LTO4 drives for tape encryption:
-keyalias Specifies the alias of a private key in the keystore to decrypt all the data
keys in the import file.
-importfile Specifies the keystore file that contains the data keys to be imported.


Example of importing symmetric keys
You may cut and paste Example 7-12 into a script file and execute it. If you plan to run it from
the command line, make sure to strip out the backslash characters ().

In this example, we import symmetric keys from the file import.key into the keystore
EKMKeys.jceks using the private key with the alias ekmcert to decrypt the symmetric keys.

Example 7-12 Importing symmetric keys
keytool -importseckey
-keyalias ekmcert
-storetype jceks
-importfile import.key

Exporting data keys using keytool -exportseckey
Use the keytool -exportseckey command to export a secret key or a batch of secret keys to
an export file. The keytool -exportseckey command takes the following parameters:
keytool -exportseckey
[-v] [-alias <alias> | aliasrange <aliasRange>] [-keyalias <keyalias>]
[-exportfile <exportfile>]

The following parameters are of particular importance when exporting data keys for EKM to
serve to LTO4 drives for tape encryption:
-alias Specifies an alias value for a single data key with up to 12 printable
characters (for example, abcfrg or ibm123tape).
-aliasrange When exporting multiple data keys, aliasrange is specified as a
3-character alphabetic prefix followed by lower and upper limits for a
series of 16-character (hexadecimal) strings with leading zeroes filled in
automatically to construct aliases that are 21 characters in length. For
example, specifying an aliasrange value of ekm1-a yields a series of
aliases from ekm000000000000000001 through ekm00000000000000000a.
Specifying an aliasrange value of xyz01-ff yields
xyz000000000000000001 through xyz0000000000000000ff.
-keyalias Specifies the alias of a public key in a keystore to encrypt all data keys.
-exportfile Specifies the keystore file to contain the data keys to be exported.

Example of exporting a range of symmetric keys
You may cut and paste Example 7-13 on page 236 into a script file and execute it. If you plan
to run it from the command line, make sure to strip out the backslash characters ().

In this example, we export ten symmetric keys from ekm000000000000000001 through
ekm00000000000000000a from the keystore EKMKeys.jceks into a file export.key using the
public key with the alias ekmcert to encrypt the symmetric keys.


Example 7-13 Exporting a range of symmetric keys
keytool -exportseckey
-aliasrange ekm1-a
-storetype jceks
-exportfile export.key
-keyalias ekmcert

7.2.3 Example using IKEYMAN
IKEYMAN (IBM Key Management) is a graphical user interface that is included in Java
Software Developer Kits (SDKs). You use it for working with keystores. IKEYMAN program
code lives in $JAVA_HOME/jre/bin:
On Windows systems, the executable is IKEYMAN.EXE.
On UNIX systems, the binary is ikeyman.

In this section, we present a similar set of examples using IKEYMAN.

Note: IKEYMAN is useful for working with X.509 certificates, however to perform
symmetric key operations on a JCEKS you must use keytool CLI commands.

To use IKEYMAN:
1. Issue the ikeyman command:
java com.ibm.gsk.ikeyman.Ikeyman
2. The IBM Key Management (IKEMAN) window opens, which is shown in Figure 7-1 on
page 237. Click the new file (circled) icon beneath the menu bar, or select Key
Database  File  New.


Figure 7-1 IKEYMAN main window

The New key database window opens as shown in Figure 7-2.

Figure 7-2 New key database window

3. Use the Key database type list box to click JCEKS and enter the keystore file name and
location (Figure 7-3). You also are required to specify this file name and location in the
EKM configuration file. Click OK.

Figure 7-3 New Key database JCEKS


4. The Password Prompt window opens that is shown in Figure 7-4. Enter a password. You
specify this same password in the EKM configuration file. Click OK.

Figure 7-4 Password Prompt dialog

5. In the IBM Key Management window in Figure 7-5, click the certificate (circled) icon, or
select Create  Create New Self-Signed Certificate.

Figure 7-5 Signing certificate dialog


6. Specify the following values in the Create New Self-Signed Certificate window, shown in
Figure 7-6:
a. Key label can be any value but must not contain any blanks. The key label values
correspond to the values that you specify for alias1 and alias2 when editing the EKM
configuration file.
b. Click X509 V3 in the Version list box.
c. Click 1024 in the Key Size list box.
d. The Common Name field defaults to the name of the host that launched the iKeyman
application. Any name can be specified.
e. You must specify an organization name to create a certificate. The remaining fields are
optional or default values.
f. Click OK.

Figure 7-6 Create New Self-Signed Certificate

The IBM Key Management window in Figure 7-7 on page 240 opens, showing the new
certificate.


Figure 7-7 Certificate added

7. Create a second self-signed certificate using the dialogs from Figure 7-5 on page 238 and
Figure 7-6 on page 239. We created two certificates, which are shown in Figure 7-8.

Figure 7-8 Certificates that we created


8. To import certificates that were created in another instance of iKeyman, click
Export/Import on the right. In the Export/Import Key window in Figure 7-9:
a. Select Import Key
b. Select key file type JCEKS
c. Specify the file name of the keystore from which to import keys (keys5.jck, in our
example) and its location.

Figure 7-9 Export/Import Key dialog

9. The Password Prompt window shown in Figure 7-10 opens. Enter the required password
and click OK.

Figure 7-10 Password dialog for source key database

A list of key labels in the specified keystore displays in Figure 7-11.

Figure 7-11 Keystore label list

10.Select one or more for import. In our example, we selected the first one. Click OK.


11.The Change Labels window opens in Figure 7-12. If you wish to change the key label,
select it, and then enter a new label name in the following field. Click Apply.

Figure 7-12 Change Labels dialog

12.Click OK. The IBM Key Management window appears in Figure 7-13 and displays the two
certificates that we created and the one that we imported.

Figure 7-13 Keystore listing

On Open Systems, a JCEKS keystore can be created and manipulated with either IKEYMAN
or command line-entered keytool commands. On z/OS systems, only keytool commands are
available.


7.3 JCE4758KS and JCECCAKS
JCE4758KS is a Java file keystore type, which is supported by Java Developer Kit (JDK) 1.4
and 5.0, that takes advantage of ICSF. This keystore is password-protected and triple
DES-encrypted, and the keymaterial is protected by hardware in one of three ways:
CLEAR (or LABEL)
PKDS
RETAINED

We suggest that you do not use RETAINED with EKM. Refer to 7.10, “Hardware
cryptography” on page 272 for more information. You can use Example 7-14 on page 244
also to create JCECCAKS keystores. To use this example, you have to replace the provider
with the IBMJCECCA provider and replace the key type with JCECCAKS. You can change
the hardware type from PKDS to CLEAR or RETAINED depending on what type and level of
hardware security you want. For more information about the hwkeytool, go to:
ftp://ftp.software.ibm.com/s390/java/jce4758/hwkeytool.html

If a JCECCAKS is specified with the CLEAR option, a public-private key pair can be exported
in a pkcs12 file using the IBMJCECCA provider. This is only supported in JDK 5.0 and higher.

7.3.1 Script notes
You may cut and paste the following examples into script files and execute them. If you plan
to run them from the command line, make sure to strip out the backslash characters (/). If you
plan to enter these commands on the OMVS command line, you might run out of space. If
that happens, either run the commands from a script or create environment variables to
shorten the commands. The UNIX System Services environment, when entered using a
Telnet daemon, rlogin daemon, or SSH daemon, does not present these problems. Refer to
“MVS Open Edition tips” on page 570 for more information about working in the UNIX System
Services environment.

Note: To create and use keystores of type JCE4758KS, the java.security file located in
$JAVA_HOME/lib/security/ has to include the JCE4758 provider in the list. Similar to:
security.provider.2=com.ibm.crypto.hdwrCCA.provider.IBMJCE4758

The script in Example 7-14 on page 244 demonstrates how to generate a public-private key
pair using the hwkeytool. Here, we create an alias of rsa2048hdwrCert1 with a distinguished
name of IBM and store the certificate in the keystore testkeys.cca. The IBMJCE4758
provider is used with the RSA algorithm and a key size of 2048 bits. The store type is
JCE4758KS; the private keymaterial is stored in a PKDS. The keypass and keystore
password are both passphrase.


Example 7-14 Generate a JCE4758KS public-private key pair
hwkeytool -genkey
-alias rsa2048hdwrCert1
-dname "CN=IBM"
-keystore testkeys.cca
-provider IBMJCE4758
-keyalg RSA
-keysize 2048
-storetype JCE4758KS
-hardwaretype PKDS

In Example 7-15, the certificate with an alias of rsa2048hdwrCert1 is exported to the
rsa2048hdwrCert1.cer file. This is a binary certificate format and does not include private key
information. If the -rfc flag is used, the certificate is exported in a printable encoding format,
as defined by the Internet RFC 1421 standard. If the -pkcs12 flag is used, the certificate
created conforms to the pkcs12 file format, and both public and private keymaterial is
exported, but only if the specified alias is of type CLEAR.

Example 7-15 Exporting a certificate from a JCE4758KS
hwkeytool -genkey
-alias rsa2048hdwrCert1
-dname "CN=IBM"
-provider IBMJCE4758
-keyalg RSA
-keysize 2048
-storetype JCE4758KS
-hardwaretype PKDS

In Example 7-16, we import our certificate back into the keystore as a trusted certificate entry.
If we had sent the exported certificate to a third-party CA, we import the fulfilled certificate
that was returned to us here. This certificate file can be imported into other keystores. The
noprompt flag tells the hwkeytool that we will import the trusted entry without prompting, even
though a copy of the public key is already in the keystore.

Example 7-16 Importing a trusted certificate using hwkeytool
hwkeytool -import
-alias CArsa2048hdwr
-noprompt
-file rsa2048hdwr.cer
-storetype jce4758ks
-keypass passphrase
-hardwaretype PKDS
-provider IBMJCE4758 -v

Example 7-17 on page 245 shows the command for listing a JCE4758KS keystore. Use the -v
flag to print extended information. This command does not list private key information. Use


the program in 7.8, “ShowPrivateTool” on page 267 to list private key information. If the
private key information is stored in PKDS or RETAINED, the tool prints the pointer to the key
entry.

Example 7-17 Listing a keystore with hwkeytool
hwkeytool -list
-storetype jce4758ks

Sample output from the hwkeytool is shown in Example 7-18.

Example 7-18 Output from hwkeytool
Keystore type: JCE4758KS
Keystore provider: IBMJCE4758


Alias name: rsa2048ccacert1
Creation date: Sep 18, 2006
Entry type: keyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=rsa4758Cert1
Issuer: CN=rsa4758Cert1
Serial number: 450f2c79
Valid from: Mon Sep 18 16:32:09 MST 2006 until: Sun Dec 17 16:32:09 MST 2006
Certificate fingerprints:
MD5: 07:0A:29:00:F7:3D:AB:02:1E:2A:A5:A8:ED:F9:E3:C4
SHA1: E3:80:25:32:8E:A3:C4:05:5B:EF:3F:5E:F8:40:ED:C1:6C:5A:47:5E

*******************************************
*******************************************

Alias name: carsa2048
Creation date: Sep 18, 2006
Entry type: trustedCertEntry

Owner: CN=rsa4758Cert1
Issuer: CN=rsa4758Cert1
Serial number: 450f2c79
Valid from: Mon Sep 18 16:32:09 MST 2006 until: Sun Dec 17 16:32:09 MST 2006
Certificate fingerprints:
MD5: 07:0A:29:00:F7:3D:AB:02:1E:2A:A5:A8:ED:F9:E3:C4
SHA1: E3:80:25:32:8E:A3:C4:05:5B:EF:3F:5E:F8:40:ED:C1:6C:5A:47:5E
*******************************************
*******************************************

7.3.2 Symmetric keys in a JCECCAKS
The hwkeytool commands now support creating keys in a CKDS and mapping those keys by
label to a JCECCAKS. A clever java programmer could have used CKDS keylabel mapping
and a JCECCAKS to use SECURE symmetric keys for LTO4 drives. Now in Example 7-19 on


we have a hwkeytool command similar to the keytool command. Here we are
creating a range of five symmetric keys in a JCECCAKS keystore where the key material is
stored in a CKDS. The algorithm being used is TDES and the keysize is 192. The CEX2C
does not support SECURE 256 bit AES keys. Using TDES with a keysize of 192 will work for
tape encryption if the EKM has the zoscompatability = true setting.

Example 7-19 Creating a range of keys
hwkeytool -genseckey -v
-aliasRange EKM2008101-2008105
-keyalg TDES
-keysize 192
-hardwaretype CKDS
-keystore ekmkeys.cca
-storetype JCECCAKS
-provider IBMJCECCA

7.4 JCERACFKS
The JCERACFKS uses SAF and RACF services to protect keymaterial and certificates. For
SAF and RACF-stored keyrings, the RACF RACDCERT command is the interface used to
manage the keyring. The RACDCERT command is documented and discussed in the z/OS
Security Server RACF Command Language Reference, SA22-7687, which is available from:
http://publibz.boulder.ibm.com/epubs/pdf/ichza460.pdf

The following facility classes control access to RACDCERT command:
IRR.DIGTCERT.ADD IRR.DIGTCERT.ALTER
IRR.DIGTCERT.DELETE
IRR.DIGTCERT.LIST
IRR.DIGTCERT.ADDRING
IRR.DIGTCERT.DELRING
IRR.DIGTCERT.LISTRING
IRR.DIGTCERT.CONNECT
IRR.DIGTCERT.REMOVE
IRR.DIGTCERT.MAP
IRR.DIGTCERT.LISTMAP
IRR.DIGTCERT.ALTMAP
IRR.DIGTCERT.DELMAP
IRR.DIGTCERT.REKEY
IRR.DIGTCERT.ROLLOVER
IRR.DIGTCERT.LIST

The command in Example 7-20 generates a self-signed certificate authority certificate. You
can use the MatchKeys tool in 7.9, “MatchKeys tool” on page 269 to check the public-private
key pairs.

Example 7-20 Generate a CA
RACDCERT CERTAUTH GENCERT SUBJECTSDN(CN(‘ITSO’)O(‘IBM’)C(‘US’))
WITHLABEL(‘LocalCertAuth’) SIZE(1024)


Tip: In OMVS, a single quotation mark and a parenthesis must be prefixed with a
backslash. The command listed in Example 7-20 looks like:
SYS1> tso “RACDCERT CERTAUTH GENCERT
SUBJECTSDN(CN(‘ITSO’)O(‘IBM’)C(‘US’))

The command in Example 7-21 generates an RSA key pair signed with the local certificate
authority certificate that was created with the previous command.

Example 7-21 Generate a personal certificate
RACDCERT GENCERT SUBJECTSDN(CN(‘ITSO’) O(‘IBM’) C(‘US’)) WITHLABEL(‘RSACert1’)
SIZE(1024) SIGNWITH(CERTAUTH LABEL(‘LocalCertAuth’))

If you will be sending the certificate for third-party verification, it has to be exported as a
certificate request. The command in Example 7-22 generates the request and stores it in the
data set hlq.PUBKEY.REQUEST.ITSO.

Example 7-22 Generate a certificate request
RACDCERT GENREQ (LABEL(‘RSACert1’)) DSN(’hlq.PUBKEY.REQUEST.ITSO’)

After this certificate is sent to a third-party and verified, a response is sent and we can receive
it into hlq.THIRD.PARTY.CERT. You have to also add the CA that was used to sign this
certificate to the ring. The command in Example 7-23 adds the certificate response into
RACF.

Example 7-23 Import a certificate from a data set
RACDCERT ADD(‘hlq.THIRD.PARTY.CERT’) TRUST WITHLABEL(’RSACert1’)

Next, we must create a keyring and connect our certificates to the keyring. The command in
Example 7-24 creates a keyring named ITSOring.

Example 7-24 Create a new ring
RACDCERT ADDRING(ITSOring)

Now that a keyring exists, we can add our certificates to it using the two commands in
Example 7-25.

Example 7-25 Connect certificates to a ring
RACDCERT CONNECT(CERTAUTH LABEL(‘LocalCertAuth’) RING(ITSOring))
RACDCERT CONNECT(LABEL(‘RSACert1’)RING(ITSOring) USAGE(PERSONAL) DEFAULT)

Note: When using a RACF keyring with Java applications, such as EKM, note that a
keyring is not read successfully, unless there is a CA on the ring. It instead generates the
following error:
CertPath not verified

This error also occurs if a SITE certificate that signed the personal certificate is on the ring.
There must be a CA on the ring.


To share data with business partners, their public keys are imported into RACF and
connected to the keyring that the EKM server is set up to use. To export a public key to send
to a business partner, issue the command in Example 7-26.

Example 7-26 Export a certificate with a public key

RACDCERT EXPORT (LABEL(‘RSACert1’)) DSN(’hlq.PUBKEY.1024.ITSO’) FORMAT(CERTDER)

This data set is then sent to a business partner, and the business partner then adds it to their
EKM keystore and uses the label to encrypt tapes that they send to you. You have to validate
with your business partners or remote sites that you trust a common CA, whether third-party
or self-signed, depending on your business and security practices. This certificate can be
imported into the keystore that is used by the EKM at the locations of your business partners.
This lets everyone in the trust network verify that the keys that are used to encrypt data are in
fact part of the trust network.

Note: The RACDCERT command can be used to list certificates and keyrings of other
users when the appropriate permissions to the irr.digtcert.* classes are added.
However, another user’s private key information can never be read. When setting up EKM
to run under a specific user account, remember that you cannot read another user’s private
key information.

Best practice
When connecting certificates to a keyring, the whole certificate chain must be connected to
the ring. This is what allows the certificate path to be verified.

TIP: To verify that the EKM server has sufficient authority, you can issue the following
hwkeytool command from OMVS:
hwkeytool -debug -J-Djava.protocol.handler.pkgs=com.ibm.crypto.provider -list
-keystore safkeyring://USERID/ITSOring -storetype JCERACFKS

7.5 JCE4758RACFKS and JCECCARACFKS
The JCE4758RACFKS and JCECCARACFKS SAF keyrings store certificate information in
RACF, securing private keymaterial in a PKDS protected by ICSF. These keyrings are
available on z/OS only. These keyrings are created and managed through the RACDCERT or
equivalent SAF certificate management command.

JCE4758RACFKS and JCECCARACFKS are similar to keystores created with the PKDS
option of the hwkeytool command. Instead of storing certificates in a file stored in UNIX
System Services, the certificates are stored in a RACF keyring, protected by and managed
with RACF or an equivalent SAF provider. The JCE4758RACKFKS keyring is supported on
JDK 1.4.2. The JCECCARACFKS keyring is supported on JDK 5.0. And, JCE4758RACFS
supports JVM 1.4.2.

The following facility classes control access to RACDCERT command:
IRR.DIGTCERT.ADD IRR.DIGTCERT.ALTER
IRR.DIGTCERT.DELETE
IRR.DIGTCERT.LIST
IRR.DIGTCERT.ADDRING
IRR.DIGTCERT.DELRING


IRR.DIGTCERT.CONNECT
IRR.DIGTCERT.REMOVE
IRR.DIGTCERT.MAP
IRR.DIGTCERT.LISTMAP
IRR.DIGTCERT.ALTMAP
IRR.DIGTCERT.DELMAP
IRR.DIGTCERT.REKEY
IRR.DIGTCERT.ROLLOVER
IRR.DIGTCERT.LIST

7.5.1 RACDCERT keywords
The two keywords used in conjunction with the RACDCERT command to take advantage of
cryptographic hardware are:
ICSF
PCICC

They specify how RACF generates the key pair and how the private key is stored for future
use. If PCICC is specified, the key pair is generated using the PCI, PCI X, or Express2
cryptographic coprocessor. If ICSF is specified, the key pair is generated using software. In
either case, the resulting private key is generated with the RSA algorithm and stored in the
ICSF PKDS.

If either keyword, PCICC or ICSF, is specified and ICSF is not operational or is not configured
for PKA operations, processing stops and an error message displays. If the PCICC keyword
is specified, a PCI, PCI X, or Express2 cryptographic coprocessor must also be present and
operational. Otherwise, processing stops and an error message displays.

If the key is stored as either an ICSF key or a PCICC key, any system using the key in the
future is required to have ICSF operational and configured for PKA operations with this
PKDS. For a PCICC key, any system using the key in the future will also need to have a PCI,
PCI X, or Express2 cryptographic coprocessor present and operational with this PKDS.

The ICSF keyword adds private keymaterial to the PKDS with a generated label. The PCICC
keyword lets you specify the PKDS label. The command in Example 7-27 generates a
personal certificate that is signed with the LocalRACF CA and stores it in a PKDS with the
PKDS label of ITOPS.EKM.CERT and with an alias of EKMServer. The MatchKeys tool (refer to
7.9, “MatchKeys tool” on page 269) can be used to check public-private key pairs.

Example 7-27 Generate a personal certificate with an alias of EKMServer
RACDCERT ID(EKMSERV) GENCERT SUBJECTSDN(CN(‘ITOperations’) O(‘MyCo’) C(‘US’))
WITHLABEL(‘EKMServer’) PCICC(ITOPS.EKM.CERT) SIZE(2048) SIGNWITH(CERTAUTH
LABEL(‘LocalRACF CA’))

Note that the options of the GENCERT command are release-dependent. The options are:
For z/OS R1.8 [ PCICC[(pkds-label | * )] | ICSF[(pkds-label | * )] | DSA ]
For z/OS R1.7 [ PCICC | ICSF | DSA]

In the following examples, the key label is auto-generated.

The following command (Example 7-28 on page 250) generates a self-signed CA certificate.


Example 7-28 Generate a CA
RACDCERT CERTAUTH GENCERT SUBJECTSDN(CN(‘ITSO’)O(‘IBM’)C(‘US’)) PCICC

Tip: In OMVS, a single quotation mark and a parenthesis must be prefixed with a
backslash. The command then looks as follows:
SYS1> tso “RACDCERT CERTAUTH GENCERT
SUBJECTSDN(CN(‘ITSO’)O(‘IBM’)C(‘US’)) PCICC

The command in Example 7-29 generates an RSA key-pair signed with the local CA
certificate created with the previous command.

Example 7-29 Generate a personal certificate
RACDCERT GENCERT SUBJECTSDN(CN(‘ITSO’) O(‘IBM’) C(‘US’)) PCICC
WITHLABEL(‘RSACert1’) SIZE(1024) SIGNWITH(CERTAUTH LABEL(‘LocalCertAuth’))

If you plan to send the certificate to third-party verification, it has to be exported as a
certificate request. The command in Example 7-30 generates the request and stores it in the
data set hlq.PUBKEY.REQUEST.ITSO.

Example 7-30 Generate a certificate request
RACDCERT GENREQ (LABEL(‘RSACert1’)) DSN(’hlq.PUBKEY.REQUEST.ITSO’)

After this certificate is sent to a third-party and verified, a response is sent, and we can
receive it into hlq.THIRD.PARTY.CERT. The command in Example 7-31 adds the certificate
response into RACF. You must also add the CA that was used to sign this certificate to the
ring.

Example 7-31 Import a certificate from a data set
RACDCERT ADD(‘hlq.THIRD.PARTY.CERT’) TRUST ICSF WITHLABEL(’RSACert1’)

Next, we must create a keyring and connect our certificates to the keyring. The command in
Example 7-32 creates a keyring named ITSOring.

Example 7-32 Create a new ring

RACDCERT ADDRING(‘ITSOring’)

Now that there is a keyring, we can add our certificates to it using the two command, as

Example 7-33 Connect certificates to a ring
RACDCERT CONNECT(CERTAUTH LABEL(‘LocalCertAuth’) RING(‘ITSOring’))
RACDCERT CONNECT(LABEL(‘RSACert1’)RING(ITSOring) USAGE(PERSONAL) DEFAULT)


Note: When using a RACF keyring with Java applications, such as EKM, note that a
keyring is not read successfully unless there is a CA on the ring. It instead generates the
following error:
CertPath not verified

This error also occurs if a SITE certificate that signed the personal certificate is on the ring.
There must be a CA on the ring.

To share data with business partners, their public keys are imported into RACF and
connected to the keyring that the EKM server is set up to use. To export a public key to send
to a business partner, issue the command in Example 7-34.

Example 7-34 Export a certificate with a public key
RACDCERT EXPORT (LABEL(‘RSACert1’)) DSN(’hlq.PUBKEY.1024.ITSO’) FORMAT(CERTDER)

This data set is then sent to a business partner. The business partner then adds it to the
business partner’s EKM keystore and uses the label to encrypt tapes that the business
partner sends to you.

Note: Use the RACDCERT command to list certificates and keyrings of other users when
the appropriate permissions to the irr.digtcert.* classes are added. However, another
user’s private key information can never be read. You must consider this when you set up
EKM to run under a specific user account.

You must validate a common CA, whether third-party or self-signed (depending on your
business and security practices), with your business partners or remote sites that you trust.
This CA certificate can be imported into the keystore that is used by the EKM at the locations
of your business partners. This lets everyone in the trust network verify that the keys that are
used to encrypt data are in fact part of the trust network.

7.5.2 Best practice
When connecting certificates to a keyring, the whole certificate chain must be connected to
the ring, allowing the certificate path to be verified.

Tip: To verify that the EKM server has sufficient authority, the following hwkeytool
command can be issued from OMVS:
hwkeytool -debug -J-Djava.protocol.handler.pkgs=com.ibm.crypto.hdwrCCA.provider
-list -keystore safkeyring://USERID/ITSOring -storetype JCERACFKS

The provider list in the java.security file (in $JAVA_HOME/lib/security/java.security)
must contain the corresponding hardware provider:
com.ibm.crypto.hdwrCCA.provider.IBMJCECCA for a JCECCARACFKS
com.ibm.crypto.hdwrCCA.provider.IBMJCE4758 for JCE4758RACFKS

This is similar to the following list:
security.provider.2=com.ibm.crypto.hdwrCCA.provider.IBMJCECCA
security.provider.4=com.ibm.security.cert.IBMCertPath


7.6 PKCS#11
The IBMPKCS11Impl provider uses the Java Cryptography Extension (JCE) and Java
Cryptography Architecture (JCA) framework to seamlessly add hardware cryptography
capabilities using the Public Key Cryptographic Standards # 11(PKCS#11) standard. This
new provider takes advantage of hardware cryptography within the existing JCE architecture
and gives Java 2 programmers the significant security and performance advantages of
hardware cryptography with minimal changes to existing Java applications. Because the
complexities of hardware cryptography are taken care of within the normal JCE, advanced
security and performance using hardware cryptographic devices are made easily available.

PKCS#11support for symmetric keys depends on hardware vendors of cryptographic
devices.

Supported platforms
The PKCS11Impl provider supports a subset of the platforms that the JVM supports at the 5.0
level (Refer to the IBM JVM for 5.0 specific documentation for the supported operating
systems and any other JVM specific requirements). The supported platforms for Java 5.0 are:
Win 32
AIX 5.2/5.3 (32-bit and 64-bit)
Linux (PPC 32-bit and 64-bit)
Linux (Intel 32)
Solaris (32-bit and 64-bit) SPARC only
Linux on zSeries (32-bit and 64-bit)

7.7 IBMi5OSKeyStore
The contents of this keystore are based on an i5OS certificate store file and the password to
access that file. This keystore class allows the modification of the certificate store. You can
make changes without using the Digital Certificate Manager (DCM).

This keystore is new for Java SDK 5.0. It allows DCM certificate stores to be updated.
Java-based tools can be used to create DCM certificate stores. Hardware key support is not
available with this keystore, and there is no application ID support.

The IBMi5OSKeyStore implementation conforms to the Sun Microsystems, Inc., specification
for the Java keystore application programming interface (API). You can find more information
in the keystore javadoc information by Sun Microsystems, Inc., at:
http://java.sun.com/j2se/1.5.0/docs/api/java/security/KeyStore.html

Currently, the IBMi5OSKeyStore does not support symmetric keys. The types of encrypting
tape drives that you support determines the type of keystore that you have to create:
If you support only TS1120 tape drives, you can create either a JCEKS or a
IBMi5OSKeystore keystore.
If you support only LTO4 tape drives, or you have one tape library that supports both
LTO4 and TS1120 tape drives, you must create a JCEKS keystore.
If you have separate tape libraries for the LTO4 and TS1120 tape drives, you can set up
two EKM servers for each of the tape libraries. One EKM server can run using an
IBMi5OSKeystore for use with the TS1120 tape drive and one EKM server can run using a
JCEKS for use with the LTO4 tape drive. The two EKM servers can run on the same
system as long as they listen on different ports.


For details about managing a JCEKS keystore, refer to 7.2, “JCEKS” on page 228.

Note: IBMi5OSKeyStore does not support symmetric keys. You cannot use this keystore
to encrypt data on LTO4 tape drives.

7.7.1 Digital Certificate Manager
A digital certificate is an electronic credential that you can use to establish proof of identity in
an electronic transaction. An increasing number of uses are available for digital certificates to
provide enhanced network security measures. For example, digital certificates are essential
to configuring and using the Secure Sockets Layer (SSL). Using SSL allows you to create
secure connections between users and server applications across an untrusted network,
such as the Internet. SSL provides one of the best solutions for protecting the privacy of
sensitive data, such as user names and passwords, over the Internet. Many System i
services and applications, such as FTP, Telnet, and HTTP Server, provide SSL support to
ensure data privacy.

System i provides extensive digital certificate support that allows you to use digital certificates
as credentials in a number of security applications. In addition to using certificates to
configure SSL, you can use them as credentials for client authentication in both SSL and
virtual private network (VPN) transactions. Also, you can use digital certificates and their
associated security keys to sign objects. Signing objects allows you to detect changes or
possible tampering with object contents by verifying signatures on the objects to ensure their
integrity.

Capitalizing on the System i support for certificates is easy when you use Digital Certificate
Manager (DCM), a free feature, to centrally manage certificates for your applications. DCM
allows you to manage certificates that you obtain from any CA. Also, you can use DCM to
create and operate your own local CA to issue private certificates to applications and users in
your organization.

You can obtain more information at:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzaha/rzaha
jssenative15.htm

7.7.2 How to set up an IBMi5OSKeyStore
The following instructions show how to create a keystore with one self-signed certificate. For
information about installing Digital Certificate Manager (DCM), visit the Information Center:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp

The following tasks assume that DCM is started and the home window opens.

To create a keyring/keystore instance:
1. Select Create New Certificate Store from the menu on the left. In the Create a New
Certificate Store window, click Other System Certificate Store and click Continue. In the
Certificate Store Name and Password window, shown in Figure 7-14 on page 254, specify
a certificate store path and filename and click Create. This filename is also specified in
your EKM configuration file.


Figure 7-14 DCM Certificate Store Name and Password dialog

2. The Certificate Store Created window opens. See Figure 7-15. Select a Certificate Store
menu item to access the new keystore that you have just created.

Figure 7-15 Certificate Store Created


Generate public-private key pairs
Perform the following steps for as many public-private key pairs as needed. If you have
multiple organizational identities within your company that need their own CA-signed
certificates, create a public-private key pair for each organizational identity. These steps
create a public-private key pair as well as a certificate request.

To generate public-private key pairs:
1. Click Select a Certificate Store. In the Select a Certificate Store window, as shown in
Figure 7-16, click Other System Certificate Store. Click Continue.

Figure 7-16 Select Certificate Store window

2. The Certificate Store and Password window opens, as shown in Figure 7-17 on page 256.
Specify the path and file name you entered in Create keyring/keystore instance in
Figure 7-14 on page 254. Click Continue.


Figure 7-17 Certificate Store and Password

3. The Current Certificate Store window opens, verifying your certificate store selection. After
you select a certificate store, you can use the Work with Server and Client Certificates
option of the Fast Path menu group to perform all of the tasks or use the various Manage
Certificates menu group options to perform individual tasks.
4. Select Create Certificate. Select VeriSign or another Internet certificate authority (CA) for
the CA to sign the certificate and click Continue. Figure 7-18 shows this dialog.

Figure 7-18 Select a Certificate Authority (CA)

5. In the Create Certificate window, shown in Figure 7-19 on page 257, select a Key size of
1024 and enter a Certificate label value that corresponds to the alias1 key label value in
your EKM configuration file. Complete the other fields as appropriate. Click Continue.


Figure 7-19 Create Certificate

6. The Certificate Request Created window opens (shown in Figure 7-20). Copy the contents
of the certificate request and paste the contents into the certificate request form provided
by the CA. When the signed certificate is received from the CA, copy it into a file on the
System i server. Click OK.

Figure 7-20 Certificate Request

7. Select Work with Server and Client Certificates. The Work with Server and Client
Certificates window opens, as shown in Figure 7-21 on page 258.


Figure 7-21 Work with Server and Client Certificates

8. Click Import to receive the signed certificate. The Import Server or Client Certificate
window opens, as shown in Figure 7-22. Specify the name of the file into which you copied
the signed certificate. Click Continue.

Figure 7-22 Import Server or Client Certificate

9. The Work with Server and Client Certificates window opens, as shown in Figure 7-23 on
page 259.


Figure 7-23 Work with server and client certificates

Create self-signed certificate (for internal use)
Self-signed certificate key pairs can be used instead of CA-signed certificates for internal use
only. Although DCM does not create self-signed certificates, it does create a local CA-signed
certificate for internal use that serves the same purpose.

To create a self-signed certificate:
1. Click Create a Local CA Certificate. In the Create a Certificate Authority (CA) window, as
shown in Figure 7-24, specify a Key size of 1024 and enter the keystore password. Fill in
the required certificate information. Click Continue.

Figure 7-24 Create a certificate authority (CA)

2. Click Select Certificate Store. In the Select Certificate Store window, select Other
System Certificate Store. Click Continue. The Certificate Store Name and Password
window opens, as shown in Figure 7-25 on page 260. Specify the path and filename that


you entered in the Create keyring/keystore instance window, as shown in Figure 7-14 on
page 254. Click Continue.

Figure 7-25 Certificate Store and Password window

3. In the Install Local CA Certificate window, as shown in Figure 7-26, click the Install
certificate link to install on your browser. Click Continue.

Figure 7-26 Install Local CA Certificate

4. The Certificate Authority (CA) Policy Data window opens, as shown in Figure 7-27 on
page 261. Click Yes to allow creation of user certificates and specify the validity period of


the certificates that are issued by this certificate authority (number of days). Click
Continue.

Figure 7-27 Certificate authority (CA) Policy Data window

5. The Work with Server and Client Certificates window opens, as shown in Figure 7-28, click
Create. You can also navigate to this window by the Work with server and client
certificates option of the Fast Path menu.

Figure 7-28 Work with Server and Client Certificates

6. The Select a Certificate Authority (CA) window opens, as shown in Figure 7-29 on
page 262. Select Local Certificate Authority (CA). Click Continue.


Figure 7-29 Select a Certificate of Authority (CA) window

7. In the Create Certificate window, as shown in Figure 7-30, specify a Key size of 1024 and
enter a Certificate label value that corresponds to the alias2 value in your EKM
configuration file. Complete the other required fields as appropriate. Click Continue.

Figure 7-30 Create Certificate window

The Work with Server and Client Certificates window opens showing the newly created
certificate in the list.


Receive the certificate
Perform these steps to create a second key label (alias2) to be used for EEDK generation
when receiving a certificate from an outside organization. Because this certificate does not
have a private key, it must be imported as a CA certificate through DCM.

To receive the certificate:
1. Select Work with CA certificates and click Import when the Work with CA Certificates
window opens.
2. In the Import Certificate Authority (CA) Certificate window, as shown in Figure 7-31,
specify the fully qualified path and filename of the certificate that you want to import. Click
Continue.

Figure 7-31 Import a Certificate Authority (CA) Certificate window

3. Click Continue.
4. Enter the password when prompted. Click Continue. The Certificate Received window
opens, verifying your certificate.

Export private key and certificate
Perform these steps when copying or moving a key, a key and a certificate, or only a
certificate from a source keystore.

To export the private key and certificate:
1. Select Work with Server and Client Certificates. On the Work with Server and Client
Certificates window, shown in Figure 7-32 on page 264, select the desired certificate and
click Export.


Figure 7-32 Work with Server and Client Certificates window

2. In the Export Destination window, shown in Figure 7-33, select File - Export to a file to
export the certificate to a file. Click Continue.

Figure 7-33 Export Destination window

3. In the Export Server or Client Certificate window, shown in Figure 7-34 on page 265,
specify a file name to which you want to export the certificate and enter the Password.
Click Continue.


Figure 7-34 Export Server or Client Certificate window

The Certificate Exported window opens.

Import private key and certificate
Perform these steps when copying or moving a key, a key and a certificate, or only a
certificate into a target keystore

To import the private key and certificate:
1. Click Work with Server and Client Certificates.
2. In the Work with Server and Client Certificates window, as shown in Figure 7-35, select
the desired certificate and click Import.

Figure 7-35 Work with Server and Client Certificates window


3. The Import Server or Client Certificate window opens, as shown in Figure 7-36. Specify
the fully qualified path and file name of the certificate file to be imported. Click Continue.

Figure 7-36 Import Server or Client Certificate window

4. Specify the Password when prompted (see Figure 7-37). Click Continue.

Figure 7-37 Import Server or Client Certificate password window

The Work with Server and Client Certificates window reopens, showing the imported
certificate, as shown in Figure 7-38 on page 267.


Figure 7-38 Work with Server and Client Certificates window showing imported certificate

7.8 ShowPrivateTool
When working with JCEKS, JCE4758KS, and JCECCAKS, no keytool command or ikeyman
command is available to display private key information. Not being able to display private
keymaterial can create difficulties when importing keymaterial into backup and secondary
keystores.

In Example 7-35 on page 268, we introduce a Java application that takes as input: a keystore
file, a keystore, the password of the keystore, and the keystore format.

Format choices are:
JCEKS
JKS
JCE4758KS
JCECCAKS

Note: The correct providers must be in the $JAVA_HOME/lib/security/java.security file
when executing this program.

In the example, we first set our command-line arguments. The keystore file is then
instantiated into the keystore object using the getInstance method with the stortype as an
argument. We then instantiate a FileInputStream object using the keystore file as input. After
the keystore object is instantiated and the FileInputStream object is created, we can call the
load method from the keystore object, using the FileInputStream and keystore password as
arguments. This loads keystore database information into memory. After that is
accomplished, we simply iterate through all aliases in the keystore to determine whether each
alias has private keymaterial associated with it. If all aliases do, we print all the private
keymaterial.


Note: If you would like to see more information about the private key, locate the following
line:
System.out.println("alias: " + alias + "Private Key=True");

Replace that line with the following line:
System.out.println("alias: " + alias + "Private Key=True" + “n” +
privKey.toString());

However, your results might vary when listing hardware keystores, because the private key
in a hardware keystore is protected.

To run this program, you must first compile it using the javac command:
javac ShowPrivate.java

The javac command has to be in the $PATH. The javac command is located in
$JAVA_HOME/bin. After the source is compiled, a ShowPrivate.class file is created. To run the
program, execute the command:
java ShowPrivate keystore password storetype

Example 7-35 Java application to show private key information
import java.io.FileInputStream;
import java.security.KeyStore;
import java.security.interfaces.RSAPrivateKey;

public class ShowPrivate {
static String keystore = null;
static char[] password = null;
static String storeType = null;
static RSAPrivateKey privKey = null;

static public void main(String[] args) {
try {
if (args.length != 3) {
System.err.println("<keystore> <password> <storetype>");
System.exit(-1);
}
keystore = args[0];
password = args[1].toCharArray();
storeType = args[2];
printPrivate();
} catch (Throwable t) {
t.printStackTrace();
System.err.println("Prog failed. Exiting...");
}
}

static void printPrivate() throws Exception {
// Load a keystore, with arguments from command line
KeyStore ks = KeyStore.getInstance(storeType);
FileInputStream fis = new FileInputStream(keystore);
ks.load(fis, password);
fis.close();

// Iterate through all keys in a keystore
String alias;


for (java.util.Enumeration e = ks.aliases(); e.hasMoreElements();) {
alias = (String) e.nextElement();

if (ks.isKeyEntry(alias)) {
privKey = (RSAPrivateKey) ks.getKey(alias, password);
if (privKey == null) {
System.out.println("alias: " + alias + "Private Key=NULL");

} else{
System.out.println("alias: " + alias + "Private Key=True");
}
}
}

}

}

The output from the command is similar to Example 7-36.

Example 7-36 Output from ShowPrivate
alias: rsakey1 Private Key=True

7.9 MatchKeys tool
The following Java application example shows that a public key and a private key loaded from
a keyring do in fact complement each other. The source in Example 7-37 on page 270 works
with keyrings of the type JCERACFKS. The source involves changing the RACFInputStream
being used to load the keyring from:
com.ibm.crypto.provider.RACFInputStream

The keyring is loaded to:
com.ibm.crypto.provider.hdwrCCA.provider.RACFInputStream.

Changing the provider to the correct hardware provider and the keystore type to the
corresponding keystore type causes this tool to work with JCECCARACFKS and
JCE4758RACFKS.

In Example 7-37 on page 270, first, the program loads the arguments from the command line
into string variables. After the arguments are loaded, we can use RACFInputStream to load
the keyring into memory. With the keyring in memory, we can access the keyring and load the
public and private key objects corresponding to the certificate that we chose at the command
line.

Now that we have key objects, we can encrypt a byte stream test message, using the public
key. Then, we can decrypt the enciphered byte stream with our private key. If the original
clear byte stream matches our decrypted message, we know that the public key and the
private key are a matched set. If they do not match, or an exception is thrown, something is
wrong with our certificate, and this certificate cannot be used for encrypting data, because we
will not be able to decrypt the data.

To run this program, you must first compile it using the javac command:
javac MatchKeys.java


The javac command has to be in the $PATH. The javac command is located in
$JAVA_HOME/bin. After the source is compiled, a ShowPrivate.class file is created. To run the
program, execute the command:
java ShowPrivate personalAlias keyring user ID

Example 7-37 MatchKeys source
import java.security.Key;
import java.security.KeyStore;
import java.security.PublicKey;

import javax.crypto.Cipher;

public class MatchKeys {

public static void main(String argv[]) {
String aliasPersonal = "";
String keyRing = "";
String userid = "";

try {
if (argv.length != 3) {
System.err.println("aliasPersonal keyring userid");
System.exit(-1);
}
aliasPersonal = argv[0];
keyRing = argv[1];
userid = argv[2];
} catch (Throwable t) {
t.printStackTrace();
System.err.println("Prog failed. Exiting...");
}

try {

String keystoreType = new String("JCERACFKS");
String algorithm = new String("RSA");

String pass = new String("password");
byte[] plainText = "testmessage_a very long test message"
.getBytes("8859_1");

/* Get certificates and keys from RACF */
KeyStore keyStore = null;
String provider = null;
System.out.println("Using the IBMJCE provider");
provider = new String("IBMJCE");
com.ibm.crypto.provider.RACFInputStream ksStream = new
com.ibm.crypto.provider.RACFInputStream(
userid, keyRing, pass.toCharArray());
keyStore = KeyStore.getInstance(keystoreType, provider);
keyStore.load(ksStream, pass.toCharArray());

/*
* Get the private and public key associated with the specified
* alias


*/
Key privKey = keyStore.getKey(aliasPersonal, pass.toCharArray());
System.out.println("Obtained the private key for alias "
+ aliasPersonal + ".");
PublicKey pubKey = keyStore.getCertificate(aliasPersonal)
.getPublicKey();
System.out.println("Obtained the public key for alias "
+ aliasPersonal + ".");

/* Use the above keys to encrypt and decrypt a message */
Cipher cp = Cipher.getInstance(algorithm, provider);

System.out.println("Doing Encrypt");
cp.init(Cipher.ENCRYPT_MODE, pubKey);
cp.update(plainText);
byte[] cipherText = cp.doFinal();

System.out.println("Doing Decrypt");
cp.init(Cipher.DECRYPT_MODE, privKey);
cp.update(cipherText);
byte[] newPlainText = cp.doFinal();

System.out.println("Plain Text messages should match below");
System.out.println("plainText = "
+ new String(plainText, "8859_1") + "n"
+ "newPlainText = " + new String(newPlainText, "8859_1"));
} catch (Exception ex) {
System.out.println("Unexpected exception: " + ex.getMessage());
ex.printStackTrace();
}
}
}

We can see the output from MatchKeys in Example 7-38. Here, we have executed the
MatchKeys application on one of our keyrings with a personal certificate in it. We can see
from the output that the public key and the private key were retrieved from the certificate, and
then a message was successfully encrypted and then decrypted. If the public key does not
match the private key in this certificate, the message is not decrypted. This tool can be useful
for troubleshooting issues where a private key might not match a public key. This situation
can happen when you incorrectly delete certificates and then regenerate the certificate while
private key information is still around.

Example 7-38 Output from MatchKeys
JBARNEY:/u/jbarney: >java -cp test.jar com.johann.MatchKeys RSA_1024_Cert1 EKMRing
JBARNEY
Using the IBMJCE provider
Obtained the private key for alias RSA_1024_Cert1.
Obtained the public key for alias RSA_1024_Cert1.
Doing Encrypt
Doing Decrypt
Plain Text messages should match below
plainText = testmessage_a very long test message
newPlainText = testmessage_a very long test message


7.10 Hardware cryptography
Using hardware cryptographic services on z/OS, the three ways to secure keymaterial are:
CLEAR Stores the key in an external hardware key structure where clear text is
tokenized into a CCA external token. This way has the greatest hardware
performance and the lowest hardware security.
PKDS This public-private key data set (PKDS) encrypts the private key with the
system master key. The clear text version of this key can never be viewed or
retrieved. The key pair is stored in a system key storage area. Compared with
CLEAR and RETAINED key types, PKDS has medium hardware security and
medium throughput.
RETAINED Stores the private key actual hardware device and is never allowed to be
viewed or retrieved in the clear. This hardware type offers the maximum
security for keys. It is also the slowest, because cryptographic calls for a
specific key pair must go to the hardware device that holds that key pair. When
using this hardware type, applications are completely tied to the physical
device.

Hardware cryptographic devices on z/OS
Hardware cryptography is the addition of a cryptographic coprocessor such as the
IBM PCI-X Cryptographic Coprocessor (PCIXCC). For more information about IBM
cryptographic hardware, refer to:
http://www-03.ibm.com/security/cryptocards/

Use of a cryptographic coprocessor can free processing cycles by offloading cryptographic
processing to the cryptographic device. In addition, use of a cryptographic device can
increase security by storing keys on the hardware itself, because they are never available in
the clear, nor when in storage or in use. The devices include:
PCIXCC:
– Supported on System z 990 servers and z9
– Replacement for both the PCICC and the Cryptographic Coprocessor Facility (CCF)
– Supports DES, TDES, RSA, and SHA-1 cryptographic operations
– Can perform modular-exponentiation for RSA and DSA
– System (master) Key and retained key storage
PCICC:
– Available on CMOS G5, G6, and System z servers, except System z 990 and z9.
– Supports DES, RSA, and DSA cryptographic operations.
– System (master) Key and retained key storage.
PCICA:
– Supports DES, RSA, and DSA cryptographic operations
– SSL Handshake Acceleration

Note: PCICA supports DSA cryptographic operations; RACF does not support DSA
keys.


CP Assist for Cryptographic Function (CPACF):
– IBM System z 990 servers and z9
– DES, TDES, MAC, and SHA-1 cryptographic operations
Cryptographic Coprocessor Facility (CCF):
– IBM CMOS G5, G6, and System z servers, except the new System z 990 and z9
– DES, TDES, RSA, and various Finance industry-specific cryptographic operations

Supported hardware cryptographic cards for Java 5.0 on Open Systems
Support for these cards through the IBMPKCS11Impl provider begins after the card, its driver,
and any manufacturer’s support software have been installed and are functioning properly.
Refer any issues regarding installation and configuration of these cards and software to the
manufacturer.

The following cards are supported on Windows (32-bit), AIX, Solaris 9 (32-bit and 64-bit,
SPARC only), and Linux:
nCipher nForce 4000 PCI (OB4033P-4K0)
nCipher nForce 1600 PCI (nC3033P-1k6)
nCipher nForce 150 PCI (nc3033P-150)
nCipher nShield 800 PCI (nC4033P-800)
nCipher nShield 150 SCSI (nc4032W-150) Note: This card is going out of support.
nCipher nShield 150 SCSI (nF300KM-1c) Note: This card is going out of support.
nCipher netHSM 1600 (nH1956)
Eracom Orange (CSA8000)
SafeNet Luna SA

The following cards are supported on Windows (32-bit), AIX, Solaris 9 (32-bit, 64-bit, SPARC
only), and Linux. These specific model cards have not been tested by IBM, but support is
assumed, because other cards in the same family have been tested successfully:
nCipher nForce 300 PCI
nCipher nForce 400 PCI
nCipher nForce 400 SCSI
nCipher nShield 400 SCSI
nCipher nShield 150 PCI
nCipher nShield 300 PCI
nCipher netHSM 300 PCI
nCipher netHSM 800 PCI

Alias and symmetric key setup for LTO4 encryption (PKCS11ImplKS
keystore)
In Example 7-39, we show you to create a range of symmetric keys in a hardware-based
PKCS11ImplKS keystore. This example is similar to the example in 7.2, “JCEKS” on
page 228 with the exception that a hardware keystore is involved. As opposed to the example
using JCEKS, we have to specify the providerClass and providerArg parameters. Invoke the
keytool with the -aliasrange option.

Example 7-39 Generating symmetric keys in a PKCS11ImplKS keystore
keytool –genseckey –v –aliasrange AES01-FF –keyalg AES –keysize 256
–keypass password -storetype PKSC11ImplKS
–keystore path/filename_of_vendor’s_PKCS11_interface_to_the_hardware
-providerClass com.ibm.crypto.pkcs11impl.provider.IBMPKCS11Impl
-providerArg path/filename_of_vendor’s_PKCS11configuration_file


This keytool invocation generates 255 sequential aliases in the range
AES000000000000000001 through AES0000000000000000FF and associated AES 256-bit
symmetric keys.

Update the symmetricKeySet property in the KeyManagerConfig.properties file to add the
following line to match any or all of the alias ranges just used and the filename under which
the symmetric keys were stored. Note that EKM might not start if an invalid alias is specified.
Other causes for validation check failure can include incorrect bit size (AES keysize must be
256) or an invalid algorithm for the platform. On z/OS, -keyalg must be DESede (3-DES). On
distributed, -keyalg must be AES and -keysize must be 256. The filename specified in the
config.keystore.file must match the name specified in the –keystore <filename> in the
KeyTool invocation:
symmetricKeySet = AES01-FF,abcfrg
config.keystore.file = <filename>.jceks

Only those keys named in the symmetricKeySet are validated (checked for an existing alias
and a symmetric key of the proper size and algorithm). If an invalid key is specified in this
property, EKM will not start, an audit record will be created, and an error message appears.

Note: If you plan to use a hardware-based keystore for encryption on LTO4 tape drives,
check with the hardware vendor for support of symmetric keys. Not all PKCS11ImplKS
keystores support symmetric keys.


8

Chapter 8. EKM operational considerations
In this chapter, we discuss EKM commands and operational considerations, including the
following topics:
Synchronizing primary EKM configuration data, including drive tables
Maintenance, including adding and removing drives
Backup procedures on Open Systems
Backup procedures on z/OS
Considerations for backing up keystores for:
– JCEKS
– JCERACFKS
– JCECCARACFKS

We also include a mixed mode data sharing example, in which we describe the steps
required to share encrypted tapes with a business partner.


8.1 EKM commands
The following sections discuss the important sync command and other EKM commands used
with the EKM command line interface.

8.1.1 The EKM sync command and EKM properties file
The sync command synchronizes the configuration file properties, drive table information, or
both on another EKM server with those on the EKM server issuing the command. The EKM
sync command creates a Secure Sockets Layer (SSL) connection between two EKMs. The
EKM making the request is considered the client, and the EKM being synchronized with is the
server. By default, the EKM is set to perform server-only authentication. That is to say, the
client checks its trust store to see if the server is trusted. This behavior can be modified by
changing the following line:

Changing the 0 to 1 modifies the EKM behavior to the setting want client auth, which means
that the server requests the client’s certificate for verification; if it does not send it, it still tries
to establish an SSL connection. Setting the 0 to 2 changes the behavior to the setting need
client auth, which means that the server requests the client’s certificates. If the server does
not get them or does not verify them, it ceases SSL handshaking, and synchronization does
not happen.

Note: Make sure to change the line (TransportListener.ssl.clientauthentication) on
the EKM acting as the server during the sync.

In the EKM properties file, the following lines set up the SSL configuration from a keystore
point of view:
Admin.ssl.keystore.name = /keymanager/testkeys
Admin.ssl.truststore.name = /keymanager/testkeys
TransportListener.ssl.keystore.name = /keymanager/testkeys
TransportListener.ssl.truststore.name = /keymanager/testkeys

The SSL server setup is done with the Admin.ssl directives, and SSL client setup is done with
the TransportListener.ssl directives. An EKM can act as either a client or a server when
performing sync commands.

Assuming clientauthentication is set to 2, we perform an SSL handshake with Server
Needs Authentication, and the following chain of events occurs:
1. The EKM acting as SSL server sends certificates from its Admin.ssl.keystore to the client
requesting a sync.
2. The EKM acting as client then searches its TransportListener.ssl.truststore for
matching certificates to validate whether it trusts the server.
3. If it does, the server then requests that the client sends its certificates from the
TransportListener.ssl.keystore.
4. The server searches its Admin.ssl.truststore for matching certificates.
5. Both server and client verify that they trust each other.


6. They then negotiate a common cipher from TransportListener.ssl.ciphersuites.
7. Finally, the requested sync command happens.

Refer to “sync” on page 281 for the detailed command syntax.

8.1.2 EKM command line interface and command set
EKM provides a command-line interface command called KMSAdminCmd that includes the
command set described in the following sections. For more information, see:
http://www.fdesecurityleaders.com/files/ibm_encryption_key_manager_component_for_the_java.pdf

adddrive
Use the adddrive command to add a new drive to the EKM drive table, or you can use the
EKM acceptunknown function to have the drives added automatically. Example 8-1 shows the
adddrive command.

Example 8-1 The adddrive command
adddrive -drivename drivename [ -rec1 alias -rec2 alias]

-drivename Specifies the serial number of the drive to be added.
-rec1 Specifies the alias (or key label) of the drive’s certificate.
-rec2 Specifies a second alias (or key label) of the drive’s certificate.

Example: adddrive -drivename 000123456789 -rec1 alias1 -rec2 alias2

deletedrive
Use the deletedrive command to delete a drive from EKM drive table. Equivalent
commands are deldrive and removedrive. Example 8-2 shows the deletedrive command.

Example 8-2 The deletedrive command
deletedrive -drivename drivename

-drivename Specifies the serial number of the drive to be added.

Example: deletedrive -drivename 000123456789

exit
Use the exit command to exit the EKM admin command and stop the EKM server. An
equivalent command is quit. Example 8-3 shows the exit command.

Example 8-3 The exit command
exit

export
Use the export command to export a drive table or configuration file to the specified URL.
Example 8-4 on page 278 shows the export command.

Chapter 8. EKM operational considerations 277

Example 8-4 The export command
export {-drivetab|-config} -url urlname

-drivetab Specifies to export the drive table.
-config Specifies to export the configuration file.
-url urlname specifies the location where the file is to be written.

Example: export -drivetab -url FILE:///keymanager/data/export.tabl

help
Use the help command to display EKM command line interface command names and syntax.
An equivalent command is the question mark character (?). Example 8-5 shows the help
command.

Example 8-5 The help command
help

import
Use the import command to import a drive table or a configuration file from a specified URL.
Example 8-6 shows the import command.

Example 8-6 The import command
import {-merge|-rewrite} {-drivetab|-config} -url urlname

-merge Specifies to merge the new data with the current data.
-rewrite Specifies to replace the current data with new data.
-drivetab Specifies to import the drive table.
-config Specifies to import the configuration file.
-url urlname specifies the location from which the new data is to be taken.

Example: import -merge -drivetab -url FILE:///keymanager/data/export.table

list
Use the list command to list certificates contained in the keystore named by the
config.keystore.file property. Example 8-7 shows the list command.

Example 8-7 The list command
list [-cert|-key|-keysym][-alias alias -verbose|-v]

-cert List certificates in the specified keystore.
-key List all keys in the specified keystore.
-keysym List symmetric keys in the specified keystore.
-alias alias specifies a specific certificate to list.
-verbose|-v Specifies to display more information about the certificates.

Example: list -alias mycert -v

listcerts
Use the listcerts command to list certificates contained in a keystore named by
config.keystore.file property. Example 8-8 on page 279 shows the listcerts command.


Example 8-8 The listcerts command
listcerts [-alias alias -verbose |-v]

-alias alias specifies a specific certificate to list.
-verbose|-v Specifies to display more information about the certificates.

Example: listcerts -alias alias1 -v

listconfig
Use the listconfig command to list the EKM configuration file properties (Example 8-9).

Example 8-9 The listconfig command
listconfig

listdrives
Use the listdrives command to list the drives in the drive table (Example 8-10).

Example 8-10 The listdrives command
listdrives [-drivename drivename -verbose |-v]]

-drivename drivename specifies the serial number of the tape drive to list.
-verbose|-v Specifies to display more information about the tape drives.

Example: listdrives -drivename 000123456789

logout
Use the logout command to log off the current user (Example 8-11). Equivalent command is
logoff. These commands are only useful when the LoginModule is enabled.

Example 8-11 The logout command
logout

modconfig
Use the modconfig command to modify a configuration file property (Example 8-12).
Equivalent command is modifyconfig.

Example 8-12 The modconfig command
modconfig {-set | -unset} -property name -value value

-set Specifies to set the specified property to the specified value.
-unset Specifies to remove the specified property.
-property name specifies the name of the property.
-value value specifies the new value for the property when -set is
specified.

Example: modconfig -set -property sync.timeinhours -value 24


moddrive
Use the moddrive command to modify drive information in the drive table (Example 8-13). An
equivalent command is modifydrive.

Example 8-13 The moddrive command
moddrive -drivename drivename [ -rec1 alias -rec2 alias]

-drivename Specifies the serial number of the drive.
-rec1 Specifies the alias (or key label) of the drive’s certificate.
-rec2 Specifies a second alias (or key label) of the drive’s certificate.

Example: moddrive -drivename 000123456789 -rec1 newalias1

refresh
Use the refresh command to have EKM refresh the debug, audit, and drive table values with
the latest configuration parameters (Example 8-14).

Example 8-14 The refresh command
refresh

refreshks
Use the refreshks command to refresh the keystore (Example 8-15). Use this command to
reload the keystore specified in config.keystore.file if it was modified while the EKM server
was running. Use this command only when needed, because it can degrade performance.

Example 8-15 The refreshks command
refreshks

startekm
Use the startekm command to start the EKM server (Example 8-16).

Example 8-16 The startekm command
startekm

status
Use the status command to display the status of whether the EKM server is started or
stopped (Example 8-17).

Example 8-17 The status command
status

stopekm
Use the stopekm command to stop the EKM server (Example 8-18).

Example 8-18 The stopekm command
stopekm


sync
Use the sync command to synchronize the configuration file properties, drive table
information, or both on another EKM server with those on the EKM server issuing the
command (Example 8-19). For more information, refer to 8.1.1, “The EKM sync command
and EKM properties file” on page 276.

Example 8-19 The sync command
sync {-all | -config | -drivetab} -ipaddr ip_addr:ssl:port [-merge | -rewrite]

-all Sends both the configuration file properties and the drive table
information to the other EKM server.
-config Sends only the configuration file properties to the other EKM server.
-drivetab Sends only the drive table information to the other EKM server.
-ipaddr ip_addr:ssl:port specifies the address of the other EKM server.
-merge Specifies to merge new drive table data with current data. (The
configuration file is always a rewrite.) This is the default.
-rewrite Specifies to replace the current data with new data.

Example: sync -drivetab -ipaddr remoteekm.ibm.com:443 -merge

Important: If your EKM setup uses Shared HFS function for UNIX Systems Services and
you use shared directories for debug and error logs, we recommend that you do not use
the sync -all or sync -config command, because these commands change the log
settings on synchronized systems to use the same directories.

Use only the sync -drivetable command for this type of configuration.

version
Use the version command to display the version of the EKM server (Example 8-20).

Example 8-20 The version command
version

8.2 Backup procedures
Maintaining primary and secondary EKM servers is desirable for maximum availability of
encrypted backup and recovery.

8.2.1 EKM file system backup
You must save the EKM and its associated data regularly without encryption. If the keystore
password is specified on the strEKM script call (and not stored in the
KeyManagerConfig.properties file), you must keep a copy of the password in a secure
location. The keystore password must be available to recover the EKM. Encrypted save or
archive operations must not be performed on the partition or system where the EKM server is
running. If data on the system where the EKM is running is encrypted, the EKM cannot be
recovered without the availability of a secondary EKM server.

If the keystore password is entered into EKM through a script (that is, the EKM config file
does not contain the keystore password), when the EKM is backed up, the files (configuration
file, drive table, and keystore backup file) do not need to necessarily be treated as secret.


However, the script that contains the keystore password must be stored securely and
resiliently (for example, multiple copies in multiple locations). The keystore password is
confidential information and must be treated as confidential information.

Backing up the script file securely has the same options that exist for backing up the
configuration file that contains the keystore password. But the scripts might be backed up and
stored/transmitted secretly and separately from the EKM backup files, which adds an
additional level of security. Finally, we must emphasize that however the keystore password
is stored (in a script or in the EKM’s configuration file), it must be stored securely and
resiliently so that the keystore password can always be recovered. Loss of all copies of the
keystore password causes loss of all of the keys in the keystore, and there is no recovery
path for this situation.

Example 8-21 shows a sample job to back up a z/OS aggregate.

Example 8-21 Job to back up a z/OS aggregate
//ZFSBKUP1 JOB (OS390),'PROGRAMMER',CLASS=A,
// MSGCLASS=X,MSGLEVEL=(1,1)
//*-----------------------------------------------------------------
//* THIS JOB QUIESCES A ZFS AGGREGATE, DUMPS IT, THEN UNQUIESCES IT.
//*-----------------------------------------------------------------
//DUMP EXEC PGM=ADRDSSU,REGION=4096K
//SYSPRINT DD SYSOUT=*
//SYSABEND DD SYSOUT=*
//OUT DD DSN=hlq.AGGR004.BACKUP,
// DISP=(NEW,CATLG,DELETE),SPACE=(CYL,(5,1),RLSE)
//SYSIN DD *
DUMP DATASET(INCLUDE(hlq.ZFS.AGGR004)) -
CONCURRENT -
OUTDD(OUT)

The zFS aggregate can be restored using DFSMSdss logical restore. It is restored into a new
aggregate (in this case, OMVS.PRV.AGGR005.LDS0005) if the original aggregate (in this case,
hlq.ZFS.AGGR004) still exists. Example 8-22 shows a restore job.

Example 8-22 Job to restore a zFS aggregate
//ZFSREST1 JOB (OS390),'PROGRAMMER',CLASS=A,
//*-----------------------------------------------------------------
//* THIS JOB RESTORES A ZFS AGGREGATE.
//*-----------------------------------------------------------------
//ZFSREST EXEC PGM=ADRDSSU,REGION=0M
//INDS DD DISP=SHR,DSN=SUIMGUR.ZFS.DUMP1
//SYSIN DD *
RESTORE DATASET(INCLUDE(**)) -
CATALOG -
RENAMEU( -
(hlq.ZFS.AGGR004, -
OMVS.PRV.AGGR005.LDS0005) -
) -
WRITECHECK -
INDD(INDS)


After the aggregate is restored, you must perform the following steps for a compatibility mode
aggregate:
1. Unmount the original aggregate (in this case, hlq.ZFS.AGGR004) if it still exists (this also
detaches it).
2. Mount the file system in the restored aggregate (in this case, OMVS.PRV.AGGR005.LDS0005).

After the aggregate is restored, you must perform the following steps for a multi-file system
aggregate:
1. Unmount the file systems in the original aggregate (if any are mounted).
2. Detach the original aggregate (in this case, hlq.ZFS.AGGR004) if it still exists.
3. Attach the restored aggregate (in this case, OMVS.PRV.AGGR005.LDS0005).
4. Mount the file systems in the restored aggregate.

Another example of a logical restore of a zFS aggregate using DFSMSdss by replacing the
existing aggregate is shown. The backup is restored into the original aggregate (in this case,
hlq.ZFS.AGGR004). The aggregate cannot be mounted (or attached) during the restore
operation. Example 8-23 is an example of a restore replace job.

Example 8-23 Job to restore a zFS aggregate with replace
//ZFSREST2 JOB (OS390),'PROGRAMMER',CLASS=A,
//*---------------------------------------------------
//* THIS JOB RESTORES A ZFS AGGREGATE.
//*---------------------------------------------------
//ZFSREST EXEC PGM=ADRDSSU,REGION=0M
//INDS DD DISP=SHR,DSN=SUIMGUR.ZFS.DUMP1
//SYSIN DD *
RESTORE DATASET(INCLUDE(hlq.ZFS.AGGR004)) -
CATALOG -
REPLACE -
WRITECHECK -
INDD(INDS)

DFSMShsm processes zFS data sets. The zFS data sets are VSAM linear data sets (LDS)
that provide a function similar to HFS data sets. DFSMShsm does not process individual file
systems within a zFS data set.

8.2.2 Identifying DFSMShsm to z/OS UNIX System Services
If you plan to use DFSMShsm to back up HFS or zFS data sets mounted by z/OS UNIX
System Services, you have to define DFSMShsm to z/OS UNIX System Services as a super
user. This action provides the required authorization to quiesce or unquiesce a file system.
DFSMShsm must have a RACF user ID associated with it. That user ID must have a default
RACF group, which has an OMVS segment with a group id (GID). The user ID must also
have an OMVS segment with the following parameters:
UID(0) HOME('/')

For additional information, refer to z/OS UNIX System Services Planning, GA22-7800.


8.2.3 Keystore backup
The maintenance, backup, and restoring of key and certificate information depend on which
keyring/keystore implementation is used. One method is:
Create copies of the keystores that the EKM will use.
Retain a PKCS12 format file for each key-certificate combination and store this file in a
secure location (for example, on read-only media in a locked cabinet).
Retain a copy of the PKCS12 format and the keystore at your disaster recovery (DR) sites.

This method allows keystores to be re-created if absolutely necessary.

Note: Simply backing up the keystore file does not work with keystore types JCE4758KS
and JCECCAKS. These keystores can store private key material in a protect PKDS. Follow
the PKDS backup and restoration procedures in 8.3, “ICSF disaster recovery procedures”
on page 286 in addition to backing up the keystore file for these types of keystores.

8.2.4 RACF
In this section, we describe how to copy a RACF database to prepare it for backup. Refer to
z/OS V1R8.0 Security Server RACF System Programmer’s Guide, SA22-7681, for more
details about RACF, the IRRUT200 utility, and the IRRUT400 utility.

As a general rule, use IRRUT200 to create a database copy if the output database is the
same size and on a device with the same track geometry as the input database. However, if
you need to produce a copy of a database of a different size from your original database or on
a different device type (for example, 3390 to 3380), you must use IRRUT400.

In cases where IRRUT200 has detected errors on upper level blocks only, or an analysis of
IRRUT200’s BAM block mappings has shown that significant fragmentation has occurred,
use IRRUT400 to perform the copy. When IRRUT400 copies a database, it rebuilds the
database, re-creating upper level index blocks and reorganizing profiles to eliminate
fragmentation. The profile reorganization makes all the segments of a single profile (for
example, a user profile’s base, TSO, and CICS® segments) contiguous.

The reorganization that IRRUT400 performs can improve performance by reducing the
number of database reads required to read profiles. As a profile is updated over time, its
segments are likely to be written to different physical blocks in the database. You can see this
by looking at the output of the IRRUT200 INDEX FORMAT function and noting the relative
byte address (RBA) of each profile segment. RACF reads the database one 4K block at a
time, so the fewer the number of 4K blocks that a profile’s segments are spread across, the
fewer the number of reads required to access all of them and the better the performance of
RACF functions that require database profile access.

For RACF databases consisting of multiple data sets, one IRRUT400 invocation can process
one or more of the data sets.

The target of the copy cannot be an active RACF database. If you specify an active primary or
backup data set on the system on which IRRUT400 is running, the utility fails. If you need to
refresh an active RACF database, use RVARY to deactivate the database before running
IRRUT400. After utility processing completes, use RVARY to activate the database.

You can copy an active RACF database, but if you do, you must either specify LOCKINPUT
or guarantee that no updates occur to the input data sets from any system.


The three ways to copy an active database using this utility are:
Specify the LOCKINPUT parameter.
This method is preferred. It creates an accurate output database and guarantees that no
information is lost before you are able to use the new copy as your active database. Using
the LOCKINPUT parameter stops you from writing information, other than statistical
updates, to the input database. If you attempt to write to the database while IRRUT400 is
running, RACF generates ABEND483 RC50 or ABEND485 RC50 errors.
Attempts to write to the database result from explicit commands, such as RALTER, and
also from a specific logon attempt. For instance, a logon causes a write to the database
and fails if:
– This is your first logon of the day, and RACF is not in data sharing mode.
– The password is being changed.
– You are entering the correct password after previously entering an incorrect password.
If the LOCKINPUT keyword is specified, you are unable to update the input data sets after
the execution of this utility. LOCKINPUT leaves the input database locked to prevent any
updates to the input database. If the input database was unlocked when IRRUT400
completed, it might get updated and, therefore, be out of sync with the new copy. If you do
not want to switch to the new copy, you must invoke IRRUT400 again, this time with the
UNLOCKINPUT parameter, to unlock the input database so that it can be updated.
Specify the NOLOCKINPUT parameter.
Specifying this parameter does not prevent you from updating the input database:
– If updates occur to the input database during the copy operation, the results of the
utility and the content of the output database are unpredictable. The updates might be
successful, an abend might occur, or the output database might become corrupted.
– If updates occur to the input database after the copy completes, the output database is
complete and consistent. However, it does not reflect any of the updates you made to
the input database. If you plan to use the output database and want to avoid losing
information, be sure that no changes are made between the time that you make the
copy and the time RACF begins using it.
Use IRRUT200 first, then use IRRUT400, in a two-stage process:
– Stage 1: Use IRRUT200
Use IRRUT200 to make a copy of a data set from the input database. This copy must
be the same size and on a device with the same geometry as the input data set. You
can use IRRUT200 only to copy one data set at a time. If the RACF database is
comprised of three data sets, for example, you must invoke the utility three times to
copy all the data sets. Because IRRUT200 uses ENQ or RESERVE serialization while
it copies a data set, updates to the data set are delayed briefly until the copy is
completed.
– Stage 2: Use IRRUT400
Use IRRUT400 against the new copy of the database. You can specify the
NOLOCKINPUT parameter, because the copy is not an active RACF database. This
option avoids the errors that are possible by using the first option and avoids the
unpredictable results that might occur by using the second option. However, to avoid
losing information, you must be sure that no changes are made between the time that
you make the copy and the time that RACF begins using it.
If you have a split database, you must not issue any user or group administration
commands until all the IRRUT200 copies are complete. Issuing these commands can
cause inconsistencies between user and group profiles on the IRRUT400 output
database.


8.3 ICSF disaster recovery procedures
This section outlines the steps required to restore IBM Integrated Cryptographic Service
Facility (ICSF) services in the event that the Cryptographic Domains have been zeroed out.
This can occur when performing a Disaster Recovery/Business Continuity test, in case of a
hardware outage or upgrade, or of a real disaster recovery.

8.3.1 Key recovery checklist
Depending on the way that your organization secures keys or key parts, recovering
cryptographic keys might involve multiple people and key parts. Before starting the recovery,
all required parties must be contacted and have their key parts available. Then, the required
parties must obtain a secure connection to the z/OS systems, which will have their
cryptographic services restored. At this point, the recovery can proceed.

The following list summarizes the required steps:
1. Verify that the corresponding CDKS/PKDS/key part files or data are available.
2. Confirm that all required people are available and have retrieved their key part. The key
part can be stored on paper, a USB device, or any other storage medium.
3. Disable PKA services and PKDS read/write access.
In a Sysplex environment, this must be done on each logical partition (LPAR) in the
Sysplex before continuing to the next step.
4. Update the PKDS:
– Enter the SYM-MK key parts.
– Set the SYM-MK.
– Enter the ASYM-MK key parts.
– Activate the PKDS.
In a Sysplex environment, updating must be done on each LPAR in the Sysplex before
continuing to the next step.
5. Complete the recovery:
– Enable all services and PKDS read/write updates.
– Verify cryptographic services are available.
In a Sysplex environment, this must be done on each LPAR in the Sysplex.

8.3.2 Prerequisites
The key or key part owners must know which CKDS and PKDS they will be recovering before
retrieving their keys or key parts. Review the documentation of your environment to
determine which LPARs need to have keys changed.

Suggestions for naming conventions for the CKDS, PKDS, and key part files:
CKDS: hlq.CSF.sysplex.Dyymmdd.CSFCKDS
PKDS: hlq.CSF.sysplex.Dyymmdd.CSFPKDS
SYM-MK: SYM-MK.sysplex.part.Dyymmdd.txt
ASYM-MK: ASYM-MK.sysplex.part.Dyymmdd.txt


In the naming conventions, descriptions are:
hlq is your system high-level qualifier.
sysplex is the name of the Sysplex.
part can be FIRST, MIDDLE, or FINAL.
yymmdd is a six-character creation date.

Note that this example assumes that the symmetric and asymmetric key parts are stored as
text files (.txt).

8.3.3 Pre-key change: All LPARs in the Sysplex
Be sure the correct CKDS/PKDSs are available and that the installation options data set
points to the right CKDS/PKDS. The initial system check must be done on each system in the
Sysplex before continuing on to 8.3.6, “Entering Master Keys for all LPARs in the Sysplex” on
page 291. Refer to your environment’s documentation for a list of all LPARs in the Sysplex.

Verify which CKDS and PKDS are available for recovery
To verify which CKDS and PKDS are available for recovery:
1. From the main ISPF panel (Figure 8-1), enter option 3 Utilities.

- ISPF Primary Options Menu-
OPTION ==> 3
--- My Options --- .----- All The Options -----.
LOG SPF Options CP Copy/Move ! ----- Top Of Data ------ !
1 Browse DU Dataset Utility ! 0 Settings !
2 Edit LU Library Utility ! 1 View !
3 Utilities TE Dialog Test ! 2 Edit !
4 SPF Foreground V VTOC Utility ! 3 Utilities !
5 SPF Background ! 4 Foreground !
6 TSO ! 5 Batch !
7 Tutorial ! 6 Command !
SD SDSF ! 7 Dialog Test !
! 8 LM Facility !
! 9 IBM Products !
! 10 SCLM !
'---------------------------'
*****************************
* Workbench Options *
* XX Change Colours/Title *
* YY Set Standard Options *
* ZZ Use Personal Options *
F1=HELP F2=SPLIT F3=END F4=RETURN F5=RFIND F6=RCHANGE
8 9 10 11 12
Figure 8-1 ISPF Primary Options Menu panel

2. From the Utility Selection Panel, shown in Figure 8-2 on page 288, enter option 4 Dslist
utility.


Menu Help
______________________________________________________________________________

Utility Selection Panel

1 Library Compress or print data set. Print index listing. Print,
rename, delete, browse, edit or view members
2 Data Set Allocate, rename, delete, catalog, uncatalog, or display
information of an entire data set
3 Move/Copy Move, or copy members or data sets
4 Dslist Print or display (to process) list of data set names.
Print or display VTOC information
5 Reset Reset statistics for members of ISPF library
6 Hardcopy Initiate hardcopy output
7 Transfer Download ISPF Client/Server or Transfer data set
8 Outlist Display, delete, or print held job output
9 Commands Create/change an application command table
11 Format Format definition for formatted data Edit/Browse
12 SuperC Compare data sets (Standard Dialog)
13 SuperCE Compare data sets Extended (Extended Dialog)
14 Search-For Search data sets for strings of data (Standard Dialog)
15 Search-ForE Search data sets for strings of data Extended (Extended Dialog)
Option ===> 4
F1=Help F2=Split F3=Exit F7=Backward F8=Forward F9=Swap
Figure 8-2 Utility Selection Panel

3. From the Data Set List Utility panel, shown in Figure 8-3, enter the high-level qualifier of
the CKDS or PKDS, such as MYSYS.TST.TESTPLEX*.

Menu RefList RefMode Utilities Help
______________________________________________________________________________

Data Set List Utility
More: +
blank Display data set list P Print data set list
V Display VTOC information PV Print VTOC information

Enter one or both of the parameters below:
Dsname Level . . . MYSYS.TST.TESTPLEX.*
Volume serial . .

Data set list options
Initial View . . . 1 1. Volume Enter "/" to select option
2. Space / Confirm Data Set Delete
3. Attrib / Confirm Member Delete
4. Total / Include Additional Qualifiers
/ Display Catalog Name

When the data set list is displayed, enter either:
"/" on the data set list command field for the command prompt pop-up,
an ISPF line command, the name of a TSO command, CLIST, or REXX exec, or
Option ===> 4
F1=Help F2=Split F3=Exit F7=Backward F8=Forward F9=Swap
F10=Actions F12=Cancel
Figure 8-3 Data Set List Utility panel

4. From the panel, shown in Figure 8-4 on page 289, verify that the correct CKDS and
PKDSs exist on this system.


Menu Options View Utilities Compilers Help
______________________________________________________________________________
DSLIST - Data Sets Matching MYSYS.TST.TEXTPLEX Row 1 of 1

Command - Enter "/" to select action Message Volume
-------------------------------------------------------------------------------
MYSYS.TST.TESTPLEX.CKDS *VSAM*
MYSYS.TST.TESTPLEX.CKDS.DATA TSOE01
MYSYS.TST.TESTPLEX.CKDS.INDEX TSOE01
MYSYS.TST.TESTPLEX.PKDS *VSAM*
MYSYS.TST.TESTPLEX.PKDS.DATA TSOE22
MYSYS.TST.TESTPLEX.PKDS.INDEX TSOE22
***************************** End of Data Set list ****************************

Command ===> Scroll ===> CSR
F1=Help F2=Split F3=Exit F5=Rfind F7=Up F8=Down F9=Swap
F10=Left F11=Right F12=Cancel
Figure 8-4 DSLIST listing

8.3.4 Check the ICSF installation options data
To check the options data:
1. From the previous panel, go back one panel by pressing F3 (Figure 8-4). You see the
panel shown in Figure 8-3 on page 288. Enter the high-level qualifier of the installation
options data set and press Enter.
2. From the menu shown in Figure 8-5, select the installation options data set for editing by
placing an E to the left of it.

Menu Options View Utilities Compilers Help
______________________________________________________________________________
DSLIST - Data Sets Matching SYS1.TEST.PARMLIB Row 1 of 1

Command - Enter "/" to select action Message Volume
-------------------------------------------------------------------------------
E SYS1.TEST.PARMLIB TSOE01
***************************** End of Data Set list ****************************

Command ===> Scroll ===> CSR
F1=Help F2=Split F3=Exit F5=Rfind F7=Up F8=Down F9=Swap
F10=Left F11=Right F12=Cancel

Figure 8-5 Selecting the installation options


3. In the data set (Figure 8-6), verify that the installation options data is correct for the given
system. Verify the CKDSN and PKDSN are pointing to the correct CKDS and PKDS.

****************************** Top of Data ****************************
/* */
/* LICENSED MATERIALS - PROPERTY OF IBM */
/* */
/* "RESTRICTED MATERIALS OF IBM" */
/* 5694-A01 */
/* */
/* (C) COPYRIGHT IBM COPR. 1990, 2003 */
/* */
/* STATUS = HCR770A */
/* */
CKDSN(MYSYS.TST.TESTPLEX.CKDS)
PKDSN(MYSYS.TST.TESTPLEX.PKDS)
COMPAT(NO)
SSM(NO)
KEYAUTH(NO)
CKTAUTH(NO)
TRACEENTRY(1000)
USERPARM(USERPARM)
COMPENC(DES)
REASONCODES(ICSF)
PKDSCACHE(64)

Figure 8-6 Verifying the installation options

8.3.5 Disable all services
To disable all services:
1. Go to the Integrated Cryptographic Service Facility (ICSF) main panel.
2. From the main ICSF panel, shown in Figure 8-7, choose option 4 ADMINCNTL. Press Enter.

HCR7720 ---------- Integrated Cryptographic Service Facility------------------
OPTION ===> 4
Enter the number of the desired option.

1 COPROCESSOR MGMT - Management of Cryptographic Coprocessors
2 MASTER KEY - Master key set or change, CKDS/PKDS Processing
3 OPSTAT - Installation options
4 ADMINCNTL - Administrative Control Functions
5 UTILITY - ICSF Utilities
6 PPINIT - Pass Phrase Master Key/CKDS Initialization
7 TKE - TKE Master and Operational Key processing
8 KGUP - Key Generator Utility processes
9 UDX MGMT - Management of User Defined Extensions

Licensed Materials - Property of IBM
5694-A01 (C) Copyright IBM Corp. 1989, 2004. All rights reserved.
US Government Users Restricted Rights - Use, duplication or
disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

Press ENTER to go to the selected option.
Figure 8-7 ICSF panel i h i


3. Disable all of the services by selecting each of them with a D (for disable) as shown in
Figure 8-8.
A status message appears in the upper right corner of the panel indicating whether the
services have been stopped.

------------------- ICSF - Administrative Control Functions -- Row 1 to 4 of 4
COMMAND ===> SCROLL ===> PAGE

Active CKDS: MYSYS.TST.TESTPLEX.CKDS
Active PKDS: MYSYS.TST.TESTPLEX.PKDS

To change the status of a control, enter the appropriate character
(E - ENABLE, D - DISABLE) and press ENTER.

FUNCTION STATUS
-------- ------
d Dynamic CKDS Access ENABLED
d PKA Callable Services ENABLED
d PKDS Read Access ENABLED
d PKDS Write, Create, and Delete Access ENABLED
*******************************Bottom of data ********************************
Figure 8-8 ICSF Administrative Control panel

4. After this is done for each system in the Sysplex, continue to the next section, 8.3.6,
“Entering Master Keys for all LPARs in the Sysplex” on page 291.

8.3.6 Entering Master Keys for all LPARs in the Sysplex
After you have completed the steps described in the previous section for all LPARs in the
Sysplex, you may start with the tasks outlined in the following sections.

Enter SYM-MK Master Key parts
These steps must be done by Master Key part owners:
1. From the panel shown in Figure 8-8, return to the main ICSF panel by clicking F3. Select
option 1 COPROCESSOR MGMT as shown in Figure 8-9 on page 292. Press Enter.


OPTION ===> 1



Press END to exit to the previous menu.

Figure 8-9 ICSF panel

2. Select the processors to set the Master Key on with the E option (for ENABLE) and press
Enter. See Figure 8-10.

------------------- ICSF - Coprocessor Management ------------ Row 1 to 4 of 4

Select the coprocessors to be processed and press ENTER.
Action characters are: A, D, E, K, R and S. See the help panel for details.

COPROCESSOR SERIAL NUMBER STATUS
-------- ------------- ------
e X00 77712345 ACTIVE
e X01 77712346 ACTIVE
e X02 77712347 ACTIVE
e X03 77712348 ACTIVE
*******************************Bottom of data ********************************

Figure 8-10 ICSF Coprocessor Management panel

3. Retrieve the key or key part.
4. In the panel shown in Figure 8-11 on page 293, enter SYM-MK, the key part (FIRST,
MIDDLE, or FINAL), the checksum, and the key value. Note that the key registers are both
empty. Press Enter and you see a status message in the upper right corner indicating the
key part has been loaded. Check to be sure that the Verification Pattern (VP) and Hash
Pattern (HP) match what is in the Master Key part document.


---------------------- ICSF - Clear Master Key Entry ------------------------
COMMAND ===>
Symmetric-keys new master key register : EMPTY
Asymmetric-keys new master key register : EMPTY

Specify information below

Key Type ===> SYM-MK (SYM-MK, ASYM-MK)

Part ===> FIRST (RESET, FIRST, MIDDLE, FINAL)

Checksum ===> B7

Key Value ===> 023457CB6E20537B
===> 5ED689736749ADF2
===> 0000000000000000 (ASYM-MK only)

Press ENTER to process.

Figure 8-11 ICSF Clear Master Key Entry panel

5. Go back to the beginning of this section (“Enter SYM-MK Master Key parts” on page 291).
6. Enter SYM-MK Master Key parts and repeat the same instructions by each key part
owner. For the previous step, enter either MIDDLE or FINAL for the key part as
appropriate. Ensure the FINAL key part is indeed entered last.

Set the SYM-MK
After you have completed all steps in the previous section, set the SYM-MK:
1. Return to the main ICSF panel and select option 2 MASTER KEY as shown in Figure 8-12.
Press Enter.

OPTION ===> 2




Figure 8-12 ICSF panel: Select option 2 MASTER KEY


2. Next, select option 2 SET MK and press Enter (see Figure 8-13). A message appears in the
upper right corner indicating whether the set was successful.

-------------------------- ICSF - Master Key Management ------------------
OPTION ===> 2


1 INIT/REFRESH CKDS - Initializw a Cryptographic Key Data Set or
acticvate an updated Cryptographic Key Data Set
2 SET MK - Set a DES/symmetric-keys master key
3 REENCIPHER CKDS - Reencipher the CKDS prior to changing the FDES
/symmetric-keys master key
4 CHANGE MK - Change the DES/symmetric-keys master key and
activate the reenciphered CKDS
5 INITIALIZE PKDS - Initialize or update a PKDS Cryptographic
Key Data Set header record
6 REENCIPHER PKDS - Reencipher the PKA Cryptographic Key Data Set
7 ACTIVATE PKDS - Activate the PKDS after it has been reenciphered
8 REFRESH CACHE - Refresh the PKDS Cache if enabled


Figure 8-13 ISCF Master Key Management: Select option 2 SET MK

Enter ASYM-MK key parts
This section must be performed by Master Key part owners:
1. Go to the ICSF Main panel. From the main ICSF panel, choose option 1 COPROCESSOR
MGMT as shown in Figure 8-14. Press Enter.

OPTION ===> 1




Figure 8-14 Integrated Cryptographic Service Facility: Select COPROCESSOR MGMT

2. Select the coprocessors to set the Master Key on with the E option (for ENABLE) as
shown in Figure 8-15 on page 295. Press Enter.


------------------- ICSF - Coprocessor Management ------------ Row 1 to 4 of 4

Select the coprocessors to be processed and press ENTER.
Action characters are: A, D, E, K, R and S. See the help panel for details.

COPROCESSOR SERIAL NUMBER STATUS
-------- ------------- ------
e X00 77712345 ACTIVE
e X01 77712346 ACTIVE
e X02 77712347 ACTIVE
e X03 77712348 ACTIVE
*******************************Bottom of data ********************************

Figure 8-15 ICSF Coprocessor Management panel

3. In the panel shown in Figure 8-16, enter ASYM-MK, key part (FIRST, MIDDLE, or FINAL),
the checksum, and the key value. Note that the key registers are both empty. Press Enter
and you see a status message in the upper right corner indicating the key part has been
loaded. Check to be sure that the Verification Pattern (VP) and Hash Pattern (HP) are the
same as what is recorded in your key part.

---------------------- ICSF - Clear Master Key Entry ------------------------
COMMAND ===>
Symmetric-keys new master key register : EMPTY
Asymmetric-keys new master key register : EMPTY

Specify information below

Key Type ===> ASYM-MK (SYM-MK, ASYM-MK)

Part ===> FIRST (RESET, FIRST, MIDDLE, FINAL)

Checksum ===> BD

Key Value ===> 123DE98DA620537B
===> 5ED58392E04FBDF2
===> 5739EA8926375995 (ASYM-MK only)


Figure 8-16 ICSF Clear Master Key Entry panel

4. Go back to the beginning of this section, “Enter SYM-MK Master Key parts” on page 291
and repeat the same instructions by each key part owner. For step 3, enter either MIDDLE
or FINAL for the key part as appropriate. Ensure the FINAL key part is indeed entered last.

Activate the PKDS
After all of the key parts have been entered, activate the new PKDS:
1. From the main ICSF panel, enter option 2 SET MK as shown in Figure 8-13 on page 294.
2. Enter option 7 ACTIVATE PKDS to activate the new PKDS. See Figure 8-17 on page 296.


-------------------------- ICSF - Master Key Management ------------------
OPTION ===> 7


1 INIT/REFRESH CKDS - Initialize a Cryptographic Key Data Set or
acticvate an updated Cryptographic Key Data Set
2 SET MK - Set a DES/symmetric-keys master key
3 REENCIPHER CKDS - Reencipher the CKDS prior to changing the FDES
/symmetric-keys master key
4 CHANGE MK - Change the DES/symmetric-keys master key and
activate the reenciphered CKDS
5 INITIALIZE PKDS - Initialize or update a PKDS Cryptographic
Key Data Set header record
6 REENCIPHER PKDS - Reencipher the PKA Cryptographic Key Data Set
7 ACTIVATE PKDS - Activate the PKDS after it has been reenciphered
8 REFRESH CACHE - Refresh the PKDS Cache if enabled


Figure 8-17 ICSF Master Key Management panel

3. Enter the new PKDS data set as shown in Figure 8-18.

----------------- ICSF - Activate PKA Cryptographic Key Data Set --------------
COMMAND ===>

Enter the name of the new PKDS below.

New PKDS ===> 'MYSYS.TST.TSTPLEX.PKDS'

Press ENTER to activate the PKDS.

Figure 8-18 ICSF Activate PKA Cryptographic Key Data Set panel

8.3.7 Post-key change for all LPARs in the Sysplex
The procedures in this section must be completed on all LPARs in the Sysplex after the
CKDS and PKDS have been activated on all LPARs.

Enable all services and PKDS read and write access:
1. Return to the main ICSF panel and select option 4 ADMINCNTL as shown in Figure 8-19 on
page 297.


OPTION ===> 4




Figure 8-19 Integrated Cryptographic Service Facility: Selecting ADMINCNTL

2. Select the services that you want to enable by entering E as shown in Figure 8-20. A
message appears in the upper right corner indicating whether the changes were
successful.

------------------- ICSF - Administrative Control Functions -- Row 1 to 4 of 4

Active CKDS: MYSYS.TST.TESTPLEX.CKDS
Active PKDS: MYSYS.TST.TESTPLEX.PKDS

To change the status of a control, enter the appropriate character
(E - ENABLE, D - DISABLE) and press ENTER.

FUNCTION STATUS
-------- ------
e Dynamic CKDS Access DISABLED
e PKA Callable Services DISABLED
e PKDS Read Access DISABLED
e PKDS Write, Create, and Delete Access DISABLED
*******************************Bottom of data ********************************

Figure 8-20 ICSF Administrative Control Functions panel

Key change verification
Now that the SYM-MK and the ASAM-MK Master Keys have been changed on all LPARs, a
sample application or multiple applications that use keys protected by the SYM-MK and
ASYM-MK must be run.


8.3.8 Exiting disaster recovery
Refer to your disaster recovery test documentation for processes that must be followed before
leaving the disaster recovery/business continuity site.

8.4 Business partner tape-sharing example
A common practice is to share tapes with other organizations for joint development,
contracting services, or other purposes. To facilitate this sharing, EKM can store two sets of
wrapped encryption keys on a TS1120 tape. This function allows another organization to read
that specific tape without your providing them any shared secret information or compromising
the security of your certificates and keys.

This capability gives you the flexibility to make a specific tape readable by both your own and
another organization. To take advantage of this capability, you must add that other
organization’s certificate and public key to your keystore.

For LTO4 tape drives, the process is different. As with LTO4 encryption, the key is not stored
on the media, you have to pass along the symmetric key in addition to the media. You can
export symmetric keys from your keystore to a public key encryption-protected file. To share
tapes with a business partner, you export the required keys from your keystore to a file. Your
business partner has to import the keys from the file to the business partner’s keystore to
read the LTO4 media encrypted by you. The next section applies to encryption on TS1120
tape drives only.

8.4.1 Key-sharing steps
Key-sharing is performed by adding the public part of the other organization’s public-private
certificate and keys to your EKM’s keystore using a second alias (or key label). When the
TS1120 tape is written, the data key is stored on the tape, protected by two sets of
public-private keys: your set and the other organization’s set. The other organization is then
able to use its EKM and private key to unwrap the data key that allows them to read that
specific tape. To reiterate, your EKM must have the certificate of the business partner
organization. The other organization must have the associated private key in the keystore
used by the other organization’s EKM.

This capability gives you the flexibility to make a specific tape readable by both your own and
another organization. To take advantage of this capability, you must add that other
organization’s certificate and public key to your keystore.

For information about sharing encrypted LTO4 tapes with business partners, refer to 8.4.3,
“Exporting a symmetric key from a JCEKS keystore” on page 302 and 8.4.6, “Importing
symmetric keys to a JCEKS keystore” on page 306.

8.4.2 Exporting a public key and certificate to a business partner
To write encrypted tapes to send to a business partner, you must import a public
key/certificate from your business partner (the business partner can read the encrypted tape
with the business partner’s corresponding private key). The reverse is also true: to have a
business partner create encrypted tapes that you can read, you must export a public
key/certificate from one of your public-private key pairs. Then, you can read the encrypted
tape with your private key.


After you have public-private keys and certificates in place, see 7.1, “Keystore and SAF
Digital Certificates (keyrings)” on page 228. Examples in the following sections describe how
to export a certificate and public key to a business partner and how the business partner
imports it so that the business partner can write encrypted tapes that can be read by your
EKM.

You must validate with your business partners or remote sites that you trust a common
certificate authority (CA), whether third- party or self-signed, depending on your business and
security practices. This certificate can be imported into the keystore that is being used by the
EKM at your business partner’s locations. To send this certificate, export it to a data set.

Note: In the following examples, we are sending the public key and corresponding
certificate that was created for use by your EKM. We only send the public key (not the
private key), so security is not compromised.

Export from JCEKS keystore
You can use the following commands to export the self-signed certificate and public key alias
of MyEKMServer from an JCEKS keystore to a file called ExportedPublicKey.cer using the
keytool utility:
keytool -export -file ExportedPublicKey.cer -keystore EKMKeystore -alias
MyEKMServer -storepass “somesecretphrase” -storetype JCEKS -provider IBMJCE
-keypass “somesecretphrase”

You may print the newly created certificate file by using the keytool printcert utility:
keytool -printcert -file ExportedPublicKey.cer –storetype JCEK

Now, you may send the ExportedPublicKey.cer file to your business partner. You might
possibly have to tell the business partner the alias MyEKMServer if the business partner is not
able to use an encoding mechanism of Public Key Hash. We explain this in more detail in
8.4.4, “Importing a public key and a certificate from a business partner” on page 303.

Export from JEC4758KS keystore
You may use the following commands to export the self-signed certificate and public key
labeled MyEKMServer from a JCE4758KS keystore to a file called ExportedPublicKey.cer by
using hwkeytool:
hwkeytool -export -file ExportedPublicKey.cer -keystore EKMKeystore4758 -alias
MyEKMServer -storepass “somesecretphrase” -storetype JCE4758KS -provider
IBMJCE4758 -keypass “somesecretphrase”

You can print the newly created certificate file using the hwkeytool printcert utility.
hwkeytool -printcert -file ExportedPublicKey.cer –storetype JCE4758KS

Now, you may send the ExportedPublicKey.cer file to your business partner. You might
possibly need to tell the business partner the alias MyEKMServer if the business partner is not
able to use an encoding mechanism of Public Key Hash. This is explained in more detail in
8.4.4, “Importing a public key and a certificate from a business partner” on page 303.

Export from z/OS JCERACFKS or JCE4758RACFKS/JCECCARACFKS
You have to select from one of the following techniques depending on the type of certificate
you use. To help make this example clearer, we also include samples of the steps that are
used to create the public-private key pair from which the public key and certificate are
generated. Refer to 7.1, “Keystore and SAF Digital Certificates (keyrings)” on page 228 for
more detail about RACF keystores.


Self-signed certificate
For a self-signed certificate:
1. Generate a Rivest-Shamir-Adleman algorithm (RSA) key-pair and certificate with the
following RACDCERT command using ICSF for private key storage. The key size is 2048
bits and the private key is saved in the ICSF PKDS in an encrypted form:
RACDCERT GENCERT SUBJECTSDN(CN(’ITOperations’) O(’MyCo’) C(’US’))
WITHLABEL(’MyEKMServer’) PCICC(ITOPS.EKM.CERT) SIZE(2048)

Note: If you are not using ICSF, omit the PCICC keyword and change the key size to
1024.

2. To send this certificate, export it to a data set:
RACDCERT EXPORT (LABEL(’MyEKMServer’)) DSN(’hlq.PUBKEY.S2048.ITOPS’)
FORMAT(CERTDER)
3. Ensure that the EKM server certificate is connected to the EKM’s keyring. This example
shows connecting the certificate that identifies the EKM server to the EKM keyring. You
have to modify these command examples to suit your installation’s needs.
RACDCERT ID(EKMSERV) CONNECT(LABEL(’MyEKMServer’)RING(EKMRing))
4. If you use ICSF, ensure that the EKM server instance has RACF authority to the key label
of the private key that is stored in the ICSF PKDS. Also, be sure to refresh the in-storage
copies of the CSFKEYS class profiles using the commands shown in Example 8-24.

Example 8-24 Refresh storage copies of the CSFKEYS class profiles
RDEFINE CSFKEYS ITOPS.EKM.CERT UACC(NONE)
PERMIT ITOPS.EKM.CERT CLASS(CSFKEYS) ID(EKMSERV) ACCESS(READ)
SETROPTS RACLIST(CSFKEYS) GENERIC(CSFKEYS) REFRESH

5. Send the ExportedPublicKey.cer file to your business partner. You might possibly need to
tell the business partner the alias MyEKMServer if the business partner is not able to use an
encoding mechanism of Public Key Hash, explained in 8.4.4, “Importing a public key and a
certificate from a business partner” on page 303.

Certificate signed by an internal certificate authority
To generate a certificate signed by an internal certificate authority:
1. Generate a self-signed certificate authority certificate using the following command:
RACDCERT CERTAUTH GENCERT SUBJECTSDN(CN(’MyLocalzOSCA’)O(’MyCo’)C(’US’))
WITHLABEL(’LocalRACF CA’) PCICC(LOCAL.RACF.CERTAUTH) SIZE(2048)

1024.

2. The following RACDCERT command uses ICSF for private key storage, and it is signed
with the local certificate authority certificate generated in the previous step:
RACDCERT ID(EKMSERV) GENCERT SUBJECTSDN(CN(’ITOperations’) O(’MyCo’) C(’US’))
WITHLABEL(’MyEKMServer’) PCICC(ITOPS.EKM.CERT) SIZE(2048) SIGNWITH(CERTAUTH
LABEL(’LocalRACF CA’))

1024.


3. With your business partners or remote sites that you trust, you must validate a common
certificate authority (CA), whether third-party or self-signed, depending on your business
and security practices. To send this certificate, export it to a data set:
FORMAT(CERTDER)
4. Ensure that the EKM server certificate is connected to the EKM’s keyring. Example 8-25
shows connecting the certificate that identifies the EKM server to the EKM keyring. You
have to modify these command examples to suit your installation’s needs.

Example 8-25 Connecting the EKM server certificate the EKM keyring
ACDCERT ID(EKMSERV) CONNECT(CERTAUTH LABEL(’LocalRACF CA’) RING(EKMRing))

of the private key stored in the ICSF PKDS. Also, be sure to refresh the in-storage copies
of the CSFKEYS class profiles as shown in Example 8-24 on page 300.
6. Send the ExportedPublicKey.cer file to your business partner, and you might have to tell
the business partner the alias MyEKMServer if the business partner is not able to use an
encoding mechanism of Public Key Hash, which is explained in 8.4.4, “Importing a public
key and a certificate from a business partner” on page 303.

Certificate signed by a third-party certificate authority
To generate a certificate signed by a third-party certificate authority:
1. Generate an RSA key pair and certificate using the following RACDCERT command using
ICSF for private key storage:
RACDCERT ID(EKMSERV) GENCERT SUBJECTSDN(CN(’ITOperations’) O(’MyCo’) C(’US’))
WITHLABEL(’MyEKMServer’) PCICC(ITOPS.EKM.CERT) SIZE(2048)

1024.

2. Generate and save a certificate request to a data set (hlq.PUBKEY.REQUEST.ITOPS)
using the following command:
RACDCERT GENREQ (LABEL(‘MyEKMServer’)) DSN(‘hlq.PUBKEY.S2048.ITOPS’)
3. Submit a certificate request, hlq.PUBKEY.S2048.ITOPS, to your certificate provider. The
response that you receive is an X.509 certificate. This example assumes that the
certificate that you receive from your third-party certificate authority is saved in the data
set ‘hlq.THIRD.PARTY.CERT’ on z/OS. The contents of this data set are imported into
RACF.

Note: This data set contains only the signed certificate that identifies the EKM instance
running on z/OS and perhaps the certificate authority certificate. The private key for the
EKM certificate remains protected in the PKDS by either ICSF or RACF.

4. Receive the response into data set ‘hlq.THIRD.PARTY.CERT’ and add the certificate to
RACF using the following command:
RACDCERT ADD(’hlq.THIRD.PARTY.CERT’) TRUST WITHLABEL(’MyEKMServer’) ID(EKMSERV)
If the CA certificate is not contained in the data set ‘hlq.THIRD.PARTY.CERT’, you will need
to acquire the CA certificate that signed the EKM certificate from the External Certificate
Authority and add it to RACF as a CERTAUTH.


5. With your business partners or remote sites that you trust, you must validate a common
certificate authority (CA), whether third-party or self-signed, depending on your business
and security practices. To send this certificate, export it to a data set:
FORMAT(CERTDER)
6. Ensure that the EKM server certificate is connected to the EKM’s keyring. This example
shows connecting the certificate that identifies the EKM server to the EKM keyring.
RACDCERT ID(EKMSERV) CONNECT(CERTAUTH LABEL(’External CA label’) RING(EKMRing))
You need to modify these commands to suit your installation’s needs.
of the private key stored in the ICSF PKDS. Also, be sure to refresh the in-storage copies
of the CSFKEYS class profiles as shown in Example 8-24 on page 300.
8. Send the ExportedPublicKey.cer file to your business partner, and you might need to tell
the business partner the alias MyEKMServer if the business partner is not able to use an
encoding mechanism of Public Key Hash, which is explained in more detail in the
following section.

8.4.3 Exporting a symmetric key from a JCEKS keystore
If you want to send encrypted LTO4 media to a business partner, you will also have to send
the symmetric AES data keys that were used to encrypt the media. You may export a
symmetric key or a range of symmetric keys to a file using the keytool -exportseckey
command.

The keytool utility protects the symmetric keys using public key encryption. For your business
partner to be able to import the symmetric keys into the business partner’s keystore, you must
use one of the business partner’s public keys for encrypting the symmetric keys. Before
exporting the private keys, you have to make sure that your keystore contains at least one of
your business partner’s public keys. If this is not the case, request a public key/certificate
from your business partner and import it into your keystore as described in “Import to a
JCEKS keystore” on page 303. When the business partner receives the file with your
exported keys, the business partner can import them with the corresponding private key.

The reverse is also true. To have a business partner export symmetric keys that you can
import into your keystore, you must export a public key/certificate from one of your
public-private key pairs and send it to your business partner. After importing your certificate,
the business partner can export symmetric keys using your public key, and you may import
the encrypted symmetric keys into your keystore using the corresponding private key.

In Example 8-26, we export the symmetric key with the alias ekm00000000000000001 from the
keystore EKMKeys.jceks to a file named exportsym.key by using the public key contained in
the certificate with the alias partnercert.

Example 8-26 Exporting a symmetric key
keytool -exportseckey -alias ekm000000000000000001 -keyalias partnercert
-keystore EKMKeys.jceks -storepass passw0rd -storetype jceks
-exportfile exportsym.key


8.4.4 Importing a public key and a certificate from a business partner
We now look at examples of how to import the certificate and public key contained in
ExportedPublicKey.cer from a business partner to the EKM keystore with an alias
CompanyXPublicKey to various keystore types. In this example, the imported alias of
CompanyXPublicKey does not match the original business partner’s alias of MyEKMServer.
This only works if you plan to specify an encoding mechanism of Public Key Hash “H” for this
key as shown in the example following this import example. Otherwise, your business partner
must provide the alias on the import command.

Note: The alias that you specify on the import must match the alias that was used by the
business partner (MyEKMServer in the examples given in 8.4.2, “Exporting a public key and
certificate to a business partner” on page 298) if you plan to specify an encoding
mechanism of label “L” when encrypting tapes. Optionally, you can specify an encoding
mechanism of Public Key Hash “H” that uses a Hash value rather than the KeyLabel to
identify the key. Although Hash gives slightly less performance, it allows you to import a
certificate/public key from a business partner without knowing the alias/KeyLabel that the
business partner used to create and export the key. In addition, it gives you the freedom to
specify the label that you want to use to identify your business partner’s public key.
Therefore, using Public Key Hash is the preferred method.

Import to a JCEKS keystore
You can use the following commands to import the certificate and public key contained in
ExportedPublicKey.cer from a business partner to an JECKS keystore with an alias
CompanyXPublicKey from various keystore types using the keytool utility:
keytool -import -file ExportedPublicKey.cer -keystore EKMKeystore -alias
CompanyXPublicKey -storepass “somesecretphrase” -storetype JCEKS -provider IBMJCE
-keypass “somesecretphrase” List the contents of the keystore the certificate was
imported to: keytool -list -keystore EKMKeystore -storetype JCEKS -storepass
“somesecretphrase”

To list the contents of the keystore to which the certificate was imported, use the keytool
-list command:
keytool -list -keystore EKMKeystore -storetype JCEKS -storepass “somesecretphrase”

Import to a JCE4758KS keystore
You may use the following commands to import the certificate and public key from a business
partner contained in ExportedPublicKey.cer to an JCE4758KS keystore with an alias
CompanyXPublicKey from various keystore types using the hwkeytool utility:
hwkeytool -import -file ExportedPublicKey.cer -keystore EKMKeystore4758 -alias
CompanyXPublicKey -storepass “somesecretphrase” -storetype JCE4758KS -provider
IBMJCE -keypass “somesecretphrase”

You may list the contents of the keystore to which the certificate was imported by using the
hwkeytool list utility:
hwkeytool -list -keystore EKMKeystore -storetype JCE4758KS -storepass
“somesecretphrase”

Import from z/OS JCERACFKS or JCE4758RACFKS/JCECCARACFKS
To import into a z/OS RACF keystore, use RACDCERT to add the certificate to RACF. The
public key in the certificate can also be saved in the ICSF PKDS depending on the operands
supplied to the RACDCERT command.


The following RADCERT ADD command imports the certificate and public key from the
business partner contained in ‘dataset _containing_the_cert_received’ with an alias
CompanyXEKMServer. RACDCERT ID(EKMServ):
ADD(’dataset_containing_the_cert_received’) TRUST WITHLABEL(’CompanyXEKMServer’)
PCICC(companyX.EKMServ.cert) SIZE(2048)

Note that in this example the imported alias of CompanyXEKMServer does not match the
original business partner’s alias of MyEKMServer. This only works if you plan to specify an
encoding mechanism of Public Key Hash “H” for this key as shown in the example following
this import example. Otherwise, the alias on the import command has to be provided to you
by your business partner.

1024.

The WITHLABEL keyword associates a string or friendly name for the certificate that is being
imported, and this name is used by EKM when accessing the certificate. Refer to the z/OS
Security Server RACF Command Language Reference, GA22-7800, for details about the
RACDCERT command.

You also have to ensure that this certificate is connected (or associated) to the EKM server’s
keyring, which is accomplished using the RACDCERT command as shown in Example 8-27.
This example assumes that the EKM keyring on this z/OS system is EKMRing, and that the
z/OS user ID associated with the EKM process is EKMSERV.

Example 8-27 RACDCERT command to connect the certificate with the EKM server’s keyring
RACDCERT ID(EKMSERV) CONNECT(LABEL(’CompanyXEKMServer’) RING(EKMRing)
USAGE(CERTAUTH))
RACDCERT ID(EKMSERV) CONNECT(CERTAUTH LABEL(’GENERATED CA Label FROM ADD’)
RING(EKMRing))

Note: Because this certificate contains only a public key, using the USAGE(CERTAUTH)
option is extremely important. If it is not specified, EKM does not start, because it believes
that the certificate that was added must also contain a private key.

Ensure that the EKM server is authorized to read from its keyring and that the EKM server is
authorized to use the ICSF key label. Ensure that the required RACF FACILITY class profiles
are defined. If not, issue the RDEFINE commands as shown in Example 8-28 to define these
profiles, which protect the use of keyring functions.

Example 8-28 RACF authorizes the ICSF key labels
RDEFINE FACILITY IRR.DIGTCERT.LIST UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE)
PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ID(EKMSERV) ACC(READ)
PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ID(EKMSERV) ACC(READ)

If using ICSF, ensure that the EKM server instance has RACF authority to the key label of the
private key stored in the ICSF PKDS. Also, issue refresh for the in-storage copies of the
CSFKEYS class profiles using the commands shown in Example 8-29 on page 305.


Example 8-29 Ensure EKM server authority to the ICSF PKDS key labels
RDEFINE CSFKEYS REMOTE.EKM.CERT UACC(NONE)
PERMIT REMOTE.EKM.CERT CLASS(CSFKEYS) ID(EKMSERV) ACCESS(READ)
SETROPTS RACLIST(CSFKEYS) GENERIC(CSFKEYS) REFRESH

8.4.5 Tape exchange and verification
Refer to Example 8-30 on page 306.To validate tape exchange with your business partner:
At your local site, perform the following steps:
a. Create a key pair and export the public key to your business partner by using
techniques discussed in 8.4.2, “Exporting a public key and certificate to a business
partner” on page 298 as appropriate for your keystore type.

Note: This solution does not require that you and your business partner have the
same keystore type. Sharing public keys between different types of keystores is
possible, if you both use TS1120 drives.

b. Perform Read/Write to the tape. If your business partner used the Hash encoding
mechanism to encode your public key key-label on the tape, you can process it on any
system where the EKM has access to the public-private key pair for this label.
Otherwise, ensure that the business partner used the same alias that you did as
described in the note reference in the next step. If you are running z/OS, you can use,
for example, IEBDG DITTO, or IEBGENER.
Your business partner steps are:
a. Load the public key certificate to the system by importing it to your keystore using the
techniques discussed in the previous section, “Importing a public key and a certificate
from a business partner” on page 303, as appropriate for your keystore type.

Note: The alias you specify on import must match the alias that was used by the
business partner (MyEKMServer in the examples given in 8.4.2, “Exporting a public
key and certificate to a business partner” on page 298) if you plan to specify an
encoding mechanism of label “L” when encrypting tapes. Optionally, you may specify
an encoding mechanism of Public Key Hash “H” that uses a Hash value rather than
the KeyLabel to identify the key. Although Hash gives slightly less performance, it
allows you to import a certificate/public key from a business partner without knowing
the alias/KeyLabel that the business partner used to create and export the key. In
addition, it gives you the freedom to specify the label you want to use to identify your
business partner’s public key. Therefore, using Public Key Hash is the preferred
method.

b. Encrypt a tape to share with your business partner using two key labels. One of the
labels should be the public key that you imported in the earlier step from your business
partner. As just noted, if you do not use Hash to encode this key, you also have to let
your partner know the alias of this key. The other label you use must be an alias of a
public-private key pair that allows you to read the tape. EKM processing has a
safeguard built-in that requires that you must be able to read any tape that you encrypt.
If you attempt to write a tape with an alias that points to only a public key, the
processing fails. Because you do not have the private key associated with that
business partner key, you cannot read the tape yourself and you must provide a
second key where you have access to the private key in order for this processing to
complete successfully.


Example 8-30 Sample job to create a business partner-encrypted tape
//C02STRW1 JOB CONSOLE,
// MSGCLASS=H,MSGLEVEL=(1,1),CLASS=B,
// TIME=1440,REGION=2M
/*JOBPARM SYSAFF=*
//*
//* ENC KEY MASTER JOB
//*
//CREATE1 EXEC PGM=IEBDG
//SEQ001 DD DSN=TAPE.C02M5CX2.PC5.NOPOOL.C02STRS1.MASTER,
// KEYLABL1='MY_PUBLIC_PRIVATE_KEY',
// KEYENCD1=L,
// KEYLABL2='COMPANYXPUBLICKEY',
// KEYENCD2=H,
// LABEL=(1,SL),UNIT=C02M5CX2,DISP=(,CATLG),
// DCB=(DSORG=PS,RECFM=FB,LRECL=2048,BLKSIZE=6144)
//SYSIN DD *
DSD OUTPUT=(SEQ001)
FD NAME=A,STARTLOC=1,LENGTH=10,FORMAT=ZD,INDEX=1
FD NAME=B,STARTLOC=11,LENGTH=13,PICTURE=13,'PRIMER RECORD'
CREATE QUANTITY=25,FILL='Z',NAME=(A,B)
END
/*

Note: The z/OS Compatibility configuration property should be set to true for the
EKM you are using if you plan to exchange tapes between z/OS and non-z/OS
systems.

c. Send the tape to the business partner site that provided the public key for processing.

8.4.6 Importing symmetric keys to a JCEKS keystore
If a business partner wants to send you encrypted LTO4 media, you will need the symmetric
AES data keys that were used to encrypt the media in order to decrypt them. The business
partner can provide you with a file containing one or more symmetric keys. Import these keys
from the file into your keystore by using the keytool -importseckey command.

The symmetric keys in export files are protected by public key encryption. For you to be able
to import the symmetric keys to your keystore, your business partner must use one of your
public keys for encrypting the symmetric keys. If your business partner does not have one of
your public keys in the business partner’s keystore, the business partner must request a
public key/certificate from you and import it to the business partner’s keystore as described in
“Import to a JCEKS keystore” on page 303. When you receive the file with the exported
symmetric keys of your business partner, you can import them using the corresponding
private key for decryption.

The reverse is also true. In order to enable a business partner to import symmetric keys that
you exported from your keystore to a file, you have to use one of your business partner’s
public keys for export.


In Example 8-31, we import one or more symmetric keys from a file named importsym.key to
the keystore EKMKeys.jceks using a private key with the alias mycert.

Example 8-31 Importing a symmetric key
keytool -importseckey -keyalias mycert -keypass passw0rd -keystore EKMKeys.jceks
-storepass passw0rd -storetype jceks -importfile importsym.key

8.5 RACF export tool for z/OS
There are many ways to transport certificates within a company to ensure that all tapes are
encrypted with the same keys. Consider using the Java keytool as a means of obtaining an
X509V3 certificate for use by the Encryption Key Manager for z/OS deployment. The Java
keytool provides a means to cryptographically clone the certificate and private key through
the distribution of the PKCS12 (.p12) file to other z/OS instances. The PKCS12 file is
password-protected and contains the certificate, public and private key, and a CA certificate
that signed it.

In the PKCS12 password-protected file, the private key is stored with compliance to PKCS#8;
the password encryption is compliant with PKCS#5.

For more information about an exported PKCS12, refer to:
http://www.rsasecurity.com/rsalabs/node.asp?id=2124

This form of certificate exchange, where even the private key is stored in a file, can raise a
security concern that an individual knows the password used to encrypt the contents of the
PKCS12 file; therefore, the individual knows the private key that can then be used to decrypt
all tapes encrypted with that private key’s matching public key. In this situation, the security of
the business is based on the trust of the individual exporting and transporting PKCS12 files.

There might be a concern from an audit perspective; the accessibility of the private key in this
situation is only as secure as the person who knows the password used to protect the private
key.

A tool to satisfy these concerns is the KEYXFER tool, which:
Generates the private key using z/OS ICSF and hardware cryptography.
Stores the private key encrypted under the host Master Key in ICSF’s PKDS.
Reads the key record from ICSF (still remains encrypted under host Master Key) and
distributes to other z/OS systems.
Imports into remote z/OS systems in an encrypted form; import processing as suggested
can be done only if the same Master Key is used across the systems.
Associates the EKM certificate with the encrypted private keystore in z/OS ICSF PKDS.

Note: This method for exporting and transporting certificates is only valid on z/OS, and this
method is only valid if you are using a hardware-based RACF keystore on z/OS.

In this scenario, no passwords or similar means to externally gain knowledge of the private
key is ever available. The private key is moved from System A to System B in this scenario in
an encrypted form: it is enciphered by the host Master Key. Therefore, using a
password-based encryption scheme to protect the private key is not necessary. This scenario
depends on utilizing the same host Master Key on System A and System B.


Note: To successfully export an encrypted ICSF PKDS record entry and import into
another PKDS instance using the KEYXFER utility, the same ICSF hardware Master Key
must be used between the exporting and importing z/OS images.

8.6 Audit log considerations
The EKM can create audit records, which wrap the log to three files. After the last file is full,
the first file is rewritten.

On z/OS, you need to allocate file system space for the EKM audit logs, and if requested by
IBM Service, you need to enable the EKM debug log.

You may choose to allocate a file system specifically for use by the EKM for audit and debug
file storage. Assume 500 cylinders of space allocated to the EKM’s audit and debug log file
system until you have observed based on tape and EKM activity how quickly the audit logs
wrap. The file system must not be shared by the EKM instances running in a Sysplex
environment, but must be private to each EKM instance. This prevents any possible
interleaving of audit or debug logs between EKM instances.

Create the EKM configuration file in /&SYSNAME/etc and customize it accordingly for your
installation, as follows:
Audit.handler.file.directory
Modify this to a location where you want EKM to store the audit logs.
z/OS Compatibility
Use this option if you intend to exchange tapes between z/OS and non-z/OS systems.
If the EKM configuration file parameter requireHardwareProtectionForSymmetricKeys is
set to true, this value must be set to true also. This applies to all supported platforms.

8.6.1 Audit overview
The audit subsystem writes textual audit records to a set of sequential files as various
auditable events occur during EKM’s processing of requests. The audit subsystem writes to a
file (directory and file name are configurable). The file size of these files is also configurable.
As records are written to the file and the size of the file reaches the configurable size, then the
file is closed and renamed based on the current time stamp. Another file is opened and
records are written to the newly created file.

The overall log of audit records is thus separated into configurable-sized files, and their
names are sequenced by the time stamp when the size of the file exceeds the configurable
size. To keep the amount of information in the overall audit log (spanning all of the sequential
files created) from growing too large and exceeding the space available in the file system, a
script or program must be created which monitors the set of files in the configured audit
directory/folder/container. As files are closed and named based on the time stamp, the file’s
contents must be copied and appended to the chosen long-term, continuous log location and
then cleared. Be careful not to remove or alter the file that is having records written to it by
EKM while EKM is running (this file does not have a time stamp in the file name).


8.6.2 Audit log parsing tool
In Example 8-32, we introduce a Java application that takes an audit log file as input. The
program then parses the audit log for tape keylabel information and outputs it to the panel. If
this output is redirected to a file, it can then be read into a spreadsheet as a comma-delimited
format, and then you can work with it. This parsing tool is included here as a sample way that
you can keep track of tapes and the keylabels on the tapes.

To run this program, you must first compile it:
javac AuditCrawler.java

The javac command has to be in the $PATH; the javac command is located in
$JAVA_HOME/bin. After the source is compiled, an AuditCrawler.class file is created. To run
the program, execute the command:
java AuditCrawler auditlog

Examples in this section include:
Example 8-32 shows the application that takes an audit log file as input.
Example 8-33 on page 313 shows the format of the audit log records.
Example 8-34 on page 313 shows the output of the AuditCrawler program.

Example 8-32 AuditCrawler source tool

import java.io.BufferedReader;
import java.io.File;
import java.io.FileNotFoundException;
import java.io.FileReader;
import java.io.IOException;
import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;

/**
* @author svenjamin
* @revision johann
*
*/
public class AuditCrawler {

private static final String DRIVE_SER_NUM = "resource=[name= Drive Serial Number:";
private static final String WORLD_WIDE_NUM = "WWN:";
private static final String VOL_SER = "VolSer:";
private static final String KEY_ALIAS_LABEL = "Key Alias/Label[";
private static final String TYPE_FINAL = ";type=file]";
private static final int DRIVE_SER_NUM_LEN = 12;
private static final int WORLD_WIDE_NUM_LEN = 16;
private static final int VOL_SER_LEN = 6;

public static void main(String[] args) {
AuditCrawler m = new AuditCrawler();

File filename = m.validateInputFile(args[0]);
m.readInputFile(filename);

}

private void readInputFile(File filename) {
List driveList = new ArrayList();


List timestampList = new ArrayList();
String times = null;
try {

BufferedReader br = new BufferedReader(new FileReader(filename));

while (br.ready()) {
String s = br.readLine();
// Parse the timestamp and save it until we find
// an audit record with drive/labels
if (s.indexOf("timestamp") > 0) {
times = s;
}
// parse the entry with keylabel info
// add our timestamp to a list
// add the drive info to a list
if (s.indexOf("resource=[name= Drive Serial Number") > 0) {
timestampList.add(times);
driveList.add(s);
}

}
} catch (FileNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
System.out

.println("DriveSerialNumber,WorldWideNodeName,VolSer,Alias1,Alias2,Day,Mon,Date,time,Timezo
ne,Year");
if (!driveList.isEmpty()) {
Iterator it = driveList.iterator();
int i = 0;
while (it.hasNext()) {
String s = (String) it.next();
try {
//process our strings and print them
//add some space to line things up pretty
System.out.println(" "+processFoundLine(s)
+ processTimeStamp((String) timestampList.get(i)));
} catch (Exception e) {

}
i++;
}

}
}

// Check to see if audit file exists and we have read permission
private File validateInputFile(String filename) {
File f = new File(filename);
if (!f.exists()) {
String s = "File " + filename + " does not exist.";
System.err.println(s + " Bailing!");
throw new IllegalArgumentException(s);
}

if (!f.canRead()) {


String s = "Can't read the file " + filename;
System.err.println(s + " Bailing!");
throw new IllegalArgumentException(s);
}
return f;
}
//comma delimit the timestamp

private String processTimeStamp(String s) throws IllegalArgumentException {
String timeInfo = s.substring(12);
String[] splitString = timeInfo.split(" ");
StringBuffer output = new StringBuffer();
for (int i = 0; i < splitString.length; i++) {
output.append(",");
output.append(splitString[i]);

}
return output.toString();

}

private String processFoundLine(String s) throws IllegalArgumentException {
StringBuffer sb;// = new StringBuffer();
String str_driveSerialNumber = null;
int int_driveSerialNumberIndex = s.indexOf(DRIVE_SER_NUM);

String str_worldWideNumber = null;
int int_worldWideNumberIndex = s.indexOf(WORLD_WIDE_NUM);

String str_volSer = null;
int int_volSerIndex = s.indexOf(VOL_SER);
int int_keyLabelIndex = s.indexOf(KEY_ALIAS_LABEL);
int int_finalTypeIndex = s.indexOf(TYPE_FINAL);

// do the processing in reverse order to save cycles
// process the key labels
if ((int_keyLabelIndex > 0) && (int_finalTypeIndex > int_keyLabelIndex)) {
// now we can allocate the StringBuffer...
sb = new StringBuffer();

// get a new string for the key label stuff...
String keylabels = s.substring(int_keyLabelIndex,
int_finalTypeIndex + 1);
String firstCert = keylabels.substring(keylabels.indexOf(":") + 2,
keylabels.lastIndexOf(KEY_ALIAS_LABEL)).trim();
sb.append(firstCert);
sb.append(",");
String lastCert = keylabels
.substring(keylabels.lastIndexOf(":") + 2);
sb.append(lastCert);

} else {
throw new IllegalArgumentException("No Key Labels to process");
}

// Next we process the VOLSER and prepend it to our StringBuffer
if ((int_volSerIndex > 0) && (int_keyLabelIndex > int_volSerIndex)) {
str_volSer = s.substring(int_volSerIndex + VOL_SER.length() + 1,
int_keyLabelIndex - 1);


if (str_volSer.length() != VOL_SER_LEN) {
System.out.println("VolSer " + str_volSer
+ " is not appropriate!");
throw new IllegalArgumentException("VolSer "
+ ((str_volSer == null) ? "UNKNOWN" : str_volSer)
+ " is not the right length");

}
sb.insert(0, str_volSer + ",");

} else {
throw new IllegalArgumentException("Problem with VolSer processing");
}

// Next process the world wide number
if ((int_worldWideNumberIndex > 0)
&& (int_volSerIndex > int_worldWideNumberIndex)) {
str_worldWideNumber = s.substring(int_worldWideNumberIndex
+ WORLD_WIDE_NUM.length() + 1, int_volSerIndex - 1);
if (str_worldWideNumber.length() != WORLD_WIDE_NUM_LEN) {
System.out.println("WWN " + str_worldWideNumber
+ "is not appropriate!");
throw new IllegalArgumentException("WWN "
+ ((str_worldWideNumber == null) ? "UNKNOWN"
: str_worldWideNumber)
+ "is not the right length");

}
sb.insert(0, str_worldWideNumber + ",");

} else {
throw new IllegalArgumentException("Problem with WWN processing");
}

// Process the drive serial number
if ((int_driveSerialNumberIndex > 0)
&& (int_worldWideNumberIndex > int_driveSerialNumberIndex)) {

str_driveSerialNumber = s.substring(int_driveSerialNumberIndex
+ DRIVE_SER_NUM.length() + 1, int_worldWideNumberIndex - 1);

if (str_driveSerialNumber.length() != DRIVE_SER_NUM_LEN) {
System.out.println("Drive Serial Number "
+ str_driveSerialNumber + "is not appropriate!");
throw new IllegalArgumentException("Drive Serial Number "
+ ((str_driveSerialNumber == null) ? "UNKNOWN"
: str_driveSerialNumber)
+ "is not the right length");
}
sb.insert(0, str_driveSerialNumber + ",");

} else {
throw new IllegalArgumentException(
"Problem with Drive Serial Number processing");
}
//remove the last comma
//processTimeStamp will prepend to its
//date information
sb.deleteCharAt(sb.length() - 1);
return sb.toString();


}

}

In Example 8-33, we see the format of the audit log records. This is what is read by the
AuditCrawler program and then subsequently parsed into an organized comma-delimited list

Example 8-33 Sample audit log
Runtime event:[
timestamp=Thu Sep 28 09:05:19 EDT 2006
event source=com.ibm.keymanager.c.eb
outcome=[result=successful]
event type=SECURITY_RUNTIME
resource=[name=Process Message;type=file]
action=stop
]
Runtime event:[

event source=com.ibm.keymanager.c.eb
resource=[name=Process Message;type=file]
action=stop
]
Runtime event:[
timestamp=Thu Sep 28 09:05:19 EDT 2006
event source=com.ibm.keymanager.c.fb
resource=[name= Drive Serial Number: YN1B00001388 WWN: 5005076300020216 VolSer:
451AAF Key Alias/Label[0]: cert1 Key Alias/Label[1]: cert2;type=file]
action=stop
]

In Example 8-34, we see the output from the AuditCrawler program. The first line is an
explanation of the fields. The subsequent lines are the parsed and formatted records. Only
records that have the information containing drive key label information are printed here.

Example 8-34 Sample output
DriveSerialNumber,WorldWideNodeName,VolSer,Alias1,Alias2,Day,Mon,Date,time,Timezone,Year
YN1B00001436,5005076300020215,444AAF,cert1,cert2,Tue,Aug,22,11:23:30,EDT,2006

Note: By following the JZOS example in “EKM and JZOS” on page 567, you can set this
up to run as a job that is scheduled to run when a new audit log has been created.


Part 3

Part 3 Implementing and
operating the TKLM
In this part, we provide the information required to plan for, implement, and operate the Tivoli
Key Lifecycle Manager (TKLM). We also describe planning considerations for keystores and
key management.


9

Chapter 9. Planning for TKLM and its
keystores
This chapter, we discuss the planning or the Tivoli Key Lifecycle Manager (TKLM). TKLM or
Encryption Key Manager (EKM) must be implemented before you can encrypt any tape using
System-Managed Encryption (SME) or Library-Managed Encryption (LME). Application-
Managed Encryption (AME) does not require a TKLM or EKM implementation. This planning
can occur even before your hardware arrives.

Chapter 10, “Implementing TKLM” on page 325 completely describes the implementation of
TKLM.

TKLM provides life cycle management for keys and certificates of an enterprise. It may be
used as a key store for encryption capable IBM storage such as the TS1120, TS1130, and
IBM LTO4 tape drive.

You must decide on what platform (or platforms) the TKLM will run. We suggest that you
implement TKLM only on a single operating system type to allow TKLM synchronization
between primary and secondary TKLM instances.

In this chapter, we first provide a TKLM planning quick reference, then we describe the
requirements for each of the platforms where TKLM can run. Then we discuss various TKLM
and keystore implementation considerations.


9.1 TKLM planning quick-reference
Table 9-1 compares the encryption characteristics of the TS1120 drive to the TS1130 and
LTO4 drive. Table 9-1 compares the Tivoli Key Lifecycle Manager (TKLM) software
prerequisites for each platform. On Open Systems platforms, the TS1120, TS1130 and the
LTO4 are almost identical as to which encryption methods they support and the operating
system software requirements. These requirements were extracted from Tivoli Key Lifecycle
Manager Installation and Configuration Guide SC23-9977.

Description TS1120 tape drive TS1130 tape drive LTO4 tape drive

Encryption standard AES (256-bit) AES (256-bit) AES (256-bit)

Encryption process for Symmetric AES (256) Symmetric AES (256) Symmetric AES (256)
data

Encryption key model Wrapped key Wrapped key Direct key

Encryption type for Public-private key Public-private key None
data keys (Asymmetric) (Asymmetric)

Data keys used Unique data key for Unique data key for Keylist: A list or range
each cartridge each cartridge of data keys used,
pregenerated in
keystore

Data keys stored? Wrapped (that is, Wrapped (that is, Stored in keystore
encrypted) data keys encrypted) data keys
(2) stored on cartridge, (2) stored on cartridge,
called EEDKs called EEDKs

Keystore Contains private keys Contains private keys Contains data keys
and certificates and certificates that have been
representing public representing public pregenerated
keys. keys.
Preloaded in keystore Preloaded in keystore

Keystore types JCEKS (All platforms) JCEKS (All platforms) JCEKS (All platforms)
supported by TKLM


Table 9-2 lists the current platforms on which TKLM may be installed.

Table 9-2 TKLM Software Platforms
Description Patch, maintenance level at
time of initial publication

AIX Version 5.3 64-bit, and Version 6.1 For Version 5.3, use Technology Level 5300-04
and Service Pack 5300-0402

Sun Server Solaris 10 (SPARC 64-bit) None
Note: TKLM runs in a 32-bit JVM.

Windows Server 2003 R2 (32-bit Intel) None

Red Hat Enterprise Linux AS Version 4.0 on compat-libstdc++-33-3.2.3-47.3 package. run
x86 32-bit rpm -qa | grep -i "libstdc" to verify it is present.

SUSE Linux Enterprise Server Version 9 and 10 compat-libstdc++-33-3.2.3-47.3 package. run
on x86 (32-bit) rpm -qa | grep -i "libstdc" to verify it is present.

Table 9-3 lists the hardware configuration for running TKLM.

Table 9-3 TKLM Hardware Re om mended Requirements
System components Recommended Value

System memory (RAM) 4 GB

Processor speed Linux/Windows 3.0 GHz dual processor
AIX and Sun Solaris: 1.5 GHz (4-way)

Free disk space 20 GB

Disk space free in /tmp or C:temp 500 MB

Disk space free in /opt 3.5 GB

Disk space free in /home directory for DB2 Database 1.5 GB

Access requirements
To install TKLM you must have different access levels by platform. Windows requires a user
with Administrator access. Linux, Solaris and AIX require root access.

Browser support
The TKLM server is accessed using a Web browser, Firefox 2.0.0.14, or Internet Explorer®
6.0.x SP1, or Internet Explorer 7.0. Note that AIX has no supported browser; the TKLM
interface must be accessed across the network using one of the supported browsers. With
TKLM 1.0, Firefox 3.0.3 did not render all pages correctly, although Firefox 2.0.0.17 did.
Therefore, use the supported browser’s major version numbers.

Chapter 9. Planning for TKLM and its keystores 319

9.2 TKLM and keystore considerations
We begin with questions for you to consider:
On what platforms will you run TKLMs?
The Tivoli Key Lifecycle Manager is currently supported on:
– AIX 5.3 Technology Level 5300-04 and Service Pack 5300-04-02
– AIX 6.1
– Sun Server Solaris 10 (SPARC 64 bit)
– Windows Server 2003 R2 (32 bit)
– Red Hat Enterprise Linux AS Version 4.0 on x86 32–bit
– SUSE Linux Enterprise Server Versions 9 and 10 on x86 (32–bit)
You might want to run the TKLM on more than one of these platforms. We do not
recommend running TKLM on different OS Platforms. With the TKLM 1.0 release as the
backup and restore mechanism used to create redundant TKLM’s requires the same
platform and configuration. In all cases, you want TKLM to be running on a highly
available platform that will be available anytime you need access to the drives. If you have
a disaster recovery site, you should also have a TKLM at this site or a way to rapidly
deploy one with the current keystore and configuration.
What keystore deployment model will you employ? At the time of this writing JCEKS
(file-based) is the only supported key store. Refer to Table 9-4.

Table 9-4 Comparison of supported keystores
Keystore Platforms TS1120, TS1130 LTO4 (stores TS1120, Symmetric
type supported (stores keypairs symmetric TS1130, key tools
and certificates) keys) LTO4 available

JCEKS ALL Yes Yes Yes keytool

Do you want to use secure hardware cryptographic services?
This consideration is driven by the regulations and requirements your business is required
to meet. If you require a hardware solution at this time, use EKM.
Is your TKLM behind a firewall?
As part of your centralized key management strategy, the TKLM that your platform has to
access might be behind a firewall. If so you should work with your company firewall to
determine appropriate rules. TCP/IP port 3801 is the default TKLM port. When using SSL
TCP port 441, note that this is different from tape libraries that usually default to port 443.

9.2.1 TKLM configuration planning checklist
Make sure you:
Have selected a support OS and hardware platform. Note that the machine name cannot
start with the following text:
– IBM
– SQL
If you are migrating an existing EKM server, verify that the server meets the TKLM server
recommendations:
– Back up your EKM configuration prior to migration.
– Write down the path to the EKM; this path name should not contain any spaces.


– Schedule an outage for your EKM server. Note that if you have redundant EKMs, you
do not have to stop all EKMs, but you do have to stop the EKM that is being migrated
to TKLM. After you have the first EKM migrated to TKLM, we suggest using the TKLM
backup/restore function to configure the remaining EKMs.
– Migration types that are not supported:
• Administrator SSL keystores or truststores
• PKCS11Impl keystores and truststores
If this is a new TKLM installation:
– Know the recipients for the tapes to be written and read. For each recipient:
• An associated X.509 certificate must exist when using TS1120 or TS1130
• A key or range of keys must be pregenerated within the keystore when using LTO4
– Identify the tape drives that will be used.
For each tape drive, determine the drive serial number for input into the TKLM drive
table. You may also configure TKLM to accept unknown drives.
– Have existing keys and certificates that you plan to use.

Note: For TKLM servers that typically handle requests from the same set of tape drives,
the information in the associated keystores must be kept the same.

This consistency is required so that no matter which TKLM server is contacted, the
necessary information is available for the TKLM server to use to support the requests that
the TKLM server receives from the tape drives.

9.2.2 Best security practices for working with keys and certificates
Best practices are:
Do not lose your keys and certificates!
No really, do not lose your keys and certificates.
Do not leave your keys and certificates for other users to see.
For example putting them on another user’s general purpose mobile computer or USB key
is a bad idea.
Make sure you back up your keys and certificates and verify you can retrieve them from
the backup.

Important: Although IBM has services that can help you to recover data from a damaged
tape, if the damaged tape is encrypted, what you receive from the recovery will still be
encrypted data. So, if you lose your keys, you have lost your data.

9.2.3 Acting on the advice
Maintenance, backup, and restoration of key and certificate information can be accomplished
using the TKLM GUI interface or CLI wsadmin. See 11.4, “TKLM backup and restore
procedures” on page 361 for more information about how to backup TKLM.


9.2.4 Multiple TKLMs for redundancy
To run a replica server, at this time, TLKM requires that both systems be running the same
OS, middleware, file system layout, and others. TKLM is not cluster-aware and not enabled
for automatic failover. Manual failover is possible. Synchronization is achieved by backing up
one server and restoring the backup configuration on the other server. You should plan to do
this backup and restore process when the following events take place:
Initial configuration
Adding keys or devices
Key or certificate replacement intervals
Certificate Authority (CA) requests
Upgrades to TKLM or middleware, such as DB2

9.3 Other TKLM considerations
In this section, we summarize additional TKLM considerations.

9.3.1 Database selection
TKLM includes DB2 in the installation process:
If you already have IBM DB2 9, TKLM uses your existing DB2 installation.
If DB2 9 is less than DB2 9.1 fix pack 4, TKLM installer upgrades your DB2 installation.
If you have a prior version of DB2 or do not have DB2 on the target machine, TKLM
installs DB2 9.1 fix pack 4.

The TKLM backup/restore function backs up the TKLM relevant tables.

9.3.2 EKM to TKLM migration
TKLM supports migration from an EKM installation to a TKLM installation, which requires
stopping the EKM server. You can either schedule a maintenance window to shut down the
EKM or, if you have redundant EKMs, you can stage this migration. The TKLM Installation
and planning guide has an excellent discussion on EKM migration. It can be found in either:
Tivoli Key Lifecycle Manager Installation and Configuration Guide SC23-9977
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.t
klm.doc/install/cpt/cpt_ic_plan_migration.html

The following list is a quick review of what to be aware of when migrating from EKM to TKLM:
Back up your EKM configuration prior to migration.
Write down the path to the EKM; this path name should not contain any spaces.
Schedule an outage for your EKM server. Note that if you have redundant EKMs, you do
not have to stop all EKMs, but you do have to stop the EKM that is being migrated to
TKLM. After you have the first EKM migrated to TKLM, we suggest using the TKLM
backup and restore function to configure the remaining EKMs.
Migration types that are not supported:
– Administrator SSL keystores or truststores
– PKCS11Impl keystores and truststores


9.3.3 Data exchange with business partners or different platforms
TKLM 1.0 does not currently support key group exchange between EKM and TKLM. If you
are exchanging LTO4 cartridges with a business partner running EKM, you have to maintain
an EKM instance or coordinate a migration to TKLM.

9.3.4 Disaster recovery considerations
Your disaster recovery site must have an operational Key Manager that has recently been
synchronized with the primary site. Or, at a minimum a recent backup of the Key Manager
based on the criteria used in Section along with your TKLM configuration worksheets and
install media. The TKLM worksheets can be found in either:
Tivoli Key Lifecycle Manager Installation and Configuration Guide SC23-9977t
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.t
klm.doc/welcome.htm


10

Chapter 10. Implementing TKLM
This chapter is intended as an example to show how the TKLM is installed on a Red Hat
Enterprise Advanced Server 2 system. TKLM is supported on other systems, described in
Chapter 9, “Planning for TKLM and its keystores” on page 317. A full installation guide for
those systems can be downloaded from:
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.tk
lm.doc/cpt/cpt_ic_releas_probsinstallupg.html

We include instructions for both setting up TKLM to serve keys to TS1100 drives through the
use of asymmetric keys, and also to LTO4 drives through the use of symmetric keys. The
TKLM interface is common across platforms; after TKLM is installed on a system, the
keystore setup is quite similar to other TKLM implementations.


10.1 Implementation notes
The Server operating system for this implementation is Red Hat Enterprise Linux Advanced
Server 2. We used the GUI installation method, which provides several wizards to ease the
implementation.

10.2 Installing TKLM
The TKLM must be installed as root. After downloading the tklminstall_linux.tar.gz file,
extract it to /root/tklm. From there, start the installation script.

To install TKLM as root:
1. Extract the TKLM tar file:
tar -zxpvf tklminstall_linux.tar.gz
From there, several folders are created.
2. Run the following command from /root/tklm to start the GUI installation:
./install.sh
Figure 10-1 shows starting the install script.

Figure 10-1 Starting the install script


3. Select the language you want to install, as in Figure 10-2, and click OK.

Figure 10-2 Language selection

4. Figure 10-3 shows the TKLM manager starting.

Figure 10-3 Installation starting

The Installation GUI opens, as shown in Figure 10-4 on page 328.

Chapter 10. Implementing TKLM 327

Figure 10-4 Installation GUI

5. Click Next.
6. If you agree with the terms of the license, accept them and click Next. See Figure 10-5 on
page 329.


Figure 10-5 License terms

7. The system on which we are installing TKLM is a clean RHEL AS 2 installation with
nothing else on it. In our lab, we accepted the defaults. Choose the DB2 destination, or
take the default, and click Next.


8. In the next panel, shown in Figure 10-6, accept all of the defaults; enter password for all
of the passwords and click Next.

Figure 10-6 Creating the DB2 Administrative user (part 1)


9. In the next panel, shown in Figure 10-7, enter the root group, and click Next.

Figure 10-7 Creating the DB2 Administrative user (part 2)


10.In the summary window (shown in Figure 10-8), review the prerequisites.

Figure 10-8 Creating the DB2 Administrative user, Summary of prerequisites

11.Click Next to accept them and start the DB2 installation.


As shown in Figure 10-9, the DB2 portion of the installation is completed. The TKLM and
Tivoli Itegrated Portal (TIP) installation will begin.

Figure 10-9 DB2 Installation complete


12.As shown in Figure 10-10, choose a directory in which to install the TIP, and click Next.

Figure 10-10 Select TIP installation directory


13.Enter a password, as shown in Figure 10-11, and click Next.

Figure 10-11 Define User ID and Password


14.In the next panel, shown in Figure 10-12, you can begin to migrate an existing EKM
implementation. We do not have an EKM on this server, so we will click Next.

Figure 10-12 EKM Migration


15.The next panel, shown in Figure 10-13, confirms all selections we have made, similar to
the DB2 installation. Review the summary.
If you want to make changes, go back now and make them, otherwise, click Install.

Figure 10-13 Summary of selections

Now that the TKLM is installed, we can configure it.

10.3 Configuring TKLM
Now that TKLM is up and running, we can create a keystore.

To configure TKLM:
1. Open a browser and point it at TKLM. Typically TKLM is at the localhost and localdomain:
https://localhost.localdoman:16316/ibm/console
A production TKLM most likely is at a different IP or a different URL. The default TKLM
installation secures the HTTPS transport with a self-signed certificate. depending on the
browser you use, you might get an exception. If that is the case, accept the certificate as a
trusted certificate.
The TIP login window opens as shown in Figure 10-14 on page 338.


Figure 10-14 Tivoli Integrated Portal

2. Log in to the Tivoli Integrated Portal as user TKLMAdmin and the password that was
configured during installation. The Welcome window opens, as shown in Figure 10-15.

Figure 10-15 The Welcome window

3. Click create the master keystore.
The window shown in Figure 10-16 on page 339 opens.


Figure 10-16 Enter keystore information

4. Keystore type is JCEKS. Enter (or browse to) tklmKeys.jck as the keystore path and file
name. JCEKS is the software keystore that supports both asymmetric and symmetric
keys. Click OK.
5. In the next window, as shown in Figure 10-17, the wizard indicates the Next Steps. Click
Configure the product to use specific communication protocol(s).

Figure 10-17 Select the next steps

6. In the next window, as shown in Figure 10-18 on page 340, select Create self-signed
certificate.


If using a third-party, a signed certificate is a requirement that is also supported. We could
use an existing certificate from the keystore, but using a certificate for encrypting tape
data to also protect the communication protocol is not good practice. Choose a descriptive
label and a certificate expiration that follows security guidelines. Optional certificate
parameters can also be entered.

Figure 10-18 Create self-signed certificate

7. Click OK. The next window opens, as shown in Figure 10-19 on page 341.


Figure 10-19 Update successful

Our SSL certificate creation was successful.
8. Click Return home.
9. In this implementation example we are creating both LTO4 keys and TS1100 keys.
Select LTO from the menu, as shown in Figure 10-20, and click Go.

Figure 10-20 Creating keys

10.In the next window, click Create (as indicated in Figure 10-21 on page 342) to create a key
group.


Figure 10-21 Key groups

11.In the next window, Figure 10-22, enter the key group name, the number of keys and a
three-letter prefix. Then, click Create Key Group.

Figure 10-22 Create key groups

12.At the warning message, shown in Figure 10-23 on page 343, click OK.


Figure 10-23 Warning message

13.In the next window, Figure 10-24, you can specify the drives from which TKLM will accept
requests. Or, to populate TKLM, you can allow TKLM to accept requests from all drives.
The best practice is to allow TKLM to accept requests from all drives until TKLM is aware
of all the drives and then turn on security to prevent any new requests from unknown
drives. At a business continuity site, a best practice is to accept all drives to facilitate a
speedy recovery. Click Return home.

Figure 10-24 Identifying drives


14.Add keys to serve the 3592 drives by selecting 3592, as shown in Figure 10-25. Click Go.

Figure 10-25 Key administration

15.In the next window, shown in Figure 10-26, click Create.

Figure 10-26 identifying drives


16.In Figure 10-27, we create a self-signed certificate. The alias name for our certificate is
tekm.11252009 and it has an expiration of 365 days. The alias name is chosen to be
useful and descriptive.A common key naming convention is to use the expiration of the
certificate in the label, to show immediately when a certificate will expire, and allow the
reuse of the descriptive portion of the alias name. A good practice is have certificates
expire at least once a year, hence the 365-day expiration on our certificates.

Figure 10-27 Certificate creation

17.Click Create Certificate.


18.At the next warning message (see Figure 10-28), click OK.

Figure 10-28 Warning message

In the next window, Figure 10-29, the TKLM can now serve keys to both LTO and TS1100
drives.

Figure 10-29 serving keys


10.4 Conclusions
The TKLM installation and implementation are significantly easier than setting up an EKM.
The TIP GUI gives the user a uniform interface for managing keys, certificates, and tape
drives across platforms. From here, a production architecture would have to take into account
how to keep keys synchronized between TKLMs, in addition to aggregating log information to
keep an audit trail of what tapes were encrypted with what keys and when that happened.
The following chapters cover the TKLM functions that enable a user to do this.


11

Chapter 11. TKLM operational considerations
This chapter discusses TKLM operational considerations, including the following topics:
Scripting
Synchronizing primary TKLM configuration data.
Maintenance, including adding and removing drives
Backup procedures
Removing Web browser certificate warnings

We also include mixed-mode data-sharing examples in which we describe the steps required
to share encrypted tapes with a business partner running TKLM or EKM.


11.1 Scripting with TKLM
As with any complex piece of software, routine tasks must be accomplished. By using a GUI,
the tasks can be automated and you gain more reliability and predictability. In this section we
provide an overview of the scripting interface. This is not intended to replace the TKLM
command line reference but to provide several supplemental examples. The scripting
interface to TKLM is Jython, a full implementation of Python integrated with the Java platform.
For more information about Jython, visit:
http://www.jython.org/Project/

The reference section of the TKLM Information Center contains a complete command line
reference, located at:
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.tklm.doc/ref/
ref_ic_cli.html

We found that the most useful way of interacting with the command line was to write a Python
script and then invoke it from the command line or a launcher.

11.1.1 Simple Linux backup script example
Note that this script is an example and requires some enhancement to be used in production.
For instance, including the password in the script is not a good idea.

Example 11-1 invokes the EKLM script on Linux. Example 11-2 shows the contents of
takeBackup.py, which takes a backup of the currently running TKLM. Example 11-3 shows
the output.

Example 11-1 TKLM Script invocation on linux
/opt/IBM/tivoli/tip/bin/wsadmin.sh -username TKLMAdmin -password password -lang
jython -f takeBackup.py

Example 11-2 The takeBackup.py contents
print "Take a Backup of the currently Running TKLM"
print AdminTask.tklmBackupRun('[-backupDirectory /root/TKLMBackup -password
myBackupPwd]')
print "A backup was placed in /root/TKLMBackup with the password myBackupPwd"

Example 11-3 Output of Example 11-2
WASX7209I: Connected to process "server1" on node TIPNode using SOAP connector;
The type of process is: UnManagedProcess
Take a Backup of the currently Running TKLM
(0) Backup operation succeeded.
===============================

A backup was placed in /root/TKLMBackup with the password myBackupPwd
[root@dyn9011169152 ~]# cd TKLMBackup/
[root@dyn9011169152 TKLMBackup]# dir
tklm_v1.0_20081114153628MST_backup.jar
[root@dyn9011169152 TKLMBackup]#


You can see from Example 11-3 on page 350 that the script in Example 11-2 on page 350
first prints out sample text (nothing complicated here). Then, the script invokes tklmBackupRun
to place the backup in /root/TKLMBackup with the password myBackupPwd, and then prints
more descriptive text. The backup operation can easily be added to any script that takes
action against the TKLM to capture a before and after snapshot. Enhancing this script could
also be used to automate synchronizing TKLM servers by setting up a cron job or windows
task scheduler to take a backup, copy it to the secondary TKLM and restore the backup.

11.2 Synchronizing primary TKLM configuration data.
For each keystore, you should define one TKLM as the primary. This primary keystore is the
one on which to make changes. Changes are then replicated on the secondary TKLM
servers. When selecting the TKLM servers, at a minimum they must be running the same OS
and the secondary TKLM must have available the same amount or more free disk space.
Matching the two servers as closely as possible is desirable. You should then install TKLM
using the same DB2 and TIP settings so that a backup from the primary TKLM can be
restored on the secondary TKLM server.

11.2.1 Setting up primary and secondary TKLM servers
For this example we are running two Windows 2003 hosts running under VMware® ESX.
This allowed us to easily match the environment seen by TKLM and its middleware. For the
purposes of this example we chose not to clone the VMware image, but instead we
performed default installations using the same configuration and passwords for DB2, TKLM,
and the keystores. To ensure the installations were the same, we recorded the primary TKLM
installation to a response file; because, the response file it created was incomplete and did
not allow the installer on the secondary machine to run, we instead used the graphical
installer and kept defaults the same as with the first machine.

Note: TKLM does not tolerate spaces in the installation directory name. You cannot install
to c:Program Files or to any other directory that contains a space. The graphical installer
defaults to c:ibm which works fine.

A good practice is to fill out the installation worksheets found in the Tivoli Key Lifecycle
Manager Installation and Configuration Guide, SC23-9977.

Note: The TKLM installer does not always set up the required services to start
automatically so be sure to test your TKLM installation after you have enabled the services
and restarted the server. For more information, refer to 9.3.2, “EKM to TKLM migration” on
page 322.

You may also obtain the product documentation from the IBM Tivoli Key Lifecycle Manager
Information Center available at:
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.tklm.doc/w
elcome.htm

Administration information is presented in HTML. The following guides are also provided in
PDF files:
IBM Tivoli Key Lifecycle Manager Quick Start Guide
IBM Tivoli Key Lifecycle Manager Installation and Configuration Guide

Chapter 11. TKLM operational considerations 351

11.2.2 Synchronizing the primary and secondary TKLM servers
TKLM 1.0 does not automatically synchronize between servers but it does provide a
convenient backup and restore operation that can be performed using the command line or
Web user interface. Synchronization involves backing up a TKLM and then restoring to a
different server with the same configuration parameters. Consider the following notes:
Select one machine to be the primary, and originate all backups from the primary. All
changes should be made on the primary and then deployed through a backup or restore to
the secondary TKLM.
Primary and secondary TKLMs must be running the same OS with the same user
accounts for TKLM, TIP, and DB2.
Restores are disruptive to the secondary TKLM, so ensure that the primary is active and
serving key’s before performing the restore.

See section 11.4, “TKLM backup and restore procedures” on page 361

11.3 TKLM maintenance
TKLM is intended to help automate some of the drudgery around key management. This
does not mean that you can setup TKLM once and then forget about it. As drives enter and
leave the environment, TKLM has to be updated. Although you can schedule key rollover and
pregenerate the keys, do not do this too far in advance otherwise you risk compromised
future keys in addition to current keys.

This section provides information about:
TKLM drive management using the GUI and CLI
LTO key group rollover
3592 certificate rollover
User management

11.3.1 Adding and removing drives
TKLM tracks which drives it knows about and allows you to group them depending on your
requirements. You may configure TKLM to add any drive that requests a key or to only allow
known drives to obtain keys. As with EKM, allowing any drive that requests a key to be
automatically added, initially to populate the list, and then disabling the adding of new drives
manually is a good compromise between security and simplicity. To allow any drive to be
added, check the Accept requests from all IBM drives check box. See Figure 11-1.

Figure 11-1 Accept requests form all IBM drives

When adding drives to TKLM, you have to know three key pieces of information: drive serial
number, World Wide Node Name (WWNN), and the key group or certificates you would like
associated with it. You can obtain this information in several ways, depending on the tape
library or host software attached to the drive. One convenient way, with the TS3500, is to
download the drive CSV log. You obtain the log by using the TS3500 Web interface. Select
Drives  Drive Summary, and then select name of the Drive Statistics(.csv). You may also


download the file http://<library ip>/FS/LIBLG_01_DS.csv (Note that the drive serial
number and drive WWNN have a leading underscore character (_) character that has to be
removed. Because TKLM supports saving only 4 bytes of the WWNN, select the last 4 bytes.

Using the GUI

Note: Depending on the system, the GUI can take awhile to initially load. Wait for it. If you
start getting unusual-looking pages, you probably started clicking links before the GUI
finished loading. If that happens, log out, log in again, and then wait for the page to finish
loading.

The GUI is simple but slower. Simply log in and go to Tivoli Key Lifecycle Manager  Key
Administration  LTO, or Tivoli Key Lifecycle Manager  Key Administration  3592.
From the Add menu, select Drive. Refer to Figure 11-2. A new window opens.

Figure 11-2 Add a tape drive using the GUI

Using the command line to add drives
For more information about the TKLM command line interface see the information center:
ref_ic_cli.html


Starting the Windows command line
From the TIP_HOME directory (usually c:IBMtivolitipbin), run the command:
wsadmin -username TKLMAdmin -password password -lang jython

Starting the AIX, Solaris, RHEL, or SLES command line
From the TIP_HOME directory (usually /opt/IBM/tivoli/tip/bin), run the command:
./wsadmin.sh -username TKLMAdmin -password password -lang jython

Adding drives using the Jython command line
To add a drive, you have to know its serial number and type LTO or 3592. You can then add
a drive or more likely a set of drives. Example 11-4 starts the command line and adds a set of
drives to the default key group. In the example, the addDrive.sh script starts the command
line and tells it to run the addDrive.py script. Which then adds two LTO and one 3529 drives.

Example 11-4 Start command line and run Jython script to add 3 drives to TKLM
[root@dyn9011169152 ~]# cat addDrive.sh
jython -f addDrive.py
[root@dyn9011169152 ~]# cat addDrive.py
print "Add a LTO Drive with the serial number 000012345670"
print AdminTask.tklmDeviceAdd('[-type LTO -serialNumber 000012345670 -attributes
"{worldwideName abcd0100} {description TS3500Frame2Drive1}"]')
print "Add a LTO Drive with the serial number 000012345671"
print AdminTask.tklmDeviceAdd('[-type LTO -serialNumber 000012345671 -attributes
print "Add a 3592 Drive with the serial number 000012345672"
print AdminTask.tklmDeviceAdd('[-type 3592 -serialNumber 000012345672 -attributes

print "List out all the drives in the TKLM"
print AdminTask.tklmDeviceList()

[root@dyn9011169152 ~]#

The output is shown in Example 11-5 on page 355.

You may also automate adding the drives to a specific key group using the aliasOne and
aliasTwo attributes for 3592 drives or the symAlias attribute for LTO drives. Note that
because the attributes are already quoted, using descriptions or aliases with spaces might be
difficult.


Example 11-5 Sample run of script in Example 11-4 on page 354
[root@dyn9011169152 ~]# ./addDrive.sh
Add a LTO Drive with the serial number 000012345670
CTGKM0001I Command succeeded.
Add a LTO Drive with the serial number 000012345671
Add a 3592 Drive with the serial number 000012345672
List out all the drives in the TKLM

Description = salesDivisionDrive
Serial Number = 000012345678
Device uuid = DEVICE-0012d3cf-89d5-412b-8a19-1897e7ce1146
Device type = LTO
World wide name = abcd1234

Description = TS3500
Device uuid = DEVICE-0a6aa209-b58a-482f-8e0d-dc128b129988
Device type = LTO
World wide name = 0bcd1234

Description = TS3500Frame2Drive1
Device uuid = DEVICE-65cae709-3132-4aaf-831e-6a32b15d0477
Device type = LTO

Device uuid = DEVICE-11719c55-37ba-4a1d-997e-dba59387c17a
Device type = LTO

Device uuid = DEVICE-ee7a0ce9-aaf3-4e79-a059-395f7f98ecac
Device type = 3592

[root@dyn9011169152 ~]#

11.3.2 Scheduling key group rollover
One of the advantages of TKLM is that you can schedule it to change key groups at a
predetermined time without human intervention. Because keys and key groups do not expire
like certificates, you do not have to worry about keys expiring. However, you should still
adhere to the key usage time guidelines set by your organization.

Note: With TKLM 1.0, you can only schedule key group rollover for the default key group.


To create a key group, go to Tivoli Key Lifecycle Manager  LTO, and select Add. The
panel in Figure 11-3 opens. Fill out the key data according to your requirements.

Figure 11-3 Creating a key group

After creating the new key group, you may schedule when it should become the new default
key by selecting the calendar icon as shown in Figure 11-4.

Figure 11-4 Scheduling a key group rollover


A future default panel opens, as shown in Figure 11-5.

Figure 11-5 Setting the key group rollover

After you set the key group you want to change to, and the date on which you want TKLM to
make the change, the key change schedule opens, as shown in Figure 11-6 on page 358.

Note: Key rollovers occur based on the operating system time of the TKLM server. To
ensure that rollovers occur when you expect, having the TKLM server use NTP is a good
practice. Another point to consider is time zones. If your disaster recovery site is in another
time zone, there might be a time window where the two key servers are serving different
keys.


Figure 11-6 Checking the key group schedule

11.3.3 Scheduling certificate rollover
One of the advantages of TKLM is that you can schedule it to change certificates at a
predetermined time with out human intervention. However care must be taken when doing
this as the certificates are generated at creation time not certificate rollover time. This means,
when you create a certificate that will take effect at a later date you must not expire the
certificate until after the next scheduled certificate change. For example, if you have a default
certificate that expires in one week but your policy is to change certificates on a three-month
cycle, when you create the certificate, you must set them to expire in no sooner than three
months and one week.


To create a new certificate select Tivoli Key Lifecycle Manager  Key Administration 
3592, and then select Add, as in Figure 11-7.

Figure 11-7 Adding a 3592 certificate

Select 3592 Certificate Rollover as in Figure 11-8.

Figure 11-8 Select the Calendar icon to schedule a certificate change


Select Add. Refer to Figure 11-9.

Figure 11-9 Certificate rollover schedule

Select the new certificate you want to use and when it should take affect. Refer to
Figure 11-10 on page 361. Note its expiration date to ensure it will be usable for encrypting
cartridges as long as you need it.


Figure 11-10 Select the certificate and its effective date

Make sure you backup and replicate this change to any secondary TKLM servers.

11.4 TKLM backup and restore procedures
The TKLM backup saves a password-protected copy of the TKLM server settings including
the keystore and DB2 tables. However, when restoring, the function assumes that the
environment is similar. TKLM restore-operations should be on the same platform with the
same system, user account information and TKLM, and middleware file layout.

Because the keystore is backed up with the TKLM instance, you should treat the backups
with the same logical and physical security controls that you do for the TKLM keystore.

Note: Backup and restore are disruptive to the TKLM server as of TKLM 1.0.


11.4.1 Backup by using the GUI
Using the GUI to backup the TKLM configuration is fairly simple but does require discipline by
the administrator to perform a backup after significant changes and on a periodic interval.
Before starting the backup, the administrator should plan for either a small service outage
and confirm that one or more secondary key servers are running.

To backup using the GUI:
1. Select Tivoli Key Lifecycle Manager  Settings  Backup and Restore.
2. Click Create Backup. Refer to Figure 11-11.

Figure 11-11 TKLM backup/restore

The panel in Figure 11-12 is displayed. You are prompted to select a location for the
backup, a password for the backup and a short description.

Figure 11-12 Backup creation

3. Click Create Backup. A warning message indicates that the backup will be stopping the
server. In our environment, this was a short outage of a couple of minutes.


11.4.2 Restore by using the GUI
Using the GUI to restore the TKLM configuration is fairly simple but does require discipline by
the administrator to perform a backup after significant changes and on a periodic interval.

Note: Restoring a backup requires command-line access to restart the server after the file
has been restored.

To restore by using the GUI:
1. Select Tivoli Key Lifecycle Manager  Settings  Backup and Restore. Refer to
Figure 11-13.

Figure 11-13 TKLM Backup/Restore

2. From the list of Backup Files, select the file that you want to restore and click Restore
From Backup as shown in Figure 11-14.

Figure 11-14 Select the backup file to restore


3. Enter the password for the backup file, as shown in Figure 11-15.

Figure 11-15 Enter the password

4. Confirm that it is OK to stop the TKLM server and overwrite the current configuration.
5. Restart TKLM, by opening a command line and then:
– If on Windows, you must be an administrator or equivalent user. Perform these steps:
i. From the c:IBMtivolitipbin directory run stopServer.bat server1.
ii. Enter the tipadmin user name and password.
iii. Run startServer.bat.
iv. Enter the tipadmin user name and password.
– If on Linux, AIX, or Solaris, you must be root or equivalent privileged user that can start
and stop the TKLM services. Perform these steps (seeExample 11-6 on page 365):
i. From the /opt/IBM/tivoli/tip/bin directory, run stopServer.sh server1.
i. Enter the tipadmin user name and password.
ii. Run startServer.sh.
iii. Enter the tipadmin surname and password.


Example 11-6 Starting and stopping the TKLM server on Linux
[root@dyn9011169152 bin]# ./stopServer.sh server1
ADMU0116I: Tool information is being logged in file

/opt/IBM/tivoli/tip/profiles/TIPProfile/logs/server1/stopServer.log
ADMU0128I: Starting tool with the TIPProfile profile
ADMU3100I: Reading configuration for server: server1
Realm/Cell Name: <default>
Username: tipadmin
Password:
ADMU3201I: Server stop request issued. Waiting for stop status.
ADMU4000I: Server server1 stop completed.

[root@dyn9011169152 bin]# ./startServer.sh server1
ADMU0116I: Tool information is being logged in file

/opt/IBM/tivoli/tip/profiles/TIPProfile/logs/server1/startServer.log
ADMU3200I: Server launched. Waiting for initialization status.
ADMU3000I: Server server1 open for e-business; process id is 1955
[root@dyn9011169152 bin]#

11.4.3 Backup by using the command line
Backing up by using the CLI is similar to using the GUI only less forgiving. Because of the
startup time for the Jython interface, backing up by using the GUI is probably as fast and
easier, unless you have integrated it into other scripts. Refer to 11.1, “Scripting with TKLM” on
page 350 for an example of a quick backup script.

Note: TKLM Backup is a disruptive operation so ensure that you only perform backups
during maintenance windows or when you have a secondary TKLM up and serving keys.

Starting the CLI on Windows
To start the Jython interactive command line as administrator or equivalent user, run the
following command (assuming TKLM is installed in the default c:IBMtivolitipbin
directory):
wsadmin.bat -username TKLMAdmin -password password -lang jython

Starting the CLI on Linux, AIX, Solaris
To start the Jython interactive command line as root or equivalent user, run the following
command (assuming TKLM is installed in the default /opt/IBM/tivoli/tip/bin/ directory):
wsadmin.sh -username TKLMAdmin -password password -lang jython

Running the backup from the CLI
When you are at the wsadmin prompt, you can take a backup by using the command:
print AdminTask.tklmBackupRun(‘[backupDirectory <the directory to save the backup in>
-password <password to use on the backup file>]’)

After this completes you should have something similar to Example 11-7 on page 366, from a
linux TKLM server. This example creates a backup with no description and a password of


myBackupPws in the /root/TKLMBackup directory. For a Windows backup, simply enter a valid
Windows path name such as c:TKLMBackup.

Example 11-7 Taking a backup from the CLI
[root@dyn9011169152 ~]# /opt/IBM/tivoli/tip/bin/wsadmin.sh -username TKLMAdmin
-password password -lang jython
WASX7031I: For help, enter: "print Help.help()"
wsadmin>print AdminTask.tklmBackupRun('[-backupDirectory /root/TKLMBackup
-password myBackupPws]')
(0) Backup operation succeeded.
===============================

wsadmin>exit
[root@dyn9011169152 ~]#

11.4.4 Restore by using the command line
Restore using the Command Line is similar to using the command line from the GUI with the
advantage you are already at a command prompt so it is more natural to restart the server.
You could even script up the restore operation so it includes starting and stopping the server.

Note: TKLM restore is a disruptive operation ensure you only perform restore’s during
maintenance windows or when you have a primary TKLM up and serving keys.

directory):


Running the restore from the CLI
When you are at the wsadmin prompt, you can restore a backup by using the command:
print AdminTask.tklmBackupRunRestore(‘[-backupFilePath <backup file inc file name>
-password <backup file password>]')

After this completes you should have something similar to Example 11-8 on page 367, from a
linux TKLM server. This example restores a backup file with a password of myBackupPws with
the full file name. For a Windows backup, simply enter a valid windows path name like
c:TKLMBackup<backup filename>.jar. The example then restarts the TKLM server, which
is a required step after performing a restore operation.


Example 11-8 Restoring TKLM from a backup file
wsadmin>print AdminTask.tklmBackupRunRestore('[-backupFilePath
/root/TKLMBackup/tklm_v1.0_20081117141514MST_backup.jar -password myBackupPws]')
(0) Restore operation succeeded. Restart the server.
====================================================

wsadmin>exit
[root@dyn9011169152 ~]# /opt/IBM/tivoli/tip/bin/stopServer.sh server1ADMU0116I:
Tool information is being logged in file
/opt/IBM/tivoli/tip/profiles/TIPProfile/logs/server1/stopServer.log
Realm/Cell Name: <default>
Username: tipadmin
Password:
ADMU3201I: Server stop request issued. Waiting for stop status.
ADMU4000I: Server server1 stop completed.

[root@dyn9011169152 ~]# /opt/IBM/tivoli/tip/bin/startServer.sh server1ADMU0116I:
Tool information is being logged in file
/opt/IBM/tivoli/tip/profiles/TIPProfile/logs/server1/startServer.log
ADMU3200I: Server launched. Waiting for initialization status.
ADMU3000I: Server server1 open for e-business; process id is 5978
[root@dyn9011169152 ~]#

11.5 Data sharing with business partners
At some time, you will probably want to send an encrypted tape to a business partner. As with
EKM, you will have to define keys or sets of keys that can be read by you and your business
partner. At this time, you may only import and export keys from TKLM using the TKLM
command line.

11.5.1 Sharing TS1100 certificate data with a business partner
TKLM can export or import certificates in two formats, which are base64 and Distinguished
Encoding Rules (DER). The default used in our example is base64.

directory):



Listing the current certificates in the keystore
Assuming you have started the CLI you can then list the keys in the keystore by using the
tklmCertList command as shown in Example 11-9. To export a certificate you must first
determine its UUID. Find the key alias by using the GUI and then list out the key by name to
find its UUID.

Example 11-9 Sample key store list usage
jython
wsadmin>print AdminTask.tklmCertList()

uuid = CERTIFICATE-c68fb4ab-55c2-4599-8362-824d5fc45858
alias(es) = ssl for key serving
key store name(s) = Tivoli Key Lifecycle Manager Keystore
key state = active
issuer name = CN=SSL for Key Serving, OU=, O=, L=, ST=, C=
subject name = CN=SSL for Key Serving, OU=, O=, L=, ST=, C=
creation date = Nov 17, 2008
expiration date = Nov 17, 2011
serial number = 1226963273423369000

uuid = CERTIFICATE-71ee0c59-676d-4d71-ab22-3f7dfeee5af0
alias(es) = 3592 certificate
key state = active
issuer name = CN=Certificate for 3592, OU=, O=, L=, ST=, C=
subject name = CN=Certificate for 3592, OU=, O=, L=, ST=, C=
serial number = 1226963425384785000

wsadmin>


If you only want a particular key, you have to use the alias(es) and key store name(es)
parameters as shown in Example 11-10.

Example 11-10 keystore list using -alias
wsadmin>print AdminTask.tklmCertList('[-alias "3592 certificate" -keyStoreName
"Tivoli Key Lifecycle Manager Keystore"]')

uuid = CERTIFICATE-71ee0c59-676d-4d71-ab22-3f7dfeee5af0
alias(es) = 3592 certificate
key state = active
issuer name = CN=Certificate for 3592, OU=, O=, L=, ST=, C=
subject name = CN=Certificate for 3592, OU=, O=, L=, ST=, C=
serial number = 1226963425384785000

wsadmin>

TS1100 encrypted media certificate export
Now that we know the certificate UUID as shown in Example 11-10, we can export the key by
using the tklmCertExport command, as shown in Example 11-11.

Example 11-11 Using tklmCertExport to export certificates from TKLM
wsadmin>print AdminTask.tklmCertExport('[-uuid
CERTIFICATE-71ee0c59-676d-4d71-ab22-3f7dfeee5af0 -fileName /root/3592certificate]')
/root/3592certificate
wsadmin>exit
[root@dyn9011169152 ~]# cat /root/3592certificate
-----BEGIN CERTIFICATE-----
MIICSjCCAbOgAwIBAgIIEQcMvBJ05GgwDQYJKoZIhvcNAQEFBQAwVjEJMAcGA1UEBhMAMQkwBwYD
VQQIEwAxCTAHBgNVBAcTADEJMAcGA1UEChMAMQkwBwYDVQQLEwAxHTAbBgNVBAMTFENlcnRpZmlj
YXRlIGZvciAzNTkyMB4XDTA4MTExNzIzMTAyNFoXDTExMTExNzIzMTAyNFowVjEJMAcGA1UEBhMA
MQkwBwYDVQQIEwAxCTAHBgNVBAcTADEJMAcGA1UEChMAMQkwBwYDVQQLEwAxHTAbBgNVBAMTFENl
cnRpZmljYXRlIGZvciAzNTkyMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCXnKuPspW7ErCJ
heYLEgU/VGI1qfOMN22NXgkgsO3DIR0BzqvAWgnYhBFoQraRhdZYK4Vu55XkIkzad7jVJ3yL771W
CXzRYHvLUmISIEpTGD4QBDSMFxF3JcRQrBUYQHuWkzqWn2sLbViEF+3NQvtqrP/8PTAuGS+rhhbt
n5EgyQIDAQABoyEwHzAdBgNVHQ4EFgQUYH89NQCw/zxWUVsqylfO6skOKOMwDQYJKoZIhvcNAQEF
BQADgYEAWrj8YX5z0AbfVAi1CmhVfxEcb3eeyXfh5b/7AGZy0H+xtxLJdt8Ro3H66k52uI7kRQf8
jCixfpbal8ITZHey6WH43WHl+gnSJIhq8CLugbRGaWcwuj9xS0RdYHvloxhKBiwPVMLsrTGCsJCh
Yv7GiSHs9UehS58N7savmSQqaXo=
-----END CERTIFICATE-----
[root@dyn9011169152 ~]#

You can then send this certificate containing your public key to a business partner so they
can write encrypted tapes that you can read using the private key stored in TKLM.

TS1100 encrypted media certificate import
Your business partner must send you a certificate containing the public key that the business
partner would like to use to encrypt the TS1100 cartridges. After you receive the key, you
may import the certificate as shown in Example 11-13 on page 370. The parameters usage is
as follows:


print AdminTask.tklmCertImport('[-fileName <full path to certificate> -alias <the name of
the certificate in tklm> -format <base64 or DER> -keyStoreName "Tivoli Key Lifecycle
Manager Keystore" -usage <3592>]')

Example 11-12 Importing a certificate from a business partner
wsadmin>print AdminTask.tklmCertImport('[-fileName /root/bpCert.cer -alias
bp3592Cert -format base64 -keyStoreName "Tivoli Key Lifecycle Manager Keystore"
-usage 3592]')
wsadmin>

11.5.2 Sharing LTO key data with a business partner
TKLM can share keys with business partners by using TKLM by exporting the symeteric or
secret keys. These keys are then imported into the business partner’s key store and may be
used to read or write tapes written with the same key or keys.

Note: With TKLM 1.0 you can only import LTO key data from TKLM

directory):


LTO encrypted media key group export
Before you can export keys to a business partner you must first have (import), from the
business partner, a public key to use for encrypting the LTO keys, which will allow secure
transmission of the LTO key (export).

Importing a business partner’s public key
Your business partner must send you a certificate containing the public key that the business
partner would like to use to encrypt the LTO keys. After you receive the key, you may import
the certificate as shown in Example 11-13. The parameters usage is:
print AdminTask.tklmCertImport('[-fileName <full path to certificate> -alias <the name of
the certificate in tklm> -format <base64 or DER> -keyStoreName "Tivoli Key Lifecycle
Manager Keystore" -usage <3592>]')

Example 11-13 Importing a certificate from a business partner
wsadmin>print AdminTask.tklmCertImport('[-fileName /root/bpCert.cer -alias
bpLTOCert -format base64 -keyStoreName "Tivoli Key Lifecycle Manager Keystore"
-usage 3592]')
wsadmin>


Viewing key aliases with the GUI
You may view a range of LTO keys when using the TKLM command line. LTO keys are
referred to as secret or symmetric keys. For this example, we have created a key group
named LTO1; all keys in this key group start with the three letters LTO. Using the GUI, you
may change the view in the TKLM to show the key aliases in a key group, as shown in
Figure 11-16.

Figure 11-16 The key alias in a key group

Exporting LTO keys from the CLI
After you know the alias of the key groups you want to export, you may use the CLI to export
them.

directory):



Exporting the LTO keys
In Example 11-14, we are exporting the keys LTO0guatda.com/cmx.p000...0 to LTO0guatda.com/cmx.p000...9 note that the
command line allows you to ignore the leading 0s (zeros) so the range passed to the
command line using the -aliasRange parameter is LTO0-9. The next option -fileName is the
absolute path of the file we are exporting. You may use a relative path but then it is relative to
the TKLM install directory. The keyStoreName parameter must be set to "Tivoli Key
Lifecycle Manager Keystore". The -type option must be set to secretkey as this tells the
export command we are exporting LTO keys the tklmKeyExport command line may also be
used to export public-private key pairs from TKLM if necessary. The -keyAlias paramater
specifies which certificate of the public key to use to encrypt the key file.

Example 11-14 Exporting LTO keys
wsadmin>
wsadmin>print AdminTask.tklmKeyExport ('[-aliasRange LTO0-9 -fileName
/root/bpLTOKeys -keyStoreName "Tivoli Key Lifecycle Manager Keystore" -type
secretkey -keyAlias "3592 certificate"]')

LTO encrypted media key or keys import
To import a TKLM key file from another source you must first have the certificate containing
the private key of the public-private key-pair used to encrypt the key file loaded into TKLM as
described in 11.5.1, “Sharing TS1100 certificate data with a business partner” on page 367.
To load the key file you have to use the CLI.

directory):


Loading the key file into TKLM
Example 11-15 on page 373 shows a script that loads a key file into TKLM. The
importKeyFile.sh script calls the importKeyFile.py script, which prints descriptive text and
then imports a file named /root/ltoKeyFile using the private key or certificate ltocert. The
type, secretkey, is an LTO asymmetric key.


The usage parameter is a required option specifying that this is an LTO key file. For additional
options you can use the CLI reference at:
ref_ic_cli_key_import.html

Example 11-15 Sample Jython script to add a key file
[root@dyn9011169152 ~]# cat importKeyFile.sh
jython -f importKeyFile.py
[root@dyn9011169152 ~]# cat importKeyFile.py
print "Importing key file /root/ltoKeyFile to TKLM with the same alias as used on
other TKLM"
print AdminTask.tklmKeyImport('[-fileName /root/ltoKeyFile -keyAlias ltocert
-keyStoreName "Tivoli Key Lifecycle Manager Keystore" -type secretkey -usage
LTO]')

[root@dyn9011169152 ~]#

Example 11-16 imports an LTO secret or asymmetric key group into TKLM.

Example 11-16 Key Import into TKLM
[root@dyn9011169152 ~]# ./importKeyFile.sh
Importing key file /root/ltoKeyFile to TKLM with the same alias as used on other
TKLM
[root@dyn9011169152 ~]#

11.6 Removing TKLM
You might have to remove TKLM from a system. The current TKLM 1.0 uninstall process is
not as straightforward as running the installer. The steps in this section clean the TKLM off a
Windows system. Make sure you have another TKLM or EKM backup system configured and
working, or that you are performing the TKLM cleanup during a maintenance cycle, because
after the TKLM service is stopped you can no longer use this TKLM server to read or write
tape cartridges.

11.6.1 Backing up the keystore
Ensure that you have a good backup copy of the keystore before starting this process
because the process removes the currently running keystore. For the procedures to back up
your TKLM configuration and keystore, see 11.4, “TKLM backup and restore procedures” on
page 361.

11.6.2 Removing TKLM from a Windows system
The general steps include stopping and removing the TIP service, uninstalling DB2, and
delete TKLM from the system.


To remove TKLM from a Windows system:
1. Stop the TIP service:
a. Open the services window and find “Tivoli Integrated Portal - TipProfile_Port_16310.
See Figure 11-17.

Figure 11-17 Stopping the TIP service

b. If the service does not stop you can stop it from the command line. In Example 11-17,
the TIP service had been installed in c:ibmtivolitip directory.

Example 11-17 Stopping the TIP service
C:ibmtivolitipbin>WASService -stop TIPProfile_Port_16310
Could not stop service: The service has not been started.

C:ibmtivolitipbin>

2. Remove the TKLM DB2 instance owner. Refer to Example 11-18.

Example 11-18 Uninstall TKLM DB2 instance owner
C:ibmtivolitipproductstklm_uninst>removeDB2Inst.bat
You will lose the database instance and all data in it when you run this batch
file, are you sure you want to continue? (yes/no) yes
DB2 instance tklmdb2
DB2 name tklmdb
DB2 install directory C:Program FilesIBMSQLLIB
Removing database instance...
Uninstall DB2 instance is complete. You can look at
tklmtempremoveDB2Inst.output.txt for more information
C:ibmtivolitipproductstklm_uninst>


3. Uninstall TIP using. Refer to Example 11-19 and Figure 11-18.

Example 11-19 Launch the graphical uninstaller
C:ibmtivolitip_uninstTIPInstall>uninstall.exe

Figure 11-18 Enter your TIP admin user name and password

Uninstalling can take several minutes.
– If uninstalling fails:
i. Run the removeDEInfo.bat file, in the productstklm_uninst directory.
ii. From the bin directory, run WASService -remove TIPProfile_Port_<port_number>.
4. Remove the TIP home directory. Refer to Example 11-20.

Example 11-20 Cleanup other directories
C:ibmtivoli>rmdir /s tip
tip, Are you sure (Y/N)? y

C:ibmtivoli>

Directory of C:Documents and SettingsVRes01

11/13/2008 12:05 PM <DIR> .
11/13/2008 12:05 PM <DIR> ..
11/13/2008 10:06 AM <DIR> Desktop
08/08/2007 06:36 AM <DIR> Favorites
11/12/2008 12:57 PM 197,634 IA-TIPInstall-00.log
11/13/2008 12:05 PM 97,336 IA-TIPUninstall-00.log
10/29/2008 08:49 AM <DIR> My Documents
10/29/2008 08:56 AM <DIR> Start Menu
6 Dir(s) 9,682,993,152 bytes free


C:Documents and SettingsVRes01>del IA*.log

C:Documents and SettingsVRes01> rmdir /S c:tklmtemp
c:tklmtemp, Are you sure (Y/N)? y

C:Documents and SettingsVRes01>del c:tklm_install.std*

C:Program FilesIBM>"Program FilesIBMCommonacsisetenv.cmd"

C:Program FilesIBM>"Program FilesIBMCommonacsibinsi_inst.bat" -r -f
ACUINI0004I UnInstallation completed successfully!
The batch file cannot be found.

C:Program FilesIBM>rmdir /s "c:Program FilesIBMCommonacsi”
c:Program FilesIBMCommonacsi, Are you sure (Y/N)? y

5. Verify that the acsi directory has actually been removed.
Uninstall DB2. Refer to Figure 11-19.

Figure 11-19 Remove DB2

6. Stop and disable the DB2 services (refer to Figure 11-20).
– DB2(tklmx)
– DB2 Governor (tklmx)
– DB2 License Server (tkmx)
– DB2 Management Service (tklmx)
– DB2 Remote Command Server (tklmx)
– DB2 Security Server (tklmx)
– DB2DAS

Figure 11-20 TKLM DB2 services to stop and disable


7. Delete the TKLM Windows user. Refer to Figure 11-21.

Figure 11-21 Delete the TKLM windows user

8. Restart the computer

11.7 Fixing the security warnings in your Web browser
Internet Explorer and Firefox both raise security warnings about the TKLM certificate. This
action is normal because the certificate that is installed is an unsigned certificate. If you want
to stop the warnings, following the steps in this section.

11.7.1 Fixing the security warning in Internet Explorer browser
If you receive the error shown in Figure 11-22, select Continue if you are sure that you have
the correct IP for your TKLM server and you have not previously installed the certificate for
this server.

Figure 11-22 Warning message in Internet Explorer browser window


Click the Certificate Error and select view certificates. Refer to Figure 11-22 on page 377.

Figure 11-23 IE Error

Then, select Install certificate and follow the prompts to install the TKLM server certificate.
After you have added the certificate, restart Internet Explorer.

Note: You must connect to TKLM using the host name in the certificate, not IP or other
host names, to avoid certificate mismatch warning.

11.7.2 Fixing the security warning in Firefox 2
Firefox 2 is more forgiving. It presents an initial warning, which, if you accept, does not
appear again. As of this writing, Firefox 3 is not supported and certain pages do not render
correctly.


Part 4

Part 4 Implementing tape data
encryption
In this part, we explain the steps required to implement tape data encryption on the various
host platforms, tape drives, and tape libraries.


12

Chapter 12. Implementing TS1100 series
Encryption in System z
In this chapter, we describe the required implementation steps for using the TS1120 and
TS1130 Tape Encryption capability in z/OS or z/VM. For these platforms, the TS1120 and
TS1130 drives must be attached to an 3592-J70 tape controller or an IBM TS1120 and
TS1130 Model C06 Tape Controller. The TS1120 or TS1130 drives can reside in a TS3500
tape library, a 3494 tape library, or an IBM TS3400 Tape Library. The drives also can reside in
a C20 Silo-compatible frame or a rack, although we do not discuss these devices here.

Note: This chapter does not discuss encryption on TS1120 drives when they are attached
to a TS7700 Virtualization Engine. For this information, refer to Chapter 13, “Implementing
TS7700 Tape Encryption” on page 421.

We discuss the following implementation topics:
Implementation overview
Tape library implementation
z/OS implementation steps
z/VM implementation steps
Miscellaneous implementation considerations
TS1120 Model E05 rekeying support in z/OS


12.1 Implementation overview
The implementation steps can include:
The installation of the tape library, TS1120 and TS1130 tape drives, and tape controllers
A firmware upgrade of the tape and library components and installation of the required
software support

We will assume here that the drives, libraries, and controllers have already been installed and
are operating without encryption. We describe what is required to implement encryption on
the TS1120 tape drives.

All prerequisites necessary for hardware (microcode levels for the tape drives, libraries, and
so forth) and software for the various platforms are discussed in Chapter 4, “Planning for
software and hardware” on page 91.

Although we do not discuss TS1120 or TS1130 encryption implementation in detail for z/VSE
and z/TPF operating systems, both of these operating systems use out-of-band encryption in
a manner similar to z/VM. Use the procedures for z/VM to enable out-of-band encryption on
the tape control units after the installation of feature code (FC) 5595 or FC9595 on the tape
control units. For information about how to control and set encryption for z/VSE or z/TPF, we
refer you to the following publications:
For z/VSE, refer to z/VSE V4R1 Administration, SC33-8304.
For z/TPF, refer to z/TPF Enterprise Edition Operations, GTPO-1MS5, at the IBM TPF
Product Information Center:
http://publib.boulder.ibm.com/infocenter/tpfhelp/current/index.jsp?topic=/com.i
bm.tpf.doc/pichHome.html

12.2 Implementation prerequisites
First, you must have tape drives, tape controllers, and a tape library operating without
encryption, which we review in 12.2.1, “Initial tape library hardware implementation” on
page 383 and in 12.2.2, “Initial z/OS software definitions” on page 384.

To enable and use tape data encryption in an already installed tape library, additional setup
steps are required. These implementation steps are described in detail in this chapter.

The prerequisites for encryption in System z are:
Encryption Key Manager (EKM) can be implemented on any supported platform.
The EKM must be connected to and communicating with the operating system (z/OS
in-band) or the EKM must be connected to and communicating with the tape control units
(z/VM, z/VSE, or z/TPF out-of-band). At least one certificate with a key label must be in
the EKM keystore.
We provide an overview in 12.3, “EKM implementation overview” on page 385. The
complete setup steps for implementing EKM are described in Chapter 7, “Planning and
managing your keys” on page 227.
Hardware setup for tape data encryption prerequisites include:
– An encryption-capable TS1120 tape drive attached to a TS1120 Model C06 Tape
Controller or a 3592-J70 tape controller.


– Enable the encryption method for the TS1120 drives installed in the library. See 12.4,
“Tape library implementation” on page 386. However, defer this action until the
necessary operating system maintenance has been installed.
– Enablement of encryption on the tape controllers. However, defer this action until the
necessary operating systems maintenance has been installed. See 12.5, “Tape control
unit implementation” on page 394.
z/OS tape data encryption setup prerequisites include:
– z/OS software maintenance installed that supports an encryption-enabled TS1120 and
TS1130. See 12.6.1, “z/OS software maintenance” on page 394.
– Update the IECIOSxx PARMLIB member. See 12.6.2, “Update PARMLIB member
IECIOSxx” on page 395.
– z/OS basic DFSMS implementation that includes a DFSMS Data Class that specifies a
Recording Technology of EE2 and specifies a key label (that exists in the EKM
keystore) to use for encrypting. See 12.6.3, “Define or update Data Class definitions”
on page 396.
– Update the JES3 definitions. See 12.6.4, “Considerations for JES3” on page 400.
– Verify and update your tape management system. See 12.6.5, “Tape management
system” on page 401.
z/VM tape data encryption setup is covered in section 12.7, “z/VM implementation steps”
on page 407.

For detailed z/OS implementation checklists, refer to Appendix A, “z/OS planning and
implementation checklists” on page 557.

Finally, we discuss other implementation items in 12.8, “Miscellaneous implementation
considerations” on page 415 and TS1120 rekeying in 12.9, “TS1120 and TS1130 tape
cartridge rekeying in z/OS” on page 416.

Now, you are ready to start creating encrypted cartridges.

12.2.1 Initial tape library hardware implementation
If you do not have an IBM system-managed tape library installed, refer to the following
publications for a detailed discussion of all implementation and migration steps:
For TS3500, refer to IBM TS3500 for System z Attachment: A Practical Guide to TS1120
Tape Drives and TS3500 Tape Automation, SG24-6789.
For IBM 3494, refer to IBM TotalStorage 3494 Tape Library: A Practical Guide to
Enterprise-Class Tape Drives and Tape Automation, SG24-4632.
For the TS3400, refer to IBM System Storage TS3400 Tape Library Planning and Operator
Guide, GC27-2107.

An overview of the tape library implementation steps follows:
Hardware installation
The service support representative (SSR) installs the hardware, such as the tape library
frames or components, the Library Manager, the tape drives, and the controllers. In
parallel, you may start defining the new hardware to your environment.
If you are installing encryption-capable TS1120 and TS1130 drives, the only additional
installation step is to enable encryption on the TS1120 and TS1130 tape drives, but not

Chapter 12. Implementing TS1100 series Encryption in System z 383

until all of the software maintenance to support encryption has been installed. We
describe enabling encryption on the TS1120 tape drives in detail later.
Library Manager setup
z/OS or z/VM requires a Library Manager for the TS3500 and 3494 tape libraries. For the
TS3500 library, the Library Manager or Managers are located in the 3953-F05 frame. For
the 3494 library, the Library Manager is in the 3494-Lxx frame and optionally, the
3494-HA1 frame.
After the tape library and drives are installed, you have to create definitions on the
hardware level. These definitions depend on which devices are installed inside the
TS3500 or 3494 tape library, whether you are sharing the tape library between different
platforms, whether an IBM Virtualization solution (TS7700 or IBM 3494 VTS) is included,
and other environment specifics. In a z/OS environment, you perform the setup at the
TS3500 and at the IBM 3953 Library Manager level.
Setup steps for the TS3500 tape library include:
– Enable Advanced Library Management System (ALMS). ALMS is required for
attachment of the TS3500 with IBM 3953 to System z servers.
– Enable the Insert Notification feature.
– Define a logical library.
– Add tape drives to the logical library.
– Define cartridge slots and control path drives for the logical library.
– Enable eight-character VOLSER support.
– Define cartridge assignment policies (CAPs).
At the IBM 3953 Library Manager or the 3494 Library Manager, setup steps include:
– Define physical VOLSER ranges for native drives, TS7700 Virtualization Engine, and
VTS, if installed.
– Define TS7700 and VTS management policies and parameters.
For TS7700 Virtualization Engine setup steps, refer to IBM System Storage Virtualization
Engine TS7700: Tape Virtualization for System z Servers, SG24-7312.
Hardware Configuration Definition
The Hardware Configuration Definition (HCD) dialog is mainly related to hardware. You
use the HCD panels to define the new hardware. All 3592 models, J1A and E05, emulate
3590 Model B tape drives from a software point of view, so the TS1120 is defined as a
3590 tape drive as well.
Because you do not define whether an IBM TS1120 or TS1130 tape drive is
encryption-enabled in HCD, both encryption-enabled and non-encryption-enabled TS1120
or TS1130 drives are defined exactly the same. You do not have to change existing HCD
definitions when implementing tape data encryption on an already defined TS1120.

12.2.2 Initial z/OS software definitions
IBM tape libraries in a z/OS environment are managed through Data Facility Storage
Management Subsystem (DFSMS). Therefore, the major part of implementing a tape library
is defining the tape library to SMS and defining the SMS constructs and Automatic Class
Selection (ACS) routines that direct tape allocation to the requested tape library.


Depending on your existing software environment, all or some of the following implementation
steps are required for z/OS host software setup:
Verify or update these SYS1.PARMLIB members:
– DEVSUPxx
– SCHEDxx
– IGDSMSxx
– IEFSSNxx
– CONSOLxx
– COMMNDxx
– GRSCNFxx
– LOADxx
– COFVLDxx
– ALLOCxx
– IECIOSxx
Define security profiles.
Allocate the Tape Configuration Database (TCDB).
Prepare, start, and customize OAM, including Installation Exits.
Update and customize your tape management system.
Using the Interactive System Management Facility (ISMF) panels, define:
– The TS3500, 3494, or TS3400 tape library

Note: The TS3400 does not appear to the host as a library; the drives in the library
appear as stand-alone drives. You only have to define the TS3400 to the host if you
will be using the drives in the TS3400 with the Manual Tape Library (MTL) support.

– One or more Data Class constructs
– One or more Storage Class constructs
– One or more Management Class constructs
– One or more Storage Group constructs
Update the ACS routines to assign the new constructs as required.
Translate, validate, and test the ACS routines.
Activate the SMS configuration.
If you are using JES3, update the JES3 INISH deck.

12.3 EKM implementation overview
In a z/OS or z/VM environment, you must use System-Managed Encryption, which requires
the Encryption Key Manager (EKM) as a prerequisite. In preparation for encryption on your
TS1120 tape drives, you must implement EKM and have at least one key in its keystore. Refer
to section 6.1, “Implementing the EKM in z/OS” on page 160, which describes the setup steps
for implementing EKM.

The basic EKM implementation steps are:
1. Note that UNIX System Services as a prerequisite for Java is already included with the
z/OS operating system. Verify whether the installed version of Java is at the appropriate
level for the Encryption Key Manager component.
2. Install the EKM after downloading the newest versions available.


3. Obtain the required security permission for the UNIX System Services segment.
4. Create a keystore for EKM.
5. Set up the EKM environment on JAVA.
6. Start the EKM.
7. Specify the TCP/IP address of the EKM or EKMs through the IECIOSxx PARMLIB
member or the SETIOS command.
8. Generate or import certificates and private keys into EKM’s keystore.

12.4 Tape library implementation
TS1120 encryption on the z/OS platform can be implemented in the TS3500, the 3494, or the
TS3400 tape library. You must specify the System-Managed Encryption method to enable
encryption in the TS1120 or TS1130 drives. Next, we describe how to specify the
System-Managed Encryption method for each of the libraries.

Note: Do not perform these implementation steps until you have installed all required
operating system support for TS1120 and TS1130 tape drives with encryption.

If you are using out-of-band encryption (which is usually for z/VM, z/VSE, or z/TPF
operating systems), you also have to update the EKM IP addresses to be used by the tape
controllers. We discuss updating the EKM IP addresses in the z/VM section, because z/VM
uses out-of-band encryption.

12.4.1 Implementation steps for the IBM TS3500 Tape Library
To update the tape drive definitions, use the Web browser interface of the TS3500, the
TS3500 Tape Library Specialist. Figure 12-1 on page 387 shows the Welcome panel of the
TS3500 Specialist.


Figure 12-1 Main entry or welcome panel of TS3500 Tape System Library

To perform the implementation:
1. On the left side of the panel, select Manage Library. The Manage Logical Libraries panel
opens. See Figure 12-2 on page 388.


Figure 12-2 Manage Logical Libraries panel

2. Check the logical library that you want to update and then click Manage Drives on the left
side of the panel. The panel shown in Figure 12-3 displays.

Figure 12-3 Encryption Method panel

3. In this panel, select the encryption method System-Managed, check the
encryption-capable drives to be attached to z/OS, and click Apply.


Warning: All drives attached to the same control unit must be selected. As Figure 12-3 on
page 388 shows that you can select the last two drives only if those drives are not
connected to the same control unit.

12.4.2 Implementation steps for the IBM 3494 Tape Library

Note: If your 3494 Library Manager is pre-535 microcode level, you will not be able to
perform these procedures. Instead, order FC5595 or FC9595 on the 3592-J70 or TS1120
and TS1130 Model C06 tape controllers. This item ships instructions and procedures for
the IBM SSR to use for enabling encryption on the controller and all attached
encryption-capable drives.

You can either use the Web browser interface of the 3494 tape library or the 3494 Library
Manager user interface. We describe both methods in the following sections.

3494 Enterprise Automated Tape Library Specialist
To update the tape drive definitions, use the Web browser interface of the 3494, the 3494
Enterprise Automated Tape Library Specialist (ETL). Figure 12-4 shows you the Welcome
panel of the Enterprise Automated Tape Specialist.

Figure 12-4 Main entry or welcome panel of the 3494 ETL

1. On the left side of the panel, select Administer library manager  Manage
Encryption  Drive Encryption Settings, which displays a panel similar to that in
Figure 12-5 on page 390. We do not show the left pane of the window in Figure 12-5 on
page 390 for better clarity. Figure 12-5 on page 390 shows a list of all encryption-capable
drives in the 3494 library and how they are currently configured.


Figure 12-5 Drive Encryption Settings panel

2. In this panel, check the boxes for all of the encryption-capable drives to be attached to
z/OS, from the Select Action pull-down menu, select Set VPD, and then click Go. The
panel shown in Figure 12-6 opens.

Figure 12-6 Encryption Method panel


3. In this panel, select the Encryption Method System-Managed from the pull-down menu,
and click Apply. Being able to set encryption in this manner was made available with
Library Manager microcode level 535.

3494 Library Manager user interface
To update the tape drive definitions for encryption using the 3494 Library Manager user
interface, start with the main Library Manager panel as shown in Figure 12-7.

Figure 12-7 Selections for Manage Encryption of the 3494 Library Manager

1. Select Commands  System Management  Manage Encryption to display a
Manage Encryption panel similar to Figure 12-8 on page 392.


Figure 12-8 Manage Encryption panel

2. With the introduction of 3494 Library Manager microcode level 535, this panel contains the
line LME: Drive Encryption Settings or SME: Drive Encryption Settings or similar line.
Highlight that entry and click Open panel, which displays a panel similar to Figure 12-9.


3. This panel lists all of the encryption-capable drives and their current settings. Select the
drives that will be attached to z/OS (or use Select All), click the System Managed radio
button, and then click Set VPD.


12.4.3 Implementation steps for the IBM TS3400 Tape Library
In this section, we describe how to implement the IBM TS3400 Tape Library.

IBM TS3400 Tape Library Specialist
To update the tape drive definitions, use the Web browser interface of the TS3400. You must
log in as an administrator. At the Java Security Warning message, simply click Run to start
the specialist. Figure 12-10 shows the initial System Summary panel of the IBM TS3400
Tape Library Specialist.

Figure 12-10 Main entry or welcome panel of the TS3400 Tape Library Specialist

1. There are only two TS1120 drives in a TS3400, so normally you only have one logical
library and we assume that here. On the left side of the panel, select Configure
Library  Encryption, which displays a panel similar to that in Figure 12-11 on
page 394.



2. In this panel, under the Encryption Settings, select the Encryption method of
System-Managed from the pull-down. For System-Managed, this is the only
specification required. Then, click Submit. This process enables the one or two TS1120
drives in the TS3400 library for System-Managed Encryption.

Repeat these steps for any other TS3400 libraries that are attached with the tape control unit.

12.5 Tape control unit implementation
In the planning phase, you should have ordered FC9595 (Plant) or FC5595 (Field) for your
3592 Model J70 or TS1120 Model C06 tape control units. Ask your service support
representative (SSR) to perform the installation steps for these features only after you have
installed all of the required operating system support for TS1120 tape drives with encryption.

12.6 z/OS implementation steps
In this section, we describe the host software implementation steps that are required for tape
data encryption.

12.6.1 z/OS software maintenance
The following z/OS software components have been enhanced to support tape data
encryption on the TS1120 and TS1130 tape drive:
Access method services (AMS)
DFSMS data set services (DFSMSdss)


DFSMS hierarchical storage manager (DFSMShsm)
DFSMS removable media manager (DFSMSrmm)
Encryption Key Manager component for the Java platform (EKM)
Input/output supervisor (IOS)
MVS job entry subsystem 3 (JES3)
Object access method (OAM)
Storage Management Subsystem (SMS)

You have to check the 3592DEVICE preventive service planning (PSP) bucket to determine
what z/OS maintenance is required to support an encryption-enabled TS1120 or TS1130
drive on your version of the z/OS operating system. Support was available beginning with
z/OS V1.4 and later. This software maintenance must be installed before the TS1120 or
TS1130 drives are enabled for encryption. Otherwise, the encryption-enabled TS1120 drives
will not come online.

12.6.2 Update PARMLIB member IECIOSxx
In support of the Encryption Key Manager (EKM), the IECIOSxx PARMLIB member has a
new EKM parameter. If in-band key management is used, you must modify this PARMLIB
member to include the TCP/IP-related information required to direct the I/O Supervisor (IOS)
proxy to an appropriate EKM (primary and secondary). This tells z/OS how to communicate
with the primary EKM and (optionally) the secondary EKM.

IPv6 support has been provided with APAR OA22271.

Specify the host names for the primary and secondary EKMs. For each EKM, either a host
name with an optional port or a decimal IP address with an optional port can be specified as
shown in Example 12-1. The default for the port is normally 3801.

Example 12-1 PARMLIB member IECIOSxx
EKM PRIMARY=host.name.com:port[,SECONDARY=127.0.0.1:port]

The host name can contain up to 60 characters. The DNS search suffixes are automatically
appended, which allows searches with shorter names.

Note: When the EKM subcommand is specified through PARMLIB, omit the comma after
the word EKM and leave a blank space between EKM and the specified parameter.

EKM settings can be changed by selecting another IECIOSxx member. Do this by using the
SET IOS=xx command dynamically.

Refer to z/OS V1R7.0 MVS Initialization and Tuning Guide, SA22-7591-03, and z/OS V1R7.0
MVS Initialization and Tuning Reference, SA22-7592-11, for reference for the command.

To display the current EKM settings, use either of the following commands:
D IOS,EKM
D IOS,EKM,VERIFY=ALL

If you also specify VERIFY, you can verify the availability of the primary and secondary EKMs.

See Figure 12-12 on page 396 for the results of the command.


Figure 12-12 The D IOS,EKM,VERIFY=ALL command shows both EKM TCP/IP addresses

The following command can dynamically change the settings of the EKM:
SETIOS EKM

The command details are shown in Example 12-2.

Example 12-2 SETIOS EKM command details
SETIOS EKM[,PRIMARY={dns_name[:port] } ]
or {ip_address[:port]}
or {NONE }
[,SECONDARY={dns_name[:port] }]
or {ip_address[:port] }
or {NONE }
[,MAXCONN=dd1 ]
[,MAXPCONN=dd2 ]

For details of the DISPLAY IOS,EKM and SETIOS EKM commands, refer to z/OS V1R7.0
MVS System Commands, SA22-7627-12.

12.6.3 Define or update Data Class definitions
Tape data encryption can be requested through the Data Class construct. The Recording
Technology specified in the Data Class determines whether a cartridge is written in J1A
format (E1), in TS1120-E05 or TS1130-E06 format (E2), or in encrypted E05 format (EE2).

The steps are:
1. You can define new Data Class constructs, or you can update the Recording Technology
parameter of existing Data Classes. Figure 12-13 on page 397 shows the ISMF Data
Class Alter panel where you change the Recording Technology. In our example,
encryption is requested by specifying EE2.


Figure 12-13 Data Class Alter (Page 3 of 5)

2. The Media Type must be 5, 6, 7, 8, 9, or 10. The Recording Technology must be EE2 to
encrypt the tape. The Performance Scaling is usually an N and Performance Segmentation
is not used. The other parameters do not apply to tape. Select PF8 after you have entered
or updated the Recording Technology. On the panel that follows, you also have to enter the
Key Labels and the Encoding for Key Labels for both key labels as shown in Figure 12-14
on page 398.
Key Label has to be the name of a key label that you have loaded into the EKM keystore.
Encoding for Key Label is either L for Label or H for Hash. L can be used (if you and the site
that will read the tape) will have the same key label names for their corresponding
certificates. H has to be used when the key label names might differ at the location where
the tape will be read, for example, a business partner’s location.
You can specify one or both key labels. If you specify only Key Label 1, then Key Label 1
will be used for both keys stored on the 3592 cartridge.


Figure 12-14 Data Class Alter (Page 4 of 5)

If you change existing Data Classes, verify your Data Class Automatic Class Selection (ACS)
routine to make sure that you are assigning the correct constructs. If you create new Data
Classes, update your Data Class ACS routine to have the new constructs assigned to those
tape data sets that you want to have encrypted.

To activate the new SMS definitions:
1. Translate the Data Class ACS routine.
2. Validate the ACS routines.
3. Activate the SMS Control Data Set (SCDS).

Key labels in JCL
In addition to using a Data Class construct to enable encryption and assign the key labels,
you can optionally assign the key labels using job control language (JCL) as shown in
Example 12-3 on page 399. However, if you do this, encryption must still be invoked through a
Data Class specification using a Recording Technology of EE2. The JCL parameters on the
DD statement are as follows, where x = 1 or 2:
KEYLABLx=
KEYENCDx=


Example 12-3 Sample JCL to write an encrypted cartridge
//C02STRW1 JOB CONSOLE,
// MSGCLASS=H,MSGLEVEL=(1,1),CLASS=B,
// TIME=1440,REGION=2M
/*JOBPARM SYSAFF=*
//*
//* ENC KEY MASTER JOB
//*
//CREATE1 EXEC PGM=IEBDG
//SEQ001 DD DSN=TAPE.C02M5CX2.PC5.NOPOOL.C02STRS1.MASTER,
// KEYLABL1='TAPE_SOL_TST_SHR_PVT_1024_LBL_02',
// KEYENCD1=L,
// KEYLABL2='TAPE_SOL_TST_SHR_PVT_2048_LBL_03',
// KEYENCD2=H,
// LABEL=(1,SL),UNIT=C02M5CX2,DISP=(,CATLG),
// DCB=(DSORG=PS,RECFM=FB,LRECL=2048,BLKSIZE=6144)
//SYSIN DD *
DSD OUTPUT=(SEQ001)
FD NAME=A,STARTLOC=1,LENGTH=10,FORMAT=ZD,INDEX=1
FD NAME=B,STARTLOC=11,LENGTH=13,PICTURE=13,'PRIMER RECORD'
CREATE QUANTITY=25,FILL='Z',NAME=(A,B)
END
/*

z/OS produces messages indicating when a tape has been encrypted and what key labels
and key modes were used. The job log for the job in Figure 12-15 lists the keys that were
used.

Figure 12-15 MSGIEC205I indicates key labels and key codes used


Note: The JCL data definition (DD) statements override encryption specifications in the
Data Class. If only one KEYLABL1 statement and only one KEYENCD1 are coded in the JCL, a
second keylabel and keycode with the same information will be generated on the cartridge
automatically. Whenever the first standard label (SL) on a cartridge contains encrypted
data, all following SL file data behind that will be encrypted. Knowing this, no further JCL or
Data Classes are required to write encrypted data to the same cartridge. You can prepare
cartridges for encryption purposes this way by writing a small file with LABEL=(1,SL) to a
cartridge.

12.6.4 Considerations for JES3
To allow for JES3 to build a list of Library Device Group (LDG) names, you update the JES3
INISH deck. Library Device Group names are a predefined set of tape subsystems within the
JES3plex. LDGs are esoteric groups in HCD and defined to JES3 as SETNAME groups.
JES3 selects a device from the LDGs and passes it to allocation.

For tape data encryption, you must define two new Library Device Group names:
LDLsssss Includes any 3592 Model E05 encryption-capable device emulating a
3590 Model B within the library indicated by serial number sssss.
LDG359L Includes any 3592 Model E05 Encryption-capable device emulating a
3590 Model B in any library in the JES3plex.

The DEVSERV command QT for device 1E0C, Read Device Characteristic returns the serial
number under LIBID.

To determine what library serial number sssss is used, enter the MVS command shown in
Example 12-4.

Example 12-4 DS QT command
DS QT,1E0C,RDC
IEE459I 11.14.29 DEVSERV QTAPE 272
UNIT DTYPE DSTATUS CUTYPE DEVTYPE CU-SERIAL DEV-SERIAL ACL LIBID
1E0C 3590L ON-RDY 3590A60 3590E1A* 0113-45731 0113-45731 I CA001
READ DEVICE CHARACTERISTIC
3590603590100190 4EDC0000B4D7FD48 6900000000000000 3590603590200009
0CA0010200000200 4683800004000000 0400001113800000 0000000000000000
**** 1 DEVICE(S) MET THE SELECTION CRITERIA
**** 1 DEVICE(S) WITH DEVICE EMULATION ACTIVE

The command response shows that tape unit address 1E0C belongs to a library with serial
number CA001.

In addition, you might find helpful the following MVS command DEVSERV Query Library. It
shows the attached devices and the associated LIBPORT-IDs of an ATL. See Example 12-5
on page 401.

Note: The DS QL,nnnnn can only be used for already initialized libraries.


Example 12-5 DS QL command
DS QL,CA001
IEE459I 15.15.43 DEVSERV QLIB 301
LIBID PORTID DEVICES
CA001 01 1E00* 1E01* 1E02* 1E03* 1E04* 1E05* 1E06* 1E07*
1E08* 1E09* 1E0A* 1E0B*
02 1E0C* 1E0D* 1E0E

12.6.5 Tape management system
The tape management systems typically track the recording format of a tape volume. With
encryption, a new recording format (EEFMT2) is used. Refer to your tape management
system provider for details about their encryption support.

12.6.6 DFSMSrmm support for tape data encryption
DFSMSrmm, as a feature of z/OS, has been updated for the new media types, recording
technology, and encryption key label support.

The following RMM TSO commands are expanded for MEDIATYPE and RECORD FORMAT:
ADDVOLUME
CHANGEVOLUME
SEARCHVOLUME

Table 12-1 shows media names and DFSMSrmm media names. We compare the media
names used in DFSMS with the media names used in DFSMSrmm. Only MEDIA5 (ETC) up
to MEDIA10 (EEEWTC) can be used for encryption on TS1120 tape drives, because only
these media names are requesting 3592 media.

Table 12-1 Media types
DFSMS media name DFSMSrmm Cartridge media Capacity without
media name compressiona

MEDIA 1 CST 3490 Standard 400 MB

MEDIA 2 ECCST 3490 Extended 800 MB

MEDIA 3 HPCT 3590 J cartridge 10, 20, or 30 GB

MEDIA 4 EHPCT 3590 K cartridge 20, 40, or 60 GB

MEDIA5 ETC 3592 JA cartridge 300 or 500 GB

MEDIA6 (WORM) EWTC 3592 JW cartridge 300 or 500 GB

MEDIA7 EETC 3592 JJ cartridge 60 or 100 GB

MEDIA8 (WORM) EEWTC 3592 JR cartridge 60 or 100 GB

MEDIA9 EEETC 3592 JB cartridge 700 GB

MEDIA10 (WORM) EEEWTC 3592 JX cartridge 700 GB
a. Effective capacities with compression are three times as much, assuming a 3:1 compres-
sion ratio. Your compression ratios will vary with the data. The larger capacities are applica-
ble for 3592 cartridges written in encrypted format.


Note: Media 9 and Media 10 support is only available on z/OS V1R5 and higher.

Figure 12-16 shows an RMM panel indicating an encrypted tape volume. Panel ID
EDGPT110 shows for tape volume J1G151 with a recording format of EEFMT2.

Figure 12-16 Recording format EEFMT2

The mountable tape volume list option in ISMF (PANEL ID=DGTLGP31) under Recording
Technology can also be used to determine if a volume is encrypted. EEFMT2 is the indication
for encryption. See Figure 12-17.

Figure 12-17 Tape Volume List in ISMF


The only way to see more information for a volume is to enter a LISTVOLUME (LV) command.
It shows the key labels and method used (Label or Hash).

The LISTVOLUME command can be issued from the ISPF option 6 command prompt or as
a TSO command. The command syntax can be any of the following lines:
RMM LV VOLSER VOL
RMM LV VOLSER ALL
TSO RMM LV VOLSER

Example 12-6 shows the response to an RMM LV command.

Example 12-6 RMM LV response
Volume information:
Volume = J1G153 VOL1 = Rack = J1G153 Owner = DPA1
Type = PHYSICAL Stacked count = 0 Jobname = C02STRWG
Worldwide ID =

Creation: Date = 08/31/2006 Time = 08:29:02 System ID = SYS6
Assign: Date = 09/08/2006 Time = 14:39:42 System ID = SYS6
Expiration date = 09/09/2006 Original =
Retention date = WHILECATLG Set retained = NO
Data set name = TAPE.C02M5CX2.PC5.NOPOOL.C02STRSG.MASTER
Volume status:
Status = MASTER Availability = Vital Record Label = SL
Current label version = Required label version =
Media information:
Density = IDRC Type = ETC Format - EEFMT2 Compaction - YES
Special attributes = NONE Vendor -
Encryption Key Labels: Method:
1=tape_sol_tst_shr_pvt_1024_lbl_01 LABEL
2=tape_sol_tst_shr_pvt_1024_lbl_01 HASH
Action on release:
Scratch immediate = Y Expiry date ignore = N
Scratch = Y Replace = N Return = N Init = N Erase = N Notify = N
Actions pending:
Scratch = N Replace = N Return = N Init = N Erase = N Notify = N
Storage group = SGCASH02
Loan location = Account = CONSOLE
Description =
Security class = UNCLASS Description = UNCLASSIFIED

Access information:
Owner access = ALTER Volume access = NONE Last change = *OCE
VM use = N MVS use = Y
Access list:

Statistics:
Number of data sets = 1 Data set recording= ON
Volume usage(Kb)= 54 Use count = 17639
Volume capacity = 286102 Percent full = 0
Date last read = 09/14/2006 Date last written = 09/08/2006
Drive last used = 07C1 Write mount count = 2
Volume sequence = 1 Media name = 3480
Previous volume = Next volume =
Product number = Level = V R M


Feature code =
Error counts:
Temporary read = 0 Temporary write = 0
Permanent read = 0 Permanent write = 0

Movement tracking date = 08/31/2006 Intransit = N
In container = Move mode = AUTO

Location: Current Destination Old Required Home
Name = CASH02 CASH02
Type = AUTO AUTO
Bin number =
Media name =

In Example 12-6 on page 403, two key labels are used:
Key label with method LABEL
Key label with method HASH

Note: For tape management systems other than DFSMSrmm, contact your vendor.

12.6.7 DFSMSdfp access method service
Use the commands in this section to change, enter, or display information in the tape control
database (TCDB) catalog.

In support of tape data encryption, the access method service (AMS) commands, CREATE
VOLUMEENTRY, ALTER VOLUMEENTRY, DCOLLECT, and LISTCAT have been changed to
support the recording technique for encryption. One subparameter, EEFMT2 for the
parameter RECORDING, has been added for CREATE VOLUMEENTRY and ALTER
VOLUMEENTRY.

ALTER VOLUMEENTRY
Use the ALTER VOLUMEENTRY command to change the recording technology fields in the
volume records of a tape library:
EEFMT2 subparameter indicates read/write on an EEFMT2 track device.
EEFMT2 subparameter of RECORDING is only allowed with media types MEDIA5,
MEDIA6, MEDIA7, MEDIA8, MEDIA9, or MEDIA10. The use of MEDIA1 through MEDIA4
produces an IDC3226I error message that is generated twice: one time for EEFMT2 and
one time for the media type.

You can alter a tape volume with the following command:
ALTER VOLUMEENTRY RECORDING(EFMT1|EFMT2|EEFMT2)

Note that we list only the recording technologies currently supported with the IBM TS1120
Tape Drive:
EFMT1 is J1A non-encrypted format.
EFMT2 is E05 non-encrypted format.
EEFMT2 is E05 encrypted format.


CREATE VOLUMEENTRY
Use the CREATE VOLUMEENTRY command to create volume records of a tape library:
EEFMT2 subparameter indicates read/write on an EEFMT2 device.
EEFMT2 is only allowed with media types MEDIA5, MEDIA6, MEDIA7, MEDIA8, MEDIA9,
or MEDIA10. Any use of MEDIA1 through MEDIA4 produces an IDC3226I error message
that is displayed twice: one time for EEFMT2 and one time for the media in question. The
double display indicates an incompatibility between the EEFMT2 subparameter and the
media type displayed.
If MEDIA5, MEDIA6, MEDIA7, or MEDIA8 is specified and RECORDING is not specified,
default to EFMT1 for RECORDING value.
If MEDIA9 or MEDIA10 is specified and RECORDING is not specified, default to EFMT2
for RECORDING value.

The following example shows the EEFMT2 subparameter for CREATE VOLUMEENTRY:
CREATE VOLUMEENTRY RECORDING(EFMT1|EFMT2|EEFMT2|UNKNOWN)

Note that we only list the recording technologies currently supported with the IBM TS1120
Tape Drive.

DCOLLECT
The DCOLLECT command has values added to its definitions for DDCRECTE to allow the
constant DDCEEFM2 for EEFMT2 devices.r

LISTCAT
Use the LISTCAT command to display the new value associated with the RECORDING
parameter for VOLUME entries, as shown in Example 12-7.

Example 12-7 LISTCAT command
LISTCAT VOLUMEENTRIES ALL

IDCAMS SYSTEM SERVICES
LISTING FROM CATALOG -- SYS1.VOLCAT.V0

VOLUME ENTRY----V0A2991
DATA-VOLUME
LIBRARY---------ATLIB02
RECORDING--------EEFMT2
MEDIA-TYPE-------MEDIAx

MEDIAx represents either MEDIA5, MEDIA6, MEDIA7, MEDIA8, MEDIA9, or MEDIA10.

12.6.8 Data Facility Data Set Services considerations
Data Facility Data Set Services (DFSMSdss), as a functional component of z/OS, allows you
to copy, move, dump, and restore data sets and volumes. With this support, hardware
encryption joins software (or host-based) encryption as a means of encrypting your
installation’s tape volumes. Because DFSMSdss avoids performing double encryption of tape
data, you must determine which type of encryption, if any, is used for your tape volumes.
DFSMSdss prevents you from combining both types of encryption to avoid double encryption
of tape volumes.


12.6.9 DFSMS Hierarchal Storage Manager considerations
The Data Facility System Managed Subsystem Hierarchical Storage Manager (DFSMShsm),
also a functional component of z/OS, automatically manages low activity and inactive data in
both system-managed and non-system-managed environments. DFSMShsm also provides
automatic backup and recovery of active data in those environments. DFSMShsm can use
the encryption-capable IBM TS1120 Tape Drive (3592-E05) for all functions. DFSMShsm
normally uses non-WORM media (MEDIA5, MEDIA7, or MEDIA9) for non-aggregate backup
and recovery support (ABARS) functions. DFSMShsm uses all media, including WORM
(MEDIA6, MEDIA8, and MEDIA10) for ABARS processing. DFSMShsm can use the WORM
media for non-ABARs processing if it is specifically enabled in your installation.

To use tape hardware encryption, you must modify your SMS Data Class definitions to
request encryption from the encryption-capable tape drives. With the support for the
encryption-capable IBM TS1120 or TS1130 tape drive, hardware encryption joins software
(or host-based) encryption as another means of encrypting your installation’s dump data. As
a result, the method for requesting encryption now depends on whether you plan to use
hardware encryption or host-based encryption:
To request hardware encryption for a dump class, specify it in the SMS Data Class for the
dump data.
To request host-based encryption for a dump class, use the DFSMShsm DEFINE
DUMPCLASS(ENCRYPT) command. With ENCRYPT, include the RSA or
KEYPASSWORD subparameters (or NONE) to specify the type of host-based encryption.

Note: Although software (or host-based) encryption supports only dump data, all HSM
functions are supported with hardware encryption.

If your dump classes are currently defined to use host-based encryption (and possibly
host-based compression before encryption), we recommend that you remove the host-based
encryption requests from any dump classes for which you plan to use tape hardware
encryption.

During the process of migrating your dump classes to use hardware encryption, you might
have several dump classes that are still defined to use host-based encryption, while their
associated SMS Data Classes are defined to use tape hardware encryption. Here,
DFSMSdss ignores requests for host-based encryption for these tape volumes and, instead,
uses hardware encryption. This processing allows you to complete the migration to hardware
encryption without having to modify your dump-requesting jobs. However, removing
host-based encryption requests from a dump class when tape hardware encryption is also
requested can avoid confusion concerning which process is active.

Important considerations:
To determine whether hardware encryption or host-based encryption was used for a
particular tape volume, check the associated dump volume record (DVL).
If more than one dump class is specified (creating more than one dump copy), if those
dump classes specify host-based encryption, if each dump class has a unique Data
Class assigned, and if some but not all of the associated Data Classes request tape
hardware encryption, all dump copies fail. In other words, tape hardware encryption can
override host-based encryption for all dump classes associated with a source volume or
none of the dump classes, but it cannot override a subset of those dump classes.


You can request information for encrypted tape volumes with list commands to the tape table
of contents (TTOC) in the offline control data set (ODS) through any of the following
commands:
LIST TTOC SELECT(EEFMT2) ODS(ttoc.out.dataset)
LIST TTOC SELECT(ENCRYPTION) ODS(ttoc.out.dataset)
LIST TTOC SELECT(NOENCRYPTION) ODS(ttoc.out.dataset)

For a list of the information for the dump volumes of the requested status managed by
DFSMShsm, specify the LIST command with the DUMPVOLUME parameter without the
volume serial number. Instead, include a status parameter, such as AVAILABLE,
UNAVAILABLE, EXPIRED, UNEXPIRED, or NORETENTIONLIMIT. The command lists the
volumes in alphanumeric sequence by volume serial number. For the commands, refer to
z/OS V1R7.0 DFSMSdfp Storage Administration Reference, SC26-7402-05.

For more details, also refer to z/OS V1R3.0-V1R8.0 DFSMS Software Support for IBM
TotalStorage Enterprise Tape System 3592 (Model E05), SC26-7514-02.

12.7 z/VM implementation steps
z/VM prov

Ibm system storage tape encryption solutions sg247320

More Related Content

What's hot (17)

Similar to Ibm system storage tape encryption solutions sg247320 (20)

More from Banking at Ho Chi Minh city (20)

Recently uploaded (20)

Ibm system storage tape encryption solutions sg247320