IBM i > Administrator > Security

New GUI and CL Commands Simplify Key Management

Changes to IBM i 6.1 Cryptographic Services for managing keys and keystores

Tweet

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Protecting data—especially sensitive business and customer information—is vital to business policy and essential to regulation. The need to protect data, as well as the use of data encryption, has never been greater. The same can be said of the need to manage and secure the keys used to encrypt data. Relatively speaking, encryption is easy; key management is difficult. In this article, I’ll share the changes to IBM i 6.1 that have helped simplify the task of securely managing the keys that protect our data.

Adding Support

In IBM i 5.4, IBM added support to help with key management, specifically APIs for managing master keys and keystores. Master keys are at the top of a hierarchical key system. They encrypt keys only, not data. Ultimately, they’re the keys that protect all other keys. IBM offers support for eight general-purpose master keys, and each is stored within the licensed internal code (LIC) in an area inaccessible to user or system applications or even by the Display/Alter/Dump utility in System Service Tools.

In i 5.4, master keys can only be managed using the i5/OS* Cryptographic Services master key APIs. If you’re new to i5/OS Cryptographic Services, it’s important to know that each master key has three functional values or versions: current, new and old. The current master key version is used to encrypt newly generated keys. The new master key version holds the master key while it’s being built, but it’s never used to encrypt keys. The old master key version holds the previous master key that’s needed to change master keys without potentially exposing data keys. When the master key is set, the current version is copied to the old version, the new version is copied to the current and the new version is cleared. I’ll address a fourth version, the pending state, later; it has only limited accessibility for the end user.

After a master key has been changed or set, keys originally encrypted under the current master key are now encrypted under the old master key. Keys originally encrypted under the old master key are now lost. Therefore, it’s important to ensure that keys get retranslated under the current master key version after the master key has changed to prevent keys from being lost next time the master key is changed. Keystore files are database files used for storing cryptographic keys. All of the keys contained within a keystore are encrypted under one specific master key, which was specified when the keystore was created. Since the keystores are created with all normal database capabilities disabled, applications can’t read or write directly from or to a keystore. Therefore, keystores can only be managed using the i5/OS Cryptographic Services APIs.

Since key management is much better suited to a GUI than to an API, a new GUI was added to support master-key and keystore management.

Tweet