Encryption can be hard, but key management is even harder. In fact it's so difficult that it is tempting to borrow from Gen. Robert H. Barrow's well-known logistics statement from 1980 and say, "Amateurs talk about encryption, but professionals study key management."
But there are ways to make key management easier, even in ways that fully comply with even the most rigorous standards. One of most important is to use derived keys.
There are two ways to get a cryptographic key: You can generate a random (more likely pseudorandom) key, or you can calculate one in some way. Here's how.
The benefits of random and calculated keys
It's easy to understand why random keys are good. There is no computational trick that will help you guess a random value that is any better than just guessing all possible values until you get the right one. For random values comprising even a couple hundred bits, that’s essentially impossible.
You can theoretically do it, but it will take you a very, very long time. So long in fact that well before you find the right key, you will be able to watch the continents collide from tectonic drift and the Milky Way and Andromeda galaxies smash together. In a world obsessed with quarterly results, that is essentially forever.
But it is also possible to calculate keys in ways that are just as secure as generating random keys. Cracking them takes the same level of effort that cracking a random key does. So a hacker trying to crack a securely calculated key will be able to pass the time by watching the same tectonic drift and collisions of galaxies that his friend does who is trying to crack a random key.
The way to most securely calculate a key is by using a secure "key derivation function" (KDF); the output of such a KDF 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.
Don't lose your data if you lose your key
Lots of business data is regulated in some way. Losing regulated data is bad — perhaps very bad. And if you encrypt regulated data and lose the key you used to encrypt it, that's just as bad as losing the data itself.
Because of this, if you use random keys to encrypt data, you need to securely archive those keys, and that is expensive; the highly reliable systems that you need to use for key archiving are not cheap.
If you lose a derived key that was used to encrypt sensitive data—perhaps the dreaded "CIO hit by a bus" scenario, but more often a user just forgets the password used to control access to a key—it is just as easy to recalculate that key as it was to calculate it in the first place.
This means that if you use derived keys, the expensive key archive that is needed for random keys is not needed at all, and it becomes simpler, easier, and less expensive to own and operate a system that uses derived keys instead of random keys.
A study (PDF) by Ferris Research said that in the case of encrypted email, the total cost of ownership (TCO) of systems that use derived keys is cheaper by roughly a factor of three when compared to the TCO of those that use random keys. That's a significant difference. And it is reasonable to expect roughly the same advantage in TCO when you use derived keys in other applications.
What a KDF does
Although the details of exactly how any particular KDF works can be somewhat complicated, all KDFs operate in the same general way. They require a secret value, S, and a key identifier, D. They then calculate KDF(D||S), possibly including other information in this calculation, for some key derivation function KDF.
So, if a user asks for the key that has the key identifier D, the application implementing the KDF calculates the key K as K = KDF(D||S), and returns the value K to the requesting user (after appropriate authentication, of course).
So, in a sense, a KDF is nothing more than a specialized cryptographic hash function—it maps the longer string D||S to the smaller string K, and that is exactly what you would expect a cryptographic hash function to do.
30 years of derived keys with DUKPT
Derived keys are not new; they have been used for quite a while in the payments industry. The Derived Unique Key Per Transaction (DUKPT, pronounced "duck putt") algorithm as defined in ANSI X9.24 part 3 can be used to derive keys that you can then use to encrypt sensitive transaction details.
DUKPT was first introduced in the 1980s and gained significant acceptance in the 1990s. So it is reasonable to say that derived keys are an established and accepted technology, having been around for over 30 years and in wide use for 20. They just have not yet gained widespread acceptance in the enterprise market. A lack of appropriate standards may be responsible for this delay.
Standards for derived keys
For many years, to comply with leading standards such as FIPS 140-2, "Security Requirements for Cryptographic Modules," you had to use random keys. This changed in 2009, however, when NIST published SP 800-108, "Key Derivation Using Pseudorandom Functions - Key-Based (KBKDF)." With that, keys that are derived with a KDF that complies with SP 800-108 also fully comply with the requirements of FIPS 140-2, and that should be enough to make even the strictest auditor happy.
Note that NIST has approved derived keys only for use in symmetric encryption algorithms such as AES. There are IEEE and ISO standards for derived-key public key algorithms, but none of these have yet been accepted by NIST.
And although there is no requirement for enterprises to use cryptography that complies with FIPS 140-2, the fact that derived keys were not recognized by any NIST standards for so long almost certainly delayed their adoption.
With all of the necessary standards now in place to keep your auditors happy, there's no reason to continue to avoid derived keys. They dramatically simplify key management and allow for systems that are significantly cheaper than those that use random keys. Yet they are just as secure as systems that use the more expensive random keys.
Ask your encryption vendors about their support for them. It might end up saving you a lot of money.
Keep learning
Get up to speed on unstructured data security with TechBeacon's Guide. Plus: Get the Forrester Wave for Unstructured Data Security Flatforms, Q2 2021.
Join this discussion about how to break the Ground Hog Day repetition with better data management capabilities.
Learn how to accelerate your analytics securely into the cloud in this Webinar.
Find out more about cloud security and privacy, and selecting the right encryption and key management in TechBeacon's Guide.
Learn to appreciate the art of data protection and go behind the privacy shield in this Webinar.
Dive into the new laws with TechBeacon's guide to GDPR and CCPA.
