The hardest part of security is encryption, and the hardest part of encryption is key management.

For a variety of reasons, IBM i customers struggle when implementing the encryption of sensitive information. There is wide acceptance and knowledge that sensitive information should be encrypted, but there is also a large amount of fear about its implementation, especially around encryption key management. Concerns about performance, business continuity, and systems management are common in IBM i shops. In fairness, these are also concerns for users of other server platforms and operating systems, such as Microsoft Windows Server, Linux, and IBM System z mainframe.

The pressure to implement encryption is coming from many directions. Compliance regulations require key management or provide safe-harbor exemptions when data is encrypted. Business and security auditors expect organizations to protect sensitive data as a part of security best practices. And the executives and directors of public and private organizations see the lack of data protection as a failure of proper governance, risk management, and compliance (GRC) that puts the organization at real risk. Everyone now knows that the failure to protect sensitive information can put the very existence of the organization at risk.

Fortunately, both IBM and third-party vendors have stepped in to provide the fundamental technology for encryption. IBM i customers have access to proven encryption libraries, and with V7R1 of the IBM i operating system, even the DB2 database has enabled the ability to implement encryption at the database level.

The big challenge for IBM i customers is getting encryption key management right. This article is about Key Management Systems (KMSs) and the important issues IBM i customers face.

Why Is Key Management Important?

Encryption keys are used to lock and unlock the encrypted data. They are unique to you, and when encryption keys are created properly, they are extremely difficult to guess or attack through brute force. In fact, there has been no known loss of encrypted data through this type of attack. With properly encrypted data, the only way a hacker can get access to the encrypted data is to steal the encryption key. For this reason, protecting your encryption keys from loss is crucial to your encryption strategy.

Protecting encryption keys is so important that the National Institute of Standards and Technology (NIST) has created best practice guidelines, standards, and certifications for encryption key management. The work of NIST in this area is directly referenced in most compliance regulations and is the core material informing the security and audit community. This is why understanding NIST standards and recommendations is crucial to your encryption key management strategy.

What Are the Standards for Key Management?

Understanding encryption key management has to start with the NIST Special Publication 800-57 (Recommendation for Key Management). It is a heavy lift to read the entire set of volumes, but the concepts are crucial for understanding the core elements of a proper key management strategy. The guidelines in this publication lead to the core guidelines for creating strong encryption keys, managing encryption keys through their lifecycle, changing keys at appropriate intervals, and handling operational controls such as separation of duties, dual control, and so forth.

The standard for encryption key management solutions is defined in the NIST publication Federal Information Processing Standards Publication 140-2, Security Requirements for Cryptographic Modules (or FIPS 140-2). This is the most widely accepted standard for key management systems, and all professional key management solutions have been validated to this standard. It is so important that FIPS 140-2 validation is a requirement for U.S. government agencies, and large enterprises in the private sector require this validation for their key management solutions.

Reflecting the importance of key management systems, NIST recently released Special Publication 800-130, "A Framework for Designing Cryptographic Key Management Systems." While the intent of the publication is to assist designers of key management systems, NIST is also attempting to help those in the public and private sectors better understand what to look for in a key management system. It's a great document to refer to as you implement key management in your organization.

The other important standard for key management systems is Key Management Interoperability Protocol (KMIP) published by OASIS. This standard defines how people and applications interface with a key management system and is an attempt to bring common standards to key management systems as well as the applications that integrate with them.

What Do Compliance Regulations Say About Key Management?

The evolution of data security compliance regulations in the U.S., EU, and Asia can be traced back to PCI DSS, the HIPAA/HITECH Act, and FISMA guidance. Sometimes the connections are explicit, as in these regulations, and sometimes the connections are implicit. However, in almost every public and private data security standard, you will find references to these standards and best practices with Separation of Duties, Dual Control, and Split Knowledge as core concepts in encryption key management.

Here is what PCI DSS says about Dual Control in the PCI DSS Version 3.0 Navigation Guide

(emphasis added):

Cryptographic keys must be strongly protected because those who obtain access will be able to decrypt data. Key-encrypting keys, if used, must be at least as strong as the data-encrypting key in order to ensure proper protection of the key that encrypts the data as well as the data encrypted with that key.

The requirement to protect keys from disclosure and misuse applies to both data encrypting keys and key-encrypting keys. Because one key-encrypting key may grant access to many data-encrypting keys, the key-encrypting keys require strong protection measures. Methods for secure storage of key-encrypting keys include but are not limited to hardware security modules (HSMs) and tamper evident storage with dual control and split knowledge.

Here is an extract from a NIST guidance paper entitled "An examination of cryptographic security services in a federal automated information system" (emphasis added):

Maintaining control of central or root keys from the time of generation is critical. Central or root keys are most likely to be used in sensitive applications such as encrypting user keys, signing a central key database for integrity, binding a key pair to a user, or generating user keys. If these keys are compromised, a complete system compromise (involving the compromise of user keys, encrypted data, and/or signed data) becomes a very real threat. It is essential to maintain the security of these central keys from the very beginning - the generation process. No one but the proper owner(s) of a key or key component should ever be able to use that key or key component. If split knowledge and dual control are a requirement for central or root keys, then a failure to maintain split knowledge and dual control of those keys at any time in their lifecycle could present both a security problem and a potential system compromise.

What Should Key Management Solutions Do?

Key management systems perform a wide variety of tasks related to creating and managing encryption keys. And beyond the specifics of managing encryption keys, they also perform business continuity, recovery, auditing, logging, configuration, authentication, and many other tasks. As is the case with any dedicated security device, key management systems occupy a critical place in your IT and application infrastructure.

Key Creation

Creating strong encryption keys is the first challenge of a KMS. It turns out to be much more difficult to create a strong encryption key than you might imagine. Computers are really good at doing the same thing in a reliable way. When you ask a computer to do something random, that turns out to be difficult. And that is exactly what we want when creating an encryption key. We want a key that is as close to purely random as possible. A good KMS will implement key creation (sometimes called "key establishment") based on industry standards such as those from NIST. You should have confidence that your encryption keys are cryptographically strong; this is crucial for the protection of your sensitive data.

Key Management

Once a key is created, it has to be properly managed through its useful lifetime. After a key is created, it goes into active use for a period of time, eventually expires and is used only for decryption tasks, becomes inactive, is escrowed, and may eventually be destroyed. This the process of managing a key through the "lifecycle" of the encryption key. A proper KMS will implement functions that let you securely manage the keys through all of these stages.

Key Versioning

Security best practices require that we only use keys for an appropriate "cryptoperiod." That is, based on a number of factors, we should retire a key after its useful lifetime and replace it with a new encryption key. This is called "key versioning," "key change," or "key rotation." A good KMS will keep track of a key's cryptoperiod and assist you in creating new keys to replace the old ones. In many cases, this can be an automatic process.

Key Storage

Since keys are the crucial secret that must be protected, there are standards about how to store them in a KMS (see FIPS 140-2). A KMS should encrypt data encryption keys (DEKs) with separate key encryption keys (KEKs) that are at least as strong as the DEKs. The KEK should be stored logically or physically separate from the DEK. And a KMS should always protect against key corruption or substitution by a bad actor.

Authentication and Access Control

Defining appropriate user roles for a KMS is also critical for the protection of encryption keys. Key users should not have access to key management functions. Likewise, server administrators should not have access to either encryption keys or key management. And importantly, those who have access to data protected by an encryption key should not have access to key management tasks (separation of duties). For these reasons, a good KMS will have clear boundaries between these roles and restrict access based on these roles. This concept of separation of duties is one of the main reasons that encryption keys must be stored off of the system containing the protected data; highly privileged users (QSECOFR or *ALLOBJ users for IBM i shops) must not have access to both protected data and encryption keys.

Business Continuity, Recovery, and High Availability

Because access to encryption keys is required for the proper operation of business applications, a KMS must have good processes to ensure business continuity. This means that a KMS must implement high availability operations, real-time mirroring of encryption keys and access policy, and backup and recovery. When implemented as a hardware security module (HSM), the KMS should be based on redundant disk, network, and power systems. In the same way that we ensure that our IBM i servers remain available to our users, we have to ensure that the KMS remains available.

Server Management

Whether a KMS is implemented as a hardware device, virtual machine, or cloud instance, it will need to provide a secure way to manage the server. A network administrator will need to configure the address of the server, establish firewall rules, enable auditing, synchronize the server clock, and set up system logging. A good KMS will provide a secure method of server management that isolates and protects against access to encryption keys.

How Do Encryption and Key Management Affect the Performance of My IBM i Applications?

There are no two ways about it: Encryption will add processing overhead on any server, including the IBM i. The more encryption you do, the more CPU resources you will use. On the IBM i Power Systems platform, we have a lot of CPU power at our disposal. Over time, IBM has given us faster and more powerful processors. That's the good news. On the other side of the ledger, the native IBM AES encryption library is not a great performer. But there are good, high-performance encryption libraries available from third-party vendors. If you have a lot of data to encrypt, you will definitely want to check that out.

A key management system has to be included when discussing performance. The manner in which keys are retrieved from a KMS system can have a big impact on performance. For example, if you perform 1,000 encryption operations in your RPG application, how many key retrieval operations are involved? Secure key caching can dramatically reduce the performance impact of a KMS on your system.

IBM's implementation of Field Procedures (FIELDPROC) in V7R1 brings an additional set of considerations related to performance. When you implement FIELDPROC to encrypt data in your DB2 database, you avoid the need to change your application code, but you incur the overhead of an external call to your FIELDPROC program on most database operations. Be sure to evaluate the performance impact on your applications if you take this route to encryption. And, of course, your FIELDPROC strategy will have to integrate with your KMS strategy!

What About Non-IBM Platforms?

The days are long past when our organizations ran applications on just one platform. We all now run applications on IBM i, Windows, Linux, and cloud platforms. A key management system should be able to provide encryption key management across all of these platforms. If you are a typical IBM i customer, you have legacy RPG applications and are experimenting with Java, PHP, or similar environments. Your colleagues are developing Windows applications in C# or VB.NET, and Linux applications in Java, PHP, Ruby, or Python. Can your KMS strategy handle all of these environments? It is really painful (think $$$) to deploy multiple KMS systems to serve different internal needs.

What About the Cloud?

When deploying a KMS, be sure that it will serve all of your needs today and will move with you to the cloud. Can your KMS move to the IBM cloud? To Amazon Web Services? To Microsoft Azure? How about Rackspace? This can be a bigger challenge than you might think! If there's one thing we can be sure about, it's that there's a cloud in our future. Be sure your KMS strategy can move to the cloud with you!

Summary

Deploying a key management system for the IBM i can seem overwhelming. But the KMS industry has matured over the last few years, and you now have multiple options for getting key management right on the IBM i. You don't have to settle for a home-grown or uncertified solution that won't meet the sniff test for encryption key management. Let's get the job done!