The initial downtime taken to encrypt data is often one of the main stumbling blocks to deploying an encryption solution. As data sets move into the terabytes, the downtime associated with initial encryption can often exceed available maintenance windows. Solutions such as HyTrust DataControl alleviate these issues by allowing the applications to continue running while the initial encryption takes place.
But what about rekeying the encrypted data, that is, switching the encrypted data from one key to another? Thus if you start with Key A and rekey, you will decrypt the data with Key A and encrypt it with Key B. Some time later you’ll decrypt the data with Key B and encrypt it with Key C and so on.
If the key management is secure and key management servers are FIPS 140-2 validated and tamperproof, why rekey data at all? Well, both industry standards such as PCI (Payment Card Industry) and government standards recognize that the longer a key is in use, the more likely that the key could be exposed or brute forced. As such, they recommend that a rekey should take place periodically. Let’s explore what NIST (the National Institute of Standards and Technology) says about rekey.
NIST provides many guidelines around cryptography and key management. So who are NIST? From their website (nist.gov):
From the smart electric power grid and electronic health records to atomic clocks, advanced nanomaterials, and computer chips, innumerable products and services rely in some way on technology, measurement, and standards provided by the National Institute of Standards and Technology.
Founded in 1901, NIST is a non-regulatory federal agency within the U.S. Department of Commerce. NIST’s mission is to promote U.S. innovation and industrial competitiveness by advancing measurement science, standards, and technology in ways that enhance economic security and improve our quality of life.
In the field of cryptography, NIST publishes a number of computer security “special publications” under SP-800-XX. Many of these special publications are used by other government organizations to measure the security of commercial software applications. Anyone who has gone through the FIPS 140-2 certification, will recognize many of the SP-800-XX documents which are constantly evolving.
Back to rekey. SP-800-57, “Recommendation for Key Management” provides guidance around the management of cryptographic keys. A somewhat healthy document at 140 pages, it covers everything from key generation, key storage, encryption algorithms used and key recovery. One topic it does cover well is rekeying of encrypted data under the topic of cryptoperiods. A cryptoperiod is “the time span during which a specific key is authorized for use by legitimate entities, or the keys for a given system will remain in effect”. A suitably defined cryptoperiod:
1. Limits the amount of information protected by a given key that is available for cryptanalysis,
2. Limits the amount of exposure if a single key is compromised,
3. Limits the use of a particular algorithm (e.g., to its estimated effective lifetime),
4. Limits the time available for attempts to penetrate physical, procedural, and logical access mechanisms that protect a key from unauthorized disclosure,
5 Limits the period within which information may be compromised by inadvertent disclosure of keying material to unauthorized entities, and
6. Limits the time available for computationally intensive cryptanalytic attacks (in applications where long-term key protection is not required).
There are many factors that affect the cryptoperiod for example the type of encryption algorithm, the operating environment (where the data is and how easy it is to get to), the volume of data and the number of copies of the keys and how those keys are distributed.
As the publication states, the shorter the cryptoperiod, the more secure the solution is. But even this publication states “Cryptoperiods are generally made longer for stored data because the overhead of re-encryption associated with changing keys may be burdensome”. And this is where the problem starts. Because of the downtown associated with rekeying encrypted data, most organizations and standards bodies look for a way to avoid rekeying data or at least make it optional. And thus, the cryptoperiod becomes larger and larger and thus the security of the solution is weakened. Having said all this, the NIST recommendation for symmetric Data Encryption Keys (DEKs) is 2 years or less.
I have seen again and again the look on peoples faces when they have to contemplate rekey operations. And I can see why. Until recently, it results in another major outage and could result in a number of difficulties. With HyTrust DataControl, it’s simply a matter of policy. You determine in KeyControl how often you want rekey to take place and that’s it. You’ll get an audit record when it starts and one when it finishes. Applications remain online and in periods of heavy I/O, the rekey operations are throttled so they don’t affect performance. It’s as simple as that.