Storage Encryption Sg247797

ibm.
com/redbooks
Front cover
IBM System Storage
Data Encryption
Alex Osuna
David Crowther
Reimar Pflieger
Esha Seth
Ferenc Toth
Understand the encryption concepts
and terminology
Compare various IBM storage
encryption methods
Plan for Tivoli Key Lifecycle
Manager and its keystores
International Technical Support Organization
IBM System Storage Data Encryption
June 2010
SG24-7797-00
Copyright International Business Machines Corporation 2010. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule
Contract with IBM Corp.
First Edition (June 2010)
This edition applies to Tivoli Key Lifecycle Manager Version 1 and later and the Encryption Key Manager
Release 1 and later.
Note: Before using this information and the product it supports, read the information in Notices on
page xvii.
Copyright IBM Corp. 2010. All rights reserved. iii
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
The team who wrote this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
Now you can become a published author, too! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Stay connected to IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Part 1. Introduction to data encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Chapter 1. Encryption concepts and terminology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Concepts of storage data encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 Symmetric key encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Asymmetric key encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1.3 Hybrid encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1.4 Digital certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 IBM Key Management methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3 Tivoli Key Lifecycle Manager and Encryption Key Manager . . . . . . . . . . . . . . . . . . . . . 16
1.3.1 IBM Encryption Key Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3.2 Encryption Key Manager components and resources . . . . . . . . . . . . . . . . . . . . . 19
1.3.3 Encryption keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.3.4 Tivoli Key Lifecycle Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.3.5 Tivoli Key Lifecycle Manager components and resources . . . . . . . . . . . . . . . . . . 22
Chapter 2. Introduction to storage data encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1 IBM tape drive encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2 IBM System Storage DS5000 series with encryption support. . . . . . . . . . . . . . . . . . . . 29
2.3 DS8000 series with encryption support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3.1 Encryption updates in DS8000 R5.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.4 Storage data encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4.1 Encryption of data on IBM tape drives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4.2 Encryption of data in IBM System Storage DS5000 Series . . . . . . . . . . . . . . . . . 35
2.4.3 Encryption of data in IBM System Storage DS8000 Series . . . . . . . . . . . . . . . . . 37
2.5 Encryption data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.5.1 IBM tape drive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.5.2 IBM Storage Series DS5000 and DS8000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.6 Using data encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.6.1 Encrypting data in the tape drive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.6.2 Encrypting data on disk drives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.6.3 Fundamentals to encryption: Policy and key management. . . . . . . . . . . . . . . . . . 46
Chapter 3. IBM storage encryption methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.1 Tivoli Key Lifecycle Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.1.1 Tivoli Key Lifecycle Manager components and resources . . . . . . . . . . . . . . . . . . 51
3.1.2 Key exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.2 IBM Encryption Key Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.2.1 Encryption Key Manager components and resources . . . . . . . . . . . . . . . . . . . . . 56
3.3 TS1120, TS1130, and LTO4 tape drive encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
iv IBM System Storage Data Encryption
3.3.1 Key exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.4 DS8000 disk encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.4.1 Encryption key management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.4.2 Encryption deadlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.4.3 Encryption recovery key support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.4.4 Dual platform key server support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.5 Comparing tape encryption methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.5.1 System-Managed Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.5.2 Library-Managed Encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.5.3 Encrypting and decrypting with SME and LME. . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.5.4 Application-Managed Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.5.5 Mixed mode example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Chapter 4. IBM System Storage tape automation for encryption. . . . . . . . . . . . . . . . . 87
4.1 IBM System Storage TS1130 and TS1120 tape drive . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.1.1 Tape data encryption support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.1.2 TS1120 characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.1.3 TS1130 characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.1.4 3592 cartridges and media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.2 IBM System Storage TS1120 Tape Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.2.1 IBM TS1120 Tape Controller characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.2.2 IBM TS1120 Tape Controller encryption support . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.2.3 Installation with an IBM TS3500 Tape Library . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.2.4 Installation with an IBM TS3400 Tape Library . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.2.5 Installation with an IBM 3494 Tape Library. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.2.6 IBM TotalStorage 3592 Model J70 Tape Controller . . . . . . . . . . . . . . . . . . . . . . 101
4.3 IBM Virtualization Engine TS7700 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.4 IBM LTO Ultrium tape drives and libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.4.1 Linear Tape-Open overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.4.2 LTO media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.4.3 IBM System Storage TS2240 Tape Drive Express Model . . . . . . . . . . . . . . . . . 108
4.4.4 IBM System Storage TS2340 Tape Drive Express Model . . . . . . . . . . . . . . . . . 109
4.4.5 IBM System Storage TS1040 Tape Drive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.4.6 IBM System Storage TS2900 Tape Autoloader . . . . . . . . . . . . . . . . . . . . . . . . . 111
4.4.7 IBM System Storage TS3100 Tape Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
4.5 IBM System Storage TS3400 Tape Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
4.6 IBM System Storage TS3500 Tape Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
4.6.1 TS3500 frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
4.6.2 TS3500 characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
4.7 IBM TotalStorage 3494 Tape Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Chapter 5. Full Disk Encryption technology in disk subsystems. . . . . . . . . . . . . . . . 133
5.1 FDE fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
5.2 Hardware implementation details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
5.3 FDE disks in storage products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Part 2. IBM System Storage DS5000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Chapter 6. Understanding Full Disk Encryption in DS5000 . . . . . . . . . . . . . . . . . . . . 141
6.1 FDE disk drives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
6.1.1 Securing data against a breach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
6.2 Creating a security key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Contents v
6.3 Changing a security key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
6.4 Security key identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
6.5 Unlocking secure drives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
6.6 Secure erase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
6.7 FDE security authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
6.8 FDE key terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Chapter 7. Configuring encryption on DS5000 with Full Disk Encryption drives. . . 153
7.1 The need for encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
7.1.1 Encryption method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
7.2 Disk Security components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
7.2.1 DS5000 Disk Encryption Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
7.2.2 Full Data Encryption disks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
7.2.3 Premium feature license . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
7.2.4 Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
7.2.5 Security key identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
7.2.6 Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
7.3 Setting up and enabling the Secure Disk feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
7.3.1 FDE and the premium feature key check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
7.3.2 Secure key creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
7.3.3 Enable disk security on the array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
7.4 Additional secure disk functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
7.4.1 Changing the security key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
7.4.2 Saving the security key file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
7.4.3 Secure disk erase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
7.4.4 FDE drive status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
7.4.5 Hot-spare drive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
7.4.6 Log files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
7.5 Migrating secure disk arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
7.5.1 Planning checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
7.5.2 Export the array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
7.6 Import secure drive array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
7.6.1 Unlock drives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
7.6.2 Import array. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Chapter 8. DS5000 Full Disk Encryption best practices . . . . . . . . . . . . . . . . . . . . . . . 177
8.1 Physical asset protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
8.2 Data backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
8.3 FDE drive security key and the security key file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
8.4 DS subsystem controller shell remote login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
8.5 Working with Full Disk Encryption drives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
8.6 Replacing controllers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
8.7 Storage industry standards and practices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Chapter 9. Frequently asked questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
9.1 Securing arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
9.2 Secure erase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
9.3 Security keys and passphrases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
9.4 Premium features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
9.5 Global hot-spare drives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
9.6 Boot support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
9.7 Locked and unlocked states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
9.8 Backup and recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
9.9 Additional questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
vi IBM System Storage Data Encryption
Part 3. Implementing tape data encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Chapter 10. Planning for software and hardware to support tape drives . . . . . . . . . 191
10.1 Encryption planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
10.2 Planning assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
10.3 Encryption planning quick-reference tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
10.4 Choosing encryption methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
10.4.1 Encryption method comparison. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
10.4.2 System z encryption methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
10.4.3 Open systems encryption methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
10.4.4 Decision time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
10.5 Solutions available by operating system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
10.5.1 The z/OS solution components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
10.5.2 z/VM, z/VSE, and z/TPF solution components for TS1120 drives . . . . . . . . . . 202
10.5.3 IBM System i encryption solution components . . . . . . . . . . . . . . . . . . . . . . . . . 204
10.5.4 AIX solution components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
10.5.5 Linux on System z. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
10.5.6 Linux on System p, System x, and other Intel or AMD Opteron servers. . . . . . 210
10.5.7 HP-UX, Sun, and Microsoft Windows components. . . . . . . . . . . . . . . . . . . . . . 213
10.5.8 Tivoli Storage Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
10.6 Ordering information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
10.6.1 TS1120 tape drive prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
10.6.2 Tape controller prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
10.6.3 LTO4 and LTO5 tape drive prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
10.6.4 Tape library prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
10.6.5 Other library and rack open systems installations. . . . . . . . . . . . . . . . . . . . . . . 222
10.6.6 TS7700 Virtualization Engine prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
10.6.7 General software prerequisites for encryption . . . . . . . . . . . . . . . . . . . . . . . . . 223
10.6.8 TS1120 and TS1130 supported platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
10.6.9 IBM LTO4 and LTO5 tape drive supported platforms . . . . . . . . . . . . . . . . . . . . 225
10.7 Other planning considerations for tape data encryption . . . . . . . . . . . . . . . . . . . . . . 226
10.7.1 In-band and out-of-band . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
10.7.2 Performance considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
10.7.3 Encryption with other backup applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
10.7.4 ALMS and encryption in the TS3500 library . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
10.7.5 TS1120 and TS1130 rekeying considerations . . . . . . . . . . . . . . . . . . . . . . . . . 229
10.8 Upgrade and migration considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
10.8.1 Potential issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
10.8.2 TS1120 and TS1130 compatibility considerations . . . . . . . . . . . . . . . . . . . . . . 231
10.8.3 DFSMSdss host-based encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
10.8.4 Positioning TS1120 Tape Encryption and Encryption Facility for z/OS . . . . . . 236
Chapter 11. Planning for Tivoli Key Lifecycle Manager and its keystores. . . . . . . . . 237
11.1 Tivoli Key Lifecycle Manager planning quick reference . . . . . . . . . . . . . . . . . . . . . . 238
11.2 Tivoli Key Lifecycle Manager and keystore considerations. . . . . . . . . . . . . . . . . . . . 241
11.2.1 Tivoli Key Lifecycle Manager configuration planning checklist . . . . . . . . . . . . . 244
11.3 Working with keys and certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
11.3.1 IT Service Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
11.3.2 General security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
11.3.3 Tivoli Key Lifecycle Manager key server availability . . . . . . . . . . . . . . . . . . . . . 246
11.3.4 Encryption deadlock prevention for DS8000. . . . . . . . . . . . . . . . . . . . . . . . . . . 247
11.3.5 Tivoli Key Lifecycle Manager key server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
11.3.6 DS8000 and tape devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Contents vii
11.4 Multiple Tivoli Key Lifecycle Managers for redundancy . . . . . . . . . . . . . . . . . . . . . . 249
11.4.1 Setting up primary and secondary Tivoli Key Lifecycle Manager servers. . . . . 250
11.4.2 Synchronizing primary and secondary Tivoli Key Lifecycle Manager servers . 250
11.5 Backup and restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
11.5.1 Categories of data in a backup file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
11.5.2 Backup file security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
11.5.3 IBM Tivoli Storage Manager as a backup repository . . . . . . . . . . . . . . . . . . . . 252
11.5.4 Backup and restore runtime requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
11.5.5 Backing up critical files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
11.5.6 Restoring a backup file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
11.5.7 Deleting a backup file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
11.6 Key exporting and importing tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
11.6.1 Exporting keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
11.6.2 Importing keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
11.6.3 Importing the public key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
11.6.4 Exporting the public key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
11.7 Integration and EKM to Tivoli Key Lifecycle Manager migration. . . . . . . . . . . . . . . . 259
11.7.1 Integrating Tivoli Key Lifecycle Manager for DS8000 with an existing EKM tape
encryption installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
11.7.2 Migrating from EKM to Tivoli Key Lifecycle Manager . . . . . . . . . . . . . . . . . . . . 259
11.7.3 Multiple encrypted disk or tape devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
11.8 Data exchange with business partners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
11.9 Disaster recovery considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
11.10 Database selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Chapter 12. Implementing Tivoli Key Lifecycle Manager . . . . . . . . . . . . . . . . . . . . . . 265
12.1 Implementation notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
12.2 Installing Tivoli Key Lifecycle Manager on 64-bit Windows Server 2008 . . . . . . . . . 266
12.3 Installing Tivoli Key Lifecycle Manager on 64-bit Red Hat Enterprise Linux AS Version
5.3 server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
12.4 Installing Tivoli Key Lifecycle Manager on z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
12.5 Configuring Tivoli Key Lifecycle Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
12.5.1 Configuration forLTO4 and TS1100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
12.5.2 Configuration for DS8000 disk drives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
12.6 Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Chapter 13. Tivoli Key Lifecycle Manager operational considerations . . . . . . . . . . . 353
13.1 Scripting with Tivoli Key Lifecycle Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
13.1.1 Simple Linux backup script example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
13.2 Synchronizing primary Tivoli Key Lifecycle Manager configuration data . . . . . . . . . 355
13.3 Tivoli Key Lifecycle Manager maintenance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
13.3.1 General disk and tape management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
13.3.2 Adding and removing drives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
13.3.3 Scheduling key group rollover for LTO tape drives. . . . . . . . . . . . . . . . . . . . . . 364
13.3.4 Scheduling certificate rollover for 3592 tape. . . . . . . . . . . . . . . . . . . . . . . . . . . 368
13.4 Tivoli Key Lifecycle Manager backup and restore procedures . . . . . . . . . . . . . . . . . 371
13.4.1 Using the GUI to back up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
13.4.2 Restore by using the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
13.4.3 Backing up by using the command line. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
13.4.4 Restore by using the command line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
13.5 Data sharing with business partners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
viii IBM System Storage Data Encryption
13.5.1 Sharing TS1100 certificate data with a business partner . . . . . . . . . . . . . . . . . 379
13.5.2 Sharing LTO key data with a business partner . . . . . . . . . . . . . . . . . . . . . . . . . 381
13.6 Removing Tivoli Key Lifecycle Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
13.6.1 Backing up the keystore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
13.7 Fixing the security warnings in your web browser. . . . . . . . . . . . . . . . . . . . . . . . . . . 385
13.7.1 Fixing the security warning in Internet Explorer browser . . . . . . . . . . . . . . . . . 385
13.7.2 Fixing the security warning in Firefox 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
13.8 The Tivoli Key Lifecycle Manager command-line interface. . . . . . . . . . . . . . . . . . . . 386
13.8.1 Commands using wsadmin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
13.8.2 Tivoli Key Lifecycle Manager commands using wsadmin. . . . . . . . . . . . . . . . . 387
13.8.3 Setting a larger timeout interval for command processing . . . . . . . . . . . . . . . . 388
13.8.4 Syntax examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
13.8.5 Continuation character . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
13.8.6 Parameter error messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
13.8.7 Command summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Chapter 14. Planning for Encryption Key Manager and its keystores . . . . . . . . . . . . 393
14.1 EKM planning quick-reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
14.2 Ordering information and requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
14.2.1 EKM on z/OS or z/OS.e requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
14.2.2 EKM on z/VM, z/VSE, and z/TPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
14.2.3 EKM on IBM System i requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
14.2.4 EKM on AIX requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
14.2.5 EKM on Linux requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
14.2.6 EKM on Hewlett-Packard, Sun, and Windows requirements . . . . . . . . . . . . . . 399
14.3 EKM and keystore considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
14.3.1 EKM configuration planning checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
14.3.2 Best security practices for working with keys and certificates. . . . . . . . . . . . . . 403
14.3.3 Acting on the advice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
14.3.4 Typical EKM implementations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
14.3.5 Multiple EKMs for redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
14.3.6 Using Virtual IP Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
14.3.7 Key manager backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
14.3.8 FIPS 140-2 certification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
14.4 Other EKM considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
14.4.1 EKM Release 1 to EKM Release 2 migration . . . . . . . . . . . . . . . . . . . . . . . . . . 410
14.4.2 Data exchange with business partners or other platforms . . . . . . . . . . . . . . . . 410
14.4.3 Disaster recovery considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
14.4.4 i5/OS disaster recovery considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
14.4.5 EKM performance considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Chapter 15. Implementing the Encryption Key Manager. . . . . . . . . . . . . . . . . . . . . . . 413
15.1 Implementing EKM in z/OS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
15.1.1 z/OS UNIX System Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
15.1.2 Installing EKM in z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
15.1.3 Security products involved: RACF, Top Secret, and ACF2. . . . . . . . . . . . . . . . 417
15.1.4 Create a JCE4758RACFKS for EKM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
15.1.5 Setting up the EKM environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
15.1.6 Starting EKM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
15.1.7 Additional definitions of hardware keystores for z/OS. . . . . . . . . . . . . . . . . . . . 428
15.1.8 Virtual IP Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
15.1.9 EKM TCP/IP configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
15.2 Installing EKM on AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Contents ix
15.2.1 Install the IBM Software Developer Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
15.3 Installing EKM on a Microsoft Windows platform . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
15.3.1 EKM setup tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
15.3.2 Installing the IBM Software Developer Kit on Microsoft Windows. . . . . . . . . . . 438
15.3.3 Starting EKM on Microsoft Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
15.3.4 Configuring and starting EKM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
15.4 Installing EKM in i5/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
15.4.1 New installation of the Encryption Key Manager. . . . . . . . . . . . . . . . . . . . . . . . 450
15.4.2 Upgrading the Encryption Key Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
15.4.3 Configuring EKM for tape data encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
15.5 Implementing LTO4 and LTO5 encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
15.5.1 LTO4 EKM implementation checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
15.5.2 Download the latest EKM software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
15.5.3 Create a JCEKS keystore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
15.5.4 Off-site or business partner exchange with LTO4 compared to 3592. . . . . . . . 466
15.5.5 EKM Version 2 installation and customization on Microsoft Windows . . . . . . . 467
15.5.6 Starting EKM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
15.5.7 Starting EKM as a Microsoft Windows Service. . . . . . . . . . . . . . . . . . . . . . . . . 470
15.6 Implementing LTO4 and LTO5 Library-Managed Encryption . . . . . . . . . . . . . . . . . . 472
15.6.1 Barcode Encryption Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
15.6.2 Specifying a Barcode Encryption Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
15.6.3 TS3500 Library-Managed Encryption differences from TS3310, TS3200, TS3100,
and TS2900 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
15.7 LTO4 or LTO5 System-Managed Encryption implementation. . . . . . . . . . . . . . . . . . 480
15.7.1 LTO4 SME implementation checklist for Windows . . . . . . . . . . . . . . . . . . . . . . 480
Chapter 16. Planning and managing your keys with Encryption Key Manager . . . . 481
16.1 Keystore and SAF Digital Certificates (keyrings) . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
16.2 JCEKS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
16.2.1 Examples of managing public-private key pairs . . . . . . . . . . . . . . . . . . . . . . . . 483
16.2.2 Managing symmetric keys in a JCEKS keystore. . . . . . . . . . . . . . . . . . . . . . . . 486
16.2.3 Example using iKeyman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
16.3 JCE4758KS and JCECCAKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
16.3.1 Script notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
16.3.2 Symmetric keys in a JCECCAKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
16.4 JCERACFKS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
16.5 JCE4758RACFKS and JCECCARACFKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
16.5.1 RACDCERT keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
16.5.2 Best practice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
16.6 PKCS#11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
16.7 IBMi5OSKeyStore. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
16.7.1 Digital Certificate Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
16.7.2 Setting up an IBMi5OSKeyStore. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
16.8 ShowPrivateTool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
16.9 MatchKeys tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
16.10 Hardware cryptography. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527
Chapter 17. Encryption Key Manager operational considerations. . . . . . . . . . . . . . . 531
17.1 EKM commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
17.1.1 The EKM sync command and EKM properties file . . . . . . . . . . . . . . . . . . . . . . 532
17.1.2 EKM command-line interface and command set . . . . . . . . . . . . . . . . . . . . . . . 533
17.2 Backup procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538
17.2.1 EKM file system backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538
x IBM System Storage Data Encryption
17.2.2 Identifying DFSMShsm to z/OS UNIX System Services. . . . . . . . . . . . . . . . . . 540
17.2.3 Keystore backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
17.2.4 RACF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
17.3 ICSF disaster recovery procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
17.3.1 Key recovery checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
17.3.2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
17.3.3 Pre-key change: All LPARs in the sysplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
17.3.4 Check the ICSF installation options data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546
17.3.5 Disable all services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
17.3.6 Entering master keys for all LPARs in the sysplex . . . . . . . . . . . . . . . . . . . . . . 548
17.3.7 Post-key change for all LPARs in the sysplex. . . . . . . . . . . . . . . . . . . . . . . . . . 553
17.3.8 Exiting disaster recovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554
17.4 Business partner tape-sharing example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554
17.4.1 Key-sharing steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554
17.4.2 Exporting a public key and certificate to a business partner . . . . . . . . . . . . . . . 555
17.4.3 Exporting a symmetric key from a JCEKS keystore . . . . . . . . . . . . . . . . . . . . . 559
17.4.4 Importing a public key and a certificate from a business partner . . . . . . . . . . . 559
17.4.5 Tape exchange and verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561
17.4.6 Importing symmetric keys to a JCEKS keystore . . . . . . . . . . . . . . . . . . . . . . . . 563
17.5 RACF export tool for z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
17.6 Audit log considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564
17.6.1 Audit overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565
17.6.2 Audit log parsing tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565
Chapter 18. Implementing TS1100 series encryption in System z . . . . . . . . . . . . . . . 571
18.1 Implementation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
18.2 Implementation prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
18.2.1 Implementing the initial tape library hardware. . . . . . . . . . . . . . . . . . . . . . . . . . 573
18.2.2 Initial z/OS software definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
18.3 EKM implementation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575
18.4 Implementing the tape library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576
18.4.1 Implementation steps for the IBM TS3500 Tape Library. . . . . . . . . . . . . . . . . . 576
18.4.2 Implementation steps for the IBM 3494 Tape Library . . . . . . . . . . . . . . . . . . . . 579
18.4.3 Implementation steps for the IBM TS3400 Tape Library. . . . . . . . . . . . . . . . . . 583
18.5 Implementing the tape control unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
18.6 z/OS implementation steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
18.6.1 z/OS software maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
18.6.2 Update PARMLIB member IECIOSxx. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
18.6.3 Define or update Data Class definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
18.6.4 Considerations for JES3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
18.6.5 Tape management system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
18.6.6 DFSMSrmm support for tape data encryption. . . . . . . . . . . . . . . . . . . . . . . . . . 592
18.6.7 DFSMSdfp access method service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
18.6.8 Data Facility Data Set Services considerations . . . . . . . . . . . . . . . . . . . . . . . . 597
18.6.9 DFSMS Hierarchal Storage Manager considerations . . . . . . . . . . . . . . . . . . . . 598
18.7 z/VM implementation steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
18.7.1 Tape library and tape control unit implementation . . . . . . . . . . . . . . . . . . . . . . 600
18.7.2 Out-of-band encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
18.7.3 Defining key aliases to z/VM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
18.7.4 Using ATTACH and DETACH to control encryption . . . . . . . . . . . . . . . . . . . . . 605
18.7.5 Using SET RDEVICE to control encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
18.7.6 QUERY responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
18.7.7 z/VM DASD Dump Restore (DDR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607
Contents xi
18.8 Miscellaneous implementation considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607
18.8.1 Data exchange with other data centers or business partners. . . . . . . . . . . . . . 607
18.8.2 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608
18.9 TS1120 and TS1130 tape cartridge rekeying in z/OS. . . . . . . . . . . . . . . . . . . . . . . . 608
18.9.1 TS1120 Model E05 rekeying support in z/OS. . . . . . . . . . . . . . . . . . . . . . . . . . 608
18.9.2 IEHINITT enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
18.9.3 Security considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612
18.9.4 Packaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612
18.9.5 Rekeying exits and messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612
Chapter 19. Implementing TS7700 tape encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . 613
19.1 TS7700 encryption overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
19.2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
19.2.1 Tape drives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
19.2.2 TS7700 Virtualization Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
19.2.3 Library Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
19.2.4 Encryption Key Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
19.3 Implementation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
19.3.1 Implementing the initial tape library hardware. . . . . . . . . . . . . . . . . . . . . . . . . . 616
19.3.2 Implementing the initial TS7700 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
19.3.3 Initial z/OS software definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
19.3.4 EKM implementation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
19.4 Tape library implementation and setup for encryption . . . . . . . . . . . . . . . . . . . . . . . 617
19.4.1 Enabling drives for encryption in the IBM TS3500 Tape Library. . . . . . . . . . . . 618
19.4.2 Enabling drives for encryption in the IBM 3494 Tape Library . . . . . . . . . . . . . . 620
19.4.3 Encryption-enabled drives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
19.5 Software implementation steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
19.5.1 z/OS software maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
19.5.2 Encryption Key Manager installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
19.5.3 z/OS DFSMS implementation steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
19.6 TS7700 implementation steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624
19.6.1 Configuring the TS7700 for encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624
19.6.2 Creating TS7700 storage groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
19.6.3 Creating TS7700 management classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
19.6.4 Activate the TS7700 Encryption Feature License. . . . . . . . . . . . . . . . . . . . . . . 629
19.6.5 EKM addresses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
19.6.6 Testing EKM connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632
19.6.7 Configuring pool encryption settings for the TS7700 . . . . . . . . . . . . . . . . . . . . 632
19.7 Implementation considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634
19.7.1 Management construct definitions and transfer . . . . . . . . . . . . . . . . . . . . . . . . 634
19.7.2 Changing storage pool encryption settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . 634
19.7.3 Moving data to encrypted storage pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635
19.7.4 EKM operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
19.7.5 Tracking encryption usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638
19.7.6 Data exchange with other data centers or business partners. . . . . . . . . . . . . . 638
19.8 TS7700 encryption with z/VM, z/VSE, or z/TPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638
Chapter 20. Implementing TS1120 and TS1130 encryption in an open systems
environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
20.1 Encryption overview in an open systems environment . . . . . . . . . . . . . . . . . . . . . . . 642
20.2 Adding drives to a logical library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643
20.2.1 Advanced Library Management System considerations. . . . . . . . . . . . . . . . . . 643
20.3 Managing the encryption and business partner exchange . . . . . . . . . . . . . . . . . . . . 644
xii IBM System Storage Data Encryption
20.3.2 Keeping track of key usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
20.4 Encryption implementation checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
20.4.1 Planning your EKM environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
20.4.2 EKM setup tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
20.4.3 Application-Managed Encryption setup tasks . . . . . . . . . . . . . . . . . . . . . . . . . . 649
20.4.4 System-Managed (Atape) Encryption setup tasks . . . . . . . . . . . . . . . . . . . . . . 650
20.4.5 Library-Managed Encryption setup tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651
20.5 Implementing Library-Managed Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651
20.5.1 LME implementation tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651
20.5.2 Upgrading firmware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
20.5.3 Add EKM or Tivoli Key Lifecycle Manager IP addresses . . . . . . . . . . . . . . . . . 658
20.5.4 Enabling Library-Managed Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659
20.5.5 Barcode Encryption Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662
20.6 Implementing System-Managed Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668
20.6.1 System-Managed Encryption tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
20.6.2 Atape device driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670
20.6.3 Update Atape EKM proxy configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670
20.6.4 System-Managed Encryption Atape device entries . . . . . . . . . . . . . . . . . . . . . 672
20.6.5 Updating the Atape device driver configuration . . . . . . . . . . . . . . . . . . . . . . . . 673
20.6.6 Enabling System-Managed Encryption using the TS3500 web GUI. . . . . . . . . 674
20.6.7 Using SMIT to enable System-Managed Encryption . . . . . . . . . . . . . . . . . . . . 676
20.6.8 Managing System-Managed Encryption and business partner exchange . . . . 683
20.7 Application-Managed Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
20.7.1 IBM Tivoli Storage Manager overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
20.7.2 IBM Tivoli Storage Manager support for 3592 drive encryption . . . . . . . . . . . . 687
20.7.3 Implementing Application-Managed Encryption . . . . . . . . . . . . . . . . . . . . . . . . 688
20.7.4 IBM Tivoli Storage Manager encryption considerations . . . . . . . . . . . . . . . . . . 691
20.8 IBM 3494 with TS1120 or TS1130 encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
20.8.1 Review the 3494 encryption-capable drives . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
20.8.2 Specifying a Barcode Encryption Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696
20.8.3 Entering the EKM IP address and key labels . . . . . . . . . . . . . . . . . . . . . . . . . . 698
20.8.4 ILEP key label mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
Chapter 21. Tape data encryption with i5/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701
21.1 Planning for tape data encryption with i5/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702
21.1.1 Hardware prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702
21.1.2 Software prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703
21.1.4 EKM keystore considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
21.1.5 TS1120 Tape Encryption policy considerations . . . . . . . . . . . . . . . . . . . . . . . . 706
21.1.6 Considerations for sharing tapes with partners. . . . . . . . . . . . . . . . . . . . . . . . . 707
21.1.7 Steps for implementing tape encryption with i5/OS . . . . . . . . . . . . . . . . . . . . . 709
21.2 Setup and usage of tape data encryption with i5/OS . . . . . . . . . . . . . . . . . . . . . . . . 709
21.2.1 Creating an EKM keystore and certificate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710
21.2.2 Configuring the TS3500 library for Library-Managed Encryption . . . . . . . . . . . 722
21.2.3 Importing and exporting encryption keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732
21.2.4 Working with encrypted tape cartridges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744
21.2.5 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749
Part 4. DS8000 encryption features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
Chapter 22. IBM System Storage DS8000 encryption preparation. . . . . . . . . . . . . . . 753
22.1 Encryption-capable DS8000 ordering and configuration. . . . . . . . . . . . . . . . . . . . . . 754
22.2 Requirements for encrypting storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755
Contents xiii
22.3 Tivoli Key Lifecycle Manager configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756
22.3.1 Log in to Tivoli Integrated Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756
22.3.2 Creating an image certificate or certificate request. . . . . . . . . . . . . . . . . . . . . . 757
22.3.3 Configure the SFIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761
22.3.4 Starting and stopping the Tivoli Key Lifecycle Manager server and determining its
status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
22.4 Configuring the Tivoli Key Lifecycle Manager server connections to the DS8000 . . 767
Chapter 23. DS8000 encryption features and implementation . . . . . . . . . . . . . . . . . . 771
23.1 DS8100/DS8300 (R4.2) GUI configuration for encryption . . . . . . . . . . . . . . . . . . . . 772
23.1.1 Configuring the encryption group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772
23.1.2 Applying the encryption activation key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
23.1.3 Configuring and administering encrypted arrays. . . . . . . . . . . . . . . . . . . . . . . . 776
23.1.4 Configuring and administering encrypted ranks . . . . . . . . . . . . . . . . . . . . . . . . 780
23.1.5 Configuring and administering encrypted extent pools . . . . . . . . . . . . . . . . . . . 783
23.2 DS8700 (R5.0) GUI configuration for encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . 788
23.2.1 Configuring the recovery key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788
23.2.2 Configuring the encryption group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792
23.2.3 Applying the encryption activation key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794
23.2.4 Configuring and administering encrypted arrays. . . . . . . . . . . . . . . . . . . . . . . . 796
23.2.5 Configuring and administering encrypted ranks . . . . . . . . . . . . . . . . . . . . . . . . 798
23.2.6 Configuring and administering encrypted extent pools . . . . . . . . . . . . . . . . . . . 801
23.3 DS8000 DS CLI configuration for encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804
23.3.1 Configuring the Tivoli Key Lifecycle Manager server connection . . . . . . . . . . . 804
23.3.2 Configuring and administering the encryption group. . . . . . . . . . . . . . . . . . . . . 806
23.3.3 Applying encryption activation key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807
23.3.4 Creating encrypted arrays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807
23.3.5 Creating encrypted ranks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 808
23.3.6 Creating encrypted extent pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809
23.4 Encryption and Copy Services functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810
Chapter 24. DS8700 advanced encryption features and implementation . . . . . . . . . 811
24.1 New security roles: Storage and security administrator . . . . . . . . . . . . . . . . . . . . . . 812
24.2 Recovery key support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814
24.2.1 Configuring the recovery key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814
24.2.2 Validating the recovery key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818
24.2.3 Initiating recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820
24.2.4 Using the process to rekey the recovery key . . . . . . . . . . . . . . . . . . . . . . . . . . 826
24.2.5 Deleting the recovery key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 830
24.2.6 Recovery key state summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
24.3 Dual platform key server support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
24.3.1 Setting up Tivoli Key Lifecycle Manager server . . . . . . . . . . . . . . . . . . . . . . . . 833
Chapter 25. Best practices and guidelines for DS8000 encryption . . . . . . . . . . . . . . 845
25.1 Best practices for encrypting storage environments . . . . . . . . . . . . . . . . . . . . . . . . . 846
25.1.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846
25.1.2 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846
25.1.3 Encryption deadlock prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847
25.2 Dual Hardware Management Console and redundancy . . . . . . . . . . . . . . . . . . . . . . 850
25.2.1 Dual Hardware Management Console advantages . . . . . . . . . . . . . . . . . . . . . 850
25.2.2 Redundant HMC configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 850
25.3 Multiple Tivoli Key Lifecycle Managers for redundancy . . . . . . . . . . . . . . . . . . . . . . 852
xiv IBM System Storage Data Encryption
25.4 Backup and restore the Tivoli Key Lifecycle Manager servers . . . . . . . . . . . . . . . . . 853
25.4.1 Categories of data in a backup file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854
25.4.2 Backup file security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854
25.4.3 IBM Tivoli Storage Manager as a backup repository . . . . . . . . . . . . . . . . . . . . 854
25.4.4 Backup and restore runtime requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854
25.4.5 Backing up critical files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855
25.4.6 Restoring a backup file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856
25.4.7 Deleting a backup file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858
25.5 Key exporting and importing tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858
25.5.1 Exporting keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859
25.5.2 Importing keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859
Appendix A. z/OS planning and implementation checklists. . . . . . . . . . . . . . . . . . . . 863
DFSMS Systems Managed Tape planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864
DFSMS planning and the z/OS encryption planning checklist . . . . . . . . . . . . . . . . . . . 864
Storage administrator stand-alone environment planning. . . . . . . . . . . . . . . . . . . . . . . 865
Storage administrator tape library environment planning . . . . . . . . . . . . . . . . . . . . . . . 866
DFSMS Systems Managed Tape implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867
Object access method planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869
Storage administrator OAM planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869
OAM implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 870
DFSMShsm tape environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 871
Appendix B. DS8700 encryption-related system reference codes. . . . . . . . . . . . . . . 873
Appendix C. z/OS Java and Open Edition tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877
JZOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878
Console communication with batch jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878
Encryption Key Manager and JZOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879
MVS Open Edition tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
Exporting a variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
Setting up an alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
Copying the escape character . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
Advantages of VT100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884
Advanced security hwkeytool and keytool scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885
Complete keytool example for JCEKS using hidden passwords . . . . . . . . . . . . . . . . . 885
Complete hwkeytool example for JCE4758KS using hidden passwords . . . . . . . . . . . 887
Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889
Security and providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889
Garbage Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890
Verifying the installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 891
z/OS region size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 891
Policy files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 891
Appendix D. Asymmetric and Symmetric Master Key change procedures. . . . . . . . 893
Asymmetric Master Key change ceremony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894
Testing encryption and decryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894
Pre-key change: Disabling PKA services for all images in the sysplex. . . . . . . . . . . . . 894
Key change: First LPAR in the sysplex. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896
Key change: Subsequent LPARs in the sysplex. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 902
Post-key change: All LPARs in the sysplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906
ICSF tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
Creating a PKDS VSAM data set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
Contents xv
Symmetric Master Key change ceremony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912
Testing the encryption and decryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912
Disabling dynamic CKDS updates for all images in the sysplex. . . . . . . . . . . . . . . . . . 912
Key change: First LPAR in the sysplex. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
Reenciphering the CKDS under the new SYM-MK. . . . . . . . . . . . . . . . . . . . . . . . . . . . 919
Changing the new SYM-MK and activating the re-enciphered CKDS . . . . . . . . . . . . . 921
Key change: Subsequent LPARs in the sysplex. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 922
Post-key change: All LPARs in the sysplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925
Appendix E. z/OS tape data encryption diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . 931
EKM problem determination when running z/OS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 932
Error scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 932
Diagnostic scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935
Encryption Key Manager error codes and recovery actions. . . . . . . . . . . . . . . . . . . . . . . . 938
Drive error codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 940
Control unit error codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 941
IOS628E message indicates connection failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 942
Appendix F. IEHINITT exits and messages for rekeying . . . . . . . . . . . . . . . . . . . . . . . 943
Dynamic Exits Service Facility support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 944
Error conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 944
Programming considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945
REKEY messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945
New messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946
Modified messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946
Appendix G. Implementing EKM on z/OS SECURE key processing to TS1100 and
LTO4/LTO5 drives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 949
Implementing EKM in z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 950
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 950
z/OS UNIX System Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 950
Installing the Encryption Key Manager in z/OS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 951
Create a JCECCAKS for EKM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 953
Setting up the EKM environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954
Starting EKM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 957
Configuring EKM TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 962
Enterprise-wide key management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964
Appendix H. Encryption testing in an open systems environment . . . . . . . . . . . . . . 965
Encryption key path test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966
Using key path diagnostics in an LME environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 966
Key Path Diagnostic test in a SME environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 969
Testing data encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 973
IBM Tape Diagnostic Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 973
Encryption Verification test using the ITDT-GE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 973
Encryption verification using the ITDT-SE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 978
Encryption test using the device driver functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985
IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985
Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987
xvi IBM System Storage Data Encryption
How to get IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 991
Copyright IBM Corp. 2010. All rights reserved. xvii
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 websites are provided for convenience only and do not in any
manner serve as an endorsement of those websites. The materials at those websites are not part of the
materials for this IBM product and use of those websites 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.
The following company name appearing in this publication is fictitious:
ZABYXC
This name is used for instructional purposes only.
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.
xviii IBM System Storage Data Encryption
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
AIX
alphaWorks
AS/400
CICS
DB2
developerWorks
DS8000
ESCON
FICON
FlashCopy
i5/OS
IBM
iSeries
Language Environment
Lotus
MVS
Netfinity
OS/400
Parallel Sysplex
pSeries
RACF
Redbooks
Redbooks (logo)
RS/6000
System i5
System i
System p
System Storage DS
System Storage
System x
System z9
System z
Tivoli
TotalStorage
VTAM
WebSphere
xSeries
z/OS
z/VM
z/VSE
z9
zSeries
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.
VMware, the VMware "boxes" logo and design are registered trademarks or trademarks of VMware, Inc. in the
United States and/or other jurisdictions.
Java, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other
countries, or both.
Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States,
other countries, or both.
Microsoft product screen shot(s) reprinted with permission from Microsoft Corporation.
Intel Xeon, 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 and other countries.
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.
Copyright IBM Corp. 2010. All rights reserved. xix
Preface
Strong security is not a luxury anymore in todays round-the-clock, global business
environment. It is a requirement. Ensuring the protection and security of an organizations
information is the foundation of any successful business.
Encrypting data is a key element when addressing these concerns. IBM provides a wide
range of IBM storage hardware products that are capable of encrypting the data that is written
on them. This product line includes a variety of disk systems and tape drives. Several IBM
storage products support encryption:
Disk systems:
IBM System Storage DS5000 series
Tape drives:
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
This IBM Redbooks publication describes IBM System Storage data encryption. This book
is intended for anyone who needs to learn more about the concepts of data encryption and
the IBM storage hardware and software that enable data encryption.
The team who wrote this book
This book was produced by a team of specialists from around the world working at the
International Technical Support Organization, Austin Center.
Alex Osuna is a Project Leader at the International Technical Support Organization, Tucson
Center. He writes extensively and teaches IBM classes worldwide on all areas of storage.
Before joining the ITSO five years ago, Alex was a Tivoli Principal Systems Engineer in
storage. Alex has over 31 years experience in the IT industry with over 29 of them spent in the
storage arena. He holds certification from IBM, Red Hat, and Microsoft.
David Crowther has over 30 years experience in the IT industry, the last 24 working for IBM.
During his IBM career, he has worked in Technical Pre-sales, Services and Support, and
currently works in IBM BetaWorks where he manages early beta programs for Tivoli Security
and Provisioning products. In addition, he creates and runs enablement workshops, authors
technical cookbooks and manuals, and provides technical support, presents, and acts as a
subject matter expert for the new products. He also has wide experience in running beta
programs on and supporting products from many of the other IBM brands, including Large
Systems, Networking, Pervasive, Lotus, Voice, and WebSphere. He is a Consulting IT
Specialist, Chartered IT Professional, and Chartered Engineer, and he holds a Masters
degree in Electrical Sciences from Cambridge University.
xx IBM System Storage Data Encryption
Reimar Pflieger is an IT Specialist from Germany working at the IBM Global Technology
Services Organization. He provides post-sales support as a Product Field Engineer for RMSS
products in Mainz. He joined IBM in 1998 and worked for many years as a Process Support
and Manufacturing Engineer in Disk and Wafer Production. In his current job role as an RMSS
Product Field Engineer, he supports Open Systems Tape, Tape Libraries from entry level to
high-end level and Tape Encryption solutions. His experience with Operating Systems
includes Linux, Windows and AIX platforms.
Esha Seth is a Software Engineer working at the IBM Systems and Technology Labs in
Pune, India. She graduated in 2006 with a Bachelor of Engineering degree in Computer
Science from Pune University. She joined IBM after graduation and has worked as a Systems
Software developer for the Systems and Storage Management group. During her tenure at
IBM, she has contributed to all phases of the software development life cycle and
collaborated with global teams in various projects for the IBM Systems Director product. Her
areas of technical expertise include understanding storage and systems Management, IBM
Systems Management solutions, service-oriented architecture (SOA), JAVA and Eclipse and
OSGi plug-in development. Currently, she is a part of the IBM Systems Director Network
Manager team and is involved in its development efforts.
Ferenc Toth is a Test Engineer working for DS8000 Storage Server manufacturing in Vac,
Hungary. He has four years of experience in high-end disk subsystem testing, test process
optimization, and new product implementation. He holds a Masters of Science degree in
Electrical Engineering, with a specialization in embedded systems, from the Budapest
University of Technology and Economics, Hungary. His focus is hardware and software
qualification for all the supported DS8000 releases in the manufacturing environment.
Thanks to the following people for their contributions to this project:
David Kahler
IBM Systems & Technology Group, Systems Hardware Development
Steven R. Hart, CISSP
z/OS Cryptography
Anjul Mathur
IBM Tucson
Jacob Sheppard
IBM Tucson
James Whelan
IBM Systems & Technology Group, Development Operations and Technical Support
Now you can become a published author, too!
Heres an opportunity to spotlight your skills, grow your career, and become a published
author - all at the same time! Join an ITSO residency project and help write a book in your
area of expertise, while honing your experience using leading-edge technologies. Your efforts
will help to increase product acceptance and customer satisfaction, as you expand your
network of technical contacts and relationships. Residencies run from two to six weeks in
length, and you can participate either in person or as a remote resident working from your
home base.
Preface xxi
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 publications in one of the following ways:
Use the online Contact us review Redbooks form found at:
ibm.com/redbooks
Send your comments in an email 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
Stay connected to IBM Redbooks
Find us on Facebook:
http://www.facebook.com/IBMRedbooks
Follow us on twitter:
http://twitter.com/ibmredbooks
Look for us on LinkedIn:
http://www.linkedin.com/groups?home=&gid=2130806
Explore new Redbooks publications, residencies, and workshops with the IBM Redbooks
weekly newsletter:
https://www.redbooks.ibm.com/Redbooks.nsf/subscribe?OpenForm
Stay current on recent Redbooks publications with RSS Feeds:
http://www.redbooks.ibm.com/rss.html
xxii IBM System Storage Data Encryption
Copyright IBM Corp. 2010. All rights reserved. 1
Part 1 Introduction to data
encryption
In this part, we introduce the concepts of data encryption and the IBM storage hardware and
software that enable data encryption.
Part 1
2 IBM System Storage Data Encryption
Chapter 1. Encryption concepts and
terminology
In this chapter, we introduce data encryption concepts and terminology.
1
1.1 Concepts of storage data encryption
In this section, we describe 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 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 separate keys for encryption and
decryption. The keys are mathematically related, but deriving one key from the other key is
practically impossible. Encryption methods using separate 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, which we describe in detail in the
following sections about symmetric and asymmetric key encryption.
The IBM Storage 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 Transport Layer Security (TLS), Internet
Protocol Security (IPSec), and Kerberos.
1.1.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-1 on page 5, 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.
Chapter 1. Encryption concepts and terminology 5
Figure 1-1 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 differ significantly. While a symmetric AES encryption might use a 128-bit secret
key, 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 and disk 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 symmetric
encryption has two drawbacks, which are the way that keys are exchanged and the number of
required keys.
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 a 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
Symmetric Key
AES_256_ITSO
Algorithm
AES
Encrypted Data
Symmetric Key
AES_256_ITSO
Decryption Process Decryption Process
Encryption Process
Plain Text
Encrypted Data Plain Text
Algorithm
AES
fast with the number of people in the group. The number of required keys 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:
k
n
=n(n-1)/2
As you can see in Figure 1-2, the number of required keys grows extremely fast. For a group
of 100 people, 4,950 separate keys are required. A group of 1,000 people requires 499,500
keys. Key distribution and key management are challenges.
Figure 1-2 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 algorithm supports.
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.1.2 Asymmetric key encryption
The 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 that is 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
Rijndael algorithm: The Rijndael algorithm supports block sizes of 128, 160, 192, 224,
and 256 bits. It supports key sizes of 128, 160, 192, 224, and 256 bits.
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 separate
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 the
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), and ElGamal.
Today, the Rivest-Shamir-Adleman (RSA) algorithm is the most widely used public key
technique.
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.1.3, Hybrid encryption on page 9.
Digital signature
You can use public/private key pairs to protect the content of a message, and also to digitally
sign a message. When a digitally signed message is sent, the receiver can be sure that the
sender has sent it, because the receiver can prove it by using the public key from the sender.
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.
For example, if Tony wants to send JoHann a digitally signed message, Tony will not use
JoHanns public key to encrypt the message, but Tonys own private key. The content of the
encrypted message is not protected, because anyone can decrypt the message by using
Tonys public key. But, if JoHann is able to decrypt Tonys message with Tonys public key,
JoHann can be sure that Tony sent the message. JoHann has proof that the message was
encrypted with Tonys private key, and JoHann knows that only Tony has access to this key.
In the previous example, JoHann has to make sure that Tonys public key really belongs to
Tony, and not to someone pretending to be Tony. If JoHann cannot confirm that it is really
Tonys public key, JoHann will need a trusted third party to verify Tonys 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 describe certificates in detail in 1.1.4, Digital certificates on page 9.
Trapdoor functions: RSA uses trapdoor functions. Trapdoor functions are mathematical
functions that are easy to compute in one direction, but they 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.
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-3 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.
Figure 1-3 Public-private key encryption
In Figure 1-4 on page 9, 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 Tonys public key. Tony sends JoHann a message that is encrypted with Tonys private key.
JoHann then uses the public key to decrypt the message. When the message is decrypted to
clear text, this decryption 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.
Asymmetric
Public Key
Plain Text
Public/Private Key Encryption
Algorithm
RSA
Encrypted
Data
Asymmetric
Private Key
Algorithm
AES
Encrypted
Data
Decryption Process
Algorithm
RSA
Plain Text
Figure 1-4 Identity verification using public-private key encryption
Both asymmetric and symmetric key encryption schemes are powerful ways to protect and
secure data.
1.1.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 they 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.
1.1.4 Digital certificates
Another possibility is to make sure that the sender can trust the receiver by using a certificate,
which is signed by a certificate authority (CA). Digital certificates are a way to bind public key
information with an identity. The certificates are signed by a CA. If users trust the CA and can
verify the CAs signature, they can also verify that a certain public key does indeed belong to
the person or entity that is identified in the certificate.
Private Key
Message
Network
Encrypted
Public Key
Data
Encrypted
Private Key
Bob
Message
Data
Alice
Message
Data
Public Key
Digital certificates are thus a way to bind public key information with an identity. The following
information can be stored in a digital certificate:
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 describe the X.509 Public Key Infrastructure (PKI), certificate chains, the
certificate request, and certificate responses. X.509 is a well established and accepted
standard for certificate management.
In Figure 1-5 on page 11, we have an abstract simplified version of part of the process of a
self-signed certificate. It shows that both the issuer and the 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-5 on page 11 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 conditions are true:
Identity proof
Message integrity
Non-repudiation
Figure 1-5 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. Only the sender has the private key; therefore, 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-6 on page 12 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 JohannTonyArtRootCAs 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.
Figure 1-6 Certificate request
In Figure 1-7 on page 13, JohannTonyArtCA receives the certificate response from company
ZABYXC. JohannTonyArtCA then uses the private key from JohannTonyArtRootCA to
encrypt a copy of the certificate requests 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 companys 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
Root, CA
Public Key
JohannTonyArt
Root, CA
Issuer = JohannTonyArt
Subject = JohannTonyArt
Public Key
Private Key
Self Signed
Personal Cert
Subject =
ZABYXC
Issuer =
ZABYXC
Public Key
Private Key
Certificate
Request
Figure 1-7 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-8 on page 14 shows an extended certificate chain. To verify certificate validity in this
situation, the whole chain has to be in the certificate repository.
Third Party, CA
Cert. Repository
JohannTonyArt, CA
Company ZABYXC
Certs
JohannTonyArt
Root, CA
Pub Key
JohannTonyArt
Root, CA
Issuer = JohannTonyArt
Subject = JohannTonyArt
Public Key
Private Key
Certificate
Response
Company ZABXYC
Subject = ZABYXC
Issuer =
JohannTonyArt
Pub Key
Encrypted Public key
Company ZABYXC
Subject = ZABYXC
Issuer =
JohannTonyArt
Public Key
Encrypted Public key
Figure 1-8 Certificate chain
Secure Sockets Layer example
Figure 1-9 on page 15 shows a simple Secure Sockets Layer (SSL) handshake with
ClientAuthentication required. 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 clients 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.
Company ZABYXC
CA
Certificate Chain
JohannTonyArt Root CA
Company ZABYXC
Personal Cert
Public Key
Encrypted Public Key
Private Key
Public Key
Private Key
Public
Private Key
Figure 1-9 SSL handshake example using ClientAuth
1.2 IBM Key Management methods
Encryption, as we have seen, is dependent upon encryption keys. This section highlights the
challenges faced in keeping the keys secure and available at the same time.
Encryption challenges
As a result of the nature of, the security of, and accessibility to encryption, data that is
encrypted is dependent on the security of, and accessibility to, the decryption key that is
needed to decrypt the data. The disclosure of a decryption key to an unauthorized agent
(individual person or system component) creates a security exposure if that agent also has
access to the ciphertext that is generated with the associated encryption key. If all copies of
the decryption key are lost (whether intentionally or accidentally), no feasible way exists to
decrypt the associated ciphertext, and the data contained in the ciphertext is said to have
been cryptographically erased. If the only copies of certain data that exist are
cryptographically erased ciphertext, access to that data has been permanently lost for all
Network
Server
Hello
Server
Certificate
Certificate
Request
Server
Hello
Complete
Cipher
Suite
Finished
SSL Client
SSL Handshake with
Client Authentication
SSL Server
Client
Certificate
Key
Exchange
Cipher
Suite
Certificate
Verified
Certificate
Verified
Client
Hello
practical purposes. The security and accessibility characteristics of encrypted data create
considerations for you that do not exist with storage devices that do not encrypt data.
Encryption key material must be kept secure from disclosure or use by any agent that does
not have authority to it; at the same time, it must be accessible to any agent that has both the
authority and need to use it at the time of need.
Key security
To preserve the security of encryption keys, the implementation must ensure that no one
individual (system or person) has access to all the information required to determine the
encryption key.
For example, an implementation using only symmetric encryption might manage
encryption keys so that the data key (used to encrypt/decrypt data) is encrypted
(wrapped) with a wrapping key (used to encrypt/decrypt data keys). In order to decrypt
the data ciphertext in this case, the wrapping key is first used to decrypt (unwrap) the data
key ciphertext to obtain the data key in plaintext, which is then used to decrypt the data
ciphertext to obtain the data in plaintext. If one agent stores the wrapping key and a
second agent stores the encrypted data key, neither agent alone has sufficient information
to determine the plaintext data key. For the IBM Encrypting Storage implementations that
will be described subsequently, the agent that stores the wrapping keys will be referred to
as a key server and the agent that stores or has access to the encrypted data keys will be
referred to as a storage device.
This separation of secrets between multiple entities is important, because it becomes
increasingly difficult to compromise the integrity (security) of a set of entities as the
number of entities required increases.
Key availability
To preserve the access to encryption keys, many techniques can be used in an
implementation to ensure that more than one agent has access to any single piece of
information necessary to determine an encryption key.
For example, redundancy is provided by having multiple independent key servers that
have multiple independent communication paths to encrypting storage devices.
Additionally, backups of each key servers data are maintained. Failure of any one key
server or any one network does not prevent storage devices from obtaining access to data
keys required to provide access to data. Redundancy is also provided in the storage
device (or on the storage media) by keeping multiple copies of the encrypted data key.
The sensitivity of possessing and maintaining encryption keys, as well the complexity of
managing the number of encryption keys in a typical environment, results in a client
requirement for a key server. A key server is integrated with encrypting storage products to
resolve most of the security and usability issues associated with key management for
encrypted storage. However, you must still be sufficiently aware of how these products
interact in order to provide appropriate management of the computer environment. Even with
a key server, generally at least one encryption key (for example, the overall key that manages
access to all other encryption keys, a key that encrypts the data used by the key server, and
so forth) must be maintained manually.
1.3 Tivoli Key Lifecycle Manager and Encryption Key Manager
Let us now describe IBM Tivoli Key Lifecycle Manager and Encryption Key Manager, which
are both Java software programs that manage keys enterprise-wide and provide
encryption-enabled tape drives and full disk encryption (FDE) disk drives with keys for
encryption and decryption. Tivoli Key Lifecycle Manager is an IBM product that adds key
management functionality over the Encryption Key Manager.
We describe various methods of managing IBM storage 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 storage media communicates
with it.
One critical consideration with a key server implementation is that all code and data objects
required to make the key server operational must not be stored on storage that is dependent
on any key server to be accessed.
A situation where all key servers cannot become operational, because there is data or code
that cannot be accessed without an operational key server, is referred to as an encryption
deadlock. It is analogous to having a bank vault that is unlocked with a combination and the
only copy of the combination is locked inside the vault.
1.3.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 IBM Tivoli Storage Manager, or externally
by an Encryption Key Manager. In this section, we describe the Encryption Key Manager.
There are three methods of encryption management from which to choose. These methods
differ in where you choose to locate your Encryption Key Manager 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 1-10 on page 18.
Key management: IBM offers an enterprise-scale key management infrastructure through
IBM Tivoli Key Lifecycle Manager and life cycle management tools to help organizations
efficiently deploy, back up, restore, and delete keys and certificates in a secure and
consistent fashion.
Figure 1-10 Encryption Key Manager 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. Encryption Key Manager operates on a variety of operating systems. Currently,
the following operating systems are supported:
z/OS
i5/OS
AIX
Linux
Hewlett-Packard UNIX (HP-UX)
Sun Solaris
Windows
Encryption Key Manager 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 Encryption Key Manager at no charge on IBM operating systems. On
platforms that are not IBM platforms, IBM Tivoli Storage Productivity Center Basic Edition
must be purchased to gain access to the Encryption Key Manager. For IBM operating
systems, download the current version of the IBM Encryption Key Manager for the Java
platform, the IBM System Storage Tape Enterprise Key Manager, Introduction Planning and
User Guide, GA76-0418, and a sample configuration file for Encryption Key Manager. To
download, go to this website:
http://www.ibm.com/support/search.wss?rs=1139&tc=STCXRGL&dc=D400&dtm
1.3.2 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 Encryption Key Manager 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, Encryption Key Manager has to rely on external components. In the
following sections, we describe the components of Encryption Key Manager and resources
that are used by Encryption Key Manager.
Figure 1-11 shows the Encryption Key Manager components and external resources.
Figure 1-11 Encryption Key Manager components and resources
Tape drive table
The tape drive table is used by Encryption Key Manager to track the tape devices that it
supports. The tape drive table contains the list of the drives that can communicate with the
Encryption Key Manager. You can populate this list with additional drives by using the
Encryption Key Manager adddrive command, or you can set a variable in the configuration
file so that Encryption Key Manager 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 Linear Tape-Open (LTO) drives.
The tape drive table is a non-editable, binary file whose location is specified in the
configuration file. A number of Encryption Key Manager commands are available to add,
delete, modify, and view keys and certificates. You can change the location of the tape drive
table to meet your requirements.
Crypto services: In Figure 1-11, Crypto services can refer to either Java security
providers (software) or cryptographic hardware that is installed on the system.
Encryption
Key Manager
(EKM)
Config
File
Drive
Table
Keystore
Crypto Services
Configuration file
The configuration file is an editable file that tells your Encryption Key Manager how to
operate. Among other information, you specify the keystore location and the drive table
location in this file.
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
Encryption Key Manager to perform cryptographic operations. A keystore can be either
hardware-based or software-based.
Encryption Key Manager supports several types of Java keystores, offering a variety of
operational characteristics to meet your requirements:
JCEKS: Clear symmetric keys and clear asymmetric keys
JCE4758KS/JCECCAKS: Clear symmetric keys, clear asymmetric keys, secure
symmetric keys, and secure asymmetric keys
JCE4785RACFKS/JCECCARACFKS: Secure asymmetric keys
JCERACFKS: Clear asymmetric keys
PKCS11IMPLKS: Types of keys that are supported depend on the Public Key
Cryptographic Standards 11 (PKCS#11) implementation
IBMi5OSKeyStore: Clear asymmetric keys
Cryptographic services
Encryption Key Manager uses the IBM Java Security components for its cryptographic
capabilities. Encryption Key Manager does not provide cryptographic capabilities and
therefore does not require, nor is allowed to obtain, Federal Information Processing Standard
(FIPS) 140-2 certification. However, Encryption Key Manager 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. In the configuration
properties file, setting the FIPS configuration parameter to ON causes Encryption Key
Manager to use the IBMJCEFIPS provider for all cryptographic functions.
More information about the IBMJCEFIPS provider, its selection, and its use is at this website:
http://www.ibm.com/developerworks/java/jdk/security/50/FIPShowto.html
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 your tape drives have been added to the table. In a
business and continuity recovery site, however, such as Sunguard or IBM Business
Continuity and Resiliency Services, it is a requirement to accept unknown tape drives.
IBM LTO Ultrium 4 drives: Encryption on IBM LTO Ultrium 4 drives requires a keystore
that supports symmetric keys.
Important: Do not use hardware-based keystore types when the FIPS parameter is set ON.
1.3.3 Encryption keys
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 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 that is currently recognized and recommended by the U.S. Government,
and it allows three key lengths. The 256-bit keys are the longest keys allowed by AES.
The two types of encryption algorithms that can be used by Encryption Key Manager 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 used 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).
Encryption Key Manager 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.
Encryption Key Manager uses symmetric, 256-bit AES keys to encrypt user data. The keys
used to encrypt client data are referred to as data keys. Table 1-1 shows key usage by drive
type and management method.
Table 1-1 Key usage by drive type and management method
1.3.4 Tivoli Key Lifecycle Manager
The IBM approach to key management revolves around IBM Tivoli Key Lifecycle Manager, a
product announced in 2008 that will be enhanced in phases. From an initial focus on key
management for tape and disk encryption, IBM plans to expand Tivoli Key Lifecycle Manager
into a centralized key management facility for managing encryption across a range of
deployments.
Encryption management
method
Keys used by
TS1120 drive or TS1130
Keys used by LTO4 drive
System-Managed Encryption
or Library-Managed Encryption
using Encryption Key Manager
One randomly generated
unique data key
a
per cartridge
a. Data key is a symmetric AES 256-bit data key
One pre-generated data key
per cartridge
Application-Managed
Encryption (no Encryption Key
Manager)
unique data key per cartridge
One data key per cartridge
exist. All of these keys and certificates have to be managed and can be handled by Tivoli Key
Lifecycle Manager.
The Tivoli Key Lifecycle Manager product is an application that performs key management
tasks for IBM encryption-enabled hardware, such as the IBM System Storage DS8000 Series
family and the IBM encryption-enabled tape drives (TS1130 and TS1040). Tivoli Key Lifecycle
Manager provides, protects, stores, and maintains encryption keys that are used to encrypt
information being written to, and decrypt information being read from, an encryption-enabled
disk. Tivoli Key Lifecycle Manager operates on a variety of operating systems. Currently,
these operating systems are supported:
AIX 5.3 and AIX 6.1: 64-bit
Red Hat Enterprise Linux AS V4.0 x86: 32-bit
SUSE Linux Enterprise Server V9.0 and V10 x86: 32-bit
Sun Server Solaris 10 Sparc: 64-bit
Microsoft Windows Server 2003 R2: x86: 32-bit
z/OS V1 Release 9 or later
Fix Pack 1 added the additional platform support:
Red Hat Enterprise Linux 5 32-bit
Red Hat Enterprise Linux 5 64-bit (32-bit mode application)
Solaris 9 SPARC 64-bit
SUSE Linux Enterprise Server 10 64-bit (32-bit mode application)
Windows Server 2003 64-bit (32-bit mode application)
Windows Server 2008 32-bit
Windows Server 2008 64-bit (32-bit mode application)
Tivoli Key Lifecycle Manager is designed to be a shared resource deployed in several
locations within an enterprise. It is capable of serving numerous IBM encryption-enabled
hardware devices, regardless of where those devices reside.
1.3.5 Tivoli Key Lifecycle Manager components and resources
With the DS8000, Tivoli Key Lifecycle Manager serves keys to the encrypting disk drives.
Tivoli Key Lifecycle Manager does not perform any cryptographic operations, such as
generating encryption keys, and it does not provide storage for keys and certificates. In
addition to the key serving function, the Tivoli Key Lifecycle Manager also performs the
following functions, which can be used for IBM encryption-enabled tape and disk drives:
Life cycle functions:
Notification of certificate expiration through the Tivoli Integrated Portal
Automated rotation of certificates
Automated rotation of groups of keys
DS8000: For the DS8000, an isolated primary Tivoli Key Lifecycle Manager key server is
required and must be deployed on an IBM System x running SUSE Linux Enterprise
Server (SLES) 9.0 with storage that is not provisioned on the DS8000. Additionally,
secondary key servers can be deployed on any of the previously mentioned platforms.
Usability features:
Graphical user interface (GUI) provided
Initial configuration wizards
Migration wizards
Integrated backup and restore of Tivoli Key Lifecycle Manager files
Only one button required to create and restore a single backup, which is packaged as a
.jar file
To perform these tasks, Tivoli Key Lifecycle Manager relies on external components. The
Tivoli Key Lifecycle Manager solution includes the Tivoli Key Lifecycle Manager server, an
IBM embedded WebSphere Application Server, and a database server (IBM DB2).
The solution also incorporates the Tivoli Integrated Portal installation manager, which
provides simple to use installation for Windows, Linux, AIX, and Solaris.
In Tivoli Key Lifecycle Manager, the drive table, LTO key group, and metadata are all kept in
DB2 tables. The Tivoli Key Lifecycle Manager DB2 tables enable the user to search and query
that information more easily. Note that the keystore, configuration file, audit log, and debug
log are still flat files.
Tivoli Key Lifecycle Manager also relies on the following resources:
Configuration file
The Tivoli Key Lifecycle Manager has a an editable configuration file with additional
configuration parameters that are not offered in the GUI. The file can be text-edited;
however, the preferred method is modifying the file through the Tivoli Key Lifecycle
Manager command-line interface (CLI).
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 Tivoli Key Lifecycle Manager to perform cryptographic operations. A
keystore can be either hardware-based or software-based. Tivoli Key Lifecycle Manager
supports several types of Java keystores, offering a variety of operational characteristics to
meet your needs.
Tivoli Key Lifecycle Manager on open systems supports the JCEKS keystore. This
keystore supports both CLEAR key symmetric keys, and CLEAR key asymmetric keys.
Symmetric keys are used for LTO 4 encryption drives, and asymmetric keys are used for
DS8000 and TS1100 tape drives.
Tivoli Key Lifecycle Manager uses the IBM Java Security components for its cryptographic
capabilities. Tivoli Key Lifecycle Manager does not provide cryptographic capabilities and
therefore does not require, nor is allowed to obtain, FIPS 140-2 certification. However,
Tivoli Key Lifecycle Manager 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.
By setting the FIPS configuration parameter to ON in the configuration properties file
either through text editing or by using the Tivoli Key Lifecycle Manager CLI, you can make
Tivoli Key Lifecycle Manager use the IBMJCEFIPS provider for all cryptographic functions.
You can obtain more information about the IBMJCEFIPS provider, its selection, and its use
at the following website:
IBM Tivoli Key Lifecycle Manager is an IBM program product that implements a key server
application. IBM Tivoli Key Lifecycle Manager integrates with certain IBM storage products
and possibly other compatible products.
Figure 1-12 Tivoli Key Lifecycle Manager components
The Tivoli Key Lifecycle Manager program product can be installed on a set of servers to
implement a set of redundant key servers. Encrypting storage devices that require key
services from the key server are configured to communicate with one or more key servers.
The key servers are configured to define the devices with which they are allowed to
communicate.
Tivoli Key Lifecycle Manager supports two key serving methods. The method used by the IBM
System Storage DS8000 and the IBM TS1120 and TS1130 tape devices is referred to as the
wrapped key method. In the wrapped key method, the configuration processes on the Tivoli
Key Lifecycle Manager and storage device define one or more key labels. A key label is a text
string that is used to associate data keys with wrapping keys.
Important: Tivoli Key Lifecycle Manager 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.
In the wrapped key method, there are two functions that an encrypting storage device can
initiate to a Tivoli Key Lifecycle Manager key server:
Request a new data key
The storage device requests a new data key for a specified key label. The Tivoli Key
Lifecycle Manager key server provides a properly generated data key to the storage
device in two forms:
Externally encrypted data key (EEDK)
The Tivoli Key Lifecycle Manager maintains a public/private key pair for each key label
(the private key is only known to the Tivoli Key Lifecycle Manager). The data key is
wrapped with the key label public key and is stored in a structure referred to as the
externally encrypted data key. This structure also contains sufficient information to
determine the key label associated with the externally encrypted data key.
Session encrypted data key
The storage device generates a public/private key pair for communicating with the
Tivoli Key Lifecycle Manager and provides the public key to the Tivoli Key Lifecycle
Manager (the private key is only known to the storage device). The data key is wrapped
with the storage device public key and is stored in a structure referred to as the session
encrypted data key.
The externally encrypted data key is persistently stored by the storage device for future
use. The session encrypted data key is decrypted by the storage device using the
storage device private key so that it can use the data key to encrypt and decrypt data
or other subordinate data keys with a symmetric encryption algorithm.
Unwrap an existing data key
The storage device requests that Tivoli Key Lifecycle Manager unwrap an existing
wrapped data key, sending the externally encrypted data key and the storage device public
key. The Tivoli Key Lifecycle Manager key server receives the externally encrypted data
key, unwraps the data key with the key labels private key to obtain the data key, wraps the
data key with the storage device public key to create a session encrypted data key, and
returns a session encrypted data key to the storage device. The session encrypted data
key is decrypted by the storage device so that it can use the data key to encrypt and
decrypt data with a symmetric encryption algorithm.
The storage device does not maintain a persistent copy of the data key in the clear so that it is
unable to encrypt or decrypt data without access to Tivoli Key Lifecycle Manager. Separate
key life cycles are appropriate for separate storage. For instance, the externally encrypted
data key for a removable media device might be stored on the media when it is initially written
and the data key forgotten when the media is dismounted so that each time the media is
re-mounted, the storage device must communicate with Tivoli Key Lifecycle Manager to
obtain the data key. The externally encrypted data key for a non-removable storage device
might be stored as persistent metadata within the storage device and the data key forgotten
when it is powered off so that each time the product is powered on, it must communicate with
Tivoli Key Lifecycle Manager to obtain the data key. In all cases, access to data encrypted
with a data key requires access to both the externally encrypted data key and to a Tivoli Key
Lifecycle Manager that knows the key label private key needed to decrypt the externally
encrypted data key to obtain the data key.
Chapter 2. Introduction to storage data
encryption
Strong security is not a luxury anymore in todays round-the-clock, global business
environment. Ensuring the protection and security of an organizations information is the
foundation of any successful business.
Encrypting data is a key element when addressing these concerns. IBM provides a wide
range of IBM storage hardware products that are capable of encrypting the data that is written
on them. These products include a variety of disk systems and tape drives. The following IBM
storage products support encryption:
Disk systems:
Tape drives:
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
2
2.1 IBM tape drive encryption
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 licensed internal code additions and changes.
The IBM System Storage TS1120 Tape Drive Model E05, which is shown in Figure 2-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 2-1 IBM System Storage TS1120 Model E05 Tape Drive
The IBM System Storage LTO Ultrium Generation 4 Tape Drive, which is shown in
Figure 2-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 2-2 IBM System Storage LTO Ultrium Generation 4 Tape Drive
Chapter 2. Introduction to storage data encryption 29
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 component for the Java platform feature, which 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, IBM has made available the next
generation of key manager software to enable serving keys to the encrypting tape drives.
Tivoli Key Lifecycle Manager is intended to give a consistent look and feel for key
management tasks across the brand, while simplifying those same key management tasks.
Encryption Facility for z/OS software provides a complementary encryption method for
sharing tape data with business partners that utilize various 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 the TS1130 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.
2.2 IBM System Storage DS5000 series with encryption support
DS5000 series is an innovative self-encrypting disk solution for middle market clients that
helps prevent exposing sensitive data on drives that are returned for repair, retired, or
re-purposed with near zero effect on performance.
Full Disk Encryption (FDE) is an optional premium feature that prevents unauthorized access
to the data on a DS5000 drive that is physically removed from the storage array. It is
supported by the DS5000 firmware Version 7.60 and higher and Storage Manager 10.60 and
higher. FDE is a premium feature of the storage management software and must be enabled
either by you or your storage vendor. Figure 2-3 shows the DS5300 Storage Server with
EXP5000 expansion modules.
Figure 2-3 DS5300 Storage Server with EXP5000 expansion modules
The FDE premium feature requires security capable drives. A security capable drive encrypts
data during writes and decrypts data during reads. Each security capable drive has a unique
drive encryption key. Secure drives provide access to data only through a controller that has
the correct security key. When you create a secure array from security capable drives, the
drives in that array become security-enabled. When a security capable drive has been
security-enabled, the drive requires the correct security key from a controller to read or write
the data. All of the drives and controllers in a storage array share the same security key. The
shared security key provides read and write access to the drives, while the drive encryption
key on each drive is used to encrypt the data.
A security capable drive works like any other drive until it is security-enabled. Whenever the
power is turned off and turned on again, all of the security-enabled drives change to a
security locked state. In this state, the data is inaccessible until the correct security key is
provided by a controller.
You can view the FDE status of any drive in the storage array from the Drive Properties
dialog.
The status information reports the state of the drive:
Security capable
Secure: Security enabled or disabled
Read/write accessible: Security locked or unlocked
When the FDE premium feature has been enabled, the Secure Drives option is displayed in
the Volume Group menu. The Secure Drives option is active if these conditions are true:
The selected storage array is not security-enabled, but it consists entirely of security
capable drives.
The storage array contains no snapshot base volumes or snapshot repository volumes.
The volume group is in an optimal state.
A security key is set up for the storage array.
The Secure Drives option is inactive if the conditions are not true. The Secure Drives option is
inactive with a check mark to the left of it if the array is already security-enabled.
You can erase security-enabled drives so that you can reuse the drives in another array or in
another storage array. When you erase security-enabled drives, you make sure that the data
cannot be read. When all the drives that you have selected in the Physical pane are
security-enabled, and none of the selected drives is part of an array, the Secure Erase option
is displayed in the Drive menu.
2.3 DS8000 series with encryption support
The IBM DS8000 disk subsystem (see Figure 2-4 on page 32) supports data encryption with
the IBM FDE drive. Currently, these enterprise-class disks are available in 146 GB, 300 GB,
or
450 GB capacities and with 15K RPM speed. These drives contain encryption hardware and
can perform symmetric encryption and decryption of data at full disk speed with no effect on
performance.
Figure 2-4 DS8000 series
To use data encryption, you must order an IBM DS8000 from the factory with all FDE drives.
At this time, DS8000 does not support an intermix of FDE and non-FDE drives. An IBM
DS8000 with FDE disks is referred to as being encryption capable. Each storage facility
image on an encryption-capable DS8000 can be configured to either enable or disable
encryption for all data that is stored on a clients disks. In order to enable encryption, you must
configure the DS8000 to communicate with one Tivoli Key Lifecycle Manager key server (two
or more Tivoli Key Lifecycle Manager key servers are better from a redundancy point of view).
The physical connection between the DS8000 Hardware Management Console (HMC) and
the key server is through a TCP/IP network.
The IBM DS8000 supports data encryption with the help of FDE drives. Each IBM FDE drive
has an encryption key for the region of the disk that contains client data. When encryption is
enabled, the encryption key for the client data is wrapped with an access credential and
stored on the disk media. Read/write access to the data on the drive is blocked following a
power loss until the initiator accessing the drive authenticates with the currently active access
credential. In the case of the DS8000, a unique access credential for each drive in the storage
facility image is derived from one data key that it obtains from the Tivoli Key Lifecycle
Manager key server. The DS8000 stores multiple independent copies of the externally
encrypted data key (EEDK) persistently, and it must be able to communicate with a Tivoli Key
Lifecycle Manager server after a power on to allow access to the disks that have encryption
enabled. In the case where the DS8000 is configured to disable encryption, the FDE disks still
encrypt data with an encryption key, but the drive does not need an access credential to
encrypt or decrypt the data.
In the current implementation, client data is persistently stored in one of three places:
On client disks
Data on client disks (that is, disk drive modules (DDMs) installed via DDM Install Group
features) that are encryption enabled is managed through a data key obtained from the
Tivoli Key Lifecycle Manager key server. The data is encrypted with an encryption key that
is managed though an externally encrypted encryption key.
Nonvolatile storage (NVS) dump data on system disks
If a force power off sequence is initiated, write data in flight in the NVS memory is
encrypted with an encryption key and stored on the system disks in the DS8000 server.
The data is limited to at most 8 GBs. The encryption key is encrypted with a derived key
and stored on the system disk. This data is only obfuscated. The data on the system disk
is cryptographically erased when power is restored.
Auxiliary processor unit (APU) data on system disks
If a force power off sequence is initiated, atomic parity write data in flight in the device
adapter memory for RAID 6 arrays is encrypted with an encryption key and stored in a
flash on the device adapter card in the DS8000 server. The data is limited to at most 32
MB per device adapter or 512 MB per storage facility in a maximum configuration. The
encryption key is encrypted with a derived key and stored on the device adapter. This data
is only obfuscated. The data is cryptographically erased in the flash memory when power
is restored.
2.3.1 Encryption updates in DS8000 R5.0
There are two encryption updates included in DS8000 R5.0:
Recovery key
Dual platform key server support (see Figure 2-5).
Figure 2-5 Dual key server platform support
Force power off sequence: The power off requests issued through the DS GUI/CLI
interfaces or through the System z power control interfaces do not initiate a force
power off sequence. Activation of the Force Power Off service switch or loss of ac
power does initiate a force power off sequence.
These encryption updates (supported on R5.0) will only be available on DS8700 Models:
Recovery key
The recovery key can be used to unlock a DS8000 that cannot obtain a required data key
from a key server. It provides a new mechanism that can be used to break an encryption
deadlock. Using the recovery key requires that the client configure and escrow the
recovery key for future use (DS8000 does not have a copy of the recovery key).
R4.3 added new user roles:
Storage administrator (STGADM): Formerly known as Administrator
Security administrator (SECADM)
Recovery key user protocols use a dual control, which requires two people to complete
recovery key operation. The security administrator is the requester and holder of the
recovery key while the storage administrator is the approver of the recovery key request.
The recovery key is a 256-bit AES key that is displayed as 64 hex characters with dashes
every 4 characters.
Dual platform key server support
DS8000 requires an isolated key server (configured with a copy of Tivoli Key Lifecycle
Manager) in the configuration to avoid encryption deadlock. The isolated key server
currently is defined with the System x server. Clients using the secure key mode keystore
on separate platforms cannot integrate with isolated key servers, because they cannot
propagate keys across key server platforms in the secure key mode.
Dual platform key server support allows you to configure two separate key server
platforms with either platform operating in either clear key mode or secure key mode.
Now that you have a basic understanding of IBM storage data encryption techniques, we look
at encryption to answer several of the most important questions:
How does storage data encryption work?
What do we encrypt, and what do we not encrypt?
Why use data encryption?
What are the benefits for my organization?
2.4 Storage data encryption
This section gives an overview of the encryption technique that is used in IBM storage
devices, such as disk drives and tape drives.
2.4.1 Encryption of data on IBM tape drives
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 little, if at all.
To encrypt the data, the tape drive requires a key. This key is provided by the Encryption Key
Manager in an encrypted form to make the tape data encryption solution secure.
Figure 2-6 on page 35 summarizes the process for tape data encryption using TS1130 and
TS1120.
Figure 2-6 TS1120 and TS1130 tape data encryption process flow
Figure 2-7 summarizes the LTO4 tape data encryption process flow.
Figure 2-7 LTO4 tape data encryption process
2.4.2 Encryption of data in IBM System Storage DS5000 Series
The FDE disks have encryption hardware, and they can perform symmetric encryption and
decryption of data at full disk speed with no effect on performance. The disk encryption
hardware is used in conjunction with IBM disk encryption Storage Manager on the DS5000
storage system. It uses asymmetric encryption to encrypt and decrypt the data key. IBM disk
encryption Storage Manager will generate encryption and decryption keys that are used to
lock each FDE drive.
Encrypted Data Key
Encrypted Data Keys
Encryption
Key
Manager
2. Tape drive requests a data key
4.Encrypted keys
transmitted to tape drive
3. Key manager
generates key and
encrypts it
5. Tape drive writes encrypted
data and stores encrypted data
key on cartridge
1. Load cartridge, specify
encryption
Encrypted Data Key Encrypted Data Key
Encrypted Data Keys Encrypted Data Keys
Encryption
Key
Manager
4.Encrypted keys
3. Key manager
generates key and
encrypts it
5. Tape drive writes encrypted
data and stores encrypted data
key on cartridge
encryption
Encrypted Data Key
Encryption
Key
Manager
4.Encrypted data key
3. Key manager
retrieves key and
encrypts it for
transmission
5. Tape drive decrypts the data
key, writes encrypted data and
keyid on the cartridge
encryption
LTO 4 Encryption
Without these IBM disk encryption Storage Manager-managed keys, the user (authorized or
unauthorized) can no longer decrypt the data on disk.
Figure 2-8 shows the relationship of the IBM Disk Encryption Manager and the individual FDE
disk with encryption enabled.
Figure 2-8 DS5000 Disk Encryption Manager using self-encrypting FDE drives
With this relationship, the correct keys, and authentication, the FDE drive encrypts data
written to and decrypt data read from it, which is called self-encryption. The user does not
have the appropriate authorizations, and data cannot be read from or written to the drive
without authenticating with the DS5000 Disk Encryption Manager, which unlocks the drive.
Important: If these keys and all copies are lost, the encrypted data on the disk cannot be
decrypted and therefore must be considered lost.
%$#@|ociui.oko%
$#@i&&6544t899#@&$
User Data
Data on Drive
Writing to the Drive
Encryption Process
Data
Encryption
Key
The quick brown fox
jumps over the lazy dog
%$#@|ociui.oko%
$#@i&&6544t899#@&$
User Data
Data on Drive
Reading from the Drive
Decryption Process
Data
Encryption
Key
S
e
l
f
-
e
n
c
r
y
p
t
i
n
g

D
r
i
v
e
I
B
M

D
S
5
0
0
0

D
i
s
k

E
n
c
r
y
p
t
i
o
n

M
a
n
a
g
e
r
Data Flow
Authorization Flow
The quick brown fox
jumps over the lazy dog
Figure 2-9 Unauthorized access to the drive results in the data remaining encrypted
2.4.3 Encryption of data in IBM System Storage DS8000 Series
You can configure the DS8000 to communicate with one Tivoli Key Lifecycle Manager key
server; however, configuring it with at least two or more Tivoli Key Lifecycle Manager key
servers to enable encryption is better. Two Tivoli Key Lifecycle Manager key servers are
required for following reasons:
Two Tivoli Key Lifecycle Manager key servers provide redundancy.
Two Tivoli Key Lifecycle Manager key servers prevent encryption deadlock.
An encryption group cannot be configured until at least two key servers are configured.
The communication between the DS8000 and the Tivoli Key Lifecycle Manager key server is
done through the Hardware Management Console (HMC). Therefore, having two HMCs to
provide redundancy on the storage device side is important. The physical connection
between the DS8000 HMC and the key server is through a TCP/IP network.
.
Lost decryption key: If all copies of the decryption key are lost (whether intentionally or
accidentally), no feasible way exists to decrypt the associated ciphertext, and the data
contained in the ciphertext is said to have been cryptographically erased. The data is lost,
because it cannot be decrypted without the key.
Figure 2-10 Connection between DS8000 HMC and Tivoli Key Lifecycle Manager
Disk encryption details
Each FDE drive has an encryption key for the area of the drive that contains client data (Band
1 in Figure 2-11). As shown in Figure 2-11, Band 0 is for internal global data, which is also
encrypted.
Figure 2-11 Encrypted bands
The band master 1 access credentials are derived from a key served by the key server. At
that stage, the client data area is locked. After a disk power loss, the read/write access to the
data on a locked area is blocked until the DS8000 has authenticated by supplying the
currently active access credential (that it must get from the Tivoli Key Lifecycle Manager
server). When the client data area is unlocked, the FDE drive still encrypts/decrypts the data
with an encryption key, but the encryption/decryption occurs transparently to the initiator
(DS8000).
StoragePlex
Customer IP Network
Key Lifecycle Manager
Cryto-Services Key-Store
HMC
SFI Server SFI Server
Storage Facility Image
Storage Facility
HMC
StoragePlex
DSGUI / DS-CLI
primary and secondary
TKLM Servers
Dual HMCs
Recommended
DS8000
Storage Admin
TKLM GUI
Security / Storage
Admin
Customer
Data
Band 1
Band 0
An FDE drive that is made a member of an encryption-enabled rank is locked. The FDE drive
is unlocked when it is unassigned, a spare, or a member of an encryption-disabled rank.
Locking occurs when an FDE drive is added to an encryption-enabled rank either during rank
creation or sparing. Unlocking occurs when an encryption-enabled rank is deleted or a
member of an encryption-enabled rank is reused as a spare. Unlocking always results in a
cryptographic erasure of an FDE drive (the disk resets its own encryption key). The
cryptographic erasure of an FDE drive also happens when an encryption-disabled rank is
deleted. The client can cryptographically erase the data for a set of logical volumes in an
encryption-capable extent pool by deleting all the ranks associated with that extent pool.
FDE drives are not cryptographically erased when the drive fails. In this case, there is no
guarantee that the device adapter can communicate with the disk. More specifically, the
device adapter intentionally fences the failing drive from the device interface as soon as
possible to prevent it from causing other problems on the interface.
At this time, DS8000 does not support the intermix of FDE and non-FDE drives in the same
storage facility, so additional drives added to a DS8000 must be consistent with the already
installed drives. An IBM DS8000 with FDE disks is referred to as being encryption capable.
Each storage facility image on an encryption-capable DS8000 can be configured to either
enable or disable encryption for all data stored on client disks.
In order to enable encryption, each DS8000 storage facility image must be configured in the
following manner:
1. Configure at least two and up to four Tivoli Key Lifecycle Manager key servers. The
physical connection between the DS8000 HMC and the key server is through a TCP/IP
network. The configuration process specifies the IP addresses of key servers.
2. Configure an encryption group on the storage facility image (see Figure 2-12 on page 40).
The configuration operation specifies a key label for the encryption group. The DS8000
uses the key label to request a new data key from an attached Tivoli Key Lifecycle
Manager for the encryption group when the encryption group is created and stores the
externally encrypted data key for subsequent use. It also generates a random 256-bit
group key for the encryption group. AES wraps the group key (GK) with the data key
producing the encrypted group key (EGK), stores the EGK for future use, and then, zeros
the data key. Both the externally encrypted data key and the EGK are stored in multiple
places for reliability.
Figure 2-12 Configuring encryption group properties
3. After the encryption group is configured, you can create ranks that are associated with a
configured encryption group so that data stored on these ranks is encrypted. These ranks
are considered encryption enabled. Ranks that are not associated with an encryption
group are not encrypted. These ranks are considered encryption disabled. All ranks on a
storage facility image are encryption enabled, or all ranks on a storage facility image are
encryption disabled. The first rank configured determines how the remaining ranks must
be configured. Deleting the last rank on the storage facility image allows the choice of
encryption enabled or encryption disabled to be made when the first rank is configured.
4. You assign one or more ranks to one or more extent pools. All ranks in an extent pool must
be encryption enabled or encryption disabled. The extent pool is set to be encryption
enabled or encryption disabled based on whether the ranks in the extent pool are
encryption enabled or encryption disabled.
5. After extent pools are configured, you configure logical volumes in each extent pool. Data
that is associated with logical volumes that are configured in an encryption-enabled extent
pool is encrypted.
Each IBM FDE drive has an encryption key for the region of the disk that contains client data.
When the client data region is locked, the encryption key for the region is wrapped with an
access credential and stored on the disk media. Read/write access to the data on a locked
region is blocked following a power loss until the initiator accessing the drive authenticates by
supplying the currently active access credential. The access credential assigned to the locked
client data region by the storage facility image is unique to each disk. This access credential
is derived from the group key and the disk serial number using a secure hash algorithm.
When the client data region is unlocked, the encryption key for the region is wrapped with a
unique access credential that is assigned to this particular disk and stored on the disk media.
This access credential is accessible to the device and to any attached initiator, and it is visible
on the device external labeling to the client. Read/write access to the data on an unlocked
region does not require an access credential or any interface protocols that are not used on a
non-FDE disk. The FDE disk still encrypts/decrypts data with an encryption key, but it does so
transparently to the initiator.
On DS8000, an IBM FDE disk that is a member of an encryption-enabled rank is locked. An
IBM FDE disk that is unassigned, a spare, or a member of an encryption-disabled rank is
unlocked. Locking occurs when an FDE disk is added to an encryption-enabled rank (either at
rank creation or during sparing). Unlocking occurs when an encryption-enabled rank is
deleted or when an encryption-enabled rank member is re-purposed as a spare. Unlocking
always entails a cryptographic erasure of an IBM FDE disk. IBM FDE disks are also
cryptographically erased when an encryption-disabled rank is deleted. You can
cryptographically erase the data for a set of logical volumes in an encryption-capable extent
pool by deleting all the ranks associated with that extent pool.
After an encryption group is configured, additional interaction with the Tivoli Key Lifecycle
Manager is not required to allow access to data, except when the storage facility image
powers on. The DS8000 must be able to communicate with a Tivoli Key Lifecycle Manager
after a power on in order to allow access to the disks that have encryption enabled. In this
case, these steps occur:
1. DS8000 asks the Tivoli Key Lifecycle Manager to unwrap the externally encrypted data
key.
2. The Tivoli Key Lifecycle Manager returns a session encrypted data key.
3. The DS8000 unwraps the session encrypted data key to obtain the data key.
4. The DS8000 unwraps the EGK with the data key to obtain the GK
5. The DS8000 uses the GK to generate the access credentials to authenticate with the FDE
disks in the encryption group.
6. The FDE disks in the encryption group use their access credential to unwrap the
encryption/decryption key that is used on client data in the client data band.
Without access to Tivoli Key Lifecycle Manager, the data at rest on any locked FDE disks is
secure.
2.5 Encryption data
We briefly describe the type of data to encrypt in various IBM storage devices.
2.5.1 IBM tape drive
Since 2005, over hundreds of millions of consumers have been notified of potential security
breaches regarding personal information. The loss of computer backup tapes triggers
consumer notification. This situation has led to increasing data protection requirements, as
indicated in Figure 2-13 on page 42.
Figure 2-13 Client data must be protected
What data do you encrypt? Just as important, what data do you not encrypt? The focus on
data security is an ever-increasing challenge:
California is generally considered the first state within the U.S. to implement a law
requiring the 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 information is this website:
http://www.Privacyrights.org
Similar federal legislation has been proposed. The source for this information is this
website:
http://www.epic.org/privacy/bill_track.html
Many requirements drive data protection. In addition to regulatory requirements that drive the
need for greater data security, integrity, retention, auditability, and privacy, clients increase
data protection for the following reasons:
Business severely affected by the 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 to maintain backups
at remote locations is increasing
Requirement to reduce complexity and to improve the processes around enterprise
encryption management is increasing
Requirement to cost-effectively encrypt large quantities of tape data
The following additional drivers for encryption are in financial services area:
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 to improve response times to
revenue generating opportunities.
Growing regulatory burden:
Gramm-Leach-Bliley Act (GLBA) of 1999
California Law No. SB 1386
Fair Credit Reporting Act/Fair and Accurate Credit Transactions Act 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)
Data Center
Secondary Site Secondary Site
In Transit
Business Partners
In summary, simply encrypt all data that you can encrypt and still be able to recover data in
the event of a disaster. As long as system data can be separated from application data,
encrypting everything with no performance effect 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.
2.5.2 IBM Storage Series DS5000 and DS8000
Full disk encryption (FDE) disk drives enable you to significantly reduce the security
vulnerabilities of stored data. FDE disk drives adhere to the Trusted Storage Group enterprise
security subsystem class specification, meet the National Security Telecommunications and
Information Systems Security Policy (NSTISSP) number 11, and provide unparalleled
security with government-grade encryption.
Separate technologies are required to protect data that is stored on disk drives against
various threats. FDE drives ensure the security of stored data through the following methods:
Securing stored data against a breach
If an unauthorized user gains possession of a disk drive that contains encrypted data (the
drive is removed from the data center or powered down), the data is protected.
Permanently erasing stored data
Secure erase provides fast, permanent erasure of data on drives that are planned for reuse
or disposal.
FDE drives secure data against threats when the drive eventually leaves the owners control
but cannot protect data from threats that occur within the data center or in the network. If a
malicious hacker gains access to a server and can access an unlocked drive, the malicious
hacker can read the clear text that comes from the drive. Remember that drive-level
encryption technology does not replace the access controls of the data center; rather, it
complements them.
In particular, organizations experience a continued push to minimize the risks of data
breaches. A new focus on privacy management tools exists with the capability to mask data.
This focus reinforces the need for cryptography and the subsequent demand to simplify the
complexity of the key-based algorithms and the management of keys throughout the life
cycle. Encrypt all the data that you can encrypt and still be able to recover data in the event of
a disaster.
Before using any encryption technology, understanding the encryption concepts and the
requirements to maintain the security and the accessibility of the encrypted data is absolutely
important. You do not want the encryption solution to negatively affect your storage
environment and the applications that depend on it. You want an encryption solution that will
not degrade application performance or jeopardize your disaster recovery plan. You also need
the assurance that encryption will not cause any data loss and that all the appropriate
measures have been taken to protect and safeguard the encryption keys.
To address these concerns, the DS8000 encryption solution approach uses disks that have
encryption hardware, and it can perform symmetric encryption and decryption of data at full
disk speed with no effect on performance (see Figure 2-14 on page 44). The disk-based
encryption is combined with an enterprise-scale key management infrastructure. That
infrastructure is based on the IBM Tivoli Key Lifecycle Manager and life cycle management
Security: No single security implementation can effectively secure all levels of data
against all threats.
tools to help organizations efficiently deploy, back up, restore, and delete keys and certificates
in a secure and consistent fashion.
Figure 2-14 Locked and secured data with self-encrypting drives
For a successful deployment, following the instructions and guidelines that are outlined in this
document is also imperative. For more information about IBM security solutions, refer to the
IBM Security page:
http://www.ibm.com/security/index.html
2.6 Using data encryption
Next, we describe the reasons for encrypting data in IBM storage devices.
2.6.1 Encrypting data in the tape drive
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 xFF 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; therefore, there is only one component to manage across
multiple platforms.
Tape data encryption can be managed by the applications, system managed, or library
managed. The following chapters describe 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 quickly.
Additionally, a clever use of encryption is for data shredding. In effect, if you delete an
encryption key, all the data that the encryption key protected, becomes useless. This use of
cryptography requires extreme care to know exactly what data belongs to what key.
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.
2.6.2 Encrypting data on disk drives
Businesses today need tools to protect against the known threats, but they also need to guard
against as yet unknown threats. Effective threat and vulnerability management must be
proactive rather than reactive, preventing problems rather than responding to them. To be
efficient and effective, businesses must address prevention, detection, and compliance in an
integrated way. Figure 2-15 on page 46 illustrates how these threats and challenges add to
the complexity, hence, the cost of running your business.
Figure 2-15 Business complexity
Companies face many threats and security challenges:
Increasing number and sophistication of threats. Businesses face more than just viruses
and worms. You have to be able to defend against all threats rather than only respond to
intrusions.
You have to prevent data breaches and inappropriate data disclosure, while ensuring no
effect on business and productivity.
Intrusions affect your bottom line in both customer confidence and business productivity.
Security breaches can destroy your brand image and affect your critical business
processes.
Growing demand for regulatory compliance and reporting. You must be able to meet a
growing number of compliance initiatives without diverting resources from core activities.
Even when you have to protect your data, you also have to maintain appropriate levels of
access.
Security issues are both internal and external. How do you protect against the
well-intentioned employee who mishandles information, as well as the malicious outside
hacker?
Your business must comply with a growing number of corporate standards and
government regulations; you must have tools that can document the status of your
application security.
Regulatory mandates are growing; you have to prove that your physical assets are secure.
2.6.3 Fundamentals to encryption: Policy and key management
This section highlights the policy and key management fundamentals of data encryption in
tape drives and disk drives.
Tape encryption fundamentals
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 Key Lifecycle 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.
Disk encryption fundamentals
When considering encryption at your installation, consider the following factors.
As the availability of encryption-capable devices becomes more pervasive, more and more
data will be migrated from non-encrypted storage to encrypted storage. Even if the key
servers are initially configured correctly, it is possible that a storage administrator might
accidentally migrate data required by the key server from non-encrypted to encrypted
storage.
Generally, a number of layers of virtualization in the I/O stack hierarchy can make it difficult for
the client to maintain an awareness of where all the files (necessary to make the key server,
and its associated keystore, available) are stored. The key server can access its data through
a database that runs on a file system that runs on a logical volume manager, which
communicates with a storage subsystem that provisions logical volumes with capacity
obtained from other subordinate storage arrays. The data required by the key server might
end up provisioned over various storage devices, each of which can be independently
encryption capable or encryption enabled.
Consolidation of servers and storage tends to drive data migration and tends to move
increasingly more data under a generalized shared storage environment. This storage
environment will become encryption capable as time goes on.
All IBM server platforms support fabric-attached boot devices and storage. Certain servers do
not support internal boot devices. Therefore, boot devices are commonly present within the
generalized storage environment. These storage devices are accessible to generalized
storage management tools that support data management and relocation.
To mitigate the risk of an encryption deadlock, you must be directly involved in managing the
encryption environment.
Important: Any data required to make the Tivoli Key Lifecycle Manager key server
operational must not be stored on an encrypted storage device that is managed by this
particular key server. This situation is referred as an encryption deadlock. This situation is
similar to having a bank vault that is unlocked with a combination and the only copy of the
combination is locked inside the vault.
Chapter 3. IBM storage encryption methods
In this chapter, we describe the Tivoli Key Lifecycle Manager and the Encryption Key
Manager (EKM), both of which are Java software programs that manage keys enterprise-wide
and provide encryption-enabled disk and tape drives with keys for encryption and decryption.
The Tivoli Key Lifecycle Manager is the follow-on product to EKM that adds a graphical
interface and additional life cycle key management functionality.
For IBM disks (specifically, the IBM System Storage DS8000), we describe the disk
encryption mechanism that is used, and how Tivoli Key Lifecycle Manager is used to manage
the keys and so enable disk encryption.
For IBM tape, we describe the various methods of managing encryption.These methods differ
in respect to 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 key
manager, such as the Tivoli Key Lifecycle Manager or EKM, to provide and manage keys.
With AME, key provisioning and key management are handled by the application.
When describing the tape and disk encryption methods, we trace the flow of data and keys.
We explain how the disk and tape drives communicate with the key manager (or, in the case
of tapes, the application, if AME is the method) 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 describe the criteria that can influence your decision for or against
a specific encryption method. For more information, see Chapter 10, Planning for software
and hardware to support tape drives on page 191).
3
3.1 Tivoli Key Lifecycle Manager
exist and all of these keys and certificates have to be managed. Key management can be
handled either internally by an application, such as the IBM Tivoli Storage Manager, or
externally by a key manager. The IBM approach to key management revolves around IBM
Tivoli Key Lifecycle Manager, a product announced in 2008 that is enhanced in phases. From
an initial focus on key management for tape and disk encryption, IBM plans to expand Tivoli
Key Lifecycle Manager into a centralized key management facility for managing encryption
across a range of deployments.
The Tivoli Key Lifecycle Manager product is an application that performs key management
tasks for IBM encryption-enabled hardware, such as the IBM System Storage DS8000 Series
family and IBM encryption-enabled tape drives (TS1120 and TS1130 tape drives and Linear
Tape-Open (LTO) Ultrium 4 Tape Drives). Tivoli Key Lifecycle Manager provides, protects,
stores, and maintains encryption keys that are used to encrypt information being written to,
and decrypt information being read from, a encryption-enabled disk or tape. Tivoli Key
Lifecycle Manager is supported on a variety of operating systems. Version 1.0 of Tivoli Key
Lifecycle Manager supports these operating systems:
AIX 5.3 and AIX 6.1: 64 bit
Red Hat Enterprise Linux AS V4.0 x86: 32 bit
SUSE Linux Enterprise Server V9.0 and V10 x86: 32 bit
Sun Server Solaris 10 Sparc: 64 bit
Microsoft Windows Server 2003 R2: x86: 32 bit
z/OS V1 Release 9 or later
Fix Pack 1 (available April 2009) added additional platform support:
Red Hat Enterprise Linux 5 32 bit
Red Hat Enterprise Linux 5 64 bit (32-bit mode application)
Solaris 9 SPARC 64 bit
SUSE Linux Enterprise Server 10 64 bit (32-bit mode application)
Windows Server 2003 64 bit (32-bit mode application)
Windows Server 2008 32 bit
Windows Server 2008 64 bit (32-bit mode application)
Interim Fix Packs 1A and 2 (available September 2009) did not add any additional platform
support.
Tivoli Key Lifecycle Manager is designed to be a shared resource deployed in several
locations within an enterprise, and it is capable of serving many IBM encrypting devices
regardless of where those drives reside. Tivoli Key Lifecycle Manager communicates with the
managed storage devices using TCP/IP.
DS8000: For the DS8000, an independent Tivoli Key Lifecycle Manager key server is
required. This server is provided by IBM when a DS8000 is ordered and currently consists
of an IBM System x running SUSE Linux Enterprise Server (SLES) 9.0 with storage not
provisioned on the DS8000 to prevent a possible deadlock situation (see 3.4.2, Encryption
deadlock on page 67). Additionally, you can deploy secondary key servers on any of the
previously mentioned platforms.
Chapter 3. IBM storage encryption methods 51
3.1.1 Tivoli Key Lifecycle Manager components and resources
The purpose of the Tivoli Key Lifecycle Manager is to serve keys to encrypting disk or tape
drives. The Tivoli Key Lifecycle Manager does not perform any cryptographic operations,
such as generating encryption keys or encrypting data, and it does not provide storage for
keys and certificates. To perform these tasks, Tivoli Key Lifecycle Manager has to rely on
external components, which are typically provided by standard Java services, especially for
non-z/OS implementations. In addition to the key-serving function, the Tivoli Key Lifecycle
Manager also provides the following functions:
Life cycle functions:
Notification of certificate expiration through the Tivoli Integrated Portal
Automated rotation of certificates
Automated rotation of groups of keys
Usability functions:
A graphical user interface (GUI)
Configuration wizards
Migration wizards
Integrated backup and restore of Tivoli Key Lifecycle Manager files
One button to create and restore a single backup that is packaged as a JAR file
Tivoli Integrated Portal installation manager:
Simple to use installation for Microsoft Windows, Linux, AIX, or Solaris
Silent installation option
The distributed version of the Tivoli Key Lifecycle Manager solution is implemented as an
application within Tivoli Integrated Portal and consists of Tivoli Integrated Portal, the Tivoli
Key Lifecycle Manager server, an IBM embedded WebSphere Application Server, and a
database server (IBM DB2).
Figure 3-1 on page 52 shows the Tivoli Key Lifecycle Manager components and external
resources.
More information: In Tivoli Key Lifecycle Manager, the drive table, LTO key group, and
metadata are all kept in DB2 tables. The Tivoli Key Lifecycle Manager DB2 tables enable
the user to search and query that information much easier. However, note that the
keystore, configuration file, audit log, and debug log are still flat files.
Figure 3-1 Tivoli Key Lifecycle Manager components and resources
Tivoli Key Lifecycle Manager uses several other resources.
Configuration file
Tivoli Key Lifecycle Manager has an editable configuration file with additional configuration
parameters that are not offered in the GUI. This file can be text-edited; however, the preferred
method is to modify the file through the Tivoli Key Lifecycle Manager command-line interface
(CLI). See Starting the CLI on Microsoft Windows on page 376.
We describe the installation, configuration, and configuration options of Tivoli Key Lifecycle
Manager in Chapter 11, Planning for Tivoli Key Lifecycle Manager and its keystores on
page 237.
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) that
are used by Tivoli Key Lifecycle Manager to perform cryptographic operations. A keystore can
be either a hardware-based or software-based keystore.
Tivoli Key Lifecycle Manager supports several types of Java keystores, offering a variety of
operational characteristics to meet your requirements.
Tivoli Key Lifecycle Manager on open systems supports the JCEKS keystore. This keystore
supports both CLEAR key symmetric keys, and CLEAR key asymmetric keys. Symmetric
keys are used for LTO 4 encrypting tape drives, and asymmetric keys are used for DS8000
and TS1100 tape drives.
We describe the characteristics of the keystores in detail in 14.3, EKM and keystore
considerations on page 400 and Keystores on page 330.
St ores public/private keypairs
St ores symmet ric keys (LTO4)
Generates Data Key (DK)
Wraps DKs EEDK/SEDK
Manages Data Key (DK) generation
Manages keys transfer to and from
tape and disk devices
Key
Store
Audi t
Log
Tracks TKLM activity
Crypto
Services
Provider
eWAS
TIP
TKLM
Config
File
Defines TKLM
behavior
DB2 Tables
Dri ve Table
Meta Data
Key Groups
Tivoli Key Lifecycle Manager uses the IBM Java Security components for its cryptographic
capabilities. Tivoli Key Lifecycle Manager does not provide cryptographic capabilities and
therefore does not require, or is allowed to obtain, FIPS 140-2 certification. However, Tivoli
Key Lifecycle Manager takes advantage of the cryptographic capabilities of the IBM Java
Virtual Machine (JVM) in the IBM Java Cryptographic Extension component and allows the
Level 1 certification.
By setting the FIPS configuration parameter to ON in the Configuration Properties file, either
through text editing or by using the Tivoli Key Lifecycle Manager CLI, you can make Tivoli Key
Lifecycle Manager use the IBMJCEFIPS provider for all cryptographic functions.
You can obtain more information about the IBMJCEFIPS provider, its selection, and its use at
this website:
3.1.2 Key exchange
Tivoli Key Lifecycle Manager acts as a process awaiting key generation or key retrieval
requests sent to it through a TCP/IP communication path between Tivoli Key Lifecycle
Manager and the disk subsystem, the tape library, tape controller, tape subsystem, device
driver, or tape drive. When a disk or tape drive writes encrypted data, it first requests an
encryption key from Tivoli Key Lifecycle Manager. The tasks that Tivoli Key Lifecycle Manager
performs upon receipt of the request differ for each device type.
DS8000 disk drives
Tivoli Key Lifecycle Manager requests an asymetric key from the cryptographic services that
is associated with the DS8000. When the DS8000 is enabled for encryption, Tivoli Key
Lifecycle Manager then generates a symmetric data key, which it wraps with the public key
(from the previously mentioned asymetric key) and sends the wrapped data key to the
DS8000 in a structure known as the externally encrypted data key (EEDK). The EEDK is
stored on the system area of the disk. Only Tivoli Key Lifecycle Manager can extract the data
key from the EEDK, because only Tivoli Key Lifecycle Manager holds the private key. The
data key is also encrypted using the DS8000s public key and sent to the DS8000 in a
structure known as the session encrypted data key (SEDK). Because the DS8000 holds the
corresponding private key, the DS8000 can retrieve the data key from the session encrypted
data key. This data key is then used to create an access credential for the disk, and the Tivoli
Key Lifecycle Manager server erases its copy of the data key.
When the DS8000 is powered off, it erases the data key, so that the only way that it can
access the unlocking credentials and, hence, the data on the disk when it is powered up, is by
obtaining the data key. The DS8000 sends the externally encrypted data key to the Tivoli Key
Lifecycle Manager. Tivoli Key Lifecycle Manager is able to extract the data key, because the
DS8000 Full Disk Encryption disks: The DS8000 Full Disk Encryption (FDE) disks
encrypt all data at all times, even when the disks are set to be non-encrypting. Each disk
holds its own symmetric key (not the data key previously mentioned) that it uses to encrypt
all data. The act of enabling encryption merely requires that the controller presents access
credentials to the disk before the disk will allow access to the encrypted data. If encryption
is not enabled, the disk does not require these access credentials, and it will simply read
the encrypted data, decrypt it using its own symmetric key, and serve it to the host. In this
way, the data key acts as an access credential, not as the major encrypting key.
Tivoli Key Lifecycle Manager holds the corresponding private key, and Tivoli Key Lifecycle
Manager sends the data key to the DS8000 in a session encrypted data key. Because the
DS8000 holds the private key for the session encrypted data key, it is able to extract the data
key and unlock the drives. For greater detail about this process, see Chapter 22, IBM System
Storage DS8000 encryption preparation on page 753.
TS1120 and TS1130 tape drives
Tivoli Key Lifecycle Manager 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 to three additional places on
the tape media in the cartridge for redundancy.
The key can be 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 Secure Sockets Layer (SSL)-encrypted connections
between the Tivoli Key Lifecycle Manager and the library for all communication. However,
even when not using SSL for general communication, Tivoli Key Lifecycle Manager always
sends the keys to the library using a secured, encrypted session.
When an encrypted tape cartridge is read by a TS1100 Tape Drive, the protected AES key on
the tape is sent to Tivoli Key Lifecycle Manager where the wrapped AES key is unwrapped.
The AES key is then wrapped with a separate key for secure transfer back to the tape drive,
where it is unwrapped and used to decrypt the data that is stored on the tape. Tivoli Key
Lifecycle Manager also allows protected AES keys to be rewrapped, or rekeyed, using
separate 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 cartridges data key to be reencrypted with a business partners public key. For
a more detailed description, see 3.5.3, Encrypting and decrypting with SME and LME on
page 79.
LTO Ultrium 4 tape drives
Tivoli Key Lifecycle Manager 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, Tivoli Key Lifecycle Manager
fetches the required key from the keystore, based on the information in the Key ID on the
tape, and serves it, wrapped for secure transfer, to the tape drive.
3.2 IBM Encryption Key Manager
exist, especially for tapes, where each tape can require its own key. All these keys and
certificates must 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 describe 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 3-2.
Figure 3-2 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 to decrypt information being read
from, tape media. EKM operates on a variety of operating systems. Currently, EKM operates
on the following supported operating systems:
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).
Important: Tivoli Key Lifecycle Manager is the follow-on product to EKM. EKM supports
the management of keys for IBM tape drives only, not disk drives. However, many clients
still use EKM to manage the keys for their encrypting tape drives.
IBM supplies EKM at no charge on IBM operating systems. On platforms that are not IBM
platforms, you must purchase IBM Tivoli Storage Productivity Center Basic Edition to gain
access to EKM. For IBM operating systems, download the current version of the IBM
Encryption Key Manager for the Java platform, the IBM System Storage Tape Enterprise Key
Manager, Introduction Planning and User Guide, GA76-0418, and a sample configuration file
for EKM. To download, go to this website:
http://www.ibm.com/support/search.wss?rs=1139&tc=STCXRGL&dc=D400&dtm
3.2.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. 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
relies on external components. In the following sections, we describe the components of EKM
and the resources that are used by EKM.
Figure 3-3 shows the EKM components and external resources.
Figure 3-3 EKM components and resources
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 EKM. You can populate this 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.
Crypto services: In Figure 3-3, crypto services can refer to either Java security providers
(software) or to cryptographic hardware that is installed on the system.
Encryption
Key Manager
(EKM)
Config
File
Drive
Table
Keystore
Crypto Services
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 can change the location of the tape drive table to meet your
requirements.
Configuration file
The configuration file is an editable file, which tells your EKM how to operate. You specify the
keystore location and the drive table location in this file.
We describe the configuration file extensively in Chapter 14, Planning for Encryption Key
Manager and its keystores on page 393 and, later, in Part 3, Implementing tape data
encryption on page 189, where we describe the full set of configuration options.
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 or clear asymmetric keys
JCE4758KS/JCECCAKS: Clear symmetric keys, clear asymmetric keys, secure
symmetric keys, or secure asymmetric keys
JCE4785RACFKS/JCECCARACFKS: Secure asymmetric keys
JCERACFKS: Clear asymmetric keys
PKCS11IMPLKS: The types of keys that are supported depend on the Public Key
Cryptographic Standards 11 (PKCS#11) implementation
IBMi5OSKeyStore: Clear asymmetric keys
We describe the characteristics of these keystores in 14.3, EKM and keystore
considerations on page 400.
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.
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 your tape drives have been added to the table. In a
business and continuity recovery site, however, such as Sunguard or IBM Business
Continuity and Resiliency Services, it is required to accept unknown tape drives.
IBM LTO Ultrium 4 drives: Encryption on IBM LTO Ultrium 4 drives requires a keystore
that supports symmetric keys.
You can obtain more information about the IBMJCEFIPS provider, its selection, and its use at
this website:
3.3 TS1120, TS1130, and LTO4 tape drive encryption
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 AES allows three key lengths. The 256-bit keys are the longest keys
allowed by AES.
The two types of encryption algorithms that can be used by EKM and Tivoli Key Lifecycle
Manager 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 that is 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 and Tivoli Key Lifecycle Manager use both symmetric and asymmetric keys. They use
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.
When implementing encryption using either LME or SME, EKM and Tivoli Key Lifecycle
Manager and all their supported tape drives (TS1120, TS1130, and LTO4), use symmetric,
256-bit AES keys to encrypt user data. The keys that are used to encrypt client data are
referred to as data keys. Important differences exist between the TS1120 and TS1130 tape
drives and the LTO Ultrium 4 tape drives in handling these data keys.
3592 and LTO4 tape drives
IBM encryption capable drive types use 256-bit AES keys to encrypt user data. The TS1120
and TS1130 encryption data keys are randomly generated when needed, used, and then
discarded. LTO4 encryption data keys are randomly pregenerated and then kept in the EKM
or Tivoli Key Lifecycle Manager keystore.
Hardware-based keystores: Do not use hardware-based keystore types when the FIPS
parameter is set ON.
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 (the 3592 drive method). EKM or Tivoli Key Lifecycle Manager select a
pre-generated data key in a round-robin fashion. The data key is sent to the drive in a secure
manner in the same way 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 or Tivoli Key Lifecycle Manager before the volume can
be read. Table 3-1 reflects the key usage by the encryption management method.
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
or Tivoli Key Lifecycle Manager 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 3-1.
Table 3-1 Key usage by drive type and management method
3.3.1 Key exchange
EKM or Tivoli Key Lifecycle Manager acts as a process awaiting key generation or key
retrieval requests sent to it through a TCP/IP communication path between EKM or Tivoli Key
Lifecycle Manager 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
or Tivoli Key Lifecycle Manager. The tasks that EKM or Tivoli Key Lifecycle Manager performs
upon receipt of the request differ for the TS1100 series drives.
Tip: Starting with IBM 31-bit software development kit (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 G, Implementing EKM on z/OS SECURE
key processing to TS1100 and LTO4/LTO5 drives on page 949.
Encryption management
method
Keys used by
TS1120 drive or TS1130
Keys used by LTO4 drive
System-Managed Encryption
or Library-Managed Encryption
using EKM or Tivoli Key
Lifecycle Manager
unique data key
a
per cartridge
a. A data key is a symmetric AES 256-bit data key.
One pregenerated data key per
cartridge
Application-Managed
Encryption (no EKM or Tivoli
Key Lifecycle Manager)
unique data key per cartridge
One data key per cartridge
EKM or Tivoli Key Lifecycle Manager requests an AES key from the cryptographic services
and serves it to the tape drives in two protected forms:
Encrypted or wrapped, using RSA key pairs. TS1120 and TS1130 tape drives write this
copy of the key to the cartridge memory and to three additional places on the tape media
in the cartridge for redundancy.
The AES can be 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 that is 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 or Tivoli Key Lifecycle Manager where the wrapped AES
key is unwrapped. The AES key is then wrapped with a separate key for secure transfer back
to the tape drive, where it is unwrapped and used to decrypt the data that is stored on the
tape. EKM or Tivoli Key Lifecycle Manager also allows protected AES keys to be rewrapped,
or rekeyed, using RSA keys that differ 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. Rekeying eliminates the need to
rewrite the entire tape and enables a tape cartridges data key to be reencrypted with a
business partners public key. For a more detailed description, see 3.5.3, Encrypting and
decrypting with SME and LME on page 79.
LTO Ultrium 4 tape drives
EKM or Tivoli Key Lifecycle Manager 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, EKM or Tivoli Key Lifecycle
Manager fetches the required key from the keystore, based on the information in the Key ID
on the tape, and serves it, wrapped for secure transfer, to the tape drive.
3.4 DS8000 disk encryption
The DS8000 disk subsystem supports data encryption with the IBM Full Disk Encryption
(FDE) drives. These drives are available in 146 GB, 300 GB, and 450 GB capacity, with a
rotational speed of 15K RPM. All disks in the DS8000 must be FDE drives; no intermix is
allowed. All drives in a two-storage logical partition (LPAR) storage facility image (SFI) system
must be FDE drives. However, in this case, you can decide not to enable encryption in one of
the storage facility images (SFIs).
These disks have encryption hardware, and they can perform symmetric encryption and
decryption of data at full disk speed with no effect on performance.
The disk encryption hardware is used in conjunction with Tivoli Key Lifecycle Manager (EKM
does not support disk drives). Tivoli Key Lifecycle Manager and the DS8000 use asymmetric
encryption to encrypt and decrypt the data key. When connected to the DS8000, Tivoli Key
Lifecycle Manager will generate encryption and decryption keys that are used to lock each
FDE drive. Without these Tivoli Key Lifecycle Manager-managed keys, the client can no
longer decrypt the data on disk.
For more details about the encryption key management, see 3.4.1, Encryption key
management on page 62.
To be able to use data encryption, you must order the DS8000 from manufacturing with FDE
drives (replacing the regular Fibre Channel (FC) drives with FDE drives in an existing DS8000
is not supported). Chapter 22, IBM System Storage DS8000 encryption preparation on
page 753 provides details about the ordering process.
Currently, the DS8000 does not support the intermix of FDE and non-FDE drives, so
additional disks to be added must be consistent with the already installed drives. A DS8000
with FDE drives is referred to as being encryption capable. Each SFI on an
encryption-capable DS8000 can be configured to either enable or disable encryption for all
data stored on client disks.
The DS8000 must be configured to communicate with at least two or more Tivoli Key
Lifecycle Manager key servers to enable encryption. Two Tivoli Key Lifecycle Manager key
servers are required for redundancy. The communication between the DS8000 and the Tivoli
Key Lifecycle Manager key server is done through the Hardware Management Console
(HMC). Therefore, having two HMCs to also provide redundancy on the storage device side is
important.
The physical connection between the DS8000 HMC and the key server is through a TCP/IP
network, as depicted in Figure 3-4.
Figure 3-4 Connection between DS8000 HMC and Tivoli Key Lifecycle Manager
Cryptographic erasure: If all copies of the decryption key are lost (whether intentionally
or accidentally), no feasible way exists to decrypt the associated ciphertext, and the data
contained in the ciphertext is said to have been cryptographically erased. The data is lost,
because it cannot be decrypted without the key.
StoragePlex
Customer IP Network
Key Lifecycle Manager
Crypto Services
Keystore
HMC
SFI Server SFI Server
Storage Facility Image
Storage Facility
HMC
StoragePlex
DSGUI/DS-CLI
Primary and secondary
TKLM Servers
Dual HMCs
Recommended
DS8000
Storage Admi n
TKLM GUI
Security/Storage
Admin
Disk encryption details
Each FDE drive has an encryption key for the area of the drive that contains customer data
(Band 1). As shown in Figure 3-5, Band 0 is for internal global data, which is also encrypted.
Figure 3-5 Encrypted bands
The encryption key for the data area is wrapped (encrypted) with an access credential that is
established by the Tivoli Key Lifecycle Manager key server. This access credential is
converted to a secure hash and stored on the disk. At that stage, the customer data area is
locked.
After a disk power loss, the read/write access to the data on a locked area is blocked until the
DS8000 has authenticated by supplying the currently active access credential (that it must get
from the Tivoli Key Lifecycle Manager server). When the customer data area is unlocked, the
FDE drive still encrypts/decrypts the data with an encryption key, but it is performed
transparently to the initiator (DS8000).
An FDE drive that is made a member of an encryption-enabled rank is locked. The FDE drive
is unlocked when it is unassigned, is a spare, or is a member of an encryption-disabled rank.
Locking occurs when an FDE drive is added to an encryption-enabled rank either during rank
creation or sparing. Unlocking occurs when an encryption-enabled rank is deleted or when a
member of an encryption-enabled rank is reused as a spare. Unlocking always results in a
cryptographic erasure of an FDE drive (the disk resets its own encryption key). This also
happens when an encryption-disabled rank is deleted.
possible to prevent it from causing other problems on the interface.
3.4.1 Encryption key management
In this section, we provide details about how the Tivoli Key Lifecycle Manager key server
manages and creates the encryption keys used by the DS8000 during key label and
encryption group and rank creation, as well as at the DS8000 power-on time.
Customer
Data
Band 1
Band 0
Important: Only key negotiation and authentication between the Tivoli Key Lifecycle
Manager and DS8000 take place at power on of the DS8000. No traffic overhead is
created by key negotiation in an encrypted DS8000 at run time.
The Tivoli Key Lifecycle Manager uses the wrapped key method to serve keys to the
encryption-enabled DS8000. The wrap/unwrap keys on the Tivoli Key Lifecycle Manager are
a public/private asymmetric key pair that is referred to as the public key encrypting key (KEK)
and the private key encrypting key (KEK).
The configuration processes on the Tivoli Key Lifecycle Manager and the storage device
(DS8000) define one key label for the DS8000 (or two key labels when dual platform support
is enabled (see 3.4.4, Dual platform key server support on page 70)).
The key label is a user-specified text string that is associated with the asymmetric key label
pair (KEK/KEK), which is generated by the Tivoli Key Lifecycle Manager when the key label is
configured. See Figure 3-6. This key label pair, or key encrypting key pair, is maintained by
the Tivoli Key Lifecycle Manager, and it is used to wrap and unwrap data keys. The key
encrypting key pair key is kept secret by the Tivoli Key Lifecycle Manager.
Figure 3-6 Configure Tivoli Key Lifecycle Manager Key Label
Now, the user (storage administrator) will use the DS8000 GUI to register the key server on
the DS8000. Next, still using the DS8000 GUI or, alternatively, using the DS8000 CLI, an
encryption group is created. For details, see 23.3.1, Configuring the Tivoli Key Lifecycle
Manager server connection on page 804.
As part of creating the encryption group, you must specify the key label that was set when
configuring the Tivoli Key Lifecycle Manager server.
While creating the encryption group, the DS8000 generates a device session key pair (device
session public key/device session private key or (DSK/DSK)). The device session private key
(DSK) is kept secret by the DS8000.
The key label, device session public key (DSK), and the DS8000 SFI certificate (which was
set and stored on the DS8000 by manufacturing) are sent to the Tivoli Key Lifecycle Manager.
After receiving these objects, Tivoli Key Lifecycle Manager performs the following steps (see
Figure 3-7 on page 64):
1. Tivoli Key Lifecycle Manager validates the DS8000 certificate.
2. From the key label, Tivoli Key Lifecycle Manager retrieves the key label key pair
(KEK/KEK).
3. Tivoli Key Lifecycle Manager generates the data key.
4. The data key is wrapped with the key label public key (or public KEK) and stored in a
structure that is referred to as the externally encrypted data key.
DS8000: Currently, the DS8000 has only one encryption group.
Key Lifecycle Manager (TKLM)
(1) USER
Create Key Label
(Key Label)
- generate Key-Label Key Pair
- Key-Label Public Key (KEK)
- Key-Label Private Key (KEK)
- store Key Label and Key-Label Key Pair
5. The data key is wrapped with the device session public key and stored in a structure
referred to as the session encrypted data key.
Figure 3-7 Configure encryption group
Now, the Tivoli Key Lifecycle Manager transfers the session encrypted data key and EEDK
key to the DS8000. The following steps occur:
1. To re-create the data key at the DS8000, the session encryption data key is unwrapped
with device session private key (DSK). The DS8000 holds the data key in memory.
2. The DS8000 generates a random 256-bit group key (GK) for the encryption group.
3. The group key (GK) is wrapped with the data key and stored in a structure referred as the
encrypted group key (EGK). The EGK is persistently stored on the system disk in the key
repository. Both the externally encrypted data key (EEDK) and the EGK are stored in
multiple places for redundancy.
This dual control from DS8000 and Tivoli Key Lifecycle Manager improves security. The
DS8000 does not maintain a persistent copy of the data key in the clear and is thus unable to
encrypt or decrypt data without access to the Tivoli Key Lifecycle Manager.
When the user configures a rank, the DS8000 creates an access credential to lock each drive
for each disk drive module (DDM) in this rank (see Figure 3-8 on page 65). The following
steps occur during the configuration of the rank:
1. The DS8000 reads the disk serial number and hashes this disk serial number with the
group key to create the access credential.
2. The access credential is sent to the drive, which is where the drive encrypted data key is
wrapped with the access credential. A hash of the access credential is also stored on the
drive.
Data key: The data key is erased by the DS8000 at power off. Each time that the DS8000
is powered on, it must communicate with the Tivoli Key Lifecycle Manager to obtain the
data key.
Storage Facility Image (SFI) Key Lifecycle Manager
Creat eEncryption Group
(N, Key Label)
System Disk
IBM Certificate
<generate devicesession key pair
DSK/DSK>
Get New Key(Key Label,
DSK, Certificat e)
<validate Certi fi cate>
<Get Key-Label Key Pai r for Key-Labe (KEK/KEK)l>
<generate data key=DK>
<EEDK=wrap(DK, KEK)>
<SEDK=wrap(DK, SDK)>
SEDK, EEDK
<DK=unwrap(SEDK, DSK>
<generate group key=GK>
<EGK=wrap(DK, GK)>
<storeEEDK(N), EGK(N) >
USER (2)
DS8000
Figure 3-8 Configure rank
The following steps, which are also shown in Figure 3-9 on page 66, are performed to regain
access to locked drives at power on:
1. The DS8000 requests that the Tivoli Key Lifecycle Manager unwrap an existing wrapped
data key by sending the request to the Tivoli Key Lifecycle Manager with the saved
externally encrypted data key (EEDK) and the session public key.
2. The Tivoli Key Lifecycle Manager unwraps the EEDK with the key label private key to
obtain the data key.
3. The data key is wrapped with the session public key to create the session encrypted data
key. The session encrypted data key is returned to the DS8000.
4. The session encrypted data key is decrypted with the session private key to obtain the
data key.
5. The data key is then used to unwrap the encrypted group key (EGK) to get the group key
(GK).
6. The serial number of the disk is read and hashed with the GK to obtain the access
credential.
7. The hashed access credential is sent to disk, and the validity of the access credential is
verified.
8. If the access credential is valid, the disk encrypted data key is unwrapped to gain access
to the data.
Important: The DS8000 must be able to communicate with the Tivoli Key Lifecycle
Manager during power on.
Encrypting Disk
Encrypt / Decrypt
Hardware
Non-Volatile Memory
Hashed Access Credential
Data Key
Encrypted Data Key
Lock (Access Credential)
<hash> <encrypt>
Storage Facility Image (SFI)
USER (3)
Configure Rank
(Encryption Group N)
Read Disk Serial Number
<Access Credential =
hash(GK(N), Disk Serial Num)>
DS8000
Figure 3-9 Power on of the DS8000
Figure 3-10 summarizes all the key management mechanisms.
Figure 3-10 Encryption key management
Encrypting Disk
Encrypt/Decrypt
Hardware
Data
Authenticate
(Access Credential)
<decrypt>
Non-Volatile Memory
Hashed Access Credent ial
<hash & verify>
Data Key
Encrypt ed Data Key
Storage Faci lity Image (SFI)
Key Li fecycle Manager (TKLM)
System Disk
IBM Cert ificate
<generate session key pair>
<DK(N)=unwrap(SEDK,
Session Private Key>
<GK(N)=unwrap(EGK(N), DK(N)
Get Existing Key (EEDK(N),
Session Public Key)
<DK=unwrap(EEDK, Key-Label Private Key)>
<SEDK=wrap(DK, Session Public Key)>
SEDK
DS8000
Encrypting Disk
Encrypt / Decrypt
Hardware
Data
Authenticate
(Access Credential)
<decrypt>
Non-Volatile Memory
Hashed Access Credential
<hash & verify>
Data Key
Encrypted Data Key
Lock (Access Credential)
<hash> <encrypt>
Storage Facility Image (SFI)
Key Lifecycle Manager (TKLM)
Create Encryption Group
(N, Key Label)
System Disk
IBM Certificate
Get New Key (Key Label,
Session Public Key, Certificate)
<validate Certificate>
<Get Key-Label Key Pair for Key-Label>
<generate data key=DK>
<EEDK=wrap(DK, Key-Label Public Key)>
SEDK, EEDK
<DK=unwrap(SEDK,
<generate group key=GK>
<EGK=wrap(DK, GK)>
<store EEDK(N), EGK(N)>
<DK(N)=unwrap(SEDK,
<GK(N)=unwrap(EGK(N), DK(N)
USER (2)
Get Existing Key (EEDK(N),
Session Public Key)
<DK=unwrap(EEDK, Key-Label Private Key)>
SEDK
USER (3)
Configure Rank
(Encryption Group N)
Read Disk Serial Number
Configure TKLM Key Label = Green
Configure Encryption Group = Red
Configure Rank = Blue
Power On = Black + Magenta
(1) USER
Create Key Label
(Key Label)
<generate Key-Label Key Pair>
<store Key Label, Key-Label Key Pair>
3.4.2 Encryption deadlock
The key server platform provides the operating environment for the key server application to
run, to access its keystore on persistent storage, and to interface with client storage devices,
such as the DS8100, DS8300, and DS8700, that require key server services.
The keystore data is accessed by the key server application (Tivoli Key Lifecycle Manager)
through a client-specified password. The keystore data is encrypted at rest, independently of
where it is stored. However, any online data that is required to initiate the key server must not
be stored on storage that has a dependency on the key server to enable access. If this
constraint is not met, the key server is unable to complete its initial program load (IPL) and will
not become operational.
This required data includes the boot image for the operating system that runs on the key
server. This required data also includes any other data that is required by that operating
system and its associated software stack to run the key server application, to allow the key
server to access its keystore, and to allow the key server to communicate with its storage
device clients. Similarly, any backups of the keystore must not be stored on storage that has a
dependency on a key server to access data.
Not strictly following these implementation requirements can result in a situation where the
encrypted data can no longer be accessed either temporarily, or worse, permanently. This
situation is referred to as encryption deadlock.
A temporary encryption deadlock and a permanent encryption deadlock differ in these ways:
Temporary encryption deadlock
A temporary encryption deadlock indicates a situation where a DS8100, DS8300, or
DS8700 cannot access its disk devices, because the Tivoli Key Lifecycle Manager servers
are not online, the network is down, or for other temporary hardware-related errors. This
temporary failure can be fixed at the clients site.
Permanent encryption deadlock
The permanent encryption deadlock is the worse case. Here, all Tivoli Key Lifecycle
Manager servers that manage a set of data cannot be made operational, because they
have a dependency on inaccessible encrypted storage. Or, all encrypted online and offline
data that is managed by the set of Tivoli Key Lifecycle Managers is, in effect,
cryptographically erased and for all practical purposes permanently lost.
When considering encryption at your installation, consider the following factors:
As the availability of encryption-capable devices becomes more pervasive, more and more
data will be migrated from non-encrypted storage to encrypted storage. Even if the key
servers are initially configured correctly, it is possible that a storage administrator might
accidentally migrate data required by the key server from non-encrypted to encrypted
storage.
Generally, a number of layers of virtualization in the I/O stack hierarchy can make it difficult
for you to know where all the files are stored (it is necessary to make the key server, and
its associated keystore, available). The key server can access its data through a database
Important: Any data required to make the Tivoli Key Lifecycle Manager key server
operational must not be stored on an encrypted storage device that is managed by this
particular key server. Again, this situation is referred as an encryption deadlock. This
situation is similar to having a bank vault that is unlocked with a combination and the only
copy of the combination is locked inside the vault.
that runs on a file system that runs on a logical volume manager, which communicates
with a storage subsystem that provisions logical volumes with capacity obtained from
other subordinate storage arrays. The data required by the key server might end up
provisioned over various storage devices, each of which can be independently encryption
capable or encryption enabled.
The consolidation of servers and storage tends to drive data migration and tends to move
increasingly more data under a generalized shared storage environment. This storage
environment will become encryption capable as time goes on.
All IBM server platforms support fabric-attached boot devices and storage. Certain servers
do not support internal boot devices. Therefore, boot devices are commonly present within
the generalized storage environment. These storage devices are accessible to
generalized storage management tools that support data management and relocation.
To mitigate the risk of an encryption deadlock, you must be directly involved in managing the
encryption environment. See 11.3, Working with keys and certificates on page 245,
Chapter 23, DS8000 encryption features and implementation on page 771, and Chapter 24,
DS8700 advanced encryption features and implementation on page 811.
Release 5 (R5) of the microcode for the DS8000 (available only for the DS8700 models)
introduced two important encryption enhancements:
Encryption recovery key support
Dual platform key server support
3.4.3 Encryption recovery key support
With R5 firmware on a DS8700, you can configure a recovery key on the DS8700 that can be
used to unlock the disk if it cannot obtain a data key from any key server (for example, in the
deadlock situation).
As shown in 3.4.1, Encryption key management on page 62, the group key (GK) is wrapped
by the data key that is supplied by the Tivoli Key Lifecycle Manager. In order to get access to
the disk, the GK must be recovered. If the Tivoli Key Lifecycle Manager is available, it is able
to supply the data key, and hence, the GK can be obtained. However, when no key server is
available, the data key cannot be obtained, and so, the GK cannot be obtained.
Figure 3-11 Using the recovery key feature
As shown in Figure 3-11, when a recovery key is configured, a new primary key/secondary
key (PRK/SRK) asymmetric key pair is generated by the DS8700. In addition, the DS8700
generates a recovery key (RK), which you must record. The PRK is then wrapped (encrypted
by) the RK and stored as an EPRK. When the encryption group is created, the GK is wrapped
by the SRK and stored as an EGRK.
If recovery is needed, the RK (which you manually enter at the console) is used by the
DS8700 to unwrap the EPRK to obtain the PRK. The PRK is then used to unwrap the EGRK
to obtain the GK. The GK can then be used to derive the disk access credential as before and
so unlock the data on the FDE disks.
If you plan to use a recovery key, you must configure it before configuring the encryption
group and enabling encryption on the DS8700. You must note the recovery key and keep it
safe for future use.
In addition, two new user roles have been created for the DS8700:
Storage Administrator (STGADM) (formerly known as the Administrator)
Security Administrator (SECADM)
The new user roles enable the DS8000 to employ Dual User Access Control for all actions on
the recovery key, so that no one person can, for instance, instigate access to the data using
the recovery key. For any actions relating to the recovery key, both the Storage Administrator
and the Security Administrator must give their consent.
<generate asymmetr ic key (PRK/SRK)>
<generate symmetric recovery key (RK) >
<EPRK=wrap( PRK,RK)>
<EGRK=wrap( GK,SRK)>
DS8700 stops at IML
because no key server is avai lable
<PRK=unwrap(EPRK,RK)>
<GK=unwr ap(EGRK,PRK)>
.
..
GK i s used to create the credentials to unlock the dri ves
DS8700
Configure recovery Key
Client requests configuration
of recovery key
Client makes a copy of the RK
and keepsit safe
Client enters the RK
DS8700
Request recovery Key
3.4.4 Dual platform key server support
To ensure key server availability, clients will usually configure at least a primary and a
secondary Tivoli Key Lifecycle Manager. In fact, the DS8000 requires that an independent
secondary Tivoli Key Lifecycle Manager (an Isolated Key Server (IKS)) is configured in order
to avoid encryption deadlock. When a DS8000 is ordered, a System x with SUSE and Tivoli
Key Lifecycle Manager is also shipped.
The primary and secondary Tivoli Key Lifecycle Managers must be kept in synchronization
(that is, all the required keys must exist on both Tivoli Key Lifecycle Managers). This
synchronization implies that the keys are exported from the primary Tivoli Key Lifecycle
Manager and imported into the secondary Tivoli Key Lifecycle Manager (using
Backup/Restore or tklmKeyExport functions). However, if the primary Tivoli Key Lifecycle
Manager operates in secure key mode, this synchronization is not possible, because secure
key mode prevents the export of private keys. Secure key mode is usually implemented using
specialized keystore hardware (such as the Hardware Security Module (HSM) used on the
System z). So, if the primary Tivoli Key Lifecycle Manager is running in secure key mode
(typically on z/OS), it is not possible to export the private keys to the secondary key server,
and so, the keystores cannot be kept in sync (although the public keys can be exported from
a keystore operating in secure key mode).
Dual platform key server support addresses this problem and ships on the DS87000 with R5
firmware. It also requires Tivoli Key Lifecycle Manager V1.0 with Interim Fix Pack 2 installed
(although Tivoli Key Lifecycle Manager V1.0 will work, but it will only display a single key, not
the dual keys).
Tivoli Key Lifecycle Manager has always been able to support two key labels for each device.
In the case of tapes, two key support was used to move tapes from a client to a business
partner. The data key for the tape was wrapped with both the clients public key and with the
business partners public key, creating two EEDKs that were stored on the tape. One of the
EEDKs was unwrapped by the client using the clients private key, and the other EEDK was
unwrapped by the business partner using their data key. Hence, both the client and the
business partner (but only the client and the business partner) were able to read the tape.
With dual platform key server support, the two Tivoli Key Lifecycle Managers exchange public
keys. When the DS8700 requests a data key, the primary Tivoli Key Lifecycle Manager
(typically on z/OS) wraps the data key with the two public keys (the public keys of the primary
Tivoli Key Lifecycle Manager and the public key of the secondary Tivoli Key Lifecycle
Manager). The primary Tivoli Key Lifecycle Manager creates two EEDKs, which are stored on
the disk. Similar to the tape example, both the Tivoli Key Lifecycle Managers can recover the
data key by unwrapping the one of the EEDKs (the EEDK for which they hold the private key).
In this way, you can use two Tivoli Key Lifecycle Managers and keep them in sync without
compromising the secure key server architecture. Therefore, you can avoid an encryption
deadlock situation that is caused by the Tivoli Key Lifecycle Manager on System z becoming
inaccessible.
Update: Since writing this Redbooks publication, Fix Pack 3 became available (in late
October 2009). Fix Pack 3 includes all the fixes and updates from all previous fix packs (Fix
Pack 1, Interim Fix Pack 1A, and Interim Fix Pack 2), as well as additional fixes. Fix Pack 3
is the correct fix pack to install).
The procedure for installing Fix Pack 3 is similar to the procedures that are shown here to
install Interim Fix Pack 1A and Interim Fix Pack 2.
You must first configure the key servers with the two labels and configure the DS8700 for
recovery key support before the DS87000 can be configured for single or dual labels. If the
key servers are incorrectly configured or the recovery key is not configured, either the create
group will fail or the DS8700 will fail to power on. For details about configuring a DS8700 for
dual platform support, see Chapter 23, DS8000 encryption features and implementation on
page 771.
Example of dual platform key server support
Figure 3-12 assumes that the primary Tivoli Key Lifecycle Manager is on System z and the
secondary Tivoli Key Lifecycle Manager is on System x.
Figure 3-12 Dual key platform support
The following numbers refer to the numbered steps of the process in Figure 3-12:
1. The key server on the System z configures a key label (labelZ) and generates an
asymmetric key pair. The keystore is a secure keystore and cannot export private keys, but
it can export the public key to the other platform (Tivoli Key Lifecycle Manager on
System x).
2. The key server on the System x configures a key label (labelX) and generates an
asymmetric key pair. This keystore is a clear keystore and can export both private keys
and public keys to the other platform (Tivoli Key Lifecycle Manager on System z). The key
servers now exchange their public keys using the Tivoli Key Lifecycle Manager CLI
tklmCertExport command. For examples of listing, exporting, and importing the public
keys, see Chapter 24, DS8700 advanced encryption features and implementation on
page 811 and 13.8, The Tivoli Key Lifecycle Manager command-line interface on
page 386. Both key servers now have two public keys for two key labels, and both key
servers can generate data keys that are wrapped for both key labels.
3. The DS8700 requests a new symmetric data key from its primary Tivoli Key Lifecycle
Manager.
4. The Tivoli Key Lifecycle Manager on System z generates a new symmetric key and wraps
it with the public keys from both Tivoli Key Lifecycle Managers (using labelZ and labelX),
creating two EEDKs.
5. DS8700 stores the wrapped data keys for both key labels; that is, it stores both the
EEDKs.
System x
Key Server
System z
Key Server
TKLM
TKLM
DS8700
Key Repository
4. Generate new
symmetric key and
wrap with key labelZ
and labelX
5. The DS8700 stores both EEDKs
HSM
labelZ
labelX
1. Generate A Key
Pair on Each Platform
2. Exchange the publi c
unwrapping keys
3. Request new
symmetric key (DK)
Figure 3-13 Dual key server platform support: Storing the wrapped keys
The DS8700 is then powered off and discards the data key. So, at power on, it needs Tivoli
Key Lifecycle Manager to provide it with the data key. Figure 3-13 shows the sequence of
events:
1. The DS8700 is powered on.
2. When DS8700 needs to unwrap the data key, DS8700 sends both wrapped keys (EEDKs)
and either key server can unwrap at least one of the two wrapped data keys. In this
example, the primary Tivoli Key Lifecycle Manager (on System z) is unavailable, and
therefore, the unwrap request is sent to the secondary Tivoli Key Lifecycle Manager.
3. The Tivoli Key Lifecycle Manager on System x unwraps one of the EEDKs using its private
key.
4. The Tivoli Key Lifecycle Manager then sends the data key (securely wrapped as a session
encrypted data key) to the DS8700.
5. The DS8700 extracts the data key from the session encrypted data key.
Figure 3-14 on page 73 expands on this example to show an example architecture of a
multiple site Tivoli Key Lifecycle Manager environment. In this example, each site has a
primary Tivoli Key Lifecycle Manager on System z using secure keystore and a secondary
Tivoli Key Lifecycle Manager on System x using clear keystore. The System z keystores are
synchronized by using replication through Integrated Cryptographic Service Facility (ICSF),
and the System z and System x keystores are synchronized using the export of public keys.
The System x keystores can also be synchronized using the Tivoli Key Lifecycle Manager
backup/restore facility.
System x
Key Server
System z
Key Server
(Unavailable due to
deadlock)
TKLM
TKLM
DS8700
4) Return unwrapped
symmetric Key
HSM
1. Power on DS8700
2. Request TKLM to Unwrap
theSymmetri c Key by sendi ng
both Key l abel Z and label X
wrapped keys
3. TKLM Unwraps the Symmetri c
Key associated with Key l abelX
(Thi s Key Server has the
pri vatekey for label X)
5. DS8700 now has the
unwrappedsymmetri c key
Key Repository
Wrapped Symmetric Keys
Figure 3-14 Tivoli Key Lifecycle Manager multiple site environment
3.5 Comparing tape encryption methods
There are three methods of tape encryption management that are 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 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
The method names relate to the layers:
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.
y y
T KLM
Cl ear Key
KS
System x IKS
System z CEC
Secure Key
KS
TKLM
LPAR LPAR
LPAR
GKS
DS8700
Key Repositor y
TKLM
System x IKS
Syst em z CEC
Secure Key
KS
LPAR
L PAR
TKLM
LPAR
GKS
Site 1 Site 2
ICSF
Key
Pushes
Recove ry Ke y
w/ Dual C ont rol
Re covery Key
w /D ual Co nt rol
x/ z
Ma nual
Publ ic
K ey
Pushes
x/ z
Ma nual
Publ ic
Ke y
Pushes
Coor dinated M of N
Master Keys
x Manu al
Export / Imp ort or
Backup /R est ore
Key-Pai r Pu sh
System z HSM i n Secure Key mode, DS8700 wi th Tw o Key Labels and Rec overy Key
System z to System z HSM Repl i cati on through ICSF
System x to System x Repl icati on vi a T KLM Backup Restor e
TKLM Expor t/Import to Copy Publ ic Keys Between System z and IKS Key Stor es
Clear Key
KS
Clear Key
KS
DS8700
Key Reposi tory
Tivoli Key Lifecycle Manager: For simplicity, this section only shows EKM as the key
manager. However, the concepts are exactly the same if Tivoli Key Lifecycle Manager were
used as the key manager.
Tivoli Key Lifecycle Manager: For the remainder of this chapter, in all text and figures, the
process flows are the same for EKM and Tivoli Key Lifecycle Manager. You can substitute
the Tivoli Key Lifecycle Manager for EKM for these discussions.
3.5.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 3-15 on page 75 shows a
schematic illustration of SME.
SME is supported on z/OS, z/VM, z/VSE, z/TPF, Linux on System z, and a number of
open systems platforms. On z/OS, z/VM, z/VSE, z/TPF, and Linux on System z, SME is the
only encryption method that is 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 support SME:
AIX
Microsoft 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.
Disadvantages are its policy granularity on open systems, the additional responsibilities for
the storage administrator, and the dependency of data access on the availability of 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 at the 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.
Figure 3-15 System-Managed Encryption (SME)
System-Managed Encryption for open systems
You set up encryption policies that specify when to use encryption 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 and Medium Changer Device Drivers for AIX,
HP-UX, Linux, Solaris and Windows, GC27-2130-06, and the planning and operator guide for
your tape library.
On open systems, this support is described as in-band where tape drive requests to the EKM
component travel over Fibre Channels to the server hosting EKM.
System-Managed Encryption for System z
On z/OS encryption, you set up policies specifying when to use encryption in Data Facility
Storage Management Subsystem (DFSMS). You can also use additional software products,
such as IBM Integrated Cryptographic Service Facility (ICSF) and IBM Resource Access
Control Facility (RACF). EKM performs the key generation and management. EKM runs 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 19, Implementing TS7700 tape encryption on page 613. Or,
refer to the white paper, IBM Virtualization Engine TS7700 Series Encryption Overview, which
is available at this website:
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 Manager
Policy
Application
Layer
System
Layer
Library
Layer
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 System z. It 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, which is shown in Figure 3-16, 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 the first-specified EKM path addresses. The effect on
the controller service requirements is minimal.
The controller performs these actions:
Reports drive status in SMIT displays
Passes encryption-related errors from the drive to the host
Reports encryption failure unit checks to the host
You must reconfigure the controller when new encryption drives are introduced for attachment
or when an encryption-capable drive is enabled for encryption.
Figure 3-16 In-band encryption key flow
Out-of-band key flow
Out-of-band key flow, which is shown in Figure 3-17 on page 77, occurs between EKM and
the tape drive through a subsystem proxy, which is located in the 3592 controller or TS7700
Encryption
Key
Manager
Encryption
Control
FICON
Proxy
System z
Subsystem
Proxy
TS1120 Tape
Controller
or 3592-J70
TS1120
Tape Drive
Library Manager
3953 / 3494
Drive
Interface
Key
Exchange
Interface
ESCON/
FICON
Interface
Library
Manager
Interface
IOS
Virtualization Engine on the EKM interface. The effect on the 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 perform these functions:
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 can enter up to two EKM IP/domain addresses (and up to two ports) for each controller,
and two domain name server IP addresses.
Figure 3-17 Out-of-band encryption key flow
3.5.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 3-18 on page 78 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
Encryption
Key
Manager
Encryption
Control
FICON
Proxy
System z
Subsystem
Proxy
TS1120 Tape
Controller
or 3592-J70
TS1120
Tape Drive
Library Manager
3953 / 3494
Drive
Interface
ESCON/
FICON
Interface
Library Manager
Interface
TS1120
Tape Drive
(Back End)
EKM
Interface
TS7700
Virtualization
Engine
Subsystem
Proxy
EKM Interface
Drive
Interface
Library
Manager
Interface
basis. LME requires additional responsibilities for the storage administrator as compared to
AME. Data access depends on the availability of EKM and the key path.
In most open systems environments, LME is the preferred method for tape encryption.
Figure 3-18 Library-Managed Encryption (LME)
LME can be implemented in these tape libraries:
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 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 barcode encryption policies, 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 operators guide.
The following IBM tape libraries support Library-Managed Encryption:
IBM System Storage TS3500 Tape Library
IBM TotalStorage 3494 Tape Library
Encryption
Key Manager
Policy
Application
Layer
System
Layer
Library
Layer
3.5.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 flows.
SME and LME encryption processes
Figure 3-19 on page 80 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 servers can be
the same server or separate servers, because whether the server is the same or not does not
affect the outcome.
We assume that a certificate from a business partner has 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 EKM send it a data
key and to encrypt the data key using the public KEKs aliased by the two KEK labels.
EKM validates that the drive is in its list of valid drives. After validation, EKM obtains a random
data key from cryptographic services. EKM then retrieves the public halves of the KEKs
aliased by the two KEK labels. EKM then requests that cryptographic services create two
encrypted instances of the data key using the public halves of the KEKs, therefore, creating
two externally encrypted data keys (EEDKs).
EKM sends both EEDKs to the tape drive. The drive stores the EEDKs in the cartridge
memory (CM) and three locations on the tape. EKM also sends the data key to the drive in a
secure manner. The drive uses the separately secured data key to encrypt the data.
Two modes are available for creating the EEDK:
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.
SME and LME: System-Managed Encryption and Library-Managed Encryption
interoperate with each other. 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.
Figure 3-19 Key and data flow for encryption using SME or LME
SME and LME decryption processes for TS1120
Figure 3-20 on page 81 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 EEDKs 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 EKM to decrypt the data key from the EEDKs. EKM validates that the
drive is in its list of valid drives. After validation, EKM requests that the keystore 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.
EKM asks cryptographic services to decrypt the data key from EEDK2 using the private half
of the KEK associated with EEDK2. EKM then sends the data key 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 EKM takes
place for a write-append.
Obtains KEK labels/methods
Requests DK using
KEK labels/methods
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
Sends EEDKs
Writes EEDKs to
three locations on
tape and into CM
Encrypts write data using DK
EKM
Validates drive in Drive Table
Creates EEDKs
Keystore
Crypto Services TS1120
Figure 3-20 Key and data flow for decryption using SME or LME
3.5.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. The IBM 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 3-21 on page 82.
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.
The IBM Tivoli Storage Manager does not restrict you to using AME. You can also choose
SME or LME to encrypt Tivoli Storage Manager data.
Reads EEDKs from
tape or from CM
Requests unwrap of
DK from EEDKs
Requests KEKs
for EEDKs
Retrieves KEK pairs
Requests unwrap of DK
from EEDKs using KEKs
Sends DK
Encrypts/decrypts
data using DK
EKM
Validates drive in Drive Table
Unwraps DK from EEDKs
Keystore
Crypto Services TS1120
AME: Volumes that are 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, you must use the same database.
Figure 3-21 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).
The following libraries support AME using the TS1120 and TS1130 tape drives:
The following IBM tape drives and libraries support application-managed tape encryption
using LTO Ultrium 4 tape drives:
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 website:
http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/index.jsp
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 3-22 on page 83 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 Figure 3-22 on page 83, a tape drive mounts a tape for encryption. The tape drive then
sends its tape ID or volume serial (VOLSER) to IBM 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
EKM: AME does not use or support EKM.
Policy
Application
Layer
System
Layer
Library
Layer
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.
Figure 3-22 Application-Managed Encryption data flow for encryption
Figure 3-23 on page 84 depicts the flow of data and keys when using AME to read or
write-append an encrypted cartridge. In this diagram, IBM 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 the IBM Tivoli Storage Manager. The IBM Tivoli
Storage Manager looks up that tape ID in its internal database and locates the entry that is
associated with it. Tivoli Storage Manager then decrypts the data key from the entry. The IBM
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
Data Key Tape ID
AES Data Key3 Tape3
Database
AES Data Key2 Tape2
... ...
AES Data Key1 Tape1
Tape
Drive
Tape
AES 256
Encrypted Data
Encrypted
Data
Tape ID
Generate Data Key
Store Data Key in DB
Tape ID
Encrypt Data
with Data Key
Data Key
Figure 3-23 Application-Managed Encryption data flow for decryption
3.5.5 Mixed mode example
In the previous sections, we described how encryption works with various tape encryption
methods. This section describes a mixed environment, using multiple types of tape encryption
methods. In reality, an enterprise likely has several types of systems. The tape solutions can
comingle and allow all the disparate setups to take advantage of tape data encryption.
In Figure 3-24 on page 85, 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 librarys control unit to have network access.
TSM
Server
Data Key Tape ID
AES Data Key3 Tape3
Database
AES Data Key2 Tape2
... ...
AES Data Key1 Tape1
Tape
Drive
Tape
AES 256
Encrypted Data
Encrypted
Data
Tape ID
Search Table for
Tape ID
Retrieve DataKey
from Database
Tape ID
Decrypt Data
with Data Key
Data Key
Decrypted
Data
Figure 3-24 Encryption in a mixed environment
ATL
FC
3592
RS422
CU
(J70 or C06)
3592
DFSMS
KS
ICSF
FICON
proxy
System z z/OS
Uses ICSF's
crypto services
& key store
Eth
Open Systems
Server
Linux; zLinux;
i5/OS, AIX;
Windows;
Solaris;
HP-UX
data
Server
(Any instance
of IBM JVM)
KS
IBM JVM
DFSMS
tells drive
to encrypt
a given
cartridge
Eth
FC
EKM
LAN/WAN
Device
Driver
TS3500 or 3494
<OB to drive>
Library
Proxy
LM
keys
DD
keys
FC
any
ATL
Key is
served if
drive is
authorized
<IB to drive>
OB keys
OB keys
(non-z/OS)
IB keys
(z/OS)
Key
req.
EKM
Chapter 4. IBM System Storage 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 describe
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 TS3310 Tape Library
4
4.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. 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 1,000 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
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 4-1 shows the front view of the IBM TS1120 Tape
Drive. You can upgrade the 3592-E05 to a TS1130 drive model 3592-EU6. We describe this
upgrade in 4.1.2, TS1120 characteristics on page 89.
Figure 4-1 TS1120 Model E05
Similar to the previous 3592-J1A and the 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 IBM 3494 Tape Library. It directly attaches to open systems servers through an FC
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)
1
IBM 3592-J70 Tape Controller
1
IBM 3494 Models B10 and B20 Virtual Tape Server
1
(VTS)

in J1A emulation mode
You can install the IBM TS1130 Tape Drive and IBM TS1120 Tape Drive 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
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.
Chapter 4. IBM System Storage tape automation for encryption 89
4.1.1 Tape data encryption support
The IBM TS1130 Tape Drive and IBM TS1120 Tape Drive support 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 later are encryption capable. For currently installed TS1120 drives with a serial
number lower than 13-6500, a chargeable upgrade is available.
You implement the encryption capability through tape drive hardware, and microcode
additions and changes. You can encrypt all 3592 media, including WORM cartridges. In
addition, two applications support encryption: IBM Tivoli Key Lifecycle Manager and IBM
Encryption Key Manager. Both Tivoli Key Lifecycle Manager and EKM use standard key
repositories on supported platforms. A supported server requires either Tivoli Key Lifecycle
Manager or EKM to interface with the tape drive for encryption in a System-Managed
Encryption or Library-Managed Encryption implementation. Refer to Chapter 3, IBM storage
encryption methods on page 49 for a detailed discussion of the EKM program and the three
encryption methods that are 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 because of the time necessary to retrieve, read, and write the encryption key.
4.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.
The following features were introduced with the 3592-J1A and incorporated in the 3592-E05:
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. The 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. The TS1120 can also read and write Enterprise Format 1 (EFMT1
or E1) that is used by the IBM 3592 Model J1A Tape Drive.
Requirement: When attaching to a System z server, supporting tape data encryption
requires the IBM TS1120 Tape Controller Model C06 or the IBM 3592 Tape Controller
Model J70.
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.
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 4-2. You must replace the drive brick (on the left side) but preserve the drive
canister and electronics (on the right side).
Figure 4-2 3592 Drive and canister assembly
Advantages of upgrading TS1120 to TS1130 (3592-EU6)
Upgrading TS1120 to TS1130 provides these advantages:
The 3592-EU6 retains the same serial number as it had as a 3592-E05 (reconfiguring your
EKM or Tivoli Key Lifecycle Manager 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
Buying a new TS1130 provides these advantages:
New warranty
Ethernet service port
Existing TS1120 can still write E1 format cartridges, if necessary
J1A emulation mode: The IBM TS1120 Tape Drive cannot be encryption enabled while
running in J1A emulation mode.
Host attachment
Each IBM TS1120 Tape Drive comes with two independent 4 Gbps FC 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 separate systems to the two FC ports and
use the drive alternatively from each system, but you cannot share a drive between an open
systems environment 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 FC 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 a 3592 Model J70 tape controller.
For the latest details about specific hardware, software, and FC support for the IBM TS1120
Tape Drive, refer to the following website:
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 this website:
http://www.ibm.com/systems/storage/tape/pdf/compatibility/ts1120_isv_matrix.pdf
For supported host bus adapters, refer to this website:
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 that were 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, you can
upgrade it 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 has these characteristics:
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
Capability to read but 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 and 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. The
TS1130 can also read Enterprise Format 1 (EFMT1 or E1) that is used by the IBM 3592
Model J1A Tape Drive.
J1A emulation
The TS1130 does not perform J1A emulation. The TS1130 can still read E1 formatted media.
Host attachment
Each IBM TS1130 Tape Drive comes with two independent 4 Gbps FC 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 separate systems to the two FC ports and
use the drive alternatively from each system, but you cannot share a drive between an open
systems environment 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 the IBM device driver, on most platforms, this
approach provides both load balancing and path failover. For more information, see the IBM
TotalStorage Tape Device Drivers Installation and Users Guide, GC35-0154, which is
available at the following ftp site:
ftp://ftp.software.ibm.com/storage/devdrvr/
The host attachment environments vary:
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
FC 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.
For the latest details about specific hardware, software, and FC support for the IBM TS1120
Tape Drive, refer to the following website:
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 this website:
http://www.ibm.com/systems/storage/tape/pdf/compatibility/ts1120_isv_matrix.pdf
For supported host bus adapters, refer to this website:
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.
4.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 640 GB. 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.
Although 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 4-1 shows the media types and capacity options that are available with 3592 tape
drives.
Table 4-1 IBM TotalStorage Enterprise 3592 media types
Name Media
type
Usable
length
Native
capacity
3592-J1A
(E1 format)
Native
capacity
3592-E05
emulating J1A
(E1 format)
Native
capacity
3592-E05
(E2 format)
Native
capacity
3592-E06
or
3592-EU6
(E3 format)
Data Facility
Storage
Management
Subsystem
(DFSMS)
Data JA 570 m
(1870 ft.
1.6 in.)
300 GB 300 GB 500 GB 640 GB MEDIA5
Extended
Data
JB 785 m
(2575 ft.
6.5 in.)
N/A N/A 700 GB 1000 GB MEDIA9
Economy JJ 204 m
(669 ft.
3.7 in.)
60 GB 60 GB 100 GB 128 GB MEDIA7
WORM JW 570 m
(1870 ft.
1.6 in.)
300 GB 300 GB 500 GB 640 GB MEDIA6
Economy
WORM
JR 204 m
(669 ft.
3.7 in.)
60 GB 60 GB 100 GB 128 GB MEDIA8
Extended
WORM
JX 785 m
(2575 ft.
6.5 in.)
N/A N/A 700 GB 1000 GB MEDIA10
Figure 4-3 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.
Figure 4-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 4-4 shows a
3592 cartridge with a JA label.
Figure 4-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 that your labels adhere to the
guidelines that are in Label Specification for IBM 3592 Cartridges when used in IBM Libraries,
which is available at this website:
http://www.storage.ibm.com/media/tapecartridges/index.html
At this website, 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.
WORM WORM R/W
R/W
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 data cartridges have these
characteristics:
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 that is 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, differs for WORM cartridge types, however. The WORM aspect does not
come from any inherent non-reversible media characteristic, such as permanent WORM on
optical media, compact disc recordable (CD-R), or ablative optical WORM, but rather by the
way that the 3592 drives 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
You cannot reuse a WORM cartridge 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.
4.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 4-5 on page 96 shows a front view of the TS1120 Model C06.
Rekeying: Instead of physically deleting or destroying the data, consider rekeying WORM
cartridges and deleting the key after the rekeying operation.
Figure 4-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.
4.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.
Tape drives: The IBM TS1120 Tape Controller supports 3592-J1A or TS1120 tape drives,
but not IBM 3590 tape drives.
Tape data encryption: 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.
The following enhancements over the 3592-J70 have been incorporated into the IBM TS1120
Tape Controller:
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 FC 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 the increased performance of certain
applications. Currently, DFSMShsm audit is the only application that is 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.
4.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, there are two supported methods to
connect to EKM. The controller can communicate with EKM residing within z/OS through the
FICON or ESCON path, or it can communicate with EKM through a TCP/IP connection.
When the controller communicates with EKM through the FICON or ESCON path, we call this
method 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 method out-of-band
encryption, because data and keys are transferred through separate paths. When using
out-of-band encryption, EKM can reside on any supported platform. Operating systems z/VM,
z/VSE, and z/TPF require out-of-band encryption.
If TS1120 drives that are attached to a TS1120 controller reside in a TS3500, TS3400, or
3494 tape library, you can encryption-enable the drives through the librarys user interface. A
service support representative (SSR) has to encryption-enable stand-alone drives and drives
that are installed in a silo.
For details about System-Managed Encryption, refer to 3.5.1, System-Managed Encryption
on page 74.
4.2.3 Installation with an IBM TS3500 Tape Library
To support the TS1130, TS1120, or 3592-J1A drives in an IBM TS3500 Tape Library, you
install the IBM TS1120-C06 Tape Controller 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 4-2.
Table 4-2 TS1120 tape controllers in 3953 tape frames
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 4-6 shows a sample of a TS1120-C06 installation and configuration in a 3953-F05
base frame with two 3953-F05 expansion frames.
Figure 4-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 FC switch per tape controller
in a 3953 Model F05 Frame to route data between the controller and its associated tape
drives. For reliability, two FC 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 4-7 on page 99. 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 four in another frame.
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
P
O
W
E
R
P
O
W
E
R
Ethernet Switch
LMB
LMA
C06-1
Ethernet Switch
Router
TS7700#2 Fibre Switch
C06 Fibre Switch
C06 Fibre Switch
TS3000 Switch
Monitor/Keyboard
KVM Switch
TS3000 System Console
P
O
W
E
R
P
O
W
E
R
C06-Fibre Switch
C06-Fibre Switch
C06-Fibre Switch
C06-Fibre Switch
C06-Fibre Switch
Ethernet Router
C06-2
Ethernet Router
C06 Fibre Switch
C06-3
C06-4
P
O
W
E
R
P
O
W
E
R
C06-5
C06-6
C06-7
C06-Fibre Switch
C06-Fibre Switch
C06-Fibre Switch
C06-Fibre Switch
C06-Fibre Switch
Ethernet Router
Ethernet Router
C06 Fibre Switch
...
Figure 4-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.
4.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 4-8 on page 100 shows the maximum configuration of TS3400 tape libraries attached
to an IBM TS1120 Tape Controller.
TS1120
Model C06
3953-F05
Frame
L2x
Frame
D2x
Frame
D2x
Frame
D2x
Frame
TS1120
Model C06
3953-F05
Frame
L2x
Frame
D2x
Frame
Figure 4-8 Maximum configuration of TS3400s attached to IBM TS1120 Tape Controller
4.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 4-3.
Table 4-3 TS1120 tape controllers in 3952 tape frames
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 FC 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. You can connect additional drives, up to a total of 16 per
TS1120 controller, in an adjacent 3494 D22 frame or 3494 L22 frame.
Table 4-4 on page 101 lists the frame capacities for drives and controllers.
TS3400
Tape Library
TS3400
Tape Library
TS3400
Tape Library
TS1120
Tape Controller
TS3400
Tape Library
TS3400
Tape Library
TS3400
Tape Library
TS3400
Tape Library
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
Table 4-4 The 3494 maximum frame capacities for drives and controllers
4.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 4-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 4-9 IBM 3592 Model J70 Tape Controller
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 code (FC) 4065,
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
4.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 publications development 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 4-10 shows the IBM Virtualization Engine TS7700 and a schematic layout of its
components.
Figure 4-10 IBM Virtualization Engine TS7700
TS7740 Cache Controller
3956-CC6
TS7740 Cache Drawer
3956-CX6
TS7740 Cache Drawer
3956-CX6
TS7740 Cache Drawer
3956-CX6
TS7740 Node
3957-V06
IO Drawer
Secondary
IO Drawer
Primary
Ethernet Router
Ethernet Router
IBM 3592 Tape Frame
Model F05
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.
We summarize the important characteristics of theTS7700:
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 enablement features can be interconnected with one or two other
TS7700s (TS7720 or TS7740) to provide peer-to-peer copy capability between
virtualization engines for tape using 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 effect 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, it requires an external Library Manager.
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 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.
You assign encryption key labels using the Management Interface on a per-storage-pool
basis. For more information, refer to these publications:
IBM Virtualization Engine TS7700 Release 1.4a: Tape Virtualization for System z Servers,
SG24-7312
IBM Virtualization Engine TS7700 Series Encryption Overview:
ftp://ftp.software.ibm.com/storage/Encryption/Docs/TS7700_Encryption_Support_V1
1.pdf
4.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 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 can attach to open systems and also to
System z hosts. We describe the TS3500 Tape Library in a separate section (4.6, IBM
System Storage TS3500 Tape Library on page 120).
4.4.1 Linear Tape-Open overview
The Linear Tape-Open (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 companies that 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
approach is critical to meeting an open market objective and is accomplished through the
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
separate LTO Ultrium manufacturers. The objective is that 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) ship LTO Ultrium products, and
numerous other licensees ship hardware and media. Obtain more information at the Linear
Tape-Open organization website:
http://www.lto.org
For more information about LTO technology, refer to the IBM System Storage Tape Libraries
Guide for Open Systems, SG24-5946.
Obtain more information at the IBM LTO website:
http://www.ibm.com/storage/lto
The LTO Ultrium road map (Figure 4-11 on page 106) shows the evolution of LTO technology.
At the time of writing this book, IBM Ultrium generation 3 and 4 products are available. The
information in the road map is an indication of possible future developments by the three
consortium members and is subject to change.
LTO: 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:
IBM LTO Ultrium 4 tape drives installed in the System Storage TS2900 Autoloader
System Storage TS3100, TS3200, and TS3310 tape libraries
Figure 4-11 LTO Ultrium road map
4.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 they cannot write in
LTO2 format. The LTO technology consists of the following generations:
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.
LTO5 is the fifth generation of the LTO technology with an uncompressed tape capacity of
1.5 TB per cartridge. A WORM (write-once, read-many) version of the LTO5 cartridge is
also available. LTO5 supports encryption.
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. The LTO Ultrium 4
data cartridge is green. The LTO Ultrium 5 cartridge is red.
Important: Hewlett-Packard, IBM, and Quantum (the successor to Seagate) reserve the
right to change the information in this migration path without notice.
Generation
1
Generation
2
Generation
3
Generation
4
Generation
5
Generation
6
Capacity
(Native)
100 GB 200 GB 400 GB 800 GB 1.6 TB 3.2 TB
Transfer
Rate
(Native)
Up to
20 MB/s
Up to
40 MB/s
Up to
80 MB/s
Up to
120 MB/s
Up to
180 MB/s
Up to
270 MB/s
WORM No No Yes Yes Yes Yes
Encryption No No No Yes Yes Yes
The third generation IBM WORM cartridge is a two-tone cartridge with a steel-blue top and a
platinum (silver) bottom. 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 fits the LTO4 WORM cartridges. Any LTO4 Tape Drive can use them
and can coexist with non-WORM cartridges. Additionally, the LTO4 drive can read and write
WORM and non-WORM LTO3 cartridges.
Figure 4-12 shows IBM LTO3 and LTO4 media. The two-tone cartridges in the picture are
LTO3 WORM media.
Figure 4-12 IBM LTO Ultrium 3 and IBM LTO Ultrium 4 media
Labels
The LTO cartridge label uses the barcode symbology of Uniform Symbol Specification-39. A
description and definition are available from the Automatic Identification Manufacturers (AIM)
specification Uniform Symbol Specification-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).
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 this
website:
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 4-13 shows a barcode label for an LTO1 data cartridge.
Figure 4-13 LTO Ultrium 1 barcode label
4.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 4-14 on
page 109.
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).
Characters allowed: No characters other than uppercase alpha A-Z or numeric 0-9 are
allowed.
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 4-14 IBM System Storage TS2240 Tape Drive Express Model
For more information about IBM TS2240 Tape Drive, see IBM System Storage Tape Library
4.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 4-15 on page 110.
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 low voltage differential (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:
TS2340 Models: 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 4-15 IBM System Storage TS2340 Tape Drive Express Model
For more information about IBM TS2340 Tape Drive, see IBM System Storage Tape Library
4.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 this document:
The TS1040 also supports Application-Managed Encryption (AME) on AIX, Windows Server
2003, Linux, Solaris, and HP-UX.
Figure 4-16 shows the IBM TS1040 Tape Drive.
Figure 4-16 IBM System Storage TS1040 Tape Drive
4.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). You can mount one half-high
IBM LTO3, LTO4, or LTO5 drive in the TS2900. The TS2900 is positioned between a
stand-alone 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. You can mount up to nine cartridges in the Autoloader at a time. See
Figure 4-17.
Figure 4-17 IBM System Storage TS2900 Tape Autoloader
Encryption settings
The TS2900 supports Application-Managed Encryption, by default, when an LTO4 or LTO5
drive is installed. An additional feature, Transparent LTO Encryption, is required for
System-Managed Encryption or Library-Managed Encryption. See Figure 4-18.
Figure 4-18 IBM TS2900 Tape Autoloader encryption settings
4.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 4-21 on page 115.
The TS3100 supports one of these tape drive arrangements:
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
Up to two IBM LTO4 half-high tape drives with a native capacity of 800 GB
Up to two IBM LTO5 half-high drives
The IBM LTO4 and LTO5 tape drives are available with Fibre Channel (FC) and Serial
Attached SCSI (SAS). The LTO4 is also available in SCSI Ultra160 LVD attachment interface.
You can store a total of 24 cartridges in two removable magazines (23 cartridges with the 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 FC LTO4 drives using LTO4 media. Not all
environments support all three encryption methods. For details about platform-specific
support, refer to Chapter 10, Planning for software and hardware to support tape drives on
page 191.
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.
Attachments: Half-high drives do not have FC attachment. You can order the TS3100 with
LTO3 drives with an LVD/SCSI or FC interface or with LTO4 drives with an LVD/SCSI, SAS,
or FC interface. Only LTO4 drives with an FC or SAS attachment interface support
encryption.
Figure 4-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 any of these devices:
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
Four IBM LTO5 half-high tape drives with a native capacity of 1.5 TB
A mix of IBM LTO3 and LTO4 full-high tape drives
The IBM LTO4 and LTO5 tape drives are available with Fibre Channel and Serial Attached
SCSI (SAS). LTO4 also supports SCSI Ultra160 LVD attachment interface.
You can store a total of 48 cartridges (45 with I/O Station enabled) 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 FC LTO4 and LTO5 drives using LTO4 media
and LTO5 media (see Figure 4-20 on page 114).
Interfaces: You can order the TS3200 with LTO3 drives with LVD/SCSI or FC interface,
LTO4 drives with LVD/SCSI, SAS, or FC interface, or LTO5 drives with SAS or FC interface.
Only LTO4 and LTO5 drives with FC or SAS attachment interface support encryption.
Figure 4-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.
metadata that is written on the tape volume by the application. NetBackup is currently the
only backup software that supports Internal Label Encryption Policies (ILEP).
metadata that is written on the tape volume by the application. NetBackup is currently the
only backup software that supports Internal Label Encryption Policies (ILEP).
You set these policies through the web interface, as shown in Figure 4-21 on page 115.
Figure 4-21 Sample TS3200 Encryption configuration panel
Not all environments support all three encryption methods. For details about platform-specific
support, refer to Chapter 10, Planning for software and hardware to support tape drives on
page 191.
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 LTO5, or a mix of LTO3, LTO4, and LTO5, 30 storage slots, and six I/O slots. The
base library module contains all 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 the model 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 Storage Management Initiative - Specification (SMI-S)
agent for monitoring the library using tools, such as 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. You can
access all library Operator Panel functions 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 FC 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.
backup software that supports Internal Label Encryption Policies (ILEP).
backup software that supports Internal Label Encryption Policies (ILEP).
You set these policies through the web interface.
Figure 4-22 TS3310 Encryption configuration interface
Not all environments support all of these three encryption methods. For details about
platform-specific support, refer to Chapter 10, Planning for software and hardware to support
tape drives on page 191.
For more information about IBM TS3310 Tape Library, refer to IBM System Storage Tape
Figure 4-23 on page 118 shows a TS3310 configuration with the base unit model L5B and
one expansion unit model E9U.
Figure 4-23 IBM System Storage TS3310 Tape Library
4.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 4-24 shows the IBM TS3400 Tape Library.
Figure 4-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 1,000 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 separate applications.
The TS3400 attaches through the FC 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 FC 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 4.2, IBM System
Storage TS1120 Tape Controller on page 95). 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 attach directly 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 systems 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 TS1130 tape 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.
The following list summarizes the standard features and capabilities of the IBM System
Storage TS3400 Tape Library:
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 operating systems
support the TS3400 as an autoloader in Auto Mode. You might require later operating system
versions to support tape encryption. Refer to Chapter 10, Planning for software and
hardware to support tape drives on page 191.
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 that is written on the tape volume by the application.
NetBackup is currently the only backup software that supports Internal Label Encryption
Policies.
The IBM TS1120 or TS1130 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 Internal Label Encryption
Policies.
In a System z environment, SME is the only option. You set the policies through the web
interface.
4.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. 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 more drive types and operating
platforms, 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, and TS1050 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. Now, you can upgrade both library and drive firmware nondisruptively, that is,
without interrupting the normal operations of the library.
Figure 4-25 on page 121 shows 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 only, or
TS1130 only) or 6,887 (frames for LTO only) cartridge storage cells.
Figure 4-25 Maximum and minimum IBM IBM TotalStorage 3584 Tape Library configuration
The IBM TS3500 Tape Library provides these functions:
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 non-IBM servers
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
4.6.1 TS3500 frames
Seven frames are currently available to build an IBM IBM TotalStorage 3584 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 drive:
LTO drives (model x53)
3592 drives, 3592-J1A, TS1120, and TS1130 (model x23)
Storage frames (model Sxx) do not support drives, but they do support higher cartridge
density.
Optional second accessor is made available through the addition of model HA1 frames.
You can intermix all currently available frame models with each other and with installed frame
models with the provision that there is only one base frame in each library. Installed frame
models include the L22, L32, L52, L53, D22, D32, D52, and D53.
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 it can attach to
up to 15 models D23 or D53. The L23 frame provides the major library components for the
whole library, whether the library consists of a single frame or multiple frames. You must
attach the Expansion frames to the right of the L23 frame. In addition, You can attach model
S24 or S54 storage only frames.
The L23 frame provides cartridge slots for 3592 media and support for up to twelve IBM
TS1130, TS1120, TS1050, 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 that are 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 drives 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 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 an L23 or L53 frame and optionally to other expansion frames.
The D23 frame offers space for a maximum of 400 3592 media. You can install up to 12
TS1130, TS1050, TS1120, or 3592-J1A (collectively referred to as 3592) drives 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.
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.
Advanced Library Management System: Installing the TS1130 Tape Drive in a TS3500
Tape Library requires Advanced Library Management System (ALMS).
ALMS: Installing the TS1130 and TS1050 tape drive in a TS3500 tape library requires
ALMS.
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 connect to
an L23 or L53 frame and optionally to other expansion frames.
The S24 frame offers space for a maximum of 1,000 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 LTO5, LTO4, or
LTO3 FC tape drives.
The number of available LTO cartridge storage slots ranges from 64 to 287. The minimum
configuration provides 64 slots that are 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, you can attach models S24 or S54 storage-only frames 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
connected to an L23 or L53 frame and optionally to other expansion frames.
The D53 frame offers space for a maximum of 440 LTO media. You can install up to 12
TS1030, TS1040, or 1050 LTO FC tape drives 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 can 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 connect to
an L23 or L53 frame and optionally to other expansion frames.
The S54 frame offers space for a maximum of 1,320 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 these subjects:
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.
ALMS has the following capabilities:
Dynamic partitioning (storage slot pooling and 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
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 an 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 Users Guide, GA32-0589.
ALMS is an optional feature for existing IBM TS3500 tape libraries; however, it is a mandatory
feature for new installations when you attach the library to a System z server or when you
install the IBM 3584 Model HA1.
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. You can use the ALMS Virtual I/O function 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 differ 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.
Each one of these 3953 logical Library Manager partitions can have up to three logical
libraries defined to it (identical to the logical libraries of a 3494), two of which can be TS7700
Virtualization Engines or Virtual Tape Servers (VTSs). The 3953 Library Manager supports
the configuration of 16 subsystems per 3953 tape system. A subsystem is a TS7700
Virtualization Engine, a 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).
ALMS: Although ALMS is not an absolute requirement for encryption, it is important that
you order ALMS.
TS7740: When using TS7740 licensed internal code 8.5.0.xx and later, a separate 3593
Library Manager is no longer required to attach a TS3500 to a TS7740. This function is
integrated into the TS7740.
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, because the library manager function is now part of the TS7700.
Figure 4-26 illustrates the attachment of a TS3500 library to System z hosts. The illustration
shows all 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.
Figure 4-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. The following summary shows equipment that is required or
installed according to client system requirements:
IBM TotalStorage 3953 Tape Frame Model F05
This model 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:
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
Open
Systems
Host
TS7700
LAN
Switch
Fibre Channel
TS1120
Model C06
ESCON
FICON
System z
Host
FC Switch (Redundant)
Logical Library Logical Library
FICON
Library Manager Complex
System z
Host
Library
Manager
Library Manager
FC Switch (Redundant)
Logical Library
IBM TS7700 Virtualization Engine or 3494 Virtual Tape Server models B10 or B20
IBM System Storage TS1120 Model C06 or 3592 Model J70 tape controller
FC switches to attach the IBM 3592 Tape Drives to the controllers
For detailed information about the IBM 3953 Tape System, refer to IBM TS3500 Tape Library
with System z Attachment A Practical Guide to Enterprise 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
Microsoft 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 failover is transparent to the running
application.
Encryption: IBM 3592-J1A Tape Drives are not encryption capable; you must have
TS1130 or TS1120 tape drives to use tape encryption.
TS7740: When using TS7740 licensed internal code 8.5.0.xx and later, a separate
3593 Library Manager is no longer required to attach a TS3500 to a TS7740. This
function is integrated into the TS7740.
Important: Have control path drives in separate library frames for increased redundancy.
See Figure 4-27 on page 128.
Figure 4-27 Redundant control paths to the library controller
Data path failover
Data path failover and load balancing exclusively support native FC 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 Microsoft Windows
hosts. Load balancing is supported for AIX, HP-UX, Linux, Solaris, and Microsoft Windows.
Refer to the IBM Tape Device Driver Installation and Users 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 Librarys 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 SMI-S support. Accessing the SMI-S
interface requires the monitor or superuser role.

DRIVE
1
DRIVE
2
Li br a r y
CONTROLLER
DRIVE
3
DRIVE
4
DRIVE
5
DRIVE
6
Two control paths
enabled
FC
adapter
Server
smc0
smc1
You can update the firmware for the library and drives 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 that 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 (HD) frames, which allow more cartridges to be
stored inside the library in the same physical footprint in the data center. You must have the
ALMS feature 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 slot is Tier 2, and so on. The
maximum tier in an LTO Ultrium (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 4-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 4-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 cartridges have to be moved out of
the way. Depending on your usage, this delay might be significant.
Figure 4-29 shows a side view of an HD S54 frame.
.
Figure 4-29 S54 frame side view
Host platforms and device drivers
A variety of operating systems support the IBM TS3500 Tape Library. For a current list of the
host software versions and release levels that support the TS3500 Tape Library, go to this
website:
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
IBM TS3500 Tape Library with System z Attachment A Practical Guide to Enterprise 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 and Internal Label
Encryption Policies.
When using Barcode Encryption Policy, be aware that policies are based on ranges of
cartridge volume serial numbers. You can specify the volume serial ranges for the volumes 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.
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 can choose one of the
following polices, which you set through the Tape Library Specialist web interface:
The System z environment only supports SME.
For more information, refer to the Operators Guide for your tape library.
4.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, and 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 can 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.
Figure 4-30 on page 132 shows a 3494 Tape Library configuration consisting of a library
frame, a driveless storage frame, and two drive frames.
Note: With the 7 November 2008 firmware, you can configure the TS3500 with
independent key managers for each logical library. This firmware requires that the ALMS
feature is installed and enabled.
Note: SME and LME require an Encryption Key Manager (EKM) or Tivoli Key Lifecycle
Manager. For LME, you enter the IP addresses of the primary and optionally backup EKMs
or Tivoli Key Lifecycle Managers on the TS3500 library through the TS3500 Specialist.
These settings can refer to the physical library or be configured on a per logical library
basis. Each logical library can be configured with its own EKM, Tivoli Key Lifecycle
Manager, Tivoli Key Lifecycle Managers, or EKMs.
IBM 3494: Effective December 2006, IBM withdrew from marketing all Model Lxx Control
Unit Frames of the IBM 3494 Tape Library. You can 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 4-30 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
can exclude ranges of volume serial numbers from encryption. LME also allows for the
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 can select one of the following
policies, which you set through the Tape Library Specialist web interface:
The System z environment only supports SME.
Chapter 5. Full Disk Encryption technology
in disk subsystems
This chapter provides information about the IBM Full Disk Encryption (FDE) technology.
In this chapter, we describe the following topics:
FDE fundamentals on page 134
Hardware implementation details on page 135
FDE disks in storage products on page 136
5
5.1 FDE fundamentals
IBM disk subsystems are designed to use Full Disk Encryption (FDE) drives to provide
encryption capable storage for clients, which means every piece of data is written encrypted
to the disk surface. If the FDE feature is activated, only authorized systems can unlock the
disk and read the data from it.
Every FDE drive has its own symmetric key called the encryption key, which is used for both
encryption and decryption. Dedicated encryption hardware transfers the data at full interface
speed with no effect on performance; the data transfer is transparent from the host side. The
encryption key is stored inside the drive. It is not accessible externally. You cannot turn off the
encryption feature at the drive level.
The FDE drives leave manufacturing in the unlocked state, so that all the disk operations are
enabled, by default. In order to protect the data (to limit the read/write access), you can
activate the locking mechanism by establishing new authentication key. This key wraps
(encodes) the encryption key. Therefore, from that point forward, the authentication key must
be provided to the drive so that the drive can unwrap its encryption key for encoding and
decoding the data transfer. The authentication key must be stored outside of the drive,
available only for authorized systems. When the drive is powered off, it forgets its state, so it
becomes locked. Every access request is denied while it is in locked state. The proper
authentication key is needed to unlock the drive temporarily. If the authentication process
succeeds, client data can be accessed without any limitations until the next power loss. See
Figure 5-1 to get an overview of the key relationship.
Figure 5-1 Authentication and encryption key relationship
The major benefit of the FDE feature is that without knowing the authentication key, it is
theoretically impossible to decrypt the data on the disk:
All the client data on the relocated drive remains safe, no one can access it. So, the data is
protected against theft or any kind of illegal access.
In case of hardware failure, you can send the drive back to the vendor for failure analysis
without worrying about the data on it.
The authentication key must be stored in a safe and reliable place. Unauthorized access to
the key undermines the FDE security. The authentication key must be available continuously
in order to unlock the drive whenever it is necessary. Losing all the copies of the
authentication key yields to permanent data loss.
If the data is no longer needed, the drive can generate a new encryption key. By using the
new encryption key, the already encrypted data (with the previous key) cannot be decoded,
and it becomes cryptographically erased (or cryptoerased). The advantage of this process is
being instant and secure, while rewriting the full disk surface takes much more time. The
Hard Disk Drive
encrypted
data
plaintext
data
encryption key
authentication key
FDE engine
auth. key unwraps the encrypt. key
to unlock the drive
Chapter 5. Full Disk Encryption technology in disk subsystems 135
authentication key is not required to issue the cryptoerase command, so every locked drive
can be unlocked (reused) in this way. However, know that the data is lost forever.
5.2 Hardware implementation details
IBM enterprise-class FDE disks are available in 146 GB, 300 GB, or 450 GB capacities with
15K RPM speed. These drives were introduced first in DS8000 high-end storage in 2008.
Now, the DS5000 family supports these drives, too. Because the hardware differs, you must
order the FDE drives from the factory; the old drives do not support the FDE mode.
The IBM FDE technology is based on open standards. For data encryption, The IBM FDE
technology uses the Advanced Encryption Standard (AES) 128
1
event control bit (ECB)
algorithm; every 128 bits of data are encrypted or decrypted in real time without degrading
the communication speed. The encryption key length is 128 bits (16 bytes). The encryption
key length is permanently stored in the secure partition of the disk. This area of the disk is
highly protected and unreadable by the user, because it is allocated outside of the regular
logical block address (LBA) space. Figure 5-2 shows this area on the disk, which only the
drive firmware can access.
You can partition the surface of the disk by defining bands on it. Each band has its own
access control settings. By default, only band0 has been created, so the same rule applies for
the whole disk capacity. Adding more bands enables you to create exceptions; a maximum of
16 bands are supported. The bands cannot overlap each other. This feature is useful, when
you must have an unlocked space for device adapter metadata, dumps, and so forth, and
client data goes to the locked area. For security reasons, read/write operations cannot cross
band margins. Figure 5-2 shows the widely used band settings.
Figure 5-2 Typical band settings
Modifying the security setting (such as banding or crypto erasing) requires password
authentication. This password is initialized in the factory and saved as the message ID
(MSID). Initially, the host can authenticate using the MSID value, which is printed on the drive
label and available electronically across the interface. Before placing the drive into service,
the host must take ownership of the drive by replacing the default password to a new system
identifier (SID). Afterward, you can only use the SID for authentication. Predefined security
roles, such as Admin or Locking/Erasing, have their own passwords, all of which are initialized
with the MSID value.
1
AES specification: http://www.csrc.nist.gov/publications/fips/fips197/fips-197.pdf
band0
FDE drive with one band (default setting, as used in DS5000):
FDE drive with two bands (as used in DS8000):
L
B
A
0
m
a
x
.
L
B
A
secure
partition
user addressable space
(can be locked or unlocked)
band1
L
B
A
0
m
a
x
.
L
B
A
secure
partition
customer data
(locked)
band0
metadata
(unlocked)
In order to harden the security, you can load only signed firmware on FDE drives., which
prevents the user from modifying the firmware to offload the encryption key. Only the drive
vendor can provide new firmware releases.
possible to prevent it from causing other problems on the interface. During the part
replacement, the drive is locked and the data cannot be accessed without its authentication
key.
5.3 FDE disks in storage products
The FDE hard disk drives are optional features of both DS5000 and DS8000 storage
systems.
The easiest way to determine whether a DS5000 contains FDE drives is to open the Storage
Manager GUI Physical Components view for each RAID array. Then, click Show FDE to mark
the FDE drives inside a storage enclosure, as shown in Figure 5-3.
Figure 5-3 FDE drive locations in DS5000
The DS8000 has a key logo label affixed to each handle of the FDE drives. Using the DS8000
Hardware Management Console (HMC) GUI, you can list the storage enclosure
field-replaceable unit (FRU) parts, as shown in Figure 5-4 on page 137. The Description fields
show the FDE attributes. Currently, FDE intermix is not allowed, so you only need to check
one enclosure closely, because the rest of the system must have the same encryption
capabilities.
Chapter 5. Full Disk Encryption technology in disk subsystems 137
Figure 5-4 FDE drives in DS8000
Part 2 IBM System Storage
DS5000
In this part, we introduce the DS5000 data storage encryption capabilities.
Part 2
Chapter 6. Understanding Full Disk
Encryption in DS5000
This chapter describes the capabilities and advantages of the Full Disk Encryption (FDE) disk
drives that are used in DS5000 storage systems. This chapter also describes how to
implement security on DS5000 storage systems that are equipped with FDE disks. This
chapter contains the following topics:
FDE disk drives
FDE security authorizations
FDE key terms
6
6.1 FDE disk drives
Full Disk Encryption (FDE) disk drives enable you to significantly reduce the security
vulnerabilities of stored data. FDE disk drives that adhere to the Trusted Computing Group
(TCG) enterprise security subsystem class specification are National Security
Agency-qualified and provide unparalleled security with government-grade encryption.
Multiple technologies are required to protect data that is stored on hard disk drives against
various threats. FDE drives ensure the security of stored data through the following methods:
Securing stored data against a breach: If an unauthorized user gains possession of a disk
drive that contains encrypted data (the drive is removed from the data center or powered
down), the data is protected.
Permanently erasing stored data: Secure erase provides fast, permanent erasure of data
on drives that are planned for reuse or disposal.
FDE drives secure data against threats when the drive eventually leaves the owners control,
but the FDE drives cannot protect data from threats that occur within the data center or on the
network. If an attacker gains access to a server and can access an unlocked drive, the
attacker can read the clear text that comes from the drive. Remember that drive-level
encryption technology does not replace the access controls of the data center; rather, it
complements them.
6.1.1 Securing data against a breach
Drives with the Full Disk Encryption technology are security capable. Each FDE drive comes
from the factory in the Security Capable (security-disabled) state. In this state, the FDE drives
behave exactly like the non-FDE drives. The data that is stored on them is not protected when
the drives are removed from the storage subsystem. They can be moved from one storage
subsystem to another storage subsystem without having to be unlocked with a security key
file. They can also be used as part of a RAID array that is composed of non-encrypting
(non-FDE) disks. However, a RAID array that is composed of Security Capable FDE and
non-FDE drives cannot be converted into a secured RAID array at a later time, leaving the
data on the FDE drives unprotected if they are removed from the storage subsystem.
The IBM DS storage subsystem controllers can apply security to every FDE drive in a RAID
array that is composed entirely of FDE drives. The controller firmware creates a security key
and activates the encryption function of the drive, which causes each FDE disk drive to
randomly generate an encryption key that is embedded on the disk. When security is
enabled, the FDE drive automatically performs full disk encryption:
When a write operation is performed, clear text enters the disk and is encrypted before it is
written to the media, using the disk encryption key.
When a read operation is performed, encrypted data that is read from the media is
decrypted before it leaves the drive.
During normal operation, whether the FDE drive is in the Security Capable or Security
Enabled state, it behaves the same as a non-encrypting disk to the storage subsystem. A
security-enabled FDE drive is constantly encrypting data. Disk encryption cannot be
accidentally turned off. The disk encryption key is generated by the drive itself, is stored on
the disk, never leaves the disk, and is unique to that drive alone. To ensure that security is
Important: No single security implementation can effectively secure all levels of data
against all threats.
Chapter 6. Understanding Full Disk Encryption in DS5000 143
never compromised, an encrypted version of the encryption key is stored on the disk drive
only. Because the disk encryption key never leaves the disk, you might not have to
periodically change the encryption key, the way a user might periodically change the
operating system password.
6.2 Creating a security key
With full disk encryption, the process of securing a drive is simple and consists of enabling
security on the DS5000 and then securing the specific security-capable RAID arrays where
the data is stored.
Enabling security on the DS5000 storage subsystem is a one-time process, unless you
decide at a later date to change the security key. Separate security keys are not required for
each drive. To enable security on the DS5000, you must purchase an IBM DS Disk
Encryption premium feature key and enable the feature in the DS5000 subsystem, using the
instructions that come with the premium feature key entitlement kit.
A security key must then be generated for the storage subsystem. The process of creating a
security key requires you to enter the security key identifier, the passphrase, and the security
key file name and location. The controllers create the security key and use this key to secure
the security-enabled FDE drives. The controllers use one security key to unlock all of the
security-enabled FDE drives in the storage subsystem even though each FDE drive has its
own unique encryption key. An encrypted version of the security key is obfuscated in the
storage subsystem to maintain security from malicious hackers. You cannot see the security
key directly, but its encrypted version is saved in a backup file at a location that you specify. In
addition to the saved location that you specify, the storage manager also saves a copy of the
file in the default location, which is ...\IBM_DS\client\data\securityLockKey in a Microsoft
Windows environment or in /var/opt/SM/securityLockkey in AIX, Linux, Solaris, and
Hewlett-Packard UNIX (HP-UX) environments.
The security key file contains the security key identifier and the encrypted security key. The
passphrase is not stored anywhere in the storage subsystem or in the security key file. The
controller uses the passphrase to encrypt the security key before it exports the security key to
the security key file. The security key identifier is stored in the security key file so that you can
identify which storage subsystem the security key file is for.
The security key file provides protection against a corrupted security key or the failure of both
controllers in the storage subsystem. The security key file is also needed to unlock
security-enabled FDE drives when they are moved from one storage subsystem to another
storage subsystem. In these cases, the security-enabled FDE drives remain locked until the
drives are unlocked by the security key that is stored in the security keyfile. To decrypt the
security key in the security key file, you must provide the same passphrase that was entered
when the security key file was generated. The drive then determines whether its security key
and the security key that was provided by the storage subsystem are the same. If they are the
same, data can be read from and written to the security-enabled FDE drives.
Important: The passphrase is used only to protect the security key in the security key file.
Anyone who can access the Subsystem Management window can save a copy of the
security key file with a new passphrase. Set a storage subsystem password for each of the
DS5300, DS5100, or DS5020 storage subsystems that requires you to provide a password
when any configuration changes are made, including creating and changing the security
key.
After the storage subsystem controller creates the security key, the RAID arrays can be
changed from a state of Security Capable to a state of Security Enabled. The Security
Enabled state requires the RAID array FDE drives to be unlocked during the drive power up
process by using the security key to access the data that is stored on the drives. Whenever
power is applied to the drives in a RAID array, the drives are all placed in the Security Locked
state. They are unlocked only during drive initialization with the storage subsystem security
key. The Security Unlocked state makes the drives accessible for the read and write activities.
After they are unlocked, the drives remain unlocked until the power is removed from the
drives, the drives are removed and reinserted in the drive bays, or the storage subsystem
power is cycled.
After a drive is secured, if it is ever powered down or removed, the drive becomes locked. The
encryption key within that drive will not encrypt or decrypt data, making the drive unreadable
until it is unlocked by the controllers.
After authentications are established and security is enabled on an array, the encryption of
write operations and decryption of read operations that take place inside the FDE drive are
not apparent to the user or to the DS5000 controllers. However, if a secured drive is lost,
removed, or stolen, the drive becomes locked, and the data that is stored on the disk remains
encrypted and unreadable. Because an unauthorized user does not have the security key file
and passphrase, gaining access to the stored data is impossible.
6.3 Changing a security key
When you change a security key, a new security key is generated by the controller firmware.
The new security key is obfuscated in the storage subsystem, and you cannot see the
security key directly. The new security key replaces the previous key that is used to unlock the
security-enabled FDE drives in the storage subsystem. The controller negotiates with all of
the security-enabled FDE drives for the new key. However, an n-1 version of the security key
is also stored in the storage subsystem for protection in case something prevents the
controllers from completing the negotiation of the new security key with the security-enabled
FDE drives (for example, loss of storage subsystem power during the key change process). If
this type of event happens, you must change the security key so that only one version of the
security key is used to unlock drives in a storage subsystem. The n-1 key version is stored in
the storage subsystem only. It cannot be changed directly or exported to a security key file.
A backup copy of the security key file is always generated when you change a security key
and must be stored on another storage medium in case of controller failure, or for transfer to
another storage array. You participate in the creation of the security key identifier, the
passphrase, and the security key file name and location when you change the security key.
The passphrase is not stored anywhere in the storage subsystem or in the security file. The
controller uses the passphrase to encrypt the security key before it exports the security key to
the security key file.
6.4 Security key identifier
For additional protection, the security key that is used to unlock FDE drives is not visible to the
user. The security key identifier is used to refer to a security key value instead. You can see
the security key identifier during operations that involve the drive security key file, such as
creating or changing the security key.
Figure 6-1 shows an example of the security key identifier field when you perform a change
security key operation.
Figure 6-1 Changing the security key
The Change Security Key Complete window shows that the security key identifier that was
written to the security key file has a random number appended to the security key identifier
that you entered in Figure 6-1 and to the storage subsystem worldwide identifier. Figure 6-2
shows an example of the random number part of the security key identifier.
Figure 6-2 Change the Security Key Complete window
The security key identifier field in the FDE Drive Properties window includes a random
number that is generated by the controller when you create or change the security key.
Figure 6-3 shows an example of the random number. The random number is currently
prefixed with 27000000. If all the secured FDE drives in the storage subsystem have the
same value in the security key identifier field, they can be unlocked by the same security key
identifier. Note that the Security Capable and Secure fields in the Drive Properties window
show whether the drive is security capable and whether it is in a Secure (Yes) or Unsecured
(No) state.
Figure 6-3 Drive Properties window: Secure FDE drive
Figure 6-4 on page 147 shows an example of the security key identifier that is displayed in the
file information field when you select a security key backup file to unlock the secured drives in
the storage subsystem. The security key identifier or LockKeyID, which is shown in the file
information field, contains the characters that you entered in the security key identifier field
when you created or changed the security key, along with the storage subsystem worldwide
identifier and the randomly generated number that is displayed in the security key identifier of
all secured FDE drives. This information is delimited by a colon.
For example, this LockKeyID contains the following information:
Passw0rdplus3:600a0b800029ece6000000004a2d0880:600a0b800029ed8a00001aef4a2e4a73
Security key identifier that you specified, for example, Passw0rdplus3
Storage subsystem worldwide identifier, for example, 600a0b800029ece6000000004a2d0880
Randomly generated number: 600a0b800029ed8a00001aef4a2e4a73
Figure 6-4 Select File: LockKeyID
Figure 6-5 on page 148 shows an example of the drive properties for an unsecured FDE
drive.
Unsecured FDE drive: The security key identifier field for an unsecured FDE drive
contains zeros. The Security Capable field value is yes, and the Secure field value is no,
indicating that this drive is a security capable but unsecured FDE drive.
Figure 6-5 Drive Properties: Unsecured FDE drive
6.5 Unlocking secure drives
You can export a RAID array with its security-enabled FDE drives to another storage
subsystem. After you install those drives in the new storage subsystem, you must unlock the
security-enabled FDE drives before data can be read from or written to the drives. The
security key on the new storage subsystem differs from the security key on the original
storage subsystem and cannot unlock the drives. You must supply the security key from a
security key file that you saved from the original storage subsystem. In addition, you must
provide the passphrase that was used to encrypt the security key to extract the security key
from the security key file. After you unlock the drives by using the security key in the security
key file, the controller negotiates the existing security key for these drives so that only one
version of the security key is used to unlock drives in a storage subsystem.
You do not have to provide the security key file to unlock the security-enabled drives in a
storage subsystem every time that the storage subsystem power is cycled or that the drives
are removed and reinserted in the same storage subsystem. The controllers always keep a
copy of the current and the previous (n-1) values of the security key to unlock these drives.
However, if the drives are removed from the subsystem and if the security key is changed
more than two times in the same subsystem, the controllers will not have the security key to
unlock the drives when they are reinserted in the same storage subsystem.
6.6 Secure erase
Secure erase protects FDE drives from security threats when they are eventually retired,
returned, discarded, or re-purposed. When these drives are moved from the data center or
reused, it is critical that you permanently erase the data on the disks so that it is not
vulnerable. Discarded drives might still have residual data that can be reconstructed by an
unauthorized user. Secure erase protects against this threat by cryptographically erasing the
data.
The traditional methods that are used to permanently erase data often prove to be expensive
and slow and might not provide the highest level of data erasure. Traditional methods might
also put the drives beyond your control and therefore subject them to a data breach. Secure
erase provides the following advantages compared to traditional methods:
Immediate, cryptographic data erasure
Lower overall costs
A higher level of media sanitation according to the National Institute of Standards and
Technology (NIST)
Secure erase with FDE drives provides the immediate erasure of data without requiring the
removal of the drive from the data center. With just a few clicks, you can quickly reuse or
discard a drive. You save money with secure erase, because drives are not destroyed but
instead are erased to be used again and again. This capability eliminates the need to destroy
a drive, still secures warranty and expired lease returns, or enables drives to be reused
securely. NIST considers secure erase to be a type of data purging, which is regarded as a
higher level of data sanitation than traditional methods.
Secure erase prompts the FDE drive to permanently erase the current encryption key and
replace it with a new randomly generated encryption key within the drive. You then use the
new drive encryption key to encode and decode all the data on the disk. After the encryption
key is changed, any data that was previously written to the disk becomes unintelligible. Data
that was encrypted with the previous encryption key is unintelligible when it is decrypted with
the new encryption key (which includes all bits, headers, and directories). The data is
completely and permanently inaccessible.
6.7 FDE security authorizations
Table 6-1 on page 150 identifies and describes the authorization parameters that are used to
implement security on DS5000 storage systems.
Important: Always back up the data in the storage subsystem to secured tape to prevent
the loss of data due to malicious acts, natural disasters, abnormal hardware failures, or
loss of the FDE security key.
Table 6-1 Security authorizations
Parameter Description Where is it located
and how is it
managed
How is it generated
Encryption key The encryption key is
used to encrypt and
decrypt data on the
FDE disk drive.
It is stored on and is
managed by the FDE
disk drive:
Is never
transferred from
the drive
Each drive has its
own unique
encryption key
The encryption key is
generated when the
drive is manufactured
and then regenerated
at the client site (by a
command from the
controller to the drive)
to ensure that the key
was not compromised
prior to use.
Security key The security key is
needed to unlock the
encryption key for
encrypting and
decrypting to occur.
One security key is
created for all FDE
drives on the storage
subsystem. The
security key is
sometimes referred to
as the lock key.
It is stored on and is
managed by the
controller. A single
security key is
synchronized for all
controllers in a storage
subsystem.
The security key is
generated by the
storage subsystem
and is encrypted and
hidden in the
subsystem.
Security key
identifier
The security key
identifier is paired with
the security key to help
you remember which
key to use for secure
operations. The
security key identifier
can be left blank, or
you can specify up to
189 alphanumeric
characters.
The security key
identifier is stored in a
special area of the
disk:
Can always be
read from the disk
Can be written to
the disk only if
security has been
enabled and the
drive is unlocked
User-specified
alphanumeric
character string. The
subsystem adds the
storage subsystem
worldwide identifier
and a randomly
generated number to
the characters that are
entered.
6.8 FDE key terms
Table 6-2 on page 152 defines the key terms that are used throughout this chapter.
Passphrase The passphrase is
used to encrypt the
security key and the
security key identifier.
The passphrase is a
user-specified
alphanumeric
character string, which
is eight characters
minimum and 32
characters maximum.
It must contain at least
one number, one
lowercase letter, one
uppercase letter, and
one non-alphanumeric
character (such as < >
& @ + -). Spaces are
not allowed, and it is
case sensitive.
User-specified
alphanumeric
character string, not
stored anywhere on
the subsystem or in the
security key file. The
passphrase is used to
encrypt the security
key when it is exported
in the security key file.
It is also used to
decrypt the key in the
security file when it is
used to import
security-enabled FDE
drives into a storage
subsystem.
User-specified
alphanumeric
character string.
Security key file File where the security
key identifier is saved
along with the
encrypted security key.
File name and location
are determined by the
administrator. In
addition to the
administrator-specified
location, the storage
manager also saves a
copy of the security
key backup file in the
default location. See
Chapter 8, DS5000
Full Disk Encryption
best practices on
page 177 for more
information.
It is generated by the
storage subsystem
after you initiate a
create security key,
change security key,
or save security key
operation.
Parameter Description Where is it located
and how is it
managed
How is it generated
Table 6-2 Full Disk Encryption key terms
Term Description
FDE Full Disk Encryption, a custom chip, or application-specific
integrated circuit (ASIC) on the disk drive that requires a
security key to allow encryption and decryption to begin. FDE
disk drives encrypt all the data on the disk. The secured drive
requires that a security key is supplied before read or write
operations can occur. The drive processes all the encryption
and decryption of data, which are not apparent to the storage
subsystem.
Secure erase Permanent destruction of data by changing the drive
encryption key. After secure erase, data that was previously
written to the disk becomes unintelligible. This feature takes
advantage of FDE disk security capabilities to erase data by
changing the encryption key to a randomly generated value.
Because the encryption key never leaves the drive, this
function provides a secure erase. After secure erase, the
drive becomes unlocked, allowing anyone to read or write to
the disk. Secure erase is sometimes referred to as drive
reprovisioning.
Local key management Management of the security keys and key linkage between
the storage subsystem and the FDE drives.
Locked The state that a security-enabled FDE drive enters when it
has been removed from and then reinserted in the storage
subsystem, or when the storage subsystem is powered off.
When storage subsystem power is restored, the drive
remains in the Locked state. Data cannot be written to or read
from a locked disk until it is unlocked by the controller,
using the security key. If the controller does not have the
security key, the security key file and its passphrase are
required to unlock the drives for read and write operations.
Repurposing/reprovisioning Changing a drive from being in the Secured state to the
Unsecured state so that the drive can be reused.
Reprovisioning the drive is accomplished by secure erase.
Secure array An array on security-enabled FDE drives.
Security-capable drive An FDE drive that is capable of encryption but is in the
Unsecured state (security not enabled).
Security-enabled drive An FDE drive with security enabled. The security-enabled
FDE drive must be unlocked using the security key during the
power up process before read or write operations can
occur.
Unlocked The state of a security-enabled FDE drive in which data on
the disk is accessible for read and write operations.
Chapter 7. Configuring encryption on
DS5000 with Full Disk Encryption
drives
This chapter describes how to implement security on DS5000 storage systems that are
equipped with Full Disk Encryption (FDE) disks. It highlights how to configure DS5000 disk
encryption with FDE drives.
Disk Security is a new feature that was introduced with DS5000 and the newly available FDE
drives. It requires the latest level of DS5000 firmware Version 7.60 and later and IBM disk
encryption Storage Manager 10.60 and later. This section describes how this new feature can
add a greater level of security to the resident data on disk, its function, the various
components of the feature, and how to implement it.
The Disk Security premium feature requires security-capable drives. A security-capable drive
encrypts data during writes and decrypts data during reads. Each security-capable drive has
a unique drive encryption key. When a security-capable drive has security enabled, the drive
requires the correct security key from the DS5000 to authenticate before allowing the system
to read or write data. The IBM disk encryption Storage Manager manages this authentication
on each of the DS5000 controllers. All the drives in the DS5000 share the same security key,
and the shared security key provides read and write access to the drives. The drive
encryption key on each drive encrypts the data.
7
7.1 The need for encryption
Data security breaches are increasingly common. Sensitive client data and intellectual
property are at greater risk for unauthorized access. Data security, which is driven greatly by
regulatory compliance, is now a common component of corporate management. Security
efforts to address data security are often fragmented.
At a certain point, all drives are beyond an organizations control and vulnerable to a breach.
For example, repurposing, decommissioning, or disposing of individual disks often occurs
with insufficient security methods:
Deleted files can be reinstated.
Drive disposal methods are subject to human error.
Password-protected data can still be accessed by a skilled individual.
Disk reformatting erases data on disks, but information can still be recovered. Certain
utilities, which are used to erase data from disks and arrays, are unsuccessful because
data can be recovered using forensic techniques.
Each case introduces a risk where legible data can be recovered from disk. Recovering
erased data is significantly more difficult if you use Disk Security on the DS5000.
7.1.1 Encryption method
The FDE disks have encryption hardware, and they can perform the symmetric encryption
and decryption of data at full disk speed with no effect on their performance. The disk
encryption hardware works in conjunction with IBM disk encryption Storage Manager on the
DS5000 storage system. It uses asymmetric encryption to encrypt and decrypt the data key.
IBM disk encryption Storage Manager generates encryption and decryption keys that are
used to lock each FDE drive.
Without these IBM disk encryption Storage Manager-managed keys, the user (authorized or
unauthorized) can no longer decrypt the data on disk.
Figure 7-1 on page 155 shows the relationship of the IBM Disk Encryption Manager and the
individual FDE disk with encryption enabled.
Important: FDE and drive-level encryption technology are new. They are an additional
level of data protection, but they do not replace the access controls and security processes
that exist. Instead, they complement them.
Important: If these keys and all copies are lost, the encrypted data on disk cannot be
decrypted and, therefore, is considered lost.
Chapter 7. Configuring encryption on DS5000 with Full Disk Encryption drives 155
Figure 7-1 DS5000 Disk Encryption Manager using self-encrypting FDE drives
With this relationship, the correct keys, and authentication, the FDE drive encrypts data
written to it and decrypts data read from it, which is called self-encryption. But if the disk is
removed and a person attempts to read the data on the disk, as shown in Figure 7-2 on
page 156, the person does not have the appropriate authorizations. Therefore, data cannot
be read from or written to the drive without authenticating with the DS5000 Disk Encryption
Manager, which unlocks the drive.
Figure 7-2 Unauthorized access to the drive results in the data remaining encrypted
7.2 Disk Security components
The Disk Security feature contains many new components. You manage these new
components by using the Storage Manager (V10.6.x and higher).
7.2.1 DS5000 Disk Encryption Manager
The Disk Encryption Manager on the DS5000 system maintains and controls the key linkage
and communications with FDE drives. It is included with the firmware (7.60) and Storage
Manager (10.6) versions:
Provides all the management tools necessary to quickly and simply enable and secure
FDE drives.
Establishes and manages a single authorization scheme for all the FDE drives in a
DS5000 storage system:
Places FDE drives in a secured state
Defines secure arrays
Supports the decommissioning or repurposing of drives with Instant Secure Erase
With this function, you can record the security key ID, passphrase, and the secure file location
in a safe place. With the FDE drive, the Disk Encryption Manager on the DS5000 generates
and encrypts a security key in this manner:
Creates a unique security key ID, which is paired with the security key
Adds a randomly generated number
Saves the security key ID in a folder location to use for each security operation (that is,
when a drive powers up)
Creates a backup of the security key and the security key identifier
Provides a secure backup in which the security key and the security key identifier are
encrypted, utilizing a user-selected passphrase
7.2.2 Full Data Encryption disks
Disk Security enablement requires FDE disks. The available FDE disks for Disk Security are
all Fibre Channel (FC) disks with a speed of 15,000 rpm:
Encryption Capable 4 GBps FC, 146.8 GB/15K
Encryption Capable 4 GBps FC, 300 GB/15K
Encryption Capable 4 GBps FC, 450 GB/15K
7.2.3 Premium feature license
DS5000 requires that the Drive Security premium feature is installed and enabled for Disk
Security to function.
7.2.4 Keys
Two types of keys are used with Drive Security and FDE drives: the security key and the
encryption key:
The encryption key is generated by the drive and never leaves the drive, so it always stays
secure. It is stored in encrypted form, and it performs the symmetric encryption and
decryption of data at full disk speed with no effect on disk performance. Each FDE drive
uses its unique encryption key, which is generated when the disk is manufactured and
regenerated when required by the storage administrator by using the DS5000 Disk
Encryption Manager.
The lock key or security key is a 32-byte random number that authenticates the drive with
the DS5000 Disk Encryption Manager using asymmetric encryption for authentication.
When the FDE drive is secure-enabled, it has to authenticate with the Disk Encryption
Manager or it will not return any data and remains locked. After the drive has been
authenticated, access to the drive operates like any other disk drive. One security key is
created for all FDE drives on the DS5000 storage system where it is generated,
encrypted, and hidden in the subsystem (non-volatile storage RAM (NVSRAM)). The
authentication only occurs typically after the FDE has powered up where it is in a locked
state.
If the lock key is not initially established between the DS5000 Disk Encryption Manager
and the disk, the disk is considered unlocked with unlimited as in any normal non-FDE
drive.
7.2.5 Security key identifier
For additional protection, the security key that is used to unlock FDE drives is not visible to the
user. The security key identifier is used to refer to a security key, instead. You can see the
security key identifier during operations that involve the drive security key backup file, such as
creating or changing the security key. The security key identifier is stored in a special area of
the disk. It can always be read from the disk and can be written to the disk only if security has
been enabled and the drive is unlocked.
The security key identifier field in the FDE Drive Properties window, as shown in Figure 7-3,
includes a random number that is generated by the controller when you create or change the
security key. One security key is created for all FDE drives on the storage subsystem.
Figure 7-3 shows that the drive is capable (FDE) of being secured and that security is
enabled.
Figure 7-3 FDE drive properties showing the security ID and status
7.2.6 Passwords
To enable Disk Security, you must set the DS5000 administration passphrase or password.
Make the password a strong password (not easy to guess). The system checks the
password. If the system does not consider the password to be strong enough when you log in
or are prompted for the password, a message, as shown in Figure 7-6 on page 160, is
displayed. The message includes suggestions to make the password stronger.
The security key and the security key identifier are encrypted using a separate password or
passphrase when the key is created or changed (see 7.3.2, Secure key creation on
page 160 and 7.4.1, Changing the security key on page 164). The array then returns a file
that is called a blob or key backup. If the array needs that key later, you enter the blob and
the passphrase at the graphical user interface (GUI), which sends it down to the array where
the original key is decrypted.
The user-specified alphanumeric character string is not stored anywhere on the DS5000 or in
the security key backup file.
Drive properties: The Security Capable and Secure fields in the Drive Properties window
show whether the drive is secure-capable and whether it is in the Secure (Yes) or
Unsecured (No) state.
7.3 Setting up and enabling the Secure Disk feature
In this section, we show a step-by-step process to create a key and file on the IBM disk
encryption Storage Manager of the DS5000. We then enable a previously configured array,
which has FDE disks.
7.3.1 FDE and the premium feature key check
First, prior to key creation, check that the premium feature key has been obtained and applied
to the system. From the Storage Manager window, select Storage Subsystem Premium
Features.
Figure 7-4 shows that the Drive Security premium feature key has been obtained and
successfully installed. The premium feature key is installed just as any other premium feature.
Figure 7-4 Correct premium feature has been obtained and installed
Next, check for the physical disks to ensure that they are FDE drives and secure capable. In
Figure 3-5, you can see that an array has been created where disk security is not enabled, as
indicated by the unlocked padlock. Click the array, and right-click to select View Associated
Physical Components to view the associated disks, as shown in Figure 7-5. Click Show
FDE, which has been circled in red, to display all the FDE drives. This action confirms that all
the drives in the array are secure capable.
The array is already in use and has several logical drives configured. The array consists of all
FDE drives; therefore, it can be enabled.
Figure 7-5 Array created with FDE disks with disk security disabled
7.3.2 Secure key creation
To create the secure key, from the IBM System Storage DS ES window, in the upper-left
corner, select Storage Subsystem Drive Security Create Security Key.
To proceed, you must have already set your DS5000 subsystem password. You might see the
message in Figure 7-6 if the existing password is considered too weak.
Figure 7-6 Warning regarding the weak subsystem password in use
You are then prompted for the following information, as shown in Figure 7-7 on page 161.
Figure 7-7 Requirements displayed for the security key creation
The key location default is in the users local personal computer directory. Copy the key and
keep it in a safe location.
When the process is complete, the key is created and located as specified. Also, as shown in
Figure 7-8 on page 162, the security identifier is displayed. From this process, three items
exist that you must keep secure so that you can manage any changes to the FDE disks when
they are encryption enabled:
Security key file created from the process
Security key identifier created from the process
Password used
Tip: Store the security key file with your key management policies along with the
passphrase. It is important to record and remember where this file is stored. The security
key file is required, along with passphrase, when a drive is moved from one storage
subsystem to another or when both controllers in a storage subsystem are replaced at the
same time.
Figure 7-8 Security key creation process complete
The key authorizations now generated are synchronized between both controllers in the
DS5000 storage subsystem. With these authorizations in place, you can secure the arrays on
the FDE drives in the storage subsystem.
7.3.3 Enable disk security on the array
With the keys created, you can now enable disk security on the array. Click the array, and then
right-click it to select Secure Drives, as shown in Figure 7-9.
Figure 7-9 Secure all drives in array
Then, the system prompts you to confirm the secure drives on the array, as shown in
Figure 7-10 on page 163.
Figure 7-10 Confirm Array Drive Security
The array is now secured, which is indicated by the padlock in a locked position, as shown in
Figure 7-11.
Figure 7-11 Array is now secured with disk security enabled
7.4 Additional secure disk functions
Now, we describe additional supported secure disk functions. We describe these features:
Changing the security key
Saving the security key file
Secure disk erase
FDE drive status
Hot-spare drive
7.4.1 Changing the security key
You can change the security key if the existing key is compromised or the passphrase is
forgotten, as long as no outstanding Secure Disk communications exist between the FDE
drives and the Disk Encryption Manager (for example, if a disk is in a locked state). Because
the disk encryption key never leaves the disk, periodically change the encryption key, similar
to the way that a user might periodically change the administrative password to an operating
system. This decision depends on the organization security guidelines.
The process to change the security key is similar to its creation process.
To change the key from the Storage Manager menu, in the upper-left corner, select Storage
Subsystem Drive Security Change Security Key (Figure 7-12).
Figure 7-12 Change Security Key
As shown in Figure 7-12, the system prompts you to add a security identifier (optional), a
location to store the key file, and a passphrase.
The new security key is generated by the controller firmware and is hidden in the storage
subsystem. The new security key replaces the previous key that was used to unlock the
security-enabled FDE drives in the storage subsystem. The controller negotiates with all the
security-enabled FDE drives for the new key.
The original security key is also stored in the storage subsystem for protection in case the
controllers are prevented from completing the negotiation of the new security key with the
security-enabled FDE drives (for example, the loss of storage subsystem power during the
key change process). If the process does not complete, you must change the security key so
that only one version of the security key is used to unlock all drives in a storage subsystem.
The original key is stored in the storage subsystem only. It cannot be changed directly or
exported to a security key backup file.
When the security key has been successfully changed, a confirmation window is displayed,
as seen in Figure 7-13. This window describes the new key file location and security key
identifier.
Figure 7-13 Change Security Key Complete confirmation window
7.4.2 Saving the security key file
This function saves a backup of the security key file and requires the original passphrase in
order to reproduce the security key file. You can use this function to verify that the stored
passphrase is correct. To save the security key file, from the Storage Manager menu, in the
upper-left corner, select Storage Subsystem Drive Security Save Security Key File.
The system prompts you for the location to store the file and the passphrase that will be used
to create or change the existing security key file, as shown in Figure 7-14 on page 166. The
DS5000 Disk Encryption Manager uses the passphrase to encrypt the security key before the
DS5000 Disk Encryption Manager exports the security key to the security key backup file.
Figure 7-14 Save Security Key File window
7.4.3 Secure disk erase
Secure erase provides a higher level of data erasure than other traditional methods. When
you initiate secure erase with the DS5000 Disk Encryption Manager, a command is sent to
the FDE drive to perform a cryptographic erase. This action erases the existing data
encryption key and generates a new encryption key inside the drive, making it impossible to
decrypt the data. Drive security becomes disabled and must be re-enabled if required again.
Figure 7-15 Secure Erase process
You can only perform secure erase on drives that are not allocated to an array. This process is
also referred to as reprovisioning:
The FDE drive becomes fully reusable.
The FDE drive can be reused in secure or non-secure applications.
Previous data and keys are not accessible.
A quick process to execute completed in less than a second.
This process returns drive to original factory state.
7.4.4 FDE drive status
The FDE disks status indicates whether the disk can be accessed:
Locked:
The drive is security capable.
The drive has security enabled.
The lock key has not been supplied to the drive.
Data cannot be read or written from drive.
Unlocked:
The drive is security capable.
The drive has security enabled.
The lock key has been supplied to the drive.
Data can be read or written from drive.
You rarely see the locked state - only when the array containing the disks has been moved to
another DS5000 or the controllers have been replaced. The drive becomes locked whenever
the disk is powered down. The drive remains unlocked during firmware upgrades or when
replacing other components. When the drive is powered on, the status is locked. If the drive
detects a security key identifier, it remains locked until it has successfully authenticated with
DS5000 Disk Encryption Manager.
7.4.5 Hot-spare drive
If a disk drive fails in the DS5000 storage subsystem, the controller uses redundant data to
reconstruct the data on the failed drive on a global hot-spare drive. The global hot-spare drive
is automatically substituted for the failed drive without intervention. When the failed drive is
eventually replaced, the data from the hot-spare drive is copied back to the replacement
drive.
Hot-spare drives must meet the array hot-spare requirements. The following drive types are
required for hot-spare drives when secure-capable arrays are configured. If a drive does fail,
the DS5000 Storage Manager automatically determines which hot-spare drive to substitute
according to the type of the failed drive:
For an array that has secured FDE drives, the hot-spare drive must be an unsecured FDE
drive of the same or greater capacity. After the unsecured FDE hot-spare drive is used as
a spare for a failed drive in the secured RAID array, it is Security-Enabled.
WARNING: All data on the disk will be permanently and irrevocably erased when the
secure erase operation is completed for a security-enabled FDE drive. Do not perform this
action unless you are sure that you want to erase the data, because you cannot recover
the data.
For an array that has FDE drives that are not secured, the hot-spare drive can be either an
unsecured FDE drive or a non-FDE drive.
An unconfigured secured FDE drive cannot be used as a global hot-spare drive. If a global
hot spare is a secured FDE drive, it can be used as a spare drive only in secured arrays.
An unconfigured secured FDE drive cannot be used as a global hot-spare drive. If a global
hot spare is a secured FDE drive, it can be used as a spare drive only in secured arrays. If a
global hot-spare drive is an unsecured FDE drive, it can be used as a spare drive in secured
or unsecured arrays with FDE drives, or as a spare drive in arrays with non-FDE drives. You
must secure erase the FDE drive to change it to the Unsecured state before it can be used as
a global hot-spare drive. The following error message is generated if you assign an
unconfigured secured FDE drive as a global hot spare:
Return code: Error 2 - The operation cannot complete because either (1) the
current state of a component does not allow the operation to be completed, (2) the
operation has been disabled in NVSRAM (example, you are modifying media scan
parameters when that option (offset 0x31, bit 5) is disabled), or (3) there is a
problem with the storage subsystem. Check your storage subsystem and its various
components for possible problems and then retry the operation. Operation when
error occurred: PROC_assignSpecificDrivesAsHotSpares.
When a global hot-spare drive is used as a spare for a failed drive in a secure array, the global
hot-spare drive becomes a secure FDE drive and remains secure as long as it is a spare in
the secure array. After the failed drive in the secure array is replaced and the data in the
global hot-spare drive is copied back to the replaced drive, the global hot-spare drive is
automatically reprovisioned by the controllers to become an unsecured FDE global hot-spare
drive.
In a mixed disk environment that includes non-security capable Serial Advanced Technology
Attachment (SATA) drives, non-security-capable FC drives, and FDE FC drives (with security
enabled or not enabled), use at least one type of global hot-spare drive (FDE FC and a SATA
drive) at the largest capacity within the array. If a secure-capable FDE FC drive and SATA
hot-spare drive are included, all arrays are protected. Hot-spare configuration guidelines are
the same for FDE drives.
7.4.6 Log files
The DS Storage Manager major events log (MEL) includes messages that describe any
security changes that are made in the storage subsystem.
7.5 Migrating secure disk arrays
In this section, we describe how to migrate an array with Disk Security enabled to another
DS5000. The process consists of exporting the array on the source DS5000 and importing
the array on the target DS5000 after the disk has been physically moved. User data remains
intact on the disks, because configuration metadata is stored on every drive in the DS5000.
Important: If an unsecured FDE hot-spare drive was used as a spare for a non-secured
FDE array and the array was secured after the data was copied back, the unsecured FDE
hot-spare drive remains unsecured, exposing the data in the drive if the drive is removed
from the storage subsystem.
The export process is the same on an ordinary array; however, extra steps are required for
the locked drives of the secure array when importing.
7.5.1 Planning checklist
This list is displayed in a window of the migration wizard (Figure 7-16 on page 170). Follow
these steps when planning the export and import of an array:
Perform these steps on the source DS5000:
Save the DS5000 configuration (click Storage Subsystem Configuration Save).
Back up all the data at the host level on the logical drives of the array.
Ensure all I/O has been stopped to the array. Unmap any logical drives that are mapped
on the array. Ensure that each host that you access no longer requires the disk presented
to it by the array to be migrated.
Locate the array disks on the DS5000, noting the enclosure ID and location slot of each
disk member.
Save the security key file, as described in 7.4.2, Saving the security key file on page 165.
Obtain blank canisters or new drives to be inserted in the DS5000 when the drives are
removed.
Perform these steps on the target DS5000:
Verify that there are available drive slots to host the disk drives.
Check that the drives that are being moved are supported. Make sure that the Drive
Security premium feature is already enabled. See Figure 7-4 on page 159.
Verify that the firmware is up-to-date and the same on the source and target DS5000s.
Unlock the drives before importing the array.
7.5.2 Export the array
From the Storage Manager window, highlight the array that you want to export on the Logical
tab of the window. Select Advanced Maintenance Export Array.
The export array wizard guides you through the export.
Figure 7-16 Export Array wizard
The preparation checklist that is shown in Figure 7-17 is displayed. Check that no planning
steps have been missed.
Figure 7-17 Preparation Checklist
When the process has completed, Figure 7-18 on page 171 indicates that the drives can be
removed.
Figure 7-18 Export Array completed
The Storage Manager now indicates that the array has been exported and the physical disks
are offline. See Figure 7-19 and Figure 7-20.
Figure 7-19 Array now exported
Figure 7-20 Array disks now offline
7.6 Import secure drive array
After all the disks have been physically moved and are seated correctly in the target DS5000
enclosure, the drives are ready to be unlocked and the array can be imported. Ensure that all
drives are seen by the DS5000 and that no drives have a problem that will affect the array
after it has been imported.
All drives are in a locked state, as shown from the event viewer. Figure 7-21 shows the
individual drive properties. Access is not allowed due to an invalid security key.
Figure 7-21 Drive Properties: Invalid key and secure enabled, therefore locked
The DS5000 also indicates that it needs attention due to the locked state of the drives. You
can see the details in the Recovery Guru, as shown in Figure 7-22.
Figure 7-22 Locked Drive message from Recovery Guru
7.6.1 Unlock drives
Prior to importing the array, all drives must be unlocked. This procedure is performed on one
disk, but then, it is applied to all disks.
From the Physical tab in the Storage Manager window, select one of the FDE drives that has
just been installed. It is marked as offline. Right-click, and select Unlock, as shown in
Figure 7-23.
Figure 7-23 Select unlock option on FDE drive
The DS5000 recognizes the FDE drives that are locked and prompts for the key file and the
passphrase, as shown in Figure 7-24.
Figure 7-24 Need key file and passphrase to unlock FDE drives
When you select the correct key file and enter the passphrase, all drives are successfully
unlocked, as shown in Figure 7-25 on page 174.
Figure 7-25 FDE drive unlock completed successfully
7.6.2 Import array
The array displays as ready to import in the Logical tab of the Storage Manager window, as
shown in Figure 7-26.
Figure 7-26 Array ready to be imported
Use the Import Array option to import an array that you have previously exported. From the
Storage Manager window in the Logical view, select the array, and then select Advanced
Maintenance Import Array.
The import array, as shown in Figure 7-27 on page 175, lists the disks that will be imported.
Check that all disks displayed are correct and that none are missing.
Figure 7-27 Import report indicating all drives to be imported
The drives are imported. Figure 7-28 shows a message that confirms the success of the
operation.
Figure 7-28 Import completed
The logical drives in the newly imported array are now ready to be mapped to hosts where
data can be accessed for read and write operations.
Change the key after a secure array is imported to the DS5000 if the DS5000 already has
secure arrays. This action ensures that all secure-enabled FDE disks use a common key for
authentication with the DS5000 when they are powered on.
Chapter 8. DS5000 Full Disk Encryption best
practices
This chapter describes best practices for maintaining security on a DS5000 storage
subsystem that is equipped with self-encrypting Full Disk Encryption (FDE) disk drives. This
chapter contains these topics:
Physical asset protection
Data backup
FDE drive security key and the security key file
DS subsystem controller shell remote login
Working with FDE drives
Replacing controllers
Storage industry standards and practices
8
8.1 Physical asset protection
Full Disk Encryption (FDE) protects the data on the disks only when the drives are removed
from storage subsystem enclosures. FDE does not prevent someone from copying the data in
the storage subsystems through Fibre Channel (FC) host port connections when the drives
are unlocked and operating (see Figure 8-1). FDE also does not prevent unauthorized
management access.
To prevent unauthorized access to the storage subsystem, take the following precautions:
Place the subsystem behind a closed and locked door.
Secure (disable) any unused FC or Ethernet switch ports.
Place the storage subsystem management network on a separate subnet from the
production Ethernet network.
Assign a subsystem management password for each storage subsystem that is managed
by the IBM DS Storage Manager client.
Figure 8-1 Levels of data protection
The DS Storage Manager caches the subsystem management password and reuses it for
every operation that requires it without prompting you to reenter the password. You must
establish strong user access controls in the system that hosts the DS Storage Manager client.
You must enable the user login and password. You must configure the host system so that the
window automatically becomes locked if it is not used.
The DS storage subsystem comes with a null storage manager client subsystem
management password as a default. Assign a storage manager subsystem management
password to each managed storage subsystem before you configure drives or arrays. If the
storage manager Subsystem Management window password remains null, any computer in
the storage subsystem management network can connect to the storage subsystem and
perform malicious acts, such as deleting arrays or mapping logical drives to unauthorized
hosts.
Chapter 8. DS5000 Full Disk Encryption best practices 179
8.2 Data backup
Always back up the data in the storage subsystem to secured tape to prevent a loss of data
due to malicious acts, natural disasters, abnormal hardware failures, or loss of the FDE
security key.
8.3 FDE drive security key and the security key file
You use the security key to unlock secured FDE drives for read and write operations. The
security key is obfuscated inside the controllers and is used to unlock the drives when they
are turned on (see Figure 8-2). A backup copy of the encrypted security key is stored in a
user-specified location when the key is initially generated or whenever you change the
security key. The security key can be changed only when all of the defined arrays in the
storage subsystem are in the Optimal state. It is not necessary to change the security key at
the same regular intervals as password changes for the server and FC/Ethernet switch.
In the rare event that the controllers encounter a corrupted security key, the stored copy of the
key is used to unlock the drives and restore the security key that is stored in the controllers.
You can also use the stored copy of the security key to unlock secured FDE drives when you
migrate them to another storage subsystem.
Figure 8-2 Internal security key
The security key that is stored in the security key file is protected by a passphrase. To protect
the security key, the passphrase and the security key are not stored separately in the security
key file. The security key is wrapped by the hashed passphrase before it is written to the
security key file; then, the passphrase is discarded. A security key identifier is paired with the
security key to help you remember which key to use for a particular storage subsystem. The
security key identifier can contain up to 189 alphanumeric characters. The storage subsystem
worldwide identifier and a randomly generated number are appended to the security key
identifier when it is written to the security key file.
There is no way to unlock a secured FDE drive without the security key. If the security key that
is stored in the subsystem controllers becomes corrupted, the only way to recover the
security key in the controllers is to use the stored security key file. The only way to decrypt the
information in the security key file to retrieve the security key is to use the passphrase. If the
passphrase does not match the one you specified when you saved the security key file, there
is no way to retrieve the security key from the security key file and unlock the secured FDE
drives. In this case, the data in the secured FDE drives is lost.
When you save the security key file, a copy of the security key file is stored in the location that
you specify and in the c:\Program Files\IBM_DS\client\data\securityLockKey default
security file directory in the Microsoft Windows operating system environment or in the
/var/opt/SM/securityLockkey default security file directory in the AIX, Linux, Solaris and
Hewlett-Packard (HP-UX) operating system environments. The default directory security key
file acts as a backup file in case your copy of the security key file is lost or damaged. If the
security key file name that you specify is the same as an existing security key file name, the
name of the security key file that is saved in the default directory is modified to include the
date and time. For example, the ds5ktop2.slk file name becomes the
ds5ktop2_2009_06_01_11_00_36.slk file name.
By design, the security key can be changed only when all the defined arrays in the storage
subsystem are in the Optimal state. The change security key process will terminate if there
are any degraded arrays in the storage subsystem. If there are any disconnected, failed, or
exported spun-down drives in the storage subsystem when the security key is changed, the
security key for these drives does not change. Failed or exported spun-down drives have the
n-1 drive security key value, where n is the number of times the security key was changed
since the drives failed, were exported, or were spun down. Because these drives are already
turned on, they can become operational even though they have a separate security key than
the rest of the FDE drives in the storage subsystem. However, these drives might not unlock
for read and write operations after the power is cycled, because the controllers do not have
the security key for these drives. These drives can be unlocked only when the security key is
provided.
Take the following precautions to protect the security key and passphrase:
To prevent situations in which there are multiple security keys in the storage subsystem,
do not change the security key when there are any disconnected, failed, or exported-down
drives in the subsystem.
If you must change the security key while there are disconnected, failed, or exported
spun-down drives, be sure to first save a security key file for these drives before you
change the security key.
Because the passphrase is used to decrypt the wrapped security key that is stored in the
security key file, be careful not to create a passphrase that can be easily discovered by
unauthorized users.
Record the passphrase, the security key identifier, and the name and location of the
security key file, and store this information in a secure place. If you lose this information,
you can lose access to your data.
Do not store the security key file on a logical drive that you created by using the disk drives
of the same DS storage subsystem.
Do not write the passphrase on the media that is used to store the security key file.
Before you run the command to export a set of drives from the subsystem, change the
security key and save the security key file and passphrase for the exported drives in a
secure place. Make sure that you can identify the correct security key file and passphrase
for the exported drives.
Chapter 8. DS5000 Full Disk Encryption best practices 181
Store more than one copy of the security key file. Do not specify the default security file
directory as the location to store your copy of the security key file. If you specify the default
directory, only one copy of the security key file is saved.
8.4 DS subsystem controller shell remote login
Do not enable remote login to the DS subsystem controller shell. The controller shell is
reserved for IBM support personnel to perform subsystem recovery and diagnostics
procedures. The DS subsystem controller shell does not provide prompts to confirm
potentially destructive tasks. Mistakes in command syntax or the inappropriate use of
controller shell commands might result in lost access or lost data.
8.5 Working with Full Disk Encryption drives
To maintain security on FDE drives, take the following precautions:
After you delete an array, secure erase the FDE drives that were part of the array. Secure
erase cryptographically erases the disk and also changes the drive state back to
Unsecured (see Figure 8-3).
Figure 8-3 Secure erase process
Use only an FDE global hot-spare drive as a spare for a drive failure in a secured array.
You can use an FC FDE global hot-spare drive as a spare drive for FC FDE drives in
secure or non-secure arrays and as a spare for an FC drive in arrays with non-FDE drives.
Although you can use an array with non-FDE drives as the repository logical drive for a
FlashCopy image of a secured FDE logical drive or as the target logical drive of a
secured volume copy source FDE logical drive, do not use non-FDE drives, because
arrays with non-FDE drives are not secured.
In a remote mirroring configuration, even if the primary and secondary logical drives of a
mirrored logical drive pair are secured, the data that is transferred between the primary
and secondary storage subsystems is not encrypted. You must ensure that the data that is
transferred between remote mirroring logical drive pairs is protected.
8.6 Replacing controllers
When you replace a controller, take the following precautions:
Do not replace both controller field-replaceable units (FRUs) at the same time. If you
replace both controllers at the same time, the new controllers will not have the correct
security key to unlock the drives. If this situation occurs, you must use the saved security
key file to unlock the drives.
Do not replace a controller FRU while the storage subsystem is powered down. If you
replace a controller FRU with the power off, the new controller and the existing controller
will have separate security keys, causing security key mismatch errors. Perform the
change security key procedure to resynchronize the security key between controllers.
Replace controller FRUs only when the subsystem is powered on and operational. This
action ensures that the firmware version, premium feature IDs, and security key in the new
controller are synchronized with the existing controller.
8.7 Storage industry standards and practices
See the following documents for storage and networking industry best practices and
guidelines:
Storage Networking Interface Association (SNIA):
For SNIA key management best practices charts, see this website:
http://www.snia.org/images/tutorial_docs/Security/WaltHubis-Best_Practices_S
ecure_Storage.pdf
For SNIA guidance and best practices documents, see this website:
http://www.snia.org/forums/ssif/programs/best_practices
Registration is required to download the following SNIA documents:
Best Current Practices: Provides broad guidance for organizations seeking to secure
their storage systems
SSIF Solutions Guide to Data at Rest: Provides baseline considerations and guidance
for factors to consider when evaluating storage security
For the SNIA Storage Security forum, see this website:
http://www.snia.org/forums/ssif/
National Institute of Standards and Technology (NIST):
See the NIST Computer Security Division Guidelines for Media Sanitation at this website:
http://csrc.nist.gov/publications/nistpubs/800-88/NISTSP800-88_rev1.pdf
Trusted Computing Group:
https://www.trustedcomputinggroup.org/home
Chapter 9. Frequently asked questions
In this chapter, we answer several frequently asked questions regarding Full Disk Encryption
(FDE) drives and their usage in the DS5000 encryption mechanism.
9
9.1 Securing arrays
Question: Can I change an unsecured array with FDE drives to a secured array?
Answer: Yes, we describe the steps to complete this process in 7.3.3, Enable disk security on
the array on page 162. You must enable the DS5000 encryption feature and have already
established the security key file and passphrase.
Question: When I enable security on an array, is the data that was previously written to that
array lost or erased?
Answer: No, unless you perform a secure erase on the array disk drives, this data remains
intact.
Question: Can I change a secured array with FDE drives to an unsecured array?
Answer: No, this option is not supported. After an unsecured array is changed to a secure
array, it cannot be changed back to an unsecured array without destroying the data in the
security-enabled FDE drives. Use volume copy to copy the secure data to an unsecured
array, or back up the data to a secured tape. If you volume copy the secure data to an
unsecured array, you must physically secure the drives. Then, you must delete the original
array and secure erase the array drives. Create a new unsecured array with these drives and
use volume copy to copy the data back to the original drives or restore the data from secure
tape.
Question: If I have an array with FDE drives that is secured, can I create another array that
uses these same drives and not enable security? Does the storage subsystem have a control
so that this situation does not occur?
Answer: No, these options are not supported functions. Any logical drive that is part of an
array must be secured, because the drives on which it is stored are security enabled.
Question: When a secure array is deleted, does disk security remain enabled?
Answer: Yes. The only way to disable security is to perform a secure erase or reprovision the
drives.
Question: If I create a new array on a set of unassigned/unconfigured security-enabled FDE
disks, will they automatically become secure?
Answer: Yes.
9.2 Secure erase
Question: With secure erase, what can I erase, an individual drive or an array?
Answer: Secure erase is performed on an individual drive. You cannot erase a secured drive
that is part of an array; you must first delete the array. After the array is deleted and the drives
become unassigned, you can erase multiple disks in the same operation by holding the Ctrl
key while you select the drives that are to be secure erased.
Chapter 9. Frequently asked questions 185
Question: If I want to use only the secure erase feature, do I still have to set up a security key
identifier and passphrase?
Answer: Yes. You must enable the full disk encryption feature before you can use secure
erase.
Question: After secure erase is performed on a drive, is security enabled or disabled on that
drive?
Answer: The drive is returned to the Secure Capable (unsecured) state after a secure erase.
Security is disabled on the drive.
Question: If I inadvertently secure erase a drive, is it possible to recover the data in the drive?
Answer: No. After a drive is secure erased, the data in the drive is not recoverable. You must
recover the lost data from a backup copy. Back up the data in secure drives before you secure
erase the drives.
9.3 Security keys and passphrases
Question: Can I get to the security keys through the DS Storage Manager or controller?
Answer: No, the security key is obfuscated in the storage subsystem. Only an encrypted
version of the key can be exported to a security key file, using the save security key operation.
The actual security key is not available for viewing. Implement prudent security features for
the storage subsystem. The DS5000 Storage Manager forces a strong password, but
administrator access must have stringent controls in place.
Question: If I lose a drive that is unlocked or security disabled, can that data be accessed
even though the data is encrypted?
Answer: Yes. Because security has not been enabled on the drive, it remains unlocked, and
the data is accessible.
Question: If an unauthorized person knows my security key, can I change my security key
without losing my data?
Answer: Yes, the drive can be rekeyed, using the procedure to change the security key.
9.4 Premium features
Question: How do I ensure that my mirrored data is secure? What is a best practice for
protecting data at the remote site?
Answer: Secure your data with security-enabled FDE drives at both the primary and the
secondary sites. Also, you must ensure that the data is protected while it is transferred
between the primary and secondary sites.
Question: Can I use volume copy to copy a secured logical unit number (LUN) to a unsecured
LUN? If so, what prevents an unauthorized user from using volume copy to copy a secured
LUN to an unsecured LUN at first and, then, stealing the unsecured copy?
Answer: Yes. To prevent someone from stealing the data by using this method, implement
prudent security features for the storage subsystem. The DS5000 Storage Manager forces a
strong password, but administrator access must also have stringent controls in place.
Question: Can FlashCopy and volume copy data be secured?
Answer: Yes. For FlashCopy, the FlashCopy repository logical drive must be secured if the
target FlashCopy data is secured. The DS5000 Storage Manager enforces this rule. Similarly,
if the source array of the volume copy pair is secured, the target array of the volume copy pair
must also be secured.
9.5 Global hot-spare drives
Question: Can I use an unconfigured FDE drive as a global hot-spare drive?
Answer: Yes, but only if the drive is unsecured (security not enabled). Check the status of the
unconfigured FDE drive. If the drive is Secure, it must be secure erased or reprovisioned
before you can use it as a global hot-spare drive.
Question: If the hot-spare drive in a secured array is an unsecured FDE drive, does this drive
automatically become secured when a secured FDE drive fails and that data is written to the
hot-spare drive?
Answer: Yes. When the failed drive is removed from the RAID group, a rebuild is automatically
started to the hot-spare drive. Security is enabled on the hot-spare drive before the rebuild is
started. A rebuild cannot be started to a non-FDE drive for a secure array. After the failed
drive in the secured array is replaced and the data in the global hot-spare drive is copied back
to the replaced drive, the global hot-spare drive is automatically reprovisioned by the
controllers to become an unsecured FDE global hot-spare drive.
9.6 Boot support
Question: Is there a special process for booting from a security-enabled drive?
Answer: No. The only requirement is that the storage subsystem must be running (which is
required in any booting process).
Question: Are FDE drives susceptible to cold boot attacks?
Answer: No. This issue applies more to the server side, because an individual can create a
boot image to gain access to the server. This situation does not apply to FDE drives. FDE
drives do not use the type of memory that is susceptible to a cold boot attack.
Chapter 9. Frequently asked questions 187
9.7 Locked and unlocked states
Question: When does a security-enabled drive go into the Locked state?
Answer: The drive becomes locked whenever the disk is powered down. When the FDE drive
is turned off or disconnected, it automatically locks down the data on the disk.
9.8 Backup and recovery
Question: How can I ensure that my archived data is secure?
Answer: Securing archived data is beyond the scope of this document. See the Storage
Networking Interface Association (SNIA) recommendations for secure tape backup. Refer to
Chapter 8, DS5000 Full Disk Encryption best practices on page 177 for specific references.
9.9 Additional questions
Question: Is DACstore information still written to the disk?
Answer: Yes. However, if the drive is secured, it must be unlocked by the controller first before
the DACstore information can be read. In the rare event that the controller security key is
corrupted or both controllers are replaced, you must use a security key file to unlock the drive.
Question: Is data on the controllers cache secure with FDE and IBM Disk Encryption? If not,
are there any best practices here?
Answer: No. This situation is a security issue of physical access to the hardware. The
administrator must have the physical control and security of the storage subsystem.
Question: If I have secure-capable disks but I have not purchased the IBM Disk Encryption
premium feature key, can I still recognize secure-capable disks from the user interface?
Answer: Yes. This information is available from several windows in the DS Storage Manager
interface.
Question: What about data classification?
Answer: See the SNIA best practices for more information about data classification. See
Chapter 8, DS5000 Full Disk Encryption best practices on page 177.
Question: Can I use both FDE and non-FDE drives if I do not secure the drives?
Answer: Yes. However, using both FDE and non-FDE drives is not a cost-effective use of FDE
drives. An array with both FDE and non-FDE drives cannot be converted into a secure array
at a later time.
Question: Do FDE disk drives have lower usable capacity because the data is encrypted or
because capacity is needed for the encryption engine and keys?
Answer: No. There is no capacity difference between non-FDE and FDE disk drives (1 GB
unencrypted = 1 GB encrypted).
Part 3 Implementing tape data
encryption
In this part, we explain the required steps to implement tape data encryption on the various
host platforms, tape drives, and tape libraries.
Part 3
Chapter 10. Planning for software and
hardware to support tape drives
In the previous chapters, we introduced the basics of encryption, how IBM tape data
encryption functions, and how Tivoli Key Lifecycle Manager 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 need to consider before implementing IBM tape data encryption.
If you plan to use System-Managed Encryption (SME) or Library-Managed Encryption (LME),
you must implement Tivoli Key Lifecycle Manager or EKM before you can encrypt any tapes.
However, many people plan for their tape hardware and their operating system first and then
plan Tivoli Key Lifecycle Manager or EKM implementation. These major parts of your tape
data encryption implementation might be handled by separate people in your organization.
Because the platform on which the tape drives reside can differ from the platform where Tivoli
Key Lifecycle Manager or EKM is implemented, we have separated out EKM planning and
describe it in Chapter 14, Planning for Encryption Key Manager and its keystores on
page 393. We describe Tivoli Key Lifecycle Manager planning in Chapter 11, Planning for
Tivoli Key Lifecycle Manager and its keystores on page 237.
10
10.1 Encryption planning
Encryption is not your typical tape or library upgrade. You must implement significant new
function and infrastructure with an encryption solution. Planning is vital to ensuring a smooth
rollout when implementing an encryption solution into your existing environment. Before you
begin this chapter, if this is your first experience with IBM tape drives or libraries, make sure
that you have read Chapter 4, IBM System Storage tape automation for encryption on
page 87.
Then, even if you have had experience with IBM Encryption Facility for z/OS or other vendor
cryptology products, read 1.1, Concepts of storage data encryption on page 4 and
Chapter 3, IBM storage encryption methods on page 49 to understand how the Encryption
Key Manager (EKM) or Tivoli Key Lifecycle Manager 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 solution or the 3592 Encryption solution,
and the Linear Tape-Open (LTO) 4 or LTO4 Encryption solution.
10.2 Planning assumptions
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:
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 of these concepts map to the TS1130, as well.
IBM System Storage Tape Library Guide for Open Systems, SG24-5946
This book describes the TS1120, TS1130, LTO4, and LTO5 tape drive in open systems
implementations. This book includes open systems IBM tape libraries: the TS3500, 3494,
TS3400, TS3310, TS3200, TS3100, and 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, and 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.
Starting at the beginning: We discuss tape data encryption planning assuming that your
tape drives and tape libraries have already been installed without encryption.
Chapter 10. Planning for software and hardware to support tape drives 193
10.3 Encryption planning quick-reference tables
The tables in this section compare encryption on the 3592 drive family to encryption on the
LTO4 drive:
Table 10-1 compares encryption characteristics.
Table 10-2 on page 194 compares drive, library, and controller prerequisites for
encryption.
Table 10-3 on page 195 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 10-1 compares encryption characteristics of the 3592 drive family and the IBM LTO4
and LTO5 drives.
Table 10-1 Encryption implementation characteristics comparison
Table 10-2 on page 194 compares tape drive, library, and controller prerequisites for tape
data encryption.
Description 3592 tape drive family
(3592-E05, 3592-EU6,
and 3592-E06)
LTO4/LTO5 tape drives
Encryption standard Advanced 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
(Asymmetric)
None
Data keys used Unique data key for each
cartridge
Keylist: A list or range of
data keys used, which is
pregenerated in keystore
Data keys stored? Wrapped (that is,
encrypted) data keys (2)
stored on cartridge, called
externally encrypted data
keys (EEDKs)
Stored in keystore
Rewriteable media required 3592 JJ, JA, or JB
cartridges
Ultrium 4 media only
WORM media required 3592 JR, JW, or JX
cartridges
Ultrium 4 WORM media
only
Rekeying support z/OS, TS3500, and 3494 No
Table 10-2 Drive, library, and controller encryption prerequisites
Description 3592 tape drive family LTO4 tape drive
Tape drives
Drive machine type and model 3592-E05
3592-E06
3592-EU6
1. TS1040 (3588-F4A)
2. Feature code (FC)
8144 or FC8145 of
the TS3310, TS3200,
or TS3100 tape library
3. TS2340 (3580-S43)
4. TS2240 (3580-E4S)
5. TS2900 (3572-SH4)
with FC5901
(Transparent LTO
Encryption)
Encryption capable FC9592 or FC5592 for
3592-E05. Standard on
3592-E06 and 3592-EU6
Standard
Encryption enabled and encryption
method set
FC9596 or FC5596 on
3592-E05 drive, FC9595
or FC5595 on controller,
or with library menus
Via library menus
Tape controllers (System z only)
3592-J70 tape controller with drives in a
TS3500 or 3494
Yes, FC9595 or FC5595.
Also, FC5593 for
out-of-band support
N/A
TS1120 Model C06 tape controller
(3592-C06) with drives in TS3500 or 3494
Yes, FC9595 or FC5595.
Also, FC5593 for
out-of-band support
N/A
TS1120 Model C06 tape controller
(3592-C06) with drives in TS3400
Yes, FC9595 or FC5595
and feature FC5247
N/A
TS7700 Virtualization Engine (3957-V06) Yes, FC9900 N/A
Tape libraries
TS3500 Library (3584-Lxx): Yes, FC9900
TS1130 requires
Advanced Library
Management System
(ALMS) (Depending on
configuration FC: 1690,
1692, 1693, or 1694)
Yes, FC9900 and FC1604
Frames for drives 3584-L22, L23, D22, and
D23
3584-L53, L52, L32, D53,
D52, and D32
z/OS, z/VM, z/VSE, and z/TPF attach Requires 3953-F05 with
3953-L05 Library
Manager
N/A
3494 library: Yes, FC9900 No
Frames for drives 3494-L22, D22, and D24 N/A
TS3400 library (3577-L5U) Yes, FC9900 No
Table 10-3 compares the encryption methods available for each tape drive environment.
Table 10-3 Encryption methods comparison
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
Encryption method or platform 3592 tape drives LTO4/LTO5 tape drive
Tivoli Storage Manager TS1120 Release 5.3.4
TS1130 Release 5.4.3 or
5.5.1
5.3.5.1
IBM z/OS (controller-attached drives) z/OS V1R7
a
or later No
IBM z/OS (TS7700 Virtualization Engine) z/OS V1R7
a
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
device driver for TS1130 -
use 11.2.9.0 or later
AIX V5.2 or later, Atape
10.4.7.0 device driver
Sun Solaris IBMTape device driver
TS1130 IBMTape.4.1.8.7
or later
IBMTape.4.1.5.0 device
driver 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
For TS1130 use 6.1.9.8 or
later. At the time of this
writing, there are no
Windows Hardware
Quality Labs (WHQL)
drivers for the TS1130
IBMTape device driver
Description 3592 tape drive family LTO4 tape drive
10.4 Choosing encryption methods
When starting to plan encryption management, several important considerations 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:
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.
Tape libraries providing this support TS3500, 3494, and
TS3400
TS3500, TS3310,
TS3200, TS3100, and
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
TS1130 use
IBMTape.4.1.8.7 or later
Sun Solaris 8, 9, or 10
IBM System i5 TS1120 i5/OS V5.2 or
later
TS1130 i5/OS V5.3 or
later
i5/OS V5.3 or later
Linux on System z SUSE Linux Enterprise
Server (SLES) 9,
SLES10, Red Hat
Enterprise Linux
(RHEL) 4, or RHEL5
SLES9, SLES10, RHEL4,
or RHEL5
Linux on other servers SLES9, SLES10, RHEL4,
or RHEL10, TS1130
requires lin_tape 1.19.0
10
SLES9, SLES10, RHEL4,
or RHEL5
HP-UX 64-bit HP-UX 11.0, 11i v1,
v2, v3, or later
atdd.84 or later
64-bit HP-UX 11i v1,
11i v2, 11iv3, or later
atdd.84 or later
Windows Windows 2000 Server,
Windows Server 2003, or
Windows Server 2008
For TS1130, use 6.1.9.8
or later. At the time of this
writing, there are no
WHQL drivers for the
TS1130.
Windows Server 2003
(build 3790 or later).
Windows Server 2008,
use 6.1.9.5 or later
a. Certain earlier releases that are no longer in service also provide support.
Encryption method or platform 3592 tape drives LTO4/LTO5 tape drive
3. Identify which server or servers will host the Encryption Key Manager (EKM) or Tivoli Key
Lifecycle Manager 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 EKM or Tivoli Key Lifecycle Manager 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 14, Planning for Encryption Key
Manager and its keystores on page 393.
We discuss Tivoli Key Lifecycle Manager and keystore planning in Chapter 11,
Planning for Tivoli Key Lifecycle Manager and its keystores on page 237.
Depending on your environment and your operating system platforms, you might use multiple
more methods of encryption. You do not have to use the same method of encryption for all
implementations.
10.4.1 Encryption method comparison
Table 10-4 lists information about encryption policy implementation and encryption key
management for each of the encryption methods, which are Application-Managed Encryption
(AME), System-Managed Encryption (SME), and Library-Managed Encryption (LME).
Table 10-4 IBM tape data encryption methods, policies, and key management
10.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.
Encryption
method
Where is the policy defined Key management
AME Tivoli Storage Manager Tivoli Storage Manager
SME For 3592 drive family:
DFSMS (z/OS)
For 3592 or LTO4 drives:
Atape device driver (AIX)
IBMTape device driver (Sun)
IBMTape device driver (Linux)
IBMTape device driver (Windows)
No HP-UX support
Either:
Encryption Key Manager (EKM)
R1 or later for TS1120. EKM R2
or later for LTO4. EKM R2.1 or
later for TS1130
Tivoli Key Lifecycle Manager
LME For 3592 drive family:
TS3500 web interface
3494 web interface or 3494 Library
Manager user interface
For LTO4 drives:
Either:
Encryption Key Manager (EKM)
R1 or later for TS1120 and EKM
R2 or later for LTO4. EKM R2.1
or later for TS1130
10.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 10-5 compares several of the differences and
considerations for open systems solutions.
Table 10-5 Comparison of open systems encryption methods
Method Policy granularity Advantages Disadvantages
AME Encryption policy is
configured at the
application GUI.
Granularity is
application-dependent.
Fewer new
responsibilities for
storage administrators
Key management is not
centralized.
Only available currently
in Tivoli Storage
Manager
SME
(using device
drivers)
Encryption is configured
(on/off) at the host for
each device driver
instance, for example, the
host-to-drive relationship.
Centralized
enterprise-class key
management
Broadest library and
non-library coverage
Requires independent
software vendor (ISV)
support for IBM tape
drive device drivers
LME Encryption is configured
(on/off) at the library GUI
for each logical grouping
of drives (for example, all
drives in a TS3500 logical
library).
Requires one of these
methods:
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
Centralized
enterprise-class key
management
Broadest application and
operating system (OS)
coverage
Not available for drives
outside an IBM tape
library
LME policy settings: 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 because of the transparency of encryption
offered through the use of EKM or Tivoli Key Lifecycle Manager. 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.
10.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 10.5, Solutions available by operating system on page 199, we indicate which encryption
methods are available for each operating system platform and tape hardware combination
and the required hardware and software prerequisites.
10.5 Solutions available by operating system
In this section, we describe the available support for each operating system.
10.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. Table 10-6 on page 200 summarizes this information.
Table 10-6 z/OS encryption support
System-Managed Encryption on z/OS has these requirements:
z/OS and z/OS.e V1R4, or later, and program temporary fixes (PTFs) required for updates
to z/OS and DFSMS
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
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 that are 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 provided support, refer to the 3592 preventive service
planning (PSP) bucket. We also discuss additional planning details in 10.8.2, TS1120 and
TS1130 compatibility considerations on page 231.
Tape library TS3500 3494 TS3400 TS3310 TS3200 TS3100
TS1120 or TS1130
tape drive attached
to controller
SME SME SME No No No
TS1120 or TS1130
tape drive attached
to TS7700
SME SME No No No No
LTO4/LTO5 tape
drive
No No No No No No
Note: z/OS V1R4, V1R5, V1R6, and V1R7 are no longer in service.
Software support: Before you encryption-enable the TS1120 drives, you must install
these software levels. 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.
Tape drives
Table 10-7 describes tape drive combinations and feature codes.
Table 10-7 Tape drive requirements for z/OS
Tape libraries
Table 10-8 describes the tape library requirements for z/OS.
Table 10-8 Tape library requirements for z/OS
Control units
Table 10-9 on page 202 describes control unit combinations and feature code prerequisites.
APARs: RACF APAR OA13030 is required on z/OS V1.4, V1.5, V1.6, and V1.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 Rivest-Shamir-Adleman algorithm (RSA) keys using
RACF to be used with JCE4758RACFKS or JCECCARACFKS keystores and your z/OS
platform is z/OS V1.4 to V1.7, you must verify that the PTF for this APAR has been applied.
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 library Machine types and models Type of update
TS3500 with
TS1130 drives
3584-L22, L23, D22, and D23 ALMS (Depending on model, FC1690,
FC1692, FC1693, or FC1694)
For the firmware update, visit
http://www.ibm.com/servers/storage/su
pport/lto/3584/downloading.html
Library Firmware 8160 or later
TS3500 with
TS1120 drives
3584-L22, L23, D22, and D23 For the firmware update, visit
3494 with
TS1130 drives
3494-L22, D22, and D24 Library Manager must be at microcode
level 536.00 or later.
3494 with
TS1120 drives
3494-L22, D22, and D24 Firmware updates shipped with FC5596
and FC9596 on the 3592-E05 drive
TS3400 with
TS1130 drives
3577-L5U Library Firmware 0032.0000 or later.
Order FC9900 for encryption configuration
documentation.
TS3400 with
TS1120 drives
3577-L5U Order FC9900 for encryption configuration
documentation.
Table 10-9 Control unit requirements for z/OS
TS7700 Virtualization Engine
Table 10-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 10-10 TS7700 Virtualization Engine tape library requirements for z/OS
10.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 SME for TS1120 drives through the 3592 Model
J70 or TS1120 Model C06 tape controllers. Table 10-11 on page 203 summarizes the
supported tape encryption methods.
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
(3952-C06)
3592-C06 Firmware update shipped with
3592-C06 FC5595 or FC9595.
Router for EKM or Tivoli Key Lifecycle Manager Attach
(only required on tape controllers for out-of-band support)
FC5593 or FC9593
3494-Lxx 3494-Lxx Firmware shipped for 3494 Library
Manager with 3592-J70 or
TS1120-C06 FC5595 or FC9595.
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.
TS3500 with
TS1130 drives
3584-L22, L23, D22, and D23 ALMS (Depending on model, FC1690,
FC1692, FC1693, or FC1694)
TS7700 microcode must be at 8.5.0.xx or
later.
TS3500 with
TS1120 drives
3494 with
TS1130 drives
3494-D22 Library Manager must be at microcode
3494 with
TS1120 drives
3494-D22 Might require FC5596 and FC9596 on the
3592-E05 drives if the Library Manager is
not at microcode level 535 or later.
Table 10-11 z/VM, z/VSE, and z/TPF available encryption methods
For z/OS prerequisites, refer to the tape libraries and control unit tables (Table 10-6 on
page 200 through Table 10-9 on page 202).
The z/VM support of SME has these requirements:
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 Tivoli Key Lifecycle Manager.
An EKM or Tivoli Key Lifecycle Manager available to the tape controller.
One of the supported tape library and tape drive combinations from Table 10-11.
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 SME has these requirements:
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 Job Control Language (JCL) in BATCH mode.
An EKM or Tivoli Key Lifecycle Manager available to the tape controller
One of the supported tape library and tape drive combinations from Table 10-11.
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 SME has these requirements:
z/TPF with APAR PJ31479
An EKM or Tivoli Key Lifecycle Manager available to the tape controller
Tape library TS3500 3494 TS3400
attached to controller
SME SME SME
SME and EKM: SME EKM does not run on z/VM, z/VSE, or z/TPF, but it is supported
through the out-of-band tape controller connection to an EKM server running on z/OS or
another EKM platform.
One of the supported tape library and tape drive combinations from Table 10-11 on
page 203.
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 19, Implementing TS7700 tape encryption on page 613 for more information.
Table 10-12 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 10-12 TS7700 Virtualization Engine tape library requirements for z/OS
10.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 (AME) is supported, but it currently
has no applications that run on the System i platform.
TS3500 with
TS1130 drives
3584-L22, L23, D22, and D23 ALMS (depending on configuration:
FC1690, FC1692, FC1693, or FC1694)
TS7700 microcode must be at 8.5.0.xx or
later
TS3500 with
TS1120 drives
3494 with
TS1130 drives
3494-D22 Library Manager must be at microcode
3494 with
TS1120 drives
3494-D22 Might require FC5596 and FC9596 on the
3592-E05 drives if the Library Manager is
not at microcode level 535 or later.
Table 10-13 i5/OS encryption support
System i support of LME has these requirements:
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 10-15 on page 206
Tape drives
Table 10-14 describes tape drive combinations and feature codes.
Table 10-14 Tape drive requirements for i5/OS
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/LTO5 tape
drive
LME No No LME LME LME
TS1130 3592-E06
3592-EU6
No features on the drive are required
for AME, SME, or LME.
TS1120 3592-E05 See TS1120 prerequisites,
encryption capable and encryption
enabled.
LTO4 3588-F4A or features of the
TS3310, TS3200, TS3100 tape
libraries and TS2900 tape
autoloader
TS2340 (stand-alone
LTO4)
3580-S43 No features are required for AME.
TS2240 (half-high
stand-alone LTO4)
3580-H4S No features are required for AME.
Tape libraries
Table 10-15 describes the tape library order options and firmware updates.
Table 10-15 Tape library requirements for i5/OS
10.5.4 AIX solution components
This section summarizes the AIX support for tape data encryption.
IBM System p running AIX supports these types of encryption:
System-Managed Encryption (SME) through the Atape device drivers
Library-Managed Encryption (LME) in conjunction with the TS3500, 3494, TS3400,
TS3310, TS3200, and TS3100 tape libraries and the TS2900 tape autoloader
Application-Managed Encryption (AME) with Tivoli Storage Manager
Tape library and
tape drive
Machine types and
models
Type of update
TS3500 with
TS1130 drives
3584-L22 and L23
3584-D22 and D23
ALMS (Depending on configuration: FC1690,
FC1692, FC1693, or FC1694)
Order FC9900.
http://www.ibm.com/servers/storage/support/
lto/3584/downloading.html
TS3500 with
TS1120 drives
3584-L22 and L23
3584-D22 and D23
Order FC9900.
3494 with
TS1130 drives
3494-L22 and D22 Order FC9900.
Library Manager must be at microcode level
536.00 or later.
3494 with
TS1120 drives
Firmware update FC0520
TS3400 with
TS1130 drives
documentation.
TS3400 with
TS1120 drives
documentation.
TS3500 with
LTO4 drives
3584-L32, L52, and L53
3584-D32, D52, and
D53
Order FC9900 and FC1604.
TS3310 with
LTO4 drives
3576-L5B and E9U Order FC9900 and FC5900, Transparent LTO
Encryption.
TS3200 with
LTO4 drives
3573-L4U Order FC9900 and FC5900, Transparent LTO
Encryption.
TS3100 with
LTO4 drives
Encryption.
Table 10-16 summarizes this information for library and drive combinations.
Table 10-16 AIX encryption support
SME with AIX has these requirements:
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 can download it from this website:
ftp://ftp.software.ibm.com/storage/devdrvr/AIX/
Device driver
For AIX SME only, Table 10-17 describes device driver order updates.
Table 10-17 Device driver requirements for AIX
LME with AIX has these requirements:
AIX V5.1, AIX V5.2, AIX V5.3, or later.
A TS3500, 3494, or TS3400 tape library with TS1120 drives and 3592 media.
A TS3500, TS3310, TS3200, or TS3100 tape library with LTO4 or LTO5 drives and
Ultrium 4 or 5 media.
Tape drives
Table 10-18 on page 208 describes tape drive combinations and feature codes.
Tape library TS3500 3494 TS3400 TS3310 TS3200 TS3100 TS2900
TS1130 tape drive
TS1120 tape drive
SME,
LME, and
AME
SME,
LME, and
AME
SME,
LME, and
AME
No No No No
LTO4/LTO5 tape drive SME,
LME, and
AME
No No SME,
LME, and
AME
SME,
LME, and
AME
SME,
LME, and
AME
SME,
LME, and
AME
Device driver Type of update
TS1130 tape drive
TS1120 tape drive
LTO Ultrium 4 tape drive
LTO Ultrium 5 tape drive
The device driver is included in the device driver web download at
ftp://ftp.software.ibm.com/storage/devdrvr/AIX/
Table 10-18 AIX tape drive requirements for encryption
Tape libraries
Table 10-19 describes tape library order options and firmware updates.
Table 10-19 AIX tape library requirements
TS1130 3592-E06
3592-EU6
No features on the drive are required for
AME, SME, or LME.
TS1120 3592-E05 See TS1120 prerequisites, encryption
capable and encryption enabled.
LTO4 and LTO5 3588-F4A No features on the drive are required for
AME, SME, or LME.
TS2340 3580-S43 No features are required for AME.
TS2240 (half-high
stand-alone LTO4)
Tape library and
tape drive
Machine types and models Type of update
TS3500 with
TS1130 drives
3584-L22 and L23
3584-D22 and D23
ALMS (Depending on configuration:
FC1690, FC1692, FC1693, or FC1694)
Order FC9900.
http://www.ibm.com/servers/storage/s
upport/lto/3584/downloading.html
TS3500 with
TS1120 drives
3584-L22 and L23
3584-D22 and D23
Order FC9900 for encryption
3494 with
TS1130 drives
Library Manager must be at microcode
3494 with
TS1120 drives
3494-L22 and D22 Firmware update FC0520
TS3400 with
TS1130 drives
TS3400 with
TS1120 drives
3577-L5U Order FC9900 for encryption
TS3500 with
LTO4 drives
3584-L32, L52, and L53
3584-D32, D52, and D53
Order FC9900 and FC1604, Transparent
LTO Encryption.
For firmware update, visit
10.5.5 Linux on System z
When the drives are connected to System z using Fibre Channel Protocol (FCP), Linux on
System z supports these types of encryption:
System-Managed Encryption (SME) through the lin_tape device drivers
Library-Managed Encryption (LME) in conjunction with the TS3500, 3494, TS3400,
TS3310, TS3200, and TS3100 tape libraries and TS2900 tape autoloader
Table 10-20 shows the encryption methods that are available on tape library and tape drive
combinations.
Table 10-20 Linux on System z supported encryption methods
TS3500 with
LTO5 drives
3584-L32, L52, and L53
3584-D32, D52, and D53
Minimum level of TS3500 Library to
support LTO5 is R10A (Axxx)
FC1700 or FC1701 is required when
the library frame type is
3584-L32/D32 or 3584-L52/D52.
These feature codes provide the
enhanced node cards that are
required for R10A level of firmware.
Model types 3584-L53/D53 already
have enhanced node cards and do
not require FC 1700/1701.
FC1604 - Transparent LTO Encryption
License key to enable transparent
LTO encryption on 3588-F4A/F5A for
SME and LME.
TS3310 with
LTO4 drives
3576-L5B and E9U Order FC9900 and FC5900, Transparent
LTO Encryption
TS3200 with
LTO4 drives
3573-L4U Order FC9900 and FC5900, Transparent
LTO Encryption
TS3100 with
LTO4 drives
3573-L2U Order FC9900 and FC5900, Transparent
LTO Encryption
TS2900 with
LTO4 drives
3572-S4H Order FC9900 and FC5901, Transparent
LTO Encryption
Tape library and
tape drive
TS1120 and TS1130
tape drive
SME,
LME, and
AME
SME,
LME, and
AME
SME,
LME, and
AME
No No No No
LME, and
AME
No No SME,
LME, and
AME
SME,
LME, and
AME
SME,
LME, and
AME
SME,
LME, and
AME
SME with Linux on System z has these requirements:
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 website:
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.
LME with Linux on System z has these requirements:
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, or TS3100 tape library or a TS2900 tape autoloader with
LTO4 or LTO5 drives and Ultrium 4 or 5 media
10.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
these types of encryption:
System-Managed Encryption (SME) with lin_tape device drivers
Library-Managed Encryption (LME) on the TS3500, 3494, TS3400, TS3310, TS3200, and
TS3100 tape libraries and TS2900 tape autoloader
Table 10-21 shows the encryption methods that are available on tape library and tape drive
combinations.
Table 10-21 Linux-supported encryption methods
SME with Linux has these requirements:
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
TS1120 and TS1130 tape
drive
SME,
LME, and
AME
SME,
LME, and
AME
SME,
LME, and
AME
No No No No
LME, and
AME
No No SME,
LME,
and AME
SME,
LME, and
AME
SME,
LME, and
AME
SME,
LME, and
AME
The lin_tape device drivers supporting encryption must be installed, updated, and utilized.
Download the lin_tape device drivers from the following website:
ftp://ftp.software.ibm.com/storage/devdrvr/Linux
LME has these requirements:
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 10-21 on page 210
Tape drive
Table 10-22 describes the tape drive combinations and feature codes.
Table 10-22 Linux tape drive requirements for encryption
TS1130 3592-E06
3592-EU6
TS1120 3592-E05 new drive order See TS1120 prerequisites, encryption
capable and encryption enabled.
TS1120 3592-E05 field upgrade for
encryption
TS3310, TS3200, and TS3100
tape libraries
TS2240 (half-high
stand-alone LTO4)
Tape libraries
Table 10-23 Linux tape library requirements
Tape library and
tape drive
TS3500 with
TS1130 drives
3584-L22 and L23
3584-D22 and D23
ALMS (Depending on configuration:
FC1690, FC1692, FC1693, or FC1694)
Order FC9900.
TS3500 with
TS1120 drives
3584-L22 and L23
3584-D22 and D23
3494 with
TS1130 drives
Library Manager must be at microcode
3494 with
TS1120 drives
3494-L22 and D22 Firmware update FC0520
TS3400 with
TS1130 drives
TS3400 with
TS1120 drives
3577-L5U Order FC9900 for encryption
TS3500 with
LTO4 drives
3584-L32, L52, and L53
3584-D32, D52, and D53
Order FC9900 and FC1604, Transparent
LTO Encryption.
TS3500 with
LTO5 drives
3584-L32, L52, and L53
3584-D32, D52, and D53
Minimum level of TS3500 library to
FC1700 or FC1701 are required
when the library frame type is
3584-L32/D32 or 3584-L52/D52
enhanced node cards that are
required for R10A level of firmware
Model types 3584-L53/D53 already
have enhanced node cards and do
not require FC 1700/1701
FC1604 - Transparent LTO
Encryption
License key to enable transparent
LTO encryption on 3588-F4A/F5A for
SME and LME.
TS3310 with
LTO4 drives
3576-L5B and E9U Order FC5900, Transparent LTO
Encryption
TS3200 with
LTO4 drives
3573-L4U Order FC5900, Transparent LTO
Encryption
10.5.7 HP-UX, Sun, and Microsoft Windows components
This section summarizes the encryption support of these operating systems and their tape
drive and tape library requirements.
This section describes the support of HP-UX, Sun Solaris, and Microsoft Windows systems.
HP-UX systems
HP-UX supports the following encryption methods:
LME on the TS3500, 3494, TS3400, TS3310, TS3200, and TS3100 tape libraries and the
TS2900 tape autoloader
AME with Tivoli Storage Manager
LME with HP-UX has these requirements:
HP-UX 11.0, 11i v1, 11i 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, or TS3100 tape library or TS2900 tape autoloader
LTO4 or LTO5 drives and Ultrium 4 or Ultrium 5 media
Sun Solaris systems
Sun Solaris supports the following encryption methods:
SME through the IBMTape device drivers
LME in conjunction with the TS3500, 3494, TS3400, TS3310, TS3200, and TS3100 tape
libraries and TS2900 tape autoloader
SME with Sun Solaris has these requirements:
Sun Solaris 8, 9, and 10
An Encryption Key Manager or Tivoli Key Lifecycle Manager that is 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 website:
ftp://ftp.software.ibm.com/storage/devdrvr/Solaris/
LME with Sun Solaris has these requirements:
TS3100 with
LTO4 drives
3573-L2U Order FC5900, Transparent LTO
Encryption
TS2900 with
LTO4 drives
3572-S4H Order FC9900 and FC5901, Transparent
LTO Encryption
Tape library and
tape drive
LTO4 or LTO5 drives and Ultrium 4 or Ultrium 5 media
Microsoft Windows systems
Microsoft Windows supports these types of encryption:
SME through the IBMTape device drives
LME in conjunction with the TS3500, 3494, TS3400, TS3310, TS3200, or TS3100 tape
library, or a TS2900 tape autoloader
SME with Microsoft Windows has these requirements:
Microsoft Windows 2000 Server, Windows Server 2003, or Windows Server 2008
An Encryption Key Manager or Tivoli Key Lifecycle Manager that is available to the
Microsoft Windows system
The IBMTape device drivers supporting encryption must be installed, updated, and
utilized. Download the IBMTape device drivers from the following website:
ftp://ftp.software.ibm.com/storage/devdrvr/Windows/
LME on Microsoft Windows has these requirements:
Microsoft Windows 2000 Server, Windows Server 2003, or Windows Server 2008
An Encryption Key Manager or Tivoli Key Lifecycle Manager that is available to the library
LTO4 or LTO5 drives and Ultrium 4 or 5 media
Table 10-24 and Table 10-25 on page 215 describe the tape drive and the tape library order
options and firmware updates.
Tape drives
Table 10-24 lists the tape drive combinations and feature codes for the operating systems.
Table 10-24 HP, Sun, and Microsoft Windows tape drive requirements for encryption
TS1130 3592-E06
3592-EU6
for SME, LME, and AME.
TS1120 3592-E05 new drive order See TS1120 prerequisites,
encryption capable and encryption
enabled.
TS1120 3592-E05 field upgrade for
encryption
TS3310, TS3200, and TS3100
tape libraries
for SME, LME, and AME.
TS2240 (half-high
stand-alone LTO4)
Tape libraries
Table 10-25 HP, Sun, and Microsoft Windows tape library requirements
Tape library with
tape drive
Machine types and
models
Type of update
TS3500 with
TS1130 drives
3584-L22 and L23
3584-D22 and D23
ALMS (Depending on configuration, FC1690,
FC1692, FC1693, or FC1694)
Order FC9900.
http://www.ibm.com/servers/storage/supp
ort/lto/3584/downloading.html
TS3500 with
TS1120 drives
3584-L22 and L23
3584-D22 and D23
Order FC9900.
3494 with
TS1130 drives
Library Manager must be at microcode level
536.00 or later.
3494 with
TS1120 drives
Firmware update FC0520
TS3400 with
TS1130 drives
documentation.
TS3400 with
TS1120 drives
documentation.
TS3500 with
LTO4 drives
3584-L32, L52, and L53
3584-D32, D52, and D53
Order FC9900 and FC1604.
TS3500 with
LTO5 drives
3584-L32, L52, and L53
3584-D32, D52, and D53
Minimum level of TS3500 Library to
FC1700 or FC1701 is required when the
library frame type is 3584-L32/D32 or
3584-L52/D52
enhanced node cards that are required
for R10A level of firmware.
Model types 3584-L53/D53 already have
enhanced node cards and do not require
FC 1700/1701.
FC1604 - Transparent LTO Encryption
License key to enable transparent LTO
encryption on 3588-F4A/F5A for SME
and LME.
TS3310 with
LTO4 drives
3576-L5B and E9U Order FC9900 and FC5900, Transparent LTO
Encryption.
TS3200 with
LTO4 drives
Encryption.
10.5.8 Tivoli Storage Manager
Currently, Tivoli Storage Manager is currently the only application that provides AME for
TS1130, TS1120, LTO4, and LTO5 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, LTO4, or LTO5 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 or LTO5 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 AME, refer to your Tivoli Storage Manager documentation or visit
the following website for more information:
http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/index.jsp
10.6 Ordering information
This section describes the features and microcode levels that you might need to order and
install to support your encryption solution. We discuss the following prerequisites:
TS1130 tape drive
TS1120 tape drive
LTO4 tape drive
LTO5 tape drive
Tape libraries
Tape controllers
TS7700 Virtualization Engine
General software
10.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.
TS3100 with
LTO4 drives
Encryption.
TS2900 with
LTO4 drives
3572-S4H Order FC9900 and FC5901, Transparent LTO
Encryption.
Tape library with
tape drive
Machine types and
models
Type of update
Encryption-capable drives
The TS1120 tape drive has these prerequisites:
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 drives
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.
Order these encryption-enabled environment prerequisite features (if any):
For System z TS1120 tape drives attached to a 3592 Model J70 or a TS1120 Model C06
tape controller, read 10.6.2, Tape controller prerequisites on page 218.
For open systems-attached TS1130 drives in a TS3500 tape library, ALMS is required
depending on the library configuration FC1690 for L22 libraries, FC1692, FC1693, or
FC1694, 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, use a licensed internal code level lower than 535), order
FC9596 (plant-installed) or FC5596 (field-installed) 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-installed) or FC5596 (field-installed) for each drive to be enabled.
These features provide instructions and procedures for the SSR to enable encryption for
the drive and to set the encryption method for the drive.
10.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, 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 that is 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 that is required for the 3590-A60
enterprise tape controller, order FC0520 (Function Enhancement Field).
For TS1120 or TS1130 drives attached to the z/OS, z/VM, z/VSE, or z/TPF System z
platforms, 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 SME method for all of the TS1120 or TS1130 drives attached
to the tape 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. Order FC5593 (Router for
EKM Attach), which provides dual routers to allow redundant connections between the tape
controller and EKM or Tivoli Key Lifecycle Manager. 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.
CU Encryption Configuration feature: When one of the CU Encryption Configuration
features is installed, it is not necessary to order the Encryption Configuration/Plant or Field
(FC9596/FC5596) feature code on the TS1120 tape drives that are attached to the
controller. The CU Encryption Configuration feature enables encryption for all
encryption-capable TS1120 drives that are 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.
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.
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 the 3953 Model F05 containing FC5505, Base Frame. This feature
supports up to sixteen 3592 or TS1120 tape controllers in a 3953 Tape System.
For the latest details about specific hardware, software, and Fibre Channel support for the
IBM TS1120 Tape Drive, refer to the following website:
http://www-03.ibm.com/systems/storage/tape/pdf/compatibility/ts1120_interop.pdf
10.6.3 LTO4 and LTO5 tape drive prerequisites
For an LTO4 or LTO5 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 and LTO5 tape drives are encryption capable (without any features), as long as
they use Ultrium 4 or 5 media, therefore, meeting LTO consortium specifications.
The LTO4 or LTO5 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.
Important: 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.
10.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 supported in the TS3500 tape
library models L23, L22, D23, and D22. The IBM LTO4 and LTO5 tape drives can be installed
and 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
clients responsibility to load, configure, and maintain the TS3500 tape library.
When using a TS1130, Automated Library Management System (ALMS) is required.
Depending on the library configuration, this feature code might be FC1690 for L32, L22, or
L52 libraries and FC1692, FC1693, or FC1694, depending on the level of capacity expansion
installed.
If you plan to use LME or SME encryption methods for LTO4 or LTO5 drives in the TS3500
tape library, you must also order FC1604, Transparent LTO Encryption. The AME encryption
method for LTO4 or LTO5 drives does not require FC1604.
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 the SME or AME method in the 3494.
You must order no-charge FC9900, Encryption Configuration, on the Lxx frame of the 3494 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 the 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 tape drive, or TS1130 tape drive.
With this support, the encryption, WORM, and standard tape cartridges in all sizes (JA, JB,
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.
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 following levels are the minimum levels of microcode firmware:
For OSLME, the minimum level is the Library Manager 535.xx code.
For TS1130, the minimum level is the Library Manager 536.xx code.
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) uses these feature codes:
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) uses these feature codes:
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.
To support any encryption, order no-charge FC9900, Encryption Configuration. If you plan to
use the LME or SME method, also order chargeable FC5900, Transparent LTO Encryption.
AME method does not require FC5900.
TS3200 or TS3100 tape library prerequisites
The AME method does not require FC5900.
TS2900 tape autoloader prerequisites
The AME method does not require FC5900.
10.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 following level is the minimum level of microcode firmware:
D3I0_851 for the IBM 3592-J1A Enterprise Tape Drive
D3I1_919 for the IBM TS1120 Tape Drive (3592-E05)
The following level is the minimum level of microcode firmware with TS1130 E3 formatted
media:
D3I0_C90 for the IBM 3592-J1A Enterprise Tape Drive
D3I1_DA0 for the IBM TS1120 Tape Drive (3592-E05)
You can upgrade the drive microcode levels or order these microcode levels as FC0500 on
the drive.
10.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. The following levels are the
current microcode requirements:
TS1130 drives in a TS3500 library:
TS7700 Virtualization Engine licensed internal code level 8.5.0.xx or later is required.
With 8.5.0.xx, the 3943 Library Manager is no longer required.
The TS1120 drives are in a TS3500 library:
TS7700 Virtualization Engine licensed internal code level 8.2.0.19 or later is required.
The 3953 Library Manager licensed internal code level 534.31 or later is required.
The TS1130 drives are in a 3494 library:
TS7700 Virtualization Engine microcode level 8.5.0.xx or later is required.
The 3494 Library microcode level 536.0 or later is required.
The TS1120 drives are in a 3494 library:
TS7700 Virtualization Engine microcode level 8.2.0 27 or later is required.
The 3494 Library microcode level 534.31 or later is required.
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 the
software already supports the TS7700 without encryption.
10.6.7 General software prerequisites for encryption
In this section, we describe general information about the operating system software
requirements. We describe the specific information about the software release levels in the
following sections where we describe each operating system in detail. The following list
describes support for encryption on certain environments and its availability:
Support for encryption on the TS1120 or TS1130 on 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 on the z/VM, z/VSE, or z/TPF operating
system environment 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 on open systems environments is provided in
the i5/OS, AIX, HP-UX, Linux, Sun, Microsoft Windows 2000 Server, Microsoft Windows
Server 2003, or Microsoft Windows Server 2008 operating system environment.
Support for encryption on LTO4 in Open Systems environments is provided in the i5/OS,
AIX, HP-UX, Linux, Sun, Microsoft Windows 2000 Server, Microsoft Windows Server
2003, or Microsoft Windows Server 2008 operating system environment.
The installation of a TS1120, TS1130, LTO4, or LTO5 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 that are required for their particular software
environment prior to the installation of the TS1130 or TS1120 with encryption or the LTO4 or
LTO5 with encryption. A solutions assurance call is required at a minimum for the installation
of the first new TS1130 or TS1120 tape drive or LTO4 or LTO5 tape drive with encryption that
is activated in a clients account.
To obtain an update of the open systems device drivers, use anonymous FTP:
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 website 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 website:
10.6.8 TS1120 and TS1130 supported platforms
The TS1120 and TS1130 tape drives are supported in a wide 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
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, and
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 10-26 shows the encryption options
available for the TS1120 and TS1130 in the mainframe environments. Table 10-27 on
page 225 shows the encryption options available for the TS1120 and TS1130 in open
systems environments.
Table 10-26 Mainframe-attached TS1120 and TS1130 encryption solution options
Requirement: A tape controller is required for attachment to ESCON or FICON
channels on IBM mainframe servers.
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 10-27 Open systems-attached TS1120 and TS130 encryption solution options
Additional information about TS1120 and TS1130 tape drives is in the announcement letter.
10.6.9 IBM LTO4 and LTO5 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 and LTO5 tape drives are available in the TS3500, TS3310,
TS3200, and TS3100 tape libraries and the TS2900 tape autoloader. LTO4 is also available
as a drive only with the TS2340 and TS2240. LTO5 is available as a drive only with the
TS2350 and TS2250. Table 10-28 shows the encryption options that are available for these
environments.
Table 10-28 Open systems-attached LTO4 encryption solution options
Refer to these resources for more information about this support:
Obtain information about the LTO4 or LTO5 tape drive in the announcement letter.
Obtain an update of the open systems device drivers through anonymous FTP:
Look under the specific directory for your operating system environment.
Refer to IBM Tape and Medium Changer Device Drivers for AIX, HP-UX, Linux, Solaris
and Windows, GC27-2130:
Open systems-attached IBM tape library Open systems-attached rack or silo
AME (Tivoli Storage Manager only)
SME (AIX, Solaris, Microsoft Windows, or Linux
only)
LME (TS3500, 3494, or TS3400 tape library)
only)
Open systems-attached in IBM tape library Open systems-attached TS2340 drive
only)
LME (TS3500, TS3310, TS3200, and 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, and TS2900 is all or nothing (entire partition or not).
only)
10.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.
10.7.1 In-band and out-of-band
SME is the only encryption method available for z/OS environments and requires the
Encryption Key Manager (EKM) or Tivoli Key Lifecycle Manager program. See Figure 10-1.
Figure 10-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 10-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 Tivoli Key Lifecycle Manager component travel over the ESCON/FICON channels to
the server proxy that is TCP/IP-connected to EKM or Tivoli Key Lifecycle Manager. The
second key flow is out-of-band encryption where the tape controller establishes the
communication to the EKM or Tivoli Key Lifecycle Manager server over TCP/IP connections
between the tape controller and the EKM or Tivoli Key Lifecycle Manager server. A router is
required for out-of-band and EKM support.
2003 IBM Corporation
z/OS
Java Virtual Machine
Key Manager (TCP/IP)
Common Platform Java Code
DFSMS
FICON Proxy to Key Manager
In-band Key Management
Across ESCON/FICON
Key Store
3592 Model
E05
J70 or C06 Control
Unit
SMS Policy
Data Class
Encrypt?
Key Labels?
(VM, VSE, TPF, or even z/OS) - out-of-band Key Management (TCP/IP)
Control Unit across TCP/IP to z/OS or elsewhere
Open Systems
Hosts
Another z/OS
(or Open Systems)
Host
Key
Manager
-OR- TCP/IP
Translates
in-band key
exchanges
TCP/IP
ESCON / FICON (in-band key management)
TCP/IP
TCP/IP
(out-of-band
Key
Management)
TCP/IP to Key
Manager
under z/OS or
elsewhere
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 EKM or Tivoli Key
Lifecycle Manager. 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 Tivoli Key Lifecycle Manager primary and
secondary server addresses from the operator console.
Out-of-band encryption
With out-of-band encryption, EKM and Tivoli Key Lifecycle Manager 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 EKM or Tivoli Key Lifecycle
Manager for which that drive was set up. With in-band encryption, you can potentially have
each z/OS image point to a separate EKM or Tivoli Key Lifecycle Manager, with each pointing
to a separate keystore. This approach allows images sharing drives to be able to use
separate keystores. You might find this method useful if you have to support a customer or an
application where each customer 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, 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.
10.7.2 Performance considerations
Unlike software encryption or encryption appliances, the TS1130, TS1120, LTO4, or LTO5
encryption solutions can encrypt data with minimal data transfer performance effect and
without requiring additional equipment in the computing environment. You might be
concerned if encryption affects 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 15, Implementing
the Encryption Key Manager on page 413 and Chapter 11, Planning for Tivoli Key Lifecycle
Manager and its keystores on page 237 for more information. Reading an encrypted
cartridge also increases the mount time because of the time that is necessary to retrieve the
encryption keys.
10.7.3 Encryption with other backup applications
All backup applications that are currently supported on any of the IBM tape libraries can
support LME, because the application is not involved in the encryption process. Applications
include Symantec NetBackup, EMC NetWorker, CommVault Galaxy, and BakBone NetVault,
for example.
10.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, LTO4, or LTO5
drives, use 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 describes the rules. For more
information, see IBM System Storage TS3500 Tape Library Advanced Library Management
System (ALMS) and Encryption, by Anthony Abete at this website:
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 all the drives must be 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, or
AME.
All 3592 logical libraries must be managed in the same manner, that is SME, LME, or
AME.
However, LTO and 3592 tape drives can be managed differently. For example, all LTO drives
can be LME and 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 will 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
non-encryption-capable 3592 drives.
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 or LTO5 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.
In summary:
On an existing TS3500 library without ALMS
Without ALMS, implementing encryption on an existing library is extremely 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 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.
10.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.
ALMS: 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.
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 partners
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 As public
key. When Business Partner A finishes with the tape, Business Partner A needs 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 As public key to Business Partner Bs public key without
having to rewrite the complete data portion of the tape. We provide details for performing
rekeying in z/OS in 18.9, TS1120 and TS1130 tape cartridge rekeying in z/OS on page 608.
The approach for compromised certificates is similar. You use rekeying to make the tape
unreadable by anyone possessing the compromised certificate or private key.
10.8 Upgrade and migration considerations
In this section, we provide you with important information for upgrading or migrating to tape
data encryption.
10.8.1 Potential issues
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 separate 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 Virtual Tape Server (VTS) code
2.32.745.x or later and Library Manager 532.xx or later.
3592-J1A drives attached to the 3494 VTS model 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.
10.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 five modes:
EEFMT3 Enterprise Tape Format 3 with encryption enabled
EFMT3 Enterprise Tape Format 3
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 separate 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:
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 separate 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, existing Device Services support
prevents the encryption-enabled TS1120 tape drives from coming online on a system that
does not have all 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 is displayed to the host as a
3592-2 without the 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 installations
DFSMSdss jobs. It does, however, require changes to your installations 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 the TS1120 Model E05 devices
under the same control unit must 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 error-recording data set (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
various 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 X12 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 X13.
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 methods (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 cross-system coupling facility (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 zeros.
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.
DFSMSrmm coexistence support 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 removable media manager (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: RMMs 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 it also tolerates CDS records containing encryption key
labels.
10.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
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.
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.
10.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 that are available on z/OS.
Figure 10-2 compares the areas to consider when implementing the complementary solutions
of TS1120 Tape Encryption and the Encryption Facility for z/OS.
Figure 10-2 Comparing Encryption Facility for z/OS and TS1120 Tape Encryption solutions
Key failover
Performance
Audit and access
control
Performance
Key retention
Enterprise wide key
management
Audit and access
control
Compatibility
Key Distribution/
manageability/
security
Audit and access
control
IBM Encryption
Capable TS1120 Tape
Drive
(Archive and
backup/restore)
Key failover
Performance
Audit and access
control
Performance
Key retention
Enterprise wide key
mgmt.
Audit and access
control
Compatibility
Key Distribution/
manageability/
security
Audit and access
control
IBM Encryption
Facility for z/OS
(Business Partner
Exchange)
Backup/Restore Archival
Business Partner
Exchange
Depends on Customer
Requirements
Satisfies requirement
Key failover
Performance
Audit and access
control
Performance
Key retention
Enterprise wide key
management
Audit and access
control
Compatibility
Key Distribution/
manageability/
security
Audit and access
control
IBM Encryption
Capable TS1120 Tape
Drive
(Archive and
backup/restore)
Key failover
Performance
Audit and access
control
Performance
Key retention
Enterprise wide key
mgmt.
Audit and access
control
Compatibility
Key Distribution/
manageability/
security
Audit and access
control
IBM Encryption
Facility for z/OS
(Business Partner
Exchange)
Backup/Restore Archival
Business Partner
Exchange
Depends on Customer
Requirements
Satisfies requirement
Can use the same mainframe centralized key management
Chapter 11. Planning for Tivoli Key Lifecycle
In this chapter, we discuss planning for the Tivoli Key Lifecycle Manager. Tivoli Key Lifecycle
Manager is required before encryption can be enabled on the DS8000. You must implement
either Tivoli Key Lifecycle Manager or Encryption Key Manager (EKM) before you can encrypt
any tape using System-Managed Encryption (SME) or Library-Managed Encryption (LME).
Application-Managed Encryption (AME) does not require a Tivoli Key Lifecycle Manager or
EKM implementation. This planning can occur even before your hardware arrives.
Chapter 12, Implementing Tivoli Key Lifecycle Manager on page 265 completely describes
the implementation of Tivoli Key Lifecycle Manager on 64-bit Microsoft Windows Server 2008
and Linux.
Tivoli Key Lifecycle Manager provides life cycle management for the keys and certificates of
an enterprise.You can use it as a keystore for encryption-capable IBM storage, such as the
DS8000 storage subsystems or the TS1120, TS1130, and IBM LTO4 tape drive.
You must decide on what platform (or platforms) the Tivoli Key Lifecycle Manager will run. We
suggest that you implement Tivoli Key Lifecycle Manager only on a single operating system
type to allow easier Tivoli Key Lifecycle Manager synchronization between primary and
secondary Tivoli Key Lifecycle Manager instances using the backup/restore function.
In this chapter, we first provide a Tivoli Key Lifecycle Manager planning quick reference, then
we describe the requirements for each of the platforms where Tivoli Key Lifecycle Manager
can run. Then, we describe various Tivoli Key Lifecycle Manager and keystore
implementation considerations.
11
11.1 Tivoli Key Lifecycle Manager planning quick reference
Table 11-1 compares the encryption characteristics of the DS8000 disk drives and the
TS1120, TS1130, and LTO4 tape drives. Table 11-2 on page 239 and Table 11-3 on page 240
compare the Tivoli Key Lifecycle Manager software prerequisites for each platform.
We took these requirements from the Tivoli Key Lifecycle Manager Installation and
Configuration Guide, SC23-9977, and from the Tivoli Key Lifecycle Manager Information
Center at this website:
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.tk
lm.doc/welcome.htm
Description DS8000 TS1120 tape drive TS1130 tape drive LTO4 tape drive
Encryption standard Advanced Encryption
Standard (AES)
(128-bit) Electronic
Code Book (ECB -
block cipher) Mode
AES (256-bit) AES (256-bit) AES (256-bit)
Encryption process
for data
Symmetric AES
(128) Electronic
Code Book (ECB -
block cipher) mode
Symmetric AES
(256)
Symmetric AES
(256)
Symmetric AES
(256)
Encryption key model Wrapped keys Wrapped key Wrapped key Direct key
Encryption type for
data keys
Public-private key
(Asymmetric)
Public-private key
(Asymmetric)
Public-private key
(Asymmetric)
None
Data keys used Unique data key for
each drive (this is a
drive-generated key -
not the key served by
Tivoli Key Lifecycle
Manager)
Unique data key for
each cartridge
Unique data key for
each cartridge
Keylist: A list or range
of data keys used,
pregenerated in
keystore
Data keys stored? Wrapped (that is,
encrypted) data keys
(2) stored on disk,
called externally
encrypted data key
(EEDK)
Wrapped (that is,
(2) stored on
cartridge, called
EEDKs
Wrapped (that is,
(2) stored on
cartridge, called
EEDKs
Stored in keystore
Keystore Contains private keys
and certificates
representing public
keys.
Preloaded in
keystore
Contains private keys
and certificates
representing public
keys.
Preloaded in
keystore
Contains private keys
and certificates
representing public
keys.
Preloaded in
keystore
Contains data keys
that have been
pregenerated
Keystore types
supported by Tivoli
Key Lifecycle
Manager on
distributed systems
JCEKS (All
platforms)
JCEKS (All
platforms)
JCEKS (All
platforms)
JCEKS (All
platforms)
Chapter 11. Planning for Tivoli Key Lifecycle Manager and its keystores 239
Table 11-2 lists the current platforms on which you can install Tivoli Key Lifecycle Manager.
Table 11-2 Tivoli Key Lifecycle Manager software platforms
Fix Pack 1 (April 2009) added additional platform support (remember to read the readme file
for the latest prerequisite information and other limitations). Table 11-3 on page 240 shows
the details.
Description
Patch or maintenance level at the
time of the initial publication
AIX Version 5.3 64-bit, and Version 6.1 64-bit For Version 5.3, use Technology Level 5300-04
and Service Pack 5300-0402
Sun Server Solaris 10 (SPARC 64-bit)
Note: Tivoli Key Lifecycle Manager runs in a
32-bit Java virtual machine (JVM).
None
Windows Server 2003 R2 (32-bit Intel) None
Red Hat Enterprise Linux AS Version 4.0 on
x86 32-bit
compat-libstdc++-33-3.2.3-47.3 package. Run
rpm -qa | grep -i "libstdc" to verify that the
package is present. Tivoli Key Lifecycle Manager
problems occur on Linux operating systems if the
Security Enhanced Linux (SELINUX) setting is
enabled.
SUSE Linux Enterprise Server Version 9 and 10
on x86 (32-bit)
compat-libstdc++-33-3.2.3-47.3 package. Run
rpm -qa | grep -i "libstdc" to verify that it is
present. Tivoli Key Lifecycle Manager problems
occur on Linux operating systems if the Security
Enhanced Linux (SELINUX) setting is enabled.
z/OS Version 1 Release 9 or later Unlike the distributed version, the required
middleware (for example, DB2 or System
Services Runtime Environment (SSRE)) is not
provided by the product.
Table 11-3 Additional platform support introduced with Fix Pack 1
Table 11-4 lists the hardware configuration that is required to run the distributed Tivoli Key
Lifecycle Manager. See the Tivoli Key Lifecycle Manager Information Center for z/OS
requirements:
lm.doc/welcome.htm
Table 11-4 Tivoli Key Lifecycle Manager hardware recommended requirements
Access requirements
To install Tivoli Key Lifecycle Manager, you must have separate access levels by platform.
Microsoft Windows requires a user with Administrator access. Linux, Solaris, and AIX require
root access.
Description
Notes, patches, and maintenance level at the
time of the initial publication
Red Hat Enterprise Linux AS Version 5.0 on
x86 32-bit and 64-bit
On 64-bit platform, it runs as a 32-bit application.
Requires the 32-bit i386 rpm installation of
compat-libstdc++-33-3.2.3-61 or later (run this
command to check:
rpm -qa | grep -i "libstdc").
Tivoli Key Lifecycle Manager problems occur on
Linux operating systems if the Security Enhanced
Linux (SELINUX) setting is enabled.
Solaris 9 SPARC 64-bit N/A
SUSE Linux Enterprise Server 10 64-bit On 64-bit platform, it runs as a 32-bit application.
Requires the 32-bit i386 rpm installation of
compat-libstdc++-33-3.2.3-61 or later (run this
command to check:
rpm -qa | grep -i "libstdc").
Tivoli Key Lifecycle Manager problems occur on
Linux operating systems if the Security Enhanced
Linux (SELINUX) setting is enabled.
Windows Server 2003 64-bit On 64-bit platform, it runs as a 32-bit application.
Requires both a new installation image and Fix
Pack 1 installation
Windows Server 2008 32-bit and 64-bit On 64-bit platform, it runs as a 32-bit application.
Requires both a new installation image and Fix
Pack 1 installation.
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
Browser support
The Tivoli Key Lifecycle Manager server is accessed using a web browser (Firefox 2.0.0.14,
Internet Explorer 6.0.x SP1, or Internet Explorer 7.0). Note that AIX and z/OS have no
supported browsers; the Tivoli Key Lifecycle Manager interface must be accessed across the
network using one of the supported browsers running on another platform. With Tivoli Key
Lifecycle Manager 1.0, Firefox 3.0.3 did not render all pages correctly, although Firefox
2.0.0.17 did. See Table 11-5 for the full list of supported browsers.
Table 11-5 Supported browsers
11.2 Tivoli Key Lifecycle Manager and keystore considerations
There are many considerations when deciding how and where to run Tivoli Key Lifecycle
Manager.
Tivoli Key Lifecycle Manager platforms
The following platforms support Tivoli Key Lifecycle Manager at the time of this publication:
AIX 5.3 and 6.1
Sun Server Solaris 9 and 10 (SPARC 64 bit)
Windows Server 2003 R2 (32 bit and 64 bit)
Windows Server 2008 (32 bit and 64 bit)
Red Hat Enterprise Linux AS Version 4.0 on x86 32 bit
Red Hat Enterprise Linux AS Version 5.0 on x86 32 bit and 64 bit
SUSE Linux Enterprise Server Version 9 on x86 32 bit
SUSE Linux Enterprise Server Version 10 on x86 32 bit and 64 bit
z/OS V1.9
For availability and disaster recovery reasons, you might want to have more than one Tivoli
Key Lifecycle Manager (typically, you have at least a primary and a secondary Tivoli Key
Lifecycle Manager). Run all the Tivoli Key Lifecycle Manager servers on the same operating
system (OS) platforms. That way, keeping the Tivoli Key Lifecycle Manager servers
synchronized is easier, because you can use the backup and restore mechanism. If the Tivoli
Key Lifecycle Managers are on separate platforms, you cannot use backup/restore. You must
use key export/import, which is as comprehensive. In all cases, you want Tivoli Key Lifecycle
Browser Fix pack,
patch, and
maintenance
level
requirements
AIX z/OS Sun server
Solaris
(SPARC)
Microsoft
Windows
Server
2003
Red Hat
Enterprise
Linux AS
SUSE
Linux
Enterprise
Server
Microsoft
Internet
Explorer
Version
6.0x
Service Pack 1 Deploy a
remote
browser on
a separate
computer
Deploy
these
versions of
Microsoft
Internet
Explorer
on a
separate
computer
No Yes No No
Microsoft
Internet
Explorer
Version 7.0
None No Yes No No
Firefox
Version
2.0.0.14
None Not
supported
on z/OS
Yes Yes Yes Yes
Manager to run on a highly available platform that will be available anytime that you need
access to the drives. If you have a disaster recovery site, also have a Tivoli Key Lifecycle
Manager at this site or a way to rapidly deploy a Tivoli Key Lifecycle Manager with the current
keystore and configuration.
Most likely, you use the DS8000 disk drives with System z, and you will probably install Tivoli
Key Lifecycle Manager on System z as the primary Tivoli Key Lifecycle Manager. Because of
the dangers of encryption lockout (see 3.4.2, Encryption deadlock on page 67), a System x
machine running Tivoli Key Lifecycle Manager on SUSE Linux ships with the DS8000 to be
used as an independent isolated key server. Therefore, backup/restore cannot be used to
keep the Tivoli Key Lifecycle Manager on System z in synchronization with the Tivoli Key
Lifecycle Manager on System x. You must use key export/import, which we describe in 3.4.4,
Dual platform key server support on page 70. Dual key server support is nominally only
needed if the Tivoli Key Lifecycle Manager on System z operates in secure key mode with a
hardware keystore/Hardware Security Module (HSM) configuration. Dual key server support
allows for Tivoli Key Lifecycle Manager on System z to operate a highly secure hardware
keystore that does not support the export of private key material to a distributed key server or
a key server with less stringent key server modes.
Employing the keystore deployment model
At the time of this writing, JCEKS (file-based) is the only supported keystore on distributed
Tivoli Key Lifecycle Manager. Refer to Table 11-6.
Table 11-6 Comparison of supported keystores
On z/OS, Tivoli Key Lifecycle Manager supports the following keystores:
JCEKS (JCE software provider)
Use this keystore type if you use only Java software for all operating systems and a 3592
tape drive, LTO tape drive, or DS8000 Turbo drive. Ensure that the flat file JCEKS keystore
resides in a restricted area of the file system on the Tivoli Key Lifecycle Manager system.
Use a JCEKS keystore for all operating systems other than z/OS. You might also use this
keystore type on a z/OS system if you want to use Java Cryptography Extension (JCE)
software and a flat file to store keys.
JCERACFKS (IBMJCE software provider):
Use this keystore type to store key material in your Resource Access Control Facility
(RACF) keyring that is not using Integrated Cryptographic Services Facility (ICSF) for a
z/OS operating system with a 3592 tape drive or DS8000 Turbo drive. This keystore
type does not support symmetric keys and, so, is not used with LTO drives.
JCERACFKS keystores are compatible with both IBMJCECCA and IBMJCE, that is,
with both hardware and software providers. When configured, certificates and key
material are stored in RACF/System Authorization Facility (SAF). The JCERACFKS
keystore makes use of all the security advantages of RACF/SAF while storing the key
in RACF/SAF.
Keystore
type
Platforms
supported
DS8000,
TS1120, and
TS1130 (stores
key pairs and
certificates)
LTO4 (stores
symmetric
keys)
DS8000,
TS1120,
TS1130, and
LTO4
Symmetric
key tools
available
JCEKS All Yes Yes Yes keytool
If you use both types of tape drives and you have a separate tape library for each type,
you can have these setups:
One Tivoli Key Lifecycle Manager running with a JCERACFKS keystore for the
3592 tape drive or the DS8000 Turbo drive
Another Tivoli Key Lifecycle Manager running with a JCEKS or JCECCAKS
keystore for the LTO tape drive
JCECCARACFKS (IBMJCECCA hardware provider):
The hardware JCE provider must be set in the Java security properties file. Use this
keystore type to store key material in your RACF keyring that uses Integrated
Cryptographic Service Facility (ICSF) for a z/OS operating system with a 3592 tape
drive or DS8000 Turbo drive.
JCECCARACFKS is a SAF keyring/ICSF-based keystore that is supported on the z/OS
operating system only. This keystore uses certificates generated in RACF or the SAF
equivalent where the key material is stored in ICSF. The JCECCARACFKS keystore
makes use of all the security advantages of both RACF/SAF and ICSF.
This keystore type does not support symmetric keys. To support LTO tape drives, use a
JCEKS or JCECCAKS keystore. If you use both types of tape drives and you have a
separate tape library for each type, you can have these Tivoli Key Lifecycle Managers:
One Tivoli Key Lifecycle Manager running with a JCECCARACFKS keystore for the
keystore for the LTO tape drive library
JCECCAKS (IBMJCECCA hardware provider)
keystore type when using a file-based keystore that leverages ICSF. Ensure that a flat file
JCECCAKS keystore resides in a restricted area of the file system on the Tivoli Key
Lifecycle Manager system. When Tivoli Key Lifecycle Manager is configured to use
hardware protection, key material will be stored within ICSFs Cryptographic Key Data Set
(CKDS) and Public Key Data Set (PKDS). When Tivoli Key Lifecycle Manager is
configured to not use hardware protection, key material will be stored within the flat
file-based JCECCAKS keystore for a z/OS operating system with a 3592 tape drive, LTO
tape drive, or DS8000 Turbo drive. Table 11-7 is a summary of the supported keystore
types.
Table 11-7 Summary of supported keystore types
To support LTO tape drives, you must use a JCEKS or JCECCAKS keystore. If you use only
3592 tape drives or DS8000 Turbo drives, you can use a JCEKS, JCECCAKS, JCERACFKS,
or JCECCARACFKS keystore. If you use only LTO tape drives or use both 3592 tape drives
Keystore Operating
system
3592 and
DS8000 (store
key pairs and
certificates)
LTO (store
symmetric keys)
3592, DS8000,
and LTO
JCEKS All Yes Yes Yes
JCECCAKS z/OS Yes Yes Yes
JCERACFKS z/OS Yes N/A N/A
JCECCARACFKS z/OS Yes N/A N/A
and LTO tape drives with the same tape library, you must use a JCEKS or JCECCAKS
keystore.
For more information about key sizes and other restrictions, see Supported key sizes and
import and export restrictions on page 332.
Using secure hardware cryptographic services
The regulations and requirements that your business is required to meet drives whether to
use secure hardware cryptographic services. A secure hardware keystore is supported on
z/OS using the ICSF. However, the secure hardware keystore can make it difficult to keep the
Tivoli Key Lifecycle Manager on z/OS synchronized with a secondary Tivoli Key Lifecycle
Manager. See 3.4.4, Dual platform key server support on page 70.
Tivoli Key Lifecycle Manager behind a firewall
As part of your centralized key management strategy, the Tivoli Key Lifecycle Manager that
your platform has to access might be behind a firewall. If so, work with your company firewall
administrator to determine the appropriate rules. TCP/IP port 3801 is the default Tivoli Key
Lifecycle Manager port that is used between Tivoli Key Lifecycle Manager and the storage
device. When using Secure Sockets Layer (SSL), the port is, by default, TCP port 441. Note
that this port differs from tape libraries that usually default to port 443. You must allow browser
access to the Tivoli Key Lifecycle Manager GUI, which is usually, by default, port 16301.
However, the clients can change all these ports.
11.2.1 Tivoli Key Lifecycle Manager configuration planning checklist
Make sure that you have performed these tasks:
You have selected a supported OS and hardware platform.
If you are migrating an existing EKM server, verify that the EKM server meets the Tivoli
Key Lifecycle Manager server recommendations:
Back up your EKM configuration prior to migration.
Write down the path to EKM; this path name cannot 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
Tivoli Key Lifecycle Manager. After you have the first EKM migrated to Tivoli Key
Lifecycle Manager, use the Tivoli Key Lifecycle Manager backup/restore function to
configure the remaining Tivoli Key Lifecycle Managers.
The following migration types are not supported:
Migration of Administrator SSL keystores and truststores is not supported. Tivoli
Key Lifecycle Manager server does not support the Administrator sync capability.
Migration of Public Key Cryptographic Standards 11 (PKCS#11) Impl keystores and
truststores is not supported. Tivoli Key Lifecycle Manager server does not support
PKCS11Impl keystores.
Tivoli Key Lifecycle Manager does not support the use of a key in multiple groups,
unlike Encryption Key Manager, which allows the use of a key in multiple groups.
When you migrate the key data in the KeyGroup.xml file from Encryption Key
Manager to Tivoli Key Lifecycle Manager, each key is attached to one group. A key
Important: The host name cannot start with IBM or SQL.
that was previously in multiple groups in Encryption Key Manager is created in only
one group in Tivoli Key Lifecycle Manager.
If this is a new Tivoli Key Lifecycle Manager installation, perform these tasks:
Know the recipients for the tapes to be written and read. Each recipient must have
these components:
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 disk and tape drives that will be used.
For each disk or tape drive, determine the drive serial number for input into the Tivoli
Key Lifecycle Manager drive table. You can also configure Tivoli Key Lifecycle Manager
to accept unknown drives.
Have existing keys and certificates that you plan to use.
11.3 Working with keys and certificates
The following sections describe the practices to use in encrypting storage environments. They
include techniques for mitigating the risk of an encryption deadlock.
11.3.1 IT Service Management
Update IT Service Management procedures:
To ensure the proper implementation and configuration of Tivoli Key Lifecycle Manager
key servers and encrypted storage products
To ensure the proper the placement or relocation of data related to, or required by, any
Tivoli Key Lifecycle Manager key server
To grant the appropriate access authority to configure Tivoli Key Lifecycle Manager key
servers or encrypted storage products
To automatically monitor the availability of any applications and equipment associated with
the management of key services and to take appropriate action to keep the equipment
operational. This equipment includes but is not limited to key servers, Simple Network
Management Protocol (SNMP) monitors, domain name servers, and DS8000 Hardware
Management Consoles (HMCs).
Update the disaster recovery plans and scenarios to include the availability of key servers,
key server backups, and key server synchronization. Establish the independence of each
recovery site from the other recovery sites.
Consistency: For the set of Tivoli Key Lifecycle Manager servers that typically handles
requests from the same set of disk and tape drives, the information in the associated
keystores must be kept the same.
This consistency is required so that no matter which Tivoli Key Lifecycle Manager server is
contacted by a disk or tape drive, the necessary information is available for the Tivoli Key
Lifecycle Manager server to use to support that request.
11.3.2 General security
Follow these security practices:
Control physical access to all hardware. Provide additional network security to protect the
Tivoli Key Lifecycle Manager key servers.
Continue to back up disk data to tape. If the data is encrypted on disk, also encrypt it on
tape.
Do not leave the details of keys and certificates where other people can see them, for
example, putting them on another users general purpose mobile computer or USB key is
a bad idea.
Keystore security
During the setup of the Tivoli Key Lifecycle Manager key server, you specify a password
that is used to access the keystore. Decide whether to provide the Tivoli Key Lifecycle
Manager password manually or whether a mechanism will be put in place to automatically
provide the password to the Tivoli Key Lifecycle Manager.
11.3.3 Tivoli Key Lifecycle Manager key server availability
Ensure that you do not lose your keys and certificates. If the keys or certificates are lost (for
example the keystore is corrupted), you cannot read the disk or tape data. The storage is then
known as being cryptographically erased. So, it is important to keep backups. The DS8000
R5 Recovery Key feature provides partial protection; see 24.2, Recovery key support on
page 814.
Make sure you back up your keys and certificates and verify that you can retrieve them from
the backup.
Ensure that the keys and certificates are readily available. Even if you have a backup, it takes
time to rebuild a Tivoli Key Lifecycle Manager and restore a backup keystore. For this reason,
make sure that you have at least two active Tivoli Key Lifecycle Managers available to each
storage device at each location, including at the disaster recovery site. In a DS8700 R5 and
z/OS environment, the dual platform support enables the use of one Tivoli Key Lifecycle
Manager on System z and another Tivoli Key Lifecycle Manager on System x when using a
secure keystore on the System z. See 3.4.4, Dual platform key server support on page 70.
To initiate the Tivoli Key Lifecycle Manager key server operation after power on, without
human intervention, set up the key server to automatically power on when power is available
and to automatically initiate the key server application. Configure the application to
automatically start:
Configure redundant network fabrics between the Tivoli Key Lifecycle Manager key
servers and encrypting disk or tape. Providing independent network paths through
independent key servers prevents any single point of failure.
Important: Although IBM has services that can help you to recover data from a damaged
storage device, if the damaged device is encrypted, you still receive encrypted data from
the recovery. So, if you lose your keys, you have lost your data.
11.3.4 Encryption deadlock prevention for DS8000
Ensure that the system files (the z/OS system files and the Tivoli Key Lifecycle Manager
application and keystore files) are not placed on encrypted disks. If they are placed on
encrypted disks, an encryption deadlock can occur. Because of virtualization and automated
data migration, you cannot ensure that system data does not migrate data onto the encrypted
DS8000. For this reason, use recovery keys (and dual platform support if required) for
DS8700s.
Define multiple security administrators and multiple storage administrators for the DS8000
storage facility images so that the recovery key process can still be used even if one of the
administrators is absent.
11.3.5 Tivoli Key Lifecycle Manager key server
Configuration of redundant key servers (at least two) is required. Redundancy implies
independent servers and independent storage devices. For key servers operating in logical
partitions (LPARs), do not use data sharing techniques that result in one copy of the data
being shared by multiple instances of the key server.
Configuring one key server with dedicated hardware and non-encrypted storage resources at
each recovery site is required. The key server is referred to as an isolated key server.
The objective of this requirement is to avoid encryption deadlock:
Implement a key server environment that is independent of all non-key server applications
so that management of the key server can be restricted to those personnel specifically
authorized to manage key servers.
Implement a key server that is physically and logically isolated from other applications that
might require access to encrypting storage so that the key server environment does not
need to be configured with access to any encrypting storage.
Implement a key server that is physically and logically isolated from encrypting storage so
there is no risk of code or data objects required by the key server being installed on, or
migrating onto, encrypting storage.
Ensure that a recovery site can operate independently of any other sites by configuring a key
server that cannot be subject to encryption deadlock.
Configuration of additional key servers on generalized server hardware and generalized
storage is allowed. Establish appropriate procedures and controls to prevent these key
servers from having their data access compromised by storing the data on key
server-managed encrypting storage. These key servers are referred to as general key
servers.
Configuration of key servers at independent sites is good practice, because it provides
additional protection from encryption deadlocks and it reduces the probability that all key
servers might experience a simultaneous power loss.
Ensure that all key servers, with which a given storage device is configured to communicate,
have a consistent keystore content relative to any wrapping keys that will be used by the
storage device. Failure to synchronize the keystores in effect means that Tivoli Key Lifecycle
Note: IBM DS8000 requires that you configure at least one isolated key server, but
configure two isolated key servers for redundancy.
Manager cannot act as a secondary key server. Refer to 11.4.2, Synchronizing primary and
secondary Tivoli Key Lifecycle Manager servers on page 250.
Back up key server data after it is updated. Do not store the backups on encrypted storage
media that is dependent on a key server. Refer to 11.5, Backup and restore on page 251.
Periodically audit to ensure all online and backup data that is required to make each key
server operational is stored on storage or media that is not dependent on a key server to
access the data.
Do not delete keys on the key server under normal circumstances. Deletion of all copies of a
key is a cryptographic erase of all encrypted data that is encrypted under this key.
11.3.6 DS8000 and tape devices
Manually configure DS8000 and tape devices on the Tivoli Key Lifecycle Manager key server.
You can use the option to automatically configure them, but that option increases the risk that
an unauthorized DS8000 or tape might gain access to a key server.
Assign each DS8000 storage facility and tape device an independent key encrypting key
(KEK) with a unique key label on the Tivoli Key Lifecycle Manager, which facilitates the
independent management and audit of each storage device.
The DS8000 supports up to four Tivoli Key Lifecycle Manager key server ports. A requirement
is that at least one port is assigned to an isolated key server. Assign two ports to isolated key
servers. Using local key servers is more reliable than using remote key servers.
When the DS8000 is configured to enable encryption, the DS8000 verifies that at least two
Tivoli Key Lifecycle Manager key servers are configured and accessible to the machine.
The DS8000 will reject the creation of ranks and extent pools with a non-zero encryption
group specified if encryption has not been activated.
The DS8000 will monitor all configured Tivoli Key Lifecycle Manager key servers. When loss
of access to the key servers is detected, clients are notified through the DS8000 customer
notification mechanism (SNMP traps, email, or both, when configured). Key server-related
errors are provided through the same mechanism (for example, if a key server cannot unwrap
a key). The client must set up monitoring for these events and take corrective actions when a
condition is detected, because these events indicate a degraded key server environment.
The following conditions are monitored and reported:
If the DS8000 cannot receive a required data key during power on for a configured
encryption group from the key servers, it reports the error condition to the client and to
IBM (using the call home function). In this case, logical volumes associated with the
encryption group are inaccessible to attached hosts. If the DS8000 is able to obtain the
required data key from a key server, after reporting the error, it reports the condition to the
client and to IBM and makes the associated logical volume accessible.
DS8000 access to each configured key server is verified at 5-minute intervals. Loss of
access is reported to the client.
The ability of each key server to unwrap data keys that are configured on the DS8000 is
verified at 8-hour intervals. The loss of the ability to unwrap a configured data key is
reported to the client and to IBM.
The DS8000 detects if fewer than two key servers are configured, if fewer than two key
servers are available, or if there are fewer than two key servers that can unwrap data keys
configured on the DS8000, at 8-hour intervals. If detected, the condition is reported to the
client and to IBM. On the 8-hour check, both the client and IBM are notified if any
configured key server fails to unwrap keys. It is expected that the key server administrator
completes the key server data maintenance to the extent that the key server is not
configured to the DS8000 until the keys can be served or retrieved.
11.4 Multiple Tivoli Key Lifecycle Managers for redundancy
In order to run duplicate Tivoli Key Lifecycle Managers for redundancy and availability, you
must keep the two (or more) Tivoli Key Lifecycle Managers synchronized. The keys,
certificates, Tivoli Key Lifecycle Manager database, and configuration files must be the same
on all Tivoli Key Lifecycle Managers. Use the in-built Tivoli Key Lifecycle Manager backup and
restore facility.
On Microsoft Windows systems and other systems, such as Linux or AIX, in order to use
backup/restore, both computers must have the required memory, speed, and available disk
space to meet the workload. The operating system, middleware components, and Tivoli Key
Lifecycle Manager application directory layout must be identical on both computers.
Cross-platform backup/restore is not supported. Therefore, as much as possible, all Tivoli Key
Lifecycle Managers must be on the same OS platform.
However, using the command-line interface, you can use a key export/import facility to keep
the keys and certificates synchronized between Tivoli Key Lifecycle Managers on dissimilar
platforms, but because this approach does not keep the other configuration information in
step, you have to synchronize it manually. When using DS8700 with z/OS, it is likely that one
Tivoli Key Lifecycle Manager will be on z/OS and a second Tivoli Key Lifecycle Manager will
be on Linux on System x, so key export/import will be required. See 2.3, DS8000 series with
encryption support on page 31. If the z/OS uses a keystore in secure mode, a separate
command (certificate export/import) is used to export the public key. See 3.4.4, Dual platform
key server support on page 70.
In addition, Tivoli Key Lifecycle Manager is not cluster-aware and not enabled for automatic
failover. Therefore, Tivoli Key Lifecycle Managers cannot share keystores or configuration
files, and so, multiple Tivoli Key Lifecycle Managers cannot be configured for performance or
automatic failover without external components. However, performance is not a major
concern, because IP traffic to Tivoli Key Lifecycle Manager is in general not extremely high
and is used mainly to provide the data key at disk power-up or at tape mount (both of which
Important: For z/OS based Tivoli Key Lifecycle Manager:
Tivoli Key Lifecycle Manager backup and restore operations on z/OS will not
automatically back up and restore your Tivoli Key Lifecycle Manager database in DB2.
When you perform backup and restore tasks on z/OS, you must coordinate with your
DB2 administrator in order to fully back up and restore both Tivoli Key Lifecycle
Manager and the Tivoli Key Lifecycle Manager database in DB2.
On z/OS, SAF-based keystores are not included in the backup or restore processes.
You must coordinate with your security administrator to back up the keyring and
certificate information in IBM RACF if you use a RACF-based keystore, as well as the
key information in ICSF if you use hardware protection.
For more information about backup and restore if you run z/OS in a sysplex
environment, refer to the installation topics for Parallel Sysplex systems in the IBM
Tivoli Key Lifecycle Manager Installation and Configuration Guide, SC23-9977. Note
that you must perform a backup and restore on each Sysplex member.
happen infrequently) and for browser access to the Tivoli Key Lifecycle Manager server
(which, after Tivoli Key Lifecycle Manager is configured, will be infrequent).
Therefore, a primary/secondary Tivoli Key Lifecycle Manager server configuration is not a
failover or clustered server from a Tivoli Key Lifecycle Manager point of view. The redundancy
is managed by setting up multiple key manager destinations at the DS8000 Storage Server or
tape library. The DS8000s periodically test for the presence of each configured Tivoli Key
Lifecycle Manager and will alert the Tivoli Key Lifecycle Manager administrator if any of the
Tivoli Key Lifecycle Managers are not available. The DS8000 will then continue by using one
of the other (that is, secondary) configured Tivoli Key Lifecycle Managers. Similarly, if the IBM
tape is not able to contact its primary Tivoli Key Lifecycle Manager, it will attempt to get the
data key from one of the other configured Tivoli Key Lifecycle Managers. In this way, failover is
initiated by the storage device itself.
In all cases, synchronization is achieved by backing up one server and restoring the backup
configuration on the other server (assuming both Tivoli Key Lifecycle Managers are on the
same OS platform) or by key export/import if they are on dissimilar platforms.
Plan to perform this backup and restore process when the following events take place,
because these events change the keystore or configuration files:
After initial configuration
After adding keys or devices
After changing the key or certificate replacement intervals
After making a Certificate Authority (CA) request
After upgrading Tivoli Key Lifecycle Manager or its middleware, such as DB2
However, just to remind you, Tivoli Key Lifecycle Manager will show an alert window when you
make any change that requires taking a new backup.
11.4.1 Setting up primary and secondary Tivoli Key Lifecycle Manager servers
In our experimentation environment, we were running two SUSE Linux 9 hosts. We were able
to easily match the environment seen by Tivoli Key Lifecycle Manager and its middleware.
Fill out the installation worksheets in the Tivoli Key Lifecycle Manager Installation and
Configuration Guide, SC23-9977.
For detailed information, refer to these resources:
Installing Tivoli Key Lifecycle Manager on 64-bit Windows Server 2008 on page 266
IBM Tivoli Key Lifecycle Manager Installation and Configuration Guide, SC23-9977
The Tivoli Key Lifecycle Manager Information Center:
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm
.tklm.doc/welcome.htm
11.4.2 Synchronizing primary and secondary Tivoli Key Lifecycle Manager
servers
Tivoli Key Lifecycle Manager 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 Tivoli Key
Lifecycle Manager and then restoring to a separate server with the same configuration
parameters.
Consider these aspects of synchronization:
Select one machine to be the primary Tivoli Key Lifecycle Manager and originate all
backups from the primary Tivoli Key Lifecycle Manager. All changes must be made on the
primary Tivoli Key Lifecycle Manager and then deployed through a backup/restore to the
secondary Tivoli Key Lifecycle Manager.
Primary and secondary Tivoli Key Lifecycle Managers must be running the same OS with
the same user accounts for Tivoli Key Lifecycle Manager, Tivoli Integrated Portal, and
DB2.
Restores are disruptive to the secondary Tivoli Key Lifecycle Manager so ensure that the
primary Tivoli Key Lifecycle Manager is active and serving keys before performing the
restore.
For detailed backup and restore information, refer to 11.5, Backup and restore on page 251.
11.5 Backup and restore
As well as being used to keep two or more Tivoli Key Lifecycle Managers synchronized,
backup and restore tasks provide protection for critical data and must be integrated with your
IT Service Management procedures to ensure server availability. Backup creates files that
contain critical data on the current state of the Tivoli Key Lifecycle Manager server.
11.5.1 Categories of data in a backup file
A backup file of Tivoli Key Lifecycle Manager critical data includes keystore, configuration file,
metadata, and other information.
The following categories of data require backup protection:
Keystore files
Certificates and keys (or pointers to the certificates and keys) that Tivoli Key Lifecycle
Manager uses to perform key serving and other operations
Tivoli Key Lifecycle Manager configuration files
Properties that define selected Tivoli Key Lifecycle Manager activities, such as audit
settings and other values that you customize for your system configuration
Tivoli Key Lifecycle Manager database
Data about Tivoli Key Lifecycle Manager objects, such as devices, key groups, certificates,
keys, and drives.
Important: Failure to back up your keystore and other critical data properly might result in
unrecoverable loss of all access to your encrypted data. Do not encrypt your backup file or
store a backup file on an encrypting device.
Tivoli Key Lifecycle Manager on z/OS backup: The Tivoli Key Lifecycle Manager on
z/OS backup differs. See the note in 11.4, Multiple Tivoli Key Lifecycle Managers for
redundancy on page 249 for details about backup on z/OS.
11.5.2 Backup file security
Observe the following guidelines to secure your backup files:
Ensure that you do not accidentally corrupt a backup file or misplace its encryption
password.
Do not edit the files contained in a backup .jar file. If you edit these files, the files become
unreadable.
Ensure that you retain the password that was used to encrypt a given backup file, because
the same password is required to restore and decrypt the file.
11.5.3 IBM Tivoli Storage Manager as a backup repository
Tivoli Storage Manager might be your backup repository of choice. Tivoli Storage Manager
provides progressive, incremental backup, hierarchical storage management, and tape
optimization.
For example, you might use the policy-based backup capabilities that Tivoli Storage Manager
provides to perform scheduled backups on an hourly, daily, or weekly basis.
For critically important data, such as the Tivoli Key Lifecycle Manager database, keystore,
and configuration file, you might use Tivoli Storage Manager to back up that data when it
changes. The Tivoli Storage Manager server can be located on a separate computer than the
computer on which the DB2 server runs. However, you must ensure that the Tivoli Key
Lifecycle Manager server is not in use when you back up its data. Using the Tivoli Key
Lifecycle Manager backup feature ensures that the data that you back up is consistent.
11.5.4 Backup and restore runtime requirements
Backing up data and restoring data from backup files for Tivoli Key Lifecycle Manager have
several runtime requirements.
Before you begin, prevent a timeout failure by increasing the time interval that is allowed for
backup and restore transactions for large key populations. Specify a larger value for the
totalTranLifetimeTimeout setting in the following file:
TIP_HOME/profiles/TIPProfile/config/cells/TIPCell/nodes/TIPNode/servers/server1/se
rver.xml
Additionally, these conditions must be true:
Ensure that the task occurs during a time interval that allows a halt to key serving activity,
because no Tivoli Key Lifecycle Manager activity will take place during a backup operation.
For a backup task, the Tivoli Key Lifecycle Manager server must be running in a normal
operational state. The Tivoli Key Lifecycle Manager database instance must be available.
For a restore task, the Tivoli Key Lifecycle Manager database instance must be accessible
through the Tivoli Key Lifecycle Manager data source.
Before you start a restore task, ensure that you have the password that was used when
the backup file was created. Restored files must be written to the same Tivoli Key Lifecycle
Manager server from which the data was previously backed up, or to an identical, replica
computer.
Ensure that directories exist and are associated with the tklm.backup.dir and
tklm.db2.backup.dir properties. System and Tivoli Key Lifecycle Manager administrator
accounts under which the Tivoli Key Lifecycle Manager server and the DB2 server run
must have read and write access to these directories.
11.5.5 Backing up critical files
The Tivoli Key Lifecycle Manager backup saves a password-protected copy of the Tivoli Key
Lifecycle Manager server settings, including the keystore and DB2 tables. However, when
performing a restore, Tivoli Key Lifecycle Manager assumes that the environment is similar.
Tivoli Key Lifecycle Manager restore operations must be on the same platform with the same
system user account information and the same Tivoli Key Lifecycle Manager and middleware
file layout.
To back up:
1. Log in to the graphical user interface (GUI). From the navigation tree, select Tivoli Key
Lifecycle Manager Settings Backup and Restore. In the backup and restore table,
click Create Backup, as shown in Figure 11-1.
Figure 11-1 Backup and restore table
2. On the Create Backup panel, as shown in Figure 11-2 on page 254, specify the required
information, such as the path and a value for the encryption password. Then, click Create
Backup.
Important: Backup and restore are disruptive to the operation of the Tivoli Key Lifecycle
Manager servers.
Figure 11-2 Create Backup
3. Review the directory that contains the backup files to ensure that the backup file exists. Do
not edit a file in the backup .jar file. If you attempt to edit the file, the file becomes
unreadable. Figure 11-3 shows the file location in the Backup File column.
Figure 11-3 Backup file created
11.5.6 Restoring a backup file
You can use the backup and restore table to restore a backup file. Only one backup or restore
task can run at a given time. If you restore a file to a replica computer, copy the file to that
computer using media, such as a disk, or electronic transmission.
1. Log in to the GUI. From the navigation tree, select Tivoli Key Lifecycle Manager
Settings Backup and Restore.
2. On the backup and restore table, select a backup file that is listed in the table. Then, click
Restore Backup. The panel that is shown in Figure 11-4 on page 255 opens.
Figure 11-4 Restore from backup
a. Before the restore procedure starts, click OK to confirm the message indicating that
the server will be stopped, as shown in Figure 11-5.
Figure 11-5 Restore warning message
3. A message indicates that the restore operation succeeded. Click OK to finish the restore
procedure. See Figure 11-6.
Figure 11-6 Restore successful message
4. Manually restart the Tivoli Key Lifecycle Manager server. Refer to 13.4.2, Restore by
using the GUI on page 373 for an example of restarting the server. Then, determine
whether the server is in the expected state. For example, you might examine the keystore
to see whether a certificate that had problems prior to restoring the backup file is now
available for use.
11.5.7 Deleting a backup file
Use the GUI or command-line interface (CLI) to delete a backup file for Tivoli Key Lifecycle
Manager. For example, you might delete a backup file for which a business use no longer
exists. You can use the backup and restore table to restore a backup file:
2. Delete a selected backup file.
3. On the backup and restore table, select a backup file that is listed in the table. Click Delete
Backup and confirm that you want to delete the file.
4. Examine the directory, in which the backup files are stored, to determine whether the
specified file was deleted.
11.6 Key exporting and importing tasks
If the secondary Tivoli Key Lifecycle Manager server differs from the primary Tivoli Key
Lifecycle Manager (in terms of OS, maintenance level, and so on), you cannot keep the Tivoli
Key Lifecycle Managers synchronized by using backup/restore. You must export the
certificate from one server and restore it on the other server. You must use the CLI for the
export and import tasks, because these tasks are not available from the GUI.
11.6.1 Exporting keys
Follow these steps to export keys:
1. Open a command window, go to the <tip installation directory>/bin folder, and
execute the wsadmin script to export keys from the primary Tivoli Key Lifecycle Manager
server (server1), as illustrated in Example 11-1.
Example 11-1 Issue the wsadmin script
23a4088:/opt/IBM/tivoli/tip/bin/wsadmin.sh -username tipadmin -password
tipadmin -lang jython
WASX7209I: Connected to process "server1" on node TIPNode using SOAP connector;
The type of process is: UnManagedProcess
WASX7029I: For help, enter: "$Help help"
2. Use the tklmKeyExport command with the -alias, -fileName, -keyStoreName, and -type
parameters to export secret or private keys. The -alias parameter is the alias of the key to
export, the -keyStoreName is the master keystore name for the Tivoli Key Lifecycle
Manager server. See Example 11-2.
Example 11-2 Exporting the keystore
wsadmin>print AdminTask.tklmKeyExport('[-alias itsokey -fileName TKLM_DS8K
-keyStoreName "ITSO Sample Keystore" -type privatekey]')
CTGKM0001I Command succeeded.
The TKLM_DS8K file was created in the /opt/IBM/tivoli/tip/products/tklm directory with
the filename TKLM_DS8K.
3. Copy the exported key to the new Tivoli Key Lifecycle Manager server.
11.6.2 Importing keys
You must perform the following steps on the second Tivoli Key Lifecycle Manager server:
1. Open a command window, and go to the <tip installation directory>/bin folder, and
use the wsadmin command to import keys from Tivoli Key Lifecycle Manager server1. See
Example 11-3.
Example 11-3 Issue the wsadmin command
2. Use the tklmKeyImport command with the -alias, -fileName, -password, -keyStoreName,
-usage, and -type parameters to export secret or private keys. The -alias parameter is
the alias of the key to import. The -password parameter is the password of the key file.
The -keyStoreName parameter is the master keystore name for the Tivoli Key Lifecycle
Manager server. The -usage parameter defines the storage type. See Example 11-4.
Example 11-4 Import the keystore
wsadmin>print AdminTask.tklmKeyImport('[-alias itsokey -fileName
/root/fromTKLM_server1/TKLM_DS8K -password passw0rd -keyStoreName "ITSO Sample
Keystore" -usage DS8K -type privatekey]')
Parameters for importing
We define the parameters:
-alias Required if the value of the -type attribute is secretkey and you want to
rename the key during import by using the -newAlias parameter.
Specify the value of alias if you want to import only this secret key
from a secret key file that has other secret keys that you do not want to
import.
-fileName Required. Specifies the path and file name of the file from which keys
are imported.
Path names: The default path to create the keystore on Linux systems is
/opt/IBM/tivoli/tip/products/tklm
On Microsoft Windows systems, the default path is C:\ibm\tivoli\tip\products\tklm
For more information about the export function, refer to this website:
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.
ibm.tklm.doc/cpt/cpt_ic_releas_probslimits.html
-keyAlias Required if the value of the -type attribute is secretkey. Specifies the
alias of the private key entry in the keystore that is used to encrypt the
secret key, or keys, to the file.
-keyStoreName Required. Specifies the name of the keystore into which the imported
key is imported.
-newAlias Specifies a new value for the key alias.
-password Required if the value of the -type attribute is privatekey. This is the
password of the private key file.
-type Required. Specifies whether the keys are secret or private. Values
include these options:
secretkey Specifies a symmetric key.
privatekey Specifies an asymmetric key in a key pair containing a public key
and a private key.
-usage Required. Specifies the target application usage, such as LTO tape
drives. Values include these options:
SSL server Key is used in secure communication using SSL.
LTO Key is used in secure communication with LTO tape drives.
3592 Key is used in secure communication with 3592 tape drives.
DS8K Certificate is used in secure communication for DS8000 Turbo
drives.
11.6.3 Importing the public key
Use the tklmCertImport command to import the public key file into your keystore. The import
command allows you to specify the name of the new certification, but you have to give the
same certification name that was used on the partner server to keep the Tivoli Key Lifecycle
Manager infrastructure consistent.
Example 11-5 and Example 11-6 show the importing process on both servers.
Example 11-5 Import the secondary public key on the primary server
wsadmin>print AdminTask.tklmCertImport('[-fileName /root/itsokey2.cert -alias
itsokey2 -keyStoreName "ITSO Sample Keystore" -usage DS8K]')
Example 11-6 import the primary public key on the secondary server
11.6.4 Exporting the public key
Execute the tklmCertExport command to export the public key to a regular file into an
existing directory on the local file system. Use a filename that contains the name of the key to
avoid mixing them up later. You must specify the Universally Unique Identifier (uuid) to select
the proper certification to export. This uuid value can be obtained from the tklmCertList
command output.
Example 11-7 and Example 11-8 show how to export a key.
Example 11-7 Export primary public key into a file
wsadmin>print AdminTask.tklmCertExport('[-uuid
CERTIFICATE-252c1687-6f03-4048-97e0-fc85003aadee -fileName /root/itsokey1.cert]')
/root/itsokey1.cert
Example 11-8 Export secondary public key into a file
CERTIFICATE-0eba963e-873d-4cf2-9666-bd8cce196974 -fileName /root/itsokey2.cert]')
/root/itsokey2.cert
11.7 Integration and EKM to Tivoli Key Lifecycle Manager
migration
This section describes installing Tivoli Key Lifecycle Manager in an existing EKM installation:
We describe in this section:
Integrating with existing encryption installations
Migration from EKM to Tivoli Key Lifecycle Manager
Managing multiple devices
11.7.1 Integrating Tivoli Key Lifecycle Manager for DS8000 with an existing
EKM tape encryption installation
If you already use encryption for tape devices with the IBM Encryption Key Manager (EKM)
as your key management system, you must first migrate your EKM key server (or servers) to
Tivoli Key Lifecycle Manager before you can integrate the DS8000 encryption feature into
your existing environment. Also, remember that at least two Tivoli Key Lifecycle Manager
servers are required for supporting DS8000 encryption.
11.7.2 Migrating from EKM to Tivoli Key Lifecycle Manager
Tivoli Key Lifecycle Manager supports migration from an EKM installation to a Tivoli Key
Lifecycle Manager installation. You must stop the EKM server, so you must either schedule a
maintenance window to shut down EKM or, if you have redundant EKMs, you can stop just
one of them. Tivoli Key Lifecycle Manager Installation and Configuration Guide, SC23-9977,
has an excellent description of EKM migration.
Important: The only opportunity to migrate the configuration is during the installation of
Tivoli Key Lifecycle Manager, or immediately afterward, before you change the Tivoli Key
Lifecycle Manager configuration.
The following list reviews considerations and tasks that you need to be aware of when
migrating from EKM to Tivoli Key Lifecycle Manager:
Back up your EKM configuration prior to migration.
Write down the directory path to EKM (you will need to specify this path when configuring
for migration); this path name must 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 Tivoli
Key Lifecycle Manager. After you have the first EKM migrated to Tivoli Key Lifecycle
Manager, use the Tivoli Key Lifecycle Manager backup and restore function to build the
remaining Tivoli Key Lifecycle Managers.
The following migration types are not supported:
Migration of Administrator SSL keystores and truststores is not supported. Tivoli Key
Lifecycle Manager server does not support Administrator sync capability.
Migration of PKCS11Impl keystores and truststores is not supported. Tivoli Key
Lifecycle Manager server does not support PKCS11Impl keystores.
Tivoli Key Lifecycle Manager does not support the use of a key in multiple groups,
unlike Encryption Key Manager, which allows the use of a key in multiple groups.
EKM configuration files will be converted to Tivoli Key Lifecycle Manager configuration
files.
The keystore will be migrated.
The drive table will be migrated into DB2.
The Keygroups.xml file (if it exists) will be migrated into DB2.
The first task after the migration must be a backup of the new Tivoli Key Lifecycle Manager
server before you start any administration tasks or even install a second Tivoli Key Lifecycle
Manager server.
After the second Tivoli Key Lifecycle Manager Server is up and running (migrated or
installed), you can start adding the new DS8000 systems, as described in 22.3.3, Configure
the SFIs on page 761.
11.7.3 Multiple encrypted disk or tape devices
Tivoli Key Lifecycle Manager can manage multiple encrypted devices of various types (disk,
tape, or other types). Tivoli Key Lifecycle Manager manages the encryption key. The nature
and number of the encrypted devices is irrelevant to Tivoli Key Lifecycle Manager.
There is however a dependency for licensing that is driven by the number of storage devices
or the volume of encrypted storage.
IBM Tivoli product licensing documents are available at this website:
http://www.ibm.com/software/tivoli/products/licensing.html
Figure 11-7 on page 261 illustrates a possible configuration for a Tivoli Key Lifecycle Manager
installation with tape and disk encryption devices.
Figure 11-7 Tivoli Key Lifecycle Manager with several DS8000 and tape encryption devices
From a connectivity standpoint, the managed devices and the Tivoli Key Lifecycle Manager
servers simply require an Ethernet connection. A maximum of four Tivoli Key Lifecycle
Manager IP connections can be set up in the DS8000 HMC. Each DS8000 can connect to a
maximum of four independent Tivoli Key Lifecycle Manager servers (with synchronized
keystores) for redundant key access.
The other consideration is in the number of separate devices that can be handled from each
Tivoli Key Lifecycle Manager, which depends on the license that you have for the Tivoli Key
Lifecycle Manager software.
11.8 Data exchange with business partners
It is common practice to share tapes with other organizations for data transfer, joint
development, contracting services, or other purposes. The methods for sharing encrypted
tapes differ for 3592 tape drives and LTO tape drives, but it entails encrypting the data key
using the public key of the business partner.
3592 tape drives
Tivoli Key Lifecycle Manager can store two sets of wrapped encryption data keys on a 3592
tape. One set will be wrapped using the public key of your Tivoli Key Lifecycle Manager; the
other set will be wrapped using the public key from the business partner. This approach
allows the business partner to read that specific tape without your providing the business
partner any shared secret information or compromising the security of your certificates and
keys.
You simply add the public part of the other organizations public/private certificate and keys to
the keystore of your Tivoli Key Lifecycle Manager, using a second alias (or key label). When
the tape is written, the encryption key is stored on the tape and protected by two sets of
2 1
Sys temStorage
SystemSto rag e SystemStorage
2 1
Sys tem Storage
Sys tem x3550
Sys tem x3550
DS8000_1
DS8000_2
Tape_1
TKLM_1
TKLM_2
E
t
h
e
r
n
e
t
public/private keys, yours and the other organizations. The other organization must have an
encryption-enabled 3592 tape drive and can use their Tivoli Key Lifecycle Manager and their
private key to unwrap the data key and, therefore, can read that specific tape.
This flexibility provides tapes that are readable by both organizations without either
organization needing to supply its private key.
LTO tape drives
To share encrypted data on an LTO tape, a copy of the symmetric data key used to encrypt
the data on the tape must be made available to the other organization to enable it to read the
tape. To secure the transport of this symmetric key to the business partner, the business
partner provides you with its public key.
This public key will be used to wrap the symmetric key when it is exported from the Tivoli Key
Lifecycle Manager keystore. When the other organization imports the symmetric key into its
Tivoli Key Lifecycle Manager keystore, the symmetric key will be unwrapped using their
corresponding private key.
This approach ensures that the symmetric key is safe in transit, because only the holder of
the private key is able to unwrap the symmetric key. With the symmetric key that was used to
encrypt the data in its Tivoli Key Lifecycle Manager keystore, the other organization will then
be able to read the data on the tape.
We describe this method in more detail in 13.5, Data sharing with business partners on
page 378.
11.9 Disaster recovery considerations
It is important to remember to keep your disaster recovery sites key manager synchronized
with your operation site. Use the same mechanism that you employ for keeping the primary
and secondary Tivoli Key Lifecycle Managers synchronized, that is, backup/restore (see 11.4,
Multiple Tivoli Key Lifecycle Managers for redundancy on page 249) or by using key
export/import, if necessary.
Alternatively, you can use an up-to-date backup of the key manager along with your Tivoli Key
Lifecycle Manager configuration worksheets and installation media to rebuild an operational
Tivoli Key Lifecycle Manager at a recovery site. The Tivoli Key Lifecycle Manager worksheets
can be found in Tivoli Key Lifecycle Manager Installation and Configuration Guide,
SC23-9977.
The recovery site is likely to be geographically remote from the primary site, so determine
how to transport the Tivoli Key Lifecycle Manager backups between sites.
11.10 Database selection
Tivoli Key Lifecycle Manager includes DB2 in the installation process (except on z/OS where
you will have to install DB2 V8.1 or later and the other middleware prior to starting the
installation of Tivoli Key Lifecycle Manager):
If DB2 Enterprise Edition Version 9.1 with Fix Pack 4 is installed, Tivoli Key Lifecycle
Manager uses the existing DB2.
If DB2 is not installed on the system, Tivoli Key Lifecycle Manager installs DB2 9.1 Fix
Pack 4.
If DB2 Version 8 is installed on the system, Tivoli Key Lifecycle Manager installs DB2 9.1
Fix Pack 4.
If DB2 Version 9 is installed, but it is earlier than DB2 9.1 Fix Pack 4, you must upgrade
DB2 before you can install Tivoli Key Lifecycle Manager.
When you use the Tivoli Key Lifecycle Manager backup/restore function, it backs up the
relevant Tivoli Key Lifecycle Manager DB2 tables (except for z/OS installations, see the note
in 11.4, Multiple Tivoli Key Lifecycle Managers for redundancy on page 249).
Chapter 12. Implementing Tivoli Key
Lifecycle Manager
This chapter is intended as an example to show how the Tivoli Key Lifecycle Manager is
installed on a 64-bit Red Hat Enterprise Linux AS Version 5.3 server and on a 64-bit Microsoft
Windows Server 2008 server. These platforms are two of the platforms that are newly
supported with Tivoli Key Lifecycle Manager Fix Pack 1. Of course, Tivoli Key Lifecycle
Manager is supported on other systems, which we describe in Chapter 11, Planning for Tivoli
Key Lifecycle Manager and its keystores on page 237, but the installation is similar on all
those platforms (except z/OS). And after it is installed, the Tivoli Key Lifecycle Manager
graphical user interface (GUI) is common across platforms (even z/OS).
You can download a complete installation guide for all the platforms at this website:
lm.doc/cpt/cpt_ic_releas_probsinstallupg.html
This chapter contains the instructions for the initial configuration of Tivoli Key Lifecycle
Manager, so that it can start to serve keys to DS8700 disks (using asymmetric keys), TS1100
tape drives (using asymmetric keys), and LTO4 tape drives (using symmetric keys).
12
12.1 Implementation notes
Three methods of installation exist for the distributed version of Tivoli Key Lifecycle Manager:
A GUI-based installation driven by a wizard.
A console mode (or command-line mode) installation that runs in a console window. This
mode scrolls information on the window and, then, prompts for your entries one line at a
time.
A silent installation that runs unattended, using response files for the configuration
options.
In this chapter, we used the GUI installation method, which is the method that most clients will
use. This method provides several wizards to ease the implementation. You can complete this
installation in less than an hour.
At the time of writing, there were three fix packs available for Tivoli Key Lifecycle Manager. Fix
Pack 1 added additional platform support (see Table 11-3 on page 240), as well as various
fixes. Interim Fix Pack 1A addressed a security exposure, and Interim Fix Pack 2 provided for
dual platform support (see 3.4.4, Dual platform key server support on page 70), as well as
various fixes. These fixes are available on Fix Central at this website:
http://www.ibm.com/support/fixcentral/
At this time, Fix Pack 1 is integrated into several of the Tivoli Key Lifecycle Manager install
images, so only Interim Fix Pack 1A and Interim Fix Pack 2 need to be installed on these
systems. In our examples, Fix Pack 1 is already integrated in the install image for Windows
Server 2008 but not into the install image for Red Hat Enterprise Linux (RHEL) 5.2 Server.
The installation is similar for all distributed platforms, because all middleware is included as
part of the Tivoli Key Lifecycle Manager installation. For installation on z/OS, the middleware
is not provided and the installation is more complex. For more details about installing and
using Tivoli Key Lifecycle Manager on z/OS, see IBM Tivoli Key Lifecycle Manager for z/OS,
REDP-4472.
12.2 Installing Tivoli Key Lifecycle Manager on 64-bit Windows
Server 2008
It is important that you refer to the latest installation information in the IBM Tivoli Key Lifecycle
Manager Installation and Configuration Guide, which is available in the Information Center at
this website:
lm.doc/welcome.htm
Fix Pack 3: Since writing this Redbooks publication, Fix Pack 3 has become available (in
late October 2009). Fix Pack 3 includes all the fixes and updates from all previous fix packs
(Fix Pack 1, Interim Fix Pack 1A, and Interim Fix Pack 2), as well as additional fixes.
The procedure for installing Fix Pack 3 is similar to the procedures shown here for installing
Interim Fix Pack 1A and Interim Fix Pack 2.
Chapter 12. Implementing Tivoli Key Lifecycle Manager 267
To install Tivoli Key Lifecycle Manager on Windows, you must have Administrator access.
Depending on how you order Tivoli Key Lifecycle Manager, you might receive it as a single
compressed file (ZIP), a self-extracting compressed file (EXE), an iso image, or a DVD. If it is
a DVD, it will autorun when loaded. If it is a compressed file or a self-extracting compressed
file, you will need to extract it to a temporary folder. In this example, we used a DVD (see
Figure 12-1) and double-clicked the Install.bat application.
Figure 12-1 Contents of the Tivoli Key Lifecycle Manager Install DVD
Follow these steps to install Tivoli Key Lifecycle Manager on Windows:
1. The first window prompts you to select the language that you want to install, as shown in
Figure 12-2. Make your selection, and click OK.
Figure 12-2 Select language
2. The wizard then starts, as shown in Figure 12-3. Select Next.
Figure 12-3 Install Wizard
3. If you agree with the terms of the license, accept them, and click Next (Figure 12-4 on
page 269).
Figure 12-4 License Agreement
4. The system on which we are installing Tivoli Key Lifecycle Manager is a clean Windows
Server 2008 installation with nothing else on it. In our lab, we accepted the defaults for
DB2 (Figure 12-5 on page 270).
Figure 12-5 DB2 installation directory
5. In the next panel, which is shown in Figure 12-6 on page 271, make your changes, or
accept the defaults. Make sure that you make a note of the ID and password. Then, click
Next.
Figure 12-6 DB2 information
The middleware installation now begins, as shown in Figure 12-7 on page 272.
Figure 12-7 Middleware installation
The DB2 database is then created, as shown in Figure 12-8 on page 273.
Figure 12-8 Creating the database
6. The Tivoli Key Lifecycle Manager Installation is now ready to begin (Figure 12-9 on
page 274), so click Next.
Figure 12-9 Start of Tivoli Key Lifecycle Manager Server installation
The Tivoli Key Lifecycle Manager installation takes a few minutes, so be patient
(Figure 12-10 on page 275).
Figure 12-10 Tivoli Key Lifecycle Manager installing
Then, the Deployment Engine installs (Figure 12-11 on page 276).
Figure 12-11 Deployment Engine Initialization
We used the defaults for the installation directory location of Tivoli Integrated Portal
Figure 12-12 Tivoli Integrated Portal setup
The installation continues. During the installation, Tivoli Key Lifecycle Manager presents
various installation progress windows, as shown in Figure 12-13 on page 278.
Figure 12-13 Tivoli Key Lifecycle Manager installing
7. When you get to this point, enter and make a note of the Tivoli Integrated Portal user ID
and password (Figure 12-14 on page 279).
Figure 12-14 Entering the Tivoli Integrated Portal user ID and password
During the installation, you can migrate an existing EKM installation. We did not have an
EKM to migrate, so we left the box unchecked, as shown in Figure 12-15 on page 280.
Figure 12-15 Option to migrate EKM
8. You then get the summary install window. Click Install (Figure 12-16 on page 281).
Figure 12-16 Summary window
The other middleware, such as embedded WebSphere Application Server, installs
Figure 12-17 Embedded WebSphere Application Server installation
And finally, Tivoli Key Lifecycle Manager is installed (Figure 12-18 on page 283). Make a note
of the URL:
http://localhost:16310
You will notice on later windows that this URL is redirected to a URL of this form with port
16316:
https://192.168.150.128:16316/ibm/console/logon.jsp
Figure 12-18 End of installation
However, the installation does not automatically restart all the required services after you
restart the system. If you restart the system now, Tivoli Key Lifecycle Manager does not start.
We will fix that issue now.
To start Tivoli Key Lifecycle Manager automatically when you restart the system, follow these
steps:
1. Go to the Windows Control Panel (Figure 12-19 on page 284).
Figure 12-19 Windows Control Panel
2. From the Control Panel, select the Administrative Tools icon and, then, Services
Figure 12-20 Administrative Tools
On the Services window, you will see that several of the DB2 services are not started
(Figure 12-21). We now start all the DB2 services and set them to automatically restart
after a reboot.
Figure 12-21 Several DB2 services are stopped
3. Right-click each service in turn, and select Start (see Figure 12-22 on page 286). Then,
after the service starts, right-click it again, and select Properties.
Figure 12-22 Starting the DB2 services
4. On the Properties page, select the Startup Type of Automatic (Figure 12-23).
Figure 12-23 Set to Automatic startup
You need to perform this task for each DB2 service. Also, verify that the Tivoli Integrated
Portal service is automatically started, as well (Figure 12-24).
Figure 12-24 Tivoli Integrated Portal service
Now, go to this URL:
http://localhost:16310
You will likely get a certificate error (see Figure 12-25). Click Continue to this website. You
might also get a certificate mismatch warning, where the certificate was created using the
host name and your URL specifies an IP address. In this case, use the host name (and
domain name) in the URL rather than the IP address.
Figure 12-25 Certificate Error
If you get a certificate error, the URL has a pink background, and there is a box to the right of
the URL that shows Certificate Error (Figure 12-26 on page 288).
Command-line method to stop and restart: There are times when you might need to
manually stop and start the Tivoli Key Lifecycle Manager servers (for example, when
installing fixes and for other maintenance procedures). You can use the Services windows
as shown previously. For a command-line method, on Windows, you must be an
administrator or equivalent user. Perform these steps:
1. To stop the server, from the c:\IBM\tivoli\tip\bin directory, run:
stopServer.bat server1 -username tipadmin -password tippassword
2. To start the server, from the c:\IBM\tivoli\tip\bin directory, run:
startServer.bat server1 -username tipadmin -password tippassword
3. To determine the status, from the c:\IBM\tivoli\tip\bin directory, run:
serverStatus.bat server1 -username tipadmin -password tippassword
Figure 12-26 Tivoli Key Lifecycle Manager login page
By clicking Certificate Error, you get more details (see Figure 12-27).
Figure 12-27 Untrusted Certificate
This error occurred, because the Tivoli Key Lifecycle Manager web server used its own
self-signed certificate and not a certificate authority (CA) signed certificate. The correct way
to resolve this problem is to obtain a properly signed certificate and have embedded
WebSphere Application Server use that certificate instead. However, for the purposes of
testing, we instruct the browser to trust this certificate. Follow these steps:
1. So, from the window that is shown in Figure 12-27, click View certificates to get the
window that is shown in Figure 12-28 on page 289.
Figure 12-28 Certificate information
2. Click Install Certificate, and you see the Certificate Import Wizard, as shown in
Figure 12-29 on page 290. Click Next.
Figure 12-29 Certificate Import Wizard
3. Select Place all certificates in the following store, and choose a certificate store by
clicking Browse (Figure 12-30).
Figure 12-30 Choosing the certificate store
4. Select Trusted Root Certificate Authorities for the certificate store (Figure 12-31), and
then, click OK.
Figure 12-31 Trusted root
5. Figure 12-32 shows a summary. Click Finish.
Figure 12-32 Certificate import summary
6. Confirm that you are installing this certificate as a trusted root (Figure 12-33 on page 292).
Figure 12-33 Confirmation that it is a trusted root
The Certificate Import Wizard shows the successful import message (Figure 12-34).
Figure 12-34 Successful certificate import
Do not use this method to manage certificates normally (it, in effect, sets you up as a Root CA
yourself). However, for testing, this approach stops you from getting the annoying Certificate
Invalid messages. Depending on which browser you use and your browser security settings,
the system still might complain that you are trying to access a non-trusted site. In which case,
you need to add the Tivoli Key Lifecycle Manager URL to the list of trusted sites.
You can now log in to Tivoli Key Lifecycle Manager. Enter the ID TKLMAdmin and the default
password, password (Figure 12-35 on page 293). Click Log in.
Figure 12-35 Initial login
Figure 12-36 shows that this version is Version 1.0.0.1 (that is, Fix Pack 1 has been installed).
We now install Interim Fix Packs 1A and 2.
Figure 12-36 Tivoli Key Lifecycle Manager Welcome window
Obtain the fix packs from Fix Central:
http://www.ibm.com/support/fixcentral
Figure 12-37 on page 294 shows the files that are downloaded when you request all three fix
packs.
Figure 12-37 Tivoli Key Lifecycle Manager V1 fix packs
It is important to read the readme file for each fix pack.
Follow these steps to install Interim Fix Pack 1A:
1. Select Interim Fix Pack 1A (a compressed file), right-click it, and select Extract All, as
Figure 12-38 Extract Interim Fix Pack 1A
2. Select the destination folder (Figure 12-39 on page 295).
Figure 12-39 Destination folder for Fix Pack 1A
3. Figure 12-40 shows the .bat file after you extract it from the compressed file.
Figure 12-40 Interim Fix Pack 1A expanded
4. Change to the folder that contains the extracted Interim Fix Pack 1A, and run this
command (Figure 12-41):
changeTklmPassword x y z
The following descriptions define x, y, and z in the command:
x is the Tivoli Integrated Portal administrator ID, as specified during the Tivoli Key
Lifecycle Manager installation.
y is the Tivoli Integrated Portal administrator password.
z is the new password for the TKLMAdmin ID.
Figure 12-41 Installing Interim Fix Pack 1A
5. The command runs. Locate the password successfully changed message at the end, as
Figure 12-42 Interim Fix Pack 1A installed
We now repeat the process for Interim Fix Pack 2:
1. First, expand it (Figure 12-43).
Figure 12-43 Interim Fix Pack 2
2. Select the destination folder, as shown in Figure 12-44 on page 297.
Figure 12-44 Interim Fix Pack 2 destination folder
Figure 12-45 shows the output of the extract function for the interim fix pack.
Figure 12-45 Interim Fix Pack 2 extracted
3. We now run this command:
updateTKLM.bat v w x y >> z
The following descriptions define v, w, x, y, and z in the command:
v is the DB2 ID specified during the installation.
w is the DB2 password.
x is the Tivoli Integrated Portal ID.
y is the Tivoli Integrated Portal password.
z is the path name for the log file.
See Figure 12-46.
Figure 12-46 Installing Interim Fix Pack 2
When the installation completes, you see the window that is shown in Figure 12-47 on
page 298. All the output is in the log file that you specified. This installation can take 5
minutes or more to run, because it stops and starts embedded WebSphere Application
Server, which takes time.
Figure 12-47 Installing Interim Fix Pack 2 has finished
4. Figure 12-48 shows the end of the log file. Look for the successful installation message at
the end.
Figure 12-48 Interim Fix Pack 2 installation log file
5. As a final check, run the command that is shown in Figure 12-49:
"C:\Program Files (x86)\IBM\Common\acsi\bin\listIU.cmd" | find "TKLM-TIP-1"
Figure 12-49 Checking the installation
6. Look for the TKLM-TIP-1002-TKLM-0002 fix name, as shown in the second entry in
Figure 12-50 Checking the installation output
If you now log in to Tivoli Key Lifecycle Manager again, you see that the version is now
1.0.0.2 (Figure 12-51).
Figure 12-51 Tivoli Key Lifecycle Manager version
Now that the Tivoli Key Lifecycle Manager is installed, we can configure it. Go to 12.5,
Configuring Tivoli Key Lifecycle Manager on page 335.
12.3 Installing Tivoli Key Lifecycle Manager on 64-bit Red Hat
Enterprise Linux AS Version 5.3 server
You must install the The Tivoli Key Lifecycle Manager as root. You need to already have the
compat-libstdc++-33-3.2.3-47.3 package installed on your system.
Figure 12-52 on page 300 shows the Red Hat desktop.
Figure 12-52 Red Hat desktop
Follow these steps to see if the compat-libstdc++-33-3.2.3-47.3 package is installed on your
system:
1. Open a Terminal window. Click Applications Accessories Terminal, as shown in
Figure 12-53.
Figure 12-53 Open a Terminal window
2. Run this command, as shown in Figure 12-54 on page 301:
rpm -qa grep -i libstdc
Figure 12-54 Looking for libstdc
Figure 12-55 shows the output of this command:
Figure 12-55 Output of the RPM command
As you can see, the compat-libstdc++-33-3.2.3-47.3 package is not installed, so we now need
to install it:
1. From the desktop, double-click the DVD Icon (the Linux install DVD), as shown in
Figure 12-56.
Figure 12-56 Selecting the Linux installation DVD
2. Select Places Search, as shown in Figure 12-57 on page 302.
Figure 12-57 Selecting to search the DVD
3. Search for compat-libstdc, and set the location to the RHEL Install DVD, as shown in
Figure 12-58.
Figure 12-58 Searching for compat-libstdc on the install DVD
We locate the compat-libstdc package (Figure 12-59).
Figure 12-59 Locating the compat-libstdc package on the DVD
4. Right-click the package, and select Open with Software Installer, as shown in
Figure 12-60 Select Open with Software Installer
The Installing packages window opens (Figure 12-61). Click Apply.
Figure 12-61 Installing the package
5. You might get a warning message; click Install anyway (Figure 12-62 on page 304).
Figure 12-62 Warning message
The software package is installed (Figure 12-63).
Figure 12-63 Package is installed
If we check for the compat-libstdc package, as we did before, we see that it is installed now
(Figure 12-64).
Figure 12-64 Confirming that the compat-libstdc package is installed
In preparation for the installation, ensure that you are running a Korn or Bourne shell. You
also need to update the selinux/config file.
To ensure that you are in the Korn shell, run exec ksh (see Figure 12-65). Remember to run
this command before beginning the installation if you close this window.
Figure 12-65 Ensuring that you are in a korn shell
Next, use the vi editor to update the selinux/config file (Figure 12-66).
Figure 12-66 Editing the selinux/config file
Change the parameter to SELINUX=disabled (Figure 12-67), and save the file (esc wq).
Figure 12-67 Updating the selinux/config file
Now, shut down (click System Shut Down), and restart your system.
Figure 12-68 Shut down RHEL
On the reboot, open a Terminal window. Go to the directory that contains your Tivoli Key
Lifecycle Manager (in this example, the directory is a .tar file), and untar it, as shown in
Figure 12-69.
Figure 12-69 Untarring Tivoli Key Lifecycle Manager
If Tivoli Key Lifecycle Manager has more than one tar file, untar the other files into the same
directory.
Ensure that you have a Korn shell (Figure 12-70).
Figure 12-70 Setting up a Korn Shell
Export the BYPASS_CHECKSYS variable (Figure 12-71).
Figure 12-71 Export BYPASS_CHECKSYS
And then, start the installer (Figure 12-72).
Figure 12-72 Starting the installation of Tivoli Key Lifecycle Manager
The installation is similar to the installation on Windows. Follow these steps:
1. First, select your language (Figure 12-73).
Figure 12-73 Select the language
2. The Install Wizard starts (Figure 12-74 on page 308). Select Next.
Figure 12-74 The installation wizard
3. Accept the license (Figure 12-75 on page 309).
Figure 12-75 Accept the license
4. We used the default DB2 directories (Figure 12-76 on page 310).
Figure 12-76 Specifying the DB2 directories
5. We used the default IDs and ports (Figure 12-77 on page 311). Make sure that you make a
note of the passwords.
Figure 12-77 DB2 IDs and passwords
6. And, we used the default DB2 Group and Home folders (Figure 12-78 on page 312).
Figure 12-78 DB2 Group and Home folders
7. Review the following summary (Figure 12-79 on page 313), and select Next.
Figure 12-79 Summary
You then get a series of progress windows showing the installation, such as Figure 12-80
on page 314. Depending on the machine, the installation can take several minutes.
Figure 12-80 Installation progress
There are several installation phases while the wizard installs the components of Tivoli Key
Lifecycle Manager. Figure 12-81 on page 315 shows that DB2 is installed and that the wizard
is about to start the installation of Tivoli Key Lifecycle Management.
Figure 12-81 DB2 installation complete
8. We used the defaults for Tivoli Integrated Portal again (Figure 12-82 on page 316).
Figure 12-82 Tivoli Integrated Portal installation
9. We used the defaults for the Tivoli Integrated Portal ID. Document the passwords
Figure 12-83 Tivoli Integrated Portal ID, password, and port number
At this point, you can choose to migrate an existing EKM installation. We did not have
EKM, so we did not select the Migrate the Encryption Key Manager properties file check
box (Figure 12-84 on page 318).
Figure 12-84 Encryption Key Manager Migration window
10.Review the summary window (Figure 12-85 on page 319), and click Next if the summary
is correct.
Figure 12-85 Summary
11.After a certain amount of time, the window opens, stating that Tivoli Key Lifecycle Manager
is successfully installed (Figure 12-86 on page 320). Make a note of the URL that is
shown.
Figure 12-86 Tivoli Key Lifecycle Manager is now installed
Open a browser and go to the URL (Figure 12-87).
Figure 12-87 Browser pointing to Tivoli Key Lifecycle Manager
Note: You might need to manually stop and start the Tivoli Key Lifecycle Manager servers
(for example, when installing fixes and for other maintenance procedures). If running on
Linux, AIX, or Solaris, you must be root or an equivalent privileged user that can start and
stop the Tivoli Key Lifecycle Manager services. use these commands:
To stop the server, from the /opt/IBM/tivoli/tip/bin directory, run:
./stopServer.sh server1 -username tipadmin -password tippassword
To start the server, from the /opt/IBM/tivoli/tip/bin directory, run:
./startServer.sh server1 -username tipadmin -password tippassword
To determine the status, from the /opt/IBM/tivoli/tip/bin directory, run:
./serverStatus.bat server1 -username tipadmin -password tippassword
You might see an error message, because the certificate (that is provided by embedded
WebSphere Application Server) is self-signed (Figure 12-88).
You might also or instead get a certificate mismatch warning if the certificate was created
using the host name and your URL specifies an IP address. In this case, use the host name
(and domain name) in the URL rather than the IP address.
Figure 12-88 Certificate problem with Firefox
In an actual production environment, you typically install a trusted certificate on the Tivoli Key
Lifecycle Manager server, but in our test environment, we click Or you can add an exception
(see Figure 12-88).
Then, the next window, click Add Exception (Figure 12-89).
Figure 12-89 Adding an exception
Click Get Certificate in Figure 12-90 on page 322.
Figure 12-90 Get the certificate
Then, click Confirm Security Exception, as shown in Figure 12-91 on page 323.
Figure 12-91 Confirm the security exception
Now, you see the Tivoli Key Lifecycle Manager Login window. Log in as tklmadmin (default
password is password). See Figure 12-92.
Figure 12-92 Tivoli Key Lifecycle Manager login
The initial window opens. Notice that the version is 1.0 (Figure 12-93 on page 324).
Figure 12-93 Tivoli Key Lifecycle Manager initial window
We now have to install the three fix packs (Fix Pack 1, Interim Fix Pack 1A, and Interim Fix
Pack 2).It is important to read the readme file for each fix pack.
Fix Pack 1 is a tar.gz file, so first, unzip and untar it, as shown in Figure 12-94 and
Figure 12-95.
Figure 12-94 Unzipping the fix pack
Figure 12-95 Untarring the fix pack and then installing it
Then, install the fix pack, as shown in Figure 12-96. The first two parameters are the DB2 ID
and the password. The second two parameters are the Tivoli Integrated Portal ID and
password. The tee identifies where the log will be written.
Figure 12-96 Installing Fix Pack 1
Look for the Fix Pack 1 successfully installed message, as shown at the bottom of
Figure 12-97.
Figure 12-97 Fix Pack 1 successfully installed
To verify that Fix Pack 1 is installed, run the command that is shown in Figure 12-98.
Figure 12-98 Verifying the installation of Fix Pack 1
To verify its installation, you must see TKLM-TIP-1001-TKLM-0001 as one of the installed
fixes, as shown in the second entry in Figure 12-99.
Figure 12-99 Fix Pack 1 is installed
Now, if you log in to Tivoli Key Lifecycle Manager, you see the version is 1.0.0.1, as shown in
Figure 12-100.
Figure 12-100 Tivoli Key Lifecycle Manager initial window showing Version 1.0.0.1
We now install Interim Fix Pack 1A. The process is similar to the installation of Fix Pack 1.
Unzip and untar Interim Fix Pack 1A, as shown in Figure 12-101 and Figure 12-102.
Figure 12-101 Unzip Interim Fix Pack 1A
Figure 12-102 Untar Interim Fix Pack 1A
Then, install Interim Fix Pack 1A, as shown in Figure 12-103.
Figure 12-103 Installing Interim Fix Pack 1A
This process is interactive (Figure 12-104). You must supply the password for tipadmin and
the new password for tklmadmin.
Make a note of the new password for tklmadmin.
Figure 12-104 Supplying the passwords for Interim Fix Pack 1A
Look for the success message, as shown at the bottom of Figure 12-105 on page 327.
Figure 12-105 Interim Fix Pack 1A successfully installed
Now, we install Interim Fix Pack 2. This process is similar to installing Fix Pack 1.
First unzip and untar Interim Fix Pack 2, as shown in Figure 12-106 and Figure 12-107.
Figure 12-106 Unzipping Interim Fix Pack 2
Figure 12-107 Untarring Interim Fix Pack 2
Then, install Interim Fix Pack 2, as shown in Figure 12-108.
Figure 12-108 Installing Interim Fix Pack 2
Look for the success message, as shown in Figure 12-109 on page 328.
Figure 12-109 Interim Fix Pack 2 successfully installed
As a further check, run the command that is shown in Figure 12-110. Look for the fix
TKLM-TIP-1002-TKLM-002.
Figure 12-110 Checking whether Interim Fix Pack 2 is installed
If you now log in to Tivoli Key Lifecycle Manager (using the new password for tklmadmin that
you specified when you installed Interim Fix Pack 1A), you see that the version is now 1.0.0.2
(Figure 12-111).
Figure 12-111 Tivoli Key Lifecycle Manager at Interim Fix Pack 2 level
12.4 Installing Tivoli Key Lifecycle Manager on z/OS
Unlike the distributed version of Tivoli Key Lifecycle Manager, the z/OS version does not
come packaged with all the required prerequisites. You must pre-install the operating system,
the correct level of DB2, and IBM System Services Runtime Environment (SSRE). Refer to
the Program Directory for IBM Tivoli Key Lifecycle Manager on z/OS for information about
installing DB2 and SSRE.
IBM Tivoli Key Lifecycle Manager for z/OS supports the following software:
z/OS V1 Release 9 or later.
IBM System Services Runtime Environment for z/OS V1.1, with Service Update 1. System
Services Runtime Environment provides IBM Integrated Solutions Console Version 7.1
and the required IBM Java Runtime Environment (JRE).
DB2 for z/OS 8.1 or later.
Cryptographic Support for z/OS V1R8-V1R10 and z/OS.e V1R8 requires a Crypto
Express2 Coprocessor.
On z/OS systems, the Tivoli Key Lifecycle Manager installation script deploys the Tivoli Key
Lifecycle Manager server within the System Services Runtime Environment. Deployment
consists of a System Modification Program/Extended (SMP/E) installation and running a set
of migration, installation, and configuration scripts.
In enterprise environments using Tivoli Key Lifecycle Manager on z/OS, it is likely that
multiple people will handle the installation. A hardware planner is involved in the installation of
the storage devices. A z/OS system programmer is responsible for getting z/OS and SSRE to
the correct levels and for installing Tivoli Key Lifecycle Manager. A DB2 administrator handles
all aspects of DB2. The security manager focuses on the Resource Access Control Facility
(RACF) security and the encryption policies. A data administrator manages the use of the
storage devices. A network engineer handles the network connectivity and firewall issues. All
these activities must coordinated and project-managed. Typically, only one or two people are
responsible for a smaller, distributed installation of Tivoli Key Lifecycle Manager.
Full details of the installation of Tivoli Key Lifecycle Manager on z/OS are beyond the scope of
this book; however, IBM Tivoli Key Lifecycle Manager for z/OS, REDP-4472, explains it in
great detail.
Supported web browsers
Refer to Browser support on page 241 for a chart of supported web browsers. There are no
z/OS-supported browsers. Therefore, you must use a browser from a separate Microsoft
Windows, Linux, or Solaris machine to access the Tivoli Key Lifecycle Manager on the z/OS
GUI.
Refer to the IBM Tivoli Key Lifecycle Manager Installation and Configuration Guide,
SC23-9977, for additional requirements, and to other documentation, such as the readme file
or the announcement letter. The announcement letter is number ZP09-0022, which is
available at this website (search on the announcement letter number):
http://www.ibm.com/common/ssi/index.wss
Required: DB2 must reside on the same z/OS system on which the IBM Tivoli Key
Lifecycle Manager server runs. You must also install the DB2 Java Database Connectivity
(JDBC) driver, which is an optional function modification identifier (FMID) that is bundled
with the base DB2 package.
Keystores
After Tivoli Key Lifecycle Manager on z/OS is installed, the operation on z/OS is almost
exactly the same as on the distributed platforms. However, Tivoli Key Lifecycle Manager on
z/OS supports additional keystore types. You must choose one of these keystore types during
installation. Table 12-1 on page 331 summarizes the keystore types.
Tivoli Key Lifecycle Manager supports these keystore types on z/OS:
JCEKS (JCE software provider)
Use this keystore type if you use only Java software. This keystore is for all operating
systems with 3592 tape drives, LTO tape drives, or DS8000 Turbo drives. Ensure that the
flat file JCEKS keystore resides in a restricted area of the file system on the Tivoli Key
Lifecycle Manager system. Use a JCEKS keystore for all operating systems other than
z/OS; however, you might also use this keystore type on a z/OS system if you want to use
JCE software and a flat file to store keys.
JCERACFKS (JCE software provider):
Use this keystore type to store key material in your RACF keyring that is not using
Integrated Cryptographic Services Facility (ICSF). This keystore is only valid for a z/OS
operating system with 3592 tape drives or DS8000 Turbo drives.
If you use a RACF keyring for the master keystore and before you select and configure
the key using JCERACFKS or JCECCARACFKS keystore type, you might have to
perform these tasks:
You might have to give SSRECFG user access to that keyring.
You might have to give SSRE_USERID-started task ID user access to that keyring.
A RACF keyring is not used with an LTO tape drive.
JCERACFKS keystores are compatible with both IBMJCECCA and IBMJCE, that is,
with both hardware and software providers. When configured, certificates and key
material are stored in RACF/System Authorization Facility (SAF). The JCERACFKS
keystore makes use of all the security advantages of RACF/SAF while storing the key
in RACF/SAF.
JCECCARACFKS (IBMJCECCA provider):
keystore type to store key material in your RACF keyring that uses ICSF. This keystore
type is applicable for a z/OS operating system with 3592 tape drives or DS8000 Turbo
drives.
Important: The keystore password can be any value. However, the key password
must match the keystore password.
This keystore type does not support symmetric keys and, therefore, cannot be used
with LTO drives.
If you use both types of tape drives and you have a separate tape library for each
type, you can have this configuration:
One Tivoli Key Lifecycle Manager running with an JCERACFKS keystore for the
keystore for the LTO tape drive
If you use a RACF keyring for the master keystore, you might need to give the
SSRECFG and the SSRE_USERID started task ID user access to that RACF keyring
before you select and configure the RACF keyring using a JCERACFKS or
JCECCARACFKS keystore type. A RACF keyring is not used with an LTO tape drive.
The keystore password can be any value. The key password must match the keystore
password. Use this keystore type if you use RACF and ICSF. For information about the
IBMJCECCA software provider, refer to this website:
http://www.ibm.com/servers/eserver/zseries/software/java/jce.html
JCECCARACFKS is a SAF keyring/ICSF-based keystore supported on the z/OS
operating system only. This keystore uses certificates generated in a RACF or SAF
equivalent where the key material is stored in ICSF. The JCECCARACFKS keystore
makes use of all the security advantages of both RACF/SAF and ICSF.
If you use both types of tape drives and you have a separate tape library for each type,
you can have this configuration:
One Tivoli Key Lifecycle Manager running with a JCECCARACFKS keystore for the
keystore for the LTO tape drive library
JCECCAKS (IBMJCECCA provider):
keystore type when using a file-based keystore that uses ICSF. Ensure that a flat file
JCECCAKS keystore resides in a restricted area of the file system on the Tivoli Key
Lifecycle Manager system. When Tivoli Key Lifecycle Manager is configured to use
hardware protection, key material will be stored within ICSFs Cryptographic Key Data
Set (CKDS) and Public Key Data Set (PKDS). When Tivoli Key Lifecycle Manager is
configured not to use hardware protection, key material will be stored within the flat
file-based JCECCAKS keystore. You can use this keystore for a z/OS operating system
with 3592 tape drives, LTO tape drives, or DS8000 Turbo drives.
JCECCAKS is a file-based keystore that is only supported on the z/OS operating
system.
Table 12-1 Summary of supported keystore types
You must use a JCEKS or JCECCAKS keystore to support LTO tape drives. If you use only
3592 tape drives or DS8000 Turbo drives, you can use a JCEKS, JCECCAKS, JCERACFKS,
or JCECCARACFKS keystore. If you use only LTO tape drives or use both 3592 tape drives
Note: This keystore type does not support symmetric keys. To support LTO tape
drives, use a JCEKS or JCECCAKS keystore.
Keystore Operating system 3592 and
DS8000 (store
key pairs and
certificates)
LTO (store
symmetric keys)
3592, DS8000,
and LTO
JCEKS All Yes Yes Yes
JCECCAKS z/OS Yes Yes Yes
JCERACFKS z/OS Yes N/A N/A
JCECCARACFKS z/OS Yes N/A N/A
and LTO tape drives with the same tape library, you must use a JCEKS or JCECCAKS
keystore.
Supported key sizes and import and export restrictions
Tivoli Key Lifecycle Manager can serve either 2048 or 1024-bit keys to devices. You can
continue to use older keys that were generated as 1024-bit keys. Table 12-2 shows the
supported key sizes and keystore types.
On z/OS Version 1 Release 9 systems, a 1024-bit key is generated only when you configure
Tivoli Key Lifecycle Manager to use one of these keystores:
JCERACFKS keystore
JCECCARACFKS keystore with ICSF protection turned OFF
At z/OS Version 1 Release 9, the RACF component can only store a 1024-bit key. The
restriction applies to both generating and storing or importing keys. The restriction does not
apply to z/OS Version 1 Release 10.
Table 12-2 Supported key sizes and keystore types
Keystore type Import Public Key
Cryptographic
Standards 12 or
PKCS#12 file
Export PKCS#12 file Key generation size
in bits
JCEKS Yes Yes 2048
Note: For Tivoli Key
Lifecycle Manager
Version 1.0 for
distributed systems,
which was released in
2008, apply Fix Pack
1.0.0.1.
JCECCAKS (z/OS) If ICSF protection is:
ON, the key will be
imported into the
PKDS.
OFF, the key will
be imported into
the JCECCAKS
file as a clear key.
No, fails whether ICSF
protection is ON or
OFF
2048
JCERACFKS (z/OS) Depends on the key
size and release of
z/OS:
V1R9:
The PKCS#12 file
must contain a
1024-bit key.
V1R10:
You can import any
key size up to 2048
bits.
The key will be
imported into RACF as
a clear key.
If the key was
generated on:
V1R9:
The exported
PKCS#12 file will
contain a 1024-bit
key.
V1R10:
The exported
PKCS#12 file will
contain a 2048-bit
key.
V1R9
1024
V1R10
2048
Specific issues with Tivoli Key Lifecycle Manager on z/OS
Running Tivoli Key Lifecycle Manager on z/OS allows you to take advantage of all the benefits
of a z/OS platform (such as high availability, reliability, performance, manageability, and so
forth); however, there is one potential disadvantage, the possibility of a deadlock (see 3.4.2,
Encryption deadlock on page 67). Therefore, a stand-alone Tivoli Key Lifecycle Manager on
a System x server ships with each DS8000. It is also partly for this reason that DS8700 with
R5 firmware now supports a recovery key, which allows you to manually enter an unlocking
key if no Tivoli Key Lifecycle Manager is available (for example, as a result of a deadlock).
One of the strengths of the z/OS platform is its security. However, when using a hardware
keystore in secure mode, the security makes it impossible to export private keys and hence
impossible to keep two Tivoli Key Lifecycle Managers in sync. You need to keep two Tivoli Key
Lifecycle Managers in sync to provide a primary and a secondary Tivoli Key Lifecycle
Manager for availability reasons and to avoid deadlock. To accommodate a keystore in secure
mode, DS8700 with R5 firmware implements dual platform support (see 3.4.4, Dual platform
key server support on page 70), which only requires that the public keys are kept in sync
between the primary and secondary Tivoli Key Lifecycle Manager.
In summary, two features of z/OS cause problems with Tivoli Key Lifecycle Manager: the
possibility of deadlock and the security of a secure hardware keystore. With DS8700 with R5
firmware, these issues are mitigated by using recovery key and dual platform support.
Tivoli Key Lifecycle Manager on z/OS GUI
The installation of Tivoli Key Lifecycle Manager on z/OS differs from the installation on
distributed systems, but after Tivoli Key Lifecycle Manager on z/OS is installed, the GUI on
z/OS is in fact similar to the GUI on distributed systems. The only real difference is that on
distributed systems, Tivoli Key Lifecycle Manager is installed on the Tivoli Integrated Portal,
whereas on z/OS, it is installed on the IBM Integrated Solutions Console (ISC), which is part
of SSRE. For example, Figure 12-112 on page 334 shows the logon window for Tivoli Key
JCECCARACFKS
(z/OS)
Depends on the key
size and release of
z/OS:
V1R9
The PKCS#12 file
must contain a
1024-bit key.
V1R10
You can import
any key size up to
2048 bits.
If ICSF protection is:
ON, the key will be
imported into the
PKDS.
OFF, the key will
be imported into
RACF as a clear
key.
Fails, whether ICSF
protection is ON or
OFF.
If ICSF protection is:
ON, the key size is
2048 bits.
OFF
V1R9 (Key size is
1024 bits)
V1R10 (Key size is
2048 bits)
Keystore type Import Public Key
Cryptographic
Standards 12 or
PKCS#12 file
Export PKCS#12 file Key generation size
in bits
Lifecycle Manager on z/OS, which differs slightly from the logon window on distributed
systems (see Figure 12-26 on page 288).
Figure 12-112 Tivoli Key Lifecycle Manager on z/OS logon window
However, after you get into Tivoli Key Lifecycle Manager, the operation and windows are
much the same as on the distributed version of Tivoli Key Lifecycle Manager. Figure 12-113
shows the 3592 Administration window for Tivoli Key Lifecycle Manager on z/OS. The left
pane contains more applications than normally seen on distributed Tivoli Key Lifecycle
Manager, but if you compare it with Figure 12-129 on page 347, you see the actual Tivoli Key
Lifecycle Manager part of the window is the same.
Figure 12-113 Key Administration window for 3592 for Tivoli Key Lifecycle Manager on z/OS
12.5 Configuring Tivoli Key Lifecycle Manager
Now that Tivoli Key Lifecycle Manager is up and running, we need to create a keystore. The
process is the same on all platforms.
Follow these steps to configure Tivoli Key Lifecycle Manager:
1. Open a browser and point it at Tivoli Key Lifecycle Manager. Typically, Tivoli Key Lifecycle
Manager is at the localhost and localdomain:
https://localhost.localdoman:16310
A production Tivoli Key Lifecycle Manager is most likely at a separate IP address or a
separate URL. The default Tivoli Key Lifecycle Manager installation secures the HTTPS
transport with a self-signed certificate and so you might get a security exception. If that is
the case, accept the certificate as shown starting at Figure 12-25 on page 287 and
2. Log on to the Tivoli Integrated Portal as user tklmadmin and the password that was
configured during the installation of Interim Fix Pack 1A. The Welcome window opens, as
shown in Figure 12-114, and Tivoli Key Lifecycle Manager walks you through the initial
setup. First, it asks you to create a master keystore.
Figure 12-114 The Welcome window
3. Click create the master keystore.
The window that is shown in Figure 12-115 on page 336 opens.
Figure 12-115 Enter keystore information
4. For a distributed platform, the only keystore option that you have is JCEKS. Note that this
window requires you to enter the path and filename of the keystore (not just the path). If
the keystore does not already exist, the wizard creates a keystore at the location and with
the name that you specify. In this example, we create tklmKeys.jck as the keystore.
JCEKS is the software keystore that supports both asymmetric and symmetric keys. Make
a note of the password, and click OK.
5. In the next window, as shown in Figure 12-116 on page 337, the wizard continues to walk
you through the initial setup. Click Configure the product to use specific
communication protocol(s).
Figure 12-116 Select the next steps
6. The next window, as shown in Figure 12-117 on page 338, helps you create a certificate to
use with the Secure Sockets Layer (SSL) session between Tivoli Key Lifecycle Manager
and the tape or disk device. You can use an existing certificate in the keystore (for
example, a certificate that will be used to protect tape data, but using a certificate for two
purposes is not a good practice), a certificate from a third party (for example, a trusted
certificate authority), a self-signed certificate, or no certificate if you do not want to use
SSL. For simplicity, we selected Create self-signed certificate.
Choose a descriptive label, and choose a certificate expiration period in days that follows
your security guidelines. You can also enter optional certificate parameters.
Figure 12-117 Create self-signed certificate
7. Click OK. The next window opens, as shown in Figure 12-118 on page 339.
Figure 12-118 Update successful
Our SSL certificate creation was successful. Make a note of the port numbers. You might
need these port numbers for firewall settings.
8. Click Return home.
9. The initial setup is now complete.
12.5.1 Configuration forLTO4 and TS1100
In this implementation example, we create both LTO4 keys and TS1100 keys.
1. Select LTO from the menu, as shown in Figure 12-119 on page 340, and click Go.
Figure 12-119 Creating keys
2. In the next window, click Create (as indicated in Figure 12-120) to create a key group.
Figure 12-120 Key groups
3. In the next window, Figure 12-121 on page 341, enter the key group name, the number of
keys to create, and a three-letter prefix for the key name. Then, click Create Key Group.
Figure 12-121 Create key groups
4. At the warning message, as shown in Figure 12-122 on page 342, click OK.
Out of sync: Because critical information has now changed, Tivoli Key Lifecycle
Manager is warning you that any existing backup is now out-of-date. Similarly, if you are
keeping two or more Tivoli Key Lifecycle Managers in sync (for example, by using
backup/restore or key export/import), these Tivoli Key Lifecycle Managers are now out
of sync, and so, you must manually resynchronize them.
5. In the next window, Figure 12-123 on page 343, you can specify the drives from which
Tivoli Key Lifecycle Manager will accept requests. Or, to populate Tivoli Key Lifecycle
Manager, you can allow Tivoli Key Lifecycle Manager to accept requests from all drives.
Allow Tivoli Key Lifecycle Manager to Accept requests from all IBM drives until Tivoli
Key Lifecycle Manager is aware of all the drives and then turn on security to prevent any
new requests from unknown drives. At a business continuity site, accept all drives to
facilitate a speedy recovery. Click Return home.
Figure 12-123 Identifying drives
6. Notice in Figure 12-124 that the Key Serving Status is Configured to serve keys to LTO
drives.
7. We can now add keys to serve the 3592 drives by selecting 3592, as shown in
Figure 12-124, and, then, clicking Go. We are configuring certificates for 3592 drives.
Figure 12-124 Key administration
8. In the next window, which is shown in Figure 12-125 on page 344, click Create.
Figure 12-125 Identifying drives
9. We now create a certificate for use with 3592s. We can use a third party (for example, a
certificate that is signed by a Certificate Authority) or a self-signed certificate. For
simplicity, in Figure 12-126 on page 345, 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 to 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 12-126 Certificate creation
10.Click Create Certificate.
11.At the next warning message (see Figure 12-127 on page 346), click OK. But, remember
to take new backups and to resync with any other Tivoli Key Lifecycle Managers.
12.In the next window, Figure 12-128, the Tivoli Key Lifecycle Manager can now serve keys to
both LTO and TS1100 drives.
Figure 12-128 Serving keys
You can configure Tivoli Key Lifecycle Manager to serve keys to tape or disk drives before
any tape (or disk) drive is actually available. So, for example, you can configure Tivoli Key
Lifecycle Manager to serve keys to a 3592 and to accept requests from all drives before a
tape drive has been installed (as shown in Figure 12-129). In this case, the tape drive
information is blank.
Tivoli Key Lifecycle Manager does not poll for tape or disk drives; all communication is
initiated from the storage device to Tivoli Key Lifecycle Manager. It is, therefore, only after
a drive has contacted Tivoli Key Lifecycle Manager (for example, as the result of a tape
mount) that the tape drive serial number is known, as shown in Figure 12-130 on
page 348.
If you configure Tivoli Key Lifecycle Manager to not accept requests from all drives, you
need to specify the drive serial numbers from which Tivoli Key Lifecycle Manager will
accept requests.
Figure 12-129 Tivoli Key Lifecycle Manager status of 3592 certificates before contact by a tape drive
Figure 12-130 Tivoli Key Lifecycle Manager status of 3592 certificates after contact by a tape drive
As described in Chapter 2, Introduction to storage data encryption on page 27, there are
many other features and options for configuring tape drives. For example, other features
include assigning specific keys to specific drives, having multiple key groups, with certain
groups associated with specific drives, having the groups then roll over at specified times in
the future, and so forth.
12.5.2 Configuration for DS8000 disk drives
For disk drives, the next step in the configuration sequence is to create the certificates and
associate them with the DS8000 storage facility images (SFIs). From a Tivoli Key Lifecycle
Manager perspective, the configuration is similar to the configuration that is needed for a
3592 tape drive. Follow these steps:
1. In the left pane, select Welcome, and under Key Administration, select DS8000 in the
drop-down menu, as shown in Figure 12-131.
Figure 12-131 Identify images
Click Go.
2. The DS8000 Drive page opens to Step 1, as shown in Figure 12-132. Just as with the
3592, it provides a guided set of configuration steps.
Figure 12-132 Create certificate: Step 1
3. For this example, we reuse a previously created certificate. Therefore, skip Step 1 (Create
Certificates) by clicking either Go to Next Step or Step 2: Identify Images.
The Step 2: Identify Images window, as shown in Figure 12-133, opens.
Figure 12-133 Accept requests
4. Although we can specify for Tivoli Key Lifecycle Manager to accept requests from any
DS8000 drives, do not use this option in a production environment, because it is less
secure.
In the Drives table, click Add.
The Add Storage Image dialog, as shown in Figure 12-134 on page 350, is displayed.
Figure 12-134 Add Storage Image
5. In the Drive serial number field, enter the DS8000 machine type and the serial number. An
example of a serial number is 2424-75XXXX1 (or 2424-75XXXX2 if you are defining the
second SFI in a dual SFI storage system). You use the Partner certificate field when the
DS8700 is configured for dual platform support. We describe the dual platform support in
Chapter 23, DS8000 encryption features and implementation on page 771.
From the Image Certificate drop-down menu, select one of the already created
certificates.
Then, click Add Storage Image.
The window that is shown in Figure 12-135 opens.
Figure 12-135 Storage image added
6. The storage image is added to the table and associated with the certificate that you
specified.
Click Return home to open the window that is shown in Figure 12-136 on page 351,
which confirms that Tivoli Key Lifecycle Manager is now configured for the DS8000.
Figure 12-136 Tivoli Key Lifecycle Manager now configured for a DS8000
You have completed the configuration steps for a DS8000. There are more options available,
depending on your specific requirements, for example, in support of dual platform support.
See Chapter 23, DS8000 encryption features and implementation on page 771 for details.
12.6 Conclusions
Tivoli Key Lifecycle Manager installation and implementation on a distributed platform is
significantly easier than setting up an EKM. Even on a z/OS platform where the installation is
somewhat more complicated due to the complexities and requirements of an enterprise data
center, the installation is still easier and quicker than it was with EKM. A design point of Tivoli
Key Lifecycle Manager is that the installation and use of Tivoli Key Lifecycle Manager can be
accomplished by the client without the need of external services. However, we do advise
engaging IBM Lab Services at least in a consultative role even for a distributed platform. As
you will see in other parts of this book, the storage devices (tape or disk) also need installing
and customizing to use encryption with Tivoli Key Lifecycle Manager. It is important that the
two installations and customizations (of Tivoli Key Lifecycle Manager and the storage device)
are coordinated, and IBM Lab services has the skills to help across all areas. Of course, this
assistance becomes even more important in a Tivoli Key Lifecycle Manager on z/OS
installation where the installation of both Tivoli Key Lifecycle Manager and of the storage
device can be more complex.
The Tivoli Integrated Portal (or on z/OS, the Integrated Solutions Console) GUI gives you a
uniform interface for managing keys, certificates, disk, and tape drives across platforms. You
must also consider in a production architecture how to keep keys and certificates
synchronized between Tivoli Key Lifecycle Managers, as well as how to aggregate log
information across Tivoli Key Lifecycle Managers (in order to keep an audit trail of what disks
and tapes were encrypted with what keys and when that happened). Other chapters in this
book describe the Tivoli Key Lifecycle Manager functions that enable you to perform these
functions.
Chapter 13. Tivoli Key Lifecycle Manager
operational considerations
This chapter discusses Tivoli Key Lifecycle Manager operational considerations, including the
following topics:
Scripting
Synchronizing primary Tivoli Key Lifecycle Manager configuration data
Maintenance, including adding and removing drives
Backup procedures
Data sharing with business partners
Removing Tivoli Key Lifecycle Manager
Removing web browser certificate warnings
The Tivoli Key Lifecycle Manager command-line interface (CLI)
We also include mixed-mode data-sharing examples in which we describe the steps that are
required to share encrypted tapes with a business partner running Tivoli Key Lifecycle
Manager or Encryption Key Manager (EKM).
13
13.1 Scripting with Tivoli Key Lifecycle Manager
As with any complex piece of software, routine tasks must be accomplished. By using a CLI,
the tasks can be automated and you gain more reliability and predictability. In this section, we
provide an overview of the scripting interface (for more information, see 13.8, The Tivoli Key
Lifecycle Manager command-line interface on page 386 for an overview of the scripting rules
and the available commands). This is not intended to replace the Tivoli Key Lifecycle Manager
command-line reference or information center, but to provide several supplemental examples.
The scripting interface to Tivoli Key Lifecycle Manager is Jython, a full implementation of
Python integrated with the Java platform. For more information about Jython, visit this
website:
http://www.jython.org/Project/
The reference section of the Tivoli Key Lifecycle Manager Information Center contains a
complete command-line reference, which is located at this website:
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.tklm.doc/ref/
ref_ic_cli.html
We found that the easiest and 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.
13.1.1 Simple Linux backup script example
Example 13-1 invokes the Tivoli Key Lifecycle Manager script on Linux. Example 13-2 shows
the contents of takeBackup.py, which takes a backup of the currently running Tivoli Key
Lifecycle Manager. Example 13-3 shows the output.
Example 13-1 Tivoli Key Lifecycle Manager script invocation on Linux
/opt/IBM/tivoli/tip/bin/wsadmin.sh -username TKLMAdmin -password password -lang
jython -f takeBackup.py
Example 13-2 Content of takeBackup.py
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 13-3 Output of Example 13-2
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
Note: This script is an example and requires enhancement to be used in production. For
instance, including the password in the script is not a good idea.
Chapter 13. Tivoli Key Lifecycle Manager operational considerations 355
tklm_v1.0_20081114153628MST_backup.jar
[root@dyn9011169152 TKLMBackup]#
You can see from Example 13-3 on page 354 that the script in Example 13-2 on page 354
first prints out sample text (nothing complicated here). Then, the script invokes tklmBackupRun
to place the backup in the /root/TKLMBackup directory with the password myBackupPwd and
prints more descriptive text. You can easily add the backup operation to any script that takes
action against the Tivoli Key Lifecycle Manager to capture a before and after snapshot. You
can enhance this script to use it to automate synchronizing Tivoli Key Lifecycle Manager
servers by setting up a cron job or windows task scheduler to take a backup, copy it to the
secondary Tivoli Key Lifecycle Manager, and restore the backup.
13.2 Synchronizing primary Tivoli Key Lifecycle Manager
configuration data
For each keystore, define one Tivoli Key Lifecycle Manager as the primary keystore. This
primary keystore is the keystore on which you make changes. Changes are then replicated
onto the secondary Tivoli Key Lifecycle Manager servers. When selecting the Tivoli Key
Lifecycle Manager servers, if you want to synchronize them using the backup/restore
function, at a minimum, they must be running the same OS, and the secondary Tivoli Key
Lifecycle Manager must have available the same amount or more of free disk space.
Matching the two servers as closely as possible is desirable. Then, install Tivoli Key Lifecycle
Manager using the same DB2 and Tivoli Integrated Portal settings so that a backup from the
primary Tivoli Key Lifecycle Manager can be restored onto the secondary Tivoli Key Lifecycle
Manager server.
For this example, we run two Microsoft Windows Server 2003 hosts running under VMware
ESX. This configuration allowed us to easily match the environment that is seen by Tivoli Key
Lifecycle Manager and its middleware. For the purpose 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, Tivoli Key Lifecycle Manager, and the keystores. To
ensure that the installations were the same, we recorded the primary Tivoli Key Lifecycle
Manager installation to a response file. But, because the response file that it created was
incomplete and did not allow the installer on the secondary machine to run, we instead used
the graphical installer and kept the defaults the same as with the first machine.
Make sure that you complete the installation worksheets that are in the IBM Tivoli Key
Lifecycle Manager Installation and Configuration Guide, SC23-9977.
Naming: Tivoli Key Lifecycle Manager does not tolerate spaces in the installation directory
name. You cannot install to the c:\Program Files directory or to any other directory that
contains a space. The graphical installer defaults to c:\ibm, which works fine.
servers
Tivoli Key Lifecycle Manager 1.0 does not automatically synchronize between servers, but it
provides a convenient backup and restore operation that can be performed using the
command-line interface or web user interface. Synchronization involves backing up a Tivoli
Key Lifecycle Manager and then restoring to another server with the same configuration
parameters:
Select one machine to be the primary Tivoli Key Lifecycle Manager, and originate all
backups from the primary Tivoli Key Lifecycle Manager. All changes must be made on the
primary Tivoli Key Lifecycle Manager and then deployed through a backup and restore to
the secondary Tivoli Key Lifecycle Manager.
When any action is taken on the primary Tivoli Key Lifecycle Manager that requires a new
backup to be taken and the secondary Tivoli Key Lifecycle Manager to be resynched, the
primary Tivoli Key Lifecycle Manager displays a warning message as shown in
To use backup/restore, the primary Tivoli Key Lifecycle Manager and the secondary Tivoli
Key Lifecycle Managers must run the same OS with the same user accounts for Tivoli Key
Lifecycle Manager, Tivoli Integrated Portal, and DB2.
Restores are disruptive to the secondary Tivoli Key Lifecycle Manager, so ensure that the
primary Tivoli Key Lifecycle Manager is active and serving keys before performing the
restore.
For more detail, see 13.4, Tivoli Key Lifecycle Manager backup and restore procedures on
page 371.
Important: The Tivoli Key Lifecycle Manager installer does not always set up the required
services to start automatically, so be sure to test your Tivoli Key Lifecycle Manager
installation after you have enabled the services and restarted the server. For more
information, refer 11.7.2, Migrating from EKM to Tivoli Key Lifecycle Manager on
page 259 and the installation windows in Chapter 12, Implementing Tivoli Key Lifecycle
Manager on page 265 that show how to set the servers to start automatically. Start at
You can also obtain the product documentation from the IBM Tivoli Key Lifecycle Manager
Information Center available at this website:
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.tklm.doc/w
elcome.htm
In the information center, the administrative information is presented in HTML. The
following guides are also provided in PDF files from the information center:
IBM Tivoli Key Lifecycle Manager Quick Start Guide
IBM Tivoli Key Lifecycle Manager Installation and Configuration Guide
13.3 Tivoli Key Lifecycle Manager maintenance
Tivoli Key Lifecycle Manager is intended to help automate part of the routine operations
around key management. However, you cannot set up Tivoli Key Lifecycle Manager one time
and then forget about it. As tape drives enter and leave the environment, you must update
Tivoli Key Lifecycle Manager. Although you can schedule key rollover and pregenerate the
keys for tapes, do not schedule these activities too far in advance; otherwise, you risk
compromised future keys in addition to compromised current keys.
However, for disk drives, after you set the key, it is never changed. Therefore, maintenance
merely involves defining new keys for new drives and deleting old keys (which will
cryptographically erase the DS8000).
In this section, we provide information about these topics:
General management issues
Adding storage devices with Tivoli Key Lifecycle Manager using the graphical user
interface (GUI) and CLI
LTO key group rollover
3592 certificate rollover
13.3.1 General disk and tape management
This section describes the management of DS8000 disk subsystems and IBM tape
subsystems with Tivoli Key Lifecycle Manager.
DS8000 disks
There is little specific ongoing maintenance required for Tivoli Key Lifecycle Manager to
manage disk drives (other than the general backup/restore and the synchronization of
primary and secondary Tivoli Key Lifecycle Manager functions). For example, the certificate is
associated with the storage image at the time that encryption is enabled on that storage
image (or when additional storage images are added), and then no further maintenance of
the certificate is required. You can, however, display the certificates or modify certificate
information (such as the certificate description or the compromised flag).
You normally set Tivoli Key Lifecycle Manager initially to accept requests from any DS8000
Storage Image (as in Figure 13-2). This option will help populate the drive table and saves
you from having to explicitly identify each Storage Image by typing the serial number of each
image. However, as an added security measure, after the initial configuration is complete, you
normally prevent Tivoli Key Lifecycle Manager from accepting requests from any drive and
limit it to those drives that it already knows or those drives that you specifically define.
Figure 13-2 Setting Tivoli Key Lifecycle Manager to accept connections from any DS8000
Tape drives
Tape drives require more active administration and management, partly because there are
often more of them and primarily because each tape can have a separate key. There are likely
many thousands of tapes, unlike the DS8000, where each image has a key, but there are only
a few DS8000s in an installation.
As with DS8000, you can configure Tivoli Key Lifecycle Manager to allow requests from any
tape drive that requests a key or to only allow known drives to obtain keys. 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.
Tivoli Key Lifecycle Manager certificate expiration: When you create the certificate,
you define the period of time during which the certificate will be valid, which means the
time that a key label will support requests for a new data key. It does not prevent any
existing data keys that were created for that key label from being unwrapped. Because
disks typically obtain a new key only one time when an encryption group is configured, the
expiration of the Tivoli Key Lifecycle Manager certificate is of no significance to the ongoing
operation of currently installed and configured encryption groups. However, the expiration
of the Tivoli Key Lifecycle Manager certificate affects whether a new encryption group can
be configured with that key label. The default validity period is 20 years.
If the certificate is approaching its expiry date, Tivoli Key Lifecycle Manager warns you 30
days before it expires, but this expiration has no effect on the ongoing operation of the
encryption groups.
Tivoli Key Lifecycle Manager also tracks which tape drives it knows about and allows you to
group them, depending on your requirements, to make management easier. In addition, for
added security, you can choose to periodically change the certificates (for 3592 tapes) or
group of keys (for LTO tapes) that Tivoli Key Lifecycle Manager uses with new write requests.
Tivoli Key Lifecycle Manager allows you to predefine the certificates and pregenerate groups
of keys and then to specify multiple rollover dates in the future when the new certificates or
key groups are to become active and the old ones inactive. In this way, you can set up Tivoli
Key Lifecycle Manager to automate much of the day-to-day key management well into the
future. See 13.3.3, Scheduling key group rollover for LTO tape drives on page 364 and
13.3.4, Scheduling certificate rollover for 3592 tape on page 368 for more details.
Tivoli Key Lifecycle Manager also warns you when the number of available keys in a key
group is getting low (less than 10% of the total number of keys in the group). This warning
allows you to take action to increase the number of keys before you run out and before you
are stopped from writing any new tapes.
You must be aware of certificate expiry. Tivoli Key Lifecycle Manager warns you 30 days
before a certificate expires, which gives you time to obtain or generate a new certificate for
those affected tape drives. If a drive is unable to get a valid certificate (because its default
certificate has expired), the drive will be unusable until a new, valid certificate is obtained.
This delay is seen as a tape outage. You can configure Tivoli Key Lifecycle Manager to
continue to use expired certificates, but it can compromise security. Valid certificates are only
required for new writes; Tivoli Key Lifecycle Manager will still use expired certificates for the
purpose of accessing existing tapes (for reading encrypted data or appending to it).
Do not delete any keys or certificates until you are sure that all tapes with which they have
been used are no longer needed (the Tivoli Key Lifecycle Manager listing features and
auditing logs will help you identify these certificates). After you delete the keys or certificates,
the data on those tapes is no longer readable.
In summary, Tivoli Key Lifecycle Manager helps with the full key life cycle management:
generating the certificates and keys, rolling them over periodically, notification of certificate
expiry, and eventual deletion.
13.3.2 Adding and removing drives
When adding a tape drive to Tivoli Key Lifecycle Manager, you have to know three key pieces
of information: drive serial number, worldwide node name (WWNN), and the key group or
certificates that you want associated to 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 comma-separated value (.csv) log. You obtain the log by
using the TS3500 web interface. Select Drives Drive Summary, and then select the name
of the drive statistics(.csv) file. You can also download the http://<library
ip>/FS/LIBLG_01_DS.csv file. Note that the drive serial number and drive WWNN have a
leading underscore character (_) that has to be removed. Because Tivoli Key Lifecycle
Manager supports saving only 4 bytes of the WWNN, select the last 4 bytes.
When adding DS8000 drives to Tivoli Key Lifecycle Manager, you only need to know the drive
serial number, for example, see Figure 13-3 on page 360. In this example, notice that the
DS8700 is configured for dual platform support (it has two certificates defined). For full details
about configuring for dual platform support, refer to Chapter 24, DS8700 advanced
encryption features and implementation on page 811.
Using the graphical user interface
The GUI is simple but slower. Simply log in and select your type of tape drive:
Tivoli Key Lifecycle Manager Key Administration DS8000
Tivoli Key Lifecycle Manager Key Administration LTO
Tivoli Key Lifecycle Manager Key Administration 3592
From the Add menu, select Storage Image (DS8000) or Drive (Tape). Refer to Figure 13-3
for the DS8000 and Figure 13-4 on page 361 for an LTO tape drive. A new window opens.
Figure 13-5 on page 361 shows the status of the DS8000 after adding it to Tivoli Key Lifecycle
Manager and shows the two certificates that are associated with this dual platform DS8700.
Figure 13-3 Adding a DS8000 to Tivoli Key Lifecycle Manager
Loading the GUI initially: Depending on the system, the graphical user interface (GUI)
can take time to load initially. Wait for it. If you start getting odd-looking pages, you probably
started clicking links before the GUI finished loading. If that situation happens, log out, log
in again, and then wait for the page to finish loading.
Figure 13-4 Adding a tape drive using the GUI
Figure 13-5 Dual platform DS87000 added to Tivoli Key Lifecycle Manager
Using the command line to add drives
For more information about the Tivoli Key Lifecycle Manager command-line interface, see
13.8, The Tivoli Key Lifecycle Manager command-line interface on page 386 or the
information center at this website:
ref_ic_cli.html
Starting the Windows command line
From the TIP_HOME directory, which is usually the c:\IBM\tivoli\tip\bin directory, run the
command:
wsadmin -username TKLMAdmin -password password -lang jython
Starting the AIX, Solaris, RHEL, or SLES command line
From the TIP_HOME directory, which is usually the /opt/IBM/tivoli/tip/bin directory, run the
command:
./wsadmin.sh -username TKLMAdmin -password password -lang jython
Adding drives using the Jython command line
To add a drive, you must know its serial number and type. You can then add a drive or, more
likely, a set of drives.
Disk drives
Example 13-4 is a batch job (addDS8k.bat) that starts the command line and instructs it to
run the addDS8k.py script (Example 13-5). Example 13-6 shows the output of these
commands.
Example 13-4 Batch job to start the command line
c:\IBM\tivoli\tip\bin\wsadmin -username tklmadmin -password tklmadmin -lang jython
-f addDS8k.py
Example 13-5 The Jython script to add a DS8000
print "Add a DS8000 Drive with the serial number 2424-75ITSO2"
print AdminTask.tklmDeviceAdd('[-type DS8k -serialNumber 2424-75ITSO2 -attributes
"{worldwideName 1234567890abcdef} {aliasOne ds8000cert} {description
DS8000StorageImage}"]')
Example 13-6 Output of the tklmDeviceAdd script
C:\>addDS8k.bat
C:\>c:\IBM\tivoli\tip\bin\wsadmin -username tklmadmin -password tklmadmin -lang
jython -f addDS8k.py
Add a DS8000 Drive with the serial number 2424-75ITSO2
The devices can then be listed, as shown in Example 13-7. This is a batch job
(listDevices.bat) that calls a script (listDevices.py).
Example 13-7 Listing the defined devices in Tivoli Key Lifecycle Manager
C:\>type listDevices.bat
c:\IBM\tivoli\tip\bin\wsadmin -username tklmadmin -password tklmadmin -lang jython
-f listDevices.py
C:\>
C:\>type listDevices.py
print "List out all the drives in the TKLM"
print AdminTask.tklmDeviceList()
C:\>
C:\>listDevices.bat
C:\>c:\IBM\tivoli\tip\bin\wsadmin -username tklmadmin -password tklmadmin -lang
jython -f listDevices.py
List out all the drives in the TKLM
Description = DS8000StorageImage
Serial Number = 2424-75ITSO2
Device uuid = DEVICE-e7f2ad44-9911-49b4-8e86-cbed38599355
Device type = DS8K
World wide name = 1234567890ABCDEF
Key alias 1 = ds8000cert
C:\>
Tape drives
Example 13-8 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 instructs it to run the
addDrive.py script, which then adds two LTO drives and one 3529 drive.
Example 13-8 Start command line to run Jython script to add three drives to Tivoli Key Lifecycle
Manager
[root@dyn9011169152 ~]# cat addDrive.sh
jython -f addDrive.py
[root@dyn9011169152 ~]# cat addDrive.py
print "Add an LTO Drive with the serial number 000012345670"
print AdminTask.tklmDeviceAdd('[-type LTO -serialNumber 000012345670 -attributes
"{worldwideName abcd0100} {description TS3500Frame2Drive1}"]')
print "Add an 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 ~]#
Example 13-9 on page 364 shows the output.
You can 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 13-9 Sample run of script in Example 13-8 on page 363
[root@dyn9011169152 ~]# ./addDrive.sh
Add an LTO Drive with the serial number 000012345670
Add an 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 ~]#
13.3.3 Scheduling key group rollover for LTO tape drives
One of the advantages of Tivoli Key Lifecycle Manager 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 still must adhere to the key usage time guidelines set by your organization.
To create a key group, go to Tivoli Key Lifecycle Manager LTO, and select Add. The
panel in Figure 13-6 opens. Fill out the key data according to your requirements.
Figure 13-6 Creating a key group
After creating the new key group, schedule when it will become the new default key by
selecting the calendar icon, as shown in Figure 13-7 on page 366.
Key group rollover: With Tivoli Key Lifecycle Manager 1.0, you can only schedule key
group rollover for the default key group.
Figure 13-7 Scheduling a key group rollover
An Add Future Write Default - LTO panel displays, as shown in Figure 13-8.
Figure 13-8 Setting the key group rollover
After you set the key group to which you want to change, and the date on which you want
Tivoli Key Lifecycle Manager to make the change, the key change schedule opens, as shown
in Figure 13-9 on page 368.
Key rollovers: Key rollovers occur based on the operating system time of the Tivoli Key
Lifecycle Manager server. To ensure that rollovers occur when you expect, having the Tivoli
Key Lifecycle Manager server use Network Time Protocol (NTP) is a good practice. You
must also consider the time zones. If your disaster recovery site is in another time zone,
there might be a time window where the two key servers serve separate keys.
Figure 13-9 Checking the key group schedule
13.3.4 Scheduling certificate rollover for 3592 tape
One of the advantages of Tivoli Key Lifecycle Manager is that you can schedule it to change
certificates at a predetermined time without human intervention. However, be careful that the
certificates are generated at creation time, not certificate rollover time. 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 it to expire no sooner than three months and one week.
To create a new certificate:
1. Select Tivoli Key Lifecycle Manager Key Administration 3592, and then, select
Add, as shown in Figure 13-10 on page 369.
Figure 13-10 Adding a 3592 certificate
2. Select 3592 Certificate Rollover, as shown in Figure 13-11.
Figure 13-11 Select the calendar icon to schedule a certificate change
3. Select Add. Refer to Figure 13-12 on page 370.
Figure 13-12 Certificate rollover schedule
4. Select the new certificate that you want to use and the date when it must take effect. Refer
to Figure 13-13 on page 371. Note its expiration date to ensure that it will be usable for
encrypting cartridges as long as you need it.
Figure 13-13 Select the certificate and its effective date
5. Make sure that you back up and replicate this change to any secondary Tivoli Key
Lifecycle Manager servers.
13.4 Tivoli Key Lifecycle Manager backup and restore
procedures
Use backup and restore for two purposes:
To safely make a backup of the Tivoli Key Lifecycle Manager configuration, databases, and
keystores
To keep a primary and secondary Tivoli Key Lifecycle Manager synchronized
restoring, the function assumes that the environment is similar. Tivoli Key Lifecycle Manager
restore operations must be on the same platform with the same system, user account
information, Tivoli Key Lifecycle Manager, and middleware file layout.
Because the keystore is backed up with the Tivoli Key Lifecycle Manager instance, treat the
backups with the same logical and physical security controls that you use for the Tivoli Key
Lifecycle Manager keystore.
13.4.1 Using the GUI to back up
Using the GUI to back up the Tivoli Key Lifecycle Manager configuration is fairly simple, but it
requires discipline by the administrator to perform a backup after significant changes and on a
periodic interval. Tivoli Key Lifecycle Manager helps, because it warns you if a new backup is
required. For example, after adding a new certificate for the DS8000, any existing backup is
out-of-date. Tivoli Key Lifecycle Manager issues a warning, as shown in Figure 13-14.
Figure 13-14 Backup warning
z/OS systems: On z/OS systems, the Tivoli Key Lifecycle Manager DB2 database is not
backed up. Also, it does not back up the keyring and certificate information in IBM
Resource Access Control Facility (RACF) if you use a RACF-based keystore, nor does it
backup the key information in Integrated Cryptographic Services Facility (ICSF) if you use
hardware protection.
On a z/OS system, you must coordinate with your DB2 and Security Administrators to
ensure that the DB2 database, keyring, and certificate information are backed up at the
same time as Tivoli Key Lifecycle Manager.
Disruptive: Backup and restore are disruptive to the Tivoli Key Lifecycle Manager server
as of Tivoli Key Lifecycle Manager 1.0. While the backup is proceeding, the Tivoli Key
Lifecycle Manager will not serve keys. A restore will replace the Tivoli Key Lifecycle
Manager settings and keys. For these reasons, perform backup and restore at times of low
system usage.
Before starting the backup, the administrator must plan for a small service outage and confirm
that one or more secondary key servers are running.
To back up using the GUI:
1. Select Tivoli Key Lifecycle Manager Settings Backup and Restore.
2. Click Create Backup. Refer to Figure 13-15.
Figure 13-15 Tivoli Key Lifecycle Manager backup/restore
The panel in Figure 13-16 is displayed. You are prompted to select a location for the
backup, a password for the backup, and a short description.
Figure 13-16 Backup creation
3. Click Create Backup. A warning message indicates that the backup will be stopping the
server. In our environment, this outage was only a couple of minutes.
13.4.2 Restore by using the GUI
Using the GUI to restore the Tivoli Key Lifecycle Manager configuration is fairly simple.
Important: 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 13-17.
Figure 13-17 Tivoli Key Lifecycle Manager Backup and 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 13-18.
Figure 13-18 Select the backup file to restore
3. Enter the password for the backup file, as shown in Figure 13-19.
Figure 13-19 Enter the password
4. Confirm that it is OK to stop the Tivoli Key Lifecycle Manager server and overwrite the
current configuration.
5. Restart Tivoli Key Lifecycle Manager by opening a command line:
If on Windows, you must be an administrator or an equivalent user. Perform these
steps:
i. From the c:\IBM\tivoli\tip\bin directory, run stopServer.bat server1.
ii. Enter the tipadmin user name and password.
iii. Run startServer.bat server1.
iv. Enter the tipadmin user name and password.
If on Linux, AIX, or Solaris, you must be root or the equivalent privileged user that can
start and stop the Tivoli Key Lifecycle Manager services. Perform these steps (see
Example 13-10 on page 376):
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 server1.
iii. Enter the tipadmin surname and password.
Example 13-10 Starting and stopping the Tivoli Key Lifecycle Manager 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

/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]#
13.4.3 Backing up 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 13.1, Scripting with Tivoli Key
Lifecycle Manager on page 354 for an example of a quick backup script and 13.8, The Tivoli
Key Lifecycle Manager command-line interface on page 386 for more details about the CLI.
Starting the CLI on Microsoft Windows
To start the Jython interactive command line as administrator or an equivalent user, run the
following command (assuming Tivoli Key Lifecycle Manager is installed in the default
c:\IBM\tivoli\tip\bin directory):
wsadmin.bat -username TKLMAdmin -password password -lang jython
Starting the CLI on Linux, AIX, or Solaris
To start the Jython interactive command line as root or an equivalent user, run the following
command (assuming Tivoli Key Lifecycle Manager is installed in the default
/opt/IBM/tivoli/tip/bin/ directory):
wsadmin.sh -username TKLMAdmin -password password -lang jython
Disruptive: Tivoli Key Lifecycle Manager Backup is a disruptive operation, so ensure that
you only perform backups during maintenance windows or when you have a secondary
Tivoli Key Lifecycle Manager up and serving keys.
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 command completes, you see something similar to Example 13-11 from a Linux
Tivoli Key Lifecycle Manager server. This example creates a backup with no description and a
password of myBackupPws in the /root/TKLMBackup directory. For a Microsoft Windows
backup, simply enter a valid Windows path name, such as the c:\TKLMBackup path.
Example 13-11 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 ~]#
13.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 that you are already at a command prompt, so it is more natural to restart the
server. You can even script the restore operation so that it includes starting and stopping the
server.
To start the Jython interactive command line as the root or an equivalent user, run the
Disruptive: Tivoli Key Lifecycle Manager restore is a disruptive operation. Ensure that you
only perform restores during maintenance windows or when you have a primary Tivoli Key
Lifecycle Manager up and serving keys.
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 restore completes, you have something similar to Example 13-12 from a Linux Tivoli
Key Lifecycle Manager server. This example restores a backup file with a password of
myBackupPws with the full file name. For a Microsoft Windows backup, simply enter a valid
windows path name, such as the c:\TKLMBackup\<backup filename>.jar path name. The
example then restarts the Tivoli Key Lifecycle Manager server, which is a required step after
performing a restore operation.
Example 13-12 Restoring Tivoli Key Lifecycle Manager 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 ~]#
13.5 Data sharing with business partners
At a certain point, 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 can only import and export keys from Tivoli Key Lifecycle
Manager using the Tivoli Key Lifecycle Manager command line.
13.5.1 Sharing TS1100 certificate data with a business partner
Tivoli Key Lifecycle Manager can export or import certificates in two formats: base64 and
Distinguished Encoding Rules (DER). The default that is used in our example is base64.
To start the Jython interactive command line as root or equivalent user, run the following
Listing the current certificates in the keystore
Assuming that you have started the CLI, you can then list the keys in the keystore by using
the tklmCertList command, as shown in Example 13-13. To export a certificate, you must
first determine its Universally Unique Identifier (UUID). Find the key alias by using the GUI,
and then list out the key by name to find its UUID.
Example 13-13 Sample keystore 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(s)
parameters, as shown in Example 13-14.
Example 13-14 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 13-14, we can export the key by
using the tklmCertExport command, as shown in Example 13-15.
Example 13-15 Using tklmCertExport to export certificates from Tivoli Key Lifecycle Manager
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 that they
can write encrypted tapes using your public key - that you can read using your private key that
is stored in your Tivoli Key Lifecycle Manager.
TS1100 encrypted media certificate import
Your business partner must send you a certificate containing the public key that the business
partner wants to use to encrypt the TS1100 cartridges. After you receive the key, you can
import the certificate by using this command, as shown in Example 13-17 on page 382. Note
the parameter usage:
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 13-16 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>
13.5.2 Sharing LTO key data with a business partner
Tivoli Key Lifecycle Manager can share keys with business partners by using Tivoli Key
Lifecycle Manager to export the symmetric or secret keys (which are protected in transit by
the business partners public key). These keys are then imported into the business partners
keystore and can be used to read or write tapes written with the same key or keys.
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 partners public key
Your business partner must send you a certificate containing the public key that the business
partner wants to use to encrypt the LTO keys. After you receive the key, you can import the
certificate, as shown in Example 13-17 on page 382. Note the parameter usage:
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>]')
Important: With Tivoli Key Lifecycle Manager 1.0, you can only import LTO key data from
Tivoli Key Lifecycle Manager.
Example 13-17 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 can view a range of LTO keys when using the Tivoli Key Lifecycle Manager 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 can change the view in the Tivoli Key Lifecycle Manager to show the key aliases in a
key group, as shown in Figure 13-20.
Figure 13-20 The key aliases in a key group
Exporting LTO keys from the CLI
After you know the aliases of the key group that you want to export, you can use the CLI to
export them.
Exporting the LTO keys
In Example 13-18, we are exporting the keys LTO0000...0 to LTO0000...9. Note that the
command line allows you to ignore the leading 0s (zeros) so that the range that is passed to
the command line using the -aliasRange parameter is LTO0-9. The next option -fileName is
the absolute path of the file that we are exporting. You can use a relative path, but then it is
relative to the Tivoli Key Lifecycle Manager install directory. The keyStoreName parameter
must be set to "Tivoli Key Lifecycle Manager Keystore". The -type option must be set to
secretkey, because this option tells the export command that we are exporting LTO keys. The
tklmKeyExport command line can also be used to export public-private key pairs from Tivoli
Key Lifecycle Manager, if necessary. The -keyAlias parameter specifies which certificate of
the public key to use to encrypt the key file.
Example 13-18 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 Tivoli Key Lifecycle Manager 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 Tivoli Key Lifecycle Manager, as described in 13.5.1, Sharing TS1100 certificate
data with a business partner on page 379. To load the key file, you have to use the CLI.
Loading the key file into Tivoli Key Lifecycle Manager
Example 13-19 shows a script that loads a key file into Tivoli Key Lifecycle Manager. The
importKeyFile.sh script calls the importKeyFile.py script, which prints descriptive text and then
imports a file named the /root/ltoKeyFile file 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 file is an LTO key file. For
additional options, you can use the CLI reference at this website:
ref_ic_cli_key_import.html
Example 13-19 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 13-20 imports an LTO secret or asymmetric key group into Tivoli Key Lifecycle
Manager.
Example 13-20 Key import into Tivoli Key Lifecycle Manager
[root@dyn9011169152 ~]# ./importKeyFile.sh
Importing key file /root/ltoKeyFile to TKLM with the same alias as used on other
TKLM
[root@dyn9011169152 ~]#
13.6 Removing Tivoli Key Lifecycle Manager
You might have to remove Tivoli Key Lifecycle Manager from a system. The current Tivoli Key
Lifecycle Manager 1.0 uninstall process is not as straightforward as running the uninstaller.
The Tivoli Key Lifecycle Manager uninstaller does not uninstall all the components; however,
it is important that you perform a complete uninstall. If you do not uninstall all components of
Tivoli Key Lifecycle Manager, a subsequent install might fail with unexpected and unexplained
errors. Make sure that you have another Tivoli Key Lifecycle Manager or EKM backup system
configured and working, or that you are performing the Tivoli Key Lifecycle Manager cleanup
during a maintenance cycle, because after the Tivoli Key Lifecycle Manager service is
stopped, you can no longer use this Tivoli Key Lifecycle Manager server to read or write disks
or tape cartridges.
You must use the most up-to-date instructions for uninstalling Tivoli Key Lifecycle Manager,
which can be found in the product readme file and also in the information center at this
website:
lm.doc/welcome.htm
13.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 Tivoli Key Lifecycle Manager configuration and keystore, see 13.4, Tivoli Key Lifecycle
Manager backup and restore procedures on page 371.
13.7 Fixing the security warnings in your web browser
In Figure 12-25 on page 287 and in Figure 12-88 on page 321 (where we describe the
installation and initial setup of Tivoli Key Lifecycle Manager on Windows 2008 and on
RedHat), we describe the security warning that you might receive from the browsers. Internet
Explorer and Firefox both raise security warnings about the Tivoli Key Lifecycle Manager
certificate. This action is normal, because the certificate that is installed is an unsigned
certificate.
These steps (and the steps that are shown in Figure 12-25 on page 287 and in Figure 12-88
on page 321) show you how to stop getting this security warning. However, in a production
environment, the appropriate solution is to install a trusted certificate on the Tivoli Key
Lifecycle Manager web application server, rather than continuing to use the unsigned
certificate. If you want to stop the warnings, follow the steps in this section.
13.7.1 Fixing the security warning in Internet Explorer browser
For full details of how to circumvent the problem with Internet Explorer, see Figure 12-25 on
page 287 and the following figures, but in summary, if you receive the error that is shown in
Figure 13-21 on page 386, select Continue if you are sure that you have the correct IP
address for your Tivoli Key Lifecycle Manager server and you have not previously installed the
certificate for this server.
Figure 13-21 Warning message in Internet Explorer browser window
Click the Certificate Error and select view certificates. Refer to Figure 13-21.
Figure 13-22 Internet Explorer error
Then, select Install certificate and follow the prompts to install the Tivoli Key Lifecycle
Manager server certificate. After you have added the certificate, restart Internet Explorer.
13.7.2 Fixing the security warning in Firefox 2
For full details of how to circumvent the problem with FireFox, see Figure 12-88 on page 321,
but, in summary, Firefox 2 is more forgiving. It presents an initial warning, which, if you accept,
does not appear again.
13.8 The Tivoli Key Lifecycle Manager command-line interface
The Tivoli Key Lifecycle Manager command-line interface (CLI) provides commands to match
the function in the Tivoli Key Lifecycle Manager graphical user interface (GUI) and also
provides additional function that is now available in the GUI. The commands use the wsadmin
interface that the WebSphere Application Server provides.
13.8.1 Commands using wsadmin
You can invoke wsadmin commands in batch or interactive mode, in a script, or from a
command prompt using the wsadmin -c command.
Note: You must connect to Tivoli Key Lifecycle Manager using the host name in the
certificate, not the IP address or other host names, to avoid the certificate mismatch
warning.
Note: Tivoli Key Lifecycle Manager V1 does not support Firefox 3, and certain pages do
not render correctly if FireFox 3 is used.
Login: To successfully run commands on the Tivoli Key Lifecycle Manager CLI, which
uses wsadmin commands, you must initially log in as root on systems, such as Linux or AIX.
Use one of these formats for a command:
commandName
This format invokes a command that does not require an argument.
commandName options
This format invokes a command with the specified options. Use this syntax to enter
interactive mode if -interactive mode is included in the options.
The wsadmin tool supports two scripting languages: JACL and Jython. Because the Jython
syntax for wsadmin is the strategic direction for WebSphere Application Server administrative
automation, these examples use the Jython syntax.
The Jython syntax has a parameter and a value:
AdminTask.tklmConfigList()
AdminTask.tklmKeyStoreList('[-v y]')
To enable Jython, specify the wsadmin -lang jython command-line parameter. For example,
change the directory to the bin directory in TIP_HOME:
Windows systems: C:\Program Files\IBM\tivoli\tip\bin
Other systems such as Linux: opt/IBM/tivoli/tip/bin
Then, type the following command:
Windows systems:
wsadmin -username TKLMAdmin -password password -lang jython
Other systems, such as AIX or Linux:
./wsadmin.sh -username TKLMAdmin -password password -lang jython
z/OS systems:
a. Change to the SSRE_APPSERVER_HOME/bin directory.
b. Type:
wsadmin.sh -username SSRECFG -password ssrecfgpass -lang jython
In Jython, use print before the AdminTask command to format the output for readability. Do not
add print to an AdminTask command in a script file.
13.8.2 Tivoli Key Lifecycle Manager commands using wsadmin
To get a list of all command groups using wsadmin, type:
print AdminTask.help ("-commandGroups")
Tivoli Key Lifecycle Manager supports these command groups:
TKLMBackupCommands back up and restore Tivoli Key Lifecycle Manager data.
TKLMConfigurationCommands configure the Tivoli Key Lifecycle Manager application.
TKLMDeviceCommands manage devices such as tape drives.
TKLMGroupCommands manage groups of keys.
TKLMKeyCertManagementCommands manage keys and certificates.
TKLMKeyServerCommands manage an internal component called the keyserver.
TKLMKeyStoreCommands manage the Tivoli Key Lifecycle Manager keystore.
To see all the commands in a group, such as the certificate management commands group,
type this command:
wsadmin>print AdminTask.help ("TKLMKeyCertManagementCommands")
To see the parameters for an individual command within a group, such as the tklmCertCreate
command, type this command:
wsadmin>print AdminTask.help ("tklmCertCreate")
To extract and print the help for the command, type these commands:
wsadmin>s = AdminTask.help("tklmCertCreate")
wsadmin>print s wsadmin>print
13.8.3 Setting a larger timeout interval for command processing
To ensure an adequate amount of time to run a command that requires significant processing,
you might set a larger default timeout interval. To change the value, set the
com.ibm.SOAP.requestTimeout parameter in the
TIP_HOME/profiles/TIPProfile/properties/soap.client.props property to a larger value, or set
the value to zero for no timeout.
13.8.4 Syntax examples
To specify attributes within a list of parameters, use the double quotation marks character (")
and braces character {} as delimiters, for example:
print AdminTask.tklmDeviceUpdate
('[-uuid DEVICE-64c588ad-5ed8-4934-8c84-64cb9e11d990
-attributes "{aliasTwo myPartner99}"]')
To specify a value containing more than one word for an attribute, use additional braces as
delimiters, for example:
print AdminTask.tklmCertUpdate
('[-uuid CERTIFICATE-33fc26e-5fb5a0e66143
-attributes "{information {new information}}"]')
13.8.5 Continuation character
To avoid overwriting the right margin of printed output, these command-line examples are
arbitrarily divided into lengths that will fit on a printed page. They do not show a continuation
character.
In actual commands, however, you might use the backslash (\) character as a continuation
character, for example:
print AdminTask.tklmBackupList \
('[-backupDirectory C:\tipbak1\tklmbackup1 -v y]')
A continuation character cannot occur inside delimited values. For example, this statement is
not valid:
print AdminTask.tklmBackupList \
('[-backupDirectory \
C:\tipbak1\tklmbackup1 -v y]')
13.8.6 Parameter error messages
If you incorrectly type the name of a parameter in a command that you run, an error message
returns the incorrect string.
For example, if you type -uui by mistake, instead of typing -uuid as a parameter, the return
message is similar to the following message:
wsadmin>AdminTask.tklmDeviceDelete('[-uui adsflk]')
WASX7015E: Exception running command:
"AdminTask.tklmDeviceDelete('[-uui adsflk]')"; exception information:
com.ibm.ws.scripting.ScriptingException: WASX8009E: Invalid parameter: uui
Examine the parameters that you typed, using the invalid parameter information as a guide.
Make the appropriate correction. Then, run the command again.
13.8.7 Command summary
tklmBackupRun: Use the tklmBackupRun command to run the backup task.
tklmBackupRunRestore: Use the tklmBackupRunRestore command to restore from an
existing backup file.
tklmBackupGetProgress: Use the tklmBackupGetProgress command to determine the
current phase of a backup task that is running.
tklmBackupGetRestoreProgress: Use the tklmBackupGetRestoreProgress command to
determine the current phase of a restore task that is running.
tklmBackupGetRestoreResult: Use the tklmBackupGetRestoreResult command to
determine the success or failure of a completed restore task.
tklmBackupGetResult: Use the tklmBackupGetResult command to determine the success
or failure of the most recent backup task.
tklmBackupIsRestoreRunning: Use the tklmBackupIsRestoreRunning command to
determine whether the restore task is currently running.
tklmBackupIsRunning: Use the tklmBackupIsRunning command to determine whether the
backup task is currently running.
tklmBackupList: Use the tklmBackupList command to list the backup files in a given
directory.
tklmCertCreate: Use the tklmCertCreate command to create a certificate and a public
and private key pair, and to store the certificate in an existing keystore.
tklmCertDelete: Use the tklmCertDelete command to delete a certificate, which can be in
any state, such as active. You cannot delete a certificate that is associated with a device,
or a certificate that is marked as either default or partner.
tklmCertExport: Use the tklmCertExport command to export a certificate file.
tklmCertGenRequest: Use the tklmCertGenRequest command to create a Public Key
Cryptographic Standards 10 (PKCS#10) certificate request file.
tklmCertImport: Use the tklmCertImport command to import a certificate.
tklmCertList: Use the tklmCertList command to return certificate information, based on
specified criteria, such as a specific state.
tklmCertUpdate: Use the tklmCertUpdate command to update attributes for a certificate.
For example, you might update the state of the certificate to indicate that its use is
compromised.
tklmConfigDeleteEntry: Use the tklmConfigDeleteEntry command to delete a property
in the Tivoli Key Lifecycle Manager configuration file. For example, you might delete a
customized property.
tklmConfigGetEntry: Use the tklmConfigGetEntry command to return the current value or
values of a property in the Tivoli Key Lifecycle Manager configuration file.
tklmConfigList: Use the tklmConfigList command to list the contents of the Tivoli Key
Lifecycle Manager configuration file.
tklmConfigUpdateEntry: Use the tklmConfigUpdateEntry command to change an existing
entry or to add a new entry in the TKLMgrConfig.properties file.
tklmDeviceAdd: Use the tklmDeviceAdd command to add a device to the Tivoli Key
Lifecycle Manager database.
tklmDeviceDelete: Use the tklmDeviceDelete command to remove information that
identifies a drive from the Tivoli Key Lifecycle Manager database.
tklmDeviceList: Use the tklmDeviceList command to list information about all devices of
a given type, or a specific device in the Tivoli Key Lifecycle Manager database.
tklmDeviceUpdate: Use the tklmDeviceUpdate command to update the attributes of a
device in the Tivoli Key Lifecycle Manager database. If the attribute does not exist, it is
added to the device entry.
tklmGroupCreate: Use the tklmGroupCreate command to create a group to which you
might add keys.
tklmGroupDelete: Use the tklmGroupDelete command to delete a key group. Deleting a
populated key group also deletes all the keys in the key group.
tklmGroupEntryAdd: Use the tklmGroupEntryAdd command to add keys to an existing
group. For example, you might add a key to a group. The combination of entries that you
specify will determine which objects are added to the group. More than one object can be
added for a given command instance. For example, you can add all objects of a specified
type.
tklmGroupEntryDelete: Use the tklmGroupEntryDelete command to delete objects from a
group. For example, you might delete a key from membership in a key group. You can
delete only one object at a time. This command does not delete the key metadata and key
material.
tklmGroupList: Use the tklmGroupList command to list the objects in a group of keys, or
the groups of a specific type.
tklmKeyDelete: Use the tklmKeyDelete command to delete a key entry from the keystore.
You cannot delete a key that is associated with a device or that is set as the default key for
the device.
tklmKeyExport: Use the tklmKeyExport command to export secret or private keys.
tklmKeyImport: Use the tklmKeyImport command to import a secret key or a set of secret
keys from a secret key file, or import a private key from a private key file. The private key
file is in PKCS#12 format.
tklmKeyList: Use the tklmKeyList command to list a key or keys, based on specified
criteria, such as an active state.
tklmKeyUpdate: Use the tklmKeyUpdate command to update key metadata in the
database.
tklmKeyServerStatus: Use the tklmKeyServerStatus command to return the status of the
key server, an internal component that the Tivoli Key Lifecycle Manager server contains.
You can use this command to confirm that Tivoli Key Lifecycle Manager server is properly
configured to serve keys to particular device types.
tklmKeyStoreAdd: Use the tklmKeyStoreAdd command to add a file-based keystore.
tklmKeyStoreDelete: Use the tklmKeyStoreDelete command to delete the alias for a
file-based keystore from the Tivoli Key Lifecycle Manager database. For example, only
during a test phase, you might delete a keystore because you want to use a separate
keystore. Do not delete a keystore that is used in production.
tklmKeyStoreList: Use the tklmKeyStoreList command to list the Tivoli Key Lifecycle
Manager keystore.
tklmKeyStoreUpdate: Use the tklmKeyStoreUpdate command to update the name and
password of an existing file-based keystore. When you change the password for the
keystore, you also change the password for all the keys in the keystore.
tklmSecretKeyCreate: Use the tklmSecretKeyCreate command to create one or more
symmetric keys.
tklmServedDataList: Use the tklmServedDataList command to query the database and
list served key data. For example, you might list which devices were served a specific key,
or list the keys that were served to a specific device.
Chapter 14. Planning for Encryption Key
In this chapter, we discuss the planning for the Encryption Key Manager (EKM). You must
implement EKM in at least one of the Java Runtime Environments (JREs) 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 15, Implementing the
Encryption Key Manager on page 413 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 that is 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 5 or LTO4 or LTO5 encryption support. Install the
latest release available, whether you are implementing for TS1120 and TS1130 encryption or
for LTO4 or LTO5 encryption.
You must decide on what platform (or platforms) 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.
14
14.1 EKM planning quick-reference
Table 14-1 compares the encryption characteristics of the TS1120 and TS1130 drives to the
LTO4 drive. Table 14-2 on page 395 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 14-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
keys
Public-private key (Asymmetric) None
Data keys used Unique data key for each cartridge Keyset: A list or range of data
keys used, pregenerated in
keystore
Data keys stored? Wrapped (that is, encrypted) data
keys (2) stored on cartridge,
called externally encrypted data
keys (EEDKs)
Stored in keystore
Keystore Contains private keys and
certificates representing public
keys.
Preloaded in keystore
Contains data keys that have
been pregenerated
Keystore types supported JCEKS (all platforms)
JCE4758KS/JCECCAKS
(z/OS)
JCE4758RACFKS/
JCECCARACFKS (z/OS)
JCERACFKS (z/OS)
IBMi5OSKeyStore (i5)
PCKS11IMPLKS (open)
DCMKS (open)
JCEKS (all platforms)
JCECCAKS (z/OS)
PCKS11IMPLKS (open)
Chapter 14. Planning for Encryption Key Manager and its keystores 395
Table 14-2 compares the software prerequisites for each EKM platform.
Table 14-2 Encryption Key Manager platform software prerequisites
Description TS1120 tape drive LTO4 tape drive
Encryption Key Manager
platform:
Requires EKM Release 1 or
later
Requires EKM Release 2 or
later
IBM z/OS IBM SDK
a
for z/OS, J2TE
b
,
V1.4, 5655-I56 (at the SDK
1.4.2 SR6
c
level or later)
IBM SDK for z/OS, J2TE, V1.4,
5655-I56 (at the SDK 1.4.2 SR8
level or later)
IBM 31-bit SDK for z/OS, J2TE,
V5.0, (z/OS 1.6 and later only),
order 5655-N98 (at the SDK 1.5
SR3 level or later)
IBM 31-bit SDK for z/OS, J2TE,
V5.0, (z/OS 1.6 and z/OS.e 1.6
and later only), order 5655-N98
(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
for Java- Java Developer Kit 5.0
i5/OS V5.3, IBM Developer Kit
for Java- Java Developer Kit 5.0
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
SR5
J2SE 5.0 SR2 or J2SE 1.4.2
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
e
(5608-VC6) and IBM
Runtime Environment for
Solaris, J2TE, Version 5.0 SR2
(Solaris SPARC 64-bit)
TPC-LE (5608-VC6) and IBM
Runtime Environment for
Solaris, J2TE, Version 5.0 SR5
(Solaris SPARC 64-bit)
HP-UX 11.0, 11i v1, or v2 TPC-LE (5608-VC6) and one of
the following Java Runtime
Environments (JREs):
TPC-LE (5608-VC6) and one of
the following JREs:
HP Runtime Environment for
J2SE HP-UX platform, adapted
by IBM for IBM Software,
Version 5.0, SR2 for 64-bit
Itanium64
Itanium64
PA-RISC
PA-RISC
14.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 14.1, EKM planning quick-reference on page 394. These
tables contain information from the IBM System Storage Tape Enterprise Key Manager,
Introduction Planning and User Guide, GA76-0418.
14.2.1 EKM on z/OS or z/OS.e requirements
If EKM is run on the z/OS system, you must install one of the IBM SDKs for Java 2 in
Table 14-3. They are available from this website:
http://www.ibm.com/servers/eserver/zseries/software/java
Table 14-3 EKM minimum software requirements for z/OS and z/OS.e
Windows 2000 Server or
Windows Server 2003
the following JREs:
the following JREs:
IBM 64-bit Runtime
Environment for Windows on
AMD64/EM64T architecture,
J2TE, Version 5.0
IBM 64-bit Runtime
Environment for Windows on
AMD64/EM64T architecture,
J2TE, Version 5.0, SR5
IBM 32-bit Runtime
Environment for Windows,
J2TE, Version 5.0
IBM 32-bit Runtime
Environment for Windows,
J2TE, Version 5.0, SR5
IBM 64-bit SDK for Windows on
Intel Itanium architecture,
J2TE, Version 1.4.2
IBM 64-bit SDK for Windows on
Intel Itanium architecture,
J2TE, Version 1.4.2, SR8
a. Software development kit (SDK)
b. Java 2 Technology Edition (J2TE)
c. Service Refresh (SR)
d. Java 2 Standard Edition (J2SE)
e. IBM TotalStorage Productivity Center - Limited Edition (TPC-LE)
Description TS1120 tape drive LTO4 tape drive
IBM SDK Model and PID number
IBM SDK for z/OS, Java 2 Technology Edition,
V1.4.2 SR8
5655-I56 (at the SDK 1.4.2 SR8 level or later)
IBM 31-bit SDK for z/OS, Java 2 Technology
Edition, V1.5.0 SR5 (z/OS and z/OS.e 1.6 and
later only)
5655-N98 (at the SDK 1.5 SR5 level or later)
As you plan for production deployment of 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.
14.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.
14.2.3 EKM on IBM System i requirements
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 EKM is run on the i5/OS system, you must install one of the following IBM SDKs for Java 2
in Table 14-4 on page 398.
Important: 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 EKM in order to serve Advanced Encryption Standard (AES) keys.
The preferred method to replace these files on z/OS is to copy the unrestricted policy files
that ship 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 website:
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).
APAR: Resource Access Control Facility (RACF) authorized program analysis report
(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 Rivest-Shamir-Adleman algorithm (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.
Table 14-4 EKM minimum software requirements for i5/OS
14.2.4 EKM on AIX requirements
If EKM is run on a System p server with AIX, the requirements is to have AIX V5.2 or later.
Table 14-5 lists the options for IBM Java SDKs to update in order to include the latest version
of EKM.
Table 14-5 AIX EKM minimum software requirements
You can obtain updates to the AIX Java SDK at the following website:
http://www.ibm.com/developerworks/java/jdk/aix/index.html
i5/OS IBM SDK Model and PID number
V5R3 IBM Developer Kit for Java -
Java Developer Kit 5.0
5722-JV1 option 7 plus PTF
SI25093 for 5722-SS1 option 3.
5722-AC3 is also required.
V5R4 IBM Developer Kit for Java -
J2SE 5.0 32-bit
5722-JV1 option 8 plus SR3,
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 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 System Storage Tape Enterprise Key Manager, Introduction Planning and User
Guide, GA76-0418.
IBM SDK Type of update
Java 5 SR5 (32-bit)
Java 5 SR5 (64-bit)
Java 1.4.2 SR8 (32-bit)
Java 1.4.2 SR8 (64-bit)
IBM AIX Developer Kit and Runtime, Java
Technology Edition AIX Software Update Web
Download available from: http://www.ibm.com/developerworks/java/jdk/aix/service.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 this website:
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
are incompatible.
14.2.5 EKM on Linux requirements
If EKM is run on a Linux system, you must install one of the IBM SDKs for Java 2 (listed in
Table 14-6).
Table 14-6 Linux EKM minimum software requirements
You can obtain updates to the Linux Java SDK at the following website:
http://www.ibm.com/developerworks/java/jdk/linux/download.html
14.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 EKM is run on the HP, Sun, or Windows platform, you must install one of the Java Runtime
Environments listed in Table 14-7 on page 400.
Platform IBM SDK
64-bit AMD/Opteron/EM64T
32-bit System x (Intel-compatible)
32-bit System p
64-bit System p
31-bit System z
64-bit System z
J2SE 5.0 SR2 or J2SE 1.4.2 SR5 for TS1120 drives
J2SE 5.0 SR5 or J2SE 1.4.2 SR8 for LTO4 drives
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
java_home/usr/java5/jre/lib/security directory with new files that you can download
from this website:
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
are incompatible.
Table 14-7 EKM minimum software requirements for HP, Sun, or Windows
14.3 EKM and keystore considerations
We begin with questions for you to consider:
On what platforms will you run EKMs? EKM is currently supported on these platforms:
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
Microsoft Windows 2000 Server and Windows Server 2003
You might want to run EKM on more than one of these platforms. In all cases, you want
EKM to run on a highly available platform that is available any time that you require access
to the drives.
If you have z/OS systems, we expect you will probably implement at least one instance of
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. See 14.3.4, Typical
EKM implementations on page 404 for more detailed information about various EKM
platform considerations.
Platform Operating system Runtime environment bundled with TPC
a
a. TPC: IBM TotalStorage Productivity Center - Limited Edition (TPC-LE) - licensed program
product 5608-VC6
HP HP-UX 11.0, 11i v1, or v2 One of the following products:
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
System x Microsoft Windows 2000
Server or Windows Server
2003
IBM 64-bit Runtime Environment for Windows on
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
What keystore deployment model will you employ? These options are available:
For z/OS, these possible keystore options are available:
JCEKS (file-based)
JCE4758KS/JCECCAKS (ICSF secure hardware)
JCE4758RACFKS/JCECCARACFKS (RACF with secure hardware)
JCERACFKS (RACF/System Authorization Facility (SAF))
For distributed open systems, these possible keystore options are available:
JCEKS (file-based)
PCKS11IMPLKS (Public Key Cryptographic Standards 11 hardware crypto)
For i5, these possible keystore options are available:
JCEKS (file-based)
IBMi5OSKeyStore (i5 platform capabilities)
For LTO4 encryption, only the JCEKS or the PCKS11IMPLKS keystore types are
currently supported.
Table 14-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 14-8 Comparison of supported keystores
Do you want to use secure hardware cryptographic services?
The regulations and requirements that your business needs to meet drive this
consideration. You can start simple, implementing a software JCEKS. If you later decide to
move to a hardware solution, you only need to 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. We describe this topic in 16.1, Keystore and SAF Digital Certificates
(keyrings) on page 482.
Do you want to use ICSF/RACF keyrings/keystores?
Again, you might start simple with JECKS and move to ICSF/RACF keyrings/keystores.
Chapter 17, Encryption Key Manager operational considerations on page 531 has an
Keystore type Platforms
supported
TS1120 and
TS1130
(stores key
pairs and
certificates)
LTO4
(stores
symmetric
keys)
TS1120,
TS1130,
and LTO4
Symmetric
key tools
available
JCEKS ALL Yes Yes Yes keytool
PKCS11Impl Open Yes Yes Yes keytool
IBMi5OS System i Yes No No No
JCE4758KS
JCECCAKS
System z Yes Yes Yes Yes, keytool
(clear keys)
hwkeytool
(securekeys)
a
a. Java 1.5 SR9 and later
JCERACFKS System z Yes No No No
JCE4758RACFKS
JCECCARACFKS
System z Yes No No No
in-depth description about why you might choose this over implementation 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 14-1), and we solved this issue by working with our network support
team to create exceptions in the firewall.
Example 14-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 14-1. If your solution requires dealing with your
companys firewall, plan to obtain this type of access as part of your implementation. For z/OS
solutions, 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.
14.3.1 EKM configuration planning checklist
Make sure you have the following information:
Know the recipients for the tapes to be written and to be read. For each recipient, you
must have these components, depending on the drive:
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.
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 15, Implementing the Encryption Key Manager on
page 413 for details.
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.
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 that are used by the TS1120
encryption method or the pregenerated symmetric data keys that are used by the LTO4
or LTO5 encryption method. EKM uses these keystores in assisting the tape drives in
generating, providing, protecting, and retrieving encryption keys.
Depending on the keystore chosen, a keystore might be shareable between the EKM
servers, such as RACF, sysplex, and so forth.
If the EKM servers are running on separate systems, you are likely to use separate
keystores.
14.3.2 Best security practices for working with keys and certificates
Follow these guidelines:
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.
14.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. You can use this method:
1. Create copies of the keystores that EKM will use.
2. Retain a PKCS#12 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 PKCS#12 format and the keystore at your disaster recovery (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 16, Planning and
managing your keys with Encryption Key Manager on page 481 for more information.
Consistency: For the 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.
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.
14.3.4 Typical EKM implementations
You can run EKM on a separate platform from where your data is being encrypted. This
section summarizes several typical scenarios.
Data transfer and EKM both on z/OS
Figure 14-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 EKM through the tape control unit.
Over the FICON channel, EKM provides the key. The data is then encrypted on the IBM
TS1120 Tape Drive.
Figure 14-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
that are associated with open systems tape data. In Figure 14-2 on page 405, the open
systems server, System C, uses 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 System z and System z9 infrastructure to manage the keys for an enterprise,
including the ability to store the keys, using ICSF, in the unique System z or System z9
hardware-enabled keystore. This method provides a highly secure environment for the
keystore and integration with RACF for tight control of the enterprise keystore. It also 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 separate keystores that
are kept synchronized using mirroring technology or administrative processes.
Note: No requirement exists to change the applications on the open systems.
z/OS
DFSMS
ICSF
Encr yption
Key Manager
LM
LXX
TS1 12 0 TS1 12 0
TS1 12 0 TS11 20
DXX
F16
TS1120-C06
TS1 12 0 TS11 20
TS1 12 0 TS11 20
TS11 20 TS11 20
TS11 20 TS1 12 0
3494 or TS3500 Tape Library
RACF
SMS
Policy
Figure 14-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 14-3 on page 406, we use the Library-Managed Encryption methodology 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 the encryption
policy set to ON for the VOLSER range requested. The library then routes the drive key
request to 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.
LM
F16
J70
3494 Tape Library
z/OS1
DFSMS
Java JCE
Primary
Key
Manager
RACF
SMS
Policy
z/OS2
Secondary
Key
Manager
FICON for z/OS data
and key transfer
TS3500 Tape Library IP for Key Requests
Open OS
FCP Data and
Control Paths
LM
J70
ICSF
CEX2C
Java JCE
RACF ICSF
CEX2C
1
a
2
b
c
TS1120 TS1120
TS1120 TS1120
TS1120 TS1120
TS1120 TS1120
TS1120 TS1120
TS1120 TS1120
TS1120 TS1120
TS1120 TS1120
TS1120 TS1120
TS1120 TS1120
TS1120 TS1120
TS1120 TS1120
TS1120 TS1120 Tape Drive
F16
Figure 14-3 Example of open systems central key management with Library-Managed Encryption
Multiple site EKM implementations
Figure 14-4 shows a multiple site tape data encryption environment where multiple platforms
across the sites can all interoperate. Figure 14-4 is an example from the solution test
environment that was 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.
Figure 14-4 Sample multiple site tape data encryption environment
TS1120 TS1120
TS1120 TS1120
TS1120 TS1120
TS1120 TS1120
TS1120 TS1120
TS1120 TS1120
TS3500 Tape Library
IP
AIX
EKM
Other OS
Other OS
Keys
FCP Data / Control Paths
z/OS 1.6
5.0 31 bit
JCERACFKS
Shared PDKS
4 way VIPA plex
z/OS 1.5
1.4.2 31 bit
JCEKS
z/OS 1.4
1.4.2 31 bit
JCE4758KS
Shared PDKS/CKDS
z/OS 1.7
5.0 31 bit
JCE4758RACFKS
Shared PDKS
i/Series
5.0 31 bit
DCMKS
z/OS 1.6 & 1.7
1.4.2 31 bit
(EKM Sysplex)
JCE4758KS
Shared PKDS
2 way VIPA plex
Poughkeepsie SW Tucson Open Tucson SW Austin
z/OS 1.8
1.4.2 31 bit
JCE4758RACFKS
Shared PDKS
10 way VIPA plex
POK Integration
Test
Rochester
Poughkeepsie
Consolidated
Service Test
EKM ONLY
Poughkeepsie
Consolidated
Service Test
EKM ONLY
IN-BAND OUT-OF-BAND
IN-BAND
IN-BAND OUT-OF-BAND
OUT-OF-BAND
x/Series
1.4.2 / 5.0 32 bit
JCEKS
z/OS 1.6
1.4.2 31 bit
JCEKS
Supported Java Levels
Java SDK 1.4.2 SR5/SR6
Java SDK 5.0 SR3
Supported Keystores
SW - JCEKS, JCERACFKS, DCMKS
HW - JCE4758KS, JCE4758RAFKS, PKCS11
TUC HW
MIXED
i/Series
1.4.2 31 bit
DCMKS
Poughkeepsie
Crypto Plex
EKM ONLY
SUN/HP
5.0 64 bit
JCEKS
z/OS 1.6 & 1.7
1.4.2 31 bit
JCEKS
2 way VIPA plex
z/Linux
1.4.2 64 bit
JCEKS
p/Series
1.4.2 32 bit
PKCS11IMPLKS
p/Series
1.4.2 / 5.0 32/64 bit
JCEKS
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 the
aspects of planning that you need to consider.
14.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 the EKMs keystore are the points of control that allow 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 relate 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 14-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.
Figure 14-5 Keystore redundancy example
Drive Table
Configuration
Keystore and
Crypto Services
Drive Table
Configuration
Keystore and
Crypto Services
EKM EKM
14.3.6 Using Virtual IP Addressing
The design of the Sysplex Distributor provides an advisory mechanism that checks the
availability of applications, such as EKM, running on separate 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 14-6. 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 configuration 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.
Figure 14-6 VIPA Sysplex Distributor
The Sysplex Distributor example in Figure 14-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 the
SETIOS command to use the V1 address; on PLEX2, you use SETIOS to use the V2
IMG-A Prim EKM V1
Sec EKM V2
Running EKM
Plex 1
* IMG-A
* IMG-B
* IMG-C
* IMG-D
(VIPAAddr V1)
IMG-B Prim EKM V1
Sec EKM V2
Running EKM
IMG-C Prim EKM V1
Sec EKM V2
IMG-D Prim EKM V1
Sec EKM V2
Plex 2
* IMG-J
* IMG-K
* IMG-L
* IMG- M
(VIPA Addr V2)
IMG-J Prim EKM V2
Sec EKM V1
Running EKM
IMG-K PrimEKM V2
Sec EKM V1
Running EKM
IMG-L Prim EKM V2
Sec EKM V1
IMG-M Prim EKM V2
Sec EKM V1
address. For large enterprises, it is best if PLEX1 and PLEX2 are in separate 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, which is extremely rare. The benefit of this setup is that 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).
14.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 use crypto hardware, be sure to copy the Public Key Data Set (PKDS).
Maintain a primary and secondary EKM and keystore copy (for backup, as well as failover
redundancy).
If you use 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 PKCS#12 format file).
14.3.8 FIPS 140-2 certification
EKM does not provide cryptographic capabilities, and therefore, it does not require, nor is it
allowed to obtain, Federal Information Processing Standard (FIPS) 140-2 certification.
However, EKM takes advantage of the cryptographic capabilities of the IBM Java virtual
machine (JVM) in the IBM Java Cryptographic Extension (IBMJCE) component. EKM 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, You must add the
following provider to the java.security file in $JAVA_HOME/lib/security/ directory:
security.provider.?=com.ibm.crypto.fips.provider.IBMJCEFIPS
Networking: 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.
Important: Backups must not be encrypted. If the backup with the data that you are
recovering is encrypted, you do not have the keystore (that is damaged) with which to get
the data back.
You must add this provider before adding the IBMJCE provider. Renumber the providers
accordingly.
14.4 Other EKM considerations
This section summarizes additional EKM implementation and migration considerations.
14.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 to support
LTO4 encryption. Follow these steps to upgrade:
1. After shutting down the EKM server, replace the Release 1 IBMKeyManagementServer.jar
file with the Release 2 version.
2. Add the required Audit.metadata.file.name property to the configuration file.
3. If you plan to support LTO4 or LTO5 encryption, follow these steps:
a. Generate and add the required symmetric keys to the keystore that is specified in the
config.keystore.file.name property in the configuration file. This action assumes that
the keystore that you use supports symmetric keys.
b. Add the symmetricKeySet property to the configuration file.
4. Restart EKM.
14.4.2 Data exchange with business partners or other platforms
A common practice is to share tapes with other organizations for joint development,
contracting services, or other purposes. 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
organizations public-private certificate and keys to your EKMs 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 organizations. The other
organization is then able to use its EKM and its private key to unwrap the data key that allows
it 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 that
is used by the other organizations EKM, which gives you the flexibility to make a specific tape
that is readable by both your own organization and another organization. If you want to take
advantage of this capability, you must add that other organizations certificate and public key
to your keystore.
Important: You must not use hardware-based keystore types with FIPS.
14.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 that are 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 separate tape drives from your primary site,
the configuration file and tape drive table must contain the correct information for the DR
site.
When using DR, it is standard practice to set the EKM variable
drive.acceptUnknownDrives in the configuration file to true. Refer to Chapter 15,
Implementing the Encryption Key Manager on page 413 for more information.
14.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 partition or a system that is
separate from where the encrypted save is performed. Failure to use a separate partition or
system for EKM can result in data loss.
Prior to recovering encrypted data, 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.
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 EKM configuration file), you must keep a copy of the
password in a secure location. The keystore password must be available to recover EKM.
Encrypted save or archive operations must not be performed on the partition or system
where the EKM server runs. If data is encrypted on the system where EKM runs, EKM
cannot be recovered without the availability of a secondary EKM server.
14.4.5 EKM performance considerations
With System-Managed Encryption 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, ensure that 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 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.
Do not encrypt the EKM files: Remember that you must not use EKM to encrypt the
EKM data files, because you cannot decrypt them without a functioning EKM.
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 14.3.6, Using
Virtual IP Addressing on page 408 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 occur,
the job can appear to have stopped.
Before cancelling a job, ensure that you have allowed enough time for the retry attempts that
are 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.
Chapter 15. Implementing the Encryption Key
Manager
In this chapter, we describe the steps to take to install the Encryption Key Manager (EKM) on
various host platforms.
15
15.1 Implementing EKM in z/OS
The Encryption Key Manager (EKM) is a common platform application that is written in Java
that runs under the Java virtual machine (JVM). EKM can also reside outside of the z/OS
environment. If EKM resides within z/OS, it is part of the UNIX System Services, which is part
of the Open MVS (OMVS) address space.
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 (Integrated Cryptographic Service Facility (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 ICSF. If EKM resides outside of the z/OS environment, the JCEKS software-based
keystores or the Public Key Cryptographic Standards 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 System Storage Tape Enterprise Key Manager,
15.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 appropriate 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 Resource Access Control Facility (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 is displayed:
IOS628E ENCRYPTION ON DEVICE dddd HAS FAILED DUE TO OMVS SEGMENT FAILURE
User ID: The user number (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.
Chapter 15. Implementing the Encryption Key Manager 415
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 15-1.
Figure 15-1 The OMVSEX address space is present
If the UNIX System Services address space is present, the OMVSEX for OMVS is shown.
15.1.2 Installing EKM in z/OS
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 website:
http://www.ibm.com/servers/storage/support/tape/ts1120/downloading.html
http://www-947.ibm.com/systems/support/supportsite.wss/brandmain?brandind=5000034
You can download the IBM 31-bit Software Developer Kit (SDK) for z/OS Java 2 Technology
Edition from the following website:
http://www.ibm.com/servers/eserver/zseries/software/java/j5pcont31.html
Registration: 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 in an OMVS session.
Use a File Transfer Protocol (FTP) and copy the file into the file system. Then, extract the file
into the /usr/lpp/java directory by using the following command:
pax -rf UK17593.PAX.Z
To verify that the correct version of EKM was installed, use the following command at the
OMVS command prompt:
/u/st6t25c>java -version
The information that is shown in Example 15-1 is displayed.
Example 15-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 relates to 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 this command:
extattr +a $JAVA_HOME/bin/libhpi.so
Issuing the java -version command gives you output similar to Example 15-2.
Example 15-2 Output from java version with fixed libhpi.so attributes
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 this website:
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 EKM for z/OS is complete.
Important: You cannot start EKM without an associated keystore.
The IBM System Storage Tape Enterprise Key Manager, Introduction Planning and User
Guide, GA76-0418, provides additional information.
To perform the installation steps that are 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 17, Encryption Key Manager operational
considerations on page 531, 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 Federal Information Processing Standard (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.
15.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.
RACF
You can obtain security permissions from RACF by issuing the following command:
ADDUSER IOSAS OMVS(UID(0) HOME('/'))
Top Secret
Top Secret is a security product that is provided by Computer Associates, Inc. You can obtain
security permissions 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 that is provided by Computer Associates, Inc. You can obtain
security permissions from ACF2 by issuing the following command:
INSERT IOSAS NAME(ID IOSAS) UID(0) HOME
Note: Do not use hardware-based keystore types with FIPS.
Note: The user ID (UID) in the following command examples does not have to be 0 (zero),
but it does require an OMVS segment. You must IPL for the changes to the IOSAS user ID
to be recognized. IOSAS is only used by the IOS component and must be defined as
protected, so giving it UID(0) works fine.
Refer to the appropriate documentation for eTrust CA-ACF2 Security for z/OS.
15.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 keystore is the most secure of the keystores. Access to the keyring is
protected by RACF administration, and private key material is stored in a Public Key Data Set
(PKDS) that is protected by cryptographic hardware. Chapter 16, Planning and managing
your keys with Encryption Key Manager on page 481 discusses this keystore type.
The RACF commands in Example 15-3 define the FACILITY classes that are necessary to
use the RACDCERT commands to create and work with keyrings and certificates.
Example 15-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 15-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 15.1.7, Additional
definitions of hardware keystores for z/OS on page 428.
Example 15-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 15-5 shows how to export a certificate reply and how to import the certificate
response back into a keyring. The RACDCERT commands that are used in Example 15-5
perform the following actions:
Create a new self-signed certificate authority (CA) with a key size of 2048 and private key
information created with crypto-hardware, and that CA is stored in the active PKDS. The
label of this CA is CAexample.
Create two personal certificates with the 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.
Import a PKCS#12 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.
Create a new keyring ITSOring.
Connect the CA to the ring and the three personal certificates.
If you require a third-party certificate verification and response, refer to 16.3, JCE4758KS
and JCECCAKS on page 497.
Example 15-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.
15.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 the /u/ekmserv directory. 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 the /u/ekmserv
directory, sets the default shell to /bin/sh, and associates it with the next available UID. If a
stricter security policy is in effect, the RACF administrator must replace the AUTOUID with
UID(UserIDNumber). Avoid using UID 0.
In addition, this user needs access to the IRR.DIGTCERT.* facility classes, as described in
Example 15-4 on page 418 in 15.1.4, Create a JCE4758RACFKS for EKM on page 418.
Before continuing, download and save the following items to the /u/ekmserv/ directory:
IBM EKM application
IBM EKM sample configuration file
JZOSEKM files for z/OS batch
Download them from this website:
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 that is shown in Example 15-6 on
page 421.
In the example, note the following process:
1. You must include the stty quit ^V line in a profile when logging on to OMVS using
Secure Shell (SSH). The export PS1 line is setting up this users command line. In this
case, we set up the command line to always list the current working directory. This setting
is useful 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 to perform Java hwkeytool commands might be longer than the command
line. By setting several of these long parameters as environment variables, we can save
space on our limited command line.
Example 15-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 JVMs
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 jzosekm.jar file contains Java wrapper code for EKM. To interact with EKM using write to
operator (WTO), we must register a callback using APIs from the JZOS toolkit. The program
code that is contained in this JAR registers a callback using APIs 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 KeyManagerConfig.properties EKM configuration file is now edited with our information.
In Example 15-7 on page 422, we have turned on extra tracing and debugging information.
Example 15-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 15-8 on page 423 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 15-8 Create directories
mkdir keymanager
mkdir keymanager/debug/
mkdir keymanager/audit
After this setup, 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 15-6 on page 421):
java $DT $EKM $keyFile
The following command is the expanded command:
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 882.
15.1.6 Starting EKM
You can start 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 ships as part of the z/OS Java product. Refer to Encryption Key Manager and JZOS
on page 879 for more information.
To define EKM as a started procedure, update the started class table with the z/OS user ID of
EKM. Previously in this section, we created EKMSERV as the user ID to be used with EKM
and the group associated with that started procedure will be SYS1. The z/OS Security Server
RACF Security Administrators Guide, SA22-7683, describes RACF processing and the
definition of started procedures.
Tip: To verify that the EKM server has sufficient authority, issue the following hwkeytool
command 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 that is located in the
$JAVA_HOME/lib/security/java.security path 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
To set up the STARTED class, enter the commands in Example 15-9.
Example 15-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 an
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:
Place the jzosekm.jar file in the $JAVA_HOME/J1.4/lib/ext path.
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 can choose to allocate a file system specifically for use by EKM for audit and debug file
storage. Assume 500 cylinders of space to allocate to the EKMs 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 file system 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 15-10.
Example 15-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 15-11 for your system.
Example 15-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 15-2, we have started 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 15-2 EKM start message
If we execute the following command, the message that is shown in Figure 15-3 on page 427
displays:
f EKMSERV,appl=status
Figure 15-3 EKM status
We can also list how many certificates were loaded into EKM by executing this command:
f EKMSERV,appl=listcerts
Figure 15-4 on page 428 lists the output from this command.
Figure 15-4 EKM certificate list
For a complete listing of EKM commands, refer to 17.1, EKM commands on page 532.
In this example, note that our EKM is running its SSL listener on port 4430. WebSphere might
use port 4430 for Secure Sockets Layer (SSL) processing, so we changed the port so that
EKM does not collide with WebSphere SSL processing.
The following section describes the use of keystores.
15.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 15-12 on page 429, we create a keyring with the name ULIRING.
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.
Example 15-12 Creating a keyring
RACDCERT ADDRING(ULIRING)
In Example 15-13, we create a self-signed certificate authority (CA) called ULICA.
Example 15-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 15-14, we allow the generation of a personal certificate signed to the CA that was
previously generated.
Example 15-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 15-15, we connect the certificate authority to the keyring.
Example 15-15 Connecting the certificate authority to the keyring
RACDCERT CONNECT(CERTAUTH LABEL('ULICA') RING(ULIRING) USAGE(CERTAUTH))
In Example 15-16, you see the definition for a key label called ULICERT1.
Example 15-16 Defining a key label
RACDCERT CONNECT(LABEL('ULICERT1') RING(ULIRING) USAGE(PERSONAL) DEFAULT)
In Example 15-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 15-17 Creating an additional key label
RACDCERT CONNECT(LABEL('ULICERT2') RING(ULIRING) USAGE(PERSONAL) DEFAULT)
In Example 15-18, we show a RACF command where we delete a key label with the name
ULICERT3.
Example 15-18 Deleting a key label
RACDCERT DELETE (LABEL('ULICERT3'))
In Example 15-19, the command deletes a keyring.
Example 15-19 Deleting a keyring
RACDCERT DELRING(ULIRING)
15.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
Open Shortest Path First (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 EKM. That is, 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 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 use.
15.1.9 EKM TCP/IP configuration
Most often, the definitions that are described in 15.1.8, Virtual IP Addressing on page 429
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 can 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 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, you must add the option SHAREOPT 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.
IECIOS PARMLIB example: We show an example of the IECIOS PARMLIB member that
includes the EKM definitions in 18.6.2, Update PARMLIB member IECIOSxx on
page 586.
To set up a Sysplex Distributor:
1. Ensure that you have a dynamic cross-system coupling facility (XCF) component on all
images; it is required. This path 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, 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 15-20 shows a complete definition example.
Example 15-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
15.2 Installing EKM on AIX
In this section, we describe the necessary steps to install EKM in the AIX environment. We
refer to the IBM System Storage Tape Enterprise Key Manager, Introduction Planning and
User Guide, GA76-0418, to install EKM on our AIX server.
15.2.1 Install the IBM Software Developer Kit
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
(JRE) from the IBM developerWorks website. And, we created the required directories and
installed the JRE.
To install the SDK:
1. Download the SDK from the following website, which is reflected in Figure 15-5:
http://www.ibm.com/developerworks/java/jdk/aix/service.html
Figure 15-5 Java code website
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 15-21.
Example 15-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 15-22.
Example 15-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 15-23.
Example 15-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 15-24.
Example 15-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 shown in Example 15-25.
In addition to the logout and login process, you can also execute the profile using the
following command:
. ./.profile
Example 15-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 that the correct directories are used.
We used the echo $JAVA_HOME command, the results of which are shown in
Example 15-26, to ensure that the correct directories are used.
Example 15-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, EKM
requires that the unrestricted policy files are installed in the JVM, before 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 differ 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 must be
placed in the JREs 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 that we followed to replace the policy files. Begin by pointing your
browser to the following website:
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 expand this file using the
pkzip, tar, or jar command.
c. Remove the local_policy.jar file and the US_export_policy.jar file from the
jre\lib\security directory.
d. Put the new files from the .zip file into the jre\lib\security directory. The files have
the same names as the files that were removed in step c.
See Example 15-27.
Example 15-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 this website:
ftp://ftp.software.ibm.com/s390/java/jce/keytool.html
Use the Keytool User Guide as a reference. The guide is located at this website:
http://www.ibm.com/developerworks/java/jdk/security/142/secguides/keytoolDocs/KeyT
oolUserGuide-142.html
Example 15-28 shows the script that we used to create our keystore.
Example 15-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 that was 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. We describe the SSL protocol in detail
in the Secure Sockets Layer example on page 14.
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 differ.
If the alias does not point to a key entry, keytool assumes that you are adding a trusted
certificate entry. In this case, the alias does not already exist in the keystore.
If the alias already exists, 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.
Listing a keystore using keytool
You can use the script that is listed in Example 15-29 to list a keystore.
Example 15-29 List keystore script
keytool -list \
-storetype jceks \
-storepass passphrase
The results of the list keystore script reflect that the import did create a trusted certificate. See
Example 15-30.
Example 15-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>
15.3 Installing EKM on a Microsoft Windows platform
In this section, we describe the installation of EKM in the Microsoft Windows environment.
IBM bundles the Java Runtime Environment (JRE) with IBM TotalStorage Productivity Center
- Limited Edition (TPC-LE) - 5608-VC6. This version of TPC is available without charge.
Important: Be sure to carefully check a certificate before importing it as a trusted
certificate.
15.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 website:
Or, visit the following website:
Click Downloads and look for IBM Encryption Key Manager for the Java platform.
6. Decide on the keystore type.
The type of keystore that you select, depending on your environment, can affect your
future flexibility for encryption implementation. Refer to 16.1, Keystore and SAF Digital
Certificates (keyrings) on page 482 for more details.
7. Define and create a keystore and certificates (AIX and other operating systems), as
shown in Example 15-28 on page 434.
8. Import or create keys and certificates into the keystore.
Refer to Importing and exporting certificates and why on page 435.
9. Define the EKM configuration file. See Example 15-35 on page 445.
10.Define the tape drives to EKM or set the drive.acceptUnknownDrives EKM configuration
property value to ON.
11.Start EKM.
Important: Regardless of which version of IBM SDK you use, you must replace the
US_export_policy.jar file and the local_policy.jar file in your
java_home/usr/java5/jre/lib/security directory with new files that you can download for
Java 5.0 on Sun, System x, and Hewlett-Packard UNIX (HP-UX) from this website:
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.
15.3.2 Installing the IBM Software Developer Kit on Microsoft 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 Microsoft 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 15-6.
Figure 15-6 Language choice
3. Click OK. The installation wizard opens, as shown in Figure 15-7 on page 439.
Important: Ensure that you use the forward slash character (/) in the Java properties EKM
configuration file when defining file locations. Because the KeyManagerConfig.properties
EKM configuration file is a Java properties file, only forward slashes are recognized in path
names, even in Microsoft Windows. Errors occur if you use the backslash character (\) in
the KeyManagerConfig.properties EKM configuration file.
Figure 15-7 InstallShield Wizard
4. Click Next. The License Agreement window opens. See Figure 15-8.
Figure 15-8 License agreement
5. Read the License Agreement, and if acceptable, click Yes.
The Choose Destination Location window opens. See Figure 15-9 on page 440.
Figure 15-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 15-10.
Figure 15-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 15-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 15-12. Click Finish to complete the installation.
Figure 15-12 Installation complete
At a Windows C: prompt, typing Java -version results in Example 15-31.
Example 15-31 After Java installation
C:\Documents and Settings\Administrator>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
US_export_policy.jar file and the local_policy.jar file in your
java_home/usr/java5/jre/lib/security directory with new files that you can download from
this website:
These files install the unrestricted policy files that EKM requires in order to serve AES keys.
See Figure 15-13.
Figure 15-13 Replacing jar files
Figure 15-13 shows the location of the JAR files that have to be replaced.
Upgrade EKM jar
Download the latest IBMKeyManagementServer.jar file and the KeyManagerConfig.properties
EKM configuration file from the IBM website:
Or, visit the following website, 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 the C:\$$$$ekm directory and copied the
KeyManagerConfig.properties EKM configuration file into it.
You must copy the IBMKeyManagementServer.jar file into the C:\Program
Files\IBM\Java50\jre\lib\ext\ directory, which was created during the Java SDK
installation. Figure 15-14 shows the directory.
Figure 15-14 Jar file copied
Editing the EKM config file
The Java SDK uses forward slashes (/), even when running on Microsoft Windows. When
specifying paths in the KeyManagerConfig.properties EKM configuration file, be sure to use
forward slashes. When specifying a fully qualified path name in the command window, use
the backslash character (\) in the normal manner for Microsoft Windows. Example 15-32
shows an example of using forward slashes in relevant KeyManagerConfig parameters.
Example 15-32 Java config forward slash example
config.drivetable.file.url = FILE:///keymanager/drivetable
debug.output.file = keymanager/debug
We discuss the KeyManagerConfig.properties EKM configuration file parameters in 15.3.4,
Configuring and starting EKM on page 444.
15.3.3 Starting EKM on Microsoft Windows
We updated the Windows PATH parameter with the Java directory information, so that we do
not have to enter C:\Program Files\IBM\Java50\bin when starting EKM.
Starting EKM is a two-step process. To get to the Java command prompt, you enter this
command:
java com.ibm.keymanager.KMSAdminCmd KeyManagerConfig_full_file_path_name
Here are the steps that we used:
1. So that we do not have to fully qualify all the configuration parameters, we ensured that we
started in the correct directory that contains our KeyManagerConfig.properties EKM
configuration file.
At the C: prompt, we changed the Windows directory to the directory to which we copied
the KeyManagerConfig.properties EKM configuration file, which in our example is the
C:\$$$$EKM directory, and entered 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 15-33.
Example 15-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
#
15.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
Follow these steps to configure EKM:
1. Download a sample configuration file that you can use as a model from this website:
http://www-1.ibm.com/support/docview.wss?&uid=ssg1S4000504
2. Scroll to the IBM EKM Sample Configuration File section that is identified in Figure 15-15.
Figure 15-15 Location of sample EKM configuration file
3. Click FTP to get the sample KeyManagerConfig.properties EKM configuration file. Edit it
to suit your environment. Example 15-34 on page 445 shows the
KeyManagerConfig.properties EKM configuration file that was downloaded from the
website that you can use as a example to get started.
Example 15-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 made
only a few changes. Example 15-35 is the file that we used to start EKM.
Example 15-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
4. If you want, create a script that tests EKM.
To save effort, we created the script in Example 15-36 so that we did not have to retype
the entire command every time that we wanted to test EKM. This script also proved helpful
to keep track of the correct version of the keymanagerconfig.properties EKM
configuration file that we wanted to use, because we had several versions in various states
for testing purposes.
Example 15-36 startj.sh script
/home/root/ekmserv>cat startj.sh
Start EKM
You are now ready to start EKM, which is a two-step process.
Follow these steps to start EKM:
1. Get to the command prompt of EKM by using the following command:
We used the startj.sh script in Example 15-37 to get to the command prompt.
Example 15-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
Important: Regarding the FIPS parameter, EKM does not provide cryptographic
capabilities, and therefore, EKM 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
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 the
$JAVA_HOME/lib/security/ directory:
security.provider.?=com.ibm.crypto.fips.provider.IBMJCEFIPS
You must add this provider before the IBMJCE provider. Renumber the providers
accordingly.
# <<<< -----EKM command prompt
2. At the EKM command prompt, enter startekm. Example 15-38 shows the results.
Example 15-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 15-39.
Example 15-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 15-40.
Example 15-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 15-41.
Example 15-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 15-42 on page 449 shows a few examples of sample output that is provided by EKM
commands. Note that the tape drive that we used to test writing an encrypted tape is now
reflected in the drive table output of the listdrives command.
Example 15-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 15-43.
Example 15-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 the changes that have been 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 15-16 on page 450, VOLSER J1S357 is mounted, but it has not yet been
encrypted.
The listcerts command: The listcerts command on a production keystore results in an
extremely large display. We shortened the certificates listing in this display example.
Figure 15-16 J1S357 prior to being encrypted
If, during your testing, you want to reset the Tape Library Specialist web GUI encryption
indicator for a cartridge, you can do that in one of two ways:
Change the indicator to NOT ENCRYPTED by insuring 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.
15.4 Installing 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 15.4.1, New installation of the
Encryption Key Manager on page 450.
To upgrade an installed EKM release to a newer service release, refer to 15.4.2,
Upgrading the Encryption Key Manager on page 453.
15.4.1 New installation of the Encryption Key Manager
For a new installation of IBM EKM component for the Java platform, perform these steps:
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 451.
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 452.
New installation of a primary EKM server
Follow these steps to install a primary EKM server:
1. Refer to 14.2.3, EKM on IBM System i requirements on page 397 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 website:
Install the files to the following IFS directories:
For V5R4, install to this directory:
/QOpenSys/QIBM/ProdData/JavaVM/jdk50/32bit/jre/lib/security/
For V5R3, install to this directory:
/QIBM/ProdData/Java400/jdk15/lib/security/
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
The java.security file is located in the following IFS directory:
For V5R4, the file is in this directory:
/QOpenSys/QIBM/ProdData/JavaVM/jdk50/32bit/jre/lib/security/
For V5R3, the file is in this directory:
/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 that 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 21.2.1, Creating an EKM keystore and certificate on page 710 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
and LTO4 and LTO5 tape encryption described in 15.4.3, Configuring EKM for tape data
encryption on page 455.
8. Set up the Encryption Key Manager address in the IBM TS3xxx library and enable
Library-Managed Encryption by referring to 21.2.2, Configuring the TS3500 library for
Library-Managed Encryption on page 722.
Important: Make to sure to replace the existing policy files with the unrestricted policy
files that were 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.
Note: The unique number to be used for adding these security providers depends on
which providers are already specified in your java.security file.
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 the /usr/bin directory 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.
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.
Follow these steps to install and set up an optional secondary EKM server:
1. Follow steps 1 to 4 for the installation of the primary EKM server.
2. When using solely LTO4 or LTO5 tape encryption, ensure that a public-private key
certificate exists in the EKM servers 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 720 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 KeyManagerConfig.properties
EKM configuration file, 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 server TPC/IP addresses on
page 723 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 453) and start the EKM Admin Console from QShell by running the
command:
strEKM -propfile /EKM/KeyManagerConfig.properties
Autostart: 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 an 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)
7. Use the following commands from the primary EKM servers 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
System Storage Tape Enterprise Key Manager, Introduction Planning and User Guide,
GA76-0418.
8. Exit from the primary EKM Admin Console by using the exit command.
9. Start the primary EKM server as a batch job by again referring to step 9 on page 452.
15.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.
Follow these steps to upgrade EKM:
1. Shut down the EKM server:
If the EKM server was started as a batch job, use the i5/OS WRKACTJOB command 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 15-17 on page 454, or by using the
following command:
ENDJOB JOB(EKMBCH)
Configuration changes: Currently, the EKM Admin Console knows nothing about the
EKM server started as a 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.
EKM Admin Console synch command: You can use the EKM Admin Console sync
command, for example, sync -all -ipaddr 9.11.202.6:443, to manually synchronize
or test the synchronization between the primary and secondary EKM server; however, it
requires that the primary EKM server is started interactively.
Important: 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.
Figure 15-17 i5/OS WRKACTJOB panel showing the EKM batch job
If the EKM server was started interactively, run the exit command 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
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 456 (in Customizing the EKM configuration file on page 456).
4. If you are implementing LTO4 tape drive encryption for the first time after this EKM
upgrade, follow these steps:
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 21.1.2, Software
prerequisites on page 703).
Important: 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.
Do not just rename old file: 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 will not be used.
b. Generate the required symmetric keys in a JCEKS-type EKM keystore by referring to
Symmetric key generation for LTO4 encryption on page 721.
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 or LTO5 tape encryption. Refer to
step 3 on page 457, step 4 on page 457, and step 8 on page 458 (all in Customizing
the EKM configuration file on page 456).
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:
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)
15.4.3 Configuring EKM for tape data encryption
In this section, we describe the EKM configuration for TS1120, LTO4, and LTO5 tape
encryption, assuming that you have completed steps 1 - 6 in 15.4.1, New installation of the
Default EKM configuration file
Example 15-44 shows the default EKM configuration file, KeyManagerConfig.properties,
which still has to be customized for a specific environment.
Example 15-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 step 4 on page 451 (in 15.4.1, New installation of the Encryption Key
Manager on page 450), 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 tracking key usage requests for volume serial numbers in an XML metadata file. This
XML data file is an abbreviated version of the EKM audit log and especially useful for LTO4
or LTO5 encryption (see Example of the EKM audit metadata XML file on page 748), for
example:
Audit.metadata.file.name = /EKM/auditlogs/metadata.xml
You can query the audit metadata XML file for specific volume serial numbers or key
aliases with the EKMDataParser Java tool by using the following syntax:
EKMDataParser [-filename metadatafile] [-volser VOLSER] [-keyalias keyalias]
Number of cached entries: 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, do not 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
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 drive.acceptUnknownDrives parameter 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. Add the drive.default.alias1 and
drive.default.alias2 parameters to make sure that EEDK1 and EEDK2 can be generated
for the new drive, for example:
drive.default.alias1 = Tape_Certificate
drive.default.alias2 = Tape_Certificate2
Synchronization: The truststore and keystore are used for optional EKM to EKM
server synchronization using SSL communication, not for communication between
EKM and the tape library.
8. For LTO4 or LTO5 encryption, add the symmetricKeySet parameter that specifies that all
symmetric keys are to be used for LTO4 or LTO5 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 System Storage Tape Enterprise Key
Manager, Introduction Planning and User Guide, GA76-0418, which is available at this
website:
http://www-1.ibm.com/support/docview.wss?rs=1139&context=STCXRGL&dc=D400&uid=ssg1S
4000504
15.5 Implementing LTO4 and LTO5 encryption
When setting up encryption for LTO4 or LTO5 drives and media, unless you use
Application-Managed Encryption (AME), you must select a key manager. For a complete
discussion of the two key management solutions, see 15.6, Implementing LTO4 and LTO5
Library-Managed Encryption on page 472 or 15.7, LTO4 or LTO5 System-Managed
Encryption implementation on page 480. At this time, if you want to run your key manager on
System z, your only option is to use EKM Version 2 or later. For other key server platforms,
you can use Tivoli Key Lifecycle Manager. Your key server can run on any supported platform
that is independent of the host systems you use 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 Storage Management Initiative
Specification (SMI-S) support are only available when the ALMS feature is installed and
enabled.
Refer to 20.2.1, Advanced Library Management System considerations on page 643 for
more details.
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.
15.5.1 LTO4 EKM implementation checklist
We used this checklist to implement encryption using LTO4 or LTO5 drives located within a
TS3500 library with EKM V2 running on a Microsoft Windows system. We show the steps
necessary for installing EKM V2, as well as the steps to implement encryption using LME and
SME:
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 or LTO5 drives. For our
testing purposes, we installed EKM on our personal computer under Microsoft Windows. We
already had Java 1.5.0 installed, as shown in Example 15-45.
Example 15-45 Java version already installed
C:\Documents and Settings\Administrator>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 the IBM System Storage Tape Enterprise Key
Manager, Introduction Planning and User Guide, GA76-0418, to learn how to get the latest
service refresh for your software platform.
15.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 the
EKM configuration file (KeyManagerConfig.properties) from the following website (also
shown in Figure 15-18 on page 460):
Figure 15-18 EKM website
2. In addition to the EKM code and sample EKM configuration, download the latest version of
the IBM System Storage Tape Enterprise Key Manager, Introduction Planning and User
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 15-46 displays the directory after we copied in the newest version
of the IBMKeyManagementServer.jar file to the correct directory. (We downloaded the JAR
file in step 1.)
Example 15-46 Our Java directory
Directory of C:\Program Files\IBM\Java50\jre\lib\ext
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
Follow these steps 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:\ekm\ekm1 command; the results of which
are shown in Example 15-47.
Example 15-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 EKM configuration file to the EKM1
directory. In our example, on Windows, use the following command:
copy KeyManagerConfig.properties c:\ekm\ekm1\KeyManagerConfig.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 this
website:
After identifying yourself by signing in at the website, the panel that is shown in Figure 15-19
on page 462 is displayed.
Figure 15-19 Website 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.
Replace the files in your <JAVA_INSTALL>/lib/security directory. These files are the
unrestricted policy files that EKM requires in order to serve AES keys. Example 15-48 shows
how our directory looked after replacing the two files.
Example 15-48 Directory after replacing the two JARs
Directory of C:\Program Files\IBM\Java50\jre\lib\security
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
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.
15.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 or LTO5) 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 15-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.
Example 15-49 Create private certificate
C:\ekm\ekm1>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:\ekm\ekm1>
At this time, if you issue the following command, you see the window that is shown in
Example 15-50 on page 464:
keytool -ekmhelp
Password: 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 separate password.
Example 15-50 keytool -ekmhelp display
C:\ekm\ekm1>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>]
As you can see from Example 15-50, the keytool utility has been enhanced to generate
aliases and symmetric keys for encryption on LTO Ultrium 4 or 5 tape drives using LTO4 or
LTO5 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 or LTO5
are -alias and -aliasrange:
-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 zeros
filled in automatically to construct aliases that are 21 characters in length, for example:
Specifying ekm1-a yields a series of aliases from EKM000000000000000001 -
EKM00000000000000000A.
Specifying an aliasrange value of xyz01-FF yields a series of aliases from
XYZ000000000000000001 - XYZ0000000000000000FF.
Important: If implementing both LTO4 and 3592 encryption, ensure that the keystore that
you select supports both symmetric (LTO4 or LTO5) and asymmetric (3592) keys. At this
time, only the JCEKS keystore supports both symmetric and asymmetric key types.
The following examples of acceptable aliases can be associated with symmetric keys:
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
The following examples of aliases are not accepted by EKM:
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.
Example 15-51 shows the -genseckey command parameter that we used. 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 use the same password for the keys. We specified a
range of aliases by specifying lto00-1f. This range 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 15-51 keytool -genseckey parameters
C:\ekm\ekm1>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 the -genseckey command with a list of the keystore entries, which is shown in
Example 15-52. Note that we had to specify the keystore password in the command. So, if
you decide to create a bat file to create this list regularly, you must protect the bat file,
because it contains your keystore password.
Example 15-52 keytool -list command
C:\ekm\ekm1>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:\ekm\ekm1>
15.5.4 Off-site or business partner exchange with LTO4 compared to 3592
In Chapter 3, IBM storage encryption methods on page 49, we explained a few 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 that was used to
encrypt the cartridge is included on each cartridge. The encrypted data key on the cartridge
is protected by using the public key of the intended recipient of the tape cartridge.
The cartridge recipient simply uses their private key to unlock or decrypt the data key 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 data key is not
included on the data cartridge? Obviously, you have to provide the recipient with the data key
that was used to encrypt the data. You can provide the data key in one of two ways:
Use a specific key or keys that are already known to the recipient.
Send the data key 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 that is already known by the recipient. Import the recipients key prior to
cartridge creation, and using a BEP, an Internal Label Encryption Policy (ILEP), or even SME
to use the imported data key to encrypt the data that is going off-site.
Sending the data key that was used to encrypt the cartridge data
Another method is to send the data key to the recipient after the cartridge is created. You
need to identify the data key that was used to encrypt the cartridge so that you share the
correct data key with the encrypted cartridge recipient.
Regardless of which method you select, you still must decide how to securely transport the
data key 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 15-50 on
page 464. 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 15-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 data key so
that transport security is not an issue. The recipient of the keytobp file will use the keytool
-importseckey and our public key to unwrap or decrypt the package, yielding the datakey
lto000000000000000001.
Example 15-53 -exportseckey example
C:\ekm\ekm1>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:\ekm\ekm1>
15.5.5 EKM Version 2 installation and customization on Microsoft Windows
In Example 15-54, you see the EKM/EKM1 directory structure that we created. At this point,
we are ready to customize the keymanagerconfig.properties EKM configuration file that we
downloaded earlier.
Example 15-54 Our EKM directory
C:\ekm\ekm1>dir
Volume in drive C has no label.
Volume Serial Number is 6806-ABBD
Directory of C:\ekm\ekm1
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
3 File(s) 13,233 bytes
Example 15-55 is what our KeyManagerConfig.properties EKM configuration file looked like
after making the minimum number of changes. The changes that we made to the original file
are highlighted.
Example 15-55 Our EKM config after minimal changes
C:\ekm\ekm1>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:\ekm\ekm1>
After generating keys and aliases, be sure to update the symmetricKeySet property in the
KeyManagerConfig.properties EKM configuration file to specify the new alias or range of
aliases and the file name 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 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.
Use the following expected administrative steps to populate a keystore:
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. In Example 15-56, we
specify, in addition to the keyrange LTO0000-1f, two single key aliases, redbook123 and
IBMtape01.
Example 15-56 SymmetricKeySet
symmetricKeySet = lto0000-1f, redbooks123, IBMtape01
15.5.6 Starting EKM
Now, you can start EKM. Starting 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. Example 15-57 shows the command that we used to start the EKM Admin
Console. Because the command to start the EKM Admin Console is long, we created a
SEKM.BAT file.
Example 15-57 Starting EKM Admin Console
C:\ekm\ekm1>sekm
C:\ekm\ekm1>java com.ibm.keymanager.KMSAdminCmd KeyManagerConfig.properties
#
2. Start the EKM server by issuing the startekm command, which results in Example 15-58.
Example 15-58 Starting the EKM server with the startekm command
# startekm
Processing
Server is started
#
Figure 15-20 shows our EKM directory after the server has been started.
Figure 15-20 Our EKM directory after the server has been started
15.5.7 Starting EKM as a Microsoft Windows Service
On Microsoft Windows, the EKM server can be installed as a Windows Service or can be
started from a command line. To run the server as a Windows Service, manually download
the binaries for LaunchEKMService.exe from the EKM website:
Refer to the readme file on this website 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.
The LaunchEKMService.exe command has the following format (see Example 15-59 on
page 471):
LaunchEKMService [-help | -i config_file | -u] -help
We define the options:
-help Displays this usage information.
-i Installs the key manager Windows Service using the properties that are specified
in config_file, which contain the 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 the 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.
EKM Windows Service: You must start the EKM Windows Service manually the first
time that it is used by using the Control Panel.
Example 15-59 The LaunchEKMService command example
LaunchEKMService -i KeyManagerConfig.properties
Be sure to specify the properties with full path names in the KeyManagerConfig.properties
EKM configuration file if EKM will be installed and used as a Windows Service. After EKM is
installed as a Windows Service with the previous command, you can start and stop EKM from
the Control Panel. If you attempt 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.
Follow these steps to make the change:
1. Log in as Administrator or a user that is a member of the Administrators group.
2. Open Services, which is 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 the user.
7. Enter user passwords in the Password and Confirm Password text fields.
8. Click Apply to apply the changes.
9. Click OK to close EKMServer properties.
The EKM Windows Service starts successfully.
Example 15-60 shows an example of the EKMDataParser command.
Example 15-60 EKMDataParser metadata report command
C:\eekm\ekm1\metadata>java com.ibm.keymanager.tools.EKMDataParser -filename
EKMData.xml -volser ATS015 >file1
Figure 15-21 shows the metadata file report from the EKMDataParser command that was
issued in Example 15-60.
Figure 15-21 Metadata file report from EKMDataParser
Tip: The registry keys that EKM uses as properties when it starts as a service are located
in this directory:
LHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EKMServer\Parameters
15.6 Implementing LTO4 and LTO5 Library-Managed Encryption
In this section, we describe how to implement Library-Managed Encryption (LME) on a
TS3500 with LTO4 or LTO6 drives to illustrate the differences between 3592 and LTO4 and
LTO5. We use the EKM and keystore that we created and installed in the preceding sections.
15.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 15-22. Note that in the encryption method column, our logical library
reflects none.
Figure 15-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.
Follow these steps to change the encryption method for your library from the pull-down list:
1. Refer to Figure 15-23 on page 473. Select Modify Encryption Method, and press Enter.
Figure 15-23 Modify the encryption method for a logical library
2. Refer to Figure 15-24. From the pull-down list, 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 service support representative (SSR) to enable encryption
on tape drives that are encryption capable but not encryption enabled.
Figure 15-24 Setting the encryption method
3. Refer to Figure 15-25 on page 474. 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 15-25 Setting the scratch encryption policy
4. Take note of the warning that is shown in Figure 15-26. You might have to restart your
operating system so it can rediscover your tape devices. We did not have to do this task in
our testing; however, you might receive the following message.
Figure 15-26 Rediscovery warning
5. If you receive that message, click OK. Then, you see the panel that is shown in
Figure 15-27 on page 475, which reflects that the logical library encryption setting change
request has completed.
Figure 15-27 Logical library encryption change completed
Taking another look at our logical library, as shown in Figure 15-28, note that it is now
configured to use Library-Managed Encryption by using Barcode Encryption Policies.
Figure 15-28 Our LME-ready logical library
15.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.
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 15-29.
Figure 15-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 or 5
tape drive.
Select Cartridges Barcode Encryption Policy, which results in the display that is shown
in Figure 15-30 on page 477. In this example, you see four BEPs that are already defined.
Important: Determining by VOLSER range which cartridges to encrypt works the same for
LTO4, LTO5, and 3592 cartridges. Note, however, that the key labels within BEPs are used
differently for LTO4 and LTO5 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 or LTO5, the
BEPs determine what data key is used to encrypt client data.
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. The 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. In our example, the two key labels that are specified are shown.
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 15.5.3, Create
a JCEKS keystore on page 463 and was specifically shown in Example 15-51 on page 465.
The ATS015 BEP actually refers to the key label for EKM to use to obtain the necessary data
key in which to encrypt client data.
Figure 15-30 Existing Barcode Encryption Policies
Let us take a look at how to define a new BEP, which is shown in Figure 15-31 on page 478.
Figure 15-31 How to define a BEP
In Figure 15-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 BEP. Because we cannot have BEP overlap, we select
ATS020-ATS029.
Select the key mode from the drop-down list box:
Wrapped-Default Default key label from either the Device drive table or the EKM
configuration file. This mode is for 3592 cartridges only.
Wrapped-Clear The externally encoded data key (EEDK) is referenced by the
specified key label. This mode 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 mode
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 666.
Direct-Default Set Select a key in a round-robin manner from the alias range defined to
the keystore. This mode 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 mode is also LTO only and is 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 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 15-32 on page 479. After selecting APPLY, the new BEP
is created.
Figure 15-32 Creating a BEP
Figure 15-33 shows the new BEP that we created.
Figure 15-33 Newly created BEP
15.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. Therefore, it offers more finely grained control over what cartridges to encrypt.
When using Library-Managed Encryption (LME) 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 by configuring the tape library into multiple library
partitions.
TS3310, TS3200, TS3100, and TS2900 do not support a library-managed Barcode
Encryption Policy. LME is 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, LME 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 separate key managers for
each logical library.
15.7 LTO4 or LTO5 System-Managed Encryption
implementation
In this section, we describe the implementation for System-Managed Encryption (SME) on
the TS3500 library with LTO4 or LTO5 drives on the Windows platform. At this time, on open
systems, SME is available on Windows, Linux, AIX, and Solaris platforms.
Encryption policies specifying when to use encryption are set up in the IBM tape device
driver. SME and LME interoperate with each other. A tape that is 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 capability might not be feasible.
For details about setting up SME, refer to the IBM Tape and Medium Changer Device
Drivers for AIX, HP-UX, Linux, Solaris and Windows, GC27-2130, and the Planning and
Operator Guide for your tape library.
15.7.1 LTO4 SME implementation checklist for Windows
Perform these steps to implement LTO4 or LTO5 SME for Windows on each host that will
access 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.
LME: At the time of this writing, Library-Managed Encryption (LME) is the current best
practice for open systems hosts.
LME: Use Library-Managed Encryption on Windows unless you use a drive that is not
mounted in a tape library or autoloader.
Chapter 16. Planning and managing your
keys with Encryption Key
Manager
In this chapter, we outline the keystores that you can use in conjunction with the Encryption
Key Manager (EKM) to complete a tape data encryption solution.
We intend that you use this information about keystores to supplement the implementation
chapters. Here, we outline the steps and commands for configuring keystores. In Part 3,
Implementing tape data encryption on page 189, we showed you how to use a specific
keystore. If the keystore that is 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.
16
16.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 that are 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 882 and Advanced security hwkeytool and keytool
scripts on page 885 for UNIX and UNIX System Services tips and advanced shell scripts for
creating keystores with an added level of security.
16.2 JCEKS
Java Cryptographic Extension Keystore (JCEKS) is a UNIX System Services Java file-based
keystore that is supported on all platforms where 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 email. 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 these tools:
Java keytool utility: The keytool utility (key and certificate management tool) has been
enhanced to generate aliases and symmetric keys for encryption on LTO4 or LTO5 tape
drives using LTO4 or LTO5 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 this
website:
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 describe the management of symmetric keys in 16.2.2, Managing symmetric keys in a
JCEKS keystore on page 486.
Chapter 16. Planning and managing your keys with Encryption Key Manager 483
The next section provides examples for generating key pairs, creating a certificate, using a
certificate authority (CA), and importing the certificate back into a JCEKS keystore.
16.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 can 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 882 for more information about working in the UNIX System
Services environment.
Example of creating a public-private key pair
In Example 16-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 16-1, the key alias is
rsa2048Cert, the distinguished name of the subject is IBM, and the keystore file name is
testkeys.jcks. The password that is used to protect this keystore is passphrase, and the
expiration of the certificate is 999 days. The key size that is generated is 2048 bits in length.
Example 16-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
Formatting: You must type keytool commands on a single line. If you choose to copy these
examples into a script file, you can use the backslash character (\) 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 16-2, the certificate with an alias of rsa2048Cert1 is exported to the
rsa2048Cert1.cer file. This certificate 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 keymaterial
and private keymaterial are exported and symmetrically encrypted.
Example 16-2 Export public key into a file
keytool -export \
-alias rsa2048Cert1 \
-storetype JCEKS \
-provider IBMJCE \
-keypass passphrase
Example of importing a certificate
In Example 16-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 16-3 Import a trusted certificate
keytool -import \
-alias CArsa2048 \
-storetype JCEKS \
-provider IBMJCE \
-keypass passphrase
Example of the keytool -list command
Example 16-4 shows the command to list a JCEKS keystore. This command does not list
private key information. Use the program in 16.8, ShowPrivateTool on page 522 to list
private key information.
Example 16-4 List a keystore
keytool -list \
-storetype jceks \
-storepass passphrase
Output from the list command looks similar to Example 16-5 on page 485.
Example 16-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
Public Key Cryptographic Standards12 (PKCS#12) is a standard format that is defined by
RSA that describes a file for moving public and private keymaterial. A PKCS#12 file is used to
store an X.509 certificate, the public and private keys associated with that certificate, and the
chain of certificate authorities that sign that certificate. The file is encrypted with a symmetric
key that is based on a passphrase. You use PKCS#12 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 16-6, we show the keytool commands to export out a certificate with an alias of
TestCert from our keystore SourceKeys.jck into a PKCS#12 file. We use a password of
CLEARTEXTPASS.
Example 16-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 16-7, we take the PkCS12 file that we created in Example 16-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 also imports
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 is
unknown.
Example 16-7 Import PKCS#12 file into JCEKS keystore
keytool -import -noprompt -trustcacerts \
-alias "TestCert" \
-file export.p12 \
-pkcs12 \
-keystore destinationKeys.jck \
-storetype JCEKS \
-provider IBMJCE
Example 16-8 shows the commands that we used to list both the source keystore and the
destination keystore.
Example 16-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 16-9, we have a listing of our source keystore, and in Example 16-10, we
have the destination keystore that now has two certificates and key pairs in it. If we chose to
run the ShowPrivate utility from 16.8, ShowPrivateTool on page 522, it will show that both
entries in the destination keystore have private keys.
Example 16-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 16-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
16.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
describe 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 zeros 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 - ekm00000000000000000a. Specifying an
aliasrange value of ekm01-ff yields ekm000000000000000001 -
ekm0000000000000000ff.
-keypass Specifies a password that is 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 the password that is 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 use a hardware-based keystore rather than JCEKS.
Example of generating a range of symmetric keys
You can cut and paste Example 16-11 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 -
ekm00000000000000000a.
Example 16-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 EKM configuration file to specify the new alias or range of
aliases. To specify the ten symmetric keys that were generated in the previous example as
the active key set, you set the symmetricKeySet parameter in the configuration file:
symmetricKeySet = ekm01-a
You can 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. Although
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.
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>]
Important: For EKM to use the new alias or range of aliases, you have to update the
symmetricKeySet property in the KeyManagerConfig.properties EKM configuration file.
The following parameters are of particular importance when importing data keys for EKM to
serve to LTO4 or LTO5 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 can cut and paste Example 16-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 import.key file into the EKMKeys.jceks
keystore using the private key with the alias ekmcert to decrypt the symmetric keys.
Example 16-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 or LTO5 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 zeros 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 - ekm00000000000000000a.
Specifying an aliasrange value of xyz01-ff yields
xyz000000000000000001 - 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 can cut and paste Example 16-13 on page 490 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 -
ekm00000000000000000a from the keystore EKMKeys.jceks into an export.key file using the
public key with the alias ekmcert to encrypt the symmetric keys.
Example 16-13 Exporting a range of symmetric keys
keytool -exportseckey \
-aliasrange ekm1-a \
-storetype jceks \
-exportfile export.key \
-keyalias ekmcert
16.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 the $JAVA_HOME/jre/bin directory:
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.
Follow these steps to use iKeyman:
1. Issue the ikeyman command:
java com.ibm.gsk.ikeyman.Ikeyman
2. The IBM Key Management (iKeyman) window opens, which is shown in Figure 16-1 on
page 491. Click the new file (circled) icon beneath the menu bar, or select Key
Database File New.
Tip: iKeyman is useful for working with X.509 certificates, however, to perform symmetric
key operations on a JCEKS, you must use keytool command-line interface (CLI)
commands.
Figure 16-1 IBM Key Management (iKeyman) window
The New key database window opens, as shown in Figure 16-2.
Figure 16-2 New key database window
3. Use the Key database type list box to click JCEKS and to enter the keystore file name and
location (Figure 16-3). You also are required to specify this file name and location in the
EKM configuration file. Click OK.
Figure 16-3 New Key database JCEKS
4. The Password Prompt window opens that is shown in Figure 16-4. Enter a password. You
specify this same password in the EKM configuration file. Click OK.
Figure 16-4 Password Prompt dialog
5. In the IBM Key Management window in Figure 16-5, click the certificate (circled) icon, or
select Create Create New Self-Signed Certificate.
Figure 16-5 Signing certificate dialog
6. Specify the following values in the Create New Self-Signed Certificate window, as shown
in Figure 16-6 on page 493:
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 16-6 Create New Self-Signed Certificate
The IBM Key Management window in Figure 16-7 on page 494 opens, showing the new
certificate.
Figure 16-7 Certificate added
7. Create a second self-signed certificate using the dialogs from Figure 16-5 on page 492
and Figure 16-6 on page 493. We created two certificates, which are shown in
Figure 16-8.
Figure 16-8 Certificates that we created
8. To import certificates that were created in another instance of iKeyman, click
Export/Import on the right (Figure 16-8 on page 494). In the Export/Import Key window in
Figure 16-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 16-9 Export/Import Key dialog
9. The Password Prompt window that is shown in Figure 16-10 opens. Enter the required
password, and click OK.
Figure 16-10 Password dialog for source key database
A list of key labels in the specified keystore displays in Figure 16-11.
Figure 16-11 Keystore label list
10.Select one or more key labels for import. In our example, we selected the first one. Click
OK.
11.The Change Labels window opens in Figure 16-12. If you want to change the key label,
select it, and then enter a new label name in the following field. Click Apply.
Figure 16-12 Change Labels dialog
12.Click OK. The IBM Key Management window opens, as shown in Figure 16-13, and
displays the two certificates that we created and the one certificate that we imported.
Figure 16-13 Keystore listing
On open systems, you can create and manipulate a JCEKS keystore with either iKeyman or
command line-entered keytool commands. On z/OS systems, only keytool commands are
available.
16.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)
Public Key Data Set (PKDS)
RETAINED
Do not use RETAINED with EKM. Refer to 16.10, Hardware cryptography on page 527 for
more information. You can use Example 16-14 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 command, go to this website:
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. Only JDK 5.0 and later support this
capability.
16.3.1 Script notes
You can 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 you
run out of space, 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 882 for more information about working in the UNIX
System Services environment.
The script in Example 16-14 demonstrates how to generate a public-private key pair using the
hwkeytool command. Here, we create an alias of rsa2048hdwrCert1 with a distinguished
name of IBM and store the certificate in the testkeys.cca keystore. We use the IBMJCE4758
provider 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 16-14 Generate a JCE4758KS public-private key pair
hwkeytool -genkey \
-alias rsa2048hdwrCert1 \
-dname "CN=IBM" \
-keystore testkeys.cca \
-provider IBMJCE4758 \
JCE4758KS: To create and use keystores of type JCE4758KS, the java.security file,
which is located in the $JAVA_HOME/lib/security/ directory, must include the JCE4758
provider in the list, similar to these providers:
-keyalg RSA \
-keysize 2048 \
-storetype JCE4758KS \
-hardwaretype PKDS
In Example 16-15, we export the certificate with an alias of rsa2048hdwrCert1 to the
rsa2048hdwrCert1.cer file. This certificate 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 is exported, but only if the specified alias is the CLEAR type.
Example 16-15 Exporting a certificate from a JCE4758KS
hwkeytool -genkey \
-alias rsa2048hdwrCert1 \
-dname "CN=IBM" \
-keyalg RSA \
-keysize 2048 \
-hardwaretype PKDS
In Example 16-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 16-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 16-17 on page 499 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 16.8, ShowPrivateTool on page 522 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 16-17 Listing a keystore with hwkeytool
hwkeytool -list \
-storetype jce4758ks
Example 16-18 shows sample output from the hwkeytool command.
Example 16-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
*******************************************
*******************************************
16.3.2 Symmetric keys in a JCECCAKS
The hwkeytool commands now support creating keys in a Cryptographic Key Data Set
(CKDS) and mapping those keys by label to a JCECCAKS. An experienced Java programmer
can use CKDS key label mapping and a JCECCAKS to use SECURE symmetric keys for
LTO4 drives. Now, in Example 16-19 on page 500, we have a hwkeytool command that is
similar to the keytool command. Here, we create a range of five symmetric keys in a
JCECCAKS keystore where the key material is stored in a CKDS. We use the TDES
algorithm, 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 EKM has the
zoscompatability = true setting.
Example 16-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
16.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 that is
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 this website:
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 16-20 generates a self-signed certificate authority certificate. You
can use the MatchKeys tool in 16.9, MatchKeys tool on page 524 to check the public-private
key pairs.
Example 16-20 Generate a CA
RACDCERT CERTAUTH GENCERT SUBJECTSDN(CN(ITSO)O(IBM)C(US))
WITHLABEL(LocalCertAuth) SIZE(1024)
The command in Example 16-21 generates an RSA key pair signed with the local certificate
authority certificate that was created with the previous command.
Example 16-21 Generate a personal certificate
RACDCERT GENCERT SUBJECTSDN(CN(ITSO) O(IBM) C(US)) WITHLABEL(RSACert1)
SIZE(1024) SIGNWITH(CERTAUTH LABEL(LocalCertAuth))
If you plan to send the certificate for third-party verification, you must export the certificate as
a certificate request. The command in Example 16-22 generates the request and stores it in
the hlq.PUBKEY.REQUEST.ITSO data set.
Example 16-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 must also add the CA that was used to sign this certificate
to the ring. The command in Example 16-23 adds the certificate response into RACF.
Example 16-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 16-24 creates a keyring named ITSOring.
Example 16-24 Create a new ring
Now that a keyring exists, we can add our certificates to it using the two commands in
Example 16-25.
Example 16-25 Connect certificates to a ring
RACDCERT CONNECT(CERTAUTH LABEL(LocalCertAuth) RING(ITSOring))
RACDCERT CONNECT(LABEL(RSACert1)RING(ITSOring) USAGE(PERSONAL) DEFAULT)
Tip: In OMVS, a single quotation mark () and a parenthesis must be prefixed with a
backslash (\). For example, the command that is listed in Example 16-20 looks like this
command:
SYS1> tso RACDCERT CERTAUTH GENCERT
SUBJECTSDN$CN\(\ITSO\$O$\IBM\$C$\US\$\)
WITHLABEL$\LocalCertAuth\$ SIZE$1024$
Important: 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 16-26.
Example 16-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 EKM at the locations of your business partners.
This approach lets everyone in the trust network verify that the keys that are used to encrypt
data are in fact part of the trust network.
Best practice
When connecting certificates to a keyring, the whole certificate chain must be connected to
the ring, which allows the certificate path to be verified.
16.5 JCE4758RACFKS and JCECCARACFKS
The JCE4758RACFKS and JCECCARACFKS SAF keyrings store certificate information in
RACF, securing private keymaterial in a PKDS that is 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
Important: 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
users private key information can never be read. When setting up EKM to run under a
specific user account, remember that you cannot read another users private key
information.
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
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
16.5.1 RACDCERT keywords
The following two keywords are used in conjunction with the RACDCERT command to take
advantage of cryptographic hardware:
ICSF
PCICC
They specify how RACF generates the key pair and how the private key is stored for future
use. If the Peripheral Component Interconnect Cryptographic Coprocessor (PCICC) is
specified, the key pair is generated using the PCI, Peripheral Component Interconnect-X
(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 Public Key Algorithm (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 16-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. You can use the MatchKeys
tool (refer to 16.9, MatchKeys tool on page 524) to check public-private key pairs.
Example 16-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:
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 16-28 on page 504) generates a self-signed CA certificate.
Example 16-28 Generate a CA
RACDCERT CERTAUTH GENCERT SUBJECTSDN(CN(ITSO)O(IBM)C(US)) PCICC
WITHLABEL(LocalCertAuth) SIZE(1024)
The command in Example 16-29 generates an RSA key pair that is signed with the local CA
certificate that was created with the previous command.
Example 16-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, you must export it as a certificate
request. The command in Example 16-30 generates the request and stores it in the data set
hlq.PUBKEY.REQUEST.ITSO.
Example 16-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 16-31 adds the certificate
response into RACF. You must also add the CA that was used to sign this certificate to the
ring.
Example 16-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 16-32 creates a keyring named ITSOring.
Example 16-32 Create a new ring
Now that there is a keyring, we can add our certificates to it using the two commands, as
Example 16-33 Connect certificates to a ring
RACDCERT CONNECT(CERTAUTH LABEL(LocalCertAuth) RING(ITSOring))
RACDCERT CONNECT(LABEL(RSACert1)RING(ITSOring) USAGE(PERSONAL) DEFAULT)
Tip: In OMVS, a single quotation mark () and a parenthesis must be prefixed with a
backslash (\). The command then looks like this command:
SYS1> tso RACDCERT CERTAUTH GENCERT
SUBJECTSDN$CN\(\ITSO\$O$\IBM\$C$\US\$\) PCICC
WITHLABEL$\LocalCertAuth\$ SIZE$1024$
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 that is shown in Example 16-34.
Example 16-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 partners EKM keystore and uses the label to encrypt tapes that the business
partner sends to you.
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 EKM at the locations of
your business partners. Everyone in the trust network can then verify that the keys that are
used to encrypt data are in fact part of the trust network.
16.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.
Important: 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.
Important: 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
users private key information can never be read. You must consider this situation when you
set up EKM to run under a specific user account.
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 the $JAVA_HOME/lib/security/java.security
directory) must contain the corresponding hardware provider:
com.ibm.crypto.hdwrCCA.provider.IBMJCECCA for a JCECCARACFKS
com.ibm.crypto.hdwrCCA.provider.IBMJCE4758 for JCE4758RACFKS
This listing is similar to the following list:
security.provider.2=com.ibm.crypto.hdwrCCA.provider.IBMJCECCA
16.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 the 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 following platforms for Java 5.0 are
supported:
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)
16.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. You can
use Java-based tools 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 this website:
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 in your environment determine the type of keystore that you have to create:
If you support only TS1120 tape drives, you can create either a JCEKS or an
IBMi5OSKeyStore keystore.
If you support only LTO4 or LTO5 tape drives, or you have one tape library that supports
LTO4, LTO5, and TS1120 tape drives, you must create a JCEKS keystore.
If you have separate tape libraries for the LTO4 or LTO5 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 or LTO5 tape drive. The two EKM servers can run on the
same system, as long as they listen on separate ports.
For details about managing a JCEKS keystore, refer to 16.2, JCEKS on page 482.
16.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 no charge 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 this website:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzaha/rzaha
jssenative15.htm
16.7.2 Setting 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 is open.
Important: IBMi5OSKeyStore does not support symmetric keys. You cannot use this
keystore to encrypt data on LTO4 or LTO5 tape drives.
Follow these steps 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, which is shown in Figure 16-14, specify
a certificate store path and filename, and click Create. This filename is also specified in
your EKM configuration file.
Figure 16-14 DCM Certificate Store Name and Password dialog
2. The Certificate Store Created window opens. See Figure 16-15 on page 509. Select a
Certificate Store menu item to access the new keystore that you have just created.
Figure 16-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.
Follow these steps to generate public-private key pairs:
1. Click Select a Certificate Store. In the Select a Certificate Store window, as shown in
Figure 16-16 on page 510, click Other System Certificate Store. Click Continue.
Figure 16-16 Select Certificate Store window
2. The Certificate Store and Password window opens, as shown in Figure 16-17. Specify the
path and file name that you entered in the create keyring/keystore instance in
Figure 16-14 on page 508. Click Continue.
Figure 16-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 16-18 shows this dialog.
Figure 16-18 Select a Certificate Authority (CA)
5. In the Create Certificate window, as shown in Figure 16-19, 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 16-19 Create Certificate
6. The Certificate Request Created window opens, as shown in Figure 16-20. Copy the
contents of the certificate request and paste the contents into the certificate request form
that is 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 16-20 Certificate Request Created
7. On the Fast Path menu, select Work with server and client certificates. The Work with
Server and Client Certificates window opens, as shown in Figure 16-21.
Figure 16-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 16-22 on page 513. Specify the name of the file into
which you copied the signed certificate. Click Continue.
Figure 16-22 Import Server or Client Certificate
9. The Work with Server and Client Certificates window opens, as shown in Figure 16-23.
Create self-signed certificate (for internal use)
You can use self-signed certificate key pairs instead of CA-signed certificates for internal use
only. Although DCM does not create self-signed certificates, it creates a local CA-signed
certificate for internal use that serves the same purpose.
Follow these steps 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 16-24 on page 514, specify a Key size of 1024 and enter the keystore
password. Fill in the required certificate information. Click Continue.
Figure 16-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 16-25 on page 515. Specify the path and filename that
you entered in the Create keyring/keystore instance window, as shown in Figure 16-14 on
page 508. Click Continue.
Figure 16-25 Certificate Store Name and Password window
3. In the Install Local CA Certificate window, as shown in Figure 16-26, click the Install
certificate link to install the CA certificate on your browser. Click Continue.
Figure 16-26 Install Local CA Certificate
4. The Certificate Authority (CA) Policy Data window opens, as shown in Figure 16-27 on
page 516. 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 16-27 Certificate Authority (CA) Policy Data window
5. The Work with Server and Client Certificates window opens, as shown in Figure 16-28,
click Create. You can also navigate to this window by using the Work with server and client
certificates option of the Fast Path menu.
6. The Select a Certificate Authority (CA) window opens, as shown in Figure 16-29 on
page 517. Select Local Certificate Authority (CA). Click Continue.
Figure 16-29 Select a Certificate of Authority (CA) window
7. In the Create Certificate window, as shown in Figure 16-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 16-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 externally encrypted
data key (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.
Follow these steps to receive the certificate:
1. From the Fast Path menu, select Work with CA certificates. When the Work with CA
Certificates window opens, click Import.
2. In the Import Certificate Authority (CA) Certificate window, as shown in Figure 16-31,
specify the fully qualified path and file name of the certificate that you want to import. Click
Continue.
Figure 16-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.
Follow these steps to export the private key and certificate:
1. On the Fast Path menu, select Work with server and client certificates. On the Work
with Server and Client Certificates window, as shown in Figure 16-32 on page 519, select
the desired certificate, and click Export.
Figure 16-32 Work with Server and Client Certificates window
2. In the Export Destination window, as shown in Figure 16-33, select File - Export to a file
to export the certificate to a file. Click Continue.
Figure 16-33 Export Destination window
3. In the Export Server or Client Certificate window, as shown in Figure 16-34 on page 520,
specify a file name to which you want to export the certificate and enter the Password.
Click Continue.
Figure 16-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.
Follow these steps to import the private key and certificate:
1. From the Fast Path menu, click Work with server and client certificates.
2. In the Work with Server and Client Certificates window, as shown in Figure 16-35, select
the desired certificate, and click Import.
Figure 16-35 Work with Server and Client Certificates window
3. The Import Server or Client Certificate window opens, as shown in Figure 16-36. Specify
the fully qualified path and file name of the certificate file to be imported. Click Continue.
Figure 16-36 Import Server or Client Certificate window
4. Specify the Password when prompted (see Figure 16-37). Click Continue.
Figure 16-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 16-38 on page 522.
Figure 16-38 Work with Server and Client Certificates window showing imported certificate
16.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 16-35 on page 523, we introduce a Java application that takes as input: a
keystore file, a keystore, the password of the keystore, and the keystore format.
The following types are your format choices:
JCEKS
JKS
JCE4758KS
JCECCAKS
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 action loads keystore database information into memory. After that step, we
simply iterate through all aliases in the keystore to determine whether each alias has private
keymaterial associated with it. If all aliases have private keymaterial associated with them, we
print all the private keymaterial.
Important: The correct providers must be in the $JAVA_HOME/lib/security/java.security
file when executing this program.
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 the
$JAVA_HOME/bin directory. After the source is compiled, a ShowPrivate.class file is created.
To run the program, execute the command:
java ShowPrivate keystore password storetype
Example 16-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;
Private keys: If you want 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.
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 16-36.
Example 16-36 Output from ShowPrivate
alias: rsakey1 Private Key=True
16.9 MatchKeys tool
The following Java application example shows that a public key and a private key loaded from
a keyring complement each other. The source in Example 16-37 on page 525 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 16-37 on page 525, 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 the
$JAVA_HOME/bin directory. After the source is compiled, a ShowPrivate.class file is created.
java ShowPrivate personalAlias keyring user ID
Example 16-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 16-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 16-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
16.10 Hardware cryptography
There are three ways to secure keymaterial using hardware cryptographic services on z/OS:
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 This method stores the private key in the actual hardware device, and the
private key 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 this website:
http://www-03.ibm.com/security/cryptocards/
Use of a cryptographic coprocessor can free processing cycles by off-loading 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, not when in storage or when in use. The following devices are cryptographic
devices:
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 Secure Hash Algorithm-1 (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
Differences: 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, message authentication code (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 manufacturers support software have been installed and function properly. Refer any
issues regarding the 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 16-39, we show you how to create a range of symmetric keys in a
hardware-based PKCS11ImplKS keystore. This example is similar to the example in 16.2,
JCEKS on page 482 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 16-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_vendors_PKCS11_interface_to_the_hardware
-providerClass com.ibm.crypto.pkcs11impl.provider.IBMPKCS11Impl
-providerArg path/filename_of_vendors_PKCS11configuration_file
This keytool invocation generates 255 sequential aliases in the range
AES000000000000000001 - AES0000000000000000FF and associated AES 256-bit symmetric
keys.
Update the symmetricKeySet property in the KeyManagerConfig.properties EKM
configuration file to add the following line to match any or all of the alias ranges just used and
the file name 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 a distributed platform, -keyalg must be AES and -keysize must be 256.
The file name that is specified in the config.keystore.file file must match the name that is
specified in the keystore <filename> in the keytool invocation:
symmetricKeySet = AES01-FF,abcfrg
config.keystore.file = <filename>.jceks
Only those keys that are 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 is displayed.
Symmetric key support: 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.
Chapter 17. Encryption Key Manager
operational considerations
In this chapter, we discuss Encryption Key Manager (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 these types:
JCEKS
JCERACFKS
JCECCARACFKS
We also include a mixed mode data sharing example, in which we describe the required steps
to share encrypted tapes with a business partner.
17
17.1 EKM commands
The following sections discuss the important sync command and other EKM commands that
are used with the EKM command-line interface.
17.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 the configuration file properties, drive table information, or
both 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, EKM is
set to perform server-only authentication. That is, the client checks its truststore to see if the
server is trusted. You can modify this behavior by changing the following line:
Changing the 0 to 1 modifies the EKM behavior to the want client auth setting, which
means that the server requests the clients 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 need client auth setting, which means that
the server requests the clients certificates. If the server does not get them or does not verify
them, it ceases SSL handshaking, and synchronization does not happen.
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 the 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.
Clarification: Make sure to change the line
(TransportListener.ssl.clientauthentication) on EKM that is acting as the server
during the sync.
Chapter 17. Encryption Key Manager operational considerations 533
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 537 for the detailed command syntax.
17.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_t
he_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 add the drives automatically. Example 17-1 shows the
adddrive command.
Example 17-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 drives certificate.
-rec2 Specifies a second alias (or key label) of the drives certificate.
Example: adddrive -drivename 000123456789 -rec1 alias1 -rec2 alias2
deletedrive
Use the deletedrive command to delete a drive from the EKM drive table. The equivalent
commands are deldrive and removedrive. Example 17-2 shows the deletedrive command.
Example 17-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 17-3 shows the exit command.
Example 17-3 The exit command
exit
export
Use the export command to export a drive table or configuration file to the specified URL.
Example 17-4 shows the export command.
Example 17-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 17-5 shows the help
command.
Example 17-5 The help command
help
import
Use the import command to import a drive table or a configuration file from a specified URL.
Example 17-6 shows the import command.
Example 17-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 17-7 shows the list command.
Example 17-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 17-8 shows the listcerts command.
Example 17-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 17-9).
Example 17-9 The listconfig command
listconfig
listdrives
Use the listdrives command to list the drives in the drive table (Example 17-10).
Example 17-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 17-11). The equivalent
command is logoff. These commands are only useful when the LoginModule is enabled.
Example 17-11 The logout command
logout
modconfig
Use the modconfig command to modify a configuration file property (Example 17-12). The
equivalent command is modifyconfig.
Example 17-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 17-13).
An equivalent command is modifydrive.
Example 17-13 The moddrive command
moddrive -drivename drivename [ -rec1 alias -rec2 alias]
-drivename Specifies the serial number of the drive.
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 17-14).
Example 17-14 The refresh command
refresh
refreshks
Use the refreshks command to refresh the keystore (Example 17-15). Use this command to
reload the keystore that is specified in the config.keystore.file file if it was modified while
the EKM server was running. Use this command only when needed, because it can degrade
performance.
Example 17-15 The refreshks command
refreshks
startekm
Use the startekm command to start the EKM server (Example 17-16).
Example 17-16 The startekm command
startekm
status
Use the status command to display whether the EKM server status is started or stopped
(Example 17-17).
Example 17-17 The status command
status
stopekm
Use the stopekm command to stop the EKM server (Example 17-18).
Example 17-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 the configuration file properties, drive table
information, or both on the EKM server that is issuing the command (Example 17-19). For
more information, refer to 17.1.1, The EKM sync command and EKM properties file on
page 532.
Example 17-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
version
Use the version command to display the version of the EKM server (Example 17-20).
Example 17-20 The version command
version
Important: If your EKM setup uses the shared hierarchical file system (HFS) function for
UNIX Systems Services and you use shared directories for debug and error logs, 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.
17.2 Backup procedures
Maintaining primary and secondary EKM servers is desirable for the maximum availability of
encrypted backup and recovery.
17.2.1 EKM file system backup
You must save 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 EKM configuration file), you must keep a copy of the password
in a secure location. The keystore password must be available to recover EKM. Encrypted
save or archive operations must not be performed on the partition or system where the EKM
server runs. If data on the system where EKM runs is encrypted, 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 EKM is backed up, the files (configuration file,
drive table, and keystore backup file) do not necessarily need to 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 EKMs 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 17-21 shows a sample job to back up a z/OS aggregate.
Example 17-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)
You can restore the zFS aggregate by using DFSMSdss logical restore. The zFS aggregate 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 17-22 on page 539 shows a
restore job.
Example 17-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
process 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 multiple file system
aggregate:
1. Unmount the file systems in the original aggregate (if any file systems 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.
We show another example of a logical restore of a zFS aggregate using DFSMSdss by
replacing the existing aggregate. 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 17-23 on page 540 is an example of a restore replace job.
Example 17-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.
17.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.
17.2.3 Keystore backup
The maintenance, backup, and restoring of key and certificate information depend on which
keyring/keystore implementation is used.The following steps represent one method:
Create copies of the keystores that EKM will use.
Retain a Public Key Cryptographic Standards 12 (PKCS#12) 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 PKCS#12 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 17.3, ICSF disaster recovery procedures
on page 542 in addition to backing up the keystore file for these types of keystores.
17.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 Programmers 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 another size from your original database or on a
another 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
IRRUT200s 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 profiles
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 separate physical blocks in the database. You can see this
situation 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 profiles 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.
Use one of the following three ways to copy an active database using this utility:
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 one of the following conditions is true:
This logon 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 that 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 that RACF begins to use 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
composed 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 to use 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.
17.3 ICSF disaster recovery procedures
This section outlines the required steps to restore IBM Integrated Cryptographic Service
Facility (ICSF) services in the event that the Cryptographic Domains have been zeroed out.
This situation can occur when performing a Disaster Recovery/Business Continuity test, in
the case of a hardware outage or upgrade, or in an actual disaster recovery.
17.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 Cryptographic Key Data Set (CKDS)/Public Key Data Set
(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 Public Key Algorithm (PKA) services and PKDS read/write access.
In a sysplex environment, this action 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 step must be done on each LPAR in the sysplex.
17.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
The following descriptions explain the naming conventions:
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.
17.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 17.3.6, Entering master keys for all LPARs in the sysplex on
page 548. Refer to your environments documentation for a list of all LPARs in the sysplex.
Assumption: This example assumes that the symmetric and asymmetric key parts are
stored as text files (.txt).
Verify which CKDS and PKDS are available for recovery
Follow these steps to verify which CKDS and PKDS are available for recovery:
1. From the main ISPF panel (Figure 17-1), enter option 3 Utilities.
Figure 17-1 ISPF Primary Options Menu panel
2. From the Utility Selection Panel, as shown in Figure 17-2, enter option 4 Dslist utility.
Figure 17-2 Utility Selection Panel
- 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
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
3. From the Data Set List Utility panel, as shown in Figure 17-3, enter the high-level qualifier
of the CKDS or PKDS, such as MYSYS.TST.TESTPLEX*.
Figure 17-3 Data Set List Utility panel
4. From the panel, as shown in Figure 17-4, verify that the correct CKDS and PKDSs exist on
this system.
Figure 17-4 DSLIST listing
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
F10=Actions F12=Cancel
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
17.3.4 Check the ICSF installation options data
Follow these steps to check the options data:
1. From the previous panel, go back one panel by pressing F3 (Figure 17-4 on page 545).
You see the panel that is shown in Figure 17-3 on page 545. Enter the high-level qualifier
of the installation options data set, and press Enter.
2. From the menu that is shown in Figure 17-5, select the installation options data set for
editing by placing an E to the left of it.
Figure 17-5 Selecting the installation options
3. In the data set (Figure 17-6), verify that the installation options data is correct for the given
system. Verify that the CKDSN and PKDSN point to the correct CKDS and PKDS.
Figure 17-6 Verifying the installation options
______________________________________________________________________________
DSLIST - Data Sets Matching SYS1.TEST.PARMLIB Row 1 of 1

-------------------------------------------------------------------------------
E SYS1.TEST.PARMLIB TSOE01

****************************** 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)

17.3.5 Disable all services
Perform these steps to disable all services:
1. Go to the Integrated Cryptographic Service Facility (ICSF) main panel.
2. From the main ICSF panel, as shown in Figure 17-7, choose option 4 ADMINCNTL. Press
Enter.
Figure 17-7 ICSF panel
3. Disable all the services by selecting each one of them with a D (for disable), as shown in
Figure 17-8.
A status message is displayed in the upper-right corner of the panel indicating whether the
services have been stopped.
Figure 17-8 ICSF Administrative Control panel
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.
i h i
------------------- 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 ********************************
4. After this change is done for each system in the sysplex, continue to the next section,
17.3.6, Entering master keys for all LPARs in the sysplex on page 548.
17.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, start with the tasks that are outlined in the following sections.
Entering SYM-MK parts
These steps must be done by master key part owners:
1. From the panel that is shown in Figure 17-8 on page 547, return to the main ICSF panel
by clicking F3. Select option 1 COPROCESSOR MGMT, as shown in Figure 17-9. Press Enter.
Figure 17-9 ICSF panel
2. Select the processors to set the master key on with the E option (for ENABLE), and press
Enter. See Figure 17-10.
Figure 17-10 ICSF Coprocessor Management panel
OPTION ===> 1
Press END to exit to the previous menu.

------------------- 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 ********************************
3. Retrieve the key or key part.
4. In the panel that is shown in Figure 17-11, 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 that 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.
Figure 17-11 ICSF Clear Master Key Entry panel
5. Go back to the beginning of this section (Entering SYM-MK parts on page 548).
6. Enter SYM-MK 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 17-12
on page 550. Press Enter.
---------------------- 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 17-12 ICSF panel: Select option 2 MASTER KEY
2. Select option 2 SET MK, and press Enter (see Figure 17-13). A message is displayed in the
upper-right corner indicating whether the set operation was successful.
Figure 17-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 17-14 on page 551. Press Enter.
OPTION ===> 2

-------------------------- 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 17-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 17-15. Press Enter.
Figure 17-15 ICSF Coprocessor Management panel
3. In the panel that is shown in Figure 17-16 on page 552, 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 that
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.
OPTION ===> 1

-------- ------------- ------
e X00 77712345 ACTIVE
e X01 77712346 ACTIVE
e X02 77712347 ACTIVE
e X03 77712348 ACTIVE
*******************************Bottom of data ********************************
Figure 17-16 ICSF Clear Master Key Entry panel
4. Go back to the beginning of this section, Entering SYM-MK parts on page 548 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 that 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 17-13 on page 550.
2. Enter option 7 ACTIVATE PKDS to activate the new PKDS. See Figure 17-17.
Figure 17-17 ICSF Master Key Management panel
COMMAND ===>
Key Type ===> ASYM-MK (SYM-MK, ASYM-MK)
Checksum ===> BD
Key Value ===> 123DE98DA620537B
===> 5ED58392E04FBDF2
===> 5739EA8926375995 (ASYM-MK only)


OPTION ===> 7
1 INIT/REFRESH CKDS - Initialize a Cryptographic Key Data Set or

3. Enter the new PKDS data set, as shown in Figure 17-18.
Figure 17-18 ICSF Activate PKA Cryptographic Key Data Set panel
17.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 17-19.
Figure 17-19 Integrated Cryptographic Service Facility: Selecting ADMINCNTL
2. Select the services that you want to enable by entering E, as shown in Figure 17-20 on
page 554. A message is displayed in the upper-right corner indicating whether the
changes were successful.
----------------- 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.

OPTION ===> 4

Figure 17-20 ICSF Administrative Control Functions panel
Key change verification
Now that the SYM-MK and the ASYM-MK have been changed on all LPARs, a sample
application or multiple applications that use keys that are protected by the SYM-MK and
ASYM-MK must be run.
17.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.
17.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 that is readable by both your
own and another organization. To take advantage of this capability, you must add that other
organizations certificate and public key to your keystore.
For LTO4 or LTO5 tape drives, the process differs. As with LTO4 or LTO5 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 partners keystore to
read the LTO4 or LTO5 media encrypted by you. The next section applies to encryption on
TS1120 tape drives only.
17.4.1 Key-sharing steps
Key-sharing is performed by adding the public part of the other organizations public-private
certificate and keys to your EKMs keystore using a second alias (or key label). When the

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 ********************************
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 organizations 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 that
is used by the other organizations EKM.
This capability gives you the flexibility to make a specific tape that is readable by both your
own and another organization. To take advantage of this capability, you must add that other
For information about sharing encrypted LTO4 or LTO5 tapes with business partners, refer to
17.4.3, Exporting a symmetric key from a JCEKS keystore on page 559 and 17.4.6,
Importing symmetric keys to a JCEKS keystore on page 563.
17.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 partners 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 16.1, Keystore and SAF
Digital Certificates (keyrings) on page 482. 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
EKM at your business partners locations. To send this certificate, export it to a data set.
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 the ExportedPublicKey.cer file using the
keytool utility:
keytool -export -file ExportedPublicKey.cer -keystore EKMKeystore -alias
MyEKMServer -storepass somesecretphrase -storetype JCEKS -provider IBMJCE
-keypass somesecretphrase
You can print the newly created certificate file by using the keytool printcert utility:
keytool -printcert -file ExportedPublicKey.cer storetype JCEK
Now, you can 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
unable to use an encoding mechanism of Public Key Hash. We explain this situation in more
Public key: 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.
detail in 17.4.4, Importing a public key and a certificate from a business partner on
page 559.
Export from JEC4758KS keystore
You can use the following commands to export the self-signed certificate and public key
labeled MyEKMServer from a JCE4758KS keystore to the ExportedPublicKey.cer file by
using the hwkeytool command:
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 might 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
unable to use an encoding mechanism of Public Key Hash. This situation is explained in more
detail in 17.4.4, Importing a public key and a certificate from a business partner on
page 559.
Export from z/OS JCERACFKS or JCE4758RACFKS/JCECCARACFKS
You have to select from one of the following techniques, depending on the type of certificate
that 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 16.1, Keystore and SAF Digital Certificates (keyrings) on page 482 for
more detail about RACF keystores.
Self-signed certificate
Perform these steps for a self-signed certificate:
1. Generate a Rivest-Shamir-Adleman (RSA) algorithm 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)
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 EKMs 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 installations 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 that are shown in
Example 17-24 on page 557.
If you are not using ICSF: Omit the PCICC keyword, and change the key size to 1024.
Example 17-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 unable to use
an encoding mechanism of Public Key Hash, which is explained in 17.4.4, Importing a
public key and a certificate from a business partner on page 559.
Certificate signed by an internal certificate authority
Follow these steps to generate a certificate that is 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)
2. The following RACDCERT command uses ICSF for private key storage, and it is signed
with the local certificate authority certificate that was generated in the previous step:
WITHLABEL(MyEKMServer) PCICC(ITOPS.EKM.CERT) SIZE(2048) SIGNWITH(CERTAUTH
LABEL(LocalRACF CA))
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 EKMs keyring. Example 17-25
shows connecting the certificate that identifies the EKM server to the EKM keyring. You
have to modify these command examples to suit your installations needs.
Example 17-25 Connecting the EKM server certificate to 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 17-24.
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 unable to use an
encoding mechanism of Public Key Hash, which is explained in 17.4.4, Importing a public
key and a certificate from a business partner on page 559.
If you are not using ICSF: Omit the PCICC keyword, and change the key size to
1024.
If you are not using ICSF: If you are not using ICSF, omit the PCICC keyword, and
change the key size to 1024.
Certificate signed by a third-party certificate authority
Perform these steps to generate a certificate that is 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:
WITHLABEL(MyEKMServer) PCICC(ITOPS.EKM.CERT) SIZE(2048)
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.
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 EKMs 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 installations needs.
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, as shown in Example 17-24 on page 557.
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 unable to use an
encoding mechanism of Public Key Hash, which is explained in more detail in the following
section.
Data set content: 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.
17.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 can 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 partners keystore, you must
use one of the business partners 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 partners public keys. If it does not, request a public key/certificate from your
business partner and import it into your keystore, as described in Importing to a JCEKS
keystore on page 560. 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 can import the
encrypted symmetric keys into your keystore using the corresponding private key.
In Example 17-26, we export the symmetric key with the alias ekm00000000000000001 from
the EKMKeys.jceks keystore to the exportsym.key file by using the public key contained in the
certificate with the alias partnercert.
Example 17-26 Exporting a symmetric key
keytool -exportseckey -alias ekm000000000000000001 -keyalias partnercert
-keystore EKMKeys.jceks -storepass passw0rd -storetype jceks
-exportfile exportsym.key
17.4.4 Importing a public key and a certificate from a business partner
We now look at examples of importing 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 partners alias of MyEKMServer.
This method 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.
Public Key Hash method: 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 17.4.2,
Exporting a public key and certificate to a business partner on page 555) 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
partners public key. Therefore, using Public Key Hash is the preferred method.
Importing 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
Importing to a JCE4758KS keystore
You can 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 can 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
Importing 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 partners alias of MyEKMServer. This method 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.
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
V1R11.0 Security Server RACF Command Language Reference, SA22-7687, for details
about the RACDCERT command.
You also have to ensure that this certificate is connected (or associated) to the EKM servers
keyring, which is accomplished using the RACDCERT command, as shown in
Example 17-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 17-27 RACDCERT command to connect the certificate with the EKM servers keyring
RACDCERT ID(EKMSERV) CONNECT(LABEL(CompanyXEKMServer) RING(EKMRing)
USAGE(CERTAUTH))
RACDCERT ID(EKMSERV) CONNECT(CERTAUTH LABEL(GENERATED CA Label FROM ADD)
RING(EKMRing))
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 17-28, to define
these profiles, which protect the use of keyring functions.
Example 17-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 that is stored in the ICSF PKDS. Also, issue refresh for the in-storage copies of
the CSFKEYS class profiles using the commands that are shown in Example 17-29.
Example 17-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
17.4.5 Tape exchange and verification
Refer to Example on page 563. Follow these steps 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 17.4.2, Exporting a public key and certificate to a business
partner on page 555 as appropriate for your keystore type.
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
Important: 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 assumes that the certificate that was added must also contain a private
key.
Note: This solution does not require that you and your business partner have the
same keystore type. Sharing public keys between separate types of keystores is
possible, if you both use TS1120 drives.
system where 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 run z/OS, you can use, for example, IEBDG
DITTO, or IEBGENER.
Your business partner follows these steps:
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 559, as appropriate for your keystore type.
b. Encrypt a tape to share with your business partner using two key labels. One of the
labels must be the public key that you imported in the earlier step from your business
partner. As 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 that 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 that is associated with that
business partner key, you cannot read the tape yourself. You must provide a second
key where you have access to the private key for this processing to complete
successfully.
Example 17-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
Public Key Hash method: The alias that you specify on import must match the
alias that was used by the business partner (MyEKMServer in the examples given in
17.4.2, Exporting a public key and certificate to a business partner on page 555) 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 partners public key. Therefore, using
Public Key Hash is the preferred method.
FD NAME=B,STARTLOC=11,LENGTH=13,PICTURE=13,'PRIMER RECORD'
CREATE QUANTITY=25,FILL='Z',NAME=(A,B)
END
/*
c. Send the tape to the business partner site that provided the public key for processing.
17.4.6 Importing symmetric keys to a JCEKS keystore
If a business partner wants to send you encrypted LTO4 or LTO5 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 partners keystore, the business partner must request a
public key/certificate from you and import it to the business partners keystore, as described in
Importing to a JCEKS keystore on page 560. When you receive the file with the exported
symmetric keys of your business partner, you can import the exported symmetric keys of your
business partner by 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 partners
public keys for export.
In Example 17-31, we import one or more symmetric keys from a importsym.key file to the
keystore EKMKeys.jceks using a private key with the alias mycert.
Example 17-31 Importing a symmetric key
keytool -importseckey -keyalias mycert -keypass passw0rd -keystore EKMKeys.jceks
-storepass passw0rd -storetype jceks -importfile importsym.key
17.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 PKCS#12 (.p12) file to other z/OS instances. The PKCS#12 file is
password-protected and contains the certificate, public and private key, and a CA certificate
that signed it.
In the PKCS#12 password-protected file, the private key is stored with compliance to
PKCS#8; the password encryption is compliant with PKCS#5.
Important: Set the z/OS Compatibility configuration property to true for EKM you
use if you plan to exchange tapes between z/OS and non-z/OS systems.
For more information about an exported PKCS#12, refer to this website:
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
PKCS#12 file. Therefore, the individual knows the private key that can then be used to
decrypt all tapes encrypted with that private keys matching public key. In this situation, the
security of the business is based on the trust of the individual exporting and transporting
PKCS#12 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 performs these functions:
Generates the private key using z/OS ICSF and hardware cryptography.
Stores the private key encrypted under the host Master Key in ICSFs 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.
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 unnecessary. This scenario
depends on utilizing the same host Master Key on System A and System B.
17.6 Audit log considerations
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.
storage. Assume 500 cylinders of space allocated to the EKMs audit and debug log file
system until you have observed based on tape and EKM activity how quickly the audit logs
environment, but it must be private to each EKM instance. This separation prevents any
possible interleaving of audit or debug logs between EKM instances.
z/OS-specific method: This method for exporting and transporting certificates is only valid
on z/OS, and this method is only valid if you use a hardware-based RACF keystore on
z/OS.
Important: To successfully export an encrypted ICSF PKDS record entry and import into
another PKDS instance using the KEYXFER utility, you must use the same ICSF hardware
Master Key between the exporting and importing z/OS images.
Create the EKM configuration file in the /&SYSNAME/etc directory and customize it accordingly
for your installation:
Audit.handler.file.directory
Modify this directory 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 requirement applies to all supported
platforms.
17.6.1 Audit overview
The audit subsystem writes textual audit records to a set of sequential files as various
auditable events occur during EKMs 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, you
must create a script or program that monitors the set of files in the configured audit
directory/folder/container. As files are closed and named based on the time stamp, you must
copy and append the files contents 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).
17.6.2 Audit log parsing tool
In Example 17-32 on page 566, we introduce a Java application that takes an audit log file as
input. The program then parses the audit log for tape key label 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. We include this parsing tool here as a
sample way that you can keep track of tapes and the key labels 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 the
$JAVA_HOME/bin directory. After the source is compiled, an AuditCrawler.class file is created.
java AuditCrawler auditlog
We include these examples in this section:
Example 17-32 on page 566 shows the application that takes an audit log file as input.
Example 17-33 on page 569 shows the format of the audit log records.
Example 17-34 on page 570 shows the output of the AuditCrawler program.
Example 17-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 17-33, we see the format of the audit log records. This content is read by the
AuditCrawler program and then subsequently parsed into an organized comma-delimited list,
as shown in Example 17-34 on page 570.
Example 17-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 17-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 information containing drive key label information are printed here.
Example 17-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 Starting EKM with JZOS as a started task on
page 423, you can set JZOS up to run as a job that is scheduled to run when a new audit
log has been created.
Chapter 18. 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 a 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.
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
18
TS7700 Virtualization Engine: This chapter does not discuss encryption on TS1120
drives when they are attached to a TS7700 Virtualization Engine. For this information, refer
to Chapter 19, Implementing TS7700 tape encryption on page 613.
18.1 Implementation overview
The implementation can include these steps:
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 assume here that the drives, libraries, and controllers have already been installed and are
operating without encryption. We describe the requirements to implement encryption on the
TS1120 tape drives.
We describe all the necessary prerequisites for hardware (microcode levels for the tape
drives, libraries, and so forth) and software for the various platforms in Chapter 10, Planning
for software and hardware to support tape drives on page 191.
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 that is 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
18.2 Implementation prerequisites
First, you must have tape drives, tape controllers, and a tape library operating without
encryption, which we review in 18.2.1, Implementing the initial tape library hardware on
page 573 and in 18.2.2, Initial z/OS software definitions on page 574.
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.
Encryption in System z requires the following prerequisites:
Encryption Key Manager (EKM) can be implemented on any supported platform.
EKM must be connected to and communicating with the operating system (z/OS in-band)
or 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 18.3, EKM implementation overview on page 575. The
complete setup steps for implementing EKM are described in Chapter 16, Planning and
managing your keys with Encryption Key Manager on page 481.
The hardware setup for tape data encryption requires these prerequisites:
Set up an encryption-capable TS1120 tape drive attached to a TS1120 Model C06
Tape Controller or a 3592-J70 tape controller.
Chapter 18. Implementing TS1100 series encryption in System z 573
Enable the encryption method for the TS1120 drives that are installed in the library.
See 18.4, Implementing the tape library on page 576. 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 system maintenance has been installed. See 18.5, Implementing
the tape control unit on page 585.
z/OS tape data encryption setup requires these prerequisites:
Install z/OS software maintenance that supports an encryption-enabled TS1120 and
TS1130. See 18.6.1, z/OS software maintenance on page 586.
Update the IECIOSxx PARMLIB member. See 18.6.2, Update PARMLIB member
IECIOSxx on page 586.
Implement z/OS basic DFSMS 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 18.6.3, Define or update Data Class definitions
on page 587.
Update the JES3 definitions. See 18.6.4, Considerations for JES3 on page 591.
Verify and update your tape management system. See 18.6.5, Tape management
system on page 592.
We describe the z/VM tape data encryption setup in 18.7, z/VM implementation steps on
page 599.
For detailed z/OS implementation checklists, refer to Appendix A, z/OS planning and
implementation checklists on page 863.
Finally, we discuss other implementation items in 18.8, Miscellaneous implementation
considerations on page 607 and TS1120 rekeying in 18.9, TS1120 and TS1130 tape
cartridge rekeying in z/OS on page 608.
Now, you are ready to start creating encrypted cartridges.
18.2.1 Implementing the initial tape library hardware
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 Tape Library with System z Attachment A Practical
Guide to Enterprise 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.
We provide an overview of the tape library implementation steps:
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 can 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
until you have installed all the software maintenance to support encryption. 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 must 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 separate platforms, whether
an IBM Virtualization solution (TS7700 or IBM 3494 Virtual Tape Server (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.
These steps set up the TS3500 tape library:
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, use these setup steps:
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 BM Virtualization Engine TS7700
Release 1.4a: 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.
18.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 Storage Management Subsystem (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, z/OS host software setup requires all or
several of the following implementation steps:
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 object access method (OAM), including installation exits.
Update and customize your tape management system.
Using the Interactive System Management Facility (ISMF) panels, define these objects:
The TS3500, 3494, or TS3400 tape library
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 use JES3, update the JES3 INISH deck.
18.3 EKM implementation overview
In a z/OS or z/VM environment, you must use System-Managed Encryption (SME), 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 15.1, Implementing EKM in z/OS on page 414, which describes
the setup steps for implementing EKM.
Follow these EKM implementation steps:
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 EKM after downloading the newest versions available.
TS3400: 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.
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 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 EKMs keystore.
18.4 Implementing the tape library
You can implement TS1120 encryption on the z/OS platform 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.
18.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 18-1 on page 577 shows the Welcome panel of the
TS3500 Specialist.
Updates: 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 use 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.
Figure 18-1 Main entry or welcome panel of TS3500 Tape System Library
Follow these steps to perform the implementation:
1. On the left side of the panel, select Manage Library. The Manage Logical Libraries panel
displays. See Figure 18-2.
Figure 18-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 that is shown in Figure 18-3 displays.
Figure 18-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.
18.4.2 Implementation steps for the IBM 3494 Tape Library
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 18-4 shows you the Welcome
panel of the Enterprise Automated Tape Specialist.
Figure 18-4 Main entry or welcome panel of the 3494 ETL
Updates: 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 service support representative (SSR) to use for enabling encryption on the
controller and all attached encryption-capable drives.
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 18-5. We do not show the left pane of the window in Figure 18-5 for better clarity.
Figure 18-5 shows a list of all encryption-capable drives in the 3494 library and how they
are currently configured.
Figure 18-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 that is shown in Figure 18-6 opens.
Figure 18-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 18-7.
Figure 18-7 Selections for Manage Encryption of the 3494 Library Manager
1. Select Commands System Management Manage Encryption to display a
Manage Encryption panel that is similar to Figure 18-8.
Figure 18-8 Manage Encryption panel
2. With the introduction of 3494 Library Manager microcode level 535, this panel contains the
line LME: Drive Encryption Settings, SME: Drive Encryption Settings, or a similar line.
Highlight that entry and click Open panel, which displays a panel that is similar to
Figure 18-9.
3. This panel lists all 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.
18.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 18-10 shows the initial System Summary panel of the IBM TS3400
Tape Library Specialist.
Figure 18-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 case here. On the left side of the panel, select Configure
Library Encryption, which displays a panel similar to the panel in Figure 18-11.
2. In this panel, under the Encryption Settings, select the encryption method of
System-Managed from the pull-down list box. For System-Managed, this selection 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.
18.5 Implementing the tape control unit
In the planning phase, you 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 the
required operating system support for TS1120 tape drives with encryption.
18.6 z/OS implementation steps
In this section, we describe the required host software implementation steps for tape data
encryption.
18.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. You must install this software maintenance before the TS1120 or
TS1130 drives are enabled for encryption. Otherwise, the encryption-enabled TS1120 drives
will not come online.
18.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 that is required to direct the I/O Supervisor
(IOS) proxy to an appropriate EKM (primary and secondary). This modification tells z/OS how
to communicate with the primary EKM and (optionally) the secondary EKM.
APAR OA22271 provides IPv6 support.
Specify the host names for the primary and secondary EKMs. For each EKM, you can specify
either a host name with an optional port or a decimal IP address with an optional port, as
shown in Example 18-1. The default for the port is normally 3801.
Example 18-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 Domain Name System (DNS) search
suffixes are automatically appended, which allows searches with shorter names.
You can change EKM settings by selecting another IECIOSxx member. Change EKM settings
by using the SET IOS=xx command dynamically.
See 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 one of the following commands:
D IOS,EKM
D IOS,EKM,VERIFY=ALL
Important: 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.
If you also specify VERIFY, you can verify the availability of the primary and secondary EKMs.
See Figure 18-12 for the results of the command.
Figure 18-12 The D IOS,EKM,VERIFY=ALL command shows both EKM TCP/IP addresses
The following command can dynamically change the settings of EKM:
SETIOS EKM
Example 18-2 shows the command details.
Example 18-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.
18.6.3 Define or update Data Class definitions
You can request tape data encryption 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).
Follow these steps:
1. You can define new Data Class constructs, or you can update the Recording Technology
parameter of existing Data Classes. Figure 18-13 shows the ISMF Data Class Alter panel
where you change the Recording Technology. In our example, we request encryption by
entering EE2.
Figure 18-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 F8 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
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. You can use L if you and the site
that will read the tape will have the same key label names for their corresponding
certificates. You must use H when the key label names might differ at the location where
the tape will be read, for example, a business partners location.
You can specify one or both key labels. If you specify only Key Label 1, Key Label 1 will be
used for both keys that are stored on the 3592 cartridge.
Figure 18-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 18-3. However, if you use JCL, you must still invoke encryption through a Data Class
specification using a Recording Technology of EE2. The following JCL parameters are on the
data definition (DD) statement, where x = 1 or 2:
KEYLABLx=
KEYENCDx=
Example 18-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 18-15 lists the keys that were
used.
Figure 18-15 MSGIEC205I indicates the key labels and key codes that were used
18.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.
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 key label 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 it will be encrypted. Therefore, writing encrypted data
to the same cartridge requires no further JCL or Data Classes. You can prepare cartridges
for encryption purposes this way by writing a small file with LABEL=(1,SL) to a cartridge.
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 that is
Example 18-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 18-5.
Example 18-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
18.6.5 Tape management system
The tape management systems typically track the recording format of a tape volume.
Encryption uses a new recording format (EEFMT2). Refer to your tape management system
provider for details about their encryption support.
18.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
Requirement: The DS QL,nnnnn can only be used for already initialized libraries.
Table 18-1 shows media names and DFSMSrmm media names. We compare the media
names that are used in DFSMS with the media names that are used in DFSMSrmm. You can
only use MEDIA5 (ETC) up to MEDIA10 (EEEWTC) for encryption on TS1120 tape drives,
because only these media names are requesting 3592 media.
Table 18-1 Media types
DFSMS media name DFSMSrmm
media name
Cartridge media Capacity without
compression
a
a. Effective capacities with compression are three times as much, assuming a 3:1 compression
ratio. Your compression ratios will vary with the data. The larger capacities are applicable for
3592 cartridges that are written in encrypted format.
MEDIA1 CST 3490 Standard 400 MB
MEDIA2 ECCST 3490 Extended 800 MB
MEDIA3 HPCT 3590 J cartridge 10, 20, or 30 GB
MEDIA4 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
MEDIA9 and MEDIA10 support: Media 9 support and Media 10 support are only
available on z/OS V1R5 and higher.
Figure 18-16 shows an RMM panel indicating an encrypted tape volume. Panel ID
EDGPT110 shows tape volume J1G151 with a recording format of EEFMT2.
Figure 18-16 Recording format EEFMT2
You can also use the mountable tape volume list option in ISMF (PANEL ID=DGTLGP31)
under Recording Technology to determine if a volume is encrypted. EEFMT2 is the indication
for encryption. See Figure 18-17.
Figure 18-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 18-6 shows the response to an RMM LV command.
Example 18-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 =
Example 18-6 on page 595 uses two key labels:
Key label with method LABEL
Key label with method HASH
18.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 that are 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.
Note: For tape management systems other than DFSMSrmm, contact your vendor.
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,
and MEDIA10. Any use of MEDIA1 through MEDIA4 produces an IDC3226I error
message that displays 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 that is 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 that are 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 that is associated with the RECORDING
parameter for VOLUME entries, as shown in Example 18-7.
Example 18-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.
18.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
installations 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.
18.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 installations 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.
If your dump classes are currently defined to use host-based encryption (and possibly
host-based compression before encryption), 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.
Hardware Security Module (HSM): Although software (or host-based) encryption
supports only dump data, all HSM functions are supported with hardware encryption.
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 several but not all of the associated Data Classes request tape
hardware encryption, all dump copies fail. Tape hardware encryption can override
host-based encryption for all dump classes that are 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.
18.7 z/VM implementation steps
z/VM provided support for encryption in the TS1120 or TS1130 tape drive (3592-E05) with
z/VM Version 5. z/VM can enable encryption on behalf of guests that are not capable of
enabling encryption on their own. Guests that understand encryption, for example, z/OS, do
not have to do anything special in z/VM for encryption.
Note the following information about z/VM versions and releases:
z/VM V5 releases 1 and 2 require the program temporary fix (PTF) for APAR VM64063.
These releases provide support for default keys only. Encryption is enabled with ATTACH
or SET RDEVice commands. Encryption can also be enabled with the z/VM DASD Dump
Restore (DDR) utility, but it utilizes its own unique externals to run in the absence of an
underlying z/VM system, that is, stand-alone dump or restore.
z/VM V5 Release 3 provided encryption support at the general availability (GA) level.
This release expanded the encryption support to allow any key label that is defined to
EKM to be used when encrypting for guests. A key label represents a public-private key
where the public key is used for encryption and the private key is used for decryption. In
addition to the key label, z/VM also requires the key encoding mechanism operand to
identify how to use the key label in the encryption of the data key. z/VM combines the two
components (key label and key encoding mechanism) to form a key alias that is used by
the ATTACH and SET RDEVice commands.
1. Ensure that the necessary z/VM software levels are installed to support encryption.
2. Verify that EKM has been implemented and that the key labels are stored in its keystore.
3. Set up tape drives for System-Managed Encryption using tape library panels. We discuss
this setup in 18.7.1, Tape library and tape control unit implementation on page 600.
4. Set up the tape control units for encryption by having your IBM SSR install FC9595 (Plant)
or FC5595 (Field) on the 3592 Model J70 Tape Control Unit or the TS1120 Model C06
Tape Control Unit.
5. Set up the tape control units for out-of-band encryption by using the web interfaces of the
TS3500, 3494, or TS3400 library to set the EKM TCP/IP addresses. We describe this
setup in 18.7.2, Out-of-band encryption on page 600.
6. Define the key aliases to z/VM.
7. Use the ATTACH, DETACH, and SET RDEVice commands to control tape encryption.
18.7.1 Tape library and tape control unit implementation
Like z/OS, you must enable the TS1120 and TS1130 drives for System-Managed Encryption
and configure the tape control units for encryption. We describe these steps in 18.4,
Implementing the tape library on page 576 and in 18.5, Implementing the tape control unit
on page 585. We do not repeat the steps here.
18.7.2 Out-of-band encryption
Out-of-band encryption is required when the operating system does not have the necessary
support to act as a proxy of EKM. This requirement is primarily for the operating systems:
z/VM, z/VSE, and z/TPF. Out-of-band encryption uses the tape control unit as a proxy for
communication with EKM. In these cases, the 3592 Model J70 or the TS1120 Model C06
Tape Controller must be updated with the TCP/IP addresses of EKM. Use the Library
Manager interface if the drives are attached to a TS3500, 3494, or TS3400 tape library.
If the drives are in a C20 silo frame or are rack-mounted, you must order FC9595 (Plant) or
FC5595 for each of the tape control units that will use out-of-band encryption. In this case, the
IBM SSR is shipped instructions for setting up encryption in the tape control unit.
The implementation steps that are described in this section are the same for TS3500, 3953,
and 3494 tape libraries and only necessary in case of out-of-band encryption. We will discuss
the procedures for out-of-band encryption on the TS3400 tape library later in this section.
Implementing out-of-band encryption on the TS3500 and 3494
We show the panels of the Library Manager (LM) to enable the libraries for out-of-band
encryption:
1. From the Library Manager console, select Commands System management
Manage Encryption. See Figure 18-18 on page 601.
Important: You can only perform the following steps at the Library Manager (LM) panels.
These definitions are only necessary for out-of-band encryption.
Figure 18-18 3494/3953 navigation for out-of-band encryption
The 3494/3953 Manage Encryption list box displays with the next Library Manager panel,
as shown in Figure 18-19.
Figure 18-19 3494/3953 Manage Encryption selection list box
2. Select the Control Unit Encryption Information row and click Open panel.
3. In the next panel (Figure 18-20), you insert the definitions for the control units.
Figure 18-20 3494/3953 Control Unit Encryption Information entry panel
4. The Control Unit Encryption Information panel is available for every control unit, or you can
use it for all the control units in a tape library. You can specify up to two key managers for
each control unit: one key manager for the primary EKM and, optionally, one key manager
for a secondary EKM.
If you specify a domain name, you must insert a Network Services (NS) IP address. Obtain
the information about this IP address from the networking department. The IP addresses
or domain names that you use must match the definitions of EKM. Refer to 15.1.8, Virtual
IP Addressing on page 429 for additional information.
After setting the values in the panel, click Modify this CU only, or click Modify ALL CUs
to set the same EKM addresses for all control units in the library.
Implementing out-of-band encryption on the TS3400
We show the panels of the TS3400 Library Specialist that are used to enable the control units
for out-of-band encryption. To update the EKM server addresses, use the web browser
interface of the TS3400. You must log in as an administrator. Although the Java Security
warning message is displayed, you only click Run to start the specialist. Figure 18-21 on
page 603 shows the initial System Summary panel of the TS3400 Tape Library Specialist.
Figure 18-21 Main entry or welcome panel of the TS3400 Tape Library Specialist
1. On the left side of the panel, select Configure Library Encryption, which displays a
panel similar to the panel that is shown in Figure 18-22.
Figure 18-22 EKM Server Settings panel
2. In this panel, under EKM Server Settings, enter the EKM IP address and the EKM port
number for the Primary EKM and (optionally) for the Secondary EKM. Then, click Submit.
Usually, the port number is 3801, but it might differ if this port number has a conflict within
your network. The IP address can be an IPv4 address or an IPv6 address, depending on
which network settings you have set up. You must perform this procedure on each TS3400
library that is attached to the tape control unit.
18.7.3 Defining key aliases to z/VM
z/VM maintains a list of key aliases, which are defined with the SET KEYALIAS command,
that represent the EKMs key labels to be used by z/VM. Each key alias is up to 32 characters
long (including spaces) and contains the key label, as well as a key mode of how that key
label will be used to create an externally encrypted data key (EEDK). You can use a key label
directly (LABEL) or hashed (HASH) when creating the EEDKs. Using HASH might be more
convenient if the recipient of the encrypted cartridge has a separate key label string defined to
represent the matching keys. Using LABEL might be more convenient for internal data where
the site that writes and the site that reads use the same key labels.
You can recall this information with the QUERY KEYALIAS command for either a single alias
or for the entire list of known aliases.
The SET KEYALIAS and QUERY KEYALIAS commands use the following formats:
SET KEYAlias aliasname {Label} KEYLabel keylabel
{Hash }
Query KEYAlias {ALL}
{aliasname}
Example 18-8 shows how to use the commands.
Example 18-8 SET KEYALIAS and QUERY KEYALIAS
set keyalias cow label keylabel moo moo moo
set keyalias duck hash keylabel quack quack
set keya old macdonald label keyl Had a Farm
q keyalias
KEYALIAS: (L) COW
= MOO MOO MOO
KEYALIAS: (H) DUCK
= QUACK QUACK
KEYALIAS: (L) OLD MACDONALD
= HAD A FARM
q keya old macdonald
Important: The information that is provided is only to be used in conjunction with guest
operating systems that are not able to enable the hardware encryption environment
themselves. Attempts to combine them are likely to create hardware problems, such as
missing interrupts.
Important: You must set up KEYALIASs for all key label and key mode combinations that
you plan to use. The ATTACH and SET RDEVice commands use these KEYALIASs later.
KEYALIAS: (L) OLD MACDONALD
= HAD A FARM
18.7.4 Using ATTACH and DETACH to control encryption
When dedicating a tape to a guest, you can specify the key aliases on the ATTACH command
to select the key labels to use when creating the EEDKs. If an alias is not recognized, an error
displays, and the ATTACH command fails. If no key aliases are specified, a set of default key
labels, which are defined in EKM, are used to create the EEDKs.
At the time of the ATTACH, the tape drive must be either unloaded or at beginning-of-tape in
order to establish the encryption environment. Thus, a tape cartridge is guaranteed to have a
consistent set of data that is either completely encrypted with a unique set of EEDKs or
completely unencrypted. Attempts to ATTACH a tape drive with encryption settings that do not
meet these criteria will fail with an error message.
Guest operating systems that use the z/VM facilities to enable encryption can use the
MULTIUSER option on ATTACH. However, all guests using the shared tape device must use
the same encryption settings to provide a consistent environment for enabling the encryption.
The encryption settings specified on an ATTACH persist until the drive is detached and
unloaded. If a DETACH is issued with the LEAVE option, the encryption settings remain in
place along with the mounted cartridge. This situation allows a subsequent ATTACH to be
issued without any encryption settings, but it also allows the encryption environment to be
passed to a new target user. In the case of the ATTACH of shared tape, the encryption
settings persist until all instances are detached, and the device is marked as free again.
We show the format of the ATTACH command. Example 18-9 also shows the ATTACH
command. We only the ATTACH parameters that are related to encryption here:
For z/VM V5.1 or V5.2:
ATTach [NOQIOAssist] [KEY]
For z/VM V5.3 and later:
ATTach [NOQIOAssist] [KEY keyalias1 keyalias2]
Example 18-9 ATTACH examples
att 181 * key
TAPE 0181 ATTACHED TO JOECOOL 0181
det 181
TAPE 0181 DETACHED
att 181 * multi key cow duck
TAPE 0181 ATTACHED TO JOECOOL 0181
att 181 * multi key cow pig
HCPATR1128E Device 0181 not attached; a mismatch in hardware encryption settings
was detected.
18.7.5 Using SET RDEVICE to control encryption
You can use the SET RDEVICE FEATURE command (set rdev feature) to enable the
encryption environment without making changes to the ATTACH command. As with ATTACH,
you must issue this command when the drive is unloaded or at beginning-of-tape, but you
also must issue this command before it is dedicated to a guest. This command permits the
encryption environment to be enabled through the use of library or tape managers that issue
a regular, unmodified, ATTACH command. You can specify up to two key aliases for each SET
RDEVICE FEATURE command. If no key aliases are specified, the EKMs default keys are
used.
Use either format of the SET RDEVICE FEATURE command:
SET RDEVICE rdev FEATURE KEY [keyalias1] [keyalias2]
NOKEY
SET RDEVICE rdev1-rdev2 FEATURE KEY [keyalias1] [keyalias2]
NOKEY
Refer to the samples in Example 18-10. We only show the SET RDEVICE FEATURE
parameters that are related to encryption.
Example 18-10 SET RDEVICE FEATURE
set rdev 7e2 feature key
HCPZRP6722I Characteristics of device 07E2 were set as requested.
1 RDEV(s) specified; 1 RDEV(s) changed; 0 RDEV(s) created
set rdev 7e2 feature key cow duck
HCPZRP6722I Characteristics of device 07E2 were set as requested.
1 RDEV(s) specified; 1 RDEV(s) changed; 0 RDEV(s) created
18.7.6 QUERY responses
There is new information available with various QUERY responses that provide
encryption-related information to the issuer. This new information includes the Class B
QUERY TAPES DETAILS <rdev> and the Class G QUERY VIRTUAL TAPES and QUERY
VIRTUAL <rdev> DETAILS commands.
All three variations include text that indicates which drives are capable of encryption. The two
commands with DETAILS options provide additional information regarding the key labels in
use on the tape device. If any encryption settings were defined with the SET RDEVICE
FEATURE command, those settings are displayed under the heading INACTIVE KEY
LABELS. After an ATTACH command is issued, those same settings reside under the
heading ACTIVE KEY LABELS if ATTACH was performed unmodified. Otherwise, the active
heading contains the encryption information that is specified on the ATTACH command. If
either heading indicates DEFAULT, the default keys defined in EKM are used.
Example 18-11 Variations of QUERY output
q v tapes
TAPE 0181 ON DEV 07E2 3590 R/W SUBCHANNEL = 0008 ENCRYPTION CAPABLE
Ready; T=0.01/0.01 16:42:02
q v 181 details
TAPE 0181 ON DEV 07E2 3590 R/W SUBCHANNEL = 0008 ENCRYPTION CAPABLE
ACTIVE KEY LABEL(S):
(H) the first mighty key label
(L) the second mighty key label
INACTIVE KEY LABEL(S): DEFAULT
q tapes details 7e2
TAPE 07E2 SEQUENCE NUMBER E0010 LIBPORT 1 ENCRYPTION CAPABLE
ACTIVE KEY LABEL(S):
INACTIVE KEY LABEL(S): DEFAULT
q tapes details 7e3
TAPE 07E2 SEQUENCE NUMBER E0010 LIBPORT 1 ENCRYPTION CAPABLE
INACTIVE KEY LABEL(S):
18.7.7 z/VM DASD Dump Restore (DDR)
The z/VM DASD Dump Restore (DDR) utility also supports tape data encryption for TS1120
and TS1130 drives, but it utilizes its own unique externals to run in the absence of an
underlying z/VM system. The Input/Output control statement includes a new option, KEY, that
will cause the output device to be enabled for device encryption. This option is only valid on
the output statement, because it has no meaning on an input device. A new HASH/LABEL
control statement has been added to define the encoding mechanism used on the tape.
These statements (up to two can be specified) determine what key labels to use for
encrypting the tape and how they will be used (as a label or as a hash of the public key).
These control statements are optional, and if not included, the default keys in EKM are used
for encryption. Example 18-12 dumps all data from the volume labeled SYSRES onto the
tape mounted on unit 181 and the data is encrypted using key e3rw33rssesyqypsftqqpx0539.
Example 18-12 specifies only one key label.
Example 18-12 DDR control statements
input 191 3390 sysres
label1 e3rw33rssesyqypsftqqpx0539
output 181 3592 (key
dump all
18.8 Miscellaneous implementation considerations
This section provides additional hints and tips for tape data encryption in a z/OS environment.
18.8.1 Data exchange with other data centers or business partners
To share tapes with data centers, other organizations, or contracting services, or for other
purposes, EKM can store two sets of wrapped encryption keys on the tape. This capability
allows another organization to read that specific tape without your providing to them any
shared secret information or compromising the security of your certificates and keys. This
sharing occurs by adding the public part of the other organizations public-private certificate
and keys to your EKMs keystore as a second alias (or key label).
When the tape is written, the encryption keys are stored on the tape in multiple places and
protected by two sets of public-private keys, your set and the other organizations set. The
other organization is then able to use its EKM and its public-private certificate and private key
to unwrap the data key, which allows it to read that specific tape. This capability gives you the
flexibility to make a specific tape that is readable by both your own organization and another
organization. If you want to take advantage of this capability, you must add that other
If you want to send an encrypted tape cartridge to another data center for data access, you
must use two key labels with the second key label using an encoding method of HASH. This
method enables you to use a key label that differs from the receiving organizations key label
for the same key.
18.8.2 Availability
When keystores are lost or damaged, you cannot decrypt the encrypted data on tapes.
Therefore, it is absolutely necessary to back up the keystore data sets.
If you use hardware-based keystores and another data center uses the backup keystore data
sets data, the same hardware equipment has to be available (IBM Integrated Cryptographic
Service Facility (ICSF)), plus hardware facilities.
If a hardware-based keystore is not used, these backup keystores are protected, for example,
by RACF profiles. Later, they can be restored or used at another data center. We recommend
that you use utilities from RACF for backup purposes, for example, IRRUT400 to create
snapshots of the database either for the primary or backup database with parameter
NOLOCKINPUT. The output of this utility can be SMS-managed, which means that the output
can be stored or copied using normal backup programs and utilities, such as DFSMSdssm,
DFSMShsm, and other programs and utilities.
18.9 TS1120 and TS1130 tape cartridge rekeying in z/OS
Rekeying is the process of changing the encrypted data keys on the TS1120 and TS1130
cartridge so that only the new keys can be used to read the data on the cartridge. You might
want to use rekeying in these situations:
The existing keys have been compromised, and you want to prevent access to this
cartridge with the compromised keys.
You want to send this same cartridge to another department or business partner that can
only understand keys that differ from those keys that currently exist on the cartridge.
Rekeying does not require that all the data is read back in and then rewritten using a separate
set of keys. It is a much quicker process than having to copy the data.
This section describes the IEHINITT changes in support of the TS1120 Model E05 and
TS1130 Model E06 rekeying capability, which is available on z/OS V1R6 and later; refer to
APAR OA20076.
18.9.1 TS1120 Model E05 rekeying support in z/OS
When the TS1120 Model E05 encryption support was first delivered, as part of that solution,
the drive supported a function that is referred to as rekeying. At that time, support for this
function was not available in z/OS and was targeted as a post-general availability (GA) item.
This section describes the support that was added in z/OS to enable the rekeying capability in
the drive.
When a tape cartridge is encrypted, the data key that is used to encrypt the data is also
encrypted, or wrapped, using the public key from a public-private key encrypting key (KEK)
pair. This method creates an externally encrypted data key (EEDK) that is stored on the tape
cartridge in non-user data areas of the tape. The private key of that public-private key pair is
then used to decrypt the data key.
When the first file sequence on a tape is written and encryption is requested, you can specify
up to two key labels, enabling the cartridges data key (DK) to be encrypted or wrapped with
two separate public keys. This method generates an EEDK for each of the key labels
specified. You can use one of the key labels for local (on-site) usage, and you can use the
second key label for export (off-site) purposes. Allowing two key labels to be specified works
well if it is known ahead of time what the usage of the tape will be, but what if the volume has
to be exported, at a later date, using a separate public key or the existing keys have been
compromised? A mechanism is provided in the drive and the Encryption Key Manager (EKM)
that enables a cartridges data key (DK) to be re-encrypted with new key encrypting keys
(using new key labels). This mechanism enables a tape cartridge to be rekeyed without
having to copy the data to another volume. You accomplish this rekeying through the drive
and the external key manager (EKM) by decrypting one of the existing EEDKs stored on tape
to get the data key, re-encrypting it with separate KEKs to create new EEDKs, and overwriting
the existing EEDKs with the new EEDKs.
18.9.2 IEHINITT enhancements
The tape encryption rekeying support in z/OS is provided as an extension of the existing
IEHINITT (tape initialization) utility. The rekey (REKEY) support takes as input a volume serial
number and its new key labels and encoding mechanism. You can specify two key labels;
however, it requires that at least one key label is specified. You can specify the same value for
both key labels. If only one key label is specified, the same value is used for the other key
label. The new key labels can be the same key labels that were used to generate the existing
EEDK structures on the tape. No checking is performed to determine whether the new key
labels are the same key labels that were originally used.
When NUMBTAPE is specified, the volume serial number of the first volume is specified and
is increased by one for each additional volume (maximum serial number is 999999). The
serial number specified must be all numeric.
As with the existing INITT function, the new REKEY function uses as input a control data set
that contains the utility control statements and produces on output a data set that contains
this content:
Utility program identification
New key label information for each tape volume that is successfully rekeyed
Message codes and error messages
Example 18-13 shows the sample output of an IEHINITT REKEY operation.
Example 18-13 Sample IEHINITT output
SYSTEM SUPPORT UTILITIES IEHINITT
LABEL REKEY SER=001000,KEYLABL1=First_Key_Label,KEYENCD1=L,
KEYLABL2=Second_Key_Label,KEYENCD2=H,NUMBTAPE=2
001000 KEYLABL1=First_Key_Label KEYENCD1=L
KEYLABL2=Second_Key_Label KEYENCD2=H

001001 KEYLABL1=First_Key_Label KEYENCD1=L
KEYLABL2=Second_Key_Label KEYENCD2=H
The new REKEY control statement uses the following syntax:
ddname REKEY SER=VOLSER
[,DISP=[rewind|unload}]
[,NUMBTAPE={n|1}}]
[,KEYLABL1=keylabel1 (64-char)]
[,KEYENCD1={L|H}] (L=Label;H=Hash)
[,KEYLABL2=keylabel2 (64-char)]
[,KEYENCD2={L|H}] (L=Label;H=Hash)
Note that all other INITT-related keywords are invalid. The new fields are in bold type.
The new REKEY control statement uses these parameters:
SER=VOLSER
The SER keyword can be specified in two forms:
SER=VOLSER Specifies the volume serial number of one volume.
SER=VOLSER,NUMBTAPE=n When NUMBTAPE is specified, SER is the volume
serial number of the first volume and is increased by
one for each additional volume (maximum serial
number is 999999). The specified serial number
must be all numeric.
KEYLABL1=keylabel1_name
KEYLABEL1 specifies the first key label for the key encryption key that is used by EKM. A
key label is from 1 to 64 characters with blanks padding the field on the right. A key label
contains alphanumeric, national (special symbols used in specific languages), or special
characters with certain additional characters also allowed. Enclose it in single quotation
marks if it contains any blanks or special characters. IEHINITT does not validate the
character set that is specified for the key label keyword.
At least one key label and its encoding mechanism are required for REKEY. When you
specify this operand, you must also specify a value for the key encoding mechanism using
the KEYENCD1.
Note that if only one key label and its associated encoding mechanism are specified, the
same key label and mechanism values will be used for both key labels and mechanisms.
KEYENCD1={L|H}
Specifies the encoding mechanism of the first key label KEYLABL1. The encoding
mechanism indicates how the label for the key encrypting key specified by the key label is
to be encoded by EKM and stored on the tape:
L Label, which is encoded as the specified label
H Hash, which is encoded as a hash of the public key referenced by the specified key
label
KEYLABL2=keylabel2_name
Specifies the second key label for the key encryption key used by EKM. A key label is from
1 to 64 characters with blanks padding the field on the right. A key label contains
alphanumeric, national, or special characters with certain additional characters also
allowed. Enclose the key label in single quotation marks if it contains any blanks or special
characters. IEHINITT does not validate the character set that is specified for the key label
keyword.
At least one key label and its associated encoding mechanism are required for REKEY.
When you specify this operand, you must also specify a value for the key encoding
mechanism using the KEYENCD2. Note that if only one key label and its associated
encoding mechanism are specified, the same key label and mechanism values will be
used for both key labels and mechanisms.
KEYENCD2={L|H}
Specifies the encoding mechanism of the second key label KEYLABL2. The encoding
mechanism indicates how the label for the key encrypting key specified by the key label is
to be encoded by EKM and stored on the tape:
L Label, which is encoded as the specified label
H Hash, which is encoded as a hash of the public key referenced by the specified key
label
NUMBTAPE={n|1}
Specifies the number of tapes to be rekeyed. The value n represents a number from 1 to
255. If more than one tape is specified, the volume serial number of the first tape must be
all numeric.
Example 1: REKEY one tape volume
Example 18-14 shows one tape volume, SL1000, to be rekeyed with two key labels specified.
Example 18-14 Rekey one tape volume
//TAPEJOB JOB
//STEP1 EXEC PGM=IEHINITT
//SYSPRINT DD SYSOUT=A
//REKEY1 DD UNIT=(TAPE,1,DEFER)
//SYSIN DD *
REKEY1 REKEY SER=SL1000,
KEYLABL1=firstkeylabel,KEYENCD1=L,
KEYLABL2=secondkeylabel,KEYENCD2=H
/*
Example 2: Multiple REKEY control statements
Example 18-15 shows two tape volumes, SL8000 and SL8001, to be rekeyed. Each tape
volume is to be rekeyed with a separate set of key labels and encoding mechanisms.
Example 18-15 Multiple REKEY control statements
//TAPEJOB JOB
//STEP1 EXEC PGM=IEHINITT
//SYSPRINT DD SYSOUT=A
//SYSIN DD *
KEYLABL1=firstkeylabel,KEYENCD1=L,
KEYLABL2=secondkeylabel,KEYENCD2=H
KEYLABL1=differentfirstkeylabel,KEYENCD1=L,
KEYLABL2=differentsecondkeylabel,KEYENCD2=H
/*
18.9.3 Security considerations
For rekeying, the following security considerations apply:
IEHINITT currently provides volume-level security checking using System Authorization
Facility/ Resource Access Control Facility (RACF), but it does not invoke data set-level
checking. If you do not use SAF/RACF TAPEVOL profiles, extra precautions might be
required when using IEHINITT for the REKEY function.
For the REKEY function, SAF/RACF will be invoked for authorization checking in both
library and non-library environments. The level of authority that is required to proceed with
the rekeying processing is UPDATE for CLASS=TAPEVOL.
The rekey utility issues a RACROUTE call after the mounted tape volume label is read.
The VOLSER that was read or from the sense bytes is passed to the RACROUTE call. If
the tape does not have a VOLSER (NL tape), the requested VOLSER will be used as an
internal VOLSER in all SAF/RACF checking. UPDATE access to the volume is required to
rekey the volume, or the volume must not be protected; not protected means that either
there is no TAPEVOL profile or the TAPEVOL class is not active.
The following available levels of authority are in hierarchical order:
READ
UPDATE
CONTROL
ALTER
If a user has UPDATE authority, and ATTR=READ is specified, RACF returns a return
code of 0 (zero). If ATTR=CONTROL, RACF returns a return code of 8.
18.9.4 Packaging
Support for the new tape enhancements is available on z/OS V1R6 and higher. TS1120 tape
data encryption Rekeying function was generally available on 31 August 2007 (refer to APAR
OA20076).
18.9.5 Rekeying exits and messages
Appendix F, IEHINITT exits and messages for rekeying on page 943 includes detailed about
the new IEHINITT Dynamic Exits Facility that is provided with the Rekeying support and
information about the new and modified IEH messages.
Chapter 19. Implementing TS7700 tape
encryption
The TS7700 Virtualization Engine implements tape encryption for the physical back-end tape
drives through storage pools. You can use up to 32 storage pools. Each storage pool can hold
non-encrypted cartridges, or it can hold encrypted cartridges, which were encrypted with the
same or separate keys.
19
19.1 TS7700 encryption overview
TS7700 tape encryption uses System-Managed Encryption (SME). DFSMS constructs are
assigned by automatic class selection (ACS) routines by selecting a storage group and
management class for the logical volume. Then, the TS7700 has matching constructs that
determine the storage pool where the logical volume will reside and then whether physical
volumes in that storage pool will be encrypted.
Figure 19-1 graphically illustrates the connections between the DFSMS constructs and the
TS7700 constructs. TS7700 encryption is implemented outboard within the storage pools of
the TS7700, but it is indirectly controlled within DFSMS by your selection of the storage group
and the management class for the data.
Figure 19-1 Invoking encryption in the TS7700
In this chapter, we describe the implementation steps in z/OS that are required to encrypt part
or all of the physical stacked TS1120 volumes that are used by the TS7700 Virtualization
Engine. These implementation steps might include the new installation of these products:
IBM TS3500 Tape Library or IBM 3494 Tape Library
IBM TS7700 Virtualization Engine
IBM TS1120 tape drives
Or, the installation might only include firmware upgrades of the existing tape libraries, tape
drives, and TS7700, along with the installation of the required software support.
We describe the following topics:
Prerequisites
Tape library implementation and setup
Software implementation tasks in z/OS
SMS implementation steps
TS7700 implementation and setup
We describe all necessary prerequisites for hardware (microcode levels for the tape drives,
the tape libraries, and the TS7700) and software for the various operating systems in
Chapter 10, Planning for software and hardware to support tape drives on page 191.
Selected DFSMS
Storage Group
Selected DFSMS
Management Class
Matching TS7700
Storage Group
Matching TS7700
Management Class
TS7700 Primary
Storage Pool Number
TS7700 Duplex
Storage Pool Number
Chapter 19. Implementing TS7700 tape encryption 615
19.2 Prerequisites
The following prerequisites are for back-end tape drive encryption within the TS7700:
An encryption-capable TS1120 drive that has been enabled for encryption with the SME
method
A TS7700 at microcode levels that support encryption and with feature code (FC) 9900
installed
A 3953 or 3494 Library Manager at microcode level 534.31 or later
An Encryption Key Manager (EKM) running, available, and communicating with the
TS7700
Available DFSMS storage group and management class constructs that will be used to
enable encryption policies at the TS7700
Matching storage groups and management classes in the TS7700 that select TS7700
storage pools that will be encrypted
TS7700 storage pool definitions that specify encryption and the key labels to use
19.2.1 Tape drives
Because data encryption is performed on the tape drives, TS1120 Model E05
encryption-capable tape drives must be attached to the TS7700. They also must be running
in native (E05) mode rather than J1A emulation mode. All TS1120 tape drives with FC5592
or FC9592 are encryption capable. These drives must also be enabled for SME before they
can be used for encryption with the TS7700.
19.2.2 TS7700 Virtualization Engine
The TS7700 must run microcode level 8.2.0.19 or later (8.2.0.27 or later if the drives are in a
3494 library). You must have FC9900 installed to access the encryption settings.
You must not configure the TS7700 to force the TS1120 drives into J1A mode. Only your IBM
service support representative (SSR) can change this setting. If you have to update the
microcode level, be sure that the SSR checks and changes this setting, if required.
19.2.3 Library Manager
The 3953 Library Manager for the TS3500 or the 3494 Library Manager requires microcode
19.2.4 Encryption Key Manager
You must install and configure your Your Encryption Key Managers (EKMs), and they must be
operational before installing the encryption feature on the TS7700. You must also create the
Key Encrypting Key (KEK) certificates that you plan to use for encrypting your backstore tape
cartridges.
Refer to the IBM System Storage Tape Enterprise Key Manager, Introduction Planning and
User Guide, GA76-0418-08, for full details about installing and configuring your EKMs. Also,
we describe planning for and implementing EKM in other chapters within this book.
19.3 Implementation overview
We divide the implementation steps to implement the tape library and the TS7700
Virtualization Engine and then to enable and use tape data encryption within the TS7700 into
four parts:
Implementation of the tape library and TS1120 tape drives
We provide an overview of the initial library implementation steps in 19.3.1, Implementing
the initial tape library hardware on page 616.
Implementation of the TS7700 Virtualization Engine
We provide an overview of the initial TS7700 implementation steps in 19.3.2,
Implementing the initial TS7700 on page 616.
Encryption Key Manager implementation
We provide an overview of the EKM implementation steps in z/OS in 19.3.4, EKM
implementation overview on page 617. We describe the complete setup steps for
implementing EKM in z/OS in 15.1, Implementing EKM in z/OS on page 414.
Setup of tape data encryption in the hardware and software
We provide the steps to set up tape data encryption in the library in 19.4, Tape library
implementation and setup for encryption on page 617.
We describe the z/OS software-related implementation steps in 19.5, Software
implementation steps on page 623 and 19.5.3, z/OS DFSMS implementation steps on
page 623.
Finally, we describe the TS7700 implementation steps in 19.6, TS7700 implementation
steps on page 624.
19.3.1 Implementing the initial tape library hardware
A prerequisite for the TS7700 Virtualization Engine is either an IBM TS3500 Tape Library or
an IBM 3494 Tape Library. If you do not have either of these IBM system-managed tape
libraries installed already, we refer you to these IBM Redbooks publications for a detailed
description of all implementation and migration steps for these tape libraries:
For TS3500:
For IBM 3494:
19.3.2 Implementing the initial TS7700
If you do not have an IBM TS7700 installed already, refer to IBM Virtualization Engine
TS7700: Tape Virtualization for System z Servers, SG24-7312, which has a detailed
description of all implementation and migration steps for the TS7700. In this publication, we
describe only the additional steps that are necessary to implement encryption on TS7700.
HCD: The Hardware Configuration Definition (HCD) is the same for the TS7700, whether
you use encryption or not.
19.3.3 Initial z/OS software definitions
For a brief overview of the z/OS software tasks for implementing an IBM tape library and an
IBM Virtualization solution (TS7700 or IBM 3494 B10 or B20 Virtual Tape Server (VTS)), refer
to 19.5, Software implementation steps on page 623. For detailed information about the
basic software setup steps, refer to IBM Virtualization Engine TS7700: Tape Virtualization for
System z Servers, SG24-7312.
19.3.4 EKM implementation overview
In a z/OS environment, you must use SME. Before you will be able to encrypt any tape within
the TS7700, you must implement the EKM software on a platform. We expect that most z/OS
clients will implement at least one instance of EKM on the z/OS platform; however, your
requirements might involve EKM implementations on other platforms.
We describe the complete setup steps for implementing EKM on each platform in Chapter 15,
Implementing the Encryption Key Manager on page 413.
The following steps give a brief overview of the EKM implementation steps in z/OS:
1. 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 EKM component.
2. Install EKM after downloading the newest versions available.
3. Obtain the required security permissions for the UNIX System Services segment.
4. Create a keystore for EKM.
5. Set up the EKM environment in Java.
6. Start EKM.
7. Set up EKM at the TS7700.
19.4 Tape library implementation and setup for encryption
The TS1120 tape drives that are to be used by the TS7700 for encryption must be encryption
capable, as well as encryption enabled. All TS1120 tape drives with FC5592 or FC9592 are
encryption capable. The drives also must be running in native (E05) mode rather than J1A
emulation mode.
If you have 3592 Model J1A drives attached to the TS7700, they must be detached. The
TS7700 does not allow the usage of a mixture of drive types. You can redeploy the J1A drives
in other subsystems or use them as direct-attached drives for open systems hosts. If you
have a mixture of J1A and TS1120 drives attached to your TS7700 and cannot detach the
J1A drives immediately, you can proceed, as long as you have a minimum of four
encryption-capable TS1120 drives attached. Be aware, though, that the J1A drives will not be
used by the TS7700 after the TS1120 drives are put into native E05 mode.
Enabling the TS1120 drives for encryption is handled differently depending on whether the
drives are installed in an IBM TS3500 Tape Library or in an IBM 3494 Tape Library. We
describe both tape libraries in the following sections.
19.4.1 Enabling drives for encryption in the IBM TS3500 Tape Library
If the TS1120 drives are installed or will be installed in an IBM TS3500 Tape Library, the
TS3500 Tape Library Specialist has the ability to enable the TS1120 drives for encryption. To
update the tape drive definitions, use the web browser interface of the TS3500, the TS3500
Tape Library Specialist. To begin this procedure, have the World Wide Node Names
(WWNNs) for the drives that will be attached to this TS7700. You can get these names from
the Enterprise Automated Library Specialist by selecting Monitor library manager
Physical Device Location, which displays the physical location of the drives and their
ownership.
Figure 19-2 shows the Welcome panel of the TS3500 Specialist.
Figure 19-2 Entry or welcome panel of TS3500 Tape Library
Important: Your TS7700 must be offline during the remainder of this procedure.
Follow these steps to enable encryption on the TS1120 drives that will be attached to the
TS7700:
1. On the left side of the panel, select Library Logical Libraries, which leads you to the
next panel called Manage Logical Libraries, which is shown in Figure 19-3.
Figure 19-3 Manage Logical Libraries panel
2. Check the logical library that is connected to the 3953 Library Manager and the TS7700.
Then, choose Select Action Modify Encryption Method, and then click Go. This step
assumes that you have already assigned the TS1120 drives to this logical library.
3. The panel shown in Figure 19-4 displays.
Figure 19-4 Panel to mark tape drives used for encryption
4. In this panel, select the Encryption Method System-Managed. Next, check all of the
encryption-capable drives to be used by the TS7700, and click Apply. If the drives that you
want to use with the TS7700 do not show Yes in the Encryption Capable column,
encryption enablement is not set and you must determine why they are not encryption
capable.
5. Review the panel that contains the following message, and then click OK:
Once the encryption change is complete, the associated host application(s)
require a reset or rediscovery of the devices. Do you want to continue with the
encryption change?
Click OK to continue.
6. Review the panel that has the following message, and then click Close:
Drive Encryption change request has completed.
You have enabled the drives for System-Managed Encryption.
19.4.2 Enabling drives for encryption in the IBM 3494 Tape Library
Prior to licensed internal code level 535, if the encryption-capable TS1120 drives are installed
or will be installed in a 3494 tape library, you must order Encryption Configuration FC9596
(plant-installed) or FC5596 (field-installed and chargeable) on the TS1120 drives to enable
the encryption method on the drives. This feature code provides the instructions and
procedures for the SSR to enable the TS120 drives for encryption and to specify the
encryption mode. The drives must be configured by the IBM SSR for the System-Managed
Encryption method.
With the introduction of the 535 licensed internal code level on the 3494 tape library, you now
have the capability to enable encryption on the TS1120 drives through the ETL Web
Specialist or user interface of the 3494 Library Manager Console. The ETL Specialist is
similar to the procedures that were just described for the TS3500, except that there is only
one logical library on the 3494. We describe the procedures for the 3494 User Interface in
detail next.
Enabling Encryption for the TS1120 drives using the 3494 User Interface
Note that as of the writing of this publication, the capabilities in licensed internal code level
535 were still being developed, so the panels shown here might differ form the panels that are
delivered, but they will be quite similar.
Only perform this procedure when the TS7700 is offline:
1. On the main 3494 Library Manager panel, select Commands System management
Manage encryption, as shown in Figure 19-5.
Figure 19-5 3494 User Interface main panel
This selection displays the Manage Encryption panel, as shown in Figure 19-6.
Figure 19-6 Manage Encryption panel
2. Highlight the row LME: Drive Encryption Settings (or SME: Drive Encryption Settings
if present), and then, click Open panel.
This step displays the Drive Encryption Settings (Set VPD) panel shown in Figure 19-7.
Figure 19-7 Drive Encryption Settings (Set VPD)
3. Highlight all drives to be used by the TS7700 (or click Select All), click System Managed,
and then, click Set VPD. This action enables System-Managed Encryption on all of these
drives, a prerequisite for the TS7700 to be able to use encryption.
19.4.3 Encryption-enabled drives
19.5 Software implementation steps
In this section, we describe the host software implementation steps that are required for
TS7700 Tape Encryption.
19.5.1 z/OS software maintenance
As of the writing of this publication, there was no known z/OS software maintenance to
support encryption in the TS7700 Virtualization Engine, because the implementation of
encryption within the TS7700 is handled in these ways:
Implemented outboard within the TS7700 microcode using Outboard Policy Management
Invoked with existing DFSMS storage group and management class constructs
19.5.2 Encryption Key Manager installation
EKM requires a separate software installation. We describe the complete setup steps for
implementing EKM on z/OS or other platforms in Chapter 15, Implementing the Encryption
Key Manager on page 413.
19.5.3 z/OS DFSMS implementation steps
The DFSMS Data Class specifications control encryption for native TS1120 drives.
Encryption on the TS7700 is not controlled by DFSMS Data Class specifications. Instead,
encryption is controlled on a TS7700 storage pool basis by using storage group and
management class DFSMS constructs. Storage group and management class DFSMS
constructs (specified for logical tape volumes) determine, through mapping in the Library
Manager, which storage pools are used for the primary copies and secondary copies (if used)
of the logical volumes. The TS7700 storage pools, originally created for management of
physical media, have been enhanced to include encryption characteristics.
You might want to set up additional storage group and management class constructs in
DFSMS. For detailed information about setting DFSMS policy constructs, refer to the DFSMS
Object Access Method Planning, Installation, and Storage Administration Guide for Tape
Libraries, SC35-0427.
We describe the setup of storage groups and management classes for DFSMS in the
following sections.
Important: When the TS7700 uses drives for encrypted physical tape volumes, it will put
drives (that are not properly enabled for encryption) offline to the subsystem. Inform the
tape library operators that they must leave TS7700-attached drives in SME mode at all
times so that the drives are not taken offline.
Setting up a storage group in DFSMS
You can use ISMF to define your storage groups by selecting option 6, Storage Group, from
the ISMF Primary Option Menu for storage administrators:
1. In the Storage Group Name field, specify the name of the storage group that you are
defining.
2. In the Storage Group Type field, specify TAPE.
3. Select 2 to Define a new Storage Group.
The only other fields that have to be entered on the Tape Storage Group Define panel are the
library names. You can specify up to eight library names. The library names must be the
names of TS7700 Virtualization Engine libraries.
The tape storage groups that are defined in DFSMS must have identically named storage
groups that are defined in the TS7700s referenced in the library names. Refer to 19.6,
TS7700 implementation steps on page 624 for setting up the storage groups in your
TS7700.
Setting up a management class in DFSMS
You can use ISMF to define your management classes by selecting option 3, Management
Class, from the ISMF Primary Option Menu for storage administrators:
1. In the Management Class Name field, specify the name of the management class that you
are defining.
2. Select 3 to define a new management class.
You do not have to define any of the management class attributes when the management
class is to be used only for virtual tape.
The management classes that are defined in DFSMS that are to be used for the TS7700 must
have identically named management classes that are defined in the TS7700s. Refer to the
next section for setting up the management classes in your TS7700.
19.6 TS7700 implementation steps
In this section, we assume that you have already set up your TS7700 without encryption. If
you do not have an IBM TS7700 installed already, refer to the following publication for a
detailed description of all TS7700 implementation and migration steps without encryption,
SG24-7312.
In this publication, we only describe the additional steps that are necessary to implement
encryption on the TS7700.
19.6.1 Configuring the TS7700 for encryption
Configuring the TS7700 to support encryption requires the following steps:
1. Define storage groups (matching your DFSMS storage group names) that specify the
storage pool to be used for the primary copy of the logical volume.
2. Define management classes (matching your DFSMS management classes) that specify
the storage pool to be used for the backup (duplex) copy of the logical volume.
3. Activate the encryption feature license.
4. Set up the EKM TCP/IP addresses.
5. Define whether encryption for a storage pool will be enabled. If the storage pool is
enabled, define the key labels and the key modes to use.
We describe these steps in detail in the following sections. The procedures use the TS7700
Management Interface (MI) and the Enterprise Automated Tape Library Specialist (ETL) or
the Library Manager User Interface (UI). You can perform most of the tasks either with the
ETL Specialist or the Library Manager panels (UI). In general, we recommend using the ETL
Specialist, because it is a more user friendly web interface. For all these procedures, you start
by choosing the TS7700 cluster to modify. In our examples, we use Administer VTS 1. The
procedures are similar for the IBM TS3500 Tape Library and for the IBM 3494 Tape Library.
For details about using the Library Manager panels, refer to these books:
IBM TotalStorage 3953 Tape Frame Model F05 and Library Manager Model L05 Operator
Guide, GA32-0473
IBM TotalStorage 3494 Tape Library Operator Guide, GA32-0449
The panel that is shown in Figure 19-8 shows the Welcome Page for the Enterprise
Automated Tape Library Specialist (ETL).
Figure 19-8 Manage constructs with the ETL Specialist
Note that all ETL Specialist panels that allow the modifications of definitions require that you
enter a user ID and password that have the proper authority.
19.6.2 Creating TS7700 storage groups
On the z/OS host, the storage group construct determines into which tape library a logical
volume is written. Within the TS7700, the storage group construct allows you to define the
storage pool to which you want the logical volume written. Multiple storage groups can be
associated with any given storage pool.
Remember, this storage group name must match a storage group name that is defined in
DFSMS. You can define up to 256 storage groups (including the default).
Even before you define the first TS7700 storage group, there is always at least one storage
group present: the default storage group that is identified by eight dashes (--------).
Although the default storage group cannot be deleted, you can modify it, for example, to point
to another default storage pool.
To define a new storage group, or modify or delete an existing storage group, select
Administer VTS n Manage constructs Storage groups. Figure 19-9 shows the
Storage Groups definition panel of the ETL Specialist.
Figure 19-9 Manage Storage Groups with the ETL Specialist
Follow these steps to create a storage group:
1. Enter a 1 - 8 character alphanumeric name in the Name field. This name must be unique
within the storage group construct names. Use your host-defined DFSMS storage group
name.
2. Enter the number of the pool that you want to use for this storage group in the Primary
Pool field. You can choose from any of the 32 storage pools, but you cannot enter 0 for the
Common Scratch Pool. The default Primary Pool is Pool 1.
Storage groups: If you assign a storage group at the host to a logical volume and if this
storage group has not been defined on the Library Manager before, this storage group will
be created on the Library Manager using the specifications of the default storage group.
3. Optionally, enter a short description in the Description field.
4. Click Add/Modify.
Follow these steps to modify a storage group:
1. Select from the current storage groups that are presented in the list box. Use the mouse or
keyboard to highlight the storage group that you want to modify.
2. Modify the primary pool and description.
The History Table at the bottom of the ETL Specialist panel that is shown in Figure 19-9 on
page 626 has several purposes:
Indicate actions that are currently in progress or have already completed.
Coordinate remote users (3953 Specialist and Library Manager Console operator).
Notify the current user if another user has performed the same kind of action while the
current user is preparing to perform the same or a similar action.
19.6.3 Creating TS7700 management classes
You can define, through the management class, whether you want to have a dual copy of a
logical volume within the same TS7700. In a Grid configuration, you will most likely choose to
copy logical volumes over to the other TS7700 instead of creating a second copy in the same
TS7700. In a single cluster configuration, however, you might want to protect against media
failures by using the dual copy capability.
If you want to have dual copies of selected logical volumes, you must use at least two storage
pools, because the copies cannot be written to the same storage pool as the original logical
volumes. The management class determines the storage pool for the second copy. You can
define up to 256 management classes (including the default).
A default management class is always available, which is identified by eight dashes
(--------) and cannot be deleted. If you assign a management class at the host to a logical
volume, and if this management class has not been defined on the Library Manager before, it
will be created on the Library Manager using the specifications of the default management
class.
To define a new management class, or modify or delete an existing management class, select
Administer VTS n Manage constructs Management classes. Figure 19-10 on
page 628 shows the Management Classes panel of the ETL Specialist.
Tips:
In an environment with multiple pools in use, we suggest not to assign a storage group
to Pool 1. If you then encounter physical cartridges and logical volumes in Pool 1, you
have an indication that your storage group definitions on the host and on the Library
Manager might not match.
The TS7700 can use up to 32 storage pools. However, keep the number of storage
pools used to the minimum necessary to meet your requirements. Excessive storage
pools in use can affect the performance on the TS7700, because cartridges from the
various pools might have to be mounted and demounted more often to write data to the
pools. Storage pools that are defined, but not used, do not affect performance.
Figure 19-10 Management Classes panel
Perform these steps to add a management class:
1. Enter a 1 - 8 character name in the Name field. This name must be unique in the
management class construct names.
2. Specify the number of a pool in the Secondary Pool field. Select one of these choices:
Specify the secondary pool number (1 - 32). This number determines in which physical
pool the dual copy of the logical volumes will reside.
If 00 is selected, no secondary copy will be made.
3. Enter a short description in the Description field.
Perform these steps to modify a management class:
1. Select a management class from the current management classes that are presented in
the list box. Use the mouse or keyboard to highlight the management class that you want
to modify. You can modify pools and description.
Perform these steps to delete a management class:
1. Select a class from the current management classes that are presented in the list box.
Use the mouse or keyboard to highlight the management class that you want to delete.
2. Click Delete, and then confirm that you wanted to delete this management class.
Important: The settings for PTP Copy Control and PTP I/O VTS only apply for IBM
TotalStorage Peer-to-Peer Virtual Tape Servers (PtP VTS).
For implementation of an IBM TS7700 Virtualization Engine, leave the VTC defined
defaults in those fields.
19.6.4 Activate the TS7700 Encryption Feature License
Both this section and the following sections require that you invoke the TS7700 Management
Interface (MI). Click Manage Virtualization Engine n near the bottom of the left panel to
invoke MI. Alternatively, you can just enter the TCP/IP address of the TS7700 Console
interface to go directly to the MI. A panel similar to Figure 19-11 opens.
Figure 19-11 TS7700 Virtualization Engine Grid Summary
Follow these steps to set up the TS7700 Cluster for Encryption:
1. Select Configuration Feature Licenses. This option displays a panel similar to the
panel that is shown in Figure 19-12 on page 630.
Figure 19-12 TS7700 Feature Licenses
2. Figure 19-12 lists the currently activated feature licenses. Perform either task:
If Feature Code 9900 is listed here, the TS7700 has already been enabled for
Encryption and you can proceed to the next section.
If Feature Code 9900 is not listed here:
i. Choose Select Action Activate New Feature License, and then click Go. A
panel similar to Figure 19-13 opens.
Figure 19-13 Activating a TS7700 Feature License
ii. When you ordered FC9900 for 3957-V06, you were supposed to receive
instructions and a license key for the feature. Enter that 32-character Feature Code
license key in the boxes on the panel in Figure 19-13 on page 630, and then, click
Activate to enable the TS7700 for Encryption.
iii. At the Confirm Feature Activation panel, click Yes.
19.6.5 EKM addresses
To set the TCP/IP addresses of EKM, select Configuration Encryption Key Manager
Addresses to bring up a panel similar to Figure 19-14.
Figure 19-14 Encryption Key Manager Addresses
Enter the information that you obtained from your EKM or network administrator, and then,
click Submit Changes.
Your network or EKM administrator can provide you with the two EKM TCP/IP addresses or
domain names.
The standard (and default) EKM port is 3801, but your EKM administrator might have
selected a separate port number for the EKM configuration file because of possible conflicts
on the system on which EKM runs.
The secondary key manager address on the panel is optional. However, always set up and
configure for two EKMs. To maintain continuous access to your data, it is critical to take
advantage of all possible redundancies in the subsystem.
Domain Name Server (DNS) addresses are only required if you specify a symbolic domain
name for one of the EKMs rather than a numeric IP address. If you have to specify a DNS, be
sure to specify both a primary and an alternate DNS server so that you do not lose access to
your EKM because of one of the DNS servers being down or inaccessible.
If you are sharing keys (KEKs) across separate EKMs, be sure to import the necessary
certificates into their corresponding keystores. Do not create separate certificates with the
same key labels.
19.6.6 Testing EKM connectivity
Follow these steps to test EKM connectivity:
1. Click Launch Library Manager (located in the lower-left corner of the panel in
Figure 19-14 on page 631).
2. Click Monitor Library Manager.
3. Select Operator Interventions.
4. Verify that no EKM-related operator interventions are listed. If you did not configure a
secondary EKM, disregard any interventions pertaining to the secondary EKM.
If no EKM-related interventions are listed, the EKM setup was successful.
If EKM-related interventions are listed:
i. Verify the IP address of your EKM with your network personnel.
ii. Verify the EKM port number with the EKM administrator.
iii. Refer to the EKM Reported Errors section of the IBM System Storage Tape
Enterprise Key Manager, Introduction Planning and User Guide, GA76-0418.
19.6.7 Configuring pool encryption settings for the TS7700
You can set many properties for a TS7700 physical stacked volume pool. IBM Virtualization
Engine TS7700: Tape Virtualization for System z Servers, SG24-7312, describes the
properties in detail. Here, we only describe the encryption properties that can be defined for a
pool.
Be sure to define all key labels in the keystores that are associated with your EKMs before
they will be used by the system. The safest way to ensure that key labels are defined in the
keystores is to set up the certificates in the keystores before entering the key labels on this
panel. Refer to Chapter 15, Implementing the Encryption Key Manager on page 413 for
details about this process.
The key modes are also entered here. Refer to Chapter 15, Implementing the Encryption Key
Manager on page 413 for descriptions of the key modes.
To set up pools for encryption, click Configuration Pool Encryption Settings. If you have
met the prerequisites for encryption on the TS7700, you see a list of 32 Physical Stacked
Volume Pools, as shown in Figure 19-15 on page 633. This panel determines whether
encryption is to be enabled or disabled for a storage pool. If encryption is enabled, you can
specify one or two key labels and their key modes.
If storage pools are not displayed, the TS7700 has not met the prerequisites for tape data
encryption. You probably have not activated the Encryption Feature License.
Figure 19-15 TS7700 Pool Encryption Settings
Figure 19-15 displays the current status of all the Physical Stacked Volume Pools. Under the
Encryption column, a pool is either Enabled or Disabled for encryption. If you are just
beginning this process, all the pools are in a Disabled status. If a pool is Enabled, it has one
or two Key Labels/Key Mode pairs listed.
In Figure 19-15, to enable encryption for a pool, check the pool or pools that you want to
change, or click Select All for all pools. Next, choose Select Action Modify Encryption,
and then Go. The panel that is shown in Figure 19-16 opens.
Figure 19-16 Physical Stacked Volume Pool Encryption Settings
Click Enable, and then, enter the Key Mode and Key Label information to use for this pool.
You can specify one or two sets. You can either use the add new key label selection from the
Key Label n drop-down list and enter the new key label in the box beneath it, or select a
previously added key label from the drop-down list. When you have specified the fields, click
OK to update the selected pools encryption settings.
19.7 Implementation considerations
In this section, we summarize additional implementation considerations.
19.7.1 Management construct definitions and transfer
Because the TS7700 Virtualization Engines of a Multi Cluster Grid configuration are
managed by separate Library Managers, you have to define the constructs on both Library
Managers, or you can transfer the definitions from one Library Manager to the other Library
Manager. Refer to IBM Virtualization Engine TS7700: Tape Virtualization for System z
Servers, SG24-7312, for the procedures for copying your constructs to another cluster.
19.7.2 Changing storage pool encryption settings
You can change storage pool encryption settings at any time. Remember that these settings
are applied only when the physical volume is written from beginning of tape. As a result, there
might be a mix of encryption usage and key use on physical volumes in a given storage pool
until volumes are reclaimed and reused.
Figure 19-17 shows settings of physical volumes in a storage pool over time. In the beginning,
encryption is not enabled for the storage pool, so all physical volumes are unencrypted.
Encryption is then enabled for the pool using key label KEK 1. As unencrypted physical
volumes are rewritten from the beginning of tape, they will be encrypted using that key label.
Figure 19-17 Encryption settings changed over time

TIME
unencrypted KEK 2 KEK 2 KEK 2 KEK 1
KEK 2 KEK 2 KEK 2 KEK 2
unencrypted
unencrypted unencrypted
unencrypted
unencrypted unencrypted
Set up Encryption
Change Keys
When the pool is reconfigured to use key label KEK 2 instead of KEK 1, physical tapes exist
that are still encrypted with the old key label. The certificate must be maintained in the EKMs
long enough for all the volumes to be rewritten with the new KEK 2 key label.
The transition from unencrypted tapes to encrypted, as well as from one set of KEKs to
another set of KEKs, occurs naturally at the pace that the tapes are reused by the TS7700. In
the meantime, the physical volumes in the storage pool can be a mix of unencrypted tapes
and encrypted tapes with various KEKs.
You can monitor the progress of the migration of data from unencrypted media to encrypted
media by using a new storage pool for encryption rather than by modifying the current pool.
Then, use the Tape Library Specialist Search Database function to see the remaining volumes
in the old unencrypting storage pool.
19.7.3 Moving data to encrypted storage pools
This section describes several of the available methods for expediting movement of data onto
encrypted tapes. All of the methods begin with the same configuration changes:
Change the storage pool associated with a storage group construct to a new (empty) pool
with encryption enabled.
Change the properties of the old storage pool to specify the new encryption-enabled
storage pool as its reclaim pool.
Change the properties of the old storage pool to specify that borrowed volumes are to be
returned to the scratch pool.
After this change is made, all new data that is associated with the storage group will migrate
to encrypted media, old data recalled to cache will migrate to encrypted media, and other old
data will migrate to encrypted media, as tapes are reclaimed. You can accelerate the
migration by using one or more of the following methods.
If the dual copy function is used, change the secondary pools in a similar manner.
Recall data method
After the previously described changes have been made, old data is automatically migrated
as it is accessed (recalled). To force this process to occur with selected logical volumes, you
can run a job that causes them to be recalled. When they are subsequently unloaded and
demounted, the TS7700 will see that the pool that is now associated with the volumes differs
from the pool that was used the last time that they were copied from the cache, and the
TS7700 will copy the volumes to the new pool. This method, combined with directing all new
allocations as just described, is probably sufficient if the time period allowed for migration is
long enough so that most of the old data has expired or been recalled as part of normal job
processing. This process leaves a relatively small amount of data to migrate by forcing a
recall. If there are a large number of volumes to migrate, the effort to set up the host jobs to
force the recalls becomes cumbersome and cache space will be taken up by the recalled
volumes.
Note that if there are a large number of volumes to migrate and this method is desired, the
efficiency for recalling the data from tape can be improved by using a map of the logical
volumes on them. Rather than randomly recalling the logical volumes, the map can be used
Tip: If a migration to new media is planned for the same time frame as encryption
implementation, the new storage pool can be set up for both the new media type and the
encryption attributes, and both migrations can be combined into one.
to structure the recall job so that the volumes are requested in the order that they are located
on the tape. The Bulk Volume Information Retrieval (BVIR) function can provide the physical
volume to logical volume mapping information. Refer to the 3494 Bulk Volume Information
Retrieval Function Users Guide white paper for details about how to use the function. The
paper is available at this website:
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP100430
Move logical volumes method
With this method, the valid logical volumes on one or more physical volumes are moved to a
target pool that has encryption specified. This move is accomplished by using the move
stacked volume function of the library. Through that function, the logical volumes resident on
a range of stacked volumes are moved to a target pool immediately or as each stacked
volume becomes eligible for reclaim. This method is a better alternative than the force recall
method to move a small number of logical volumes. The TS7700 manages the migration
internally, and no host jobs have to be run. Data is moved from tape to tape so no cache
space is required.
Reclamation processing method
This method uses reclamation policies to affect how quickly the old data is moved to
encrypted volumes because of reclamation.
Reclamation policies
The following policies are supported:
Reclaim percentage threshold
A physical volume is eligible for reclaim when the amount of active data on the volume falls
under the defined threshold for the pool. A value of 5 - 95% can be specified for this field.
This policy is the default policy.
Days since last accessed
A physical volume is eligible for reclaim when the number of days defined in the days
without access field has elapsed since any data on the volume has been accessed
because of a recall. You can specify a value of 1 - 365 days as a criteria for reclaim. A
value of 0 (zero) disables this criteria for reclaim.
Days since last written
A physical volume is eligible for reclaim when the number of days defined in the age of last
data written field has elapsed since any data was written to the volume. You can specify a
value of 1 - 365 days as a criteria for reclaim. A value of 0 (zero) disables this criteria for
reclaim.
Days since last data inactivation
A physical volume is eligible for reclaim when the number of days defined in the days
without data inactivation field has elapsed since any data was invalidated on the volume
and the amount of active data on the volume falls under the threshold that is defined in the
maximum active data field. You can specify a value from 1 - 365 days as a criteria for
reclaim. A value of 0 (zero) disables this criteria for reclaim. You can specify a value of
5 - 95% for the maximum active data field.
Pool assignment: If a logical volume is in cache at the time that its primary pool
assignment is changed, the pool assignment will not affect where the data will be copied
until the volume is subsequently unloaded and demounted. It is during the rewind/unload
command processing time that the primary pool destination for a logical volume is
determined.
When reclamation is allowed, the TS7700 examines the physical volumes that have been
filled and takes into account all the policies that are specified for a pool independently when
determining the physical volumes in the pool that are eligible for reclamation. Each pool can
have a separate set of reclamation policies. During reclamation processing, the TS7700 will
prefer eligible physical volumes that have the least amount of active data to move,
considering all pools. Although a pool might have volumes that meet one or more of the
reclamation policies for that pool, if another pool has physical volumes with less active data to
move, it will get preference during reclaim. Physical volumes that have not yet been filled are
not considered for reclamation.
Cleanup
After all the previously full volumes in a pool have been migrated (and assuming you
redefined the pool to return scratch volumes), a few physical volumes will be left in the pool.
Those volumes are the volumes that were partially filled when the migration began and are
not considered for reclamation. You will have to use the move stacked volume method to
complete the migration of the data from the pool.
After you have completed the migration, you can redefine old storage pools for other uses.
19.7.4 EKM operation
The TS7700 tries to maintain TCP/IP connections with all configured EKMs at all times. When
contact is lost with a configured EKM, an operator intervention is raised at the Library
Manager (LM). This operator intervention is displayed on the user interface and web panels
for the LM. In addition, hosts are notified of the degraded mode that is displayed on z/OS host
consoles. When contact is regained, the intervention is cleared, and the hosts are notified.
Operators have to be trained to recognize and respond to EKM communications loss,
because loss of the second EKM will cause a temporary loss of access to encrypted data.
The TS7700 will always perform key exchanges with the primary EKM when it can. If EKMs
differ in host or network performance or reliability, the best choice must be specified as the
primary EKM.
If no communications with EKMs are established when a key exchange is required, or if
contact with EKMs is lost during the exchange, a call-home communication is generated to
alert IBM service of the problem. Loss of communications with both EKMs will prevent you
Note: The maximum active data field is only used in conjunction with the days since last
data inactivation policy. It is independent of the reclaim percentage threshold field.
A portion of the data on a physical volume is invalidated when the logical volume that it
represents has been modified and rewritten or deleted (as part of the delete expired
volume data function). The remaining data on the physical volume is considered active
data.
Reclamation workload: The reclamation workload for a VTS will increase while the
migration of old data is taking place. The effect of that increased workload must be
monitored. If it affects production use of the VTS, the inhibit reclamation policy setting for
the TS7700 must be used to minimize that effect during peak production demand times.
If the dual copy function is used, you must set up the reclamation policies for both the
primary and secondary pools.
from accessing encrypted data. This situation is treated as a serious issue, even though the
problem might be with the network or the host on which the EKMs are installed rather than the
TS7700 Virtualization Engine.
19.7.5 Tracking encryption usage
If new storage pools are configured for use with encryption, database queries and statistics
records give an indication of the amount of data being encrypted on the system.
You can then use the Library Manager specialist or User Interface panels to query tape
volumes in the encryption storage pools. This function is most useful when you configure the
pools to borrow and return tapes from the common scratch pool.
You can also use the TS7700 statistics records to gather information regarding the storage
pools that are used for encrypted data.
Messages for the host console are sent when a tape has been filled and a database backup
has been written to it. For unencrypted tapes, the following message is displayed:
Database Backup written to Physical Tape XXXXXX
For encrypted tapes, this message is displayed:
Database Backup written to Encrypted Physical Tape XXXXXX.
19.7.6 Data exchange with other data centers or business partners
To share tapes with data centers, other organizations, or contracting services, or for other
purposes, EKM can store two sets of wrapped encryption keys on the tape. This approach
allows another organization to read that specific tape without your providing to them any
shared secret information or compromising the security of your certificates and keys. This
approach is accomplished by adding the public part of the other organizations public-private
certificate and keys to your EKMs keystore as a second alias (or key label). When the tape is
written, the encryption keys are stored on the tape in multiple places and protected by two
sets of public-private keys: your public-private keys and the other organizations public-private
keys. The other organization is then able to use its EKM and its public-private certificate and
private key to unwrap the data key that allows the other organization to read that specific tape.
This method 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 organizations certificate and public key to your keystore.
If you want to send an encrypted tape cartridge to another data center for data access, two
key labels have to be used, with the second key label using an encoding method of HASH.
This method enables you to use a key label that differs from the receiving organizations key
label for the same key.
19.8 TS7700 encryption with z/VM, z/VSE, or z/TPF
Encryption within the TS7700 is supported when z/VM, z/VSE, or z/TPF is attached to the
TS7700. It is supported totally with the Outboard Policy Management capability within the
TS7700. These operating systems will not be able to dynamically assign the storage group
and management class constructs, because they do not have the capability to pass these
constructs to the TS7700.
However, you can implement a static assignment of storage group and management class
within the TS7700 to control encryption. All the TS7700 implementation steps that have been
described earlier in this chapter (except for the DFMSM storage group and management
class constructs) must still be implemented for encryption with these operating systems. Also,
you can perform one additional step at the TS7700 that allows a static assignment of TS7700
storage group and management class to logical volume ranges within the TS7700.
Perform these steps to implement Outboard Policy Management for these operating systems
when they are attached to a TS7700:
1. Define your storage pools and constructs, as described earlier in this chapter.
2. Insert the logical volumes (to be used by these operating systems) in groups through the
TS7700 Management Interface. Refer to IBM System Storage TS7700 Virtualization
Engine: Tape Virtualization for System z Servers, SG24-7312, for this procedure.
3. Go to the 3953 Library Manager or the 3494 Library Manager and assign the required
static construct name to these logical volume ranges through the Manage Logical
Volumes function. Define groups of logical volumes with the same construct names
assigned. Then, during insert processing, direct them to separate LM volume categories
so that all volumes in one LM volume category will have identical constructs assigned.
Managed Logical Volumes procedure
From the ETL Specialist, select Manage Logical Volumes from the Administer VTS n work
items, which displays the panel that is shown in Figure 19-18.
Figure 19-18 Manage Logical Volumes panel
Perform these steps to set up for encryption:
1. Enter the VOLSER ranges in the From and To boxes.
2. Click Change.
3. Enter or select the Storage Group, Management Class, Storage Class, and Data Class to
be used for this VOLSER range.
4. Click Submit.
Repeat this process as necessary for other VOLSER ranges. Only the storage group and
management class are required to invoke encryption, but you probably want to specify the
other constructs, also. For encryption, the storage group and management class selected
must point to a storage pool where encryption is specified.
Chapter 20. Implementing TS1120 and
TS1130 encryption in an open
systems environment
This chapter provides detailed information for the installation and implementation of
encryption in both the AIX and Windows environments using the IBM System Storage
TS3500 Tape Library and the IBM System Storage TS1120 Tape Drive and the IBM System
Storage TS1130 Tape Drive.
Implementation checklist
Implementing System-Managed Encryption (SME)
Implementing Library-Managed Encryption (LME)
Implementing Application-Managed Encryption (AME)
20
20.1 Encryption overview in an open systems environment
The three methods to implement encryption in the open systems environment are
Library-Managed Encryption (LME), System-Managed Encryption (SME), and
Application-Managed Encryption (AME). Using the TS3500, we provide implementation
information and examples of each encryption method, as reflected in Table 20-1.
Table 20-1 Open systems encryption solutions supported
In addition, Table 20-1 reflects all the environments that are supported, as of this writing, of
the encryption solution and all applications and their associated operating systems that
currently support TS1120 or TS1130 drives in an open systems-attached environment. For a
current list, see the IBM Tape and Medium Changer Device Drivers for AIX, HP-UX, Linux,
Solaris and Windows, GC27-2130, at this website:
ftp://ftp.software.ibm.com/storage/devdrvr/Doc/archive
The installation of the Advanced Library Management System (ALMS) on a TS3500 library
affects your ability to use more than one method of encryption concurrently. On a partitioned
TS3500 library that has ALMS installed, you can use all three encryption implementation
methods concurrently, although a non-ALMS-partitioned library can only have one method
implemented at a time. For example, in an ALMS-enabled TS3500 library that has three
logical libraries, each logical library can use a separate encryption method.
Figure 20-1 on page 643 is an example of an ALMS-enabled TS3500 that is partitioned into
three logical libraries using all three encryption methods simultaneously. You can only
implement all three methods concurrently if ALMS is enabled.
AME SME LME
IBM library IBM Tivoli Storage
Manager only
AIX only using Atape
Windows
Solaris
Linux
TS3500
TS3400
3494
Rack or silo IBM Tivoli Storage
Manager only
AIX only using Atape
Windows
Solaris
Linux
N/A
Important: Using a TS1130 tape drive in a TS3500 tape library requires the ALMS feature.
Chapter 20. Implementing TS1120 and TS1130 encryption in an open systems environment 643
Figure 20-1 ALMS-partitioned TS3500 using all three encryption methods
20.2 Adding drives to a logical library
When you add a drive to a logical library, be aware that certain guidelines exist depending on
whether the Advanced Library Management System (ALMS) is enabled.
20.2.1 Advanced Library Management System considerations
Sharing your TS3500 Tape Library between open systems and System z hosts requires
ALMS. In the following section, note the use of the term encryption enabled as opposed to
encryption capable. The following paragraphs attempt to describe the effect in detail.
ALMS-enabled
In a TS3500 Tape Library, which uses ALMS, encryption-enabled drives in a logical library
must be defined as all library-managed, all application-managed, or a combination of
system-managed and no encryption.
A drive can only be shared in homogeneous logical libraries; that is, all drives within a logical
library must be set to the same encryption method.
A drive that is not encryption capable cannot be added to a logical library that is defined to
use LME or AME.
Within a logical library, encryption-capable drives can reside with non-encryption-capable
drives, but encryption-capable drives are not allowed to become encryption enabled.
Encryption-capable and encryption-enabled drives can coexist in the same frame. A
non-encryption-capable drive can be added to a System-Managed logical library.
Important: The LME and SME methods can share the same Encryption Key Manager
(EKM) or Tivoli Key Lifecycle Manager, which allows the two modes to be interchanged. At
this time, IBM Tivoli Storage Manager cannot share and cannot utilize encryption keys
between the AME method and either the LME or SME methods of encryption. IBM Tivoli
Storage Manager provides its own structure for key management. Consequently, storage
tapes encrypted with IBM Tivoli Storage Manager and sent to a business partner will
require IBM Tivoli Storage Manager at the business partner to decrypt them.
Logical Library # 1 Logical Library #2 Logical Library #3
Application-Managed System-Managed Library-Managed
Encryption Encryption Encryption
ALMS-disabled or non-ALMS libraries
Certain guidelines apply when you configure encryption-capable drives in non-ALMS
libraries. The following drive configurations are possible:
An encryption-capable drive is added to a library that contains non-encryption-capable
drives.
You can add a drive that is encryption capable to a library that previously did not have
encryption-capable drives, but you cannot enable encryption.
A non-encryption-capable drive is added to a library that contains encryption-capable
drives, which are not encryption enabled.
You can add a non-encryption-enabled drive to a library that is installed with
encryption-capable drives, which are not set for encryption. The drives that are encryption
capable are restricted from becoming encryption enabled.
A non-encryption-capable drive is added to an encryption-capable and
encryption-enabled physical library.
A drive that is not encryption capable cannot be added to a library that has
encryption-enabled drives and will be restricted (not available for use). In the event that
you create this configuration, the Operator Panel or Tape Library Specialist web interface
displays the number of restricted drives.
TS1130 drives are not supported.
20.3 Managing the encryption and business partner exchange
In addition to keeping your on-site data safer, encryption adds security to your data when it
leaves your premises. After it leaves your premises, the security procedures that you have
established that limit access to this data are pretty much null and void. This area is where
encryption really proves its worth.
Figure 20-2 on page 645 reflects the usage of both symmetrical and asymmetrical key usage
in the IBM encryption solution. The user data is encrypted with a symmetrical key. Symmetric
encryption is both fast and secure and allows the data to be written to the cartridge at near
line speed. The key that was used to encrypt the user data is then encrypted with an
asymmetrical key and then stored on the cartridge. In this example, KEK refers to key
encrypting key, which is also referred to as the public-private key or the
Rivest-Shamir-Adleman algorithm (RSA) key.
Encryption key management allows you to specify two key encrypting keys (KEKS), which are
used to create the two externally encrypted data keys (EEDKs) that are placed on the
cartridge both in the cartridge memory (CM) and on three non-user accessible places on the
tape media.
Figure 20-2 Key flow
Table 20-2 on page 646 is a useful reference table when you are in the process of deciding
how to implement encryption. The encryption method that you choose affects how you
manage which files get encrypted and as a by-product, how and where to influence which
keys are used to create those files. AME provides the most flexibility, because you can decide
at the file level whether it is eligible for encryption.
SME is done at the drive level; so, for files that have to be encrypted, you have to direct those
allocations to specific tape drives. LME policy is controlled and specified at the tape cartridge
VOLSER level, or, in the case where Internal Label Encryption Policy is selected, and
NetBackup is being used, encryption is based on the pool ID supplied by NetBackup. AME
using IBM Tivoli Storage Manager is managed at the file level, controlled by IBM Tivoli
Storage Manager.
Table 20-2 Managing open systems encryption
Your disaster recovery (DR) hardware environment has to be considered when implementing
encryption, because the method that you choose will affect the required equipment at your
disaster recovery site.
Your recovery process will have to be changed to ensure that EKM and its associated
keystore or an identical Tivoli Key Lifecycle Manager system and a current backup are
available and running prior to your having to access encrypted data. Ensure that you do not
encrypt your EKM keystore or Tivoli Key Lifecycle Manager backup.
Type of
encryption
management
Description Notes Sample
environment
AME The application
directly controls
whether a
cartridge is
encrypted.
The application manages allocations
of cartridge format types to
appropriate drives in heterogeneous
environments.
This method supports a large number
of systems (for example, IBM and
other libraries that are not IBM).
You can control encryption based on
existing DEVCLASS type policies.
Program updates are required for the
application and, in certain cases, the
underlying operating systems or
components.
IBM Tivoli
Storage
Manager
SME The device driver
controls whether
data is
encrypted. All
cartridges in the
logical library will
become
encrypted when
written from
beginning of
tape.
Encryption management is by drive,
rather than by cartridge.
This method transparently supports a
large number of systems (for example,
other libraries that are not IBM).
New IBM device drivers must be
deployed on tape servers.
This method is available for only IBM
device drivers.
The IBM device driver supports
failover to the drives alternate Fibre
Channel (FC) connection.
IBM Atape AIX
device driver in
an open
systems
environment
LME The library
controls whether
a specific
cartridge is
encrypted.
Based on drive settings, the library
allows you to encrypt data by
cartridge.
This method is the most transparent,
because the application and device
driver might not require updates.
New library firmware must be
deployed.
This method is supported only on IBM
libraries.
IBM 3584 Tape
Library
Important: Do not encrypt your EKM or Tivoli Key Lifecycle Manager backup files.
Encryption compatibility
LME data and SME data are fully compatible. In this case, data that is encrypted using LME
can be decrypted using SME, when AIX is the host operating system. The reverse is also true
for AIX hosts, so that data that is encrypted using SME can be decrypted using LME.
However, it is also important to note that if LME is implemented, a TS3500, TS3400, or the
ability to run SME must be available at the DR site. If a TS3500 is not available, a TS3400 or
SME environment (AIX and Atape), along with EKM and its associated files, is necessary and
will have to be available prior to your having to read encrypted data.
20.3.2 Keeping track of key usage
To keep track of the key labels by VOLSER that were used to create the EEDKs on your
encrypted cartridges, refer to EKM or Tivoli Key Lifecycle Manager audit log. The
KeyManagerconfig.properties EKM configuration file holds the location of the audit log. The
audit log that is created by EKM has extremely useful information in it. Example 20-1 is an
EKM audit log entry. The log entry contains the time and date of file creation, tape drive serial,
and worldwide name (WWN) used, cartridge VOLSER, and key alias/labels that were used to
create the EEDKs on the cartridge.
Example 20-1 EKM audit log example
Runtime event:[
timestamp=Tue Sep 28 23:21:02 MST 2000
event source=com.ibm.keymanager.c.fb
resource=[name= Drive Serial Number: 000001365071 WWN: 500507630F0c8501 VolSer:
J1G490 Key Alias/Label[0]: tape_sol_tst_shr_pvt_1024_lbl_01 Key Alias/Label[1]:
tape_sol_tst_shr_pvt_1024_lbl_01;type=file]
action=stop
]
Using the information in the audit log, we created a table, as shown in Figure 20-3 on
page 648. You can reference this information if required to verify which key labels were used
to encrypt the data on the cartridge, and consequently, who can access the data.
The audit subsystem writes textual audit records to a set of sequential files as various
auditable events occur during the EKM processing of requests. The audit subsystem writes to
a file. The directory, file name, and size are configurable and set in the EKM configuration file.
As records are written to the file, and the size of the file reaches the configurable size, then
the file is closed, renamed based on the current time stamp, and 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 with their names sequenced by the time stamp of 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, you must create a script or program, 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 files contents must be copied and appended to the desired long-term,
continuous log location and then cleared. Be careful not to remove or alter the file, which is
having records written to it by EKM while EKM is running (this file does not have a time stamp
in the file name).
Important: If LME is implemented, a TS3500, TS3400, or a SME-compatible environment
will be necessary at your DR site.
For the remainder of the audit entry types created, refer to the IBM System Storage Tape
Enterprise Key Manager, Introduction Planning and User Guide, GA76-0418, which has a
chapter about audit records.
Figure 20-3 Formatted EKM audit log entries
Tape System Reporter on the TS3500
You can also use the Tape System Reporter (TSR) tool on Microsoft Windows to monitor tape
drives and encrypted cartridges in TS3500 tape libraries. The TSR tool saves the tape library
statistics logs into a database and provides a front end to the database to assist with tracking
and trending the behavior of your tape libraries. TSR requires ALMS. Download it from this
website:
ftp://ftp.software.ibm.com/storage/358x/3584/TSR/
It tracks when cartridges become encrypted and in which drives a cartridge is used, among
other parameters.
20.4 Encryption implementation checklist
In this section, we describe the necessary planning and setup tasks.
20.4.1 Planning your EKM environment
You must consider many factors when you plan how to set up an encryption strategy.
Encryption setup tasks at a glance
Before you can use the encryption capability of the IBM TS1120 or TS1130 tape drive, you
must be sure that certain software and hardware requirements are met. The following
checklists are intended to help you meet these requirements.
Note: Contact your IBM marketing representative for additional information about
encryption on the IBM TS1120 or TS1130 tape drive.
20.4.2 EKM setup tasks
Before you can encrypt tapes, you must first configure EKM or Tivoli Key Lifecycle Manager,
and it must be running so that it can communicate with the TS1120 or TS1130 tape drives.
EKM or Tivoli Key Lifecycle Manager does not have to be running while tape drives are being
installed, but it must be running to perform encryption. It is easier to verify a correct EKM
configuration if it is running at drive install time, because the IBM service support
representative (SSR) can run an end-to-end encryption test from the TS3500 operator panel.
Note that you do not have to set up EKM or Tivoli Key Lifecycle Manager if you are
implementing AME.
Perform the following tasks before using EKM:
1. Decide what systems to use as EKM servers.
2. Upgrade the server operating system, if necessary.
3. Upgrade the IBM Java Virtual Machine (JVM), if necessary.
4. Install the IBM Java Unrestricted Policy Files.
5. Upgrade the EKM JAR, if necessary, which you can obtain at this website:
Or, visit the following website, click Download, and look for IBM Encryption Key
Manager for the Java platform:
6. Decide on the keystore type.
The type of keystore that you select, depending on your environment, can affect your
future flexibility for encryption implementation. Refer to 16.1, Keystore and SAF Digital
Certificates (keyrings) on page 482 for more details.
7. Define the keystore:
a. Create a keystore and certificates (AIX and other operating systems), as shown in
Example 15-28 on page 434.
b. Import or create keys and certificates into the keystore. Refer to Importing and
exporting certificates and why on page 435.
8. Define the EKM configuration file. Refer to Example 15-35 on page 445.
9. Define tape drives to EKM, or set the drive.acceptUnknownDrives EKM configuration
property value on.
10.Start EKM.
20.4.3 Application-Managed Encryption setup tasks
You must perform these required tasks to run encryption on the TS1120 tape drive:
Ensure that the TS1120 tape drives are encryption capable.
Ensure that library and tape drive firmware are at the correct levels to support encryption.
Note: If you are implementing AME, these steps are not necessary, because IBM Tivoli
Storage Manager handles the EKM function.
Enable encryption on the IBM TS1120 Tape Drive (3592-E05). Refer to the IBM System
Storage TS3500 Tape Library Operator Guide, GA32-0560, for configuring the IBM
TS1120 Tape Drive on TS3500. The IBM SSR must perform this task for stand-alone or
rack-mounted tape drives.
You must perform these required tasks to run encryption on the TS1130 tape drive:
Ensure that automation is updated to support the TS1130 tape drive.
Ensure that the TS1130 tape drives are encryption capable.
Enable encryption on the IBM TS1130 (3592-E06 or 3592-EU6). Refer to the IBM System
Storage TS3500 Tape Library with ALMS Tape System Reporter Users Guide,
GA32-0589, for configuring the IBM TS1130 Tape Drive on TS3500.
Perform these common activities to set up AME:
Install the appropriate IBM Tape Device Driver level (Atape, for example).
Set up encryption policies. Refer to the IBM Tivoli Storage Manager for AIX
Administrators Guide, GC32-0117.
Perform write/read operation to test encryption.
Verify encryption of the test volume by Application-Managed Encryption (AME):
Issue QUERY VOLUME FORMAT=DETAILED.
Verify that the Drive Encryption Key Manager is set to IBM Tivoli Storage Manager.
20.4.4 System-Managed (Atape) Encryption setup tasks
You can divide the setup tasks for SME into a group of preliminary tasks that can be
completed in advance and a group of primary tasks to enable encryption.
Preliminary tasks
You must perform these required tasks to perform SME on the IBM TS1120 or IBM TS1130
tape drive:
Install encryption-capable TS1120 or TS1130 tape drives and the TS3500 library.
Create a certificate-populated keystore.
Install the IBM Encryption Key Manager component for the Java platform (EKM) or Tivoli
Key Lifecycle Manager.
Primary tasks
Perform these primary tasks:
Firmware updates:
If using a TS1130 with a TS3500 install ALMS feature.
Update TS3500 library firmware.
Update tape drive firmware.
Encryption-enable the IBM TS1120 (3592-E05) or IBM TS1130 (3592-E06 or 3592-EU6)
tape drive:
Use the TS3500 web GUI or an IBM Service task.
Refer to the IBM System Storage TS3500 Tape Library Operator Guide, GA32-0560,
for configuring the IBM TS1120 Tape Drive on TS3500. The IBM SSR must perform
this task for stand-alone or rack-mounted tape drives.
Update the Atape device driver.
Update the Atape EKM proxy configuration file with EKM or Tivoli Key Lifecycle Manager
IP addresses.
Update device attributes by using rmtx, which is the drive that you want to system-manage
using the Atape device driver. Update using SMIT, tapeutil, or TS3500:
Use System Encryption Fibre Channel Protocol (FCP) Proxy Manager.
System encryption for write commands at beginning of partition (BOP), which is similar
to beginning of tape (BOT).
Use tapeutil functions to verify the EKM paths and encryption configuration.
20.4.5 Library-Managed Encryption setup tasks
Performing encryption on the IBM TS1120 or TS1130 tape drive requires the following
components:
Encryption-capable TS1120 or TS1130 tape drives
Keystore
IBM Encryption Key Manager (EKM) component for the Java platform or Tivoli Key
Lifecycle Manager
20.5 Implementing Library-Managed Encryption
This method is best for TS1120 or TS1130 tape drives in an open systems-attached IBM
System Storage TS3500 Tape Library. You set up Barcode Encryption Policies and Internal
Label Encryption Policies specifying when to use encryption through the IBM System Storage
Tape Library Specialist web interface. Policies are based on cartridge volume serial numbers
or on an internal label that is written in the tape header. EKM, which is a Java application
running on a library-attached host, performs the key generation and management. Policy
control and keys pass through the library-to-drive interface; therefore, encryption is
transparent to the applications.
SME and LME are transparent to each another. A tape that is encrypted using SME can be
decrypted using LME, and alternatively, provided that they both have access to the same
EKM or Tivoli Key Lifecycle Manager keystore and use an IBM device driver that supports
SME and is compatible with the host operating system.
20.5.1 LME implementation tasks
Perform these tasks to implement LME:
1. Install and cable the IBM TS1120 or TS1130 tape drive (IBM Service or SSR task).
2. Update the tape system library and the tape drive firmware. If using a TS1130, install
ALMS on the TS3500.
3. Use the IBM System Storage Tape Library Specialist to enable the IBM TS1120 or IBM
TS1130 tape drive and the IBM TS3500 Tape Library for LME (refer to IBM System
Storage TS3500 Tape Library Operator Guide, GA32-0560, or IBM System Storage
TS3500 Tape Library Operator Guide (with ALMS), GA32-0594).
4. Add EKM or Tivoli Key Lifecycle Manager IP addresses.
5. Set up the Barcode Encryption Policy (BEP) or Internal Label Encryption Policy (ILEP).
6. Use library diagnostic functions to verify the EKM paths and encryption configuration. As
of this writing, this verification requires physical access to the TS3500 operator panel.
Select Menu Service Tests/Tools Diagnostics Test Encryption Key Path
Setup.
20.5.2 Upgrading firmware
In this section, we review the necessary steps to upgrade both the TS3500 library and the
TS1120 or TS1130 drive firmware.
Verify library firmware levels
Using the web GUI, confirm that the TS3500 library is at firmware version 6470 or later for the
TS1120 or 8160 or later for the TS1130 by selecting Node Cards under the Service Library
Work Item. You see Figure 20-4.
Figure 20-4 Library firmware version level
Policies: Previously, the term Scratch Encryption Policy (SEP) referred to the only
encryption policy that was available for the LME method. SEP uses a volumes
VOLSER to determine the encryption policy. A new LME policy called Internal Label
Encryption Policy (ILEP) has been added. This policy also relates to scratch volumes.
Thus, SEP now refers in general to the various LME policies. A new term, Barcode
Encryption Policy (BEP), is now used to refer to the policy that was previously known as
SEP.
Notes: All levels of the TS1130 are encryption capable. You must install the ALMS feature
to use the TS1130 with a TS3500, and 8160 or later firmware must be loaded on the tape
library.
The firmware encryption versions are 6470 for the TS3500 library without ALMS and the
D3I1_942 or later for the TS1120 tape drives.
Tip: If the web GUI loads a blank page, clear the web browser cookies, and then reload.
Because the library is at the correct firmware level, we do not have to update the library
firmware. However, if you must update the library firmware level, perform the steps in
Installing software feature codes, such as ALMS on page 653 and upgrade the firmware, as
described in Update the library firmware on page 653.
Installing software feature codes, such as ALMS
Perform these steps to install and enable ALMS on your TS3500 using the TS3500 web
interface:
1. Enter the ALMS license key.
2. Type the Ethernet IP address on the address line of the browser, and press Enter. The
Welcome page displays.
3. Select Service Library Download Library Logs. Then, select the log/file type NVRAM
Backup/Memory Dump, select the Download option from the Select Action pull-down
menu, and click Go. This step can take several minutes (Figure 20-5).
Figure 20-5 Backing up your current library configuration
4. At your next service window, select Library ALMS, select Enable, and follow the
instructions on the window. This process can take time, depending on your firmware
version and library configuration.
Update the library firmware
Update the library firmware by using the TS3500 web interface:
1. Type the Ethernet IP address on the URL line of the browser, and press Enter. The
Welcome page displays.
2. Select Service Library Firmware Update. The Firmware Update panel is displayed,
as shown in Figure 20-6 on page 654.
Figure 20-6 TS3500 Tape Library Firmware Update panel in the wizard
3. If you do not already have the new firmware to install, click Go To UltraScalable Tape
Library Technical Support. This option takes you to the web page where you can
download the library firmware. Ensure that you extract it prior to continuing with the next
step.
4. From the Firmware Update panel in Figure 20-6, select Launch Firmware Update
Wizard.
The panel that is shown in Figure 20-7 opens.
Figure 20-7 Selecting the firmware image to update
5. Select Library Firmware as the firmware image to update, and click Next.
The panel that is shown in Figure 20-8 opens.
Figure 20-8 TS3500 Web GUI Library Firmware update
6. Enter or browse for the name of the update image file. Then, click Update.
As indicated in the Attention box in Figure 20-8, the update can take up to 60 minutes to
complete.
In the past, when library firmware required an update, scheduling downtime for the IBM 3584
Tape Library was necessary. Job flow was interrupted, and productivity was reduced. The
library now offers a nondisruptive library firmware update that either the SSR can perform by
using the Customer Engineer Tool software application, or that you can perform by using the
Tape Library Specialist web interface. Certain levels of library and drive firmware are required.
Table 20-3 lists the levels of firmware that are necessary for a nondisruptive library firmware
update.
Table 20-3 TS3500 nondisruptive firmware levels
Upgrading the TS1120 firmware
The TS1120s on our library were not at the correct firmware level to support encryption, so
we had to upgrade them to the required level. The drives for our logical library are in Frame 1,
Rows 9 and 10. See Figure 20-9 on page 656. The process is the same for TS1130 drives.
Device Level of firmware
3584 Tape Library 6050
Ultrium 3 tape drives 62R0
Ultrium 2 Tape Drive 6750
TS1130 Tape Drive All GA Levels
TS1120 Tape Drive 16E4
3592-J1A Tape Drive 0828
Figure 20-9 Drive Vital Product Data (VPD) reflects the installed firmware versions
Updating drive firmware
Updating the drive firmware is a fairly simple process. It takes approximately 30 minutes from
start to completion. We obtained the firmware from the following IBM website and
downloaded it to our personal computer:
http://www-1.ibm.com/support/docview.wss?rs=564&context=STCTNLZ&dc=D420&uid=ssg1S4
000317&loc=en_US&cs=utf-8&lang=en
Expand the Service Library folder, and select Firmware Update. The panel in Figure 20-10
opens.
Figure 20-10 Updating drive firmware
In the past, a firmware update to a drive that was performed through the library was disruptive
to the host server, because the operator had to stop host jobs that were queued to the drive
and take the drive offline. The library now provides two nondisruptive options for updating
drive firmware:
Activate when drive is empty.
Activate when drive is reset.
These options do not affect the host. Activate immediately might affect the host if the drive is
performing read/write operations.
Perform these steps to use the Tape Library Specialist web interface to update firmware for
drives in the 3584 Tape Library:
1. Select Service Library Firmware Update. The Firmware Update panel is displayed.
2. Select Launch Firmware Update Wizard, and then, select the option to update a drive.
The Specify Firmware Image File panel displays, as shown in Figure 20-11.
Figure 20-11 Drive firmware update window
3. Select one or more drives that you want to update, and then select one of the Firmware
Activation options in Table 20-4.
Table 20-4 Firmware activation options
4. Select Update.
20.5.3 Add EKM or Tivoli Key Lifecycle Manager IP addresses
To set the IP address that the library will use, select Manage Access Key Manager
Addresses. The Key Manager Addresses panel is displayed, as shown in Figure 20-12.
Figure 20-12 Setting Key Manager (KM) IP addresses
The logical library uses the Key Manager (KM) IP addresses in the following order: If the first
EKM or Tivoli Key Lifecycle Manager in the list is not available, the library fails over to the next
EKM or Tivoli Key Lifecycle Manager, and on to the All/Other KMs, if necessary. This process
is considered a failover process.
Option Description
Activate immediately Performs the update as soon as the code is transferred
to the drive.
Activate when drive is empty Performs the update only after the host has demounted
the cartridge from each specified drive.
Activate when drive is reset Performs the update after the next time that the drive resets.
The drive can be reset using the web UI.
Note: Only the Activate immediately option is available to the Ultrium 1 Tape Drive, which
cannot be defined as a control path drive. The Activate when drive is empty option is
supported for control path drives.
After a KM is contacted, it is at that point that we look for the correct label or hash in the
keystore. If these values are not in the keystore of the first contacted EKM or Tivoli Key
Lifecycle Manager, the request fails. Although the Label or Hash might exist in the keystore of
the next EKM or Tivoli Key Lifecycle Manager, the request does not fail over to the next EKM
or Tivoli Key Lifecycle Manager. You have to ensure that all keystores are alike, so that this
situation does not occur.
Setting the KM address is straightforward. Select the Select Action list box, and select
Create. At this point, you can enter the IP address of your KM along with the port address.
The port address has to match the port address that is specified in the KM configuration. The
data in Example 20-2 is not intended to be all inclusive, because we have included only a few
statements around the TransportListener.cp.port=3801 parameter, which is the value that we
refer to with this panel. If you have to see the entire EKM configuration file that we used, refer
to Example 15-35 on page 445.
Tivoli Key Lifecycle Manager also defaults to listening on TCP port 3801. You can change this
port with the Tivoli Key Lifecycle Manager GUI under Tivoli Key Lifecycle Parameters
Configuration Key Serving Parameters.
Example 20-2 Short edited version of EKM configuration
# listconfig
Audit.eventQueue.max=0
TransportListener.tcp.port=3801
TransportListener.ssl.truststore.name=tonyskeys.jcks
The TransportListener.tcp.port parameter is the port that the EKM server listens on for
requests from the tape drives. Although this parameter is a required parameter, you might
notice that we used the default value that came with the sample configuration.
20.5.4 Enabling Library-Managed Encryption
Now that you are at the correct levels of both drive firmware and library firmware, you are
ready to enable Library-Managed Encryption (LME). We list the steps:
1. Enable encryption for the logical library.
2. Modify the logical library EKM address panel to point to your EKM for that logical library.
3. Set up a Barcode Encryption Policy (BEP) or Internal Label Encryption Policy (ILEP).
4. Verify that the library can communicate with your EKM.
Enable encryption for the logical library
Perform these steps to enable encryption for your logical library:
1. Select Manage library by logical library, which results in the Manage Logical
Libraries Panel, as shown in Figure 20-13 on page 660.
Failover: Failover only occurs if a Key Manager (KM) cannot be contacted, for example,
when it is not started. Failover does not occur if EKM or Tivoli Key Lifecycle Manager is
running but has an operational problem, for example, a configuration file setting is
incorrect.
Figure 20-13 Setting Encryption method by logical library
2. From the Manage Logical Libraries selection panel, select Modify Logical Library from
the Select Action pull-down menu, check the logical library to modify, and click Go.
3. As shown in Figure 20-14, we use logical library 29, so we checked its box, selected
Modify Encryption Method from the list box, and then, clicked Go.
Figure 20-14 Modifying Encryption Method for logical library 29
The Encryption Method panel displays, as shown in Figure 20-15.
Figure 20-15 Encryption Method selection panel
4. Choose the Encryption Method for the logical library with which you are working. Because
we are setting up LME, select Library-Managed.
Select an encryption policy type to use, and then, click Apply:
Barcode (default)
5. After refreshing the panel (Figure 20-16), you see that logical library 29 now has
Library-Managed displayed in the Encryption Method column.
Figure 20-16 Library-Managed Encryption panel
Note: On this panel, you can also select another encryption method: either
System-Managed or Application-Managed. We describe these settings in their
corresponding sections in this book.
20.5.5 Barcode Encryption Policy
After enabling the Barcode Encryption Policy for Library-Managed Encryption for the first
time, you must create a Barcode Encryption Policy (BEP), even if you are encrypting all
cartridges.
A Barcode Encryption Policy is a range of cartridge VOLSERs and 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 LME, a Barcode
Encryption Policy controls cartridge encryption by VOLSER ranges in all logical libraries for
which Barcode Encryption Policy was chosen. Stated another way, if you have defined
multiple policies (overlap not allowed), they all are in effect simultaneously, and they affect
which cartridges are encrypted in every defined library-managed logical library in a TS3500
that selected Barcode Encryption Policy.
When implementing a Library-Managed BEP, you not only specify which cartridges to encrypt
but also the public keys that are used to encrypt the data key. You manage this situation by
directing future allocations to specific Barcode Encryption Policies, depending on the
cartridge destination. Using Table 20-5 as an example of the BEPs that we have built in our
test environment, we create a few encrypted tapes that are intended for separate business
partners.
For encrypted data that is to be sent to business partner PART2, we direct allocations to tape
VOLSERs ABC100 - ABC199 to ensure that one of the EEDKs created on the tape can be
decrypted by PART2s private key. This approach allows the business partner to access the
data key (DK) and decrypt the data on the cartridge.
Sending an encrypted cartridge to business partner PART1 dictates that we direct an allocation
to tape VOLSERs ABC000 - ABC099, ensuring that EEDK 1 is built using business partner
PART1s public key. This approach allows PART1s EKM at PART1s location to decrypt this
EEDK using PART1s private key to then retrieve the data key so that the data can be
decrypted by the TS1120 drive.
Table 20-5 Barcode Encryption Policy table
Policies: Previously, the term Scratch Encryption Policy (SEP) referred to the only
encryption policy that was available for the LME method. SEP uses a volumes VOLSER to
determine the encryption policy. A new LME policy that is called Internal Label Encryption
Policy (ILEP) has been added. This policy also relates to scratch volumes. Thus, SEP now
refers in general to the various LME policies. A new term, Barcode Encryption Policy
(BEP), is now used to refer to the policy that was previously known as SEP.
Barcode Encryption Policies (BEPs)
BEP VOLSER sequence Key label number 1
a

a. Key label can be in clear text or HASH format.
Key label number 2
BEP number 1 ABC000 - ABC099 Business partner PART1 Our key label
Creating a Barcode Encryption Policy
The Barcode Encryption Policy is merely a sequence of VOLSERs specified to the library. To
view, change, or add to these policies, from the TS3500 web GUI, select Manage
Cartridges Barcode Encryption Policy. The panel in Figure 20-17 opens.
Figure 20-17 Barcode Encryption Policy GUI
On this panel, you can modify, create, or delete a VOLSER range. Let us look at how to create
a Barcode Encryption Policy.
Select Create from the list box, and click Go in the panel that is shown in Figure 20-17.
Figure 20-18 on page 664 displays.
BEPs: Only cartridge VOLSERs that are specified in defined Barcode Encryption Policies
are encrypted.
Figure 20-18 Barcode Encryption Policy panel
At this panel, for the fields Volume Serial Number Start and Volume Serial Number End, you
enter the beginning and ending VOLSERs of the Barcode Encryption Policy for the BEPs that
you want to create. If you try to enter a range that overlaps with a previously entered range,
you receive an error and the BEP is not created.
There are three key modes that you can select. The key mode refers to the method by which
the externally encrypted data keys (EEDKs) that are created on the cartridge are referenced:
Default label The label was configured at the Encryption Key Manager and is
specified within the EKM configuration file.
Clear label The externally encrypted data key (EEDK) is referenced by the
specified key label.
Hash label The EEDK is referenced by a computer value, which corresponds to
the public key that is referenced by the specified key label.
The Default Label is self-explanatory; however, we have to explain Clear Label and Hash
Label.
When a certificate is imported into a keystore, a label is assigned to it. It is this label that you
enter on this panel. When an encrypted cartridge is created, two EEDKs are also created and
stored on the cartridge. In addition to the encrypted Data Key, each EEDK has a pointer to the
public key that was used to encrypt the Data Key. The pointer can either be the label of the
certificate or a hash value based on the public key. Regardless of which pointer is used, EKM
uses the value to identify the correct private key to use to decrypt the encrypted data key.
Let us see how this might work in your environment. You decide that you want to encrypt
cartridges sent to your business partner (BP); so, how do you proceed?
Perform these steps to create the BEP:
1. Contact your BP to obtain a certificate with the BPs public key in it.
2. Import this certificate into your keystore.
3. The import process assigns a label to the certificate, which you can consider as My BPs
certificate.
4. Because you are implementing LME, you have to create a BEP, so that you can send
encrypted cartridges to your business partner.
5. Create the BEP by specifying the VOLSER range = BP001-BP100:
a. Key1 mode = clear label and label = My BPs certificate, which corresponds to the
value that you specified when you imported this BPs certificate into your keystore.
b. Key2 mode = clear label and label = My certificate.
The BEP is created.
You are now ready to create an encrypted cartridge to send to your BP:
1. You write data to cartridge BP001. The data is encrypted, and two EEDKs are placed on
the cartridge with the data:
EEDK1 Encrypted data key and clear label version of My BPs certificate.
EEDK2 Encrypted data key and clear label version of My certificate.
2. Demount the cartridge.
You decide that prior to sending the cartridge, you want to verify that you can access the data,
so the cartridge is mounted. You follow this process:
1. The tape drive sends both the EEDKs to EKM.
2. EKM unwraps both EEDKs and, using the label within each EEDK, finds the correct
certificate, which contains the private key that is required to decrypt the encrypted data
key.
3. EKM finds certificate labeled My Business Partner, but it does not contain a private key, so
EKM continues.
4. EKM finds a certificate labeled My certificate, finds the private key, decrypts the data key,
and sends that decrypted data key to the drive.
5. The drive uses the data key to decrypt the data and passes the decrypted data to your
application, which reads it without issue.
Because you were able to read the cartridge at your site, you decide that the cartridge is
encrypted correctly and you send it to your business partner. To read the encrypted cartridge,
the business partner proceeds. The steps in the following process can result in an error:
1. The cartridge is mounted on an encryption-enabled drive.
2. The tape drive sends both of the EEDKs to EKM.
3. EKM unwraps both of the EEDKs and, using the label within each EEDK, attempts to find
the corresponding certificate that contains the private key that is required to decrypt the
encrypted data key.
4. EKM looks for a certificate labeled My Business Partner, cannot find it, so it continues with
the next EEDK.
5. EKM looks for a certificate labeled My certificate and cannot find that one either.
6. EKM passes an error code to the drive stating that the certificate is not in the keystore.
7. The application that is attempting to read the cartridge fails.
What happened, and how do you ensure that this problem does not happen again? The
previous example is an error case where hash needed to be specified. You are now ready to
investigate using the hash label, as opposed to the clear label.
Creating a BEP using hash values
Why was your business partner unable to read the cartridge? A certificate that contained the
correct private key did exist in the business partners keystore; it is simply that the key
manager was unable to find it. Why was the key manager unable to find it? You told the key
manager to look for a certificate labeled My BPs certificate, and there simply was not a
certificate in your BPs keystore with this label.
What questions to ask
Do you see the problem now? How do you ensure that you and your BP both label certificates
with the same name? This issue does not seem too difficult if you have one or two BPs,
because you can contact each BP and agree on a name, but what if you have several
hundred BPs? What if you have a BP, whom you have never contacted, and to whom you now
have to send an encrypted cartridge? What if you misspell the label when entering it?
Where hash values are used
There are several fields within each certificate. One of these fields is named Subject Key
Identifier (SKI). The content of the SKI field is a hash value representing the public key that is
contained within the certificate. Let us see how this SKI field is used when specified in the
BEP:
1. You write data to cartridge BP001, the data is encrypted, and two EEDKs are placed on
the cartridge with the data:
EEDK1 Encrypted data key and HASH label of My BPs certificate.
EEDK2 Encrypted data key and Clear label version of My certificate.
2. Demount the cartridge.
Now, when the BP receives the cartridge, the following steps occur:
1. The cartridge is mounted on an encryption-enabled drive.
2. The tape drive sends both of the EEDKs to EKM.
3. EKM unwraps both EEDKs and, using the label within each EEDK, attempts to find the
corresponding certificate that contains the private key that is required to decrypt the
encrypted data key.
4. EKM realizes that for EEDK1, it has a hash value and not a certificate label, so EKM
compares this value to the SKI field in each certificate until the key manager finds a match
or reaches the end of the keystore. Finding the match, the key manager then uses the
private key in the certificate to decrypt the encrypted data key. The key manager then
sends the data key to the drive.
5. The drive uses the data key to decrypt the cartridge data and passes the decrypted data
to your application, which uses it without issues.
Barcode Encryption Policies for scratch cartridges
The BEP web GUI page allows you to create, change, or delete an encryption policy for
scratch cartridges. A scratch cartridge is a labeled cartridge that is blank or contains no valid
data. A Barcode Encryption Policy allows the library to identify to an IBM TS1120 or TS1130
tape drive which scratch cartridges to encrypt on the next attempt to write from the beginning
of the tape.
The following information also displays on this panel:
Refresh A button that allows you to redraw the contents of the page. You can
select Refresh at any time.
Select Action A drop-down list box that allows you to select actions to perform. After
you select a range of scratch cartridges by their volume serial
(VOLSER) numbers, select the action that you want to perform on
them, and then click Go. You have these choices:
Create Allows you to create a Barcode Encryption Policy for the
range of scratch cartridges that you specify.
Modify Allows you to change the VOLSER range, key labels, or
modes in the policy that you selected.
Delete Allows you to remove the policy that you selected. If only
one Barcode Encryption Policy exists, the library does
not allow you to delete it.
Volser Ranges The range of cartridges to be encrypted from the beginning of the
tape.
Key 1 Label An alias for an encryption key (cipher). It is used by the Encryption Key
Manager software.
Key 1 Mode For Key 1, the method by which an Encryption Key Manager identifies
the public-private keys that were used to encrypt it.
Creating a Barcode Encryption Policy
Follow these steps to create a Barcode Encryption Policy:
1. From the Select Action drop-down list box, select Create, and click Go.
2. In the pop-up menu, check Set All/Other Volsers or 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.
3. Enter two key labels for the policy. You can select an existing key label from each
drop-down list box, or you can enter a new key label.
4. 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 encrypted data key. Choose from these
values:
Default Label The label was configured at the Encryption Key Manager.
Clear Label The externally encrypted data key (EEDK) is referenced by the
Hash Label The EEDK is referenced by a computer value, which corresponds
to the public key that is referenced by the specified key label.
5. Click Apply.
Changing a Barcode Encryption Policy
Follow these steps to change a Barcode Encryption Policy:
1. In the Select column, select the policy that you want to edit.
2. From the Select Action drop-down list box, select Modify, and click Go.
3. In the pop-up menu, 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.
4. Enter two key labels for the policy. You can select an existing key label from each
drop-down list box, or you can enter a new key label.
5. Select two key modes for the policy. Choose from these values:
Default Label The label was configured at the Encryption Key Manager.
Clear Label The externally encrypted data key (EEDK) is referenced by the
Hash Label The EEDK is referenced by a computer value, which corresponds
to the public key that is referenced by the specified key label.
6. Click Apply.
Deleting a Barcode Encryption Policy
Follow these steps to delete a Barcode Encryption Policy:
1. In the Select column, select All/Other Volsers or the VOLSER range of the policy that
you want to remove.
2. From the Select Action drop-down list box, select Delete, and click Go.
3. A pop-up menu asks you to confirm the deletion.
4. Click OK to delete the policy.
20.6 Implementing System-Managed Encryption
Implementing System-Managed Encryption (SME) involves changes that are implemented at
the system and library level that are transparent to the application, as shown in Figure 20-19.
Although we describe SME implementation for the TS3500 Tape Library, be aware that SME
for open systems is also supported with TS1120 or TS1130 tape drives installed in an
IBM 3494 Tape Library or an IBM TS3400 Tape Library.
Figure 20-19 Policy, keys, and changes overview
You implement encryption policies at the system level using Atape on the AIX 5.1, 5.2, or 5.3
operating system. Figure 20-20 on page 669 shows the data flow using the Atape device
driver.
2006 IBM Corporation
Library
System
Application
Changes required
at the system
layer to manage
encryption
Policy and keys
passed
between
system layer
and drives
Encryption-
capable IBM
tape drives
Figure 20-20 Key and policy flow in the SME environment
20.6.1 System-Managed Encryption tasks
Performing SME on the IBM TS1120 or TS1130 tape drive requires these steps:
Ensure that TS1120 or TS1130 tape drives and TS3500, IBM 3494, or TS3400 tape
library are encryption capable.
See Verify library firmware levels on page 652 for more information.
Install, verify, and configure:
Keystore. See Creating a keystore using keytool on page 434.
IBM EKM component. See 15.2, Installing EKM on AIX on page 431.
Ensure that encryption is enabled on TS1120 (3592-E05) or TS1130 (3592-E06 or
3592-EU6) tape drive.
Use the TS3500 web GUI or an IBM Service task. Refer to Enable encryption for the
logical library on page 659 to enable encryption using the web GUI. Also, refer to IBM
System Storage TS3500 Operators Guide, GA32-0560, or IBM System Storage TS3500
Tape Library Operator Guide with ALMS, GA32-0594, for configuring the TS1120 or
TS1130 tape drive on the TS3500 Tape Library.
Install or update Atape device driver. See Atape device driver on page 670.
Version 10.2.8.0 for AIX 5.1, 5.2, or 5.3 includes Atape encryption support.
Update the entry in the Atape EKM proxy configuration file with the EKM or the Tivoli Key
Lifecycle Manager IP address and port.
Update entries in the Atape device driver configuration for each tape drive (rmtx) that is
used for SME:
Use System Encryption Fibre Channel Protocol (FCP) Proxy Manager.
System Encryption for Write Commands at BOP.
Use tapeutil functions to verify EKM or Tivoli Key Lifecycle Manager paths and encryption
configuration.
20.6.2 Atape device driver
Example 20-3 shows how to verify that you are at the correct Atape device driver version by
issuing the AIX lslpp command.
Example 20-3 Verify the Atape version that is installed
lslpp -l Atape.driver
Fileset Level State Description
----------------------------------------------------------------------------
Path: /usr/lib/objrepos
Atape.driver 10.3.2.0 COMMITTED IBM AIX Enhanced Tape and
Medium Changer Device Driver
As you can see, we are at licensed internal code (LIC) level 10.3.2.0 and the level that is
required for encryption is 10.2.8.0, so we are ready, and we continue with 20.6.3, Update
Atape EKM proxy configuration on page 670. If you are not at the correct LIC level or you
have to install Atape, refer to the next section.
Atape installation procedure
Enter the following command to list the currently installed Atape.driver version:
lslpp -l Atape.driver
If you have the tape device drivers and the Storage Management Initiative Specification
(SMI-S) Agent CD, use the following instructions to install the device driver:
1. Place the CD into the CD-ROM drive on your AIX system.
2. Mount the CD over an empty directory. For example, if your CD-ROM drive is defined at
/dev/cd0 and you have an empty directory at /cdrom, issue the following command to
mount the CD:
mount -frv cdrfs /dev/cd0 /cdrom
You can create an empty directory using the mkdir command, for example:
mkdir /cdrom
Subsequent instructions assume that you have mounted the CD at mount point /cdrom.
3. Enter the following command:
cd Drivers/cdrom/AIX
4. Consult the Atape.Readme file for any important information pertaining to the device driver.
Information in this file takes precedence over information in the manual.
5. Execute the install_atape script. This script uninstalls any previous versions of Atape,
installs and commits the latest version of Atape, and then, runs cfgmgr to define your
devices.
6. Enter the following command:
cd/ unmount/cdrom
7. Remove the CD from the CD-ROM drive, and store it in a safe place.
20.6.3 Update Atape EKM proxy configuration
After installing the device driver, the addresses of the key managers have to be made known
(configured) to Atape. The servers are configured in a text file called ibmekm.conf, which is
installed in the /etc directory by the device driver.
This step consists of changing the configuration file that Atape uses to communicate with
EKM or Tivoli Key Lifecycle Manager. We change an entry in this file that consists of the
Encryption Key Manager IP address. Refer to Example 20-4.
Example 20-4 Atape Encryption Key Manager configuration file
# IBM Encryption Key Manager Configuration File
#
# (C) COPYRIGHT International Business Machines Corp. 2006
# All Rights Reserved
# Licensed Materials - Property of IBM
#
# US Government Users Restricted Rights - Use, duplication or
# disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
#
# This file contains the TCP/IP address(es) and port(s) for the Encryption Key
# Server with a configuration entry in the following formats. The IPv4 address
# entered as x.x.x.x:port. The IPv6 address entered as x:x:x:x:x:x:x:x port.
# The server is for information only and is not used. The timeout value is
# specified in seconds.
#
# The format for IPv4 address:
# server timeout address:port
# for example,
# ekmtest 10 9.12.123.1234:8050
#
# The format for IPv6 address:
# server timeout address port
# for example,
# ekmtest 10 fe80::207:30ee:edcb:d05d 8050
#
# The Encryption Key Server address and port can be a local loop back
# address 127.0.0.1:port in IPv4 format or ::1 port in IPv6 format if the server
# is on the same host or a network address and port if external to the host.
# Up to 16 server address and port entries are supported if there are multiple
# TCP/IP connections to the same server and/or multiple servers.
#
# Interoperability between IPv4 and IPv6 versions running on dual-stack hosts:
# IPv4 Client <--> IPv4/IPv6 Server using IPv4 address for EKM server
# IPv6 Client <--> IPv4 Server using IPv4 address for EKM server
# IPv6 Client <--> IPv6 Server using IPv6 address for EKM server
#
# Sample entry for a local server with a 10 second timeout using port 8050
# in IPv4 format
ekmtest 10 127.0.0.1:8050
#
# in IPv6 format
# ekmtest 10 ::1 8050
ekmonp 10 9.82.26.27:3801 <<<---------
In Example 20-4, you see the value that we added to the configuration file. The field is defined
this way:
Server - Timeout value - IPv4 address:port (for IPv4)
Server - Timeout value - IPv6 address - port (for IPv6)
Because we use IPv4, we use these values:
Server = ekmonp
Timeout value = 10 seconds
IPv4 address:port = 9.82.26.27:3801
The server value is used only for testing purposes for EKM or Tivoli Key Lifecycle Manager
connectivity, which you can see in 20.6.5, Updating the Atape device driver configuration on
page 673.
The timeout value in seconds is used when a request is sent to EKM or Tivoli Key Lifecycle
Manager. If a response is not received within the time set, Atape fails over to the next EKM or
Tivoli Key Lifecycle Manager that is defined and redrives the request. If EKM or Tivoli Key
Lifecycle Manager is on the same server as Atape, set this value low, at perhaps 10 seconds.
However, if EKM or Tivoli Key Lifecycle Manager and Atape are on separate servers and
connected using a network that is perhaps very busy at times, increase this value to
something more appropriate, such as 60 seconds.
The IP address is the IP address where EKM or Tivoli Key Lifecycle Manager is located, and
the port number is the port that EKM or Tivoli Key Lifecycle Manager uses to listen for traffic
from tape drives. The port value has to be the same value that is specified in the EKM
configuration file on the TransportListener.tcp.port or the Tivoli Key Lifecycle Manager GUI.
On this port, the key management server listens for requests from tape drives. This value is
required in both the Atape and EKM configuration files; Tivoli Key Lifecycle Manager defaults
to 3801.
20.6.4 System-Managed Encryption Atape device entries
You can set SME on a specific tape drive using the standard SMIT panels to Change/Show
Characteristics of a tape device or the command line chdev command.
Two attributes have been added for encryption:
sys_encryption yes/no
Use System Encryption FCP Proxy Manager. This attribute enables device driver SME for
a tape drive by setting the value to yes.
wrt_encryption off/on/custom
Use System Encryption for Write Commands at BOP. This attribute controls whether the
device driver sets the tape drive to encryption enabled for write commands:
When set to off, the tape drive uses encryption for read operations, and write
operations do not use encryption.
When set to on, the tape drive uses encryption for both read and write operations.
When set to custom, the device driver does not modify the current tape drive setting.
The custom setting is intended for applications using SME to control write encryption
without device driver intervention.
Our TS3500
Looking at our TS3500, you notice that it is partitioned into several logical libraries, as
reflected in Example 20-5.
Example 20-5 Our partitioned TS3500
lsdev -Cc tape
rmt0 Available 06-08-02 IBM 3580 Ultrium Tape Drive (FCP)
rmt1 Available 06-08-02 IBM 3592 Tape Drive (FCP)
smc0 Available 06-08-02 IBM 3584 Library Medium Changer (FCP)
smc3 Available 06-08-02 IBM 3573 Tape Medium Changer (FCP)
smc5 Available 06-08-02 IBM 3573 Tape Medium Changer (FCP)
Our logical library consists of the devices that are shown in Example 20-6.
Example 20-6 Our logical library
20.6.5 Updating the Atape device driver configuration
Prior to making any changes to the Atape configuration, we display the encryption attributes
using the AIX lsattr command, as well as tapeutil. Refer to Example 20-7.
Example 20-7 Using lsattr command and tapeutil to check encryption parameters on the drives
> lsattr -El rmt6 | grep encr
drv_encryption yes Drive Encryption Support False
sys_encryption no Use System Encryption FCP Proxy Manager True
wrt_encryption off Encryption for Write Commands at BOP True
> lsattr -El rmt7 | grep encr
sys_encryption no Use System Encryption FCP Proxy Manager True
wrt_encryption off Encryption for Write Commands at BOP True
tapeutil -f/dev/rmt6 encryption
Getting drive encryption settings...
Encryption settings:
Drive Encryption Capable.... Yes
Encryption Method........... Library
Encryption State............ NA
tapeutil -f/dev/rmt7 encryption
Encryption Method........... Library
Our tape drives are in an IBM TS3500 Tape Library and currently have LME turned on. If you
are changing your drives to SME from LME and attempt to use smitty tape to change the Use
system encryption FCP Proxy manager setting while in this state, you receive the message in
Example 20-8. Choose one of these actions:
If the message applies to your environment, read and follow 20.6.6, Enabling
System-Managed Encryption using the TS3500 web GUI on page 674.
If the message does not apply to your environment, continue with 20.6.7, Using SMIT to
enable System-Managed Encryption on page 676.
Example 20-8 Error message 0514-018
COMMAND STATUS
Command: failed stdout: yes stderr: no
Before command completion, additional instructions may appear below.
Method error (/etc/methods/chgAtape):
0514-018 The values specified for the following attributes
are not valid:
Drive encryption method 60 not set to system method
20.6.6 Enabling System-Managed Encryption using the TS3500 web GUI
To enable SME using the TS3500 web GUI, select Manage Library By Logical Library,
and press Enter. The panel that is shown in Figure 20-21 on page 675 opens.
Figure 20-21 Modify Encryption Method
Select the library to modify, and using the drop-down list box, select Modify Encryption
Method, and press Enter. The panel that is shown in Figure 20-22 opens.
Figure 20-22 Using the TS3500 web GUI to turn on SME for selected drives
Now that you have changed the drives to use SME, if you use tapeutil to display the
encryption settings for each drive, you see the output that is listed in Example 20-9.
Example 20-9 tapeutil drive display
>tapeutil -f/dev/rmt6 encryption
Encryption Method........... System
>tapeutil -f/dev/rmt7 encryption
Encryption State............ Off
20.6.7 Using SMIT to enable System-Managed Encryption
In Example 20-9, you note that the drives are encryption capable, the encryption method
selected is System, but the encryption state is off. The two parameters that have to be
changed for SME are not yet set. We use an AIX tool called System Management Interface
Tool (SMIT) to change these parameters. SMIT provides an alternative to the typical method
of using complex command syntax, valid parameter values, and custom shell path names for
managing and maintaining your operating system configuration.
Perform these steps:
1. Enter smitty tape, and press Enter. Figure 20-23 on page 677 shows the result.
Flexibility: Referencing Figure 20-22, note that all the drives in an SME logical library do
not have to use SME. Only this open systems encryption environment allows this flexibility.
When implementing LME, all drives in a logical library must use LME. When implementing
AME, all drives in a logical library must use AME. This requirement is not the case with
SME.
Figure 20-23 SMITTY tape
2. Highlight Change / Show Characteristics of a Tape Drive, as shown in Figure 20-23,
and then press Enter.
3. Figure 20-24 shows the results in the panel.
Figure 20-24 SMIT select drive
4. Select the drive, and press Enter. Figure 20-25 on page 678 shows the results.
Tape Drive
Move cursor to desired item and press Enter.
List All Defined Tape Drives
List All Supported Tape Drives
Add a Tape Drive
Change / Show Characteristics of a Tape Drive
Remove a Tape Drive
Configure a Defined Tape Drive
Generate Error Report
Trace a Tape Drive
Figure 20-25 Drive parameters prior to SME being turned on
5. We have to change the last two fields:
Use System Encryption FCP Proxy Manager
This attribute enables device driver SME for a tape drive by setting the value to yes.
System Encryption for Write Commands at BOP
This attribute controls whether the device driver sets the tape drive to encryption
enabled for write commands. When set to off, the tape drive uses encryption for read
operations, and write operations do not use encryption. When set to on, the tape drive
uses encryption for both read and write operations. When set to custom, the device
driver does not modify the current tape drive setting.
The custom setting is intended for applications using SME to control write encryption
without device driver intervention.
6. Using SMIT, highlight each field one at a time and change the value; then, press Enter to
start the process to change all fields. Highlighting the field and pressing F4 results in the
options that you can select, as shown in Figure 20-26.
Figure 20-26 Results of F4 list
7. The SMIT tool is careful to ensure that even after you select yes, you still have a chance to
change your mind. So, even after you select yes, press Enter, and see the display that is
shown in Figure 20-27 on page 679, you still have to confirm that you want to make the
change, so you must press Enter one more time.
Figure 20-27 Selecting the Encryption mode
The change has not taken place unless you see the panel that is shown in Figure 20-28,
which confirms that the change has been made.
Figure 20-28 Pressing Enter until rmt reflects the change
The Use System Encryption FCP Proxy Manager attribute, which enables device driver
SME for a tape drive, has been set to yes, as shown in Figure 20-29 on page 680.
Important: After highlighting yes, ensure that you press Enter until you see
Figure 20-28, which reflects that rmt7 changed. If not, the change does not take effect.
Figure 20-29 SME device driver parameter
8. The next and last parameter to change is the System Encryption for Write Commands at
BOP parameter that is shown in Figure 20-30. This attribute controls whether the device
driver sets the tape drive to encryption enabled for write commands. When set to off, the
tape drive uses encryption for read operations, and write operations do not use
encryption. When set to on, the tape drive uses encryption for both read and write
operations. When set to custom, the device driver does not modify the current tape drive
setting.
Figure 20-30 SME for Write Commands
9. As indicated previously, selecting F4 lists the options, as shown in Figure 20-31. We set
this value to on, so that the tape drive uses encryption for both read and write operations.
Figure 20-31 Select F4 for list and then select on
10.Again, you see the confirmation panel, as shown in Figure 20-32, and the instruction to
press Enter.
Figure 20-32 Confirmation still required
11.Remember that you have to press Enter one more time to confirm the change and that you
have to see the panel that is shown in Figure 20-33.
Figure 20-33 Change has been accepted
The display that is shown in Figure 20-34 on page 682 reflects that both parameters have
been changed for rmt7. This drive is almost ready to write encrypted data.
Figure 20-34 All changes for rmt7 have been made
You can use the AIX command lsattr -El rmtn | grep encryp, and then, enter tapeutil to
verify that the drive is SME ready. Refer to Example 20-10.
Example 20-10 lsattr and tapeutil display
lsattr -El rmt8 | grep encryp
sys_encryption yes Use System Encryption FCP Proxy Manager True
wrt_encryption on System Encryption for Write Commands at BOP
lsattr -El rmt7 | grep encryp
sys_encryption yes Use System Encryption FCP Proxy Manager True
wrt_encryption on System Encryption for Write Commands at BOP
> tapeutil -f/dev/rmt7 encryption
Encryption State............ On
> tapeutil -f/dev/rmt8 encryption
Figure 20-35 Drive encryption characteristics
20.6.8 Managing System-Managed Encryption and business partner exchange
Managing SME differs from managing LME. Whether to encrypt in LME is managed at the
VOLSER-level by using the BEPs. SME is managed at the drive level, because not every
drive in a logical library must have SME implemented. Implementing your decision to encrypt
a tape using SME is solved simply by directing allocations to one drive instead of another
drive.
Let us quickly review label usage. Labels inform EKM which public key to use when
encrypting the data key (DK). This encrypted data key is stored within an EEDK along with
the label and written to the cartridge. There are two EEDKs for each cartridge. EKM at your
business partners site unwraps the EEDKs, pulls out the certificate label, and uses it to do a
lookup within your business partners keystore to obtain the correct private key to decrypt the
data key.
Referring to Figure 20-36, EKM responds to a write request in the following order (these
numbers correspond to the numbers in the figure):
1. The tape drive requests the key to encrypt the tape.
2. EKM verifies that the tape device is in the drive table.
3. EKM fetches the keys and certificates for the tape device from the keystore.
4. EKM generates a random data key
5. EKM wraps it with public keys to create an EEDK.
6. EKM sends the EEDKs and (separately wrapped) data key to the tape drive.
7. The tape drive unwraps the data key and writes the EEDKs on the tape leader.
8. The tape drive encrypts data using the data key and writes encrypted data to tape.
Figure 20-36 EKM response to a write request
Referring to Figure 20-37, the following events occur when reading an encrypted cartridge at
your business partners site:
1. The tape drive receives a read request and sends the EEDKs to EKM.
2. EKM verifies the tape device in the drive table.
3. EKM fetches the required keys to process the EEDKs from the keystore.
4. EKM unwraps the EEDK using the private key of the KEK pair to recover the data key.
5. EKM wraps the data key with a key that the drive can decrypt and sends the wrapped data
key to the tape drive.
6. The tape drive unwraps the data key and uses it to decrypt the data.
Figure 20-37 EKM response to read request
The success of the read operation at your business partners site assumes two things:
You have selected the correct public key (using label specification) to encrypt the data key
when the cartridge was created.
The label that you use to encrypt also exists in your business partners keystore.
LME within the BEP has a hash option so that certificate labels do not have to match. SME
does not have this option, so you must ensure that you carefully manage the label usage
between you and your business partners. It is necessary that you and your business partner
agree on a naming convention for the business partners certificate, or that you exchange this
information with your business partner so that the correct certificate can be found within the
business partners keystore.
Sending a cartridge to a business partner entails selecting the correct public key to encrypt
the data key, and you select the correct public key by specifying the right certificate label to
use. How do you perform this task within SME? Business partner exchange for LME is
managed using labels specified within Barcode Encryption Policies. SME business partner
exchange is managed using label information that is kept in the drive table or EKM
configuration file.
You can specify these values in the drive table. Or, if you have drive.acceptUnknownDrives
set to yes in your EKM configuration, the values are taken from the EKM configuration file
global default.drive.alias1 and default.drive.alias2 parameters.
EKM provides an option to set an EKM-wide default for the primary alias and secondary alias.
Refer to Table 20-6.
Table 20-6 EKM label alias configuration parameters
These variables are used to wrap the data encrypting key when writing to a tape drive that
has not been configured with specific keys and certificates to use. The values of these
variables are used when a tape device in the drive table does not have a specific definition as
to which alias to use when writing a tape. When EKM encounters a device that does not have
a specific entry in the drive table specifying an alias (or key label) and an alternate alias, EKM
then uses the drive.default.alias1 and drive.default.alias2 variables if they are set.
This capability allows you to set the default certificate alias (or key label) and alternate
certificate alias (drive.default.alias1, drive.default.alias2) for encryption on newly added
devices. You can have EKM fully configure the device with associated certificates when the
device contacts EKM. If you choose not to have EKM fully configure the device with
associated certificates when the device is added to the drive table, you can do so after the
tape drive has been added to the tape drive table, using the moddrive command.
Changing which encryption label to use is as easy as issuing the moddrive command prior to
allocation. You can use the moddrive command to modify drive information in the drive table.
The equivalent command is modifydrive. See Example 20-11 for the syntax of the moddrive
command.
Example 20-11 moddrive command
moddrive -drivename drivename [ -rec1 alias -rec2 alias]
-drivename drivename specifies the serial number of the tape drive.
Example: moddrive -drivename 000123456789 -rec1 newalias1
For more information about these configuration variables, refer to the IBM System Storage
Tape Enterprise Key Manager, Introduction Planning and User Guide, GA76-0418.
Parameters Definition Required
drive.default.alias1 Provides a default alias, to a drive, for use if an alias is
not specified in the drive table.
Yes
drive.default.alias2 Provides a default alias, to a drive, for use if an alias is
not specified in the drive table.
Yes
20.7 Application-Managed Encryption
Application-Managed Encryption (AME) is currently supported with IBM Tivoli Storage
Manager. In this section, we describe how to implement encryption in the IBM Tivoli Storage
Manager environment. We contrast IBM Tivoli Storage Manager encryption with LME and
SME and explain when to use each method. IBM Tivoli Storage Manager uses the AME
method, as shown in Figure 20-38.
Figure 20-38 Application-Managed Encryption architecture
By design, when implementing AME, the application is aware of encryption. IBM Tivoli
Storage Manager creates and manages the policies and the keys and passes this information
between the application layer and the 3592-E05 drive.
20.7.1 IBM Tivoli Storage Manager overview
IBM Tivoli Storage Manager is an enterprise-wide storage management application. It
provides automated storage management services to workstations, personal computers, and
file servers from a variety of vendors, with a variety of operating systems.
How IBM Tivoli Storage Manager stores client data
IBM Tivoli Storage Manager stores data using policies. Policies are rules that determine how
the client data is stored and managed. The rules include where the data is initially stored, how
many backup versions are kept, how long archive copies are kept, and so on. You can have
multiple policies and assign policies as required to specific clients, or even to specific files. A
policy assigns a location in server storage where data is initially stored. Server storage is
divided into storage pools that are groups of storage volumes. Server storage can include
hard disk, optical, and tape volumes.
Policies are rules that you set at the IBM Tivoli Storage Manager server to help you manage
client data. Policies control how and when client data is stored, for example:
How and when files are backed up and archived to server storage
How space-managed files are migrated to server storage
The number of copies of a file and the length of time that copies are kept in server storage
Referring to Figure 20-39, when a IBM Tivoli Storage Manager client is registered, it is
associated with a policy domain. Within the policy domain are the policy set, management
class, and copy groups. When a client backs up, archives, or migrates a file, it is bound to a
management class. A management class and the backup and archive copy groups within it
specify where files are stored and how they are managed when they are backed up, archived,
or migrated from the client. Storage pools are the destinations for backed-up, archived, or
space-managed files. Copy groups specify storage pools for backed-up or archived files.
Management classes specify storage pools for space-managed files. Storage pools are
mapped to device classes, which represent devices. The storage pool contains volumes of the
type indicated by the associated device class. For example, a storage pool that is mapped to
a device class with a device type of 8 MM contains only 8 mm tapes. Files that are initially
stored on disk storage pools can migrate to tape or optical disk storage pools if the pools are
set up in a storage hierarchy.
Figure 20-39 How clients, server storage, and policies work together
20.7.2 IBM Tivoli Storage Manager support for 3592 drive encryption
IBM tape device encryption is now supported for 3592-E05, 3592-E06, and 3592-EU6 drives.
When enabled, IBM Tivoli Storage Manager handles encrypting and decrypting data on
tapes, according to specifications that are set when defining the device class. You must use
IBM Tivoli Storage Manager 5.4.3 or 5.5.1 or later when using the TS1130 with IBM Tivoli
Storage Manager.
Encryption keys are managed by the IBM Tivoli Storage Manager and not by the Encryption
Key Manager. IBM Tivoli Storage Manager generates and stores the keys in the IBM Tivoli
Storage Manager server database. The data keys that are required to decrypt the cartridge
data are not kept on the data cartridge, as they are with LME and SME. Data is encrypted
during WRITE operations, when the encryption key is passed from the server to the drive.
Data is decrypted on READ operations. The AME method is only supported for storage pool
volumes.
Data that is encrypted using IBM Tivoli Storage Manager is incompatible with data that is
encrypted using LME or SME.
20.7.3 Implementing Application-Managed Encryption
To utilize drive encryption, your IBM Tivoli Storage Manager environment must be set up so
that all drives in a library support the new encryption format. In addition, all drives within a
logical library must use the same method of encryption. An environment is not supported that
has several drives using AME, and several drives using LME or SME methods.
When using encryption-capable drives with a supported encryption method, a new format is
used to write encrypted data to tapes. If volumes are written to use the new format and then
returned to scratch, they contain labels that are only readable by encryption-enabled drives.
You must relabel these scratch volumes to use them in a drive that is not enabled for
encryption, either because the hardware is incapable of encryption or because the encryption
method is set to NONE.
Encryption is enabled using the DRIVEENCRYPTION parameter within the device class and
can affect several storage pools, as shown in the example in Figure 20-40.
Figure 20-40 Device class impact
Setting the device class DRIVEEncryption parameter
The device class DRIVEEncryption parameter (abbreviated as drivee) is supported on the
3592-E05, which is also known as the TS1120 (3592-2 and 3592-2C), and the 3592-E06,
which is also known as the TS1130 (3592-3 and 3592-3C) formats. It specifies whether drive
encryption is enabled or can be enabled. The three types of drive encryption that are
available with the 3592-E05 and 3592-E06 drives are AME, SME, and LME. These methods
are defined through the hardware. IBM Tivoli Storage Manager supports all three encryption
methods with the DRIVEEncryption parameter. This parameter is used to ensure IBM Tivoli
Storage Manager compatibility with hardware encryption settings for empty volumes. Refer to
TSM
Logical
Library
Storage Pool A Storage Pool C Storage Pool B
Device Class A
DRIVEE=ON
Device Class B
DRIVEE=OFF
Figure 20-41 DRIVEEncryption parameter
Note the following information:
To utilize the AME method, in which IBM Tivoli Storage Manager generates and manages
encryption keys, the parameter must be set to ON. This setting permits the encryption of
data for empty volumes. When the parameter is set to ON, backup operations fail if the
hardware is configured for another encryption method.
To utilize the LME or SME method, the parameter must be set to ALLOW. This setting
specifies that IBM Tivoli Storage Manager is not the key manager for drive encryption, but
this setting allows the hardware to encrypt the volumes data through one of the other
methods. Data is only encrypted by setting the ALLOW parameter and configuring the
hardware to use one of these methods. Volumes are not automatically encrypted by
specifying this parameter.
To disable any method of encryption on new volumes, the parameter must be set to OFF.
If the hardware is configured to encrypt data through the LME or SME method, and
DRIVEEncryption is set to OFF, backup operations fail.
The DRIVEEncryption parameter is optional. The default value allows the LME or SME
methods.
Defining an encrypted storage pool
Assume that you want to encrypt storage pool volumes and use IBM Tivoli Storage Manager
to manage encryption. This method is defined through the device class.
Complete the following steps:
1. Define your library: define library 3584 libtype=SCSI
2. Define a device class 3592_ENCRYPT so that storage pool volumes are encrypted: define
devclass 3592_encrypt library=3584 driveencrypt=on
3. Define a storage pool named 3592_ENCRYPT_POOL with a MAXSCRATCH value of 10:
define stgpool 3592_encrypt_pool 3592_encrypt maxscr=10
Displaying encryption status
To display the status of encryption for a particular devclass, issue the Query devclass
command. To display a detailed report of the 3592 device class, as shown in Figure 20-42 on
page 690, enter the following command:
query devclass 3592 format=detailed
Note: In Figure 20-42 on page 690, Drive Encryption is set to On.
Figure 20-42 Detailed Devclass query report
To check the status of a volume that results in a detailed report, as shown in Figure 20-43,
use the following command:
query volume 000642 format=detailed
Figure 20-43 Detailed query volume command report
In this example in Figure 20-43, the Drive Encryption Key Manager field indicates Tivoli
Storage Manager. The volume is encrypted, and IBM Tivoli Storage Manager performed the
key management.
Changing your encryption method and hardware configuration
If you want to update the DRIVEEncryption parameter for a given set of volumes, the volumes
have to be returned to scratch status. Updating the parameter only affects empty volumes.
For example, if you currently have AME enabled, and you want to update DRIVEEncryption to
OFF, only empty volumes are affected by the change. Filling volumes continue to be encrypted,
although new volumes are not encrypted. If you do not want currently filling volumes to
continue being encrypted, the volume status must be changed to READONLY. This status
ensures that Tivoli Storage Manager does not append any more encrypted data to the
volumes. You can use the MOVE DATA command to transfer the data to a new volume
following the update of the DRIVEEncryption parameter. The data then is available in an
unencrypted format.
When migrating from one hardware configuration to another hardware configuration, you
have to move your data from the old volumes to new volumes with new encryption keys and
key managers. Set up two logical libraries and storage pools (each with a separate encryption
method) and migrate the data from the old volumes to the new volumes. This action
eliminates volumes that were encrypted using the original method.
Assume that you have volumes that were encrypted using the LME method and you want to
migrate to the AME method. IBM Tivoli Storage Manager is unable to determine which
encryption keys are required for data on these volumes, because the librarys Encryption Key
Manager stores these keys and IBM Tivoli Storage Manager does not have access to them.
Table 20-7 illustrates considerations when changing your hardware encryption method.
Table 20-7 Hardware and volume compatibility
20.7.4 IBM Tivoli Storage Manager encryption considerations
This section explores considerations that are unique to AME using IBM Tivoli Storage
Manager.
Safeguarding encryption keys
When implementing AME using IBM Tivoli Storage Manager, take extra care to secure the
backups of the database. The keys to encrypt and decrypt data using these methods are
stored in the IBM Tivoli Storage Manager server database. To restore your data, you must
have the correct database backup and corresponding encryption keys to access your
information. Ensure that you back up the database frequently and safeguard the backups to
prevent data loss or theft. Anyone who has access to both the database backup and
encryption keys has access to your data.
Business partner exchange
LME and SME include on each encrypted cartridge two EEDKs, which contain the data key
that was used to encrypt the data on the cartridge. AME using IBM Tivoli Storage Manager
does not. The data key is kept within the IBM Tivoli Storage Manager database.
Volumes with
no encryption
Volumes with
AME
Volumes with
LME
Volumes with
SME
Desired hardware
method=None
No special
consideration
Incompatible scratch tape labels will be unreadable and will have to be
relabeled
Desired hardware
method=Application
No special
consideration
Incompatible
Desired hardware
method=Library
Incompatible No special
consideration
Ensure that the same
Key Server is still used
Ensure that the same
Key Server is still used
No special
consideration
Exchanging AME-encrypted cartridges with business partners is a challenge as compared to
LME or SME, because LME and SME include a copy of the data key on the cartridge. If you
want to exchange AME cartridges, you must also share a copy of the IBM Tivoli Storage
Manager database, because the data key that is used to encrypt the data is only available
using the IBM Tivoli Storage Manager database.
If your business dictates that you regularly have to share data with business partners, outside
vendors, and so forth, continue to create this data as you do today, which is probably outside
of IBM Tivoli Storage Managers control. If you want to encrypt this data, you encrypt it using
LME or SME. This encryption environment is referred to as a hybrid.
Backing up the IBM Tivoli Storage Manager database
Implementing encryption does not affect or cause any changes to the process that you
currently use to back up your IBM Tivoli Storage Manager databases.
20.8 IBM 3494 with TS1120 or TS1130 encryption
In this section, we review the 3494 web GUI panels and the values that are required to
implement LME using BEPs on a 3494 using TS1120 drives. The same principles apply when
using TS1130 drives. We review the web GUI panels for LME ILEP, AME, and SME.
20.8.1 Review the 3494 encryption-capable drives
As shown in Figure 20-44, we have four drives in our 3494 library that are encryption capable.
The drives are devices 100, 101, 300, and 301.
Follow these steps to implement LME using BEPs on a 3494 using TS1120 drives:
1. Select Administer Library Manager Manage 3592 Drives. In our examples, we work
with drives 100 and 101.
Figure 20-44 3494 encryption-capable drives
2. Select Administer Library Manager Manage Encryption Drive Encryption
Settings. The results are shown in Figure 20-45.
Note that drives 100 and 101 are already set for Library-Managed Encryption; however,
they both use Internal Label - Selective Encryption scratch encryption policies.
Update the panel with current Vital Product Drive (VPD) information by selecting Get VPD
(not Set VPD) and, then, clicking Go.
Figure 20-45 Drive Encryption Settings
3. The 3494, like the TS3500 web GUI, has help panels to guide you. For example, if you
have any questions about the Drive Encryption Settings panel, select the question mark
character (?) in the upper-right corner of the panel. A User Assistance panel is displayed,
Figure 20-46 3494 web GUI help panel
4. To set the drive encryption method, select the drives that you want to change, select
Set VPD, and click Go, as shown in Figure 20-45 on page 693. For our example, we select
drive 100 only, which results in the display that is shown in Figure 20-47.
Figure 20-47 Drive Encryption Settings (Set VPD)
5. For our example, we select Library Managed, and click Apply. (Note that on this panel,
you can also select Application Managed or System Managed. If you select either one of
those encryption methods, no other panel displays and you are finished with the 3494 web
GUI.
Selecting Library Managed results in the panel that is shown in Figure 20-48.This panel is
where you select either Barcode, or if you are implementing Symantec NetBackup, you
can select either the Internal label - Selective Encryption or Internal Label - Encrypt All
policy method. Internal Label Encryption Policies are referred to as ILEP.
Figure 20-48 Library-Managed Scratch Encryption Policy
6. For our example, select Barcode, and then, click Apply, which results in the panel that is
shown in Figure 20-49. Note that for drive 100 in the Scratch Encryption Policy column, the
value has changed from Internal Label-selective Encryption to Barcode. After you ensure
that the correct BEPs are set, you are ready to encrypt data. We now look at specifying a
Barcode Encryption Policy (BEP).
Figure 20-49 Drive 100 after LME and Barcode Encryption Policy changes
20.8.2 Specifying a Barcode Encryption Policy
Select Administer Library Manager Manage Encryption Barcode Encryption
Policy. The panel that is shown in Figure 20-50 opens. The panel reflects three barcode
encryption policies that are already created for three VOLSER ranges.
Figure 20-50 Barcode Encryption Policy
To create a new Barcode Encryption Policy, select the Create action, and then, click Go,
which results in the panel that is shown in Figure 20-51.
Figure 20-51 Blank specify Barcode Encryption Policy panel
A Barcode Encryption Policy is a range of cartridge VOLSERs and 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 LME, a Barcode
Encryption Policy controls cartridge encryption by VOLSER ranges in all logical libraries that
have LME with Barcode Encryption Policy selected. Stated another way, if you have defined
multiple policies (overlap is not allowed), they all are effective simultaneously, and they affect
which cartridges are encrypted in every defined library-managed logical library in a TS3500
that is enabled to encrypt using Barcode Encryption Policies.
When implementing a Library-Managed BEP, you not only specify which cartridges to encrypt
but also the public keys that are used to encrypt the data key. You manage this specification
by directing future allocations to certain Barcode Encryption Policies through VOLSER
ranges. The BEP that you select depends on the cartridge destination.
For our example, which is shown in Figure 20-52, we create a BEP to encrypt all cartridge
VOLSERs from ATS000 - ATS999. Each cartridge that falls within that sequence will be
encrypted using a public key that is referenced by label a for key label 1 and a public key that
is referenced by label b for key label 2. When a certificate is imported into a keystore, a label
is assigned to it. You enter this label on this panel, which, in our example, is label b and
label a. When an encrypted cartridge is created, two EEDKs are also created and stored on
the cartridge. In addition to the encrypted Data Key, each EEDK has a pointer to the public
key that was used to encrypt the Data Key. The pointer can either be the label of the
certificate or a hash value that is based on the public key. Regardless of which method is
used, EKM uses the value to identify the correct private key to use to decrypt the encrypted
data key.
Because we do not plan to send this cartridge off-site, we create each label in clear mode.
For an explanation of clear label mode compared to the hash label, refer to Creating a BEP
using hash values on page 666.
Figure 20-52 Barcode policy create
Figure 20-53 reflects the new Barcode Encryption Policy that we just created.
Figure 20-53 Newly created Barcode Encryption Policy
With the following Barcode Encryption Policies in place, imagine this scenario. What if a
cartridge with the VOLSER of RAJ001 is mounted on a drive that has LME with the Barcode
Encryption Policy specified? Will it be encrypted? What keys will be used to encrypt the data
key (DK)? Remember that on the TS1120, the data key is enclosed within a data structure
called EEDK1 and EEDK2. Each EEDK includes the data key encrypted by a public key,
which is pointed to by the key label that is specified in the Barcode Encryption Policy.
Therefore, in our scenario, yes, the cartridge will be encrypted, because it falls within the
VOLSER range of the RAJ000 - RAJ999 BEP. The first EEDK (EEDK1) on the cartridge will
contain the data key encrypted with the key pointed to by the following label and in HASH
format:
internal_label_nbu_3505_a
Key 2 is not specified, so a default label value will be used to encrypt the data key and create
EEDK 2. Use this order of default key labels for the TS1120:
1. Drive table, if specified
2. EKM configuration.properties file, if no key label is specified in the drive table
20.8.3 Entering the EKM IP address and key labels
Before you can specify a key label as part of a BEP or within the key label remapping
function, identify the key label to the 3494, as shown in the panel in Figure 20-54 on
page 699.
To open this panel from the 3494 web GUI, select Administer Library Manager Manage
Encryption Key Label Entry / EKM IP Info. The current maximum number of labels that
you can specify is 64. This panel is also where you specify the IP address for the Encryption
Key Manager (EKM) that is used for LME.
Figure 20-54 Key label entry
20.8.4 ILEP key label mapping
If implementing Internal Label Encryption Policies (ILEP), a function within the 3494 web GUI
allows you to map the ILEP-generated label into a more user-friendly label. ILEP-generated
labels can get quite long and are not easy to read.
To access the panel that is shown in Figure 20-55 on page 700, select Administer Library
Manager Manage Encryption ILEP Key Label Mapping. In the example, you can see
that for testing purposes we remapped the label internal_label_nbu_3505_a to a key label
named test1.
Also, be aware that both labels must already exist in the key label table, which we describe in
20.8.3, Entering the EKM IP address and key labels on page 698. If the key labels do not
already exist in the table, you cannot remap them using this function.
Important: The IP address that is specified in this panel is for LME-enabled drives only. If
using SME on open systems, the pointer for EKM is kept within the device driver
configuration file. AME does not use an EKM. The z/OS uses SME only.
Figure 20-55 ILEP Key Label Mapping
We have completed our description of the 3494 and TS1120 on open systems.
Chapter 21. Tape data encryption with i5/OS
In this chapter, we describe Library-Managed Encryption (LME) with the IBM TS1120
Enterprise Tape Drive Model 3592-E05 and the IBM LTO4 tape drive TS1040 for i5/OS
environments.
Planning for tape encryption with i5/OS and clarification of the software and hardware
prerequisites, together with considerations for disaster recovery (DR) and sharing tape
cartridges with partners
Describing detailed implementation procedures that provide guidance for configuring LME
for TS1120 and LTO4 drives
21
21.1 Planning for tape data encryption with i5/OS
In this section, we provide planning information about the hardware and software
prerequisites for using tape encryption with i5/OS and the IBM TS1120 Enterprise Tape Drive
and the IBM TS1040 LTO4 Tape Drive. We describe important considerations pertaining to
the selection of the EKM keystore, the encryption policies, the EKM setup for disaster
recovery, and sharing tape cartridges with partners. Then, we provide an overview of the
required implementation steps for tape encryption with i5/OS.
21.1.1 Hardware prerequisites
Currently, the following IBM tape drives support hardware tape encryption:
IBM TS1120 Enterprise Tape Drive encryption capable with feature code (FC) 9592
(earlier TS1120 models can be upgraded to be encryption capable through the chargeable
feature FC5592)
IBM TS1040 LTO4 Fibre Channel or serial-attached Small Computer System Interface
(SCSI) (SAS) tape drive (encryption support for LTO4 tape cartridges only)
IBM TS1050 LTO5 Fibre Channel or SAS tape drive (encryption support for LTO4 or LTO5
tape cartridges only)
To enable these encryption-capable IBM tape drives for LME, which is required for i5/OS, they
must reside in one of the following supported IBM tape libraries:
TS1120 supported in these IBM tape libraries:
IBM TS3400 library
TS3500 library frame models L23 or D23
TS1040 LTO4 supported in these IBM tape libraries:
IBM TS3100 and TS3200 libraries (AAS orders only) Release 4 or later with
Transparent LTO Encryption feature (FC5900)
IBM TS3310 library Release 4 or later with Transparent LTO Encryption feature
(FC5900) and Encryption Configuration (FC9000)
IBM TS3500 library frame models L53 or D53 Release 7A or later with Transparent
LTO Encryption feature (FC1604) and TS1040 Fibre Channel Model 3588-F4A only
TS1050 LTO5 supported in these IBM tape libraries:
IBM TS3100 and TS3200 libraries (AAS orders only) Release 4 or later with
Transparent LTO Encryption feature (FC5900)
IBM TS3310 library Release 4 or later with Transparent LTO Encryption feature
(FC5900) and Encryption Configuration feature (FC9000)
3584-L32/D32, 3584-L52/D52, 3584-L53/D53 with Transparent LTO Encryption feature
(FC1604) and TS1050 Fibre Channel Model 3588-F5A only
The minimum TS1120 drive firmware level to support LME is 1942.
LME with the Encryption Key Manager: Within this chapter, we focus on
Library-Managed Encryption (LME) with the Encryption Key Manager (EKM) running on
i5/OS. There is no requirement to have EKM installed on i5/OS to use tape encryption for
i5/OS, because with LME, EKM can be installed on any supported platform.
Chapter 21. Tape data encryption with i5/OS 703
For the IBM TS3500, use FC1690, Advanced Library Management System (ALMS), to set
encryption methods at a logical library level flexibly and to allow the intermixing of
encryption-capable drives with non-encryption-capable drives within a logical library.
Without ALMS, all logical libraries of the same technology (either TS1120 or LTO) must be set
to the same encryption mode, which has the following implications:
Encryption-capable drives added to a non-ALMS library with older non-encryption-capable
drives cannot be encryption enabled.
Older non-encryption-capable drives added to a non-ALMS encryption library will be set to
restricted mode and will not be available for use.
21.1.2 Software prerequisites
You must meet the following software prerequisites to use tape encryption with the IBM
Encryption Key Manager component for the Java platform (EKM) installed on i5/OS:
i5/OS V5R3 or later
Crypto Access Provider 128-bit, product number 5722-AC3 (V5R3 only)
IBM HTTP Server for i5/OS, product number 5722-DG1 (TS1120 tape encryption with
IBMi5OSKeyStore only)
Digital Certificate Manager, product number 5722-SS1, option 34 (TS1120 tape encryption
with IBMi5OSKeyStore only)
Java Developer Kit 1.5, product number 5722-JV1, *BASE and option 7 (V5R3 only)
J2SE 5.0 32 bit, product number 5722-JV1, *BASE and option 8 (V5R4 only)
The latest Java Group program temporary fix (PTF) (SF99269 for V5R3 and SF99291 for
V5R4)
5722-JV1 PTF SI26811, which provides IBM Java 5.0 Service Release 4, which contains
EKM Release 1 code (V5R4 only)
5722-SS1 PTF SI25094, which provides the EKM default configuration file and strEKM
script (V5R4 only)
5722-SS1 PTF SI26705, which provides the IBM EKM Release 1 code, default
configuration file and strEKM script (V5R3 only)
5722-BR1 PTF SI24934, which provides a new media density FMT3592A2E for Backup,
Recovery and Media Services (BRMS) to help identify encrypted tape cartridges (V5R4
only)
5722-BR1 PTF SI24933, which provides a new media density FMT3592A2E for BRMS to
help identify encrypted tape cartridges (V5R3 only)
Note: Use the i5/OS Digital Certificate Manager to administer an IBMi5OSKeyStore for
TS1120 tape encryption. It does not support the symmetric keys that are required for
LTO4 tape encryption.
Requirements: LME for LTO4 tape drives requires EKM Release 2 code and IBM Java 5.0
Service Release 5, which adds support for handling symmetric data keys.
The plan is to release EKM Release 2 code (build 20070503) for i5/OS with IBM Java 5.0
Service Release 5. This code includes the IBM Java keytool that is required for generating
and storing symmetric keys support, which will be made available as a 5722-JV1 PTF for
i5/OS. To download a more recent version of the EKM code, refer to the IBM support website:
http://www-1.ibm.com/support/docview.wss?rs=1139&context=STCXRGL&dc=D400&uid=ssg1S
4000504
The major reason against using a single EKM server is that if this EKM server fails, there is no
way to read from or write to newly mounted encrypted tapes before you manually recover the
failed EKM server.
Another reason to set up a secondary EKM server is that an EKM server that was started in a
batch job currently cannot be dynamically reconfigured using the EKM Admin Console.
Figure 21-1 shows a redundant two EKM server setup. If one EKM server fails, the IBM tape
library, which has been configured with two redundant EKM paths, that is, EKM server TCP/IP
addresses, automatically attempts to fail over to the second EKM server. After the failover, the
tape library retrieves the data keys that are required for the encryption and decryption of the
tape cartridges. Having two redundant EKM servers requires keystore, configuration file, and
drive table synchronization, which you can perform automatically at regular intervals through
defined parameters in the EKM configuration file.
For additional details about setting up a secondary EKM server and synchronizing EKM
servers, refer to Additional information on page 458.
Figure 21-1 Redundant EKM server configuration using two systems
Important: For availability reasons, set up two redundant EKM servers on separate host
systems that are at separate locations.
Data Path
EKM Path 2
(TCP/IP)
FTP
Saved
EKM
data
Data Path
EKM Path 1
(TCP/IP)
EKM sync.
(TCP/IP)
i5/OS
running EKM Server 1
using
Tape Encryption
i5/OS
running EKM Server 2
using
Tape Encryption
IBM Tape Library
Library-Managed Encryption
with encryption-enabled tape
drives
System i5 Server 2 System i5 Server 1
If EKM server availability and recovery time are not issues and you want a single EKM server
configuration, be aware of the disaster recovery implications. Install the EKM server on
another logical partition (LPAR) or on a system other than the system from which you take
system backups with tape encryption. Otherwise, you will not have a way to perform a quick
system restore from the encrypted tapes without a lengthy and error-prone configuration of a
new EKM server from the unencrypted saved EKM data.
For this reason, this distributed EKM server configuration, which is shown in Figure 21-2, is
the only single EKM server configuration that is supported by IBM Rochester System i
development.
Figure 21-2 Single distributed EKM server configuration
21.1.4 EKM keystore considerations
There are two types of supported keystores for installing the Encryption Key Manager (EKM)
on i5/OS:
An IBMi5OSKeyStore that is managed through i5/OS Digital Certificate Manager, which is
i5/OS-specific and supports no storage of symmetric keys so that it can be used for
TS1120 tape encryption only
A Java Cryptography Extension Keystore (JCEKS) that is supported on all platforms and
supports both LTO4 encryption with the storage of symmetric keys and TS1120 tape
encryption with the storage of asymmetric keys
Use the IBMi5OSKeyStore only for TS1120 tape encryption environments where there is no
LTO4 or LTO5 encryption used and where EKM (both a primary and an optional secondary
EKM server for high availability) is installed on i5/OS only.
Important: Taking regular unencrypted backups of the EKM keystore *.KDB file, drive table,
and KeyManagerConfig.properties EKM configuration file, for example, through prior
transfer (using FTP) to another system, is crucial for restoring a working EKM server
configuration after a disaster before you can regain access to the encrypted tape data.
System i5
using
Tape Encryption
Other System
running EKM
(keystore, config-file,
drivetable)
IBM Tape Library
with encryption-enabled drives
Data Path EKM Path
(TCP/IP)
FTP
Saved
EKM
data
System i5
using
Tape Encryption
Other System
running EKM
(keystore, config-file,
drivetable)
IBM Tape Library
with encryption-enabled drives
Data Path EKM Path
(TCP/IP)
FTP
Saved
EKM
data
In all other situations, a JCEKS keystore is either required when LTO4 or LTO5 encryption is
used or advised when the EKM primary server and secondary server reside on separate
platforms in order to ease synchronization of both of the EKM servers. For information about
automatic synchronization between two EKM servers, refer to Additional information on
page 458.
Table 21-1 shows a comparison between the supported features of a JCEKS keystore and an
IBMi5OSKeyStore.
Table 21-1 Comparison between the IBMi5OSKeyStore and the JCEKS keystore
21.1.5 TS1120 Tape Encryption policy considerations
Three methods of defining encryption policies are available to determine which encryption
keys from the EKM keystore (referenced by key labels or aliases) are used for TS1120 tape
encryption. We list these methods in the order of priority that they are used by EKM:
Default global key aliases that are defined in the EKM configuration file
Default drive key aliases that are defined in the EKM drive table
Barcode Encryption Policies that are defined in the IBM TS3500 Tape Library
Default global key aliases are defined in the EKM configuration file through the parameters
drive.default.alias1 and drive.default.alias2, which can be set to the default key labels to be
used for the EEDK1 and EEDK2. We recommend that you define default global key aliases
when using the parameter setting drive.acceptUnknownDrives = true to make sure that
certificates for generating or decrypting EEDK1 and EEDK2 are associated with new drives
that are automatically added to the drive table. To implement default global key aliases, refer
to Customizing the EKM configuration file on page 456.
You use default drive key aliases to associate certificates with 3592 drive serial numbers. You
define them by using the rec1 and rec2 parameters when you manually create or modify an
entry in the EKM drive table using the EKM Admin Console adddrive and moddrive
commands. Defining default drive key aliases is useful if separate (logical) tape libraries
communicating with the same EKM server use separate encryption keys, for example,
because only a subset of libraries is used for sharing tape cartridges with business partners.
For reference information about the EKM Admin Console commands, refer to the IBM System
Storage Tape Enterprise Key Manager, Introduction Planning and User Guide, GA76-0418.
Only one keystore: Each EKM server only supports one keystore so you must decide
whether to use an IBMi5OSKeyStore or JCEKS keystore.
Supported feature IBMi5OSKeyStore JCEKS
TS1120 (asymmetric keys) Yes Yes
LTO4 or LTO5 (symmetric keys) No Yes
Supported platforms i5/OS only All
Graphical user interface Yes No
Barcode Encryption Policies (BEPs) are supported with the IBM System Storage TS3500
Tape Library only. Use BEPs to specify which VOLSER ranges to encrypt (and which to not
encrypt) and which certificates, referred to by the specified key labels, to use for the
encryption process. A key mode that is specified for the two key labels determines the method
by which EKM identifies the public-private keys to use for generating and decrypting the
EEDKs. There are three choices for key mode:
Default label Use the key label, default drive key alias, or default global key alias, which
is configured at the encryption key manager.
Clear label The key is referenced by the specified key label.
Hash label The key is referenced by a computed value from the public key that is
referenced by the specified key label.
Using a Hash label is especially helpful for sharing tapes with a business partner, because
the certificate can be imported into the keystore with another label than the label with which it
was exported. That way, both partners do not have to agree on a common key label to use.
For additional information about sharing tape cartridges, refer to 21.1.6, Considerations for
sharing tapes with partners on page 707.
Figure 21-3 shows an example from the IBM System Storage TS3500 Tape Librarys IBM
UltraScalable Specialist Cartridges Barcode Encryption Policy view. This view shows a
user-defined BEP for the VOLSER range J10000 - JZZZZZ using a Hash label to refer to the
public key certificate from the business partner.
Figure 21-3 IBM UltraScalable Specialist: TS3500 Tape Library Barcode Encryption Policy panel
21.1.6 Considerations for sharing tapes with partners
This section describes approaches for sharing encrypted 3592 tape cartridges and encrypted
LTO4 tape cartridges.
Sharing encrypted 3592 tape cartridges
If you plan to share encrypted 3592 tape cartridges with partners, do not provide the partners
with the private part of the key encryption key (KEK) that is used for decryption for security
reasons. A private key is intended to be kept safely in your organization and never provided to
other organizations. Sharing a private key is a security risk, because anyone else with access
to your private key can read your encrypted tape data.
On i5/OS with the Digital Certificate Manager (DCM) or on other platforms with the IBM Key
Management tool as part of the IBM Java Runtime Environment (RTE), you can export the
the digital certificate that is used for tape encryption into a file that can be imported into a
partners EKM keystore. You must be careful not to export the full certificate, which holds the
public key and corresponding private key, but only the public key part of the certificate. In
21.2.3, Importing and exporting encryption keys on page 732, we describe the detailed
procedures to export and import public-private key certificates as Public Key Cryptographic
Standards 12 or PKCS#12 binary files and public key only certificates as Base64_encoded text
files.
You can store two sets of EEDKs on a 3592 tape cartridge (specify your partners public key
certificate as the second key label), depending on your encryption policy. Your encryption
policy is either in your EKM configuration file if using default key labels, in the drive table
entries, or in your TS3500 library BEP. Enable only the selected business partner, who owns
the corresponding private key, to read your 3592 cartridges that are newly written with
encryption from beginning of tape (BOT).
To share already encrypted 3592 cartridges with existing data, you can rekey the cartridges
with the IBM Tape Library Specialist Web GUI. Refer to Rekeying encrypted 3592 cartridges
on page 747.
For exporting certificates, including the public key and the private key from an i5/OS keystore,
to an EKM keystore on a platform other than i5/OS for redundancy or disaster recovery,
consider that the i5/OS DCM exports certificates in the PKCS#12 Version 3 file format.
Therefore, the target keystore must support the same format, or the exported certificate file
must be converted, for example, by using the OpenSSL open source utility.
Sharing encrypted LTO4 and LTO5 tape cartridges
The possibilities for sharing encrypted LTO4 and LTO5 cartridges are limited compared to the
inherent business-to-business model of the TS1120 two-layer encryption algorithm. TS1120
encryption supports sharing encrypted cartridges by securing the data key with two separate
certificates. LTO tape drive encryption uses a single-layer symmetric encryption algorithm.
You can always provide the symmetric key certificate that was used for a specific encrypted
LTO4 cartridge to the partner. The EKM audit metadata XML file that is specified in the EKM
configuration file provides the information regarding which symmetric key was used for a
specific cartridge volume serial number. Refer to Example of the EKM audit metadata XML
file on page 748.
However, sharing your symmetric data key causes a security risk that anyone else who
obtains your symmetric data key can read your LTO4 or LTO5 cartridges, which were
encrypted with this same data key. You can create a set of symmetric keys in the EKM
keystore to be used across the pool of LTO4 or LTO5 cartridges. This set increases security
over sharing cartridges with partners, because there is no control over which key alias from
this set will be used for a specific LTO4 or LTO5 cartridge serial number. With the IBM TS3500
Public key: Share encrypted 3592 tapes with partners by importing your business
partners certificate, including only the public key but not the private key, into your EKM
keystore.
Note: Existing encrypted 3592 tape cartridges will continue to use their EEDK1 and
EEDK2 that were originally stored with the first write on the cartridge, even if the EKM
encryption policy is changed.
Tape Library, a feasible workaround to prevent sharing your own symmetric data keys might
be to define a dedicated data key within a BEP for an LTO4 or LTO5 cartridge serial number
range to share with the partner.
21.1.7 Steps for implementing tape encryption with i5/OS
This section provides an overview of the required steps for implementing tape encryption with
i5/OS. We also summarize the required steps for installing EKM in i5/OS that we described in
15.4, Installing EKM in i5/OS on page 450.
Consider these prerequisites:
Ensure that the hardware and software prerequisites are met. Refer to 21.1.1, Hardware
prerequisites on page 702 and 21.1.2, Software prerequisites on page 703.
Consider the EKM backup and disaster recovery concept. Refer to 21.1.3, Disaster
recovery considerations on page 704.
Determine the type of EKM keystore to use. Refer to 21.1.4, EKM keystore
Determine the encryption policies to use. Refer to 21.1.5, TS1120 Tape Encryption policy
Determine requirements for the key and certificate, especially for sharing cartridges. Refer
to 21.1.6, Considerations for sharing tapes with partners on page 707.
Implementing tape encryption with i5/OS requires the following major steps:
1. Install a primary or single EKM server on i5/OS. Refer to 15.4.1, New installation of the
2. Create an EKM keystore and encryption keys. Refer to 21.2.1, Creating an EKM keystore
and certificate on page 710.
3. Configure EKM for TS1120, LTO4, or LTO5 tape encryption. Refer to 15.4.3, Configuring
EKM for tape data encryption on page 455.
4. Configure the IBM tape library for LME. Refer to 21.2.2, Configuring the TS3500 library
for Library-Managed Encryption on page 722.
5. Back up the EKM data (keystore, configuration file, and drive table file).
6. Optionally, install a secondary EKM server on another i5/OS system. Refer to 15.4.1,
New installation of the Encryption Key Manager on page 450.
21.2 Setup and usage of tape data encryption with i5/OS
In this section, we describe the EKM configuration and setup of LME in the IBM tape library
for TS1120 tape encryption or LTO4 tape encryption. We assume that the IBM Encryption
Key Manager component for the Java platform (EKM) has already been installed, as
described in steps 1 to 5 in 15.4.1, New installation of the Encryption Key Manager on
page 450.
21.2.1 Creating an EKM keystore and certificate
Refer to the planning section, 21.1.4, EKM keystore considerations on page 705, to decide
which type of the required keystore to use for EKM on i5/OS before going to the
corresponding following sections to create an EKM keystore:
To create an IBMi5OSKeyStore, see Creating an IBMi5OSKeyStore keystore and
certificate on page 710.
To create a JCEKS keystore, see Creating a JCEKS keystore and certificate on
page 720.
Creating an IBMi5OSKeyStore keystore and certificate
Follow these steps to create an IBMi5OSKeyStore and certificate:
1. Use a web browser to connect to the i5/OS HTTP admin server at the address
http://ipaddress:2001, and click Digital Certificate Manager, as shown in Figure 21-4.
You access the i5/OS Digital Certificate Manager that is used for creating and managing
an IBMi5OSKeyStore.
Figure 21-4 HTTP admin server i5/OS Tasks entry panel
Connectivity: If you experience connection problems from the web browser to the
i5/OS HTTP admin server, use WRKACTJOB on i5/OS to check that the HTTP admin
server QHTTPSVR/ADMIN is running. If not, start it by entering the following command:
STRTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN)
2. Select Create New Certificate Store. Choose Other System Certificate Store, and then
click Continue, as shown in Figure 21-5.
Figure 21-5 DCM: Create New Certificate Store panel
The next panel opens, as shown in Figure 21-6.
Figure 21-6 DCM: Create a Certificate in New Certificate Store panel
3. Select No - Do not create a certificate in the certificate store, and then, click Continue.
The panel, as shown in Figure 21-7 on page 712, opens.
Figure 21-7 DCM: Certificate Store Name and Password panel
4. Enter the certificate store path and file name, for example, /EKM/EKM.KDB, making sure to
use the path for the integrated file system (IFS) directory that was created for EKM.
Specify a certificate store password. Document the certificate store path, file name, and
certificate store password, because they will be required later for configuring EKM. Click
Continue.
The message The certificate store has been created indicates the successful
creation of the certificate store, as shown in Figure 21-8.
Figure 21-8 DCM: Certificate Store Created panel
5. Select Create a Certificate Authority (CA). Choose a key size of 1024 bits, enter the
required local CA certificate information, as in the example that is shown in Figure 21-9,
and click Continue to proceed.
Figure 21-9 DCM: Create a Certificate Authority panel
The Install Local CA Certificate panel, as shown in Figure 21-10 on page 714, opens.
Local CA: The Create a Certificate Authority (CA) menu option displays if no local
CA has been created yet. If a local CA already exists, proceed directly to step 10.
Figure 21-10 Install Local CA Certificate panel
6. Click Continue to create the local CA certificate. Installing the local CA certificate in your
browser is not necessary, because the local CA is not meant to be used for Secure
Sockets Layer (SSL) web connections.
The panel, as shown in Figure 21-11 on page 715, opens.
7. For Allow creation of user certificates, select Yes. Specify the validity period (in days)
for the certificates, which are issued by your local CA, that you will use for tape encryption.
This validity period must be shorter than the validity period of the CA certificate itself.
Figure 21-11 Certificate Authority (CA) Policy Data panel
8. Click Continue.
More information: EKM does not care about the validity period or expiration of
certificates. It also works with the keys from expired certificates, as long as they remain
in the keystore.
The message The policy data for the Certificate Authority (CA) was
successfully changed indicates the successful modification of the local CA policy data,
Because the local CA certificate will be used to issue self-signed certificates to use for
tape encryption, click Cancel, so that a server certificate store is not created.
Figure 21-12 DCM: Policy Data Accepted panel
9. After creating the local CA keystore and certificate, select the EKM keystore, which was
created in a previous step, by clicking Select a Certificate Store. Select Other System
Certificate Store, as shown in Figure 21-13. Then, click Continue.
Figure 21-13 DCM: Select a Certificate Store panel
10.In Figure 21-14, enter the certificate store path, file name, and certificate store password
of the previously created EKM keystore. Then, click Continue.
Figure 21-14 DCM: Certificate Store and Password panel
Successful selection of the certificate store is indicated, as shown in Figure 21-15.
Figure 21-15 DCM: Current Certificate Store panel
11.Select Fast Path Work with server and client certificates, and click Create, as
shown in Figure 21-16 on page 718.
Figure 21-16 DCM: Work with Server and Client Certificates panel
12.Select Local Certificate Authority (CA) for the creation of a self-signed certificate to use
for tape encryption, and click Continue, as shown in Figure 21-17.
Figure 21-17 DCM: Select a Certificate Authority (CA) panel
13.Select 1024 bits for the key size, specify a Certificate label, which you must record to use
later when configuring EKM, and complete the required Certificate Information fields with
your identity information. Click Continue to proceed, as shown in Figure 21-18.
Figure 21-18 DCM: Create Certificate panel
The message Your certificate was created and placed in the certificate store
listed below indicates the successful creation of your self-signed certificate in your EKM
keystore, as shown in Figure 21-19.
Figure 21-19 DCM: Certificate Created Successfully panel
Now, you have created an EKM keystore with a self-signed public-private key certificate to
use for TS1120 tape encryption. To create a second certificate to share with a business
partner, as described in 21.1.6, Considerations for sharing tapes with partners on page 707,
repeat step 11 on page 717 through step 13 on page 719, and specify a separate certificate
label. Return to 15.4.1, New installation of the Encryption Key Manager on page 450, and
proceed with step 7 on page 457 to continue with configuring EKM for tape encryption.
Creating a JCEKS keystore and certificate
To create a public-private key certificate for TS1120 tape encryption in a JCEKS keystore,
refer to Public-private key generation for TS1120 tape encryption on page 721. To create a
symmetric key certificate for LTO4 or LTO5 tape encryption in a JCEKS keystore, refer to
Symmetric key generation for LTO4 encryption on page 721.
The JCEKS keystore will automatically be created with the corresponding key generation
commands if it does not exist yet.
Public-private key: When using solely LTO4 or LTO5 tape encryption, also create one
public-private key as described in Public-private key generation for TS1120 tape
encryption on page 721. This public-private key is required for the SSL communication
that is used for the synchronization of two EKM servers. A missing public-private key will
not cause the EKM server to fail, but it might result in the Java exception message No
available certificate corresponds to the SSL cipher suites which are enabled.
Important: The keypass and storepass values that are used in the following key generation
procedures must be the same, because EKM allows you to specify only one password in
its KeyManagerConfig.properties EKM configuration file. Both the keystore and each
associated key label use this file.
Public-private key generation for TS1120 tape encryption
Use the following command syntax from i5/OS Qshell to create a public-key certificate for
TS1120 tape encryption:
keytool -genkey -alias Tape_Certificate -dname "CN=WING3" -keystore /EKM/EKM.jck
-keyalg RSA -keysize 1024 -keypass password -storepass password -storetype JCEKS
This example creates a new self-signed public-private key certificate to use for TS1120 tape
encryption that is generated from the Rivest-Shamir-Adleman (RSA)-1024 encryption key
algorithm. It is labeled Tape_Certificate with the common name WING3 in the JCEKS
keystore /EKM/EKM.jck. Both the keystore and the certificate are protected by the same
specified password and are valid for 90 days, by default.
Symmetric key generation for LTO4 encryption
The keytool script in /usr/bin uses the default Java version that is configured on your i5/OS
system. On i5/OS systems with multiple Java versions, that is, with several 5722-JV1 options
installed, this version might not be the version that is required for any symmetric key
management.
Check your current default Java version by running the command:
STRQSH CMD('java -version')
If your current default Java version differs from Java 2 Platform, Standard Edition (J2SE) 5.0
32-bit for V5R4 and Java 1.5 for V5R3, set the required version by defining an i5/OS job-level
environment variable, as shown:
For V5R4:
ADDENVVAR ENVVAR(JAVA_HOME) VALUE('/QOpenSys/QIBM/ProdData/JavaVM/jdk50/32bit')
LEVEL(*JOB)
For V5R3:
STRQSH CMD('print java.version=1.5 > /EKM/EKMjava.properties')
ADDENVVAR ENVVAR(QIBM_JAVA_PROPERTIES_FILE) VALUE('/EKM/EKMjava.properties')
Use the following command in Qshell to generate symmetric keys for LTO4 tape encryption:
keytool -genseckey -alias LTO_Key -keypass password -keyalg AES -keysize 256
-keystore /EKM/EKM.jck -storepass password -storetype JCEKS
This example creates a new symmetric (or secret) key certificate to use for LTO4 tape
encryption, which was generated from the Advanced Encryption Standard (AES)-256
encryption key algorithm, labeled LTO_Key in the JCEKS keystore /EKM/EKM.jck. Both the
keystore and the certificate are protected by the same specified password.
Certificate expiration irrelevant: The validity period of a digital certificate is irrelevant,
because certificate expiration does not matter for EKM.
Job-level environment variable: The previously defined job-level environment
variable is only valid for the current interactive i5/OS user session. However, do not use
a system-level environment variable for the default Java version, because it might result
in incompatibilities with other programs, such as the i5/OS HTTP admin server, which
does not work with J2SE 5.0.
Viewing the newly created certificate in the EKM JCEKS keystore
List the contents of the keystore with the newly created certificates by using the command:
keytool -list -keystore /EKM/EKM.jck -storetype JCEKS -storepass password
Example 21-1 shows the listing for a sample JCEKS keystore with two public-private key
certificates that are labeled tape_certificate and tape_certificate2 and sixteen
symmetric keys that are labeled aes0...0 - aes0...f.
Example 21-1 Sample JCEKS keystore
> keytool -list -keystore /EKM/EKM.jck -storetype JCEKS -storepass TS1120
Keystore type: JCEKS
aes000000000000000009, Apr 14, 2007, SecretKeyEntry,
aes00000000000000000f, Apr 14, 2007, SecretKeyEntry,
aes00000000000000000e, Apr 14, 2007, SecretKeyEntry,
aes00000000000000000d, Apr 14, 2007, SecretKeyEntry,
aes00000000000000000c, Apr 14, 2007, SecretKeyEntry,
aes00000000000000000b, Apr 14, 2007, SecretKeyEntry,
tape_certificate2, Apr 14, 2007, keyEntry, Certificate fingerprint (MD5):
41:24:F7:87:7E:6F:C4:B6:DD:17:7E:76:5A:A3:C6:AB
aes00000000000000000a, Apr 14, 2007, SecretKeyEntry,
tape_certificate, Apr 14, 2007, keyEntry, Certificate fingerprint (MD5):
3F:6C:34:D1:2D:01:44:83:29:8F:4D:8A:2A:26:8C:F5
21.2.2 Configuring the TS3500 library for Library-Managed Encryption
Using the example of an IBM TS3500 Tape Library, we describe the procedures for setting up
the Encryption Key Manager (EKM) addresses in the tape library and enabling it for
Library-Managed Encryption in this section.
Aliasrange: Specify the alias using up to 12 characters. If you want increased security by
using a set of symmetric LTO4 encryption keys across the pool of encrypted LTO4 or LTO5
cartridges to limit the work in case a key gets compromised, the keytool also allows the
creation of multiple symmetric keys in one step by using the aliasrange parameter instead.
You specify an aliasrange with a three-character prefix followed by lower and upper limits
of up to 16 hex digits, for example, AES00-0F, which creates 16 symmetric key aliases at
one time. Refer to the online help that is accessible by using the keytool -ekmhelp
command for additional information.
For information about configuring encryption on the IBM TS3100, TS3200, TS3310, or
TS3400 tape libraries, refer to the following corresponding operator guides:
IBM System Storage TS3100 Tape Library and TS3200 Tape Library: Setup, Operator and
Service Guide, GA32-0545
IBM System Storage TS3310 Tape Library Setup and Operator Guide, GA32-0477
IBM System Storage TS3400 Tape Library Planning and Operator Guide, GC27-2107
Setting up Encryption Key Manager server TPC/IP addresses
Follow these steps to set up the EKM server TCP/IP addresses that are used by the IBM
TS3500 Tape Library to communicate with the EKM servers:
1. Use a web browser. Enter the IBM TS3500 Tape Library IP address to connect to the
TS3500 Tape Library Specialist.
2. Under Work Items, select Access Key Manager Addresses. Select Create from the
drop-down menu, as shown in Figure 21-20.
Figure 21-20 IBM TS3500 Tape Library: Key Manager Addresses window
3. Click Go. The panel, as shown in Figure 21-21 on page 724, opens.
4. In the newly opened Create Key Manager Address window, enter the IP address of the
i5 server where you installed EKM.
Figure 21-21 IBM TS3500 Tape Library: Create Key Manager Address window
5. Click Apply to proceed, and then, close the window that contains the The Key Manager
Address Change is complete message.
The IBM UltraScalable Specialist shows the newly created EKM address in the Key
Manager Addresses window that is shown in Figure 21-22.
Figure 21-22 IBM TS3500 Tape Library: Key Manager Addresses window
Important: If you use a TCP/IP port other than the default port 3801, either because
port 3801 is already being used for other TCP/IP services, or because multiple EKM
servers will be installed on the same host system, remember to change the
TransportListener.tcp.port parameter in your corresponding EKM configuration file,
/EKM/KeyManagerConfig.properties.
6. Repeat steps 2 on page 723 through step 5 on page 724 for any secondary EKM servers
that you will use.
Enabling Library-Managed Encryption
Follow this procedure to configure logical libraries in the IBM TS3500 Tape Library for
Library-Managed Encryption:
1. Use a web browser to enter the IBM TS3500 Tape Library IP address to connect to the
TS3500 Tape Library Specialist.
2. Select Library Logical Libraries. Select the logical libraries from the list with the same
media type (either TS1120, LTO4, or LTO5) for which Library-Managed Encryption will be
enabled, and choose Modify Encryption Method, as shown in Figure 21-23. Click Go.
Figure 21-23 IBM Tape Library Specialist: Manage Logical Libraries window
Automatic EKM server failover: You can configure up to four EKM server addresses
in the IBM TS3500 Tape Library for automatic EKM server failover. The library attempts
to talk to the first configured EKM server, and if this attempt fails, the library proceeds to
try to talk to the next EKM server in the list. At the end of the list, the library starts over
again trying the first EKM server.
Non-encryption-capable drives: Logical libraries in the list that show an Encryption
Method of N/A have non-encryption-capable drives and cannot be enabled for
encryption.
3. Select Library-Managed for Encryption Method, and leave the other settings at their
default values, as shown in Figure 21-24.
Figure 21-24 IBM UltraScalable Specialist: Encryption Method window
4. After clicking Apply, select OK for the confirmation window that is shown in Figure 21-25.
Figure 21-25 IBM UltraScalable Specialist: Encryption Method change confirmation window
5. A new progress window about modification of the encryption method opens. The
encryption method modification is complete, as indicated by the message Drive
Encryption change request has completed. Select Close to close the Success window
that is shown in Figure 21-26 on page 727.
Important: i5/OS supports no dynamic device reconfiguration. An IOP reset is required
to recognize the changed encryption setting, which we account for later as the last step
of this procedure.
Figure 21-26 IBM UltraScalable Specialist: Success window
6. The automatically refreshed Manage Logical Libraries window shows the enabled
Library-Managed encryption method for the changed logical library, as shown in
Figure 21-27.
Figure 21-27 IBM UltraScalable Specialist: Manage Logical Libraries window
7. Repeat steps 2 - 6 to enable Library-Managed Encryption for other media types, if
required.
8. Use the following procedure on i5/OS to make it recognize the configuration change after
enabling encryption with two newly added media densities, FMT3592A1E and
FMT3592A2E, for encrypted 3592 cartridges:
a. Vary off the the corresponding tape library device by running the command:
VRYCFG CFGOBJ(TAPMLB73) CFGTYPE(*DEV) STATUS(*OFF)
b. Obtain the IOP resource name of the newly attached encryption-enabled tape drive
from the output of the following command:
WRKHDWRSC *STG
Figure 21-28 shows an example with the TAPMLB73 library being attached through the
#2844 IOP with the resource name CMB09.
Figure 21-28 i5/OS Work with Storage Resources window
c. Access System Service Tools (SST) to reset and start the IPL of the IOP that is
associated with the attached encryption-enabled tape drive:
STRSST
d. Log in to SST with your SST password and user ID, and perform these steps:
i. Select Start a service tool from the System Service Tools (SST) window.
ii. Click Select Hardware service manager from the Start a Service Tool window.
iii. Click Locate resource by resource name from the Hardware Service Manager
window.
iv. In the Locate Resource By Resource Name window, enter your IOP resource name
from step b (in the given example, it is CMB09).
v. Select option 6=I/O debug for the IOP in the Logical Hardware Resources window.
vi. Select 3. Reset I/O processor in the Select IOP Debug Function window, and
confirm the action by pressing Enter.
vii. After receiving the completion message Reset of IOP was successful, select IPL
I/O processor from the Select IOP Debug Function window, and confirm the action
by pressing Enter.
viii.After receiving the completion message Re-IPL of IOP was successful, press F3
three times, and press Enter to exit SST.
e. Vary on the corresponding tape library device again by running the command:
VRYCFG CFGOBJ(TAPMLB73) CFGTYPE(*DEV) STATUS(*ON)
Testing the EKM IBM TS3500 Library-Managed Encryption setup
After completing the steps in Setting up Encryption Key Manager server TPC/IP addresses
on page 723 and Enabling Library-Managed Encryption on page 725, use the procedure in
this section to test the IBM TS3500 Library communication with the configured EKM server
addresses.
Follow these steps to test the setup:
1. Start the EKM Admin Consoles for all configured EKM server addresses:
For EKM servers installed on i5/OS, run the following command from the i5/OS Qshell:
For EKM servers installed on other Java platforms, run the following Java command:
java com.ibm.keymanager.KMSAdminCmd KeyManagerConfig_full_file_path_name
Example 21-2 shows the EKM admin command prompt # displayed after starting the EKM
Admin Console. The output from the listdrives EKM command shows that there are no
drives yet listed in the EKM drive table.
Example 21-2 EKM admin command prompt
> strEKM -propfile /EKM/KeyManagerConfig.properties
Apr 16, 2007 4:33:21 PM Thread[main,5,main] com.ibm.keymanger.config.ConfigImpl
get
FINER: ENTRY
get ALL: debug.output = simple_file
get
FINER: RETURN
#
> listdrives
Drive entries: 0
#
2. If you use the EKM configuration file KeyManagerConfig.properties parameter setting
drive.acceptUnknownDrivesBefore = false to not automatically add new drives, you must
manually add each tape drive that will be used for encryption to the EKM drive table. Run
this EKM adddrive command before you can use the tape drives with the EKM server:
adddrive -drivename drivename -rec1 alias1 -rec2 alias2
Example:
adddrive -drivename 000123456789 -rec1 Tape_Certificate -rec2 Tape_Certificate2
Note: Always use the strEKM start script on i5/OS for starting the EKM Admin
Console, which helps to ensure that the correct Java version is used for EKM.
3. Start the EKM server for all configured EKM server addresses by running the command
startekm from the EKM Admin Console.
Example 21-3 shows the output from the startEKM command.
Example 21-3 startEKM output
> startekm
No symmetric keys in symmetricKeySet, LTO drives can not be supported.
Processing
Server is started
#
4. Test the encryption setup by using the IBM TS3500 Tape Library Operator Panel function
MENU Service Tests/Tools Diagnostics Test Encryption Key Path/Setup.
Press Enter, and use the Up and Down arrow keys to select the drive from the list of
encryption-enabled drives, as shown in Figure 21-29.
Figure 21-29 IBM TS3500 Tape Library Operator Panel Test Encryption Key Path/Setup select panel
5. Press Enter. The library performs the following tests for the encryption setup:
Ethernet test
The library performs a ping to the EKMs IP addresses where the selected drive is
registered. It can ping up to four host server IP addresses. If successful, the panel
displays the message Passed, which means that the target host system can be
Important: The drivename parameter value has to be specified as a 12-digit drive
serial number (with leading zeros). The rec1 and rec2 parameters apply for TS1120
tape encryption only and allow you to use an encryption policy with specified default key
aliases for a selected drive serial number.
The drive table can be changed dynamically without restarting the EKM server,
however, currently only if the EKM server was started interactively from the EKM Admin
Console.
LTO4 encryption not supported: The message No symmetric keys in
symmetricKeySet, LTO drives cannot be supported is posted by EKM to inform you
that there was no symmetricKeySet parameter in the EKM configuration file and, thus, it
cannot support LTO4 encryption.
reached by the library over the network. If unsuccessful, the panel displays the
message Failed. If at least one ping test passes, the testing continues with the EKM
Path and EKM Configuration tests; otherwise, it stops and ENTER is displayed.
EKM Path test
The EKM Path test tries to establish communication to an Encryption Key Manager. It
ensures that the communication path between the drive and EKM, including the
librarys proxy server, works. If successful, the panel displays the message Passed; if
unsuccessful, it displays Failed, the following EKM Configuration test does not run,
and ENTER is displayed.
EKM Configuration test
The EKM Configuration test is a diagnostic test that establishes a link to an Encryption
Key Manager and requests a default key, which ensures that the drive has been
correctly installed and is able to service key requests.
Figure 21-30 IBM TS3500 Tape Library Operator Panel Test Encryption Key Path/Setup result panel
6. Ensure all three diagnostic tests are passed successfully, and repeat steps 4 - 5 for each
encryption-enabled drive:
A failed Ethernet test normally points to a network problem of the library not reaching
the host server where EKM is installed, which might be further isolated by trying to
ping the EKM host server and library from another server in the network.
For a failed EKM Path test, the first steps in failure isolation are to verify if the EKM
server was started and is running properly by using the EKM Admin Console status
command. Check that the IP port settings for the EKM servers that are defined in the
library match with those IP port settings in the EKM configuration file and cause no port
conflicts on the host.
A failed EKM Configuration test typically points to a problem with the configured key
alias or keystore. For additional guidance to isolate and resolve the problem, refer to
Chapter 6. Problem Determination of the IBM System Storage TS3500 Tape Library
Operator Guide, GA32-0560. Contact your IBM service support representative (SSR)
for additional assistance, if necessary.
Note: The librarys three encryption diagnostics, that is, ping, EKM Path, and EKM
Configuration tests, all have to pass successfully, as shown in Figure 21-30, as a
prerequisite to being able to use tape encryption for the selected drive.
7. End the interactive EKM server sessions again by entering the command exit from each
EKM Admin Console. Return to New installation of the Encryption Key Manager on
page 450, and proceed with the step to start the EKM servers as a batch job.
21.2.3 Importing and exporting encryption keys
In this section, we describe the procedures to import or export a digital certificate that is used
for tape encryption from an EKM keystore. The procedures vary based on whether you use
public-private keys, symmetric keys, or public key only certificates:
For importing and exporting public-private key certificates and symmetric keys, for
example, for transfer to another EKM server on a separate host platform, refer to
Procedures for public-private key certificates and symmetric keys.
For importing and exporting a public key only certificate to provide it to a business partner
to exchange encrypted TS1120 tape cartridges, refer to Procedures for public key only
certificates on page 733.
Procedures for public-private key certificates and symmetric keys
The procedures to import or export either a public-private key certificate that is used for
TS1120 tape encryption or a symmetric key that is used for LTO4 tape encryption depend on
the type of keystore that is used:
For IBMi5OSKeyStore, use the i5/OS Digital Certificate Manager (DCM) Manage
Certificates Export certificate or Import certificate menu option, and select Server
or client certificate to export your public-private key certificate that is used for TS1120
tape encryption.
Additional information about DCM is available on the i5/OS Information Center:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp
Select Site map Networking Networking security Digital Certificate
Management.
For Java Cryptography Extension Keystores (JCEKS), use the IBM Java keytool
command:
Export a public-private key certificate:
keytool -export -alias keylabel -file filename -keystore keystore -storepass
password -storetype JCEKS -keypass password -pkcs12
Import a public-private key certificate:
keytool -import -alias keylabel -file filename -keystore keystore -storepass
password -storetype JCEKS -keypass password -pkcs12
Export a symmetric key that is wrapped by a public key:
keytool -exportseckey -alias keylabel -keyalias publickey -keystore keystore
-storepass password -storetype JCEKS -exportfile filename
Import a symmetric key that is wrapped by a public key:
keytool -importseckey -alias keylabel -keyalias publickey -keystore keystore
-storepass password -storetype JCEKS -importfile filename
Adding new drives: When using the drive.acceptUnknownDrives = true EKM
configuration file parameter setting, new drives are automatically added to the EKM
drive table after their successful completion of EKM Path diagnostic tests, even if the
subsequent EKM Configuration test fails.
Additional information about the IBM Java keytool is available:
IBM Java keytool online help by entering keytool -help and keytool -ekmhelp
IBM Java Keytool Users Guide, which is available online at this website:
http://www-128.ibm.com/developerworks/java/jdk/security/50/secguides/keytool
Docs/KeyToolUserGuide-150.html
Procedures for public key only certificates
The following procedures to export and import a public key only certificate apply only in the
context of providing or receiving a public key certificate to or from a business partner for
sharing encrypted 3592 tape cartridges, as described in 21.1.6, Considerations for sharing
tapes with partners on page 707. These procedures depend on the type of keystore that is
used.
Exporting a public key only from an i5OSKeyStore
For IBMi5OSKeyStore *Other System Certificate Store-type EKM keystores, the i5/OS Digital
Certificate Manager (DCM) provides no option to directly export only the public key of a digital
certificate that is used for TS1120 tape encryption. However, by using the workaround, which
we describe next, create an *OBJECTSIGNING certificate store first and then export the
EKM keystore certificate that is used for tape encryption into the *OBJECTSIGNING
certificate store. The public key only can be exported from the *OBJECTSIGNING certificate
store as a signature verification certificate without the private key.
Follow these steps:
1. Connect to the HTTP Admin Server from the i5/OS system with the EKM keystore by
entering the URL http://ipaddress:2001 in a web browser.
2. Access the i5/OS Digital Certificate Manager by selecting Digital Certificate Manager
from the i5/OS Tasks HTTP Admin Server entry panel, as shown in Figure 21-31.
Figure 21-31 HTTP Admin Server i5/OS Tasks entry panel
3. Select *OBJECTSIGNING from the Select a certificate store menu, as shown in
Figure 21-32. Click Continue.
Figure 21-32 DCM: Create New Certificate Store panel
*OBJECTSIGNING certificate store: If the *OBJECTSIGNING option does not show
in the DCM Create New Certificate Store panel, proceed directly to step 7, because an
*OBJECTSIGNING certificate store already exists.
4. Select No - Do not create a certificate in the certificate store (Figure 21-33). Click
Continue.
Figure 21-33 DCM: Create a Certificate in New Certificate Store panel
5. Specify a password for the new *OBJECTSIGNING certificate store, as shown
Figure 21-34. Click Continue.
Figure 21-34 DCM: Certificate Store Name and Password panel
6. The confirmation message in Figure 21-35 shows the successful creation of the new
*OBJECTSIGNING certificate store.
Figure 21-35 DCM: Certificate Store Created panel
7. After creating the *OBJECTSIGNING certificate store, select the EKM keystore by clicking
Select a Certificate Store Other System Certificate Store, which contains the
certificate to be exported first into the *OBJECTSIGNING certificate store. Finally, the
public key only is exported into a file to provide to the business partner. The business
partner then can use the public key only as a second key label for encryption of 3592 tape
cartridges to share with you, because you have the private key that is required to decrypt
them.
8. Export the EKM keystore certificate into the *OBJECTSIGNING certificate store by
selecting Manage Certificates Export certificate, and choosing Server or client, as
shown in Figure 21-36. Click Continue.
Figure 21-36 DCM: Export Certificate panel
9. Select the certificate that is used for TS1120 tape encryption for which the public key must
be exported in order to provide it to the business partner, as shown in Figure 21-37. Click
Export.
Figure 21-37 DCM: Export Server or Client Certificate panel
10.Select Certificate store for the export destination to export the certificate into the
previously created *OBJECTSIGNING certificate store, as shown in Figure 21-38. Click
Continue.
Figure 21-38 DCM: Export Destination panel
11.Specify the target certificate store by entering *OBJECTSIGNING and your password, as
shown in Figure 21-39. DCM automatically replaces *OBJECTSIGNING with its full IFS
file path name. Click Continue.
Figure 21-39 DCM: Specify Target Certificate Store panel
12.The message The certificate has been exported to the certificate store, which is
shown in Figure 21-40, confirms the successful completion of exporting the public key
certificate into the *OBJECTSIGNING certificate store.
Figure 21-40 DCM: Export Server or Client Certificate panel
13.For the remaining tasks, switch to the *OBJECTSIGNING certificate store again by
clicking Select a Certificate Store *OBJECTSIGNING, clicking Continue, entering
your password, and clicking Continue.
14.Export the public key only certificate by clicking Manage Certificates Export
certificate, and choosing Object signing, as shown in Figure 21-41. Click Continue.
Figure 21-41 DCM: Export Certificate panel
15.Select your certificate that is used for TS1120 tape encryption for which the public key will
be exported, which is shown in Figure 21-42. Click Export.
Figure 21-42 DCM: Export Object Signing Certificate panel
16.Select File, as a signature verification certificate for exporting the public key only, as
shown in Figure 21-43. Click Continue.
Figure 21-43 DCM: Object Signing Certificate Export Destination panel
17.Enter the file name for exporting the certificate, as shown in Figure 21-44. Click Continue.
Figure 21-44 DCM: Export Object Signing Certificate panel
18.The message The certificate has been exported to the file, as shown in
Figure 21-45, indicates a successful export of the public key certificate.
Figure 21-45 DCM: Export Object Signing Certificate confirmation panel
Important: To import this exported public key certificate on another system, use FTP
ASCII mode to transfer the file, because the certificate has been exported in the
Base64_encoded text format. Copying the file through iSeries Navigator to a personal
computer destroys the certificate.
Importing a public key only to an IBMi5OSKeyStore
For importing a public key only certificate that is received in a Base64_encoded text file from a
business partner to an IBMi5OSKeyStore, use the i5/OS Digital Certificate Managers Fast
Path Work with CA Certificates. Click Import, which is shown in Figure 21-46, to import
it into your EKM keystore.
Figure 21-46 DCM: Work with CA Certificates panel
Exporting and importing a public key only from a JCEKS keystore
For Java Cryptography Extension Keystores (JCEKS), use the IBM Java keytool command to
export a public key only certificate:
For exporting a public key only certificate, use this command:
keytool -export -alias keylabel -file filename -keystore keystore -storepass
password -storetype JCEKS
For importing a public key only certificate, us this command:
keytool -import -alias keylabel -file filename -keystore keystore -storepass
password -storetype JCEKS
21.2.4 Working with encrypted tape cartridges
In this section, we show you examples of working with encrypted tape cartridges, such as
viewing their encryption status or rekeying 3592 tape cartridges.
Viewing tape cartridge encryption status
This example shows you how to view the tape cartridge encryption status by using the
TS3500 Tape Library Specialist on an IBM TS3500 Tape Library. Selecting Cartridges
Data Cartridges and using the option to select a specific logical library shows its assigned
data cartridges, as shown for a 3592 drive logical library in Figure 21-47 and an LTO4 drive
logical library in Figure 21-48 on page 745.
Figure 21-47 IBM UltraScalable Specialist: 3592 logical library cartridges panel
Figure 21-48 IBM UltraScalable Specialist: LTO4 logical library cartridges panel
The following commands show adding tape cartridges from the *INSERT category to the
*SHARED category to make them available for usage with the TAPMLB73 3592 logical library
and the TAPMLB71 LTO4 logical library:
ADDTAPCTG DEV(TAPMLB73) CTG(J1H039 JEX163 JJX283)
ADDTAPCTG DEV(TAPMLB71) CTG(3MC037 3MC055 3SR038)
The next two commands show initializing a 3592 and LTO4 data cartridges using the new
media density FMT3592A2E for 3592 encryption:
INZTAP DEV(TAPMLB73) NEWVOL(JBX163) VOL(JBX163) CHECK(*NO) DENSITY(FMT3592A2E)
INZTAP DEV(TAPMLB71) NEWVOL(3MC037) VOL(3MC037) CHECK(*NO)
Unload the initialized cartridges from the drives by using the IBM UltraScalable Specialist
Cartridges Move option on the IBM UltraScalable Specialist Cartridges panel. You see that
the initialized cartridges now have the encryption status Encrypted, as shown for the 3592
cartridge VOLSER JBX163 in Figure 21-49 on page 746, and for the LTO4 cartridge VOLSER
3MC037 in Figure 21-50 on page 746.
Tip: The Encryption column in the cartridges panel for an encryption-enabled logical
library is not shown before the first data cartridge has been written to and unloaded from
the drive.
FMT3592A2E support: Although two new media densities, FMT3592A1E and
FMT3592A2E, are available on i5/OS for encryption-enabled 3592 tape drives, only the
format FMT3592A2E is supported. FMT3592A1E was originally intended for use with the
3592-J1A emulation mode of the 3595-E05 drive, but IBM does not support encryption in
the emulation mode.
Figure 21-49 IBM UltraScalable Specialist: 3592 Cartridges panel with Encryption information
Figure 21-50 IBM TS3500 Specialist: LTO4 Cartridges panel with Encryption information
Status: The cartridge encryption status that is displayed in the Encryption column is
updated only when the cartridge is unloaded from a drive. The status Unknown is displayed
for cartridges in an encryption-enabled logical library, as long as they have not been loaded
or unloaded from a drive.
Rekeying encrypted 3592 cartridges
This example shows using the TS3500 Tape Library Specialist for rekeying encrypted 3592
tape cartridges. You can use rekeying after you have imported a public key certificate from a
business partner for sharing already encrypted tape cartridges.
Encrypted 3592 tape cartridges that are loaded into a library-managed encryption-enabled
drive are rekeyed through the IBM Tape Library Specialist web GUI. Select Manage
Cartridges Data Cartridges. Select Rekey Encryption from the list box, as shown in
Figure 21-51.
Figure 21-51 IBM TS3500 Specialist: Cartridges panel with ReKey Encryption option selected
After clicking Go, you can specify new key settings for the Key Mode and the Key Label for
each of the two key labels that are used to refer to EEDK1 and EEDK2, as shown in
Figure 21-52 on page 748. In the example, a Hash label key mode was chosen for a new
EEDK2. So, a hash computed value of the public key part of the specified tape_certificate2
key label, which refers to the imported public key certificate from the business partner, is
stored within the EEDK2, instead of the clear label itself.
Tip: Use a hash label for sharing tape cartridges with business partners, because it
eliminates the requirement of using the same key label as the business partner.
Figure 21-52 IBM UltraScalable Specialist: Rekey Encryption panel
The message Cartridge Rekey request has completed indicates the successful
completion of the 3592 cartridge rekeying request, as shown in Figure 21-53.
Figure 21-53 IBM UltraScalable Specialist: Rekey Encryption Success window
Example of the EKM audit metadata XML file
EKM Release 2 introduced an audit metadata XML log file for logging key usage events for
3592 and LTO4 cartridge serial numbers. Refer to Customizing the EKM configuration file
on page 456, item 2 for information about the new EKMDataParser Java tool, which you can
use for querying this file for a particular VOLSER or keyalias. Figure 21-54 on page 749
shows an example of the audit metadata XML file with key usage events logged for 3592
cartridge VOLSER JBX163 and LTO4 cartridge VOLSER 3MC037.
Figure 21-54 Example of EKM audit metadata XML file
21.2.5 Troubleshooting
When you encounter problems with EKM, check the EKM standard outputs, on the EKM
Admin Console, especially the /EKM/stdout.log and /EKM/stderr.log files if EKM was
started as a batch job, and the EKM audit log file, which is typically the
/EKM/auditlogs/ekm_audit.log file.
For failure isolation, refer to the Problem Determination chapter in the IBM System Storage
Tape Enterprise Key Manager, Introduction Planning and User Guide, GA76-0418.
For debugging EKM error messages that are displayed on the Admin Console or logged in the
standard error outfile when starting EKM or issuing EKM Admin commands, refer specifically
to the Debugging EKM Server problems and Messages sections in the Problem
Determination chapter in the IBM System Storage Tape Enterprise Key Manager,
EKM runtime errors show up as errorcode = Exyz in the EKM audit log. For debugging EKM
runtime errors, refer to the EKM Reported Errors section in the Problem Determination
chapter in the IBM System Storage Tape Enterprise Key Manager, Introduction Planning and
User Guide, GA76-0418.
Usually, you must collect the following data for additional assistance from IBM support:
Audit log (typically, the /EKM/auditlogs/ekm_audit.log file)
EKM configuration file (typically, the /EKM/KeyManagerConfig.properties file)
Standard output files if EKM was running as a batch job (typically, the /EKM/stdout.log
and /EKM/stderr.log files)
Debug log if debugging was enabled (typically, the /EKM/debug.log file)
Part 4 DS8000 encryption
features
This section describes the encryption features that are available with the DS8100, DS8300,
and DS8700.
Part 4
Chapter 22. IBM System Storage DS8000
encryption preparation
This chapter provides all the general information that is needed for planning and ordering a
DS8000 storage server. Then, it shows you how to set up the first Tivoli Key Lifecycle
Manager server using graphical user interface (GUI) and command-line interface (CLI)
functions.
We describe these topics in this chapter:
Encryption-capable DS8000 ordering and configuration on page 754
Requirements for encrypting storage on page 755
Tivoli Key Lifecycle Manager configuration on page 756
Configuring the Tivoli Key Lifecycle Manager server connections to the DS8000 on
page 767
22
22.1 Encryption-capable DS8000 ordering and configuration
The Full Disk Encryption (FDE) support feature (feature code (FC) 1751) is available only as
plant order. Drive intermixing is not supported. The entire system can be encryption capable
with FDE drives (FC5nnn features) or non-encryptable with non-FDE Fibre Channel (FC),
Serial Advanced Technology Attachment (SATA), and solid-state disk drive (SSD) devices
(FC2nnn and FC6nnn features). The FDE feature requires the Laptop Management Console
feature (FC112n).
The following steps summarize the sequence for the ordering, activating, and configuring an
encryption-capable DS8000 system:
1. The IBM marketing representative or IBM Business Partner places a client order for a
DS8000 with encryption-capable Disk Drive Modules (DDMs). This step automatically
engages additional IBM support resources to ensure successful implementation of
encryption.
2. The additional IBM support resources carry out the following steps in parallel:
a. A system assurance call is established.
b. A manufacturing order is submitted.
c. A request to enable encryption is submitted (request for price quotation (RPQ)
8S1028).
3. You (client) must complete an environment verification process to ensure the best practice
configuration of the encryption solution. Request this verification from IBM Lab Services,
or you can complete it, but it is a prerequisite of the encryption solution activation process.
4. After the ordering process and verification process have been completed, IBM delivers the
DS8000 and an IBM service support representative (SSR) installs the DS8000. The
Encryption Authorization licensed internal code (LIC) feature key is provided to you for
each storage facility image (SFI) on the DS8000. You cannot obtain the key from the Disk
Storage Feature Activation (DSFA) website. You or IBM Lab Services install the LIC
feature key on the SFI.
5. You or IBM Lab Services or configure the key servers that are to be used with the DS8000.
6. You are now ready to configure the encryption group, encrypted ranks, extent pools, and
volumes.
Information: Current DS8000 models do not support the miscellaneous equipment
specification (MES) installation of FDE storage enclosures or racks.
Imports or exports: In certain countries, you might have to sign an Import
Agreement to be able to import or export FDE drives.
Chapter 22. IBM System Storage DS8000 encryption preparation 755
22.2 Requirements for encrypting storage
The following strict requirements apply for deploying an encryption-capable DS8000 storage:
Install at least one isolated key server (IKS) per site with an encryption-capable DS8000.
You can configure this key server to serve keys to any Tivoli Key Lifecycle Manager
supported device, including other encryption-enabled DS8000 or supported IBM tape
drives.
The isolated key server is a separately purchased hardware product (using System
Storage Productivity Center, Machine type 2805 Model MC3) for the DS8000 and is
required for all DS8000 encryption-enabled sites.
The isolated Tivoli Key Lifecycle Manager key server consists of the following equipment:
IBM System x3550:
Quad-core Intel Xeon processor x5420
8 GB memory
146 GB serial-attached SCSI (SAS) hard disk drive
SuSE Linux Enterprise Server (SLES) x86, 32 bit (v9 or v10)
Dual gigabit Ethernet ports
Single or redundant power supply
Tivoli Key Lifecycle Manager V1 software:
Includes DB2 9.1 FB4
Isolated key servers that are ordered with feature code number 0021 (Machine type 2805
Model MC3) have a pre-installed Linux operating system without Tivoli Key Lifecycle
Manager software. You must install Tivoli Key Lifecycle Manager to able to set the
passwords and specify other preferences. You must acquire a Tivoli Key Lifecycle
Manager license for the use of the Tivoli Key Lifecycle Manager software, which you order
separately from the stand-alone server hardware.
Important:
1. You must configure all ranks and extent pools on a given encryption-capable
DS8000 SFI with the same encryption group attribute. The first rank or encryption
group configured determines with what the remaining objects must be configured.
A value of zero indicates encryption disabled. A value of non-zero indicates that the
encryption group is being used, so the data is encrypted.
2. To change between encryption enabled and encryption disabled, all ranks and
extent pools must be unconfigured. Unconfiguring an encryption-enabled rank
causes any data that was stored on the rank to be cryptographically erased and,
subsequently, overwritten to re-initialize the rank.
Important: Encryption planning is a client responsibility. Not adhering to these
requirements can result in a permanent encryption deadlock, which means the permanent
loss of all encrypted data.
Important: No other hardware or software is allowed on this server. An isolated
server must use only internal disk for all the files that necessary to start up and have
the Tivoli Key Lifecycle Manager key server become operational.
Any DS8000 that is encryption enabled must be configured with at least one isolated key
server.
An encryption-enabled DS8000 requires the configuration of at least two key servers (an
isolated server and a backup server). More than one DS8000 can share the key servers.
To use encryption on a DS8000, you (client) must be certified for using encryption on each
DS8000 SFI.
22.3 Tivoli Key Lifecycle Manager configuration
We describe the Tivoli Key Lifecycle Manager installation in illustrated steps in Chapter 12,
Implementing Tivoli Key Lifecycle Manager on page 265.
For more complete information, refer to the IBM Tivoli Key Lifecycle Manager Installation and
Configuration Guide, SC23-9977-01. Additionally, refer to the Tivoli Integrated Portal:
http://publib.boulder.ibm.com/infocenter/tivihelp/v15r1/topic/com.ibm.tip.doc/welc
ome_tip_ic.htm
Make sure that the latest version of Tivoli Key Lifecycle Manager software is installed. Use
IBM Fix Central portal to browse the released fix packs (Tivoli IBM Tivoli Key Lifecycle
Manager):
http://www-933.ibm.com/support/fixcentral/
After Tivoli Key Lifecycle Manager is installed, we can create a keystore by accessing Tivoli
Key Lifecycle Manager through the Tivoli Integrated Portal.
22.3.1 Log in to Tivoli Integrated Portal
Open a web browser and point it at Tivoli Key Lifecycle Manager, which is typically at the
IP-Address and IP-Port, using the following web address format:
https://<IP-Address>:<IP-Port>/ibm/console
The default Tivoli Key Lifecycle Manager installation secures the HTTPS transport with a
self-signed certificate. Depending on what browser you use, you might get an exception and
must then accept that certificate as a trusted certificate. The Tivoli Integrated Portal login
window opens; see Figure 22-1 on page 757. Specify a User ID and Password, and click Log
in.
Requirement: The dual platform key server feature requires the Tivoli Key Lifecycle
Manager Version 1.0 Fix Pack 2 or later.
Figure 22-1 Tivoli Integrated Portal login window
The Welcome window that is shown in Figure 22-2 is displayed.
Figure 22-2 Welcome window
The actual version number is visible in the title of the Welcome window. In this case, it is
1.0.0.2, which indicates that Fix Pack 2 has been installed on the 1.0 base level.
22.3.2 Creating an image certificate or certificate request
The first time that you access Tivoli Key Lifecycle Manager, an action item prompts you to
configure Tivoli Key Lifecycle Manager Master Keystore (create the master keystore). See
Figure 22-2. You use this keystore to hold all the keys and certificates that are managed by
Tivoli Key Lifecycle Manager (open systems).
Follow these steps:
1. Click create the master keystore, which then opens the Keystore window that is shown in
Figure 22-3. Select the Keystore type JCEKS, which is actually the only choice for open
systems. The JCEKS software keystore type supports asymmetric and symmetric keys. In
our example, we enter ITSO Sample Keystore as the Keystore name and
/opt/TKLM/Keystores as the Keystore path and file name. Specify a password, which will
be the master keystore password.
Click OK.
Figure 22-3 Create master keystore
The window that is shown in Figure 22-4 on page 759 opens.
Password: Losing this password results in not being able to transfer any certificate
from this Tivoli Key Lifecycle Manager server to another Tivoli Key Lifecycle Manager
server.
Figure 22-4 Keystore created successfully
2. In Figure 22-4, under Next Steps, click Configure the product to use specific
communication protocol(s) to set up a key, which will be used for the Secure Sockets
Layer (SSL) certificate. The window that is shown in Figure 22-5 opens.
Figure 22-5 Create self-signed certificate
In Figure 22-5 on page 759, select Create self-signed certificate. Using a third-party
signed certificate is also supported. It is possible to use an existing certificate from the
keystore, but using a certificate that is used for encrypting disk data to also protect the
communication protocol is not good practice. Enter a descriptive certificate label. Enter a
certificate expiration period (in days) that follows your security guidelines. You can enter
optional certificate parameters, also. Click OK.
3. The Configuration window that is shown in Figure 22-6 opens.
Figure 22-6 Key Serving Parameters Update Successful
As indicated, the SSL certificate creation succeeded.
4. Click Return home.
You return to the Welcome window. See Figure 22-7 on page 761.
Figure 22-7 Welcome to Key Lifecycle Manager window
At this point, the Tivoli Key Lifecycle Manager master keystore and the SSL certificate have
been created.
22.3.3 Configure the SFIs
The next step in the configuration sequence is to create the image certificates that are
necessary for associating with the storage facility images (SFIs) that you are about to identify.
Follow these steps:
1. Under Key Administration, select DS8000 in the drop-down menu, as shown in
Figure 22-8. Click Go.
Figure 22-8 Select device type
2. The DS8000 Drive page opens to Step 1, as shown in Figure 22-9. It provides a guided
set of configuration steps.
Figure 22-9 Step 1: Create Certificates
3. You can create a new certificate, or skip Step 1: Create Certificates by clicking either Go
to Next Step or Step 2: Identify Images.
The Step 2 window that is shown in Figure 22-10 opens.
Figure 22-10 Step 2: Identify Images
Although it is possible to specify for Tivoli Key Lifecycle Manager to accept requests from
any DS8000 drives, do not use it in a production environment, because it is less secure.
4. In Figure 22-10, in the Drives table, click Add.
The Add Storage Image dialog, which is shown in Figure 22-11, is displayed.
Figure 22-11 Add Storage Image
5. In the Drive serial number field, enter the DS8000 machine type and the drive serial
number. An example of a serial number is 2424-75XXXX1 or 2, in the case of the second
SFI in a dual SFI storage system. From the Image Certificate drop-down list box, select
the certificate that was created earlier (refer to Figure 22-5 on page 759, in the field
named Certificate label in keystore). We used the following example SFI that is shown in
Figure 22-12. Then, click Add Storage Image.
Figure 22-12 Sample SFI and its key
6. The window that is shown in the Figure 22-13 opens. The storage image has been added
to the table.
Figure 22-13 Storage Image has been added
7. You have configured the Key Serving Status. In Figure 22-13 on page 764, if you click
Return home, the Welcome window opens again (Figure 22-14), which also shows the
configured state.
Figure 22-14 Welcome window with configured keys
22.3.4 Starting and stopping the Tivoli Key Lifecycle Manager server and
determining its status
You might have to use the startServer or stopServer command to start or stop the Tivoli Key
Lifecycle Manager server. Restarting the server, for instance, is required after the completion
of a restore task. You can also check its status.
Starting and stopping the Tivoli Key Lifecycle Manager server
Scripts to start and stop the Tivoli Key Lifecycle Manager server are located in the
/TIP_HOME/bin directory. Navigate to the TIP_HOME directory and, depending on the OS
environment, execute the commands in this section. In the commands, the server1
parameter is the default name of the configured Tivoli Key Lifecycle Manager server instance.
Start the server
Use a command to start the server:
Microsoft Windows systems:
StartServer.bat server1
Linux or AIX systems:
./startServer.sh server1
Stop the server
Use a command to stop the server:
MIcrosoft Windows systems:
StopServer.bat server1 -username TipAdminId -password Password
Linux or AIX systems:
./stopServer.sh server1 -username TipAdminId -password Password
When global security is enabled, enter the user ID and password of the Tivoli Integrated
Portal administrator as parameters to the stopServer script. The script will prompt for
these parameters if they are omitted, but you can specify them on the command line.
Determining status
If you want to determine whether the Tivoli Key Lifecycle Manager server is running, simply
try to log in to the Tivoli Key Lifecycle Manager server from a web browser. If the login is
successful, the Tivoli Key Lifecycle Manager service is running.
Otherwise, in Microsoft Windows or Linux and AIX systems, you can issue the serverStatus
command under the /TIP_HOME/bin directory with the server instance, user name, and
password parameters, as illustrated in Example 22-1.
Example 22-1 Check server status
cmd> ./serverStatus server1 -username TipAdminId -password Password
/opt/IBM/tivoli/tip/profiles/TIPProfile/logs/server1/serverStatus.log
ADMU0500I: Retrieving server status for server1
ADMU0508I: The Application Server "server1" is STARTED
In Windows systems, you can also check in the Services window to see if the service is
running, as shown in Figure 22-15.
Figure 22-15 WIndows server state check
In Linux, issue the ps command, as shown in Example 22-2.
Example 22-2 Linux server state check
ps -ef | grep tip | grep server1
root 3747 1 67 16:20 pts/7 00:00:55 /opt/IBM/tivoli/tip/java/bin/java
-Declipse.security -Dwas.status.socket=59520
......./opt/IBM/tivoli/tip/profiles/TIPProfile/config TIPCell TIPNode server1
22.4 Configuring the Tivoli Key Lifecycle Manager server
connections to the DS8000
The DS8000 supports up to four Tivoli Key Lifecycle Manager key server ports.
The following suggestions apply to configurations:
In multiple site configurations, assign at least two of the key server ports to isolated key
servers at separate physical sites. You can connect the remaining ports to general key
servers.
In single site configurations, assign at least two of the key server ports to isolated key
servers at the same site.
The DS8000 configuration for encryption also requires that you connect and define at least
two active key servers at the DS8000.
The DS8000 monitors all configured key servers. Customer notification is provided for the
loss of access to key servers and other key server-related errors through DS8000 customer
notification mechanisms (Simple Network Management Protocol (SNMP) traps and email, if
configured):
Loss of access to key servers is reported at 5-minute intervals.
Loss of the ability for at least two key servers to provide key services that prevents access
to the data on the DS8000 is reported at 8-hour intervals.
The inability of any one key server to provide key services that prevents access to data on
the DS8000 is also reported at 8-hour intervals.
To configure a Tivoli Key Lifecycle Manager server connection, perform the following steps
from the Storage Manager GUI:
1. Select Manage Hardware.
2. Select Encryption.
3. Select Key Servers. Figure 22-16 shows the Encryption Key Servers window, which is
empty now.
Figure 22-16 Select Create Key Server
4. Select Create Key Server from the Select action drop-down menu. The Create
Encryption Key Server dialog box displays, as shown in Figure 22-17.
Figure 22-17 Create Encryption Key Server
5. Select the ID, specify the Host Address (IP address or name of the Tivoli Key Lifecycle
Manager key server), and enter, in the Port field, the TCP port, which is displayed in the
Welcome to Key Lifecycle Manager window (in Chapter 12, Implementing Tivoli Key
Lifecycle Manager on page 265). Click OK. Now, you have configured the encryption key
server.
6. Repeat the steps to register the additional key servers (remember that you must configure
at least two key servers).
Chapter 23. DS8000 encryption features and
implementation
This chapter reviews the sequence of steps to configure an encryption-capable DS8000
storage server. The process differs slightly in the case of DS8100/DS8300 (Release 4.2 and
Release 4.3) and DS8700 (Release 5.0), so we describe those processes in separate
sections.
In this chapter, we describe the following topics:
DS8100/DS8300 (R4.2) GUI configuration for encryption on page 772
DS8700 (R5.0) GUI configuration for encryption on page 788
DS8000 DS CLI configuration for encryption on page 804
Encryption and Copy Services functions on page 810
23
23.1 DS8100/DS8300 (R4.2) GUI configuration for encryption
This section explains how to configure disk encryption on the DS8100/DS8300 Storage
Server Release 4.2 and 4.3 using the Storage Manager GUI. It is assumed that the TKLM
servers are already configured in the HMC.
The high-level configuration follows this sequence:
1. Configure the encryption group.
2. Apply the activation key.
3. Configure and administer encrypted arrays.
4. Configure and administer encrypted ranks.
5. Configure and administer encrypted extent pools.
23.1.1 Configuring the encryption group
The client data within the storage facility image (SFI) that is encrypted is partitioned in one
encryption group. The encryption group that contains encrypted data is enabled to access
data through one data key that is obtained from a key server.
An encryption group contains a set of extent pools, each of which has a set of associated
ranks and volumes. IBM FlashCopy and Remote Mirror and Copy functions can migrate data
within or between encryption groups.
Follow these steps to configure the encryption group on the DS8000:
1. In the My Work section, select Manage Hardware.
3. Select Groups.
Figure 23-1 shows the Manage Encryption Groups window.
Figure 23-1 Create Encryption Groups
4. Select Create Group from the Select action drop-down menu.
The Create Encryption Group window opens, as shown in Figure 23-2 on page 773.
Support: Currently, the DS8000 supports only one encryption group.
Chapter 23. DS8000 encryption features and implementation 773
Figure 23-2 Create Encryption Group: Add Key Label
5. Enter the Key Label, which was configured during the Tivoli Key Lifecycle Manager server
configuration (see Figure 23-3 Certificate label in keystore), and click OK. Now, the
encryption group is configured, as you can see in Figure 23-3.
Figure 23-3 Create Encryption Group: Added successfully
23.1.2 Applying the encryption activation key
Now that the Tivoli Key Lifecycle Manager key servers have been set up and are registered
with the DS8000, you must apply the encryption feature activation key, before the logical
configuration (defining ranks and extent pools) can take place.
To apply the encryption activation key:
2. Select Storage Images.
Important: Remember that the Encryption Authorization licensed internal code (LIC)
feature key cannot be obtained from the Disk Storage Feature Activation (DSFA) website.
3. Select the Storage Image and select Apply Activation Codes, from the Select Action
pull-down list box, as illustrated in Figure 23-4.
Figure 23-4 DS8000 Storage Images selection window
4. The Activation key dialog panel displays. If you are importing your activation codes from a
file, click Import key file (see Figure 23-5).
Note the Encryption Authorization field at the bottom of the panel.
Figure 23-5 DS8000 Apply Activation codes input panel
5. The Apply Activation codes: Real-time import window opens (see Figure 23-6). Enter the
name of the key file to import, and then, click OK to complete the import process.
Figure 23-6 DS8000 import key file window
If the file was not downloaded, manually enter the code into the appropriate field
(Encryption Authorization) on the Apply Activation codes window (Figure 23-5 on
page 774).
6. The license keys are installed. See Figure 23-7.
Figure 23-7 DS8000 Apply Activation codes input window with activated keys
23.1.3 Configuring and administering encrypted arrays
The creation of arrays is based on the array sites that are associated with the storage unit.
To create an array, perform the following steps in the DS GUI:
1. In the My Work section, select Configure Storage.
2. Select Disk Configuration.
3. Select Arrays. The Arrays task window opens, as shown in Figure 23-8.
Figure 23-8 Create an array
4. In Figure 23-8, from the Select storage image drop-down list box, select the storage image
where you want to add the array.
Create the new array by selecting Create from the Select Action drop-down menu.
Tip: Creating arrays first and then ranks is not necessary. Proceeding directly with the
creation of Extent Pools is possible. We explain this process in 23.1.5, Configuring and
administering encrypted extent pools on page 783.
5. In the Definition method window that opens (Figure 23-9), select one option:
Create arrays automatically
This option automatically selects an array site.
Create custom arrays
With this option, you must select the array site for the array.
Figure 23-9 Create array: Definition method window
Regardless of which option you choose, click Next.
The Array configuration window opens, as shown in Figure 23-10.
Figure 23-10 Create array: Array configuration window
6. Provide the following information:
Quantity of arrays
Shows the quantity of each type of disk drive module (DDM) that is physically installed
in the storage unit.
RAID type
The supported/available RAID types are listed (for example: RAID5, RAID6, and
RAID10).
When you have made your selections, click Next.
7. In the Add arrays to ranks panel (see Figure 23-11 for putting new arrays into ranks and
see Figure 23-12 on page 779 if the new arrays will not be put into ranks), provide the
following information:
Add these arrays to ranks
This option indicates that the new arrays will be put into ranks (checked) or indicates
that the new arrays will not be put into ranks (unchecked). If this box is checked, you
must select the Storage Type and Encryption Group.
Storage Type
This option indicates the type of extent for which the rank will be configured. You can
select either count key data (CKD) or fixed block (FB).
Encryption Group:
The DS8000 currently supports one encryption group. Consequently, 1 is the only
possible selection for the encryption group where the rank is created.
Figure 23-11 Create array: Add arrays to ranks
Figure 23-12 Create array: Add arrays to ranks is not selected
8. Click Next when you have made all your selections.
9. In the Verification panel, review and verify the information that you entered during the
creation process. To make changes, click Back, or click Cancel to cancel the process
altogether.
After making any changes and verifying the information, click Finish to create the array.
Figure 23-13 shows the Verification window for the case when the Add these arrays to
ranks box was unchecked (in Figure 23-12). Figure 23-14 on page 780 shows the
Verification window for the case when the Add these arrays to ranks box was checked.
Figure 23-13 Create array: Verification with no rank and Encryption group None
Figure 23-14 Create array: Verification with rank and Encryption group 1
Figure 23-15 shows the newly created array.
Figure 23-15 New array created
23.1.4 Configuring and administering encrypted ranks
A rank is a logically contiguous storage space that is made up of one array. You can assign a
rank to every unassigned array. A rank inherits the characteristics, including the RAID type, of
its parent array and is given a storage type attribute of either fixed block (FB) or count key
data (CKD).
The rank configuration state is unassigned until it is assigned to an extent pool. An
unassigned rank is not associated with either rank group 0 or 1. Any unassigned rank can be
assigned to an extent pool that is associated with either rank group 0 or 1.
You can assign a rank to an unassigned array and also assign the rank to an extent pool at
the same time if you have already created the extent pools and the arrays. Creating extent
pools first saves a step in the configuration.
To create a new encrypted rank:
1. Select Configure Storage.
3. Select Ranks. The Ranks task window opens, as shown in Figure 23-16.
4. From the Select storage image drop-down list box, select the storage image where the
rank will be added.
Figure 23-16 Create encrypted ranks
5. Select Create from the Select Action drop-down menu.
6. In the Select array for rank panel, as shown in Figure 23-17, choose an array from which
you want to create the rank, and then, click Next.
Figure 23-17 Select array for rank window
7. In the Define rank properties panel, as shown in Figure 23-18, make the following choices:
Storage type: Select either fixed block (FB) or count key data (CKD).
Encryption Group: Select either 0 or 1.
Figure 23-18 Define rank properties
After you make your selections, click Next.
8. The Select extent pool window opens, as shown in Figure 23-19.
Select an extent pool, and then, click Next.
Figure 23-19 Select extent pool
Encryption group: 0 = unencrypted and 1 = encrypted. Currently, the selected
encryption group for the first created rank will be used for all other created ranks.
Intermix between encrypted and unencrypted ranks is currently not supported in
an SFI.
9. In the Verification panel, as shown in Figure 23-20, review and verify the data for the rank,
and then, click Finish.
Figure 23-20 Verification window
23.1.5 Configuring and administering encrypted extent pools
Creating the encrypted extent pools before the encrypted arrays and encrypted ranks saves a
configuration step. When you create the new encrypted ranks, you can assign them to
existing encrypted extent pools. Otherwise, you must modify each rank object to complete the
extent pool ID assignment after the encrypted extent pools have been defined.
Each encrypted extent pool is defined with the rank group of 0 or 1. Extent pools that are
defined for rank group 0 or 1 are assigned an even-numbered or odd-numbered extent pool
ID. Even-numbered extent pools are managed by storage server ID 0. Odd-numbered extent
pools are managed by storage server ID 1.
Each rank is assigned to one extent pool. Therefore, storage server workload is affected by
the rank assignments to even-numbered and odd-numbered extent pool IDs. Always evenly
distribute rank and extent pool allocations to keep the storage server workloads balanced.
Perform the following steps to configure an extent pool:
3. Select Extent Pools (refer to Figure 23-21 on page 784).
If necessary, select from the Storage image drop-down list box, the name of the storage
image with which you are working. Look at the following sections of the panel:
Capacity Summary
Shows the total available capacity for open systems and IBM System z, allocated
capacity to standard volumes and Space Efficient repository, and ranks that are not
used in any extent pool.
Alerts
Shows any active alerts.
Manage Extent Pools
Shows the list of defined extent pools with the specified allocated storage, the name of
the extent pool, extent pool ID, status, available storage, RAID protection (RAID 5,
RAID 6, or RAID 10), and so on. It also provides the drop-down menu to perform
actions on extent pools. The Status field shows the general status information about
the extent pools in the storage unit.
Figure 23-21 Select Extent Pools
4. Select Create New Extent Pools from the Select action drop-down menu, as illustrated
in Figure 23-22.
Figure 23-22 Create New Extent Pools
5. The Create New Extent Pools window opens (Figure 23-23). It has the following sections:
Define Storage Characteristics
Specify the type of storage (FB or CKD) and RAID protection to use for the extent pool,
which can be RAID 5, RAID 6, or RAID 10.
Select Available Capacity
Specify the type of configuration (Automatic or Manual), type of physical disks,
capacity, and usage of device adapter pairs for the new extent pool in this section. If
Automatic is selected, the system automatically chooses which ranks to use based on
the selections of capacity, disk type, and adapter usage. But, if Manual is selected, you
have to decide which ranks to use for the new extent pool. In this section, the
Encryption field is new, and the choices for it can be either 1 (encryption enabled) or
None (encryption disabled).
Define Extent Pool Characteristics
Insert the number of extent pools to create, the prefix for the name of the extent pools,
the maximum percentage of storage threshold to generate an alert, and the
percentage of reserved storage in this section. You can also specify to which processor
to assign a specific extent pool, or have the system assign it automatically.
Figure 23-23 Create New Extent Pools: Define Storage Characteristics
6. When you complete your selections, click OK.
7. In the Create extent pool verification panel, as shown in Figure 23-24, review that the
extent pools configuration meets your needs. If the information is acceptable, click Create
All; otherwise, you can add additional extent pools or add capacity to one of the listed
extent pools.
Figure 23-24 Create extent pool verification
Now, the extent pool is created, as shown in Figure 23-25.
Figure 23-25 Create extent pools completed
8. Check the properties of an extent pool by selecting the extent pool and, then, clicking
Properties from the Select action drop-down menu, as illustrated in Figure 23-26.
Note that you can also select multiple extent pools.
Figure 23-26 Check for the properties of one extent pool
The Single Pool Properties window opens, as shown in Figure 23-27.
Figure 23-27 Extent Pool Properties
Figure 23-28 shows the pool properties when multiple extent pools are selected.
Figure 23-28 Multiple Pools Properties
23.2 DS8700 (R5.0) GUI configuration for encryption
This section explains how to configure disk encryption on the DS8700 Storage Server
Release 5.0 using the Storage Manager GUI. We assume that the Tivoli Key Lifecycle
Manager servers are already configured in the Hardware Management Console (HMC).
The high-level configuration follows this sequence:
1. Configure the recovery key.
4. Configure and administer the encrypted arrays.
5. Configure and administer the encrypted ranks.
6. Configure and administer the encrypted extent pools.
23.2.1 Configuring the recovery key
The DS8700 does not allow you to create the encryption group if the recovery key is not
configured. So, we need to create the recovery key first on a new system. You can obtain
more details in Chapter 24, DS8700 advanced encryption features and implementation on
page 811.
Follow these steps to create a recovery key:
1. Log in to the DS8000 Storage Manager GUI as a user with secadmin privileges.
2. Select Manage Hardware.
4. Select Groups.
5. Under the Select action drop-down menu, click Create Recovery Key, as shown in
Figure 23-29.
Figure 23-29 Create Recovery Key
A new window called Create Recovery Key opens (Figure 23-30).
Figure 23-30 Create Recovery Key window
Currently, only one encryption group is supported, which is already selected in the ID list.
6. Click Generate Key to continue.
After few seconds, the recently generated recovery key is displayed on the window, as
shown in Figure 23-31. It is displayed as 64 hexadecimal characters with dashes between
every four characters.
Figure 23-31 New recovery key has been generated
The security administrator is responsible for writing down the recovery key and storing the
paper in a safe place. Click Next.
7. To ensure that the written text is correct, type it into the Verify Recovery Key field
(Figure 23-32). Click Verify.
Figure 23-32 Recovery key verification
If the verification process passed, a confirmation appears in the same window, as shown
in Figure 23-33.
Figure 23-33 Recovery key verification passed
8. Click Finish to close the window.
Now you have created the recovery key, but it is waiting for the storage administrators
approval (see Figure 23-34).
Figure 23-34 Authorization pending status
9. Log in as the storage administrator to initiate the Authorize Recovery Key Update action,
which is highlighted in Figure 23-35.
Figure 23-35 Authorize Recovery Key Update
10.The Authorize Recovery Key Update window opens (Figure 23-36). If you agree with
creating a new recovery key, click Authorize Update to complete the process.
Figure 23-36 Authorize Recovery Key Update window
11.A successful authorization message appears on the same window (Figure 23-37).
Figure 23-37 The recovery key update has been authorized successfully
From that point, the new recovery key has been activated and can be used in the future. In
the Encryption Group panel, we can see its Configured status, as shown in Figure 23-38.
Figure 23-38 Configured recovery key
Now that the recovery key is ready for use, you can create the encryption group.
23.2.2 Configuring the encryption group
ranks and volumes. IBM FlashCopy and Remote Mirror and Copy functions can migrate data
Follow these steps to configure the encryption group on the DS8700:
1. Log in as the storage administrator.
4. Select Groups.
Figure 23-39 shows the Manage Encryption Groups window, where the recovery key has
been already established.
Figure 23-39 Create encryption group
5. Select Create Group from the Select action drop-down menu.
The Create Encryption Group window opens, as shown in Figure 23-40 on page 793.
Important: Currently, the DS8000 supports only one encryption group.
Figure 23-40 Create Encryption Group window
6. Depending on how many labels you have, fill the Key Label fields accordingly. In single
label mode, leave the Secondary Key Label field empty, and then, click OK.
The encryption group creation takes approximately a minute (Figure 23-41).
Figure 23-41 Create Encryption Group is in progress
7. Wait until the Finished message is displayed, as seen in Figure 23-42, and then, click
Close.
Figure 23-42 Create Encryption Group process has finished
8. Verify, in the Encryption Group panel, that the Group State is Accessible, as shown in
Figure 23-43.
Figure 23-43 Configured Encryption Group in dual key mode
23.2.3 Applying the encryption activation key
Now that you have set up the Tivoli Key Lifecycle Manager key servers and registered them
Follow these steps to apply the encryption activation key:
3. Select Storage Complexes.
4. Select the Storage Image, and from the Select Action pull-down menu, select Apply
Activation Codes, as highlighted in Figure 23-44.
Figure 23-44 Apply Activation Codes
Important: Remember that you cannot obtain the Encryption Authorization LIC feature key
from the Disk Storage Feature Activation (DSFA) website.
The Apply Activation Codes window opens (Figure 23-45), which shows all the active keys
that have already been applied on the storage system.
Figure 23-45 Apply Activation Codes window
If required, add additional keys by typing them into an input box (Select action Add
Activation Key, as shown in Figure 23-46) or select the file, which contains a list of new
codes (Select action Import Key File, as shown in Figure 23-47 on page 796).
Figure 23-46 Apply Activation Codes input window
Figure 23-47 Import key file dialog
23.2.4 Configuring and administering encrypted arrays
The creation of arrays is based on the array sites that are associated with the storage unit.
To create an array, perform the following steps in the DS GUI:
2. In the My Work section, select Configure Storage.
4. Select the Arrays tab in the Manage Disk Configuration frame.
5. Select the Create Arrays menu entry, as highlighted in Figure 23-48.
Figure 23-48 Starting the Create Arrays function
The Create New Arrays window opens, as shown in Figure 23-49 on page 797.
Tip: Creating arrays first and then ranks is not necessary. Proceeding directly with the
creation of Extent Pools is possible, which we explain in 23.2.6, Configuring and
administering encrypted extent pools on page 801.
Figure 23-49 Create New Arrays window: Automatic Configuration mode
6. In Figure 23-49, select the RAID Type that you want to use. The supported RAID types are
RAID5, RAID6, and RAID10.
7. Specify the way that you want to create arrays by choosing one of the options from the
Type of Configuration list box:
Automatic: In this case, you need to select the Drive Class and the number of required
arrays, and then, the system determines an optimal setup depending on the DA Pair
Usage preference.
Manual: You get a list of available array sites, and you can select them on your own.
8. Click OK.
The next window gives you an overview of the new arrays, as shown in Figure 23-50. We
can click Cancel to cancel the operation, if something is wrong. Otherwise, select all the
rows, and click Create All to continue. In this example, we create two RAID6 arrays.
Figure 23-50 Overview of the arrays that we plan to create
9. Wait until the job completes (Figure 23-51 on page 798).
Figure 23-51 Creating arrays job has finished
10.The arrays are ready, and we can verify them. Open the Arrays tab again to see the
results. In this example, we have created two arrays successfully, as shown in
Figure 23-52.
Figure 23-52 Verify the new arrays
In the Encryption Group column, the state is None at this stage, because the encryption is
defined in the rank level, so we will set it in the next section.
23.2.5 Configuring and administering encrypted ranks
A rank is a logically contiguous storage space that is made up of one array. You can assign a
rank to every unassigned array. A rank inherits the characteristics, including the RAID type, of
its parent array and is given a storage type attribute of either FB (fixed block) or CKD (count
key data).
The rank configuration state is unassigned until it is assigned to an extent pool. An
unassigned rank is not associated with either rank group 0 or 1. You can assign any
unassigned rank to an extent pool that is associated with either rank group 0 or 1.
You can assign a rank to an unassigned array and also assign the rank to an extent pool at
the same time if you have already created the extent pools and the arrays. Creating extent
pools first saves a step in the configuration.
Follow these steps to create a new encrypted rank:
4. Select the Ranks tab in the Manage Disk Configuration frame.
5. Select the Create Ranks menu entry, as highlighted in Figure 23-53.
Figure 23-53 Starting the Create Ranks function
The Create New Ranks window opens (Figure 23-54).
Figure 23-54 Create New Ranks window
6. Select the Storage Type (FB or CKD) and the RAID Type (RAID5, RAID6, or RAID10).
If arrays have been created in advance, use the same RAID type to utilize them;
otherwise, new arrays will be created.
7. Select the way that you create ranks by choosing one of the options from the Type of
Configuration list:
Automatic: In this case, you must select the Drive Class and the number of required
ranks, and then, the system determines an optimal setup, depending on the DA Pair
Usage preference.
Manual: You get a list of available arrays, and you can select them on your own.
8. Select the encryption group. Currently, encryption intermix is not allowed, so you have to
decide whether all the storage will be encrypted or not. When you create the first rank, you
can enable or disable it, but the following ranks must use the same setting as the first rank.
Therefore, you cannot change the encryption group selection later.
9. Click OK.
The next window gives you an overview of the new ranks, as shown in Figure 23-55. We
can click Cancel to cancel the operation, if something is wrong. Otherwise, select all the
rows, and click Create All to continue. In this example, we create two encrypted CKD
ranks on our RAID6 arrays.
Figure 23-55 Overview of the ranks we plan to create
10.Wait until the job finishes. To follow the progress in real time, open the Long Running
Task Properties window to see the details, as shown in Figure 23-56.
Figure 23-56 Creating ranks in progress
11.Verify the new ranks under the Ranks tab. This view lists the Encryption Group property,
Figure 23-57 Verify the new ranks
These ranks can be part of an encrypted extent pool, which we will create in the next
section.
23.2.6 Configuring and administering encrypted extent pools
The process of creating encrypted extent pools is similar to the process of creating ranks. We
will see almost the same dialog windows, but we need to select ranks instead of arrays.
Create the separate storage layers (arrays, ranks, and extent pools) step-by-step, but it is not
mandatory to prepare the lower layers before you start the extent pool configuration. If you
select more ranks than already exist, the system will create them automatically based on the
defined storage (FB or CKD) and RAID type. Use this shorter process only if the automatic
rank assignments and array assignments are suitable for you.
Each encrypted extent pool is defined with the rank group of 0 or 1. Extent pools that are
defined for rank group 0 or 1 are assigned an even-numbered or odd-numbered extent pool
ID. Even-numbered extent pools are managed by storage server ID 0. Odd-numbered extent
pools are managed by storage server ID 1. Each rank is assigned to one extent pool.
Therefore, storage server workload is affected by the rank assignments to even-numbered
and odd-numbered extent pool IDs. Evenly distribute rank and extent pool allocations to keep
the storage server workloads balanced. The Automatic configuration mode helps you set the
rank and extent pool allocations optimally.
Perform the following steps to configure an encrypted extent pool:
4. Select the Extent pools tab in the Manage Disk Configuration frame.
5. Select the Create Extent Pools menu entry, as highlighted in Figure 23-58 on page 802.
Figure 23-58 Starting the Create Extent Pools function
The Create New Extent Pools window opens (Figure 23-59).
Figure 23-59 Create New Extent Pools window
6. Select the Storage Type (FB or CKD) and the RAID Type (RAID5, RAID6, or RAID10). If
ranks have been created in advance, use the same RAID type to utilize them; otherwise,
new ranks will be created.
7. Specify the way that you create extent pools by choosing one of the options from the Type
of Configuration list:
Automatic: In this case, you must select the Drive Class and the number of required
ranks, and then, the system determines an optimal setup, depending on the DA Pair
Usage preference. A small diagram shows the current and the new rank distributions.
Manual: You get a list of available ranks, and you can select them on your own.
8. Specify the encryption group. Currently, encryption intermix is not allowed, so if you
already have encrypted ranks, the extent pool must be encrypted, also.
9. Click OK.
The next window gives you an overview of the new extent pools, as shown in
Figure 23-60. You can click Cancel to cancel the operation, if something is wrong.
Otherwise, select all the rows, and click Create All to continue. In this example, we create
an encrypted extent pool for our existing RAID6 CKD ranks.
Figure 23-60 Overview of the extent pool that we plan to create
10.When the job finishes, verify the new extent pools under the Extent Pools tab, as shown
in Figure 23-61.
Figure 23-61 Verify the new extent pool
11.To verify that it is actually encrypted, select the extent pool and open the Single Pool
Properties window (Figure 23-62). The Encryption Group status is displayed on it.
Figure 23-62 Single Pool Properties window
Now that the encrypted extent pools are ready, you can create encrypted volumes inside
them. Each volume has the same encryption properties as the parent extent pool, which
cannot be modified. You can obtain the actual settings from the Single Volume Properties
window, as shown in Figure 23-63 on page 804.
Figure 23-63 FB and CKD Volume Properties windows
23.3 DS8000 DS CLI configuration for encryption
This section explains how to configure disk encryption on the DS8000 Storage Server using
the DS command-line interface (DS CLI). The high-level configuration sequence consists of
the following steps:
1. Configure the Tivoli Key Lifecycle Manager server connection to the DS8000.
4. Configure and administer encrypted arrays.
5. Configure and administer encrypted ranks.
6. Configure and administer encrypted extent pools.
23.3.1 Configuring the Tivoli Key Lifecycle Manager server connection
The DS8000 supports up to four Tivoli Key Lifecycle Manager key server connections (ports).
The following suggestions apply to configurations:
In multiple site configurations, assign at least two of the key server ports to isolated key
servers at separate physical sites. You can connect the remaining ports to general key
servers.
In single site configurations, assign at least two of the key server ports to isolated key
servers at the same site.
Note: For detailed information about the CLI and commands, refer to the DS Command
Line Interface Users Guide for the DS8000 series:
http://publib.boulder.ibm.com/infocenter/dsichelp/ds8000ic/index.jsp
The DS8000 configuration for encryption also requires that you connect and define at least
two active key servers at the DS8000.
To configure the Tivoli Key Lifecycle Manager server connection, use the lskeymgr and
mkkeymgr commands:
1. Issue the lskeymgr command to view the list of already registered Tivoli Key Lifecycle
Manager servers, if any.
Enter the lskeymgr command at the dscli command prompt with the parameters and
variables, as illustrated in Example 23-1. In this example, we already had one Tivoli Key
Lifecycle Manager server, named popcorn, registered with the DS8000.
Example 23-1 List existing Tivoli Key Lifecycle Manager servers
dscli> lskeymgr -l
Date/Time: February 27, 2009 9:16:59 PM MST IBM DSCLI Version: 5.4.2.540 DS: -
ID state status addr port
===============================
1 active normal popcorn 3801
2. Issue the mkkeymgr command to add a new Tivoli Key Lifecycle Manager server.
Enter the mkkeymgr command at the dscli command prompt with the parameters and
variables, as illustrated in Example 23-2. In this example, we added a second Tivoli Key
Lifecycle Manager server named peanuts to the DS8000 configuration.
Example 23-2 Add new Tivoli Key Lifecycle Manager server
dscli> mkkeymgr -addr peanuts 2
CMUC00354I mkkeymgr: The key server 2 has been created.
3. Verify that the new Tivoli Key Lifecycle Manager server was added successfully, the state
is active, and the status is normal. Again, issue the lskeymgr command with the -l
parameter, as shown in Example 23-3.
Example 23-3 Verifying the Tivoli Key Lifecycle Manager servers
dscli> lskeymgr -l
ID state status addr port
======================================
1 active normal popcorn 3801
2 active normal peanuts 3801
4. To delete a Tivoli Key Lifecycle Manager server you can issue the rmkeymgr command with
the parameters and variables in Example 23-4.
Example 23-4 Removing Tivoli Key Lifecycle Manager server from configuration
dscli> rmkeymgr 2
CMUC00356I rmkeymgr: Are you sure you want to delete the key server 3? [y/n]:y
CMUC00357I rmkeymgr: The key server 2 has been deleted.
23.3.2 Configuring and administering the encryption group
ranks and volumes. The FlashCopy and Remote mirror and copy functions can migrate data
In the case of DS8700, you must establish the recovery key first, and then, you can configure
the encryption group. Refer to 24.2, Recovery key support on page 814 for DS CLI
commands.
Follow these steps to configure the encryption group using the DS CLI commands:
1. Issue the lskeygrp command to view a list of existing key groups. Enter the lskeygrp
command at the dscli command prompt with the parameters and variables that are
Example 23-5 Listing key groups
dscli> lskeygrp -dev IBM.2107-75HT551 -l
Date/Time: February 27, 2009 9:51:40 PM MST IBM DSCLI Version: 5.4.2.540 DS: IBM
.2107-75HT551
CMUC00234I lskeygrp: No Encryption Group found.
2. Issue the mkkeygrp command to add the new encryption key group. Enter the mkkeygrp
command at the dscli command prompt with the parameters and variables that are
Example 23-6 Creating a key group
dscli> mkkeygrp -dev IBM.2107-75HT551 -label imaginary1 1
.2107-75HT551
The key server encryption key group 1 has been created.
3. Verify that the encryption group was added successfully and that its state is accessible by
issuing the lskeygrp command with the -l parameter, as shown in Example 23-7.
Example 23-7 Listing defined key groups
dscli> lskeygrp -dev IBM.2107-75HT551 -l
.2107-75HT551
ID numranks numpools state label
============================================
1 5 6 accessible imaginary1
DS8000: Currently, the DS8000 supports only one encryption group.
DS8700: In the case of DS8700, you can specify the secondary label with the -label2
parameter.
23.3.3 Applying encryption activation key
Now that the Tivoli Key Lifecycle Manager key servers have been set up and are registered
The DS CLI applykey command activates the licenses for your storage unit. The DS CLI
lskey command verifies which type of licensed features are activated for your storage unit.
To apply the encryption activation key, issue the following command:
dscli> applykey -file c:\keys.xml -dev IBM.2107-75HT551
This example presumes that your XML file is named keys.xml and that it resides in the root
directory of your C: drive.
Issue the lskey command to verify that the license codes have been applied:
dscli> lskey -dev IBM.2107-75HT551
23.3.4 Creating encrypted arrays
Complete this task to create encrypted arrays using the DS CLI commands.
Use the lsarraysite and mkarray commands to create the arrays.
An array inherits the characteristics of its parent array sites and is given a RAID type attribute
(5, 6, or 10). A DS8000 array of RAID type 5, 6, or 10 is made from one (8 DDM) array site.
The status of the array is unassigned until the array is assigned to a rank.
Perform these steps to create an encrypted array from unassigned array sites:
1. Issue the lsarraysite command to view a list of array site IDs for all installed array sites.
Review those arrays that are designated with the state of unassigned. Enter the
lsarraysite command at the dscli command prompt with the following parameters and
variables:
dscli> lsarraysite -dev IBM.2107-75HT551 -state unassigned -l
2. Press Enter.
A report of unassigned array sites is displayed. Use the list to identify unassigned array
site capacity, disk revolutions per minute (rpm), and device adapter (DA) pair attributes.
Record the RAID type for each array site. Example 23-8 shows an illustration.
Example 23-8 Listing array sites
dscli> lsarraysite -dev IBM.2107-75HT551 -state unassigned -l
.2107-75HT551
arsite DA Pair dkcap (10^9B) diskrpm State Array diskclass encrypt
=========================================================================
S8 0 450.0 15000 Unassigned - ENT supported
Tip: Make sure that the array site supports encryption. If this step is the first time that
you create fixed block volumes, all the arrays are displayed with a state of unassigned.
3. Issue the mkarray command to create an array from one array site with the status
unassigned. Enter the mkarray command at the dscli command prompt with the
following parameters and variables:
dscli>mkarray -dev storage_image_ID -raidtype 6 -arsite array_site
Consider the following information when you create the arrays:
Specify one array site with identical capacity, rpm, interface, and DA pair attributes.
The new array inherits the capacity, rpm, interface, and DA pair characteristics of its
parent array site.
The state of the array remains unassigned until it is assigned to a rank.
4. Verify that the array-to-array site assignment is recognized and complete by issuing either
the lsarray or lsarraysite command with the -l parameter. Example 23-9 gives an
illustration.
Example 23-9 Verifying the arrays
dscli> lsarray -dev IBM.2107-75HT551 -l
Date/Time: February 27, 2009 8:38:41 PM MST IBM DSCLI Version: 5.4.2.540 DS:
IBM.2107-75HT551
Array State Data RAIDtype arsite Rank DA Pair DDMcap (10^9B)
diskclass encrypt
===============================================================================
A0 Assigned Normal 5 ( 6+P+S ) S8 R1 0 450.0 ENT supported
23.3.5 Creating encrypted ranks
Use the lsarray, mkrank, and lsrank commands to assign a rank to each unassigned array.
To create ranks, perform the following steps:
1. Ensure that you have a list of the unassigned arrays for which ranks must be assigned.
Issue the lsarray command to obtain this list if you do not already have it. Enter the
lsarray command at the dscli command prompt with the following parameters and
variables:
dscli>lsarray -dev IBM.2107-75HT551 -state unassigned
2. Issue the mkrank command to assign a rank to rank group 0 or 1, according to the rank
group number of the assigned extent pool ID.
To create an encrypted rank, use the -encryptgrp variable.
Enter the mkrank command at the dscli command prompt with the parameters and
variables, as shown in Example 23-10, for the fixed block storage type.
Example 23-10 Assigning an array to a rank
dscli>mkrank -dev IBM.2107-75HT551 -array A1 -stgtype fb -wait -encryptgrp 1
Date/Time: February 27, 2009 1:55:50 PM MST IBM DSCLI Version: 5.4.2.540 DS:
IBM
.2107-75HT551
Rank IBM.2107-75HT551/R0 successfully created.
3. Press Enter to display a report of rank assignments for your entire storage unit. Because
the process of creating the rank involves formatting drives, the process can take time
before it finishes. If you want to check on the process, issue the lsrank command from a
separate DS CLI session.
4. Issue the lsrank command to verify that ranks and extent pools have been assigned.
Enter the lsrank command at the dscli command prompt with the parameters and
variables that are shown in Example 23-11.
5. Press Enter to display a report of the rank assignments for your entire storage unit.
Example 23-11 Verifying the ranks
dscli> lsrank -dev IBM.2107-75HT551 -l
.2107-75HT551
ID Group State datastate Array RAIDtype extpoolID extpoolnam stgtype exts usede
xts encryptgrp
===========================================================================================
===
R0 0 Normal Normal A1 10 P0 raid10P0 fb 1186 1 152
1
23.3.6 Creating encrypted extent pools
Complete this task to create encrypted volume extent pools. This step is the first step in
configuring new encrypted fixed block storage.
Issue the mkextpool command to create the encrypted extent pool for rank group 0 (zero).
Enter the mkextpool command at the dscli command prompt with the parameters and
variables, as shown in Example 23-12, for fixed block extent pools. Make sure that
-encryptgrp 1 represents the encryption group ID and P0 represents the extent pool name
that you assign. This name can be 16 double-byte characters.
Example 23-12 Creating encrypted FB extent pool
dscli>mkextpool -dev IBM.2107-75HT551 -rankgrp 0 -stgtype -encryptgrp 1 fb P0
.2107-75HT551
Extent pool P0 successfully created.
Verify the extent pool assignments by issuing the lsextpool command when you have
finished creating the extent pools. Use the -l parameter to display a full report for the extent
pools that are assigned to the storage unit.
Explanation:
The -encryptgrp encryption_group_ID specifies the encryption group that this rank
must use. The default is 0 (zero), which means that no encryption group is assigned
to the rank.
You can specify either the -wait or the -extpool parameter when you use the mkrank
command. Either of these parameters allows you to be notified if the rank
configuration fails for any reason.
If you use the -wait parameter, you cannot issue other commands until the entire
transaction has been processed.
Enter the lsextpool command at the dscli command prompt with the parameters and
variables, as shown in Example 23-13.
Example 23-13 Verifying the extent pool assignments
dscli> lsextpool -dev IBM.2107-75HT551 -l
.2107-75HT551
Name ID stgtype rankgrp status availstor (2^30B) %allocated available rese rved
numvols numranks encryptgrp
==================================================================================
raid10P0 P0 fb 0 below 34 97 34 0 24
1 1
All ranks and extent pools on a given encryption-capable DS8000 SFI must be configured
with the same encryption group attribute. The first rank or encryption group that is configured
determines what the remaining objects must be configured with. A value of 0 indicates
encryption disabled. A value of 1 indicates encryption enabled.
To change between encryption enabled and encryption disabled, all ranks and extent pools
must be unconfigured. Unconfiguring an encryption-enabled rank causes any data that is
stored on the rank to be cryptographically erased (the disk is instructed to reset its own
encryption key) and subsequently overwritten to re-initialize the rank.
23.4 Encryption and Copy Services functions
Copy Services operations are not affected by encrypting drives. The encryption applies only
to data at rest, which is the data that is physically written to the disk drives. If you are
performing remote replication of the encrypted data, when the data is read from the source
disk, it is decrypted, sent across the network link, and if the target storage system is also set
up for encryption, when the data is written to disk at the target site, it is encrypted again.
There is no relationship between the encryption that is done at the source and the encryption
at the target. These operations are completely independent operations with their own set of
keys and potentially even their own key managers (Tivoli Key Lifecycle Manager), depending
on how the environment is configured.
This encryption strategy also applies, by the way, for FlashCopy. Although this copy is a T0
copy of data that only resides with the DS8000, when the source data is read and rewritten to
the FlashCopy target volume, it will be decrypted at read and re-encrypted at write. The
encryption itself is not intrusive in terms of performance, because it is all performed by the
drives themselves.
Chapter 24. DS8700 advanced encryption
features and implementation
This chapter describes the new encryption-related features that were introduced in DS8700
(DS8000 Release 5.0) storage systems:
New security roles: Storage and security administrator on page 812
Recovery key support on page 814
Dual platform key server support on page 833
Whenever it is possible, we used the DS8700 Storage Manager Web-based GUI to
demonstrate the functions, but we also provided the corresponding DS command-line
interface (CLI) commands.
24
24.1 New security roles: Storage and security administrator
The DS8000 comes with an internal authentication and authorization service, which is called
the Basic authentication service. This service also provides user management and is
identical to the service that is provided in previous DS8000 models. The DS8700 allows you
to use an external authentication service, such as a Lightweight Directory Access Protocol
(LDAP) server. The DS8700 still uses the internal authorization service to grant access to
resources as defined by the DS8700 user group roles of admin, op_storage, op_volume,
op_copy_services, service, and monitor.
An authentication policy defines the authentication service to use, any parameters that are
required to connect to and utilize that authentication service, and any mappings from that
services user groups to the DS8700 user group roles. It is assumed that any external
authentication service will provide tools for user account management; therefore, the DS8700
will only manage user accounts that are defined in the Basic authentication service. Currently,
the DS8700 defines two policy types, Basic and Storage Authentication Service (SAS). The
Basic policy type uses the DS8700 Basic authentication service, and the SAS policy type
uses the authentication service that is provided by an IBM System Storage Productivity
Center (IBM SSPC).
With the introduction of the encryption recovery key, a dual control security process is
required to protect the authorized usage of the recovery key. This dual control process
requires two separate user accounts to process most recovery commands. If these accounts
are owned by two separate people, the recovery key cannot be used by any one person to
gain access to encrypted data. The first user role is the same admin user group role that has
existed in previous versions of the DS8000, but it is now referred to as a storage
administrator. The second user role, secadmin, is referred to as a security administrator.
Both users are created by default, as shown in Figure 24-1.
Figure 24-1 Default user roles: admin and secadmin
Any user that has secadmin authority cannot have the authority of any other user role, and a
user with any other user role cannot have the secadmin authority at the same time. The
secadmin can create only new secadmins (see Figure 24-2 on page 813). The storage admin
can create any kind of users without secadmin authority (see Figure 24-3 on page 813).
Passwords: The initial admin password is admin, and the secadmin password is
secadmin. The first time that you log in, you must change the password to a new
password. Because these users are owned by separate people, the admin and secadmin
passwords must not be stored in one place.
Chapter 24. DS8700 advanced encryption features and implementation 813
Figure 24-2 Add new user as secadmin
Figure 24-3 Add new user as admin
This isolation of the secadmin authority is extended into the creation of a SAS policy by
restricting who can specify mapping of external users and groups to the secadmin role to only
those users with secadmin authority. This last restriction can create problems if the active
SAS policy does not have any valid users or groups mapped to the secadmin role, because
no user can initiate any of the recovery key operations. To avoid these problems, use the
following SAS creation procedure:
1. Create a new SAS policy, or copy an existing SAS policy.
2. A security administrator specifies the mappings to the secadmin role.
3. A storage administrator specifies all other attributes and mappings of the SAS policy.
4. Test the new policy.
5. Activate the new policy.
In the dual control process, the security administrator initiates a recovery key operation, and
the storage administrator authorizes the operation which completes, or activates, it. The
storage administrator cannot initiate any recovery key operation, and a security administrator
cannot authorize any recovery key operation. Figure 24-4 lists the complete set of roles.
Figure 24-4 Storage and Security Administrator roles
24.2 Recovery key support
Whenever an encryption technology is applied, a new kind of risk appears: the deadlock
situation. Deadlock happens when the necessary keys on the Tivoli Key Lifecycle Manager
servers are lost somehow, so that all the data becomes inaccessible. Without the keys, the
data can no longer be decrypted. You can obtain more details about the deadlock situation in
Chapter 3, IBM storage encryption methods on page 49.
You can greatly minimize the risk of the deadlock situation by maintaining redundant (dual
platform) Tivoli Key Lifecycle Manager servers, but you cannot eliminate the risk of a
deadlock. The recovery key feature provides a way to get out of a deadlock state. See 3.4,
DS8000 disk encryption on page 60 for more details.
24.2.1 Configuring the recovery key
The DS8700 does not allow you to create an encryption group while the recovery key is not
configured. So, we need to create the recovery key first on a new system.
Follow these steps:
1. Only the security administrator is allowed to initiate this process, so log in to the DS8000
Storage Manager graphical user interface (GUI) as a user with secadmin privileges. Then,
navigate to the Manage Hardware Encryption Groups window, where under the
Select action drop-down menu, you click Create Recovery Key, as shown in Figure 24-5
on page 815.
General roles:
- Administrator
- Physical Operator
- Logical Operator
- Copy Services Operator
- Monitor
Dual control role:
- Security Admin. authorization
Security roles:
- Create Recovery Key
- Verify Recovery Key
- Initiate Recovery
- Re-key Recovery Key
- Delete Recovery Key
Storage Administrator Security Administrator
Figure 24-5 Create Recovery Key
2. The Create Recovery Key window opens (Figure 24-6).
Figure 24-6 Create Recovery Key window
3. Currently, only one encryption group is supported, which is already selected in the ID list,
so, click Generate Key to continue. After few seconds, the recently generated recovery
key is displayed on the window, as shown in Figure 24-7. It is displayed as 64 hexadecimal
characters with dashes between every four characters.
Figure 24-7 New recovery key has been generated
4. The security administrator is responsible for documenting the recovery key and providing
a recoverable means, that is, documenting it in a secured operations notebook. To ensure
that the written text is correct, type it into the field of the next window (Figure 24-8) for
verification.
Figure 24-8 Recovery key verification
If the verification process passed, a confirmation message appears in the same window,
Figure 24-9 Recovery key verification passed
5. Click Finish to close the window. Now, the recovery key has been created, but it is waiting
for the storage administrator approval (see Figure 24-10).
Figure 24-10 Authorization pending status
Document the recovery key: Or, you can use the mkreckey DS CLI command. Do not
copy the new recovery key text from the terminal and save it in a file to print, because
the key can be sniffed in the network. It is better to document the recovery key
elsewhere.
6. Log in as the storage administrator. Click Authorize Recovery Key Update, which is
highlighted in Figure 24-11.
Figure 24-11 Authorize Recovery Key Update
The Authorize Recovery Key Update window opens (Figure 24-12).
7. If you want to authorize the recovery key update, click Authorize Update to complete the
process (Figure 24-13).
Figure 24-13 The recovery key update has been authorized successfully
From that point forward, the new recovery key is activated and it can be used in the future. In
the Encryption Group panel, we can see its Configured status, as shown in Figure 24-14.
Figure 24-14 Configured recovery key
Now that the recovery key is ready, you can create the encryption group. Follow the process
that is documented in Chapter 23, DS8000 encryption features and implementation on
page 771. When you complete the process, the encryption group state must be Accessible,
Figure 24-15 Encryption Group state is Accessible
You can use this encryption group when you define new ranks on the system. Refer to 23.3.5,
Creating encrypted ranks on page 808.
The flowchart in Figure 24-16 gives an overview of how to create a new recovery key. It
contains the recovery key states and the DS CLI commands, as well.
Figure 24-16 Configure recovery key flowchart
24.2.2 Validating the recovery key
During the recovery key creation process, you verify the generated key, which ensures that it
was written correctly. Later, it is useful to verify that the stored key is still valid so that, in the
case of an emergency, you can use it to unlock the storage system. For this purpose,
implement the recovery key validation, so that the security administrators can validate the key
whenever they want. Only users with security administrator authority can validate the
recovery key. This validation process does not change anything in the system, and storage
administrator approval is not needed.
Storage Administrator
Create Recovery Key
Verify Recovery Key
Authorize Recovery
Key Update
Security Administrator
Recovery Key
State
n/a
New Key Verification Pending
New Key Authorization Pending
Configured
mkreckey
managereckey
-action verify
managereckey
-action authorize
Follow these steps:
1. Navigate to the Manage Hardware Encryption Groups panel to select the Validate
Recovery Key menu entry, as shown in Figure 24-17.
Figure 24-17 Starting the Validate Recovery Key function
2. The Validate Recovery Key window opens (Figure 24-18). Type the key into the field.
Then, click Validate.
Figure 24-18 Validate Recovery Key window
If the key is valid, a confirmation message will appear on the same window (see
Figure 24-19).
Figure 24-19 The recovery key was validated successfully
The flowchart of this process is quite simple, as shown in Figure 24-20 on page 820.
Figure 24-20 Validate Recovery Key flowchart
24.2.3 Initiating recovery
If the Tivoli Key Lifecycle Manager servers are down or inaccessible for any reason, you
cannot start the DS8000 Storage Facility Image (SFI). Without the keys, the storage remains
in locked mode. In this situation, you have two choices:
Repair at least one of the Tivoli Key Lifecycle Manager servers or its network connectivity
to be able to serve the necessary key for the DS8700.
Initiate the recovery process to unlock the SFI to let the volumes be accessible again.
Start with the first option, and depending on the result (time needed for restoring the Tivoli
Key Lifecycle Manager server), initiate the recovery process as a last resort to get the data
back online.
Demonstrating a Tivoli Key Lifecycle Manager failure
In this section, we demonstrate a real-life example of how the recovery key works. Imagine a
site disaster where all the Tivoli Key Lifecycle Manager servers have failed, as shown in
Figure 24-21.
Figure 24-21 Tivoli Key Lifecycle Manager servers are not functioning
The DS8000 Hardware Management Console (HMC) monitors the availability of the Tivoli
Key Lifecycle Manager servers. The connection is verified in every 5 minutes. The Last
Access column, in Figure 24-21, shows the last time stamp when the Tivoli Key Lifecycle
Manager server answered the heartbeat request. If the HMC detects the outage of a Tivoli
Key Lifecycle Manager server, the BE14EAF1 SRC will be reported (see Figure 24-22 on
page 821), which is only an early notification. When the outage exceeds the four hour limit,
the BE14EAF2 error is reported as a call home event, so that both the client and IBM are
Validate Recovery Key
Recovery Key
State
Configured
Configured
managereckey
-action validate
alerted about this incident. See the Appendix B, DS8700 encryption-related system
reference codes on page 873 for reference.
Figure 24-22 Sample BE14EAF1 SRC
The Tivoli Key Lifecycle Manager servers are accessed only when the key is required for the
DS8000 (excluding the heartbeat verification). In most cases, this access happens when the
SFI is starting, but several of the reliability, serviceability, and availability (RAS) functions,
such as Concurrent Code Load (CCL), also trigger a Tivoli Key Lifecycle Manager key
retrieval. The easiest way to reach this point if we turn off the SFI (with logical partitions
(LPARs)). Use the HMC GUI, as shown in Figure 24-23.
Figure 24-23 LPARs are shut down
If we start the SFI again while the Tivoli Key Lifecycle Manager servers are still down, we
notice that the initialization progress is much slower, because warm starts are initiated in
order to configure the storage devices. Without the essential key from Tivoli Key Lifecycle
Manager servers, the configuration phase fails, and the DS8000 stops trying to retrieve the
key and reports the failure by using one of these error messages:
BE14E008: Unable to retrieve keys from any configured encryption key management
servers due to communication errors between the HMC and encryption key
management server(s).
Figure 24-24 on page 822 shows a sample system reference code (SRC).
Figure 24-24 Sample BE14E008 SRC
BE1E2058: Config Error - Global Data Inaccessible (Figure 24-25).
Figure 24-25 Sample BE1E2058 SRC
The encryption group also reflects the Inaccessible state, as shown in Figure 24-26 on
page 823.
Figure 24-26 Encryption Group is Inaccessible
Initiating the recovery process
Follow these steps to start the recovery process:
1. Log in as the security administrator, and select Initiate Recovery, as highlighted in
Figure 24-27.
Figure 24-27 Starting the recovery process
2. The Initiate Recovery window opens (Figure 24-28).
Figure 24-28 Initiate Recovery window
3. The Recovery process requires the valid recovery key. Type it into the input field in the
same way that it was shown on the window (uppercase characters with dash separators).
Then, click Initiate. A confirmation message is displayed, as shown in Figure 24-29 on
page 824.
Figure 24-29 The Recovery process was initiated successfully
4. Click Close to close the window. In Figure 24-30, notice that the Recovery Key State has
changed to Request Recovery Authorization Pending state.
Figure 24-30 Request Recovery Authorization Pending state
5. The storage administrator has to approve our request. Select Authorize Recovery Key
Update to finalize the recovery, as highlighted in Figure 24-31.
Figure 24-31 Start Authorize Recovery Key Update
6. The Authorize Input Recovery Key window opens (Figure 24-32).
Figure 24-32 Authorize Input Recovery Key window
7. If you click Authorize Update, you get a confirmation message, such as the message that
is shown in Figure 24-33.
8. To complete the recovery process, restart the SFI.
Figure 24-33 Recovery process has been authorized successfully
You can follow the restart process by viewing the LPAR status messages on the HMC
(Figure 24-34).
Figure 24-34 SFI restart is in progress
Depending on the DS8000 configuration, you will need to wait several minutes to finish the
initialization. When it becomes ready, the Group State changes to Accessible, as shown in
Figure 24-35, which means that the volumes are online and can be accessed from the
hosts.
Figure 24-35 Group State is Accessible again
Figure 24-36 shows the flowchart and the corresponding DS CLI commands of the Recovery
process.
Figure 24-36 Initiate Recovery flowchart
24.2.4 Using the process to rekey the recovery key
In case you lose the recovery key or if you suspect that an unauthorized person might access
to the key, the security administrator can decide to regenerate the recovery key. If you
regenerate the recovery key, the old key becomes revoked and it cannot be used anymore.
This process is called rekey recovery key.
Follow these steps:
1. Navigate to the Manage Hardware Encryption Groups panel. Select Re-key
Recovery Key, as shown in Figure 24-37.
Figure 24-37 Starting the Re-key Recovery Key function
The Re-key Recovery Key window opens (Figure 24-38 on page 827).
Important: This process is not a permanent operation, because the recovered SFI is
unlocked only until the next power cycle. But while the system is up and running, you have
time to repair the Tivoli Key Lifecycle Manager infrastructure. If all the Tivoli Key Lifecycle
Manager servers are lost forever (and there is no backup available), you must re-create the
encryption group in the future, which is a destructive process. Therefore, you must offload
all the client data first.
Initiate Recovery
Authorize Recovery
Key Update
Recovery Key
State
Configured
Request Recovery Authorization Pending
managereckey
-action recover
Configured
managereckey
-action authorize
Group
State
I

n

a

c

c

e

s

s

i

b

l

e
Accessible
S F I r e b o o t
Configured
Figure 24-38 Re-key Recovery Key window
2. Click Generate Key to establish a new key, which is also displayed on the window, as
Figure 24-39 Re-key recovery key has been generated
The new recovery key will replace the recovery key, but do not shred the old recovery key
now, because the old recovery key is still active until the storage administrator approves
the key update. The process is similar to the process to create a new key (refer to 24.2.1,
Configuring the recovery key on page 814).
3. We need to verify that the new recovery key is written down correctly. Type the key text into
the input field, and click Verify (Figure 24-40).
Figure 24-40 Re-key Recovery Key verification
4. The confirmation message is displayed shortly, as shown in Figure 24-41, if the new
recovery key is correct.
Figure 24-41 Re-key recovery key was verified successfully
5. Click Finish to close the window.
6. In the Encryption Group state panel, notice that the new key needs to be authorized by the
storage administrator. Log in as the storage administrator and select Authorize Recovery
Key Update, which is highlighted in Figure 24-42.
Figure 24-42 Starting the Authorize Recovery Key Update function
7. The Authorize Recovery Key Update window opens (Figure 24-43). Click Authorize
Update, but only if you agree with the authorization.
8. The message in Figure 24-44 shows that the new recovery key has been activated.
Figure 24-44 The recovery key has been authorized successfully
From now on, only the new recovery key is valid, because the old recovery key has been
revoked. The state of the key changes back to the Configured state.
Figure 24-45 on page 830 shows the flowchart of the rekey recovery key process. We also
provide the corresponding DS CLI commands.
Figure 24-45 Re-key recovery key flowchart
24.2.5 Deleting the recovery key
You might need to delete the actual recovery key if you want to convert an encryption-enabled
SFI to encryption-disabled mode. As a prerequisite, the encryption group must be in
Unconfigured state, which means that the client data has already been erased.
Follow these steps:
1. Log in as the security administrator, and select Delete Recovery Key, as highlighted in
Figure 24-46.
Figure 24-46 Starting the Delete Recovery Key process
2. The Delete Recovery Key window opens (Figure 24-47).
Figure 24-47 Delete Recovery Key window
Re-key Recovery Key
Verify Re-key Recovery Key
Authorize Recovery
Key Update
Recovery Key
State
Configured
Re-key Verification Pending
Re-key Authorization Pending
Configured
managereckey
-action verify
managereckey
-action rekey
managereckey
-action authorize
3. Click Delete Recovery Key, and then, a confirmation message is displayed, as shown in
Figure 24-48. You can close the window by clicking Close.
Figure 24-48 Delete recovery key process was initiated successfully
4. Figure 24-49 shows that the Recovery Key State changed to Deconfigure Key
Authorization Pending state.
Figure 24-49 Deconfigure Key Authorization Pending
5. Now, the system is waiting for the storage administrator to authorize the request. Log in as
the storage administrator, and select Authorize Recovery Key Update, as highlighted in
Figure 24-50.
Figure 24-50 Starting the Delete Recovery Key process authorization
6. The Authorize Recovery Key Update window opens (Figure 24-51).
7. If you agree with the authorization, click Authorize Update to complete the request. A
confirmation message is displayed, as shown in Figure 24-52.
Figure 24-52 Delete recovery key process has been authorized successfully
8. The Encryption Group panel is empty, as shown in Figure 24-53. Starting from this state,
you can create non-encrypted arrays and ranks on this storage system.
Figure 24-53 Empty Encryption Group panel
Figure 24-54 shows the flowchart and the corresponding DS CLI commands of the delete
recovery key process.
Figure 24-54 Delete recovery key flowchart
Delete Recovery Key
Authorize Recovery
Key Update
Recovery Key
State
Configured
Deconfigure Key Authorization Pending
n/a
rmreckey
managereckey
-action authorize
24.2.6 Recovery key state summary
We have already introduced the recovery key-related functions in this chapter. In most cases,
the recovery key has multiple temporary states during a dual-role action. Figure 24-55
summarizes all the possible recovery key states and their relationships.
Figure 24-55 Overview of the recovery key states
24.3 Dual platform key server support
For security purposes, encryption keys are stored on external key servers, not on the DS8700
hardware. You must synchronize the external key servers by using the key export and import
or backup functions (see Chapter 22, IBM System Storage DS8000 encryption preparation
on page 753). In certain environments, there might be two disjoint groups of external key
servers that are defined and that cannot synchronize their stored keys securely. In this case,
the DS8700 allows you to specify a second label, so there is one label for each group of
servers. We describe these steps in the following sections. You can obtain general details in
2.3, DS8000 series with encryption support on page 31.
24.3.1 Setting up Tivoli Key Lifecycle Manager server
In this scenario, we must have two groups of independent external key servers:
IKS is based on IBM System x hardware, which stores the keys in the master keystore file
that is written on its hard drive.
zTKLM runs on the IBM System z (mainframe), which might have a dedicated Hardware
Security Module (HSM) for storing the keys in a more secure way. If HSM is used, you can
only export the public key.
Configured
Create / Delete Recovery Key Re-key Recovery Key
Validate Recovery Key Initiate Recovery
n/a
New Key
Verification Pending
New Key
Authorization Pending
Deconfigure Key
Re-key
Verification Pending
Re-key
Request Recovery
You can obtain more details and comparisons in Chapter 3, IBM storage encryption
methods on page 49.
In this chapter, we set up two Tivoli Key Lifecycle Manager servers: itso-tklm1 and itso-tklm2.
These servers represent our IKS (primary) and zTKLM (secondary) key server topology for
this demonstration.
When you have installed both Tivoli Key Lifecycle Manager servers, make sure that your Tivoli
Key Lifecycle Manager servers are updated to the latest version. Currently, the dual platform
key server support requires Tivoli Key Lifecycle Manager V1.0 Fix Pack 2, or later. If you need
to upgrade your servers, use the IBM Fix Central portal to download the latest fix pack, which
also contains a manual describing the upgrade process.
We need to create the master keystores on every Tivoli Key Lifecycle Manager instance. On
IKS, currently only the JCEKS keystore type is supported. zTKLM has more options available
(JCERACFKS and JCECCARACFKS), depending on whether HSM exists. The process is the
same as the process that we described in 22.4, Configuring the Tivoli Key Lifecycle Manager
server connections to the DS8000 on page 767. Use the same keystore name.
We can create the new keys on both platforms. It is easier to use the Tivoli Key Lifecycle
Manager servers in command-line interface (CLI) mode, because the commands are almost
the same; only few characters differ between the servers. It is better to use terminals, where
we can copy the pre-formatted commands.
Creating the certificates
Create your own unique certificates on both servers. Use the tklmCertCreate command in
CLI mode. In Example 24-1, we create itsokey1 on the itso-tklm1 server. In Example 24-2, we
create itsokey2 on the secondary itso-tklm2 server.
Example 24-1 Creating certificate on primary server
wsadmin>print AdminTask.tklmCertCreate ('[-type selfsigned -cn itsokey1 -alias
itsokey1 -usage DS8K -validity 1095 -keyStoreName "ITSO Sample Keystore"]')
CTGKM0503I Created a key pair and self-signed certificate: itsokey1
Example 24-2 Creating certificate on secondary server
wsadmin>print AdminTask.tklmCertCreate ('[-type selfsigned -cn itsokey2 -alias
itsokey2 -usage DS8K -validity 1095 -keyStoreName "ITSO Sample Keystore"]')
CTGKM0503I Created a key pair and self-signed certificate: itsokey2
You can also specify more parameters for customizing for your organization. See the online
CLI reference:
ref_ic_cli.html
List the new certificate by using the tklmCertList command, as shown in Example 24-3 on
page 835. The verbose mode (-v y) provides more details about it.
Important: Do not give the certificates the same name. You can use the same expiration
date in the validity parameters.
Certificates: If you already have certificates from a third-party provider, you need to import
them instead of creating new self-signed keys.
Example 24-3 List certificates
wsadmin>print AdminTask.tklmCertList('[-alias itsokey1 -keyStoreName "ITSO
Sample Keystore" -v y]')
CTGKM0661I Found 1 certificates.
uuid CERTIFICATE-252c1687-6f03-4048-97e0-fc85003aadee
alias(es) itsokey1
certifications null
information null
key store name(s) ITSO Sample Keystore
key store uuid(s) KEYSTORE-83bd0463-92e9-4e3d-8380-345107d60300
owner null
key state active
issuer name CN=itsokey1
subject name CN=itsokey1
target public key uuid null
activation date Sep 23, 2009
archive date Sep 16, 2037
compromise date null
creation date Sep 23, 2009
expiration date Sep 22, 2012
destroy date null
retirement date Sep 17, 2032
serial number 1253745487459693000
Each certificate contains both public and private keys. You can view them using the
tklmKeyList command, as shown in Example 24-4.
Example 24-4 List keys
wsadmin>print AdminTask.tklmKeyList ('[-alias itsokey1 -keyStoreName "ITSO Sample Keystore"
-v y]')
CTGKM0710I Found 2 keys.
uuid KEY-1ffcc23b-6ecd-4111-be66-e5e6d1ecbb12
information null
alias(es) itsokey1
key algorithm AlgorithmName
key length (in bits) 2048
key type RSAPrivateKey
owner null
certifications null
key state active
destroy date null
hash value 0000: 40 8e 4f eb e7 44 78 50 e7 9c 2f bd 4c 65 8d 60
..O..DxP....Le..
uuid KEY-c0abd46e-32c1-4524-b8a1-3ac70ddce66b
information null
alias(es) itsokey1
key type RSAPublicKey
owner null
certifications null
key state active
destroy date null
hash value 0000: b0 f5 7d ab eb 85 f1 85 32 e3 82 bc 75 b1 05 b3
........2...u...
The key type line shows whether it is a public key or a private key.
Exchanging the public keys
The concept of the dual platform key support feature is that the isolated key server (IKS) and
the zTKLM have their own asymmetric key pair and also have each others public key stored
from the partner server. If one of the Tivoli Key Lifecycle Manager servers breaks down, the
other server has all the required keys for unwrapping the DS8700 data key, so the
redundancy is provided on Tivoli Key Lifecycle Manager side, as well.
We need to exchange the public keys between the Tivoli Key Lifecycle Manager servers. We
follow this process:
1. Export the public keys on the primary server and the secondary server.
2. Copy the key files to the other server.
3. Import the public keys on the primary server and the secondary server.
Exporting the public key
Execute the tklmCertExport command to export the public key to a regular file in an existing
directory on the local file system. Use a file name that contains the name of the key, to avoid
mixing them up later. You must specify the Universal Unique Identifier (uuid) to select the
proper certificates to export. You can obtain this uuid value from the tklmCertList command
output.
Example 24-5 on page 837 and Example 24-6 on page 837 show how to export a key.
CLI: You can only use CLI mode for this process. Currently, the GUI does not support
these functions.
Example 24-5 Exporting primary public key to a file
CERTIFICATE-252c1687-6f03-4048-97e0-fc85003aadee -fileName /root/itsokey1.cert]')
/root/itsokey1.cert
Example 24-6 Exporting secondary public key to a file
CERTIFICATE-0eba963e-873d-4cf2-9666-bd8cce196974 -fileName /root/itsokey2.cert]')
/root/itsokey2.cert
Transferring the key files to the other server
The exported keys are regular files on the file system. How you transfer them depends on the
operating systems. IKS currently uses SUSE Linux Enterprise Server (SLES) V10. Many
options are available. If possible, copy the files over the network using a secure transfer
method, such as scp or sftp.
In this example, we transfer the itsokey1.cert file from the primary server to the secondary
server, and we transfer the itsokey2.cert file from the secondary server to the primary
server.
Importing the public key
Use the tklmCertImport command to import the public key file into your keystore. The import
command allows you to specify the name of the new certificate, but you have to use the same
certificate name that was used on the partner server to keep the Tivoli Key Lifecycle Manager
infrastructure consistent.
Example 24-7 and Example 24-8 show the importing process on both servers.
Example 24-7 Importing the secondary public key on the primary server
Example 24-8 importing the primary public key on the secondary server
Verifying the key exchange
Check the content of the keystores before moving forward.
Both Tivoli Key Lifecycle Manager servers must have a complete key pair (public and private)
and a single public key from the partner server. Altogether, two certificates with three keys
inside are stored on each server. Example 24-9 on page 838 and Example 24-10 on
page 838 demonstrate the content of the primary server.
Important: If you use any kind of media (floppy disk, CD, USB, or pendrive) during the file
transfer, make sure that you permanently erase it. Do not leave any temporary files outside
of the Tivoli Key Lifecycle Manager servers.
Example 24-9 List of certificates on the primary server after the key exchange
wsadmin>print AdminTask.tklmCertList('[-v y]')
uuid CERTIFICATE-252c1687-6f03-4048-97e0-fc85003aadee
alias(es) itsokey1
certifications null
information null
owner null
key state active
destroy date null
serial number 1253745487459693000
uuid CERTIFICATE-7e18fcd9-402d-4d26-856e-912e7917ee7c
alias(es) itsokey2
certifications null
information null
owner null
key state active
issuer name CN=itsokey2,OU=,O=,L=,ST=,C=
subject name CN=itsokey2,OU=,O=,L=,ST=,C=
destroy date null
serial number 1253760544252699000
Example 24-10 List of keys on the primary server after the key exchange
wsadmin>print AdminTask.tklmKeyList ('[-v y]')
uuid KEY-1ffcc23b-6ecd-4111-be66-e5e6d1ecbb12
information null
alias(es) itsokey1
owner null
certifications null
key state active
destroy date null
hash value 0000: 40 8e 4f eb e7 44 78 50 e7 9c 2f bd 4c 65 8d 60
..O..DxP....Le..
uuid KEY-c0abd46e-32c1-4524-b8a1-3ac70ddce66b
information null
alias(es) itsokey1
owner null
certifications null
key state active
destroy date null
........2...u...
uuid KEY-da187ac1-95b1-4c94-8836-a3fa45015794
information null
alias(es) itsokey2
key algorithm RSA
owner null
certifications null
key state pre-active
destroy date null
hash value 0000: e3 29 8a 0d 5c f9 64 e8 9b 17 80 09 bc 5a 18 7e
......d......Z..
On the primary server, both itsokey1 and only the public key of itsokey2 exist, which complies
with the requirements. Example 24-11 and Example 24-12 on page 841 show the state of the
secondary server.
Example 24-11 List of certificates on the secondary server after key exchange
wsadmin>print AdminTask.tklmCertList('[-v y]')
uuid CERTIFICATE-0eba963e-873d-4cf2-9666-bd8cce196974
alias(es) itsokey2
certifications null
information null
key store uuid(s) KEYSTORE-0c8fd4ca-c21f-4cc9-8487-c1d734e275af
owner null
key state active
issuer name CN=itsokey2, OU=, O=, L=, ST=, C=
subject name CN=itsokey2, OU=, O=, L=, ST=, C=
destroy date null
serial number 1253760544252699000
uuid CERTIFICATE-5fd17bda-6131-4386-beca-856f616485b2
alias(es) itsokey1
certifications null
information null
owner null
key state active
destroy date null
serial number 1253745487459693000
Example 24-12 List of keys on the secondary server after key exchange
wsadmin>print AdminTask.tklmKeyList ('[-attributes "{state active}" -v y]')
uuid KEY-4ed8b668-5d61-4311-85be-c639a02a75cd
information null
alias(es) itsokey2
owner null
certifications null
key state active
destroy date null
hash value 0000: dc 10 49 33 b2 48 9d e5 81 28 9f a6 f5 59 50 c0
..I3.H.......YP.
uuid KEY-c7c3a79b-d1b7-44c2-99e3-dd04ef0d2b42
information null
alias(es) itsokey2
owner null
certifications null
key state active
destroy date null
hash value 0000: e3 29 8a 0d 5c f9 64 e8 9b 17 80 09 bc 5a 18 7e
......d......Z..
uuid KEY-79fd184f-888e-43ad-8b15-990a3edaa8da
information null
alias(es) itsokey1
key algorithm RSA
owner null
certifications null
key state active
destroy date null
........2...u...
The number of the certificates and keys are correct. If we compare the output of the
tklmCertList and tklmKeyList commands, note that the adequate certificate serial numbers
and key hash values match with each pair, which proves that the keys are exactly the same
replicas.
Adding Storage Images
After the key exchange process, the Tivoli Key Lifecycle Manager servers are ready to identify
new DS8700 Storage Facility Images (SFIs) with dual keys. In this step, we can use the GUI
again; however, the tklmDeviceAdd command is available for CLI.
Figure 24-56 shows the sample GUI windows on both servers.
Figure 24-56 Adding Storage Images on the primary (left) and secondary (right) servers
In Figure 24-56, notice that on the primary server (left), the primary key (itsokey1) is selected
for Image Certificate and the secondary public key (itsokey2) is assigned as the Partner
certificate. On the secondary server side (right), the key relationship is reversed, because
itsokey2 is the primary Image Certificate and itsokey1 is the transferred public key or Partner
certificate on that server.
Click Add Storage Image on both servers.
On the primary server, verify the result, as shown in Figure 24-57 on page 843.
Figure 24-57 Configured Storage Image on primary server
Figure 24-58 shows the secondary server state.
Figure 24-58 Configured Storage Image on secondary server
Now, the Tivoli Key Lifecycle Manager infrastructure is ready for serving the keys for
authorized storage images.
Chapter 25. Best practices and guidelines for
DS8000 encryption
This chapter provides information about mandatory rules and best practices for setting up
encrypting storage environments.
We describe these topics in this chapter:
Best practices for encrypting storage environments on page 846
Dual Hardware Management Console and redundancy on page 850
Multiple Tivoli Key Lifecycle Managers for redundancy on page 852
Backup and restore the Tivoli Key Lifecycle Manager servers on page 853
Key exporting and importing tasks on page 858
25
Important: For up-to-date considerations and best practices regarding DS8000
encryption, refer to IBM Encrypted Storage Overview and Customer Requirements at this
website:
The previous link also includes the IBM Notice for Storage Encryption that all clients must
read when acquiring an IBM storage device that includes encryption technology.
25.1 Best practices for encrypting storage environments
The following information can help you to identify the best practices for encrypting storage
environments. It includes key techniques for mitigating the risk of an encryption deadlock.
25.1.1 Security
There are several considerations and best practices for security:
General:
Clients must manage the physical security of access to hardware in general. You might
also want to provide additional network security around hardware that is associated
with Tivoli Key Lifecycle Manager key servers.
Keystore:
During the setup of the Tivoli Key Lifecycle Manager key server, you specify a
password to use to access the keystore. Decide whether the Tivoli Key Lifecycle
Manager password is provided manually or whether a mechanism is in place to
automatically provide the password to the Tivoli Key Lifecycle Manager. If a startup
script containing the password is used at the Tivoli Key Lifecycle Manager key server,
the script file must have access controls to prevent unauthorized access to the file and
password.
Maximum security is achieved when the Key Material is stored securely using the
services of a Hardware Security Module (HSM) and the master key for that module is
formally managed, and only distributed in split key form, by way of key ceremonies. At
this time, IBM provides the capability for clients to realize this level of security on
System z servers using Integrated Cryptographic Service Facility (ICSF) and the
CryptoExpress 2 HSM at this time.
DS8000:
You must change the passwords on factory default user accounts, or you can delete
the factory default user accounts after other user accounts with that same authority are
created.
On DS8700, you must maintain the division of roles between security administrators
and storage administrators to avoid defeating the dual control provided by these two
roles.
On DS8700, you must securely maintain the recovery keys for future use and make
them accessible to only security administrators.
25.1.2 Availability
The following list consists of availability considerations and best practices:
DS8000:
Configure the DS8000 with the dual HMC option to provide redundant access to the
client network. Refer to 25.2, Dual Hardware Management Console and redundancy
on page 850. The inability of a DS8000 to communicate with a Tivoli Key Lifecycle
Manager key server when it powers on will prevent access to encrypted storage on the
DS8000.
Chapter 25. Best practices and guidelines for DS8000 encryption 847
Tivoli Key Lifecycle Manager key server
Configure redundant key servers to each encrypting storage device. Have independent
and redundant key servers on each site.
To initiate the Tivoli Key Lifecycle Manager key server operation after power on, without
human intervention, set up the key server to automatically power on when power is
available and to automatically initiate the key server application. Configure the
application to automatically start.
Configure redundant network fabrics between the Tivoli Key Lifecycle Manager key
servers and encrypting DS8000 (see Figure 25-1 on page 851). Providing independent
network paths through independent key servers prevents any single point of failure.
25.1.3 Encryption deadlock prevention
The following list consists of considerations and best practices to help prevent encryption
deadlock:
General
The change management processes at the client installation must cover any
procedures that are required to ensure adherence to guidelines that are required to
ensure the proper configuration of key servers, encrypted storage, and the data
placement of data that is related to key servers.
All personnel who have any of the following assignments or capabilities must be
required to review a client document that describes these risks and the processes
adopted to mitigate them, at least annually:
Responsibility for the implementation of Tivoli Key Lifecycle Manager key servers or
encrypted storage products
Responsibility to manage the placement or relocation of data related to, or required
by, any Tivoli Key Lifecycle Manager key server
Access authority to configure Tivoli Key Lifecycle Manager key servers or encrypted
storage products
The client must thoroughly review and update systems management processes,
especially configuration and change management processes, to ensure adherence to
guidelines required to ensure proper configuration and isolation of key servers,
configuration and utilization of encrypted storage, and placement of code and data
objects related to key servers.
The client must implement automated monitoring of the availability of any equipment
associated with management of key services and take appropriate action to keep the
equipment operational. This equipment includes but is not limited to key servers,
Simple Network Management Protocol (SNMP) masters, domain name servers, and
DS8000 Hardware Management Consoles (HMCs).
The client must pay particular attention to disaster recovery plans and scenarios, and
consider the availability of key servers, key server backups, and key server
synchronization. A good practice is to establish the independence of each recovery site
from the other recovery site.
Note the following information on the Tivoli Key Lifecycle Manager Key Server:
Configuration of redundant key servers (at least two) is required. Redundancy implies
that the key servers have no common single points of failure and typically means that
they are implemented on independent servers and independent storage devices. For
key servers operating in logical partitions (LPARs), do not use data sharing techniques
that result in one copy of the data being shared by multiple instances of the key server.
Configuration of one key server with dedicated hardware and non-encrypted storage
resources at each recovery site is required. The key server is referred to as the isolated
key server.
The objective of this requirement is to avoid encryption deadlock by these methods:
Implementing a key server environment that is independent of all non-key server
applications so that management of the key server can be restricted to those
personnel specifically authorized to manage key servers
Implementing a key server that is physically and logically isolated from other
applications that might require access to encrypting storage so that the key server
environment does not need to be configured with access to any encrypting storage
Implementing a key server that is physically and logically isolated from encrypting
storage so that the risk storing (initially or through data migration) code and data
objects required by the key server on encrypting storage is eliminated
Ensuring that a recovery site can operate independently of any other sites by
configuring a key server that is not subject to encryption deadlock because of the
characteristics of an isolated key server
Configuration of additional key servers on generalized server hardware and
generalized storage is allowed. The client must establish appropriate procedures and
controls to prevent these key servers from having their data access compromised by
storing the data on key server-managed encrypting storage. These key servers are
referred to as general key servers.
Configuration of key servers at independent sites is good practice and provides
additional immunity to encryption deadlocks, because it reduces the probability that all
key servers will experience a simultaneous power loss. The best practice is to utilize
uninterruptible power supplies (UPSs) on certain key servers for continuous key
serving.
The initiation of a Tivoli Key Lifecycle Manager key server involves the specification of
a password that is used to access the keystore. The client must ensure the appropriate
retention of the password, as well as limit access to the password to appropriate
personnel. Loss of a password is a cryptographic erasure of the keystore for the
associated key servers. Loss of one or more redundant key servers increases the
probability of an encryption deadlock. The permanent loss of all encryption key servers
is equivalent to a permanent encryption deadlock.
Clients must ensure that all key servers, which a given storage device is configured to
communicate with, have a consistent keystore content relative to any wrapping keys
that will be used by the storage device. Failure to synchronize the keystores effectively
eliminates one or more key servers from the set of redundant key servers for a storage
device that uses the keys that are not synchronized. Refer to 25.3.2, Synchronizing
primary and secondary Tivoli Key Lifecycle Manager servers on page 853.
Clients must back up key server data after it is updated. The backups must not be
stored on encrypted storage media that is dependent on a key server. Refer to 25.4,
Backup and restore the Tivoli Key Lifecycle Manager servers on page 853.
Note: IBM DS8000 requires at least one isolated key server to be configured, but a
best practice is two for redundancy.
Clients must periodically audit to ensure that all online and backup data required to
make each key server operational is stored on storage or media that is not dependent
on a key server to access the data.
Clients must not delete keys on the key server under normal circumstances. The
appropriate action to remove a key from a key server is almost always to archive the
key. If the wrong key is inadvertently archived causing the loss of access to encrypted
data at a point in the future, the archive action allows the key to be restored from the
archive. Deletion of all copies of a key is a cryptographic erase of all encrypted data
that is encrypted under this key.
Note the following information on the DS8000:
On DS8700, recovery keys must be configured and securely maintained. The recovery
keys must be rekeyed periodically. The availability of a recovery key does not eliminate
the requirement for configuring isolated key servers or for properly configuring general
key servers. If a recovery key is actually needed to break an encryption deadlock, an
outage is already in progress.
On DS8700, multiple security administrators and multiple storage administrators must
be defined on storage facility images so that the loss of access to one administrator
does not prevent the ability to use a recovery key for recovery purposes.
A suggestion is that the clients manually configure DS8000 devices on the Tivoli Key
Lifecycle Manager key server. The option to automatically configure them can be used,
but it increases the risk that an unauthorized DS8000 might gain access to a key
server.
Each DS8000 storage facility image can be assigned an independent key encrypting
key (KEK) with a unique key label on the Tivoli Key Lifecycle Manager. This approach
might facilitate independent management of each storage facility image.
The DS8000 supports up to four key server ports. IBM requires that at least one of the
key server ports be assigned to an isolated key server. IBM suggests that two of the
key server ports be assigned to isolated key servers. The remaining ports can be
connected to general key servers. Key servers at the local site must generally be
preferred over key servers at a remote site to improve availability.
When the DS8000 is configured to enable encryption, the DS8000 verifies that at least
two Tivoli Key Lifecycle Manager key servers are configured and accessible to the
machine. The configuration request is rejected if this condition is not met.
The DS8000 will reject the creation of ranks and extent pools with the non-zero
encryption group specified, if the encryption has not been activated.
The DS8000 will monitor all configured Tivoli Key Lifecycle Manager key servers. Client
notification is provided through the DS8000 client notification mechanism (SNMP traps,
email, or both, when configured) when loss of access to the key servers is detected.
Key server-related errors are provided through the same mechanism. The client must
set up monitoring for these indications and take corrective actions when a condition is
detected. This condition reflects a degraded key server environment.
The following conditions are monitored and reported:
If, at power on, the DS8000 cannot obtain the required data key for a configured
encryption group from the key servers, it reports the error condition to the client and
to IBM. In this case, encrypted logical volumes associated with the encryption
group are inaccessible to attached hosts. If subsequent to reporting this error, the
DS8000 is able to obtain the required data key from a key server, it reports the
condition to the client and to IBM and makes the associated logical volume
accessible.
DS8000 access to each configured key server is verified at five-minute intervals.
Loss of access is reported to the client.
The ability of each key server to unwrap data keys configured on the DS8000 is
verified at eight-hour intervals. Loss of the ability to unwrap a configured data key is
reported to the client and to IBM.
The DS8000 detects whether fewer than two key servers are configured, or if fewer
than two key servers are available, or if there are fewer than two key servers that
can unwrap data keys configured on the DS8000 at eight-hour intervals. If detected,
this condition is reported to the client and to IBM.
25.2 Dual Hardware Management Console and redundancy
A dual Hardware Management Console (HMC) is a redundant management system that
provides flexibility and high availability. When two HMCs manage one system, they are peers,
and each HMC can be used to control the managed system. One HMC can manage multiple
managed systems, and each managed system can have two HMCs.
25.2.1 Dual Hardware Management Console advantages
Having an external DS HMC provides a number of advantages:
Enhanced maintenance capability
Because the DS HMC is the only interface available for service personnel, a second DS
HMC greatly enhances maintenance operational capabilities if the primary DS HMC fails.
Improved remote support
In many environments, the DS8000 and internal HMC are secured behind a firewall in a
users internal local area network (LAN). In this case, it can be difficult for IBM to provide
remote support. An external DS HMC can be configured in such a way that it is able to
communicate with both the DS8000 and IBM. Thus, the dual HMC configuration can
greatly enhance remote support capabilities.
High availability for configuration operations
In open systems environments, all configuration commands must go through the HMC,
which is true regardless of whether you use the DS CLI, the DS Storage Manager, or the
DS Open application programming interface (API). An external DS HMC will allow these
operations to continue to work despite a failure of the internal DS HMC.
High availability for Advanced Copy Services operations
In open systems environments, all Advanced Copy Services commands must also go
through the HMC. This approach is true regardless of whether you use the DS CLI, the DS
Storage Manager, or the DS Open API. An external DS HMC will allow these operations to
continue to work despite a failure of the internal DS HMC.
High availability for Tivoli Key Lifecycle Manager Server
See 25.2.2, Redundant HMC configurations on page 850.
25.2.2 Redundant HMC configurations
You can have a configuration in which dual HMC servers are connected to the DS8000
Storage Server and to the Tivoli Key Lifecycle Manager servers.
Using a redundant HMC configuration with your Tivoli Key Lifecycle Manager Server and
DS8000 Storage Server setup requires a specific port configuration, as shown in Figure 25-1.
In this configuration, each Tivoli Key Lifecycle Manager server is connected to two network
switches, and each of the switches is connected to one HMC. Each HMC is connected to the
DS8000 Storage Server. The network switches connected to the HMC must remain in the
power-on state. Any Ethernet switch or hub can be used to connect the Tivoli Key Lifecycle
Manager server and HMC.
Figure 25-1 Redundant HMC configuration: Normal operation
In a normal operation, the DS8000 Storage Server connects to the primary Tivoli Key
Lifecycle Manager server across the Primary HMC, as shown in Figure 25-2.
Figure 25-2 Communication path between DS8000 and Tivoli Key Lifecycle Manager server
In case of network failure or maintenance issues on the primary HMC, the DS8000 Storage
Server can connect to the Primary Tivoli Key Lifecycle Manager Server over the secondary
HMC, as shown in Figure 25-3 on page 852.
Figure 25-3 Failover communication between DS8000 and Tivoli Key Lifecycle Manager server
In a redundant HMC configuration, both HMCs and Tivoli Key Lifecycle Manager servers are
fully active, highly available, and accessible at all times, enabling you to perform
management tasks from either HMC at any time.
25.3 Multiple Tivoli Key Lifecycle Managers for redundancy
To ensure continuous key and certificate availability to encrypting devices, configure a
primary and a replica Tivoli Key Lifecycle Manager server for your enterprise, and then
provide repeated backup/restore or import/export actions to protect critical data.
On Windows systems and other systems, such as Linux or AIX, both computers must have
the required memory, speed, and available disk space to meet the workload. The operating
system, middleware components, and Tivoli Key Lifecycle Manager application directory
layout must be identical on both computers.
Note that this server is not a failover or clustered server from a Tivoli Key Lifecycle Manager
point of view. The redundancy is managed by setting up multiple key manager destinations at
the DS8000 Storage Server.
Synchronization is achieved by backing up one server and restoring the backup configuration
on the other server, assuming both servers have the same operating system. If you have
servers with separate operating systems (AIX, Linux, or Windows) or platforms (System x,
System p, or System z), you have to use the export/import function.
If your System z (mainframe) contains the Hardware Security Module (HSM), you need to set
up a dual platform key server environment. See 24.3, Dual platform key server support on
page 833 for more details.
Plan to perform this backup/restore or export/import process when the following events take
place:
Initial configuration
Adding keys or devices
Key or certificate replacement intervals
Certificate Authority (CA) requests
In our experimentation environment, we were running two SUSE Linux 10 hosts, which
allowed us to easily match the environment seen by Tivoli Key Lifecycle Manager and its
middleware.
A good practice is to fill out the installation worksheets found in the Tivoli Key Lifecycle
Manager Installation and Configuration Guide, SC23-9977.
For detailed information, refer to these resources:
Installing Tivoli Key Lifecycle Manager on 64-bit Windows Server 2008 on page 266
The Tivoli Integrated Portal Information Center:
http://publib.boulder.ibm.com/infocenter/tivihelp/v15r1/topic/com.ibm.tip.doc/w
elcome_tip_ic.htm
servers
Tivoli Key Lifecycle Manager 1.0 does not automatically synchronize between servers, but it
provides a convenient backup and restore operation that can be performed using the
command line or web user interface. Synchronization involves backing up a Tivoli Key
Lifecycle Manager and then restoring to a separate server with the same configuration
parameters. There are several considerations:
Select one machine to be the primary and originate all backups from the primary. All
changes must be made on the primary and then deployed through a backup/restore to the
secondary Tivoli Key Lifecycle Manager.
Primary and secondary Tivoli Key Lifecycle Managers must be running the same OS on
the same platform with the same user accounts for Tivoli Key Lifecycle Manager, Tivoli
Integrated Portal, and DB2.
Restores are disruptive to the secondary Tivoli Key Lifecycle Manager so ensure that the
primary is active and serving keys before performing the restore.
For detailed backup and restore information, refer to 25.4, Backup and restore the Tivoli Key
Lifecycle Manager servers on page 853.
25.4 Backup and restore the Tivoli Key Lifecycle Manager
servers
Backup and restore tasks provide protection for critical data, and they require consideration of
your site practices to ensure server availability and runtime capabilities. Tivoli Key Lifecycle
Manager creates backup files that contain critical data for the current state of the Tivoli Key
Lifecycle Manager server.
Important: Failure to back up your keystore and other critical data properly might result in
the unrecoverable loss of all access to your encrypted data. Do not encrypt your backup
file, or store a backup file on an encrypting device. Failure to back up data might also result
in subsequent inconsistency of the key manager and potential data loss on the storage
device.
25.4.1 Categories of data in a backup file
A backup file of Tivoli Key Lifecycle Manager critical data includes the keystore, configuration
file, metadata, and other information.
The following categories of data require backup protection:
Keystore files
Certificates and keys (or pointers to the certificates and keys) that Tivoli Key Lifecycle
Manager uses to perform key serving and other operations
Tivoli Key Lifecycle Manager configuration files
Properties that define selected Tivoli Key Lifecycle Manager activities, such as audit
settings and other values that you customize for your system configuration
Tivoli Key Lifecycle Manager database
Data about Tivoli Key Lifecycle Manager objects, such as devices, key groups, certificates,
keys, and drives
25.4.2 Backup file security
Observe the following guidelines to secure your backup files:
Ensure that you do not accidentally corrupt a backup file or misplace its encryption
password.
Do not edit the files contained in a backup .jar file. The files will become unreadable.
Ensure that you retain the password that is used to encrypt a given backup file. The same
password is required to restore and decrypt the file.
25.4.3 IBM Tivoli Storage Manager as a backup repository
Tivoli Storage Manager might be your backup repository of choice. Tivoli Storage Manager
provides progressive, incremental backup, hierarchical storage management, and tape
optimization.
For example, you might use the policy-based backup capabilities that Tivoli Storage Manager
provides to perform scheduled backups on an hourly, daily, or weekly basis.
For critically important data, such as the Tivoli Key Lifecycle Manager database, keystore,
and configuration file, you might use Tivoli Storage Manager to back up that data when it
changes. Install the Tivoli Storage Manager server on a separate computer than the computer
on which the DB2 server runs.
25.4.4 Backup and restore runtime requirements
Backing up data and restoring data from backup files for Tivoli Key Lifecycle Manager have
several runtime requirements.
Before you begin, you might prevent time out failure by increasing the time interval that is
allowed for backup and restore transactions for large key populations. Specify a larger value
for the totalTranLifetimeTimeout setting in the following file:
TIP_HOME/profiles/TIPProfile/config/cells/TIPCell/nodes/TIPNode/servers/server1/se
rver.xml
Additionally, these conditions must be true:
Ensure that the task occurs during a time interval that allows a halt to key serving activity.
For a backup task, the Tivoli Key Lifecycle Manager server must be running in a normal
operational state. The Tivoli Key Lifecycle Manager database instance must be available.
For a restore task, the Tivoli Key Lifecycle Manager database instance must be accessible
through the Tivoli Key Lifecycle Manager data source.
Before you start a restore task, ensure that you have the password that was used when
the backup file was created. Restored files must be written to the same Tivoli Key Lifecycle
Manager server from which the data was previously backed up, or to an identical, replica
computer.
Ensure that directories exist and are associated with the tklm.backup.dir and
tklm.db2.backup.dir properties. System and Tivoli Key Lifecycle Manager administrator
accounts under which the Tivoli Key Lifecycle Manager server and the DB2 server run
must have read and write access to these directories respectively.
25.4.5 Backing up critical files
performing a restore, Tivoli Key Lifecycle Manager assumes that the environment is similar.
Tivoli Key Lifecycle Manager restore operations must be on the same platform with the same
system user account information and Tivoli Key Lifecycle Manager and middleware file layout.
Follow these steps to back up critical files:
1. Log in to the graphical user interface. From the navigation tree, select Tivoli Key
Lifecycle Manager Settings Backup and Restore.
2. In the backup and restore table, click Create Backup, as shown in Figure 25-4.
Figure 25-4 Backup and restore table
Important: Backup and restore are disruptive to the Tivoli Key Lifecycle Manager server
as of Tivoli Key Lifecycle Manager 1.0.
3. On the Create Backup panel, as shown in Figure 25-5, specify the required information,
such as the path and a value for the encryption password. Then, click Create Backup.
Figure 25-5 Create Backup
4. Review the directory that contains the backup files to ensure that the backup file exists. Do
not edit a file in the backup .jar file. The file that you attempt to edit will become
unreadable. The file location is shown in the Backup File column, as shown in Figure 25-6.
Figure 25-6 Backup file created
25.4.6 Restoring a backup file
You can use the Backup and Restore table to restore a backup file. Only one backup or
restore task can run at a given time. If you restore a file to a replica computer, copy the file to
that computer using media, such as a USB or pen drive, or transfer it over the network.
1. Log in to the graphical user interface. From the navigation tree, select Tivoli Key
Lifecycle Manager Settings Backup and Restore.
2. On the Backup and Restore table, select a backup file that is listed in the table. Then, click
Restore from Backup. The panel that is shown in Figure 25-7 opens.
Figure 25-7 Restore from backup
3. Before the restore procedure starts, click OK to confirm the message indicating that the
server will be stopped, as shown in Figure 25-8.
Figure 25-8 Restore warning message
4. A message indicates that the restore operation succeeded. Click OK to finish the restore
procedure. See Figure 25-9.
Figure 25-9 Restore successful message
5. Manually restart the Tivoli Key Lifecycle Manager server. Then, determine whether the
server is in the expected state. For example, you might examine the keystore to see
whether a certificate that had problems prior to restoring the backup file is now available
for use.
25.4.7 Deleting a backup file
Use the graphical user interface (GUI) or command line interface (CLI) to delete a backup file
for Tivoli Key Lifecycle Manager. For example, you might delete a backup file for which a
business use no longer exists.
You can use the Backup and Restore table to restore a backup file:
2. On the Backup and Restore table, select a backup file that is listed in the table. Click
Delete Backup, and confirm that you want to delete the file.
3. Examine the directory in which the backup files are stored, to determine whether the
specified file was deleted.
25.5 Key exporting and importing tasks
If the secondary Tivoli Key Lifecycle Manager server differs from the primary Tivoli Key
Lifecycle Manager server (in terms of OS, maintenance level, and so on), you have to export
the certificate from one server and restore it on the other server. You have to use the CLI for
the export and import tasks that are not available from the GUI.
If you have Hardware Security Module (HSM) in your System z environment, you have to
follow the installation process that is described in 24.3, Dual platform key server support on
page 833.
25.5.1 Exporting keys
Follow these steps to export keys:
1. Open a command window, go to the <tip installation directory>/bin folder, and
execute the wsadmin script to export keys from the primary Tivoli Key Lifecycle Manager
server (server1), as illustrated in Example 25-1.
2. Use the tklmKeyExport command with the -alias, -fileName, -keyStoreName, and -type
parameters to export secret or private keys. The -alias parameter is the given name from
the Tivoli Key Lifecycle Manager server DS8000, the -keyStoreName is the master
keystore name for the Tivoli Key Lifecycle Manager server. See Example 25-2.
Example 25-2 Exporting the key
wsadmin>print AdminTask.tklmKeyExport('[-alias itsokey -fileName TKLM_DS8K
-keyStoreName "ITSO Sample Keystore" -type privatekey]')
The file TKLM_DS8K was created in /opt/IBM/tivoli/tip/products/tklm with the file name
TKLM_DS8K.
3. Copy and archive the exported key to the new Tivoli Key Lifecycle Manager server.
25.5.2 Importing keys
You must perform these steps on the second Tivoli Key Lifecycle Manager server:
1. Open a command window, go to <tip installation directory>/bin folder, and use the
wsadmin command to import keys from Tivoli Key Lifecycle Manager server1. See
Example 25-3.
More information: The default path to create the keystore on Linux systems is:
/opt/IBM/tivoli/tip/products/tklm
On Windows systems, it is:
C:\ibm\tivoli\tip\products\tklm
For more information about the export function, refer to:
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.
ibm.tklm.doc/cpt/cpt_ic_releas_probslimits.html
2. Use the tklmKeyImport command with the -alias, -fileName, -password, -keyStoreName,
-usage, and -type parameters to export secret or private keys. The -alias parameter is the
given name from the Tivoli Key Lifecycle Manager server DS8000, the password is the key
password from the DS8000, the -keyStoreName is the master keystore name for the
Tivoli Key Lifecycle Manager server, and the usage defines the storage type. See
Example 25-4.
Example 25-4 Import the key
wsadmin>print AdminTask.tklmKeyImport('[-alias itsokey -fileName
/root/fromTKLM_server1/TKLM_DS8K -password passw0rd -keyStoreName "ITSO Sample
Keystore" -usage DS8K -type privatekey]')
3. Verify that both the public and private keys are available using the tklmKeyList command,
as shown in Example 25-5.
Example 25-5 Verify the imported key
wsadmin>print AdminTask.tklmKeyList ('[-attributes "{state active}" -v y]')
uuid KEY-20a2ddc6-c314-4e95-8cf5-cba59f74b15b
information null
alias(es) itsokey
owner null
certifications null
key state active
destroy date null
hash value 0000: 35 85 96 69 c2 d6 af 2e 37 57 1e 91 2e f9 5b f2
5..i....7W......
uuid KEY-0922fa60-0af5-4c7a-a199-38dd712e7e25
information null
alias(es) itsokey
owner null
certifications null
key state active
destroy date null
hash value 0000: 42 03 0b e2 73 16 13 fc 49 62 30 1c 86 73 25 a2
B...s...Ib0..s..
Appendix A. z/OS planning and
implementation checklists
This appendix provides various checklists to use as references in planning and implementing
your z/OS encryption environment. These checklists are not necessarily in the order in which
you might use them.
A
DFSMS Systems Managed Tape planning
These are the planning steps that you have to complete prior to implementing a z/OS
encryption solution using DFSMS Systems Managed Tape.
DFSMS planning and the z/OS encryption planning checklist
Both native TS1120 drives (attached to a tape control unit) and TS1120 drives that are
attached to a TS7700 are available for encryption in IBM Tape Library environments. In a
stand-alone or C20 Silo implementation, only native TS1120 drives are supported in the z/OS
environment. Many of the planning steps are common to both the native TS1120 and TS7700
environments, but certain steps are unique to one environment or the other environment. We
describe both environments in the following checklist:
z/OS encryption planning checklist
Perform the following steps:
1. For both environments, plan for the installation of the Encryption Key Manager (EKM) and
decide which of the supported keystores to use.
2. For both environments, plan for the key labels that will be used, the key encoding
mechanism (label or hash) for each key label, and where the key labels will be specified.
3. Perform these steps for encryption on native TS1120 drives:
a. Determine which z/OS systems must have TS1120 encryption coexistence support
and which systems must have TS1120 encryption full support. Check the IBM
preventive service planning (PSP) bucket 3592DEVICE for this maintenance.
b. Determine when to start the IPL on the host systems after installing the coexistence
program temporary fixes (PTFs) or the full support PTFs, if required.
c. In a stand-alone or C20 Silo implementation, order feature code (FC) 5596 or FC9596
for each of the TS1120 drives to be used by z/OS.
d. Order FC5595 or FC9595 on the 3592 Model J70 and the TS1120 Model C06 tape
controllers that you want to support encryption.
e. Determine which data has to be encrypted and set up the appropriate Data Class
policies specifying EE2 (Enterprise Encrypted Format 2 or EEFMT2). Also, specify as
appropriate, the non-encryption recording formats, E1 (Enterprise Format 1 or EFMT1)
or E2 (EFMT2). If an encryption-capable IBM TS1120 Tape Drive is allocated, the
default recording format is E2 (EFMT2), which is non-encrypted E05 mode. Also,
determine what modifications are required for automatic class selection (ACS) routines
to associate the tape output functions that you plan to use with a Data Class that has
the appropriate recording format specified.
f. Determine which key labels and key encodings are to be used and how they will be
specified: in the Data Class, in the data definition (DD) statement, or using Encryption
Key Manager (EKM)-established defaults.
g. Determine the EKM TCP/IP addresses to be used to update the I/O Supervisor (IOS)
PARMLIB member (IECIOSxx) using the new EKM command. Also, plan to create an
OMVS (open MVS) segment for the IOS address space.
h. If you plan to share the same 3592 media between encryption-enabled TS1120 drives
and either 3592 Model J1A or non-encryption-enabled TS1120 Model E05 drives,
order or download microcode upgrades for the 3592 Model J1A and the
non-encryption-enabled TS1120 Model E05 drives. The microcode enables these
drives to recognize and convert the EEFMT2-formatted cartridges to be relabelled and
Appendix A. z/OS planning and implementation checklists 865
reused as EFMT1 or EFMT2 cartridges. Also, ensure that VOLNSNS=YES is in the
DEVSUPxx member of PARMLIB.
i. If the TS1120 drives are installed in a library, identify whether any installation exit
changes are required.
4. Perform these steps for encryption on TS1120 drives that are attached to the TS7700:
a. Determine which data has to be encrypted, and set up appropriate DFSMS storage
group and management class policies. Also, modify or create ACS routines to select
these storage group and management class constructs for data that you want to be
encrypted within a storage pool in the TS7700.
b. Determine which TS7700 storage pools will be encrypted and which key labels and key
encodings to use.
c. Plan for storage groups and management classes within the TS7700 that specify these
storage pools. These storage groups and management classes must match the
DFSMS storage group and management class constructs.
d. Make sure that you have ordered FC9900, Encryption Configuration, for the TS7700
(3957-V06).
e. No additional software maintenance is required to support encryption within the
TS7700.
5. For both environments, determine whether you will have help from your tape management
system vendor and contact the vendor, if required.
6. For both environments, with availability of the new media (MEDIA9 and MEDIA10),
determine if any microcode updates on the drives are required.
7. For both environments, identify whether any installation exit changes are required.
Storage administrator stand-alone environment planning
Complete these planning steps:
1. Determine how to set up your tape management systems pooling support to segregate
rewritable (MEDIA5, MEDIA7, and MEDIA9) and WORM (MEDIA6, MEDIA8, and
MEDIA10) media and also how to segregate the standard, economy, and extended length
cartridges, as appropriate for their jobs and application usage.
2. Review the usage of the DEVSUPxx PARMLIB option, ENFORCE_DC_MEDIA, (this step
is optional) to ensure that the media type that is mounted is the media type that is
requested through the Data Class. You can use this method in conjunction with the tape
management systems pooling support as an additional safety check.
3. Review the existing SMS Data Class media policies to ensure compatibility with existing
tape scratch pool policies before enabling the DEVSUPxx PARMLIB option,
ENFORCE_DC_MEDIA.
4. Review the existing SMS Data Class recording technology policies to ensure that data set
policies set to EFMT1 are being appropriately used. If an encryption-capable IBM TS1120
Tape Drive is allocated and the specified Data Class indicates EFMT1, the drive will record
in the lower recording technology.
5. Determine the Data Class updates that are required to request the appropriate recording
format for the encryption-capable TS1120 tape drives. If an encryption-capable IBM
TS1120 Tape Drive is allocated, the default recording format is EFMT2 (non-encryption).
6. Determine if media has to use performance segmentation, with a fast access segment to
be filled first, and a slower access segment to be filled after the fast access segment. If
you decide to use the performance segmentation attribute (available with MEDIA5 and
MEDIA9 tape cartridges only and mutually exclusive with performance scaling), you can
perform these tasks:
a. Define a Data Class that requests performance segmentation.
b. Modify or create ACS routines to associate the tape output functions using
performance segmentation with a Data Class that requests performance
segmentation.
7. Determine whether media must be used at full capacity or scaled for optimal performance.
If you decide to use the performance scaling attribute (available with MEDIA5 and MEDIA9
tape cartridges only), you can perform these tasks:
a. Define a Data Class that requests performance scaling.
b. Modify or create ACS routines to associate the tape output functions using
performance scaling with a Data Class that requests performance scaling.
8. Determine how to allocate media to appropriate non-library drives. Consider using the IBM
manual tape library. You can also segregate the actual drives from the emulating drives,
use third-party tape management software, or use client-written applications.
9. Identify any required changes to the hardware configuration definition (HCD) to define the
new devices.
Storage administrator tape library environment planning
Complete these planning steps:
1. Review the usage of the DEVSUPxx PARMLIB option, MTL_NO_DC_WORM_OK, if the
WORM cartridges in the manual tape library environment will be mounted through the use
of the tape management systems pooling support as opposed to a Data Class WORM
media specification.
2. Determine the 3592 media usage of rewritable (MEDIA5, MEDIA7, and MEDIA9) and
WORM (MEDIA6, MEDIA8, and MEDIA10) media and also the usage of the standard,
economy, and extended length cartridges. Then, make the appropriate Data Class
definition updates to select the appropriate media type. You can only use WORM media if
it is explicitly requested through the Data Class.
3. Review ACS routines for changes that are required in selecting tape storage groups and
libraries that have the new encryption-capable IBM TS1120 tape drives.
4. Determine the Data Class updates that are required for using the recording technology,
media type, and performance scaling or performance segmentation Data Class attribute.
Performance scaling or segmentation is available with MEDIA5 and MEDIA9 tape
cartridges only.
5. Identify any required changes to the HCD to define the new devices.
6. To define the partitioning category code for MEDIA5, MEDIA6, MEDIA7, MEDIA8,
MEDIA9, and MEDIA10 tape cartridges, specify the appropriate parameter of the
DEVSUPxx PARMLIB member.
DFSMS Systems Managed Tape implementation
After completing the planning steps, these tasks are required to implement this solution.
Both native TS1120 drives and TS1120 drives attached to a TS7700 are available for
encryption in IBM tape library environments. Many of the planning steps are common to both
environments, but certain steps are unique to one environment or the other environment.
z/OS encryption implementation checklist
Follow these steps to implement this solution:
1. For both native TS1120 drives and the TS7700 environment, install the Encryption Key
Manager (EKM) and set up the keystore that it will use.
2. Perform these steps for native TS1120 drives:
a. When systems will share the encryption-enabled TS1120 drive, install either the
TS1120 encryption coexistence support or full support on all systems and restart these
systems.
b. If the TS1120 drives are in a TS3500, 3494, or TS3400 tape library, use the TS3500,
3494, or TS3400 Tape Specialist to set (enable) the TS1120 drives (attached to the
3592 Model J70 or TS1120 Model C06 tape controllers) to the System-Managed
Encryption method.
c. If the TS1120 drives are in a rack or in a C20 Silo frame, have your IBM service support
representative (SSR) install FC5596 or FC9596 on each of the TS1120 drives. This
feature code enables the System-Managed Encryption method on each of the drives.
d. Have your SSR install FC5595 or FC9595 on the 3592 Model J70 and the TS1120
Model C06 tape controllers, which also enables encryption on all attached
encryption-capable drives. Make sure that this step is not performed until the
previously mentioned operating system maintenance has been implemented.
e. Create the DFSMS Data Class policies specifying EE2 (EEFMT2). Also specify, as
appropriate, the non-encryption recording formats: E1 (EFMT1) or E2 (EFMT2). In
addition, you must specify a media type of MEDIA5, MEDIA6, MEDIA7, MEDIA8,
MEDIA9, or MEDIA10, and the performance scaling and performance segmentation
attributes. Performance scaling and performance segmentation are available with
MEDIA5 and MEDIA9 tape cartridges only.
f. Modify the DFSMS Data Class constructs or use DD statements (or use Encryption
Key Manager defaults) to specify the key labels and their encoding mechanism (label
or hash).
g. Modify or create ACS routines to associate the tape output functions using with a Data
Class that has the appropriate recording format specified.
h. Update the IOS PARMLIB member (IECIOSxx) using the new EKM command. Also,
create an OMVS (open MVS) segment for the IOS address space. Creating an OMVS
segment for IOS requires an IPL.
i. Upgrade 3592 Model J1A and base TS1120 Model E05 microcode to enable the drives
to recognize the EEFMT2-formatted cartridges and enable the cartridges to be
relabelled and reused. Also, ensure that VOLNSNS=YES is in the DEVSUPxx member
of PARMLIB.
j. Make any required changes to the HCD to define the new devices; generally, this step
is not required except when installing 3592 or TS1120 drives for the first time. No
additional HCD changes are required to support encryption.
k. If required, define the partitioning category code for MEDIA5, MEDIA6, MEDIA7,
MEDIA8, MEDIA9, or MEDIA10 tape cartridges, and specify the appropriate parameter
of the DEVSUPxx PARMLIB member.
3. Perform these steps for TS1120 drives that are attached to the TS7700 Virtualization
Engine:
a. Implement the appropriate DFSMS storage group and management class policies.
Also, modify or create ACS routines to select these storage group and management
class constructs for data that you want to be encrypted within a storage pool in the
TS7700.
b. Implement matching storage groups and management classes in the TS7700 that
specify the storage pools where encryption will be used.
c. Using the TS3500, 3494, or TS3400 Tape Specialist, set (enable) the TS1120 drives
that are to be used by the TS7700 to the System-Managed Encryption method.
d. Using the instructions that are provided with FC9900, install the Feature License for
9900 in the TS7700 (3957-V06). This Feature License enables encryption microcode
within the TS7700.
e. Modify storage pools within the TS7700 to specify encryption and to specify the key
labels and key encoding (Label or Hash) to be used.
f. Modify the EKM addresses within the TS7700 to specify the TCP/IP addresses for your
EKM implementations.
g. If required, define the partitioning category code for MEDIA1 or MEDIA2 virtual
volumes within the TS7700, and specify the appropriate parameter of the DEVSUPxx
PARMLIB member.
4. Perform these steps for both environments:
a. Ensure that the required microcode updates for the new media (MEDIA9 and
MEDIA10) have been made.
b. Make any required installation exit changes.
c. Define or alter the existing storage group constructs to include libraries with the new
encryption-enabled TS1120 tape drives or the encryption-enabled TS7700.
d. Update ACS routines to direct allocations to the encryption-enabled IBM TS1120 Tape
Drive or to the encryption-enabled TS7700, as requested.
e. Validate and activate any new or modified storage management subsystem (SMS)
configuration.
f. Test your implementation.
Object access method planning
The planning steps that you must consider in tape environments that use object access
method (OAM) objects vary depending upon the type of environment that is installed. OAM is
not a common implementation.
Perform the following steps:
1. Perform these steps if you install the new encryption-capable IBM TS1120 Tape Drive in a
stand-alone environment:
a. Follow the system customization planning steps that are listed for the DFSMS
environment.
b. Determine the esoteric or generic device names that have to be added to
STORAGEGROUP statements in the CBROAMxx member of PARMLIB for the object
storage groups that are designated to use the new devices.
c. Determine whether to use the global keyword DSNWITHSGNAME on the SETOAM
statement in the CBROAMxx member of PARMLIB to append the object storage group
name to the OAM object tape data set names.
2. Perform these steps if you install the new encryption-capable IBM TS1120 Tape Drive in
an IBM tape library:
a. Follow the system customization planning considerations that are listed for the DFSMS
environment.
b. Determine the new Data Classes that have to be defined in STORAGEGROUP
statements in the CBROAMxx member of PARMLIB for the object storage groups that
are designated to use the new devices.
3. In addition, perform these steps if you install the new encryption-capable IBM TS1120
Tape Drive in an OAMplex:
a. Ensure that the new encryption-capable IBM TS1120 tape drives are available to all
instances of OAM where the full support software is installed.
b. Determine whether systems exist that will require coexistence support. This situation is
particularly important in an OAMplex where at least one system has the full-support
software installed and enabled, and at least one system will not have all the support
installed or enabled. Coexistence support is required if not all the systems in the
OAMplex will be at the same full-support level.
c. To provide this coexistence support, as appropriate for the support and the release
level, install the OAM full-support PTF without the enabling PTF or any separate
coexistence support PTF.
d. Determine when to start the IPL of the host system after installing the coexistence
PTFs, if required.
Storage administrator OAM planning
The planning steps that you must consider in tape environments that use OAM objects vary
depending upon the type of environment that is installed:
1. If you install the new encryption-capable IBM TS1120 Tape Drive in a stand-alone
environment, follow the storage administration planning steps that are listed for the
Storage Administrator stand-alone environment planning.
2. Perform these steps if you install the new encryption-capable TS1120 Tape Drive in an
IBM tape library:
a. Follow the storage administration planning steps that are listed for the Storage
Administrator tape library environment planning.
b. Review the ACS routines for STORE or CTRANS environments and make any
changes that are required to ensure proper class assignment.
3. If you install the new encryption-capable TS1120 Tape Drive in an OAMplex, you must
make the devices available to all instances of OAM where the full support is installed.
OAM implementation
After completing the planning steps, these are the tasks required to implement this solution.
The migration steps that you must take in tape environments that use OAM objects vary
depending upon the type of environment that is installed. Perform the following tasks:
1. If you install the new encryption-capable IBM TS1120 Tape Drive in an OAMplex:
a. Make the new encryption-capable IBM TS1120 tape drives available to all instances of
OAM where the full support software is installed.
b. Install coexistence PTFs as appropriate.
c. Consider setting DSNWITHSGNAME in the SETOAM statement in the CBROAMxx
PARMLIB member. Review your ACS routines if you are appending the storage group
name to OAM data set names (DSNWITHSGNAME).
d. IPL the system.
2. If you install the new encryption-capable IBM TS1120 tape drives in an IBM tape library:
a. Follow the migration steps listed for DFSMS Implementation.
b. Define the new Data Classes in STORAGEGROUP statements in the CBROAMxx
member of PARMLIB for the object storage groups that are to use the new devices.
c. Make the required changes to ACS routines for ALLOC, STORE, or CTRANS
environments.
3. If you install the new encryption-capable IBM TS1120 tape drives in a stand-alone
environment:
a. Follow the migration steps listed for DFSMS Implementation.
b. Add new device esoteric unit names or generic unit names to STORAGEGROUP
statements in the CBROAMxx member of PARMLIB for the object storage groups that
are to use the new devices. The esoteric or generic unit name must consist of
encryption-capable IBM TS1120 tape drives exclusively, because the EFMT2 recording
technology is incompatible with other recording technologies.
c. Consider setting DSNWITHSGNAME in the SETOAM statement in the CBROAMxx
PARMLIB member. Review your ACS routines if you are appending the storage group
name to OAM data set names (DSNWITHSGNAME).
d. Make the required changes to ACS routines for the ALLOC, STORE, and CTRANS
environments.
DFSMShsm tape environment
DFSMShsm allows the specification of tape unit names using either generic or esoteric
names. In installations that have a mixture of non-SMS-managed 3590 or 3592 devices that
are defined under the 3590-1 generic name, perform the following steps:
1. Define a unique esoteric name for each recording technology.
2. Use the SETSYS USERUNITTABLE command to define these esoteric names to
DFSMShsm. This also applies to mixed devices in the 3490 generic device name.
Installations, which use SMS-managed tape devices or have a single 3590-1 recording
technology, do not have to define an esoteric name for those devices. However, if you have
a mixed SMS-managed 3590 environment, review APAR OW57282.
Appendix B. DS8700 encryption-related
system reference codes
Table 25-1 contains all the system reference codes (SRCs), which might occur on an
encryption-enabled DS8700 only. The Action column contains advice to help you start the
investigation.
Table 25-1 Encryption-related SRCs
B
SRC Description Call home
or notify
only
Action
BE14CFE0 DS8000 management console was
unable to retrieve keys from any of
the encryption key management
(EKM) servers.
Call home Check the connection to the
servers.
BE14CFE1 DS8000 management console
regained access to client EKM
servers.
Call home Automatic dual cluster reboot
initiated. No further action is
needed.
BE14CFE5 Base page mismatch detected and
recovered by automatic dual cluster
reboot.
Notify only No further action is needed.
BE14CFEA Periodic key retrieval failed for one
or more configured EKM servers.
servers.
BE14CFEB DS8000 microcode detected fewer
than two EKM servers configured.
Call home Install/configure additional
servers.
BE14CFEC Microcode detected valid deadlock
recovery key. Dual cluster reboot
initiated to restore machine to
operational state.
Call home Deadlock recovery is in
progress. No further action is
needed.
BE14CFED Microcode failed to unwrap
encryption group key based on
recovery key received from client.
Call home
Call next level of support.
BE14CFEF Microcode detected that client has
not configured deadlock recovery
key.
Call home Configure deadlock recovery
key.
BE14CFF0 Microcode detected multiple
attempts to authenticate or recover
dead-locked system with invalid
recovery key.
Call home Call next level of support.
BE14CFF1 Microcode detected that user has
rekeyed recovery key.
Notify only No further action is needed.
BE14CFF2 Microcode detected that the
electronic recovery key (ERK) and
the electronic group key (EGK)
records are out of sync.
Notify only Generate new recovery key.
BE14CFF3 Rivest-Shamir-Adleman (RSA)
generation key process stopped in
microcode.
BE14E004 Unable to retrieve keys from any
configured EKM server. No active
EKM server paths found.
servers.
BE14E008 Unable to retrieve keys from any
configured EKM servers due to
communication errors between the
Hardware Management Console
(HMC) and EKM servers.
servers.
BE14E009 The DS8000 management console
is unable to retrieve encryption keys
from client EKM servers due to
communication errors between
DS8000 partitions and the hardware
management console.
BE14E00B The DS8000 management console
from client EKM servers. A
command timeout has occurred
between DS8000 partitions and the
HMC.
BE14E011 All configured EKM servers are
unable to unwrap keys provided by
DS8000 management console.
BE14E012 Microcode is unable to unwrap keys
received from all configured EKM
servers.
or notify
only
Action
Appendix B. DS8700 encryption-related system reference codes 875
BE14E013 Key retrieved from all the configured
EKM servers failed signature
verification.
BE14E0F1 The DS8000 management console
is unable to access the client EKM
servers.
servers.
BE14E1F6 DS8000 partitions started initial
machine load (IML) without any
client encryption servers. EKM
server is now available.
Call home DS8000 partitions must have
IML restarted to allow data
access.
BE14E3F7 DS8000 data encryption key
repository permanent error. Failure
to read record or certificate.
BE14EA0B The DS8000 management console
from several of the EKM servers. A
command timeout has occurred
between DS8000 partitions and the
HMC.
BE14EA11 One or more EKM servers are
unable to unwrap keys provided by
DS8000 management console.
BE14EA12 Microcode is unable to unwrap keys
received from one or more EKM
servers.
BE14EA13 Key retrieved from several of the
EKM servers has failed signature
verification.
BE14EAF1 DS8000 management console is
unable to connect to configured
EKM server.
Notify only Check the connection to the
servers.
BE14EAF2 DS8000 management console is
unable to connect to configured
EKM server. Heartbeat is failing for 4
hours.
servers.
or notify
only
Action
Appendix C. z/OS Java and Open Edition tips
In this appendix, we provide helpful tips for UNIX and UNIX System Services environments to
help you set up Encryption Key Managers (EKMs) and Java. We include an introduction to
Java.
C
JZOS
The JZOS job launcher and runtime application programming interfaces (APIs) are the latest
inclusion in the IBM Java software development kit (SDK) distribution for z/OS that is
specifically tailored for submitting Java applications as a job.
1
You can obtain a more detailed
description of JZOS in Java Stand-alone Applications on z/OS Volume II, SG24-7291.
Obtain the JZOS Batch Launcher and Toolkit function in IBM SDK for z/OS Installation and
Users Guide:
http://www.ibm.com/servers/eserver/zseries/software/java/pdf/jzosinstal.pdf
JZOS includes Java classes that make the console communication from Java applications
easy. Instead of implementing the console communication using Java Native Interface (JNI)
calls, JZOS provides a framework to register a listener for interaction with operators or write
to operator (WTO). It also provides a method to write messages to MVS system logs directly
from Java applications. Using this framework, Java programs are able to write messages to
the MVS system log when they require special attention from the operator. You can use this
capability as a means to integrate with the system automation tools to monitor the status of
the running Java batch programs. Receiving commands from the operator while Java batch
jobs are running (accepting the modify command) is also possible. Consequently, it is
possible to program Java programs to change behaviors depending on the commands that
are received from the operator without restarting the job. Refer to Java Stand-alone
Applications on z/OS Volume II, SG24-7291, for more information about JZOS.
The JZOS batch launcher directs stdout and stderr input streams to the standard MVS data
sets and JESS SYSOUT data set. Also, Java programs are able to read from stdin from the
standard MVS data sets. With BPXBATCH, it is only possible to write to and read files in UNIX
System Services. Consequently, operators are able to monitor the output from Java programs
using System Display and Search Facility (SDSF) just like monitoring any other job steps in
the MVS environments.
JZOS supports the following functions:
Runs in the same address space as the submitted job
Supports data definition (DD) statements
Redirects stdin, stdout, and stderr to an MVS data set
Supports console communication
Supports return codes using System.exit
Console communication with batch jobs
A common practice is to use the write-to-operator (WTO) macro by running programs (jobs) to
write messages to the job log and the system console. You typically use the macro to report
the status of the program. For instance, use the macro to record events when failure occurs in
a long running job. Based on the messages, the operator can decide to take appropriate
actions to resolve the problems. Under such circumstances or when the operator has to
interact with the job, a common practice is to use the MVS stop (P) command to stop the
running job or use the MVS modify (F) command to send arbitrary commands to change the
behavior of the job. Running jobs are programmed to accept and respond to these
commands. JZOS provides APIs to add these capabilities to Java applications. In this section,
we present how to interact with jobs using the MVS console and how to use these APIs in
Java applications.
1
IBM acquired JZOS batch technology from Dovetailed Technologies, LLC, in 2006. At the time of writing this book,
JZOS is available from alphaWorks at no charge. JZOS is part of the standard distribution of IBM Java SDK 5.0
for z/OS.
Appendix C. z/OS Java and Open Edition tips 879
Encryption Key Manager and JZOS
A UNIX System Services process in a foreground shell environment is incapable of providing
reliability, availability, and serviceability (RAS) as a task that is started under MVS. A UNIX
System Services process is subject to the environment under which the user started it.
In the foreground, a started EKM is tied to a specific terminal where the user started the
process. If the terminal goes down or the user that was logged in to start that process exits,
the process is stopped, and EKM is stopped. Running EKM in the foreground provides an
interaction with EKM that BPXBATCH removes. The JZOS process started with the console
wrapper application. The com.ibm.jzosekm.EKMConsoleWrapper provides the interface
between the z/OS operators console and EKM. Therefore, the need for a shell process is
eliminated, EKM can run as a started task with all the security controls that environment
entails, and messages come to the console and can be acted upon by automation processes.
MVS modify command
To interact with a Java application that was started using JZOS, the MVS modify command is
used. The MVS modify command uses the following syntax:
/f jobName,commands
This command sends the specified commands to the specified job. A job receiving the
commands has to be programmed to receive and react to the commands.
Installing non-SMP/e JZOS
These instructions assume that the non-SMP/E for z/OS pax file has been uploaded and
extracted according to the Java SDK product installation instructions. Follow these steps:
1. Allocate any required MVS partitioned data sets extended (PDSE) or partitioned data set
(PDS) data sets. For your information, the SMP/E installation, by default, places a load
module in SYS1.SIEALNKE, a sample PROC in SYS1.PROCLIB, and sample JCL in
SYS1.SAMPLIB.
For installation into private data sets, use the suggested allocation parameters for
SAMPJCL and for SAMPPROC:
RECFM=F/FB,LRECL=80,SPACE=(TRK,(5,1))
2. Copy the load modules to a PDSE and copy the procedures and JCL to a PDS from the
extracted (unpaxed) file. The load module is in <JAVA_HOME>/mvstools. The sample JCL
and PROC is in <JAVA_HOME>/mvstools/samples/jcl. For example, for the 1.4 SDK and
using the default target libraries, issue the following commands under a UNIX System
Services shell:
cp JVMJCL14 "//SYS1.SAMPLIB(JVMJCL14)"
cp JVMPRC14 "//SYS1.PROCLIB(JVMPRC14)"
cp -X JVMLDM14 "//SYS1.SIEALNKE(JVMLDM14)"
3. Change the sample JCL and PROC as appropriate for your environment. Specifically,
update JCL with JOB card information, update the JCL and PROC with HLQ where the
PROC and LOADLIB exist, and update the PROC with the location of JAVA_HOME. Make
sure that your sample JCL or PROC includes a STEPLIB to the load library unless that
load-library is included in your LNKLST member. In Example C-1 on page 880, we have
modified the procedure to point to where we copied the loadlib, which is at this location:
JBARNEY.PRIVATE.JZOS.LIB
Tip: The jzosekm.jar JAR file provides the callback functionality to communicate with
EKM when it is started using JZOS.
Example C-1 Sample modified procedure
//*********************************************************************
//*
//*
//* Tailor the procedure for your installation:
//* 1.) Replace '<HLQ>.JZOS.LOADLIB' with the PDSE that contains the
//* JZOSVMxx modules that were installed during installation
//*
//*********************************************************************
//EXJZOSVM PROC JAVACLS=, < Fully Qfied Java class..RQD
// LIBRARY='JBARNEY.PRIVATE.JZOS.LIB', < STEPLIB FOR JZOSVM module
// VERSION='14', < JZOSVM version: 14, 50, 56
// LOGLVL='', < Debug LVL: +I(info) +T(trc)
// REGSIZE='0M', < EXECUTION REGION SIZE
// LEPARM=''
//JAVAJVM EXEC PGM=JVMLDM&VERSION,REGION=&REGSIZE,
// PARM='&LEPARM/&LOGLVL &JAVACLS &ARGS'
//ABNLIGNR DD DUMMY
//*
//*The following DDs can/should be present in the calling JCL
//*
//*STDIN DD < OPTIONAL - Java System.in
//*STDENV DD < REQUIRED - JVM Environment script
//*MAINARGS DD < OPTIONAL - Alternate method to supply args
// PEND
Example C-2 is a sample JCL that we copied into JBARNEY.PRIVATE.SAMPJCL, which also
contains our procedure from Example C-1. This sample JCL calls the procedure with the
setup for our Java environment and execute the Java class Hello. This class must be
included in the class path setup in this JCL example.
Example C-2 Sample JCL
//JBARNEY0 JOB ()
//PROCLIB JCLLIB ORDER=JBARNEY.PRIVATE.SAMPJCL
//*
//*********************************************************************
//*
//* Batch job to run the Java1.4 VM
//*
//* Tailor the proc and job for your installation:
//* 1.) Modify the Job card per your installation's requirements
//* 2.) Modify the PROCLIB card to point to this PDS
//* 3.) edit JAVA_HOME to point the location of the 1.4 JDK
//* 4.) Modify the CLASSPATH as required to point to your Java code
//* 5.) Modify JAVACLS and ARGS to launch desired Java class
//*
//*********************************************************************
//*
//*
//JAVA EXEC PROC=JZOSPRC,
// JAVACLS='Hello'
//STDENV DD *
. /etc/profile
export JAVA_HOME=/usr/lpp/java/J1.4
LIBPATH=/lib:/usr/lib:"${JAVA_HOME}"/bin
CLASSPATH=/usr/lpp/java/J1.4/lib/ext
# Add required jars to end of CLASSPATH
for i in "${CLASSPATH}"/*.jar; do
CLASSPATH="$CLASSPATH":"$i"
done
# Use this variable to specify encoding for DD STDOUT and STDERR
# export JZOS_OUTPUT_ENCODING=Cp1047
# Use this variable to prevent JZOS from handling MVS operator commands
# export JZOS_ENABLE_MVS_COMMANDS=false
# Use this variable to supply additional arguments to main
# Configure JVM options
IJO="-Xms16m -Xmx128m"
# Uncomment the following to aid in debugging "Class Not Found" problems
IJO="$IJO -verbose:class"
# Uncomment the following if you want to run with Ascii file encoding..
#IJO="$IJO -Dfile.encoding=ISO8859-1"
export JAVA_DUMP_HEAP=false
export JAVA_PROPAGATE=NO
export IBM_JAVA_ZOS_TDUMP=NO
//
4. SUBMIT the modified JCL and check the job log. If you set up everything properly, the
SYSOUT DD contains output that is similar to Example C-3.
Example C-3 Sample JZOS output
JVMJZBL1001N JZOS batch Launcher Version: 2.0.0 2006-06-30
JVMJZBL1002N Copyright (C) IBM Corp. 2005. All rights reserved.
Classic VM (build 1.4.2, J2RE 1.4.2 IBM z/OS Persistent Reusable VM
build cm142-20060803 (JIT enabled: jitc))
JVMJZBL1023N Invoking Hello.main()...
JVMJZBL1024N Hello.main() completed.
JVMJZBL1021N JZOS batch launcher completed, return code=0
Hello World
To diagnose problems with the JZOS batch launcher, change the LOGLVL parameter to:
+I:
This following LOGLVL parameter is an example:
// EXEC JVMLDM14,LOGLVL=+I,
MVS Open Edition tips
The OMVS shell entered through TSO is not the most UNIX-like shell environment. Because
of differences in the tn3270 protocol and a VT100 terminal, you can only use the Interactive
System Productivity Facility (ISPF) editor when invoking OMVS through Time Sharing Option
(TSO) by using the tn3270 protocol. In addition, the OMVS command line is limited to
approximately 125 characters.
Several workarounds are available to the 125-character limit on the command line:
Exporting long arguments to environment variables
Setting up an alias
Using relative paths instead of fully qualified paths for arguments
Copying the escape character, the cent sign (), to the end of a line, pressing Enter, and
continuing the command on a new line
Exporting a variable
To export a variable, enter a command similar to the following command:
export shortName = someLongCommandArgument
Then, when you want to use the argument someLongCommandArgument, enter this command:
$shortName
A common practice is to set up a .profile file in your home directory with a list of commonly
used environment variables that will be read each time that you log in.
Setting up an alias
An alias is a UNIX shorthand for a command that you commonly use. Aliases are typically set
up in the .profile file. The following alias is one of the most common aliases:
alias ll = ls -l
When you enter ll at the command line, it performs the same as the ls -l command.
It can also take all the additional ls arguments. Use this alias to work with EKM:
alias startEKM = java com.ibm.keymanager.KMSAdminCmd
Trace level setting: Setting this logging level (+I) dumps the environment that is passed to
the JVM. The trace level setting +T produces many messages, several of which might
be helpful in tracking down installation problems.
Now, enter the following command to start EKM:
startEKM KeyManagerConfig.properties
Copying the escape character
Figure C-1 is an example of spanning new lines using the cent () escape character.
Figure C-1 Using the escape character
The following actions relate to the example that is shown in Figure C-1:
1. On a single line, we entered all the following information:
The java command
The -Djava.protocol.handler.pkgs=com.ibm.crypto.hdwrCCA.provider system
argument
The character at the end of the line
2. We pressed Enter.
3. We added the com.ibm.keymanager.KMSAdminCmd class argument with another
character.
After we press Enter, we simply add the KeyManagerConfig.properties EKM configuration
file, and EKM starts.
Advantages of VT100
You can set up a Telnet daemon, rlogin daemon, or a Secure Shell (SSH) daemon to give
alternative access to OMVS. Refer to the Communications Server for z/OS V1R2 TCP/IP
Implementation Guide, SG24-5227, for setting up Telnet and rlogin using the inetd
command. Refer to the IBM Ported Tools for z/OS Users Guide, SA22-7985, for details about
setting up SSH.
If any of these three daemons currently run on a z/OS system, you can use a VT100 terminal
emulator to log in to the system. Then, changing our shell from /bin/sh to /usr/sbin/bash is
useful. Refer to the following website for more information about ported tools and bash:
http://wwwibm.com/servers/eserver/zseries/zOS/unix/port_tools.html
Replacing bash with the sh shell and using a VT100 terminal give us the following features:
Tab completion
When entering the name of a command, file, or directory, pressing Tab autocompletes
them if you typed enough of the name to make it unique. If you did not enter enough of the
name to make a unique match, pressing Tab twice gives you a list of possible matches.
Ctrl+r
Pressing Ctrl+r puts the command line into a reverse search of previous commands. Type
a portion of a previously entered command and the shell tries to choose the closest
match.
Up and down arrow keys
The up and down arrow keys navigate the history list of commands.
Command line length
Using a VT100 terminal lets you type in a virtually endless length command on the
command line.
History command
Typing history echoes the complete command list, prefixed with a number, to the window.
Entering ! commandNumber executes that command.
Directory stack
When navigating long directory paths, if you use the pushd . command, the current
working directory path is pushed onto a stack. Typing popd pops the directory path off the
stack and returns you to that working directory.
When using an SSH client, you must include the stty quit ^V command in your .profile
file. In Example C-4 on page 885, there is a sample .bashrc file. We suggest that when you
log in with a VT100 terminal that you include a simple .profile file in your user home
directory, and at the end of the .profile file, execute the bash command. If the path to bash is
Security alert: SSH is the most secure of the three daemons listed here. Connection to
OMVS using SSH requires an SSH client. SSH is not included in Windows. For this book,
we used SecureCRT on Windows. Many no-charge SSH clients are available for other
UNIX and Linux systems, including OpenSSH.
SSH encrypts all traffic between the SSH client and the SSH daemon.
Windows includes a Telnet client.
There are also no charge ssh clients for Linux.
lost, or you do not have a path to bash setup and you end up logging in from TSO, entering
OMVS fails, because the shell cannot be found. If a .profile is calling bash, and if bash is
lost, you simply receive an error, and continue. When bash is executed, the .bashrc file is
read, which is similar to when you log in to OMVS and the .profile file is read.
The export PS1 sets up this users command line. In this case, we are setting the command
line to always list the current working directory. This setting is useful when navigating around
an OMVS file system.
After that, we set up the JAVA_HOME environment variable. This environment variable has to
point to the Java home on your system. Next, we add JAVA_HOME/bin to our path, in addition to
several other useful directories. Notice that we are careful to keep our original path here by
appending it to our new PATH. After that, we create environmental shorthand.
Example C-4 Simple .profile
stty quit ^V
export PS1='$PWD>';
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 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 EKM=com.ibm.keymanager.KMSAdminCmd
Advanced security hwkeytool and keytool scripts
In this section, we describe how to create scripts to aid in the generation of JCEKS and
JCECCAKS keystores for use with EKM. Unlike previous sections, here we present complete
scripts to make it easier to cut and past into a script file. We include showing you how to
prevent passwords from being saved in the script file. You can also apply the techniques that
are outlined in this section to preventing passwords from showing up in shell history, because
they never appear in the window.
Complete keytool example for JCEKS using hidden passwords
The script in Example C-5 on page 886 creates a JCEKS keystore with two self-signed
certificates, each with a public and private key pair. The script then exports the first certificate
created and reimports that certificate with a new alias as a trusted certificate entry. This entry
does not have a private key associated with it. The following definitions explain these
certificates:
cert1 Certificate alias and public and private keys that are associated with
this certificate
this certificate
cert1ca Trusted certificate entry with only a public key that is associated with
this certificate
rsa2048Cert1.cer Distinguished Encoding Rules (DER)-encoded file that contains the
exported public key that matches the public key of cert1
In this script, the first line tells the operating system that we use the bash shell to execute the
commands in the script. The following example is the first line:
#!/bin/bash
This script is sufficiently generic that it can be executed using /bin/sh.
After we set up the shell with which to execute the script, we then use the echo command to
prompt for the correct passwords.
The following command prevents what we type, in this case, a password, from being
displayed to the command line:
stty -echo
We then read what is typed into the command line to a variable and plug the variable into our
keytool commands.
Example C-5 Keytool hidden password script
#!/bin/bash
echo -n "Please Enter the Keystore password"
echo ""
stty -echo
read STOREPASS
stty echo
echo "" #force a carriage return to be output
echo -n "Please Enter the private key password"
echo ""
stty -echo
read KEYPASS
stty echo
echo -n "start key generation"
keytool -genkey \
-alias cert1 \
-dname CN=IBM \
-provider IBMJCE \
-keyalg RSA \
-keysize 2048 \
-keypass $KEYPASS \
-storepass $STOREPASS \
-storetype JCEKS \
-validity 999
echo "Finish genkey for alias = cert1"
keytool -genkey \
-alias cert2 \
-dname CN=IBM \
-provider IBMJCE \
-keyalg RSA \
-keysize 2048 \
-keypass $KEYPASS \
-storetype JCEKS \
-validity 999
keytool -export \
-alias cert1 \
-storetype JCEKS \
-provider IBMJCE \
-keypass $KEYPASS
echo "Finish export of cert1"
keytool -import \
-noprompt \
-alias cert1ca \
-storetype JCEKS \
-provider IBMJCE
Complete hwkeytool example for JCE4758KS using hidden passwords
The script in Example C-6 on page 888 creates a JCE4758KS keystore with two self-signed
certificates, each of which has a public and private key pair. The script then exports the first
certificate created, and then the script reimports that certificate with a new alias as a trusted
certificate entry. This entry does not have a private key associated with it. In this script, we
use default values for the hardwaretype argument, which is going to be CLEAR. The default
value for hardwareusage specified is KEYMANAGEMENT. Because we are creating
Rivest-Shamir-Adleman algorithm (RSA) key pairs, the hardwareusage and hardwaretype
defaults differ for digital signature algorithms (DSAs). The following definitions explain these
certificates:
this certificate
this certificate
cert1ca Trusted certificate entry with only a public key that is associated with
this certificate
rsa2048Cert1.cer DER-encoded file, which contains an exported public key that matches
the public key of cert1
In this script, the first line tells the operating system that we use the bash shell to execute the
commands in the script:
#!/bin/bash
This script is sufficiently generic that it can be executed using /bin/sh.
After we set up the shell with which to execute the script, we then use the echo command to
prompt for the correct passwords.
The following command prevents what we type, in this case, a password, from displaying to
the command line:
stty -echo
We then read what is typed into the command line to a variable and plug the variable into our
keytool commands.
Example C-6 Password hidden hwkeytool script
#!/bin/bash
echo -n "Please Enter the Keystore password"
echo ""
stty -echo
read STOREPASS
stty echo
echo -n "Please Enter the private key password"
echo ""
stty -echo
read KEYPASS
stty echo
echo -n "start key generation"
hwkeytool -genkey \
-alias cert1 \
-dname CN=IBM \
-keystore testkeys.4758ks \
-keyalg RSA \
-keysize 2048 \
-keypass $KEYPASS \
-validity 999
hwkeytool -genkey \
-alias cert2 \
-dname CN=IBM \
-keyalg RSA \
-keysize 2048 \
-keypass $KEYPASS \
-validity 999
hwkeytool -export \
-alias cert1 \
-keypass $KEYPASS
echo "Finish export of cert1"
hwkeytool -import \
-noprompt \
-alias cert1ca \
-provider IBMJCE4758
echo "Finish import of cert1ca"
Java
Java has become extremely popular for building new applications on distributed platforms and
also on the mainframe. Java is a language whose specifications are maintained by Sun
Microsystems, Inc. Java achieves this goal simply by compiling programs to byte code, which
creates one or more class files, which can then be run by a machine-specific Java Runtime
Environment (JRE). A JRE consists of a Java virtual machine (JVM) and a just-in-time
compiler (JIT). A JIT is used to translate a subset of Java byte code into native machine code
at run time to improve performance, that is, just in time. Running a Java application without
the JIT and incurring a large performance degradation is possible. The existence of a JVM
enables applications that are written in Java to be largely independent of the operating
system in use.
Java was originally developed in the early 1990s by Sun Microsystems, Inc., as an
object-oriented programming language based on the programming language C++. The
syntax that is used in Java code originates from C++ and is therefore recognizable for those
people with C++ experience.
To run a Java application, you have either a JRE or a Software Developer Kit (SDK) installed
on the system where the application will run. A JRE only includes the required JVM code to
execute Java applications. An SDK, which is also referred to as a JDK (Java Developer Kit),
includes everything a JRE has, and in addition, it includes developer tools, such as the javac
compiler, and gives developers access to Java APIs. You must download and install the SDK
to run EKM.
Security and providers
The IBM Java SDKs include a set of security providers. A provider is a set of common APIs to
extend Java to add security capabilities. The provider architecture supplies algorithm
implementations for service classes. A collection of all the implementations is referred to as a
service provider, or simply a provider. The provider architecture supports the development of
these plug-replaceable components.
You can obtain more information about implementing your own security provider at this
website:
http://java.sun.com/j2se/1.4.2/docs/guide/security/HowToImplAProvider.html
The following list shows a sampling of IBM providers:
IBMJCE Java Cryptographic Extension
IBMJCE4758 JCE using z/OS hardware cryptographic services JDK 1.42 and earlier
IBMJCECCA JCE using z/OS hardware cryptographic services JDK 5.0 and later
IBMJSSE Java Secure Sockets Extension (Secure Sockets Layer (SSL) and
Transport Layer Security (TLS))
IBMJSSE2 Java Secure Sockets Extension (SSL and TLS). JSSE2 is aliased in JDK 5
and later as JSSE
IBMJAAS Java Authentication and Authorization Service
IBMJGSS Generic Security Services: Kerberos and Generic Security Services
application programming interface (GSS-API) (JDK 1.4.0 and later only)
IBMPKCS11 Use hardware cryptography using the Public Key Cryptographic Standards
11 (PKCS#11 standard)
Garbage Collector
Another important feature of the JVM is the Garbage Collector. The Garbage Collector is a
background thread of the JVM to reclaim unusable space and is extremely important for the
performance of the JVM.
When a Java program makes a request for storage and the JVM is unable to comply, an
allocation failure occurs. This allocation failure triggers the Garbage Collection process.
Garbage Collection is the process of automatically freeing objects that are no longer
referenced by the program.
IBM is a major supporter and user of Java across all of the IBM computing platforms, from
open systems to z/OS. As a middleware product, Java offers an application programming
interface (API) and a JVM to run programs. The existence of a JVM means that applications
that are written in Java are largely independent of the operating system in use.
Over the years, Java has been shown to be extremely popular, and the JVM is available on
nearly all available operating systems, such as Microsoft Windows, Apple OS-X, i5/OS,
OS/400, Linux, UNIX, and z/OS UNIX.
The Java SDK contains the program products to assist application developers in the use of
the Java APIs.
Heap size: The behavior of the Garbage Collector is related to the heap size. A small heap
can produce more frequent, but shorter Garbage Collector cycles. A large heap size,
alternatively, produces less frequent, but longer Garbage Collector cycles.
zAAP: To simulate the use of Java on the mainframe, IBM came up with a special
processor for running Java applications. It is called the System z Application Assist
Processor, also known as zAAP. This type of processor is an optional feature in System z
hardware. When bought and installed, zAAP allows the client to benefit from additional
resources that are available only for Java executable code. In return, the client gets no
additional software license fees, because this processor type is outside of the scope of IBM
mainframe software licensing and pricing calculations.
Java SDKs contain industry standard APIs, and each SDK product can be ordered and
serviced independently and separately. The available Java SDKs for IBM systems are
available through the Internet or by placing a regular software order through IBM Software
Manufacturing. For more information about these products and for download instructions,
refer to this website:
http://www.ibm.com/developerworks/java/jdk/
Verifying the installation
Your path must contain the binary directory where Java is located:
PATH=/usr/lpp/java/J5.0/bin
CLASSPATH=/usr/lpp/java/J5.0/lib/
LIBPATH=/usr/lpp/java/J5.0/lib/ext/:
JAVA_HOME=/usr/lpp/java/J5.0/
The PATH statement is an environment variable to tell a UNIX-type system where the
programs (binaries) are located, in this case, the program java.
Now, verify that Java is correctly installed (Figure C-2).
Figure C-2 Java version
z/OS region size
Java programs can take up a lot of system resources, sometimes even more than you might
expect. Therefore, it is always necessary to examine your region size and allow for heap and
stack storage requirements, Language Environment code, Java code, and Language
Environment internal control blocks.
The region size describes the amount of storage in which a user is allowed to run or execute
programs. This value determines what kinds of programs (depending on their size) and how
many programs are executable at the same time.
Policy files
Because of governmental export regulations, JDKs are set up with the ability to perform
limited function cryptography. For full function cryptography, you must install the unrestricted
policy files. They are located at this website:
http://www.ibm.com/servers/eserver/zseries/software/java/j5jcecca.html
Copy the unrestricted policy files to $JAVA_HOME/lib/security. Make sure that the old policy
files are replaced or moved out of the JDK filesystem.
/u/johann>java -fullversion
java full version "J2RE 1.5.0 IBM z/OS build pmz31dev-20060607
(SR2)"
/u/johann>
Note: Installing multiple versions of SDK products is possible. The environment variable is
what points to a specific version of the SDK at run time. Each user can use a SDK version
at any time, independent from other users.
Tip: Some JDKS have policy files located in $JAVA_HOME/demo/jce/policy-files/.
Appendix D. Asymmetric and Symmetric
Master Key change procedures
This appendix presents detailed directions about how to change the Asymmetric Master Key
(ASM-MK) and Symmetric Master Key (SYM-MK) for Integrated Cryptographic Service
Facility (ICSF).
D
Asymmetric Master Key change ceremony
This section outlines the steps for changing the public key algorithm (PKA) Master Key. After
a new Master Key has been generated, you must secure the new key parts.
Prerequisites
The following steps outline the actions that must be completed before beginning a key change
ceremony:
1. Know the date that the ceremony will take place. This knowledge is required for the
naming of the Public Key Data Set (PKDS) and for uniquely identifying the correct key
parts.
2. You must create a PKDS prior to the key change ceremony. You must create the PKDS
with the following naming convention, as shown here:
PKDS: MVSSYS.CSF.<SYSPLEX>.D<YYMMDD>.CSFPKDS
3. You must obtain the devices, which will hold the key parts, prior to starting the key change
ceremony.
Testing encryption and decryption
This section is optional, but we encourage you to perform these steps. This procedure proves
that data keys can be correctly accessed from the PKDS, and data can be encrypted and
decrypted before attempting to change the ASYM-MK key. This procedure also provides data
to verify that the data keys that are protected by the ASYM-MK key are available after the
ASYM-MK key has been changed. You must perform this procedure one time for each
sysplex:
1. On the main Interactive System Productivity Facility (ISPF) panel, enter
option 6 PPINIT.
2. From this panel, enter the EX DATA.SET.NAME(MEMBER) command.
3. Return to the main ISPF panel (press F3), and enter MVS.
4. On the MVS panel, enter SDSF.
5. On the System Display and Search Facility (SDSF) panel, enter ST.
6. Select the job that was just executed by entering an S next to it. The job will be called
<JOBNAME>.
7. Scroll to the bottom to verify that the procedure worked correctly.
Pre-key change: Disabling PKA services for all images in the sysplex
Before changing the ASYM-MK, you must disable the PKA services and all PKDS access
within the sysplex:
1. Go to the Integrated Cryptographic Service Facility (ICSF) main panel, as shown in
Figure D-1 on page 895.
Appendix D. Asymmetric and Symmetric Master Key change procedures 895
Figure D-1 ICSF panel
2. On the main ICSF panel, type option 4 ADMINCNTL. Press Enter. This option takes you
to the panel that is shown in Figure D-2.
3. Select the following services by typing d to the left of them to disable them. Refer to
Figure D-2:
PKA Callable Services
PKDS Read Access
PKDS Write, Create, and Delete Access
A status message is displayed in the upper-right corner of the panel indicating whether the
services have been stopped.
Figure D-2 ICSF Administrative Control Functions panel
4. Return to the beginning of this section Pre-key change: Disabling PKA services for all
images in the sysplex on page 894, and execute these instructions on all logical partitions
(LPARs) in the sysplex.
OPTION ===> 4


FUNCTION STATUS
-------- ------
Dynamic CKDS Access ENABLED
*******************************Bottom of data ********************************
Key change: First LPAR in the sysplex
The process for changing Master Keys in a sysplex differs on the first LPAR from the process
for the subsequent LPARs in the sysplex. On the first LPAR, the key parts are generated and
the PKDS is re-enciphered. On all subsequent LPARs in the sysplex, the Master Keys are
simply set and the newly re-enciphered PKDS is activated.
Generating ASYM-MK key parts
Follow these steps to generate ASM-MK key parts:
1. On the main ICSF panel, as shown in Figure D-3, type option 5 UTILITY. Press Enter.
Figure D-3 ICSF panel
2. Type option 3 RANDOM to access the Random Number Generator panel (Figure D-4).
Press Enter.
Figure D-4 ICSF Utilities panel
3. Type RANDOM as the parity of the number that you are generating. Asymmetric keys can
have either EVEN or ODD parity. Press Enter. See Figure D-5 on page 897.
OPTION ===> 5

------------------------------ ICSF - Utilities -------------------------------
OPTION ===> 3
1 ENCODE - Encode Data
2 DECODE - Decode Data
3 RANDOM - Generate a random number
4 CHECKSUM - Generate a checksum and verification and
hash pattern
5 PPKEYS - Generate master key values from a pass phrase


Figure D-5 ICSF Random Number Generator panel
4. Press F3 to return, and then, type option 4 CHECKSUM (see Figure D-6). Press Enter.
----------------------- ICSF - Random Number Generator ------------------------
COMMAND ===>

Enter data below.

Parity option ===> RANDOM ODD, EVEN, RANDOM
Random Number1 : 23A836458CE01957 Random Number 1
Random Number2 : 3E1C3987AC763980 Random Number 2
Random Number3 : D5E3733972057A19 Random Number 3


------------------------------ ICSF - Utilities -------------------------------
OPTION ===> 4
hash pattern


5. Type PKAMSTR for the key type (Figure D-7). Press Enter.
Figure D-7 ICSF Checksum and Verification and Hash Pattern panel
6. Copy the entire panel as text into a Notepad document and save it on the USB device, as
shown in Figure D-8. The USB device has a folder for each sysplex. Be sure that the key
part is saved in the correct folder. You must use this naming convention for the file:
ASYM-MK.<SYSPLEX>.D<YYMMDD>.<KEYPART>.txt
<KEYPART> can be one of FIRST, MIDDLEx, or FINAL.
Figure D-8 Copying the panel text
--------------- ICSF - Checksum and Verification and Hash Pattern ---------------
OPTION ===>
Enter data below:
Key Type ===> PKAMSTR (Selection panel displayed if blank)

Key Value ===> 2E48D75FF03BF357 Input key value 0 - 7
===> 3E1C0B0D7DAC7443 Input key value 8 - 15
===> D5BA722FE0F99296 Input key value 16 - 23 (PKA Keys only)
Checksum : BC Check digit for key value
Key Part VP : Verification Pattern
Key Part HP : A3AC4D3428D8A6D7 Hash Pattern
: 6C0C471D55B8E123

Entering the ASYM-MK key parts
Follow these steps to enter the key parts:
1. Return two panels back (F3 two times) from this menu, and type
option 1 COPROCESSOR MGMT (Figure D-9). Press Enter.
Figure D-9 ICSF main panel
2. As shown in Figure D-10, select the coprocessors on which to set the Master Key by
typing e to the left of the coprocessor name. You must select any coprocessor that has a
prefix of E or X (for example X01) here. Press Enter.
Figure D-10 ICSF Coprocessor Management panel
3. In Figure D-11 on page 900, type ASYM-MK, one of FIRST, MIDDLE, or FINAL depending on
which key part you are entering, the checksum, and the key value that was just generated.
Note that the Asymmetric-keys master register is empty. Press Enter, and you see a status
message in the upper-right corner indicating that the key part has been loaded. Check to
be sure that the Hash Pattern (HP) is the same as what you recorded earlier.
More information: There is no Verification Pattern for the asymmetric key part. For your
convenience, this key part file must remain open until it has been entered into ICSF.
OPTION ===> 1

-------- ------------- ------
e X00 77712345 ACTIVE
e X01 77712346 ACTIVE
e X02 77712347 ACTIVE
e X03 77712348 ACTIVE
*******************************Bottom of data ********************************
Figure D-11 ICSF Clear Master Key Entry panel
4. Go back to the beginning of this section. Generate ASYM-MK key parts and execute the
same instructions for each key part. For the previous step, type either MIDDLE or FINAL for
the key part as appropriate. Ensure that the FINAL key part is indeed entered last. Also,
be sure that you record the order in which the keys have been entered so that they can be
reentered when recovering the Master Keys in Disaster Recovery or if the device has been
tampered with.
Reenciphering the PKDS under the new asymmetric-keys master keys
Follow these steps to reencipher:
1. On the main ICSF panel, type option 2 Master Key, as shown in Figure D-12. Press Enter.
Figure D-12 ICSF Main Panel
COMMAND ===>
Symmetric-keys new master key register : FULL
Checksum ===> BC
Key Value ===> 2E48D75FF03BF357
===> 3E1C0B0D7DAC7443
===> D5BA722FE0F99296 (ASYM-MK only)

OPTION ===> 2
2. Type option 6 REENCIPHER PKDS, as shown in Figure D-13. Press Enter.
Figure D-13 ICSF Master Key Management panel
3. Type the current and new data set names for the PKDS, as shown in Figure D-14. Note
that for convenience, the PKDS data set name has the date that the reencipher happened.
Press Enter.
Figure D-14 ICSF Reencipher PKDS panel
OPTION ===> 6

--------------------------- ICSF - Reencipher PKDS ----------------------------
COMMAND ===>
To reencipher all PKDS entries from encryption under the old signature/
asymmetric-keys master key to encryption under the current master key
enter the PKDS name below.
Input PKDS ===> 'MYSYS.CSF.CSFPKDS'
Output PKDS ===> 'MYSYS.CSF.TESTPLEX.D060920.CSFPKDS'

Press ENTER to reencipher the PKDS.
Activating the PKDS
Follow these steps to activate the PKDS:
1. Return to the previous panel, and type option 7 ACTIVATE PKDS. See Figure D-15.
Press Enter.
2. Note that the New PKDS that was specified in the previous panel displays here. If it does
not, type it now as shown in Figure D-16. Press Enter.
Figure D-16 ICSF Activate PKA Cryptographic Key Data Set panel
Key change: Subsequent LPARs in the sysplex
These instructions assume that a new ASYM-MK has already been generated and that the
new PKDS has already been re-enciphered.
OPTION ===> 7

------------ ICSF - Activate PKA Cryptographic Key Data Set -----------------------
Command =====>
New PKDS =====> 'MYSYS.CSF.TESTPLEX.D060920.CSFPKDS'
Pree END to exit to the previous menu.
Entering the ASYM-MK key parts
Follow these steps to enter the key parts:
1. On the main ICSF panel, type option 1 COPROCESSOR MGMT, as shown in
Figure D-17. Press Enter.
Figure D-17 ICSF Main panel
2. Select the processors on which to set the Master Key by typing e to the left of the
coprocessor, as shown in Figure D-18. Press Enter.
OPTION ===> 1
-------- ------------- ------
e X00 77712345 ACTIVE
e X01 77712346 ACTIVE
e X02 77712347 ACTIVE
e X03 77712348 ACTIVE
*******************************Bottom of data ********************************
3. Open the document that resides on the USB device, which corresponds to the correct key
part, as shown in Figure D-19.
Figure D-19 Working with the previously stored document on the USB device
4. In this panel, type ASYM-MK, Part (FIRST, MIDDLE, or FINAL), the Checksum, and the Key
Value (see Figure D-20). 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 you recorded earlier.
Figure D-20 ICSF Clear Master Key panel
COMMAND ===>
Checksum ===> BC
Key Value ===> 2E48D75FF03BF357
===> 3E1C0B0D7DAC7443
===> D5BA722FE0F99296 (ASYM-MK only)


5. Go back to the beginning of this section. Enter the ASYM-MK key parts and execute the
same instructions for each key part. For the previous step, enter either MIDDLE or FINAL for
the key part, as appropriate. Ensure that the FINAL key part is indeed entered last.
Activating the new PKDS
After all key parts have been entered, continue to activate the new PKDS:
1. On the ICSF Main panel, type option 2 MASTER KEY, as shown in Figure D-21. Press
Enter.
Figure D-21 ICSF Main Panel
2. Type option 7 ACTIVATE PKDS to activate the new PKDS. See Figure D-22. Press Enter.
OPTION ===> 2
OPTION ===> 7

3. Enter the new PKDS data set, as shown in Figure D-23.
Figure D-23 ICSF Activate PKA Cryptographic Key Data Set panel
Post-key change: All LPARs in the sysplex
You must complete this set of instructions on all LPARs in the sysplex after the PKDS has
been activated on all LPARs.
Changing installation options to reflect the new PKDS
Perform these steps to change the installation options:
1. Go to the ISPF Primary Options Menu panel and type option 3 Utilities, as shown in
Figure D-24 ISPF Primary Options Menu panel
------------ ICSF - Activate PKA Cryptographic Key Data Set -----------------------
Command =====>
New PKDS =====> 'MYSYS.CSF.TESTPLEX.D060920.CSFPKDS'
Pree END to exit to the previous menu.
OPTION ==> 3
6 TSO ! 5 Batch !
! 8 LM Facility !
! 9 IBM Products !
! 10 SCLM !
'---------------------------'
*****************************
8 9 10 11 12
2. Type option 4 for the Dslist Utility, and press Enter. See Figure D-25.
Figure D-25 Utility Selection panel
3. Enter the data set name (Dsname Level), in our example, SYS1.TEST.PARMLIB, on the Data
Set List Utility panel, as shown in Figure D-26.
Figure D-26 Data Set List Utility panel
Menu Help
______________________________________________________________________________

Option ===> 4
______________________________________________________________________________
More: +

Dsname Level . . . SYS1.TEST.PARMLIB
Volume serial . .


Option ===> 4
4. Select the ICSF Installation Options data set by typing E (edit) option, as shown in
Figure D-27.
Figure D-27 Selecting the ICSF Installation Options data set
5. Select the correct CSFPRMxx PARMLIB member, and press Enter.
6. Change the name of the PKDS in the Installation Options Data Set, as shown in
Figure D-28.
Figure D-28 Editing the PARMLIB member
7. Save the PARMLIB member.
______________________________________________________________________________
DSLIST - Data Sets Matching SYS1.TEST.PARMLIB Row 1 of 1

-------------------------------------------------------------------------------
E SYS1.TEST.PARMLIB TSOE01

****************************** Top of Data ****************************
/* */
/* */
/* 5694-A01 */
/* */
/* */
/* */
CKDSN(MYSYS.CSF.TESTPLEX.D060920.CSFCKDS)
PKDSN(MYSYS.CSF.TESTPLEX.D060920.CSFPKDS)
COMPAT(NO)
SSM(NO)
KEYAUTH(NO)
CKTAUTH(NO)
TRACEENTRY(1000)
USERPARM(USERPARM)
COMPENC(DES)
REASONCODES(ICSF)
PKDSCACHE(64)
Enabling PKA services and PKDS read/write access
Perform these steps to enable services and access:
1. Return to the main ICSF panel, and type option 4 ADMINCNTL on the ISCF Main menu,
as shown in Figure D-29. Press Enter.
Figure D-29 ISCF main menu
2. Select the services to enable, and press Enter, as shown in Figure D-30. A message is
displayed in the upper-right corner indicating whether the changes were successful.
Verifying the key change
Now that the ASYM-MKs have been changed on all logical partitions (LPARs), you must run a
sample application, which uses keys that are protected by the ASYM-MK:
1. Run a sample job, which demonstrates that keys are again accessible.
2. Return to Post-key change: All LPARs in the sysplex on page 906 and repeat for each
LPAR in the sysplex.
OPTION ===> 4

Active CKDS: MYSYS.CSF.TESTPLEX.CSFCKDS
Active PKDS: MYSYS.CSF.TESTPLEX.CSFPKDS

FUNCTION STATUS
-------- ------
Dynamic CKDS Access ENABLED
e PKA Callable Services DISABLED
e PKDS Read Access DISABLED
e PKDS Write, Create, and Delete Access DISABLED
*******************************Bottom of data ********************************
Post key change: Backing up the key part
After you have changed the ASYM-MK, you must back up the key parts to the secondary USB
device. This is labeled <INSERT LABEL CONVENTION>.
Perform these steps to back up the key parts:
1. Connect both the primary USB device and the backup USB device to the computer. This
opens a Windows Explorer window for both devices as they are detected.
2. In our procedure, we created a folder for each sysplex, for example, TGTPLEX on the
primary USB device. From the primary USB device window, copy the new folders from the
primary USB device to the backup USB device.
ICSF tips
In this section, we summarize a few hints and tips for ICSF.
Creating a PKDS VSAM data set
Example D-1 lists the sample JCL to create a PKDS VSAM cluster. You must change the
items that are noted in bold in Example D-1 before attempting to execute the JCL:
You must change the job card parameters to reflect your practices.
Change <SYSPLEX> to the sysplex name.
Change <YYMMDD> to the date that the key change ceremony will occur.
Change VOLUME(XXXXXX) to the volume where the PKDS must reside.
Example D-1 Sample JCL to create a PKDS VSAM cluster
//CSFPKDS JOB job card parameters
//*********************************************************************
//* Licensed Materials - Property of IBM *
//* 5694-A01 *
//* (C) Copyright IBM Corp. 2002,2003 *
//* *
//* THIS JCL DEFINES A VSAM PKDS TO USE FOR ICSF *
//* *
//* CAUTION: This is neither a JCL procedure nor a complete JOB. *
//* Before using this JOB step, you will have to make the following *
//* modifications: *
//* *
//* 1) Add the job parameters to meet your system requirements. *
//* 2) Be sure to change CSF to the appropriate HLQ if you choose *
//* not to use the default. *
//* 3) Change xxxxxx to the volid where you want your PKDS to *
//* reside. The PKDS needs to be on a permanently resident *
//* volume. *
//* *
//*********************************************************************
//DEFINE EXEC PGM=IDCAMS,REGION=4M
//SYSIN DD *
DEFINE CLUSTER (NAME(<SYSID>.CSF.<SYSPLEX>.D<YYMMDD>.CSFPKDS) -
VOLUME(xxxxxx) -
RECORDS(100,50) -
RECORDSIZE(350,2800) -
KEYS (72 0) -
FREESPACE(0,0) -
SHAREOPTIONS(2,3) -
UNIQUE) -
DATA (NAME(<SYSID>.CSF.<SYSPLEX>-D<YYMMDD>.CSFPKDS.DATA -
BUFFERSPACE(100000) -
ERASE -
CISZ(8192) -
WRITECHECK) -
INDEX (NAME(<SYSID>.CSF.<SYSPLEX>-D<YYMMDD>.CSFPKDS.INDEX))
This checklist gives you an overview of the process for changing the ASYM-MK:
1. Create a new PDKS.
2. All required people are available and have retrieved their key part device (USB device or
paper).
3. Perform this task to all images in the sysplex before continuing:
Disable PKA services and PKDS read/write access.
4. Perform these steps only on the first image in the sysplex:
a. Generate the ASYM-MK key part.
b. Record the ASYM-MK key part.
c. Enter the ASYM-MK key part.
5. Perform these steps only on the first image in the sysplex:
a. Reencipher the PKDS under the new asymmetric-keys Master Keys.
b. Activate the PKDS.
c. Change the Installation Options data set to reflect the new PKDS.
6. Perform these steps on all subsequent LPARs in the sysplex:
a. Enter the ASYM-MK key parts: This step requires all key part owners.
b. Activate the new PKDS: This step requires only one person.
7. Perform these steps for each member of the sysplex after all ASYM-MK keys have been
set:
a. Enable the PKA services.
b. Enable the PKDS read/write access.
c. Verify that cryptographic services work correctly.
This step requires only one administrator.
Symmetric Master Key change ceremony
This section outlines the steps for changing the Symmetric Master Key (SYM-MK), which is
also known as the Data Encryption Standard (DES) Master Key. Error handling procedures
are out of the scope of this section. If an error occurs, return to the start of the section and
start over.
Important: Changing parameters other than those parameters that are marked in bold in
this job can cause unpredictable results with ICSF. Make any other changes at your own
risk.
Prerequisites
The following list outlines the actions that must be completed prior to beginning a key change
ceremony:
1. Determine the date that the ceremony will take place. This date is required for naming the
Cryptographic Key Data Set (CKDS), as well as for uniquely identifying the correct key
parts.
2. You must create a CKDS prior to the key change ceremony. You must create the CKDS
with the following naming convention:
CKDS: <SYSID>.CSF.<SYSPLEX>.D<YYMMDD>.CSFCKDS
3. You must obtain the devices, which will hold the key parts, prior to starting the key change
ceremony.
Testing the encryption and decryption
This section is optional, but we encourage you to complete these steps. This procedure
proves that the data keys can be correctly accessed from the CKDS and that data can be
encrypted and decrypted before attempting to change the SYM-MK key. This procedure also
provides data to verify that the data keys that are protected by the SYM-MK key are available
after the SYM-MK key has been changed. You must perform this procedure one time for each
sysplex:
1. On the main ISPF panel, enter option 6.
2. From this panel, enter the EX DATA.SET.NAME(MEMBER) command.
3. Return to the main ISPF panel (F3) and enter MVS.
4. On the MVS panel, enter SDSF.
5. On the SDSF panel, enter ST.
6. Select the job that was just executed by typing S next to it. It is called <JOBNAME>.
7. Scroll to the bottom to verify that the procedure worked correctly.
Disabling dynamic CKDS updates for all images in the sysplex
The first step is to disable dynamic CKDS updates on every image in the sysplex. This action
ensures that the CKDS does not become out of sync between images in the sysplex. You
must perform this step on each image of the sysplex before changing the Master Keys.
Follow these steps:
1. Go to the ICSF main panel and type option 4 ADMINCNTL, as shown in Figure D-31.
Press Enter.
2. Disable Dynamic CKDS Access by selecting it with a d. Press Enter. See Figure D-32.
Key change: First LPAR in the sysplex
The process for changing Master Keys in a sysplex is not the same process on the first LPAR
as the process that is used on subsequent LPARs in the sysplex. On the first LPAR, the key
parts are generated and the CKDS is re-enciphered. On all subsequent LPARs in the sysplex,
the Master Keys are simply set and the newly re-enciphered CKDS is read into memory.
OPTION ===> 4


FUNCTION STATUS
-------- ------
d Dynamic CKDS Access ENABLED
*******************************Bottom of data ********************************
Generating SYM-MK key parts
Perform these steps to generate the SYM-MK key parts:
1. On the main ICSF panel, type option 5 UTILITY, as shown in Figure D-33. Press Enter.

Figure D-33 ICSF main menu
2. Type option 3 RANDOM to access the Random Number Generator panel; see
OPTION ===> 5

------------------------------ ICSF - Utilities -------------------------------
OPTION ===> 3
hash pattern


3. In the panel that is shown in Figure D-35, choose ODD as the parity of the number that you
are generating. ICSF only accepts odd parity numbers for SYM-MK key parts. Press Enter.
Figure D-35 ICSF Random Number Generator panel
4. Return with F3 to the panel that is shown in Figure D-36, and type
option 4 CHECKSUM. Press Enter.
----------------------- ICSF - Random Number Generator ------------------------
COMMAND ===>

Enter data below.

Parity option ===> ODD ODD, EVEN, RANDOM
Random Number1 : 024357CD6E20573B Random Number 1
Random Number2 : 5ED68A97E5DF9234 Random Number 2
Random Number3 : AB43E0E5F797795B Random Number 3


------------------------------ ICSF - Utilities -------------------------------
OPTION ===> 4
3 RANDOM - Generate a random numberol Functions
hash pattern

5. Because we know that we are generating Master Key parts, type MASTER in the panel that
is shown in Figure D-37. This panel generates the new key part. Press Enter.
Figure D-37 ICSF Checksum and Verification and Hash Pattern panel
--------------- ICSF - Checksum and Verification and Hash Pattern ---------------
OPTION ===>
Enter data below:
Key Type ===> MASTER (Selection panel displayed if blank)

Key Value ===> 024357CD6E20573B Input key value 0 - 7
===> 5ED68A97E5DF9234 Input key value 8 - 15
===> 0000000000000000 Input key value 16 - 23 (PKA Keys only)
Checksum : B7 Check digit for key value
Key Part VP : B01E7C6CCC40D9F2 Verification Pattern
Key Part HP : 597846226F3A612F Hash Pattern
: 60952D2A50A45A15

6. Copy the entire panel as text into a Notepad document, and save it on the USB device
(see Figure D-38). The USB device has a folder for each sysplex. Be sure that the key part
is saved in the correct folder. Use this naming convention for the file:
SYM-MK.<SYSPLEX>.D<YYMMDD>.<KEYPART>.txt
<KEYPART> can be one of FIRST, MIDDLEx, or FINAL.
Figure D-38 Saving the data to the USB device
Tip: For your convenience, this key part file must remain open until it has been entered into
ICSF.
Entering SYM-MK key parts
Perform these steps to enter SYM-MK key parts:
1. From the panel that is shown in Figure D-37 on page 916, return two panels back (F3
twice) to the panel in Figure D-39. Type option 1 COPROCESSOR MGMT. Press Enter.
2. Select the processors to set the Master Key on with the E option (see Figure D-40). You
must select any coprocessor with an action prefix of E or X. Press Enter.
OPTION ===> 1

-------- ------------- ------
e X00 77712345 ACTIVE
e X01 77712346 ACTIVE
e X02 77712347 ACTIVE
e X03 77712348 ACTIVE
*******************************Bottom of data ********************************
3. In this panel, type SYM-MK, FIRST, the checksum, and the key value that was just generated.
Note that the key registers in Figure D-41 are both empty.
Press Enter and you see a status message in the upper-right corner indicating that the key
part has been loaded. Check to be sure that the Verification Pattern (VP) and Hash
Pattern (HP) are the same as what you recorded earlier.
4. Go back to the beginning of this section. Generate SYM-MK key parts and repeat the
same process for each key part. For the previous step, enter either MIDDLE or FINAL for the
key part as appropriate. Ensure the FINAL key part is indeed entered last.
Reenciphering the CKDS under the new SYM-MK
Perform these steps to reencipher the CKDS:
1. Now that we have generated the new key parts, we can proceed to reenciphering the
CKDS.
COMMAND ===>
Checksum ===> B7
Key Value ===> 023457CD6E20573B
===> 5ED68A97E5DF9234
===> 0000000000000000 (ASYM-MK only)


Type option 2 Master Key on the main ICSF menu, as shown in Figure D-42. Press Enter.
2. Type option 3 REENCIPHER CKDS on the ICSF Master Key Management panel, as
shown in Figure D-43. Press Enter.
Figure D-43 Master Key Management panel
OPTION ===> 2

OPTION ===> 3

3. In the panel that is shown in Figure D-44, specify the name of the existing CKDS and the
name of the CKDS that will replace it. For convenience, a date stamp has been added to
this data set, so that the date when the SYM-MK was changed last will be obvious to
those people who maintain it.
.
Figure D-44 ICSF Reencipher CKDS panel
The message REENCIPHER SUCCESSFUL is displayed in the upper-right part of the panel if
the reencipher succeeds.
Changing the new SYM-MK and activating the re-enciphered CKDS
Perform these steps to change the new SYM-MK and activate the re-enciphered CKDS:
1. On the panel that is shown in Figure D-44, return from the previous panel by pressing F3.
Type option 4 CHANGE MK, as shown in Figure D-45. Press Enter.
--------------------------- ICSF - Reencipher CKDS ----------------------------
COMMAND ===>
To reencipher all CKDS entries from encryption under the old signature/
asymmetric-keys master key to encryption under the current master key
enter the PKDS name below.
Input PKDS ===> 'MYSYS.CSF.CSFCKDS'
Output PKDS ===> 'MYSYS.CSF.TESTPLEX.D060920.CSFCKDS'

Press ENTER to reencipher the CKDS.

OPTION ===> 4

2. In Figure D-46, you must type the New CKDS, which was specified in Figure D-44 on
page 921. If not, fill in the CKDS data set name, and press Enter.
Figure D-46 ICSF Change Master Key panel
After changing the Master Key, a message is displayed in the upper-right corner indicating
whether the Master Key was changed.
Key change: Subsequent LPARs in the sysplex
These instructions assume that a new SYM-MK has already been generated and that the new
CKDS has already been re-enciphered.
Entering SYM-MK key parts
Perform these steps to enter key parts:
1. On the main ICSF panel, type option 1 COPROCESSOR MGMT, as shown in Figure D-47.
Press Enter.
------------------------- ICSF - Change Master Key ----------------------------
Command =====>
Enter the name of the new CKDS below.
New CKDS =====> 'MYSYS.CSF.TESTPLEX.D060920.CSFCKDS'
When the master key is changed, the new CKDS will become active.
Press ENTER to activate the CKDS.
OPTION ===> 1

2. Select the coprocessors to set the Master Key on with the E option (see Figure D-48).
Press Enter.
3. Open the document residing on the USB device, which corresponds to the correct key
part; see Figure D-49.
Figure D-49 Opening the document on the USB device
-------- ------------- ------
e X00 77712345 ACTIVE
e X01 77712346 ACTIVE
e X02 77712347 ACTIVE
e X03 77712348 ACTIVE
*******************************Bottom of data ********************************
4. In the panel that is shown in Figure D-50, type SYM-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 that the
key part has been loaded. Check to be sure that the Verification Pattern (VP) and Hash
Pattern (HP) are the same as what you recorded earlier.
5. Go back to the beginning of this section to Entering SYM-MK key parts on page 918 and
execute the same instructions for each key part. For step 4, enter either MIDDLE or FINAL
for the key part, as appropriate. Ensure the FINAL key part is indeed entered last.
Activate the new Master Key
After all key parts have been entered, continue to activate the Master Key on this LPAR:
1. On the main ICSF panel, enter option 2 Master Key; see Figure D-51.
COMMAND ===>
Checksum ===> B7
Key Value ===> 023457CD6E20573B
===> 5ED68A97E5DF9234
===> 0000000000000000 (ASYM-MK only)


OPTION ===> 2

2. Enter option 4 CHANGE MK to change the Master Key, as shown in Figure D-52.
This panel displays a message in the upper-right corner indicating whether the change
was successful. If it was successful, proceed to the next LPAR in the sysplex or to the
Post-key change section.
Post-key change: All LPARs in the sysplex
You must complete this set of instructions on all LPARs in the sysplex after the PKDS has
been activated on all LPARs.
Changing the installation options to reflect the new CKDS
Perform these steps to change the installation options to reflect the new CKDS:
OPTION ===> 4

1. Go to the ISPF Primary Options Menu panel, and type option 3 Utilities, as shown in
Figure D-53 ISPF Primary Options Menu panel
2. Type 4 for the Dslist utility; see Figure D-54. Press Enter.
OPTION ==> 3
6 TSO ! 5 Batch !
! 8 LM Facility !
! 9 IBM Products !
! 10 SCLM !
'---------------------------'
*****************************
8 9 10 11 12
Menu Help
______________________________________________________________________________

Option ===> 4
3. Type the data set name (Dsname Level) SYS1.TEST.PARMLIB, as shown in Figure D-55.
Press Enter.
Figure D-55 Data Set List Utility panel
4. In the panel in Figure D-56, select the ICSF Installation Options data set by using the E
(edit) option. Press Enter.
Figure D-56 DSLIST panel
______________________________________________________________________________
More: +

Dsname Level . . . SYS1.TEST.PARMLIB
Volume serial . .


Option ===> 4
______________________________________________________________________________
DSLIST - Data Sets Matching MYSYS.TST.TEXTPLEX Row 1 of 1

-------------------------------------------------------------------------------
e SYS1.TEST.PARMLIB TSOE11
****************************** End of Data Set list ****************************

5. Select the correct CSFPRMxx PARMLIB member, and change the name of the CKDS in
the Installation Options Data Set, as shown in Figure D-57. Press Enter.
Figure D-57 Updating the CSFPRMxx PARMLIB member
Enabling Dynamic CKDS updates
The final step for the CKDS processing is to enable the Dynamic CKDS Access:
1. On the main ICSF panel, type option 4 ADMINCNTL, as shown in Figure D-58. Press
Enter.
/ /
/* */
/* 5694-A01 */
/* */
/* */
/* */
CKDSN(MYSYS.CSF.TESTPLEX.D060920.CSFCKDS)
PKDSN(MYSYS.CSF.TESTPLEX.D060920.CSFPKDS)
COMPAT(NO)
SSM(NO)
KEYAUTH(NO)
CKTAUTH(NO)
TRACEENTRY(1000)
USERPARM(USERPARM)
COMPENC(DES)
REASONCODES(ICSF)
PKDSCACHE(64)
OPTION ===> 4

2. Enable Dynamic CKDS Access by selecting it with an E, as shown in Figure D-59. Press
Enter.
Verifying the key change
Now that the SYM-MK have been changed on all LPARs, you must run a sample application,
which uses keys that are protected by the SYM-MK:
1. Run the sample job, which demonstrates keys are again accessible.
2. Return to Post-key change: All LPARs in the sysplex on page 906, and repeat this
verification for each LPAR in the sysplex.
Post-key change
After the SYM-MK has been changed, you must back up the key parts according to your
companys rules and standards. You can choose to use a USB device to store the key parts.
Perform these steps to back up the key parts:
1. Connect both the primary USB device and the backup USB devices to the computer,
which opens a Windows Explorer window for both devices as they are detected.
2. In our procedure, we created a folder for each sysplex, for example, TGTPLEX, on the
primary USB device. From the primary USB device window, copy the new folders from the
primary USB device to the backup USB device.
3. Repeat this process for each folder, so that all new key parts are copied to the backup
device.
Active CKDS: MYSYS.CSF.TESTPLEX.D060920.CSFCKDS
Active PKDS: MYSYS.CSF.TESTPLEX.D060920.CSFPKDS

FUNCTION STATUS
-------- ------
e Dynamic CKDS Access DISABLED
PKA Callable Services ENABLED
PKDS Read Access ENABLED
PKDS Write, Create, and Delete Access ENABLED
*******************************Bottom of data ********************************
Appendix E. z/OS tape data encryption
diagnostics
This appendix is intended to assist you in problem determination if you encounter a tape data
encryption error. We describe error diagnostic scenarios and error codes.
E
EKM problem determination when running z/OS
When running the Encryption Key Manager (EKM) on z/OS, you can look for errors in three
places:
EKM audit log
Most error messages appear in the audit log. The location and file name are set in the
KeyManagerConfig.properties EKM configuration file in the Audit.handler.file.directory
and Audit.handler.file.name properties.
Standard error (stderr)
When running EKM as a started task using the EKM console wrappers, examine the
Execution log for errors. When running EKM in the foreground using UNIX System
Services/OMVS, these errors appear where you have directed STDERR, which can
simply be the window.
EKM debug log
The location is set in the KeyManagerConfig.properties EKM configuration file
debug.output.file property, and the data written to the file is controlled by the debug
property. For space reasons, we recommend that you initially set the property to
debug=none. If an error is encountered while EKM is running, you can turn debug on by
submitting the modconfig set property debug value all command. If you have run
into a problem and did not get any debug information from the EKM audit log or Standard
Error, set debug=all.
Error scenarios
We list the errors that you might see when running EKM on z/OS and possible causes:
Error one
com.ibm.keymanager.j [Caused by java.security.PrivilegedActionException:
java.io.IOException: The private key of EKMSERVE is not a software or icsf key.
Error creating key entry because private key is not available.]
Possible causes
If you use a RACF keystore type (that is, JCE4758RACFKS or JCERACFKS), this error can
occur:
If the user ID running EKM is not the owner of the keyring/private key. RACF only allows a
private key to be retrieved by its owner.
When starting EKM if your keyring has a public key (that does not contain a corresponding
private key, such as a business partners key) and that key was not connected as
CERTAUTH.
Error two
Runtime event:[ timestamp=Wed Sep 06 13:30:54 EDT 2006 event
source=com.ibm.keymanager.g.fb outcome=[result=unsuccessful]event
type=SECURITY_RUNTIME message= ***Error: Information not available for protected
private keys.. ErrorCode=0xEE0F resource=[name= Drive Serial Number: 000001350808
WWN: 500507630F04BC1B Key Alias/Label[0]:
Tape_Sol_Tst_Shr_Pvt_1024_Lbl_02;type=file] action=stop
Appendix E. z/OS tape data encryption diagnostics 933
Possible cause
This error can occur if unrestricted policy files were not installed. To check and correct this
situation, regardless of which IBM Software Developer Kit (SDK) version that 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 EKM to serve Advanced Encryption Standard (AES)
keys.
The preferred method to install the unrestricted policy files on z/OS is to copy the unrestricted
policy files that are shipped in the z/OS Java Software Developer Kit (SDK) build under the
jce demo directory. You only have to copy them to the lib/security directory using the
following command:
cp /usr/lpp/java/J1.4/demo/jce/policy-files/unrestricted/*
/usr/lpp/java/J1.4/lib/security
Alternatively, you can download the unrestricted policy files from the following website:
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, which is incompatible.
This error usually is displayed in the EKM audit log.
Error three
# java.lang.NoClassDefFoundError: javax/crypto/b at javax.crypto.Cipher.a(Unknown
Source)
at javax.crypto.Cipher.getInstance(Unknown Source)
at com.ibm.keymanager.g.b.a(b.java:189)
at com.ibm.keymanager.g.fb.a(fb.java:937)
at com.ibm.keymanager.g.fb.run(fb.java:1277)
Possible cause
The wrong version, or a corrupt copy, of unrestricted policy files might be installed. Note that
this error is sent to STDERR (your job execution log) and not the EKM audit log.
Error four
***Error: no such provider: IBMJCE4758. ErrorCode=0xEE0F
Runtime event:[
timestamp=Mon Sep 18 22:43:26 EDT 2006 event
source=com.ibm.keymanager.logic.MessageProcessor outcome=[result=unsuccessful]
event type=SECURITY_RUNTIME message= ***Error: no such provider: IBMJCE4758.
ErrorCode=0xEE0F resource=[name= Drive Serial Number: 000001350699 WWN:
500507630F0C851C;type=file] action=stop ]
Possible cause
The Java hardware provider has not been added to the java.security provider list. You must
add the provider each time that there is a new Java installation or upgrade if you plan to use
the IBM Integrated Cryptographic Service Facility (ICSF) hardware keys.
If you have decided to use a keystore of either of the following types to make use of the
security advantages of ICSF, you must add the Java hardware provider:
JCE4758KS/JCECCAKS
JCE4758RACFKS/JCECCARACFKS
You might decide that for test purposes, you want to start by using the JCEKS software
keystore, which does not use ICSF and, thus, does not require you to add the Java hardware
provider at this time.
To add the Java hardware provider, edit the $JAVA_HOME/lib/security/java.security file
and add the hardware provider so that it is the second provider in the list, as shown in the
following examples. Be sure to change the security.provider.# so that the providers are
listed in order from 1, 2, 3, and so on.
For SDK 1.4.2, add the IBMJCE4758 provider, as shown in Example E-1.
Example E-1 Add the IBMJCE4758 provider
#
# List of providers and their preference orders (see above):
#
security.provider.4=com.ibm.security.jgss.IBMJGSSProvider
For SDK 5.0 and later, add the IBMJCECCA provider, as shown in Example E-2.
Example E-2 Add the IBMJCECCA provider
#
# List of providers and their preference orders (see above):
# security.provider.1=com.ibm.jsse2.IBMJSSEProvider2
security.provider.2=com.ibm.crypto.hdwrCCA.provider.IBMJCECCA
security.provider.4=com.ibm.security.jgss.IBMJGSSProvider
security.provider.6=com.ibm.security.sasl.IBMSASL
For more detailed information about the Java hardware provider, visit this website:
http://www.ibm.com/servers/eserver/zseries/software/java/jcecca14.html
Error five
java.security.PrivilegedActionException: java.io.IOException: R_datalib (IRRSDL00)
error: error while getting certificate or trust info (8, 8, 80)
Possible cause
Quotation marks surround the keyring name that is specified in the
KeyManagerConfig.properties EKM configuration file (for example, config.keystore.file =
safkeyring://EKMSERV/EKMRing). Remove the quotation marks.
Note: IBMJCECCA is not supported in SDK 1.4.2.
Error six
java.security.PrivilegedActionException: java.io.IOException: Failed validating
certificate paths
at java.security.AccessController.doPrivileged1(Native Method)
at java.security.AccessController.doPrivileged(AccessController.java:351)
at com.ibm.keymanager.b.a.a(a.java:23)
at com.ibm.keymanager.b.a.a(a.java:148)
at com.ibm.keymanager.b.a.b(a.java:138)
at com.ibm.keymanager.i.a.a.h(a.java:711)
at com.ibm.keymanager.i.a.a.c(a.java:595)
at com.ibm.keymanager.KMSAdminCmd.main(KMSAdminCmd.java:2)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
Possible cause
A certificate authority (CA) certificate is not connected to the keyring.
This message might appear only in the debug log and might only occur when you attempt to
start the EKM server.
Error seven
java.lang.NoClassDefFoundError
java.lang.NoClassDefFoundError: com/ibm/keymanager/logic/EncryptionCBDQuery
:at com.ibm.keymanager.logic.RequestEEDKs.createMsg(RequestEEDKs.java:48)
:at com.ibm.keymanager.logic.RequestEEDKs.<init>(RequestEEDKs.java:39)
:at com.ibm.keymanager.logic.MessageProcessor.ProcessMessage(MessageProcessor.java:351)
:at com.ibm.keymanager.logic.MessageProcessor.run(MessageProcessor.java(Compiled Code))
Possible cause
Java is not available. The file system, where Java is installed, might have been demounted.
If using in-band key management, you might also see this I/O supervisor (IOS) error:
IOS628E ENCRYPTION ON DEVICE E0A4 HAS FAILED DUE TO COMMUNICATION TIME OUT IOS000I
E0A4,D6,IOE,01,0E00,,**,A0209A,ITSXZ071 948 804C08C022402751 0301FF0000000000
0000000000000092 2004E82062612111 ENCRYPTION FAILURE CU = 03 DRIVE = 000000 EKM =
000000
Diagnostic scenarios
The following scenarios are targeted toward encryption failures and are meant to assist you in
problem diagnostics. If an error occurs, follow these steps:
1. Determine if an IOS000I message has been issued indicating Encryption Failure.
See Example E-3.
Example E-3 IOS000I message example
IOS000I 0BD0,60,IOE,01,0E00,,**,JJC046,ATNCMP1 031
804C08C022402751 0001FF0000000000 0005EE2500000092 2004E82061BA2111
ENCRYPTION FAILURE
CU=00 DRIVE=000000 EKM=05EE25
Requirement: At least one CERTAUTH certificate is required, even if all certificates are
self-signed.
Perform the following tasks:
a. If Encryption Failure occurred, verify if IOS628E has also been issued. If IOS628E
is issued, make sure the complete text of the IOS628E message and the complete text
of the IOS000I message are included in the problem record (this problem must be
reported to the IOS group - COMPID 5752SC1C3). However, if the IOS628E message
indicates either of the following messages, this problem has to be reported through
IBM Hardware Support:
Encryption Status Not Returned
IO Error
See Example E-4.
Example E-4 IOS628E message example
IOS628E ENCRYPTION ON DEVICE 1DA1 HAS FAILED
DUE TO CONNECTION FAILURE SOCKET ERNO=0467

IOS000I 1DA1,87,IOE,01,0E00,,**,J12523,DDR1A
804C08C022402751 0301FF0000000000 0000000000000092 2004E82000272011
ENCRYPTION FAILURE
CU = 03 DRIVE = 000000 EKM = 000000
b. If Encryption Failure occurred, but there is no IOS628E message, note the following
values:
Non-zero control unit (CU) value:
Verify which CU is associated with the error, then contact Hardware Support.
Provide the complete IOS000I message and also identify the failing hardware so
that Hardware Support can dial in to the machine and gather diagnostic information.
Non-zero drive value:
Verify which drive is associated with the error, and look up the error code that
reported by the drive (Format ID (FID) message: descriptions are included in Drive
error codes on page 940). Determine if the problem can be easily resolved. If it
cannot be resolved, contact Hardware Support. Provide the complete IOS000I
message, as well as information about which hardware has a problem (to allow
Hardware Support to gather information from that hardware).
Non-zero EKM value:
Look up the reported codes for EKM (see Table E-1 on page 938) to determine if
the problem can be easily resolved. If it cannot, report the problem to the Java
Service Group (COMPID - 5648C9800), and provide the key manager audit log and
(if available) the key manager debug log. The Java team will then forward the
information to the Java Security group.
Important: The critical piece of a non-zero EKM error code is the last two bytes. In the
previous example, the critical part is the EE25 value.
Note: If the IOS628E message indicates that a failure occurred connecting to the
key manager (as indicated in Example E-4), refer to additional information in this
book at IOS628E message indicates connection failure on page 942 that pertains
to the failing socket error number.
If more than one non-zero value exists, and if the EKM value is non-zero, follow the
previous non-zero EKM process; otherwise, follow the previous non-zero CU
process.
2. IOS000I message indicates something other than an Encryption Failure; verify which
hardware is associated with the error. The problem must be reported through IBM
Hardware Support. Also, provide the complete IOS000I message output, as well as
identify the failing hardware (so IBM Hardware Support can dial in to the machine and
gather diagnostic information).
See Example E-5 and Example E-6 for sample messages.
Example E-5 IOS000I message example: Long Busy Timeout
IOS000I 0963,86,IOE,03,0E00,,**,L00500,JOBX
4040C0C60120050 0000000000000000 0000000000000000 0000000000000000
DEVICE HAS EXCEEDED LONG BUSY TIMEOUT
Example E-6 IOS000I message example: Equipment Check
IOS000I 0963,86,IOE,03,0E00,,**,L00500,JOBX
000102FF04057007 0000000000000000 0000000000000000 0000000000000000
EQUIPMENT CHECK
Or, a separate failure might be indicated in line 3 of the IOS000I message.
Depending on the failure, Hardware Support might also ask you to re-create the error and
provide a generalized trace facility (GTF) trace with the parameters that are shown in
Example E-7.
Example E-7 Sample GTF TRACE command
TRACE =SIOP,IOP,CCWP,XSCH,CSCH,HSCH
SSCH=IO=(xxxx) (where xxxx = device address)
CCW=(SI,CCWN=1024,DATA=256,IOSB)
3. If an encryption job is stopped, this problem must initially be handled by the IOS service
group (COMPID - 5752SC1C3). The group has to look at the CTRACE records to
determine whether the stopped job is related to the new encryption support (new
CTRACE records are cut in the trace entries for SYSIOS). See Example E-8.
Example E-8 Sample DUMP command
DUMP COMM=(TAPEENC HANG)
04 IEE094D SPECIFY OPERAND(S) FOR DUMP COMMAND
R
04,JOBNAME=(IOSAS),SDATA=(CSA,PSA,SQA,NUC,LSQA,TRT,SUM,SWA,RGN, GRSQ,LPA,NUC)
4. If the failure is none of the above, ensure that the problem is routed to the correct service
area (software or hardware).
Encryption Key Manager error codes and recovery actions
Encryption Key Manager (EKM) error codes and recovery actions are in Table E-1. For more
details, also refer to the IBM System Storage Tape Enterprise Key Manager, Introduction
Planning and User Guide, GA76-0418.
Table E-1 Encryption Key Manager error codes
Note: When looking up the EKM error reported in the IOS000I message EKM=xxyyzz, focus
on the last two bytes yyzz for the EKM error number in Table E-1.
Error number Description Recovery action
EE02 Encryption Read Message
Failure:
DriverErrorNotifyParameterError:
Bad ASC & ASCQ received. ASC
& ASCQ do not match with
either of Key Creation/Key
Translation/Key Acquisition
operation.
The tape drive asked for an unsupported
action. Ensure that you are running the latest
version of EKM. Check the versions of drive
or proxy server firmware, and update them to
the latest release, if necessary. Enable debug
tracing on the key manager server. Try to
re-create the problem, and gather debug logs.
If the problem persists, contact IBM Disk/Tape
SupportLine.
EE0F Encryption logic error: Internal
error: Unexpected error.
Internal programming error in
EKM.
Ensure that you are running the latest version
of EKM. Check the versions of drive or proxy
server firmware, and update them to the latest
release, if necessary. Enable debug tracing
on the key manager server. Try to re-create
the problem, and gather debug logs. If the
problem persists, contact IBM Disk/Tape
SupportLine.
Error: Hardware error from call
CSNDDSV returnCode 12
reasonCode 0.
If using hardware cryptography, ensure that
ICSF is started.
Failure: Internal error:
Unexpected error........
The message received from the drive or proxy
server cannot be parsed because of a general
error. Ensure that you are running the latest
version of EKM. Enable debug on the key
manager server. Try to re-create the problem,
and gather debug logs. If the problem
persists, contact IBM Disk/Tape SupportLine.
EE25 Encryption Configuration
Problem: Errors that are related
to the drive table occurred.
Ensure that the config.drivetable.file.url is
correct in the KeyManagerConfig.properties
EKM configuration file, if that parameter is
supplied. Run the listdrives -drivename
<drivename> command on the EKM server to
verify whether the drive is correctly configured
(for example, the drive serial number, alias,
and certificates are correct). Ensure that you
are running the latest version of EKM. Check
the versions of drive or proxy server firmware,
and update them to the latest release, if
necessary. Enable debug tracing, and retry
the operation. If the problem persists, contact
IBM Disk/Tape SupportLine.
Failure: Invalid signature.
The message received from the drive or proxy
server does not match the signature on it.
of EKM. Enable debug on the key manager
server. Try to re-create the problem, and
gather debug logs. If the problem persists,
contact IBM Disk/Tape SupportLine.
EE2B Encryption Read Message
Failure: Internal error: Either no
signature in DSK or signature
in DSK cannot be verified.
of EKM. Check the versions of drive or proxy
server firmware, and update them to the latest
release, if necessary. Enable debug tracing
SupportLine.
EE2C Encryption Read Message
Failure:
QueryDSKParameterError:
Error parsing a
QueryDSKMessage from a device.
Unexpected dsk count or
unexpected payload.
The tape drive asked EKM to perform an
unsupported function. Ensure that you are
running the latest version of EKM. Check the
versions of drive or proxy server firmware,
and update them to the latest release, if
necessary. Enable debug tracing on the key
EE2D Encryption Read Message
Failure: Invalid Message Type.
EKM received a message out of sequence or
received a message that it does not know how
to handle. Ensure that you are running the
latest version of EKM. Enable debug on the
key manager server. Try to re-create the
problem, and gather debug logs. If the
problem persists, contact IBM Software
Support and ask for SupportLine.
EE2E Encryption Read Message
Failure: Internal error: Invalid
signature type.
The message received from the drive or
proxy server does not have a valid signature
type. Ensure that you are running the latest
version of EKM. Enable debug on the key
Drive error codes
Action plans for drive errors are determined from the format ID or FIDxx messages that are
displayed on the drive panel, reported to the host server, and displayed on the 3584 library
web interface to the drive. The new encryption FIDs are FID5x messages. These FIDs are
documented in the drive machine interface (MI), along with action plans. Table E-2 on
page 941 lists the encryption FIDs.
EE31 Encryption Configuration
Problem: Errors that are related
to the keystore occurred.
Check the key labels that you are trying to use
or that you configured for the defaults. You
can list the certificates that are available to
EKM by using the listcerts command. If you
know that you are trying to use the defaults,
run the listdrives -drivename drivename
command on the EKM server to verify
whether the drive is correctly configured (for
example, the drive serial number and
associated aliases or key labels are correct).
If the drive in question has no aliases or key
labels associated with it, check the values of
default.drive.alias1 and default.drive.alias2. If
this check does not help or the alias/key label
exists, collect debug logs and contact IBM
Disk/Tape SupportLine.
EEE1 Encryption logic error: Internal
error: Unexpected error:
EK/EEDK flags conflict with
subpage.
of EKM. Check the versions of the drive
or proxy server firmware, and update them to
the latest release, if necessary. Enable debug
SupportLine.
EF01 Encryption Configuration
Problem: Drive not
configured.
The drive that is trying to communicate with
EKM is not present in the drive table. Ensure
that the config.drivetable.file.url is correct in
the KeyManagerConfig.properties EKM
configuration file, if that parameter is
supplied. Run the listdrives command to
check whether the drive is in the list. If not,
configure the drive manually by using the
adddrive command with the correct drive
information, or set the
drive.acceptUnknownDrives property to true
using the modconfig command. Enable
debug tracing, and retry the operation. If the
SupportLine.
Table E-2 Drive error codes
Control unit error codes
IBM has enhanced the control unit to report additional errors for encryption failures. See
Table E-3 on page 942.
FID Description Comments
50 Encryption Configuration 100%
Drive Canister
Encryption Configuration installed during manufacturing
is incorrect. Drive canister must be replaced.
51 Encryption Self-Test (POST HW)
100% Drive Canister
Encryption hardware power on self-test (POST) failed.
Drive canister must be replaced.
52 Encryption Self-Test (POST FW) Encryption firmware (FW) power on self-test (POST)
failed.
53 Encryption Self-Test (Invoked)
50% Drive Canister; 50%
Microcode
An explicitly invoked encryption self-test failed.
54 Encryption Self-Test (Automatic)
80% Drive Canister; 20%
Microcode
An automatically invoked encryption diagnostic failed.
55 Encryption Module Failure 80%
Drive Canister; 20% Microcode
An unexpected failure of hardware function occurred.
58 Encryption Error 100% Drive
Canister
An error was detected during the encryption of data.
59 Decryption Error 25% Drive
Canister; 25% Microcode; 25%
EKM; 25% Cartridge
An error was detected during the decryption of data.
5A Encryption Key Manager (EKM)
Failure
An unexpected status was returned by the key
manager. Check library/proxy interface, and check EKM
log. This error is not a drive or microcode problem and
requires investigation by client.
5B Encryption PROXY Failure A failure or timeout occurred on the proxy interface.
Check library/proxy interface, and check EKM log. This
error is not a drive or microcode problem and requires
investigation by client.
5F Security Prohibited Function A function was attempted, which is prohibited because
of the current security settings.
Table E-3 Control unit error codes
IOS628E message indicates connection failure
The IOS628E message can indicate a connection failure, as shown in Example E-9.
Example E-9 Connection failure
IOS628E ENCRYPTION ON DEVICE 0540 HAS FAILED DUE
TO CONNECTION FAILURE SOCKET ERNO=0468
Use this link to obtain the table that has the documented error codes:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/bpxza870/3.0?ACTION=MAT
CHES&REQUEST=0467&TYPE=FUZZY&SHELF=&DT=20060615093634&CASE=&searchTopic=TOPIC&sear
chText=TEXT&searchIndex=INDEX&rank=RANK&ScrollTOP=FIRSTHIT#FIRSTHIT
The z/OS V1R8.0 UNIX System Services Messages and Codes, SA22-7807, manual
includes the table of the error codes.
Error code Description Recovery action
00 Not a control unit-reported failure. Refer to EKM and drive error codes
that are reported in the IOS000I
message for failure information.
01 The key manager was not available for
an out-of-band key exchange.
Verify the key manager that the control
unit is configured for use, and verify the
state of that key manager. However, if
the intent was to use in-band key
management, use the EKM
subcommand of the IECIOSxx
PARMLIB member or the SETIOS
command to specify your key
managers.
02 Timeout for an out-of-band key
exchange.
EKM might have failed mid-sequence,
or there might be a network problem.
Verify the state of the key manager and
the TCP/IP network. However, if the
intent was to use in-band key
management, use the EKM
subcommand of the IECIOSxx
PARMLIB member or the SETIOS
command to specify your key
managers.
03 An in-band key exchange was
canceled by the host.
Check for an IOS628E message for
additional information to learn why the
in-band proxy might have canceled
the key exchange.
Appendix F. IEHINITT exits and messages for
rekeying
This appendix provides additional details about the exits that support the rekeying function in
the IEHINITT program. It also lists new IEHINITT messages that are available with the
rekeying support.
F
Tip: For additional information about IEHINITT REKEY, refer to the appendix in IBM
TS3500 Tape Library with System z Attachment A Practical Guide to Enterprise Tape
Drives and TS3500 Tape Automation, SG24-6789.
Dynamic Exits Service Facility support
IEHINITTs REKEY support provides an interface (through the Dynamic Exits Facility) that
enables notification of a volumes key labels changes to be received through a user exit. This
notification is of particular importance if the key labels that are associated with a volume are
being recorded. As with IEHINITTs Dynamic Exits support, a single exit (REKEY_EXIT) is
predefined to the system, enabling a user-written exit routine to be associated with the
REKEY_EXIT, using the Dynamic Exits Services macro, CSVDYNEX.
To add an exit routing, refer to z/OS MVS Programming: Authorized Assembler Services
Reference, Volume 1 (ALESERV-DYNALLOC), SA22-7609.
With tape labeling (INITT), a single exit, IEHINITT_EXIT, exists. It has two associated exit
points:
Pre-Label exit is invoked just before issuance of the labeling I/O occurs. This exit point
allows the installation to indicate whether labeling of the volume is to occur, and, to a
degree, the values that are to be used in the labeling.
Post-Label exit is invoked just after issuance of the labeling I/O has occurred. This exit
point informs the installation exit routines of the results of the labeling request and
associated Pre-Label exit processing.
The Dynamic Exits support for REKEY is provided in a similar fashion as the INITT
Post-Label exit processing in which the new REKEY_EXIT will be invoked one time, after the
rekey I/O successfully completes. All exit routines associated with this exit will always be
called for each successful rekey. A new indicator is set in the parameter list that is passed to
the exit routines to indicate that the exit is called for REKEY. The key labels listed in
Example F-1 and their associated encoding mechanisms are passed in the parameter list
(IEHUEXIT).
Example F-1 Key labels and their encoding mechanisms
INXKYLB1 Char(64) First key label
INXKYLB2 Char(64) Second key label
INXENCD1 Char(1) Encoding mechanism for the first key label
INXENCD2 Char(1) Encoding mechanism for the second key label
REKEY function code for INXFUNC:
INXREKEY Fixed(8) Constant(3) Exit Routine is called for REKEY
Currently, no requirement exists to return any return or reason codes or any values from the
exit routine. All returned values will be ignored, and a warning message will be issued.
Error conditions
If a failure occurs during rekey I/O processing, no exit routines are called. If the Dynamic Exits
Services fails, no subsequent rekey exit routines are called. Refer to 18.9.2, IEHINITT
enhancements on page 609 for information about the setup, use, and invocation of exits that
are associated with the IEHINITT utility.
Appendix F. IEHINITT exits and messages for rekeying 945
Programming considerations
The following programming considerations apply:
The exit routines are required to be in AMODE 31.
The exit routines run in Key 5, authorized state.
The parameter list that is passed to the exit routines is not fetch-protected and is put in
Key 5 storage. Therefore, the exit routines are given control in Key 5.
Although the service does not enforce reentrancy, we suggest that the exit routine is
reentrant.
Registers on entry
Table F-1 lists registers on entry.
Table F-1 Registers at entry
Registers on exit
No requirement exists to return any values in registers from the exit routines, so restoring any
registers on exit from the exit routine is unnecessary.
Return and reason code values
No requirement exists to return any return and reason code other than the default values of
return code 4 and reason code 0 from the exit routines for rekey Dynamic Exits processing.
However, if any other value is returned by the exit routine, it is ignored, and a warning
message is issued. The following values are the default values:
INXRC Contains the exit routine return code. It will be set to a value of 4 each time
that an exit is called.
INXRSN Contains the exit routine reason code. It will be set to zero.
REKEY messages
This section lists new messages and messages that have been changed for REKEY support.
Register Contents
1 Address of the parameter list, INXPLIST
13 Address of the standard 72-byte save area
a
a. The 72-byte save-area is provided solely for exit routines that expect to be
able to save the registers on entry. Its contents are not used by the Dynamic
Exits Service Facility nor by IEHINITT.
14 Return address of the caller
15 Entry point address of the exit routine
New messages
The following messages are new:
IEH630I REKEY FAILED FOR VOLUME, VOLSER
Explanation: Rekey processing failed for volume VOLSER for various
reasons. Refer to other IEH6xxI and IOSxxxx messages for additional
explanations.
IEH631I ONE KEYLABLX AND KEYENCDX ARE REQUIRED
Explanation: At least one key label and its associated encoding mechanism
are required for REKEY function. If only one key label and its encoding
mechanism are specified, the same values will be used for the other key
label and encoding mechanism.
IEH632I KEYENCDX REQUIRED IF KEYLABLX SPECIFIED
Explanation: If the KEYLABLX key word is specified, its associated
KEYENCDX must also be specified, and vice versa.
IEH633I KEYLABLX REQUIRED IF KEYENCDX SPECIFIED
Explanation: If the KEYENCDX key word is specified, its associated
KEYLABLX must also be specified, and vice versa.
IEH635I INVALID VALUE FOR KEYENCDX KEYWORD EXPECTED L FOR LABEL OR H FOR
HASH
Explanation: Invalid 1-character value specified for the KEYENCDX
keyword. Valid values are L for LABEL and H for HASH.
IEH636I CALL TO DFSMSrmm API ENDED WITH RC=XXX, RSN=XXXX
Explanation: Call to DFSMSrmm API fails for RC=XXX, RSN=XXXX. The
key label information has not been updated in the DFSMSrmm inventory.
IEH637I DEVICE DOES NOT SUPPORT REKEY FEATURE
Explanation: The device does not support the rekeying feature or has a
downlevel version.
IEH638I TAPE IS NOT ENCRYPTED
Explanation: The mounted tape is not encrypted. Rekey processing is
terminated.
IEH639I ERROR ACQUIRING MEDIUM SENSE INFORMATION
Explanation: Error on the medium sense command. Unable to verify
whether the tape is encrypted.
IEH640I KEY LABELS WERE NOT SUCCESSFULLY CHANGED
Explanation: The key labels were not successfully changed.
Modified messages
The following messages have been modified:
IEH621I VOLUME VOLSER, NOT REKEYED, RACF AUTHORIZATION FAILURE
SAF RC: return_code, RACF RC: return_code, REASON CODE:
reason_code.
Explanation: Rekeying processing of a volume failed, because the user did
not have RACF TAPEVOL access to the volume.
Appendix F. IEHINITT exits and messages for rekeying 947
IEH629I CALL TO DYNAMIC EXIT SERVICE CSVDYNEX [FAILED DURING aaaa
PROCESSING] RC = XX, RSN = ZZZZ.
Where XX is SPLDEXRC, the dynamic exit service return code, when the
CSVDYNEX return code is not 0 or 4.
Where ZZZZ is SPLDEXRS, the dynamic exit service reason code, when
CSVDYNEX return code is not 0 or 4.
Explanation: Call to the Dynamic Exits Services CSVDYNEX failed for the
following processing:
Note: aaaa is one of three possibilities:
[FAILED DURING PRE LABEL PROCESSING] Pre-label dynamic exit
processing
[FAILED DURING POST LABEL PROCESSING] Post-label dynamic exit
processing
[FAILED DURING REKEY PROCESSING] Rekeying dynamic exit
processing

Appendix G. Implementing EKM on z/OS
SECURE key processing to
TS1100 and LTO4/LTO5 drives
In this appendix, we describe how to implement an Encryption Key Manager (EKM) on z/OS
to take advantage of cryptographic hardware, enabling us to have SECURE key processing to
serve keys to both TS1100 and LTO4/LTO5 drives. This chapter is intended to be a cookbook
to help you get started with a unified keystore that takes advantage of both the security
advantages of having cryptographic hardware and the superior security of z/OS. We assume
in this chapter that the drives and libraries are already set up to take advantage of an EKM
running on z/OS. We also assume that the libraries can get to the z/OS EKM through the
TCP/IP network and that our encryption policies will use the default keys as set in the EKM
configuration file.
G
Implementing EKM in z/OS
The Encryption Key Manager (EKM) is a common platform application that is written in Java
that runs under the Java virtual machine (JVM). EKM can also reside outside of the z/OS
environment; however, for the purposes of this section, we must implement it on z/OS.
Additionally, the z/OS logical partition (LPAR) on which we implement EKM, also needs
access to Integrated Cryptographic Service Facility (ICSF) and a CEX2C. On z/OS, EKM runs
under UNIX System Services, which is part of the Open MVS (OMVS) address space.
EKM interfaces with the associated keystores using application programming interfaces
(APIs). We use secure TCP/IP connections to communicate with the tape drives (in-band or
out-of-band).
For SECURE symmetric key processing on z/OS, we have to use a JCECCAKS, which also
supports SECURE asymmetric key processing. The JCECCAKS enables us to have a
keystore that has the highest level of protection for both LTO4/LTO5 and TS1100 drives. This
hardware-based keystore works with the ICSF.
Use more than one EKM because of redundancy. EKMs can either share keystores or use
separate keystores. For this implementation, we explain the special key management
considerations in Enterprise-wide key management on page 964. For more detailed
information about EKMs, refer to the IBM System Storage Tape Enterprise Key Manager,
Prerequisites
The following products provide the hwkeytool support for SECURE LTO4/LTO5 keys in a
JCECCAKS:
IBM 31-bit SDK for z/OS, Java 2 Technology Edition (J2TE) V5.0, and z/OS 1.6 and
z/OS.e 1.6, and later only
Order 5655-N98 (at the SDK 1.5 Service Release (SR) 5 level or later)
ICSF, which must be up and running on the LPAR that will serve as the EKMs home
z/OS UNIX System Services
On z/OS, EKM runs under UNIX System Services, which is part of the Open MVS (OMVS)
address space.
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.
We assume 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 informa-
tion about how to install and tailor UNIX System Services on 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 G-1 on page 951.
Appendix G. Implementing EKM on z/OS SECURE key processing to TS1100 and LTO4/LTO5 drives 951
Figure G-1 The OMVSEX address space is present
If the UNIX System Services address space is present, the OMVSEX for OMVS is shown.
Installing the Encryption Key Manager in z/OS
The Encryption Key Manager (EKM) is automatically installed as part of the IBM Java
Developer Kit (JDK). However EKM and IBM JDK are on separate development streams. To
ensure that the latest EKM program code is installed, you must download EKM and copy it to
the JAVA SDK directory.
To download the latest version of the IBM EKM, go to this website:
You can download the IBM 31-bit Software Developer Kit (SDK) for z/OS Java 2 Technology
Edition from the following website:
http://www.ibm.com/servers/eserver/zseries/software/java/j5pcont31.html
In ISPF or TSO, use option 6, (Commands), type OMVS, and then press Enter. Or, type
telnet/rlogin,ssh into an OMVS session.
Use a File Transfer Protocol (FTP) program, and copy the file into the file system. Then,
extract the file into /usr/lpp/java using the following command:
pax -rf UK17593.PAX.Z
Tip: 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.
To verify that the correct version of EKM was installed, use the following command at the
OMVS command prompt:
/u/st6t25c>java -version
Example G-1 shows the output.
Example G-1 Output from java -version
Java(TM) 2 Runtime Environment, Standard Edition (build pmz31devifx-20060302 (SR
1))
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 z/OS s390-31 j9vmmz3123-20060223 (JI
T enabled)
J9VM - 20060220_05389_bHdSMr
JIT - 20060220_2133_r8
GC - 20060214_AA)
JCL - 20060301
Download and install the latest EKM server code. Obtain the code and documentation from
this website:
After you have downloaded the EKM code, place it in the $JAVA_HOME/lib/ext directory. 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 EKM for z/OS is complete.
The IBM System Storage Tape Enterprise Key Manager, Introduction Planning and User
Guide, GA76-0418, provides additional information.
To perform the necessary installation steps to use EKM, special authorization rights are
required; for example, you must enable the RACDCERT command for the OMVS segment.
We also require access to the crypto hardware through the CSFSERV and CSFKEYs
classes. In Chapter 17, Encryption Key Manager operational considerations on page 531,
you can read about the types of keystores and their usage. In the following sections, we
create a hardware keystore.
EKM does not provide cryptographic capabilities; therefore, it does not require, nor is it
allowed to obtain, Federal Information Processing Standard (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 your
setting the FIPS configuration parameter to ON in the configuration properties file, EKM will
use the IBMJCEFIPS provider for all cryptographic functions.
TIP: Installing JAVA with SMP/E for z/OS also installs JZOS. If you download and install
Java through this process, you must manually install JZOS.
Requirements: You cannot start EKM without an associated keystore and a rudimentary
KeyManagerConfig.properties EKM configuration file.
In addition to setting the FIPS parameter in the configuration properties file, you must add the
following provider to the java.security file, just before the IBMJCE provider:
$JAVA_HOME/lib/security/security.provider.?=com.ibm.crypto.fips.provider.IBMJCEFIPS
Renumber the providers accordingly.
Create a JCECCAKS for EKM
In this section, we create a JCECCAKS, which we will later use as the keystore for EKM
initialization. JCECCAKS is the most secure of the keystores that use symmetric keys.
Access to the keystore file is protected by UNIX System Services file permissions; access to
use the crypto hardware is through Resource Access Control Facility (RACF) administration.
Our symmetric keys are stored in the Cryptographic Key Data Set (CKDS), which is protected
by cryptographic hardware.
Refer to Chapter 16, Planning and managing your keys with Encryption Key Manager on
page 481 for a more detailed description of this keystore type.
The following hwkeytool commands in Example G-2 create a keystore with five triple Data
Encryption Standard (DES) (or TDES) 192-bit symmetric keys in it. Our JCECCAKS file will
contain labels that point to the master key encrypted entries in the CKDS. These entries are
the keys that will be used to protect data on LTO4 or LTO5 cartridges.
Example G-2 JCECCAKS with symmetric keys in the CKDS
hwkeytool -genseckey -v \
-aliasRange EKM2008101-2008105 \
-keyalg TDES \
-keysize 192 \
-hardwaretype CKDS \
-provider IBMJCECCA
To serve keys to TS1100 tape drives, we create an x.509 certificate and key pair in our
keystore. Example 25-6 on page 954 is the hwkeytool command that creates the key pair in
the keystore. It generates a self-signed certificate with a validity of one year. This certificate
can be signed later by a third-party certificate authority (CA), but for the purposes of
describing this scenario, that exercise is left to you.
Tip: Do not use hardware-based keystore types with FIPS.
Tip: We list these hwkeytool commands in these examples so that you can cut and paste
them directly into a shell script and run the script. To run these commands from the OMVS
command line, remove the trailing backslashes (\) and type the whole command on a line.
We have put the trailing backslashes in the example in a script format for readability and
usability.
Example 25-6 X.509 asymmetric key creation
hwkeytool -genkey -alias "Company.TEKM.20081210" \
-keyalg RSA \
-keysize 2048 \
-dname "cn=Company,c=US" \
-provider IBMJCECCA \
-hardwaretype PKDS
For our EKM example, we created a keystore for our Secure Sockets Layer (SSL) certificates
to enable our EKMs to communicate over an SSL connection. In Example G-3, we add our
SSL certificate to the keystore that was created in Example G-2 on page 953. This command
stores our key material in the Public Key Data Set (PKDS). This SSL certificate is valid for 10
years from today, with a key size of 2048 bits.
Example G-3 Creating an SSL certificate in a JCECCAKS keystore
hwkeytool -genkey -alias "SSL.TEKM.20181210" \
-keyalg RSA \
-keysize 2048
-validity 3650 \
-dname "cn=Company,c=US" \
-provider IBMJCECCA \
-hardwaretype PKDS
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 the /u/ekmserv directory. 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 the /u/ekmserv
directory, sets the default shell to /bin/sh, and associates it with the next available user
identifier (UID). If a stricter security policy is in effect, the RACF administrator must replace
the AUTOUID with UID (UserIDNumber). Avoid using UID 0 (zero).
In addition, this user will have access to the IRR.DIGTCERT.* facility classes, as described in
Example 15-4 on page 418 in 15.1.4, Create a JCE4758RACFKS for EKM on page 418.
Before continuing, download and save the following files to the /u/ekmserv/ directory:
IBM EKM application
IBM EKM sample configuration file
JZOSEKM files for z/OS batch
You can find the application and files at the following website:
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 ensure that the ekmserv ID has an acceptable .profile file. In the /u/ekmserv
directory, edit the .profile file to make it look like the sample profile that is shown in
Example G-4.
In the example, include the line stty quit ^V in a profile when logging on to OMVS using
Secure Shell (SSH). The line export PS1 sets up this users command line. In this case, we
set up the command line to always list the current working directory. This setting is a useful
setting when navigating around an OMVS file system.
After that, we set up the JAVA_HOME environment variable. This variable must 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.
Now, we create 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 to perform Java hwkeytool commands might be longer than the command line; by
setting several of these long parameters as environment variables, we can save space on our
limited command line.
Example G-4 Sample .profile
stty quit ^V
export PS1='$PWD>';
alias hw="hwkeytool -debug -list -storetype JCECCAKS -keystore"
After our profile is set up, we can reread it by either of the following methods:
Type the following line:
. ./.profile
Log out and log back in, which executes the .profile again.
Now, we must copy the updated EKM:
cp IBMKeyManagementServer.jar $JAVA_HOME/lib/ext
This command copies the EKM program code into the JAVA_HOME/lib/ext directory. The
JARs in the lib/ext directory are all loaded into the JVMs class path. A simple listing of that
directory reveals security provider JAR files, among other things.
You must extract the JZOS EKM files. Enter the command:
This command extracts the following files:
PROCLIB.EKM2ENV
readme
jzosekm.jar
PROCLIB.EKM2
The jzosekm.jar file contains Java wrapper code for EKM. To interact with EKM using write to
operator (WTO), we must register a callback using APIs from the JZOS toolkit. The program
code that is contained in this JAR registers the callback for us. To ensure that this code is in
our class path, we copy it to the lib/ext directory:
cp jzosekm.jar $JAVA_HOME/lib/ext
The KeyManagerConfig.properties EKM configuration file is now edited with our information.
In Example G-5, we have turned on extra tracing and debugging information. All our keystore
and directory structure properties in the configuration file are set to relative file paths.
Example G-5 Sample EKM config
fips = Off
Admin.ssl.keystore.name = ekmkeys.cca
config.keystore.provider = IBMJCECCA
Admin.ssl.truststore.password = CLEARTEXTPASS
config.keystore.password = CLEARTEXTPASS
TransportListener.ssl.truststore.name = ekmkeys.cca
TransportListener.ssl.truststore.type = JCECCAKS
config.keystore.file = ekmkeys.cca
TransportListener.ssl.keystore.name = ekmkeys.cca
TransportListener.ssl.keystore.password = CLEARTEXTPASS
TransportListener.ssl.truststore.password = CLEARTEXTPASS
Audit.event.outcome.do = success,failure
debug.output.file = keymanager/debug/ekmdebug.txt
Audit.handler.file.name = ekm.audit.log
TransportListener.ssl.keystore.type = jceccaks
config.keystore.type = jceccaks
Audit.event.types.backup = authentication,authorization,data synchronization,runtime,audit
management,authorization terminate,configuration management,resource management,none
debug = all
Admin.ssl.truststore.name = ekmkeys.cca
config.drivetable.file.url = FILE:////keymanager/drivetab
symmetricKeySet = EKM2008101-2008105
default.drive.alias2 = Company.TEKM.20081210
default.drive.alias1 = Company.TEKM.20081210
Admin.ssl.keystore.password = CLEARTEXTPASS
At this point, we can create the directories that EKM will use, or let EKM create the directories
on startup. Allow EKM to create its directories, which will let EKM set itself as owner, and
which will also avoid any typing errors when creating the directories. The debug.output.file
option points to a file. If the assumption is made that the option points to a directory,
java.io.permission errors can occur. If the file does not exist, EKM creates it, but the file
cannot point to a directory.
Starting EKM
In this section, we describe how to perform interactions with an EKM as a started task. We
also describe how to set up EKM to run as a started task using JZOS.
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.
Set up EKM to run as a started task on z/OS using the JZOS batch launcher, which is
shipped as part of the z/OS Java product. Refer to Encryption Key Manager and JZOS on
page 879 for more information.
To define EKM as a started procedure, update the started class table with the z/OS
user ID of EKM. Previously in this section, we created EKMSERV as the user ID to use with
EKM and the group associated with that started procedure will be SYS1. The z/OS Security
Server RACF Security Administrators Guide, SA22-7683, describes details of RACF
processing and the definition of started procedures.
To set up the STARTED class, enter the commands that are shown in Example G-6.
Example G-6 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 that was downloaded in the beginning of this section consists of
the jzosekm.jar file, sample JCL, the STDENV file for the sample JCL, and an
EKMConsoleWrapper. Refer to the readme file that explains where each file must be located
and any specific installation and tailoring tasks that might be required.
To extract the contents of the download file, issue the following command:
Place the jzosekm.jar file into the $JAVA_HOME/J1.4/lib/ext directory.
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 have to allocate file system space for the EKM audit logs,
and possibly the EKM debug log.
storage. Assume 500 cylinders of space to allocate to the EKMs audit and debug log file
system until you have observed, based on tape and EKM activity, how quickly the audit logs
z/OS compatibility: Our configuration file has the following information:
We set this value to true because of the way that the symmetric keys are stored in the
CKDS. This option must be set to use SECURE symmetric keys.
environment, but the files must be private and dedicated to each EKM instance. This setup
prevents any possible interleaving of audit or debug logs between EKM instances.
Mount the ekmlogs file system and create a directory for each system on which EKM will run.
For example, the two file systems that are 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 PDS 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 G-7.
Example G-7 EKM environment script

#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.5"

LIBPATH=/lib:/usr/lib:"${JAVA_HOME}"/bin:"${JAVA_HOME}"


CLASSPATH=${JAVA_HOME}/lib
CLASSPATH=$CLASSPATH:"${EKM_HOME}"


#Update with location of config data
export keyFile="KeyManagerConfig.properties"
#The EKM main class
export ekmClass="com.ibm.keymanager.KMSAdminCmd"
export JZOS_MAIN_ARGS="$ekmClass $keyFile"

# 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 JAVA_DUMP_HEAP=false
#export JAVA_PROPAGATE=NO
#export IBM_JAVA_ZOS_TDUMP=NO
env
Customize the sample procedure in Example G-8 for your system.
Example G-8 Start procedure
//EKM PROC JAVACLS=com.ibm.jzosekm.EKMConsoleWrapper,
// LIBRARY=SYS1.SIEALNKE, < STEPLIB FOR JVMLDM module
// VERSION=15, < JVMLDM version: 14, 50, 56
// LOGLVL=+T, < Debug LVL: +I(info) +T(trc)
// REGSIZE=0M, < EXECUTION REGION SIZE
// LEPARM=
//*********************************************************************
//*
//* Specifically, to execute the Enterprise Key Manager under JZOS
//*
//*********************************************************************
//EKM EXEC PGM=JVMLDM&VERSION,REGION=&REGSIZE,
// PARM=&LEPARM/&LOGLVL &JAVACLS &ARGS
//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
You can now start the EKM process with the operator start command as a started task. The
following command starts the EKM server:
S EKMSERV
In Figure G-2 on page 960, we have started EKM as a job using JZOS. We can see the
Loaded drive key store successfully message. We can see that EKM is running and
communicating with the console.
Figure G-2 EKM start message
If we execute the following command, the message in Figure G-3 on page 961 displays:
f EKMSERV,appl=status
Figure G-3 EKM status
We can also list how many certificates were loaded into EKM by executing this command:
f EKMSERV,appl=listcerts
Figure G-4 on page 962 shows the output from this command.
Figure G-4 EKM certificate list
For a complete listing of EKM commands, refer to 17.1, EKM commands on page 532.
Configuring EKM TCP/IP
Most often, the definitions that are described in 15.1.8, Virtual IP Addressing on page 429
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 that are 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.
The entire TCP/IP configuration, including virtual IP addresses (VIPAs), is done in the TCP/IP
profile. For all images that are running EKM, the following items are required in the profile:
Ports 3801 and 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, you must add the option SHAREOPT to each of the
applications using the port, for example:
PORT
1443 TCP EKM SHAREOPT ;Key Manager
1443 TCP IMWEB SHAREOPT ;Web server
Important: In this example, note that our EKM runs its SSL listener on port 4430.
WebSphere might use 4430 for SSL processing, so we changed the port so that EKM does
not collide with WebSphere SSL processing.
EKM can also be started when TCP/IP starts up by adding it to the AUTOLOG section, for
example:
AUTOLOG
EKM ;Key Manager
ENDAUTOLOG
Sysplex Distributor
The following description is for a 10-way sysplex with EKM running on most of the images.
We configured a Sysplex Distributor 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 will move the Sysplex
Distributor to another image where the requests will be handled. The backup stack has to be
configured in the TCP/IP profile.
Perform these steps to set up a Sysplex Distributor:
1. Ensure that you have a dynamic cross-system coupling facility (XCF) component. This
component is the path that is used for the requests through the Sysplex Distributor:
IPCONFIG DYNAMICXCF 192.168.49.30 255.255.255.03
Perform this step on all images where the Sysplex Distributor might be the backup.
2. Define the required dynamic VIPA (DVIPA) parameters in the VIPADYNAMIC section of the
profile:
VIPARANGE DEFINE 255.255.255.255 9.xxx.xxx.xxx;keystore
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 the 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).
3. For the images that were configured as backup, you need dynamic XCF EKM running and
the following example, which tells the sysplex which DVIPAs you are backing up:
VIPADYNAMIC
VIPABACKUP 9.xxx.xxx.xxx
ENDVIPADYNAMIC
Example G-9 shows a complete definition example.
Example G-9 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
Enterprise-wide key management
A common theme with improving security of a solution is a decrease in accessibility of the
solution. For tape encryption solutions, use more than one EKM, all with the same keys in
their keystores to enable EKM to EKM failover.
The best way to keep the keys that are used by the EKM implementation that is described in
this appendix is to have your EKMs on LPARs in a sysplex with a shared CKDS. Therefore,
anytime that you create keys in the CKDS using hwkeytool, all LPARs in the sysplex that have
the same master keys and point to the same CKDS will have the ability to access the keys.
You will be able to copy the JCECCAKS file itself, because it is simply pointing to the key
labels in the CKDS, but you will need those keys and key labels in the CKDS for that to work.
Sharing keys between sites becomes a bit more complex. If the CKDS contains all the same
keys site to site, you simply have to create the keys in one CKDS and copy the whole CKDS
to the other site, making sure that both sites use the same master keys. Then, you can copy
the JCECCAKS file to the second site and EKM will be able to load the same keys.
It gets a bit more complicated if you have CKDSes across multiple sites that do not contain
the same keys in them. One way to keep the keys synchronized between CKDSes is to use
the ICSF Key Generation Utility Program (KGUP) to export the CKDS key protected by a
transport key from one CKDS to another CKDS. The z/OS Cryptographic Services Integrated
Cryptographic Service Facility Administrators Guide, SA22-7521-09, describes this process.
After CKDS keys are moved from one CKDS to another CKDS, you can then copy the
JCECCAKS file to the other system, start EKM, and have the same keys between both
CKDSes.
A similar situation is in place to share our asymmetric keys. The best solution is to use the
-keylabel option when using the hwkeytool commands to create a X.509 certificate and key
pair in the PKDS. This keylabel option lets the user specify the label that the private key
material will get in the PKDS. Then, we can copy out the private key material from one PKDS
to another PKDS, assuming they have the same master keys, using the key transfer (keyxfer)
utility. You can obtain the keyxfer utility at this website:
ftp://ftp.software.ibm.com/s390/zos/tools/keyxfer/keyxfer.rexx.txt
After the private keys are copied, copy the JCECCAKS file to the system, and then, start
EKM.
You can avoid this manual process if the destination system will have the exact same PKDS.
Simply copy the entire PKDS and CKDS to the destination system, move the JCECCAKS file,
and start EKM. For more programing examples of how to move key material around
programmatically, refer to Java Security on z/OS - The Complete View, SG24-7610.
Conclusions
This appendix is intended as a cookbook to get an EKM up and running on z/OS with a
JCECCAKS keystore, using both SECURE key types, asymmetric keys for the TS1100 drives
and symmetric keys stored in a CKDS to handle LTO4/LTO5 tape drives. This type of EKM
implementation takes advantage of the improved security of both using cryptographic
hardware for protecting key material and putting EKM on z/OS to take advantage of all the
security benefits of running on that platform.
Appendix H. Encryption testing in an open
systems environment
This chapter provides detailed information about encryption test methods in an open systems
environment. Various test methods are available to verify the functionality of the end-to-end
encryption setup.
Encryption test and diagnostic functions are available with these products:
IBM tape diagnostic tool (ITDT)
IBM tape device driver
IBM tape library
Key Manager logs
We describe the following topics in this chapter:
Encryption key path testing:
For Library-Managed Encryption (LME)
For System-Managed Encryption (SME)
Data encryption testing:
IBM tape diagnostic tool (ITDT)
Encryption verification using the ITDT-Graphical Edition (GE)
Encryption verification using the ITDT-Standard Edition (SE)
Encryption verification by library and log-provided information
Encryption test with tape device driver functions
We used this test environment:
AIX and Microsoft Windows Server 2008 operating system connected by way of Fibre
Channel (FC) to the IBM System Storage TS3500 and TS3400 tape library.
IBM TS1120 and TS1130 tape drives
H
Encryption key path test
In this section, we explain how to test the Key Manager IP address. We also provide
procedures for testing the key path and the setup between Library-Managed or
System-Managed encryption-enabled tape drives and the Key Manager.
We use the Key Manager (KM) in this chapter for both the Encryption Key Manager (EKM)
and the Tivoli Key Lifecycle Manager.
For LME, the key path test is performed on the library level. For SME, the key path test is
performed on the system level.
In an LME setup, the proxy runs on the library layer. In a SME setup, the proxy runs on the
system layer where the IBM Tape Device Driver is installed. In the LME environment, the key
exchange runs through a TCP/IP network communication path between the Key Manager and
the tape library. This method is often called out-of band key management, because the keys
are served out of the systems data path. In an open systems SME environment, the key
handling is often called in-band key management. The key exchange runs first through a
TCP/IP communication path between the Key Manager and the system. On the system level,
the keys are served to the tape drives over the data channel using the IBM tape device driver.
Use the following methods to test the address of a Key Manager or the path between a drive
and a Key Manager.
Using key path diagnostics in an LME environment
The Key Path Diagnostics test provides the ability to perform diagnostics on the encryption
key path. Only encryption-capable drives in logical libraries that are configured for LME will
and can be tested. Make sure that the library and Key Manager are configured correctly prior
to the test.
The general key path diagnostics consist of the following tests:
Drive test: This test is a drive communication test to ensure that the library-drive interface
(LDI) functions properly.
Ethernet test: The library pings each KM server IP address and records the result. If this
test fails, there typically are network problems. Eventually, the library cannot reach the
host server where the KM is installed. Try to ping the KM server and library from another
server in the network.
Key manager path test: The library performs an KM communication test for each KM
server IP address that passed the Ethernet test. If this test fails, verify if the KM server has
been started and is running properly. In the case of using Tivoli Key Lifecycle Manager,
make sure that the Tivoli Integrated Portal service has been started. Check that the IP port
settings for the KM servers that are defined in the library match the settings that are
configured in KM and cause no port conflicts on the host.
Key manager config test: This test causes the drive to establish a link and get a default key
from the KM (confirms the keystore and defaults). This test confirms that the drive is
correctly configured in the drive table to service the key requests. If this test fails, there is a
problem with the configured key alias or with the keystore.
You implement the Key Path Diagnostic test in the web Graphical User Interface (GUI) for the
following listed IBM tape libraries:
IBM TS2900 Tape Autoloader
Appendix H. Encryption testing in an open systems environment 967
The key path test on the web GUI is the same for all five of these library models. For more
detailed information about IBM tape drives and libraries, refer to the IBM System Storage
Tape Library Guide for Open Systems, SG24-5946, or refer to the product information guides,
which are located at this website:
http://www.ibm.com/systems/storage/tape
Figure H-1 shows an example of the TS3400 Key Path Diagnostic test function that is
provided by the web GUI. In this example, the library is partitioned into two logical libraries:
Logical Library 1 (Drive 1) has encryption disabled. Diagnostics are not possible.
Logical Library 2 (Drive 2) has LME enabled. Diagnostics are possible.
We run the Key Path Diagnostic test against the LME-enabled logical library in drive 2.
Figure H-1 TS3400 Key Path Diagnostic test
The TS3500 requires the Key Path Diagnostic test firmware level 9590. The test is available
on the library Operator Panel. The TS3500 diagnostic test does not include the drive test
function. For TS3500, you must select the appropriate single drive manually prior to the test
start. All the other TS models have the drive test included in the web diagnostics. The test
runs sequentially on each IP address of each drive that is enabled for LME.
The TS3500 Operator Panel in Figure H-2 on page 968 shows a example of a Key Path
Diagnostic test running against a drive in Frame01/Row03. We selected the appropriate tape
drive prior to starting the test.
Figure H-2 Key Path Diagnostic test on TS3500
The TS3500 web GUI provides a second test for key path diagnostic support. You can
perform a Ping Address test to the Key Manager address, as shown in Figure H-3. Select the
Logical Library and the Key Manager address to start the test.
Figure H-3 TS3500 Key Manager Ping Address test
The library performs the ping, and the window displays a status message afterward, as
shown in Figure H-4 on page 969.
Figure H-4 TS3500 Ping Address test results
Key Path Diagnostic test in a SME environment
The IBM Tape Device Driver provides encryption diagnostic tests for the following supported
open systems operating systems:
AIX
Microsoft Windows
Linux
Solaris
Encryption key path test on an AIX operating system
The device driver configuration for SME is set on a specific tape drive using the standard
SMIT panels to change or show the characteristics of a tape device. Or, you can use the
chdev command line command.
For SME device driver configuration and configuration file setup, refer to IBM Tape and
Medium Changer Device Drivers for AIX, HP-UX, Linux, Solaris and Windows, GC27-2130.
Figure H-5 on page 970 shows the setup for all the SME tests that are shown in this chapter.
Make sure that you create the IBMEKM.conf file on the system where the device driver is
installed.
Device driver tool: The tool that is delivered with the device driver is called tapeutil on
UNIX operating systems and is called ntutil on Microsoft Windows operating systems.
Figure H-5 SME test setup
Querying the tape drive configuration
There is a new tapeutil command that has been added for encryption to query the tape drive
encryption settings. You can query the current tape drive encryption settings by using the
tapeutil menu option 38 Get Drive Encryption Settings or by using the following command
on the command line:
tapeutil f/dev/name encryption
Example H-1 shows a correct tape drive configuration with wrt_encryption set to on. If the
wrt_encryption attribute is set to no, the tape drive Encryption State will be Off.
Example H-1 Option 38 Get Drive Encryption Settings
>tapeutil -f/dev/rmt1
encryption Getting drive encryption settings...
AIX and SME: On AIX, you enable SME by changing the characteristics for the specific
tape drive by using the standard SMIT panels.
Open System Host
AIX or Windows 2008
- IBM Tape Device Driver
- ITDT Tool
- IBMEKM.conf file
TS1130
Tape Library
-TS3400
- TS3500
FC Connection
LDI
Key Server (Windows 2008)
- TKLM or
- EKM
TCP/IP
For SME the IBM Tape Device Driver is required.
Drive key exchange runs over TCP/IP network path
from the Key Server to the OS Host.
OS Host exchange the keys via In-band management
over the Data channel to the Library usi ng the IBM
Tape Devi ce Driver.
ITDT and IBM Device Dri ver is runni ng on OS Host.
TS1130 Drive i s connected via FC to the OS Host.
SME Test setup
Encryption Key Path Diagnostic
On AIX, use the tapeutil command to validate the ibmekm.conf file server entries and to test
connectivity from the tape drive to the Key Manager server. Run this test by using the tapeutil
menu option 40 Data Encryption Test, or run the command:
tapeutil f/dev/name ekmtest
The following tests run:
The first test checks the server configuration that is defined in the ibmekm.conf file and
then the communication to the configured servers. This test reports the number of
available servers.
The second test runs a basic diagnostic test that checks the tape drive to server
communication and reports success or failure.
The third test runs an enhanced diagnostic test that checks a key operation between the
tape drive and server, and then, it reports success or failure.
Example H-2 shows the output of the tapeutil command.
Example H-2 tapeutil ekm validation
Enter Selection for /dev/rmt7: 40
Testing server configuration and connections...
Testing complete, servers available 1
Running basic drive to server encryption test...
Testing complete, completion code 0
Running full drive to server encryption test...
Testing complete, completion code 0
After all Atape changes have been made and the EKM tapeutil validation has run to a
successful completion, you are ready to start encrypting data.
Testing encryption on a Windows Server 2008
Device driver configuration SME parameters on Windows are placed in the registry under the
key for the device driver. You can set these parameters on a specific tape drive by changing
the registry.
For SME device driver configuration and configuration file setup, refer to IBM Tape and
Medium Changer Device Drivers for AIX, HP-UX, Linux, Solaris and Windows, GC27-2130.
Querying tape drive configuration
Use the ntutil command to query the encryption settings of a tape drive. The appropriate
tape drive must be in opened status prior to querying the encryption settings.
Switch to Library mode, and list all your registered devices by entering menu option 88. Then,
enter ntutil menu option 1 to set the device special file. Then, enter menu option 20 to open
the tape device and medium changer. The ntutil command to get encryption state is menu
option 59. Figure H-6 on page 972 is an example of the output when the drive is correctly
configured for SME, with encryption turned on.
Tip: If a cartridge is mounted on the tape drive, unload this cartridge before running the
ekmtest command.
Figure H-6 Menu option 59: Get encryption state
Encryption key path diagnostic test
On Windows, use the ntutil command to validate the ibmekm.conf file server entries and to
test connectivity between the tape drive and the server.
Enter menu option 60 to provide a key path diagnostic test:
The first test checks the server configuration that is defined in the ibmekm.conf file and the
communication to the configured servers. This test reports the number of available
servers.
The second test runs a diagnostic test that checks the tape drive to server communication
and reports success or failure.
The third test runs an enhanced diagnostic test that checks a key operation between the
tape drive and the server and, then, reports success or failure.
Figure H-7 shows the output of the ntutil command.
Figure H-7 Menu option 60: Encryption diagnostic
After you have made all registry and config file changes and the Key Manager validation has
run to a successful completion, you are ready to start encrypting data.
SME on Windows: On Windows operating systems, SME is enabled in the registry for the
specific tape drive.
Testing data encryption
In this section, we introduce the data encryption test function that is delivered by the ITDT tool
and the methods that you can use to verify the functionality of the end-to-end encryption
setup.
IBM Tape Diagnostic Tool
The IBM Tape Diagnostic Tool (ITDT) V4.0 offers multiple functional capabilities that simplify
the task of maintaining IBM tape products. ITDT is available in two versions:
Standard Edition (ITDT-SE): This version is a command line version. Invoke it by entering
the executable from the directory where the tool is located. The Help feature gives a brief
explanation of each function and shows the required syntax.
Graphical Edition (ITDT-GE): This version is a GUI version for the following operating
systems:
Microsoft Windows operating systems (Microsoft Windows Server 2003 and Microsoft
Windows Server 2008 (32-bit x86) and Microsoft Windows Server 2003 and Microsoft
Windows Server 2008 (64-bit x64) [with a 32-bit Java virtual machine (VM)].
Linux operating systems (Linux distributions with Kernel 2.6, glibc 2.2.5, and later
(X86))
Download the tool from this IBM using ftp.software.ibm.com/storage/ITDT/Current/.
Both versions provide a single diagnostic program for tapeutil applications. Both SE and GE
contain tapeutil functionality. SE also provides scripting capability. The ITDT Tool offers
multiple functional capabilities that simplify the task of updating tape and library firmware. It is
available for most major platforms and requires no special device drivers. In addition to the
executable file, the tool provides a readme file. Note that this readme file only contains issues
and limitations that did not make it into the IBM Tape Diagnostic Tool documentation, which is
now part of the IBM Tape and Medium Changer Device Drivers for AIX, HP-UX, Linux, Solaris
and Windows, GC27-2130.
You can perform the advanced operations that are provided by the IBM Tape Diagnostic Tool
on tape drives and tape libraries. By using this functionality, you can perform maintenance
tasks and run diagnostic tasks to determine tape drive issues. This testing significantly
reduces product downtime and increases productivity. One of the ITDT functions is the
Encryption Verification test.
Encryption Verification test using the ITDT-GE
Use the encryption verification function to verify if data on the cartridge was actually written in
an encrypted manner. The ITDI-GE reads both decrypted and raw encrypted data from the
cartridge into two separate files on disk. You can then verify that the data differs to ensure that
encryption worked. The encryption function does not provide a write-read quality test.
The encryption function is only supported on encryption-enabled drives and requires that an
encryption infrastructure, including the Encryption Key Manager (EKM) or the Tivoli Key
Lifecycle Manager, is properly set up.
The following encryption environments support the encryption function:
SME: The IBM Tape Device Driver must be installed and in use by ITDT to read decrypted
data.
LME
AME: Only raw encrypted data will be read (result file is *.ENC).
In this section, we run an ITDT encryption test using LME.
As shown in Figure H-8, we used a TS3400 with a TS1130 Drive installed.
In this setup, the TS1130 is directly attached by way of Fibre Channel to a Windows Server
2008 backup server, which has ITDT-GE V4 installed and running. The library is connected
through a TCP/IP network to a Tivoli Key Lifecycle Manager Key Server, which is also running
on a Windows Server 2008 operating system.
Figure H-8 LME setup with key server and tape library
After starting the ITDT on the system, you have to scan for the attached devices. This will
remind you to stop all the backup jobs, as shown in Figure H-9 on page 975.
Open System Host
Windows 2008
- ITDT Tool
TS1130
Tape Library
-TS3400
- TS3500
FC Connection
LDI
- TKLM v1.0.0.1
TCP/IP
Drive key exchange occurs over the Library Drive
Interface (LDI) and TCP/IP path to the Key Server.
ITDT i s running on the OS Host.
TS1130 Dri ve is connected vi a FC to the OS Host.
For LME, the IBM Tape Driver is not required.
LME Test setup
Key Server (Windows 2008)
Figure H-9 ITDT start window with scan option
The scan process will discover all the connected tape devices and medium changers. For
drive selection, check the box to the left of the drive on which you want to run the Encryption
Verification test, as shown in Figure H-10.
Figure H-10 ITDT drive selection window
Start the ITDT Encryption Verification by selecting Test Encryption Verification. The
drive is initializing and a cartridge selection window pops-up.
In that window, you must choose one of the following options:
Click Select to select a cartridge from the current inventory.
Insert a new cartridge into the library, and then, click Insert.
Click Cancel to end the test.
The next window prompts you to select the test cartridge. After cartridge selection, click Start,
as shown in Figure H-11.
Figure H-11 ITDT cartridge selection window
On the next window, as shown in Figure H-12, the system requires the entry of the number of
the start record and the amount of data (in KB) to read. The maximum data length is
100000 KB.
Figure H-12 ITDT Encryption Verification start window
If you entered the values correctly, click OK to start the encryption test. During the encryption
test, the program shows a progress indicator in the form of a blue vertical bar that shows the
progress of a single sub-test, as well as information about that sub-test. You can end the
encryption function by clicking Abort at any time.
If all encryption operations are finished, ITDT-GE shows a window that indicates PASSED if
the encrypted test completed successfully, as shown in Figure H-13, and ABORTED,
otherwise.
Figure H-13 ITDT Encryption Verification result window
The window also shows the name of the encrypted and decrypted output files that were
generated during the encryption test. See Figure H-14 for an output file example.
Figure H-14 Encrypted and decrypted output files
The serialnumber.n.ENC file contains the raw encrypted data. The serialnumber.n.DEC
contains the decrypted data.
The test uses these abort codes and their root causes:
LOCATE FAILED: Start position as requested by the user was not reached
MEDIUM NOT ENCRYPTED: ITDT detected medium as non-encrypted
NO DRIVER SPECIAL FILE: System-Managed environment, but generic device file is used
instead of IBM device driver special file
DRIVE ENCRYPTION DISABLED: Mode sense detected disabled drive encryption
UNEXPECTED DATA: Set raw read mode failed or one of the commands failed
END OF MEDIUM: End of medium encountered before the given amount of data was read
END OF DATA: End of data encountered before the given amount of data was read
READ FAILED
ENCRYPTION ERROR
INVALID PARAMETER: User entered data length of 0 KB
Encryption verification using the ITDT-SE
The Encryption [E] function is also available in the SE version. The command-line interface
(CLI) version runs on the most operating systems. See Figure H-15.
Figure H-15 ITDT SE Version 4
Follow these steps:
1. After starting ITDT-SE, type S and then press Enter to activate the device scan.
2. Select the device that you want to test by entering its number and pressing Enter. Type E
and press Enter to start the encryption test.
3. ITDT-SE then switches to the Encryption Verification window, as shown in Figure H-16 on
page 979. On this window, the system requires that you enter the number of the start
record and the amount of data (in KB) to be read.
4. Type S followed by a space and the start record number, and then, press Enter. Type L
followed by a blank and the data length (maximum 100000 KB), and press Enter. See
Figure H-16.
Figure H-16 Encryption verification window
5. If you entered the values correctly, press Enter to start the encryption verification.
During the verification, the program shows a progress indicator in form of a bar of hash marks
(#) that shows the progress of a single sub-test, as well as information about that sub-test.
You can stop the encryption function by typing A and pressing Enter at any time.
The window also shows the output files that were generated during the encryption function.
The serialnumber.n.ENC file contains the raw encrypted data. The serialnumber.n.DEC
contains the decrypted data.
Abort codes are the same codes that are used for the ITDT-GE version.
Encryption test using the device driver functions
In this section, we write encrypted data to a tape cartridge. Afterward, we verify our
encryption by using the information gathered from the library web GUI and the Key Manager
log file.
Note: It might take time before the encryption verification actually stops. If all encryption
operations are finished, ITDT-SE shows a window that displays the Status field on the
lower-left side that indicates PASSED if the encrypted test completed successfully and
ABORTED otherwise.
LTO4/LTO5: You can perform these same tests in the same way for LTO4 or LTO5 drives.
Only the Key Manager and key setup differ for LTO4/LTO5 drives in comparison to
3592-E05 and 3592-E06 drives.
Encrypting data using ntutil
Again, we use a TS3400, including a TS1130 drive with SME enabled for that test. We started
ntutil from command line, switched to Library mode, and set the device special file. Then,
we opened the drive and changer by typing menu option 20, as shown in Figure H-17.
Figure H-17 Devices opened successfully
The cartridge was put into the I/O station prior to the test. By typing menu option 10, we
checked the element address of the TDJ012JJ cartridge, as shown in Figure H-18 on
page 981.
Figure H-18 TS3400 Inventory Logical Library 2
We moved the TDJ012JJ cartridge into drive 1326885 by typing menu option 11. Afterward,
we wrote encrypted data to our cartridge and read it back decrypted by typing the R/W test
menu option 87, as shown in Figure H-19. Alternatively, all other native operating system
backup and restore commands are available. Also, you can use the single read and write
function in ntutil.
Figure H-19 RW test function with SME enabled
Verifying encryption by using the Key Manager log
In the Key Manager audit log, you can see an entry, such as the entry that is shown in
Example H-3, after the RW write test for cartridge TDJ012.
Example H-3 Key Manger Audit log entry for 3592-E05/E06
Runtime event:
[timestamp=Sun Sep 13 13:48:30 MST 2009
ComponentId=[threadId=Thread[Thread-89,5,KeyManagementServerV2-Processors]]
event source=com.ibm.tklm.keyserver.ekm.logic.MessageProcessor
resource=[name=WriteRequest: Drive Serial Number: 000001326885 WWN:
5003013D3835A020 VolSer: TDJ012 Key Alias/Label[0]: cert01 Key Alias/Label[1]:
cert01;type=file]
action=stop]
Example H-4 shows an LTO4 log entry.
Example H-4 Key Manager Audit log entry for LTO4
Runtime event:
[timestamp=Tue Jan 20 11:08:05 CST 2009
ComponentId=[threadId=Thread[Thread-312,5,KeyManagementServerV2-Processors]]
event source=com.ibm.tklm.keyserver.ekm.logic.MessageProcessor
resource=[name= Drive Serial Number: 001310001123 WWN: 500308C09753C090
VolSer: 123456 Key Alias(DKI)/Label[0]: pfe000000000000000007;type=file]
action=stop]
The audit log is the only place where you can see which keys were used to encrypt a data
cartridge. You can also monitor your audit log in real-time mode while the test is running by
using the tail -f tklmaudit.log file for TKLM or the tail -f kms_audit.log file for EKM.
Encryption verification by using the library web GUI
This sections shows examples for TS3500 and TS3400.
TS3500 with LME enabled
For this encryption test, we use a TS3500 with LME enabled. Figure H-20 on page 983 is a
view of the cartridges that exist in the library prior to encryption. We run the ntutil R/W test
using cartridge VOLSER 447AAF. The window shows the VOLSER together with the media
identifier JA (447AAFJA). The column on the right in the example reflects that the status of
the cartridge is Not Encrypted.
Figure H-20 TS3500 cartridge encryption status prior to encryption
We mounted 447AAF to the drive and performed a write to the cartridge. After the write, we
closed and demounted the cartridge. Looking at Figure H-21, note that the cartridge status
has changed to Encrypted.
Figure H-21 TS3500 cartridge encryption status after encryption
TS3400 with SME enabled
We performed the same action on a TS3400 with SME enabled. Figure H-22 on page 984 is a
web GUI view of the cartridges that exist in the library prior to encryption. The window shows
the VOLSER together with the media identifier JJ (TDJ004JJ). The column on the right in the
example reflects that the status of the cartridge is currently Not Encrypted.
Figure H-22 TS3400 cartridges encryption status prior to encryption
We mounted TDJ004 to Drive 2 (with SME enabled) and performed the ntutil R/W test. After
the test, the cartridge status has changed to Encrypted, as shown in Figure H-23.
Figure H-23 TS3400 cartridge encryption status after encryption
Related publications
The publications listed in this section are considered particularly suitable for a more detailed
discussion of the topics covered in this book.
IBM Redbooks publications
For information about ordering these publications, see How to get IBM Redbooks
publications on page 988. Note that several of the documents referenced here might be
available in softcopy only.
IBM System Storage Tape Encryption Solutions, SG24-7320-02
IBM Midrange System Storage Hardware Guide, SG24-7676-01
IBM Tivoli Key Lifecycle Manager for z/OS, REDP-4472
SG24-7312
IBM System Storage DS8700 Disk Encryption Implementation and Usage Guidelines,
REDP-4500
Using IBM Tivoli Key Lifecycle Manager: Business Benefits and Architecture Overview,
REDP-4529
IBM System Storage Tape Library Guide for Open Systems, SG24-5946
UNIX System Services z/OS Version 1 Release 7 Implementation, SG24-7035
Communications Server for z/OS V1R7 TCP/IP Implementation, Volume 3 High
Availability, Scalability, and Performance, SG24-7171
IBM Virtualization Engine TS7700: Tape Virtualization for System z Servers, SG24-7312
Java Stand-alone Applications on z/OS Volume II, SG24-7291
Java Security on z/OS - The Complete View, SG24-7610
Communications Server for z/OS V1R2 TCP/IP Implementation Guide, SG24-5227
Other publications
These publications are also relevant as further information sources:
IBM System Storage Tape Enterprise Key Manager, Introduction Planning and User
Guide, GA76-0418
IBM System Storage TS3400 Tape Library Planning and Operator Guide, GC27-2107
IBM System Storage TS3500 Tape Library Operator Guide, GA32-0560
IBM System Storage TS3500 Tape Library with ALMS Tape System Reporter Users
Guide, GA32-0589
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
IBM TotalStorage Tape Device Drivers Installation and Users Guide, GC35-0154
IBM Tape and Medium Changer Device Drivers for AIX, HP-UX, Linux, Solaris and
Windows, GC27-2130
IBM TotalStorage 3953 Tape Frame Model F05 and Library Manager Model L05 Operator
Guide, GA32-0473
IBM TotalStorage 3494 Tape Library Operator Guide, GA32-0449
IBM System Storage TS3100 Tape Library and TS3200 Tape Library: Setup, Operator and
Service Guide, GA32-0545
IBM System Storage TS3310 Tape Library Setup and Operator Guide, GA32-0477
z/OS Security Server RACF Security Administrators Guide, SA22-7683

z/OS DFSMS Software Support for IBM System Storage TS1120 Tape Drive (3592),
SC26-7514
z/OS Cryptographic Services Integrated Cryptographic Service Facility Administrators
Guide, SA22-7521-09
z/OS V1R7.0 DFSMSdfp Storage Administration Reference, SC26-7402-05
z/OS V1R3.0-V1R8.0 DFSMS Software Support for IBM TotalStorage Enterprise Tape
System 3592 (Model E05), SC26-7514-02
DFSMS Object Access Method Planning, Installation, and Storage Administration Guide
for Tape Libraries, SC35-0427
z/VSE V4R1.0 Administration, SC33-8304
z/OS V1R11.0 Security Server RACF Command Language Reference, SA22-7687
z/OS UNIX System Services Planning, GA22-7800
z/OS V1R8.0 UNIX System Services Messages and Codes, SA22-7807
z/OS V1R8.0 Security Server RACF System Programmers Guide, SA22-7681
z/OS Security Server RACF Security Administrators Guide, SA22-7683
z/OS V1R7.0 MVS Initialization and Tuning Guide, SA22-7591-03
z/OS V1R7.0 MVS Initialization and Tuning Reference, SA22-7592-11
z/OS V1R7.0 MVS System Commands, SA22-7627-12
z/OS MVS Programming: Authorized Assembler Services Reference, Volume 1
(ALESERV-DYNALLOC), SA22-7609
IBM Ported Tools for z/OS Users Guide, SA22-7985
z/VM CP Planning and Administration, SC24-6083
z/VM CP Commands and Utilities, SC24-6081
IBM Tivoli Storage Manager for AIX Administrators Guide, GC32-0117
Related publications 987
Online resources
These websites are also relevant as further information sources:
IBM Encryption Key Manager component for the Java Platform:
http://www-01.ibm.com/support/docview.wss?uid=ssg1S4000504
IBM Encrypted Storage Overview and Customer Requirements:
Using the IBM Java FIPS approved Providers IBMJSSEFIPSProvider and IBMJCEFIPS:
Storage Networking Interface Association (SNIA):
For SNIA key management best practices charts, see this website:
http://www.snia.org/images/tutorial_docs/Security/WaltHubis-Best_Practices_S
ecure_Storage.pdf
For SNIA guidance and best practices documents, see this website:
http://www.snia.org/forums/ssif/programs/best_practices
Registration is required to download the following SNIA documents:
Best Current Practices: Provides broad guidance for organizations seeking to secure
their storage systems
SSIF Solutions Guide to Data at Rest: Provides baseline considerations and guidance
for factors to consider when evaluating storage security
For the SNIA Storage Security forum, see this website:
http://www.snia.org/forums/ssif/
IBM Tivoli Key Lifecycle Manager Quick Start Guide at this website:
elcome.htm
IBM Tivoli Key Lifecycle Manager Installation and Configuration Guide at this website:
elcome.htm
Tivoli Integrated Portal:
http://publib.boulder.ibm.com/infocenter/tivihelp/v15r1/topic/com.ibm.tip.doc/w
elcome_tip_ic.htm
Online CLI reference:
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.tklm.doc/r
ef/ref_ic_cli.html
DS Command Line Interface Users Guide for the DS8000:
http://publib.boulder.ibm.com/infocenter/dsichelp/ds8000ic/index.jsp
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
IBM System Storage TS3500 Tape Library Advanced Library Management System
(ALMS) and Encryption, by Anthony Abete:
IBM Virtualization Engine TS7700 Series Encryption Overview Version 1.1:
ftp://ftp.software.ibm.com/storage/Encryption/Docs/TS7700_Encryption_Support_V1
1.pdf
IBM Virtualization Engine TS7700 Series Encryption Overview:
3494 Bulk Volume Information Retrieval Function Users Guide white paper:
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP100430
National Institute of Standards and Technology (NIST)
See the NIST Computer Security Division Guidelines for Media Sanitation at this website:
http://csrc.nist.gov/publications/nistpubs/800-88/NISTSP800-88_rev1.pdf
IBM Java Keytool Users Guide:
http://www-128.ibm.com/developerworks/java/jdk/security/50/secguides/keytoolDoc
s/KeyToolUserGuide-150.html
JZOS Batch Launcher and Toolkit function in IBM SDK for z/OS Installation and Users
Guide:
http://www.ibm.com/servers/eserver/zseries/software/java/pdf/jzosinstal.pdf
Refer to the following website for information about ported tools and bash:
http://wwwibm.com/servers/eserver/zseries/zOS/unix/port_tools.html
Implementing your own security provider:
http://java.sun.com/j2se/1.4.2/docs/guide/security/HowToImplAProvider.html
Java SDKs:
http://www.ibm.com/developerworks/java/jdk/
Trusted Computing Group:
https://www.trustedcomputinggroup.org/home
How to get IBM Redbooks publications
You can search for, view, or download IBM Redbooks publications, Redpapers, Web Docs,
draft publications and Additional materials, as well as order hardcopy IBM Redbooks
publications, at this website:
ibm.com/redbooks
Help from IBM
IBM Support and downloads
ibm.com/support
Related publications 989
IBM Global Services
ibm.com/services
Index
Symbols
(DK 64
(RK 69
(TCG) 43
Numerics
1024-bit key length 5
128-bit secret key 5
13-6500 serial number 89
192-bit symmetric keys 953
2048 bits 954
256-bit AES data key 21, 58, 83
symmetric 21, 5859
256-bit AES keys 58
3494 Models B10 88
3494 Tape Library 77, 88, 100101, 103, 119, 131132,
192, 194, 203204, 206, 208, 214, 219220, 231, 571,
573576, 579, 582583, 599601, 614, 636, 639, 642,
668669, 692, 694, 698700, 988
3592 WORM 95
AIX 206
enabling drives for encryption 620
encryption checklist 867
encryption methods 82, 197198
encryption setup and implementation 617
encryption-enabled 217
HP-UX 213
i5/OS 206
libraries 215
library manager 217
library microcode level 534.31 223
library microcode level 536.0 223
Linux on System z 209
LME 197
logical in System z 125
mixed mode example 84
Model D22 100, 131
Model D22 frame 100
out-of-band 219
SME 74
System z attachment 127
TS1120 9697
TS1120 and TS1130 88, 224
TS7700 615616
encryption 625
prerequisites 222
3577-L5U 221
3580S4X 82
3590 Model B1x devices 233
3590-A60 enterprise tape controller 218
3592 93, 121122, 200, 219
3592 (Model S24) 129
3592 cartridge 94
3592 cartridge storage slots 122
3592 drive family 193
3592 drives 59, 9697, 121122
3592 media 89
3592 Model C20 Silo Compatible Frame 222
3592 Model E05 96, 233
3592 Model E05. 232
3592 Model J1A 89, 93, 233
3592 Model J70 101, 202203, 219
3592 tape cartridge 129
3592 tape controllers 219
3592 tape drives 59, 88, 97
3592 Write Once Read Many 95
3592-2 233
3592-C06 218
3592-E05 88, 90, 9597, 99, 200
3592-E06 9091, 95
3592-EU6 9091
3592-J1A 88, 93, 96, 122
3592-J1A configuration 103
3592-J1A drives 99, 222
3592-J1A tape drives 131
3592-J70 controller 97, 218, 223
3943 Library Manager 222
3952 Model F05 219
3952 Model J70 219
3952 Tape Frame 100
3953
Model F05 9698, 126, 194, 218219, 574, 625, 986
Model F05 Frame 98
3953 Library Manager 223
3953 logical Library Manager partitions 125
3953 Tape Frame 97
3953 tape system 98, 125
3957-V06 223
5655-N98 950
A
abstract server 79
AC power 33
access credential 32, 40, 53, 65
access credentials 53
access request 134
ACS routine 575, 589, 866, 868
activation key 807
Adleman 58
Advanced Encryption Standard
See AES
Advanced Library Management System
See ALMS
AES 4, 6, 21, 45, 54, 58, 60, 8283, 193, 238, 394,
397399, 437, 442, 459, 461462, 487488, 528, 559,
563, 721, 933
key 7
standard supports 128-bit block sizes 5
AES Key 34
AES key 60
AES wraps 39
AES_256_ITSO 4
agent 16
AIX 18, 22, 55, 74, 109, 128, 223, 965
AIX 5.3 50
AIX V5.1 207
algorithm 4
algorithms 21
alias/KeyLabel 559, 562
ALLOCxx 575
ALMS 122125, 131, 228
enabled 124
feature 123, 129
Virtual I/O function 125
alternate path
across multiple host ports 128
support 127
AME 49, 73, 78, 8183, 112113, 120, 130, 198199,
204, 206, 209210, 213214, 216, 220
APAR 201
OA16523 235
OA16524 235
ape cartridge 29
API 890
APIs 950
application layer 47, 73, 81
application performance 43
application usage 865
Application-Managed Encryption 59
See AME
applykey 807
APU 33
archive purposes 29
array 30
array encryption 776, 796, 807
Asianux 2.0 211
associated encryption key 4
asymetric key 53
asymmetric 4, 69, 17, 2122, 4950, 54, 58, 463464,
482, 543, 705706, 900, 911
encryption 4, 7, 9, 21, 58
encryption algorithms 4
key 67
key algorithms 7
asymmetric encryption 35
asymmetric key pair 71
asymmetric key pair. 71
asymmetric keys 964
ASYM-MK key 894, 899, 903, 905, 911
master 896, 899900
parts 543, 550, 552, 903, 911
Atape device driver 207
audit 849
auditability 42
authenticates 40
authenticating 36
authentication key 134, 136
authentication key. 134
authentication process succeeds 134
Auto Mode 119
Autoloader 111, 119
AUTOLOG 963
automated tape storage 120
automatic backup 962
Automatic Identification Manufacturers 107
auto-negotiates 92
autonomic self-optimizing capability 128
autostart job entry 452
availability 246, 846
B
B10 9192
backup 254, 848, 853, 856
Backup File column 254, 856
backup tapes 41
backup/restore facility 72
Band 0 38
band master 1 38
band settings 135
band0 135
Barcode Encryption Policy
See BEP
barcode reader 113, 119
barcode symbology 107
barcodes 130, 132
base frame 98, 121
Basel II 42
basic encryption 4
BEP 78, 130, 132
definition of 662
replaces SEP 662
binary file 19, 57
boot image 67
BOT 82
business partner 13, 29, 42, 54, 60, 458, 531, 554557,
559, 589, 608, 707, 720, 732733, 736737, 743, 747
certificate/public key 559, 562
encrypted tape 562
encrypted tapes 531
key 562, 747
public key 559, 562
tape data 29
C
C06 controller 100, 571
CA's signature 9
California law 42
call home communication 97
capacity expansion 217
Capacity On Demand features 122123
cartridge accessor 120
Cartridge Assignment Policy (CAP) 124
cartridge memory 89, 95, 107
cartridge memory (CM) 79
CBROAMxx member 869870
STORAGEGROUP statements 869870
CD-R 95
Index 993
CDS records 235
CE4785RACFKS 20, 57
centralized key management 81
CERTAUTH Label 501, 503504, 557558, 561
certificate 7, 910, 14, 22, 50
chain 13
entry 885, 887
information 11, 403, 463, 502, 513, 540, 713
management 10
repository 1113
request 1014, 501, 504, 509, 512, 558
response 1213, 419, 483, 501, 504
store 506, 508511, 711, 716717, 720, 733735,
737739
certificate authority 9
certificate authority (CA) 7, 11, 484, 507, 511, 513,
515516, 518, 555, 557558, 713, 716, 718
Certificate label 773
certificate replacement interval 852
certificates 9, 17, 44
channel calibration 89
channel ports 9192, 119
cipher tex 4
cipher text 4
ciphertext 1516, 37, 61
ciphertext, 15
CKDS 964
CKDS keys 964
CKDSes 964
CKDSes i 964
CLEAR 7980
clear key 34
client certificate 511513, 516517, 519521, 737, 739
ClientAuth 14
ClientAuthentication 14
coexistence PTFs 200, 864, 869
coexistence support 233234
COFVLDxx 575
command line 420, 434, 458, 483, 488489, 496,
522524, 533, 672, 882, 884, 886, 888, 955, 971
character limit 882
COMMNDxx 575
common scratch pool 222
communication paths 16
communication speed 135
CommVault Galaxy 227
company ZABYXC 1113
certificate response 12
complexity 42
computationally 7
computer environment 16
computer technology 4
computer-based cryptography 4
computing environments 105
configuration file 1819, 56, 410, 420, 437, 444, 448,
451, 453458, 478, 480, 491492, 508, 511, 517, 532,
534538, 565, 631, 647, 649, 659, 664, 669, 671, 685,
699, 703704, 706, 708, 720, 724, 729732, 749, 954
configuration options 57
configuration wizards 23
CONSOLxx 575
control data set (CDS) 235
control paths 125
controller 30
controller prerequisites 193
controller service requirements 76
Copy Export Function 103
Copy Services 810
CPF 127
Crypto Services 19, 56
cryptoerase command 135
cryptographers 4, 7
cryptographic 964
cryptographic capabilities 20, 23, 57
Cryptographic Coprocessor Facility (CCF) 528
cryptographic erasure 41, 62
cryptographic functions 20, 57, 952
cryptographic hardware 19, 56, 949
Cryptographic Key Data Set (CKDS), 953
Cryptographic Services 23
Cryptographic Services Integrated Cryptographic Service
Facility 964, 986
cryptographically 15, 39
cryptographically erase 41
cryptographically erased 33, 37, 41, 61, 134
cryptography 45, 58
CSFSERV 952
CU Encryption Configuration 218
customer data area 38
customer data region 40
D
D23 122123
D23 frame 122123
D23s 122
D53 123
D53 frame 123
data ciphertext 16
data class 235, 575, 870
performance segmentation 866
data compression 45
data encryption 61
data encryption keys 59
Data Encryption Standard (DES) 4, 953
Data Encryption Testing 965
Data Facility Storage Management Subsystem
See DFSMS
data key 25
data key (DK) 21, 29, 5859, 63, 68, 79, 81, 555, 894,
912
data migration 68
data path 81
data path failover 128
data protection 8, 41
requirements 42
data security 42
Data Security Standard (DSS) 42
DB2 755
DB2 tables 23, 51
DD statement 227, 590, 864, 878
DDM 32
deadlock 17, 34, 67
deadlock prevention 247, 847
deadlock situation 68
debug.output.file 956
decrypt 7, 910, 15, 18, 2122, 36, 50, 55, 58, 60, 134
decrypt a message 9
decrypt data 36
decrypted 8, 10, 21, 3637, 58, 81
decryption 80, 134
decryption data path 8
decryption key 15, 37, 61
decryption process 80
decrypts 30
default key 966
default value 457, 493, 659, 689, 887
degaussed 45
derived key 33
Developer Kit (JDK) 951
device adapter 33, 39, 62, 136
device driver 198
device external labeling 40
device interface 62, 136
Device Services Exit for z/OS V1R4 233
Device Services full function support APAR 233
device session key 63
DEVSUPxx 575
DEVSUPxx member 233, 865, 867
DFSA 754, 773, 794
DFSMS 47, 75, 199200
construct 614
DFSMSdss 235
DFSMSdss jobs 235
DFSMShsm 97, 234
dump classes 235
DFSMSrmm 227
Diffie-Hellman 7
Diffie-Hellman key exchange 7
digital certificate 910, 482, 506507, 703, 705, 708,
710, 732733, 743
digital signature 10
digital speed matching 89
digitally signed message 7
disable encryption 39
disclosure 16
disk cache 102
disk encryption 35
Disk encryption fundamentals 47
Disk Storage Feature Activation (DSFA) 754, 773, 794
disk-based encryption 43
DITTO 203
DK 25, 53, 6465, 79
Domain Name Server IP addresses 77
drive availability 81
drive canister 90
drive encrypted data key 64
drive encryption key 30
Drive Test 966
drive-level encryption 43
DS 33
DS command line interface (DS CLI) 804
DS5000 29, 135136
DS5000 Disk Encryption Manager 36
DS5000 firmware 29
DS5000 series 29
DS8000 22, 32, 34, 3739, 41, 49, 5253, 6065, 6970,
135136
DS8000 encryption solution 43
DS8000 GUI 63
DS8000 Hardware Management Console 136
DS8000 HMC 32, 37, 61
DS8000 power-on time. 62
DS8000 R5.0. 33
DS8000 server 33
DS8000s public key 53
DS8100 67
DS8700 6772
DSK 63
DSLIST utility 544, 907, 926
DSMFS 74
dual copy 103, 627628, 635, 637
dual Hardware Management Console (HMC) 850
dual keys 70
Dual Path Concentrator 219
Dual Platform Key Server 33
Dual Platform Key Server Support 34, 70
Dual Platform Key Server support 34
Dual Platform Key Server Support, 70
dump classes 235
DVIPA 963
DVIPA address 963
dynamic cross-system 963
dynamic partitioning 124
dynamic XCF setup 963
E
E05 drive 234
E05 drives 90
E1 93
E1 formatted media 91
E2 93
E3 93
EC705I 227
economical 44
Economy WORM 94
EE2 89
EE3 92
EEDK 25, 32, 64, 70, 7980
EEDK. 25
EEDKs 70
EEFMT2 234
EEFMT2-formatted cartridges 232233
efficient data storage 45
efficient encryption 9
EFMT2 89
EFMT3 92
EGK 39, 41
EGRK 69
EKM 1621, 23, 29, 34, 4951, 5360, 7380, 82, 84,
90, 97, 131, 191192, 197, 199, 203, 205, 207, 210211,
Index 995
213214, 218, 226227, 259, 575, 949950, 952,
954957, 959, 961964, 966
adddrive command 19
application 17, 55
assigned defaults 227
attach 219
capability 45
commands 19, 57
component 76, 200, 210, 213
configuration file
parameter requireHardwareProtectionForSym-
meticKeys 565
property 535
instance 408, 424, 558, 564, 958
instance, debug logs 564
interface 77
IP/domain addresses 77
keyring 556558, 561
planning and keystores 393
program 89
server 203, 227, 245, 397, 403, 410411, 416,
422423, 426, 450, 452453, 455, 457, 469, 502, 505,
507, 532533, 536538, 556558, 561, 602, 659,
671, 704706, 709, 720, 723, 725, 729732, 938, 940,
952, 959
authority 561
certificate 557558, 935
instance 557558, 561
EKM adddrive command 56
EKM code 952
EKM configuration file 956
EKM debug log 957
EKM implementation 964
EKM instance 958
EKM instances 957
EKM program 952
EKM program code 951
EKM validates 79
EKM, 962
EKMs audit 957
ekmlogs 958
EKMs 950
ekmserv ID 955
EKMSERV.ENCRYPT.CONFIG 958
ElGamal 7
elliptic curve cryptography 7
e-mail 768
emulation mode 90
enable encryption 39
enabling APAR 233
enabling encryption 53, 219
enciphered text 8
encoding mechanism 234, 555562, 599, 607, 609610,
864, 867, 944, 946
encrypt 7, 34, 43, 45, 60, 73, 7879, 81
encrypt all 116, 120
encrypt data 16
encrypt the data 30
encrypted 32
data 6, 10, 34, 4445
data on tape 49
message 7
tape 80, 83
volume 234
encrypted arrays 776, 796, 807
encrypted data 16, 53, 67
encrypted data key 16
encrypted data keys 16
encrypted data on disk 36
encrypted extent pools 783, 809
encrypted group key 64
encrypted ranks 780, 798, 808
encrypted storage 67
encrypted storage device 47, 67
encrypted/decrypted 135
encryptgrp 809
encrypting 27
Encrypting data 27
encrypting storage device 25
encrypting tape drives 50
Encryption 15, 34
encryption 15, 965
algorithm 8
capability 28, 89, 218
characteristics 193
code 21, 58
configuration 218
enabled 233
encryption and decryption 4
Encryption Authorization LIC feature key 754
encryption capability 28
encryption capable 966
encryption capable storage 134
encryption deadlock 17, 34, 37, 47, 6768
permanent 67
temporary 67
encryption deadlock. 47
encryption disabled 40
encryption enabled 4041
encryption environment 47
Encryption Facility 29
Encryption Facility for z/OS 29, 236
encryption failure unit checks 7677
encryption feature 134
encryption group 37, 3941, 63, 755, 772, 792, 806, 809
encryption hardware 60
Encryption key 16
encryption key 16, 21, 3233, 47, 58, 89, 134, 136
availability 16
security 16
encryption key labels 104
encryption key management, 61
Encryption Key Manager 22, 950
See EKM
Encryption Key Manager (EKM) 259, 951
Encryption Key Path Testing 965
encryption key. 16
encryption keys 16, 22, 43, 47, 227
encryption keys protected 45
encryption management 17
encryption management method. 59
encryption methods 4, 9, 49, 84, 196197, 209
encryption of tape data 45
encryption policies 17, 46, 49, 7375, 104, 132
implementation 197
management. 75
encryption policy engine 55, 73
encryption process 45, 79
encryption solution 29, 34, 43, 84
secure 34
encryption standard 21, 58
Encryption Storage Manager 35
encryption support 234
encryption technique 34
Encryption test 965
Encryption Test and Diagnostic Functions 965
Encryption test methods 965
encryption transforms 4
Encryption Verification 965
Encryption Verification using the ITDT-Graphical Edition
(GE 965
Encryption Verification using the ITDT-Standard Edition
(SE) 965
encryption-capable 39, 47, 61, 68, 79, 89, 233, 754
drive 77
LTO-4 tape drives 225
TS1120 drives 218
TS1120 tape drive device 866, 868870
encryption-capable devices 47, 67
encryption-capable DS8000 61
encryption-disabled rank 39, 62
encryption-enabled 16, 18, 32, 55, 81, 219, 234235
3592 device 234
drive 233
IBM TS1120 Tape Drive support 235
encryption-enabled disk 4950
encryption-enabled hardware 22, 50
encryption-enabled rank 39, 41, 62
encryption-related errors 7677
encrypts/decrypts 62
ENDAUTOLOG 963
End-to-End 965
Enterprise Automated Tape Library Specialist interface
78
Enterprise Encrypted Format (EEFMT) 92
Enterprise Format (EFMT) 9293
enterprise key management 29
enterprise-scale key management 17
enterprise-scale key management infrastructure 43
enterprise-wide 16, 49
environmental layers 17, 55
environments other than z/OS 104
EPI value 234
ERDS physical identifier (EPI) 233234
ESCON 97, 199, 218, 224, 226227
Ethernet service port 9091
Ethernet Test 966
Ethernet Test. 966
ETL Specialist
Management Class Definition 627
panel 625627
Stacked Volume Pool Properties update 634
Storage Group Definition screen 626
export EKM 421, 885
export or import 852
export volumes 60
exporting keys 256, 859
extended certificate chain 13
extent pool 39, 780, 798
encryption 783, 801, 809
extent pools 40
Externally Encrypted Data Key 79
externally encrypted data key 53
Externally Encrypted Data Key (EEDK) 25
externally encrypted data key (EEDK) 63
F
F05 model 98
failover 852
failover mechanism 128
fallback system 235
fast encryption 9
FC drives 61
FC0500 222
FC0520 218
FC1690 124, 217, 220
FC3478 221
FC4641 221
FC4862 219
FC5220 220
FC5247 219, 221
FC5592 217
FC5593 218219
FC5593s 219
FC5594 219
FC5595 218, 220
FC5596 217
FC5900 222
FC7004 222
FC9014 221222
FC9046 220
FC9592 217
FC9595 218
FC9596 217
FC9900 202, 204, 220, 222
FCRA/FACTA 42
FDE 29, 31, 36, 60, 754
FDE disk 36
FDE disk drives 43
FDE disks 35, 41
FDE drive 35, 3839, 60, 62, 134
FDE drives 39, 43, 6162, 134, 136
FDE feature 134
FDE hard disk 136
FDE mode 135
FDE premium 3031
FDE security 134
feature key 754
federal legislation 42
Fibre Channel 84, 88
Index 997
adapters 97
attachment 112
interface attachment 110
interfaces 9192
support 9192, 219
switch 98
switches 98
FICON 76
directors 103
in-band key flow 76
or ESCON 97
TS1120 97
TS3500 121
field replaceable unit (FRU) 89
File Transfer Protocol (FTP) 951
FILEE parameter 234
financial services 42
FIPS 20, 23, 53, 5758, 409, 952953
FIPS 140-2 certification 23
first rank 40
Fix Pack 1 50
fixpack 757
FlashCopy 772, 792, 810
flexible drive assignment 124
flexible solution 46
FTP 223
Full Capacity feature 122123
Full Disk Encryption 29, 53
Full Disk Encryption (FDE) 60
Full disk encryption (FDE) disk drives 43
Full Disk Encryption (FDE) drives 134
full function support 233234
G
Garbage Collector 890
GENCERT SUBJECTSDN 419, 429, 500501,
503504, 556558
general key server 848
generalized shared storage environment. 68
generalized storage environment. 68
GK 68
government-grade encryption 43
Gramm-Leach-Bliley Act (GLBA) 42
grid network 103
group key 40, 64
group key (GK) 65
GRSCNFxx 575
GUI 23, 52
H
HA1 frame 124
hardware configuration definition (HCD) 866
hardware levels 45
Hash 80
hash 64
Hash Pattern (HP) 549, 551, 899, 904, 916, 919, 924
hash value 7
hashed access 65
HBA 128
HD S54 129130
Hewlett-Packard servers 224225
Hewlett-Packard UNIX
See HP-UX
high availability configuration 124
high availability tape frames (3494-HA1) 131
high capacity tape media 107
High Density Capacity On Demand feature 123
High Density Frames 124
high resolution tape directory 89
High Voltage Differential 121
hlq.ZFS.AGGR 004 538539
HMC 61, 850
dual 850
redundant configuration 851
homogeneous 233
host bus adapters 9192
host-based compression 235
host-based encryption 235
HP 105
HP-UX 18, 55, 110, 213, 223
11.0 213
HSM) 70
HSMplex 234
HTTPS 756
human-readable characters 108
hwkeytool 59, 950, 964
hwkeytool command 953
hwkeytool commands 953
hybrid
encryption 9
encryption environment 692
methods 9
I
I/O attachments 227
I/O stack 47
I/O station 113, 125
i5/OS 18, 55, 204
V5.2 205
V5.3 205
IBM 46, 59, 966
IBM 31-bit SDK 59, 950
IBM 31-bit Software Developer Kit (SDK) 951
IBM 3592 122
IBM 3592 Cartridges 108
IBM 3592 Model J1A Tape Drive 89
IBM 3592 Tape Controller 220
IBM 3592 tape drives 88, 127
IBM 3592-J1A 222
IBM 3592-J1A Enterprise Tape Drive 222
IBM 3592-J70 Tape Controller 88
IBM 3953 Tape System 127
IBM Business Partner 754
IBM device driver 92
IBM Disk Encryption Manager 36
IBM Disk Encryption Storage Manager 35
IBM Disk Encryption Storage Manager managed keys 36
IBM DS8000 3132, 39
IBM EKM 951, 954
IBM encrypting tape drives 18, 55
IBM encryption capable drive 58
IBM encryption command set 82
IBM encryption enabled tape 22
IBM Encryption Facility for z/OS 192
IBM Encryption Key Manager 18, 5556
IBM Encryption Key Manager component 236, 952
IBM Encryption Key Manager for Java platform 29
IBM encryption-enabled tape drives 22, 50
IBM enterprise-class FDE disks 135
IBM FDE 32, 40
IBM FDE disk 41
IBM Fix Central portal 756
IBM Full Disk Encryption (FDE) technology. 133
IBM Integrated Cryptographic Service Facility 201
IBM Java Virtual Machine 20, 23, 53, 57
IBM JVM 952
IBM Lab Services 754
IBM Linear Tape-Open 87
IBM LTO 105, 123
IBM LTO Tape Libraries 87, 966
IBM LTO tape products 109
IBM LTO3 107, 111, 113
IBM LTO-4 half-high tape drives 113
IBM mainframe 224
IBM multipath architecture 119, 121
IBM patented Multipath Architecture 124
IBM Redbooks publications 192
IBM sales representative 754
IBM SDK 951
IBM Security page 44
IBM server 84
IBM server platforms 47, 68
IBM statistics 951
IBM storage data encryption techniques 34
IBM storage devices 41
IBM storage products 27
IBM System i 224225
IBM System p 224225
IBM System p running AIX 206
IBM System Storage xix, 27
Tape Drive TS1120 29
IBM System Storage DS5000 27
IBM System Storage DS8000 27
IBM System Storage Tape Library Guide for Open Sys-
tems 192, 986
IBM System Storage Tape Library Guide for Open Sys-
tems, SG24-5946 967
IBM System Storage Tape Library Specialist 78, 113
IBM System Storage TS1040 110
IBM System Storage TS1040 Tape Drive 104
IBM System Storage TS1120 xix, 27
IBM System Storage TS1120 Model C06 127
IBM System Storage TS1120 Tape Controller 95
IBM System Storage TS1120 Tape Drive 88, 91, 986
104
104
IBM System Storage TS2900 Tape Autoloader 104
IBM System Storage TS3100 Tape Library 78, 82, 104
IBM System Storage TS3400 Tape Library 120
IBM System Storage TS3500 Tape Library 78, 82
IBM System Storage TS3500 Tape Library with ALMS
Tape System Reporter 125, 986
IBM System Storage Virtualization Engine TS7700 102
IBM System x 224225
IBM System x 22
IBM System x3550 755
IBM System z 121
running z/OS 224
running z/TPF 224
running z/VM 224
running z/VSE 224
IBM tape 49
device driver 74
device driver installation 75, 225, 986
device driver installation guide 128
library 29, 75, 87, 121, 192, 227, 457, 480, 574, 704,
709, 864, 867, 869870
library environment 869870
IBM tape data 34
IBM tape data encryption 45
IBM Tape Device Driver 965966
IBM tape device drivers 213214
IBM Tape Diagnostic Tool 965
IBM Tape Diagnostic Tool (ITDT) 965
IBM tape drives 192, 967
IBM tape encryption 17, 45
IBM tape encryption solution 29
IBM Tape Library 965
IBM Tape System Reporter 125
IBM Tape Systems 966
IBM Tivoli Key Lifecycle Manager (TKLM) 43
IBM Tivoli Storage 81
IBM TotalStorage 3494 Tape Library 78, 87, 192,
985986
See 3494 Tape Library
IBM TotalStorage 3953 Library Manager Model L05 126
IBM TotalStorage tape device drivers installation guide
92
IBM TPF 103
IBM TS1040 Tape Drive 110
IBM TS1120 89, 91, 97, 102, 119120, 192, 233
IBM TS1120 Model C06 100
IBM TS1120 Tape Controller 9597, 99, 221
IBM TS1120 Tape Controller (3592-C06) 221
IBM TS1120 Tape Drive 88, 221, 233
IBM TS1120 Tape Drive devices 234
IBM TS1120-C06 98
IBM TS1130 92, 120, 126, 128
IBM TS1130 Tape Drive 8889, 92
IBM TS1130 Tape Drives 89, 104
IBM TS2240 108
IBM TS2340 109
Index 999
IBM TS2340 Tape Drive Model L43 109
IBM TS2900 Tape Autoloader 87, 111, 966
IBM TS3100 112
IBM TS3100 Tape Library 111, 113
IBM TS3100 Tape Library Express Model 87, 966
IBM TS3200 113
IBM TS3200 Tape Library Express Model 87, 967
IBM TS3310 116
IBM TS3310 Tape Library 87, 115117, 967
IBM TS3400 88
IBM TS3400 Tape Library (3577 Model L5U) 222
IBM TS3500 98, 125, 129
IBM TS3500 Models L23 and D23 frames 126
IBM TS3500 Tape Library 120121, 124125, 128130,
985
IBM TS3500 Tape Library interface 128
IBM TS3500 Tape Library provides 121
IBM TS3500 Tape Library Specialist 128
IBM Ultrium generation 3 105
IBM Virtualization Engine TS7700 102, 104
IBM Virtualization Engine TS7740 102
IBM Virtualization Engine TS7740 Cache Controller Mod-
el CC6 102
IBM Virtualization Engine TS7740 Cache Drawers Model
CX6 102
IBM z/OS V1.7 103
IBM z/TPF 103
IBM z/VM 103
IBM z/VSE 103
IBM_JAVA_OPTIONS (IJO) 881
IBMi5OSKeyStore 20, 57
IBMJCE 953
IBMJCEFIPS 20, 2324, 53, 5758, 952
ICSF 75, 542, 950
ICSF panel 547550, 552553, 895896, 900, 903, 909,
914, 922, 924, 928
ID EKM 954
ID EKMSERV 954
identity-proof 10
IECIOSxx 575
IEFSSNxx 575
IGDSMSxx 575
IKS 755
IKS) 70
ILEP 78, 112, 114, 116, 120, 130132, 467
scratch volumes 662
illegal accesses 134
import or export 852
importing keys 257, 859
inaccessible encrypted storage 67
in-band 75, 84, 218, 227
encryption 97, 226227
key 76
key management path 227
In-band Key Management. 966
INCITS 82
independent fabric 92
independent key servers 16
independently encryption-capable 68
initiate the key server 67
initiator 38, 41
input database 541542
Integrated Cryptographic Service Facility 75, 542
integrity (security) 16
Intel-compatible servers
Microsoft Windows 2000 Server 224
interchange 81
Interim Fixes 1A 50
Intermediate Capacity feature 123
internal boot devices 47, 68
Internal Label - encrypt all 112, 114, 116, 120, 132
Internal Label - selective encryption 112, 114, 116, 120,
131
Internal Label Encryption Policies
See ILEP
Internet banking 42
IP addresses 39
IP port settings 966
IRR 954
ISMF 575
isolated key server 22, 755, 767, 848
isolated key servers 34
ISPF 951
J
J1A 89, 92
Emulation mode 96, 103
performance 90
J70 Tape Controller 101, 571
JAR 956
JAVA 952
java application 565, 878
Java Cryptography Extension 20, 52, 57
Java Cryptography Extension (JCE) 23
Java Developer Kit (JDK) 880, 889890
Java home 955
Java Native Interface (JNI) 878
Java Runtime Environment (JRE) 889
JAVA SDK directory 951
Java Security components 23
Java security components 20, 52, 57
Java security keystore 20, 23, 52, 57
Java Security on z/OS 964, 985
Java Virtual Machine 950
Java Virtual Machine (JVM) 880882
JAVA_HOME 955
java.io.permission errors 956
JB cartridge 88
JCE 20, 23, 52, 57
JCE4758KS 20, 57
JCE4758RACFKS 201
JCECCAKS 59, 953, 964
JCECCAKS file 964
JCECCAKS keystore 964
JCEKS 20, 57, 758
JCEKS keystore 23
JCERACFKS 20, 57
JECKS key store 555, 560
JES3 575
JES3 INISH deck 575
job entry, autostart 452
Just-In-Time (JIT) enabled 881
JVMs 955
JZOS 952
JZOS batch
launcher 423, 878, 882, 957
technology 878
JZOS EKM 955
JZOSEKM 954
jzosekm.jar 955, 957
JZOSEKMFiles.pax.Z 957
K
KEK 63, 7980
label 79
OCE 234
stored in EEDK 79
Key Administration 762
key alias 966
key change 893894, 896, 902, 906, 909911, 913, 925,
929
key ciphertext 16
key database 495
key distribution 6
key encrypting key
See KEK
key encrypting key (KEK) 63
key exchange 54
key flow 76
Key ID 54, 60
key label 39, 59, 63, 234235, 410, 429, 458, 477478,
492, 496, 503, 511, 518, 533, 536, 554, 556558, 561,
568, 570, 589, 592, 599, 607, 609610, 634635, 638,
664, 667, 685, 697699, 707708, 736, 747, 867, 940,
944, 946
key label pair 63
key labels 24
Key Lifecycle Manager (TKLM) 17
key management 1617, 21, 49, 62
internal/external handling 17, 54
key management approach 29
key management facility 21
key management mechanisms. 66
Key Manager 962963, 966
key manager 82
required or not 17, 49
software 29
Key Manager Config Test
966
Key Manager IP Address 966
Key Manager logs 965
Key Manager SSL 962
key method 24
Key negotiation 62
key part 542543, 548552, 708, 747, 894, 898900,
904, 910911, 916, 919, 923924, 929
Key Path Diagnostic 966
Key Path Diagnostic test 966
Key Path Diagnostics Test 966
Key Path test 967
Key Server 71
key server 1617, 34, 47, 6768, 72
backup 848
general 848
isolated 848
key server application 24, 67
key server implementation 17
key server operational 17
key server. 16
key servers data 16
key servers 17, 24
key services 24
key size 419, 483, 487, 493, 497, 511, 513, 517, 556
key store 444, 447, 469, 707, 730, 867
key symmetric keys 52
keyboard video mouse (KVM) switch 126
key-encrypted 11
keygroups.xml 260
keylabel option 964
keyring 403, 418419, 423, 428429, 482, 500502,
504505, 508, 510, 514, 524, 540, 556558, 561, 932,
934935
keys
exporting 256, 859
importing 257, 859
keys and certificates 19, 5657
keys secure 15
keyservers 71
keysize 434435, 463465, 483, 487488, 498, 528,
556558, 560, 721, 886, 888
keystore 20, 23, 29, 47, 5152, 54, 5758, 60, 67, 7980,
84, 192193, 197, 201, 227, 238, 393394, 397,
400405, 407411, 414, 416418, 421423, 426, 428,
430431, 434437, 445, 448, 451, 455, 457, 463465,
467468, 472, 478, 481484, 486491, 495498, 502,
505508, 510, 513, 518, 520, 522524, 528529,
531532, 534536, 538, 540, 554556, 559564,
572573, 575576, 589, 599, 607608, 617, 632, 638,
646, 649651, 659, 664666, 683684, 697, 702,
704706, 708709, 715716, 720722, 731733,
736737, 743, 846, 864, 885888, 932934, 940, 950,
952953, 956, 959, 963
types 20, 58
keystore data 67
keystore file 251, 854
keystore hardware 70
keystores 23, 950, 952
keytool command 463, 886, 888
keyxfer 964
KM 966
KM communication test 966
KM server 966
L
L frame storage capacity 124
L12 model 219
L22 model 121
Index 1001
L23 frame 121123
L53 frame 122123
Label - Encrypt All 198
label specification for 3592 94
LAN/WAN 84
landfill 95
last rank 40
LBA space 135
legislation 42
liability 42
library accessor 125
library layer 47, 73
Library Manager 100, 125, 220, 574
attached logical library 126
licensed internal code 217
licensed internal code level 535 217
licensed internal code level 536 217
logical partitions 124126
PC 220
user interface 104
Library Manager Console 227
library Operator Panel functions 112, 116
library robotics 125
Library Specialist 112
or the 3494 Library Manager 217
Library-Managed 966
Library-Managed Encryption 78
See LME
Library-Managed Encryption (LME) 965
licensed internal code 28
Lifecycle 22
lifecycle functions 51
lifecycle key management functionality 49
lin_tape device driver 210211
linear data sets (LDS) 540
Linear Tape-Open
See LTO
Linux 18, 55, 74, 109, 210211, 767
servers 109, 224225
LME 29, 45, 49, 58, 7374, 7779, 81, 111112, 114,
120, 130, 132, 191, 206207, 209211, 213214, 216,
219220, 222, 227, 966
Barcode Encryption Policy 198
encrypt all 198
implementation 89
load balancing 92, 128
LOADxx 575
locked 40, 62
locked area 135
locked customer data region 40
locked FDE disks 41
locked region 40
Locking 41
locking mechanism 134
Logical Library 967
logical library 114, 116
Logical Library 2 967
logical Library Manager partitions 124126
logical partition
See LPAR
Logical Unit Number (LUN) 127
logical volume manager 47
logical volumes 3940, 103104
LPAR 60, 124126, 543, 705, 896, 909, 913, 924925,
929
LPARs 964
lsarraysite 807
lsextpool 810
lskeygrp 806
lskeymgr 805
lsrank 809
LTO xix, 1921, 2728, 50, 54, 5658, 60, 78, 82,
104108, 110111, 115, 120121, 123, 131, 206208,
212, 215, 219220, 222, 228, 464, 478, 488, 702703,
730
compliant drives 105
drive 123
drives 123
encryption 111
format cartridges 105
media 123
organization 105
specified products 105
tape library 104
technology 105, 109
Ultrium 1 106
Ultrium 3 106
Ultrium 4 78
Ultrium Generation 4 tape drive 28, 54, 60, 82, 105
Ultrium manufacturers 105
Ultrium tape drive 105106
LTO 4 23
LTO-1 106
LTO-2 28, 106, 229
LTO-3 28, 106107, 112113, 115, 123, 228
drives 113
half-high tape drives 112
non-WORM 107
WORM 107
WORM media 107
LTO-4 17, 21, 2829, 35, 55, 58, 105110, 112116,
123, 192193, 195, 197, 200, 205, 207216, 219220,
223, 225, 227229, 238, 393396, 399402, 410, 452,
454456, 458, 463464, 466, 472, 475476, 480, 482,
487, 489, 506, 528529, 554555, 559, 563, 701703,
705709, 720722, 725, 730, 732, 744746, 748
cartridges 59, 112113
drive 112, 116
drives 112113, 116
encryption 29, 58
tape drive 29, 59, 113, 216, 219
LTO4 950
LTO4 cartridges. 953
LVD/SCSI 112
M
main ICSF panel 547, 549550, 552, 895896, 900, 903,
905
main ISPF panel 544, 894, 906, 912
MAINARGS DD 880
Managed Encryption 966
Management Class 104, 575
Definition screen 627
select one 628
Management Interface (MI) 104
master key (MK) 548552, 894, 900, 924925
master key encrypted entries 953
Master Keystore 757
mastered servo pattern 95
maximum configuration 33
media type 94, 107, 221, 233234, 596, 725, 865867
MEDIA9 233
Medium Changer commands 124
MES installation 754
Message integrity 10
metadata 78, 120, 131
Microsoft Windows
TS2340 models attach 109
Microsoft Windows 2000 Server 225
Microsoft Windows 2008
operating system environments 223
Microsoft Windows 22
midrange 105
Migration wizards 23
migration wizards 51
mixed environment 234
mkarray 807
mkextpool 809
mkkeygrp 806
mkkeymgr 805
mkrank 808
Model C06 219
Model C06 tape controller 96, 217
Model C10. 219
Model E05 tape drives 233
Model EU6 101
Model J1A 89
Model J70 218
controller 96, 101
Models L52 110
modular 102
monitoring 847
MSID 135
MSID value 135
MTL 575
Multi Cluster Grid configuration 634
Multipath Architecture of the IBM TS3500 Tape Library
125
multiple platforms 45
multi-site TKLM environment 72
MVS 950
MVS panel 894, 912
N
native drive 574
attachment 125
Native SMI-S Support 124
ncryption hardware 60
NetBackup 112, 114, 116, 132
See also Symantec NetBackup
Netfinity 121
network 43
network access 84
no-charge FC9900 222
NOLOCKINPUT parameter 542
non-encrypted 67
non-encrypted storage 47, 67
non-encrypting tape devices 235
non-encryption-capable drives 222
non-erasable 107
non-FDE disk 41
non-removable storage device 25
non-repudiation 10
non-reversible screws 95
non-rewritable tape media 95
non-TS1120 tape cartridge data 236
non-WORM cartridges 107
NVS 33
NVS memory 33
O
OA15685 200
OA16523 235
OA16524 235
OA17562 200
OA18111 200
OA22118 200
OA22119 200
OAM 234235
object 234, 869870
support 234
tape data 869
tape environment 870
OAMplex 200, 234, 869870
obfuscated 33
OMVS 950, 952953, 955
OMVS file system 955
on demand features 103
OPEN processing 89
Open System SME environment 966
Open Systems 29, 47, 84, 87, 9192, 118120, 125,
220221, 405, 890
attached 217
attached library 119
attached partitions 125
attached TS1120 drives 217
device drivers 225
environment 45, 9192, 125, 198
hosts 119, 125
IBM tape libraries 192
LME 220
operating systems 199
partition 126
platforms 119, 193
server 84
operating system 77, 119, 191193, 196197, 199, 204,
223, 394, 396, 437, 572, 575576, 585586, 600, 651,
867, 886887, 889
choosing encryption method 196
encryption compatibility AIX 647
Index 1003
encryption management 29
encryption policies 668
Java 463, 890
Linux on zSeries 76
management 676
Open Systems 225
upgrade server 649
z/OS 617
operational key server 17
Option
2-Set MK 550
4 CHECKSUM 897, 915
OSLME 220221
outboard policy management 103, 625
Out-of band Key Management 966
out-of-band 76, 97, 202, 218
support 76
Out-of-band encryption key flow 76
out-of-band support. 76
P
PARMLIB member 233, 430, 576, 586, 864, 867, 870,
908, 928, 942
PATH 955
Path Failover feature 128
Payment Card Industry (PCI) 42, 527528
PCICC keyword 419, 503, 556558, 560
PDS 958
performance impact 43
performance scaling 866867
permanent data loss 134
Permanent encryption deadlock 67
permanent encryption deadlock 67, 755
permanent erasure 43
persistent copy 25
personal certificate 1113, 428429, 501, 503504, 526
physical capacity 88
physical cartridge pools 103
physical media 104
physical VOLSER range 574
PKCS11IMPLKS 20, 57
pkcs12 file 484, 497498, 564
PKDS 418419, 497498, 502503, 527, 540, 543,
545546, 552553, 556558, 560561, 564, 894896,
900902, 905906, 908, 910911, 925, 953, 964
PKDS, 964
plaintext data key 16
policy 81
control and keys 78
granularity 47
implementation 47
PORT 962
Post-Key Change - All (PKA) 543, 553, 894895, 902,
906, 909
preconfigured path 128
prerequisites 572
Primary Key 69
private key 4, 611, 13, 21, 58, 79, 230, 410, 419, 452,
463, 466468, 478, 482484, 489, 497498, 500,
502503, 505, 509, 518, 520, 522524, 526, 555559,
561564, 599, 608609, 638, 644, 662, 664667,
683684, 697, 707708, 720722, 732733, 736, 739,
885, 887, 932
key label 556558, 561
PROCLIB 955
PROCLIB.EKM2 955
programmatic 128
propagate keys 34
protected information 42
provider
IBMJCE 457, 555, 560
IBMJCE4758 556
provisioned 47
PSP 200, 223
PTF 201, 203, 234235
public key 68, 1013, 21, 54, 58, 60, 71, 7980, 230,
410, 435, 466467, 478, 482484, 489, 498, 502, 505,
524526, 554556, 559564, 599, 607610, 638, 662,
664, 666667, 683684, 697698, 707708, 732733,
736737, 740743, 747, 885, 887, 932
Cryptographic Standard 890
enciphered copy 10
encrypted copy 1112
encrypted version 11
encryption 78
Hash 555560, 562
new encrypted copy 12
Public Key Data Set (PKDS) 954
Public Key Infrastructure (PKI) 10, 13
public keys 7071
public-key encryption 7
public-private
encryption algorithm 21, 58
public-private key pair 69, 452, 483, 497, 503, 509, 527,
555556, 559, 562, 609, 720, 732
encryption 7
Q
quick reference encryption planning 193
R
R4.3 34
R5.0 34
RACDCERT 952
RACDCERT command 201
RACDCERT GENREQ 501, 504, 558
RACDCERT Id 503, 556558, 560
RACF 44, 75, 201, 414, 540541, 556557, 954, 957
RACF administration 953
RACF authority 556558, 561
RACF Security Administrators Guide, SA22-7683. 957,
986
rack-installed 99
RAID 778, 785
RAID 6 33
rank
encryption 780, 798, 808
ranks 41
Read/Write Accessible 31
Read/Write cartridges 94
real time 42
receiver 7
record retention. 107
recording format 233
recording technology 93, 221, 234, 592, 596, 865866,
870871
recover data 43
Recovery Key 34
Recovery key 69
Recovery key user 34
Red Hat 22, 50
Red Hat AS 4.0 50
Red Hat Enterprise 22, 50
Red Hat Enterprise Linux 22, 210
Red Hat Enterprise Linux 4 210211
Redbooks Web site 988
Contact us xxi
Redundancy 16
redundancy 37
redundant HMC configuration 851
redundant key servers 24
regulations, security 44
regulatory burden 42
rekeying 54, 60, 95
release level 234
remote management 119
remote management unit
See RMU
Remote Mirror and Copy 772, 792
removable media device 25
Resource Access Control Facility
See RACF
restore 254, 853, 856
retrieval performance 120
Rijdindael algorithm 6
riskier environment 42
Rivest-Shamir-Adleman
See RSA
RK 69
RMM 235
RMMplex 235
RMU 112113, 116, 119
Ron Rivest 21
rotation of certificates 22, 51
rotation of groups of keys 22, 51
RS/6000 9192
RSA 5, 78, 21, 54, 58, 60, 79, 201, 397, 434435, 463,
483, 497, 501, 503504, 525, 527, 556, 558, 598, 644,
721, 886888
RSA keys 54
rules and regulations 43
S
S1120 216, 218
S24 frame 123
S54 frame 123
sample digital certificate 10
sample JCL 424, 879880, 910, 957
SAN environment 128
SAS 109
SAS-attached TS2340 tape drives 109
SCHEDxx 575
scratch cartridge 666
scratch volume 233
SCSI 124
SCSI library 125
SCSI Medium Changer 125
SCSI Ultra160 LVD attachment interface 113
SECADM 69
second accessor 121
secondary key path 7677
secondary TKLM 72
secret key 5
algorithms 5
encryption 4
secrets 16
SECURE asymmetric key processing 950
secure asymmetric keys 20, 57
Secure Drives option 31
secure infrastructure 29
secure key mode 70
secure partition 135
Secure Shell (SSH) 955
SECURE symmetric key processing 950
SECURE symmetric keys 59
SECURE symmetric keys. 957
security 16, 20
Security Administrator 34, 69
security benefits 964
security breaches 41
Security Capable 31
security capable drive 30
Security enabled 31
security enabled 31
security exposure 15
security key 3031
security layers 42
security locked state 30
security setting 135
security-enabled drives 3031
security-enabled drives, 31
SEDK 25, 54, 65
self-management capabilities 102
self-signed certificate 10, 429, 483, 493494, 500, 503,
507, 513, 555557, 718, 720, 953
sensitive data 44
SEP
replaced by BEP 662
Serial Attached SCSI (SAS) 112113
serial number 10, 89, 217, 402, 457, 499, 533, 535536,
566, 569, 591, 599, 609, 611, 685, 708, 730, 938, 940
server identities 14
servo format 95
session encrypted data key 53
SFIs 60, 761
SG24-4632 192
SG24-7312 192
shared public key 10
SHAREOPT 962
Index 1005
short length 94
SID 135
silo 97, 224
Simple Network Management Protocol
See SNMP
single security implementation 43
SME 21, 29, 49, 59, 7376, 79, 81, 84, 89, 97, 103, 110,
112113, 116, 120, 130132, 191, 195, 197, 199200,
202203, 206207, 209210, 213214, 218, 220, 222,
226, 393, 480, 575576, 585, 599, 614615, 620, 622,
641643, 645, 647, 650, 668669, 672, 674, 676,
678679, 682684, 686687, 689, 691, 867
SMI-S interface 128
SMIT 7677
SMStape 97
SNMP 112113, 768, 847, 849
traps 116
software 9192, 395396, 398, 400, 414, 431, 434, 438,
599, 614, 623, 891, 939, 986
cryptographic features 236
programs 44
software development kit (SDK) 889
software stack 67
software-based 20
Solaris 50
See also Sun Solaris
Solaris 10 Sparc
See also Sun Solaris
Solaris 9 22
specified URL
configuration file 534
SSH client 884
SSL 14, 54
cipher 14
handshake
acceleration 527
SSL connection 954
SSR 97, 217218
stand-alone environment 232, 864865, 869870
new encryption-capable TS1120 tape drive devices
869870
STARTED class 957
StartServer.bat 765
static char 523
statistical analysis 89
STGADM) 69
StopServer.bat 766
Storage Administrator 34
storage administrator 47, 67
storage array 3031
Storage Class 575
storage device 25
storage device clients 67
storage devices 16
Storage Element 124
storage facility image 41
Storage Frames 121
Storage Group 104, 204, 575, 626
storage hierarchy 102
storage management tools 47, 68
Storage Manager GUI 136
storage pool 104, 613
storage subsystem 47, 68
Storage Virtualization Engine 104
STORAGEGROUP statement 869870
StorageTek 95
stored data encryption 42
storetype JCE4758KS 556, 560
storetype JCEK 555
Streaming Lossless Data Compression (SLDC) 89
String timeInfo 567
StringBuffer 567568
Subject Distinguished Name 10
subordinate storage arrays 47
subsequent LPARs 896, 902, 911, 913, 922
Subsystem 24
Sun Server 22
Sun Solaris 18, 55, 112113, 116, 213
servers 224225
Sun Solaris 8 213
Sunguard 20, 57
SUSE 22, 50
SuSE Linux Enterprise Server 22
SUSE Linux Enterprise Server 9 50, 210211
Symantec NetBackup 227
Symantec Netbackup 78, 131132
Symbol Specification (USS-39) 107
Symmetric 21
key encryption 21, 58
symmetric 47, 9, 17, 2122, 4950, 54, 58, 242,
401402, 410, 454, 458, 463464, 468, 478, 482,
486489, 506, 528, 534, 543, 554, 559, 563, 703,
705706, 720722, 730, 732
AES encryption, 5
data key 9
encryption 45
key 4, 21, 58
key encryption 5, 7
symmetric data key 53
symmetric encryption 5, 16, 31, 43
Symmetric keys 23
symmetric keys 953, 957
symmetrically encrypted information 5
SYM-MK key 543, 912, 914915, 918920, 922
SYM-MK master
key 919, 921922
key part 549
SYS1.PARMLIB 575
SYS1.PROCLIB 957
SYSIN DD 540
Sysplex 235, 963
958
sysplex 963
Sysplex Distributor 963
Sysplex environment 564
System 199
system
data 43
layer 47, 73
system assurance call 754
System Control Program 950
System Display and Search Facility (SDSF) 878
System i 204
System i5 204
System Managed Storage 96
System Mode 119
System p 109, 210
System Storage Interoperation Center 119, 224
System Storage Productivity Center 755
System Storage Tape Library Specialist 116
System z 88, 92, 120, 125, 209, 223
990 527528
Application Assist Processor 890
attachment 119120, 124
environment 74, 91, 120, 131132, 197
ESCON 218
hardware 126, 404, 890
hosts 104
server 8889, 125, 127, 404, 527
servers 95
System.err.println 523, 525, 567
System.out.println 523525, 567568
System-Managed Encryption 965
See SME
system-managed tape library 233
T
T10 82
tape
assets 199
cartridge scratch pool 218
cartridge volume 234
compression 34
controller 202, 226
controller requirements 220
controllers 120
tape cartridges data key 54, 60
tape configuration database (TCDB) 233
tape drive 6, 19, 2829, 34, 45, 49, 5354, 56, 5860,
7576, 7982, 89, 104, 107, 112, 120, 128, 192193, 195,
198, 200201, 203205, 207208, 210211, 214215,
221, 225226, 394395, 402, 404, 407, 409, 411, 448,
454, 457, 507, 533, 535, 572, 574, 576, 579, 582, 584,
586, 599, 605, 615, 618, 647, 649651, 665666, 669,
672, 678679, 681, 683, 685, 701702, 728729,
938939, 971972
encryption 46
encryption keys 29
outboard encryption 45
serial number 535
tape drive combinations 209
Tape Encryption 189
tape encryption 46, 15, 27, 29, 3435, 4445, 49, 73,
81, 84, 87, 89, 9596, 101, 119, 121, 191193, 196, 199,
203, 206, 226, 230, 235236, 406, 408409, 414, 417,
435, 455, 481, 571573, 585, 587, 591592, 596, 607,
612614, 616, 623, 702, 706, 709, 721, 931
process flow 3435
tape encryption function 220
Tape encryption fundamentals 46
Tape Encryption management 29
tape encryption solutions 964
Tape Frame 100
tape infrastructure 29
tape interchange 77
Tape Library configuration 131
Tape Library Models L23 220
Tape Library Operators Guide 78
Tape Library Specialist Web interface 131132
tape library subsystems 18, 55
Tape Library Web interface 217
tape media 54
tape solutions 84
Tape System Reporter 124
tape virtualization 102
TCDB 575
TCP/IP 32, 37, 5354, 59, 76, 116, 949, 962963, 966
TCP/IP connection 227
TCP/IP network 39
TDES (triple DES) 5
technology provider companies 105
Telecommunications 43
Telnet 955
Telnet client 884
temporary encryption deadlock 67
TEPEVER 234
TEPMCRYP bit 234
The IBM FDE technology 135
The IBM System Storage TS3400 Tape Library 118
The parameter 457
theft of data 42
third party 7, 501, 504, 555, 557558
third-party certificate 953
Tier 0 slots 129
Tier 1 cartridge 129
timestamp 565566, 569, 647, 932
Audit crawler 567
errors 933
TIP 22
TIP installation manager 51
Tivoli Integrated Portal 23, 51
Tivoli Integrated Portal (TIP) 22, 756
Tivoli Key Lifecycle Manager 49, 755
See TKLM
See TKLM
Tivoli Key Lifecycle Manager (TKLM) 24
Tivoli Storage Manager 17, 50, 54, 8183, 199, 216, 252,
854
TKLM 16, 2125, 29, 32, 41, 4955, 60, 6365, 7073,
89, 131, 191, 227, 966
CLI 53
command line interface 52
components 51
configuration file 251, 854
database 251252, 854855
failover 852
file 51
primary 227
TKLM CLI, 23
TKLM command line interface (CLI) 23
Index 1007
TKLM key serve 62
TKLM key server 32, 47, 62, 67
TKLM key servers 37, 39, 61
TKLM on xSeries 72
TKLM server 38, 6263
start 765
stop 765
TKLM V1.0 70
tklmCertExport 71
TKLMs 67, 7071
toleration APARs 235
toleration PTFs 235
TotalStorage 3952 Model C20 216
TotalStorage Productivity Center 116
TPC-BE 18, 56
transit 10
Transparent LTO Encryption 222
triple DES (TDES) 4
TRUST WITHLABEL 419, 501, 558, 560
trusted certificate 14
truststore 14
TS1040 Tape Drive 110
TS1100 53, 949
TS1100 tape drive 953
TS1120 Tape Drive 19, 21, 2829, 54, 56, 5860, 75, 82,
8793, 97, 99101, 103104, 118120, 127, 132,
192193, 195, 199200, 207, 209, 216225, 231235,
476, 572, 574, 576, 596597, 641, 648651, 666, 669,
864866, 869, 965
controller 9698, 221
controller (3592-C06) 218
controller (3952-C06) 199
controller Model C06 88
devices 234
encryption 220
Model C06 9596, 98100, 125, 218219
Model C06 controller 97, 219
Model C06 Tape Controller 88
Model E05 97, 233
tape drive 28
Model E05 devices 233
support 234
TS1120 Tape Encryption 236
TS1130 60
TS1130 Tape Drive 29, 9293, 97, 99100, 103, 120,
122123, 192, 216, 218, 220224, 227
TS1130 Tape Drive ALMS 220
TS1130 Tape Drive characteristics 91
TS1130 Tape Drive encryption 58
TS1130 Tape Drives 102
TS2240 108109
models 109
TS2340 225
Model S43 109
models 109
tape drive 105
TS2900 111
tape autoloader 225
TS3000 System Console 126
TS3100 78, 105, 111112
tape library 112, 213, 216
TS3200 78, 113, 206, 209, 214
TS3310 78, 115116
configuration 116117
library 116
Model E9U 116
tape library 116
TS3400 967
TS3400 Tape Library 78, 82, 8788, 9597, 99100,
118120, 192, 194, 196197, 200201, 203, 205206,
208209, 212215, 217, 219, 221, 224, 571, 573,
575576, 583, 585, 599600, 602, 604, 702, 723, 867,
985
TS3500 Tape Library 74, 7778, 82, 84, 8788, 9598,
101, 103104, 110, 119131, 192194, 196198,
200201, 203204, 206210, 212215, 217218, 220,
222, 224225, 228229, 458, 472473, 476, 480, 571,
573576, 599600, 614618, 621, 625, 641643, 647,
650652, 662663, 668669, 672, 674, 694, 697, 702,
706708, 722724, 729731, 744, 746747, 867, 965
attachment 130
frames 121
includes Storage Management 128
Model Dxx expansion frame 124
TS3500 Tape Library Specialist 124
TS7000 Virtualization Family 102
TS7700 103
TS7700 Virtualization Engine 7577, 8788, 9092, 98,
102104, 125126, 192, 194195, 199, 202, 204, 216,
222223, 232, 571, 574, 613620, 622624, 626629,
631632, 634635, 637638, 864865, 867868
(3957-V06) 223
encryption 222
encryption function 223
microcode level 8.2.0 27 223
TS7700s 103
TS7720 102
TS7740 102, 125, 127
TS7740 Cache 103
TS7740 Server 103
TSO 950
two public keys 7071
Twofish 5
U
U.S. Government 4
UCB class extension as X13 233
UCBCXEPI field 233
UID 954
UK24398 203
UltraScalable Tape Library Specialist 128
Ultrium 131
Ultrium Generation 4
drives 105
media 210, 213214
tape drives 18, 55
tapes 21, 58
unauthorized user 43
uncompressed tape 103
unencrypted tapes 236
unencrypted workloads 45
unified keystore 949
UNIX System Services 414415, 417, 420, 482483,
497, 502, 540, 575576, 617, 877879, 932, 942,
950951, 953954, 986
UNIX System Services in z/OS 950
unlocked 62
unlocked region 40
unlocked space 135
Unlocking 39, 41
unlocking credentials 53
unscramble data 21, 58
up-level recording format 233
URL 534, 653, 710, 733, 884, 891, 988
usability enhancements of EKM 51
USB device 543, 898, 904, 910911, 917, 923, 929
V
V1.0 of TKLM 50
valid drives 80
validity date 10
validity period 13
vault 17, 47
verifying the Atape driver installation 672
Virtual Backhitch 89
virtual I/O slots 124
Virtual Machine 24
virtualization 67
Virtualization Engine 75, 77, 8788, 9092, 102103,
125, 127, 192, 194195, 199, 202, 204, 216, 222223,
232, 571, 574, 613616, 623624, 628, 632, 634, 639,
868
Virtualization Engines 103
VOLSER 83, 124, 204
volume group 31
volume pool
stacked cartridges 632
volume serial numbers 47, 130, 132
volume serial ranges 130, 132
VT100 terminal 882, 884
VTS 98, 102103, 125, 127, 574, 624, 628
release 2.32.745.xx 90
vulnerability management 45
W
Web GUI 967
Web Server 962
WebSphere 962
WebSphere Application Server 23, 51
WebSphere SSL 962
Whitfield Diffie 7
Windows 18, 23, 5051, 55, 74, 767
Windows 2000 Server 214
Windows Server 22, 50
Windows Server 2003 50
Windows Server 2008 22, 50, 224225
Windows Server 2008 64-bit 22
WLM 963
Workload Manager 963
WORLD_WIDE_NUM (WWN) 566, 568570
WORM 45, 9495, 97, 106107, 220
cartridge 95, 107, 866
wrapped 16
wrapped (encrypted) 62
wrapped key method 63
wrapped key structures 95
wrapping keys 24
Write Once Read Many
See WORM
write-append 80
write-to-operator (WTO) 878
WTO 956
X
X.509 10, 964
XCF EKM 963
XCF messaging services 234
xSeries 9192
xseries 72
xSeries server 34
Z
z/OS 22, 70, 949950, 957
z/OS Java product 957
z/OS LPAR 950
z/OS started task 957
z/OS system 18, 47, 55, 74, 84, 104, 119, 200, 227, 230,
236, 396397, 404405, 542, 561, 563565, 884
clients 29
DFSMS 233
EKM keyring 561
encryption 75
image 227
tapes 227
z/OS UNIX
System Service 540
System Services Planning 540, 986
z/OS V1 50
z/OS V1R4 200, 233235
z/OS V1R9 200
z/TPF 97, 203204
z/VM 202203, 218
CP commands and utilities 203, 985
CP planning and administration 203
V5.1 203
z/VSE 199, 203
V3.1 203
V4.1 203
V4R1.0 Administration 203
ZFS Aggregate 538539
zOSCompatibility 957
zSeries 33
(
1
.
5

s
p
i
n
e
)
1
.
5
<
-
>

1
.
9
9
8
7
8
9

<
-
>
1
0
5
1

p
a
g
e
s
I
B
M

S
y
s
t
e
m

S
t
o
r
a
g
e

D
a
t
a

E
n
c
r
y
p
t
i
o
n
I
B
M

S
y
s
t
e
m

S
t
o
r
a
g
e

D
a
t
a

E
n
c
r
y
p
t
i
o
n
I
B
M

S
y
s
t
e
m

S
t
o
r
a
g
e

D
a
t
a

E
n
c
r
y
p
t
i
o
n
I
B
M

S
y
s
t
e
m

S
t
o
r
a
g
e

D
a
t
a

E
n
c
r
y
p
t
i
o
n
I
B
M

S
y
s
t
e
m

S
t
o
r
a
g
e

D
a
t
a

E
n
c
r
y
p
t
i
o
n
I
B
M

S
y
s
t
e
m

S
t
o
r
a
g
e

D
a
t
a

E
n
c
r
y
p
t
i
o
n
SG24-7797-00 ISBN 0738434302

INTERNATIONAL
TECHNICAL
SUPPORT
ORGANIZATION
BUILDING TECHNICAL
INFORMATION BASED ON
PRACTICAL EXPERIENCE
IBM Redbooks are developed
by the IBM International
Technical Support
Organization. Experts from
IBM, Customers and Partners
from around the world create
timely technical information
based on realistic scenarios.
Specific recommendations
are provided to help you
implement IT solutions more
effectively in your
environment.
For more information:
ibm.com/redbooks
IBM System Storage

Data Encryption
Understand the
encryption concepts
and terminology
Compare various IBM
storage encryption
methods
Plan for Tivoli Key
Lifecycle Manager
and its keystores
Strong security is not a luxury anymore in todays round-the-clock,
global business environment. It is a requirement. Ensuring the
protection and security of an organizations information is the
foundation of any successful business. Encrypting data is a key
element when addressing these concerns. IBM provides a wide range
of IBM storage hardware products that are capable of encrypting the
data that is written on them. This product line includes a variety of disk
systems and tape drives. Several IBM storage products support
encryption.
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. In addition to hardware
encryption facilities, IBM disk systems and tape drives provide data
encryption capabilities. This IBM Redbooks publication explores the
IBM solutions to encrypt data in the enterprise, as well as key
management using the Tivoli Key Lifecycle Manager.
This book describes IBM System Storage data encryption. This book is
intended for anyone who needs to learn more about the concepts of
data encryption and the IBM storage hardware and software that
enable data encryption.
Back cover

Storage Encryption Sg247797

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Storage Encryption Sg247797

Uploaded by

Copyright:

Available Formats

ibm.

z/OS Security Server RACF Security Administrators Guide, SA22-7683

SG24-7797-00 ISBN 0738434302

IBM System Storage

You might also like