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