sSE04 - Full Disk Encryption For IBM Disk

System Storage Technical University
Full Disk Encryption for IBM Disk

sSE04
Craig Gordon Americas Storage ATS ckgordon@us.ibm.com
2011 IBM Corporation
Agenda
Why use Full Disk Encryption (FDE)? DS8000 Key Servers
TKLM Tivoli Key Lifecycle Manager ISKLM IBM Security Key Lifecycle Manager
DS5000 Best Practices
Why encrypt disks in the Storage Unit?

Breach of Security is defined as the loss of confidentiality (secret data exposed), integrity (unauthorized users modifying data), or availability (system unusable) The DS8000 and DS5000 FDE features address data confidentiality
DDM Replacement Lease Expiration
Active authentication mechanisms in place while Storage in use This disappears when equipment is removed from environment (and no one should be authorized access to this data)
Logical Volume does not equal physical volume
Not all customer data resident on disk is host accessible
Secure erasure is an option (possibly a compliance issue) Encryption is an option

2011 IBM Corporation 3
IBMs policy concerning data on replaced HDDs

Defective hard disk drives (HDD) are handled through a controlled process that begins at the time of replacement, either by you, the customer, or an IBM service representative. The data on returned defective drives are either deleted during the repair process or the drive is scrapped. Because no erasure or destruction process can be guaranteed to be completely effective IBM recommends that, whenever possible, you attempt to delete any data that might remain on the HDD before returning the drive to IBM. IBM further recommends that if any data is subject to protections by federal, state, or local laws, you take appropriate measures to ensure the affected data is stored sufficiently unintelligible through commercially available encryption technologies that require a security key, known only to you, to access the protected data. IBM follows two methods for the processing of defective HDDs that include data removal or destruction.
HDD's that are designated to be repaired are retained by the IBM Service Representative at the time the defective drive is replaced. These drives are then returned to an IBM parts consolidation center using IBM's controlled Used Parts Return process and subsequently sent through the parts repair process at an IBM repair center. The repair process includes the electronic resurfacing and a complete format of the drive. Once the re-utilization process has been completed, quality seals are installed on each HDD. If the test process fails then the HDD is scrapped. HDD's designated for scrap are retained by the IBM Service Representative at the time the defective drive is replaced. These drives are then returned to an IBM parts consolidation center using IBM's controlled Used Parts Return process where they are scrapped. The scrap process includes total destruction and disposal of the HDD according to established environmental standards.
In the case where returned HDD's are handled by a third party, IBM requires such third party to follow specific guidelines for handling and protecting information. IBM Business Practices/Contracts and Negotiations Section Re: Data Security Procedure of Returned Magnetic Media
Whats on a data disk in the DS8000?

What if we removed a disk from the DS8000? (Assuming the disk isnt a spare) What makes this different than a disk from a PC? Disk and Logical Volume Meta-data, available extents Data written on 256KB strips
One part in 3 or 4 if RAID10 array format One part in 6 or 7 if RAID 5 array format Rotating Parity (one strip in 7 or 8 disks is parity) Possible RAID rank types (5, 6, 10) D D D D D D D D D D D D D D S S D D D D D D D P D D D D D P D S
RAID10 4+4 RAID10 3+3 RAID5 7+P RAID5 6+P Minimum Logical Volume size, one extent=1GB(binary)=4096 strips
Simplest Case
D D
D D
D D
D D
RAID10 4+4
Logical Volumes (what the Host sees) are made up of extents
This includes
Disk Metadata
Strip 1 Strip 5 Strip 9 .
. .
Extent 1
Directory Freespace Files
Strip 4093
. . .
Extent N
Extents are spread across the physical disks in the Rank Unless the file is smaller than a strip, unlikely a whole file is visible Records and portions of files are certainly visible.
DS8000: Logical/Physical Volume Conclusions

One physical disk can hold the pieces of many logical volumes
Physical Disks create the disk array
As long as extents are available in the extent pool, logical volumes can be created Logical Volumes can also be deleted, returning the extents to the extent pool for volume creation
Dirty Extents marked as reusable, customer data remains
Means there may be data on the physical disk that no host can access Strategies to counter dirty extents (what you can do).
Upon LUN / logical volume creation, previous data is initialized (cleaned-up)
Define volumes on all extents in every extent pool
Array creation performs disk initialization too (MKARRAY) Or use Full Disk Encryption
Disk Defect Management

Sector Relocation Spare sectors are reserved in intervals across the disk surface When errors occur, a spare sector may get reassigned
managed with the Sector ID field
Although normal operations now will skip over the bad sector(s) data previously written remains in this area.
Image reproduced by permission of Hitachi Global Storage Technologies. Unauthorized use not permitted.
IBM Encryption Whitepaper and Redwork

IBM Encrypted Storage Overview and Customer Requirements
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101479
4/2/2010 Rick Ripberger IBM System Storage DS8000 Disk Encryption Implementation and Usage Guidelines http://www.redbooks.ibm.com/abstracts/redp4500.html?Open IBM System Storage Data Encryption Redbook SG24-7797-00 http://www.redbooks.ibm.com/abstracts/sg247797.html?Open This presentation is an overview of these papers and the IBM Announcements concerning DS Full Disk Encryption features
Explanation of terms and concepts concerning encryption and FDE.
Cryptography 101
Encryption is encoding data with an encryption key Decryption requires a key Encrypted data is called Ciphertext Non-encrypted data is called plaintext or cleartext If done correctly, it is prohibitively difficult to derive cleartext from ciphertext without the decryption key A strong Cipher requires resolution by key or brute force Properly encrypted data is securely secret from anyone who does not have the decryption key An encryption/decryption key is preferably random numbers of a bit length specified by the encryption algorithm
Encryption / Decryption Process

Encryption Process Clear Text
Key
Encryption algorithm (e.g. AES)
Cipher Text (Encrypted Data)
Decryption Process Cipher Text Encryption algorithm

Key
Clear Text
Data that is not encrypted is referred to as clear text Clear text is encrypted by processing with a key and an encryption algorithm
Several standard algorithms exist, include DES, TDES and AES
Keys are bit streams that vary in length

For example AES supports 128, 192 and 256 bit key lengths
Cryptography 101 (cont.)

Distributed Encryption Standard (64 bit DES) can be broken in about 22 hours on Todays computers
Breaking involved use of a distributed application called EFF Cracker on 1000s of PCs (like SETI or Folding) This technique is known as Brute Force
Triple DES is expected to be broken in about the year 2030 (via Brute Force) Advanced Encryption Standard (AES) hasnt seen its end date yet. (i.e. AES is considered stronger than TDES).
Considered a Block Cipher (128-bit block size and 128,192, or 256-bit keys)

One class of cipher depends if the key used by the algorithm is symmetric or asymmetric Symmetric key algorithms use the same key for encryption and decryption
These keys are referred to as as private or secret keys Very efficient algorithms for creating/decoding ciphertext Need a secure method to transfer key between parties
Asymmetric keys use different (but mathematically related) keys for encryption and decryption
These keys are referred to as private/public key pair Provides a method to transfer key securely between parties
Decryption requires access to the proper key and ciphertext

If all copies of the decryption key are lost, the ciphertext has been cryptographically erased. -and- If the only copies of some data exist as ciphertext, and no decryption key exists, then this data is permanently lost
Symmetric Encryption
Eg., Data Key
Data that is not encrypted clear text Clear text is encrypted by processing with a key and an encryption algorithm Keys are bit streams
128, 192, 256 bit key length
Symmetric encryption same key to encrypt and decrypt
Asymmetric Encryption
Eg., Key Encrypting Key
The key used to encrypt is often referred to as the Public key, eg. the KEKs used to wrap the DK and create the EEDKs. The Public key may be made widely available without fear of compromise. The Key used to decrypt is referred to as the Private key. Private Keys must be secured against unauthorized access. Public / Private encryption is widely used for exchange of data between organizations.

Disclosure to a person or system component (an agent) of an decryption key creates a security exposure if that agent also has access to cyphertext generated with the associated decryption key To preserve the integrity of encryption keys, they may also be encrypted (wrapped)
Decryption then requires decrypting the data key, then using the result to decrypt the ciphertext.
IBM Encrypting Storage uses a Key Server to store wrapping keys The agent that stores or has access to the encrypted data keys is a storage device Only when the Key Server is united with the proper storage device(s) can the ciphertext become cleartext.
Key Servers
To preserve access to encryption keys more that one Key Server needs access to any single piece of information needed to determine the encryption key (redundant key servers, consistent key stores). These redundant Key Servers use independent communication paths to the storage devices Backups of each Key Servers data are maintained. Failure of any Key Server or any network does not prevent storage devices from obtaining access to data keys required to access data (worst case, data must be restored to a new Key Server). Redundancy is also provided on the storage media by providing multiple copies of the encrypted data key
Implementation of DS8000 FDE
Encryption Process
DS8000 Host
Apps
H A
D A
Encrypted Disk
HMC
Clear text
TKLM
IBM Tivoli Key Lifecycle Manager (TKLM)

The TKLM works with IBM encryption-enabled storage devices in generating, protecting, storing and maintaining encryption keys that are used to encrypt information being written to and decrypt information being read from storage media. TKLM executes in the IBM Java run time environment and it uses IBM Java security components for the cryptographic capabilities used. Supported Operating Systems TKLM
AIX 5.3 and 6.1 Red Hat AS 4.0 Red Hat AS 5.0 Suse Linux 9, 10, 11 Solaris 9, 10 Sparc Windows Server 2003 or 2008 z/OS V1 R9, R10, or R11
(TKLM Version 1, hosted in the System Services Runtime Environment for z/OS)
Designed to be Easy to use

Provide a Graphical User Interface
Initial configuration wizards
Easy backup and restore of TKLM files

One button, single jar file
Lifecycle functions
Notification of certificate expiry Automated rotation of groups of keys
Same TKLM can be used with IBM DS8000, DS5000, and IBM Tape
TKLM continued
The keys used by TKLM are a public/private asymmetric key pair referred to as the public Key Encrypting Key (KEK) and the private Key Encrypting Key (KEK), respectively. The key generation and propagation processes on the TKLM, associate a Key Label to each wrap/unwrap pair This Key Label is a user specified text string and retained with each wrap/unwrap pair Key negotiation and authentication between TLKM and the DS8000 take place at DS8000/DS5000 power on. One TKLM key server can easily handle multiple DS8000s and DS5000s, the network traffic requirement is small
Security Key Lifecycle Manager for z/OS V1.1

Attributes of encryption and key management:
Encryption in storage hardware does not hurt performance Encryption and key management doesnt require changing applications, middleware, JCL, operating systems Key management completely separate from the data path Storage arrays and libraries contact the key manager on behalf of the application and hosts doing I/O With disk arrays done at power up With tape libraries at each cartridge mount Encryption and key management fits into your operations management Separation of duties Leverage investments in high availability and security
ISKLM V1.1 benefits:

Easy upgrade from EKM, easy SMPE install Still supports ICSF, RACF, crypto express hardware Writes SMF records type 83 subtype 6 audit records Supports all of the latest system z/OS centric storage tape and disk No longer requires DB2 or SSRE Goal was simplest key serving with no co-reqs
Disk Storage Array
3592 Enterprise Tape Library
IBM DS8000 Disk Encryption

New DS8000 hardware w/Full Disk Encryption (FDE Feature) GA March 6th, 2009
DS8700 Drives: DS8800 Drives: 300GB 450GB 15K RPM 300GB 450GB 10K RPM
Customer data at rest is encrypted

Data at rest = data on any disk or in any persistent memory
Customer data in flight is not encrypted

Data in flight = on I/O interfaces or in dynamic memories (Cache, NVS)
Uses Encrypting Disk

Encryption hardware in disk (AES 128) Runs at full data rate
Integrated with Tivoli Key Lifecycle Manager (TKLM)

Requires new DS8000 HMC Feature (1120/1130) DS8000 network attachment to TKLM (TCP/IP) DS8000 automatically communicates with TKLM when configuring encryption group or at power on to obtain necessary encryption keys to access customer data
Supports cryptographic erasure of data (change of encryption key) Key attack vectors being addressed:
Disk removed (repair, or stolen) Box removed (retire, or stolen)
IBM procedure to sign a Customer Agreement and to activate Encryption function on each SFI
IBM DS8000 Disk Encryption

One Encryption Group per Storage Facility Image (One Key on TKLM) No intermix of encrypting and non-encrypting DDMs New factory order only, no field MES to add encryption to existing non-encrypting machines only to add encryption capacity to an encryption capable machines. Entire storage facility image is either all encrypted or all not encrypted - selected when configure first rank
Encryption Group 1/0

Encrypted Logical Volumes in Encryption Group 1
Non-Encrypted Logical Volumes
Non-Encrypting Extent Pools Encrypting Extent Pools

R1 A1 R2 A2 R3 A3 Rn An R5 A5 R6 A6 R7 A7 Rm Am
Encrypting Ranks Encrypting Arrays
Non-Encrypting Ranks Non-Encrypting Arrays
Encrypting Disks
.. Non-Encrypting Disks
Encrypting Disks on DS8000

All data on disk is encrypted
One or more data bands on disk Each data band has an encryption key
Data is always encrypted on write and decrypted on read Encryption key is wrapped with access credential and maintained within the disk Establishing a new encryption key causes cryptographic erasure
Access to data requires authentication

Each data band can be locked with an access credential
Access credential established by TKLM based on key hierarchy when band is locked Access credential converted to a secure hash and maintained within the disk Re-authentication required on locked band after disk power loss
Bands with encrypted customer data are locked by DS8000 before any customer data is stored on band Bands with unencrypted customer data are not locked by DS8000
Encrypting disks have band encryption key set, band unlocked, and data pre-initialized at factory so do not have to re-initialize when band is locked
DS8000 Encryption Network Environment

User
Configure Rank(s) (and lock bands)
StoragePlex DS8000 Storage Facility Storage Facility Image StoragePlex SFI Server SFI Server HMC
Dual HMCs Recommended
3 DSGUI / DS-CLI
Configure TKLM Ports 2 DS8000 Encryption Group
HMC
Customer Network
Get New Data Key
TKLM GUI
Configure TKLM Devices & Key Labels
Key Lifecycle Manager Cryto-Services Key-Store

Up to 4 Redundant TKLM IP/Ports Supported
User
Encryption Dual Platform Key Server Support

DS8000 requires an Isolated Key Server in configuration to avoid encryption deadlock Isolated key server currently defined with xSeries server Customers using secure key mode key store on different platforms cannot integrate with isolated key servers because cannot propagate keys cross key server platforms in secure key mode Dual Platform Key Server support allows two different key server platforms to be configured with either platform operating in either clear key or secure key mode
28 2011 IBM Corporation
Dual Platform Key Server Support

TKLM uses asymmetric keys to wrap a symmetric data key needed by a DS8000 to unlock encrypted disks Protocol can provide the data key wrapped by the public keys of two different key labels Originally used by Tape for exporting tapes between companies Can be exploited to support two key server platforms on disk Key Management Key Server Platform 1 configures key label 1 that generates an asymmetric key pair. Export the public key to the other platform Key Server Platform 2 configures key label 2 that generates an asymmetric key pair. Export the public key to the other platform All key servers now have two public keys for two key labels and can generate data keys wrapped for both key labels DS8000 must store wrapped data keys for both key labels When DS8000 needs to unwrap the data key, DS8000 sends both wrapped keys and any key server can unwrap at least one of the two wrapped data keys Cross-platform server key transfers are secure because only send public keys - can be used with secure key HSMs on one or both platforms
Dual Key Server Platform Support

Isolated Key Server(s) Generic Key Server(s)
TKLM
HSM
TKLM
HSM
Key Repository
DS8000

Isolated Key Server(s) Generate A Key Pair on Each Platform Generic Key Server(s)
TKLM
HSM
TKLM
HSM
Public Wrapping Keys Private Unwrapping Keys

Key Label 1 Key Label 2
Key Repository
DS8000

Isolated Key Server(s) Exchange Public Key of each Key Pair Between Platforms Generic Key Server(s)
TKLM
HSM
TKLM
HSM

Key Key Label Label 1 2 Key Key Label Label 2 1
Key Repository
DS8000

Isolated Key Server(s) Replicate Key Stores within Each Platform Generic Key Server(s)
TKLM
HSM
TKLM
HSM
Key Repository
DS8000

Isolated Key Server(s) Create Encryption Group on DS8000 Generic Key Server(s)
TKLM
HSM
TKLM
HSM
Key Repository
1) Request New Symmetric Key
Key Label 1 & 2
DS8000

TKLM
HSM
TKLM
HSM
Key Repository
2) Generate Symmetric Key and Wrap for Key Labels 1 and 2
DS8000

TKLM
HSM
TKLM
HSM
Key Repository
3) Return New Symmetric Keys Wrapped Symmetric Keys Symmetric Key
DS8000

Isolated Key Server(s) Normal Disk Operation TKLM
HSM
Generic Key Server(s)
TKLM
HSM
Key Repository
Wrapped Symmetric Keys Symmetric Key DS8000


Isolated Key Server(s) Power Off DS8000 Generic Key Server(s)
TKLM
HSM
TKLM
HSM
Key Repository


Isolated Key Server(s) Power Off DS8000 Generic Key Server(s)
TKLM
HSM
TKLM
HSM
Key Repository
Wrapped Symmetric Keys
DS8000

Isolated Key Server(s) Power On DS8000 Unwrap Symmetric Key Generic Key Server(s)
TKLM
HSM
TKLM
HSM
Key Repository
1) Request Unwrap Symmetric Key sending both Key Label 1 and 2 wrapped keys
DS8000

TKLM
HSM
TKLM
HSM
Key Repository
2) Unwrap Symmetric Key associated with Key Label that this Key Server has the private key for
DS8000

TKLM
HSM
TKLM
HSM
Key Repository
3) Return unwrapped symmetric Key DS8000

Wrapped Symmetric Keys Symmetric Key

Isolated Key Server(s) Normal Disk Operation TKLM
HSM
Generic Key Server(s)
TKLM
HSM
Key Repository

Multi-Site zSeries/Disk Encryption at R4.2 with xSeries IKS All Key Servers in Clear Key Mode
Site 1
System z Key Store Backup replicated cross site by Disk Mirror Restore Mirror At Secondary Site to Replicate Key Stores TKLM Export/Import to Copy from zSeries Key Store to IKS No Support for System z ICSF secure key mode, Single Key Label on DS8000 Series z CEC Series x IKS
Clear Key KS TKLM General Key Servers (GKSs) Manual Key-Pair LPAR Push TKLM
Site 2
Series z CEC
General Key Servers (GKSs) Manual Key-Pair Push
Series x IKS
Clear Key KS TKLM
LPAR LPAR
LPAR LPAR
LPAR
TKLM
Key Repository
Clear Key KS
Clear Key KS
Key Repository
DS8000
DS8000
Non-Encrypting
DS8000
Non-Encrypting
DS8000
Multi-Site zSeries/Disk Encryption at R5.0 with Secure Key zSeries HSM and Clear Key xSeries IKS
System z HSM in Secure Key mode, DS8000 with Two Key Labels and Recovery Key System z to System z HSM Replication through ICSF System x to System x Replication via TKLM Backup Restore TKLM Export/Import to Copy Public Keys Between zSeries and IKS Key Stores
Site 1
Series x IKS
Clear Key KS TKLM
Series z CEC
Secure Key KS x/z Manual GKS Public Key LPAR Pushes TKLM
Coordinated M of N Master Keys ICSF Key Pushes
Series z CEC
Secure Key KS
Site 2
Series x IKS x/z Manual Public Clear Key Key KS Pushes TKLM
GKS LPAR LPAR LPAR LPAR LPAR

TKLM
x Manual Export/Import or Backup/Restore Key-Pair Push

Recovery Key w/Dual Control
Key Repository
Key Repository
Recovery Key w/Dual Control
DS8000
DS8000
DS8000 Data Encryption Management Overview

Customer configures one or more storage facility images on TKLM Customer Configures one or more key labels on TKLM Customer configures one or more TKLM IP ports on DS8000 (up to 4 TKLM ports) Customer configures one encryption group on each Storage Facility Image.
Customer provides a key label for an encryption group DS8000 communicates with TKLM to get necessary keys to manage each encryption group
Customer configures one or more encryption capable ranks in an extent pool that is configured for encryption group.
Ranks and extent pools have an encryption group attribute: Encryption Group 0 designates No Encryption Encryption Group 1, designates Encryption DS8000 locks data bands on encryption disks that are configured in an extent pool that is configured for encryption group 1
Customer configures logical volumes in the extent pool

Data for these logical volumes is stored on encrypting disks that have locked data bands
Deleting a rank causes SFI to reset the encryption key on the disks in the rank causing cryptographic erasure.
Disks are reinitialized whenever a rank is deleted (encrypting or non-encrypting)
Copy services functions are performed in the clear encryption does not affect
DS5000 Full Disk Encryption

Minimum levels of DS5000 firmware of Version 7.60.xx.xx and Storage Manager 10.60 Support for an external key server (TKLM V2) requires firmware 7.70.xx.xx or higher Current drives include 300GB, 450GB, and 600GB 15K RPM Fiber Channel drives Options for internal key management or external key management
47
DS5000 Internal Key Management

Storage Manager is used to create a security key that will be used to wrap the encryption keys for individual DDMs The user provides a pass-phrase which is used to encrypt the security key, which is written to the security file in 2 locations external to the DS5000 controllers The security file is also stored to the DDMs that are encryption enabled The security key is also stored as obfuscated cipher text within the controllers and is used to unlock drives, as needed within the same subsystem The security key can be changed through the Storage Manager, at which time the controllers will negotiate a new wrapping key with each DDM The security file and the pass-phrase must be protected
48
DS5000 Internal Key Management (2)

It is critical that access to the Storage Subsystem be restricted by enabling a password required to gain access to an FDE enabled storage subsystem
The security file discussed above contains the security key needed to unlock the drives, and anyone with access to the Storage Subsystem can create a new security file, with their own pass-phrase, and thereby have access to unlock the drives.
An encryption enabled array can be exported to another encryption capable subsystem

Export the array from the source storage subsystem Move the DDMs to the target storage subsystem Import the array, providing the security file and pass-phrase used to enable the drives on the source subsystem The target subsystem will validate the keys and will negotiate a new key with each imported DDM, so the target subsystem will still be managed by a single security file/key.
DS5000 External Key Management

TKLM V2 is the currently supported external key manager It is necessary to install and configure a DS TKLM Proxy Server, which will direct requests for security keys from the controllers to the TKLM server TKLM will generate the security key instead of the controller, and can be used as a central source of encryption keys It is still possible and recommended to use the Storage Manager to backup the security key into a security file, using a encrypting passphrase. The security file and pass-phrase must be secure. With external key management, since the security key is only stored (obfuscated) in volatile system memory in the controller, at least one DDM in the subsystem is required to NOT be FDE enabled. This will allow the controller to boot to the point of contacting the proxy server to obtain the security key to unlock the enabled drives If it is not possible for the controller to boot, it will be possible to provide the security file and pass-phrase
Deadlock Prevention
One Critical Consideration with using a key server implementation is that all code and data objects required to make the key server operational must not be stored on a storage device dependent on any key server to be accessed. Potential for all encrypted data managed by Key Servers to be permanently lost Examples of a deadlock: TKLM server boot disk located on encryption enabled drive TKLM Data Base / program code located on encryption enabled drive TKLM backup on encryption enabled tape For DS80000, use of an Isolated Key Server is required Key Server backups cant reside on encrypted media DS8000 Feature Code #1760 will provide Isolated Key Server Hardware and pre-installed TKLM software
Deadlock Creation Factors

Besides poor design (examples on the previous chart), there are a number of factors that can eventually lead to a deadlock occurring.
Layers of Virtualization can make it difficult to know where data resides Transparent Data Relocation Consolidation of Servers and Storage Difficult to determine if deadlock exists without power cycling the storage complex Servers supporting SAN Boot (and not supporting internal boot)
Encryption Environment must be managed to a high standard of care to prevent deadlock occurrence
New Recovery Key Functions

DS8000 Release 5.1 and above provides the requirement to create a Recovery Key and the ability to disable the Recovery Key The Recovery Key is a 256 bit AES key that can be used by a security administrator to overcome an encryption deadlock By default, when enabling encryption, a user with Security Admin authority initiates the request for a Recovery Key. The Storage Admin approves the request and the RK is presented to the SecAdmin and validated, the Storage Admin again approves and then encryption can be allowed. If the RK is needed, the SecAdmin will enter the RK and the StorAdmin has to approve the use of the RK. The double hand-shake can also be used to disable the use of the RK completely, which may be required for PCI compliance.
FDE Best Practices - Security

Physically secure the hardware, communications, and associated media Startup of TKLM key server requires a password
Can provide password through keyboard Could also use Start-up script Use access controls on this script to prevent tampering and provide audit
Maximum security is achieved when the key material is stored securely using the services of a Hardware Secure Module (HSM)
IBM provides this level of capability on System z using ICSF and the CryptoExpress 2 HSM
FDE Best Practices Security (2)

Factory default users and passwords should be changed or the factory users deleted after other user accounts with proper authority have been established On DS8000 Release 5.1 and above
the division between the roles of security and storage administrators must be maintained the recovery key must be securely maintained and accessible only to security administrators The re-label function can and should be used on a periodic basis by defining a new key label to TKLM and requesting the re-label function within the DS8000
Each DS5000 encryption enabled subsystem should be password protected to prevent unauthorized creation of the security file
FDE Best Practices - Availability

Use of Redundant Key Servers at each independent customer recovery site (4 possible, 2 required) For Lights out operation, Key Servers and Key server application should be configured to automatically power on and boot Provide Redundant Network fabrics between key servers and encrypting storage Use DS8000 with Dual HMC
FDE Best Practices Deadlock Prevention

Review and understand the white paper
IBM Encrypted Storage Overview and Customer Requirements
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101479 April 2010 Rick Ripberger
Customer personnel need to review Customer Encryption documentation annually. Anyone who:
Implements or configures TLKM key servers or encrypted storage products Responsible for Key Server Backups
Review and update Systems Management processes related to configuration and change management of key servers and encrypted storage.

Implement automated monitoring of the availability of any equipment associated with the management of key services and take appropriate action to maintain proper operations. Review Disaster recovery plans providing consideration for the availability of key servers, key server backups and key server synchronization Isolation of network paths to remote key servers (a planned site power cycle is a way to verify no deadlock condition exists).

Two redundant key servers are required. Redundancy implies that the key servers do not share any single point of failure. For Key Servers operating in LPARs, do not implement data sharing such that there is one copy of data shared by independent key servers. One Isolated key server (IKS) is required per recovery site. Isolated key server is a dedicated set of server resources running only the TKLM application and its associated software stack, that are directly attached (no switches) to dedicated non-encrypted storage resources Configuration of general key servers is allowed after IKS requirement is met.

Configuration of key servers at independent sites is recommended. This provides further deadlock protection as it is unlikely all Key Servers would ever experience a simultaneous power loss. Use of UPS on general key servers Ensure all Key Servers for a given storage device have a current and consistent key store content relative to the wrapping keys that the storage device requires.

Backup key server data after its updated and not place the backups on encrypted media that is dependent on a key server. Periodically audit all online and backup data required to make each key server operational data is stored on storage media that is not dependent on a key server to access the data. Choose to archive, not delete keys on the key server under normal circumstances. This reduces the possibility of data loss, and does not cause cryptographic erasure.

Manually configure DS8000s on TKLM rather than allow TKLM to automatically configure them. This reduces the chance of an unauthorized DS8000 gaining access to a key server. Each DS8000 should be assigned a unique key label in TKLM so that each DS8000 has a unique key encrypting key (KEK) assigned. IBM recommends 2 of 4 TKLM ports be assigned to IKS. Key servers at the local site should be preferred to remote key servers to improve availability.

The DS8000 verifies 2 key servers are configured on and accessible to the DS8000. The DS8000 will reject configuration requests until this condition is met If encryption has not been activated on the DS8000, the DS8000 will reject the configuration of ranks and extent pools with non-zero encryption group assigned.(applies to the installation of the Licensed Feature Key for Encryption) The DS8000 will monitor all configured key servers. Customer notification is provided for loss of access to a key server or other related Key Server errors through the DS8000 customer notification mechanism (SMNP traps or email, when configured). Monitoring these indications and taking corrective action is a best practice
DS8000 Data Encryption Summary

Requires DS8000 R4.2 LIC and TKLM
Initial release requires all disks encryption capable Enterprise Class Disk Features Supported
Entire Storage Facility is encryption-capable or not encryption capable. Applications continue to work unchanged. TKLM unwraps single key stored on DS8000 to unlock the entire Storage Facility Image.
DS8000 MUST be connected to at least 2 TKLM Servers. One of the two TKLM servers must be dedicated/isolated.
Designed to address confidentiality of data when single disks are removed for repair, and when the entire Storage Facility Image is discontinued or re-purposed READ IBM Encrypted Storage Overview and Customer Requirements
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101479
IBM Systems Lab Services and Training

is composed of experts who develop and deploy solutions across IBMs systems family offerings. From in-depth product expertise, to training, to platform-specific hardware and software solutions, were here for you!
Sample System Storage Services and Training

TS7650G Implementation / Configuration XiV Implementation Services IBM Certified Secure Data Overwrite Service Technical Project Management Information Infrastructure Storage Optimization Study or Workshop Storage Energy Analysis SAN Volume Controller (SVC) - Planning and Implementation (ILO) - Course IBM System Storage Tape Encryption Implementation (ILO) Course System Storage certifications Private and customized courses "No Travel Training" options (instructor-led online, e-learning, onsite training, etc.) Money saving IBM Education Packs Technical Conferences
Contact Us
stgls@us.ibm.com or visit ibm.com/systems/services/labservices
201165 Corporation IBM
Session Evaluations in 3 Easy Steps!

1 2
Go to:
http://ibmtechu.com
and complete the form
Select Register button (One time only)
Session Evaluations in 3 Easy Steps!

3
Select Session Evals button and complete the online form

Username, as created in step 2.
sSE04

sSE04 - Full Disk Encryption For IBM Disk

Uploaded by

Copyright:

Available Formats

sSE04 - Full Disk Encryption For IBM Disk

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

sSE04 - Full Disk Encryption For IBM Disk

Uploaded by

Copyright:

Available Formats

Why is data encryption important for storage devices?

Why is data encryption important for storage devices?

What are some best practices for configuring encryption on IBM storage devices?

What are some best practices for configuring encryption on IBM storage devices?

System Storage Technical University

Full Disk Encryption for IBM Disk

2011 IBM Corporation

System Storage Technical University

DS5000 Best Practices

2011 IBM Corporation

System Storage Technical University

Why encrypt disks in the Storage Unit?

Logical Volume does not equal physical volume

Not all customer data resident on disk is host accessible

Secure erasure is an option (possibly a compliance issue) Encryption is an option

System Storage Technical University

IBMs policy concerning data on replaced HDDs

System Storage Technical University

Whats on a data disk in the DS8000?

2011 IBM Corporation

System Storage Technical University

Directory Freespace Files

2011 IBM Corporation

System Storage Technical University

DS8000: Logical/Physical Volume Conclusions

2011 IBM Corporation

System Storage Technical University

Disk Defect Management

2011 IBM Corporation

System Storage Technical University

IBM Encryption Whitepaper and Redwork

2011 IBM Corporation

System Storage Technical University

Explanation of terms and concepts concerning encryption and FDE.

2011 IBM Corporation

System Storage Technical University

2011 IBM Corporation

System Storage Technical University

Encryption / Decryption Process

Encryption algorithm (e.g. AES)

Cipher Text (Encrypted Data)

Decryption Process Cipher Text Encryption algorithm

Keys are bit streams that vary in length

System Storage Technical University

Cryptography 101 (cont.)

2011 IBM Corporation

System Storage Technical University

Cryptography 101 (cont.)

Decryption requires access to the proper key and ciphertext

2011 IBM Corporation

System Storage Technical University

Eg., Data Key

Symmetric encryption same key to encrypt and decrypt

2011 IBM Corporation

System Storage Technical University

Eg., Key Encrypting Key

System Storage Technical University

Cryptography 101 (cont.)

2011 IBM Corporation