Database encryption using IBM InfoSphere Guardium for DB2 and IMS

Glenn Galler, Product Manager, IMS Tools Development, Rocket Software

With over 500 million data records breached every year from malware, phishing, and third-party software, most security experts agree that companies need multiple layers of data security protection. When a system is compromised, it can take hours or even days from the initial attack to realize a data breach occurred.

As large computer systems become a major part of Service Oriented Architectures (SOA) or providers of web services, the risk for malware infiltration increases. The threat isn’t just from outside the computer system, but from privileged users who have a need to know, but who can abuse the systems or just make mistakes with their accessibility.

The IBM® System z® environment has many security and data safeguards, including disk encryption that works at the disk subsystem level. Disk encryption is an all-or-nothing type of encryption that uses a single key. It’s useful to prevent disk or box removals; however, it falls very far short in protecting DBMS environments.

Data encryption is better suited to protect DBMS subsystems. It allows data to remain encrypted even when copies of the database data sets are made, such as what’s done with image copies or log files. It’s also more flexible because it operates at the DB2 row or column level or the IMS segment level. Data encryption provides the granularity that’s needed to protect IBM DB2® and IBM IMS™ data.

In this article, we explore basic encryption terminology and the cryptographic facilities available in the System z environment. We also discuss how IBM InfoSphere® Guardium® Encryption for DB2 and IMS (5655-P03) reduces the complexities of using data encryption for DB2 and IMS applications. With this product, you can use data encryption and decryption without having to change your DB2 or IMS applications.

Understanding encryption
To fully appreciate data encryption, it’s necessary to understand data encryption terminology and algorithms.

Encryption keys
Most modern day encryption techniques use a cryptographic algorithm to scramble data. The process is controlled with an encryption key. A key is a sequence of binary digits that’s used by an encryption algorithm to alter text into an unreadable format. The security of any encryption algorithm is entirely dependent on keeping the key a secret.

A key can vary from 56 to 256 bits. The bits in a key determine the number of bit combinations. As the number of bits increases, so does the difficulty for guessing the secret key. For example, a key size of 128 bits ensures at least 2128 different keys, and is generally considered to be a very secure number of key combinations.

The National Institute of Standards and Technology (NIST) has rated the most common encryption algorithms. NIST has determined that Data Encryption Standard (DES), which has 56 bits, is too weak for today’s sophisticated computers. Triple Data Encryption Standard (TDES) and Advanced Encryption Standard (AES), which have 128 or 256 bits, provide universally acceptable encryption algorithms, as shown in Figure 1.

Figure 1. DES, TDES, and AES encryption
Figure 1. DES, TDES, and AES encryption

IBM CP Assist for Cryptographic Functions (CPACF)
IBM CPACF is a specialized hardware processing unit (PU) responsible for providing very high-speed and secure cryptographic computations. It’s driven by a set of instructions that are only available to authorized programs like IBM InfoSphere Guardium Encryption for DB2 and IMS.

IBM Integrated Cryptographic Service Facility (ICSF)
ICSF is a software interface to CPACF. ICSF runs in its own address space and manages the creation and distribution of keys. ICSF stores keys in the cryptographic key data set (CKDS). The CKDS is secured using Security Access Facility (SAF). ICSF assigns a key label to each key. Several SAF resource classes exist, like CSFKEYS, that secure access to these keys using the key label.

Clear key
A clear key is not encrypted. It’s visible within the main storage of the computer system. A clear key is meant for short transient data transmissions that flow over unsecured networks. When it’s exposed, the data under the clear key is compromised. It’s not appropriate to use a clear key to encrypt DB2 or IMS data for long periods of time.

Secure key
A secure key is a key whose clear value is never exposed outside of a tamper-proof device. It’s created by encrypting it with a master key, which only exists in cryptographic cards (PCI). The secure key is passed with the data to the PCI cards to be encrypted or decrypted.

Protected key
While the secure key provides the strongest level of encryption, it also incurs the most amount of performance overhead because each data encryption or decryption is performed inside the tamper-proof PCI cards. The protected key provides strong encryption with better performance.

Every LPAR has a special key called an LPAR wrapping key, which resides in protected storage. The LPAR wrapping key is used to encrypt clear keys. A new LPAR wrapping key is created each time the LPAR is reset or cleared (re-IPL’ed). The protected key is created by encrypting the clear key using DES-56, TDES-128, AES-128, or AES-256, with the LPAR wrapping key.

Encryption algorithm performance
Performance differentiators exist between clear key, secure key, and protected key.

For secure key, encryption and decryption are asynchronous operations that move the secure key and the data from the general purpose central processor units (CPU) to PCI cards, where the secure key is unencrypted using the master key. The PCI cards are bus-attached devices that exhibit I/O-like characteristics, which greatly impacts the performance from an elapsed time perspective.

In contrast, when a clear key is used, the encryption and decryption work is performed at general purpose CPU speeds directly on the CPACF using synchronous operations.

With protected key, the performance is better than secure key, because the wrapping and unwrapping of the protected key using the LPAR wrapping key is performed on the CPACF.

Many other factors can impact the performance of clear key, secure key, and protected key encryption algorithms. For example, the speed of the processor, the level of the cryptographic hardware, and the number of DB2 rows or columns or IMS segments that are encrypted. It’s important to keep up-to-date with IBM’s advances in cryptography and IBM IMS and DB2 Tools since they’re in lockstep with these technological advances.

IBM InfoSphere Guardium Encryption for DB2 and IMS
IBM InfoSphere Guardium Encryption for DB2 and IMS allows you to select what type of key and which encryption algorithm to use. These two choices are conveyed to the product through your selection of the encryption exit.

Encryption exits for DB2 and IMS
For DB2, the choice of exit is determined by where you define the encryption. You can define encryption using EDITPROC, FIELDPROC, or as a user-defined function (UDF). The EDITPROC and FIELDPROC parameters are specified on the SQL CREATE TABLE statement, while the UDF is specified in the SQL CREATE FUNCTION statement. With DB2, the encryption method is called for a DB2 table row or column.

For IMS, you define the exit in the database descriptor (DBD) using the COMPRTN= segment edit/compression exit routine. Which exit you choose determines the type of key used and the encryption algorithm. In IMS, encryption is performed on an IMS segment or segment field.

Figure 2 shows DB2 encryption exits for EDITPROC. These exits support the standard clear key, secure key, and protected key types. A special exit (DECENBI0) called CPACF protected key with Initial Chaining Vector (ICV) allows data to be altered before it’s encrypted.

Figure 2: Encryption exits for DB2 EDITPROC
Figure 2: Encryption exits for DB2 EDITPROC

Figure 3 shows the DB2 encryption exit for FIELDPROC. This exit, DECENF00, uses protected key and supports the AES encryption algorithm.

Figure 3: Encryption exit for DB2 FIELDPROC
Figure 3: Encryption exit for DB2 FIELDPROC

Figure 4 shows DB2 encryption exits defined as a UDF. All UDF exits use an ICV to alter data before it’s encrypted.

Figure 4: Encryption exits for DB2 user-defined functions
Figure 4: Encryption exits for DB2 user-defined functions

Figure 5 shows IMS encryption exits. IMS encryption exits support clear key, secure key, and protected key types and all three encryption algorithms (DES, TDES, and AES).

Figure 5: Encryption exits for IMS as specified in the segment edit/compression exit routine
Figure 5: Encryption exits for IMS as specified in the segment edit/compression exit routine

Encryption and decryption
This section describes how encryption and decryption works for DB2 and IMS.

DB2 encryption flow
Figure 6 shows the flow of DB2 encryption from the DB2 application call to the storing of the row or column in the DB2 database.

Figure 6: DB2 encryption flow
Figure 6: DB2 encryption flow

Step 1: The DB2 application passes a row or column to the DB2 address space.

Step 2: DB2 loads the encryption exit routine that could have been created using an edit procedure, a field procedure, or a UDF.

Step 3: The encryption exit passes the key label and the row or column to ICSF.

Step 4: ICSF encrypts the row or column and passes it back to the encryption exit, which passes it back to the DB2 address space.

Step 5: DB2 stores the encrypted row or column into the table.

DB2 decryption flow
Figure 7 shows the flow of DB2 decryption from the DB2 application request for data from the DB2 Database.

Figure 7: DB2 decryption flow
Figure 7: DB2 decryption flow

Step 1: The DB2 application requests data from the DB2 address space.

Step 2: DB2 loads the encryption exit routine, which could have been created using an edit procedure, a field procedure, or a UDF.

Step 3: DB2 retrieves the encrypted row or column from the table and passes it to the encryption exit.

Step 4: The encryption exit passes the key label and the encrypted row or column to ICSF.

Step 5: ICSF decrypts the row or column and passes it back to the encryption exit, which passes it back to the DB2 address space.

Step 6: DB2 passes the decrypted row or column back to the DB2 application.

IMS encryption flow
Figure 8 shows the flow of IMS encryption from the IMS application call to the storing of the segment in IMS Database.

Figure 8: IMS encryption flow
Figure 8: IMS encryption flow

Step 1: The IMS application issues a segment ISRT, REPL or LOAD request to the IMS control region.

Step 2: IMS loads the encryption exit routine that is the segment edit/compression exit routine specified on the COMPRTN parameter of the SEGM statement of the DBD. IMS passes the segment to this encryption exit.

Step 3: The encryption exit passes the key label and the IMS segment to ICSF.

Step 4: ICSF encrypts the segment and passes it back to the encryption exit, which passes it back to the IMS control region.

Step 5: IMS stores the encrypted segment in the database.

IMS decryption flow
Figure 9 shows the flow of IMS decryption from the IMS application request for data from the IMS Database.

Figure 9: DB2 decryption flow
Figure 9: DB2 decryption flow

Step 1: The IMS application issues a segment GET request to the IMS control region.

Step 2: IMS loads the encryption exit routine that is the segment edit/compression exit routine specified on the COMPRTN parameter of the SEGM statement of the DBD. IMS passes the segment to this encryption exit.

Step 3: IMS retrieves the encrypted segment from the database and passes it to the encryption exit.

Step 4: The encryption exit passes the key label and the IMS segment to ICSF.

Step 5: ICSF decrypts the segment and passes it back to the encryption exit, which passes it back to the IMS control region.

Step 6: IMS passes the decrypted segment back to the IMS application.

Implementing data encryption using IBM InfoSphere Guardium Encryption for DB2 and IMS
With IBM InfoSphere Guardium Encryption for DB2 and IMS, you need to take a few steps to set up the cryptographic environment and to encrypt DB2 and IMS data. Figure 10 shows these steps.

Figure 10: Steps to implement encryption for DB2 and IMS data
Figure 10: Steps to implement encryption for DB2 and IMS data

In some situations keys need to be changed, known as key rotation. These situations can pertain to regulatory compliance rules, actions needed after a data breach, or if a key is compromised. Key rotation requires the data to be unloaded using the existing key, creating of new keys and key labels, and reloading the data using the new keys. When rotating keys in this manner, it’s important to retain the old keys in case they’re needed to decrypt older resources like image copies.

Disaster recovery implications
Most IMS and DB2 customers have to be concerned with their disaster recovery strategy. If data encryption is deployed at the active site, then the remote site must be able to decrypt the data when the database data sets are restored in the event of a disaster. A strategy, then, is needed in which the master key, LPAR wrapping key, and all clear keys, secure keys, and protected keys in the CKDS are moved from the active site to the remote site.

In a storage mirroring configuration, the volumes holding the CKDS must be included in the consistency group so that they can be mirrored together with any master key changes from the active site to the remote site.

In a non-storage mirroring configuration, where recovery resources are manually sent from the active site to the remote site, the disaster recovery strategy depends on whether the cryptographic hardware already exists at the remote site.

If the cryptographic hardware environment was already created at the remote site, then after restoring the CKDS data sets of the active site at the remote site, the cryptographic environment must be re-initialized using the master key of the active site before the CKDS can be used.

If the cryptographic hardware environment was not created yet, then the CKDS is transferred to the remote site. When the CKDS is restored, the clear keys, secure keys, and protected keys that are stored in the CKDS can be used at the remote site.

Another method for recreating the CKDS at the remote site is using ICSF Key Generator Utility Program (KGUP) utility, which can manually add clear keys, secure keys, and protected keys from the active site to the CKDS at the remote site.

Summary
Data security is one of the most important business concerns today. A multi-defense strategy using data encryption, monitoring and auditing, and DBMS controls are required to thwart the sophisticated software at the heart of most data breaches.

IBM InfoSphere Guardium Encryption for DB2 and IMS provides data encryption using state-of-the-art encryption keys and algorithms.

See our web page for more information.

1 comment on"Database encryption using IBM InfoSphere Guardium for DB2 and IMS"

  1. ASimonelli July 19, 2018

    This page contains incorrect or outdated information about Cryptographic key encryption methods. Current information is available in the IBM Knowledge Center: https://www.ibm.com/support/knowledgecenter/SSNPLQ_1.2.0/topics/decucon_oview-methods.html

Join The Discussion

Your email address will not be published. Required fields are marked *