Encryption Key Management

Posted in Technopedia, Application Security

Encryption key management is the administration of tasks involved with protecting, storing, backing up and organizing encryption keys.

High-profile data losses and regulatory compliance requirements have spurred a dramatic increase in the use of encryption in the enterprise. The problem is that a single enterprise might use several dozen different and possibly incompatible encryption tools, resulting in thousands of encryption keys -- each of which must be securely stored, adequately protected and reliably retrievable.

There are a number of encryption key management standards efforts underway. IEEE is developing P1619-3, a data storage key management standard. In addition, Brocade, Cisco Systems Inc., EMC, Hewlett-Packard (HP) Co., IBM Corp., LSI Corp., NetApp, Seagate Technology and Thales e-Security recently submitted a standard called the Key Management Interoperability Protocol (KMIP) to the Organization for the Advancement of Structured Information Standards (OASIS).

Vendors of encryption key management products include Entrust, NetApp (Decru), PGP, Protegrity, RSA (EMC), SafeNet (Ingarian), Thales, Venafi, Vormetric and WinMagic.
Types of keys

Encryption Key ManagementBelow are some different types of keys as described by NIST in the Key lifecycle documentation available
  • Signing Keys
  • Transport Private Keys
  • Public Keys Used to Verify
  • Static Key Agreement Private Keys
  • Digital Signatures
  • Static Key Agreement Public Keys
  • Secret Authentication Keys
  • Domain Parameters
  • Public Authorization Keys
  • Initialization Vectors
  • Long term Data Encrypting Keys
  • Shared Secrets
  • Encrypted Keys
  • Seeds
  • Master Keys Used to Derive

Key management

Good key management entails 10 simple yet necessary steps which will ensure that you will be able to gain access to your data or communications in a secure manner when you need it. Reference: NIST

Generally Should Archive
  • Signature verification key,
  • Secret authentication key,
  • Public authentication key,
  • Long term data encryption,
  • Key encrypting key used,
  • Key for key wrapping
  • Domain parameters
Should Not Archive
  • Signing key,
  • Private authentication key,
  • Short term data encryption key,
  • RNG key,
  • Key transport public key,
  • Ephemeral key agreement,
  • Private keys,
  • Secret authorization key,
  • Private authorization key,
  • Public authorization key,
  • Intermediate results and key material.
  1. Make a backup of your encryption keys. If the encryption keys change, ensure that the changes are also backed up. This includes the restorability of the keys that are used for your archived data. If ever you need to restore the data you will need to decrypt the data. Countless organizations fall victim to this because of poor key management.
  2. Ensure that the backups are recoverable and an effective disaster recovery plan that details the recovery of the keys from backup is in place. If historical data has been encrypted then this data should also be recovered and decrypted as part of your test. Note: As discussed in this article, storing the decryption keys with the encrypted data is bad practice, for this reason the keys should not be stored on the tapes that contain the encrypted achieved data.
  3. Make sure that the logical access control to your encryption keys is secure and available to authorized users. Logical access to keys plays a vital role in keeping your data encrypted. Storing encryption keys on your local drives can lead to compromise, especially if the computer or device is partially encrypted. Typically keys are stored securely out of reach in a secure location.
  4. Ensure that the keys are stored in a physically secure environment and that only authorized users can gain access to the keys. Physical access controls are of high importance as disruption in the key availability may result in failure in the decryption process.
  5. Escrow the keys with a trusted third party, although you may feel that this is not a necessary step when things go wrong, I can assure you, you will wish you had escrowed the keys. Typically keys are escrowed and kept safely for many organizations without incident.
  6. Ensure that the keys are not stored logically where someone could make a duplicate or destroy the key. Logical access controls are not enough if an unauthorized user can alter the state of the machine that the keys are stored on remotely or physically you will have a denial of service on your hands, resulting in the data not being able to be decrypted.
  7. Ensure that you have a way of disposing the keys, locking out older, possibly compromised keys and creating new keys that will decrypt the data. This process needs to be carefully managed and security needs to be monitored throughout. It is common that through the key issue and revocation process a key compromise is structured by an unauthorized user.
  8. Understand what data and communications has been encrypted by the keys so that if you have to issue a new key you are able to first decrypt and encrypt the data if your software does not perform this function automatically.
  9. Ensure that the key is only used and issued from a secure system; often this rule is overlooked and will result in compromise. Not all computer systems are secure and as rootkits and software recording software become more pervasive caution needs to be taken when using the decryption key. Systems like the ones found at internet kiosks and other public facilities are good examples where more caution is needed.
  10. Ensure that the key generation process has high security and that the process has integrity.
The above ten rules are guidelines that will aid an organization and individual in effectively managing keys to their most confidential information. On many occasions, decryption fails because of fundamental pitfalls made by key staff members that manage keys but lack the experience to make the right decisions.
Key Management Lifecycle

The first step in the key management lifecycle is to generate the key. Key creation must be conducted in a secure environment (hardened system), and may include the need to conform to requirements for separation of duties. In most cases, the key generated will be a symmetric key (a.k.a. [shared key]). The key should be of an adequate strength, and is reliant in part on the underlying ability to generate a random number. Key strength (generally measured in number of bits) is typically based on the project valid lifetime of the data being protected, combined with the time it takes to break (via brute forcing) keys within a given crypto scheme. For example, if your data is valid for 5 years, then you want a key that can withstand brute force attacks for longer than 5 years. In addition to choosing an appropriate key strength, one should also endeavor to choose an encryption algorithm that has been subjected to peer review and academic scrutiny. Proprietary encryption schemes should be avoided, bearing in mind the mantra "if they need to keep the algorithm secret, then it probably means that it cannot withstand scrutiny and is thus a bad technique."

Encryption Key Management Lifecycle

Once your key is generated using known good libraries that have been properly reviewed, it may then be desirable to protect it by encrypting it with the public half of an asymmetric key pair (a.k.a. public key cryptography). In environments where the encryption key must be distributed to other systems, particularly via networks, it is recommended that this practice be followed. From the standpoint of separation of duties, an organization can have one team own and manage the key generation box, but bar them access to the encryption system itself, requiring them to instead encrypt the symmetric key with the public key before providing it to the deployment team.

Before a new key is installed into production, it is imperative that a backup be made. The backup could simply be a matter of writing the key to external media (e.g., CD, DVD, USB drive) and storing it in a physical vault. Or, it may be useful to back it up using an existing traditional backup solution (local or networked).

In either case (though especially for traditional backups), it is highly recommended that a second asymmetric key pair be used to protect the symmetric key. Think of this second public key pair as your [escrow] key. As with the deployment key pair, it is recommended that the public key be used to encrypt the shared key, and then it becomes important that the private half of this key pair be protected and available for recovery operations.

Another consideration in performing backups is to apply the same disaster recovery plans that you would in any other business continuity planning process. The key should be stored in and retrievable from a location that can be accessed within the time requirements specified by the appropriate business owners. Given the potential damage due to catastrophic failure within the crypto system, it is extremely important that your BCP/DR team be briefed in on the system in order to help set and managed backup and recovery requirements and processes.

As already mentioned, it is highly recommended that the new symmetric key be encrypted by a public key prior to being delivered for deployment. This simple step provides a method for separation of duties in an environment where key management activities are not strictly contained within a single system (such as with encryption appliances). Some regulations may require this separation of duties to ensure that no single entity can create a key, deploy a key, and then arbitrarily access and decrypt data without authorization. Workflow practices should be documented and enforced in all cases to support this requirement.

The objective of the deployment phase is to install the new key into the encryption environment, but it is not charged with removing the old key from that environment. Specifically, it is advisable that the new key be deployed and tested for a pre-determined period of time to ensure that operations with the new key are successful before risking a data outage. With modern appliances, these concerns have been reduced, but from a lifecycle perspective, they are still worth bearing in mind. When working with crypto systems, one must tend toward caution, lest a key be lost, effectively removing access to important data. That is to say, errors with crypto systems can become quite costly.

Monitoring may or may not deserve to be its own lifecycle phase as it could just as easily be an area of responsibility that is parallel to the entire key management lifecycle. There are three key aspects to monitoring that should be considered.
  1. It is important to monitor for unauthorized administrative access to crypto systems to ensure that unapproved key management operations are not performed. Any sort of unauthorized operation could have serious consequences for your system, and for your data.
  2. Monitoring the performance of crypto systems is important. The performance of cryptographic calculations tends to be CPU-intensive, which means that your systems may be under significant load. Events such as flash popularity can result in a denial of service on its own, but when combined with an overloaded encryption service, the results could be far more serious, including data corruption or unavailability.
  3. Monitoring the key in production is also important to ensure that the key has been created and deployed properly. If a corrupted key is deployed too quickly without proper vetting, the results could be catastrophic. Similarly, if a fault in the crypto system occurs, then the results could also interrupt service, with a negative impact to the business.
The concept of key rotation is related to key deployment, but they are not synonymous. In rotating keys, the goal is to bring a new encryption key into active use by the crypto system, and to also convert all stored, encrypted data to the new key. This process can be extremely time-consuming and CPU-intensive. However, assuming that all previous steps of the lifecycle have been followed, then this phase can be discretely focused on the conversion activity, and less on the activation of the new key for future encryption requests.

A word of caution: be mindful not to remove an old key from a production system until it can be proven that no data in production is still encrypted with the old key. Failing to perform due diligence, such as doing a manual query for the old key ID may result in data loss or a service outage.

Bearing this warning in mind, the diagram below demonstrates how the lifecycle of the first key will overlap the lifecycle of the new key. Note that Rotation and Expiration are essentially overlapping between the two keys. Also, it's worth noting that Rotation is maintained as a separate phase from Deployment because of its unique considerations, independent of installing a key into the production crypto system.

One additional thought to consider is that there may be good reasons for not performing a batch rollover of stored data from the old key to the new key. E.g., if the data is highly transient (accessed, written, or rewritten with very high frequency), then it may be adequate to instead flag a condition within the calling application such that the data will be automatically converted to the new key as part of the read/write activity. Using such a mechanism can reduce some of the load associated with key rotation.

Encryption Key Management Rotation and Expiration

The chosen strength of an encryption key will primarily take into consideration the length of time for which the data may be valid. In addition to key strength, it has also become best practice (and dictated by regulations like PCI DSS) that keys be expired and replaced on a timeframe shorter than the calculated life span of the key. The minimum time span that is advocated these days is one year for each key, and preferably shorter for keys protecting data of greater sensitivity.

The Expiration phase of key management represents the beginning of the deprecation period for the key. Key rotation should be completed prior to expiration, with all data encrypted with that key converted to the new key. The objective is to have the key replaced within the production system (but not removed) before it expires. In a sense, expiration represents a gating factor for planning, as much as it is a discrete phase in the lifecycle.

The absolute last thing that you want to do when managing crypto systems is to destroy a key that still has data associated with it. Therefore, the second-to-last phase in the lifecycle is included, with a potentially open-ended mandate to not proceed to the final phase.
Archival of expired, decommissioned keys should be based on a determination of whether or not data still exists somewhere in the data ecosystem that may be encrypted with the archived key. The data ecosystem extends beyond live data in production to backups that may exist in disaster recovery sites, as well as to all offline backups. If there is a requirement for data to be recoverable, then it is imperative that the keys be archived in parallel to that data.

Here are a couple tips to keep in mind when archiving a key:
  1. Document and index the key and its associated data in such a way that, should you need to recover the data with an archived key, you can do so in as effective and efficient a manner as possible. Documentation of the key should also include the time period during which the key was in use to help narrow down the search for an appropriate key in a recovery scenario.
  2. Ensure that the archived copy of the key has itself been secured. As was recommended in the Creation and Deployment phases, it may be useful to encrypt the symmetric key with the public half of an asymmetric key pair.
  3. Include recovery of encrypted data using archived keys as part of your routing BCP/DR testing procedures.

It is worth noting that some cryptographic appliances automatically archive expired keys in a secure fashion and may not ever move to the final phase, Destruction. Overall, this is a business risk decision that should be considered on a case-by-case basis. It may be rightfully concluded that encryptions keys will never advance from Archival to Destruction because the risk of such a change, and the associated permanence of the loss, may outweigh the risk of exposing the archived key.

The life of a key will end when it is destroyed. Key destruction should follow secure deletion procedures so as to ensure that it is properly obliterated. Be warned: key destruction should not be taken lightly, and should only occur after an adequately long Archival phase, and after at least two reviews have been completed to ensure that loss of the key will not correspond to loss of data.
Whitepaper: Key Management Lifecycle

Share This

Comments (0)

Leave a comment

Please login to leave a comment. Optional login below.