Front cover

IBM DS8000 Encryption

for Data at Rest, Transparent Cloud
Tiering, and Endpoint Security
(DS8000 Release 10.0)

Bert Dufrasne
Gregg Arquero
Rinkesh Bansal
Tony Eriksson
Michael Frankenberg
Peter Kimmel
Aditi Prasad
Andreas Reinhardt

Redpaper
IBM Redbooks

IBM DS8000 Encryption for Data at Rest, Transparent

Cloud Tiering, and Endpoint Security

November 2024

REDP-4500-11
 Note: Before using this information and the product it supports, read the information in “Notices” on
page vii.

Twelfth Edition (November 2024)

This edition applies to the IBM DS8000 Release 9.2.

This document was created or updated on November 1, 2024.

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

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Now you can become a published author, too! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Stay connected to IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii

Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

November 2024, Twelfth Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Chapter 1. Encryption overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Business context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Threats and security challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Data-at-rest encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.3 Transparent Cloud Tiering encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.4 IBM Fibre Channel Endpoint Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Encryption concepts and terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.1 Symmetric key encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.2 Asymmetric key encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.3 Hybrid encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.4 Communication protocols: IBM Proprietary Protocol, SSL/TLS 1.2, and Key
Management Interoperability Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3 Encryption challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Chapter 2. External key managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1 External key managers for IBM DS8000 systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 IBM Security Guardium Key Lifecycle Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.1 IBM Security Guardium Key Lifecycle Manager V4.1 . . . . . . . . . . . . . . . . . . . . . . 19
2.2.2 IBM Security Guardium Key Lifecycle Manager Traditional Edition . . . . . . . . . . . 20
2.2.3 IBM Security Guardium Key Lifecycle Manager Container Edition . . . . . . . . . . . . 20
2.2.4 Traditional and Container Edition comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.5 Key serving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.6 Protecting IBM Security Guardium Key Lifecycle Manager data . . . . . . . . . . . . . 22
2.3 IBM Security Key Lifecycle Manager for z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.1 IBM Security Key Lifecycle Manager for z/OS components . . . . . . . . . . . . . . . . . 23
2.3.2 Functions performed by IBM Security Key Lifecycle Manager for z/OS . . . . . . . . 24
2.3.3 Preventing a deadlock situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.4 Installing the IBM Security Key Lifecycle Manager for z/OS and keystores . . . . . 25
2.4 IBM Security Guardium Data Encryption V5.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5 Gemalto SafeNet KeySecure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.6 Thales Vormetric Data Security Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.7 Thales CipherTrust Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Chapter 3. IBM DS8000 encryption mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.1 DS8000 data-at-rest encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2 Key management for IBM Proprietary Protocol with IBM Security Guardium Key Lifecycle
Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

© Copyright IBM Corp. 2014, 2021. All rights reserved. iii

 3.3 Key management by using KMIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.4 Encryption deadlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.5 Working with a recovery key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.5.1 Recovery key management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.5.2 Disabling or enabling a recovery key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.6 Dual key server support (IBM Proprietary Protocol only) . . . . . . . . . . . . . . . . . . . . . . . 53
3.7 DS8000 TCT encryption key management using KMIP . . . . . . . . . . . . . . . . . . . . . . . . 56
3.8 DS8000 endpoint encryption key management using KMIP . . . . . . . . . . . . . . . . . . . . . 59
3.8.1 IBM Fibre Channel Endpoint Security settings and policies . . . . . . . . . . . . . . . . . 64

Chapter 4. Planning and guidelines for IBM DS8000 encryption . . . . . . . . . . . . . . . . . 65

4.1 About certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.2 Planning and implementation process flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.3 Encryption-capable DS8000 ordering and configuration. . . . . . . . . . . . . . . . . . . . . . . . 68
4.3.1 Local encryption ordering and configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.3.2 External encryption ordering and configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.4 Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.4.1 Local encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.4.2 External encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.5 Advice for external encryption in storage environments . . . . . . . . . . . . . . . . . . . . . . . . 71
4.5.1 Using LDAP authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.5.2 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.5.3 Encryption deadlock prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.6 Multiple key managers for redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Chapter 5. Implementing IBM DS8000 encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.1 Installing IBM Security Guardium Key Lifecycle Manager V4.x . . . . . . . . . . . . . . . . . . 76
5.2 Migrating IBM Security Guardium Key Lifecycle Manager . . . . . . . . . . . . . . . . . . . . . . 77
5.3 Setting up external key managers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.3.1 Configuring IBM Security Guardium Key Lifecycle Manager V4.x . . . . . . . . . . . . 77
5.3.2 Configuring Gemalto SafeNet KeySecure platform. . . . . . . . . . . . . . . . . . . . . . . 104
5.3.3 Configuring Thales Vormetric Data Security Manager . . . . . . . . . . . . . . . . . . . . 121
5.3.4 Importing the CA certificate chain into Vormetric DSM . . . . . . . . . . . . . . . . . . . . 128
5.3.5 Configuring Thales CipherTrust Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
5.4 Configuring data-at-rest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
5.4.1 Setting up IBM Security Guardium Key Lifecycle Manager Key management by using
IBM Proprietary Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
5.4.2 Setting up IBM Security Guardium Key Lifecycle Manager Key management by using
KMIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
5.4.3 DS8000 configuration for data-at-rest encryption in DS GUI . . . . . . . . . . . . . . . 150
5.4.4 DS8000 CLI configuration for data-at-rest encryption. . . . . . . . . . . . . . . . . . . . . 165
5.4.5 IBM Security Guardium Key Lifecycle Manager authentication mechanisms . . . 172
5.5 Configuration for TCT encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
5.5.1 Setting up TCT encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
5.6 IBM Fibre Channel Endpoint Security configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 184
5.6.1 DS8000 GUI configuration for IBM Fibre Channel Endpoint Security. . . . . . . . . 184
5.6.2 DS8000 CLI configuration for IBM Fibre Channel Endpoint Security . . . . . . . . . 188
5.7 Data-at-rest encryption and Copy Services functions . . . . . . . . . . . . . . . . . . . . . . . . . 190
5.8 NIST SP 800-131a requirements for key servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
5.9 Migrating certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
5.9.1 Migrating from a Gen 2 to a Gen 3 certificate for encryption . . . . . . . . . . . . . . . 191
5.10 Using a custom-generated Gen 2 or Gen 3 certificate . . . . . . . . . . . . . . . . . . . . . . . 200
5.10.1 Configuring a custom certificate by using the DS GUI . . . . . . . . . . . . . . . . . . . 200

iv IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 5.10.2 Configuring a custom certificate by using DS CLI. . . . . . . . . . . . . . . . . . . . . . . 202

Chapter 6. Maintaining the IBM DS8000 encryption environment . . . . . . . . . . . . . . . 203

6.1 Rekeying the data key for data-at-rest encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
6.1.1 Rekeying the data key when the IBM Proprietary Protocol is used . . . . . . . . . . 204
6.1.2 Rekeying the data key when the KMIP protocol is used . . . . . . . . . . . . . . . . . . . 209
6.2 Recovery key usage and maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
6.2.1 Validating or testing a recovery key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
6.2.2 Using the recovery key in an emergency-deadlock situation (recovery action) . 214
6.2.3 Rekeying the recovery key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
6.2.4 Deleting or deconfigure a recovery key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
6.3 Recovery key state summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

Chapter 7. Local key management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
7.1.1 Concept and design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
7.2 Implementing local encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
7.2.1 Preparing for local encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
7.2.2 Implementing local encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Contents v
vi IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
Notices

This information was developed for products and services offered in the US. This material might be available
from IBM in other languages. However, you may be required to own a copy of the product or product version in
that language in order to access it.

IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area. Any
reference to an IBM product, program, or service is not intended to state or imply that only that IBM product,
program, or service may be used. Any functionally equivalent product, program, or service that does not
infringe any IBM intellectual property right may be used instead. However, it is the user’s responsibility to
evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter described in this document. The
furnishing of this document does not grant you any license to these patents. You can send license inquiries, in
writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, MD-NC119, Armonk, NY 10504-1785, US

INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION “AS IS”

WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED
TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. Some jurisdictions do not allow disclaimer of express or implied warranties in
certain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may make
improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time
without notice.

Any references in this information to non-IBM websites are provided for convenience only and do not in any
manner serve as an endorsement of those websites. The materials at those websites are not part of the
materials for this IBM product and use of those websites is at your own risk.

IBM may use or distribute any of the information you provide in any way it believes appropriate without
incurring any obligation to you.

The performance data and client examples cited are presented for illustrative purposes only. Actual
performance results may vary depending on specific configurations and operating conditions.

Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm the
accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the
capabilities of non-IBM products should be addressed to the suppliers of those products.

Statements regarding IBM’s future direction or intent are subject to change or withdrawal without notice, and
represent goals and objectives only.

This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to actual people or business enterprises is entirely
coincidental.

COPYRIGHT LICENSE:

This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the sample
programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore,
cannot guarantee or imply reliability, serviceability, or function of these programs. The sample programs are
provided “AS IS”, without warranty of any kind. IBM shall not be liable for any damages arising out of your use
of the sample programs.

© Copyright IBM Corp. 2014, 2021. vii

Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines
Corporation, registered in many jurisdictions worldwide. Other product and service names might be
trademarks of IBM or other companies. A current list of IBM trademarks is available on the web at “Copyright
and trademark information” at http://www.ibm.com/legal/copytrade.shtml

The following terms are trademarks or registered trademarks of International Business Machines Corporation,
and might also be trademarks or registered trademarks in other countries.
AIX® IBM® Redbooks®
Db2® IBM Security™ Redbooks (logo) ®
DS8000® IBM Z® System z®
FICON® Passport Advantage® Tivoli®
FlashCopy® POWER® WebSphere®
Guardium® POWER9™ z/OS®
HyperSwap® RACF® z15™

The following terms are trademarks of other companies:

The registered trademark Linux® is used pursuant to a sublicense from the Linux Foundation, the exclusive
licensee of Linus Torvalds, owner of the mark on a worldwide basis.

LTO, Ultrium, the LTO Logo and the Ultrium logo are trademarks of HP, IBM Corp. and Quantum in the U.S.
and other countries.

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

Java, and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its
affiliates.

OpenShift, Red Hat, are trademarks or registered trademarks of Red Hat, Inc. 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.

Other company, product, or service names may be trademarks or service marks of others.

viii IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
Preface

The IBM® DS8000® supports encryption-capable drives. They are used with key
management services (local or external) to allow encryption for data-at-rest. The use of
encryption technology involves several considerations that are critical for you to understand to
maintain the security and accessibility of encrypted data.

This edition of this IBM Redpaper™ publication focuses on IBM Security™ Guardium Key
Lifecycle Manager with the DS8000 Release 10.0 code or later and updated DS GUI for
encryption functions.

The DS8000 Release 9.2 code introduced support for local key management for data-at-rest
encryption and is described in Chapter 7, “Local key management” on page 229.

Important: Failure to follow the requirements that are described in this publication can
result in an encryption deadlock.

The DS8000 system supports Transparent Cloud Tiering (TCT) data object encryption. With
TCT encryption, data is encrypted before it is transmitted to the cloud. The data remains
encrypted in cloud storage and is decrypted after it is transmitted back to the IBM DS8000.

The DS8000 system also supports Fibre Channel Endpoint Security when communicating
with IBM z15 and newer Z systems, which includes encryption of data that is in-flight, as well
as link authentication.

Authors
This paper was produced by a team of specialists from around the world.

Gregg Arquero is an Advisory Software Engineer at IBM. He

joined IBM in 2015 working with the z/OS® ICSF team. During
his time on the ICSF team, he designed and developed several
key crypto solutions on IBM Z®, such as early ICSF availability
at IPL, AES-DUKPT support, and Quantum-safe algorithm
support. He also is an avid innovator with over a dozen granted
patents by the USPTO. He received his bachelor’s degree in
Computer Science from Binghamton University.

© Copyright IBM Corp. 2014, 2021. ix

 Rinkesh Bansal is a Senior Development and Release
Manager for Encryption and Key Management products in IBM.
He is expert of Key Management domain and has more than 18
years of experience. He joined IBM in 2009, working with IBM
Security Guardium Key Lifecycle (GKLM) team since 2012. His
experience includes roles as an installation package developer,
test engineer, test lead, automation lead, Project Manager, and
Release Manager. Currently, he manages the GKLM
development team. He is a passionate innovator with 10
patents and an enthusiastic speaker at various conferences,
colleges, and schools.

Bert Dufrasne is an IBM Certified Consulting IT Specialist and

Project Leader for IBM System Storage disk and flash products
at the ITSO, San Jose Center. He has worked at IBM in various
IT areas. Bert has written many IBM Redbooks® publications
and developed and taught technical workshops. Before joining
the ITSO, he worked for IBM Global Services as an Application
Architect in the retail, banking, telecommunication, and
healthcare industries. He holds a master’s degree in Electrical
Engineering.

Tony Eriksson works at IBM Systems Lab Services Nordic,

based in Stockholm, Sweden. He joined IBM in 1988 as a
mainframe Customer Engineer. From 1999, he has worked as
a product specialist on enterprise storage solutions, including
IBM DS8000®, IBM SAN Volume Controller, and SAN
products. In 2014, he joined an IBM Business Partner as a
pre-sales and implementation consultant, mainly migrating to
IBM storage products. In 2019, he joined IBM Systems Lab
Services Nordic working close with the Swedish technical sales
team for storage solutions. He holds a Technical College
Graduation in Electrical Engineering.

Michael Frankenberg is a Certified IT Specialist in Germany

and joined IBM in 1995. With more than twenty-five years of
experience in high-end storage he works in Technical Sales
Support for EMEA. His area of expertise includes performance
analysis, establishing high availability and disaster recovery
solutions and implementation of storage systems. He supports
the introduction of new products and provides advice for
business partners, Technical Sales and customers. He holds a
degree in Electrical Engineering / Information Technology from
University of Applied Sciences Bochum, Germany

x IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 Peter Kimmel is a Senior Platform Engineer for Enterprise
Storage in the IBM EMEA Client Engineering team Frankfurt,
Germany. He joined IBM Storage in 1999, and since then has
worked with all DS8000 generations, with a focus on
architecture and performance. Peter has co-authored several
DS8000 IBM publications. He holds a Diploma (MSc) degree in
physics from the University of Kaiserslautern.

Aditi Prasad is an Advisory Software Engineer at IBM. She

joined IBM in 2008 and is working with the IBM Security
Guardium® Key Lifecycle (GKLM) team since 2012. She is the
Level 3 support lead for GKLM. She has approximately 13
years of experience with more than 7 years in Security Domain.
She holds a Masters degree in Computer Science from Pune
University, India.

Andreas Reinhardt is an IBM® Certified Specialist for

high-end disk systems in Frankfurt, Germany and has worked
in various IT areas at IBM for more than 20 years. Andreas
works for IBM Systems and started as an IBM System Service
Representative. He was a member of the DS8000 SME team.
Later he moved to the FlashSystem SME team. Andreas now
works for the Spectrum Fusion support and still supports the
IBM EMEA Lab Services department with encryption
implementation services.

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

Jacob Sheppard, DS8000 Development Senior Engineer

Samantha Utter, DS8000 Development
Mike Stenson, Team lead for the DS8000 development field screen team

IBM US

Now 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 IBM Redbooks 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.

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

Preface xi
Comments welcome
Your comments are important to us!

We want our papers to be as helpful as possible. Send us your comments about this paper 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:
[email protected]
򐂰 Mail your comments to:
IBM Corporation, IBM Redbooks
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400

Stay connected to IBM Redbooks

򐂰 Find 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

xii IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
Summary of changes

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

Summary of Changes
for IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint
Security

November 2024, Twelfth Edition

This revision includes the following new and changed information.

Changed information
򐂰 Chapter 5 “Implementing IBM DS8000 encryption” has been updated for DS8000 Release
10.0
򐂰 Chapter 7 “Local key management” has been updated for DS8000 Release 10.0

© Copyright IBM Corp. 2014, 2021. All rights reserved. xiii

xiv IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 1

Chapter 1. Encryption overview

The IBM DS8000 supports hardware-level, self-encrypting drives. Combined with key
management software (external or local), the DS8000 can securely encrypt data-at-rest
(DAR), while also offering a simple, cost-effective solution for securely erasing any disk or
flash drive that is being retired or repurposed (cryptographic erasure).

Starting with DS8000 Release 8.5, the Transparent Cloud Tiering (TCT) feature allows
encryption before data is transmitted to the cloud.

Starting with Release 9.1, the DS8000 supports encryption for host data communication with
IBM Z (IBM Fibre Channel Endpoint Security). For more information about this feature, see
IBM DS8900F Architecture and Implementation Release 9.1, SG24-8456.

Starting with Release 9.2, the DS8000 supports two options for data-at-rest encryption:
򐂰 With external key servers (external encryption)
򐂰 Without external key servers (local encryption)

Important: Data-at-rest encryption without external key servers does not require a specific
license, but the option to use this feature must be selected during the initial order process
of the DS8000. It cannot be activated by way of a license function later. An upgrade to
Release 9.2 from a previous version does not enable the availability of local encryption for
the DS8000.

Both methods use the same encryption algorithms. They also provide the same level of data
security. However, encryption without external key servers offers a somewhat lower level of
security for the system than encryption with external key servers does.

Data-at-rest encryption without external key servers (local encryption) is a chargeable

feature. With the D8000 R9.2, you can order feature code 0405 (Local Key Manager for
encryption for data-at-rest) for a fee.

Encryption must not be deployed without careful planning and a thorough understanding of
encryption techniques and encryption management products.

© Copyright IBM Corp. 2014, 2021. All rights reserved. 1

 Important: Improper handling or implementation of encryption with key servers for
data-at-rest and for IBM Fibre Channel Endpoint Security with IBM Z can result in a
permanent encryption deadlock, which is mostly equivalent to the permanent loss of all
encrypted data that a key server manages, as described in 3.4, “Encryption deadlock” on
page 47.

To gain access to data, even in a deadlock situation, the DS8000 offers a recovery key
(RK) implementation for data-at-rest encryption. The RK can be set only as the first activity
when a DS8000 is set up. The RK can be configured as disabled in those environments
where you do not want to maintain an RK. With Local Key Encryption, the Recovery Key is
and must remain disabled.

This chapter includes the following topics:

򐂰 1.1, “Business context” on page 3
򐂰 1.2, “Encryption concepts and terminology” on page 9
򐂰 1.3, “Encryption challenges” on page 15

2 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
1.1 Business context
Businesses need tools to protect against the known threats, but also 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.

1.1.1 Threats and security challenges

Figure 1-1 shows how threats and challenges add to the complexity and the cost of running
your business.

EVOLVING
THREATS

EVOLVING EVOLVING
COMPLIANCE TECHNOLOGIES
BUSINESS
COMPLEXITY=
RISING COSTS

EVOLVING EVOLVING
ECONOMICS BUSINESS
NEEDS

Figure 1-1 Business complexity

Companies face the following threats and security challenges:

򐂰 Increasing number and sophistication of threats. Businesses face more than just viruses
and worms. You must be able to defend against all threats rather than respond only
to intrusions.
򐂰 Prevention of data breaches and inappropriate data disclosure, and ensuring no impact on
business and productivity.
򐂰 Intrusions that affect the bottom line in both client 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 meet a growing
number of compliance initiatives without diverting resources from core activities.
򐂰 Protecting your data and maintaining appropriate levels of access.
򐂰 Security issues are both internal and external. How do you protect against the
well-intentioned employee who mishandles information, and the malicious outsider?
򐂰 Having your business comply with a growing number of corporate standards and
government regulations. You must have tools that can document the status of your
application security.
򐂰 Growing number of regulatory mandates. You must prove that your physical assets
are secure.

Chapter 1. Encryption overview 3

1.1.2 Data-at-rest encryption
In particular, organizations experience a continued push to minimize the risks of data
breaches. There is a new focus on privacy management tools with the capability to mask
data. This focus reinforces the need for cryptography, and subsequent demand to simplify the
complexity of the key-based algorithms and management of keys throughout the lifecycle.

A significant concern is when disk drives leave the company premises, which usually
happens when a disk drive fails and the IBM technician replaces it with a new drive. Often, the
drive is not damaged and data can still be accessed. IBM has a procedure to delete all data
on the drive. However, this task is no longer under the control of the client. Some clients buy
back the drives and destroy them themselves. This procedure can be expensive. Another
concern is when the whole DS8000 is returned to IBM. The IBM technician erases all data,
but this step is not sufficient for some clients. IBM offers a service (IBM Certified Secure Data
Overwrite) to erase all data (several passes) in compliance with the American Department of
Defense regulations (DoD 5220.20-M).

All of these concerns become obsolete when data on the drives is encrypted. Without a
decryption key, the data is unreadable.

What should you encrypt and what should you not encrypt? Simply encrypt everything that
you can encrypt and still be able to recover data if there is a disaster. If system data can be
separated from application data, encrypting everything with no performance impact is easier
than choosing which data falls into which legislation for encryption, and trying to keep current
on the dynamic privacy rights rules and regulations.

Before using any encryption technology, understanding the encryption concepts and the
requirements to maintain the security and the accessibility of the encrypted data is essential.

You do not want the encryption solution to affect negatively your storage environment and the
applications that depend on it. You want an encryption solution that does not degrade
application performance or jeopardize your disaster recovery plan. You also need the
assurance that encryption does not cause any data loss and that all the appropriate
measures are taken to protect and safeguard the encryption keys.

To address these concerns, the DS8000 encryption approach uses drives that include
encryption hardware and can perform symmetric encryption and decryption of data with no
impact on performance. The drive-based encryption can be combined with or without an
enterprise-scale key management infrastructure. That infrastructure is based on IBM Security
Guardium Key Lifecycle Manager or other supported external key managers, which all
provide similar capabilities. For more information about encryption with external key servers,
see Chapter 2, “External key managers” on page 17.

These security lifecycle management software products help organizations efficiently deploy,
back up, restore, and delete keys and certificates securely and consistently. Starting with
Release 9.2, the DS8000 also supports encryption for data-at-rest without the need of an
external key management infrastructure. For more information about encryption without
external key servers, see Chapter 7, “Local key management” on page 229.

4 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 Important:
򐂰 The DS8000 provides encryption for data that is at rest on drives. It also allows
encryption of data that is transmitted to the cloud when the TCT function is used, and
encryption when connecting to an IBM Z z15 host. If encryption over the network is
required, more encryption services must be investigated and deployed for other hosts
connectivity or Copy Services traffic.
򐂰 Data encryption is protected by the Advanced Encryption Standard (AES) algorithm
that uses a 256-bit symmetric encryption key in XTS mode, as defined in the IEEE
1619-2007 standard and NIST Special Publication 800-38E as XTS-AES-256.

For a successful deployment, following the instructions and guidelines that are outlined in this
publication also is imperative. For more information, see IBM Security.

1.1.3 Transparent Cloud Tiering encryption

TCT for IBM DS8000 was introduced to help customers use IBM Z resources more efficiently.
Integration with IBM z/OS through DFSMShsm allows clients to reduce CPU usage by
eliminating constraints that are tied to original data migration methodologies.

TCT enables direct data movement from IBM DS8000 to cloud object storage, without the
need for data to go through the host. DFSMS communicates with DS8000 through a REST
API interface. It issues commands for the DS8000 to move the data directly to and from a
public, private, or hybrid cloud.

For more information about TCT, see IBM DS8000 and Transparent Cloud Tiering,
SG24-8381.

Having a storage cloud that uses object storage has several benefits. A storage cloud
significantly reduces the complexity of storage systems by simplifying data scaling within a
single namespace. The use of high-density, low-cost commodity hardware turns storage
clouds into a scalable, cost-efficient storage option.

When data is off-loaded to a storage cloud in its original, unencrypted condition, unauthorized
access is not prevented.

TCT encryption now changes this situation and ensures that critical mainframe data is
encrypted while it is transferred over the network. It uses the DS8000 internal IBM POWER®
servers hardware acceleration with 256-bit Advanced Encryption Standard (AES) encryption
at full speed, and I/O performance is not affected. The data remains encrypted in the cloud
storage and is decrypted when it is transferred back to the DS8000.

If the data set is already encrypted by data set-level encryption, DFSMS informs the DS8000,
and TCT encryption avoids double encrypting the data.

You can use TCT encryption to offload and decrypt data with any DS8000 storage system.
You also can use the same key servers as the system that first encrypted the data. The data
remains encrypted, even when it lands on the object storage. Without a decryption key, the
data object is unreadable.

In IBM HyperSwap® High Availability and Disaster Recovery scenarios with Metro Mirror and
Global Mirror, all DS8000s must be connected to the same cloud and all must be configured
for TCT encryption. The certificates of every DS8000 must be added to the encryption group
in IBM Security Guardium Key Lifecycle Manager during setup. This setup is required so that
any DS8000 in the encryption group can decrypt data that is migrated from any other

Chapter 1. Encryption overview 5

 DS8000. Local encryption cannot be used for TCT encryption because the decryption key
remains with the DS8000 and is not available to any other external system.

TCT encryption does not require a specific license. It can be used along with or independently
from DAR encryption.

Starting with DS8000 R9.2 TCT provides multi-cloud support. Defining multiple cloud network
connections allows you to create multiple policies that direct some types of data to a TS7700
object store and other types of data to private or public clouds, along with encryption
capability.

6 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
1.1.4 IBM Fibre Channel Endpoint Security
IBM Fibre Channel Endpoint Security is designed to protect data that is transferred over Fibre
Channel (FC) storage area networks (SANs) to IBM Z. It consists of the following
components:
򐂰 Link authentication
򐂰 Encryption of data in flight (EDIF)

Today, data that is stored and processed in IT systems is one of the core assets of most
enterprises or organizations. Losing or exposing data often results in high costs or even
irreparable damage. In addition, more regulatory requirements are introduced, which forces
organizations to protect the data they store and process and induces severe penalties if
requirements are not met or sensitive data is lost or exposed. Thus, organizations are
experiencing increased pressure from internal and external sources to protect and
govern data.

Data protection features the following main aspects:

򐂰 Protection against loss
Although losing access to data can severely affect an organization’s ability to function,
such a loss generally has a limited effect on third parties. In the past, most of the efforts of
data protection focused on this aspect. Hardware redundancy, back up and restore
processes, or disaster recovery solutions are examples of methods that are used here.
򐂰 Protection against unauthorized access and abuse
Losing control of data affects the storing and processing capabilities of an organization
and other organizations or persons with which it is interacting. This aspect is gaining
significance in recent years because data breaches and abuse are reported frequently.
Here, the most effective methods of protection are access control and encryption.

Starting with the IBM Z z14, IBM introduced the concept of Pervasive Encryption. IBM Z
clients should no longer be required to put excessive effort into planning, implementing, and
maintaining effective access control and encryption of their data. Pervasive encryption
provides the means to encrypt all data at all levels and in all components of the IT
infrastructure, without affecting the operation or requiring changes to applications.

Figure 1-2 shows a graphical representation of the layers where encryption can occur.

Figure 1-2 IBM Pervasive Encryption pyramid

Chapter 1. Encryption overview 7

 The width of each layer represents the coverage that can be achieved that is related to overall
protection. The vertical positions of the layers represent the granularity of control, but also the
complexity of implementation and management. Starting with the top layer, we briefly explain
each layer:
򐂰 Application encryption provides encryption and data protection by each individual
application. It is highly granular and specific, but also requires the highest efforts because
each application needs the necessary encryption capabilities and must be managed
individually. It can provide protection of highly sensitive application data, which is not
covered by any of the lower levels or if their protection is not sufficient.
򐂰 Database encryption provides the capability to protect key database files and database
backup images from inappropriate access. Therefore, it is less granular and easier to
manage, but covers only a certain subset of data.
򐂰 File or data set encryption provides broad coverage for sensitive data by using encryption
that is tightly integrated with the operating system and managed by policies. It is not
apparent to applications and allows for separation of duties within an organization.
Security administration can be performed independently of application, database, or
storage administration.
򐂰 Disk and tape encryption provide coverage for data-at-rest at the storage infrastructure
level. It is an “all or nothing” solution and encrypts DAR within a storage controller without
differentiating type, sensitivity, or importance of data. Therefore, it requires the least
organizational effort of all layers with the broadest coverage. It protects against intrusion,
tampering, or removal of physical infrastructure.

For more information about Pervasive Encryption, see Getting Started with z/OS Data Set
Encryption, SG24-8410, and Getting Started with z/OS Data Set Encryption, SG24-8410.

For the upper three levels that are shown in the pyramid in Figure 1-2 on page 7, data is
encrypted on the host side. Therefore, it is protected at-rest on external storage media and
in-flight while being read or written. With conventional disk encryption, data is unprotected if it
is outside of the respective storage system.

IBM Fibre Channel Endpoint Security adds the protection of data in-flight between the IBM Z
and the IBM DS8000 storage system. It controls access and encrypts data that is transferred
over a SAN.

The IBM Z and the DS8000 must be connected to the same set of IBM Security Guardium
Key Lifecycle Managers. Local encryption cannot be used for IBM Fibre Channel Endpoint
Security because the decryption key remains with the DS8000 and is not available to any
other external system.

IBM Fibre Channel Endpoint Security does not require a specific license. It can be used along
with or independently from DAR encryption.

Note: Only data that is transferred between an IBM Z (z15) and IBM DS8900F storage
systems can be protected with IBM Fibre Channel Endpoint Security.

At the time of this writing, data that is in-flight is not protected in following instances:
򐂰 On PPRC replication links between DS8000 storage systems
򐂰 Between an IBM Z system and virtual or physical tape devices

For more information about the IBM Fibre Channel Endpoint Security feature, see IBM Fibre
Channel Endpoint Security for IBM DS8900F and IBM Z, SG24-8455.

8 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
1.2 Encryption concepts and terminology
Encryption transforms data that is unprotected, or plain text, into encrypted data, or
ciphertext, by using a key. Without knowledge of the encryption key, the ciphertext cannot be
converted back to plain text.

Computer technology enabled increasingly sophisticated encryption algorithms. Working with

the US Government National Institute of Standards and Technology (NIST), IBM invented one
of the first computer-based algorithms, Data Encryption Standard (DES), in 1974. Today,
several widely used encryption algorithms exist, including 3Key-3DES and the more secure
AES for symmetric encryption, Rivest-Shamir-Adleman (RSA), which is commonly used for
public keys, and Secure Hash Algorithm (SHA) for key derivation functions. There are many
more encryption algorithms that are not mentioned here.

1.2.1 Symmetric key encryption

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

Everyone who obtains 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.

Figure 1-3 shows a sample encryption and decryption data flow path. In the figure, the
AES_256_ITSO symmetric key is used to encrypt plain text by 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.

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

Encryption Process

Algorithm
Plain Text Encrypted Data
AES

Symmetric Key
AES_256_ITSO

Decryption Process

Algorithm
Plain Text Encrypted Data
AES

Symmetric Key
AES_256_ITSO

Figure 1-3 Symmetric key encryption

Chapter 1. Encryption overview 9

1.2.2 Asymmetric key encryption
In the 1970s, cryptographers invented asymmetric key algorithms for encryption and
decryption. Encryption methods that use 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.

Asymmetric key encryption uses one key for encrypting (public key) and one key (private key)
for decrypting data. Because the key that is used for encrypting a message cannot be used
for decrypting, this key does not have to be kept a secret. It can be widely shared and is 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 must
always be kept a secret. Because asymmetric encryption uses public/private key pairs, it is
also called public/private key encryption or public key encryption.

Public/private key encryption is widely used on the internet today to secure transactions,
including Secure Sockets Layer (SSL) and Transport Layer Security (TLS).

To encrypt data requires an algorithm. Today, the RSA algorithm1 is the most widely used
public key technique.

The advantage of asymmetric key encryption is the ability to share secret data without
sharing the encryption key. But disadvantages exist too. Asymmetric key encryption is
computationally more intensive and slower than symmetric key encryption. In practice, you
often use a combination of symmetric and asymmetric encryption. This method is described
in 1.2.3, “Hybrid encryption” on page 12. With the DS8000, the IBM solution uses a
combination of symmetric and asymmetric encryption methods. This combination (hybrid
encryption) is prevalent in many security solutions.

Important: The data-at-rest and the TCT encryption solution use only the asymmetric
RSA algorithm to encrypt symmetric AES keys that are used for data encryption.

Figure 1-4 shows an encryption and decryption data path when using public key encryption.

Public/Private Key Encryption

Algorithm Encrypted
Plain Text
RSA Data

Asymetric Public Key

Decryption Process

Algorithm Encrypted
Plain Text
RSA
AES Data

Asymetric Private Key

Figure 1-4 Public/private key encryption

1 Ronald L. Rivest, Adi Shamir, and Leonard Adleman developed this algorithm in 1977.

10 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
Digital signature
You can use public/private key pairs to protect the content of a message and to digitally sign a
message. When a digitally signed message is sent, the receiver can be sure that the sender
sent it because the receiver can provide proof by using the public key from the sender. In
practice, predominantly for efficiency reasons, a hash value of the message is signed rather
than the whole message, but the overall procedure is the same.

Note: This section applies to encryption with key servers in place only. It does not apply
when encryption without key servers (local key encryption) is in use because no external
key exchange occurs.

Figure 1-5 shows how the digital signature is used in the communication between the
DS8000 and a key server, such as IBM Security Guardium Key Lifecycle Manager or other
external key managers, by using an asymmetric key pair. It illustrates a mechanism that is
used as part of the DS8000 encryption process. The DS8000 has a private key, and the key
server has a copy of the DS8000 public key.

The DS8000 sends the key server a message that is encrypted with the DS8000 disk storage
system’s private key. The key server then uses the DS8000 public key to validate the
message that is sent from the DS8000. The key server cannot use the public key to decrypt
the encrypted data, but it can, with the DS8000 public key, validate that the message was
encrypted with the DS8000 private key. This approach proves to the key server that it is
communicating with the DS8000 because only the DS8000 has a copy of its private key.
Then, the key server uses the DS8000 public key to encrypt the communication that it wants
to protect and sends the data to the DS8000. The DS8000 can use its private key to decrypt
the data.

Note: IBM Security Key Lifecycle Manager V4.0 and later or other external key managers
are a requirement to comply with the NIST Special Publication (SP) 800-131a. For more
information, see Chapter 2, “External key managers” on page 17.

DS8000 Network Key Server

Private Key Public Key

Privat Key
Encrypted
Message
Message Message

Public Key
Data Encrypted Data
Message

Figure 1-5 Identity verification by using public/private key encryption

Chapter 1. Encryption overview 11

 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; then, they also
can verify that a specific public key does belong to whomever (a person or an entity) is
identified in the certificate.

Note: This section applies to encryption with key servers in place only. It does not apply
when encryption without key servers (local key encryption) is in use, because no external
key exchange occurs.

Part of the information that is stored in a digital certificate includes the following items:
򐂰 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

Note: For the DS8000, digital certificates are created and set by manufacturing for each
Storage Facility. IBM initially introduced disk encryption on the DS8000 with 80-bit security
strength; IBM calls it the Gen 1 certificate.

DS8000 Release 7.2 and later offers 112-bit security strength. IBM calls it the Gen 2
certificate. Any DS8000 that is delivered by manufacturing with Release 8.1 or later does
not support Gen 1 80-bit security strength certificates.

DS8900F Release 9.0 and later now offers 128 to 192-bit security strength, which is the
Gen 3 certificate. The DS8900F includes an active Gen 2 certificate and a Gen 3 certificate
that is dormant. The Gen 1 certificate no longer exists.

Asymmetric and symmetric key encryption schemes are powerful ways to protect and secure
data. For more information about their use with the IBM DS8000 series, see 3.2, “Key
management for IBM Proprietary Protocol with IBM Security Guardium Key Lifecycle
Manager” on page 34 or see 3.8, “DS8000 endpoint encryption key management using
KMIP” on page 59.

1.2.3 Hybrid encryption

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

Hybrid methods use a symmetric data key (DK) to encrypt and decrypt data. They do not
transfer this symmetric DK in the clear, but use public/private key encryption to encrypt the
DK. The recipient can decrypt the encrypted DK and use the DK to encrypt or decrypt
a message.

With hybrid encryption methods, you can combine secure and convenient key exchange with
fast and efficient encryption of large amounts of data.

12 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 The data-at-rest and the TCT encryption solution uses a symmetric AES DK to encrypt and
decrypt data. This DK is protected by the asymmetric RSA algorithm and is not available in
plain text when the storage device communicates with the IBM Security Guardium Key
Lifecycle Manager or any other third-party key server, such as Gemalto SafeNet KeySecure
(KS). For more information, see Chapter 3, “IBM DS8000 encryption mechanisms” on
page 31.

1.2.4 Communication protocols: IBM Proprietary Protocol, SSL/TLS 1.2, and

Key Management Interoperability Protocol
This section covers the different protocols that are supported by DS8000 encryption with key
servers.

IBM Proprietary Protocol

The DS8000 can support IBM Proprietary Protocol (IPP) while it communicates with the IBM
Security Guardium Key Lifecycle Manager. It was first developed for tape drives and then, the
DS8000 incorporated the IBM Proprietary Protocol into its earliest encryption version and
continues to support it. The IBM Proprietary Protocol is wrapped with TLS when it
communicates with the IBM Security Key Lifecycle Manager. IPP is available for data-at-rest
encryption only.

Important: TCT encryption and IBM Fibre Channel Endpoint Security do not support the
IBM Proprietary Protocol.

Secure Sockets Layer/Transport Layer Security 1.2

For the US federal government, a minimum security strength of 80 bits was the
recommendation until 2010. This requirement was achieved by the IBM Proprietary Protocol.

At the beginning of 2011, the minimum key strength number increased from 80 bits to 112
bits. However, with the acceptance of a specific amount of risk, the minimum of 80 bits of
security strength could be used until the end of 2013.

NIST SP 800-131a requires longer key lengths and stronger cryptography than other
standards. The standard requires cryptographic algorithms that feature key strengths of at
least 112 bits. IBM Proprietary Protocol is wrapped into SSL secured by TLS when
communicating with the IBM Security Guardium Key Lifecycle Manager and enabling NIST
mode.

Strict enforcement of NIST SP 800-131a imposes the usage of the TLS 1.2 protocol for the
SSL context.

Note: TLS 1.3 protocol will be officially supported starting with version 9.4. It is not
supported in earlier versions.

Key Management Interoperability Protocol

Key Management Interoperability Protocol (KMIP) is an industry standard that aims to be a
common language for key management systems and encryption systems of all varieties.
Many commercial key server vendors support KMIP. Many systems, ranging from email
databases to storage devices that offer encryption, also support KMIP as their
communication protocol.

By supporting KMIP, the DS8000 starting with Release 8.5 provides customers with more
flexibility and choice in key management. DS8000 customers now can take advantage of

Chapter 1. Encryption overview 13

 encryption if KMIP is a requirement in their infrastructure. KMIP is supported by IBM Security
Guardium Key Lifecycle Manager and other external key managers, as described in
Chapter 2, “External key managers” on page 17.

14 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
1.3 Encryption challenges
Encryption depends on encryption keys. Those keys must be kept secure and available. The
following responsibilities must be split:
򐂰 Keys security
To preserve the security of encryption keys, the implementation must be set up so that no
single individual (person or system) can access all the information that is required to
determine the encryption key. In a system-based solution, the encryption Data Keys (DKs)
are encrypted with a wrapping key (another key to encrypt/decrypt the DKs). This wrapped
key method is used with the DS8000 by separating the storage of a wrapped DK. The
wrapped DK is stored in the DS8000 while the wrap/unwrap keys are stored within a key
server.
With local encryption, the DK is obfuscated and stored on DS8000 internal servers rather
than being stored on an external key server when data-at-rest encryption is used. The
data is safe from any drive theft but might be exposed in the unlikely event of an entire box
theft.
򐂰 Key availability
More than one individual (person or system) can access any single piece of information
that is necessary to determine the encryption key. In a system-based solution, redundancy
is provided by having multiple isolated key servers. In addition, backups of the key server’s
data are maintained.
The DS8000 ensures the key availability for data-at-rest encryption without key servers
(local encryption).
򐂰 Separation of responsibilities
The DS8000 offers a data-at-rest encryption recovery key (RK) to provide access to data if
none of the key servers are available. To prevent one person from gaining access to the
data, the handling of an RK requires two people with separate roles: the Security
Administrator and the Storage Administrator. It also is possible to disable the RK, but it is
done at the client’s own risk.
Setting up a RK is not available for data-at-rest encryption without key servers.
The sensitivity of possessing and maintaining encryption keys and 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 that are associated with key management
for encrypted storage.

Lifecycle management tools: IBM offers an enterprise-scale key management

infrastructure through the IBM Security Guardium Key Lifecycle Manager and lifecycle
management tools to help organizations efficiently deploy, back up, restore, and delete
keys and certificates in a secure and consistent fashion.

However, the client must still be sufficiently aware of how these products interact to provide
the suitable management of the IT environment. Generally speaking, even when you use a
key server, at least one encryption key or the RK must be maintained manually. The
encryption key might be an overall key that manages access to all other encryption keys or a
key that encrypts the data that is used by the key server. However, this requirement of
manually maintaining a key does not apply when encryption is used without an external key
server.

Chapter 1. Encryption overview 15

 One critical consideration with a key server implementation is that all code and data objects,
which are required to make the key server operational, must not be kept on storage that
depends on any key server being 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 can be unlocked with a combination, but
the only copy of the combination is locked inside the vault.

This situation, and the policies and mechanisms that are required to avoid it, are described in
Chapter 3, “IBM DS8000 encryption mechanisms” on page 31.

16 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 2

Chapter 2. External key managers

In an enterprise, many symmetric keys, asymmetric keys, and certificates can exist. All these
keys and certificates must be managed. Key management can be handled by an external
key manager.

This chapter includes the following topics:

򐂰 2.1, “External key managers for IBM DS8000 systems” on page 18
򐂰 2.2, “IBM Security Guardium Key Lifecycle Manager” on page 18
򐂰 2.3, “IBM Security Key Lifecycle Manager for z/OS” on page 23
򐂰 2.4, “IBM Security Guardium Data Encryption V5.0” on page 28
򐂰 2.5, “Gemalto SafeNet KeySecure” on page 29
򐂰 2.6, “Thales Vormetric Data Security Manager” on page 29
򐂰 2.7, “Thales CipherTrust Manager” on page 29

© Copyright IBM Corp. 2014, 2021. All rights reserved. 17

2.1 External key managers for IBM DS8000 systems
External key managers provide a centralized encryption and key management solution to
minimize the risk of exposure and simplify keys management operations.

Important: For IBM Fibre Channel Endpoint Security, IBM Security Guardium Key
Lifecycle Manager V4.1.0.1 is recommended.

The DS8000 ranks must all be either encrypted or non-encrypted for data-at-rest (DAR)
encryption. An environment verification process or solution assurance must be completed to
ensure that best practices regarding the configuration of the encryption solution are taken.
This verification can be requested from IBM Lab Services or completed by the client’s staff,
but it is a prerequisite to activate the encryption solution.

Table 2-1 show a comparison of various external key managers and their support for DS8000
features.

Table 2-1 External key manager comparison

Key managers Data-at-rest Data-at-rest Transparent IBM Fibre
over IBM over Key Cloud Channel
Proprietary Management Tiering Endpoint
Protocol Interoperability Security
Protocol

IBM Security Guardium Key Lifecycle Manager x x x x

Traditional Edition

IBM Security Guardium Key Lifecycle Manager x

Container Edition

IBM Security Key Lifecycle Manager for z/OS x

IBM Security Guardium Data Encryption x x

Safenet Gemalto KS x x

Thales CipherTrust Manager x x

Thales Vormetric DSM x x

2.2 IBM Security Guardium Key Lifecycle Manager

The IBM Security Guardium Key Lifecycle Manager provides key storage, key serving, and
key lifecycle management for storage devices from IBM and other vendors. For more
information about supported products, see this web page.

The focus of this publication is IBM key server interoperability with the DS8000. The DS8000
supports data-at-rest encryption with the Full Disk Encryption (FDE) feature. With Version
8.5, it supports Transparent Cloud Tiering (TCT) encryption. IBM Fibre Channel Endpoint
Security is supported by Version 9.0 and later.

The FDE drives can encrypt and decrypt at interface speeds, so there is no impact on
performance. TCT encryption uses IBM POWER9™ hardware acceleration with 256-bit
Advanced Encryption Standard (AES) encryption at full speed with no impact on performance
for encrypting the data before it is transferred over the network.

18 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 All drives in the DS8000 are encryption-capable by default. To use the encryption feature, the
DS8000 must be configured to communicate with the IBM Security Guardium Key Lifecycle
Managers.

The DS8000 only can be completely encrypted (partial data-at-rest encryption is not
possible). An environment verification process or solution assurance must be completed to
ensure that best practices regarding the configuration of the encryption solution are taken.
This verification can be requested from IBM Lab Services or completed by the client’s staff,
but is a prerequisite for activating the encryption solution.

2.2.1 IBM Security Guardium Key Lifecycle Manager V4.1

IBM Security Guardium Key Lifecycle Manager v4.1.0.1 includes the following key features:
򐂰 IBM Security Key Lifecycle Manager was rebranded as IBM Security Guardium Key
Lifecycle Manager.
򐂰 IBM Security Guardium Key Lifecycle Manager V4.1 is available in the following editions:
– Traditional Edition
– Container Edition
򐂰 IBM Security Guardium Key Lifecycle Manager is now available in Container edition that
supports the following container platforms:
– Red Hat OpenShift
– Kubernetes
– IBM z/OS Container Extensions (zCX)
򐂰 Capability to create group of clients and use the new workflow to manage clients to enable
seamless sharing and serving of cryptographic objects among them.
򐂰 Support for Log Event Extended Format (LEEF) format for audit logs.
򐂰 Support for IBM Java JCEPlus and JCEPlusFIPS provider for cryptographic operations.
򐂰 Important features in IBM Security Guardium Key Lifecycle Manager Container Edition:
– User Management through IBM Security Guardium Key Lifecycle Manager Graphical
User Interface
– LDAP configuration through IBM Security Guardium Key Lifecycle Manager Graphical
User Interface
– Support for PostgreSQL database for storing cryptographic keys and metadata
򐂰 Important features in IBM Security Guardium Key Lifecycle Manager Traditional Edition:
– New prerequisite utility for accurate prerequisite checking before installation
– Installation of IBM Security Guardium Key Lifecycle Manager as a domain (Microsoft
Active Directory) user on a domain-managed Windows system
– Multi-Master Agent status on IBM Security Guardium Key Lifecycle Manager Graphic
User Interface for easy monitoring
– New utility to convert master in Multi-Master cluster to Standalone
– Password-less authentication with the database (IBM Db2®) by using Kerberos

Note: A Multi-Master configuration is mandatory if you use IBM Security Guardium Key
Lifecycle Managers for TCT encryption or IBM Fibre Channel Endpoint Security. You
also can use Multi-Master for DAR encryption.

Chapter 2. External key managers 19

 For more information about the features of the IBM Security Key Lifecycle Manager and its
predecessors, see this web page.

Note: You must use the predefined device group DS8000 for DAR encryption and
DS8000_TCT for TCT encryption. New device group of type Peer_to_Peer is created
automatically for IBM Fibre Channel Endpoint Security.

2.2.2 IBM Security Guardium Key Lifecycle Manager Traditional Edition

IBM Security Guardium Key Lifecycle Manager V4.0 or above is now called IBM Security
Guardium Key Lifecycle Manager Traditional Edition. IBM Security Guardium Key Lifecycle
Manager V4.1 continues to bundle IBM WebSphere® Application Server, IBM Db2 database,
and IBM Java.

2.2.3 IBM Security Guardium Key Lifecycle Manager Container Edition

Beginning with V4.1, IBM Security Guardium Key Lifecycle Manager is available as a
Container Edition that is supported on various platforms, such as the following examples:
򐂰 IBM Red Hat OpenShift
When running on IBM Red Hat OpenShift, IBM Security Guardium Key Lifecycle Manager
provides easy to use deployment scripts that are called Helm charts.
On IBM Red Hat OpenShift, the option to select between databases, such as IBM Db2 or
PostgreSQL for internal data storage.
򐂰 Kubernetes
When running on IBM Red Hat OpenShift, IBM Security Guardium Key Lifecycle Manager
provides easy to use deployment scripts called Helm charts.
On Kubernetes, you use PostgreSQL database for internal data storage.
򐂰 IBM z/OS Container Extensions (zCX)
IBM z/OS Container Extensions (zCX), introduced on z/OS 2.4, enables clients to deploy
Linux applications as Docker containers on z/OS as part of a z/OS workload. With zCX,
you can select between databases, such as PostgreSQL or IBM Db2 database running on
native z/OS for internal data storage.
Carefully review the Planning for zCX steps before provisioning your zCX instance to
ensure your IBM Security Guardium Key Lifecycle Manager Container Edition deployment
has sufficient resources. You can modify some resources after the initial zCX provision by
using the reconfiguration workflow in z/OSMF.

Restriction: IBM Security Guardium Key Lifecycle Manager Container Edition does not
support the Multi-Master feature.

20 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
2.2.4 Traditional and Container Edition comparison
Figure 2-1 shows comparison between Traditional edition and containerized edition of IBM
Security Guardium Key Lifecycle Manager.

Figure 2-1 Comparison of IBM Security Guardium Key Lifecycle Manager editions

2.2.5 Key serving

The information about key serving, which is summarized in this section, can help you become
familiar with the terms and statements that are used throughout this book.

IBM Security Guardium Key Lifecycle Manager enables the definition and serving of keys, or
groups of keys, which can be associated with a device. IBM Security Guardium Key Lifecycle
Manager deploys separate key types to separate devices that request them.

Consider the following points:

򐂰 A key can be a member of a single key group, and deleting a key group deletes all keys in
that group.
򐂰 The key metadata includes information, such as a key alias, algorithm, and activation date.
IBM Security Guardium Key Lifecycle Manager stores metadata for a key in the IBM
Security Guardium Key Lifecycle Manager database.
򐂰 A key or certificate can be in the following states, which define the level of use that
is allowed:
– Pending
– Pre-active
– Active

Chapter 2. External key managers 21

 – Compromised
– Deactivated
– Destroyed
– Destroyed-compromised
An object that is no longer active might change states from deactivated to destroyed,
deactivated to compromised, compromised to destroyed-compromised, or destroyed to
destroyed-compromised.
When a key is generated, the keys, its alias, and metadata are stored in an
IBM Security Guardium Key Lifecycle Manager database. The new key enter an active
state immediately. When a certificate request is created, IBM Security Guardium Key
Lifecycle Manager creates an entry that is in a pending state. It waits for the return of a
certificate that was approved and certified by a certificate authority (CA).

Changing attributes: Information attributes of a key, regardless of its state, can be

changed by using REST or CLI.

򐂰 Standard and operating system-specific Java keystore methods are supported by

IBM Security Guardium Key Lifecycle Manager to store public/private key and certificate
information. The Java Cryptography Extension KeyStore (JCEKS) keystore type is
supported as the IBM Java Cryptography Extension software provider. It can be used for
all distributed operating systems.

2.2.6 Protecting IBM Security Guardium Key Lifecycle Manager data

The IBM Security Guardium Key Lifecycle Manager contains critical information that must be
protected. It includes the following options:
򐂰 Backup: You can back up critical data files on a secure computer at a geographically
separate location or on a replica computer that provides another IBM Security Guardium
Key Lifecycle Manager server. The replica computer enables quick recovery at times when
the primary IBM Security Guardium Key Lifecycle Manager server is not available.
򐂰 Restore: A restore operation returns the IBM Security Guardium Key Lifecycle Manager
server to a known state by using backed-up production data, such as the IBM Security
Guardium Key Lifecycle Manager keystore and other critical information.
򐂰 Audit: On distributed systems, audit logs are stored in the Common Base Event format or
Syslog format by IBM Security Guardium Key Lifecycle Manager.
򐂰 Automated clone replication: A master IBM Security Guardium Key Lifecycle Manager
server can be configured to replicate data to up to 20 clones. The replicated data includes
keys and certificates that are stored in tables in an IBM Security Guardium Key Lifecycle
Manager database, certificates in a truststore keystore, and a master key that is stored in
Java keystore and IBM Security Guardium Key Lifecycle Manager configuration files.

Note: The replicated data is identical to the IBM Security Guardium Key Lifecycle
Manager backup, except for the replication configuration file. During replication, these
items are not backed up or passed to the clones.

򐂰 Multi-Master: In a Multi-Master cluster, all IBM Security Guardium Key Lifecycle Manager
servers are masters. In one cluster, 21 masters can be configured where keys can be
created and fetched from any master in real-time.

22 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 򐂰 Master key protection: IBM Security Guardium Key Lifecycle Manager stored its master
key in Java keystore by default. IBM Security Guardium Key Lifecycle Manager can be
configured to use an Hardware Security Module (HSM) or Enterprise Key Management
Foundation (EKMF) Web to store the IBM Security Key Lifecycle Manager master key. IBM
Security Guardium Key Lifecycle Manager master key is used to protect all keys and
certificates that are stored in the database. This option adds extra protection to the
storage and use of the master key.

2.3 IBM Security Key Lifecycle Manager for z/OS

As an alternative to the IBM Guardium Security Key Lifecycle Manager V4.1 or later for open
systems, you can use the IBM Security Key Lifecycle Manager for z/OS product. Previous
names for this product were IBM Encryption Key Manager and IBM Tivoli® Key Lifecycle
Manager for the z/OS.

IBM Security Key Lifecycle Manager for z/OS also helps when you generate, protect, store,
and maintain encryption keys that are used to perform the following tasks:
򐂰 Encrypt information that is being written to devices
򐂰 Decrypt information being read from devices

IBM Security Key Lifecycle Manager for z/OS supports System Management Facilities
(SMFs) for audit records. The IBM Security Key Lifecycle Manager for z/OS is part of the IBM
Java environment, and uses the IBM Java Security components for its cryptographic
capabilities.
.

Attention: Do not confuse IBM Security Key Lifecycle Manager for z/OS with IBM Security
Guardium Key Lifecycle Manager V4.1 for Open Systems. IBM Security Key Lifecycle
Manager for z/OS supports DAR encryption key management only. It does not support
TCT encryption and IBM Fibre Channel Endpoint Security.

However, you can install IBM Security Key Lifecycle Manager V4.0 in IBM Z Linux.

2.3.1 IBM Security Key Lifecycle Manager for z/OS components

IBM Security Key Lifecycle Manager for z/OS features the following components:
򐂰 Java security keystore
򐂰 Configuration files
򐂰 Device table
򐂰 KeyGroups.xml file

Java security keystore

The keystore is defined as part of the Java Cryptography Extension (JCE). The keystore is an
element of the Java Security components, which are part of the Java runtime environment. A
keystore holds the certificates and keys (or pointers to the certificates and keys) that are used
by the IBM Security Key Lifecycle Manager for z/OS to do cryptographic operations.

IBM Security Key Lifecycle Manager for z/OS supports non-hardware and hardware-assisted
keystores. Hardware-based JCECCARACFKS keystores need a hardware cryptographic
services provider. This support for hardware-assisted keystores makes IBM Security Key
Lifecycle Manager for z/OS the preferred key server for a z/OS environment, at least for
tape encryption.

Chapter 2. External key managers 23

 Configuration files
With configuration files, you can customize the behavior of IBM Security Key Lifecycle
Manager for z/OS to meet the needs of your organization.

Device table
The device table is used by IBM Security Key Lifecycle Manager for z/OS to monitor the
devices it supports. The device table is a non-editable, binary file whose location is specified
in the configuration file. You can change its location to meet your needs.

KeyGroups.xml file
This password-protected file contains the names of all encryption key groups and the aliases
of the encryption keys that are associated with each key group.

2.3.2 Functions performed by IBM Security Key Lifecycle Manager for z/OS
IBM Security Key Lifecycle Manager for z/OS requests the generation of encryption keys and
passes those keys to TS1120, TS1130, TS1140, TS1150, and LTO Ultrium 4, 5, and 6 tape
drives, and DS8000 disk storage systems, to name some of the supported storage devices.
When a DS8000 starts, the storage system requests an unlock key from IBM Security Key
Lifecycle Manager for z/OS.

If the DS8000 requests a new key for its unlock key, IBM Security Key Lifecycle Manager for
z/OS generates an AES key and serves the key to the DS8000 in two protected forms:
򐂰 Encrypted (wrapped), by using Rivest-Shamir-Adleman (RSA) key pairs. The DS8000
stores this copy of the key.
򐂰 Separately wrapped for secure transfer to the DS8000, where it is unwrapped upon arrival
and the key inside is used to unlock the DS8000.

If the DS8000 requests an existing unlock key, the protected AES key on the DS8000 is sent
to IBM Security Key Lifecycle Manager for z/OS, where the wrapped AES key is unwrapped.
The AES key is then wrapped with a different key for secure transfer back to the DS8000,
where it is unwrapped and used to unlock the system.

The IBM Security Key Lifecycle Manager for z/OS design allows redundancy and offers high
availability. You can have multiple IBM Security Key Lifecycle Manager for z/OS sets that
service the same devices. In this way, you can have two IBM Security Key Lifecycle Manager
sets. They are mirror images of each other. They have built-in backup of the critical
information about your keystores and serve as a failover options if one IBM Security Key
Lifecycle Manager for z/OS set is not available. When you configure your DS8000, you can
point it to two sets of IBM Security Key Lifecycle Manager for z/OS. If one IBM Security Key
Lifecycle Manager for z/OS set is not available, your DS8000 uses the other IBM Security Key
Lifecycle Manager for z/OS set.

You can also keep the two IBM Security Key Lifecycle Manager for z/OS sets synchronized.
Be sure that you take advantage of this important function when necessary.

2.3.3 Preventing a deadlock situation

If you use IBM Security Key Lifecycle Manager for z/OS as a key manager for DS8000 DAR
encryption, you can run into a deadlock situation if you use key servers that are run only on
encrypted DS8000 disk storage systems.

24 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 When all z/OS logical partitions (LPARs) are powered down and are restarted, the DS8000
disk storage systems with enabled encryption must “talk” to an encryption server to get the
unlock key. However, IBM Security Key Lifecycle Manager for z/OS cannot start because its
data is stored on an encrypted DS8000 disk.

A DS8000 must have all encrypted data or no encrypted data. A mix of encrypted and
non-encrypted data is not possible.

To avoid this type of deadlock, be sure that you have one of these setups available:
򐂰 A z/OS attached storage system that is not encrypted for the IBM Security Key Lifecycle
Manager for z/OS LPAR.
򐂰 A duplicate IBM Security Key Lifecycle Manager for z/OS set at the disaster recovery site
with a backup copy of the data files.
򐂰 A stand-alone IBM Security Key Lifecycle Manager for open systems set as an alternative
to IBM Security Key Lifecycle Manager for z/OS with a copy of the keys.

If you have an environment with an IBM Security Key Lifecycle Manager on z/OS and a
stand-alone IBM Security Guardium Key Lifecycle Manager for open systems, you must
create a certificate and a private key on IBM Security Key Lifecycle Manager for z/OS and
one on IBM Security Guardium Key Lifecycle Manager for open systems.

Export these certificates and then import the certificates for each other. This task means that
the IBM Security Key Lifecycle Manager for z/OS certificate goes to IBM Security Guardium
Key Lifecycle Manager for open systems. Also, the IBM Security Guardium Key Lifecycle
Manager for open systems certificate goes to IBM Security Key Lifecycle Manager for z/OS.
Configure the DS8000 to use both certificates.

The DS8000 must communicate with at least two key servers because you cannot configure
a DS8000 with encryption enabled if the DS8000 cannot communicate with two key servers.
For a power-on operation, it is sufficient for the DS8000 to access only one key server.

2.3.4 Installing the IBM Security Key Lifecycle Manager for z/OS and keystores
Install IBM Security Key Lifecycle Manager for z/OS as described in Program Directory for
IBM Security Key Lifecycle Manager for z/OS V1.1.0.

This section includes only an overview of the installation steps.

You can set up IBM Security Key Lifecycle Manager for z/OS in several ways, depending on
the keystore types. IBM Security Key Lifecycle Manager for z/OS supports the following
keystores:
򐂰 JCEKS
򐂰 JCECCAKS
򐂰 JCERACFKS
򐂰 JCECCARACFKS

IBM Security Key Lifecycle Manager for z/OS requires IBM Java Software Developer Kit 5.0 or
6.0 and later. It also requires the unrestricted policy files for Java. The files are available at
this website.

The installation process includes the following overall steps:

1. Install the Java SDK.
A recent version, IBM 64-bit SDK for z/OS Java Technology Edition Version 8 is preferred.
It already should be installed in your z/OS environment.

Chapter 2. External key managers 25

 Verify that the correct version of Java is installed. First, make sure that the Java bin
directory is in your PATH by running the USSexport command:
export JAVA_HOME=/usr/lpp/java84
export PATH="$PATH":"${JAVA_HOME}"/bin
Replace the path with the path where your Java SDK was installed. Then, run the java
-version command from the UNIX console under z/OS.
2. Copy the unrestricted policy files. You must replace the US_export_policy.jar and
local_policy.jar files in the following directory with an unrestricted version of these files:
$JAVA_HOME/lib/security
3. Select the keystore type:
– Add the Java hardware provider if you want to use hardware cryptography.
If you decide to use a keystore type of either JCECCAKS or JCECCARACFKS so that
you can use the security advantages of ICSF, you must add the Java
hardware provider.
You cannot use both JCERACFKS and JCECCARACFKS keystore types concurrently
in the IBM Security Key Lifecycle Manager for z/OS configuration file. You must specify
only one of these types in the configuration file.
To add the Java hardware provider, you must edit the following file and complete the
following steps:
$JAVA_HOME/lib/security/java.security
i. If you want the RSA key to be secure and not visible in the clear, create your RSA
keys in the ICSF PKDS by using either the RACDCERT PCICC option or hwkeytool with
the -hardwaretype PKDS flag.
ii. If you want the data encryption key (DEK) to be secure and not visible in the clear,
change the configuration to set the requireHardwareProtectionForSymmetricKeys
property to true.
iii. Ensure that the IBM Java Cryptography Extension CCA provider is installed in
java.security provider list.
– If you are not using hardware cryptography, use a JCEKS keystore type by completing
the following steps:
i. Obtain a list of all the aliases (or key labels) for the RSA keys that you want to use.
For more information, see your keystore documentation.
ii. Obtain a list of all the type Drive Serial Numbers that you need to register. This step
is optional if you set drive.acceptUnknownDrives = true for automatic addition of
tape drives to device table and ds8k.acceptUnknownDrives=true to accept
automatically new DS8000 drives.
iii. Edit the ISKLMConfig.properties.zos file, as shown in Configuration Basics, to
customize the entries that are appropriate for your installation.
4. Set up a user to run IBM Security Key Lifecycle Manager for z/OS.
In our case, we used the ISKLMSRV user ID (UID). This UID must have an OMVS
segment with a UID and group ID (GID) that is defined. The UID does not need to be zero;
it can be any value. The home directory of this UID OMVS segment is where IBM Security
Key Lifecycle Manager for z/OS is started. The UID must also run the standard shell at
login (/bin/sh), and be connected to a default group that has a GID. You can allow
IBM RACF® to automatically assign the UID or explicitly define the UID. The ISKLMSRV
UID is a protected user. It cannot be used as a TSO UID.

26 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 Note: In Open MVS (OMVS), the configuration file permission is set so that only the
owner can read or write the configuration file. If you log on and you are not the owner of
the configuration file, you do not have permission to write to the configuration file. You
might encounter an error similar to the following one:
- java.io.FileNotFoundException:
/u/isklmsrv/JA0/ISKLMConfig.properties.zos.JCECCARACFKS (EDC5111I Permission
denied.)

You might encounter the same error when stopping the server, running the refresh
operation, or changing passwords. As a best practice, log on by using the UID with
owner permissions.

5. Get digital certificates.

6. Set up the IBM Security Key Lifecycle Manager for z/OS configuration file.
Edit ISKLMConfig.properties.zos to update the following values (IBM Security Key
Lifecycle Manager for z/OS must not be running when you edit the
ISKLMConfig.properties.zos file):
a. Audit.handler.file.directory: Specify a location where audit logs are stored.
b. Audit.metadata.file.name: Specify a fully qualified path and file name for the
metadata XML file.
c. config.drivetable.file.url: Specify a location for information about drives that are
known to IBM Security Key Lifecycle Manager for z/OS. This file is not required before
starting the server or CLI client. If it does not exist, it is created during shutdown of the
IBM Security Key Lifecycle Manager for z/OS server.
d. TransportListener.ssl.keystore.name: Specify the path and file name of the keystore
that is created in step 1 on page 25.
e. TransportListener.ssl.truststore.name: Specify the path and file name of the
keystore that is created in step 1 on page 25.
f. Admin.ssl.keystore.name: Specify the path and file name of the keystore that is
created in step 3 on page 26.
g. Admin.ssl.truststore.name: Specify the path and file name of the keystore that is
created in step 3 on page 26.
h. config.keystore.file: Specify the path and file name of the keystore that is created in
step 3 on page 26.
i. drive.acceptUnknownDrives: Specify true or false. A value of true allows new tape
drives that contact IBM Security Key Lifecycle Manager for z/OS to be automatically
added to the device table. The default is false.
j. ds8k.acceptUnknownDrives: Specify true or false. A value of true allows a new
DS8000 that contacts IBM Security Key Lifecycle Manager for z/OS to be automatically
added to the device table. The default is false.
The following optional password entries can be added or omitted. If these entries are not
specified in ISKLMConfig.properties.zos, IBM Security Key Lifecycle Manager for z/OS
prompts for the keystore password during the start of the server. When added to the
ISKLMConfig.properties.zos file, IBM Security Key Lifecycle Manager for z/OS
obfuscates these passwords for extra security. Obfuscating the passwords ensures that
they do not appear in the clear in the properties file.

Chapter 2. External key managers 27

 – Admin.ssl.keystore.password: Specify the password of the keystore that is created in
step 3 on page 26.
– config.keystore.password: Specify the password of the keystore.
– TransportListener.ssl.keystore.password: Specify the password of the keystore.
7. Define IBM Security Key Lifecycle Manager for z/OS as a started task. Use option 6 from
the ISPF primary screen to enter the following TSO commands:
SETROPTS GENERIC(STARTED)
RDEFINE STARTED ISKLM*.* STDATA(USER(ISKLMSRV) GROUP(STCGROUP) TRACE(YES))
SETROPTS CLASSACT(STARTED) SETROPTS RACLIST(STARTED)
SETROPTS RACLIST(STARTED) GENERIC(STARTED) REFRESH
To start IBM Security Key Lifecycle Manager, run the S ISKLM command from SDSF or any
z/OS console (the output of the command is shown after the command):
S ISKLM
$HASP100 ISKLM ON STCINRDR
IEF695I START ISKLM WITH JOBNAME ISKLM IS ASSIGNED TO USER ISKLMSRV, GROUP SYS1
$HASP373 ISKLM STARTED
ISKLM console interaction is now available. 546
To submit commands to the IBM Security Key Lifecycle Manager from the console, run the
following command:
F ISKLM,APPL=’ISKLM command’
To stop the IBM Security Key Lifecycle Manager, run the following command:
P ISKLM
Loaded drive keystore successfully
Starting the Encryption Key Manager 2.0-20070
Processing Arguments
Processing
Server is started
Server is running. TCP port: 3801, SSL port: 4

For more information, see the IBM Security Key Lifecycle Manager for z/OS Version 1.1
Planning, and User’s Guide, SC14-7628.

2.4 IBM Security Guardium Data Encryption V5.0

IBM Security Guardium Data Encryption is another external key manager that is supported for
DS8000 DAR encryption over KMIP and TCT encryption to cloud storage.

IBM Security Guardium Data Encryption consists of an integrated suite of products that are
built on a common infrastructure. These highly-scalable solutions provide encryption,
tokenization, data masking, and key management capabilities to help protect and control
access to databases, files, and containers across the hybrid multicloud. This protection
secures assets that are in cloud, virtual, big data, and on-premise environments.

For more information, see IBM Guardium Data Encryption.

28 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
2.5 Gemalto SafeNet KeySecure
Gemalto SafeNet KS is a third-party, centralized key management platform. It offers an
alternative to IBM Security Guardium Key Lifecycle Manager for clients and is fully supported
by DS8880 Release 8.5 and later for DAR encryption and TCT encryption.

Gemalto SafeNet KS is provided as hardware and virtual software appliance. At the time of
writing, the current version is 8.3.2 RevA. It supports the KMIP 1.1 (used with DS8000
Release 8.1), PKCS #11, JCE, MS-CAPI, ICAPI, and .NET APIs. LDAP and Active Directory
authentication are included too, and multiple network management protocols.

Like IBM Security Guardium Key Lifecycle Manager, Gemalto SafeNet KS supports 128-bit
encryption and provides a GUI named “Gemalto SafeNet KS Management Console” and an
SSH CLI.

Gemalto SafeNet KS can manage up to 1,000,000 keys and 1,000 devices, and it supports
HSM for storing the master key.

For more information about Gemalto SafeNet KS, see Cloud Protection and Licensing
Solutions.

2.6 Thales Vormetric Data Security Manager

The Thales Vormetric DSM is another external key manager that is supported for DS8000
DAR encryption and TCT encryption to cloud storage.

For organizations that opt for the Thales Vormetric DSM platform products, Vormetric DSM is
the central management point of the platform. DSM creates, stores, and manages the
encryption keys that protect data, and it also enables organizations to manage every aspect
of their data security platform implementation. Thales Vormetric DSM allows administrators to
specify data access policies, administer DSM users and logical domains, generate usage
reports, register hosts, access security logs, and manage third-party keys and digital
certificates.

For more information, see Vormetric Data Security Manager.

2.7 Thales CipherTrust Manager

Thales CipherTrust Manager (formerly known as Next Generation KS) is another external key
manager that is supported for DS8000 DAR encryption and TCT encryption to cloud storage.

Thales CipherTrust Manager offers an industry-leading enterprise key management solution

that organizations can use to centrally manage encryption keys, provide granular access
control, and configure security policies. Thales CipherTrust Manager is the central
management point for the Thales CipherTrust Manager data security platform. It manages
key lifecycle tasks that include generation, rotation, destruction, import, and export, and it
provides Role Based Access Control (RBAC) to keys and policies, supports robust auditing
and reporting, and offers a developer-friendly REST API.

For more information, see CipherTrust Manager.

Chapter 2. External key managers 29

30 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 3

Chapter 3. IBM DS8000 encryption

mechanisms
This chapter provides information about the DS8000 disk encryption mechanisms that use an
external key server. For more information about local encryption, see Chapter 7, “Local key
management” on page 229.

This chapter includes the following topics:

򐂰 3.1, “DS8000 data-at-rest encryption” on page 32
򐂰 3.2, “Key management for IBM Proprietary Protocol with IBM Security Guardium Key
Lifecycle Manager” on page 34
򐂰 3.3, “Key management by using KMIP” on page 45
򐂰 3.4, “Encryption deadlock” on page 47
򐂰 3.5, “Working with a recovery key” on page 49
򐂰 3.6, “Dual key server support (IBM Proprietary Protocol only)” on page 53
򐂰 3.7, “DS8000 TCT encryption key management using KMIP” on page 56
򐂰 3.8, “DS8000 endpoint encryption key management using KMIP” on page 59

© Copyright IBM Corp. 2014, 2021. All rights reserved. 31

3.1 DS8000 data-at-rest encryption
The DS8000 supports data encryption in systems that are equipped with Full Disk Encryption
(FDE) capable hard disk drives (HDDs) and flash drives, such as in the High Performance
Flash Enclosure (HPFE).

All drives (disk or flash) in the DS8880 or DS8900F systems are encryption-capable
(DS8900F supports only flash drives). Those drives include drive encryption hardware and
can perform symmetric encryption and decryption of data with no effect on performance.

The drive encryption hardware is used with various key managers.

All compatible key managers support the Key Management Interoperability Protocol (KMIP)
by using the direct key method to deliver keys to encrypting storage devices. Without these
keys, which are managed by the key servers, the data on disk cannot be decrypted.

IBM Security Guardium Key Lifecycle Manager also supports running IBM Proprietary
Protocol (IPP) by using a wrapped key method. The DS8000 uses an external key server
method to secure keys by separating the storage of a data key (DK) that is stored within the
device from the storage of the keys within the key server. The wrap/unwrap keys are also
referred to as the key encryption/key decryption keys. Without these keys, which are
managed by the key servers, the data on disk cannot be decrypted.

Cryptographically erased: 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 that is contained in the ciphertext is said to be cryptographically erased. The
data is lost because it cannot be decrypted without the key. This issue is relevant for
data-at-rest (DAR) and Transparent Cloud Tiering (TCT) encryption, but does not apply to
IBM Fibre Channel Endpoint Security where the keys are used only to encrypt data while
over the wire (data in flight).

For more information about encryption key management, see 3.2, “Key management for IBM
Proprietary Protocol with IBM Security Guardium Key Lifecycle Manager” on page 34, and
3.8, “DS8000 endpoint encryption key management using KMIP” on page 59.

An encryption-capable DS8000 can be configured to enable or disable encryption for DAR for
all data that is stored on drives.

Attention: Enabling DAR encryption cryptographically erases all data on the disks.
Therefore, encryption must be enabled directly at the beginning of the process, before data
is stored in the DS8000.

The DS8000 must be configured to communicate with at least two key servers to enable
encryption. Two key servers are required for redundancy. The communication between the
DS8000 and the key server is done through the Hardware Management Console (HMC).

32 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
The physical connection between the DS8000 HMC and the key server is through a Internet
Protocol network, as shown in Figure 3-1.

Figure 3-1 Connection between the DS8000 HMC key servers

Before explaining the various keys that are used by DS8000 and key servers for encryption
and how messages can be exchanged between two systems in a secure way (generically),
you must learn about the concept of digital signatures.

Digital signatures are used to authenticate a sender. The digital signatures are generated by
using the private and public keys. Figure 3-2 on page 34 shows the following steps:
1. The sender writes its message.
2. According to a mathematical formula, a digital string, usually of a fixed length, is derived
from the message. This string is called a hash. Although a hash is derived from and
uniquely linked to the data, deriving the data from the hash is not possible.
3. The hash is encrypted with the sender’s private key. The encrypted hash is called a
digital signature.
4. The digital signature is attached to the message.
5. Both message and digital signature are encrypted with the receiver’s public key.
6. The encrypted message is sent to the receiver.
7. The receiver decrypts the message and signature combination.
Now, the receiver reproduces the message hash in the following ways:
– The receiver decrypts the digital signature with the sender’s public key to get the
original hash.
– The receiver calculates the hash from the received message.
8. If both hashes match, the receiver has good reason to trust the message.

Chapter 3. IBM DS8000 encryption mechanisms 33

 Message exchange and sender verification
Sender
Receiver‘s
public key

Message Message
The quick The quick
brown fox brown fox Send
M
6
Digital
1 signature
Encrypt message and
signature with receiver’s 5
public key
Attach to
2 message
Receiver‘s
Hash the Receiver private key
message
4
101..Hash..010 Decrypt message and
M
signature with receiver’s
Compare to verify
private key
Sender‘s message integrity
private key 7
8
10 Decrypt digital sigature
with sender‘s public key Digital
signature

? Message
101..Hash..010
101..Hash..010 = 101..Hash..010 The quick
..Hash.. brown fox

3 9
Encrypt Hash with
sender‘s private key Digital Hash the
101..Hash..010
= digital signature signature
message

Figure 3-2 Authentication with digital signatures

3.2 Key management for IBM Proprietary Protocol with IBM

Security Guardium Key Lifecycle Manager
In this section, we describe how the IBM Security Guardium Key Lifecycle Manager key
server manages and creates the encryption keys that are used by the DS8000 during key
label, encryption group, rank creation, and DS8000 power-on time. This section also
describes the IBM Proprietary Protocol.

Important: Key negotiation and authentication between the IBM Security Guardium Key
Lifecycle Manager and DS8000 occurs at DS8000 power-on time only. Traffic does not
increase in an encrypted DS8000 at run time that is created by key negotiation.

The IBM Security Guardium Key Lifecycle Manager key server uses the wrapped key method
to serve keys to an encryption-enabled DS8000. The wrap and unwrap keys on the key server
are a public/private asymmetric key pair. The wrap key is referred to as the public key
encrypting key (KEK) and the unwrap key is referred to as the private key encrypting key
(KEK’).

The configuration processes on the key server and the storage device (the DS8000) define
one or more key labels. For more information, see 5.2, “Migrating IBM Security Guardium Key
Lifecycle Manager” on page 77.

34 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 Note: Most figures in this section still show SKLM as the key manager because the
process remained the same under the product new name as IBM Security Guardium Key
Lifecycle Manager (GKLM).

The key label is a user-specified text string that is associated with the asymmetric key label
pair (KEK/KEK’), which is generated by the key server when the key label is configured (see
Figure 3-3). The key generation and propagation processes on the key server associates a
key label with each wrap/unwrap key pair. This key label is a user-specified text string that is
retained with each wrap/unwrap key pair. The KEK-pair key is kept secret by IBM Security
Guardium Key Lifecycle Manager.

IBM Security Key Lifecycle Manager (SKLM)

SKLM generates keys: public / private Keystores

key pair for a certain Key Label
(associated with a DS8000) JCEKS
and puts them into the keystore
3
1
Password
locked

2
Wrapping
keys KEK‘ KEK
SKLM
Private Public

This key will be used

Key to communicate with Different keystores supported
Label: „DS8K1“
Key for
DS8K1 • JCEKS keystore file
• JCERACFKS z/OS RACF
• JCECCARACFKS z/OS HW
encryption

Figure 3-3 Configure IBM Security Guardium Key Lifecycle Manager key label

Rekey Data Key feature: With this feature, a user can change the DK labels (see 6.1,
“Rekeying the data key for data-at-rest encryption” on page 204).

Now, the user (storage administrator) can use the DS8000 GUI or DS command-line interface
(DS CLI) to register the key server on the DS8000. Next, still by using the DS8000 GUI or DS
CLI, an encryption group is created. For more information, see “DS8000 enabling data-at-rest
encryption” on page 156).

As part of creating the encryption group with IBM Proprietary Protocol, you must specify the
key label that was set when configuring the IBM Security Guardium Key Lifecycle Manager
server is configured, which was configured for a particular DS8000.

Chapter 3. IBM DS8000 encryption mechanisms 35

 Note: The DS8000 must have separate encryption groups: one encryption group for DAR
encryption, one for TCT, and one for IBM Fibre Channel Endpoint Security encryption.
Only DAR supports IBM Proprietary Protocol.

While creating the encryption group, the DS8000, which is referred to as DS8K1 in our
illustrated scenario, generates a “Device Session Key pair (device session public key/device
session private key, respectively noted as DSK/DSK’) from a random number. The
public/private key pair is associated with a key label. The DSK’ is kept secret by the DS8000.

The key label, DSK, and the DS8000 storage facility certificate, which was set and stored on
the DS8000 by manufacturing, are sent to the IBM Security Guardium Key Lifecycle Manager
on the key server to request a DK (see Figure 3-4).

Figure 3-4 DS8000 creates session keys and requests a data key

36 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
Upon reception of these elements, IBM Security Guardium Key Lifecycle Manager completes
the following steps (see Figure 3-5):
1. It validates the DS8000 certificate.
2. It generates the DK.
3. The DK is wrapped with DS8000 disk storage system’s DSK and stored in a structure that
is referred to as the session encrypted data key (SEDK).
4. From the key label, IBM Security Guardium Key Lifecycle Manager retrieves the KEK/KEK’
pair for the specified key label. The DK is wrapped with the KEK and stored in a structure
that is referred to as the externally encrypted data key (EEDK).

SKLM – generates data key

2 SKLM generates
symmetric key SKLM deletes the 6
1 Random
for DS8K1 number data key
generator
SKLM verifies DK Data
Data
Symmetric key Symmetric key
sender by
key key
validating DS8K1‘s
Data Key for DS8K1
certificate 3
DSK
Wrap
Key data key SEDK
Label:
Key for
with
DS8K1 DS8K1‘s
DS8K Data
public Symmetric key
Public
key key
DSK Send both locked
4 5 (encrypted) envelopes
KEK to DS8K1
JCEKS Wrap
data key EEDK
with
SKLM‘s Data Note: SKLM keeps only
Symmetric key
KEK/KEK‘ public the wrapping keys
key
key in his keystore

Figure 3-5 IBM Security Guardium Key Lifecycle Manager generates data key

Chapter 3. IBM DS8000 encryption mechanisms 37

 Now, IBM Security Guardium Key Lifecycle Manager transfers the SEDK and EEDK to the
DS8000 and the following steps occur at the DS8000:
1. The DS8000 receives the encrypted structures with the DK in it.
2. To re-create the DK at the DS8000, the SEDK is unwrapped with the DS8000 disk storage
system’s DSK’. The DS8000 holds the DK in memory, as shown in Figure 3-6.

Figure 3-6 DS8000 unwraps data key and stores encrypted data key

3. The EEDK is stored in DS8000 disk storage system’s keystore. The DS8000 does not
have the key to unlock this structure.

38 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
4. The DS8000 generates a random 256-bit group key (GK) for the encryption group. See
Figure 3-7.

DS8000 – setting up encryption

….the group key
DS8K1 generates is volatile and lost
4 7
symmetric 256-bit after a power drop
group key
Group key used to
lock / unlock
disk drives…
Random
number
generator
GK DS8000 keystore:
Data
Symmetric key DS8K‘s communication keys
key DS8K
Private Private DSK
Group key

Encrypted data key

The data key is used to wrap the group key
EEDK
5
DK The encrypted group key
Data
Symmetric key is stored in keystore on 6
key EGK internal disk
EGK

Data
Symmetric key
key
Encrypted group keys

Figure 3-7 Setting up encryption

5. The GK is wrapped with the DK and stored in a structure that is referred as the encrypted
group key (EGK).
6. The EGK is persistently stored in the key repository (KR) of the DS8000. The EEDK and
the EGK are stored in multiple places in the DS8000 for reliability.
This dual control (from the DS8000 and IBM Security Guardium Key Lifecycle Manager)
improves security. The DS8000 does not maintain a persistent copy of the DK on disk in
the clear. It also cannot encrypt or decrypt data without access to IBM Security Guardium
Key Lifecycle Manager.
The DK is erased by the DS8000 at power off, such that each time it is powered on, the
DS8000 must communicate with IBM Security Guardium Key Lifecycle Manager to obtain
the DK again.

Chapter 3. IBM DS8000 encryption mechanisms 39

 When the user configures a rank, the DS8000 creates, for each DDM in this rank, an access
credential to lock the drive, as shown in Figure 3-8. The following steps occur during
configuration of the rank:
1. The DS8000 reads the serial number of each disk.
2. The serial number is hashed with the GK to create the access credential.
3. The access credential is sent to the drive.
4. In the drive, its encryption key is wrapped with the access credential. A hash of the access
credential is also stored on the drive.

DS8000 enabling encryption – locking drives

1 Current keys from factory
Format a Rank Get serial numbers

GK
Data
Symmetric key Drives are encrypting
key but the drives are
Hash group key and unlocked which means
Group key the drives allow
to lock / encrypt drive serial number
access to data
drive keys to produce locking keys 3
2 4
Lock drive
encrypt key
Hash input: group key + drive serial number Drive access credentials
Hash
0110011010010101………1111110011010000 11000010100 0110101111011110
Function Store credential hash

Hash input: group key + drive serial number Drive access credentials
Hash
0110011010010101………1111110011010000 11000010100 0110101111011110
Function
Store credential hash
Hash input: group key + drive serial number Drive access credentials
0110011010010101………1111110011010000
Hash
11000010100 0110101111011110
Function
Store credential hash

Figure 3-8 Setting up encryption: Locking the drives

The drives are locked now, which means after a power-off and a power-on, the drives grant
access to data only when the encrypted encryption key that is stored on the drives is
unlocked by providing access credentials and an unlock key, as shown in Figure 3-9 on
page 41.

Disk encryption details

Each FDE drive has an encryption key for the area of the drive that contains client data (Band
1). As shown in Figure 3-9 on page 41, Band 0 is for internal global data, which is
also encrypted.

When the client data area is unlocked, the FDE drive still encrypts/decrypts the data with a
data encryption key (DEK) and this DEK is also wrapped (encrypted) with access credentials.
Here, a default encryption key is used to encrypt the DEK, but it is done transparently to the
initiator (the DS8000). However, if someone takes the disk plate without the interface, trying to
read from the disks is impossible because the data is encrypted.

40 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
The DEK for the data area is wrapped (encrypted) with an access credential that is produced
with the GK. This access credential is converted to a secure hash and stored on the disk. 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 is authenticated by supplying the currently active access credential, that is, the GK,
as shown in Figure 3-9. (The DS8000 first must unlock keys for the GK from the IBM Security
Guardium Key Lifecycle Manager server). The following steps occur:
1. The disk drive verifies the access credentials (containing the GK).
2. The drive validates the access credentials with the one stored on the disk drive.
3. The drive reads the stored encrypted DK.
4. The encrypted DK is decrypted by using access credentials (GK).
0110011010010101………1111110011010000

Inside the disk drive when a rank is created

Hash input: group key + drive serial number

If access credentials
GK Decrypted data /
verified, unlock
Group Drive Encryption Key
clear text
Symmetric key “The quick brown fox ...”
key
4

Volatile Encryption/Decryption
1 DEK
Engine
Storage
5
11000010100

Verify access
credentials 3
Encrypted data
Drive access credentials Drive retrieves s<38q@id;gi4#!~jeg0d$
Hash encrypted DEK
0110101111011110
function
Hash access credentials
1110110010101110
2 Storage Media

Encrypted user data

User data band(s) Stored drive
Band 1 access credentials hash
Encrypted
System band 1110110010101110 Data Encryption Key (DEK)
(user-inaccessible)
Band 0

Figure 3-9 Unlocking drives

An FDE drive that is made a member of an encryption-enabled rank is locked. The FDE drive
is unlocked when it is unassigned, or is a spare. Locking occurs when an FDE drive is added
to an encryption-enabled rank either during rank creation or sparing. Unlocking occurs when
an encryption-enabled rank is deleted or a member of an encryption-enabled rank is reused
as a spare. Unlocking always results in a cryptographic erasure of an FDE drive (the disk
resets its own encryption key). This action also happens when an encryption-disabled rank
is deleted.

Chapter 3. IBM DS8000 encryption mechanisms 41

 In a cryptographic erasure, a new DEK is generated in each disk drive (see Figure 3-10). The
new key is encrypted with default access credentials, and both the access credentials and the
encrypted DEK are stored on Band 0 of the drive. Now, the drive is unlocked. If someone tries
to read the old data, nonsense data is returned because decryption now uses another key,
which no longer decrypts the data.

Cryptographic erasure

Set a new
Drive Encryption Key Decrypted data / 6
clear text Data no longer
1 “%$#@EGHOLMUXLOVNG%..” readable

Encrypt the Volatile Encryption/Decryption New key in

Drive Encryption Key DEK Engine Encryption/
with a unique Storage Decryption
access credential 5 Engine
(a default credential)

3
4 Encrypted data
Drive access credentials s<38q@id;gi4#!~jeg0d$
Delete old
Data Encryption Key

Storage Media

Old access Encrypted user data

0110101111011110
credentials
New default
access credentials Encrypted
Data Encryption Key (DEK)
0110101111011110
2

As the Drive Encryption Key is encrypted with a default access credential for that drive, the drive is unlocked

Figure 3-10 Cryptographic erasure

FDE drives are not cryptographically erased when a drive fails. In this case, there is no
guarantee that the device adapter (DA) can communicate with the disk to cryptographically
erase it. More specifically, the DA intentionally fences the failing drive from the device
interface immediately to prevent it from causing other problems on the interface. However,
because the currently active encryption key that still exists in the failed FDE drive is
encrypted, the data is not readable.

42 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
Getting access to data after a power-on
After powering off and powering on, the DS8000 no longer has a DK or a GK in the clear, as
shown in Figure 3-11. The DEKs in the drives are encrypted, the GK to unlock the drives is
encrypted, and the DK to access to the GK keystore is encrypted. But, the DS8000 does not
have access to all these keys. It must first get a key to unlock the DK from IBM Security
Guardium Key Lifecycle Manager.

Status after a power drop / power on

SKLM DS8000

Drives locked
Keystores DS8000 keystore:

JCEKS Encrypted data key

EEDK

KEK/KEK‘

EGK

Encrypted group key

No keys to unlock the drives

DS8K1‘s communication / session keys

are not preserved

Figure 3-11 DS8000 status after a power drop/power on

Chapter 3. IBM DS8000 encryption mechanisms 43

 The DS8000 must complete the following steps (see Figure 3-12) to regain access to locked
drives and data at power-on:
1. The DS8000 generates a new session key pair (private and public) to communicate with
IBM Security Guardium Key Lifecycle Manager.

Important: The DS8000 must be able to communicate with at least one IBM Security
Guardium Key Lifecycle Manager server at power-on.

2. The DS8000 gets the EEDK from its keystore.

3. The DS8000 requests IBM Security Guardium Key Lifecycle Manager to unwrap a
wrapped DK by sending the request to IBM Security Guardium Key Lifecycle Manager with
the saved EEDK, DSK, and DS8000 disk storage system’s certificate.
4. The IBM Security Guardium Key Lifecycle Manager unwraps the EEDK with its key-label
private key to obtain the DK.
5. The DK is wrapped with DS8000 disk storage system’s DSK to create the SEDK.
6. The SEDK is returned to the DS8000.
7. The SEDK is decrypted with DS8000 disk storage system’s DSK’ to obtain the DK.
8. The DK is then used to unwrap the EGK to get the GK.
9. The serial number of the disk is read and hashed with the GK to obtain the access
credential. The hashed access credential is sent to disk and the validity of the access
credential is verified. If the access credential is valid, the disk encrypted DK is unwrapped
to gain access to the data.

Getting the keys to unlock the drives after a power on

Please, decrypt the data key DS8000 DS8K1
3
SKLM and send it to me, encrypted Create new
with my public session key session keys
JCEKS
1
2
Key
Label: EEDK
Key for
DS8K1
Get
KEK/KEK‘ encrypted
DS8K
Public
data key

EEDK
4 SKLM unlocks data key
8
KEK‘
Use group
Unwrap group key
EEDK key to unlock
EGK
9 drive keys
SKLM uses its
private key to
unlock the data key
6 Encrypted
SKLM wraps data key group key
Send to DSK‘
DSK
SEDK DS8K1
SEDK
DS8K1‘s
5 private key
SKLM uses 7
DS8K1‘s public key to wrap
the data key Unwrap data key
Figure 3-12 Regaining access to data after a power on

44 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
3.3 Key management by using KMIP
In this section, we describe how the key servers manage and create encryption keys. These
keys are used by the DS8000 during encryption group and rank creation and DS8000
power-on time.

Important: Key negotiation and authentication between the key manager and DS8000
occur at DS8000 encryption configuration and power-on time only. Traffic use does not
increase in an encrypted DS8000 at run time that is created by key negotiation.

The key manager server that uses KMIP uses the direct key method to serve keys to
encryption-enabled DS8000 while IBM Security Guardium Key Lifecycle Manager uses IBM
Proprietary Protocol the wrapped key method.

In the direct key model, the DK is created and stored on the external key server upon request
from the DS8000. It is created and registered on the key server. When the storage device
requires the DK for its cryptographic purposes, the storage device requests the key and the
key server delivers it.

A single DK is associated to the DS8000. During a rekey, the DS8000 requests that a DK is
created by the key server.

The DS8000 authenticates itself with a root Secure Sockets Layer (SSL) certificate at the key
server, or, for more security, with the root SSL certificate and a user ID (UID), which are
created during manufacturing and set into the SSL certificate on the DS8000.

For more information, see the following resources:

򐂰 Setting up the IBM Security Guardium Key Lifecycle Manager with UID and SSL
certificates for DK delivery, see “Creating an TLS/KMIP server certificate” on page 79.
򐂰 Setting up the Gemalto SafeNet KeySecure (KS) servers with UID and SSL certificates for
DK delivery, see 5.3.2, “Configuring Gemalto SafeNet KeySecure platform” on page 104.
򐂰 Setting up the Thales Vormetric Data Security Manager (DSM) server with UID and SSL
certificates for DK delivery, see 5.3.3, “Configuring Thales Vormetric Data Security
Manager” on page 121.
򐂰 Setting up the Thales CipherTrust Manager server with UID and SSL certificates for DK
delivery, see 5.3.5, “Configuring Thales CipherTrust Manager” on page 133.

Now, the user (Storage Administrator) can use the DS8000 GUI or DS CLI to register the key
server on the DS8000. For more information about how to perform this action, see 5.4.3,
“DS8000 configuration for data-at-rest encryption in DS GUI” on page 150.

Next, an encryption group must be created by using the DS8000 GUI or DS CLI. As part of
creating the encryption group, you must specify the encryption protocol KMIP. For more
information about how to perform this action, see 5.4.3, “DS8000 configuration for
data-at-rest encryption in DS GUI” on page 150.

Note: The DS8000 supports only one DAR encryption group.

Chapter 3. IBM DS8000 encryption mechanisms 45

 The encryption group creation process features the following steps (see Figure 3-13):
1. A user requests that an encryption group is created.
2. The DS8000 requests a DK generation from one of the previously created key servers.
3. The key server generates the DK and replicates it to all other key servers in the cluster,
which can be up to four. It stores the key in an encrypted database.
4. The key server returns a universally unique identifier (UUID) back to the DS8000.
5. The DS8000 requests the DK from the key server by using that UUID that is received
during the generate key request process.

Note: The UUID is a random 64-byte unique identifier with no relationship to the DK. It
is created during initial encryption group creation when requesting the DK for the first
time and used for identification.

6. The key server returns the DK, which is secured by TLS/SSL, to the DS8000.
7. The DS8000 creates the GK and wraps it with the DK to get an EGK.
8. The DS8000 stores the encrypted GK, UUID, and protocol information (KMIP) in its KR.
9. The DS8000 temporarily stores the DK in protected memory, but not on disk.
10.The DS8000 request to retrieve the DK from all configured key servers and compares it
with the one in memory for verification. At least two of the configured key servers must
return the correct DK.
11.The DS8000 deletes DK and the GK from local (working) memory after verification
is successful.

Figure 3-13 KMIP key server key exchange

46 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 After the encryption GK is created, the remaining drive encryption steps are the same as the
steps that are used with IBM Security Guardium Key Lifecycle Manager that uses IBM
Proprietary Protocol because the internal DS8000 encryption mechanism did not change. For
more information, see 3.2, “Key management for IBM Proprietary Protocol with IBM Security
Guardium Key Lifecycle Manager” on page 34. Cryptographic erase, rekey, and recovery key
(RK) usage and actions are also mostly unchanged.

Accessing data after a power-on

After powering off and powering on, the DS8000 no longer has a DK or a GK in the clear. The
DEKs in the drives are encrypted, the GK to unlock the drives is encrypted, and the DK to get
access to the GK in keystore is encrypted. But, the DS8000 cannot access all of these keys.
Instead, it must first get the unlock DK from KMIP key server.

Because the DK is now stored encrypted in the key server, the DS8000 asks during power-on
for the DK and authenticates itself with the UUID and its certificate. The key server then
provides the key and the DS8000 can unlock the encrypted GK and continues to power on.

3.4 Encryption deadlock

The key server platform provides the operating environment for the key server application to
run in, access its keystore on persistent storage, and interface with client storage devices,
such as the DS8000 that requires key server services.

The keystore data is accessed by the key server application through a password that is
specified by the client. As such, 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 a storage server that depends on the key server to enable access. If this
constraint is not met, the key server cannot complete its initial program load (IPL) and does
not become operational.

This required data includes the boot image for the operating system that runs on the key
server and 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 depends on a key server to
access data.

Not strictly following these implementation requirements might result in the situation where
the encrypted data can no longer be accessed temporarily, or worse, permanently. This
situation is referred to as encryption deadlock.

Important (encryption deadlock): Any data that is required to make the 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 to as an encryption deadlock. This
situation is similar to having a bank vault that is unlocked with a combination and the only
copy of the combination is locked inside the vault.

Chapter 3. IBM DS8000 encryption mechanisms 47

 A temporary encryption deadlock and a permanent encryption deadlock feature the following
differences:
򐂰 Temporary encryption deadlock
The temporary encryption deadlock indicates a situation where the DS8000 cannot
access its disk devices because the key servers are not online, the network is down, or for
any other temporary hardware-related errors. This temporary failure can be fixed at the
client site.
򐂰 Permanent encryption deadlock
This permanent encryption deadlock is the worse case. Here, all key servers that manage
some set of data cannot be made operational because they depend on inaccessible
encrypted storage, or all encrypted online and offline data that is managed by the set of
key servers is, in effect, cryptographically erased and for all practical purposes
permanently lost.

When considering encryption in your environment, consider the following factors:

򐂰 As the availability of encryption-capable devices becomes more pervasive, more data is
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 some data that is 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 cause
difficulties for the client to maintain awareness of where all the files (necessary to make
the key server, and its associated keystore, available) are stored. The key server can
access its data through a database that runs on a file system that runs on a logical volume
manager, which communicates with a storage subsystem that provisions logical volumes
with capacity that is obtained from other subordinate storage arrays. The data that is
required by the key server might end up provisioned over various storage devices, each of
which can be independently encryption-capable or encryption-enabled.
򐂰 Consolidation of servers and storage tends to drive data migration and move more data
under a generalized shared storage environment. This storage environment becomes
encryption-capable as time goes on.
򐂰 All IBM server platforms support fabric-attached boot devices and storage. Some 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.
򐂰 For containerized GKLM environments, the container platform should use persistent
storage that is not handled by the same GKLM. Caution must be taken so that the
container is moved to the storage that has encryption keys stored in the GKLM container.

To mitigate the risk of an encryption deadlock, a stand-alone key server (also called an
isolated key server) is recommended and the client must be directly involved in managing the
encryption environment.

For more information, see Chapter 4, “Planning and guidelines for IBM DS8000 encryption”
on page 65, and Chapter 5, “Implementing IBM DS8000 encryption” on page 75.

48 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
3.5 Working with a recovery key
To get out of a deadlock situation (or as a recovery option if all key servers are destroyed and
unrecoverable), use the DS8000 to create an RK, a Security Administrator can unlock a
DS8000 without the involvement of a key server. It is also possible to disable the RK.

Note: Consider the following important points:

򐂰 An RK can be created for DAR encryption only. It is not supported for TCT or IBM Fibre
Channel Endpoint Security. It is also not created when a local encryption key is used.
򐂰 An RK can be created during the DAR encryption enablement process only. You cannot
create an RK when a DS8000 is configured as encrypted. Similarly, disabling the RK
management is allowed only for an unconfigured DS8000. Creating or disabling an RK
must be one of the first tasks when setting up the DS8000 for DAR encryption.

Managing the RK requires two people (roles): A Storage Administrator (admin) and a Security
Administrator (secadmin). The Security Administrator is a new role for DS8000 users. A
Storage Administrator cannot create a Security Administrator user on a DS8000 and vice
versa. The Security Administrator maintains the RK and keeps it safe; the Storage
Administrator must approve every action of the Security Administrator.

Client responsibility: Although DS8000 supports two roles, Storage Administrator and
Security Administrator, the client is responsible to assign these roles to two
separate individuals.

3.5.1 Recovery key management

Setting up an RK involves the following steps, as shown in Figure 3-14:

Generating a recovery key

Security 8 Storage 9
RK
administrator administrator
5 DS8000: Delete keys
Here is 3 Random
The key RK
1 number
generator
Request recovery key OK ! generates PRK
2048 bit
key
PRK SRK
2 Private Public
DS8000:
7
Random Primary Secondary
number recovery recovery Store keys
generator key key Encrypted
generates group key
recovery key RK 6
EPRK
EPRK Encrypt
RK primary
Recov.
Symmetric key recovery
Private key with
key 4 recovery SRK
key
Generate a secure hash of recovery key  recovery key signature
RS
RS
0110011010010101………1111110011010000
Hash 0110101111011110
0110101111011110
Function

Figure 3-14 Generating a recovery key

Chapter 3. IBM DS8000 encryption mechanisms 49

 1. The Security Administrator user requests the creation of an RK, which can be done with
the DS CLI or the GUI. This request function is not available to other users.
2. At some stage in the process, the Storage Administrator must approve the action that the
Security Administrator is going to perform.
3. With the request to generate an RK, the DS8000 creates a random 256-bit RK.
4. The DS8000 generates the recovery signature (RS) from a secure hash of the RK.
5. The storage facility generates an asymmetric public/private key pair from a random
2048-bit number. The private key is referred to as the primary recovery key (PRK) and the
public key is referred to as the secondary recovery key (SRK).
6. The DS8000 wraps the PRK with the RK to produce the encrypted primary recovery
key (EPRK).
7. The EPRK, SRK, and RS are stored in multiple places within the storage facility
for reliability.
8. The storage facility provides the RK to the Security Administrator. The system follows a
verification process, which is not described here (the Security Administrator must reinput
the RK).
9. The DS8000 deletes the PRK and the RK.

When you configure an encryption group with an RK defined, you must complete the following
steps in addition to the steps (see Figure 3-15 on page 50) that are shown in Figure 3-7 on
page 39:
1. The DS8000 wraps the GK with the SRK to produce the encrypted group recovery key
(EGRK).
2. The EGRK is stored with the EPRK and the other encrypted keys (EEDK and EKG) in the
DS8000 keystore.

Configuring an encryption group

with a recovery key defined

DS8000
keystore

EEDK

Encrypted
data key
Use the secondary (public)
recovery key to encrypt EGK Encrypted
the group key and store it group
1 2 recovery
SRK key
GK
Group EGRK EGRK
Symmetric key
key
Secondary
Encrypted
recovery group key
key Encrypted
(public key) group EPRK
Encrypted
recovery
key primary
recovery
key

Figure 3-15 Setting up encryption with a recovery key defined

50 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
After the encryption group is configured, ranks can be created and assigned to the
encryption group.

Using a recovery key to unlock a DS8000

After a power-off and power-on, the DS8000 attempts to contact all other configured key
servers to obtain the required key if it cannot obtain the required DK from a key server.

On a DS8000 with an RK configured, an option exists to allow a Security Administrator enter

the RK.

If the Security Administrator provides the RK and the Storage Administrator approves this
operation, the DS8000 uses the RK to unwrap the “EPRK to obtain the PRK (see
Figure 3-16). The RK process includes the following steps:
1. The DS8000 cannot communicate with any key server.
2. The DS8000 allows the RK to be entered.
3. The Security Administrator enters the RK.
4. The Storage Administrator approves the action.
5. The RK is used to unlock the PRK.
6. The PRK is used to unlock the GK.
7. The GK is used to unlock the drives.

Now, access to data is restored.

Using the recovery key

1
SKLM-1
SKLM-2
No SKLM
available SKLM-3
SKLM-4

Give me the
recovery key

Security Storage
administrator administrator

3
4 5 Unlock
Enters recovery key Approve !
drives
RK 6
RK EPRK 7
PRK

EGRK
GK
Get primary
recovery key
Get group key

Figure 3-16 Using the recovery key

Changing the recovery key

The DS8000 also supports functions to rekey, verify, and unconfigure an RK.

Chapter 3. IBM DS8000 encryption mechanisms 51

 The rekey and verify RK functions can be performed at any time while the RK is configured
and a key manager server is available. Access to a key manager server is required. It allows
the DS8000 to verify that it is in the correct environment.

Only when the key manager can decrypt the DK can the DS8000 be sure that it is in the same
environment (see Figure 3-17 on page 52). Only then, it generates a new RK. For example,
rekeying the RK is not possible on a DS8000 that was stolen and placed in a
separate environment.

During the rekey operation, the following steps are completed:

1. The DS8000 sends the EEDK and its public key to Key Manager Server and requests a
rekey validation.
2. Key Manager attempts to decrypt the DK.
3. If Key Manager can decrypt the DK, it signals the DS8000 that it can proceed to generate
a new RK.
4. The DS8000 generates a new RK.

Changing the RK does not erase the data.

Figure 3-17 Rekeying the recovery key

3.5.2 Disabling or enabling a recovery key

The RK can be optionally disabled or configured before establishing an initial logical
configuration. This section describes the steps that are required for disabling or enabling
the RK.

52 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 Disabling a recovery key
If you do not want to manage an RK in your environment, it can be disabled. However, this
process must be done as your first task before the encryption group is defined. The process
of disabling the RK includes the following steps:
1. The Security Administrator (secadmin) requests the disabling of an RK. This process can
be done by using the DS CLI or the GUI. This request function is available to a user with
the Security Administrator role only.
2. The Storage Administrator (admin) approves the disabling status.
3. The RK enters the disable state.

The encryption group can now be defined. For more information, see 5.5, “Configuration for
TCT encryption” on page 175.

Enabling a recovery key

When an RK is disabled, it can later be reenabled. This action is disruptive. All data (on the
DS8000) must be erased as a prerequisite.

Enabling the RK management involves the following steps:

1. The Security Administrator user requests the enabling of a disabled RK. This process can
be done with the DS CLI or the GUI. This request function is not available to other users.
2. The Storage Administrator approves the enabling status.

The RK can now be created, as described in 3.5.1, “Recovery key management” on page 49.
For more information, see 5.5, “Configuration for TCT encryption” on page 175.

3.6 Dual key server support (IBM Proprietary Protocol only)

The DS8000 supports the configuration of one or two key labels for the data-at-rest
encryption group when using IPP. IPP uses the concept of key labels whereas KMIP does
not.

When all key server platforms operate their keystores in clear-key mode or when only a single
host platform is used for all key servers, a single key label is typically sufficient to allow all key
severs to interoperate with the DS8000. In this case, it is possible for the asymmetric key pair
that is maintained for the key label by the IBM Security Guardium Key Lifecycle Manager to
be propagated across all supporting key servers so that each key server has the necessary
keys to wrap and unwrap the one EEDK that is maintained on the DS8000.

When two key server platforms and at least one of the key server platforms are operating in
secure key mode (which is available on the z/OS platform), a second key label is
typically required.

Note: Consider the following points:

򐂰 Having a key server platform in secure key mode on z/OS platform for the DS8000 is
not at all common. Typically, the z/OS runs on volumes that are on a DS8000, which is
encrypted. This situation increases the chance of running into a deadlock situation.
Having a second DS8000 that is not encrypted to run the key server also is
not common.
򐂰 In an IBM Security Guardium Key Lifecycle Manager Multi-Master configuration, at
least two key servers are deployed and keys are automatically replicated.

Chapter 3. IBM DS8000 encryption mechanisms 53

 A key server operating in secure key mode typically does not support exporting any private
keys outside of the key server platform. In this case, the following actions are performed to
synchronize keys between key servers (see Figure 3-18 on page 54):
򐂰 Key label 1 (with public and private key) is configured on a UNIX platform.
򐂰 Key label 2 (with public and private key) is configured on z/OS platform.
򐂰 The public key from key label 1 is exported to the IBM Security Key Lifecycle Manager for
z/OS (abbreviated as “SKLM-z/OS” in Figure 3-18 on page 54 and Figure 3-19 on
page 55).
򐂰 The public key from key label 2 is exported to platform IBM Security Guardium Key
Lifecycle Manager for UNIX (abbreviated as “SKLM-UNIX” in Figure 3-18 and Figure 3-19
on page 55).

Dual key server support

SKLM servers on separate platforms 4 DS8000 can

request a new key
SKLM – UNIX 1 from any SKLM
Generate key Public key of
„Clear Key Keystore“ Key Label 2
Priv. Publ.

Key Label 1
KL1

Exchange /
Cannot exchange KL2
private keys,
export 3
secure keystore public Keys DS8K
does not allow this
5 Give me Public
a new SEDK
data key
SKLM – z/OS Generate Key Encrypted with Data key from
„Secure Key Keystore“ DS800‘s TKLM-z/OS
Priv. Publ. public key

Encrypted EEDK-Ux
with
SKLM-UNIX
Public key of public key Data key from
Key Label 2 2 TKLM-z/OS
KL2 Key Label 1
Encrypted
with EEDK-z
Send encrypted keys SKLM-z/OS
public key
Data key from
6 TKLM-z/OS

Figure 3-18 Dual key server support

Now, all key servers on both platforms have the public keys for both key labels and the private
of one or the other key label. The DS8000 can request a new key from any key server and
store an EEDK that is associated with each key label. Therefore, the DS8000 now includes
two separate EEDKs.

Each IBM Security Guardium Key Lifecycle Manager has a “public key” of each key label so it
can generate two EEDKs.

The following steps summarize the example that is shown in Figure 3-18:
1. IBM Security Key Guardium Lifecycle Manager for UNIX creates a public/private key pair
for key label 1.
2. IBM Security Key Lifecycle Manager for z/OS creates a public/private key pair for key
label 2.

54 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
3. Both Security Key Lifecycle Managers exchange their public keys.
4. A DS8000 can request a DK from any IBM Security Guardium Key Lifecycle Manager. For
this example, assume it requests the DK from IBM Security Key Lifecycle Manager for
z/OS.
5. IBM Security Key Lifecycle Manager for z/OS generates the DK, wraps it with the DS8000
disk storage system’s public key to produce the SEDK, wraps the DK with its own public
key to produce EEDK with Z (EEDK-z), and wraps the DK with IBM Security Guardium
Key Lifecycle Manager for the UNIX public key to produce EEDK with UNIX (EEDK-Ux).
Then, the SEDK, the EEDK-z, and the EEDK-Ux are sent to the DS8000.

The DS8000 can request the EEDKs to be unwrapped by any key server because the request
contains both EEDKs (see Figure 3-19), and any key server has the private key for at least
one of the two EEDKs in the request. Secure key mode operation is maintained during the
exporting of secure keys because only the public key is exported.

Getting the key in a dual key server environment

SKLM servers on separate platforms

SKLM-UNIX can unwrap this EEDK
SKLM – UNIX
with its private key
„Clear Key Keystore“ 2
Priv. Publ.

EEDK-Ux
Key Label 1
KL1
Data key from
TKLM-z/OS
Can not exchange
DS8K
KL1
private keys, Public
secure keystore Public key of
does not allow this 1
SKLM-z/OS
EEDK-z
SKLM – z/OS
„Unlock KL2
„Secure Key Keystore“ Data key from
whatever TKLM-z/OS
you can“

DSK
SEDK

Data key from

TKLM-z/OS

Figure 3-19 Getting the recovery key in a dual server environment

In the example that is shown in Figure 3-19, the DS8000 sends its request to decrypt the DK
to IBM Security Guardium Key Lifecycle Manager for UNIX with both key labels and EEDKs.
IBM Security Guardium Key Lifecycle Manager for UNIX can decrypt the EEDK-Ux that is
associated with key label 1.

IBM Security Guardium Key Lifecycle Manager for UNIX can now send the encrypted DK
back to the DS8000 server.

Chapter 3. IBM DS8000 encryption mechanisms 55

3.7 DS8000 TCT encryption key management using KMIP
As described in 3.1, “DS8000 data-at-rest encryption” on page 32, DAR encryption is
implemented in the DS8000 by using external key servers. This approach provides a physical
and logical isolation between the encryption keys and the DS8000 and thus protects data if
the DS8000 or any of its drives were stolen.

However, DAR encryption does not protect data as it is transferred to or from the cloud when
TCT is used.

Starting with DS8000 Release 8.5, you can encrypt data as it is transmitted between the
DS8000 and the cloud. This encryption mechanism also uses external key servers.

This section describes how the IBM Security Guardium Key Lifecycle Manager and Gemalto
SafeNet KS servers manages and creates the encryption keys that are used by the DS8000
during encryption group and cloud server connection configuration.

Restriction: As of this writing, IBM Security Guardium Key Lifecycle Manager Container
Edition does not support TCT encryption.

It also describes the major components that are used with TCT encryption and behavior
during normal and abnormal operation.

In the direct key model, a DK is stored on the key server. The DK is created by and registered
on the key server. When the storage device requires the DK for its cryptographic purposes,
the storage device requests the key, and the key server delivers it.

For more information about TCT functions, see IBM DS8000 and Transparent Cloud Tiering
(DS8000 Release 9.1), SG24-8381.

TCT encryption components

The major components for TCT encryption are as follows:
򐂰 Key Manager:
The Key Manager creates and stores the DK with the association to the Device Group.
The DK is an Advanced Encryption Standard (AES) 256 symmetric wrapping key that is
identified by a DS8000 device-specific UUID and is stored in the cache of the encrypting
DS8000 after initial retrieval from Key Manager as well. It wraps the Cloud Encryption Key
(CEK) to obtain Encrypted Cloud Encryption Key (ECEK).
򐂰 DS8000:
The DS8000 stores the DK in the cache and its specific UUID in the KR. It generates and
stores a specific CEK in the Encryption Engine. Consider the following points:
– The CEK is an AES 256 symmetric key that is used to encrypt / decrypt data that is
stored in the cloud and will be destroyed after use and wrapping.
– The UUID is created by manufacturing and is unique for every DS8000. It is stored with
the Cloud Data Object and in the KR of the DS8000. It identifies the DK uniquely on the
key server.
򐂰 Data Object:
The Data Object is the actual data that is stored in the Cloud Data Storage. It includes the
encrypted customer data, the specific UUID from the encrypting DS8000 and the ECEK.
The ECEK is the result of wrapping the CEK with the DK.

56 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
These components are shown in Figure 3-20.

Cloud Encryption Major Components

Key Manager DS8K Cloud Data Storage

Key Store Encryption Data Object

Device Key Engine UUID of DK
UUID
Group Repository
ECEK
CEK
DK UUID !5X p& ^Hi $#)q Encrypted Data

CEK Cloud Encryption Key (CEK) – AES 256 symmetric key used to encrypt /
decrypt data in the cloud. Generated on DS8K. Destroyed after use.
ECEK Encrypted Cloud Encryption Key (ECEK) – The result of wrapping CEK with DK,
stored in the data object in the cloud.
Data Key (DK) – AES 256 symmetric wrapping key. Obtained from Key Server,
DK
identified by UUID, wraps CEK to obtain ECEK.
Universally Unique ID (UUID) – Stored in Cloud Data Object and Key
UUID Repository, identifies DK uniquely on the Key Server.

Figure 3-20 Major components of cloud encryption

Encrypted writes to the cloud

Every encrypted data object write operation to the cloud is handled by the encrypting
DS8000. The DS8000 adds its unique identifier to the data object and encrypts the data with
a new unique CEK every time a write happens. All DKs are stored in the encryption key
managers. The unencrypted CEK is destroyed after use.

Writes for encrypted cloud follow the following high-level write sequence:
1. DS8K sends UUID to the Key Manager and requests a DK.
2. DS8K receives the DK from Key Manager.

Note: Creating the DK occurs when the encryption key group is created, which is a
one-time process. For more information about creating the encryption key group, see IBM
DS8000 and Transparent Cloud Tiering, SG24-8381.

3. DS8K uses a CEK to encrypt data.

4. DS8K wraps the CEK with the DK to obtain the ECEK.
5. DS8K stores its UUID, the ECEK, and the Encrypted Data in the Cloud Storage Object.

Chapter 3. IBM DS8000 encryption mechanisms 57

 The write sequence is shown in Figure 3-21.

Encrypted Writes To the Cloud

DS8K 1
Key Encryption
Repository Engine
UUID1 5 Data Object 1
Key Manager
Clear Text Data1 UUID1 UUID of DK
1 DK DS8k 1 3 5 ECEK1
Key Store AES256 CEK1 ECEK1
4 =/)%$”=)//%§ Encrypted Data 1
Device
Encrypted Data1
Group 2 5
Cloud Storage
DK DS8k 1
DS8K 2
Data Object 2
1 Key Encryption
Repository 5 UUID2 UUID of DK
Engine
UUID2 ECEK2
DK DS8k 2 2
Clear Text Data2 5
!5X p& ^Hi $#) Encrypted Data 2
AES256
DK DS8k 2 3 CEK2 ECEK2
4
Encrypted Data2 5

Figure 3-21 Encrypted writes to the cloud

In addition to the encrypted data, every Data Object in the cloud that is written by a specific
DS8000 includes the unencrypted UUID of the DS8000 and the CEK. This key is encrypted
by the DK that remains in the key server and in the encrypting DS8000.

Encrypted reads from the cloud

A DS8000 that was not the encrypting system might read an encrypted data object from the
cloud. This might happen during normal operations or in a failure scenario where the original
encrypting DS8000 is unavailable at the time of the read request.

The DS8000 with the read request must be part of the encryption environment, with access to
the same key servers that the writing DS8000 had. The reading DS8000 must be able to
obtain the correct wrapping DK from the key server to unwrap the CEK and to decrypt the
data object. It stores the foreign UUID in its own KR and the foreign DK, requested from the
key server during the read request, in the cache. If the UUID of the Data Object read matches
the UUID stored in the KR, the DK is retrieved from Cache if it was initially retrieved from the
key manager.

Reads for encrypted cloud follow this high-level read sequence:

1. DS8K 1 reads in Data Object 2 from Cloud Storage and DS8K 2 reads in Data Object 1
from Cloud Storage.
2. DS8K 1 sends UUID2 to Key Manager and DS8K 2 sends UUID1 to Key Manager.
3. DS8K 1 receives DK DS8k 2 with UUID2 from Key Manager. DS8K 2 receives DK DS8K 1
with UUID1 from Key Manager.
4. DS8K 1 unwraps CEK2 and DS8K 2 unwraps CEK1.
5. DS8K 1 decrypts Encrypted Data 2 and DS8K 2 decrypts Encrypted Data 1.

58 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 The read sequence is shown in Figure 3-22.

Encrypted Reads From the Cloud

DS8K 1 Encryption
UUID2 Engine
2 4 Clear Text Data2 Data Object 2
Key Manager
UUID2 UUID 2
AES256 DK DS8k 2 ECEK CEKCEK2 5
ECEK 2
Key Store Encrypted Data2
Device !5X p& ^Hi $#) Encrypted Data 2
3
Group 1
Cloud Storage
DK DS8k 1
DS8K 2
2 Encryption Data Object 1
UUID1 Engine
UUID1 UUID 1
4
Clear Text Data1 ECEK 1
DK DS8k 2 3
AES256 DK DS8k 1 ECEK CEK 5 =/)%$”=)//%§ Encrypted Data 1

Encrypted Data1

Figure 3-22 Encrypted reads from the cloud

DS8K 2 is now able to read all Data Object encrypted by DS8K 1 and vice versa without an
extra key retrieval from the key server each time.

3.8 DS8000 endpoint encryption key management using KMIP

With DAR encryption, your data is protected when stored on FDE drives. With TCT, your data
is protected when being transferred between the cloud when using TCT. Now with IBM Fibre
Channel Endpoint Security, your data can be protected when transferred between the
DS8900F storage system and an IBM z15.

Starting with DS8000 Release 9.0, you can use IBM Fibre Channel Endpoint Security
encryption to encrypt data as it is transmitted between an IBM z15 Central Processor
Complex (CPC) and the DS8900F. This encryption mechanism also uses external
key servers.

This section describes how the IBM Security Key Guardium Lifecycle Manager manages and
creates the encryption keys that are used by the DS8000 during encryption group and server
connection configuration.

Important: For IBM Fibre Channel Endpoint Security, we recommend IBM Security
Guardium Key Lifecycle Manager Traditional Edition V4.1.0.1 or later. As of this writing,
IBM Security Guardium Key Lifecycle Manager Container Edition does not support IBM
Fibre Channel Endpoint Security.

This section also describes the major components that are used with IBM Fibre Channel
Endpoint Security encryption and behavior during normal and abnormal operations.

Chapter 3. IBM DS8000 encryption mechanisms 59

 For more information about IBM Fibre Channel Endpoint Security encryption functions, see
IBM Fibre Channel Endpoint Security for IBM DS8900F and IBM Z, SG24-8455.

IBM Fibre Channel Endpoint Security encryption components

IBM Fibre Channel Endpoint Security involves three major components:
򐂰 Two endpoint devices:
– A z15, IBM Z CPC, also referred to as the initiator.
– An IBM DS8900F storage system, also referred to as the target.
IBM Fibre Channel Endpoint Security is set up between individual IBM FICON or Fibre
Channel (FC) port pairs of these devices. For FICON, the ports are logically connected
through the definitions in the input/output control data set (IOCDS) of the host system.
IBM Fibre Channel Endpoint Security requires no changes to the IOCDS.
򐂰 An external key manager that maintains the shared secrets that identify the trusted
relationships between endpoint devices.

Figure 3-23 shows the IBM Fibre Channel Endpoint Security infrastructure.

Figure 3-23 Main IBM Fibre Channel Endpoint Security components

External key manager

The external key manager maintains the shared secrets that associate pairs of host and
storage system, or initiators and targets. Such a shared secret is called a Device
Authentication Key (DAK). It is stored securely in the external key manager keystore. To make
sure that a DAK is always available when needed, the external key manager must be
redundant and configured for continuous availability. A Master-Clone setup with daily
replication is not sufficient to handle this.

Important: If IBM Fibre Channel Endpoint Security is in place and enforced, the external
key manager is a crucial component during the start of an IBM Z CPC or any connected
DS8900F storage system. If IBM Fibre Channel Endpoint Security is unavailable, IBM
FICON® connections between host and storage fail to start and data cannot be accessed.

60 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
The endpoint devices retrieve the DAK from the external key manager:
򐂰 When IBM Fibre Channel Endpoint Security is set up for the first time (for example,
at power-up).
򐂰 When the DAK is renewed according to the specified IBM Fibre Channel Endpoint
Security policies.

During normal operation, each endpoint device maintains a copy of the DAK in its local key
manager (LKM) to avoid excessive external key manager traffic.

Note: The LKM function is implemented in the IBM Z firmware.

The external key manager and endpoint devices use the industry-standard KMIP for their
communication. IBM developed an extension to the KMIP protocol that adds support for
peer-to-peer device groups, which you can use to store the trusted association of two devices
(peers). The peers are the IBM Fibre Channel Endpoint Security endpoints, with the IBM Z
system being the owner of the group, and the DS8900F storage system the partner. The FC
worldwide node names (WWNNs) of the endpoint devices are used to provide unique
identification. One such device group is created and maintained by the external key manager
for each IBM Z CPC and DS8900F pair.

Figure 3-24 shows an example with two device groups, which associates an IBM z15 with two
DS8900F systems.

Figure 3-24 Peer-to-peer device group example

The external key manager is composed of the names of the peer-to-peer device groups from
the WWNNs of the peers (endpoint devices) in the group. The device group contains the
security credentials (certificates) that the external key manager needs to communicate with
each of the peers and their common DAK. The peer-to-peer device group and initial DAK are
created on the external key manager automatically at the request of the IBM Z CPC.

Chapter 3. IBM DS8000 encryption mechanisms 61

 When endpoints must retrieve the DAK from the external key manager, they provide the
WWNNs of both peers and identify themselves with their certificate. The external key
manager then pulls the DAK from the matching device group and passes it to the requesting
peer. The device certificates are presented to the external key manager by the HMCs (IBM Z
and DS8900F) on behalf of the initiator and target, respectively. This process is
out-of-band communication.
.

Note: IBM Security Guardium Key Lifecycle Manager that is configured in Multi-Master
mode is the only external key manager solution that is supported for IBM Fibre Channel
Endpoint Security.

Endpoints: IBM Z CPC

Note: An IBM z15 with at least one encryption capable FICON adapter (FICON Express
16SA feature) is required for IBM Fibre Channel Endpoint Security.

From an FC or FICON perspective, the IBM Z CPC is the initiator of all I/O operations and
IBM Fibre Channel Endpoint Security configuration activities. You can configure and enable
IBM Fibre Channel Endpoint Security on an IBM Z CPC when the following requirements
are met:
򐂰 The IBM Fibre Channel Endpoint Security feature is activated.
򐂰 The CP Assist Cryptographic Facility (CPACF) feature is activated (however, the Fibre
Channel Security Endpoint Security feature cannot be ordered without
CPACF enablement).
򐂰 At least one encryption capable FC adapter is installed.

To enable IBM Fibre Channel Endpoint Security for an IBM Z CPC, you must define only the
external key manager (IBM Security Guardium Key Lifecycle Manager) servers IP addresses
or hostnames, and port numbers) in the corresponding configuration window in the IBM Z
HMC. The IBM Fibre Channel Endpoint Security firmware that is running on the IBM Z CPC
performs all the necessary steps to set up secure communication to the external key manager
by using the HMC as the communication gateway and user interface.

The IBM Fibre Channel Endpoint Security firmware in the IBM Z CPC retrieves the DAK from
the external key manager when needed and stores the DAK in the LKM. The local copy of the
DAK is used for normal operations to avoid excessive external key manager traffic. The LKM
uses the DAK in the authentication sequence with target peers and starts a key renewal of the
DAK when it is due.

This part of the IBM Z firmware runs in an encapsulated container to ensure that the secrets it
keeps cannot be compromised, for example, when a dump or trace is generated. It does not
use client memory or processing power because it runs with system internal resources.

Endpoints: IBM DS8900F storage system

Storage systems are targets for I/O operations and IBM Fibre Channel Endpoint Security
configuration requests. A DS8900F receives an IBM Fibre Channel Endpoint Security
configuration request from an IBM Z CPC and acts on it. The DS8900F does not start
endpoint protection on its own.

To support IBM Fibre Channel Endpoint Security, a DS8900F system must access the same
external key manager (IBM Security Guardium Key Lifecycle Manager servers) as the IBM Z
CPC. You can define the IBM Security Guardium Key Lifecycle Manager servers to the
DS8900F through its HMC by using the GUI or DS CLI.

62 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
In addition to providing the IBM Security Guardium Key Lifecycle Manager servers’ IP
addresses and port numbers, you must ensure that the following credentials for secure
communication between DS8900F and IBM Security Guardium Key Lifecycle Manager are in
place:
򐂰 Export communication certificates from the IBM Security Guardium Key Lifecycle Manager
servers and import them to the DS8900F.
򐂰 The factory-installed default communication certificates of a DS8900F or Z CPC are
known and trusted by the IBM Security Guardium Key Lifecycle Manager servers. You do
not have to take any further action if you intend to use those certificates.
򐂰 If you intend to use another certificate, you must install it on the DS8900F and import it to
the IBM Security Guardium Key Lifecycle Manager servers.

Because the WWNNs of the endpoints are used to associate them with each other, you also
must ensure that any certificate you provide for an endpoint contains its WWNN in the
Subject Alternative Name field.

Note: If a DS8900F is configured for another type of encryption (DAR or TCT), the IBM
Security Guardium Key Lifecycle Manager servers also can be used as external key
manager for IBM Fibre Channel Endpoint Security if they meet the IBM Fibre Channel
Endpoint Security requirements.

Similar to the IBM Z CPC, the HMC acts mainly as a user interface and communication
gateway in this case. Communication to the external key manager is started by the DS8900F
server nodes. Both the IBM Z CPC and DS8900F server nodes also have their own LKM to
keep the DAK during normal operations.

After you complete the steps to configure a DS8900F for IBM Fibre Channel Endpoint
Security, it contacts the external key manager and tests whether it can perform all necessary
KMIP operations.

Note: For these tests, the DS8900F creates a special peer-to-peer device group with the
external key manager. In the IBM Security Guardium Key Lifecycle Manager list of device
groups, you can identify it by its name. This name consists of the letter “D”, which is
followed by the DS8900F WWNN (repeated twice), which indicates that it is both the owner
and partner of the group.

Fibre Channel endpoints

Until now, we only looked at the endpoint devices (host and storage) as a whole. However,
IBM Fibre Channel Endpoint Security is a function that protects data flowing between the
following FC port pairs:
򐂰 Host or initiator ports
򐂰 Storage or target ports

The port pairs perform the authentication and encryption set up individually. They
communicate inband over FC and use the IBM Secure Key Exchange (SKE) protocol, which
was developed by IBM based on the industry standard Fibre Channel Security Protocols 2
(FC-SP 2).

Chapter 3. IBM DS8000 encryption mechanisms 63

3.8.1 IBM Fibre Channel Endpoint Security settings and policies
If all hardware and software requirements are met and you successfully defined the external
key manager to both endpoint devices (initiator and target), you can enable IBM Fibre
Channel Endpoint Security on a storage system host adapter (target) port level. A target port
can be configured to one or more initiator ports by the IOCDS. The policy setting affects all
possible connections to this target port from any configured initiator ports. You can set each
port individually to one of the following IBM Fibre Channel Endpoint Security policies:
Disabled The target port does not signal IBM Fibre Channel Endpoint Security
capability to the initiators. Therefore, all attached initiator ports do not
try to set up IBM Fibre Channel Endpoint Security. The FC endpoint
pairs act as if IBM Fibre Channel Endpoint Security did not exist.
Enabled The target port signals IBM Fibre Channel Endpoint Security capability
to the initiators. If an attached initiator port is IBM Fibre Channel
Endpoint Security capable, it tries to set up IBM Fibre Channel
Endpoint Security. However, the port pair can set up a connection,
regardless of whether the authorization succeeds. If a host port is not
IBM Fibre Channel Endpoint Security capable, or if the necessary
connection to IBM Security Guardium Key Lifecycle Manager is not yet
set up, it cannot start the IBM Fibre Channel Endpoint Security
authorization sequence. However, it can connect to the target without
it. This policy is also called Audit Mode because you can use it to
verify the IBM Fibre Channel Endpoint Security configuration without
affecting access to data.
Enforced The target port signals IBM Fibre Channel Endpoint Security capability
to the initiators. If an attached initiator port is IBM Fibre Channel
Endpoint Security-capable, it tries to set up IBM Fibre Channel
Endpoint Security. If the authorization succeeds, the port pair can
connect. If the authorization fails, the port pair cannot set up a
connection. If a host port is not IBM Fibre Channel Endpoint
Security-capable or if the necessary connection to IBM Security
Guardium Key Lifecycle Manager is not yet set up, the connection also
fails.

Whenever you change the IBM Fibre Channel Endpoint Security policy of a target port, this
port goes offline (drop light) and the IBM Fibre Channel Endpoint Security negotiation starts
from the beginning. This way, you can switch IBM Fibre Channel Endpoint Security on and off
while the systems are in operation.

A short period occurs in which the affected port pairs cannot transfer data until the
connections are established again. This interruption is handled by the z/OS Input/Output
Supervisor (IOS) multipathing, and is transparent to the running applications.

Note: For more information about implementation, see IBM Fibre Channel Endpoint
Security for IBM DS8900F and IBM Z, SG24-8455.

64 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 4

Chapter 4. Planning and guidelines for IBM

DS8000 encryption
This chapter describes planning for an IBM DS8000 encryption-capable storage system. It
covers local and external key management.

This chapter includes the following topics:

򐂰 4.1, “About certificates” on page 66
򐂰 4.2, “Planning and implementation process flow” on page 67
򐂰 4.3, “Encryption-capable DS8000 ordering and configuration” on page 68
򐂰 4.4, “Licensing” on page 70
򐂰 4.5, “Advice for external encryption in storage environments” on page 71
򐂰 4.6, “Multiple key managers for redundancy” on page 74

Note: The focus of this chapter is for data-at-rest encryption when IBM Security Guardium
Key Lifecycle Manager is used as the key server. If you use another supported external key
server, see the related vendor documentation.

When applicable, we also indicate differences in terms of planning for local key data-at-rest
encryption (that is, encryption without key servers).

© Copyright IBM Corp. 2014, 2021. All rights reserved. 65

4.1 About certificates

Note: Certificates are important in external key management environments only. They are
unimportant in local key management environments.

The DS8000 with Release 9.2 implemented new security features that must be considered
when you plan to implement disk encryption or migrate an encryption environment in the past.

Early versions of the DS8000 used a GEN 1 certificate. More recent versions used a GEN 2
or GEN 2+ certificate.

Every DS8000 R9.2 system that is shipped from IBM manufacturing features an active GEN
2+ certificate and a dormant GEN 3 certificate. The GEN 1 certificate is no longer supported.
Consider the following points:
򐂰 If you need TLS 1.2 support with DS8000 Release 9.2, you must use or upgrade to IBM
Security Guardium Key Lifecycle Manager V2.6 and later because TLS 1.2 is not
supported by Tivoli Key Lifecycle Manager Version 2.x.
򐂰 If you do not require TLS 1.2, the DS8000 Release 9.2 GEN 2+ certificate can still use
IBM Proprietary Protocol by way of TCP, which is supported by Tivoli Key Lifecycle
Manager Version 2.x. and later.
򐂰 If KMIP in combination with IBM Security Guardium Key Lifecycle Manager is required,
you must upgrade to IBM Security Guardium Key Lifecycle Manager V3.0.0.2 or later.

Release 9.2 of the DS8000 includes a GEN 2+ and a GEN 3 certificate. Consider the
following points:
򐂰 Gen 2+ certificates include 112-bit security strength and were introduced in Release 9.0.
The GEN 2+ certificates meet the requirements of the NIST SP 800-131a: Transitions
Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths.
GEN 2+ certificates are the same as GEN 2 certificates, but include another use of the
Subject Alternative Name field. The use of this field to provide the Fibre Channel (FC)
worldwide node name (WWNN) is standardized. GEN 2+ is the active certificate when the
DS8000 Release 9.2 is shipped.
򐂰 GEN 3 certificates feature 128 - 192-bit security strength. The GEN 3 certificate meets the
requirements of the NIST SP 800-131a beyond the year 2031. It is included with the
DS8000 Release 9.2 system, but is dormant. The IBM Security Guardium Key Lifecycle
Manager V4.1 server automatically trusts the DS8000 GEN 3 certificate.

Careful planning is required when selecting which certificate is used, especially when
migrating an encryption environment.

66 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
4.2 Planning and implementation process flow
Figure 4-1 shows the planning and implementation process for an encryption-capable
DS8000. The details for this process are described in subsequent sections of this chapter.
Figure 4-1 also shows the overall decision flow and outcomes.

Check and
Order DS8000 fulfill
Setup and
with requirements External or
power on the local
encryption for an local
system
feature codes encryption encryption?
system

external Enable local

Check the encryption
system and
enter keys
Recovery N
Key?
Y/N

Y
Create arrays,
N Encryption Y
ranks, pools
Y/N
and volumes.
Create
recovery key.

Disable
encryption /
Remove
encryption Create
key SGKLM
certificates
and keys

Remove
arrays, ranks,
pools and
volumes. Enable Create arrays,
external ranks, pools
encryption and volumes.

Changing
encryption
mode

Normal production

Figure 4-1 Encryption implementation planning flow

Chapter 4. Planning and guidelines for IBM DS8000 encryption 67

4.3 Encryption-capable DS8000 ordering and configuration
To enable encryption on a DS8000 system, the Full Disk Encryption (FDE) feature is required.
All the supported DS8000 models are equipped with FDE drives (hard disk or flash drives)
by default.

4.3.1 Local encryption ordering and configuration

Data-at-rest encryption without external key servers (local encryption) is a chargeable
feature. With the D8000 R9.2, you must order feature code 0405 (Local encryption for
data-at-rest0 during the initial ordering process.

You also must still perform the specific tasks to enable or disable encryption, as described in
7.2, “Implementing local encryption” on page 235.

Country requirements before proceeding with the steps: In specific countries, clients
might be required to sign an Import Agreement to import or export FDE drives.

Complete the following steps:

1. After the ordering and verification process is complete, IBM delivers the DS8000 and the
IBM service representative installs the DS8000.
2. After the storage system is made available to the client, the client must download the
activations keys from the DSFA website and activate them. Encryption is part of the
DS8000 base license since Release 8.0.
3. Enable local data-at-rest encryption. The use of a recovery key is not available. For more
information, see 7.2, “Implementing local encryption” on page 235.

You can now configure pools and assign arrays.

Notes: Consider the following points:

򐂰 All arrays and storage pools on an encryption-capable DS8000 must be configured with
the same encryption group attribute. This option is available when DS CLI is used. (By
default, the GUI creates encrypted storage pools if data-at-rest is enabled.) The first
storage pool or encryption group that is configured determines how the remaining
objects must be configured. A value of zero indicates that encryption is disabled. A
value other than zero indicates that encryption is enabled.
򐂰 To change between encryption-enabled and encryption-disabled, all arrays and storage
pools must be unconfigured. Unconfiguring an encryption-enabled array causes any
data that was stored on the array to be cryptographically erased and later, overwritten
to reinitialize the array.

4.3.2 External encryption ordering and configuration

When you plan to use IBM Security Guardium Key Lifecycle Manager as your external key
server, you must acquire an isolated key server. For more information about the hardware and
operating system requirements, see Detailed system requirements for a specific product.

You must still perform the specific tasks to enable or disable encryption, as described in
Chapter 5, “Implementing IBM DS8000 encryption” on page 75.

68 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 Country requirements before proceeding with the steps: In specific countries, clients
might be required to sign an Import Agreement to import or export FDE drives.

Complete the following steps:

1. After the ordering and verification process is complete, IBM delivers the DS8000 and the
IBM service representative installs the DS8000.
2. After the storage system is made available to the client, the client must download the
activations keys from the DSFA website and activate them. Encryption is part of the
DS8000 base license since Release 8.0.
3. Enable external data-at-rest encryption.
4. For data-at-rest encryption, create a deadlock recovery key (RK) by using the GUI or DS
CLI.
5. Now that the system can be recovered at any time by using the RK, set up the IBM
Security Guardium Key Lifecycle Manager connection and confirm that it is functioning.
After this step is complete, the system is fully enabled and activated for encryption.

You can now configure pools and assign arrays.

Notes: Consider the following points:

򐂰 All arrays and storage pools on an encryption-capable DS8000 must be configured with
the same encryption group attribute. This option is available when DS CLI is used. (By
default, the GUI creates encrypted storage pools if data-at-rest is enabled.) The first
storage pool or encryption group that is configured determines how the remaining
objects must be configured. A value of zero indicates that encryption is disabled. A
value other than zero indicates that encryption is enabled.
򐂰 To change between encryption-enabled and encryption-disabled, all arrays and storage
pools must be unconfigured. Unconfiguring an encryption-enabled array causes any
data that was stored on the array to be cryptographically erased and later, overwritten
to reinitialize the array.

Chapter 4. Planning and guidelines for IBM DS8000 encryption 69

4.4 Licensing
The encryption feature is part of the Base License and is mandatory for every for DS8000.

4.4.1 Local encryption

Although the local encryption does not require a separate license, it does requires the
purchase of a separate Feature Code (405) that can be ordered only for new DS8900F
systems with DS8000 Release 9.2 code. The feature enables the encryption capability for the
DS8000 and potential subsequent capacity upgrades.

4.4.2 External encryption

When ordering the IBM Security Guardium Key Lifecycle Manager, consider the following
points:
򐂰 Number of IBM Security Guardium Key Lifecycle Manager servers per data center
򐂰 Amount of data to be encrypted (if you plan to use data-at-rest encryption)
򐂰 Number of IBM Z servers

Note: In the past, IBM Security Guardium Key Lifecycle Manager was licensed based on
the quantity of drives to be encrypted.

The following components must be ordered:

򐂰 For data-at-rest encryption:
– IBM Security Guardium Key Lifecycle Manager Basic Edition:
• For Master-Clone (one per instance of IBM Security Guardium Key Lifecycle
Manager server and Clone)
• For Multi-Master (one per instance of IBM Security Guardium Key Lifecycle
Manager server)
– IBM Security Guardium Key Lifecycle Manager for RAW Decimal Terabyte Storage
Resource Value Units (RVUs). Quantity = X where X is the RVU calculation. For more
information, see License usage metrics.
򐂰 For IBM Fibre Channel Endpoint Security: IBM Security Guardium Key Lifecycle Manager
Z-platform for KMIP client (one for each IBM Z system)
򐂰 For Transparent Cloud Tiering (TCT): Same as for data-at-rest, based on the raw capacity
of the DS8900F

IBM Security Guardium Key Lifecycle Manager server software entitlements must be
purchased for production and high-availability and disaster recovery environments (HA/DR).
No special licensing is needed for HA/DR. If the data is encrypted and IBM Security
Guardium Key Lifecycle Manager servers the encryption keys, the server must be licensed.

After you license the software, it is available for download through IBM Passport Advantage®.

After the IBM Security Guardium Key Lifecycle Manager software is licensed, it is available for
download through IBM Passport Advantage. For more information about IBM Passport
Advantage, see this web page.

70 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
4.5 Advice for external encryption in storage environments
The following information can help you find the best practices for encryption in storage
environments. It includes key techniques for mitigating the risk of an encryption deadlock.

4.5.1 Using LDAP authentication

Ideally, a best practice is to manage the physical security of access to hardware through an
LDAP implementation. This approach allows a close monitoring of who, when, and what
actions were taken by monitoring the audit logs of the DS8000. With a basic security policy,
having a single person who handles the admin and secadmin role of a DS8000 is still
possible. With LDAP, a policy can be set up that does not allow having the same user ID (UID)
for both roles in the DS8000.

4.5.2 Availability
Consider the following considerations and best practices:
򐂰 DS8000
The DS8000 must be configured with the dual Hardware Management Console (HMC)
option to provide redundant access to the client network. DS8900F is always delivered
with dual HMCs.
򐂰 IBM Security Guardium Key Lifecycle Manager key server:
– Configure redundant key servers to each encrypting storage device. The client must
have independent and redundant key servers on each site.
– To start the IBM Security Guardium Key Lifecycle Manager key server operation after
start without human intervention, the key server must be set up to start automatically
when power is available and to initiate automatically the key server application. The
application must be configured to boot automatically, especially when running the key
server in a virtualized environment.

4.5.3 Encryption deadlock prevention

Consider the following points and best practices:
򐂰 General:
– The change management processes at your installation must cover any procedures
that are necessary to ensure adherence to guidelines that are required to ensure
correct configuration of key servers, encrypted storage, and placement of data that is
related to key servers.
– All personnel who have any of the following assignments or capabilities are required to
review at least annually a client document that describes these risks and the processes
that are adopted to mitigate them:
• Responsibility to implement IBM Security Guardium Key Lifecycle Manager key
servers or encrypted storage products.
• Responsibility to manage the placement or relocation of data that is related to, or
required by, any IBM Security Guardium Key Lifecycle Manager key server.
• Access authority to configure IBM Security Guardium Key Lifecycle Manager key
servers or encrypted storage products.
• Responsibility to rekey the deadlock RK of the DS8000, if used.

Chapter 4. Planning and guidelines for IBM DS8000 encryption 71

 – You must implement automated monitoring of the availability of any equipment that is
associated with management of key services and take appropriate action to keep them
operational. This equipment can include but is not limited to key servers, SNMP
masters, domain name servers, and DS8000 HMCs.
– The client must pay particular attention to disaster recovery plans and scenarios and
consider the availability of key servers, key server backups, and key server
synchronization. A best practice is to establish the independence of each recovery site
from the other recovery sites.
– If the RK management is enabled, the client must have a documented process to
handle and maintain the deadlock RKs of each DS8000 instance. This key is the last
resort to unlock the DS8000 if the IBM Security Guardium Key Lifecycle Manager
environment is destroyed or inaccessible. The deadlock RK is not used while IBM
Security Guardium Key Lifecycle Manager remains available.
򐂰 IBM Security Guardium Key Lifecycle Manager key server:
– Configuration of redundant key servers (at least two) is required. Redundancy implies
independent servers and independent storage devices. For key servers operating in
logical partitions (LPARs), do not use data-sharing techniques that result in one copy of
the data being shared by multiple instances of the key server.
– Configuration of one key server with dedicated hardware and non-encrypted storage
resources at each recovery site is required. The key server is referred to as the isolated
key server.

Note: Consider the following points:

򐂰 The DS8000 requires at least one isolated key server to be configured, but it is a
best practice to use two for redundancy.
򐂰 For TCT encryption and IBM Fibre Channel Endpoint Security encryption, IBM
Security Guardium Key Lifecycle Manager must be set up in a Multi-Master
configuration. This type of configuration requires one IBM Security Guardium
Key Lifecycle Manager license per server.

The objective of this requirement is to avoid encryption deadlock by the following tasks:
• Implementing a key server environment that is independent of all non-key server
applications so that management of the key server can be restricted to those
personnel that are authorized to manage key servers.
• Implementing a key server that is physically and logically isolated from other
applications that might require access to encrypting storage so that the key server
environment does not need to be configured with access to any encrypting storage.
• Implementing a key server that is physically and logically isolated from encrypting
storage so that the risk of storing (initially or through data migration) code and data
objects that are required by the key server on encrypting storage is eliminated.
• Ensuring that a recovery site can operate independently from any other sites by
configuring a key server that is not subject to encryption deadlock because of the
characteristics of an isolated key server.
– Configuration of more key servers on generalized server hardware and generalized
storage is allowed. Be sure to establish the appropriate procedures and controls to
prevent these key servers from having your data access compromised by storing the
data on key server managed encrypting storage. These key servers are referred to as
general key servers.

72 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 – Configuration of key servers at independent sites is a best practice and provides extra
immunity to encryption deadlocks because it reduces the probability that all key
servers experience a simultaneous power loss.
– Clients must ensure that all key servers that a particular storage device is configured to
communicate with have consistent keystore content relative to any wrapping keys that
are used by the storage device. Failure to synchronize the keystores effectively
eliminates one or more key servers from the set of redundant key servers for a storage
device that uses the keys that are not synchronized.
– Clients should back up key server data after it is updated. The backups must not be
stored on encrypted storage media that depends on a key server. For more
information, see 6.1, “Rekeying the data key for data-at-rest encryption” on page 204.
– Clients should periodically audit to ensure that all online and backup data that is
required to make each key server operational is stored on storage or media that does
not depend on a key server to access the data.
– Clients must not delete keys on the key server under normal circumstances. Deletion
of all copies of a key is a cryptographic erase operation of all encrypted data that is
encrypted under this key.
򐂰 DS8000:
– Before any IBM Security Guardium Key Lifecycle Manager server is connected to the
DS8000, run the deadlock RK generation process.
– Suggestion: Manually configure DS8000 devices with the IBM Security Guardium Key
Lifecycle Manager key server. The option to configure them automatically can be used,
but it increases the risk that an unauthorized DS8000 might gain access to a key
server.
– The DS8000 supports up to four IBM Security Guardium Key Lifecycle Manager key
server ports. A requirement is that at least one port is assigned to one isolated key
server.
A best practice is to assign two ports to isolated key servers. Using key servers at the
local site should be preferred to improve reliability.
– When the DS8000 is configured to enable encryption, the DS8000 verifies that at least
two IBM Security Guardium Key Lifecycle Manager key servers are configured and
accessible to the machine.
– The DS8000 rejects the creation of ranks and extent pools with a nonzero encryption
group that is specified if the encryption is not activated.
– The DS8000 monitors all configured IBM Security Guardium Key Lifecycle Manager
key servers. When loss of access to the key servers is detected, notification is provided
through the DS8000 client notification mechanism (SNMP traps, email, or both, when
configured).
Key server-related errors are provided through the same mechanism. Set up monitoring
for these indications and take corrective actions when a condition is detected, which
reflects a degraded key server environment.
The following conditions are monitored and reported:
– If the DS8000 cannot receive a required data key (DK) during power-on for a
configured encryption group from the key servers, it reports the error condition to the
client and to IBM. In this case, logical volumes that are associated with the encryption
group are inaccessible to attached hosts. After reporting the error, if the DS8000 can
get the required DK from a key server, it reports the condition to the client and to IBM
and makes the associated logical volume accessible.

Chapter 4. Planning and guidelines for IBM DS8000 encryption 73

 – DS8000 access to each configured key server is verified at 5-minute intervals. Loss of
access is reported to the client.
– The ability of each key server to unwrap DKs that are configured on the DS8000 is
verified at 8-hour intervals. Loss of the ability to unwrap a configured DK is reported to
the client and to IBM.
– The DS8000 detects if fewer than two key servers are configured, if fewer than two key
servers are available, or if fewer than two key servers can unwrap DKs that are
configured on the DS8000 at 8-hour intervals. If detected, this condition is reported to
the client and to IBM.

4.6 Multiple key managers for redundancy

Whether you use the IBM Security Guardium Key Lifecycle Manager product or any other
supported external key managers, such as the Thales CipherTrust Manager or Gemalto
SafeNet KS, you must be certain that at least one key server always remains available. You
need some redundancy, which can be achieved by deploying multiple key servers:
򐂰 IBM Security Guardium Key Lifecycle Managers
To ensure continuous key and certificate availability to encrypting devices, configure your
IBM Security Guardium Key Lifecycle Manager servers in a Multi-Master setup.
On Microsoft Windows systems and other systems, such as Linux or IBM AIX®, both
computers must have the required memory, speed, and available disk space to handle
the workload.
This setup is not a failover or clustered server from an IBM Security Guardium Key
Lifecycle Manager perspective. The redundancy is managed by setting up multiple key
manager destinations at the DS8000 system.
򐂰 Gemalto SafeNet KS
To ensure continuous key and certificate availability to encrypting devices, configure your
Gemalto Safenet KS servers in a clustered setup.
򐂰 Thales Vormetric Data Security Manager (DSM)
To ensure continuous key and certificate availability to encrypting devices, configure your
Thales Vormetric DSM servers in a clustered setup.
򐂰 Thales CipherTrust Manager
To ensure continuous key and certificate availability to encrypting devices, configure your
Thales CipherTrust Manager servers in a clustered setup.

74 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 5

Chapter 5. Implementing IBM DS8000

encryption
This chapter reviews the sequence of tasks for deployment of an encryption-capable DS8000,
from ordering to installation and use.

This chapter includes the following topics:

򐂰 5.1, “Installing IBM Security Guardium Key Lifecycle Manager V4.x” on page 76
򐂰 5.2, “Migrating IBM Security Guardium Key Lifecycle Manager” on page 77
򐂰 5.3, “Setting up external key managers” on page 77
򐂰 5.4, “Configuring data-at-rest” on page 143
򐂰 5.5, “Configuration for TCT encryption” on page 175
򐂰 5.6, “IBM Fibre Channel Endpoint Security configuration” on page 184
򐂰 5.7, “Data-at-rest encryption and Copy Services functions” on page 190
򐂰 5.8, “NIST SP 800-131a requirements for key servers” on page 190
򐂰 5.9, “Migrating certificates” on page 191
򐂰 5.10, “Using a custom-generated Gen 2 or Gen 3 certificate” on page 200

© Copyright IBM Corp. 2014, 2021. All rights reserved. 75

5.1 Installing IBM Security Guardium Key Lifecycle Manager
V4.x
For more information about installing IBM Security Guardium Key Lifecycle Manager V4.2 or
V4.1, including all prerequisites, see IBM Security Guardium Key Lifecycle Manager,
SG24-8472.

Its bundle includes the following software components:

򐂰 Runtime environment:
– IBM WebSphere Application Server V9.0.5.5
– IBM WebSphere SDK Java Technology Edition V8.0.6.15
򐂰 Database: IBM Db2 Workgroup Server Edition V11.5.4.0
򐂰 IBM Security Guardium Key Lifecycle Manager V4.1

In the IBM Security Guardium Key Lifecycle Manager base architecture, and the WebSphere
Application Server runs a Java virtual machine, which provide the runtime environment. The
application server provides communication security, logging, messaging, and web services.

Db2 stores key materials and other essential IBM Security Guardium Key Lifecycle Manager
information in a relational database. The IBM Security Guardium Key Lifecycle Manager base
architecture is shown in Figure 5-1.

Figure 5-1 IBM Security Guardium Key Lifecycle Manager base architecture

For more information about the IBM Security Guardium Key Lifecycle Manager, see this IBM
Documentation web page.

Note: If you use a fresh installation of IBM Security Guardium Key Lifecycle Manager that
you want to set up, you can ignore 5.2, “Migrating IBM Security Guardium Key Lifecycle
Manager” on page 77.

For more information about configuring IBM Security Guardium Key Lifecycle Manager,
see 5.3.1, “Configuring IBM Security Guardium Key Lifecycle Manager V4.x” on page 77.

76 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
5.2 Migrating IBM Security Guardium Key Lifecycle Manager
IBM Security Guardium Key Lifecycle Manager provides the following mechanisms to migrate
from an older version of IBM Security Key Lifecycle Manager:
򐂰 Inline migration: This process is used when IBM Security Guardium Key Lifecycle
Manager V4.1 is installed on the same machine where an earlier version of IBM Security
Key Lifecycle Manager is installed. Migration does not remove the earlier version of IBM
Security Key Lifecycle Manager.
򐂰 Cross migration: This process is used when IBM Security Guardium Key Lifecycle
Manager V4.1 is installed on a different machine than the earlier version of IBM Security
Key Lifecycle Manager and data is migrated by using migration scripts or the backup and
restore mechanism.

For more information about supported paths, see Chapter 4 in IBM Security Guardium Key
Lifecycle Manager, SG24-8472.

5.3 Setting up external key managers

This section describes setting up external key managers, such as IBM Security Guardium
Key Lifecycle Manager and other external key managers.

5.3.1 Configuring IBM Security Guardium Key Lifecycle Manager V4.x

IBM Security Guardium Key Lifecycle Manager Versions V4.2 and V4.1 for open systems and
Microsoft Windows include all of the features and functions that were supported in IBM Tivoli
Key Lifecycle Manager Version 2.0 for open systems and IBM Security Key Lifecycle Manager
Versions 2.x and 3.x.

Microsoft Windows, Linux, Linux on IBM Z, and IBM AIX operating systems are supported.
Please note that all SKLM/TKLM versions V4.0 and older are meanwhile out of support.

The IBM Security Key Lifecycle Manager for z/OS is a different product that is not described
in this chapter.

The IBM Security Guardium Key Lifecycle Manager security features follow NIST SP
800-131a requirements and maintain compatibility with previous security and encryption
certificates that were used for previous generations of the DS8000 series.

It includes the following enhancements compared to its predecessors:

򐂰 Support for only 64-bit platforms.
򐂰 TLS 1.2 (default) and Elliptic Curve Digital Signature Algorithm (ECDSA) keys and
certificates.
򐂰 Keys and certificates are stored in a database (the name keystore is still used).
򐂰 Simplified installation by using IBM Installation Manager.
򐂰 High availability support by using replication or a Multi-Master cluster.
򐂰 DS8000 Key Management Interoperability Protocol (KMIP) support for data-at-rest (DAR)
encryption, Transparent Cloud Tiering (TCT) encryption, and IBM Fibre Channel Endpoint
Security. For IBM Fibre Channel Endpoint Security encryption, IBM Security Key Lifecycle
Manager Version 3.0.1.3 or later is required.

Chapter 5. Implementing IBM DS8000 encryption 77

 This section describes the procedure to configure IBM Security Guardium Key Lifecycle
Manager to serve keys to an encryption-enabled DS8000. The instructions are based on the
assumption that the IBM Security Guardium Key Lifecycle Manager servers are installed and
ready for configuration. The system clocks of all key servers must be relatively synchronized.

For more information, see this IBM Documentation web page.

Configuring the IBM Security Guardium Key Lifecycle Manager requires several steps to
prepare the key server to serve a DS8000 encryption-enabled disk storage system. The
following benefits are new to this release:
򐂰 Encryption strength of the Rivest-Shamir-Adleman (RSA) algorithm with 2048-bit keys.
򐂰 Support for TLS by using TLS Version 1.2 to encrypt communication between the DS8000
Hardware Management Console (HMC) and IBM Security Guardium Key Lifecycle
Manager.

Attention: For more information about the use of TLS 1.2 with IBM Security Guardium Key
Lifecycle Manager to make it compliant with NIST SP 800-131a, see 5.8, “NIST SP
800-131a requirements for key servers” on page 190. Modify the IBM Security Guardium
Key Lifecycle Manager configuration.

Before you configure devices, such as the DS8000, the IBM Security Guardium Key Lifecycle
Manager requires some initial basic configuration:
򐂰 IBM Security Guardium Key Lifecycle Manager Standalone:
– At least two Key Lifecycle Manager instances are required.
– You must create an TLS/KMIP communication certificate on one instance.
– Keys and certificates must kept in sync between the servers manually by using the
Backup and Restore function.
򐂰 IBM Security Guardium Key Lifecycle Manager Multi-Master:
– You must create TLS/KMIP communication certificates on the primary master.
– Ensure that all other servers that are joining the Multi-Master cluster are clean servers
without any keys or certificates.
– Ensure that the operating system kernel parameters are correctly set. For more
information about other requirements for Multi-Master, see this IBM Documentation
web page.
򐂰 IBM Security Guardium Key Lifecycle Manager Master-Clone Replication:
– You must create TLS/KMIP communication certificates before setting up the
replication cluster.
– You must establish a replication between the IBM Security Guardium Key Lifecycle
Manager servers, or set up a disaster recovery solution through backup and restore.

78 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
Consider the following definitions:
򐂰 TLS/KMIP Certificate: The IBM Security Guardium Key Lifecycle Manager servers and its
devices require a TLS/KMIP certificate for secure communication between the following
entities:
– The servers themselves (when you use replication or in Multi-Master environments).
– The servers and the device, such as the DS8000 HMC. You always must create an
TLS/KMIP certificate. Self-signed and third-party (CA) signed certificates are
supported. The choice is based on the customer’s requirements or policy regarding the
types of certificate and authority.
򐂰 Backup and Restore: The IBM Security Guardium Key Lifecycle Manager creates
cross-platform backup files independently of operating systems and directory structure of
the server. You can restore the backup files to an operating system that is different from
the one it was backed up from. For example, you can restore a backup file that is taken on
a Linux system and restore it on a Windows system. Using backup and restore is not
supported in KMIP environments or when you use TCT encryption.
򐂰 Replication: The DS8000 does not require replication between the IBM Security Guardium
Key Lifecycle Manager servers when you use IBM Proprietary Protocol (IPP) through TLS
for DAR encryption. However, setting it up prepares the servers for future functions, in
which replication is required. Replication is not supported in KMIP environments when you
use TCT, ENDPOINT for encryption of data in flight, or DAR encryption.
򐂰 Multi-Master: The IBM Security Guardium Key Lifecycle Manager instances with
Multi-Master configuration achieve continuous availability of data across multiple IBM
Security Guardium Key Lifecycle Manager deployment environments. This function is
required for a DS8000 R8.5, and later that uses the KMIP protocol for TCT encryption and
encryption of data in flight (ENDPOINT).

Note: Consider that if you move from an older IBM Security Key Lifecycle Manager version
to IBM Security Guardium Key Lifecycle Manager 4.2, you must use the backup and
restore operations for earlier versions of IBM Security Key Lifecycle Manager. Do not
continue with creating certificates after that process is complete.

Creating an TLS/KMIP server certificate

The IBM Security Guardium Key Lifecycle Manager installation secures HTTPS transport with
a self-signed certificate by default. Depending on the browser and version that is used, an
exception might occur. In that case, you must accept the certificate as a trusted certificate by
completing the following steps:
1. Log in to IBM Security Guardium Key Lifecycle Manager (see Figure 5-2 on page 80) at
the following address:
https://<ip address>:<port>/ibm/SKLM/jsp/Main.jsp

Chapter 5. Implementing IBM DS8000 encryption 79

 Figure 5-2 IBM Security Guardium Key Lifecycle Manager login window

Important: IBM Security Guardium Key Lifecycle Manager V4.x uses port 9443 for the
GUI and REST APIs by default.

2. Select Action Items to begin the configuration of IBM Security Guardium Key Lifecycle
Manager. The Action Items menu guides you through the configuration steps.
3. In the Welcome window, select Advanced Configuration → Server certificates, and
then select Add, as shown in Figure 5-3.

Figure 5-3 IBM Security Guardium Key Lifecycle Manager Administer Server Certificates option

You can create a self-signed server certificate (see “Option 1: Creating a self-signed
TLS/KMIP server certificate”) or create a certificate that is signed by a third-party provider
(see “Option 2: Creating a certificate that is signed by a third-party provider” on page 82).

Option 1: Creating a self-signed TLS/KMIP server certificate

This example uses a self-signed certificate. If you use a certificate that is signed by a
third-party provider (that is, a certificate authority [CA]), see “Option 2: Creating a certificate
that is signed by a third-party provider” on page 82.

80 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
Although the use of an existing certificate from the keystore is possible, it is not a best
practice to use the same certificate that encrypts disk data to also protect communication.

Complete the following steps:

1. To create a self-signed SSL certificate, log in to the IBM Security Guardium Key Lifecycle
Manager Server GUI, and select Advanced Configuration → Server Certificates, as
shown in Figure 5-3 on page 80.
2. Enter a certificate label and a certificate description when you create the certificate.
Figure 5-4 shows the TLS/KMIP for Key Serving window under the Advanced
Configuration tab, where you create the certificate. This example is left blank to indicate
that this field must be completed when creating the certificate. The validity period
determines how long the certificate is valid. The RSA algorithm uses the 2048-bit key.

Figure 5-4 TLS/KMIP for Key Serving window

3. After you complete all of the fields, click Add Certificate to create and add the certificate.
Figure 5-5 shows that the SSL certificate is created and recommends a backup.

Figure 5-5 SSL certificate created successfully

Chapter 5. Implementing IBM DS8000 encryption 81

 4. Restart the IBM Security Guardium Key Lifecycle Manager. Select sklmadmin in the
upper right, and then, click Restart Server, as shown in Figure 5-6.

Figure 5-6 Restart Server option

5. See “Exporting the TLS/KMIP server certificate” on page 86.

Option 2: Creating a certificate that is signed by a third-party provider

This example uses a certificate that is signed by a third-party CA.

Although the use of an existing certificate from the keystore is possible, the use of the
certificate that is used to encrypt disk data to protect communication is not a best practice.

To have a certificate that is signed by a third-party CA, it is required to start with a

certificate request.

Note: Multi-layer certificate chains will be officially supported starting with version 9.4. This
feature is not available in earlier versions.

Complete the following steps:

1. To create a third-party signed SSL certificate request, log in to the IBM Security Guardium
Key Lifecycle Manager Server GUI, and select Advanced Configuration → Server
Certificates, as shown in Figure 5-3 on page 80.
2. Select Request certificate from a third-party provider and complete the fields, as
shown in Figure 5-7. Then, click Add Certificate.

82 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 Figure 5-7 Adding certificate from a third party

The certificate request is now active, but the status is Pending (Figure 5-8).

Figure 5-8 Pending certificate

3. The certificate request file is in the directory that is shown in Example 5-1. If you cannot
access your server’s file system, you can download the CSR file from the GUI, as shown in
Figure 5-9. Manually send this certificate request file to a CA and get it signed. You must
import the signed certificate to IBM Security Guardium Key Lifecycle Manager later.

Note: If inline migration is performed on this system, you find the AppServer and
AppServer_1 folders in the /opt/IBM/WebSphere folder, where the AppServer folder is
holding data for the older IBM Security Key Lifecycle Manager server and AppServer_1
holds data for IBM Security Guardium Key Lifecycle Manager V4.1.

Example 5-1 CSR location

[[root@sklmdemo74 data]# cd /opt/IBM/WebSphere/AppServer_1/products/sklm/data

[root@sklmdemo74 data]# ls -l
-rw-r--r--. 1 sklmdb40 sklmdb40 958 Nov 17 22:23 201117224338-sklm_cert_ca.csr
drwx------. 2 sklmdb40 root 6 Nov 12 02:14 agent
drwx------. 2 sklmdb40 root 6 Nov 12 02:14 restore

Chapter 5. Implementing IBM DS8000 encryption 83

 Figure 5-9 Download CSR

4. Transfer the signed TLS/KMIP certificate that returned from the CA to

/opt/IBM/WebSphere/AppServer/products/sklm/data/ and import it by clicking
Third-party certificates pending import under Action Items on the welcome page, as
shown in Figure 5-10 on page 84. If you cannot access the file system of your server, you
can upload the certificate later during the process that is described in Step 7.

Figure 5-10 Welcome page: Third-party certificate pending import

5. On the Import page, select and right-click the pending certificate, and then, select Import,
as shown in Figure 5-11.

Figure 5-11 Selecting the signed certificate for import

6. Browse for the signed certificate if it exists on your server and click Import, as shown in
Figure 5-12. If you need to upload it first, select Upload, browse for your certificate and

84 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
transfer it to the server, as shown in Figure 5-13 on page 85. Then, select and import it as
shown in Figure 5-12.

Figure 5-12 Importing the signed certificate

Figure 5-13 Uploading and importing the signed certificate

After the signed TLS/KMIP certificate is imported, the status of the certificate changes to
valid, as shown in Figure 5-14.

Figure 5-14 Valid certificate

Chapter 5. Implementing IBM DS8000 encryption 85

 7. Restart the IBM Security Guardium Key Lifecycle Manager. Select sklmadmin in the
upper right, and then, click Restart Server, as shown in Figure 5-15.

Figure 5-15 Restart Server option

Exporting the TLS/KMIP server certificate

The TLS/KMIP Server certificate for secure communication between the IBM Security
Guardium Key Lifecycle Manager Server and the DS8000 must be exported to the IBM
Security Guardium Key Lifecycle Manager servers local hard disk drive (HDD) and transferred
to the DS8000 in a later step.

Complete the following steps to export the TLS/KMIP Server certificate:

1. Log in to any IBM Security Guardium Key Lifecycle Manager server as SKLMAdmin and
select Advanced Configuration → Server Certificates, as shown in Figure 5-16.

Figure 5-16 Server Certificates option

2. Highlight the previously created certificate, and then, click the Download icon, as shown
in Figure 5-17.

Figure 5-17 Exporting the certificate

86 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
3. Click Download to download the exported certificate on to your local machine, as shown
in Figure 5-18.

Figure 5-18 Exported certificate download

The TLS/KMIP Certificate is now exported. Transfer it to a destination that is accessible when
activating encryption in the DS8000. The Certificate must be specified during activation to
ensure secure communication between the servers and the DS8000.

Only continue with backup and restore as described in “Backup and restore” on page 87 if
Multi-Master is not to be used. In Multi-Master configurations, the certificate is transferred
automatically to the Standby master when you set it up. Continue to set up a Multi-Master
environment as described in “Setting up a Multi-Master environment with two IBM Security
Guardium Key Lifecycle Manager key servers” on page 98.

The Multi-Master environment can be set up in new environments only.

Backup and restore

The IBM Security Guardium Key Lifecycle Manager creates cross-platform backup files
independently of operating systems and directory structure of the server. You can restore the
backup files to an operating system that is different from the one it was backed up from. For
example, you can restore a backup file that is taken on a Linux system and restore it on a
Windows system.

Important: Using backup and restore is not supported in Multi-Master environments when
you use DAR, ENDPOINT or TCT encryption with KMIP.

Creating a backup
To create a backup, complete the following steps:
1. In the IBM Security Guardium Key Lifecycle Manager GUI, select Administration →
Backup and Restore, as shown in Figure 5-19.

Figure 5-19 Backup and Restore menu

Chapter 5. Implementing IBM DS8000 encryption 87

 2. Under the Backup and Restore tab that is shown in Figure 5-20, click Create to create a
backup.

Figure 5-20 Backup and Restore directory

3. In the Create Backup window that is shown in Figure 5-21, enter a password for the
backup, and then, click Create Backup. This password is required to use the restore
function later.

Figure 5-21 Create Backup window to enter the password and backup description

88 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
4. When you see the “successfully created” notice that is shown in Figure 5-22, click Close.

Figure 5-22 Successful backup confirmation

5. Download the backup to you local machine for further use by clicking the Download
button on the right (see Figure 5-23).

Figure 5-23 Downloading the backup file

Additional Information
Because this server is not a failover or clustered server from an IBM Security Guardium Key
Lifecycle Manager perspective, the redundancy is managed by setting up multiple key
manager destinations at the DS8000. Synchronization is achieved by backing up one server
and restoring the backup configuration on the other server, by setting up remote replication
between the IBM Security Guardium Key Lifecycle Manager Key servers (see “Setting up
remote replication between IBM Security Guardium Key Lifecycle Manager key servers” on
page 93) or by setting up a Multi-Master environment, as shown in “Setting up a Multi-Master
environment with two IBM Security Guardium Key Lifecycle Manager key servers” on
page 98.

Plan to perform this backup or restore process when the following events occur:
򐂰 Initial configuration in non Multi-Master environments
򐂰 Adding keys or devices without synchronization
򐂰 Key or certificate replacement intervals without synchronization
򐂰 CA requests without synchronization

Transfer and restore the previously taken backup to all further IBM Security Guardium Key
Lifecycle Manager Key servers that are installed. Always keep the latest backup in a secure
place, such as off the key server on unencrypted storage.

Chapter 5. Implementing IBM DS8000 encryption 89

 Restoring the backup
To restore the backup, complete the following steps:
1. Log in to the IBM Security Guardium Key Lifecycle Manager and go to Backup and
Restore and then, click Browse to browse for the backup file if it was transferred to the
server, as shown in Figure 5-24. Alternatively, you can upload the backup during this
procedure.

Figure 5-24 Browsing for backup

2. Browse to the directory with the stored backup, as shown in Figure 5-25, and click Select.

Figure 5-25 Browsing to the directory

90 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 If the backup was not yet transferred to the server, you must uploaded it first as shown in
Figure 5-26.

Figure 5-26 Uploading backup

3. Click Display Backups to refresh. The backup appears, as shown in Figure 5-27.

Figure 5-27 Displaying backups

4. Select the backup and click Restore From Backup, as shown in Figure 5-28.

Figure 5-28 Highlight and restore

Chapter 5. Implementing IBM DS8000 encryption 91

 5. Enter the password that is specified during the backup and click Restore Backup, as
shown in Figure 5-35.

Figure 5-29 Password for restoring backup

6. The following dialog must be confirmed by clicking OK:

“The system will be restored from
${SKLM_DATA}\sklm_v4.1.0.1_20210706170957+0200_backup.jar.
the key and configuration data will be restored to the level of the backup that
you select.
Any changes made after the selected backup will be lost, including the
metadata.
After restoring from this backup, the server will be restarted automatically.
The server will not be available during restart process. After the server is
restarted, you must restart the browser session (Log-in again to use the
product user interface).
Do you want to continue?.”
The backup is successfully restored if you receive the message that is shown in
Figure 5-30.

Figure 5-30 Restore successful confirmation

The Security Guardium Key Lifecycle Manager is now set up to serve keys to the DS8000.

92 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
Setting up remote replication between IBM Security Guardium Key
Lifecycle Manager key servers
To set up the IBM Security Guardium Key Lifecycle Manager automated clone replication
process, you must configure the replication parameters for the master and clone servers.

IBM Security Guardium Key Lifecycle Manager provides a set of operations to replicate
current active files and data across systems. This replication enables cloning of IBM Security
Guardium Key Lifecycle Manager environments to multiple servers, independently of
operating systems and directory structure of the server. For example, you can replicate data
from a master server on a Windows system to a clone server on a Linux system.

Configuring a master server

Master server is the primary system that is being replicated. The replication process is
triggered only when the new keys are added to the master server. You can replicate the
master server with a maximum of 20 clone servers. Each clone server is identified through an
IP address or hostname and a port number.

You can also use the IBM Security Guardium Key Lifecycle Manager replication program to
schedule automatic backup operation. You must configure properties only for the master
server to back up data at regular intervals. For more information about automatic backup
operations, see this IBM Documentation web page.

Configuring a clone server

The replication process enables cloning of IBM Security Guardium Key Lifecycle Manager
environments from master server to multiple clone servers. When the replication process is
triggered, the following data is replicated to the clone server:
򐂰 Data in the IBM Security Guardium Key Lifecycle Manager database tables
򐂰 Truststore and keystore with the master key
򐂰 IBM Security Guardium Key Lifecycle Manager configuration files

Specifying replication parameters for a master server

Complete the following steps:
1. Log in to the IBM Security Guardium Key Lifecycle Manager that is going to become your
master key server, and click Administration → Replication, as shown in Figure 5-31.

Figure 5-31 Replication menu

Chapter 5. Implementing IBM DS8000 encryption 93

 2. Change the value for one or more settings of the master server. Select Master and
confirm “Are you sure to set up this IBM Security Guardium Key Lifecycle Manager as
Master?” by clicking OK, as shown in Figure 5-32.

Figure 5-32 Confirming the master

3. Specify the following Basic Properties settings. Then, click OK, as shown in Figure 5-33:
– Select a certificate from the list. The SSL/TLS certificate must exist on the master and
all clone systems that you configure for replication.
– The encryption password for the backup file to ensure data security. You need the
same password to decrypt and restore the file.
– The port number for communication when non-serialized or delayed replications take
place. The default master listen port is 1111.

Figure 5-33 Basic Properties tab (Master)

Note: If you want to set up incremental replication, select the Incremental Replication
option under Advanced Properties.

94 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
Specifying replication parameters for a clone server
Complete the following steps:
1. Log in to the IBM Security Guardium Key Lifecycle Manager that is going to become your
master key server and select Configuration → Replication, as shown in Figure 5-34.

Figure 5-34 Replication menu on the clone machine

2. Select Clone and change the ports under Basic Properties, if required. Click OK, as
shown in Figure 5-35. The default parameters do not need be modified under Advanced
Properties.

Figure 5-35 Basic Properties tab (Clone)

3. Start the replication server as clone. Click Start Replication Server, as shown in
Figure 5-36.

Figure 5-36 Start Replication Server (Clone) option

Chapter 5. Implementing IBM DS8000 encryption 95

 Configuring the clone in the master key server
For replication, one master and at least one clone IBM Security Guardium Key Lifecycle
Manager server must be available. The clones must be known to the master. Complete the
following steps:
1. Log in to the master IBM Security Guardium Key Lifecycle Manager, and click
Administration → Replication → Add Clone, as shown in Figure 5-37.

Figure 5-37 Adding clone

2. Add the fully qualified hostname or IP address of the clone, and click OK, as shown in
Figure 5-38.

Figure 5-38 Inserting IP address and hostname

3. Start the replication server as master. Click Start Replication Server, as shown in
Figure 5-39.

Figure 5-39 Start Replication Server (Master) option

4. Restart the master IBM Security Guardium Key Lifecycle Manager server and then all
clone servers. Then, verify whether the replications service is running. Log in to all IBM
Security Guardium Key Lifecycle Manager servers and look for the replication status in the
lower right, as shown in Figure 5-40 on page 97.

96 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 Figure 5-40 Verifying the replication status

5. Log in again to the IBM Security Guardium Key Lifecycle Manager Replication Master and
perform an initial replication. Select Administration → Replication and then, select
Replicate Now, as shown in Figure 5-41.

Figure 5-41 Selecting the Replicate Now option

6. Confirm the open window by clicking OK, as shown in Figure 5-42.

Figure 5-42 Replication confirmation

Chapter 5. Implementing IBM DS8000 encryption 97

 An information message is displayed, as shown in Figure 5-43.

Figure 5-43 Replication successful

7. Return to the Welcome window and verify the replication status. It displays the last
replication with the current timestamp, as shown in Figure 5-44.

Figure 5-44 Replication status

The IBM Security Guardium Key Lifecycle Manager is now set up for replication. All
configured servers are ready to serve keys.

Setting up a Multi-Master environment with two IBM Security Guardium

Key Lifecycle Manager key servers
In a Multi-Master configuration, all IBM Security Guardium Key Lifecycle Manager instances
in the cluster point to a single data source. This data source is configured for Db2 high
availability disaster recovery (HADR) to ensure real-time availability of latest data to all the
masters in the cluster.

Db2 HADR configuration is used as single data source for all masters in IBM Security
Guardium Key Lifecycle Manager Multi-Master cluster. HADR protects against data loss by
transmitting data changes from a source database, called primary, to a target database,
called the standby. Db2 HADR supports multiple standby databases in your Multi-Master
setup.

98 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 Important: The Multi-Master setup must be performed before any configuration in the IBM
Security Guardium Key Lifecycle Manager servers, immediately after installation and
patching.

A Multi-Master environment is required when you use the KMIP protocol for DAR, TCT, or
ENDPOINT encryption.

You must ensure that your computer hostname is configured correctly before you set up IBM
Security Guardium Key Lifecycle Manager masters for Multi-Master configuration. You can
resolve an IP address to a hostname by editing the /etc/hosts file.

For Db2 HADR configuration, you must update the /etc/hosts file in the primary and all
standby master servers of the cluster to enable host name-to-IP address mapping.

Location of the host file:

򐂰 Windows:
C:\Windows\System32\Drivers\etc\
򐂰 Linux:
/etc/hosts

A correct Linux host file is shown in Example 5-2.

Example 5-2 The /etc/hosts file for Multi-Master

[root@sklma ]# cat /etc/hosts
# 127.0.0.1 sklma
0.00.000.01 sklma
0.00.000.02 sklmb

Nominate one of the IBM Security Guardium Key Lifecycle Manager servers as “Primary
Master” and set up the Multi-Master environment on the primary server. The other IBM
Security Guardium Key Lifecycle Manager servers become “Standby Masters” during the
configuration activity.

Creating a TLS/KMIP certificate on the Primary Master

The IBM Security Guardium Key Lifecycle Manager servers and its devices require a
TLS/KMIP certificate for secure communication between the servers and between the servers
and devices, such as the DS8000 HMC. It is always required that you create a TLS/KMIP
certificate.

Creating a TLS/KMIP certificate for Multi-Master configurations corresponds to the procedure

that is described in “Creating an TLS/KMIP server certificate” on page 79.

Do not transfer the created certificate to any standby master. The Multi-Master
synchronization process ensures that all servers in the environment are running with the
same TLS/KMIP server certificate.

A manual transfer causes the Multi-Master setup to fail. Ensure that the following conditions
are met before starting a Multi-Master cluster.
򐂰 Only the primary server should have a server certificate.
򐂰 Ensure that all other servers that join the Multi-Master cluster are clean without any keys
or certificates.

Chapter 5. Implementing IBM DS8000 encryption 99

 򐂰 Ensure that the operating system kernel parameters are correctly set.

For more information about setting up a Multimaster environment, see the following
resources:
򐂰 This IBM Documentation web page
򐂰 IBM Security Guardium Key Lifecycle Manager, SG24-8472

Adding a standby master to the cluster

An IBM Security Guardium Key Lifecycle Manager high-availability solution is implemented by
using Multi-Master cluster configuration. The cluster must contain a Primary Master and at
least one Standby Master.

The Primary Master was automatically defined in “Creating a TLS/KMIP certificate on the
Primary Master” on page 99.

Complete the following steps to add a Standby Master to the cluster:

1. Log on to the GUI of one IBM Security Guardium Key Lifecycle Manager Primary Master
Server and select Administration → Multi-Master, as shown in Figure 5-45.

Figure 5-45 Multi-Master menu

2. If the IBM Security Guardium Key Lifecycle Manager Multi-Master is not yet configured,
click Multi-Master for configuration, as shown in Figure 5-46.

Figure 5-46 Multi-Master configuration

100 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 A confirmation message appears, as shown in Figure 5-47. The current server
automatically becomes a master.

Figure 5-47 Multi-Master confirmation message

3. By default, Agent is not working; therefore, all protocols show as down. Wait until all
services turn green, which can take up to 15 minutes. Click the green refresh button
periodically to display the current status. After all services are up, click Add Master to
start the cluster creation process, as shown in Figure 5-48.

Figure 5-48 Multi-Master: Add Master

4. In the Basic Properties window that is shown in Figure 5-49 on page 102, specify the
following information for the standby master that you are adding:
– Hostname/IP address
The hostname or IP address of the IBM Security Guardium Key Lifecycle Manager
standby master that is added to the cluster.
– IBM Security Guardium Key Lifecycle Manager Username
The name of the IBM Security Guardium Key Lifecycle Manager administrator. The
administrator name is displayed by default.
– IBM Security Guardium Key Lifecycle Manager Password
The password for the IBM Security Guardium Key Lifecycle Manager server
administrator.
– WebSphere Application Server Username
The WebSphere Application Server login username for the IBM Security Guardium Key
Lifecycle Manager server administrator profile. The WebSphere Application Server
login username is displayed by default.

Chapter 5. Implementing IBM DS8000 encryption 101

 – WebSphere Application Server Password
The password for the WebSphere Application Server login username.
– UI port
The HTTPS port to access IBM Security Guardium Key Lifecycle Manager GUI and
REST services. The port number is displayed by default.

Figure 5-49 Multi-Master - Add Master: Basic Properties

5. Select the Advanced Properties tab, as shown in Figure 5-50.

Figure 5-50 Multi-Master - Add Master: Advanced Properties

102 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 Specify the following information for the standby master:
– Do you want to set this master as standby database?
Select Yes to add the current instance as a standby master to the cluster.
– HADR port
The port number for the standby HADR database to communicate with the primary
HADR database. Keep it at the default.
– Standby priority index
The priority index value for the standby database to take over when the primary
database is down. You can set the priority index to any value 1 - 3. The standby server
with a higher-priority index level (lower number) takes precedence over the
lower-priority databases.
6. Click Check Prerequisite, as shown in Figure 5-51, to test various prerequisites and
communication between the standby master that you are adding and the current primary
master. Click Close on the information message that is shown when all the prerequisites
are met.

Figure 5-51 Check Prerequisites

7. If the prerequisite checking was successful, click Add (as shown in Figure 5-52) to add the
Standby Master to the cluster. Confirm the dialog “Are you sure to add this master to the
multi-master Cluster?” by clicking OK.

Figure 5-52 Add the standby master

The HADR Database is now built across the Masters. This process can take up to
10 minutes to complete. A progress window is displayed, as shown in Figure 5-53.

Figure 5-53 HADR progress

8. A confirmation window opens. After clicking OK, both IBM Security Guardium Key
Lifecycle Manager instances are restarted in the background.
9. Log in to all configured IBM Security Guardium Key Lifecycle Manager servers and verify
the Multi-Master availability. The Welcome window resembles the example that is shown in
Figure 5-54 on page 104.

Chapter 5. Implementing IBM DS8000 encryption 103

 Figure 5-54 Multi-Master status on the welcome window

10.If one of the hosts shows a failed state, which is indicated by a red cross, return to the
Multi-Master configuration window, select the host that shows the red cross, and refresh
its status, as shown in Figure 5-55.

Figure 5-55 Multi-Master detailed status

The IBM Security Guardium Key Lifecycle Manager is now set up as a Multi-Master cluster.
All configured servers in the HADR database are now ready to serve keys.

5.3.2 Configuring Gemalto SafeNet KeySecure platform

Gemalto SafeNet KeySecure (KS) is a third-party centralized key management platform, such
as the IBM Security Guardium Key Lifecycle Manager, that is fully supported by DS8000
Release 8.1 and later.

Gemalto SafeNet KS is available as a hardware and virtual software appliance.

In our scenarios, we used Version 8.3.2 RevA. It supports KMIP Version 1.1 and the IBM
Security Guardium Key Lifecycle Manager does (used with DS8000 Release 8.1 and later),
LDAP and Active Directory authentication, and multiple network management protocols.

Like IBM Security Guardium Key Lifecycle Manager, Gemalto SafeNet KS provides a GUI,
which is named Gemalto SafeNet KS Management Console. It supports 128-bit encryption
and an SSH command-line interface (CLI).

Gemalto SafeNet KS can manage up to 1,000,000 keys and 1,000 devices. It supports the
Hardware Security Module (HSM) to store the master key.

For more information about Gemalto SafeNet KS, see Cloud Protection and Licensing
Solutions.

104 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
This section describes the procedure to configure Gemalto SafeNet KS to serve keys to an
encryption-enabled DS8000. The instructions are based on the assumption that the Gemalto
SafeNet KS servers are installed, clustered, and ready for configuration. The system clocks of
all key server must be relatively synchronized.

Preparation
When using Gemalto SafeNet KS KMIP Compatible Key Servers, KMIP must be configured
with the necessary client certificate authentication policy. Three policies are supported by the
DS8880:
򐂰 Client Certificate Authentication Not Used
Not using Client Certificate Authentication when connecting to the DS8000 is not a best
practice because it does not meet KMIP standards.
򐂰 Client Certificate Authentication used for SSL session only
This policy applies to DS8000 disk storage systems that are included with Release 8.1
and later and to DS8000 disk storage systems that are upgraded from Release 8.0 to
Release 8.1 and later.
򐂰 Client Certificate Authentication for SSL Session and user ID (UID)
This policy applies to DS8000 disk storage systems that are shipped from manufacturing
with Release 8.1 and later. A UID is added to the Gen 2 certificate in the DS8000 by
manufacturing, thus connecting the DS8000 to the KMIP capable key server by using
Client Certificate Authentication for SSL Session and UID. It is the most secure way.

Not using Client Certificate Authentication (policy 1) is not a best practice, so it is not covered
in this paper. Both the Client Certificate Authentication used for SSL session only (policy 2)
and the two-factor authentication by enabling Client Certificate Authentication for SSL and
configuring the username (policy 3) are preferred and covered in this paper.

Policy 2 and 3 prerequisites

Before starting the Gemalto SafeNet KS Configuration, the following prerequisites must be
met:
򐂰 You configured two independent key servers in a cluster.
򐂰 The recovery key (RK) is configured (see “Creating the recovery key” on page 154).
򐂰 The DS8000 certificate is updated from Gen 1 to Gen 2 or Gen 3, as described in
“Migrating certificates” on page 191.
򐂰 The root certificate for DS8000 is downloaded to the client computer from IBM
Documentation.
򐂰 (For Policy 3 only): The Gen 2 or GEN 3 certificate is exported to the client computer to
extract the UID. For more information about how to export it and how to extract the UID
from it, see “Exporting and using DS8000 Encryption Communication Certificate (Gen 2)”
on page 106.

Note: DS8000 Release 8.2 and later features an active Gen 2+ and a dormant GEN 3
certificate from manufacturing by default.

Chapter 5. Implementing IBM DS8000 encryption 105

 Exporting and using DS8000 Encryption Communication Certificate
(Gen 2)
Complete the following steps to export and use DS8000 Encryption Communication
Certificate (Gen 2):
1. To export the GEN 2 or GEN 3 certificate, follow the procedure that is described in
“DS8000 TCT encryption certificate (Gen 2) import (IBM Security Guardium Key Lifecycle
Manager)” on page 178 and return here.
2. Extract the UID field from this certificate.
In UNIX based operating systems, run openssl to extract the UID field from this certificate,
as shown in Example 5-3.

Example 5-3 Extract the UID

[root@sklm-rehl64 tmp]# openssl x509 -in smoker1h_gen2_cert.pem -text | grep
Subject:
Subject: UID=DS8K-2107-75LR811, C=US, O=ibmDisk, CN=2107-75LR811
[root@sklm-rehl64 tmp]#

Important: Save the UID. It is required in a later step.

In Windows, you can use the Certificate Manager to read the UID by completing the
following steps:
a. Run CertManager, as shown in Figure 5-56.

Figure 5-56 Run CertMgr

106 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
b. Click Personal → Certificates and then, click All Tasks → Import, as shown in
Figure 5-57.

Figure 5-57 Import menu

c. Follow the wizard to import the certificate. Be sure to select All Files (*.*) to see the
certificate in .pem format, as shown in Figure 5-58.

Figure 5-58 Selecting All Files (*.*) option

Chapter 5. Implementing IBM DS8000 encryption 107

 The certificate is now imported, as shown in Figure 5-59.

Figure 5-59 Imported certificate

d. Open the certificate, click the Details tab, and then, select Subject. Figure 5-60 shows
the UID.

Figure 5-60 Showing the UID

108 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 Important: Save the UID. It is required in a later step.

You can delete the Gen 2 certificate from the Windows keystore and Windows and UNIX
HDDs now.

DS8000 GEN 2 and GEN 3 root and intermediate certificates

This section describes the DS8000 root GEN 2 and GEN 3 CA certificate and the
intermediate GEN 3 CA certificate

If you do not have access to the IBM Documentation, use the root certificates from
Example 5-4 (Gen 2 root), Example 5-5 (Gen 3 root), and Example 5-6 on page 110 (GEN3
intermediate).

Make sure to copy everything, including -----BEGIN CERTIFICATE----- and -----END

CERTIFICATE-----.

Example 5-4 Gen2 root CA certificate

-----BEGIN CERTIFICATE-----
MIIDHzCCAgegAwIBAgIBADANBgkqhkiG9w0BAQsFADAfMQswCQYDVQQGEwJVUzEQ
MA4GA1UEChMHaWJtRGlzazAeFw0xMjA4MTcwMDM2NTVaFw0zMjA4MTIwMDM2NTVa
MB8xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdpYm1EaXNrMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAptHo9ET6dtKKUqWHzqS0lWJlQI7lKBTn5niD/XwH
mBkZhRWCYkoM/GZvlk4YGvYvoxHmsvuADk0+/Sj2ZqlC0r5mWNdX4xqSuPO7xNT7
jUDt6E/39TpQS+2svseHrO7XCmf9qCncYW29Klyv5UQtvoszOvlGmwlz2WnF7qwu
CiMsqd6WoYsmRgStXGGGCuKHbPMJi7jKBgRf1QKmpIDw1NM/dA4lZElg/Nu+EHKq
KcbKzAcrx4PBY/7rLE9nkpqzzooH5Z/3s5tq7M0gHEuxJD86mLzug9kQ0uP0VP5K
j/0q+/CYVHq0AOwo3KuN8Ft78u2+c21RimoDW3kUhepizQIDAQABo2YwZDAdBgNV
HQ4EFgQUN4o9G4sMHvLCxe3qjGWpB/3CqeQwDgYDVR0PAQH/BAQDAgIEMBIGA1Ud
EwEB/wQIMAYBAf8CAQEwHwYDVR0jBBgwFoAUN4o9G4sMHvLCxe3qjGWpB/3CqeQw
DQYJKoZIhvcNAQELBQADggEBAGq6kM7n7IRVZS32uj1FYuB4PjWTYGRqm7HCYmIX
8zFpszP0Bg9DWbtntQSXrVJV5u8lIyoU3m5ARgGWNKKEttHGLpF2M91ZxkkNyyhu
v1q+bPWt+jv1A7TfnvzxXpTx9jKrkSApuANP5AjMXZzVpem/pVM8DND8GFewSfKc
/CQacdGvE1SuXoaxUNWjC11RErvoEB2ty3B6Sf+snOecnD/iSRvOAR5q/2qY/vIM
7AURXz+XyrB1OLHRKOCHOwY+3AVKcQJU0ulC9/qnof8c1gtKL+mc896vSRsGBaxR
hj8BbJAfD+xMf7Y4Ch9O4fjisSFWL9NX464wIjbaJhdqQWo=
-----END CERTIFICATE-----

Example 5-5 Gen 3 root CA certificate

-----BEGIN CERTIFICATE-----
MIIFvzCCA6egAwIBAgIJAL2EBbsrQpocMA0GCSqGSIb3DQEBDQUAMGsxCzAJBgNV
BAYTAlVTMRAwDgYDVQQIDAdBcml6b25hMQ8wDQYDVQQHDAZUdWNzb24xDDAKBgNV
BAoMA0lCTTEQMA4GA1UECwwHU3RvcmFnZTEZMBcGA1UEAwwQSUJNIERpc2sgUm9v
dCBDQTAeFw0xOTA2MTUwMTUyMTdaFw0zOTA2MTAwMTUyMTdaMGsxCzAJBgNVBAYT
AlVTMRAwDgYDVQQIDAdBcml6b25hMQ8wDQYDVQQHDAZUdWNzb24xDDAKBgNVBAoM
A0lCTTEQMA4GA1UECwwHU3RvcmFnZTEZMBcGA1UEAwwQSUJNIERpc2sgUm9vdCBD
QTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAL2LCj+g1nOZEx43kRmC
/OwYU3WDI7qJ/ZVb+9uogQklKVTbQDED9PAOM5Cjh63EMXmg9XyyrCeOjtZoA/UO
D0NLDWKItEyzTcTDMBlTaaubI5xMlO3NKcj/kAa1MWubf60/ANTrg+MDj+mnSCJf
QVsgcqkm1aqe/VPwrMIsUWDuGn0/9mW+VYVzGj8Mhq7o5gnkkGMxNTqvCwSEHVTg
Q1G2Wo1cg0EN2dtw1ZxukHihsvXHr7NE/uZfewQ9dMsAFn+W/WFszOvwChEmVz2c
OCDgNiYeS799QzC8ihvjB32pZyYAGCTVn0rroyWmI4ODQbNqobaom3UZ4LTW4CIs
+91r626aEKz9c2lqnMssnPUwI7+LI0sXlC3xehGSZgieWyjJSwTEon8ISxbu5grZ
O29m78oSFnELBdFOzi13zzB9sbMR6VSyl6d3qB0APahcKNLkIpnCcyLcIUgrXZFa
kuaMIG0kbEOzH+JK8JCUSfbTZFKVwAwgup5Z/rGW7O8FGTPjv/zFz/ILbXcAljwk

Chapter 5. Implementing IBM DS8000 encryption 109

 2ClTDsDhqX3Gf9hQkCTfk8+QBYvTkF+YTJecFC7NGOnaL8RuCO6Cg/Ve2mmp1H1b
gh+ufQGqT4Q6dPfoO6Bqx75ds28nMwRExAL37QRkrHkGOU2rzMNtJK99cjTVZqHi
nef40/jOn+Fq+d9UR7/qEoY3AgMBAAGjZjBkMB0GA1UdDgQWBBR7YXEATOBNjdDn
rMvp8+yKGQJ9rTAfBgNVHSMEGDAWgBR7YXEATOBNjdDnrMvp8+yKGQJ9rTASBgNV
HRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0BAQ0FAAOC
AgEAIuHBYYcaqe3RQMt/zSawC2tOWP+uo0ev7rEKcvHuxRtDPwxlPeG5xnIwv+ss
jwXzPst8EVY5lXf0h5oGvqt+T2jFK2/uchri8Cml835wxIIzgAFmNSBvvlm9r0Xo
higBcgsEuPP8SjbyS1lUhDpYC8FIxyi1L+4a9N0hi7nul72E6BCrc+qNk/oXpnEN
GnqTQI0EuYN/qEpI8eaCN5MecY/+KLYQMTvFdc/b4l3F6e/1WHP4CMaCSJpLNS55
flYgkW4m4WVFX6Z1RLp8DPJ/n5UYIEFUBxlDAQzpD2bAiLlDwBHgC2CW0QVmDmV+
T13T8lKhZ2NTF2XTDXIGLYSwiSCJBvwv1SCPMN7MsONkifLH75iDAN9PuyIzIfds
gzrKB5Ix+cT60FR2Ah7IXQNFeh7nWvSZVnj1FLVtYOx5gAB5cRcReathGFitXgt/
Q5Gwd0Z9jpUMtQqoUbCvuTEdJl5kI/VWGiPDnW9NO4T4BZKHI7u4IAb2RlBBYhkX
Btd/kaJ01++G+vZ0+hxhj8EbgRIFGzdLeNo+J1LOnGjIwf16KDNuujcGaUAa5HQB
kJ3iEddbVVKyGnzF0mfS+ykOdXUU2JtYsRkY+bwsRdyNyM7T+oHE/MRIqME8Lwos
09iKndrd8NzbcL29FL+PUAKTSKz/wAo/IZUdGXGatBDk0aY=
-----END CERTIFICATE-----

Example 5-6 Gen3 intermediate CA certificate

-----BEGIN CERTIFICATE-----
MIIFsTCCA5mgAwIBAgIENkRWBDANBgkqhkiG9w0BAQ0FADBrMQswCQYDVQQGEwJV
UzEQMA4GA1UECAwHQXJpem9uYTEPMA0GA1UEBwwGVHVjc29uMQwwCgYDVQQKDANJ
Qk0xEDAOBgNVBAsMB1N0b3JhZ2UxGTAXBgNVBAMMEElCTSBEaXNrIFJvb3QgQ0Ew
HhcNMTkwNjE1MDE1ODE2WhcNMzkwNjEwMDE1ODE2WjBiMQswCQYDVQQGEwJVUzEQ
MA4GA1UECAwHQXJpem9uYTEMMAoGA1UECgwDSUJNMRAwDgYDVQQLDAdTdG9yYWdl
MSEwHwYDVQQDDBhJQk0gRGlzayBJbnRlcm1lZGlhdGUgQ0EwggIiMA0GCSqGSIb3
DQEBAQUAA4ICDwAwggIKAoICAQDAwzYUgL8+R1KYR8SDUBwCOw1IcK2LMYHw6uEq
v/PSO4Y1OwwmhM/ukAoSKacAWVH9y0c/ETnpQoksOvJTVf1bWO6N+bKRqrZyQyb9
wibxBevydMe2nLFmnOf/qxQ/gBkPFI6PGBV3XWGphsequsbOlODp0IVxRUxhyhoc
M3EbsxqbRsQjdxxYCekFy6xfizfP7TwC7f4jtoYxGoLHACkHIz2CllZ2HFtzVVfX
6P8qNbz8BlR6DZA+qw1LXCiFgB/6ChvPZ7SZtegwidS/smz5k6z35CLAdplPTf43
sknXFVaOgXR95kDHDsnMwuwSW+G4o5B7n0QOkI2P9BLNYg3VYLbsxOuN9HwgWA/g
NEmf0IwAzLCU+ebS7DAENVxTWi2+kRn5OVZgepT4QeIhWDbMdpNTO1U7d3hqCWZw
LlyUYEP9EIJX+J3Ub4IjfDl8jkOx8MB8xtgngsyYFHedgB87FatjLOZ/X9Hnk0QZ
qkVv3L9gkhR9cgANadans2R2n4K6mG4YudSJjsI1MpkaxvqnNhcWUG9kCqkroteo
zcuxn/8nJQ0CI7/F5kDtTgfmtzSPM0i6+lOH0Lvb6pOScRw+5tm2RVhKk22gvYok
fD8vS/8wJXe3oI/1Nrmew/t7FmLYNiuZlKr0XsRUFJp6j6/wK/LlcOoLlrdW1EkF
N7S8WQIDAQABo2YwZDAdBgNVHQ4EFgQUmxHC4fzLs9VwDzPf3LfNnVUqSO8wHwYD
VR0jBBgwFoAUe2FxAEzgTY3Q56zL6fPsihkCfa0wEgYDVR0TAQH/BAgwBgEB/wIB
ADAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQENBQADggIBADng3Le1irqLI2cq
a1Ht1KXenJXFuPE+fIciLAbnWEITKBNJTRSW05TpVYUdkHMSqedDqkCSS/UiLWkf
WMUD0KQzQPloWW3ifsvO0gZlHDcmeWUdYBhK8Lk5DZ1F7E/YH1PzMWBt+b84OXjP
DGFdYPzyOHXOqPOSecXa8dpylQfj+Oxl18ooKn8bxxYbq/3w9LmHajBCrCUQmvvo
uGGMCUrjDCCH7IiTolyy+xsSuqxk1IXYO10h9A9N/gSx2ze9UCbpwh51SBNAtpVa
5AhiuJBNr44fBMyZZWT4Z+yRRjMPIe0D1tcInaWjKPAcFld5yUxDCYWJwWWrhw8v
PQkQ5VeJo9fB7SnYN73BLwEVewa1KYzNUAk4wIHIhN2LNNMMCCbsRVD7cL0RrINz
Q4pEt4Bm6JVdWK/i8Ky3AIdjjqaPYXN8dvBqMdrLyVhpH5gXUAgv0TG/4aSSuzML
Djft0LPNOSdWfAofeNN03FEQP2wF9m4lbbhgOGjk7yyrwLfvjGQQIfPu1jD2XdYk
P9rQXkm54uU70X9WtqtqmBXz51PjM6+p9bYAw+wqdIQJcqVAWQzFype91fD+wnhb
XXwPG8D7OLTIFJSeB2O9wyYUq7YSWqx5IekYFTYKg0onGGtdTuxGZDAm2O1Vtpqp
+nIykZSkeGQYMfZ9m7BOgz/dVXxV
-----END CERTIFICATE-----

The GEN 2 and GEN 3 root certificates also can be downloaded from this IBM
Documentation web page.

110 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
Configuration

Note: Illustrations in this section are shown courtesy of Thales DIS CPL US, Inc.

Five steps are needed to configure the KMIP server immediately after installation. SSL is
mandatory for KMIP and must be configured.

Complete the following steps:

1. Create a self-signed SSL server certificate, or use a public CA with CSR on every
Gemalto SafeNet KS server.
2. Install the DS8000 root certificate from IBM Documentation.
3. Create a Trusted CA List and add the known CA.
4. Add a KMIP device and edit it.
5. Add a user to key server, based on the UID from the Gen 2 certificate (policy 3 only).

The Gemalto SafeNet KS installation secures HTTPS transport with a self-signed certificate
by default. Depending on the browser and version that is used, an exception can occur. In that
case, you must accept the certificate as a trusted certificate.

Creating a self-signed SSL server certificate

The self-signed SSL server certificate must be created on every Gemalto SafeNet KS server.

Important: SSL server certificates are not replicated between the servers. Every SSL
server certificate must have the exact same name.

Complete the following steps:

1. Log in as Admin to the Gemalto SafeNet KS GUI by pointing your browser to the address
of the key server by using the format https://(ip address>:<ip port>. The default port
is 9443.
2. Select Security → SSL Certificates and create a certificate request, as shown in
Figure 5-61 on page 111.

Figure 5-61 Creating a certificate

Chapter 5. Implementing IBM DS8000 encryption 111

 3. After the SSL certificate is created, select it and click Properties, as shown in Figure 5-62.

Figure 5-62 SSL certificate properties

4. Within the properties, select Create Self-Signed Certificate, as shown in Figure 5-63.

Figure 5-63 Self-sign the certificate

112 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
5. You can modify the certificate duration in days, as shown in Figure 5-64. Although you can
use the system to specify a maximum of 7300 days (20 years), it is advised as a
cryptographic best practice to use smaller durations, such as 365 or 730 days
(1 or 2 years).

Figure 5-64 Maximum certificate duration

The SSL Certificate is now active, as shown in Figure 5-65.

Figure 5-65 SSL Cert Ready

6. Select the self-signed SSL certificate again and select Properties. Then, click Download,
as shown in Figure 5-66.

Figure 5-66 Download the Concurrent Code Load certificate

Chapter 5. Implementing IBM DS8000 encryption 113

 7. Save it to your local HDD and do not rename it, as shown in Figure 5-67.

Figure 5-67 Save the SSL certificate to the hard disk drive

Important: Repeat these steps on all Gemalto SafeNet KS servers.

Installing the DS8000 Gen 2 or GEN 3 root certificate from IBM

Documentation
This section shows how to install the DS8000 root certificate for the Gemalto SafeNet KS key
server cluster. There is only one DS8000 root certificate for all machines in your environment.

From now, all steps can be performed on just one Gemalto SafeNet KS key server,
independently from which one you choose.

Complete the following steps:

1. Still logged in to the Gemalto SafeNet KS GUI, click Security → Known CAs, as shown in
Figure 5-68, paste the certificate text, and click Install. The name should clearly identify
the DS8000 Gen 2 root certificate.

Figure 5-68 Install the DS8000 Gen 2 root certificate

114 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
2. The root certificate is now installed and active. As shown in Figure 5-69, the certificates
must be added to a trusted CA list to be recognized by the KMIP server.

Figure 5-69 Root certificate is now installed

Using a multi-layer certificate chain of trust

In some environments, there might be a requirement to use certificates that are signed by
multiple certificate authorities. This situation is known as a multi-layer certificate chain of trust.

The certificate chain of trust includes a leaf certificate, a set of intermediate CA certificates,
and a root CA certificate.

For successful authentication between the DS8000 and the Gemalto SafeNet KS key server,
the entire chain of trust must be presented to the DS8000. To ensure that condition, proceed
as follows:
1. Configure the Gemalto SafeNet KS key server with the leaf certificate and the set of
intermediate CA certificates.
In the entry box that is displayed as shown in Figure 5-68 on page 114, paste the
certificate chain in PEM format, with the leaf certificate first and then the successive
intermediate CA certificates in descending order.
2. When you configure the key manager on the DS8000, use the root CA certificate as the
key server certificate.

Tip: You can test the chain of trust by using the following command:
openssl s_client -connect key_server_ip_address:key_server_port_number -showcerts

Creating a trusted certificate authority list profile and adding the known
certificate authority
The next step is to create a trusted certificate authority list profile for your environment and
add the previously created known CA to the profile list.

Chapter 5. Implementing IBM DS8000 encryption 115

 Complete the following steps:
1. Still logged in to the Gemalto SafeNet KS GUI, click Security → Trusted CA Lists, as
shown in Figure 5-70, and click Add.

Figure 5-70 Adding a profile

The name should clearly identify the DS8000 profile, as shown in Figure 5-71.

Figure 5-71 Naming the profile

2. The new profile is now in the list of profiles, as shown in Figure 5-72. Select it and open
the properties.

Figure 5-72 Profile properties

116 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
3. In the profile properties, click Edit (see Figure 5-73).

Figure 5-73 Editing the profile

4. Add the previously created DS8000 root CA to the list of trusted CAs and save it, as
shown in Figure 5-74.

Figure 5-74 Adding the DS8000 root CA to the list of trusted CAs

Chapter 5. Implementing IBM DS8000 encryption 117

 Adding a KMIP device to Gemalto SafeNet KeySecure
Now, a KMIP Cryptographic Key Server protocol must be configured in your environment to
serve the keys to the DS8000. Complete the following steps:
1. Still logged in to the Gemalto SafeNet KS GUI, click Device → Key Server and click Add
to create a protocol, as shown in Figure 5-75. One NAE-XML protocol is preconfigured,
which can be ignored.

Figure 5-75 Add KMIP protocol

2. Figure 5-76 on page 118 shows the settings for the KMIP protocol that must be selected:
– Protocol: KMIP.
– IP: All.
– Port: 5696. (This port is the default KMIP port for the DS8000.)
– Use SSL: Select it.
– Server Certificate: Select the Servers SSL certificate that was created in “Creating a
self-signed SSL server certificate” on page 111.

Figure 5-76 Defining KMIP protocol settings

3. The KMIP protocol appears in the list, as shown in Figure 5-77. Select it and
click Properties.

Figure 5-77 KMIP protocol created

118 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
4. In the KMIP Protocol properties, click Edit in the Authentication Settings area, as shown in
Figure 5-78.

Figure 5-78 KMIP Authentication Settings window

5. The Authentication Settings must be modified as follows:

– Password Authentication: “Not Used”.
– Client Certificate Authentication:
• If you have at least one DS8000 that was upgraded from Release 8.0 to release 8.1
in your encryption environment, select Used for SSL session only. DS8000
Release 8.0 systems do not have a UID field in the Gen 2 certificate.
• If you have one or more DS8000 disk storage systems that were delivered with
Release 8.1 or later, select Used for SSL session and username (most secure).
DS8000 Release 8.1 and later systems from manufacturing do have a UID field in
the Gen 2 certificate. However, it is possible to use “Used for SSL session only”.
– Trusted CA List Profile: Select the previously created Trusted CA List Profile.
– Username Field in Client Certificate: Select UID (User ID) for DS8000 disk storage
systems that were delivered with Release 8.1 and None for DS8000 disk storage
systems that were upgraded from Release 8.0 to Release 8.1.
– Require Client Certificate to Contain Source IP: Do not select it.

Chapter 5. Implementing IBM DS8000 encryption 119

 6. A full configured KMIP profile is shown in Figure 5-79. Click Save when you are ready.

Figure 5-79 Configured KMIP profile

120 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 Adding a user to a key server based on the UID from the Gen 2
certificate
The final step is to create a user account for each DS8000 Release 8.1 or later in your
environment that is encrypted.

Complete the following steps:

1. Still logged in to the Gemalto SafeNet KS GUI, click Security → Local Authentication →
Local Users & Groups and click Add to add a user, as shown in Figure 5-80.

Figure 5-80 Adding a DS8000 user

2. The UID equals the UID that was extracted from the DS8000 Gen 2 certificate in “Extract
the UID field from this certificate.” on page 106. In Figure 5-81, the UID is
DS8K-2107-75LR811. Add as many different UIDs as you require in your environment and
click Save. Complete the following fields:
– Password: The password can be anything. The password is not supported by
the DS8000.
– User Administration Permission: Do not check it.
– Change Password Permission: Do not check it.

Figure 5-81 User details

The Gemalto SafeNet KS server is now ready to serve keys to the DS8000.

5.3.3 Configuring Thales Vormetric Data Security Manager

The Thales Vormetric Data Security Manager (DSM) is another third-party external key
manager that is supported for DS8000 DAR encryption and TCT encryption to cloud storage.

For more information, see Vormetric Data Security Manager.

Like IBM Security Guardium Key Lifecycle Manager, Thales Vormetric DSM provides a web
browser-based GUI.

Chapter 5. Implementing IBM DS8000 encryption 121

 This section describes the procedure to configure Thales Vormetric DSM to serve keys to an
encryption-enabled DS8000. The instructions are based on the assumption that the DSM
servers are installed, clustered, and ready for configuration. The system clocks of all key
servers must be synchronized.

Prerequisites
Before starting the Thales Vormetric DSM Configuration, make sure to satisfy the
following prerequisites:
򐂰 Make sure that you configure two or more independent key servers in a cluster, and the
system clocks on the servers are synchronized.
򐂰 Configure the RK (see “Creating the recovery key” on page 154).
򐂰 Client Certificate Authentication for SSL Session and UID only: Export the Gen 2 or Gen 3
certificate to the client computer.

Note: DS8000 Release 8.1 and later features a Gen 2 certificate from manufacturing by
default. DS8900F R9 features a Gen 2+ certificate that is active and a Gen 3 certificate
that is not active.

If you need to use a CA signed certificate, follow instructions in 5.3.4, “Importing the CA
certificate chain into Vormetric DSM” on page 128. This action must be completed before
installing the new certificate on the DS8000.

Preparation steps

Note: Illustrations in this section are shown courtesy of Thales DIS CPL US, Inc.

Start the Thales Vormetric DSM Management console from a web browser and provide your
login and password credentials. In our example in Figure 5-82, we used the ds8000 UID,
which is defined as a DSM administrator.

Figure 5-82 Log on to the Thales Vormetric Data Security Manager Management GUI

You must have a valid license to configure hosts and register agents with a DSM. To register
and configure a DS8000 system, install a license file that contains KMIP agents. Licenses are
provided by the Thales Vormetric DSM customer support and are uploaded to the DSM (see
your DSM documentation on how to obtain a license file).

122 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
Complete the following steps:
1. Upload a license file:
a. Log on to a DSM HA node as a System/All administrator (other administrator types can
view the license in the Management Console, but they cannot upload a license file. In
our example, we defined an administrator that is named ds8000 with the All type.
b. Get a license file from Customer Support.
c. Select System → License in the menu bar. The License window opens, as shown in
Figure 5-83.

Figure 5-83 Installing system licenses

d. Click Upload License File. The Upload License File window opens.
If you are in a domain, Upload License File is disabled. Click Domain → Exit Domain
instead.
e. In the License File dialog box, click Browse to find and select the license file, as
shown in Figure 5-84.

Figure 5-84 Browsing and selecting the license file

f. Click OK.

Chapter 5. Implementing IBM DS8000 encryption 123

 2. Create a domain and enable KMIP:
a. Select Domain → Manage Domains from the menu bar. The Manage Domains
window opens, as shown in Figure 5-85.

Figure 5-85 Managing and creating domains

b. Click Add to open the Add Domains window. In the General tab, complete the details
for the domain. Select Enable KMIP. Click Apply to create the domain, as shown in
Figure 5-86.

Figure 5-86 Add Domain window

c. In the Assign Admin tab, select the administrator account that you created, and then
click Apply, as shown in Figure 5-87.

Figure 5-87 Assigning an administrator to the new domain

124 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 d. In the License tab, complete the KMIP Agent information, and then click OK to return
to the Manage Domain window.

Configuration steps
To configure a DS8000 storage system in Thales Vormetric DSM, log on to the DSM console
as the Security administrator with Host role permissions, a Domain and Security
administrator, or All administrator.

Complete the following steps:

1. Select Domain → Switch Domains from the menu bar to switch to the domain where you
will add the host, as shown in Figure 5-88.

Figure 5-88 Switch Domain option

Make your selection, and then click Switch to domain.

2. Select Hosts → Hosts in the menu bar. The Hosts window opens, as shown in
Figure 5-89.

Figure 5-89 Hosts window

Chapter 5. Implementing IBM DS8000 encryption 125

 3. Click Add to add a host. The Add Host window opens, as shown in Figure 5-90.

Figure 5-90 Add Host window

In the Add Host window, complete the details for the host as follows:
– Hostname
The hostname must match the CN field of the client certificate for the storage system.
You can get the CN field by using the DS8000 DS Command-Line Interface (DS CLI)
showkeygrp command, as shown in Example 5-7.

Example 5-7 Retrieve the CN from the DS8000 certificate

dscli> showkeygrp -certificate 1
Date/Time: December 16, 2020 6:41:16 PM MST IBM DS CLI Version: 7.9.20.181
DS: IBM.2107-75NR641
ID 1
certificate GEN2
version 3
serial number 00:fd:1b:32:f1:35:b3:7c:74
issuer O=ibmDisk,C=US
not valid before 06/26/2019 20:45:19 MST
not valid after 08/11/2032 17:36:55 MST
subject CN=2107-75NR641,O=ibmDisk,C=US,uid=DS8K-2107-75NR641
WWNN OTHERNAME=50:05:07:63:06:FF:C5:DD
size 2048
..
..

– Password Creation Method: Select Generate.

– License Type: Select TERM and KMIP.
– Under Agent Information, select Communication Enabled.
4. Click OK. You are returned to the Hosts window.

126 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
5. You must now import the DS8000 public certificate. From the Host window, click the
hostname for the storage system, which opens the Edit Host window, as shown in
Figure 5-91.

Figure 5-91 Edit Host window

6. Click Import KMIP Cert to import the DS8000 public certificate. The Import KMIP Client
Certificate dialog box opens, as shown in Figure 5-92.

Figure 5-92 Browsing for the DS8000 KMIP communication certificate

7. Click Browse to retrieve the file containing the DS8000 public communication certificate.
Usually, you download the certificate as described in “Prerequisites” on page 122. You
also can retrieve it by running the showkeygrp -certificate 1 command, as shown in
Example 5-7 on page 126.

Chapter 5. Implementing IBM DS8000 encryption 127

 8. Click OK. You return to the Edit Host window, which now shows the Certificate Fingerprint,
as shown in Figure 5-93. The configuration is now complete.

Figure 5-93 Edit Host

5.3.4 Importing the CA certificate chain into Vormetric DSM

This step is required for DSM to trust a Customer Defined Certificate that is installed on the
DS8000. This process must be done first; that is, before the new certificate is installed on the
DS8000.

Complete the following steps:

1. Log in to Vormetric DSM as administrator and Select System → KMIP Trusted CA
Certificates (see Figure 5-94 on page 129).

128 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 Figure 5-94 Selecting KMIP Trusted CA Certificates

2. Browse for the full certificate chain in the CA File Name field and then, click
Import/Update Certificate (see Figure 5-95). The certificates in the certificate chain are
displayed in the table below.

Figure 5-95 Browse certificate chain

Chapter 5. Implementing IBM DS8000 encryption 129

 3. Log in to DSM as DS8000 device administrator (see Figure 5-96).

Figure 5-96 Logging on as DS8000 administrator

4. Select Domains → Switch Domains (see Figure 5-97).

Figure 5-97 Switching domains action

5. Select the ds8000 row and click Switch to domain (see Figure 5-98).

Figure 5-98 Confirming switch to domain

130 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
6. Select Hosts → Hosts (see Figure 5-98).

Figure 5-99 Selecting Host

7. Select the Host Name for which you want to update the certificate (see Figure 5-100).

Figure 5-100 Confirming Host selection

Chapter 5. Implementing IBM DS8000 encryption 131

 8. Click Import KMIP Cert (see Figure 5-101).

Figure 5-101 Importing DS8000 KMIP Certificate

9. Click Browse and select a certificate file; then, select OK (see Figure 5-102).

Figure 5-102 Selecting certificate file

10.The message that is shown in Figure 5-103 is displayed if the process is successful.

Figure 5-103 Certificate import completed message

132 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
5.3.5 Configuring Thales CipherTrust Manager
Thales CipherTrust Manager is a third-party centralized key management platform like IBM
Security Guardium Key Lifecycle Manager that is fully supported by DS8000 Release 9.2 and
later. Thales CipherTrust Manager was formerly known as Next Generation KS.

Thales CipherTrust Manager is available as a hardware or virtual software appliance.

The examples that follow are from Version 2.0, which supports KMIP V1.1 and authentication
by using a local user or LDAP/Active Directory authentication.

Like IBM Security Guardium Key Lifecycle Manager, Thales CipherTrust Manager provides a
web browser-based GUI.

Thales CipherTrust Manager can manage up to 1,000,000 keys and 1,000 devices. It
supports the HSM to store the master key.

For more information about Thales CipherTrust Manager, see CipherTrust Manager.

This section describes the procedure to configure Thales CipherTrust Manager to serve keys
to an encryption-enabled DS8000. The instructions are based on the assumption that the
Thales CipherTrust Manager servers are installed, clustered, and ready for configuration. The
system clocks of all key servers must be synchronized.

Preparation
When using Thales CipherTrust Manager KMIP Compatible Key Servers, KMIP must be
configured with the necessary client certificate authentication policy. The following policies
are supported by the DS8000 R9.2:
򐂰 Client Certificate Authentication that is used for an SSL session only
򐂰 Client Certificate Authentication for SSL Session and UID
A UID is added to the Gen 2 and Gen 3 certificate in the DS8000 by manufacturing, which
connects the DS8000 to the KMIP capable key server by using Client Certificate
Authentication for SSL Session and UID. It is the more secure way.

Both methods are supported and covered in this paper.

Prerequisites
Before starting the Thales CipherTrust Manager Configuration, make sure to satisfy the
following prerequisites:
򐂰 Two independent key servers are configured in a cluster.
򐂰 The RK is configured (see “Creating the recovery key” on page 154).
򐂰 The root certificate for the DS8000 is downloaded to the client computer from IBM
Documentation for the DS8000, as described in 5.9, “Migrating certificates” on page 191.
򐂰 Client Certificate Authentication for SSL Session and UID only: The Gen 2 or Gen 3
certificate is exported to the client computer to extract the UID. For more information about
how to export it and how to extract the UID from it, see “Exporting and using DS8000
Encryption Communication Certificate (Gen 2)” on page 106.

Note: DS8000 Release 8.1 and later features a Gen 2 certificate from manufacturing by
default. DS8000 R9.1 and later features a Gen 2+ certificate that is active and a Gen 3
certificate that is not active.

Chapter 5. Implementing IBM DS8000 encryption 133

 Configuration

Note: Illustrations in this section are shown courtesy of Thales DIS CPL US, Inc.

Multi-layer Certificate Chain of Trust: Establishing a successful Transport Layer Security

(TLS) handshake with a DS8000 requires presenting the entire certificate chain of trust to
the DS8000. This includes both the root and intermediate CA certificates when using the
factory-supplied certificates. If a customer-defined certificate is used, you must add the
entire CA chain of certificates.

Complete the following steps to configure the KMIP server immediately after installation (SSL
is mandatory for KMIP and must be configured):
1. Import and install the DS8000 root and intermediate CA certificates.
2. Create a registration token.
3. Configure the KMIP interface.
4. Obtain the KMIP public certificate to use as a trust anchor when creating the key server on
the DS8000.
5. Create DS8000 users and add them to appropriate groups.
6. Restart the KMIP System service.

Importing and installing the DS8000 root and intermediate CA certificates

For each certificate, complete the following steps:
1. On the Thales CipherTrust Manager home page, click Keys & Access Management (see
Figure 5-104).

Figure 5-104 Select Keys & Access Management option

2. Add the DS8000 root and intermediate CA certificates as external CAs, as shown in
Figure 5-105 on page 135:
a. Click CA to open the Certificate Authorities window.
b. Expand Upload External Certificate.
c. Paste the PEM formatted text from a DS8000 certificate into the text box and
click Upload.
d. Repeat these steps for each DS8000 root and intermediate CA certificate.

134 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 Figure 5-105 Upload the DS8000 certificate

Creating a registration token

Complete the following steps:
1. On the Thales CipherTrust Manager home page, click KMIP (see Figure 5-106).

Figure 5-106 Selecting KMIP option

2. Select Registration Token and then +New Registration Token (see Figure 5-107).

Figure 5-107 New Registration Token

Chapter 5. Implementing IBM DS8000 encryption 135

 3. Follow the wizard and copy the token when the wizard completes (see Figure 5-108).

Figure 5-108 Create New Registration Token wizard

Configuring the KMIP interface

Complete the following steps:
1. In the KMIP Interface Configuration window:
a. On the Thales CipherTrust Manager home page, click Admin Settings (see
Figure 5-109).

Figure 5-109 Selecting Admin Settings option

b. Select System → Interfaces to open the Interface Configurations window.

c. Click the ellipsis icon at the upper right of the KMIP Interface Configuration window and
select Edit (see Figure 5-110 on page 137).

136 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 Figure 5-110 Edit the KMIP Interface

d. Select a DS8000 CA certificate from the External Trusted CAs certificate list or click the
+ icon to upload a new certificate, as shown in Figure 5-111. Repeat for each DS8000
root and intermediate CA certificate.

Figure 5-111 Adding a CA Certificate to the KMIP interface

Chapter 5. Implementing IBM DS8000 encryption 137

 e. Enable Auto Registration and provide a registration token. The token can be created
as described in “Creating a registration token” on page 135.
f. Set Mode to one of the following options:
• TLS, verify client cert, username taken from client cert, auth request is
optional (tls-cert-pw- opt)

Note: The username must match the value that is created in “Creating DS8000
users and adding them to the appropriate groups”.

• TLS, verify client cert, allow anonymous logins (tls-pw-opt) (recommended)

g. If Mode is set to “TLS, verify client cert, username taken from client cert, auth
request is optional”, Set Username Location in Certificate to one of the
following options:
• CN
• UID

Obtaining the KMIP public certificate

Complete the following steps:
1. Go to the KMIP Interface Configuration window:
a. In the Thales CipherTrust Manager home page, click Admin Settings (see
Figure 5-112).

Figure 5-112 Selecting Admin Setting option

b. Click the ellipsis icon at the upper right of the KMIP Interface Configuration window,
and then, select Edit.

138 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 c. Click Download Current Certificate, as shown Figure 5-113.

Figure 5-113 Download Current Certificate

d. Save the file.

This file is used later when creating the key server on the DS8000 system.

Chapter 5. Implementing IBM DS8000 encryption 139

 Creating DS8000 users and adding them to the appropriate groups
Complete the following steps:
1. Create a user:
a. In the Thales CipherTrust Manager home page, click Key and Access Management,
as shown in Figure 5-114.

Figure 5-114 Selecting Key & Access Management option

b. Click Users, and then, click Create New User, as shown in Figure 5-115.

Figure 5-115 Creating a user

140 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 c. Complete the required fields, as shown in Figure 5-116.

Figure 5-116 Create a New User fields

d. Verify the user details in the Users window.

2. Add the user to groups:
a. Click the username (see Figure 5-117).

Figure 5-117 Selecting the username

Chapter 5. Implementing IBM DS8000 encryption 141

 b. Expand Groups, find the group, and click Add (see Figure 5-118).

Figure 5-118 Adding groups to user

Note: The user must be added to a group with permissions to create keys and
perform operations on keys that they own.

c. For DAR, you can use the default Key Users group.
d. For TCT, if there are multiple DS8000 systems that can retrieve an object, the user
should also be a member of a user-defined group, and each key should have the group
added for key sharing.
3. Complete the required fields.

Note: If the KMIP interface mode requires Username taken from client certificate,
the value of the username must match the value of the required field that is contained in
the DS8000 client public certificate.

4. Verify the user details in the Users window.

142 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 Restarting the KMIP system service
Complete the following steps:
1. Select System → Services.
2. A window opens to confirm the KMIP restart. Click Restart kmip (see Figure 5-119).

Figure 5-119 Restarting KMIP

The Thales CipherTrust Manager server is now ready to serve keys to the DS8000 server.

5.4 Configuring data-at-rest

This section describes the following topics:
򐂰 Setting up IBM Security Guardium Key Lifecycle Manager Key management by using IBM
Proprietary Protocol
򐂰 Setting up IBM Security Guardium Key Lifecycle Manager Key management by using
KMIP
򐂰 DS8000 configuration for data-at-rest encryption in DS GUI
򐂰 DS8000 CLI configuration for data-at-rest encryption
򐂰 IBM Security Guardium Key Lifecycle Manager authentication mechanisms

5.4.1 Setting up IBM Security Guardium Key Lifecycle Manager Key

management by using IBM Proprietary Protocol
With the IBM Security Guardium Key Lifecycle Manager key server setup complete, you can
now add the configuration details for DS8000 DAR encryption with IBM Proprietary Protocol
or KMIP, as described in this section. For more information about TCT encryption, see 5.5,
“Configuration for TCT encryption” on page 175. For more information about IBM Fibre
Channel Endpoint Security, see 5.6, “IBM Fibre Channel Endpoint Security configuration” on
page 184.

Chapter 5. Implementing IBM DS8000 encryption 143

 Configuring IBM Security Guardium Key Lifecycle Manager for a
data-at-rest configuration with IBM Proprietary Protocol
Complete the following steps:
1. From the Welcome window, in the Key and Device Management pane, select DS8000.
Then, from the Go to menu, select Guided key and device creation.
These actions provide the guidance for steps that are required to add a storage facility
image that the IBM Security Guardium Key Lifecycle Manager serves. Figure 5-120 shows
these selections.

Figure 5-120 Guided key and device creation for DS8000

2. Click Create to start creating the certificate (see Figure 5-121) that will be associated with
the storage facility image.

Figure 5-121 Creating the DS8000 certificate

144 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
3. After completing the required fields (see Figure 5-122), click
Create Certificate.

Note: Do not confuse this certificate with the one that was created in “Option 1:
Creating a self-signed TLS/KMIP server certificate” on page 80 for
network communication.

Figure 5-122 Create Certificate window to use for the storage facility image

This certificate that is created here is used with the DS8000 storage image to encrypt the
data key (DK). The maximum validity period of a certificate is 9000 days (more than
24 years).
Both self-signed certificates and third-party certificates are supported.
To use a third-party signed SSL certificate, follow the same steps to create the request,
and export and import the signed certificate, as described in “Option 2: Creating a
certificate that is signed by a third-party provider” on page 82, but for the Device
Certificate this time, and not for the SSL / KMIP Server Certificate.

Chapter 5. Implementing IBM DS8000 encryption 145

 After the certificate is created, a warning to create a backup displays (see Figure 5-123).

Figure 5-123 Warning to ensure the creation of a backup

Creating a backup includes the two certificates that were created: one for network
communication and one that is going to be associated with the storage image for DK
encryption. You can wait until after all storage images are defined to create the backup. It
takes about 2 minutes to create the backup, and there is no progress indicator.
4. If you want to create the backup now, click Create a Backup. If the backup is to be created
after the storage images are defined, click Close.
The new certificate is available to associate with the storage image that you define next.
5. Click Go to Next Step at the bottom of the window, as shown in Figure 5-124.

Figure 5-124 Create Certificate window for DS8000 Guided Path

6. In the Step 2: Identify Images window (see Figure 5-125 on page 147), add the storage
image that is to be managed by the key server.
If all the key servers are on the same platform, for example, Linux, only the primary
certificate is used. If the key servers use multiple platforms, the secondary certificate also
is created on the alternative platform.

146 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 Figure 5-125 Adding a storage image

7. Under the Drives section, click Add to define the storage facility image. Enter the storage
image and enter the certificate label that you created. The example in Figure 5-126 shows
the correct format of the information that is required. All DS8000 models use the Storage
Image ID with a 1 at the end (2107-75XXXX1) format for the serial number.

Figure 5-126 Add Storage Image window

Chapter 5. Implementing IBM DS8000 encryption 147

 In that window, if you click Select after the Primary certificate for image field, you see
the window that is shown in Figure 5-127, in which all certificate names are listed.

Figure 5-127 Selecting the primary certificate for image

8. Select the certificate (ds8k_tuc_02 in this example).

After selecting the primary certificate for image, you return to the Add Storage Image
window that is shown in Figure 5-128. Click Add Storage Image to complete the task.

Figure 5-128 Add Storage Image window

148 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
The task to add a storage image is complete, as shown in Figure 5-129.

Figure 5-129 DS8000 machine defined

Verifying the DAR configuration with IBM Proprietary Protocol

Complete the following steps:
1. Verify that the storage image and certificate information are correct. From the Welcome
window, select DS8000 and under Key and Device Management, select Manage keys
and devices, as shown in Figure 5-130. It is a good idea to verify all changes when
adding storage images.

Figure 5-130 Manage keys and devices menu

Chapter 5. Implementing IBM DS8000 encryption 149

 2. Check all the keys and storage images to verify that the information is correct, as shown in
Figure 5-131.

Figure 5-131 Checking the keys and storage images

3. Ensure all modifications made to the SKLM in previous steps are replicated to all
redundant SKLM instances prior to moving on to DS8000 configuration:
򐂰 If Non-Incremental remote replication is enabled, go to the Replication configuration menu
and manually replicate, as described in step 5 on page 95, and wait for replication to
complete prior to configuring DS8000.
򐂰 If Incremental remote replication is enabled, go to the Replication configuration menu and
manually replicate, as described in step 5 in “Creating a backup” on page 87, and wait for
replication to complete prior to configuring DS8000.
򐂰 In Stand Alone with manual replication environments, if no backup was created, create
one now, as described in described in “Backup and restore” on page 87“. Restore the new
backup to all clones prior to configuring DS8000.
򐂰 In Multi-Master environments, the certificate and devices are automatically synchronized.
No action will be necessary to replicate prior to configuring DS8000.

5.4.2 Setting up IBM Security Guardium Key Lifecycle Manager Key

management by using KMIP
If you are using KMIP instead of IBM Proprietary Protocol, no other setup is required in the
IBM Security Guardium Key Lifecycle Manager server. Directly proceed with 5.4.3, “DS8000
configuration for data-at-rest encryption in DS GUI” on page 150.

5.4.3 DS8000 configuration for data-at-rest encryption in DS GUI

This section explains how to configure DAR encryption on the DS8000 by using the
DS GUI and the DS CLI. The high-level configuration sequence includes the following steps
(DS8000 encryption is part of the Base Function license and no longer requires a
license key):
1. Create more storage and security administrator users.
2. Create the RK.
3. Save the RK in a secure location.
4. Enable encryption:
a. If you use IBM Security Guardium Key Lifecycle Manager:
i. Define the key labels (if IBM Proprietary Protocol is used).
ii. Configure the key server connection to the DS8000.

150 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 iii. Authorize the RK.
b. If you use Thales Vormetric DSM or Thales CipherTrust Manager:
i. Configure the key server connection to the DS8000.
ii. Authorize the RK.
5. Configure and administer encrypted arrays, ranks, and storage pools.

For more information about enabling NIST SP 800-131a-compliant encryption certificates and
TLS V1.2 communication, see 5.8, “NIST SP 800-131a requirements for key servers” on
page 190.

Creating storage and security Administrators by using the DS GUI

The DS8000 includes an internal authentication and authorization service that is called the
basic authentication service. This service also provides local user management. With the
DS8000, you also use an external authentication service, such as an LDAP server, but still
use the internal authorization service to grant access to resources as defined by these
DS8000 user group roles:
򐂰 admin
򐂰 secadmin
򐂰 op_storage
򐂰 op_volume
򐂰 op_copy_services
򐂰 service
򐂰 monitor
򐂰 ibm_engineering
򐂰 ibm_service

With the introduction of the encryption RK on DS8000, a dual control security process is
required to prevent unauthorized use of the RK. This dual control process requires two
separate user accounts to process most recovery commands. If these accounts are owned by
two separate people, the RK cannot be used by any one person to gain access to
encrypted data.

The first user role is in the admin user group and is called Storage Administrator. The second
user role, secadmin, is called Security Administrator. Both users are created on the DS8000
by default, and you should assign these roles to two individuals.

To define new UIDs or modify the default usernames, complete the following steps:
1. Sign on to the DS8000 GUI with Storage Administrator or Security Administrator
privileges, depending on which role is needed.
2. From the left pane of the Welcome window, select the User Access icon and then, select
Users, as shown Figure 5-132.

Figure 5-132 Selecting Users option

Chapter 5. Implementing IBM DS8000 encryption 151

 Passwords: The initial admin password is admin and the secadmin password is
secadmin. The first time that you log in, you must change the password. Because these
users are owned by different individuals, the admin and secadmin passwords must not
be stored in one place.

152 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 The list of users that are filtered for admin is shown in Figure 5-133. The full unfiltered list
includes all of the users on the system. The default users are admin and secadmin.

Figure 5-133 User Administration window

3. Click the Add User option to create users (see Figure 5-134).

Figure 5-134 Add User window

A user who has the Security Administrator role cannot have the authority of any other user
role. Also, a user with any other user role cannot have the Security Administrator authority
concurrently. The secadmin user is required to create users with the Security
Administrator authority. All other authorities are disabled if you are logged in as the user
belonging to the secadmin group authority. Any attempt to select any other role results in
an error message, as shown in Figure 5-135 on page 154. The security administrator role
is required for creating the RK.

Chapter 5. Implementing IBM DS8000 encryption 153

 Figure 5-135 Adding a user by using the Security administrator role

4. After you enter the new username, Security Administrator role, and temporary password
and verification, click Add to complete this task.

Creating the recovery key

Whenever an encryption technology is applied, a new type of risk appears: deadlock. This
situation happens, for example, when a DS8000 cannot obtain a required DK from the key
server because no key server can communicate during a restart of the DS8000 system. As a
consequence, all data on the DS8000 becomes inaccessible because the data can no longer
be decrypted without the keys.

The risk of a deadlock can be substantially minimized by maintaining redundant

(dual-platform) key servers, but it cannot be eliminated. The RK feature provides a way to get
out of a deadlocked state.

Without the RK, the DS8000 data becomes unrecoverable if access to the key servers is
permanently lost (typically if the key servers are corrupted and not recoverable).

Note: Creating an RK applies only for DAR encryption. It is not supported by TCT
encryption or IBM Fibre Channel Endpoint Security.

The decision about whether to create the RK must be made at this stage. Creation enables
the RK automatically. If you decide to proceed without creating the RK, you can enable it later.
However, all DS8000 logical configuration, including volumes, ranks, and extent pools, must
be removed (deleted) to do so. The same disruptive process happens if you create the RK
during initial configuration and later decide to disable it.

154 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
Configuring or disabling a RK
Complete the following steps to configure or disable a RK:
1. Log in to the DSGUI as a user with Security Administrator privileges. If the DS8000 does
not have any extent pool that is defined yet, the window that is shown in Figure 5-136
opens in the GUI only. Decide whether to configure or disable it at this stage. If you
configure it, continue with step 2. If you disable it, continue with step 4.

Figure 5-136 Recovery Key decision

2. If the Configure Recovery Key option was selected, the DS8000 automatically generates a
RK. It is displayed as a 64-hexadecimal character key with dashes between every four
characters. The Security Administrator must record and protect this key because there is
no way to view the key from the key server. You can select and copy the key. Click Enable
to continue, as shown in Figure 5-137.

Figure 5-137 Configure Recovery Key (or disable recovery key) window

Saving the key text: The Security Administrator is responsible for recording and
storing the RK in a safe place. This key is critical to recovery of a deadlock condition.
Any person that knows the RK can unlock the DS8000.

Chapter 5. Implementing IBM DS8000 encryption 155

 3. To ensure that the RK was recorded correctly, enter it into the Verify Recovery Key field
(see Figure 5-138) and click Verify. This information also can be pasted into the field.

Figure 5-138 Recovery key verification

After the key is verified, it is still not active because it is waiting for the Storage
Administrator to authorize the newly created RK. At this stage, you can log off as the
Security Administrator user, log back in with the Storage Administrator access and
continue as described in the next section.
4. If the Disable Recovery Key option was selected, the DS8000 automatically disables the
RK. After the key was disabled, the change is still not active because it is waiting for the
Storage Administrator to authorize the disabled RK.
At this stage, you can log off as the Security Administrator user, log back in with the
Storage Administrator access, and continue as described in the next section.

DS8000 enabling data-at-rest encryption

The data that is encrypted within the DS8000 is partitioned in one encryption key group. The
encryption key group that contains encrypted data is enabled to access data through one DK
that is obtained from a key server. After DAR encryption is enabled, all data on the system
is encrypted.

Note: As of this writing, the DS8000 supports only one encryption key group for DAR
encryption. It must be configured for IBM Proprietary Protocol or KMIP. The IBM
Proprietary Protocol is supported by IBM Security Guardium Key Lifecycle Manager key
servers only. Separate encryption key groups are used for TCT and IBM Fibre Channel
Endpoint Security encryption.

Enabling DAR encryption with the IBM Security Guardium Key Lifecycle Manager by using
KMIP requires a Multi-Master configuration of the key server. The key servers do not require
any other configuration to serve keys to the DS8000.

KMIP has been supported starting with DS8000 Release 8.5 and IBM Security Key Lifecycle
Manager V3.0.0.2.

156 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
To configure the DS8000, complete the following steps:

Note: Some figures in this section might not reflect the latest DS GUI version. However,
the process that is described here remains the same.

1. After the RK is created, log on to the DS8000 GUI as a user with Administrator role to
enable the encryption and authorize the previously generated RK. From the DS8000 GUI
Welcome window, click Settings and then, Security, as shown in Figure 5-139.

Figure 5-139 Go to the Encryption window

2. The encryption wizard is shown in Figure 5-140. This wizard is started only when you
enable the encryption for the first time. Click Enable Encryption to continue.

Figure 5-140 Encryption wizard: Enable Encryption

The Welcome window opens (see Figure 5-141 on page 158). Prerequisites for the next
steps are that at least two key servers must be configured and online and connected to the
DS8000. Click Next to continue.

Note: SKLM was renamed GKLM since the DS8000 Release 9.2 DSGUI.

Chapter 5. Implementing IBM DS8000 encryption 157

 Figure 5-141 Encryption wizard: Welcome window

3. Select the Key Server Type depending on the setup:

– Select IBM GKLM (TLS) to use TLS port 1441 to communicate with IBM Security
Guardium Key Lifecycle Manager if IBM Proprietary Protocol is used.
– If KMIP is used, select KMIP Compatible (TLS), as shown in Figure 5-142. It is the
default selection.

Figure 5-142 Type selection

158 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 Note: If you select IBM GKLM as Key Server Type, the default port number for the key
servers is set to 3801. Port 3801 is the default IBM Proprietary Protocol TCP port for
IBM Security Guardium Key Lifecycle Manager; it is not secured by TLS and therefore
not recommended.

However, if you choose that option instead of TLS at your own risk, you must not
provide key server certificates as part of key server configuration.

If you select Key Server Type IBM GKLM (TLS), the key servers’ port will be set to 441
and you must update it with port 1441. You also must provide key server certificates,
even if you change the key server port number to the IBM Proprietary Protocol TCP
port of the IBM Security Guardium Key Lifecycle Manager, which defaults to 3801, as
shown in Figure 5-143.

If your key server port number is the IBM Proprietary Protocol TCP port of the IBM
Security Guardium Key Lifecycle Manager and you configured a certificate when
creating the key server object, key server communication fail because the IBM Security
Guardium Key Lifecycle Manager is communicating through TCP and the DS8000 is
communicating by using TLS. This situation results in errors during encryption
enablement.

Figure 5-143 shows the default ports as displayed in the IBM Security Guardium Key
Lifecycle Manager GUI Welcome window.

Figure 5-143 Default ports in IBM Security Guardium Key Lifecycle Manager

4. Configure the key servers. The DS8000 supports up to four key servers. Consider the
following points regarding multiple- and single-site configurations:
– In multiple site configurations, at least two of the key server ports should be assigned
to isolated key servers at separate physical sites. The remaining ports can be
connected to general key servers.
– In single-site configurations, at least two of the key server ports should be assigned to
isolated key servers at the same site.
The DS8000 configuration for encryption also requires that at least two active key servers
be connected and defined at the DS8000 instance.
The DS8000 monitors all configured key servers. Client notification is provided for loss of
access to key servers and other key server-related errors through DS8000 client
notification mechanisms (SNMP traps and email, if configured) in the following ways:
– Loss of access to key servers is reported at 5-minute intervals.
– Loss of the ability for at least two key servers to provide key services that can prevent
access to the data on the DS8000 is reported at 8-hour intervals.
– The inability of any one key server to provide key services that can prevent access to
data on the DS8000 is also reported at 8-hour intervals.

Chapter 5. Implementing IBM DS8000 encryption 159

 In Figure 5-144, two key servers are defined. You can add up to four or remove key
servers by clicking the + or - sign next to each key server field. Specify the host address
(IP address or full qualified hostname of the key server). Click Next.

Figure 5-144 Encryption wizard: Define key servers

5. Each key server connection is tested. The message that is shown in Figure 5-145 is
displayed if all the key servers that you defined are accessible. Click OK.

Note: The ports also can be changed and must match the setting on the IBM Security
Guardium Key Lifecycle Manager key server.

Figure 5-145 Encryption wizard: Test Key Servers

6. If the setup is using IBM Proprietary Protocol, continue with step 7. If KMIP is used,
continue with step 8.

160 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
7. Define the key label for the DK that is generated by the IBM Security Guardium Key
Lifecycle Manager server during the certificate creation step on the IBM Security
Guardium Key Lifecycle Manager server. (It is not required when the KMIP protocol is
used.)
This key label must match the label that is defined as described in 5.4.1, “Setting up IBM
Security Guardium Key Lifecycle Manager Key management by using IBM Proprietary
Protocol” on page 143. In this example, this key label is named ds8900_cert.
Only one key label is required when all of the IBM Security Guardium Key Lifecycle
Manager key servers are installed on the open systems platforms with the same keystore
type. A dual key label option is applicable only if at least one IBM Security Guardium Key
Lifecycle Manager key server is installed on an IBM System z® server (z/OS) and the
other on the open systems platform because of the different keystore type that is used on
IBM Z servers. In addition, the IBM Security Guardium Key Lifecycle Manager on IBM Z
does not support TCT encryption.
As shown in Figure 5-146, only one label is defined because all IBM Security Guardium
Key Lifecycle Manager key servers are installed on the same platform with the same
keystore type. Click the + sign to add a key label for the dual platform support. You can
add the key label even after the encryption is enabled.

Figure 5-146 Defining the key label

You can continue by using the encryption wizard, although the key label that you provided
does not match the key label that you specified in the IBM Security Guardium Key
Lifecycle Manager server. The label verification is done as the last step of the encryption
enablement process. Click Next to continue.

Chapter 5. Implementing IBM DS8000 encryption 161

 8. Transfer the SSL certificates from the key servers to the DS8000 server, as shown in
Figure 5-147 and Figure 5-148. The System defined (GEN2) certificate that was created
in step 2 does not need to be exported. This certificate is known in the IBM Security
Guardium Key Lifecycle Manager.

Figure 5-147 Transfer the SSL certificates to a DS8000 server: Step 1

Figure 5-148 Transfer the SSL certificates to a DS8000 server: Step 2

162 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 Exporting the SSL certificates is described in “Exporting the TLS/KMIP server certificate”
on page 86 for IBM Security Guardium Key Lifecycle Manager, “Creating a self-signed
SSL server certificate” on page 111 for Thales Vormetric DSM, and “Obtaining the KMIP
public certificate” on page 138 for Thales CipherTrust Manager.
9. Authorize the pending request for the RK from the Security Administrator (if not done yet).
Click Authorize, as shown in Figure 5-149.

Figure 5-149 Authorizing the recovery key

10.The confirmation message window opens (see Figure 5-150). Click Yes to continue.

Figure 5-150 Confirming recovery key authorization

Chapter 5. Implementing IBM DS8000 encryption 163

 The RK state changes to Configured when the RK authorization is confirmed (see
Figure 5-151). If the RK is disabled, the state shows as disabled.

Figure 5-151 Recovery key configured

11.Figure 5-152 shows a summary of the configuration. Click Finish to start all of the tasks
that are required to enable the encryption.

Figure 5-152 Summary window

12.Encryption enablement tasks take approximately 1 minute. Expand the View more details
section to see the task list. The overall progress is displayed as a percentage. When the
completed message displays, click Close.

164 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 In the Encryption window (see Figure 5-153), the encryption state is Enabled and the
encryption key is Accessible. By expanding each section, you get more information. In this
example, one key label exists and in this case, two key servers that are accessible and online.

Figure 5-153 Encryption enabled and accessible

The overall process to enable encryption on a DS8000 by using the GUI interface is simple. It
takes approximately 5 minutes to complete all these steps. Now, you are ready for logical
configuration, that is, create ranks, extent pools, and volumes. When you create the extent
pools, you cannot disable the encryption unless you delete all the volumes, ranks, and
extent pools.

There are a few options that are available to manage the encryption environment. You can
rekey the DK and RK. For more information, see 6.1, “Rekeying the data key for data-at-rest
encryption” on page 204 and 6.2, “Recovery key usage and maintenance” on page 212.

5.4.4 DS8000 CLI configuration for data-at-rest encryption

You can configure DAR on the DS8000 server by using the DS CLI. The high-level
configuration sequence includes the following steps:
1. Enable the RK (for DAR encryption only).
2. Configure the Key Manager server connection to the DS8000.
3. Configure the encryption key group.
4. Configure and administer the encrypted storage pools and assign arrays.

For more information about enabling NIST SP 800-131a compliant encryption certificates and
TLS 1.2 communication, see 5.8, “NIST SP 800-131a requirements for key servers” on
page 190.

For more information about the CLI and commands, see IBM DS8000 Series Command-Line
Interface User's Guide, SC27-9562.

Chapter 5. Implementing IBM DS8000 encryption 165

 Enabling the recovery key for data-at-rest encryption

Note: Creating and managing an RK applies to DAR encryption only.

As described in “Creating the recovery key” on page 154, the risk of a deadlock situation can
be substantially minimized by maintaining redundant (dual-platform) IBM Security Guardium
Key Lifecycle Manager servers for DAR encryption, but it cannot be eliminated.

The RK feature for DAR encryption provides a way to get out of a deadlock state.

You can enable or disable RK management. This choice must be made before you configure
any encryption key group.

The encryption key group and recovery key start in the unconfigured state. See Example 5-8.

Example 5-8 lskeygrp command

dscli> lskeygrp -l 1
ID state reckeystate reckeydate datakeydate grpstatus mgrstatus label label2
keyprotocol type name
----------------------------------------------------------------------------------
1 unconfigured unconfigured - - - - - - -
- N/A

To configure the RK by using CLI commands, complete the following steps:

1. The CLI command that is used to configure the RK must be entered by a user with
Security Administrator (secadmin) authority. Run the mkreckey command, as shown in
Example 5-9.

Example 5-9 Configuring the recovery key by using the mkreckey command
dscli> mkreckey –dev IBM.2107-75xxxx1 1
-----------------------------------------------------------------------------------
CMUC00392I mkreckey: The access Recovery Key
0123-4569-4443-3334-3334-0123-4569-3334-4443-3334-3334-0123-4569-4443-3334-3334 for
encryption group 1 has been created, pending verification.

dscli> lskeygrp -l 1
ID state reckeystate reckeydate datakeydate grpstatus mgrstatus label label2
keyprotocol type name
----------------------------------------------------------------------------------------
1 unconfigured newkeyveripend - - - - - -
- - N/A

You can copy the new RK text from the terminal and save it in a file, which can be used for
printing. However, this approach is not preferable because the key can be discovered by a
network sniffer. A better approach is to write the key on a piece of paper.
The Security Administrator is responsible for writing the RK and storing the paper in a
safe place.
2. The secadmin runs the managereckey -action verify command to ensure that the written
key is correct, as shown in Example 5-10.

Example 5-10 Verifying the recovery key

dscli> managereckey –dev IBM.2107-75xxxx1 –action verify - key
0123-4569-4443-3334-3334-0123-4569-3334-4443-3334-3334-0123-4569-4443-3334-3334 1
---------------------------------------------------------------------------------

166 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 CMUC00393I managereckey: The access Recovery Key for encryption group 1 has been
verified, pending authorization.

dscli> lskeygrp -l 1
ID state reckeystate reckeydate datakeydate grpstatus mgrstatus label label2
keyprotocol type name
----------------------------------------------------------------------------------
1 unconfigured newkeyauthpend - - - - - -
- - N/A

The RK is now in the Authorization Pending status.

3. After the RK is verified, the Storage Administrator authorizes usage of the RK that was
created. You must log on as a user with Storage Administrator authority to run the
managereckey -action authorize command, as shown in Example 5-11.

Example 5-11 Authorizing the recovery key

dscli> managereckey –dev IBM.2107-75xxxx1 –action authorize 1
CMUC00406W managereckey: Are you sure that you want to authorize the creation of the
access Recovery Key for encryption group 1? [Y/N]:Y
-------------------------------------------------------------------------------------
CMUC00395I managereckey: The pending Recovery Key management operation for encryption
group 1 has been authorized.

dscli> lskeygrp -l 1
ID state reckeystate reckeydate datakeydate grpstatus mgrstatus label label2
keyprotocol type name
-------------------------------------------------------------------------------
1 unconfigured configured 02/05/2024 - - - - - -
- N/A

To disable the RK by using CLI commands, complete the following steps:

1. The CLI command that is used to disable the RK must be entered by a user with Security
Administrator (secadmin) authority. Run the managereckey command, as shown in
Example 5-12.

Example 5-12 Disabling the recovery key

dscli> managereckey -action disable 1
---------------------------------------------------------------------
CMUC00416I managereckey: The access recovery key for key group 1 has been
disabled, pending authorization.

dscli> lskeygrp -l 1
ID state reckeystate reckeydate datakeydate grpstatus mgrstatus
label label2 keyprotocol type name
----------------------------------------------------------------------------
1 unconfigured disableauthpend - - - - -
- - - N/A

2. After the RK is disabled, the Storage Administrator authorizes the disabled RK. You must
log on as a user with Storage Administrator authority to run the managereckey -action
authorize command, as shown in Example 5-13.

Example 5-13 Authorizing the disabled recovery key

dscli> managereckey -action authorize 1

Chapter 5. Implementing IBM DS8000 encryption 167

 CMUC00418W managereckey: Are you sure that you want to authorize the disable of
the access recovery key for key group 1? [Y/N]: y
CMUC00395I managereckey: The pending recovery key management operation for key
group 1 has been authorized.

dscli> lskeygrp -l 1
ID state reckeystate reckeydate datakeydate grpstatus mgrstatus label
label2 keyprotocol type name

-------------------------------------------------------------------------------
1 unconfigured disabled - - - - - -
- - N/A

To enable the RK by using CLI commands, complete the following steps. The encryption key
group must be in the unconfigured state to enable the RK.
1. The CLI command used to enable the RK must be entered by a user with Security
Administrator (secadmin) authority. Run the managerekey command, as shown in Example
5-14.

Example 5-14 Enabling the recovery key

dscli> managereckey -action enable 1
CMUC00415I managereckey: The access recovery key for key group 1 has been
enabled, pending authorization.

dscli> lskeygrp -l 1
ID state reckeystate reckeydate datakeydate grpstatus mgrstatus
label label2 keyprotocol type name

-------------------------------------------------------------------------------
1 unconfigured enableauthpend - - - - -
- - - N/A

2. After the RK is requested to be enabled, the Storage Administrator authorizes the enabled
RK. You must log on as a user with Storage Administrator authority to run the
managereckey -action authorize command, as shown in Example 5-15.

Example 5-15 Authorizing enablement of the recovery key

dscli> managereckey -action authorize 1
CMUC00417W managereckey: Are you sure that you want to authorize the enable of
the access recovery key for key group 1? [Y/N]: y
CMUC00395I managereckey: The pending recovery key management operation for key
group 1 has been authorized.

dscli> lskeygrp -l 1
ID state reckeystate reckeydate datakeydate grpstatus mgrstatus label
label2 keyprotocol type name
-------------------------------------------------------------------------------
---------------------------
1 unconfigured unconfigured - - - - -
- - - N/A
....

168 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
Configuring the key server connection
The DS8000 supports up to four Key Manager Server connections per encryption key group.
However, only one encryption key group (encryption key group 1) is available for
DAR encryption.

An intermixing between different sorts of key servers connections is not allowed. KMIP and
IBM Proprietary Protocol protocols also cannot be intermixed for DAR encryption.

Having an IBM Proprietary Protocol DAR key group and KMIP for the key group for TCT
encryption or IBM Fibre Channel Endpoint Security in parallel is allowed when you use
IBM Security Guardium Key Lifecycle Manager for the key servers.

The following suggestions apply to configurations per encryption key group:

򐂰 In multiple site configurations, at least two of the key server ports should be assigned to
isolated key servers at separate physical sites. The remaining ports can be connected to
general key servers.
򐂰 In single-site configurations, at least two of the key server ports should be assigned to
isolated key servers at the same site.

The DS8000 configuration for encryption also requires that at least two active key servers be
connected and defined at the DS8000 installation. The following configuration describes how
to connect the key servers by using these port assignments:
򐂰 SSL/TLS port 1441 for IBM Security Guardium Key Lifecycle Manager
򐂰 KMIP port 5696 for IBM Security Guardium Key Lifecycle Manager
򐂰 Port 5697 for Thales Vormetric DSM
򐂰 Port 5697 for Thales CipherTrust Manager

If you must connect the IBM Security Guardium Key Lifecycle Manager by using SSL/TLS
v1.2 for NIST SP 800-131a compliance, see 5.8, “NIST SP 800-131a requirements for key
servers” on page 190. Then, see “Configuring IBM Security Guardium Key Lifecycle Manager
servers for data-at-rest encryption” on page 170.

Note: When running mkkeymgr to configure IBM Proprietary Protocol key managers, be
aware that port 3801 is the default IBM Proprietary Protocol TCP port for IBM Security
Guardium Key Lifecycle Manager.

IBM Proprietary Protocol communication on the IBM Security Guardium Key Lifecycle
Manager IBM Proprietary Protocol TCP port is not secured by TLS and it is not
recommended because it is not as secure.

However, if you choose that option at your own risk instead of TLS, you must not provide
key server certificates as part of key server configuration.

In your mkkeymgr parameters, if you select the port that is used for IBM Proprietary Protocol
TCP communication on IBM Security Guardium Key Lifecycle Manager (default is 3801),
do not provide a certificate location.

If your key server port number is the IBM Proprietary Protocol TCP port of the IBM Security
Guardium Key Lifecycle Manager and you configured a certificate when creating the key
server object, key server communication fails because the IBM Security Guardium Key
Lifecycle Manager is communicating through TCP and the DS8000 is communicating
through TLS. This situation results in errors during encryption enablement.

Chapter 5. Implementing IBM DS8000 encryption 169

 Figure 5-154 shows the default ports as displayed in the IBM Security Guardium Key
Lifecycle Manager GUI Welcome window.

Figure 5-154 Default ports in IBM Security Guardium Key Lifecycle Manager

Configuring IBM Security Guardium Key Lifecycle Manager servers for

data-at-rest encryption
To configure the IBM Security Guardium Key Lifecycle Manager server connection, use the
mkkeymgr, mkkeygrp, and lskeymgr commands.

With DS8000 Release 8.5 and later, your configuration commands must also specify the
encryption type dar and the encryption key group number. (The defaults are IPP protocol,
type DAR (DAR), and encryption key group 1.)

Complete the following steps:

1. Run the mkkeymgr command at the dscli command prompt, with the parameters and
variables for IBM Proprietary Protocol and DAR that are shown in Example 5-16.

Example 5-16 Creating one or more key servers with IBM Proprietary Protocol
dscli> mkkeymgr -addr 9.123.456.10 -serverport 1441 -cert
/home/source/keba_ssl_kmip_2.cer -keyprotocol IPP -type dar -keygrp 1 1
-------------------------------------------------------
CMUC00354I mkkeymgr: The key server 1 has been created.

Commands for KMIP are shown in Example 5-17.

Example 5-17 Create one or more key servers with KMIP

dscli> mkkeymgr -addr 9.123.456.11 -serverport 5696 -cert
/home/source/keba_ssl_kmip_2.cer -keyprotocol KMIP -type dar -keygrp 1 1
-------------------------------------------------------
CMUC00354I mkkeymgr: The key server 1 has been created.

Repeat the mkkeymgr command for key servers 2 - 4, if required.

2. Verify that the new IBM Security Guardium Key Lifecycle Manager server was added
successfully, the state is active, and the status is normal. Run the lskeymgr command with
the -l parameter, as shown in Example 5-18.

Example 5-18 Verifying the IBM Security Guardium Key Lifecycle Manager servers
dscli> lskeymgr
Date/Time: October 1, 2019 5:07:38 PM CEST IBM DS CLI Version: 7.9.0.509 DS: -
ID state status keyprotocol addr port type keygrp
============================================================

170 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 1 active normal IPP 9.123.456.10 1441 DAR 1

3. Create the Key group with IBM Proprietary Protocol (see Example 5-19) or for KMIP (see
Example 5-20).

Example 5-19 Creating a Key Group with IBM Proprietary Protocol

mkkeygrp -keyprotocol ipp -label ds8900 -type dar 1

Example 5-20 Creating a Key Group with KMIP

mkkeygrp -keyprotocol kmip -type dar 1

4. The encryption key group is created in the accessible state (see Example 5-21 and
Example 5-22). All key servers are in the active state and have a normal status (see
Example 5-23 and Example 5-24).

Example 5-21 Encryption key group state with IBM Proprietary Protocol
dscli> lskeygrp -l 1
ID state reckeystate reckeydate datakeydate grpstatus mgrstatus label
label2 keyprotocol type name

-------------------------------------------------------------------------------
1 accessible configured 02/05/2024 02/05/2024 - normal ds8900 -
IPP DAR DAR_1

Example 5-22 Encryption key group state with KMIP

dscli> lskeygrp -l 1
ID state reckeystate reckeydate datakeydate grpstatus mgrstatus label
label2 keyprotocol type name

-------------------------------------------------------------------------------
1 accessible configured 02/05/2024 02/05/2024 - normal - -
KMIP DAR DAR_1

Example 5-23 Key server state with IBM Proprietary Protocol

dscli> lskeymgr -l -keygrp 1
ID state status keyprotocol addr port type keygrp
------------------------------------------------------------
1 active normal IPP 9.123.456.10 1441 DAR 1
2 active normal IPP 9.123.456.10 1441 DAR 1

Example 5-24 Key server state with KMIP

dscli> lskeymgr -l -keygrp 1
ID state status keyprotocol addr port type keygrp
-----------------------------------------------------------
1 active normal KMIP 9.123.456.10 5696 DAR 1
2 active normal KMIP 9.123.456.11 5696 DAR 1

Chapter 5. Implementing IBM DS8000 encryption 171

 A DAR encryption key group contains a set of extent pools, each of which has a set of
associated ranks and volumes. The remote mirror and copy functions can migrate data within
or between encryption key groups.

You can now start creating the extent pools.

You do not need to specify or enable any other parameters to start using the encrypted
DS8000 disks. When you select arrays, the encryption status for each array is displayed.

5.4.5 IBM Security Guardium Key Lifecycle Manager authentication

mechanisms
IBM Security Guardium Key Lifecycle Manager have different levels of authentication for
incoming requests from IBM Proprietary Protocol and KMIP devices.

Certificate authentication for TLS 1.2 communication

The first level of authentication is done by validating certificates. The DS8000 server
communicates with IBM Security Guardium Key Lifecycle Manager over TLS 1.2. IBM
Security Guardium Key Lifecycle Manager has the root and intermediate certificates (Gen 2
and Gen 3) of DS8000 certificates in IBM Security Guardium Key Lifecycle Manager
truststore (Figure 5-155).

Therefore, if the DS8000 server uses default certificates, the certificates are automatically
trusted by IBM Security Guardium Key Lifecycle Manager (see Figure 5-155).

Figure 5-155 IBM Security Guardium Key Lifecycle Manager truststore

If the DS8000 server presents the Chain of Trust and the root certificate of that certificate
chain is trusted in IBM Security Guardium Key Lifecycle Manager, the entire chain is
automatically trusted. You do not have to import and trust all the intermediate levels and
endpoint certificate in IBM Security Guardium Key Lifecycle Manager.

IBM Security Guardium Key Lifecycle Manager servers do not present the Chain of Trust to
the DS8000 devices; therefore, you must ensure that the IBM Security Guardium Key
Lifecycle Manager server certificate or certificate-signing IBM Security Guardium Key
Lifecycle Manager server certificate is trusted at the DS8000 endpoint.

172 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 Note: The certificate that is described here is the network communication certificate, which
should not be confused with the certificate that is created for the DAR or TCT encryption.

Device authentication for IBM Proprietary Protocol

A DS8000 server can communicate with IBM Security Guardium Key Lifecycle Manager by
using the IBM Proprietary Protocol over TLS communication channels. In IBM Security
Guardium Key Lifecycle Manager, you can configure policy to have step-up authentication.

Chapter 5. Implementing IBM DS8000 encryption 173

 The following policy options are available for new DS8000 devices (see Figure 5-156):

Figure 5-156 IBM Security Guardium Key Lifecycle Manager device policies

򐂰 Only accept manually added devices for communication

This option is the default option, and it is the most secure option. When this option is
configured, requests from new DS8000 devices are rejected automatically, so an
administrator must manually configure the devices. This process is described in 5.4.1,
“Setting up IBM Security Guardium Key Lifecycle Manager Key management by using IBM
Proprietary Protocol” on page 143.
򐂰 Hold new device requests pending my approval
This option is a secure option when requests from new DS8000 devices are added to a
pending list in IBM Security Guardium Key Lifecycle Manager. An administrator of IBM
Security Guardium Key Lifecycle Manager can approve or reject these requests from the
IBM Security Guardium Key Lifecycle Manager UI.
To approve or reject a pending device, complete the following steps:
a. Log in to the IBM Security Guardium Key Lifecycle Manager UI. You see the Pending
device link in the Action Items section of Welcome page (Figure 5-157).

Figure 5-157 Pending Devices link on the Welcome page

b. Click Pending devices to see list of pending devices. Select any device and click
Accept to approve the pending device (see Figure 5-158).

Figure 5-158 Pending devices

174 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 c. Click Accept to approve the device (see Figure 5-159).

Figure 5-159 Accepting pending devices

򐂰 Automatically accept all new device requests for communication

This option is the least secure option. When this option is configured, a new device
request is approved automatically.

Certificates in Transparent Cloud Tiering

Even when certificates are trusted in IBM Security Guardium Key Lifecycle Manager
truststore, they will not be served keys until they are added to the DS8000_TCT device group.
After certificates are added to the DS8000_TCT device group, any of the endpoints that are
associated with those certificates can access any keys that are created in the DS8000_TCT
device group. For more information, see 5.5, “Configuration for TCT encryption” on page 175.

Worldwide node name authentication in IBM Fibre Channel Endpoint

Security
IBM Security Guardium Key Lifecycle Manager composes the names of the peer-to-peer
device groups from the worldwide node names (WWNNs) of the peers (endpoint devices) in
the group. The device group contains the security credentials in the form of a WWNN in the
Subject Alternative Name of the certificates that the endpoints use to communicate with IBM
Security Guardium Key Lifecycle Manager. For more information, see 3.8, “DS8000 endpoint
encryption key management using KMIP” on page 59.

5.5 Configuration for TCT encryption

The IBM Security Guardium Key Lifecycle Manager create keys to encrypt data objects that
are transferred from the DS8000 to the cloud by TCT and by using the KMIP.

To use TCT encryption, you must set up the IBM Security Guardium Key Lifecycle Manager
with a DS8000 device. After the device is configured, you can enable TCT encryption by using
a DSCLI command at any time. You run this command independently from DAR encryption
and without affecting access to the data.

Note: Enablement of TCT encryption in the DS8000 GUI is not supported at the time of
this writing.

TCT encryption includes the following prerequisites:

򐂰 The DS8000 must be Release 8.5 or later
򐂰 IBM Security Guardium Key Lifecycle Manager must be Version 3.0.0.2 or later – use a
supported GKLM V4.x

Chapter 5. Implementing IBM DS8000 encryption 175

 򐂰 IBM Guardium Key Lifecycle Manager must run in a Multi-Master environment

Thales Vormetric DSM and Thales CipherTrust Manager are supported by TCT encryption.

5.5.1 Setting up TCT encryption

The following process is used to set up TCT encryption:
1. Export the certificate from the DS8000.
2. Transfer certificate to the key server.
3. Import the DS8000 certificate into the key server TCT device group.
4. Configure DS8000 TCT by using CLI.

Exporting the DS8000 certificate

Most often when you set up and use TCT encryption, it is not necessary to have DAR
encryption enabled. However, the Gen 2 or Gen 3 certificate can be exported through the
DSGUI only when DAR encryption is enabled, or while you are using the DAR encryption
activation wizard. Consider the following points:
򐂰 If DAR encryption is enabled, log in to the DS8000 GUI and export the DS8000 Encryption
Communication Certificate by using one of the following options:
– Use DS CLI, as shown in Example 5-25.

Example 5-25 Exporting certificate with CLI

dscli> managekeygrp -action exportcert -certType GEN3 -loc
C:\Users\xxxxx\ds8k_75xxxx1_gen3_cert.pem 1
Date/Time: September 30, 2019 5:23:36 PM CEST IBM DS CLI Version: 7.9.0.491 DS:
IBM.2107-75xxxx1
CMUC00490I managekeygrp: The certificate for key group 1 has been exported.

– If DAR encryption is enabled, select Settings → Security → Data-at-rest encryption

and then, click Export Certificate, as shown in Figure 5-160.

Figure 5-160 Export Certificate option

176 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
򐂰 If DAR encryption is not enabled and no logical configuration exists, log in to the DS8000
GUI and select Settings → Security → Data-at-rest encryption. Then, follow the wizard
after you select Enable, as described in “DS8000 enabling data-at-rest encryption” on
page 156 to enable DAR encryption.
Continue until you reach the DS8000 Certificate step as shown in Figure 5-161. Export it
by clicking Export Certificate.

Figure 5-161 Export Certificate option

򐂰 If DAR encryption is not enabled and a logical configuration exists, you can export the
certificate by using the CLI, as shown in Example 5-25 on page 176. Even if no key
manager and keygroup were configured, you can export the certificate.

Transferring the certificate to the key server

Then, you must transfer the file to the primary key manager server. Example 5-26 shows
running the scp command to transfer the certificate file and shows the target directory
/opt/IBM/WebSphere/AppServer/products/sklm/data on IBM Security Guardium Key
Lifecycle Manager where the file needs to reside. You can use the SGKLM GUI in a later step
to upload the certificate as well.

Example 5-26 Certificate transfer to IBM Security Guardium Key Lifecycle Manager
[root@sklma source]# scp ds8k_75xxxx1_gen3_cert.pem
[email protected]:/opt/IBM/WebSphere/AppServer/products/sklm/data/

ds8k_75BRX70_gen2_cert.pem 100% 1270 1.2KB/s 00:00

[root@sklma source]#

Chapter 5. Implementing IBM DS8000 encryption 177

 DS8000 TCT encryption certificate (Gen 2) import (IBM Security
Guardium Key Lifecycle Manager)
The exported certificate can now be imported to the IBM Security Guardium Key Lifecycle
Manager Primary Master server. Complete the following steps to finish the IBM Security
Guardium Key Lifecycle Manager configuration:
1. Log in to the IBM Security Guardium Key Lifecycle Manager GUI and locate the device
group “DS8000_TCT” in “Key and Device Management” on the left side, as shown in
Figure 5-162.

Figure 5-162 DS8000_TCT option in Key and Device Management window

2. Right-click the group DS8000_TCT and select Manage keys and devices, as shown in
Figure 5-163.

Figure 5-163 Managing keys and devices

3. The window that is shown in Figure 5-164 on page 179 allows you to add or delete a
certificate and the associated node name. You can also modify the node name that is
associated with a certificate. Click Add and then, select Certificate to import the DS8000
Encryption Communication Certificate (Gen 2).

178 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 Figure 5-164 Adding certificate

4. In the Add Certificate window, enter a unique certificate alias name. Then, browse for the
certificate file that was transferred in “Exporting the DS8000 certificate” on page 176, as
shown in Figure 5-165.

Figure 5-165 Certificate alias

5. If you did not use the default directory

/opt/IBM/WebSphere/AppServer/products/sklm/data, browse and select the directory
where the certificate file that was transferred in an earlier step. If you did not upload it, you
can do it now by using the Upload button, as shown in Figure 5-166.

Figure 5-166 Uploading the GEN2 or GEN3 certificate

Chapter 5. Implementing IBM DS8000 encryption 179

 Then, highlight the certificate file, and click Select, as shown in Figure 5-167.

Figure 5-167 Browse file window

6. Select Add in the Add Certificate window, as shown in Figure 5-168.

Figure 5-168 Add Certificate window

7. A warning to create a backup is displayed. Click Close (see Figure 5-169) and create a
backup now or later. For more information, see “Creating a backup” on page 87.

Figure 5-169 Take a backup warning window

180 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
8. Confirm that the certificate was imported successfully and appears in the list, as shown in
Figure 5-170.

Figure 5-170 Certificate list

The key servers are now configured and synchronized. For Multi-Master setup, the
synchronization is done automatically. To create the IBM Security Guardium Key Lifecycle
Manager server connection for TCT, proceed to “DS8000 CLI configuration for TCT”.

DS8000 CLI configuration for TCT

To configure the key servers with KMIP for TCT encryption, run the lskeymgr, mkkeymgr, and
managekeymgr commands, as shown in the following steps:
1. To view the list of registered key servers, if any exist, run the lskeymgr command (see
Example 5-27).

Example 5-27 Listing the key managers

dscli> lskeymgr
Date/Time: 10 October 2024 15:34:44 CEST IBM DSCLI Version: 7.10.0.749 DS: -
ID state status keyprotocol addr port type keygrp
===========================================================
1 active normal KMIP 9.155.121.33 5696 DAR 1
2 active normal KMIP 9.155.112.32 5696 DAR 1

2. This example shows two key managers that are configured in the DS8000 for DAR
encryption by using the KMIP. If those servers are prepared to serve keys for both types
DAR encryption and TCT encryption), the connection can be modified by using the
managekeymgr command in Step 1. If the key server cannot be used for TCT encryption,
see “Creating a TCT key server” on page 182 to create key servers.

Adding a TCT key group to a KMIP key server

Complete the following steps:
1. Run the managekeymgr command to modify the key servers and add encryption key group
2 for TCT, as shown in Example 5-28.

Example 5-28 Managing key managers

dscli> managekeymgr -action addgrp -keygrp 2 -type tct 1
CMUC00563I managekeymgr: The key group was added to the key manager successfully.

dscli> managekeymgr -action addgrp -keygrp 2 -type tct 2

CMUC00563I managekeymgr: The key group was added to the key manager successfully.

Chapter 5. Implementing IBM DS8000 encryption 181

 2. Verify the extra connections by using the lskeymgr command, as shown in Example 5-29.
Both key servers show now type = DAR,TCT and keygrp = 1,2.

Example 5-29 Listing key managers

dscli> lskeymgr
ID state status keyprotocol addr port type keygrp
===============================================================
1 active normal KMIP 0.000.000.01 5696 DAR,TCT 1,2
2 active normal KMIP 0.000.000.02 5696 DAR,TCT 1,2

3. Configure encryption key groups for TCT encryption, as shown in Example 5-30.

Example 5-30 Creating encryption key group

dscli> mkkeygrp -keyprotocol kmip -type tct 2
CMUC00358I mkkeygrp: The key server key group 2 has been created.

4. List the encryption key groups, as shown in Example 5-31.

Example 5-31 Listing encryption key group

dscli> lskeygrp
ID state reckeystate reckeydate datakeydate keyprotocol type name
========================================================================
1 accessible configured 10/01/2019 10/02/2019 KMIP DAR DAR_1
2 accessible disabled - 10/02/2019 KMIP TCT TCT_2

A TCT encryption key group contains a set of cloud server connections.

You can now configure the cloud server connection for TCT with the encryption parameters.
For more information, see IBM DS8000 and Transparent Cloud Tiering, SG24-8381.

Creating a TCT key server

Complete the following steps:
1. Run the lskeymgr command (see Example 5-32) to view the list of registered key servers,
if any.

Example 5-32 Listing key managers

dscli> lskeymgr
ID state status keyprotocol addr port type keygrp
============================================================
1 active normal IPP 0.000.000.01 441 DAR 1
2 active normal IPP 0.000.000.02 441 DAR 1

The preceding example shows two key managers that are configured in the DS8000 for
DAR encryption by using the IBM Proprietary Protocol.
Key managers that are configured with IBM Proprietary Protocol cannot be used for TCT
encryption. The encryption type tct is not supported by IBM Proprietary Protocol and TCT
encryption requires the KMIP protocol. You also cannot have IBM Proprietary Protocol and
KMIP protocols on the same key server.
Therefore, key servers must be created.

182 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 To create key servers, use the mkkeymgr command, as shown in Example 5-33.
You must specify the following values:
– Server certificate (-cert) that was exported in “Exporting the TLS/KMIP server
certificate” on page 86
– Protocol (-keyprotocol) KMIP
– Servers IP address or hostname (-addr)
– Encryption type (-type) tct
– Encryption key group (keygrp) 2
– New key server ID

Example 5-33 Creating key servers

dscli> mkkeymgr -cert
/opt/IBM/WebSphere/AppServer/products/sklm/data/ssl_kmip_server_cert.cer
-keyprotocol KMIP -addr 0.000.000.10 -type tct -keygrp 2 10
CMUC00354I mkkeymgr: The key server 10 has been created.

dscli> mkkeymgr -cert

/opt/IBM/WebSphere/AppServer/products/sklm/data/ssl_kmip_server_cert.cer
-keyprotocol KMIP -addr 0.000.000.11 -type tct -keygrp 2 11
CMUC00354I mkkeymgr: The key server 11 has been created.

Note: The -cert parameter specifies the location of the certificate file that was
exported earlier. This certificate is used as a trust anchor to authenticate the certificate
of the specified key server when a TLS security protocol is used. If the parameter is not
specified, only non-TLS protocols that do not require a trust anchor certificate are
allowed. The certificate is in the PEM or DER format. The TLS security protocol is
required when you use KMIP.

2. Verify the new connections by using the lskeymgr command, as shown in Example 5-34.
The key servers 1 and 2 that are use IBM Proprietary Protocol by way of port 441 still
show type = DAR and keygrp = 1. However, the new key servers 10 and 11 that use KMIP
by way of port 5696 show type = TCT and keygrp = 2.

Example 5-34 Listing all key servers

dscli> lskeymgr
ID state status keyprotocol addr port type keygrp
============================================================
1 active normal IPP 0.000.000.01 441 DAR 1
2 active normal IPP 0.000.000.02 441 DAR 1
10 active normal KMIP 0.000.000.10 5696 TCT 2
11 active normal KMIP 0.000.000.11 5696 TCT 2

3. Configure encryption key groups for TCT encryption, as shown in Example 5-35.

Example 5-35 Creating encryption key group

dscli> mkkeygrp -keyprotocol kmip -type tct 2
CMUC00358I mkkeygrp: The key server key group 2 has been created.

Chapter 5. Implementing IBM DS8000 encryption 183

 4. List encryption key groups, as shown in Example 5-36.

Example 5-36 Listing encryption key group

dscli> lskeygrp
ID state reckeystate reckeydate datakeydate keyprotocol type name
========================================================================
1 accessible configured 10/01/2024 10/02/2024 DAR DAR DAR_1
2 accessible disabled - 10/02/2024 KMIP TCT TCT_2

A TCT encryption key group contains a set of cloud server connections.

You can now configure the cloud server connection for TCT with the encryption parameters.
For more information, see IBM DS8000 and Transparent Cloud Tiering, SG24-8381.

5.6 IBM Fibre Channel Endpoint Security configuration

This section provides a brief overview of the IBM Fibre Channel Endpoint Security encryption
setup on the target DS8000 (DS8A00 or DS8900F).

Tip: For more information about the setup that is required on the Z Central Processor
Complex (CPC) (initiator), see IBM Fibre Channel Endpoint Security for IBM DS8900F and
IBM Z, SG24-8455.

5.6.1 DS8000 GUI configuration for IBM Fibre Channel Endpoint Security
Enabling IBM Fibre Channel Endpoint Security with the IBM Security Guardium Key Lifecycle
Manager by using KMIP requires a Multi-Master configuration of the key server. The key
servers do not require any more configuration to serve keys to the DS8900F, assuming that
you exported the DS8000 certificates to the key servers.

To configure the DS8000, complete the following steps:

1. Log on to the DS8000 GUI as a user with Administrator role to enable the IBM Fibre
Channel Endpoint Security. From the DS8000 GUI Welcome window, click Settings and
then, Security, as shown in Figure 5-171.

Figure 5-171 Go to the Encryption window

184 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
2. The encryption wizard is shown in Figure 5-172. This wizard is started only when you
enable the IBM Fibre Channel Endpoint Security for the first time. Click Configure IBM
Fibre Channel Endpoint Security to continue.

Figure 5-172 Configure Endpoint Security option

3. The Welcome window opens with the basic information that is related to the prerequisites
for the next steps, such as at least two key servers should be already configured and
online; that is, connected to the DS8000 (see Figure 5-173). Click Next to continue.

Figure 5-173 Welcome window

Chapter 5. Implementing IBM DS8000 encryption 185

 4. Configure the key servers. The DS8000 supports up to four key servers. In Figure 5-174,
two key servers are defined. You can add up to four or remove key servers by clicking the
+ or - sign next to each key server field. Specify the host address (IP address or fully
qualified hostname of the key server). If DAR or TCT encryption is set up, select Use
existing key servers from TCT encryption at the bottom of the window. Click Next.

Figure 5-174 Defining key servers

5. Each key server connection is tested. The message that is shown in Figure 5-175 is
displayed if all the key servers that you defined are accessible. Click OK.

Note: The ports also can be changed and must match the setting on the IBM Security
Guardium Lifecycle Manager key server. The default TLS port in 5696.

Figure 5-175 Test Key Servers window

186 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
6. Transfer the SSL certificates from the key servers to the DS8000, as shown in
Figure 5-176. Exporting the SSL certificates is described in “Exporting the TLS/KMIP
server certificate” on page 86 for IBM Security Guardium Key Lifecycle Manager. If DAR or
TCT encryption is set up, select Use existing certificates from TCT encryption at the
bottom of the window.

Figure 5-176 Transferring SSL certificates to DS8000

7. Encryption enablement tasks take approximately 1 minute. Expand the View more details
section to see the task list. The overall progress is displayed as a percentage. When the
completed message displays, click Close.

In the Encryption window (see Figure 5-177 on page 188), the encryption state is Enabled
and the encryption key is Accessible. By expanding each section, you get more information.

The overall process to enable encryption on a DS8000 by using the GUI interface is simple. It
takes approximately 5 minutes to complete these steps.

Now, configure the IBM Z. For more information, see IBM Fibre Channel Endpoint Security for
IBM DS8900F and IBM Z, SG24-8455.

Chapter 5. Implementing IBM DS8000 encryption 187

 Figure 5-177 Encryption is enabled and accessible

5.6.2 DS8000 CLI configuration for IBM Fibre Channel Endpoint Security
If you have a KMIP key group configured for DAR or TCT, you can add a key group for IBM
Fibre Channel Endpoint Security for the configured key servers.

Complete the following steps:

1. Check for current key managers, as shown in Example 5-37.

Example 5-37 Listing key managers

dscli> lskeymgr
ID state status keyprotocol addr port type keygrp
============================================================
10 active normal KMIP 0.000.000.01 5696 DAR 1
11 active normal KMIP 0.000.000.02 5696 DAR 1

2. Add Endpoint key group 2 to each key manager, which is identified by ID 10 and 11, as
shown in Example 5-38.

Example 5-38 Adding key group 2

dscli> managekeymgr -action addgrp -keygrp 2 -type endpoint 10
CMUC00563I managekeymgr: The key group was added to the key manager
successfully.
dscli> managekeymgr -action addgrp -keygrp 2 -type endpoint 11
CMUC00563I managekeymgr: The key group was added to the key manager
successfully.

188 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
3. Create key group 2, as shown in Example 5-39.

Example 5-39 Creating IBM Fibre Channel Endpoint Security key group
dscli> mkkeygrp -keyprotocol kmip -type endpoint 2
CMUC00358I mkkeygrp: The key server key group 2 has been created.

4. Verify the key managers and see that Endpoint was added, as shown in Example 5-40.

Example 5-40 Verify key managers

dscli> lskeymgr
ID state status keyprotocol addr port type keygrp
====================================================================
10 active normal KMIP 0.000.000.01 5696 DAR,ENDPOINT 1,2
11 active normal KMIP 0.000.000.02 5696 DAR,ENDPOINT 1,2

If no KMIP key manager exists, create a key manager and key group by completing the
following steps:
1. Create the key managers, as shown in Example 5-41.

Example 5-41 Creating endpoint key managers

dscli> mkkeymgr -cert C:\Users\xxxx\sklm_ssl_kmip_production_2019.cer
-keyprotocol KMIP -addr 0.000.000.01 -type endpoint -keygrp 2 10
CMUC00354I mkkeymgr: The key server 10 has been created.
dscli> mkkeymgr -cert C:\Users\xxxx\sklm_ssl_kmip_production_2019.cer
-keyprotocol KMIP -addr 0.000.000.02 -type endpoint -keygrp 2 11
CMUC00354I mkkeymgr: The key server 11 has been created.

2. Create the key group, as shown in Example 5-42.

Example 5-42 Creating key group

dscli> mkkeygrp -keyprotocol kmip -type endpoint 2
CMUC00358I mkkeygrp: The key server key group 2 has been created.

3. Verify the key managers, as shown in Example 5-43.

Example 5-43 Verifying key managers

dscli> lskeymgr
ID state status keyprotocol addr port type keygrp
=================================================================
10 active normal KMIP 0.000.000.01 5696 ENDPOINT 2
11 active normal KMIP 0.000.000.02 5696 ENDPOINT 2

Chapter 5. Implementing IBM DS8000 encryption 189

5.7 Data-at-rest encryption and Copy Services functions
Copy Services operations are not affected by encrypting drives. The encryption applies only
to DAR, which is the data that is physically written to the disk drives. If you are doing remote
replication of the encrypted data, when the data is read from the source disk, it is decrypted,
and sent across the network link. If the target storage system is also set up for encryption,
when the data is written to disk at the target site, it is encrypted again. There is no relationship
between the encryption that is done at the source and the encryption at the target. They are
independent operations with their own sets of keys and potentially even their own key
managers, depending on how the environment is configured.

This encryption strategy also holds true for IBM FlashCopy®. Although this copy is a T0 copy
of data that resides only with the DS8000, when the source data is read and rewritten to the
FlashCopy target volume, it is decrypted at read and re-encrypted at write. The encryption is
not intrusive in terms of performance because it is all done by the drives.

5.8 NIST SP 800-131a requirements for key servers

If one or more key servers are configured on the DS8000, the HMC initiates periodic
connections to the key servers to monitor whether the key servers are accessible. When an
encryption key group or RK is configured on the DS8000, the HMC initiates connections to
the key servers to request key services and periodically verifies that any active DKs are valid
on all configured key servers.

Encryption key servers use a secure connection with the HMC with IBM Proprietary Protocol.
However, TLS 1.2 can also be enabled. IBM Security Key Lifecycle Manager V2.6 and later
includes an NIST SP 800-131a security-compliant Java level to meet this requirement.

The periodic key server accessibility monitoring is implemented in the DS/NI server on the
HMC. The key services requests and periodic DK validation are implemented in the key client
in the storage facility image, and it communicates through the DS/NI server.

The key server network connection uses IBM Proprietary Protocol. The protocol uses a digital
certificate to authenticate the key client with the key server, and it has data security for the
DKs that are passed between the key client and server.

However, use of TLS protocols with the proprietary protocol is recommended to further
secure the key server connection between the management server and the key server.

190 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
5.9 Migrating certificates

Note: A Gen 2 certificate is set to the DS8000 Release 8.1 in factory. Thus, a migration
from Gen 1 to Gen 2 is not possible or required. Only machines that were upgraded from a
previous level of code can be migrated. Gen 2 and Gen 3 certificates are delivered with all
DS8900F; although the Gen 2 is active, the Gen 3 is dormant.

Note: The encryption certificate may be updated to a system defined or customer defined
certificate. The encryption key group must configured and accessible using the factory
default certificate before it can be updated.

5.9.1 Migrating from a Gen 2 to a Gen 3 certificate for encryption

To migrate from Gen 2 to Gen 3 certificate, complete the following steps:

1. Verify the version of the certificate that is being used for data encryption. Example 5-44
shows how to verify which certificate (Gen 2 or Gen 3) that the DS8000 is using.

Example 5-44 Determining which certificate the DS8000 uses for data encryption
dscli> showkeygrp 1
ID 1
numranks 4
numpools 4
state accessible
reckeystate configured
reckeydate 10/10/2019 14:48:09 CEST
datakeydate 10/15/2019 11:45:50 CEST
grpstatus normal
mgrstatus normal
label -
label2 -
certificate GEN2
certificate not valid before 08/22/2019 21:55:02 CEST
certificate not valid after 08/12/2032 02:36:55 CEST
certificate issuer O=ibmDisk,C=US
certificate subject
CN=2107-75KMW81,O=ibmDisk,C=US,uid=DS8K-2107-75KMW81
endpoint enabled Yes
certificate install state Not Imported
pending cert valid not before -
pending cert valid not after -
pending cert issuer -
pending cert subject -
pending cert endpoint enabled -
uuid KEY-4d74e7f-4cbabdc7-2d25-465f-b4c5-d065c2e8a097
keyprotocol KMIP
type DAR
name
DAR_1

Chapter 5. Implementing IBM DS8000 encryption 191

 2. Export the Gen 3 certificate from the DS8900F by using GUI or CLI:
– Use DS CLI, as shown in Example 5-45.

Example 5-45 Export certificate with CLI

dscli> managekeygrp -action exportcert -certType GEN3 -loc CMUC00490I managekeygrp:
The certificate for key group 1 has been exported.

– Select Settings → Security → Data-at-rest encryption and click Export Certificate,

as shown in Figure 5-178.

Figure 5-178 Export certificate

3. Transfer the file to the IBM Security Guardium Key Lifecycle Manager server.

Note: You need a method to transfer the certificate file that you exported from the
DS8900F to the file system of the server on which IBM Security Guardium Key Lifecycle
Manager runs.

You also need a UID that includes sufficient access to add a file to the IBM Security
Guardium Key Lifecycle Manager import directory. On UNIX systems, this directory
defaults to: /opt/IBM/WebSphere/AppServer/products/sklm/data.

Example 5-46 shows the use of the scp command to transfer the certificate file and the
target directory /opt/IBM/WebSphere/AppServer/products/sklm/data on IBM Security
Guardium Key Lifecycle Manager where the file must reside. You can use the GUI to
upload the certificate in a later step.

Example 5-46 Certificate transfer to IBM Security Guardium Key Lifecycle Manager
[root@sklma source]# scp ds8k_75xxxx1_gen3_cert.pem
[email protected]:/opt/IBM/WebSphere/AppServer/products/sklm/data/ds8k_75BRX70_gen2_

192 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 cert.pem 100% 1270 1.2 KBps 00:00

4. Import the Gen 3 certificate into the Client Device Certificates. Select Advanced
Configuration - Client Device Certificates, as shown in Figure 5-179.

Figure 5-179 Client Device Certificates option

From the table header, click Import, as shown in Figure 5-180.

Figure 5-180 Importing certificate

5. Enter a unique certificate name that you can recognize easily; for example, by including
the DS8900F serial number. If you did not transfer the certificate yet, you can upload it
now.
In the Import dialogue select Browse → Upload and upload the certificate, as shown in
Figure 5-181.

Chapter 5. Implementing IBM DS8000 encryption 193

 Figure 5-181 Uploading certificate

6. Click Browse and locate the certificate that you copied or uploaded to the IBM Security
Guardium Key Lifecycle Manager import directory. Finish the import process by clicking
Import (see Figure 5-182).

Figure 5-182 Importing certificate details

194 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
7. If TCT is activated, update TCT device group by completing the following steps:
a. In the IBM Security Guardium Key Lifecycle Manager welcome window, select
DS8000-TCT → Manage keys and devices, as shown in Figure 5-183.

Figure 5-183 Selecting Manage keys and devices option

b. Select Add and then, click Certificate.

Chapter 5. Implementing IBM DS8000 encryption 195

 c. Select Browse, select the certificate, and then, Select. Click Add, as shown in
Figure 5-184. Gen 3 certificate is now added to the DS8000 TCT Device Group.

Figure 5-184 Add Certificate window

8. If IBM Fibre Channel Endpoint Security is activated, update the diagnostic device group
and all peer-to-peer groups in IBM Security Guardium Key Lifecycle Manager.
Complete the following steps:
a. In the welcome tab of IBM Security Guardium Key Lifecycle Manager, filter for the
DS8000 WWNN in the Key and Device Management section.
The DS8000 WWNN appears in at least two peer-to-peer device groups. One group is
the diagnostic device group with the DS8000 WWNN repeated twice. The others are
the IBM Z CPC - DS8000 association device groups whose names consist of the
WWNN of the IBM Z CPC (as owner) and the WWNN of the DS8000 (as partner). One
device group exists for each IBM Z and DS8000 pairing.
b. Start with the z/DS8000 device groups. Highlight a group, right-click, and select
Manage Keys and Devices, as shown in Figure 5-185.

Figure 5-185 Selecting Manage keys and devices option

196 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
c. In the window, highlight the second item, which is the Partner device type, right click,
and select Modify, as shown in Figure 5-186.

Figure 5-186 Selecting Modify device group option

d. Browse for the new DS8900F certificate that you imported and click Modify (see
Figure 5-187).

Figure 5-187 Modify Device Certificate window

Repeat these steps for all device groups to which the DS8000 belongs.
e. In the Welcome window, filter for the DS8000 WWNN again, and highlight the
diagnostic device group whose name begins with the letter “D” followed by the DS8000
WWNN repeated twice. Right-click and select Manage Keys and Devices.
For this group, modify the owner and partner. For each, right-click and modify
the certificate.

Chapter 5. Implementing IBM DS8000 encryption 197

 9. Upgrade the certificate on the DS8000.
If CLI is used, run the managekeygrp command, as shown in Example 5-47, to change from
the Gen 2 to Gen 3 certificate on the DS8000.

Example 5-47 Updating the certificate from Gen 2 to Gen 3 on the DS8000
dscli> managekeygrp -action updatecert -certType GEN3 -key data 1
CMUC00472I managekeygrp: The certificate for key group 1 has been updated.

Run the showkeygrp 1 command to verify that the Gen 3 certificate is now being used for
data encryption (see Example 5-48 on page 198).

Example 5-48 Verifying that the certificate was updated from Gen 2 to Gen 3
dscli> showkeygrp 1
ID 1
numranks 4
numpools 4
state accessible
reckeystate configured
reckeydate 10/10/2019 14:48:09 CEST
datakeydate 10/15/2019 18:19:51 CEST
grpstatus normal
mgrstatus normal
label -
label2 -
certificate GEN3
certificate not valid before 08/22/2019 21:55:04 CEST
certificate not valid after 08/12/2032 02:36:55 CEST
certificate issuer CN=IBM Disk Intermediate
CA,OU=Storage,O=IBM,ST=Arizona,C=US
certificate subject
CN=2107-75xxxx1,O=ibmDisk,C=US,uid=DS8K-2107-75xxxx1
endpoint enabled Yes
certificate install state Not Imported
pending cert valid not before -
pending cert valid not after -
pending cert issuer -
pending cert subject -
pending cert endpoint enabled -
uuid KEY-4d74e7f-ba1db885-9ca3-49a7-b33c-94454a57eb3e
keyprotocol KMIP
type DAR
name DAR_1

198 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 If the DS GUI is used, complete the following steps:
a. In the DS8000 GUI Welcome window, click Settings and then, Security and then,
Data-at-rest.
The System defined (Gen 2) certificate is listed. Select Update Certificate, as shown
in Figure 5-188.

Figure 5-188 Update certificate option

b. Select System Defined (Gen3) and Update (see Figure 5-189).

Figure 5-189 Update DS8000 Encryption Certificate window

If the SSL certificate was updated from the key server and the data encryption certificate was
updated to Gen 3, the DS8000 encryption configuration is now compliant with NIST SP
800-131a.

Chapter 5. Implementing IBM DS8000 encryption 199

5.10 Using a custom-generated Gen 2 or Gen 3 certificate
A custom Gen 2 or Gen 3 certificate can be used for communication between the encryption
key servers (typically IBM Security Guardium Key Lifecycle Manager) and the storage
system. You can update to a custom defined certificate by way of DS GUI or DS CLI.

Note: If the current DS8000 encryption certificate is Gen 1, before you update to a
customer defined certificate, ensure that the CA signed root certificate is installed on each
key server. Encryption certificates must be digitally signed by a CA that is designated as a
trusted root CA.

After you update a DS8000 encryption certificate to a customer defined certificate, you can
change the certificate back to Gen 2, but not Gen 1.

5.10.1 Configuring a custom certificate by using the DS GUI

Update the DS8000 encryption certificate with a custom certificate by using one of the
following options:
򐂰 The encryption enablement wizard when encryption is not enabled.
Click Settings → Security → Encryption. Then, select Enable Encryption to start the
wizard (see Figure 5-190).

Figure 5-190 Enabling encryption

200 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
򐂰 Update Certificate on the Encryption Settings page when encryption is configured:
a. To update the certificate, on the DS GUI home page select Settings → Security →
Encryption. The Encryption window is shown in Figure 5-191.

Figure 5-191 Settings Encryption window

b. Click View Certificate to view the DS8000 Encryption Certificate. Click Update
Certificate. The Update DS8000 Encryption Certificate window opens
(see Figure 5-192).

Figure 5-192 Encryption Settings Update Certificate

c. Click the Customer defined option In the Update DS8000 Encryption Certificate
window. Select Customer that is defined. Browse for the certificate location and enter a
password for the certificate. Click Update to update the certificate.

Note: The maximum length of customer-generated machine password is 128 characters.

An example of a file name for a customer-generated file name is 2107-75YZ123.mfg or
2107-75YZ123.p12 and password is XyZABcPQRstu.

Chapter 5. Implementing IBM DS8000 encryption 201

5.10.2 Configuring a custom certificate by using DS CLI
Custom defined certificate can be specified by using managekeygrp, as shown in the following
examples:
򐂰 managekeygrp -action importcert -loc location -pw password encryption_group_ID
(see Example 5-49).

Example 5-49 Importing custom certificate

dscli> managekeygrp -action importcert -loc /home/hscroot/rashm/da6.p12 -pw
blah 1
CMUC00489I managekeygrp: The certificate for encryption key group 1 has been
imported.

򐂰 managekeygrp -action updatecert -certType customer -key data encryption_group_ID

(see Example 5-50).

Example 5-50 Updating custom certificate

dscli> managekeygrp -action updatecert -certType CUSTOMER -key data 1
CMUC00472I managekeygrp: The certificate for encryption key group 1 has been
updated.

Note: You must specify option -certType with updatecert. If you do not specify this option,
the default is the IBM Gen 2 option. Parameter -key also is required with the
updatecert action.

202 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 6

Chapter 6. Maintaining the IBM DS8000

encryption environment
This chapter provides information about the maintenance and use of your IBM DS8000
encryption environment. It focuses on data-at-rest (DAR) encryption with IBM Security
Guardium Key Lifecycle Manager.

Note: This chapter applies to DAR encryption only. Some figures in this chapter are based
on former versions of IBM Security Guardium Key Lifecycle Manager and the DS8000 GUI,
but the processes that is described are still valid.

This chapter includes the following topics:

򐂰 6.1, “Rekeying the data key for data-at-rest encryption” on page 204
򐂰 6.2, “Recovery key usage and maintenance” on page 212
򐂰 6.3, “Recovery key state summary” on page 228.

Important: For more information about maintaining the IBM Security Guardium Key
Lifecycle Manager environment, see IBM Documentation.

In particular, pay attention to the backup tasks. Failure to back up your keystore and other
critical data correctly can result in the unrecoverable loss of all access to your encrypted
data. Do not encrypt your backup file or store a backup file on an encrypting device.

Failure to back up data also might result in the inconsistency of the key manager and
potential data loss on the storage device.

© Copyright IBM Corp. 2014, 2021. All rights reserved. 203

6.1 Rekeying the data key for data-at-rest encryption
The process of rekeying the data key (DK) depends on the communication protocol (IBM
Proprietary Protocol or Key Management Interoperability Protocol (KMIP)) between IBM
Security Guardium Key Lifecycle Manager and the DS8000.

It is also possible to rekey the Data Key when Local Key Management is used, as described
“Re-key Data Key” on page 238.

6.1.1 Rekeying the data key when the IBM Proprietary Protocol is used
The Rekey Data Key option is available on the DS8000. You can use this option with the
Storage Administrator role to rekey the DK by changing the DK label. A client might want to
use this function to change periodically the DK.

The following procedure describes how to:

򐂰 Define a new certificate in the IBM Security Guardium Key Lifecycle Manager key servers.
򐂰 Rekey the DK labels in the DS8000.

Defining a new key label or certificate in the IBM Security Guardium Key
Lifecycle Manager key servers
To create a certificate, log in to the Primary/Master IBM Security Guardium Key Lifecycle
Manager key server, and complete the following steps:
1. Highlight DS8000 under Device Group in the Key and Device Management page, as
shown in Figure 6-1.

Important: You must use the predefined DS8000 Device Group. The use of
custom-defined device groups is not supported.

Figure 6-1 Key and Device Management window

2. Right-click DS8000 and select Manage keys and devices, as shown in Figure 6-2 on
page 205.

204 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 Figure 6-2 Manage keys and devices

The certificate that is in use is displayed on the left side. On the right side, the association
to the Storage Image is indicated, as shown in Figure 6-3.

Figure 6-3 DS8000 devices and certificates

3. Select Add → Certificate to create a certificate, as shown in Figure 6-4.

Figure 6-4 Add certificate

4. Create a self-signed certificate or Request certificate from a third-party provider, as

explained in “Creating an TLS/KMIP server certificate” on page 79.
The new certificate appears in the list, as shown in Figure 6-5.

Figure 6-5 New certificate

Chapter 6. Maintaining the IBM DS8000 encryption environment 205

 5. Highlight the Storage Image to be rekeyed on the right side, right-click, and select Modify,
as shown in Figure 6-6.

Figure 6-6 Modify Storage image

6. The Storage Image properties are displayed.

Locate the Primary certificate for image section and click Select to assign a new primary
certificate to the storage image, as shown in Figure 6-7.

Figure 6-7 Selecting primary certificate

7. Select the new certificate from step 4 on page 205, as shown in Figure 6-8.

Figure 6-8 Selecting the new certificate

8. Repeat steps 6 and 7 for the Secondary certificate for image, as shown in Figure 6-9.

Figure 6-9 Selecting secondary certificate

206 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
9. After the new certificate is assigned as primary and secondary image certificate, click
Modify Storage Image, as shown in Figure 6-10.

Figure 6-10 Modify Storage Image option

The Storage Image now shows the new assigned certificate as Primary and Secondary,
as shown in Figure 6-11.

Figure 6-11 New certificates for Image

10.Ensure all modifications made to the SKLM in previous steps are replicated to all
redundant SKLM instances prior to moving on to DS8000 configuration:
򐂰 If Non-Incremental remote replication is enabled, go to the Replication configuration menu
and manually replicate, as described in step 5 on page 95, and wait for replication to
complete prior to configuring DS8000.
򐂰 If Incremental remote replication is enabled, go to the Replication configuration menu and
manually replicate, as described in step 5 in “Creating a backup” on page 87, and wait for
replication to complete prior to configuring DS8000.
򐂰 In Stand Alone with manual replication environments, if no backup was created, create
one now, as described in described in “Backup and restore” on page 87“. Restore the new
backup to all clones prior to configuring DS8000.
򐂰 In Multi-Master environments, the certificate and devices are automatically synchronized.
No action will be necessary to replicate prior to configuring DS8000.

Rekeying the data key in the DS8000

To rekey the DK, complete the following steps:
1. Log in to the DS8000 as a user with Administrator privileges, select Settings →
Encryption, and expand Key Labels, as shown in Figure 6-12.

Chapter 6. Maintaining the IBM DS8000 encryption environment 207

 Figure 6-12 Starting the Rekey Data Key function

208 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 2. Select the key label that you want to change and from the Actions menu, select Modify
(see Figure 6-13).

Figure 6-13 Selecting the Modify option

3. The Modify Key Label window opens, as shown in Figure 6-14. Enter the new DK label
that is defined in step 4 on page 205 into the provided field, and then, click Modify.

Figure 6-14 Modify Key Label window

4. When the rekey task is complete, the confirmation message displays.

In the Encryption window, the new key label is displayed under the Key Labels section.

6.1.2 Rekeying the data key when the KMIP protocol is used
The Rekey Data Key option is available on the DS8000.

You can use this option with the Storage Administrator role to rekey the DK. A client might
want to use this function to change the DK periodically.

Chapter 6. Maintaining the IBM DS8000 encryption environment 209

 To rekey the DK, complete the following steps:
1. Log in to the DS8000 as user with Administrator privileges and click Settings →
Encryption.
2. Expand the Encryption key section, as shown in Figure 6-15. In the example, the current
key is KEY-4d74e7f-3eebe180-3194-474d-a2af-cc96f12e999a.

Figure 6-15 Data-at-rest encryption

3. Click Rekey to start the Encryption Key Rekey process, as shown in Figure 6-16.

Figure 6-16 Rekey button

210 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
4. A window opens in which the rekey can be confirmed, as shown in Figure 6-17. You must
decide whether to delete the old keys from the server. Make your choice and click Yes.

Figure 6-17 Confirming rekey

A confirmation window is displayed to confirm a successful rekey operation, as shown in

Figure 6-18.

Figure 6-18 Rekey successful

5. Verify the new DK, as shown in Figure 6-19. The new key is
KEY-4d74e7f-3eebe180-3194-474d-a2af-cc96f12e999a.

Figure 6-19 New data key

Chapter 6. Maintaining the IBM DS8000 encryption environment 211

6.2 Recovery key usage and maintenance
The following recovery key-related options are available:
򐂰 Recovery key (RK) enabling
򐂰 RK disabling

The Recovery Key applies only to data-at-rest. When the RK is enabled, the following
functions are available to manage and use the RK after its creation:
򐂰 Validating or testing a recovery key
򐂰 Using the recovery key in an emergency-deadlock situation (recovery action)
򐂰 Rekeying the recovery key
򐂰 Deleting or deconfigure a recovery key

When the RK is disabled, RK enablement is still possible. When Local Key Management is
used, the RK is always disabled.

The details of each function are described in this section.

6.2.1 Validating or testing a recovery key

Part of the RK creation process is the verification of a newly created RK. Verification ensures
that the RK was written correctly. However, after the encryption environment is operational,
the RK is used only in a deadlock situation. Therefore, verify that the stored RK is still valid.
The validation process can be performed occasionally and it can be included in your task list
for the maintenance of the encryption environment. The Security Administrator can validate
the RK at any time. Only users with the Security Administrator authority can validate the RK.
Verifying the RK does not change anything in the system, and Storage Administrator approval
is not needed.

To validate or test an RK, complete the following steps:

1. Log on as a user with the Security Administrator role, click Settings → Encryption, and
click Test, as shown in Figure 6-20.

Figure 6-20 Starting the Validate /Test Recovery Key function

212 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
2. The Test Recovery Key window opens (Figure 6-21). Enter the key into the field and
click Test.

Figure 6-21 Test Recovery Key window

3. When the task is complete, the window in Figure 6-22 on page 213 opens. Click Close.

Figure 6-22 Task completed message

4. If the key is valid, a successful confirmation message is displayed, as shown in

Figure 6-23. Click OK to return to the Encryption window.

Figure 6-23 Recovery key is valid

Chapter 6. Maintaining the IBM DS8000 encryption environment 213

6.2.2 Using the recovery key in an emergency-deadlock situation (recovery
action)
If the IBM Security Guardium Key Lifecycle Manager servers are down or inaccessible for any
reason, the DS8000 storage facility image cannot be started because without the keys the
storage remains in locked mode. In this situation, the following choices are available:
򐂰 Repair at least one of the IBM Security Guardium Key Lifecycle Manager servers or its
network connectivity to serve the necessary key for the DS8000.
򐂰 Start the recovery process to unlock the DS8000 and to enable the volumes to be
accessible again.

Consider the first option and check the IBM Security Guardium Key Lifecycle Manager
servers status first. Attempt to fix the problem with key servers if the problem is not complex,
and if you have time to meet your service-level agreement (SLA). Otherwise, use the RK to
start the process to unlock DS8000 volumes.

Simulating an IBM Security Guardium Key Lifecycle Manager failure

This section describes a real-life example to demonstrate how deadlock recovery works. You
can use this scenario soon after implementing encryption in your environment to test and
document system recovery in a deadlock situation.

Complete the following steps:

1. Shut down all IBM Security Guardium Key Lifecycle Manager servers that are connected
to the DS8000.
2. Check the key server status from the DS8000 Storage Manager GUI by clicking
Settings → Encryption and expand the key servers section. The state of each server
should change to Inaccessible, as shown in Figure 6-24.

Figure 6-24 IBM Security Guardium Key Lifecycle Manager servers status is Inaccessible

The Encryption keys status is still Accessible because the keys are stored in the DS8000
cache. However, if you power off and then on the DS8000, the encryption keys are removed
from the cache. The only way to access the DS8000 data is by obtaining the key from one of
the defined IBM Security Guardium Key Lifecycle Manager key servers.

214 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
The DS8000 Hardware Management Console (HMC) monitors the availability of the IBM
Security Guardium Key Lifecycle Manager servers. The connection is verified every 5
minutes.

If the HMC detects an outage of a key server, the BE14EAF1 SRC is reported (see
Figure 6-25), which is only an early notification. When the outage exceeds the 4-hour limit,
the BE14EAF2 error is reported as a call-home event; therefore, both the client and IBM are
alerted of this incident.

Figure 6-25 BE14EAF1 SRC on DS8000 HMC

The IBM Security Guardium Key Lifecycle Manager key servers are accessed only when the
key is required by the DS8000 (excluding the heartbeat verification).

In most cases, this situation occurs when the DS8000 is starting, but several of the reliability,
availability, and serviceability (RAS) functions, such as Concurrent Code Load (CCL), also
trigger a key retrieval from IBM Security Guardium Key Lifecycle Manager key server. The
easiest way to reach this point is to turn off the DS8000 by using the DS8000 HMC GUI.

By starting the DS8000 again while the key servers are still down, you notice that the
initialization progress is much slower. The reason is that some warm starts are initiated to
configure the storage devices.

In addition, the DS8000 waits 10 minutes for the IBM Security Guardium Key Lifecycle
Manager key servers to become available. However, without getting the necessary keys from
the IBM Security Guardium Key Lifecycle Manager servers, the configuration phase fails and
the DS8000 must give up and report the failure.

Chapter 6. Maintaining the IBM DS8000 encryption environment 215

 The following SRC codes are available:
򐂰 BE14E008: Unable to retrieve keys from any configured encryption key management
servers because of communication errors between the HMC and encryption key
management server (or servers). Figure 6-26 shows a sample SRC.

Figure 6-26 BE14E008 SRC on DS8000 HMC

򐂰 BE1E2058: Config Error - Global Data Inaccessible, as shown in Figure 6-27.

Figure 6-27 BE1E2058 SRC on DS8000 HMC

216 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
Starting the recovery process
When none of the defined IBM Security Guardium Key Lifecycle Manager key servers are
accessible, the recovery process is started to regain access to the DS8000 data.

To start the recovery process, complete the following steps:

1. Log on to DS8000 GUI as a user with Security Administrator authority and click
Settings → Encryption. As shown in Figure 6-28 (the figures are from the DS GUI R8.5,
but the process is the same), the Encryption keys status is Inaccessible because of the
broken communication between DS8000 and IBM Security Guardium Key Lifecycle
Manager key servers. Click Recover to start the recovery process by using the RK.

Figure 6-28 Starting the recovery process

Chapter 6. Maintaining the IBM DS8000 encryption environment 217

 2. The Recover Storage System window opens (see Figure 6-29). The recovery process
requires the valid RK. Enter the key into the input field (uppercase characters with dash
separation) and click Recover.

Figure 6-29 Entering the recovery key

3. A task completion message is displayed when the recovery task completes.

Figure 6-30 shows that the RK has a pending authorization request that is addressed to
Storage Administrator user.

Figure 6-30 Request recovery authorization pending state

218 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
4. At this stage, the user with Storage Administrator authority must approve this recovery
request. Therefore, log on as a Storage Administrator and click Settings → Encryption.
Expand the Recovery Key Authorization pending (initiate recovery) section. Two
options are available: Authorize and Decline (see Figure 6-31).

Figure 6-31 Starting authorize recovery key update

5. The recovery process is now completed and you are logged off because of the DS8000
restart process.
You can follow the restart process by viewing the DS8000 status messages at the HMC
(see Figure 6-32).

Figure 6-32 Storage facility image restart is in progress

6. Depending on the DS8000 configuration, you must wait several minutes to finish the
initialization. When it is running, log on with as a Storage Administrator user and click
Settings → Encryption. The Encryption keys status changed to the Accessible state,
which means that the DS8000 volumes are online and accessible from hosts
(see Figure 6-33 on page 220).

Chapter 6. Maintaining the IBM DS8000 encryption environment 219

 Figure 6-33 Encryption keys are accessible

Important: This operation is not permanent. The recovered DS8000 is unlocked only until
the next power cycle. However, while the system is running, you have time to repair the
IBM Security Guardium Key Lifecycle Manager key servers and the communication links
between key servers and DS8000. If all the IBM Security Guardium Key Lifecycle Manager
key servers are lost forever (and no backup is available), the encryption must be reenabled
in the future (which is a destructive process) and all the client data must be offloaded first.

Figure 6-34 shows the flowchart and corresponding DS command-line interface (DS CLI)
commands of the recovery process.

Group Recovery Key

State Storage Administrator State Security Administrator

Configured

Initiate Recovery
managereckey
In -action recover
a
c
ce Request Recovery Authorization Pending

s
si Authorize Recovery
b
le Key Update
managereckey
-action authorize
Configured

S F I r e b o o t

Accessible Configured

Figure 6-34 Initiate Recovery flowchart

220 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
6.2.3 Rekeying the recovery key
In the case of a lost RK or an unauthorized person is suspected to gain access to the key, the
Security Administrator can generate a new RK. The old key is revoked and cannot be used
anymore. The name of this process is rekey RK.

To rekey the RK, complete the following steps:

1. Log on to the DS8000 GUI as a user with Security Administrator authority and click
Settings → Encryption. Expand the Recovery Key section and select Rekey, as shown
in Figure 6-35.

Figure 6-35 Rekey recovery key

2. The rekey task starts. After it completes, the task completion message displays (see
Figure 6-36). Click Close to continue.

Figure 6-36 Task completion message

Chapter 6. Maintaining the IBM DS8000 encryption environment 221

 3. The next window (see Figure 6-37) displays the newly generated RK. You must record the
key (select and copy). It is required for validation in step 4. Click Rekey.

Figure 6-37 Rekey recovery key is generated message

4. Although the new key replaces the old one, do not destroy the old key yet because the old
key is still active until the Storage Administrator approves the new RK. The process is
similar to the process of creating a key (see “Creating the recovery key” on page 154).
Verify that the new key is written correctly by entering the key text into the input field and
clicking Test (see Figure 6-38).

Figure 6-38 Entering rekey recovery key

222 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
5. When the RK verification task completes, the confirmation message displays (see
Figure 6-39). Click Close.

Figure 6-39 Verifying rekey recovery key

The result is shown with instructions about the next step (see Figure 6-40).

Figure 6-40 Configure Recovery Key window

6. In the Encryption window (see Figure 6-41), the RK is now in the Authorization pending
(rekey) state, which indicates that any user with Storage Administrator authority must
approve this rekey request. Contact the Storage Administrator user to authorize the
new RK.

Figure 6-41 Authorization pending

Chapter 6. Maintaining the IBM DS8000 encryption environment 223

 7. A user with Storage Administrator authority logs on and clicks Settings → Encryption.
Expand the Recovery Key section and click Authorize, as shown in Figure 6-42.

Figure 6-42 Authorizing the recovery key

8. The RK authorization task starts. After it completes, a window with the confirmation
message opens, as shown in Figure 6-43. Click Close.

Figure 6-43 Task completion message

224 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
Now, only the new RK is valid. The old key is revoked. The state of the key changes back to a
Configured state, as shown in Figure 6-44.

Figure 6-44 Recovery key configured

The flowchart of the rekey RK process is shown in Figure 6-45. The corresponding DS CLI
commands also are provided.

Recovery Key
Storage Administrator State Security Administrator

Configured

Re-key Recovery Key

managereckey
-action rekey

Re-key Verification Pending

Verify Re-key Recovery Key

managereckey
-action verify

Re-key Authorization Pending

Authorize Recovery
Key Update

managereckey
-action authorize

Configured

Figure 6-45 Rekey recovery key flowchart

Chapter 6. Maintaining the IBM DS8000 encryption environment 225

6.2.4 Deleting or deconfigure a recovery key
Deleting the RK might be needed only if the client wants to convert an encryption-enabled
DS8000 to encryption-disabled mode. As a prerequisite, the encryption must be disabled; that
is, delete all DS8000 volumes, ranks, and extent pools.

To delete or deconfigure an RK, complete the following steps:

1. Log on to the DS8000 GUI as a user with Security Administrator authority and click
Settings → Encryption. Click Deconfigure, as shown in Figure 6-46.

Figure 6-46 Deleting or deconfiguring recovery key

2. The Deconfigure Recovery Key task starts. After it completes, the window with the
confirmation message opens, as shown in Figure 6-47. Click Close.

Figure 6-47 Deconfigure Recovery Key window

226 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 Figure 6-48 shows that the Recovery Key State changed to a Deconfigure Key
Authorization Pending state.

Figure 6-48 Deconfigure key authorization pending

3. The system is waiting for a Storage Administrator to authorize this request. A user with the
Storage Administrator authority logs on and clicks Settings → Encryption. Expand the
Recovery Key section and click Authorize. This action completes the process of deleting
RK. The encryption is disabled and starting from this state, non-encrypted arrays, and
ranks can be created on this storage system.

Figure 6-49 shows the flowchart and the corresponding DS CLI commands of the delete
RK process.

Recovery Key
Storage Administrator State Security Administrator

Configured

Delete Recovery Key

rmreckey

Deconfigure Key Authorization Pending

Authorize Recovery
Key Update

managereckey
-action authorize

n/a

Figure 6-49 Delete recovery key flowchart

Chapter 6. Maintaining the IBM DS8000 encryption environment 227

6.3 Recovery key state summary
This chapter introduced RK functions. In most cases, the RK has multiple temporary states.
Figure 6-50 summarizes the possible RK states and their relationships.

Create / Delete Recovery Key Re-key Recovery Key

n/a
New Key Re-key
Verification Pending Verification Pending

New Key Re-key

Authorization Pending Authorization Pending

Deconfigure Key
Authorization Pending
Configured

Request Recovery
Authorization Pending

Validate Recovery Key Initiate Recovery

Figure 6-50 Recovery key states overview

228 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 7

Chapter 7. Local key management

Local key management was introduced within DS8000 Release 9.2. It provides key
management for data-at-rest encryption without the need for external key managers. With
DS8000 Release 10 local key management is part of the DS8A00 Base Function license.

For a small enterprise in which only one or two DS8000 storage servers exist, supporting
external key servers can result in cost and management concerns.

Setting up and running an external key management environment that handles these few
keys and certificates also can incur overhead and lead to even more management,
maintenance, and cost. The key servers must be kept current with fixes and patches to
prevent security breaches.

All keys and certificates in the environment also must be kept in sync between at least two
key servers and another backup of the keys and certificates, and the key servers must be
maintained.

However, in larger environments with multiple DS8000s or other storage systems, such as
FlashSystem or tape, the IBM Security Guardium Key Lifecycle Manager (GKLM) or other
supported external key management encryption is still the recommended solution.
T

Important: Data-at-rest encryption without external key servers (local key management) is
available since DS8000 Release 9.2. With DS8A00 Release 10 it is part of the DS8000
Base License of a new system. For DS8900, the option to use this feature must be
selected during the initial order process of the DS8000, it cannot be activated by using a
license function later.

This chapter includes the following topics:

򐂰 7.1, “Overview” on page 230
򐂰 7.2, “Implementing local encryption” on page 235

© Copyright IBM Corp. 2014, 2021. All rights reserved. 229

7.1 Overview
Local key management for DS8000 provides data-at-rest encryption and a key management
solution to minimize the risk of exposure and to reduce operational costs. It is simple to
configure and offers good security for data on disk, even when a drive is physically removed
with the intent of stealing the data.

However, data can be compromised in the unlikely event that the entire DS8000 storage
system is stolen because the data key is stored in DS8000 central processing servers.
Therefore, the data key is within the confines of the storage system.

Table 7-1 lists the threats that local key management protects against with DS8A00 Release
10.

Table 7-1 Local key management protection with DS8A00 Release 10

Threat Security Details Justification

Data drive theft or Encryption Drive locks on power N/A

failure loss

Data and CEC drive Encryption Encrypted data key Customer provides
theft or failure stored on CEC drive physical security

Note: While local encryption is effective for many scenarios, it cannot protect against the
theft of the entire DS8000 system. External encryption, however, offers additional security
by keeping the encryption keys separate from the storage system. Even if the DS8000 is
stolen, external encryption, with its keys stored on a separate server, prevents
unauthorized access to the encrypted data.

The DS8900 system is using local key obfuscation of the data key, therefore DS8900 does
not protect against a data drive + CEC drive theft.

DS8000 storage systems need to operate autonomously in data centers without human
intervention, especially during startup. To ensure data security, the DS8900 model employs a
technique called local key obfuscation. This involves scrambling the data encryption key on
the storage system itself. This way, even if someone gains unauthorized access to the
system, the key remains protected.

The DS8A00 Release 10 takes a different approach. It uses an encrypted main key that is
generated by a secure component within the system called the CEC service processor. This
key is then used to encrypt data on the storage system. In summary, both the DS8900 and
DS8A00 offer robust data protection, but the DS8A00's encrypted main key provides an
additional layer of security and centralized management.

Important: Local key management is available for data-at-rest encryption only. It does not
support IBM Fibre Channel Endpoint Security Encryption (IFCES) or Transparent Cloud
Tiering Encryption (TCT).

As with for data-at-rest encryption with external key managers the DS8000 ranks must all be
encrypted or non-encrypted for data-at-rest (DAR) encryption with local key management. As
a recommendation, an environment verification process or solution assurance must be
completed to ensure that best practices regarding the configuration of the encryption solution
are taken. This verification can be requested from IBM Lab Services or completed by the
client’s staff.

230 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
7.1.1 Concept and design
In this section, we describe at a high level how the DS8000 local key management creates
the encryption keys by comparing it to the external key management.

External key manager

Figure 7-1 on page 231 shows the key delivery process from an external key manager to the
encrypted drives in the DS8000 (for more information, see Chapter 3, “IBM DS8000
encryption mechanisms” on page 31). An external key server creates the Data Key. It also
provides physical and logical separation of key encrypting keys from the system that uses
them to protect against these two attack vectors.

Figure 7-1 Key delivery from the external key manager

For more information about external key management and creating external keys, see 3.1,
“DS8000 data-at-rest encryption” on page 32.

Local key manager

Figure 7-2 shows the local key creation and delivery to the encrypted disk in DS8000 Release
10 system.

Note: The DS8900 system use an obfuscated data key in the LPAR, therefore a DS8900
doesn’t provide protection against a “data drive + CEC drive” theft.

The data key creation occurs within the DS8000 system. Subsequent steps are the same as
the steps that are shown for the external key server method.

Chapter 7. Local key management 231

 Figure 7-2 Key delivery from the local key manager in DS8000 Release 10 system

No external key managers are required to provide the data key. Key management is a
DS8000 internal process. After a power shutdown, when the DS8000 restarts, it automatically
obtains the Data Key (DK) from its own Key repository. No manual intervention is required.
Within DS8000 Release 10 systems the encrypted Data Key is generated by using a Main
Key stored in the Platform KeyStore (PKS) of the Power 9 service processor. For more
information about PKS, see Platform Key Store.

Key creation
The following steps occur during local encryption activation:
1. The user is creating the key group by using -keyprotocol LOCAL and -type DAR
2. The DS8000 HMC java crypto engine creates a DataKey (DK) by using the Main Key.
3. The DS8000 HMC java crypto engine creates a GroupKey (GK).
4. Both keys are transferred to the DS8000 LPARs (servers that are also known as CPCs).
5. The DS8000 Device Adapter crypto engine creates drive access keys that are derived
from the GK.
6. The GK is wrapped by the DK and stored as encrypted in the DS8000 LPAR key
repository.
7. The DK is stored obfuscated in the LPAR key repository.

Key repository robustness

With external key managers, a set of such managers ensures the high availability of the data
key for the DS8000. Subsequent functions also ensure key and certificate redundancy and
the key availability after a disaster or any other event in which a key, certificate, key manager,
or even the key management environment can be lost or fail.

Local key management must ensure the same level of high availability and disaster recovery
of the data key, which is stored in the internal key repository of the DS8000 LPARs (CPCs). It
achieves this key repository robustness by mirroring the key repository eight times, as shown
in Figure 7-3. The DS8000 reliability, availability, and scalability (RAS) features ensure the key
repository availability during a service action, such as a hardware replacement.

232 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
Figure 7-3 DS8000 Key repository robustness

For robustness of the Main Key in a DS8000 Release 10 system each PKS contains two
copies of Main Key, means four mirrored copies existing in a DS8A00, see the Figure 7-4.

Figure 7-4 DS8A00 R10 PKS robustness for Main Key

Chapter 7. Local key management 233

 Comparing local and external key management
Table 7-2 shows a comparison between local and external key management. Both types of
management features advantages and disadvantages. The local key management does not
protect against the unlikely event of a machine theft because the DK, although obfuscated, is
stored on the storage system servers.

Table 7-2 Local versus external key management DS8000 Release 10 (DS8A00)
Local key management External key management

Must purchase key servers? No Yes

Must purchase local encryption? Yes No

Must configure and maintain key No Yes

server?

Where is data key stored and DS8000 Key Server

generated?

Protects against data drive theft? Yes Yes

Protects against data and CEC drive Yes Yes

theft?

Protects against entire DS8K theft? No Yes

Protects against entire DS8K theft and No No

key server theft?

Supports TCT encryption? No Yes

Supports endpoint security? No Yes

Must maintain a recovery key? No Yesa

Separation of duties? No Yes

AES 256-bit encryption? Yes Yes

FIPS 140-2 Level 1 capable?b Yes Yes

a. The Recovery Key for external encryption can be disabled or configured before making the
encryption implementation and initial logical configuration. It is a customer decision. We highly
recommend configuring a recovery key.
b. See https://www.ibm.com/support/pages/sklm-and-fips-140-2-level-3-compliancy-0.

234 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
7.2 Implementing local encryption
Local data-at-rest encryption must be enabled after the DS8000 is physically installed by the
IBM Support representative and before any logical configuration is done. The activation is a
DSCLI-only procedure and is not supported by the DSGUI. It is supported by embedded CLI.

If you enable local encryption, external key servers cannot be configured for data-at-rest
encryption at the same time. However, you can have external key managers configured at the
same time for Transparent Cloud Tiering encryption (TCT) and IBM Fibre Channel endpoint
security (IFCES)

Switching between internal and external key management is not supported by the DS8000.
Therefore, you cannot have data-at-rest encryption with key managers activated and switch to
data-at-rest encryption without key servers, or vice versa, dynamically. The switch to another
encryption mechanism always requires a deactivation of the current encryption mechanism.
This process is destructive.

Prerequisites
Local data-at-rest encryption includes the following prerequisites:
򐂰 The latest DSCLI version for Release 9.2 is installed (minimum version is 7.9.20.440).
򐂰 The DS8000 must be shipped with microcode Release 9.2 or later
򐂰 Feature code 0405 was ordered for a DS8900 (Note: It is part of DS8A00 base license)
򐂰 External data-at-rest encryption is not activated
򐂰 No logical configuration (volumes, pools, or ranks) exists

7.2.1 Preparing for local encryption

Before activating data-at-rest encryption without key servers, the following conditions must be
reviewed by a local DSCLI administration user:
򐂰 Verify whether the latest DSCLI level is installed by running the ver command in DSCLI
(see Example 7-1).

Example 7-1 DSCLI verification

dscli> ver
Date/Time: September 18, 2024 at 3:05:41 AM EDT IBM DSCLI Version: 7.10.0.749 DS:
-
DSCLI 7.10.0.749
dscli>

The latest DSCLI version is available at IBM Fix Central.

򐂰 Verify the microcode level by using the lsserver command. In the Bundle column,
89.20.x.x or higher must be displayed (see Example 7-2).

Example 7-2 DSCLI microcode level

dscli> lsserver -l
Date/Time: September 18, 2024 at 3:06:13 AM EDT IBM DSCLI Version: 7.10.0.749 DS:

ID Image ID Image Name Power Control SFI State LIC Version OS Version Bundle
Version
==================================================================================
00 1 SF78NKG40ESS01 0 online 7.10.0.749 7.3.2.112 10.0.198.0
01 1 SF78NKG40ESS11 0 online 7.10.0.749 7.3.2.112 10.0.198.0

Chapter 7. Local key management 235

 dscli>

򐂰 Verify that the DS8000 is local encryption is capable (see Example 7-3). The lskey
command includes a new line for local encryption. It must show as On. If it shows as Off,
you cannot activate local encryption for your machine. If the Local Data-at-Rest Encryption
line is missing and you purchased it, you might need to update your DSCLI.

Example 7-3 Verify local encryption

dscli> lskey

Date/Time: September 18, 2024 at 3:07:15 AM EDT IBM DSCLI Version: 7.10.0.749 DS:
Activation Key Authorization Level (TB) Scope
==========================================================================
Base function 1266.6 All
Copy services 1266.6 All
Encryption Authorization on All
Global mirror (GM) 1266.6 All
High Performance FICON for System z (zHPF) on CKD
IBM HyperPAV on CKD
IBM System Storage DS8000 Thin Provisioning on All
IBM System Storage Easy Tier on All
IBM z/OS Distributed Data Backup on FB
Local Data-at-Rest Encryption on All
Metro mirror (MM) 1266.6 All
Metro/Global mirror (MGM) 1266.6 All
Operating environment (OEL) 1266.6 All
Parallel access volumes (PAV) 1266.6 CKD
Point in time copy (PTC) 1266.6 All
RMZ Resync 1266.6 CKD
Transparent Cloud Tiering 1266.6 CKD
z-synergy services 1266.6 CKD

򐂰 Verify that no external data-at-rest encryption exists. Example 7-4 shows that no external
key manager exists.

Example 7-4 Verify no external encryption

dscli> lskeymgr
Date/Time: September 18, 2024 at 3:08:28 AM EDT IBM DSCLI Version: 7.10.0.749 DS:
CMUC00234I lskeymgr: No Key Manager found.

dscli> lskeygrp -l
Date/Time: September 18, 2024 at 3:08:56 AM EDT IBM DSCLI Version: 7.10.0.749 DS:
CMUC00234I lskeygrp: No Encryption Group found.

Attention: You can have key groups with external key management for ENDPOINT and
TCT. However, a key group for DAR prevents the activation of local encryption.

򐂰 Verify that no local configuration exists (see Example 7-5).

Example 7-5 No logical configuration

dscli> lsrank
Date/Time: September 18, 2024 at 3:11:13 AM EDT IBM DSCLI Version: 7.10.0.749 DS:
CMUC00234I lsrank: No Rank found.

236 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
 dscli> lsextpool
Date/Time: September 18, 2024 at 3:11:29 AM EDT IBM DSCLI Version: 7.10.0.749 DS:
CMUC00234I lsextpool: No Extent Pool found.

7.2.2 Implementing local encryption

With all preparation done and all prerequisites fulfilled, local encryption can be implemented.
This section describes:

Activation
Local encryption activation is achieved by using the mkkeygrp command (see Example 7-6). It
requests the data and group key from the internal logical key manager and distributes the
derivatives of the GK to the drives.

Depending on the amount of installed drives, creating the encryption group can take a few
minutes. Complete the following steps:
1. Create the key group 1 (see Example 7-6), which might take a few minutes.

Example 7-6 mkkeygrp LOCAL

dscli> mkkeygrp -keyprotocol LOCAL -type DAR 1
Date/Time: September 18, 2024 at 3:12:18 AM EDT IBM DSCLI Version: 7.10.0.749 DS:
CMUC00358I mkkeygrp: The key server key group 1 has been created

2. Verify that the key group 1 was created (see Example 7-7).

Example 7-7 Group verification

dscli> lskeygrp
Date/Time: September 18, 2024 at 3:14:51 AM EDT IBM DSCLI Version: 7.10.0.749 DS:
ID state reckeystate reckeydate datakeydate keyprotocol type name
========================================================================
1 accessible disabled - 09/18/2024 LOCAL DAR DAR_1

3. Verify the details of the key group 1 (see Example 7-8).

Example 7-8 Key group details

dscli> showkeygrp 1
Date/Time: September 18, 2024 at 3:15:56 AM EDT IBM DSCLI Version: 7.10.0.749 DS:
ID 1
...
state accessible
...
keyprotocol LOCAL
...

In the DSGUI, you are prevented from modifying encryption when local encryption was set up
by using DSCLI and pools exist (see Figure 7-5). If no pools exist, the only possible action
from this DSGUI window is to disable encryption.

Chapter 7. Local key management 237

 Figure 7-5 DSGUI LOCAL enabled

Now you are ready for logical configuration; that is, create ranks, extent pools, and volumes.
When you create the extent pools, you cannot disable the encryption unless you delete all of
the volumes, ranks, and extent pools.

Another option is available to manage the encryption environment. You can rekey the DK. For
more information, see “Re-key Data Key”.

In addition, data-at-rest encryption without key managers eliminates the requirement and
maintenance of a recovery key. During local encryption activation, a Recovery Key disable is
performed automatically, as shown in Example 7-7 on page 237 (reckeystate) and Figure 7-5
(Recovery Key - State: - Disabled).

If no pools exist yet, you can disable the local encryption from the DSGUI. If you disable it
(which might occur by mistake), you can still re-enable it through the DSCLI.

However, when you disable local encryption, the system also automatically re-enables the
Recovery Key. Therefore, to re-enable local encryption, you first must disable the Recovery
Key. To disable the Recovery Key, log on to the DSCLI as secadmin and issue the
managereckey -action disable 1 command. Next, you must log on as storage administrator
and issue the managereckey -action authorize 1 command. Now, you can re-activate the
local key protocol, as shown in Example 7-6 on page 237.

Re-key Data Key

The re-key Data Key (DK) option is available on the DS8000.

You can use this option with the Storage Administrator role to re-key the DK. You might want
to use this option to periodically change the DK; for example, if your company security policy
requires it. Changing the DK with LOCAL encryption is only allowed through DSCLI.

Complete the following steps:

1. Re-key the DK by running the managekeygrp command (see Example 7-9).

Example 7-9 Re-keying the DK

dscli> managekeygrp -action rekey -key data 1
Date/Time: September 18, 2024 9:24:16 AM CEST IBM DSCLI Version: 7.10.0.767 DS:
CMUC00429I managekeygrp: The key for key group 1 has been rekeyed.

2. Verify the new DK (see Example 7-10).

Example 7-10 Old versus new DK

Old DK:

dscli> showkeygrp 1
Date/Time: September 18, 2024 9:25:38 AM CEST IBM DSCLI Version: 7.10.0.767 DS:
ID 1

238 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
numranks -
numpools -
state accessible
reckeystate disabled
reckeydate -
datakeydate 09/18/2024 03:12:41 EDT
grpstatus -
...

New DK:

dscli> showkeygrp 1
Date/Time: September 18, 2024 9:25:38 AM CEST IBM DSCLI Version: 7.10.0.767 DS:
ID 1
numranks -
numpools -
state accessible
reckeystate disabled
reckeydate -
datakeydate 09/18/2024 09:24:18 CEST
grpstatus -
...

Chapter 7. Local key management 239

240 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
Related publications

The publications that are listed in this section are considered suitable for a more detailed
description of the topics that are covered in this paper.

IBM Redbooks
The following IBM Redbooks publications provide more information about the topic in this
document. They might be available in softcopy only:
򐂰 IBM Security Guardium Key Lifecycle Manager, SG24-8472
򐂰 IBM DS8000 and Transparent Cloud Tiering (DS8000 Release 9.1), SG24-8381
򐂰 IBM DS8900F Architecture and Implementation Release 9.1, SG24-8456
򐂰 IBM Fibre Channel Endpoint Security for IBM DS8900F and IBM Z, SG24-8455
򐂰 IBM z15 Technical Introduction, SG24-8850

You can search for, view, download, or order these documents and other Redbooks,
Redpapers, web docs, draft and additional materials, at the following website:
ibm.com/redbooks

Other publications
IBM DS8900 Introduction and Planning Guide, GC27-9560 also is relevant as another
information source.

Online resources
The following websites also are relevant as further information sources:
򐂰 IBM DS8900 Documentation:
https://www.ibm.com/docs/en/ds8900
򐂰 IBM Security Guardium Key Lifecycle Manager Documentation:
https://www.ibm.com/docs/en/sgklm

Help from IBM

IBM Support and downloads
ibm.com/support

IBM Global Services

ibm.com/services

© Copyright IBM Corp. 2014, 2021. All rights reserved. 241

242 IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security
Back cover

REDP-4500-11

ISBN 0738459631

Printed in U.S.A.

®
ibm.com/redbooks