Stringent regulations and demanding customers have increased the importance of data privacy. Cryptography plays a significant role in protecting data confidentiality.

By John Concini

Note: This article was derived from an IBM Redbooks publication, IBM System i Security: Protecting i5/OS Data with Encryption, written by a team that included the author of this article as well as Beth Hagemeister, Milan Kalabis, Robin Tatam, and Yessong Johng. The following is a management overview of some of the issues discussed in the publication, which should be consulted for a more detailed and technical discussion.

Data security, which includes protecting the privacy, integrity, and availability of data, has always been a prudent business practice, but its importance has increased appreciably in recent years. The reasons for the increased focus are varied. Businesses collect and store significantly more personal and transactional data than they did in the past. This has brought confidentiality issues to the fore. Headlines shrieking about serious privacy breaches have served to heighten the concern. In addition to the demands of customers themselves, governments and industry organizations have responded by passing regulations and industry standards that require privacy protection.

Many of those regulations and standards also dictate the protection of data integrity. As a result, organizations must ensure that no unauthorized changes are made to the data they hold. At one time, the primary threats to data integrity were internal--a disgruntled employee destroys data before leaving the company or an operator error or a program bug has the same effect unintentionally. Those threats have not disappeared, but in today's widely interconnected world, external hackers and viruses add new risks.

The third aspect of security, the protection of data availability, has always been an issue, but as the value of the data has increased and as organizations move to 24x7 operations, the importance of ensuring that data is continuously available has increased.

The most obvious role for data encryption, the subject of this article, is in the area of keeping confidential data confidential. In a nutshell, encryption scrambles data so that it is unintelligible if viewed in its encrypted form. To be viewed and/or put to use, the data must be decrypted.

Encryption cannot protect against data corruption, but several cryptographic functions--such as digital signatures, message authentication codes, and keyed hashes--can be used to determine whether any unauthorized alteration of the encrypted data has occurred. Digital signatures also help to ensure that data did, indeed, come from the purported source.

Cryptography does not have a specific role to play in ensuring data availability, but because high availability (HA) and disaster recovery (DR) solutions create duplicates of enterprise data, if security concerns require the encryption of production data, the backup copies must also be encrypted.

Cryptography: A Piece of the Security Puzzle

It is crucial to recognize that cryptography is only one element of an effective IBM i security plan. Other security tactics are beyond the scope of this article, but they are nonetheless equally important. For example, many organizations assign the "All Object" authority to more user profiles than is strictly necessary. This allows those users to read and write to every record in every file. Consequently, encryption may be of little use in protecting data from malfeasance undertaken by individuals with All Object authority as this grants them the ability to access decryption keys and to render encrypted data unusable by corrupting it in its encrypted state.

The above is only one example of a security concern that might affect the success of cryptography. Thus, rather than merely implementing cryptographic functions and forgetting about them, it is important to first undertake a security review and implement a comprehensive security plan, of which cryptography is only one component.

When the required security skills don't exist in-house, they should be acquired either through training or by hiring or contracting security experts. Even when the expertise does exist within the organization, it can still be useful to contract an outside expert during the review phase as a fresh pair of eyes can often spot vulnerabilities that might be overlooked by someone who is steeped in the organization's data and processes day in and day out.

When evaluating the cryptography aspects of your security plan, you must consider two types of data: data in motion (also known as data in flight) and data at rest. Data in motion is, as the name implies, data that is being transmitted from its primary location. Data at rest is data residing in the primary databases and files.

The confidentiality of data transmitted over a network is protected using a variety of technologies such as Secure Sockets Layer (SSL), Virtual Private Networks (VPNs), and IP Security (IPSec), some of which include encryption as an inherent component. A different set of technologies, such as digital certificates, message authentication codes, and keyed hashes, serve to protect the integrity of data transmitted over a network.

Electronic transmission of transaction data is not the only type of data in motion that you must consider. Backup data, possibly sent on a physical medium such as tape, contains a copy of all of your critical data. Once it leaves a secure environment, it is vulnerable if stored in an unencrypted state. This can be a particular concern if you use another company to ship and/or store the backup media. And, as news articles attest, security can be a problem even when relying on trusted employees to transport data if those employees leave the media in an unsecured vehicle while they undertake other activities such as shopping or having lunch. Encryption can't prevent the theft of physical media, but it can protect the privacy of the data on those media by ensuring that the thief is unable to decipher their contents.

Another security hole that is frequently overlooked is email. Employees often email large files containing confidential information without considering the consequences, but standard email messages are vulnerable to being intercepted, thereby exposing their contents to unintended recipients. Therefore, critical files should be encrypted before being emailed.

IBM i Cryptography

The security of data in motion has generally garnered more attention than data at rest as data in motion has been seen to be the most vulnerable. After all, the theory goes, unlike data in motion, physical locks, keys, and security procedures protect data at rest. The unintended consequence of this belief is that data in motion tends to be well-protected by highly secure encryption, leaving data at rest as the more vulnerable "soft target." IBM i provides a number of native security controls that, when used in conjunction with database encryption, address this vulnerability.

The cipher algorithms--routines that translate back and forth between intelligible "plaintext" and unintelligible "ciphertext"--available in IBM i are all in the public domain. As such, they don't provide security through the secrecy of their program logic; it isn't secret. Instead, the privacy of encrypted data depends on the security of the key. If the key is exposed to an unauthorized individual, that person can decrypt the data using the publicly available encryption algorithms.

When the key is of an adequate length, cryptography algorithms can encrypt data to a level that is virtually unbreakable. Thus, securing the confidentiality of encrypted data is primarily a matter of choosing an appropriate key and then securing it from prying eyes.

It should be apparent from the preceding paragraph that a critical question is, what is an appropriate key? All of the regularly stated rules about choosing system passwords also apply to the choice of key values. For instance, if choosing the key manually, don't use one that is easy to guess; the CEO's name and birthday, for example, are likely available on the Web and, therefore, would be a poor choice. A better option is to use a program that generates a key using a random- or pseudo-random-number generator.

Key length is an equally important consideration. One way that hackers attempt to decrypt data is by trying every possible key. Thus, to use an admittedly ridiculous example, if your key is only 8 bits long, there are only 256 possible keys. With such a weak key, hackers could decipher your data quickly even if they tried each possible key manually.

On the other hand, a 128-bit key yields more than 3.4 times ten raised to the 38th power possible keys. A hacker would find it difficult to break such a strong key in a reasonable time even when using a very high-powered computer. This is in part because no bells are set off when the correct key is found. Hackers, or more likely their software, must analyze each "decrypted" result to see if the key produced a meaningful value.

A key is only as good as its unpredictability. This unpredictability is known as entropy.

Because dictionaries contain a finite number of words, all of which can be systematically searched easily using software, if you use a key that consists of English words each byte in the key typically provides only one or two bits worth of entropy. Thus, if you are using a passphrase rather than random characters--letters, numbers and symbols--you should use a key with as many bytes as the number of bits of entropy you desire. For example, if you want a key that is 128 bits strong, you should use a 128-byte passphrase.

When creating particularly important keys, such as a master key, it is a good policy to divide the key into parts with no one person knowing all of the parts. Full-function IBM i cryptography routines handle multi-part master keys; however, if you want to use multi-part keys in your applications, you will likely have to write a program that assembles the key parts before interfacing with the cryptography routines.

Storing Keys

Keys can be stored in a number of locations, some of which are permanent storage areas, but others hold keys only while an application makes use of it.

One place where a key can, but definitely should not be kept is hard-coded in a program. Doing so exposes the key to anyone who has access to the source code. Nonetheless, applications that work with encrypted data need to access the necessary keys. The recommended method for providing that access is through application variables. Even though variable contents do not persist, keys stored in them should be encrypted so the key will not be visible if a program dump is generated.

Outside of applications, keys can be stored on digital media, including in IBM i objects and keystores, so they won't be forgotten or misplaced, but the reason for using encryption in the first place is that online media are vulnerable. Therefore, it is important to encrypt keys that are stored online.

One way to protect the integrity of keys is to not store them online at all, but rather have a trusted individual enter them as required. However, when doing so, it is important to ensure that the individual does not jeopardize a key's security by writing it down in an unsecured location or by entering the key somewhere where an unauthorized person might view the key when it is being typed. Another issue to consider when depending on an individual to keep a key is whether the key is backed up because, without the key, encrypted data is inaccessible.

Sharing Keys

Keys used to encrypt and decrypt data at rest can be kept within a single facility, but, by definition, keys used to encrypt data in motion must be shared before the recipient can read and use the data. Broadly speaking, there are two schemes for sharing keys: symmetric and asymmetric key algorithms. With a symmetric key algorithm, the sender and receiver share the same key. The problem then is finding a way to share keys securely. Whether that occurs physically or electronically, the exchange should be done using a secure channel.

Asymmetric key algorithms use a pair of keys: a private and a public key. Only one party holds the private key. The other key, a public key, can be shared openly. The public and private keys are related mathematically such that data encrypted with the public key can be decrypted only with the private key. Despite this mathematical relationship, the private key cannot be derived from the public key. The advantage of an asymmetric key algorithm is that, because the public key is used to encrypt but not decrypt data, the public key can be shared without the threat of exposing the underlying data to an unauthorized individual who gains access to the public key.

Because there are advantages to symmetric key algorithms (which are beyond the scope of this article), organizations often encrypt and exchange symmetric keys using asymmetric algorithms and then do the bulk of their encryption using symmetric key algorithms.

Application Implications

Applications require a means to perform the encryption and decryption functions. IBM i supports a variety of cryptographic API sets for this purpose, including the following:

•·                     The Common Cryptographic Architecture (CCA) API set runs cryptographic operations on a Cryptographic Coprocessor, if available.

•·                     The IBM i Cryptographic Services API set runs general-purpose cryptographic operations within the Licensed Internal Code or optionally on the 2058 Cryptographic Accelerator.

•·                     Functions for encrypting and decrypting data in a database are standard features of Structured Query Language (SQL).

•·                     IBM i supports Java Cryptography that is compatible with the Sun Microsystems implementation.

High Availability and Disaster Recovery Implications

The use of encrypted data has implications for both DR and HA products. These solutions create either offline (DR) or online (HA) backups of all data and applications. The most obvious consideration is that the cryptography keys need to be available to the backup systems when they assume operations. Without those keys, encrypted data on the backup system would be inaccessible.

Some HA and DR products compress data to reduce storage and network bandwidth requirements, but encrypted data cannot be compressed. Furthermore, when using a DR product, the backup system is not always a duplicate of the primary system. If the Coded Character Set ID (CCSID) or the date and time formats are different on the backup system than on the primary system, the data must be translated when transmitted from one to the other, but encrypted data cannot be translated. Thus, data must be decrypted before being compressed and/or translated and then encrypted again in its compressed and/or translated state.

Management Tips

Securing data using cryptography is not a matter of simply "set it and forget it." A comprehensive security plan must be created and followed to avoid jeopardizing the security of the encrypted data. The following are only a few of the recommendations that should be considered:

•·                     Create a variety of keys for different cryptography tasks and separate those keys by the data they act on, the way they are used (encryption, decryption, message authentication, etc.), the level of authority, and key management responsibilities.

•·                     Do not assign all key management responsibilities to a single person. Good management control requires that responsibilities be separated and assigned such that malfeasance can occur only through collaboration rather than by the actions of a single individual.

•·                     Securely back up all current keys. Without the keys, your data is worthless.

•·                     In general, the more often you change keys, the more secure the encrypted data, but there are tradeoffs. The more frequently you change keys, the more difficult it is to keep track of them. In addition, each time you change a key, data encrypted with that key must first be decrypted with the old key and then encrypted again with the new one. This consumes both human and system resources.

•·                     Destroy all unnecessary key material when it is no longer needed.

•·                     At first glance, it might seem that the safest course of action is to encrypt all data, but encryption and decryption functions consume system resources and they can, therefore, slow applications and create a need for more powerful servers. Furthermore, encrypting data that is widely known can lessen the security of all encrypted data because a hacker may be able to use the known data to discern the encryption algorithm and key. Thus, when deciding which data to encrypt, you must ensure that the benefits of increased data privacy and integrity outweigh the costs.

As mentioned in the introduction, this article touches only the surface of cryptography. Furthermore, cryptography is only one piece of the security puzzle. For more information, consult the IBM Redbooks publication IBM System i Security: Protecting i5/OS Data with Encryption or contact an IBM i security professional.

Also Read

IBM i Security Essentials: 4 Components for an Effective Strategy

New IBM i Security Features and a Farewell

Securing IBM i: A Dual Responsibility