Using Fortanix Data Security Manager with IBM DB2

1.0  Introduction

IBM Db2® is a family of hybrid data management products offering a complete suite of AI-empowered capabilities designed to help you manage both structured and unstructured data on-premises as well as in private and public cloud environments. Db2 is built on an intelligent common SQL engine designed for scalability and flexibility.

1.1  Why use Fortanix Data Security Manager (DSM) with IBM DB2

Db2® native encryption uses a two-tier approach to data encryption. Data is encrypted with a Data Encryption Key (DEK), which is in turn encrypted with a Master Key (MK). The encrypted DEK is stored with the data while the MK is stored in a keystore external to Db2.

Db2 native encryption ensures that the DEK is never exposed outside of the encrypted database, transaction log, or backup file. There are no interfaces provided to access the DEK in either its clear text or encrypted forms. As the MK is stored in a different location from the encrypted data, the chance of the encrypted DEK being concurrently exposed with the MK used to encrypt it is very unlikely. Since the risk of the DEK being exposed is extremely low, the need to rotate it is negligible. The rotation of the MK, which is used to protect the DEK, can be done efficiently without the need to decrypt and re-encrypt the data.

The Db2 database system supports SSL, which means that a Db2 client application that also supports SSL can connect to a Db2 database by using an SSL socket. CLI, CLP, and .Net Data Provider client applications and applications that use the IBM® Data Server Driver for JDBC and SQLJ (type 4 connections) support SSL.

2.0  Prerequisites

  • Fortanix DSM
  • IBM DB2
  • Access to create a certificate for KMIP Server

3.0  Adding App in Fortanix Data Security Manager

There are two ways to create an app in Fortanix DSM:

3.1  Using Fortanix DSM On-Premises Deployments

  1. Add an app in Fortanix DSM in an appropriate group or a new group. For instructions on how to add a group or app, refer to the Fortanix DSM Getting Started Guide. IBM_group.png
    Figure 1: Create New App
  2.  Once you have added the application, note down its App ID by clicking the icon for “Copy UUID” to copy the App UUID as shown below. You will need this App ID for the certificate. App-UUID.png
    Figure 2: Copy app UUID
  3. If an App / Client needs to authenticate to Fortanix DSM using the only certificate, then the App ID needs to be embedded in the certificate in one of the following ways:

    • Provided as the value of a custom OID in the certificate
    • Standard human-readable UUID encoding: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx provided as the value of CN.
    • CN example:
  4. Change the authentication method of the Fortanix DSM App created above to ‘Certificate’ and click SAVE.
  5. Continue to Section 4.1 for authentication using a client certificate.
  6. Click UPDATE to update the authentication method.

3.2  Using Fortanix DSM SaaS Deployment

To configure IBM DB2 wizard in Fortanix DSM SaaS:

  1. Sign up at
  2. Log in to the Fortanix DSM UI.
  3. Click the Integrations tab in the left panel.
  4. On the Integrations page, click ADD INSTANCE on the IBM DB2 wizard.
  5. Enter the details as shown in the screenshot below:Add_instance.png
    Figure 3: Add instance
    1. Add Instance: This is the name to identify the instance created.
    2. Authentication method: Select the desired authentication method. There are two options to choose from:
      1. API key: This method is used to authenticate the application with the API Gateway.
      2. Client Certificate: This method is used to authenticate the application with Fortanix DSM using a Client Certificate. To upload the client certificate, click UPLOAD CERTIFICATE. Alternatively, the client certificate can be pasted in the field provided.
  6. Continue to Section 4.1 for authentication using client certificate.
  7. Click SAVE INSTANCE. With saving an instance a new Group, an App, and Keys are created within Fortanix DSM.

3.2.1 IBM DB2 Wizard Instance Detailed View

In the instance detailed view page, the created instances are listed as shown below.
In the instance details, you will notice the following:

  • Credentials: This is the App authentication method used.
    • Click CERTIFICATE to download the Client Certificate. This is applicable only if the App authentication method used is Client Certificate.
    • Click COPY API KEY to copy the API key. This is applicable only if the App authentication method used is API Key.
  • MANAGE: Click MANAGE to manage the keys created.
  • Instance status: To disable the instance created, click the toggle Disabled.
  1. To delete the instance created click the delete_button.pngbutton. Note that deleting an instance will delete the App, Group, and all security objects belonging to the instance and all key material will become inaccessible.detailed_instance.png
    Figure 4: Detailed view

4.0  Configuration on IBM DB2

4.1  Create Folders for Certificates and Config File

  1. Log in to the IBM DB2 machine and log in as the DB user as shown in the following screenshot. 3.png
    Figure 5: Login to IBM DB2 as a DB user
  2. Next, create folders so as to bifurcate the certificates and config file.
    1. KMIP (For config file)
    2. SDKMS_Certs (For all the certificates)
  3. Create a self-signed certificate and make sure that you should have the App-ID handy as we need to update the Common Name for the self-signed certificate.
    • Change directory to SDKMS_Certs and run the following command:
    openssl req -newkey rsa:2048 -nodes -keyout private.key -x509 -days 365 -out certificate.crt
    Figure 6: Create self-signed certificate 5.png
    Figure 7: Certificate generated
  4. Paste or upload the certificate that was generated in Step 3 above in the Upload Certificate text box in the Fortanix DSM UI for App authentication and save the details. 

4.2  Updating the Certificate in Fortanix DSM

To update the certificate in the authentication method:

  1. Make sure you change the configuration to KMIP from the default, which is, REST API.
  2. Now import the private key and certificate into the SSL key store, you need to combine the private key and certificate into one.
    • The certificate should come first, followed by the private key. Combine them as follows.
    • We give this entry label which will be used in the KMIP configuration file. Make a note of the label.
    • Depending on where you are running this command from, tweak the path of the "sdkms.pem" file.
      cat certificate.crt private.key > sdkms.pem
      Figure 8: Combine cert and private key
  3. Verify the private key matches the Certificate and CSR.
    openssl x509 -noout -modulus -in certificate.crt | openssl md5

4.3  Create the SDKMS-KMIP.P12 and Stashed File

Run the following command:

gsk8capicmd_64 -keydb -create -db "sdkms-kmip.p12" -pw "sdkms-kmip.pWd" -type pkcs12 -stash

In case you get an error that the gsk8capicmd_64 command is not found; you need to export the libraries for gsk8capicmd_64 from sqllib.

Linux Environments:

export LD_LIBRARY_PATH=$HOME/sqllib/lib64/gskit:$LIBPATH

export PATH=$HOME/sqllib/gskit/bin:$PATH

Re-run the above command to create .p12 and stash file. In the following screenshot sdkms-kmip.p12 and sdkms-kmip.sth file is created.

Figure 9: Create .p12 and stash file

4.4  Add Client Cert and Key to SSL Keystore

  1. Add client cert and key to the SSL keystore by running the following command:
    gsk8capicmd_64 -cert -add -db "sdkms-kmip.p12" -stashed -label "sdkms_app_cert" -file "sdkms.pem"
  2. Find the CA certificate from your Fortanix DSM installation and copy it into a file CA.pem. Please note that if your CA certificate has a chain then the complete chain must be copied into this file. You can get the complete chain from your Fortanix DSM browser by going to your Fortanix DSM URL and then view certificates and download the certificate chain.
    Since we are using "https://<fortanix_dsm_url>",  let us get the CA Certificate from the UI.
  3. In the IBM shell, create the CA.pem file using the following command.
    touch CA.pem
  4. Perform vi on CA.pem and then paste the certificate information to give the following output. CA.pem will contain the intermediate+ root certificate. 9.png
    Figure 10: Output of CA.pem

4.5  Import CA Certificate into SSL Keystore

Import CA Certificate into the SSL keystore by running the following command:

gsk8capicmd_64 -cert -add -db "sdkms-kmip.p12" -stashed -label "trustedCA" -file CA.pem

4.6  List Certificate in the Keystore

List certificate in your keystore to verify everything is fine by running the following command

gsk8capicmd_64 -cert -list -db sdkms-kmip.p12 -stashed

Figure 11: List certificates

Create a KMIP config file in the KMIP folder. In the following example, it is kmip.cfg:



Figure 12: Create a KMIP config file

  •  Update the path of SSL_KEYDB and SSL_KEYDB_STASH based on your setup.
  • SSL_KMIP_CLIENT_CERTIFICATE_LABEL must match the label you used when you created the key store.
  • Set value of MASTER_SERVER_HOST to point to your Fortanix DSM cluster.

4.7  Configure a DB2 Instance to Use a Keystore

  1. To configure a Db2 instance to use a keystore for native encryption, you need to set two database manager configuration parameters: keystore_type  and keystore_location.
  2. For a centralized keystore, where the key manager product uses the Key Management Interoperability Protocol (KMIP), set keystore_type to "KMIP", and set keystore_location to the absolute path and file name of the centralized keystore configuration file.
  3. To do this, run the following command:
    db2 update dbm cfg using keystore_location /mnt/blumeta0/home/db2inst1/KMIP/kmip.cfg keystore_type kmip
    Figure 13: Set keystore type and location
  4. To get the keystore changes to take effect, we need to restart the DB2 again.
    The command to stop the DB2:
  5. The command to start the DB2:
    Figure 14: Stop and start the DB2
  6.  Verify that the dbm cfg is set correctly by running the following command. Look at value of Keystore type and keystore location.
    db2 get dbm cfg
    Figure 15: Verify database manager configuration

4.8 Renewing Certificate

  1. To renew the certificate, run the following command using the existing private key.
    openssl req -key private.key -new -x509 -days 700 -out renewcertificate.crt
    Figure 16: Renew certificate DB2_Certificate_generated.png
    Figure 17: Certificate generated
  2. Go to the Fortanix DSM UI and update the app certificate. Paste or upload the new certificate that was generated in the previous step. DB2_Certificate_update.png
    Figure 18: Update application authentication to certificate
  3. Import the private key and certificate into the SSL key store. You must combine the private key and certificate into one.
    cat renewcertificate.crt private.key > sdkms.pem
  4. Verify that the private key matches the Certificate and CSR.
    openssl x509 -noout -modulus -in certificate.crt | openssl md5
    openssl x509 -noout -modulus -in renewcertificate.crt | openssl md5
  5. Remove the existing sdkms.pem entry from the current p12 file.
    gsk8capicmd_64 -cert -delete -db "sdkms-kmip.p12" -stashed -label "sdkms_app_cert"
  6. Add client certificate and key to SSL Keystore.
    gsk8capicmd_64 -cert -add -db "sdkms-kmip.p12" -stashed -label "sdkms_app_cert" -file "sdkms.pem"
    The database should be able to communicate with Fortanix DSM using the new certificate. The db2stop and db2start commands may be needed to force the use of the new certificate.
  7. Import the CA certificate into the SSL Keystore.
    1. Delete the existing CA.pem from the p12 file using the following command.
      gsk8capicmd_64 -cert -delete -db "sdkms-kmip.p12" -stashed -label "trustedCA" -file CA.pem
    2. Download the latest CA certificate from the Fortanix DSM URL as described from Step 2 to Step 4 in Section 4.4.
      gsk8capicmd_64 -cert -add -db "sdkms-kmip.p12" -stashed -label "trustedCA" -file CA.pem
    Importing a CA certificate is an optional step and is only needed if there is a change in the Fortanix DSM CA cert.
  8. List the certificate in your keystore to verify if everything is fine.
    gsk8capicmd_64 -cert -list -db sdkms-kmip.p12 -stashed

4.9  Updating Certificate in IBM DB2 Keystore

  1. Verify the certificate in the IBM DB2 Keystore.
    gsk8capicmd_64 -cert -list -db sdkms-kmip.p12 -stashed
    db2inst1@2407b7a6943b SDKMS_Certs]$ gsk8capicmd_64 -cert -
    list -db sdkms-kmip.p12 -stashed
    Certificates found
    * default, - personal, ! trusted, # secret key
    !       CN=<fortanix_dsm_url>
    !       "CN=R3,O=Let's Encrypt,C=US"
    !       trustedCA
    -       sdkms_app_cert
    [db2inst1@2407b7a6943b SDKMS_Certs]$
  2. Create a new signed certificate.
    gsk8capicmd_64 -certreq -recreate -db sdkms-kmip.p12 -stashed -label "sdkms_app_cert" -target new_cert_request.arm
  3. Sign: Send the resulting new_cert_request.arm to be signed by the original Certificate Authority (CA).
  4. Receive: After the signed certificate has been returned (assuming you got it back as new_cert_signed.arm) then receive it back into your server keystore.
    gsk8capicmd_64 -cert -receive -db sdkms-kmip.p12 -stashed -file new_cert_signed.arm
  5. Verify: Verify the new dates on the received certificate.
    gsk8capicmd_64 -cert -details -label "sdkms_app_cert" -db sdkms- kmip.p12 -stashed
  6. Restart: For the new certificate to take effect, the Db2 server instance must be restarted.

4.10  Create an Encrypted Database

  1. Create an encrypted database using the following command:
    db2 create db mydb1 encrypt
    Figure 19: Create encrypted database
  2. Once you create the database you can find the Master key created in Fortanix DSM as shown below.
    Figure 20: Master key created
  3. You can find the Activity logs in the Application tab as below.
    Figure 21: Activity logs

In case you are getting any error in your environment. Then you need to troubleshoot the certificate and network-related issue so that we can communicate to the Fortanix DSM.

5.0  Rotating Master Keys in Fortanix Data Security Manager with IBM DB2

Rotating your encryption keys is part of a complete security policy. And as with passwords, how often is a controversial topic. This article is intended to give you information to make an informed decision about how and when to rotate your encryption keys. The focus is the keys that protect your data at rest and do not discuss SSL certificates.

IBM Db2 native encryption uses a 2-tier approach to data encryption where the data is encrypted with a Data Encryption Key (DEK) and the DEK itself is encrypted with a Master Key (MK). The encrypted DEK is stored with the data while the MK is stored in a keystore external to Db2.

As the master key is stored outside of the database manager, the requirement and frequency to rotate the master key depend on the type of keystore in use and the protections provided by the keystore. A local keystore file is protected by a password and operating system file permissions, however, it is owned by the Db2 Instance Owner, which is often a shared service account. In such an environment policy to rotate the master key on a regular basis would be natural. On the other extreme, master keys protected by Hardware Security Modules (HSM) require much less rotation if at all. Master keys protected by an HSM never leave the secure confines of the hardware device and strong controls exist to prevent the key from being extracted. Master keys accessed from a KMIP server fall somewhere in the middle. Strong controls exist within the KMIP server to authorize who has access to the master keys and audit their usage. However, these servers are often deployed as software running on a traditional operating system and servers and are only as secure as the environment in which they are deployed. On the other hand, there are secure HSMs offering KMIP interfaces. A key rotation schedule would be suggested by the security hardening of the KMIP server and the environment in which it is deployed.

Db2 provides routine SYSPROC.ADMIN_ROTATE_MASTER_KEY() to rotate the database master key to a new value. This operation decrypts the database DEK and re-encrypts it with the new master key.

The 2-tier approach ensures that the key used to encrypt the data, the DEK, is never exposed outside of the encrypted database, transaction log, or backup and no interfaces exist within Db2 to access the DEK. Since the MK is stored in a different location from the encrypted data, this makes concurrent exposure of the encrypted data and the MK much less likely again reducing risk. Finally, since the DEK is not exposed, there is little reason to rotate it, and rotation of the MK used to protect the DEK, can be done efficiently without the need to decrypt and re-encrypt the data itself.

5.1  Steps for Rotating Keys in DB2

  1. List your DB directory.
    db2 list db directory
    Figure 22: List DB directory
  2. Connect the DB to the same database.
    db2 connect to MYDB1
    Figure 23: Connect DB
  3. Check the encryption info from the below command.
    db2 “select * from table(sysproc.admin_get_encryption_info())”
    Figure 24: Check encryption info
  4. Now rotate the master key from DB2.
    Figure 25: Rotate master key
  5. Once the key is rotated, check on Fortanix DSM end if the Master Key is rotated.
    Figure 26: Check in Fortanix DSM
    You will find a new key created in Fortanix-DSM.

6.0  Backup and Restore Encrypted Database

  1. To take backup of the database run the following command:
    db2 backup database mydb1
    Where mydb1 is the database that is encrypted with keys in Fortanix DSM.
  2. Move the backup file generated to the destination server.
  3. On the destination server, configure Fortanix DSM integration for the new db2 instance as previously described in this document from Section: “Adding App in Fortanix Data Security Manager” until Section: “Configure a DB2 Instance to Use a Keystore”
    1. This will be a new configuration with a new app.
      The app must be created under the same group as earlier.
  4. Run the following command to restore the backup of the encrypted database mydb1.
    db2 restore db mydb1 encrypt
  5. Verify that you can query the encrypted data in the restored database.
    db2 list db directory
    db2 connect to mydb1
    db2 "select * from <table_name>"
    You should now be able to connect to the database and select data from tables.
  6. Run the following query to see the new master key used by the database.
    db2 "select * from table(sysproc.admin_get_encryption_info())"
  7. Verify from the Fortanix DSM UI that the new db2 Key from the previous step is seen under the group’s security objects.

7.0  Migrating from a Local Keystore to a Centralized KMIP Keystore

If you want to migrate your Db2 local keystore to a centralized keystore that is configured for the Key Management Interoperability Protocol (KMIP), you can copy your master keys to the centralized keystore by issuing the db2p12tokmip command.

7.1  Prerequisites

The following are the prerequisites:

  • Create a KMIP keystore configuration file.
  • Configure TLS between the DB2 instance and the centralized key manager.

7.2  Procedure

The following is the procedure to migrate from a local keystore to a centralized KMIP keystore:

  1. Set up the centralized KMIP keystore.
  2. Set the allow_key_insert_without_keystore_backup parameter to “TRUE” in the centralized KMIP keystore configuration file.
  3. Copy all master keys from the local keystore to the centralized KMIP by issuing the db2p12tokmip command.
                                                                          Figure 27: Copy all master keys


Here is an example:

db2p12tokmip -from /home/test/keystores/ne-keystore.p12 -to /database/config/db2inst1/KMIP/kmip.cfg

In the above example, /home/test/keystores/ne-keystore.p12 is the .p12 file for the local keystore and /database/config/db2inst1/KMIP/kmip.cfg is the config file for the KMIP Keystore.



Please sign in to leave a comment.

Was this article helpful?
0 out of 0 found this helpful