5/4/2016 5 Things to Know about DB2 Native Encryption (5 Things To Know IBM Redbooks Blog)

developerWorks Premium Sign up

IBM Sign in  |  Register

Search developerWorks

Profiles  Communities  Apps  English 

Blogs  This Blog Search

My Blogs Public Blogs My Updates

Log in
to participate

5 Things to Know about DB2 Native
Encryption
PhilipMonson  |   Jan 20 2015  |   Visits (8345)  1

Share  

Tweet

Written by Walid Rjaibi, Senior Technical Staff Member & Chief Security Architect, IBM
Information Management
Here are 5 things to know about DB2 Native Encryption available today, January 20th,
from IBM !   Read the announcement here.

1. DB2 Native Encryption is transparent to your applications and schemas

DB2 Native Encryption encrypts your data as it is written to disk. It is implemented within
the DB2 kernel itself. This means that encryption is totally transparent to your
applications and database schemas. This is important particularly when compared to
column level encryption. With column level encryption, your database schemas are
affected as you need to ensure that the column type is compatible with encryption.
Additionally, your application needs to change to add calls for encryption and decryption
of column data values.
https://www.ibm.com/developerworks/community/blogs/5things/entry/5_things_to_know_about_db2_native_encryption?lang=en 1/4
5/4/2016 5 Things to Know about DB2 Native Encryption (5 Things To Know IBM Redbooks Blog)

2. Key Management is secure and transparent

DB2 Native Encryption uses a standard two­tier model for key management. The Data
Encryption Key (DEK) constitutes the first tier. The DEK is the actual key used to perform
data encryption. The DEK is then encrypted with a second key and stored within the
database (or backup image). The second key is called the Master Key (MK) and
constitutes the second tier. In the industry, this model is referred to as envelope
encryption. The MK is stored outside the database in a Public­Key Cryptography
Standards (PKCS#12) compliant keystore. There are two security protection measures
for your keystore. The first is file permissions. You need to make sure that only the DB2
instance owner has read/write access to the keystore. The second is encryption of the
actual content of the keystore. You need to make sure you create your keystore with the
password option. The content of the keystore (i.e., your master keys) is encrypted using a
symmetric key derived from that password using a hashing algorithm. Without the
password, the content of the keystore cannot be decrypted. You have the option to stash
or not stash the password. Stashing the password is good for secure production
environments where you need your DB2 instance to be able to start without human
intervention. You can also choose not to stash the password and provide it only as
needed when starting your DB2 instance. This is possible through the new open
keystore option of the db2start command.  DB2 Native Encryption also allows you to
rotate your database MK to comply with your corporate security policies. You rotate your
database MK by calling the new ADMIN_ROTATE_MASTER_KEY procedure. The
procedure decrypts your database DEK with the old MK and then re­encrypts it with the
new MK. You have 2 options when calling the ADMIN_ROTATE_MASTER_KEY
procedure. You can either provide a label for the desired new MK or use the default.
When using the default, DB2 automatically generates a new master key and adds it to
the keystore on your behalf. Then, it rotates the current database MK to this newly
generated MK.

3. DB2 Native Encryption encrypts both your online data and your backup images

To encrypt your online data, you need to create your database with the new ENCRYPT
option of the CREATE DATABASE command. By default, your database encryption uses
Advanced Encryption Standard (AES) in Cipher­Block Chaining (CBC) mode with a 256
bits key. But other encryption algorithms and key sizes are available. Every database
has its own unique Data Encryption Key (DEK). This is automatic and transparent. For
the Master Key (MK), you have two options. When creating your database, you can either
specify a label for an existing MK or use the default. When using the default, DB2
automatically generates a new master key and adds it to the keystore on your behalf. So
you can choose whether you want each database to have its own unique MK or to share
that MK with other databases. The encryption for backup images is independent of
online database encryption. That is, you can choose to encrypt your backup images
even if your online database is not encrypted. You can request an encrypted backup
image by explicitly specifying the ENCRYPT option of the BACKUP DATABASE
command. Alternatively, you can enforce and automate backup images encryption by
configuring the new ENCRLIB and ENCROPTS database configuration parameters. For
encrypted databases, these two parameters are automatically configured by DB2. This
means that when your database is encrypted, the default is that your backup images are
automatically encrypted. As for online data, every backup image has its own unique

https://www.ibm.com/developerworks/community/blogs/5things/entry/5_things_to_know_about_db2_native_encryption?lang=en 2/4
5/4/2016 5 Things to Know about DB2 Native Encryption (5 Things To Know IBM Redbooks Blog)

DEK. By default, the backup image DEK is encrypted with the database MK although a
different MK can be used. Also, by default a backup image is encrypted with AES 256,
but a different algorithm and key size can be chosen. For both online data and backup
images encryption, you need to make sure you have set up the keystore for your DB2
instance. This is a one time set up where you configure the KEYSTORE_TYPE and
KEYSTORE_LOCATION database manager configuration parameters.
KEYSTORE_TYPE must be set to PKCS12, and KEYSTORE_LOCATION must be set to
the absolute path of your keystore file.

4. DB2 Native Encryption employs certified and compliant cryptography, and
exploits hardware acceleration for cryptographic operations.

Certification and compliance are critical when it comes to encryption solutions. DB2
Native Encryption uses FIPS 140­2 certified cryptographic modules. Additionally, only
cryptographic algorithms that are compliant with NIST SP 800 ­ 131 are employed by
DB2 Native Encryption. Similarly, performance is critical for database workloads. DB2
Native Encryption is capable of exploiting recent innovations in processor technology
such as the Intel AES­NI. This exploitation is automatically detected and transparently
exploited by DB2 Native Encryption.

5. DB2 Native Encryption supports encrypting your existing DB2 databases

It is possible to convert an existing unencrypted database into an encrypted database.
The approach is as follows. First, you take a backup of your existing database using the
BACKUP DATABASE command. Then, you restore that backup image into a new
database using the RESTORE DATABASE command. When invoking the RESTORE
DATABASE command, you specify the new ENCRYPT option. This new option mirrors
exactly the ENCRYPT option of the CREATE DATABASE command. That is, the default is
that your new database will be encrypted using AES 256. But you can choose different
algorithms and key sizes if so desired.
 

https://www.ibm.com/developerworks/community/blogs/5things/entry/5_things_to_know_about_db2_native_encryption?lang=en 3/4
5/4/2016 5 Things to Know about DB2 Native Encryption (5 Things To Know IBM Redbooks Blog)

Add a Comment  More Actions 

Comments (0) Add a Comment   More Actions 

There are no comments to display

Previous Entry  Main  Next Entry

About Feeds Report abuse Faculty

Help Newsletters Terms of use Students

Contact us Follow Third party notice Business Partners

Submit content Like IBM privacy

IBM accessibility

https://www.ibm.com/developerworks/community/blogs/5things/entry/5_things_to_know_about_db2_native_encryption?lang=en 4/4