These days, encryption is essential. Be sure you're doing it right.

Encryption key management is a crucial part of any data encryption strategy. It's designed to protect credit card numbers, social security numbers, or any other sensitive information you need to protect in data files. A failure in encryption key management can result in the loss of your sensitive data and can lead to severe penalties and legal liability. Unlike public/private key technology, which maintains the security of two separate endpoints, database encryption uses a single secret key, and its loss compromises your data. That's why good encryption key management is so important to your data security strategy.

As criminals get more sophisticated at stealing sensitive data, a disturbing trend has been developing in attacks on encryption keys and their management. Recent data losses have been accomplished by attacking weak encryption keys and weak key management systems. It's a good time to review your strategy for protecting keys.

Let's talk about the five essentials of good encryption key management.

Create Strong Encryption Keys

Encryption key management starts with the creation of strong encryption keys and extends through the life of the key. Creating a strong encryption key is an important first step. There are several common methods of creating encryption keys:

•·                     Random number generation

•·                     Key derivation from passwords

•·                     Passphrases used as keys

All modern key management systems support standards-based key generation. Keys based on random numbers should be created with either a Cryptographically Secure Pseudo Random Number Generator (CS-PRNG) or a true random number generator. Passwords are rarely secure enough for use as encryption keys, but strong keys can be derived from passwords by using Password-Based Encryption (PBE), which combines a pass phrase, a random number, and hash or encryption operations. Passphrases alone make very poor encryption keys, and their use as keys should be avoided. All good key management solutions create strong keys using proven methods.

It's amazingly difficult to create good encryption keys, and it's easy to get it wrong. Just recently, a major error was discovered in Debian-based OpenSSL implementations.  A one-line code change destroyed the strength of all encryption keys, and attacks on Debian-based OpenSSL have already occurred.

Store Keys Securely and Protect Access to Key Management

Once a good key has been created, it has to be stored securely until it is used. Encryption keys should not be stored in the clear in a database file. Good key management solutions will use a variety of techniques to securely store keys, including these:

•·                     Encrypting the key with one or more master encryption keys

•·                     Protecting the key database with native file security

•·                     Detecting key corruption or substitution

•·                     Optionally storing keys in secure hardware modules

•·                     Controlling and reporting access to key management

Key management systems work hard to ensure that only those users authorized to access keys can do so and to prevent the substitution or corruption of keys.

Good key management systems also implement strong controls over who can manage encryption keys. Some systems require two or more authorized users to validate before access is granted to key management. Others use biometric or smart-card access controls. All good key management systems provide system logging to record and report access to the key management application.

Manage Keys Through Their Life Cycle

Encryption key management solutions should help you implement your security policies throughout the life of the encryption key. You should be able to define when a key becomes active, when it is no longer available for use, when it gets backed up, and who can use the key. These policies help prevent unauthorized access. Here are some examples of policy controls that good key management systems implement:

•·                     Activation and deactivation dates for keys

•·                     User controls on access to keys

•·                     Application controls on access to keys

•·                     Backup, escrow, and archival policies

•·                     Automatic or manual key change (rollover) and change interval

•·                     Key distribution and export policy

These attributes help you implement proper security controls over access to encryption keys. When paired with good system logging and reporting, you can have a high degree of confidence that encryption keys are being accessed and used appropriately.

Secure and Authenticated Key Retrieval

Increasingly, compliance auditors are insisting that encryption keys be stored separately from the data they are protecting. By separating the encryption keys from the data, you further minimize the potential for key loss through poor backup strategies or through the physical loss of a server or hard drive. This means you may have to deploy a key management system on a separate server or in a separate logical partition and then provide access over a network connection. It is important that your key management solution support this architecture and provide for secure network access.

Of course, if your staff is retrieving a key via a network connection, you must ensure that the connection is encrypted so that the key is not exposed during transport. This is normally done by implementing an encrypted Transport Layer Security (TLS) network connection. In addition to encrypting the encryption key when it is retrieved, the secure TLS connection can authenticate both the client and server by using public/private key technology.

You will want to move sensitive data between your internal applications without decrypting and re-encrypting. This means that your key management solution should provide encryption keys to a wide variety of application and server environments. Be sure that your IBM i, Windows, Linux, UNIX, and System z applications can retrieve keys using standard methods implemented by your key management system. Does your key management vendor provide example applications in Java, .NET, RPG, and other common languages? This will be crucial to the success of your key management strategy.

Never accept a key management solution that does not implement encrypted transfer of keys. Many recent data losses have occurred when criminals captured data on internal networks. You don't want them capturing your encryption keys!

Disaster Recovery and High Availability

As encryption permeates your business applications, key management solutions become an important keystone in your IT infrastructure. The loss of a key management system will mean the loss of critical information in your applications. Here are some questions to consider:

•·                     How does your key management solution fit into your data mirroring and high availability strategy?

•·                     Do you have offsite backups of your encryption keys and policies for recovery?

•·                     Are encryption keys separated from your backup data?

•·                     If you use a third-party disaster recovery service, how will your key management system be restored to this site?

If you are using an IBM i high availability mirroring solution, be sure that your key management solution fits into this strategy. Because encryption keys may change at any time due to automatic key rollover or manual change, you will want these changes to be reflected in your high availability environment as quickly as possible. If your key management solution involves hardware-based master keys, ask your key management vendor how these keys are mirrored, too.

Many IBM i customers use a third-party business recovery service with backup systems at a remote location. You should let your vendor know that you are using a key management solution and then work with the vendor on the steps that will be needed to restore the key management solution. If the key management solution must be restored before the data is restored, your vendor's recovery team will need to know this and have explicit instructions on the sequence of steps to take. Remember, if you are storing your encryption key backups with a separate data archival service, let your vendor know the procedures for key recovery.

If you are using an IBM i or appliance-based key server solution, you must plan for deploying the server at your disaster recovery site. If you are using a Power Systems server, your vendor will need to know the minimum requirements for it. If you are using a key server appliance, your vendor will need to know the rack and power requirements.

Lastly, as many of us have learned the hard way, a disaster recovery plan that hasn't been tested is not worth the paper it is written on! Be sure to include key management recovery in your DR tests.

Resources

Here are a couple of key management resources that you might find helpful:

•·       NIST recommendations for encryption key management

•·       PKCS#5 Password-Based Key Derivation

Also Read

Data Privacy Rules Around the World

Data Security: 8 Privacy Principles Every IT Pro Should Know

Why the IBM i Community Needs to Pay Attention to GDPR