sSE04 - Full Disk Encryption for IBM Disk

©2011 IBM Corporation

System Storage Technical UniversitySystem Storage Technical University


Full Disk Encryption for IBM Disk

Craig GordonAmericas Storage [email protected]

sSE04



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� 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)� DDM Replacement� Lease Expiration

� 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

3



IBM’s 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



What’s on a data disk in the DS8000?

� What if we removed a disk from the DS8000? (Assuming the disk isn’t 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)

� Minimum Logical Volume size, one extent=1GB(binary)=4096 strips

RAID5 6+PRAID5 7+PRAID10 3+3

D DD D

D PD S

D DD D

D DD P

D DD S

D DD S

D DD D

D DD D

RAID10 4+4



Simplest Case

� Logical Volumes (what the Host sees) are made up of extents

� This includes � Directory� Freespace� Files

� 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.

�

D DD D

D DD D

RAID10 4+4

Disk Metadata

Strip 1

Strip 5

Strip 9 .

.

.

.

.

.

Strip 4093

Extent 1

Extent N



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 Guidelineshttp://www.redbooks.ibm.com/abstracts/redp4500.html?Open

� IBM System Storage Data Encryption Redbook SG24-7797-00http://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



� 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

Encryption Process

Encryption algorithm(e.g. AES)

Clear TextCipher Text (Encrypted Data)

Decryption Process

Encryption algorithm

Cipher Text

Clear Text

Key

Key

Encryption / Decryption Process



Cryptography 101 (cont.)

� Distributed Encryption Standard (64 bit DES) can be broken in about 22 hours on ‘Today’s computers’

� Breaking involved use of a distributed application called EFF Cracker on 1000s of PC’s (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) hasn’t 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



Eg., Data Key Symmetric Encryption

� 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



� 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.

Asymmetric EncryptionEg., Key Encrypting Key




� 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 Server’s 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

Encrypted Disk

Host

Clear text

HA

DA

DS8000

TKLM

HMC

Apps



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 doesn’t 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-reqsDisk Storage

Array

Enterprise Tape

Library

3592



IBM DS8000 Disk Encryption

� New DS8000 hardware w/Full Disk Encryption (FDE Feature) GA March 6th, 2009� DS8700 Drives: 300GB 450GB 15K RPM� DS8800 Drives: 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

Encrypting Arrays

……

A1 A2 A3 An

Encrypting Disks

R1 R2 R3 RnEncrypting Ranks

Non-Encrypting Arrays

…..……

A5 A6 A7 Am

Non-Encrypting Disks

R5 R6 R7 RmNon-Encrypting Ranks

Non-Encrypting Extent PoolsEncrypting Extent Pools

Non-Encrypted Logical Volumes

Encryption Group 1/0

Encrypted Logical Volumes inEncryption Group 1



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



StoragePlex

DS8000 Encryption Network Environment

Customer Network

Key Lifecycle Manager

Cryto-Services Key-Store

HMC

SFI Server SFI Server

Storage Facility Image

Storage Facility

HMC

StoragePlex

DSGUI / DS-CLI

Configure TKLM PortsDS8000 Encryption Group

Get New Data Key

Up to 4 Redundant TKLMIP/Ports Supported

Dual HMCsRecommended

DS8000

2

Configure Rank(s)(and lock bands)User

3

TKLM GUI

User

Configure TKLMDevices & Key Labels

1



28

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



29

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



30

Dual Key Server Platform Support

Isolated Key Server(s) Generic Key Server(s)

TKLM TKLM

HSM HSM

DS8000

Key Repository



31


TKLM TKLM

HSM HSM

DS8000

Public Wrapping Keys

Private Unwrapping Keys

Key Repository

Generate A Key Pair

on Each Platform


Key

Label

1

Key

Label

2



32


TKLM TKLM

HSM HSM

DS8000



Key Repository

Exchange Public Key of each

Key Pair Between Platforms


Key

Label

1

Key

Label

2

Key

Label

2

Key

Label

1



33


TKLM TKLM

HSM HSM

DS8000



Key Repository

Replicate Key Stores within

Each Platform




34


TKLM TKLM

HSM HSM

DS8000

1) Request New

Symmetric Key



Key Repository

Create Encryption Group

on DS8000


Key Label 1 & 2



35


TKLM TKLM

HSM HSM

DS8000



Key Repository


on DS8000

2) Generate Symmetric Key and

Wrap for Key Labels 1 and 2




36


TKLM TKLM

HSM HSM

DS8000



Key Repository


on DS8000

3) Return New

Symmetric Keys

Wrapped Symmetric Keys

Symmetric Key




37


TKLM TKLM

HSM HSM

DS8000



Key Repository

Normal Disk Operation


Symmetric Key




38


TKLM TKLM

HSM HSM

DS8000



Key Repository

Power Off

DS8000


Symmetric Key




39


TKLM TKLM

HSM HSM

DS8000



Key Repository

Power Off

DS8000





40


TKLM TKLM

HSM HSM

DS8000



Key Repository

Power On DS8000

Unwrap Symmetric Key

Wrapped Symmetric Keys1) Request Unwrap

Symmetric Key sending

both Key Label 1 and 2

wrapped keys




41


TKLM TKLM

HSM HSM

DS8000



Key Repository

Power On DS8000


Wrapped Symmetric Keys2) Unwrap Symmetric

Key associated with

Key Label that this

Key Server has the

private key for




42


TKLM TKLM

HSM HSM

DS8000



Key Repository

Power On DS8000



Symmetric Key

3) Return unwrapped

symmetric Key




43


TKLM TKLM

HSM HSM

DS8000



Key Repository

Normal Disk Operation


Symmetric Key




44

Multi-Site zSeries/Disk Encryption at R4.2 with xSeries IKSAll Key Servers in Clear Key Mode

TKLM

Series x IKS

Series z CEC

TKLM

LPAR LPARLPAR

General Key Servers (GKSs)

DS8000

Key Repository

DS8000

Key Repository

TKLM

Series x IKS

Series z CEC

LPARLPAR TKLM

LPAR

Site 1 Site 2

ManualKey-PairPush

DS8000Non-Encrypting

Clear Key KS

DS8000 Non-Encrypting

Clear Key KS

Clear Key KS

ManualKey-PairPush

General Key Servers (GKSs)

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

Clear Key KS



45

Multi-Site zSeries/Disk Encryption at R5.0 with Secure Key zSeries HSM and Clear Key xSeries IKS

TKLM

Series x IKS

Series z CEC

Secure KeyKS

TKLM

LPAR LPARLPAR

GKS

DS8000

Key Repository

DS8000

Key Repository

TKLM

Series x IKS

Series z CEC

Secure KeyKS

LPARLPAR TKLM

LPAR

GKS

Site 1 Site 2

ICSFKey Pushes

Recovery Key

w/Dual Control

Recovery Key

w/Dual Control

x/z ManualPublicKey Pushes

x/zManual PublicKeyPushes

Coordinated M of NMaster Keys

x Manual Export/Import orBackup/Restore Key-Pair Push

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

Clear Key KS

Clear Key KS



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 there-by 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.

49



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 pass-phrase. 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

50



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 can’t reside on encrypted media

� DS8000 Feature Code #1760 will provide Isolated Key Server Hardware and pre-installed TKLM software



Deadlock Creation Factors

� 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

Besides poor design (examples on the previous chart), there are a number

of factors that can eventually lead to a deadlock occurring.



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.

53



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 it’s 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 it’s 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



65

IBM Systems Lab Services and Trainingis composed of experts who develop and deploy solutions across IBM’s systems family offerings. From in-depth product expertise, to training, to platform-specific hardware and software solutions, we’re 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 [email protected] or visitibm.com/systems/services/labservices


System Storage Technical UniversitySystem Storage Technical UniversitySession Evaluations in 3 Easy Steps!

Go to: http://ibmtechu.com1

2 Select Register button and complete the form

(One time only)


System Storage Technical UniversitySystem Storage Technical UniversitySession 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

Documents

Transcript of sSE04 - Full Disk Encryption for IBM Disk