Blog

A DB2 Native Encryption Primer

Chief Security Architect IBM Information Management

by Walid Rjaibi, Chief Security Architect for IBM Information Management

Encryption is the process of storing and transmitting data in a form such that only those the data is intended for can read and process. It is an effective way of protecting sensitive information as it is stored on media or transmitted through un-trusted communication channels. Encryption is mandatory for complying with many government regulations and industry standards such as the Payment Card Industry Data Security Standard (PCI DSS).
In an encryption scheme, the data requiring protection (referred to as plaintext) is transformed into an unreadable form (referred to as ciphertext) by applying an encryption algorithm and an encryption key. Encryption keys are randomly generated using a key-generation algorithm. There are two main encryption schemes: Symmetric encryption and asymmetric encryption. In symmetric encryption, the same key is used to encrypt and decrypt a given piece of data. The Advanced Encryption Standard (AES) is an example of a symmetric encryption scheme. In asymmetric encryption, data is encrypted using one key (usually referred to as the public key) and is decrypted using another key (usually referred to as the private key). The Rivest, Shamir, Adleman (RSA) algorithm is an example of an asymmetric encryption scheme. Symmetric encryption schemes are typically used when encrypting large amounts of data such as databases or file systems. Asymmetric encryption schemes also have other important applications, for example digital signatures generation and verification.
DB2 for Linux, Unix and Windows (LUW) has had support for encrypting data transmissions between the database server and an application for several years now. This is the built-in DB2 Secure Socket Layer (SSL) capability. In DB2 10.5 FP5, DB2 adds support for encrypting data in storage. This is the built-in DB2 native encryption capability. DB2 native encryption uses a symmetric encryption scheme for both the database and the backup images. Two symmetric encryption algorithms are supported: AES and 3DES. Encryption is supported for all DB2 configurations including DPF and PureScale. Similarly, encryption is supported for all types of tables including column organized tables (BLU Acceleration). The sections below cover  the top 5 things you need to know about DB2 native encryption.
DB2 transparent data encryption

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 you compare DB2 native encryption 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, column level encryption requires your application to change in order to add calls for encryption and decryption of column data values. With DB2 native encryption, your applications and schemas do not need to change.

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

 

For more information on these new encryption capabilities, visit the DB2 10.5 Knowledge Center watch the encryption presentation by Walid or listen to the Tech Talk on data encryption.

 



9 comments
crussell
crussell moderator

Hi Vinod Duggirala

Here are the answers to your questions from our expert:

1) Native encryption is only for data at rest, and does not apply to data in-transit.  The data in-transit would need separate protection.  Additionally, there's generally no link between encryption settings from one database to another, at least for something like SQL Replication of Q Rep.  Where native encryption can affect replication solutions is access to transaction log files, which are encrypted. Use of the online db2ReadLog API is fully supported and will read decrypted data.   If we are talking about DB2's HADR feature as replication, then there is a link with native encryption.  It's necessary that the master keys used be available at both the primary and secondary servers.  This step is not handled by DB2 and must be performed by the customer.  Any key rotation that happens at the primary will be detected and automatically applied at the secondary.


2) In general there's always an impact from encryption, but how much varies quite a bit depending on workload and system performance.  Backup overhead from encryption is particularly sensitive to how much parallelization can be driven.  Your backup/restore time is going to be largely dependent on that largest tablespace, so a single large tablespace is going to take longer than several smaller
 

 

KaaN2997
KaaN2997

Hi, I have two problems. 


1. First problem is with 'db2start open keystore'. I write about this here http://stackoverflow.com/questions/33765272/db2-0-the-service-has-returned-a-service-specific-error-code-error-while-d . I explain there everything in detail.


2. How to do encrypted backup from unencrypted database ? I tried specify encrypt option on backup command level. Next I also set ENCRLIB and ENCROPTS in db cfg. Nothing works and i have the same error in this two case :

SQL2062N An error occurred while accessing media "db2encr.dll". Reason code:"1". db2encr.dll exists and path is good, otherwise i get other error info.


I wolud appreciate it, if You could help me.

DeniseMorse
DeniseMorse

Hello Walid, enjoyed presentation but have a few questions.

We recently converted character set to Unicode so we could deploy Optim TDM.

Are there any problems using TDM if Native Encryption is in place?

Learning to ask more questions FIRST!

Thanks.

DMorse

kalawat1985
kalawat1985

Hi Walid-


Thanks for the detailed explanation on encryption. For storing the keystore, can we use any hardware security module for ex - AWS CloudHSM.


-Amit

crussell
crussell moderator

Hi Vipin001 


Here are the answers to your questions:

1. how can we cross check the data is stored in encrypted form in database ? 

One option is to go to your tablespace container files and run OS commands like strings for example. If the data is in clear text you will be able to see table data. Otherwise, you will see cipher text. You want to do this on a test system.


2. what is the impact on database sizing if we do encryption ? do we need to increase column length or encryption will be done outside of database ? 

DB2 Native Encryption is done by DB2 deeply in the kernel so it is totally transparent to your database schemas. Because of where the encryption is done, there is no impact on database sizing. You don't need to change anything related to your column lengths or schemas.

Vipin001
Vipin001

Hi Walid, its a wonderful article and giving depth knowledge here. 


after reading it few questions are coming in my mind,

1. how can we cross check the data is stored in encrypted form in database ?

2. what is the impact on database sizing if we do encryption ? do we need to increase column length or encryption will be done outside of database ?


Regards,

Vipin 

crussell
crussell moderator

Hi Marif 


Here is the answer to your question:
Here is the answer.

- If the goal is to encrypt the existing database, then you need to take a backup of that database and then restore into a new database while specifying the new ENCRYPT option on the restore command.

- If the goal is to encrypt a backup image, then you can do so even when the underlying database is not encrypted. You need to configure your instance with a keystore as you would do when you want to create an encrypted database. Then, you call the backup command with the options to encrypt that backup.

marif
marif

Hi Walid,  Good to see this article. I created db2 (ver 10.5) database with default option. so no encryption was done.  Can we encrypt existing db2 database so our backup (image) are proted over the line?


Thanks in advance.

Arif

Trackbacks

  1. […] Walid Rjaibi’s post on Native Encryption […]