• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Ibm system storage data encryption sg247797
 

Ibm system storage data encryption sg247797

on

  • 979 views

 

Statistics

Views

Total Views
979
Views on SlideShare
979
Embed Views
0

Actions

Likes
0
Downloads
21
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Ibm system storage data encryption sg247797 Ibm system storage data encryption sg247797 Document Transcript

    • Front coverIBM System StorageData EncryptionUnderstand the encryption conceptsand terminologyCompare various IBM storageencryption methodsPlan for Tivoli Key LifecycleManager and its keystores Alex Osuna David Crowther Reimar Pflieger Esha Seth Ferenc Tothibm.com/redbooks
    • International Technical Support OrganizationIBM System Storage Data EncryptionJune 2010 SG24-7797-00
    • Note: Before using this information and the product it supports, read the information in “Notices” on page xvii.First Edition (June 2010)This edition applies to Tivoli Key Lifecycle Manager Version 1 and later and the Encryption Key ManagerRelease 1 and later.© 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 ScheduleContract with IBM Corp.
    • 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiPart 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© Copyright IBM Corp. 2010. All rights reserved. iii
    • 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.4.8 IBM System Storage TS3200 Tape Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 4.4.9 IBM System Storage TS3310 Tape Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136Part 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143iv IBM System Storage Data Encryption
    • 6.3 Changing a security key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1446.4 Security key identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1446.5 Unlocking secure drives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1486.6 Secure erase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1496.7 FDE security authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1496.8 FDE key terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151Chapter 7. Configuring encryption on DS5000 with Full Disk Encryption drives . . . 1537.1 The need for encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 7.1.1 Encryption method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1547.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1587.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1627.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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1687.5 Migrating secure disk arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 7.5.1 Planning checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 7.5.2 Export the array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1697.6 Import secure drive array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 7.6.1 Unlock drives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 7.6.2 Import array. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174Chapter 8. DS5000 Full Disk Encryption best practices . . . . . . . . . . . . . . . . . . . . . . . 1778.1 Physical asset protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1788.2 Data backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1798.3 FDE drive security key and the security key file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1798.4 DS subsystem controller shell remote login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1818.5 Working with Full Disk Encryption drives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1818.6 Replacing controllers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1828.7 Storage industry standards and practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182Chapter 9. Frequently asked questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1839.1 Securing arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1849.2 Secure erase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1849.3 Security keys and passphrases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1859.4 Premium features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1859.5 Global hot-spare drives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1869.6 Boot support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1869.7 Locked and unlocked states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1879.8 Backup and recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1879.9 Additional questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Contents v
    • 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248vi IBM System Storage Data Encryption
    • 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 . 25011.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25611.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25811.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26011.8 Data exchange with business partners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26111.9 Disaster recovery considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26211.10 Database selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263Chapter 12. Implementing Tivoli Key Lifecycle Manager . . . . . . . . . . . . . . . . . . . . . . 26512.1 Implementation notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26612.2 Installing Tivoli Key Lifecycle Manager on 64-bit Windows Server 2008 . . . . . . . . . 26612.3 Installing Tivoli Key Lifecycle Manager on 64-bit Red Hat Enterprise Linux AS Version 5.3 server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29912.4 Installing Tivoli Key Lifecycle Manager on z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32912.5 Configuring Tivoli Key Lifecycle Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 12.5.1 Configuration forLTO4 and TS1100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 12.5.2 Configuration for DS8000 disk drives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34812.6 Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351Chapter 13. Tivoli Key Lifecycle Manager operational considerations . . . . . . . . . . . 35313.1 Scripting with Tivoli Key Lifecycle Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 13.1.1 Simple Linux backup script example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35413.2 Synchronizing primary Tivoli Key Lifecycle Manager configuration data . . . . . . . . . 355 13.2.1 Setting up primary and secondary Tivoli Key Lifecycle Manager servers. . . . . 355 13.2.2 Synchronizing primary and secondary Tivoli Key Lifecycle Manager servers . 35613.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36813.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37713.5 Data sharing with business partners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378 Contents vii
    • 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431viii IBM System Storage Data Encryption
    • 15.2.1 Install the IBM Software Developer Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43115.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44415.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45515.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 . . . . . . . . . . . . . . . . . . . . . . . . . 47015.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47915.7 LTO4 or LTO5 System-Managed Encryption implementation. . . . . . . . . . . . . . . . . . 480 15.7.1 LTO4 SME implementation checklist for Windows . . . . . . . . . . . . . . . . . . . . . . 480Chapter 16. Planning and managing your keys with Encryption Key Manager . . . . 48116.1 Keystore and SAF Digital Certificates (keyrings) . . . . . . . . . . . . . . . . . . . . . . . . . . . 48216.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49016.3 JCE4758KS and JCECCAKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497 16.3.1 Script notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497 16.3.2 Symmetric keys in a JCECCAKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49916.4 JCERACFKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50016.5 JCE4758RACFKS and JCECCARACFKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502 16.5.1 RACDCERT keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503 16.5.2 Best practice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50516.6 PKCS#11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50616.7 IBMi5OSKeyStore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506 16.7.1 Digital Certificate Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507 16.7.2 Setting up an IBMi5OSKeyStore. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50716.8 ShowPrivateTool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52216.9 MatchKeys tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52416.10 Hardware cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527Chapter 17. Encryption Key Manager operational considerations. . . . . . . . . . . . . . . 53117.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 . . . . . . . . . . . . . . . . . . . . . . . 53317.2 Backup procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538 17.2.1 EKM file system backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538 Contents ix
    • 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) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607x IBM System Storage Data Encryption
    • 18.8 Miscellaneous implementation considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607 18.8.1 Data exchange with other data centers or business partners . . . . . . . . . . . . . . 607 18.8.2 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60818.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612Chapter 19. Implementing TS7700 tape encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . 61319.1 TS7700 encryption overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61419.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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61519.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61719.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62319.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62319.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 . . . . . . . . . . . . . . . . . . . . 63219.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 . . . . . . . . . . . . . . 63819.8 TS7700 encryption with z/VM, z/VSE, or z/TPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638Chapter 20. Implementing TS1120 and TS1130 encryption in an open systems environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64120.1 Encryption overview in an open systems environment . . . . . . . . . . . . . . . . . . . . . . . 64220.2 Adding drives to a logical library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643 20.2.1 Advanced Library Management System considerations . . . . . . . . . . . . . . . . . . 64320.3 Managing the encryption and business partner exchange . . . . . . . . . . . . . . . . . . . . 644 20.3.1 Disaster recovery considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646 Contents xi
    • 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.3 Disaster recovery considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749Part 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755xii IBM System Storage Data Encryption
    • 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76522.4 Configuring the Tivoli Key Lifecycle Manager server connections to the DS8000 . . 767Chapter 23. DS8000 encryption features and implementation . . . . . . . . . . . . . . . . . . 77123.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 . . . . . . . . . . . . . . . . . . . 78323.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 . . . . . . . . . . . . . . . . . . . 80123.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80923.4 Encryption and Copy Services functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810Chapter 24. DS8700 advanced encryption features and implementation . . . . . . . . . 81124.1 New security roles: Storage and security administrator . . . . . . . . . . . . . . . . . . . . . . 81224.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83324.3 Dual platform key server support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833 24.3.1 Setting up Tivoli Key Lifecycle Manager server . . . . . . . . . . . . . . . . . . . . . . . . 833Chapter 25. Best practices and guidelines for DS8000 encryption . . . . . . . . . . . . . . 84525.1 Best practices for encrypting storage environments . . . . . . . . . . . . . . . . . . . . . . . . . 846 25.1.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846 25.1.2 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846 25.1.3 Encryption deadlock prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84725.2 Dual Hardware Management Console and redundancy . . . . . . . . . . . . . . . . . . . . . . 850 25.2.1 Dual Hardware Management Console advantages . . . . . . . . . . . . . . . . . . . . . 850 25.2.2 Redundant HMC configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85025.3 Multiple Tivoli Key Lifecycle Managers for redundancy . . . . . . . . . . . . . . . . . . . . . . 852 25.3.1 Setting up primary and secondary Tivoli Key Lifecycle Manager servers. . . . . 853 25.3.2 Synchronizing primary and secondary Tivoli Key Lifecycle Manager servers . 853 Contents xiii
    • 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910xiv IBM System Storage Data Encryption
    • 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925Appendix E. z/OS tape data encryption diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . 931EKM problem determination when running z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 932Error scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 932Diagnostic scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935Encryption Key Manager error codes and recovery actions. . . . . . . . . . . . . . . . . . . . . . . . 938 Drive error codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 940 Control unit error codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 941 IOS628E message indicates connection failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 942Appendix F. IEHINITT exits and messages for rekeying . . . . . . . . . . . . . . . . . . . . . . . 943Dynamic Exits Service Facility support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 944 Error conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 944 Programming considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945REKEY messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945 New messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946 Modified messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946Appendix G. Implementing EKM on z/OS SECURE key processing to TS1100 and LTO4/LTO5 drives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 949Implementing 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964Appendix H. Encryption testing in an open systems environment . . . . . . . . . . . . . . 965Encryption key path test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966 Using key path diagnostics in an LME environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 966 Key Path Diagnostic test in a SME environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 969Testing 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987 Contents xv
    • How to get IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988 Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 991xvi IBM System Storage Data Encryption
    • NoticesThis information was developed for products and services offered in the U.S.A.IBM may not offer the products, services, or features discussed in this document in other countries. Consultyour local IBM representative for information on the products and services currently available in your area. Anyreference to an IBM product, program, or service is not intended to state or imply that only that IBM product,program, or service may be used. Any functionally equivalent product, program, or service that does notinfringe any IBM intellectual property right may be used instead. However, it is the users responsibility toevaluate and verify the operation of any non-IBM product, program, or service.IBM may have patents or pending patent applications covering subject matter described in this document. Thefurnishing of this document does not give you any license to these patents. You can send license inquiries, inwriting, to:IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.The following paragraph does not apply to the United Kingdom or any other country where suchprovisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATIONPROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS ORIMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer ofexpress or implied warranties in certain transactions, therefore, this statement may not apply to you.This information could include technical inaccuracies or typographical errors. Changes are periodically madeto the information herein; these changes will be incorporated in new editions of the publication. IBM may makeimprovements and/or changes in the product(s) and/or the program(s) described in this publication at any timewithout notice.Any references in this information to non-IBM websites are provided for convenience only and do not in anymanner serve as an endorsement of those websites. The materials at those websites are not part of thematerials 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 incurringany obligation to you.Information concerning non-IBM products was obtained from the suppliers of those products, their publishedannouncements or other publicly available sources. IBM has not tested those products and cannot confirm theaccuracy of performance, compatibility or any other claims related to non-IBM products. Questions on thecapabilities of non-IBM products should be addressed to the suppliers of those products.This information contains examples of data and reports used in daily business operations. To illustrate themas completely as possible, the examples include the names of individuals, companies, brands, and products.All of these names are fictitious and any similarity to the names and addresses used by an actual businessenterprise is entirely coincidental.The following company name appearing in this publication is fictitious:ZABYXCThis name is used for instructional purposes only.COPYRIGHT LICENSE:This information contains sample application programs in source language, which illustrate programmingtechniques on various operating platforms. You may copy, modify, and distribute these sample programs inany form without payment to IBM, for the purposes of developing, using, marketing or distributing applicationprograms conforming to the application programming interface for the operating platform for which the sampleprograms are written. These examples have not been thoroughly tested under all conditions. IBM, therefore,cannot guarantee or imply reliability, serviceability, or function of these programs.© Copyright IBM Corp. 2010. All rights reserved. xvii
    • TrademarksIBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business MachinesCorporation in the United States, other countries, or both. These and other IBM trademarked terms aremarked on their first occurrence in this information with the appropriate symbol (® or ™), indicating USregistered or common law trademarks owned by IBM at the time this information was published. Suchtrademarks may also be registered or common law trademarks in other countries. A current list of IBMtrademarks is available on the web at http://www.ibm.com/legal/copytrade.shtmlThe following terms are trademarks of the International Business Machines Corporation in the United States,other countries, or both: AIX 5L™ Lotus® System x® AIX® MVS™ System z9® alphaWorks® Netfinity® System z® AS/400® OS/400® Tivoli® CICS® Parallel Sysplex® TotalStorage® DB2® pSeries® VTAM® developerWorks® RACF® WebSphere® DS8000® Redbooks® xSeries® ESCON® Redbooks (logo) ® z/OS® FICON® RS/6000® z/VM® FlashCopy® System i5® z/VSE™ i5/OS® System i® z9® IBM® System p® zSeries® iSeries® System Storage DS® Language Environment® System Storage®The following terms are trademarks of other companies:AMD, AMD Opteron, the AMD Arrow logo, and combinations thereof, are trademarks of Advanced MicroDevices, Inc.SUSE, the Novell logo, and the N logo are registered trademarks of Novell, Inc. in the United States and othercountries.VMware, the VMware "boxes" logo and design are registered trademarks or trademarks of VMware, Inc. in theUnited States and/or other jurisdictions.Java, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, othercountries, 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 registeredtrademarks 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.xviii IBM System Storage Data Encryption
    • Preface Strong security is not a luxury anymore in today’s round-the-clock, global business environment. It is a requirement. Ensuring the protection and security of an organization’s 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 – IBM System Storage DS8000® 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 Master’s degree in Electrical Sciences from Cambridge University.© Copyright IBM Corp. 2010. All rights reserved. xix
    • 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 SupportNow you can become a published author, too! Here’s an opportunity to spotlight your skills, grow your career, and become a published author - all at the same time! Join an ITSO residency project and help write a book in your area of expertise, while honing your experience using leading-edge technologies. Your efforts will help to increase product acceptance and customer satisfaction, as you expand your network of technical contacts and relationships. Residencies run from two to six weeks in length, and you can participate either in person or as a remote resident working from your home base.xx IBM System Storage Data Encryption
    • Find out more about the residency program, browse the residency index, and apply online at: ibm.com/redbooks/residencies.htmlComments 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-5400Stay 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 Preface xxi
    • xxii IBM System Storage Data Encryption
    • Part 1Part 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.© Copyright IBM Corp. 2010. All rights reserved. 1
    • 2 IBM System Storage Data Encryption
    • 1 Chapter 1. Encryption concepts and terminology In this chapter, we introduce data encryption concepts and terminology.© Copyright IBM Corp. 2010. All rights reserved. 3
    • 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.4 IBM System Storage Data Encryption
    • Encryption Process Algorithm Plain Text Encrypted Data AES Symmetric Key AES_256_ITSO Decryption Process Algorithm Plain Text Encrypted Data AES Symmetric Key AES_256_ITSOFigure 1-1 Symmetric key encryptionSymmetric key encryption algorithms are significantly faster than asymmetric encryptionalgorithms, which makes symmetric encryption an ideal candidate for encrypting largeamounts of data.In addition, the comparable key sizes for symmetric encryption as opposed to asymmetricencryption differ significantly. While a symmetric AES encryption might use a 128-bit secretkey, 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 byspecified 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 symmetricencryption has two drawbacks, which are the way that keys are exchanged and the number ofrequired keys.Secure exchange of keys has always been a problem with symmetric encryption. The senderand the recipient have to share a common, secret key. The sender of a confidential messagemust 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 aface-to-face meeting, through a trusted courier, or a secure electronic channel. This methodof transferring keys might work as long as only a few people are involved in the exchange ofconfidential information. When a larger number of people have to exchange keys, thedistribution of secret keys becomes difficult and inefficient with this method.The second drawback of symmetric encryption is the large number of required keys. When agroup of people are to exchange symmetrically encrypted information, each possible pair oftwo people in this group has to share a secret key. The number of required keys grows very Chapter 1. Encryption concepts and terminology 5
    • 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: kn =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. 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. 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. Because6 IBM System Storage Data Encryption
    • asymmetric encryption uses public-private key pairs, it is also called public-private keyencryption or public key encryption.Public-private key encryption is useful for sharing information between organizations and iswidely used on the Internet today to secure transactions, including Secure Sockets Layer(SSL).The concept of asymmetric encryption is relatively new. For centuries, cryptographersbelieved that the sender and the recipient had to share the same secret key. In the early1970s, British cryptographers Ellis, Cocks, and Williamson discovered a way to use separatekeys for encrypting and decrypting data. Because they were working for GCHQ, a Britishintelligence agency, their findings were kept secret until 1997. In 1976, Whitfield Diffie andMartin Hellman invented a solution to the problem, which has since become known as theDiffie-Hellman key exchange. In 1977 Ron Rivest, Adi Shamir, and Leonard Adlemanpublished an algorithm for public-key encryption.Well-known examples of asymmetric key algorithms are RSA, Diffie-Hellman, Elliptic curvecryptography (ECC), and ElGamal.Today, the Rivest-Shamir-Adleman (RSA) algorithm is the most widely used public keytechnique. 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.The advantage of asymmetric key encryption is the ability to share secret data withoutsharing the same encryption key. But there are disadvantages, too. Asymmetric keyencryption is computationally more intensive and therefore significantly slower thansymmetric key encryption. In practice, you will often use a combination of symmetric andasymmetric encryption. We describe this method in 1.1.3, “Hybrid encryption” on page 9.Digital signatureYou can use public/private key pairs to protect the content of a message, and also to digitallysign a message. When a digitally signed message is sent, the receiver can be sure that thesender 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 signedrather 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 useJoHann’s public key to encrypt the message, but Tony’s own private key. The content of theencrypted message is not protected, because anyone can decrypt the message by usingTony’s public key. But, if JoHann is able to decrypt Tony’s message with Tony’s public key,JoHann can be sure that Tony sent the message. JoHann has proof that the message wasencrypted with Tony’s private key, and JoHann knows that only Tony has access to this key.In the previous example, JoHann has to make sure that Tony’s public key really belongs toTony, and not to someone pretending to be Tony. If JoHann cannot confirm that it is reallyTony’s public key, JoHann will need a trusted third party to verify Tony’s identity. A certificateissued and signed by a Certification Authority (CA) can confirm that the public key belongsto 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. Chapter 1. Encryption concepts and terminology 7
    • 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. Public/Private Key Encryption Algorithm Encrypted Plain Text RSA Data Asymmetric Public Key Decryption Process Algorithm Encrypted Plain Text RSA AES Data Asymmetric Private Key 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 Tony’s public key. Tony sends JoHann a message that is encrypted with Tony’s private key. JoHann then uses the public key to decrypt the message. When the message is decrypted to clear text, this 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.8 IBM System Storage Data Encryption
    • Network Bob Alice Private Key Private Key Encrypted Public Key Message Message Message Public Key Data Encrypted Data Data 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 CA’s signature, they can also verify that a certain public key does indeed belong to the person or entity that is identified in the certificate. Chapter 1. Encryption concepts and terminology 9
    • 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-repudiation10 IBM System Storage Data Encryption
    • Figure 1-5 Sample digital certificateWhen sending information that was private key-encrypted, the receiver of the message knowsthat the message must have been sent by the entity with the private key; the receiver also canverify that the message was not tampered with. Finally, the entity receiving a message thatwas private key-encrypted knows that the message that they got cannot be denied by thesender. Only the sender has the private key; therefore, the sender must have sent it.Certificate authoritiesA 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 acompany 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 acertificate request to the JohannTonyArtCA third-party certificate authority (CA) company. Inthe figure, we see that company ZABYXC already trusts JohannTonyArtCA, becauseZABYXC has a copy of the JohannTonyArtRootCA in its certificate repository. This copy ofJohannTonyArtRootCA has only the public key and an encrypted copy of the public key, whichis encrypted with JohannTonyArtRootCA’s private key.Company ZABYXC also has a self-signed personal certificate with a public and a private keyassociated with it. Using certificate managing tools, company ZABYXC exports a copy of itsself-signed personal certificate that includes only the certificate information, the public key,and the encrypted version of the public key. Chapter 1. Encryption concepts and terminology 11
    • This certificate request is sent to JohannTonyArtCA. Third Party, CA Cert. Repository JohannTonyArt, CA JohannTonyArt Root, CA Issuer = JohannTonyArt Subject = JohannTonyArt Company Public Key ZABYXC Private Key Certs JohannTonyArt Root, CA Public Key Self Signed Personal Cert Certificate Subject = Request ZABYXC Issuer = ZABYXC Public Key Private Key Figure 1-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 request’s public key and attaches both the clear public key and the new encrypted copy of the public key to a certificate response. In addition, the certificate response has the issuer changed to JohannTonyArtCA. This response is sent to company ZABYXC. When company ZABYXC receives the certificate response from JohannTonyArtCA, company ZABYXC imports the certificate into the company’s certificate repository. The company replaces the self-signed personal certificate in the repository, and it keeps the private key previously associated with the personal certificate. Company ZABYXC can verify that the certificate response came from JohannTonyArtCA, because they have a copy of JohannTonyArtRootCA. They can use the public key from JohannTonyArtRootCA to verify that the certificate response came from JohannTonyArtCA.12 IBM System Storage Data Encryption
    • Third Party, CA Cert. Repository JohannTonyArt, CA Company ZABYXC Certs JohannTonyArt JohannTonyArt Root, CA Root, CA Pub Key Issuer = JohannTonyArt Subject = JohannTonyArt Public Key Certificate Private Key Response Company ZABXYC Company ZABYXC Subject = ZABYXC Subject = ZABYXC Issuer = Issuer = JohannTonyArt JohannTonyArt Public Key Pub Key Encrypted Public key Encrypted Public keyFigure 1-7 Certificate responseIf company ZABYXC wants another company to share data with it, the company can nowexport a copy of its personal certificate, which contains its public key, and the public keysigned by JohannTonyArtRootCA. When ZABYXC sends this certificate to a businesspartner, the business partner can add JohannTonyArtRootCA to its own certificate repositoryand 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 certificatechain, the JohannTonyArtRootCA is the root CA with a validity of several years. Next in thechain is a ZABYXCCA signed by the JohannTonyArtRootCA. This certificate can have ashorter validity period and might have to be re-requested. The third-party CA keeps theprivate key information for these certificates. When company ZABYXC generates a certificaterequest 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 thissituation, the whole chain has to be in the certificate repository. Chapter 1. Encryption concepts and terminology 13
    • Certificate Chain JohannTonyArt Root CA Public Encrypted Public Key Private Key Company ZABYXC CA Public Key Encrypted Public Key Private Key Company ZABYXC Personal Cert Public Key Encrypted Public Key Private 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 client’s identity is verified. After the client and the server have verified that they are indeed who they claim to be, they exchange keys and decide with which SSL cipher to communicate. Data can then be encrypted and sent across the network. Not only does SSL allow data communication to be protected between a client and server, it also is used to prove client and server identities.14 IBM System Storage Data Encryption
    • SSL Handshake with SSL Client Client Authentication SSL Server Client Hello Server Hello Certificate Server Verified Certificate Certificate Request Server Hello Network Complete Client Certificate Certificate Verified Key Exchange Cipher Suite Cipher Suite Finished Figure 1-9 SSL handshake example using ClientAuth1.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 Chapter 1. Encryption concepts and terminology 15
    • 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 server’s 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.16 IBM System Storage Data Encryption
    • 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. 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. 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. Chapter 1. Encryption concepts and terminology 17
    • 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&dtm18 IBM System Storage Data Encryption
    • 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. Encryption Key Manager (EKM) Config Drive File Table Keystore Crypto Services Figure 1-11 Encryption Key Manager components and resources 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. 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. Chapter 1. Encryption concepts and terminology 19
    • 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. 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 IBM LTO Ultrium 4 drives: Encryption on IBM LTO Ultrium 4 drives requires a keystore that supports symmetric 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. Important: Do not use hardware-based keystore types when the FIPS parameter is set ON. More information about the IBMJCEFIPS provider, its selection, and its use is at this website: http://www.ibm.com/developerworks/java/jdk/security/50/FIPShowto.html20 IBM System Storage Data Encryption
    • 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 Encryption management Keys used by Keys used by LTO4 drive method TS1120 drive or TS1130 System-Managed Encryption One randomly generated One pre-generated data key or Library-Managed Encryption unique data keya per cartridge per cartridge using Encryption Key Manager Application-Managed One randomly generated One data key per cartridge Encryption (no Encryption Key unique data key per cartridge Manager) a. Data key is a symmetric AES 256-bit data key1.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. Chapter 1. Encryption concepts and terminology 21
    • In your enterprise, a large number of symmetric keys, asymmetric keys, and certificates can exist. All of these keys and certificates have to be managed 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. 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.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 keys22 IBM System Storage Data Encryption
    • 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 fileTo perform these tasks, Tivoli Key Lifecycle Manager relies on external components. TheTivoli Key Lifecycle Manager solution includes the Tivoli Key Lifecycle Manager server, anIBM embedded WebSphere Application Server, and a database server (IBM DB2®).The solution also incorporates the Tivoli Integrated Portal installation manager, whichprovides 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 inDB2 tables. The Tivoli Key Lifecycle Manager DB2 tables enable the user to search and querythat information more easily. Note that the keystore, configuration file, audit log, and debuglog 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). 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 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. Cryptographic services 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. Chapter 1. Encryption concepts and terminology 23
    • 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. You can obtain more information about the IBMJCEFIPS provider, its selection, and its use at the following website: http://www.ibm.com/developerworks/java/jdk/security/50/FIPShowto.html 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.24 IBM System Storage Data Encryption
    • In the wrapped key method, there are two functions that an encrypting storage device caninitiate 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 label’s 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 isunable to encrypt or decrypt data without access to Tivoli Key Lifecycle Manager. Separatekey life cycles are appropriate for separate storage. For instance, the externally encrypteddata key for a removable media device might be stored on the media when it is initially writtenand the data key forgotten when the media is dismounted so that each time the media isre-mounted, the storage device must communicate with Tivoli Key Lifecycle Manager toobtain the data key. The externally encrypted data key for a non-removable storage devicemight be stored as persistent metadata within the storage device and the data key forgottenwhen it is powered off so that each time the product is powered on, it must communicate withTivoli Key Lifecycle Manager to obtain the data key. In all cases, access to data encryptedwith a data key requires access to both the externally encrypted data key and to a Tivoli KeyLifecycle Manager that knows the key label private key needed to decrypt the externallyencrypted data key to obtain the data key. Chapter 1. Encryption concepts and terminology 25
    • 26 IBM System Storage Data Encryption
    • 2 Chapter 2. Introduction to storage data encryption Strong security is not a luxury anymore in today’s round-the-clock, global business environment. Ensuring the protection and security of an organization’s 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: – IBM System Storage DS5000 series – IBM System Storage DS8000 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© Copyright IBM Corp. 2010. All rights reserved. 27
    • 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 Drive28 IBM System Storage Data Encryption
    • 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 Chapter 2. Introduction to storage data encryption 29
    • 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.30 IBM System Storage Data Encryption
    • 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. Chapter 2. Introduction to storage data encryption 31
    • 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 client’s 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.32 IBM System Storage Data Encryption
    • 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. 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. 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 Chapter 2. Introduction to storage data encryption 33
    • 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.34 IBM System Storage Data Encryption
    • 1. Load cartridge, specify encryption Encryption 2. Tape drive requests a data key Key Manager Encrypted “Data Key” 5. Tape drive writes encrypted 3. Key manager 4.Encrypted keys data and stores encrypted data generates key and transmitted to tape drive key on cartridge encrypts it Encrypted “Data Keys” Figure 2-6 TS1120 and TS1130 tape data encryption process flow Figure 2-7 summarizes the LTO4 tape data encryption process flow. 1. Load cartridge, specify encryption Encryption 2. Tape drive requests a data key Key Manager 5. Tape drive decrypts the data key, writes encrypted data and 3. Key manager keyid on the cartridge 4.Encrypted data key retrieves key and transmitted to tape drive encrypts it for transmission LTO 4 Encryption Encrypted “Data Key” Figure 2-7 LTO4 tape data encryption process2.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. Chapter 2. Introduction to storage data encryption 35
    • Without these IBM disk encryption Storage Manager-managed keys, the user (authorized or unauthorized) can no longer decrypt the data on disk. Important: If these keys and all copies are lost, the encrypted data on the disk cannot be decrypted and therefore must be considered lost. Figure 2-8 shows the relationship of the IBM Disk Encryption Manager and the individual FDE disk with encryption enabled. IBM DS5000 Disk Encryption Writing to the Drive Reading from the Drive Encryption Process Decryption Process Manager The quick brown fox The quick brown fox jumps over the lazy dog jumps over the lazy dog User Data User Data Self-encrypting Drive Data Data Encryption Encryption Key Key %$#@% %$#@% $#@#@&$ $#@#@&$ Authorization Flow Data on Drive Data on Drive Data Flow 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.36 IBM System Storage Data Encryption
    • Figure 2-9 Unauthorized access to the drive results in the data remaining encrypted2.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. Chapter 2. Introduction to storage data encryption 37
    • Storage Admin StoragePlex DS8000 Storage Facility Storage Facility Image DSGUI / DS-CLI SFI Server StoragePlex SFI Server HMC Dual HMCs HMC Recommended Customer IP Network TKLM GUI primary and secondary TKLM Servers Key Lifecycle Manager Cryto-Services Key-Store Security / Storage Admin 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. Customer Ba nd 1 Data Ba nd 0 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).38 IBM System Storage Data Encryption
    • An FDE drive that is made a member of an encryption-enabled rank is locked. The FDE driveis 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 rankcreation or sparing. Unlocking occurs when an encryption-enabled rank is deleted or amember of an encryption-enabled rank is reused as a spare. Unlocking always results in acryptographic erasure of an FDE drive (the disk resets its own encryption key). Thecryptographic erasure of an FDE drive also happens when an encryption-disabled rank isdeleted. The client can cryptographically erase the data for a set of logical volumes in anencryption-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 noguarantee that the device adapter can communicate with the disk. More specifically, thedevice adapter intentionally fences the failing drive from the device interface as soon aspossible 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 samestorage facility, so additional drives added to a DS8000 must be consistent with the alreadyinstalled 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 eitherenable or disable encryption for all data stored on client disks.In order to enable encryption, each DS8000 storage facility image must be configured in thefollowing 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. Chapter 2. Introduction to storage data encryption 39
    • 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 a40 IBM System Storage Data Encryption
    • 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. Chapter 2. Introduction to storage data encryption 41
    • Data Center Secondary Site Business Partners In Transit 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)42 IBM System Storage Data Encryption
    • 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. Security: No single security implementation can effectively secure all levels of data against all threats. 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 owner’s 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 Chapter 2. Introduction to storage data encryption 43
    • 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.html2.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.44 IBM System Storage Data Encryption
    • The advantage of IBM tape data encryption is that the data is encrypted after compression, and there are no additional software program costs. IBM tape data encryption saves space on tape cartridges and saves additional hardware investments. In addition, outboard encryption in the tape drives might help you protect large volumes of tape data in a cost-effective way. Data on cartridges does not have to be degaussed or overwritten with patterns of x’FF’ at the end of life of the cartridge. This approach is valid for Write Once Read Many (WORM) cartridges and for normal cartridges. The encryption key management capability is designed to manage keys across mainframes and open systems environments; 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. Chapter 2. Introduction to storage data encryption 45
    • 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.46 IBM System Storage Data Encryption
    • The IBM solution provides policy options at three levels: Application layer System layer Library layerIBM supports two methods for managing the encryption keys: through the application (in opensystems) 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, ina z/OS environment, the encryption policies can be managed by Data Facility StorageManagement 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 volumeserial numbers on cartridges in a library.Disk encryption fundamentalsWhen considering encryption at your installation, consider the following factors.As the availability of encryption-capable devices becomes more pervasive, more and moredata will be migrated from non-encrypted storage to encrypted storage. Even if the keyservers are initially configured correctly, it is possible that a storage administrator mightaccidentally migrate data required by the key server from non-encrypted to encryptedstorage.Generally, a number of layers of virtualization in the I/O stack hierarchy can make it difficult forthe 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 througha database that runs on a file system that runs on a logical volume manager, whichcommunicates with a storage subsystem that provisions logical volumes with capacityobtained from other subordinate storage arrays. The data required by the key server mightend up provisioned over various storage devices, each of which can be independentlyencryption capable or encryption enabled.Consolidation of servers and storage tends to drive data migration and tends to moveincreasingly more data under a generalized shared storage environment. This storageenvironment will become encryption capable as time goes on.All IBM server platforms support fabric-attached boot devices and storage. Certain servers donot support internal boot devices. Therefore, boot devices are commonly present within thegeneralized storage environment. These storage devices are accessible to generalizedstorage management tools that support data management and relocation.To mitigate the risk of an encryption deadlock, you must be directly involved in managing theencryption 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 2. Introduction to storage data encryption 47
    • 48 IBM System Storage Data Encryption
    • 3 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).© Copyright IBM Corp. 2010. All rights reserved. 49
    • 3.1 Tivoli Key Lifecycle Manager In your enterprise, a large number of symmetric keys, asymmetric keys, and certificates can 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.50 IBM System Storage Data Encryption
    • 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). 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 on page 52 shows the Tivoli Key Lifecycle Manager components and external resources. Chapter 3. IBM storage encryption methods 51
    • • Manages Data Key (DK) generation • Manages keys transfer to and from tape and disk devices Key • Stores public/priv ate keypairs Store • Stores symmetric keys (LTO4) eWAS TIP Config File TKLM • Defines TKLM behavior Audi t • Track s TKLM activity Log DB2 Tables Crypto Drive Table Services Provider Meta Data • Generates Data Key (DK) • Wraps DKs  EEDK/SEDK Key Groups 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. Java security keystore The keystore is defined as part of the Java Cryptography Extension (JCE) and an element of the Java Security components, which are, in turn, part of the Java Runtime Environment (JRE). A keystore holds the certificates and keys (or pointers to the certificates and keys) 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.52 IBM System Storage Data Encryption
    • Cryptographic services 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 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 this website: http://www.ibm.com/developerworks/java/jdk/security/50/FIPShowto.html3.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 DS8000’s 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. 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. 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 Chapter 3. IBM storage encryption methods 53
    • 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 cartridge’s data key to be reencrypted with a business partner’s 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 In your enterprise, a large number of symmetric keys, asymmetric keys, and certificates can 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.54 IBM System Storage Data Encryption
    • 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.LTO4, like the encryption-capable 3592 drives TS1120 and TS1130, provides three methodsof encryption management from which to choose. These methods differ in where you chooseto locate your EKM application. Your operating environment determines which is the bestmethod for you, with the result that key management and the encryption policy engine mightbe located in any one of the following three environmental layers, as shown in Figure 3-2.Figure 3-2 EKM architectureThe IBM Encryption Key Manager component for the Java platform is a Java softwareprogram that assists IBM encryption-enabled TS1120 tape drives and Linear Tape-Open(LTO) Ultrium 4 tape drives by providing, protecting, storing, and maintaining encryption keysthat are used to encrypt information being written to, and to decrypt information being readfrom, tape media. EKM operates on a variety of operating systems. Currently, EKM operateson the following supported operating systems: z/OS i5/OS AIX Linux Hewlett-Packard UNIX (HP-UX) Sun Solaris WindowsEKM is designed to be a shared resource deployed in several locations within an enterprise. Itis capable of serving numerous IBM encrypting tape drives, regardless of where those drivesreside (for example, in tape library subsystems, connected to mainframe systems throughvarious types of channel connections, or installed in other computing systems). Chapter 3. IBM storage encryption methods 55
    • 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&dtm3.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. Encryption Key Manager (EKM) Config Drive File Table Keystore Crypto Services Figure 3-3 EKM components and resources 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. 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.56 IBM System Storage Data Encryption
    • The tape drive table is a non-editable, binary file whose location is specified in theconfiguration file. A number of EKM commands are available to add, delete, modify, and viewkeys and certificates. You can change the location of the tape drive table to meet yourrequirements. 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.Configuration fileThe configuration file is an editable file, which tells your EKM how to operate. You specify thekeystore location and the drive table location in this file.We describe the configuration file extensively in Chapter 14, “Planning for Encryption KeyManager and its keystores” on page 393 and, later, in Part 3, “Implementing tape dataencryption” on page 189, where we describe the full set of configuration options.Java security keystoreThe keystore is defined as part of the Java Cryptography Extension (JCE) and an element ofthe Java Security components, which are, in turn, part of the Java Runtime Environment. Akeystore holds the certificates and keys (or pointers to the certificates and keys) used by EKMto perform cryptographic operations. A keystore can be either hardware based or softwarebased.EKM supports several types of Java keystores, offering a variety of operational characteristicsto 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 keysWe describe the characteristics of these keystores in 14.3, “EKM and keystoreconsiderations” on page 400. IBM LTO Ultrium 4 drives: Encryption on IBM LTO Ultrium 4 drives requires a keystore that supports symmetric keys.Cryptographic servicesEKM uses the IBM Java Security components for its cryptographic capabilities. EKM does notprovide cryptographic capabilities and therefore does not require, nor is allowed to obtain,FIPS 140-2 certification. However, EKM takes advantage of the cryptographic capabilities ofthe IBM Java Virtual Machine in the IBM Java Cryptographic Extension component andallows the selection and use of the IBMJCEFIPS cryptographic provider, which has a FIPS140-2 Level 1 certification. In the configuration properties file, setting the FIPS configurationparameter to ON causes EKM to use the IBMJCEFIPS provider for all cryptographic functions. Chapter 3. IBM storage encryption methods 57
    • Hardware-based keystores: Do not use hardware-based keystore types when the FIPS parameter is set ON. You can obtain more information about the IBMJCEFIPS provider, its selection, and its use at this website: http://www.ibm.com/developerworks/java/jdk/security/50/FIPShowto.html3.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.58 IBM System Storage Data Encryption
    • 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. 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. TS1120 and TS1130 tape drives In addition to 256-bit AES symmetric data keys that are randomly generated for each volume being encrypted, EKM also uses public-private (asymmetric) key cryptography to protect the symmetric data encryption keys that are generated and retrieved as they pass between EKM 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 Encryption management Keys used by Keys used by LTO4 drive method TS1120 drive or TS1130 System-Managed Encryption One randomly generated One pregenerated data key per or Library-Managed Encryption unique data keya per cartridge cartridge using EKM or Tivoli Key Lifecycle Manager Application-Managed One randomly generated One data key per cartridge Encryption (no EKM or Tivoli unique data key per cartridge Key Lifecycle Manager) a. A data key is a symmetric AES 256-bit data key.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. Chapter 3. IBM storage encryption methods 59
    • TS1120 and TS1130 tape drives 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 cartridge’s data key to be reencrypted with a business partner’s 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.60 IBM System Storage Data Encryption
    • 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.For more details about the encryption key management, see 3.4.1, “Encryption keymanagement” on page 62.To be able to use data encryption, you must order the DS8000 from manufacturing with FDEdrives (replacing the regular Fibre Channel (FC) drives with FDE drives in an existing DS8000is not supported). Chapter 22, “IBM System Storage DS8000 encryption preparation” onpage 753 provides details about the ordering process.Currently, the DS8000 does not support the intermix of FDE and non-FDE drives, soadditional disks to be added must be consistent with the already installed drives. A DS8000with FDE drives is referred to as being encryption capable. Each SFI on anencryption-capable DS8000 can be configured to either enable or disable encryption for alldata stored on client disks.The DS8000 must be configured to communicate with at least two or more Tivoli KeyLifecycle Manager key servers to enable encryption. Two Tivoli Key Lifecycle Manager keyservers are required for redundancy. The communication between the DS8000 and the TivoliKey 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 isimportant.The physical connection between the DS8000 HMC and the key server is through a TCP/IPnetwork, as depicted in Figure 3-4. Storage Admin StoragePlex DS8000 Storage Facility Storage Facility Image DSGUI/DS-CLI SFI Server StoragePlex SFI Server HMC Dual HMCs HMC Recommended Custome r IP Network TKLM GUI Primary and secondary TKLM Servers Key Lifecycle Manager Crypto Services Keystore Security/Storage AdminFigure 3-4 Connection between DS8000 HMC and Tivoli Key Lifecycle Manager Chapter 3. IBM storage encryption methods 61
    • 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. Customer Ba nd 1 Data Ba nd 0 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. 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.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. 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.62 IBM System Storage Data Encryption
    • The Tivoli Key Lifecycle Manager uses the wrapped key method to serve keys to theencryption-enabled DS8000. The wrap/unwrap keys on the Tivoli Key Lifecycle Manager area 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 supportis 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 labelpair (KEK/KEK’), which is generated by the Tivoli Key Lifecycle Manager when the key label isconfigured. See Figure 3-6. This key label pair, or key encrypting key pair, is maintained bythe Tivoli Key Lifecycle Manager, and it is used to wrap and unwrap data keys. The keyencrypting key pair key is kept secret by the Tivoli Key Lifecycle Manager. Key Lifecycle Manager (TKLM) - generate Key-Label Key Pair Create Key Label - Key-Label Public Key (KEK) (1) USER (Key Label) - Key-Label Private Key (KEK‘) - store Key Label and Key-Label Key PairFigure 3-6 Configure Tivoli Key Lifecycle Manager Key LabelNow, the user (storage administrator) will use the DS8000 GUI to register the key server onthe DS8000. Next, still using the DS8000 GUI or, alternatively, using the DS8000 CLI, anencryption group is created. For details, see 23.3.1, “Configuring the Tivoli Key LifecycleManager server connection” on page 804.As part of creating the encryption group, you must specify the key label that was set whenconfiguring the Tivoli Key Lifecycle Manager server. DS8000: Currently, the DS8000 has only one encryption group.While creating the encryption group, the DS8000 generates a device session key pair (devicesession 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 wasset 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 (seeFigure 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. Chapter 3. IBM storage encryption methods 63
    • 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. Creat e Encryption Grou p (N, Key Label) USER (2) DS8000 System Disk Get New Key (Key Label, <valid ate Certi fi cate> IBM Certificate <Get Key-Label Key Pai r for Key-Labe (KEK/KEK’)l> DSK, Certificat e) <generate data key=DK> <generate device session key pair DSK/DSK’> <DK=unwrap(SEDK, DSK’> <generate group key=GK> SEDK, EEDK <EED K=wra p(DK, KEK)> <EGK= wrap(DK, GK)> <SED K=wra p(DK, SDK)> <store EEDK(N), EGK(N) > Storage Facility Image (SFI) Key Lifec ycle Manager 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. 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. 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.64 IBM System Storage Data Encryption
    • DS8000 Configure Rank (Encryption Group N) USER (3) <Access Credential = <hash> <encrypt> Lock (Access Credential) hash(GK(N), Disk Serial Num)> Read Disk Serial Number Non-Volatile Memory Hashed Access Credential Encrypted Data Key Data Key Encrypt / Decrypt Hardware Storage Facility Image (SFI) Encrypting DiskFigure 3-8 Configure rankThe following steps, which are also shown in Figure 3-9 on page 66, are performed to regainaccess to locked drives at power on: Important: The DS8000 must be able to communicate with the Tivoli Key Lifecycle Manager during 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. Chapter 3. IBM storage encryption methods 65
    • DS8000 S ystem Disk IBM Certificate Key Lifecyc le Manager (TKLM) <generate session key pair> Get Existing Key (EEDK(N), <DK=unwrap(EEDK, Key-Label Private Key)> Session Public Key) <DK(N)=unwrap(SEDK, <SEDK=wrap(DK, Session Public Key)> Session Private Key> SEDK <GK(N)=unwrap(EGK(N), DK(N) Non-Volatile Memory Hashed Access Credent ial Encrypted Data Key <Access Credential = Authenticate hash(GK(N), Disk Serial Num)> <hash & verify> (Access Credential) <decrypt> Data Key Data Encrypt/Decrypt Storage Facility Image (SFI) Hardware Enc rypting Disk Figure 3-9 Power on of the DS8000 Figure 3-10 summarizes all the key management mechanisms. Configure TKLM Key Label = Green Configure Encryption Group = Red Configure Rank = Blue Power On = Black + Magenta Create Encryption Group USER (2) System Disk (N, Key Label) Key Lifecycle Manager (TKLM) IBM Certificate Get New Key (Key Label, <validate Certificate> Session Public Key, Certificate) <Get Key-Label Key Pair for Key-Label> <generate session key pair> <generate data key=DK> <EEDK=wrap(DK, Key-Label Public Key)> <SEDK=wrap(DK, Session Public Key)> SEDK, EEDK <DK=unwrap(SEDK, Session Private Key> Create Key Label <generate group key=GK> (1) USER (Key Label) <generate Key-Label Key Pair> <EGK=wrap(DK, GK)> <store Key Label, Key-Label Key Pair> <store EEDK(N), EGK(N)> <generate session key pair> Get Existing Key (EEDK(N), <DK=unwrap(EEDK, Key-Label Private Key)> <DK(N)=unwrap(SEDK, Session Public Key) <SEDK=wrap(DK, Session Public Key)> Session Private Key> SEDK <GK(N)=unwrap(EGK(N), DK(N) Configure Rank USER (3) (Encryption Group N) <Access Credential = <hash> <encrypt> Lock (Access Credential) hash(GK(N), Disk Serial Num)> Read Disk Serial Number Non-Volatile Memory Hashed Access Credential Encrypted Data Key <Access Credential = Authenticate hash(GK(N), Disk Serial Num)> <hash & verify> (Access Credential) <decrypt> Data Key Data Encrypt / Decrypt Storage Facility Image (SFI) Hardware Encrypting Disk Figure 3-10 Encryption key management66 IBM System Storage Data Encryption
    • 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. 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. 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 client’s 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 Chapter 3. IBM storage encryption methods 67
    • 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 support3.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.68 IBM System Storage Data Encryption
    • DS8700 Configure recovery Key Client requests co nfiguratio n o f recovery key <generate asymmetr ic key (PRK/SRK)> <generate symmetric recovery key (RK) > Client makes a copy of the RK and keep s it safe <EPRK=wrap( PRK,RK)> <EGRK=wrap( GK,SRK)> DS8700 Request recovery Key DS8700 stops at IML because no key server is avai lable Client enters the RK <PRK=unwrap(EPRK,RK)> <GK=unwr ap(EGRK,PRK)> . .. GK is used to create the credentials to unlock the drivesFigure 3-11 Using the recovery key featureAs shown in Figure 3-11, when a recovery key is configured, a new primary key/secondarykey (PRK/SRK) asymmetric key pair is generated by the DS8700. In addition, the DS8700generates a recovery key (RK), which you must record. The PRK is then wrapped (encryptedby) the RK and stored as an EPRK. When the encryption group is created, the GK is wrappedby the SRK and stored as an EGRK.If recovery is needed, the RK (which you manually enter at the console) is used by theDS8700 to unwrap the EPRK to obtain the PRK. The PRK is then used to unwrap the EGRKto obtain the GK. The GK can then be used to derive the disk access credential as before andso unlock the data on the FDE disks.If you plan to use a recovery key, you must configure it before configuring the encryptiongroup and enabling encryption on the DS8700. You must note the recovery key and keep itsafe 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 onthe recovery key, so that no one person can, for instance, instigate access to the data usingthe recovery key. For any actions relating to the recovery key, both the Storage Administratorand the Security Administrator must give their consent. Chapter 3. IBM storage encryption methods 69
    • 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). 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. 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 client’s public key and with the business partner’s public key, creating two EEDKs that were stored on the tape. One of the EEDKs was unwrapped by the client using the client’s 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.70 IBM System Storage Data Encryption
    • You must first configure the key servers with the two labels and configure the DS8700 forrecovery key support before the DS87000 can be configured for single or dual labels. If thekey servers are incorrectly configured or the recovery key is not configured, either the creategroup will fail or the DS8700 will fail to power on. For details about configuring a DS8700 fordual platform support, see Chapter 23, “DS8000 encryption features and implementation” onpage 771.Example of dual platform key server supportFigure 3-12 assumes that the primary Tivoli Key Lifecycle Manager is on System z and thesecondary Tivoli Key Lifecycle Manager is on System x. 1. Generate A Key System z System x Pair on Each Platform Key Server Key Server labelX TKLM 2. Exchange the public TKLM labelZ unwrapping keys HSM 4. Generate new symmetric key and wrap with key labelZ and labelX 3. Request new Key Repositor y symmetric key (DK) DS8700 5. T he DS8700 stores both EEDKsFigure 3-12 Dual key platform supportThe 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. Chapter 3. IBM storage encryption methods 71
    • System z Key Server S ystem x (Unavailable due to Key Server deadlock) TKLM 3. TKLM Unwraps the Symmetric TKLM Key associated with Key labelX (T his Key Server has the private key for labelX) HSM 4) Return unwrapped symmetric Key 1. Power on DS8700 Key Repositor y 2. Request TKLM to Unwrap Wrapped Symmetric Keys the Symmetric Key by sending both Key labelZ and labelX 5. DS8700 now has the wrapped keys unwrapped symmetric key DS8700 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.72 IBM System Storage Data Encryption
    • y y S ys tem z HS M in Sec ure Key mode, DS 8700 wi th Tw o K ey Labels and Rec ov ery K ey Sy stem z to Sy stem z HS M Repli cation through ICSF S ys te m x to Sy stem x Repl ic ati on via T KLM B ac kup Res tor e TK LM Ex por t/Im port to Copy P ublic K eys B etween S y stem z and IK S Key Stor es Coor dinated M of N Site 1 Syste m z C EC M as ter Key s Syst em z C EC Site 2 Sec ure Key S ecure K ey KS ICS F KS Syste m x IKS K ey Syste m x IKS x/ z Pushes x/ z Cl ear Key M a nu al M a nu al Cle ar K ey G KS GKS Pub l ic Clear K ey KS Pub l ic KS K ey Ke y KS P u sh es L PAR LP AR LPA R LPAR Pu sh es T KL M LP AR L PAR T KL M T KLM TK LM x M anu al Export/ Im p ort or Backup /R estore K ey Re pos itor y K ey Reposi tory Key-Pai r Pu sh R ecove ry Ke y Re covery Key w / Dual C ont rol D S8 70 0 D S87 00 w /D ual Co ntrol Figure 3-14 Tivoli Key Lifecycle Manager multiple site environment3.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. 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. 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: System-Managed Encryption (SME) Library-Managed Encryption (LME) Application-Managed Encryption (AME) 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. 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. Chapter 3. IBM storage encryption methods 73
    • 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.74 IBM System Storage Data Encryption
    • Application Layer Encryption Key Manager Policy System Layer Library LayerFigure 3-15 System-Managed Encryption (SME)System-Managed Encryption for open systemsYou set up encryption policies that specify when to use encryption in the IBM tape devicedriver. For details about setting up System-Managed Encryption on tape drives in an opensystems 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 foryour tape library.On open systems, this support is described as in-band where tape drive requests to the EKMcomponent travel over Fibre Channels to the server hosting EKM.System-Managed Encryption for System zOn z/OS encryption, you set up policies specifying when to use encryption in Data FacilityStorage Management Subsystem (DFSMS). You can also use additional software products,such as IBM Integrated Cryptographic Service Facility (ICSF) and IBM Resource AccessControl Facility (RACF). EKM performs the key generation and management. EKM runs onthe host or externally on another host. Policy controls and keys pass through the data pathbetween the system layer and the encrypting tape drives. Encryption is transparent to theapplications.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-poolbasis. DFSMS storage constructs are used by z/OS to control the use of storage pools forlogical volumes, resulting in an indirect form of encryption policy management. For moreinformation, refer to Chapter 19, “Implementing TS7700 tape encryption” on page 613. Or,refer to the white paper, IBM Virtualization Engine TS7700 Series Encryption Overview, whichis available at this website:http://www.ibm.com/support/docview.wss?&uid=ssg1S4000504For information about encryption, refer to DFSMS Software Support for IBM System StorageTS1120 Tape Drive (3592), SC26-7514. Chapter 3. IBM storage encryption methods 75
    • 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. System z Encryption Key Library Manager Manager 3953 / 3494 Library Manager Interface IOS Key Exchange Interface FICON Subsystem TS1120 Proxy Proxy Drive Tape Drive Interface Encryption ESCON/ TS1120 Tape FICON Control Controller Interface or 3592-J70 Figure 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 TS770076 IBM System Storage Data Encryption
    • 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. Encryption TS7700 EKM Interface Key Virtualization Manager Library Engine Manager EKM Library Manager Interface Interface 3953 / 3494 Subsystem Proxy Library Manager Interface Drive System z Interface TS1120 Tape Drive FICON Subsystem (Back End) Proxy Proxy ESCON/ Encryption FICON TS1120 Tape Drive Control Interface Interface TS1120 Controller or 3592-J70 Tape Drive Figure 3-17 Out-of-band encryption key flow3.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 Chapter 3. IBM storage encryption methods 77
    • 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. Application Layer Encryption Key Manager System Layer Library Policy Layer 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 operator’s guide. The following IBM tape libraries support Library-Managed Encryption: IBM System Storage TS3500 Tape Library IBM TotalStorage® 3494 Tape Library IBM System Storage TS3310 Tape Library IBM System Storage TS3200 Tape Library IBM System Storage TS3100 Tape Library78 IBM System Storage Data Encryption
    • 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.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. Chapter 3. IBM storage encryption methods 79
    • Obtains KEK labels/methods Requests DK using KEK labels/methods Validates drive in Drive Table Requests a Data Key (DK) Generates a random DK Requests KEKs using KEK labels/method Retrieves KEK pairs Requests DK to be wrapped with public half of KEKs generating two EEDKs Creates EEDKs Sends EEDKs Writes EEDKs to three locations on tape and into CM Encrypts write data using DK Keystore Crypto Services EKM TS1120 Figure 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.80 IBM System Storage Data Encryption
    • Reads EEDKs from tape or from CM Requests unwrap of DK from EEDKs Validates drive in Drive Table Requests KEKs for EEDKs Retrieves KEK pairs Requests unwrap of DK from EEDKs using KEKs Unwraps DK from EEDKs Sends DK Encrypts/decrypts data using DK Keystore Crypto Services EKM TS1120 Figure 3-20 Key and data flow for decryption using SME or LME3.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. 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. Chapter 3. IBM storage encryption methods 81
    • Policy Application Layer System Layer Library Layer 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: IBM System Storage TS3400 Tape Library IBM System Storage TS3500 Tape Library IBM TotalStorage 3494 Tape Library 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 IBM System Storage TS3100 Tape Library IBM System Storage TS3200 Tape Library IBM System Storage TS3310 Tape Library IBM System Storage TS3500 Tape Library 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 EKM: AME does not use or support EKM. 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. Tivoli82 IBM System Storage Data Encryption
    • Storage Manager then sends the data key to the tape drive. Using the AES algorithms andthe data key that was sent to it, the tape drive encrypts data to the tape. TSM Server Tape Drive  Tape ID  Generate Data Key  Store Data Key in DB  Encrypt Data  Data Key with Data Key Database  Encrypted  Tape ID Tape ID Data Key Data Tape1 AES Data Key1 Tape2 AES Data Key2 Tape Tape3 AES Data Key3 AES 256 ... ... Encrypted DataFigure 3-22 Application-Managed Encryption data flow for encryptionFigure 3-23 on page 84 depicts the flow of data and keys when using AME to read orwrite-append an encrypted cartridge. In this diagram, IBM Tivoli Storage Manager is theapplication that controls encryption.In our example, an encrypted tape is mounted for decryption. The tape drive reads the tapeID or VOLSER and sends that information to the IBM Tivoli Storage Manager. The IBM TivoliStorage Manager looks up that tape ID in its internal database and locates the entry that isassociated with it. Tivoli Storage Manager then decrypts the data key from the entry. The IBMTivoli 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 the256-bit AES data key and the AES algorithms to yield clear data. Chapter 3. IBM storage encryption methods 83
    • TSM Server  Tape ID Tape  Search Table for  Data Key Drive Tape ID  Retrieve DataKey  Decrypted  Decrypt Data with Data Key from Database Data Database  Encrypted  Tape ID Tape ID Data Key Data Tape1 AES Data Key1 Tape2 AES Data Key2 Tape Tape3 AES Data Key3 AES 256 ... ... Encrypted Data Figure 3-23 Application-Managed Encryption data flow for decryption3.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 library’s control unit to have network access.84 IBM System Storage Data Encryption
    • z/OS System z Open Systems KS Server Server DFSMS Uses ICSFs (Any instance Linux; zLinux; ICSF crypto services of IBM JVM) i5/OS, AIX; & key store Windows; EKM Solaris; data HP-UX IBM JVM Device FICON proxy EKM KS Driver Eth IB keys OB keys FC (z/OS) DD DFSMS keys tells drive Key to encrypt req. LAN/WAN any ATL a given LM OB keys cartridge keys (non-z/OS) CU Library (J70 or C06) Eth Proxy FC FC Key is served if TS3500 or 3494 drive is <OB to drive> authorized RS422 <IB to drive> 3592 3592 ATLFigure 3-24 Encryption in a mixed environment Chapter 3. IBM storage encryption methods 85
    • 86 IBM System Storage Data Encryption
    • 4 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 TS3200 Tape Library Express Model – IBM TS3310 Tape Library – IBM TS3400 Tape Library IBM System Storage TS3500 Tape Library IBM TotalStorage 3494 Tape Library© Copyright IBM Corp. 2010. All rights reserved. 87
    • 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 Controller1 IBM 3494 Models B10 and B20 Virtual Tape Server1 (VTS) in J1A emulation mode Important: To use tape encryption on a System z server, the TS1120 has to attach to the host through a TS1120 Model C06 Tape Controller, the IBM 3592-J70 Controller, or the TS7700 Virtualization Engine. 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 marketing88 IBM System Storage Data Encryption
    • 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. 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.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. Chapter 4. IBM System Storage tape automation for encryption 89
    • 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. J1A emulation mode: The IBM TS1120 Tape Drive cannot be encryption enabled while running in J1A emulation mode. Upgrading TS1120 to TS1130 If your TS1120 is still under warranty or a service contract, you can upgrade it to a 3592-EU6. Refer to Figure 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 necessary90 IBM System Storage Data Encryption
    • 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.4.1.3 TS1130 characteristics 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 Chapter 4. IBM System Storage tape automation for encryption 91
    • 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 User’s 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.wss92 IBM System Storage Data Encryption
    • 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 Usable Native Native Native Native Data Facility type length capacity capacity capacity capacity Storage 3592-J1A 3592-E05 3592-E05 3592-E06 Management (E1 format) emulating J1A (E2 format) or Subsystem (E1 format) 3592-EU6 (DFSMS) (E3 format) Data JA 570 m 300 GB 300 GB 500 GB 640 GB MEDIA5 (1870 ft. 1.6 in.) Extended JB 785 m N/A N/A 700 GB 1000 GB MEDIA9 Data (2575 ft. 6.5 in.) Economy JJ 204 m 60 GB 60 GB 100 GB 128 GB MEDIA7 (669 ft. 3.7 in.) WORM JW 570 m 300 GB 300 GB 500 GB 640 GB MEDIA6 (1870 ft. 1.6 in.) Economy JR 204 m 60 GB 60 GB 100 GB 128 GB MEDIA8 WORM (669 ft. 3.7 in.) Extended JX 785 m N/A N/A 700 GB 1000 GB MEDIA10 WORM (2575 ft. 6.5 in.) Chapter 4. IBM System Storage tape automation for encryption 93
    • 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. WORM WORM R/W R/W 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.94 IBM System Storage Data Encryption
    • 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 drive’s microcode handles a WORM cartridge. The drive microcode does not allow writing over the data or erasure of previously written user data, such as records or file marks; however, appending new data following existing data is supported. Final destruction of WORM cartridges 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. Rekeying: Instead of physically deleting or destroying the data, consider rekeying WORM cartridges and deleting the key after the rekeying operation.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. Chapter 4. IBM System Storage tape automation for encryption 95
    • 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. Tape drives: The IBM TS1120 Tape Controller supports 3592-J1A or TS1120 tape drives, but not IBM 3590 tape drives.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 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.96 IBM System Storage Data Encryption
    • 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 library’s 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 Chapter 4. IBM System Storage tape automation for encryption 97
    • 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 Frame Attachments 3953 Tape Frame Model F05 (base) Zero to one IBM TS1120 tape controllers 3953 Tape Frame Model F05 (expansion) One to three IBM TS1120 tape controllers A fully configured 3953 Tape System (3953-F05 frames and 3953-L05 Library Manager) can have up to sixteen subsystems attached (tape controllers, TS7700 Virtualization Engines, or Virtual Tape Servers (VTSs)). If the maximum of two TS7700 Virtualization Engines (or VTSs) is attached, you can only have fourteen TS1120 controllers. Figure 4-6 shows a sample of a TS1120-C06 installation and configuration in a 3953-F05 base frame with two 3953-F05 expansion frames. Ethernet Switch Ethernet Router Ethernet Router Ethernet Switch Ethernet Router Ethernet Router TS7700#2 Fibre Switch C06-Fibre Switch C06-Fibre Switch TS7700#2 Fibre Switch C06-Fibre Switch C06-Fibre Switch TS7700#1 Fibre Switch C06-Fibre Switch C06-Fibre Switch TS7700#1 Fibre Switch C06-Fibre Switch C06-Fibre Switch C06 Fibre Switch C06-Fibre Switch C06-Fibre Switch C06 Fibre Switch C06 Fibre Switch C06 Fibre Switch LMB TS3000 Switch Monitor/Keyboard TS3000 System Console C06-4 C06-7 ... KVM Switch P P P P P P O O O C06-3 O O C06-6 O W LMA W W W W W E E E