Using DB2’s New Native Encryption Feature
With fixpack 5 of DB2 10.5, IBM introduced Native Encryption for data at rest in DB2. This is a fairly significant new feature for introduction in a fixpack. It does require separate licensing – either the Advanced Edition of ESE or WSE or the separate purchase of the Native Encryption feature.
DB2 Native Encryption is transparent data encryption for data at rest. It does not encrypt data that is in flight or in memory. There are no application changes that are necesary, and it includes functionality for managing encryption keys. You don’t change data encryption keys, but instead can change the key used to access the data encryption keys – the key encryption key.
DB2 Native Encryption is NOT performance neutral. It is likely to impact performance, and that performance impact is expected to be “less than 100%”. There may be some areas where the impact is more noticeable than others. It largely impacts CPU time. If you implement Native Encryption on a system that already runs at 80% CPU utilization, bad things will likely happen. It is very strongly recommended that you do through performance testing before implementing it in production. The system I’m enabling it on is currently extremely over-sized, averaging LESS than 5% cpu utilization. Because of this, I’m not terribly worried about the impact, but I sure would be with a more reasonably sized system.
The client I’m working with now chose to purchase the Native Encryption feature to use with a standard WSE implementation. The program number to get from IBM is:
5725T25 IBM DB2 Encryption Offering
The code for Native Encryption is included in db2 10.5 fixpack 5, so there is nothing separate to install. To get the license file you’ll need, you’ll need to download the following part from passport advantage:
CN30DML IBM® DB2® Encryption Offering - Quick Start and Activation 10.5.0.5 for Linux®, UNIX and Windows®
If your DB server is not already on 10.5 fixpack 5, you’ll need to upgrade to it before implementing Native Encryption.
The steps for implementing Native Encryption are pretty well laid out in the IBM DB2 Knowledge Center page on Native Encryption. EXCEPT if you copy and paste the command for creating the keystore. I did and got this error:
CTGSK3020W Invalid object: –strong
The problem is documented in the comments on this page. No idea why IBM hasn’t fixed the documentation yet. The ‘-‘ character before two of the options on this command is incorrect in the info center, and it’s barely visable as such. In my steps below, I use the correct kind of dash, so you should be able to copy and paste the below.
Here are the steps for encrypting an existing database – you must do a backup and restore to do it at this time. All actions here are done as the DB2 instance owner.
- Apply the license file – unzip/untar the dowloaded activation file and navigate to db2ef/db2/license, and issue:
db2licm -a db2ef.lic
- Ensure your PATH and library variables are set properly. To do this, I added the following lines to my DB2 instance owner’s .bash_profile (you’d use .profile on AIX):
PATH=$PATH:$HOME/sqllib/gskit/bin export PATH LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$HOME/sqllib/lib64/gskit export LD_LIBRARY_PATH LIBPATH=$LIBPATH:$HOME/sqllib/lib64/gskit export LIBPATH SHLIB_PATH=$SHLIB_PATH:$HOME/sqllib/lib64/gskit export SHLIB_PATH
- Next, issue the command to create your keystore. This is the one with the incorrect dashes in the IBM DB2 Knowledge Center:
gsk8capicmd_64 -keydb -create -db /db2home/db2inst1/pdesignkeystore.p12 -pw MfsWq9UntZGGhe96 -strong -type pkcs12 -stash;
There is absolutely no output returned by this command. You’ll likely want to change the location, and the password you feed into this.
- Update the dbm cfg with the keystore location:
$ db2 update dbm cfg using keystore_type pkcs12 keystore_location /db2home/db2inst1/pdesignkeystore.p12 DB20000I The UPDATE DATABASE MANAGER CONFIGURATION command completed successfully.
- Backup your database
db2 backup db sample to /db2backups compress without prompting
- Drop your database (man, this is hard to do – I still cringe whenever using a drop command)
$ db2 drop db sample DB20000I The DROP DATABASE command completed successfully.
- Restore your database, with the encrypt option
db2 "restore db sample from /db2backups taken at 20150827182456 encrypt without rolling forward without prompting"
Your database is now encrypted, congratulations!
In my case, I’m dealing with a small database, and I didn’t find my restore/encryption time of less than 10 minutes any different than a recent restore of the same database.
Remember DB2 will now encrypt every backup you take with the same encryption options you’ve set in the dbm cfg. This means that part of what you now need to backup is that keystore that you created. I think you’ll also want to store the keystore password somewhere, as you may need it.
I have so far found that these backups take longer than non-encrypted backups. The backup I took of a database before enabling Native Encryption took 4 minutes. The one afterwards took 11 minutes. You may want to test backup duration as a part of your performance testing process.
Next month, I’ll be implementing Native Encryption for an HADR database, and will blog about it, and the extra wrinkles that adds.