Anda di halaman 1dari 84

Exploring IBM DB2

Encryption Technology
Presenter: Marcin Baster
DB2 LUW Advanced Support Analyst
IBM Analytic Platform Client Success and Smarter Support

2015 IBM
Corporation

Disclaimer

The information contained in this presentation is provided for informational purposes only.
While efforts were made to verify the completeness and accuracy of the information contained in this
presentation, it is provided as is, without warranty of any kind, express or implied.
In addition, this information is based on IBMs current product plans and strategy, which are subject to
change by IBM without notice.
IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this
presentation or any other documentation.
Nothing contained in this presentation is intended to, or shall have the effect of:
Creating any warranty or representation from IBM (or its affiliates or its or their suppliers and/or
licensors); or
Altering the terms and conditions of the applicable license agreement governing the use of IBM
software.
Performance is based on measurements and projections using standard IBM benchmarks in a
controlled environment. The actual throughput or performance that any user will experience will vary
depending upon many factors, including considerations such as the amount of multiprogramming in the
user's job stream, the I/O configuration, the storage configuration, and the workload processed.
Therefore, no assurance can be given that an individual user will achieve results similar to those stated
here.

2015 IBM
Corporation

PART ONE

Encryption highlights

March 26, 2015

2015 IBM
Corporation

Agenda
 IBM DB2 Encryption Offering
Data encryption requirements
Offering overview
Functionality Highlights

 Encryption overview
Encryption keys, algorithms, and security strengths
Encryption key managment

 Key management
GSKit Overview
Keystore and key creation, deletion, reporting, exporting, and importing

 Encrypting databases
 Backup and restore
 Utilities, diagnostics and other considerations
2015 IBM
Corporation

Protecting Data Is More Than Good Business It's the LAW!


Korea:
3 Acts for Financial
Data Privacy

Russia:
Computerization & Protection of Information
/ Participation in Int'l Info Exchange

Japan:
Guidelines for the
Protection of Computer
Processed Personal Data

Hong Kong:
Privacy Ordinance

New Zealand:
Privacy Act

United Kingdom:
Data Protection
Act
EU:
Protection
Directive

Poland:
Polish
Constitution
Germany:
Federal Data Protection
Act & State Laws

China
Commercial
Banking Law

Indonesia:
Bank Secrecy
Regulation 8

Singapore:
Monetary Authority of
Singapore Act

Vietnam:
Banking Law

Philippines:
Secrecy of Bank
Deposit Act

Australia:
Federal Privacy
Amendment Bill

Switzerland:
Pakistan:
Federal Law on
Banking Companies
Data Protection
Ordinance
Israel:
Protection of
India:
Privacy Law
SEC Board of
India Act

South Africa:
Promotion of Access
to Information Act

Taiwan:
Computer- Processed
Personal Data
Protection Law

Canada:
Personal Information Protection
& Electronics Document Act

USA:
Federal, Financial & Healthcare
Industry Regulations & State Laws

Mexico:
E-Commerce Law
Brazil:
Constitution, Habeas Data &
Code of Consumer Protection &
Defense

Argentina:
Habeas Data Act

Colombia:
Chile:
Political Constitution
Protection of
Personal Data Act Article 15
2015 IBM
Corporation

Data Encryption Requirements


 Meet compliance requirements
Industry standards such as PCI DSS
Regulations such as HIPAA
Corporate standards

 Protect against threats to online data


Users accessing database data outside the scope of the DBMS

 Protect against threats to offline data


Theft or loss of physical media

 Reduce the cost of security and compliance


No third-party add-on tools required
Easy to consume by DB2 bundlers such as ISVs

2015 IBM
Corporation

IBM DB2 Encryption Offering


 Simple to deploy in cloud, software, or appliance
 Encrypts online data and backups
 Transparent
No application or schema changes

 Built-in secure and transparent key management


 Compliant, e.g.
NIST SP 800-131 compliant cryptographic algorithms
Uses FIPS 140-2 certified encryption

 Runs wherever DB2 runs!


Exploits available HW acceleration (AES encryption only)
Intel supported

2015 IBM
Corporation

IBM DB2 Encryption Offering Licensing


 License available for these editions:
DB2 Enterprise Server
DB2 Workgroup Server
DB2 Express Server

 Included in these Editions


DB2 Advanced Enterprise Server
DB2 Advanced Workgroup Server
Express-C

2015 IBM
Corporation

Create database Highlights


 Encrypting a new database is as simple as using the new ENCRYPT option
CREATE DATABASE mydb ENCRYPT

 Default is AES 256

 Other Algorithms and key lengths are possible


CREATE DATABASE mydb ENCRYPT CIPHER AES KEY LENGTH 128
CREATE DATABASE mydb ENCRYPT CIPHER 3DES KEY LENGTH 168

2015 IBM
Corporation

Backup highlights
 Leverages existing interface for calling out to an external library
 Same encryption algorithm choices as for database
 Non-encrypted databases can also have backups encrypted
 Automated backup encryption through use of new ENCRLIB/ENCROPTS
database configuration parameters
Use of encryption for backups enforced by SECADM
Automation turned on by default when an encrypted database is created

2015 IBM
Corporation

Key Management Highlights


 Industry standard 2-tier model
Actual data is encrypted with a Data Encryption Key (DEK)
DEK is encrypted with a Master Key (MK)
 DEK is managed within the database, MK is managed externally
 MK is stored within a PKCS#12 compliant keystore
Encrypted keystore file containing master keys
 Keystore backup is the responsibility of the customer
 Support for master key rotation through new procedure
ADMIN_ROTATE_MASTER_KEY()

2015 IBM
Corporation

Database Objects that are Encrypted


 All user data in a database is encrypted

All table spaces (system defined and user defined)


All types of data in a table space (LOB, XML, etc. )
All transaction logs including logs in the archives
All LOAD COPY data
All LOAD staging files
All dump .bin files
All backup images

 Additional objects that are encrypted


Encryption keys in memory, except for the time they are actually used
Keystore passwords when transparently communicated from one member/ partition to
another upon restart

2015 IBM
Corporation

PART TWO

Encryption overview

March 26, 2015

2015 IBM
Corporation

Encryption Key
 The sequence that controls the operation of the
cryptographic algorithm
 The number of bits in a key is called key length
 The length of the key reflects the difficulty to decrypt a plaintext encrypted
with that key
 A 256 bit key has 2256 distinct values in its key space
Key

Plaintext

Key

Ciphertext
Encryption

Encryption

Plaintext

2015 IBM
Corporation

Symmetric Encryption Algorithms


 A cryptographic algorithm that uses the same key for both encryption and
decryption
 AES and 3DES are the most famous symmetric
encryption algorithms
Encryption

Original Message

Secret Key

Encrypted Message

Decryption

Encrypted Message

Secret Key

Original Message

2015 IBM
Corporation

Asymmetric Encryption Algorithms


 A cryptographic algorithm that uses one key for encryption and another key
for decryption
The encryption key is called a public key
The decryption key is called a private key
The public key and private key are different but
mathematically related

 It is not feasible to derive the private key from the public key in any
reasonable time
 RSA, ECC, and Diffie-Hellman are the most famous examples
Public Key

Plaintext

Private Key

Ciphertext
Encryption

Encryption

Plaintext

2015 IBM
Corporation

Approximate Equivalence in Security Strength

Symmetric Key
Length (AES)

Asymmetric Key
Length (RSA)

Asymmetric Key
Length (ECC)

1024

160

2048

224

128

3072

256

192

7680

384

256

15360

512

2015 IBM
Corporation

Encryption Key Wrapping


 The process of encrypting one key with another key
 The key encrypting key is typically referred to as a master key
 The master key is typically stored separately from the data system
 The top drivers for this 2- tier encryption approach are:
Security: Compromise of the data system does not mean compromise of the data as
the master key is stored outside the data system
Performance: Complying with key rotation requirements does not mean re-encrypting
the actual data; only the data encryption key is re-encrypted with a new master key

 DB2 Implements the industry standard 2-tier model


Actual data is encrypted with a Data Encryption Key (DEK)
DEK is encrypted with a Master Key (MK)

2015 IBM
Corporation

Encryption Key Management


 Refers to the secure management of keys during their lifecycle
Creation, distribution, expiration, deletion, backup, restore, etc.
Protection of encryption keys including access control and encryption
 Public Key Cryptography Standard (PKCS) #12:
A password-protected keystore with a format for storing encryption keys
Local keystore file
Stores master keys
Might recognize this as keystore for SSL certificates

2015 IBM
Corporation

Master Key and Data Key Relationships


A Keystore is created locally and has a strong password associated with it:
The keystore must be available to the DB2
instance in order to get the Master Keys
required for encryption and decryption.

PassW0rd

Keystore

Master Keys with Labels are created in order to encrypt database keys:
Key Label

DB2 can generate Master Keys and


Labels automatically for the user.
Creating your own labels will require
that you generate an encryption key.

Key

SECRET.DB2INST1.2015.02.01

Keystore

Database Keys are generated internally by DB2 and are used to encrypt the database:
Key Label
DB2 Key

Key

SECRET.DB2INST1.2015.02.01
The DB2 encryption key is itself
encrypted within the database image
by using the Master Key found within
the keystore.
2015 IBM
Corporation

PART TWO

Master Key Management

March 26, 2015

2015 IBM
Corporation

IBM Global Security Kit


 DB2 Encryption uses the IBM Global Security Kit (GSKit) for
key management and encryption
This component is installed as part of DB2
Located in the /sqllib/gskit directory
GSKit libraries are used to create, store, and manage the keys required for encrypting
databases
FIPS 140-2 certified encryption library
gsk8capicmd_64 is command line tool to manage the keystore

 Three GSKit command options are used for manipulating keys


keydb
Used to create a keystore for use by DB2

secretkey
Use for add master key labels to a keystore

cert
Used for listing, deleting, importing, and exporting master key labels

2015 IBM
Corporation

Creating a Keystore (keydb)


 A keystore must be created and registered before using encryption
A keystore must be created using the gsk8capicmd command
gsk8capicmd_64 keydb create[-drop] db pw strong type stash

 Parameters
Keyword

Use

-keydb

Indicates that the command will apply to a keystore.

-create or -drop

Create (or drop) a keystore.

-db

Keystore filename. The keystore must be available to the DB2 instance.

-type

Must be pkcs12.

-pw

Password for the keystore (at least 14 characters long when -strong is used).

-strong

Check that the password is non-trivial.

-stash

Create a stash file to allow for commands to run without prompting for password.

 Example

gsk8capicmd_64 -keydb create -db ~/db2/db2keys.p12


-type pkcs12
-pw "Str0ngPassw0rd"
-strong -stash

2015 IBM
Corporation

Stash File Considerations


 When the -stash option is specified during the create action, an obfuscated
version of the keystore password is stashed in a file:
<key database name>.sth

 A stash file is used as an automatic way of providing a password


If a keystore password was not provided during db2start, the password will be retrieved
from the stash file

 The stash file can only be read by the instance owner


Not stashing the password enhances security if the instance owner account becomes
compromised
This additional security must be weighed against any requirements that the DB2
instance can start without human intervention
If the password is not stashed, you cannot access an encrypted database until you
provide the keystore password.

2015 IBM
Corporation

Starting DB2 without a Stash File


 DB2 will start normally (no error condition returned) if a stash file is not
present in the system
 Database activation, or applications connecting to encrypted databases will
encounter an error condition:
SQL1728N The command or operation failed because the keystore could not be
accessed. Reason code "3".

 The db2start command must be re-executed with the open keystore


option to enable access to encrypted databases
db2start open keystore USING KeySt0rePassw0rd

 To avoid placing the password on the command line:


db2start open keystore will prompt for password
For scripts of other executables, supply the password through either a
temporary file or open file descriptor
db2start open keystore PASSARG FILENAME:<value> | FD:<value>

2015 IBM
Corporation

Creating Master Keys


 DB2 will generate master keys for you automatically during:
Database Creation
Key rotation
Restoring into a new database

 DB2 master keys are always AES 256-bit


This key is used to encrypt the database key, not the actual database

 You may want to create a key with a specific label for a number
of reasons:
You want to keep track of the Master Key Labels and their corresponding keys for
offsite recovery without having the entire keystore available on the
backup site
You have an HADR pair that must have synchronized keys
You are encrypting a backup for an unencrypted database

2015 IBM
Corporation

Creating a Master Key Label


 A keystore must be created before adding a Master Key Label
Also require write access to the keystore
The gsk8capicmd is used to create a new master key
gsk8capicmd_64 secretkey add db label file -stashed

 Parameters
Keyword

Use

-secretkey

Indicates that the command will insert a new master key into an existing keystore

-add

Add a key to the keystore (Note: You can't drop a key using this command)

-db

Keystore filename

-label

Name of the master label (text string)

-pw

Password for the keystore if the stash file is not available

-file

Location of the AES key that will be used to encrypt the database key

-stashed

Use the stashed password to access the keystore

 Example
gsk8capicmd_64 secretkey add -db ~/db2/db2keys.p12
-label secret.key
-stashed
-file ~/db2/mysecretkey

2015 IBM
Corporation

Generating an AES Key for a Master Key Label


 A secret key needs to be generated by the user before adding a master key
to the keystore
The secret key is used to encrypt the database key
The strength of the secret key has no relationship to the actual encryption that takes
place within the database
Recommendation is to use the highest level of AES encryption (256) for the database
key (same as DB2)
Overhead is insignificant since the database key is not frequently decrypted

 Generating a random key


A key needs to be 16, 24, or 32 bytes wide
Corresponds to 128, 192, or 256-bit AES keys

On Linux, UNIX, and AIX use the following command to generate a 32-byte random
string (which represents a 256-bit AES key)
head c 32 /dev/random >~/db2/mysecretkey

2015 IBM
Corporation

Delete or List Master Key Labels


 You can delete a master key or query the contents of a keystore by using the
cert option of the GSKit command
gsk8capicmd_64 cert [-list|-delete]

 Parameters
Common Keywords

Use

-db

Absolute location of the keystore

-stashed

Use the stashed password to access the keystore

-pw

Password for the keystore if the stash file is not available

Delete

Use

-delete -label

Name of the master key label (text string)

List

Use

-list

List all of the master keys in the keystore

 Examples
gsk8capicmd_64 cert list -db ~/db2/db2keys.p12 stashed
gsk8capicmd_64 cert delete db ~/db2/db2keys.p12 -stashed
-label secret.key

2015 IBM
Corporation

Exporting a Master Key Label


 A secure method of moving a key (to import to another keystore) involves
the use of the cert option of the GSKit command
gsk8capicmd_64 cert -export db label target target_pw

 Parameters
Keywords

Use

-export

Tells the command to export a master key into a file

-db

Absolute location of the keystore

-stashed

Use the stashed password to access the keystore

-pw

Password for the keystore if the stash file is not available

-label

Name of the master key label (text string)

-target

Name of the file to place the contents of the keystore into

-target_pw

Password used to encrypt this file

-target_type

Type of file (pkcs12)

 Example
gsk8capicmd_64 cert export -db ~/db2/db2keys.p12 -stashed
-label secret.key target ~/db2/exportedkey.p12 target_type pkcs12
-target_pw Str0ngPassw0rd

2015 IBM
Corporation

Importing a Master Key Label


 The import option on the cert command is used to import the master key
into an existing keystore (usually at a backup site)
Note that the target file is the keystore on the backup system
gsk8capicmd_64 cert -import db label target target_pw

 Parameters
Keywords

Use

-import

Tells the command to import a master key into a file

-db

Absolute location of the key that we want to import (not the current keystore)

-stashed

Use the stashed password to access the keystore

-pw

Password for the key that we exported from the original keystore

-label

Name of the master key label that we want to import

-target

Name of the local keystore file to place the contents of the master key into.

-target_pw

Password for the keystore file, but you can use the stashed option

-target_type

Type of file (pkcs12)

 Example
gsk8capicmd_64 cert import -db ~/db2/exportedkey.p12 -stashed
-pw Str0ngPassw0rd -label secret.key
target ~/db2/db2keys.p12 target_type pkcs12

2015 IBM
Corporation

Registering the Keystore in DB2


 After creating a keystore file, the DB2 instance must be updated with the
location and type of keystore
Two new configuration parameters
KEYSTORE_TYPE Type of keystore being used (either NULL or PKCS12)
KEYSTORE_LOCATION Absolute location of the keystore (or NULL if none)

 A DB2 instance can only have one keystore


The system could have keystores for other applications, but DB2 only supports one
keystore at the instance level

 Best practice is to update both parameters simultaneously


UPDATE DBM CFG USING
KEYSTORE_TYPE PKCS12
KEYSTORE_LOCATION "/home/db2inst1/db2/db2keys.p12"

 To remove a keystore from an instance, set the values to NONE


and NULL
UPDATE DBM CFG USING KEYSTORE_TYPE NONE KEYSTORE_LOCATION NULL

2015 IBM
Corporation

PART TWO

Encrypting DB2 Databases

March 26, 2015

2015 IBM
Corporation

Encrypting Online Data


 Once the keystore has been created and registered, and (optional) a master
key created, you can encrypt a database
 Encryption can be requested via a new option on the CREATE DATABASE
command:
CREATE DATABASE mydb ENCRYPT;

 The default encryption is AES 256, but users can select other algorithms and
key lengths if they so desire
CREATE DATABASE mydb
ENCRYPT CIPHER AES KEY LENGTH 128;
CREATE DATABASE mydb
ENCRYPT CIPHER 3DES KEY LENGTH 168;
CREATE DATABASE mydb
ENCRYPT CIPHER AES KEY LENGTH 256
MASTER KEY LABEL mylabel;

2015 IBM
Corporation

Encryption Options
 The ENCRYPT keyword has three options
CIPHER

This is the type of encryption to use


AES (Advanced Encryption standard) or 3DES (Triple Data Encryption Standard)
AES is the default if CIPHER is not specified
AES is implemented in some hardware so potentially more efficient to use

KEY LENGTH
For AES encryption this can be 128, 192, or 256 bits
Default length is 256 for AES, and it can only be 168 for 3DES

MASTER KEY LABEL


The name of the master key found within the keystore that will encrypt the database
encryption key

 A master key label is optional


DB2 will generate a master key if one is not supplied on the CREATE DATABASE
command
The name of the generated master key is:
DB2_SYSGEN_<instance>_<database>_<timestamp>

2015 IBM
Corporation

Determine Current Database Encryption Settings


 The SYSPROC.ADMIN_GET_ENCRYPTION_INFO table function can be used to
determine the encryption settings for a database
Column

Contents

ALGORITHM

Encryption algorithm used

ALGORITHM_MODE

Encryption algorithm mode used

KEY_LENGTH

Encryption key length

MASTER_LEY_LABEL

Master key label associated with the master key used

KEYSTORE_NAME

Absolute path of the keystore file location

KEYSTORE_TYPE

Type of keystore

KEYSTORE_HOST

Host name of the server where the keystore file is located

KEYSTORE_IP

IP address of the server where the keystore file is located

KEYSTORE_IP_TYPE

Type of the IP address of the keystore (IPV4 or IPV6)

PREVIOUS_MASTER_KEY_LABEL

Master key label before the last master key rotation took place - If a master key rotation has not occurred,
this value is the master key label

ROTATION_TIME

Timestamp when the last master key rotation took place

AUTH_ID

Authorization ID that was used during the last master key rotation

2015 IBM
Corporation

Key Rotation
 The process of changing encryption keys for compliance purposes
It requires decrypting any key encrypted with the old key and then re- encrypting it with
the new key
The data does not get re-encrypted!

 The key rotation frequency depends on the compliance driver


This generally ranges from once every 3 months to once per year

 The key rotation requirement can be thought of as analogous to the


requirement to change passwords every 90 days
Key Label

SECRET.DB2INST1.2015.02.01

Master Key

DB2 Key

Key Label

Master Key

DB2 Key

SECRET.DB2INST1.2015.03.05

The current Master Key is used to


to decrypt the DB2 encryption key

Now a new Master Key is used to encrypt


the DB2 encryption key
2015 IBM
Corporation

Key Rotation Procedure


 The SYSPROC.ADMIN_ROTATE_MASTER_KEY procedure can be used to
change the database key to comply with key rotation requirement
You must be connected to the database to run this command
CALL SYSPROC.ADMIN_ROTATE_MASTER_KEY('newMasterKeyLabel')

 The SYSPROC.ADMIN_ROTATE_MASTER_KEY procedure re-encrypts the


database key with the new master key
 DB2 will automatically generate the new master key unless you override it
with a key label
 Key rotation is logged in the db2diag.log file:
grep A 3 "Key Rotation" ~/sqllib/db2dump/db2diag.log
Key Rotation successful using label:
DATA #2 : String, 46 bytes
DB2_SYSGEN_db2inst1_SECRET_2015-02-09-05.03.12

2015 IBM
Corporation

PART TWO

Backup and Restore Using Encryption

March 26, 2015

2015 IBM
Corporation

Backup Encryption Settings


 Two database parameters can be used to automatically control the
encryption of backups
ENCRLIB Which encryption library to use
ENCROPTS What options to pass to the encryption routine

 ENCRLIB is set to one of the following values (full path required)


Operating System

Compression

Encryption

Both

Windows

db2compr.dll

db2encr.dll

db2compr_encr.dll

Linux

libdb2compr.so

libdb2encr.so

libdb2compr_encr.so

AIX

libdb2compr.a

libdb2encr.a

libdb2compr_encr.a

 ENCROPTS is a string with the following optional values


Each option is separated by a colon (:) in the string (Cipher=AES:Length=256)
Option

Purpose

Values

Cipher

Type of encryption algorithm to use

AES, 3DES

Length

Length of the encryption key

AES: 128, 192, 256 3DES: 168

Master Key Label

Optional name of the Master Key Label used to encrypt the database key String

2015 IBM
Corporation

Backup Encryption Settings for Encrypted Databases


 ENCRLIB and ENCOPTS are automatically set when a new database is
created with encryption
Both values are set according to the ENCRYPT options that were used at database
creation time
Any database backup will be encrypted automatically with these setting
No requirement for additional encryption keywords on the BACKUP command
Only a SECADM can override the database encryption parameters

 Overriding the backup encryption level requires that SECADM update the
ENCROPTS settings
A database backup can have a different level of encryption than the
database itself
The ENCROPTS can also be set manually on the BACKUP command but that would
require that the database ENCROPTS parameter be set to NULL
Supplying no ENCROPTS on the BACKUP would result in default encryption settings
(AES 256)
Setting ENCRLIB to NULL and ENCROPTS to NULL will allow the DBA to backup the
database with NO ENCRYPTION

2015 IBM
Corporation

Backup Encryption Settings for Normal Databases


 ENCRLIB and ENCROPTS can be set to for databases that have no
encryption settings
Set the values according to the ENCRLIB and ENCROPTS options that you want for the
database
Once these parameters are set by the SECADM, they "lock in" the encryption of the
backup
The backup options cannot be overridden on the BACKUP command unless
ENCROPTS is null (for encryption options) or ENCRYPT is null for no encryption

 Setting ENCRLIB/ENCROPTS at the database level ensures that backups will


always be encrypted
DBAs can run the BACKUP command with no additional options required
for encryption

 Example:
BACKUP DATABASE SECRET TO /HOME/DB2INST1/DB2
ENCRYPT ENCRLIB 'libdb2encr.so'
ENCROPTS 'Cipher=AES:Key Length=256'

2015 IBM
Corporation

Backup Encryption Summary


 The following chart summarizes the combination of settings of ENCRLIB
and ENCROPTS that result in encrypted backups
If ENCRLIB is set, backups will always be encrypted
DBAs can only override the level of backup encryption if ENCROPTS is
set to NULL
A backup will be decrypted when ENCRLIB and ENCROPTS are NULL

2015 IBM
Corporation

Restoring Encrypted Backup to an Existing Database


 Restoring a backup by replacing an existing database requires no special
parameters
Keystore must contain the master key label that was used to generate this backup
copy
Standard databases with an encrypted backup would restore back to an unencrypted
copy
RESTORE DATABASE SECRET FROM /home/db2inst1/db2

 RESTORE will use the existing database encryption settings to encrypt the
data being restored
The encryption settings can not be changed when restoring into an existing database

2015 IBM
Corporation

Restoring Encrypted Backup to an New Database


 Restoring a backup to a new copy of the database requires that the
ENCRYPT parameter be added to the command
DB2 needs to create the database before restoring the encrypted copy, and without the
ENCRYPT keyword, the database would not be secure
Parameters for the ENCRYPT keyword are identical to creating an
encrypted database
RESTORE DATABASE SECRET FROM /home/db2inst1/db2
ENCRYPT
CIPHER AES
KEY LENGTH 128
MASTER KEY LABEL secret.key

 Encryption settings can be different from the backup copy settings


The parameters used with the ENCRYPT option can specify a different cipher, key
length, or master key label
If you need to duplicate the exact encryption settings, use the show master key
details option of the RESTORE command

2015 IBM
Corporation

Determining the Backup Encryption Settings


 When restoring a backup as a new database, the database will need to be
created with encryption enabled
You can chose to change the cipher, key length, and master key label settings
There is an option to query the encryption settings of the backup image

 The RESTORE command can extract the backup encryption settings


The RESTORE command with the show master key details option will prompt the
user if they want to overwrite an existing copy of the database
Accepting the overwrite will NOT overwrite the database
RESTORE DATABASE SECRET FROM /home/db2inst1/db2
ENCROPTS 'show master key details'

 Encryption information from the backup will be placed into the db2dump
directory
File with the following name will be generated
<DATABASE>.#.<instance>.<partition>.<timestamp>.masterkeydetails

You can then use ENCROPTS 'Master Key Label=xxx' option on the RESTORE
command to decrypt the backup with the proper master key

2015 IBM
Corporation

Backup/Restore Encrypted Database Examples


Create, Backup, and Restore an Encrypted Database
CREATE DATABASE SECRET ENCRYPT
BACKUP DATABASE SECRET ON /db2
RESTORE DATABASE SECRET FROM /db2

Restore to a new copy of the Encrypted Database


RESTORE DATABASE SECRET FROM /db2 ENCRYPT

Restore to a new copy of the Encrypted Database with different encryption options
RESTORE DATABASE SECRET FROM /db2 ENCRYPT CIPHER AES KEY LENGTH 192

Restore to a new copy of the Encrypted Database with no encryption


RESTORE DATABASE SECRET FROM /db2 NO ENCRYPT

Extract the Master Key Label information from the backup image
RESTORE DATABASE SECRET FROM /db2 ENCRYPT
ENCROPTS 'show master key details'

Backup Encrypted Database with different ENCROPTS settings


UPDATE DATABASE CONFIG USING ENCROPTS NULL IMMEDIATE
BACKUP DATABASE SECRET ON /db2 ENCROPTS 'Ciper=AES:Key Length=128'

Backup Encrypted Database with no encryption at all


UPDATE
ENCRLIB NULL ENCROPTS NULL IMMEDIATE
BACKUP DATABASE
DATABASE CONFIG
SECRET USING
ON /db2

2015 IBM
Corporation

Backup/Restore Regular Database Examples


Create, Backup, and Restore a Regular Database
CREATE DATABASE NOSECRET
BACKUP DATABASE NOSECRET TO /db2
RESTORE DATABASE NOSECRET FROM /db2

Restore to a new copy of the database and have it encrypted using the defaults
RESTORE DATABASE NOSECRET FROM /db2 ENCRYPT

Restore to a new copy of the Encrypted Database with different encryption options
RESTORE DATABASE NOSECRET FROM /db2 ENCRYPT CIPHER AES KEY LENGTH 192

Backup a regular database using Encryption


BACKUP DATABASE NOSECRET TO /db2 ENCRYPT
ENCRLIB 'libdb2encr.so'
ENCROPTS 'Cipher=AES:Key length=128:Master Key Label=secret.key'

Restore the Encrypted backup to a regular database


RESTORE DATABASE NOSECRET FROM /db2

Backup regular database using ENCRLIB and ENCROPTS settings


UPDATE DATABASE
ENCRLIB
ENCROPTS
BACKUP DATABASE

CONFIG USING
'/home/db2inst1/sqllib/lib/libdb2encr.so'
'Cipher=AES:Key length=128:Master Key Label=secret.key'
NOSECRET TO /db2

2015 IBM
Corporation

Restoring an Encrypted Backup to a Different Server


 Create the database and do a backup
CREATE DATABASE SECRET ENCRYPT
BACKUP DATABASE SECRET TO /primary

 Extract the Master Key Label for the keystore


gsk8capicmd cert export db ~/db2/primary.p12 stashed
-label secret.key target secret.p12
-target_type pkcs12 target_pw Str0ngPassw0rd

 Copy the master key to the backup site and add the key to the backup site
keystore
gsk8capicmd cert import db secret.p12 pw Str0ngPassw0rd
stashed -label secret.key
-target ~/db2/backup.p12
-target_type pkcs12

 Restore the database


RESTORE DATABASE SECRET FROM /backup

2015 IBM
Corporation

PART TWO

Utilities, Diagnostics and


Special Considerations

March 26, 2015

2015 IBM
Corporation

Migration of Existing Data


 Take a standard non encrypted backup of the database
 Restore the backup into a new database using the newly added ENCRYPT
clause to enable the desired encryption settings

Backup

Restore

RESTORE DATABASE SECRET FROM /home/db2inst1


ENCRYPT
CIPHER AES
KEY LENGTH 192
MASTER KEY LABEL secret.key

2015 IBM
Corporation

HADR Considerations
 Normally both primary and secondary databases are encrypted
Possible to only have the primary or secondary encrypted
On HADR startup, an admin warning message will be produced

 Secondary site will be set up as new a database


Specify encryption options as part of the RESTORE command
Keystore needs to be available locally
Create keystore and master key label at primary and secondary site (The Master Key Label must be the same)
gsk8capicmd keydb create db ~/db2/db2keys.p12 type pkcs12 pw Str0ngPassw0rd strong stash
head c 32 /dev/random > ~/db2/secretkey.p12
gsk8capicm secretkey add db ~/db2/db2keys.p12 stashed label secret.key file ~/db2/secretkey.p12
Move keystore to secondary site, or export master key and import into secondary site

Update local and backup instance with the location and type of keystore
UPDATE DBM CONFIG USING
KEYSTORE_NAME /home/db2inst1/db2/db2keys.p12 KEYSTORE_TYPE PKCS12

Create the primary database using the master key label, setup HADR, and then backup the database
CREATE DATABASE SECERT ENCRYPT MASTER KEY LABEL secret.key
Setup of HADR primary
BACKUP DATABASE SECRET TO ~/db2

Restore to a new copy of the Encrypted Database at the secondary site


RESTORE DATABASE SECRET FROM /db2 ENCRYPT CIPHER MASTER KEY LABEL secret.key
Setup of HADR standby

2015 IBM
Corporation

Tooling Changes
 Tools with encryption support

db2cklog
db2flsn
db2LogsForRfwd
db2ckbkp
db2adutl
db2dart

 These tools will use the keystore specified in the DBM CFG
KEYSTORE_LOCATION parameter
Additional arguments used to connect to the keystore if the password is
not stashed
-kspassword password
-kspassarg fd:file_descriptor
filename:file_name
-ksprompt

2015 IBM
Corporation

Database Encryption Scenario


 Database Encryption Implementation

Configure the keystore for the instance (one-time set-up)


Specify encryption when creating a database
Specify encryption when taking a backup (default for encrypted databases)
Specify encryption when restoring a backup

 Database Encryption Operational Management


Regular backup and safe storage of the keystore
Rotate the database master key as dictated by the compliance requirements
If password protection of the keystore was selected, manage the password carefully
including changes as dictated by the compliance requirements

The customer is responsible for backing


up the keystore!

2015 IBM
Corporation

PART THREE

Deep Dive

March 26, 2015

2015 IBM
Corporation

GSKit Global Security Kit

Encryption library provided to all IBM products from a team in Tivoli

Shared libraries and executables shipped with DB2


Currently used for existing encryption and SSL support
Upgraded to new version 8.0.50.31
Use gsk8ver_64 to get version
New version has support for secret keys required by this solution
Consult docs on how to set $PATH and $LD_LIBRARY_PATH
For this solution, we are interested in the command line tool gsk8capicmd_64
to manage keystores

While not specific to this solution, the requirement of a new version


might increase problems with interoperability with other products.
Most likely manifest itself as a db2diag.log entry about missing functions, or
inability to load a GSKit library

56

March 26, 2015

2015 IBM
Corporation

PKCS12 Keystore

DB2 stores Master Keys outside of the database/instance


Stored in a PKCS12 keystore file on disk (.p12)
PKCS12 Public Key Crypto-system #12
RSA standards for public key cryptography

Keystore is always encrypted and the key is derived from a password


Contains both public and private (secret) keys referenced by a label
Public keys SSL
Secret Keys Native encryption

57

March 26, 2015

2015 IBM
Corporation

PKCS12 Keystore Stash File

A stash file contains an obfuscated version of the password


It's NOT encrypted, it's similar to plaintext

Allows instance owner to access the keystore without providing the


password
Permissions same as keystore, only accessible by the instance owner

Allows automated db2start, such as after a crash, to proceed without a


user manually entering a password

Should provide sufficient security for majority of customers


Not mandatory, for those that feel it's inadequate, can manually enter
password on db2start. Easy to recreate if you remember the password

58

March 26, 2015

2015 IBM
Corporation

PKCS12 Keystore Backing up the keystore


The customer is responsible for backing up the keystore and stash file
Failure to backup keystore can result in the inability to access all
encrypted data, including logs and backups

Keystore must be backed up whenever a new key is added.

There is no backdoor for IBM to access data.

When DB2 inserts a new Master Key into the keystore, it logs an admin
message to remind customer to backup
2015-01-12-12.03.57.408278 Instance:gstager Node:000
PID:20764(db2agent (instance)) TID:3443517760 Appid:*LOCAL.gstager.150112170356
bsu security sqlexInsertNewMasterKeyLabel Probe:519 Database:
ADM8014W Backup the keystore.

59

March 26, 2015

2015 IBM
Corporation

PKCS12 Keystore- DBM CFG / Creation


Two new parameters tell DB2 about the keystore

KEYSTORE_TYPE PKCS12
KEYSTORE_LOCATION fully qualified path of the keystore

Creates the keystore.p12 file, along with keystore.sth stash file


gsk8capicmd_64 -fips true -keydb -create -db keystore.p12 -pw
Str0ngPassw0rd -strong -type pkcs12 -stash;

File permissions of keystore


When created, only the creator will have read/write permission
Instance owner should be the one to create it
File permissions should never be changed

60

March 26, 2015

2015 IBM
Corporation

PKCS12 Keystore Creating keys


In general, you should rely on DB2 to create the master keys and
associated label. This can happen during:
Create db
Key rotations
Restore (creating new db)

The exceptions when the customer needs to manually create master keys
and labels:
HADR
Sharing encrypted backups without exposing all keys in the keystore

61

March 26, 2015

2015 IBM
Corporation

PKCS12 Keystore Manually creating a key


Customer is responsible for secure random number generation
Example: head -c 32 /dev/random > mysecretfile
Must be exactly 128, 192 or 256 bits (16,24, or 32 bytes)
This is the level of AES encryption used to encrypt the DEK

gsk8capicmd secretkey add db ccardskeystore.p12


stashed label mylabel.mydb.myinstance.myserver
file mysecretkeyfile;

62

March 26, 2015

2015 IBM
Corporation

Common Label Problems


Only specify a label when that label already exists in the keystore
For example, you can specify a master key label on
ADMIN_ROTATE_MASTER_KEY, but it must already exist in the keystore
or else and error SQL1729N will occur.

General rule is to never delete labels from a keystore


Are you sure you don't need access to that 5 your old backup encrypted with
this label?
Key rotation does not guarantee current label has stopped being used. Main
example is log file, only new log files will use new label.

For missing label, why do you expect the label to be available?


Was the backup copied from another system, HADR
Use the following to list labels in the keystore:
gsk8capicmd_64 -cert -list all -db keystore.p12 -stashed

63

March 26, 2015

2015 IBM
Corporation

Common label problems


Don't create the same label multiple times, or re-create a label with a name
already used
Ex. Create A, delete A, then re-create A
Ex. Create label A in keystore 1, create label A in keystore 2, then backup
database using keystore 1, and restore using keystore 2

They might have the same label, but will have a different key. DB2 can
detect this:

FUNCTION: DB2 UDB, bsu security, sqlexDecryptDEK, probe:0


MESSAGE : ZRC=0x805C08F4=SQLEX_MASTER_KEY_FOR_LABEL_CHANGED
"The key for the master key label has changed."
checksum: 3026379365
version: 1
masterKeyLabel: mylabel.mydb.myinstance.myserver
masterKeyLength: 32

Most keystore problems reported as SQL1728N


Bad values for KEYSTORE_LOCATION
Bad file permissions
Password required to open keystore
64

March 26, 2015

2015 IBM
Corporation

Accessing Keystore without a stash file


When a stash file is not used, a password must be provided to db2start to
open the keystore
db2start open keystore using <password>
Can be done after DB2 has started, it will just update the password
Similarly if the password changes, just re-issue db2start
Sent to each member that is started during db2start
Example:
db2start
db2 connect to mydb
Fails with SQL1728 RC 3 password is missing
db2start open keystore using thepassword (note no db2stop)
db2 connect to mydb succeeds
Note the error is only when we access the encrypted database
65

March 26, 2015

2015 IBM
Corporation

Db2start keystore password recovering from


crashes
For DPF and SD, DB2 makes a best effort to maintain the keystore password in
memory. If at least one member is active that knows the password, the system can
continue running, as members will ask each other for the password (RPC). If all
members that knew the password crash, a manual db2start will need to be issued to
provide the password
Restart automation like TSA does not have the password

Several options are provided to ensure password is not seen during ps


output, history etc.
db2start open keystore will prompt for password, in the same way CLP would prompt
for password during connect
Interactive use
db2start open keystore PASSARG <passarg>
Passarg = fd:<file descriptor> where password has been written to open pipe
Passarg = filename:<filename> where the first line of the file contains the
password
Used for scripts/executables where prompting is cumbersome
66

March 26, 2015

2015 IBM
Corporation

Backup and Restore - errors


$ db2 "backup db testdb compress comprlib 'libdb2encr.so' compropts 'Master Key

Label=no_such_label'" ;
SQL2062N An error occurred while accessing
media "libdb2encr.so". Reason code: "1".
$ db2 "backup db testdb compress comprlib 'libdb2encr.so' compropts 'Cipher=AES:Key
Length=257:Master Key Label=label_mihai'" ;
SQL2062N An error occurred while accessing media "libdb2encr.so". Reason code:
"1".

2015-01-09-15.56.29.008456
Instance:miacob
Node:000
PID:6131(db2bm.41.0 (TESTDB))
TID:3330271552 Appid:*LOCAL.miacob.150109205625
bsu security InitEncryption Probe:911
Database:TESTDB
ADM8013E The command or operation failed due to an error in the encryption or
compression library.

2015-01-09-15.59.59.878013
Instance:miacob
Node:000
PID:6131(db2bm.152.0 (TESTDB))
TID:3300911424 Appid:*LOCAL.miacob.150109205957
bsu security InitEncryption Probe:911
Database:TESTDB
ADM8013E The command or operation failed due to an error in the encryption or
compression library.
67

March 26, 2015

2015 IBM
Corporation

Backup and Restore


2015-01-09-15.56.28.959004-300 I55540E2155
LEVEL: Error
PID : 6131
TID : 46912963078464 PROC : db2sysc
INSTANCE: miacob
NODE : 000
DB : TESTDB
APPHDL : 0-23
APPID: *LOCAL.miacob.150109205625
AUTHID : MIACOB
HOSTNAME: hotel51
EDUID : 125
EDUNAME: db2bm.41.0 (TESTDB)
FUNCTION: DB2 Common, Cryptography, cryptP12KSGetSecretKey, probe:479
MESSAGE : ECF=0x90000644=-1879046588=ECF_CRYPT_KEYSTORE_LABEL_NOT_FOUND
The requested label does not exist
DATA #1 : unsigned integer, 4 bytes
117
DATA #2 : String, 13 bytes
no_such_label
CALLSTCK: (Static functions may not be resolved correctly, as they are resolved to the nearest symbol)
[0] 0x00002AAAB6215CAB /home/miacob/sqllib/lib64/libdb2osse.so.1 + 0x221CAB
[1] 0x00002AAAB6215AE3 ossLog + 0xA3
[2] 0x00002AAAAF64328E cryptLogKMErrorString + 0x3E
[3] 0x00002AAAAF643BDB _Z22cryptP12KSGetSecretKeyP26cryptPKCS12KeyStoreContextPKcPPhPjbb + 0x13B
[4] 0x00002AAAB0248566 _Z26sqlexGetMasterKeyFromLabelPKctPtPhS1_bbP5sqlca + 0x1B6
[5] 0x00002AAAB025E11E _Z31sqlexFillOutDEKStorageForBackupttjmP15sqlexDEKStorageP20cryptBlockCipherInfoP5sqlca + 0x29E
[6] 0x00002AAAB026693E _Z14InitEncryptionPK13COMPR_DB2INFOP12COMPR_PIINFOPP8COMPR_CB + 0x53E
[7] 0x00002AAAB951000D InitCompression + 0x5D
[8] 0x00002AAAB03C49EF _Z22InitCompressionWrapperPv + 0x2F
[9] 0x00002AAAB0D681C3 sqloInvokeInterruptibleFunction + 0x123
[10] 0x00002AAAB03C4AE2 _Z19InitCompressionCallPFiPK13COMPR_DB2INFOP12COMPR_PIINFOPP8COMPR_CBES1_S3_S6_ + 0x62
[11] 0x00002AAAB03ABB49 _Z24sqluBMInitComprFrameworkP14SQLU_BUFMAN_CB + 0x2C9
[12] 0x00002AAAB03A9A4E _Z10sqluBMInitP14SQLU_BUFMAN_CBP12SQLU_BAGT_CB + 0x19E

68

March 26, 2015

2015 IBM
Corporation

Backup and Restore


2015-01-09-15.59.59.865699-300 I84795E1813
LEVEL: Error
PID : 6131
TID : 46912933718336 PROC : db2sysc
INSTANCE: miacob
NODE : 000
DB : TESTDB
APPHDL : 0-26
APPID: *LOCAL.miacob.150109205957
AUTHID : MIACOB
HOSTNAME: hotel51
EDUID : 178
EDUNAME: db2bm.152.0 (TESTDB)
FUNCTION: DB2 UDB, bsu security, sqlexParseENCROPTSforBackup, probe:360
MESSAGE : ZRC=0x805C08F0=-2141452048=SQLEX_MASTERKEY_BAD_LENGTH
"The command or operation failed because the master key does not match a supported key length."
DATA #1 : String, 29 bytes
Unsupported option:Key Length
CALLSTCK: (Static functions may not be resolved correctly, as they are resolved to the nearest symbol)
[0] 0x00002AAAB0265DEE _Z27sqlexParseENCROPTSforBackupijPcPtS0_PjS1_PP16MASTER_KEY_LABELP5sqlca + 0x73E
[1] 0x00002AAAB02669AA _Z14InitEncryptionPK13COMPR_DB2INFOP12COMPR_PIINFOPP8COMPR_CB + 0x5AA
[2] 0x00002AAAB951000D InitCompression + 0x5D
[3] 0x00002AAAB03C49EF _Z22InitCompressionWrapperPv + 0x2F
[4] 0x00002AAAB0D681C3 sqloInvokeInterruptibleFunction + 0x123
[5] 0x00002AAAB03C4AE2 _Z19InitCompressionCallPFiPK13COMPR_DB2INFOP12COMPR_PIINFOPP8COMPR_CBES1_S3_S6_ + 0x62
[6] 0x00002AAAB03ABB49 _Z24sqluBMInitComprFrameworkP14SQLU_BUFMAN_CB + 0x2C9
[7] 0x00002AAAB03A9A4E _Z10sqluBMInitP14SQLU_BUFMAN_CBP12SQLU_BAGT_CB + 0x19E
[8] 0x00002AAAB03ACA91 _Z8sqlubbufP8sqeAgent + 0x351
[9] 0x00002AAAB0104AE8 _Z26sqleSubCoordProcessRequestP8sqeAgent + 0xE8
[10] 0x00002AAAADDC1464 _ZN8sqeAgent6RunEDUEv + 0xA44
[11] 0x00002AAAAF575067 _ZN9sqzEDUObj9EDUDriverEv + 0xF7
[12] 0x00002AAAAED61983 sqloEDUEntry + 0x303

69

March 26, 2015

2015 IBM
Corporation

Backup and Restore

db2 "restore db testdb encrlib 'libdb2encr.so' encropts 'show master


key details'"

SQL2539W The specified name of the backup image to restore is the


same as the name of the target database. Restoring to an existing
database that is the same as the backup image database will cause
the current database to be overwritten by the backup version. Do you
want to continue ? (y/n) y

DB20000I The RESTORE DATABASE command completed


successfully.

(Does not perform a restore)

70

March 26, 2015

2015 IBM
Corporation

Backup and Restore

/home/miacob/sqllib/db2dump:$ cat
TESTDB.0.miacob.DBPART000.20150109155924.masterKeyDetails

KeyStore Type: PKCS12


KeyStore Location: /home/miacob/sqllib/keystore.p12
KeyStore Host Name: hotel51.torolab.ibm.com
KeyStore IP Address: 9.26.120.67
KeyStore IP Address Type: IPV4
Encryption Algorithm: AES
Encryption Algorithm Mode: CBC
Encryption Key Length: 192
Master Key Label: label_mihai

71

March 26, 2015

2015 IBM
Corporation

Backup and Restore

db2 "restore db testdb encrlib 'libdb2encr.so' encropts 'master key


label=label_mihai' encrypt master key label label_jack"

Note that at restore time we will try the labels used to encrypt the
backup image one by one if a label is not specified via 'encropts'.

72

March 26, 2015

2015 IBM
Corporation

Backup and Restore: sharing encrypted backups


 Scenario: take an encrypted backup on system A and restore it on
system B (without sharing the master key label used to encrypt the
source database on system A)
 Create a new master key label to be used for the backup:
label4systemb
 Extract the key from the keystore on system A, securely copy it
to system B, import it into the keystore on system B.
 Take the encrypted backup and specify 'master key
label=label4systemb' via encropts
 Copy the encrypted backup to system B
 Restore the encrypted backup on system B

73

March 26, 2015

2015 IBM
Corporation

Backup and Restore: sharing encrypted backups


 Common problem: the master key label used to encrypt the backup is not
available in the keystore on the target system B.

 How to diagnose:
 Look at the db2diag.log for the real error
(SQLEX_KEYSTORE_LABEL_DOES_NOT_EXIST)
 Use 'show master key details' via encropts on the restore command to
generate the .masterKeyDetails file in db2dump and find out the
master key label used to encrypt the backup and the location of the
keystore on the source system.
 Extract this key from the source system keystore, securely copy it to the
target system, import it into the keystore, re-run the restore.

74

March 26, 2015

2015 IBM
Corporation

Restore 'no encrypt' clause


 To ensure backup images containing encrypted databases are not
inadvertently restored without encryption, this clause was introduced.

 This is applicable to any database level images, not for tablespace (uses
existing db's setting) or snapshot restore (uses setting in image).
 Examples:

BAD Note: sample does not exist prior to the restore (e.g. moving to new system)

db2 restore db sample taken at 20150110121447


SQL1743N The RESTORE command failed because the database in the backup image
is encrypted but the existing database on disk is not encrypted.
Note: Folks found the above wording confusing, changing to 'source db at the time of backup was
encrypted but the target database is not encrypted' in later FP.

75

March 26, 2015

GOOD db2 restore db sample taken at 20150110121447 no encrypt


DB20000I The RESTORE DATABASE command completed successfully.

2015 IBM
Corporation

Setting up HADR and encryption


The primary hadr database may or may not be setup with database encryption and the
standby database can utilize different encryption settings. Note that when one is not
encrypted an admin message will be produced to warn as such. o setup a standby
database, generally, you will be restoring into a new database, implying you need to
specify the desired encryption options at restore time, if this is not done, no encryption
will be used on the standby database.
Recommend procedure for setting up HADR system:
PRIMARY:
- db2 update dbm cfg using keystore_name <key store path on primary>
- db2 create db sample encrypt ...

master key label <X>

- ... setup for hadr primary ...


- db2 backup db sample

STANDBY:
- db2 update dbm cfg using keystore_name <key store path on standby>
- db2 restore db sample encrypt ...

master key label <X>

- ... setup for standby primary

76

March 26, 2015

2015 IBM
Corporation

Key Rotation and HADR


In this procedure it is important to first add the new master label in the standby's key
store and then proceed to add the new master label in the primary's key store, and only
then carry out the key rotation operation. This ensures there is no scenario in which an
archived log with the new master key label is required on the standby prior to the
standby's key store having an entry for this new label.
STANDBY:
- Add new master key label <Y> to the key store on the standby database.

PRIMARY:
- Add new master key label <Y> to the key store on the primary database.
- CALL SYSPROC.ROTATE_MASTER_KEY('<Y>');

How can the keystores at the primary and standby be kept in sync:

77

March 26, 2015

Automatically: Set up some file level synchronization mechanism such as


rsync or similar / or physically share the key.
Manually: Add keys to both (just to standby first).

2015 IBM
Corporation

HADR Key Rotation Error Diagnostics


 Key Rotation on Standby happens asynchronously, but driven by key rotation
on primary system.

 If the key rotation on standby has failed, an ADM message is logged:


2015-01-12-15.55.23.398487

Instance:geoffrey

PID:17361(db2hadrs.0.0 (HADRDB))

TID:1065347392

High Availability Disaster Recovery

ADM12517E

Node:000
Appid:none

hdrEdu::hdrEduS Probe:21719

Database:HADRDB

A master key rotation to label

"DB2_SYSGEN_geoffrey_HADRDB_2015-01-12-15.54.26" failed on the HADR standby


with zrc "-2141452059". The standby system disconnects to retry key rotation.

 Extra diagnostics from db2diag.log messages to see cause of key rotation


failure. Most common is master key label not present in standby keystore.

78

March 26, 2015

2015 IBM
Corporation

HADR Monitoring flags


 Can check monitoring flags from either primary or standby systems through
db2pd -hadr option:
HADR_STATE = REMOTE_CATCHUP_PENDING
HADR_FLAGS = STANDBY_RECV_BLOCKED STANDBY_KEY_ROTATION_ERROR

 STANDBY_KEY_ROTATION_ERROR flag indicates that there has been an


key rotation error on the standby system and receiving of new HADR
messages has been blocked.

 If problem is resolved within timeout period (30 mins), the systems will reconnect and HADR continues. Otherwise, HADR will shut down and users
have to restart HADR after issue is resolved.

79

March 26, 2015

2015 IBM
Corporation

HADR Common Errors

Customer creates primary DB using automatically generated master key


label.

Determine label using (db2pd -encr / table function, covered in later section)
Extract from primary system's keystore.
Import into standby system's keystore.
Use this label when restoring backup to create standby database

Customer creates standby DB using automatically generated master key


label
The standby will immediately drive key rotation as it detects primary is using a
different label.
This will fail as the label does not exist on the standby site (hadr will retry
several times but after bring down the system).
Add label and restart.

80

March 26, 2015

2015 IBM
Corporation

Tooling Changes (See SES for Details)

Tools with encryption support

81

March 26, 2015

db2pdlog
db2fmtlog
db2cklog
db2flsn
db2LogsForRfwd
db2UncompressLog
db2ckbkp
db2adutl
db2dart

2015 IBM
Corporation

Tools with encryption support


 The following new options are added to specify the keystore password
(exact syntax may vary in different tools):
Keystore Password
|-+- -kspassword ---------+------ password ------+-------------------|
+- -kspassarg ----------+- fd:file_descriptor -+
+
'- filename:file_name -+
+- -ksprompt-----------------------------------'

 Only need to specify these options if the keystore password is not


stashed.

 These tools will use the keystore specified in the DBM CFG
KEYSTORE_LOCATION parameter. There's no way to specify
another keystore file through the tools.

82

March 26, 2015

2015 IBM
Corporation

Run-time PD functions
 DB CFG Encrypted database to see if db is encrypted
 ADMIN_GET_ENCRYPT_INFO() table function
 New db2pd option -encryptioninfo (-enc)
db2pd -db dynam -encryptioninfo
Database Member 0 -- Database DYNAM -- Active -- Up 0 days 00:00:16 -- Date 2015-01-09-14.24.13.275668
Encryption Info:
Object Name:
Object Type:

DYNAM
DATABASE

Encyrption Key Info:


Encryption Algorithm:
Encryption Algorithm Mode:
Encryption Key Length:
Master Key Label:
Master Key Rotation Timestamp:
Master Key Rotation Appl ID:
Master Key Rotation Auth ID:
Previous Master Key Label:

AES
CBC
256
DB2_SYSGEN_geoffrey_DYNAM_2015-01-09-14.20.58
2015-01-09-14.20.59.000000
*LOCAL.geoffrey.150109192055
GEOFFREY
DB2_SYSGEN_geoffrey_DYNAM_2015-01-09-14.20.58

KeyStore Info:
KeyStore Type:
KeyStore Location:
KeyStore Host Name:
KeyStore IP Address:
KeyStore IP Address Type:
83

March 26, 2015

PKCS12
/home/geoffrey/sqllib/keystore.p12
hotel80.torolab.ibm.com
9.26.120.37
IPV4
2015 IBM
Corporation

THANK YOU

84

March 26, 2015

2015 IBM
Corporation

Anda mungkin juga menyukai