Cryptography is the foundation of cybersecurity, and can effectively protect both consumer privacy and sensitive data from attackers. When encrypted data is stolen, what may have been a serious breach is only a mere incident: something to continue to protect against, but which has minimal impact and may not even require public disclosure.
Encryption uses cryptographic algorithms and keys, and the proper management of cryptographic keys is essential to effective use of encryption: poor key management can make strong algorithms useless. The National Institute of Standards and Technology (NIST) publishes “Recommendations for Key Management” in Special Publication 80057 (Part 1, Revision 5).
Modern, strong encryption is never cracked, but often bypassed. It does not matter how much encryption is done: if keys are not well protected, it takes little for a hacker to obtain the crown jewels, with significant business and reputational impact. Key management is just as important as implementing strong cryptography, and is all too often the Achilles heel of enterprise data security and privacy programs.
There are two ways to create a cryptographic key: generate a random key, or calculate it. It's easy to understand why random keys are good. There is no computational trick that will help an attacker guess a random value that is any better than just guessing all possible values until they get the right one. But it is also possible to generate keys dynamically, in a manner that is just as secure as the traditional approach: by using random seed material generated once, and then deriving keys on demand based on combining a key “name” or an “identifier” with that seed material.
The most secure way to calculate a key is by using a secure key derivation function (KDF), the output of which is a derived key. Derived keys are just as secure as random keys, but they have some significant practical advantages. In particular, they make it much cheaper to buy, use, and maintain systems that employ them.
Traditional key management entails a complex sequence: generating keys, marking them “not yet used” backing them up; making them available; assigning names; marking them as “in use” deactivating them, so they are no longer available; and more, including replication, synchronization, archiving, and permissions management. This is tedious, and installations using many encryption keys quickly find that key management is as much or more work than the actual encryption.
The downside of the random key generation approach is that you must back up each new key before it is used to encrypt data. If you do not, then the protected data will not be able to be decrypted if the key store fails.
Comparatively, derived keys offer some significant practical advantages. Since the secret changes only rarely, backups are infrequently required and the need for the whole create-activate-name-deactivate sequence (other than authorization) is removed. Multiple key servers can be created from a single backup and are guaranteed to derive the same keys from the same inputs, since the original seed material is reused, without requiring any real-time replication or synchronization. There is also no risk of losing keys: if an application loses a derived key, it can be re-derived as easily as generating it in the first place.
Regardless of the key management solution, a significant challenge is to ensure that keys are not mishandled by users. It is critical to disconnect users and developers from key management. Application teams should not be involved in storing, protecting, or rotating encryption keys, and nor should they be allowed to actually possess keys. Instead, they should be provided with key identifiers and an interface to an abstraction layer that automates key generation, retrieval, caching, protection, and refresh.
Voltage SecureData by OpenText™ implements stateless key management, giving enterprises unprecedented scale and simplified key management. With Voltage SecureData, key management is also abstracted, which means developers don’t ever hold keys and hence don’t need to store them. Instead they store identities – key names – which can be meaningful strings, such as PAN, SSN, SensitiveData, etc. Developers can store these identities in properties files without any protection, since they are not sensitive. SecureData client software takes care of the key management processes – key retrieval, security, cache, etc. With remote, REST-based operation, keys are never exposed outside of the SecureData server. SecureData enables key derivation at the SecureData server or within an HSM.
Encryption can be hard, and key management is even harder; but there are ways to make key management easier while fully complying with even the most rigorous standards. Voltage SecureData makes key management easy, helping to shield this critical aspect of a data security program.