Select the cryptographic data network for each authorized level of processing.
Encryption key management is administering the full lifecycle of cryptographic keys. This includes: generating, using, storing, archiving, and deleting of keys. Protection of the encryption keys includes limiting access to the keys physically, logically, and through user/role access. Show
^Back to Top Introduction“The proper management of cryptographic keys is essential to the effective use of cryptography for security. Keys are analogous to the combination of a safe. If a safe combination is known to an adversary, the strongest safe provides no security against penetration. Similarly, poor key management may easily compromise strong algorithms.”
Let’s get started with a brief overview of the types of encryption keys.
^Back to Top Types of Encryption KeysSymmetric Keys: Data-at-RestIn symmetric key cryptography, the same encryption key is used to both encrypt and decrypt the data. This means of encryption is used primarily to protect data at rest. An example would be to encrypt sensitive data into ciphertext while it is stored in a database and decrypt it to plaintext when it is accessed by an authorized user, and vice versa.Asymmetric Keys: Data-in-MotionAsymmetric keys, on the other hand, are a pair of keys for the encryption and decryption of the data. Both keys are related to each other and created at the same time. They are referred to as a public and a private key:
^Back to Top How Encryption Key Systems WorkSymmetric Key SystemsFirst, let’s establish a few definitions:
This is an interactive graphic, click on the numbers above to learn more about each step Now that we have the definitions in place, below is a step by step example of how an authorized user accesses encrypted data:
Asymmetric Key Systems
^Back to Top The Full Life-Cycle of KeysThe encryption key life-cycle, defined by NIST as having a pre-operational, operational, post-operational, and deletion stages, requires that, among other things, a operational crypto period be defined for each key. A crypto period is the "time span during which a specific key is authorized for use" and in Section 5.3 of NIST's Guide, the crypto period is determined (for example, with a symmetric key) by combining the estimated time during which encryption will be applied to data (the Originator Usage Period (OUP)) and the time when it will be decrypted for use (the Recipient Usage Period (RUP)).
But, since an organization may reasonably want to encrypt and decrypt the same data for years on end, other factors may come into play to when factoring the crypto period: You may want to limit the:
The general rule: as the sensitivity of data being secured increases, the lifetime of an encryption key decreases. Given this, your encryption key may have an active life shorter than an authorized user's access to the data. This means that you will need to archive de-activated keys and use them only for decryption. Once the data has been decrypted by the old key, it will be encrypted by the new key, and over time the old key will no longer be used to encrypt/decrypt data and can be deleted. (see graphic below) See below for a more thorough understanding of a keys full life-cycle. Key Creation (Generation & Pre-Activation)The encryption key is created and stored on the key management server. The key manager creates the encryption key through the use of a cryptographically secure random bit generator and stores the key, along with all it’s attributes, into the key storage database. The attributes stored with the key include its name, activation date, size, instance, the ability for the key to be deleted, as well as its rollover, mirroring, key access, and other attributes. The key can be activated upon its creation or set to be activated automatically or manually at a later time. The encryption key manager should track current and past instances (or versions) of the encryption key. You need to be able to choose whether or not the key can be deleted, mirrored to a failover unit, and by which users or groups it can be accessed. Your key manager should allow the administrator to change many of the key’s attributes at any time. Key Use and Rollover (Activation through Post-Activation)
Key RevocationAn administrator should be able to use the key manager to revoke a key so that it is no longer used for encryption and decryption requests. A revoked key can, if needed, be reactivated by an administrator so that, In certain cases the key can be used to decrypt data previously encrypted with it, like old backups. But even that can be restricted. Back Up (Escrow)NIST (Section 8.3.1) requires that an archive should be kept for deactivated keys. The archive should “protect the archived material from unauthorized [disclosure,] modification, deletion, and insertion.” The encryption keys need “to be recoverable … after the end of its cryptoperiod” and “the system shall be designed to allow reconstruction” of the keys should they need to be reactivated for use in decrypting the data that it once encrypted. Key Deletion (Destruction)If a key is no longer in use or if it has somehow been compromised, an administrator can choose to delete the key entirely from the key storage database of the encryption key manager. The key manager will remove it and all its instances, or just certain instances, completely and make the recovery of that key impossible (other than through a restore from a backup image). This should be available as an option if sensitive data is compromised in its encrypted state. If the key is deleted, the compromised data will be completely secure and unrecoverable since it would be impossible to recreate the encryption key for that data.
^Back to Top Segregated Roles in Key ManagementSeparation of DutiesIn “Recommendation for Key Management – Part 2” NIST defines Separation of Duties as: A security principle that divides critical functions among different staff members in an attempt to ensure that no one individual has enough information or access privilege to perpetrate damaging fraud. The practice of Separation of Duties reduces the potential for fraud or malfeasance by dividing related responsibilities for critical tasks between different individuals in an organization. It is common in the financial and accounting procedures of most organizations. For example, the person who prints the checks at a company would not be the person who signs the checks. Similarly, the individual who signs checks would not reconcile the bank statements. A company would ensure that business critical duties are categorized into four types of functions: authorization, custody, record keeping, and reconciliation. In a perfect system, no one person should handle more than one type of function. Regarding information security practices, the implementation of Separation of Duties is critical in the area of encryption key management. To prevent unwanted access to protected data, it is important that the person who manages encryption keys not have the ability to access protected data, and vice versa. This is no more difficult to accomplish in an information technology context than in a financial context, but is often overlooked or misunderstood in complex computer systems. Dual ControlAgain, NIST, in Recommendation for Key Management – Part 2, defines Dual Control: While Separation of Duties involves distributing different parts of a process to different people, Dual Control requires that at least two or more individuals control a single process. In data security practice it is common to find requirements for Dual Control of encryption key management functions. Because a key management system may be storing encryption keys for multiple applications and business entities, the protection of encryption keys is critically important. Split KnowledgeThe concept of Split Knowledge applies to any access or handling of unprotected cryptographic material like encryption keys or passphrases used to create encryption keys, and requires that no one person know the complete value of an encryption key. If passphrases are used to create encryption keys, no one person should know the entire passphrase. Rather, two or more people should each know only a part of the pass phrase, and all of them would have to be present to create or recreate an encryption key.
^Back to Top The Domains to Secure Encryption KeysPhysical SecurityMany, when talking about securing a key manager, will naturally turn to securing the key manager itself with a hardware security module (HSM). While that is a necessary topic (and we will discuss it), we should first talk about securing the physical environment in which your key manager is housed.In NIST’s Special Publication 800-14, they offer this definition of physical security: “Physical and environmental security controls” should be “implemented to protect the facility housing system resources, the system resources themselves, and the facilities used to support their operation.”An organization's physical security plan need to include things like:
Now comes securing the cryptographic module itself. The Federal Information Processing Standards (FIPS) has identified four levels of increasing security in FIPS 140-2 that can be applied to the module, each corresponding to the commensurate threat level:
Every data security product available makes claims as to superior functionality or data protection. But when protecting sensitive data, organizations need to have assurance that a product's stated security claim is valid. This is certainly true when it comes to an encryption key manager. To address this, NIST has devised a system to validate cryptographic modules and ensure that they comply with FIPS 140-2 standards. Here are the steps an encryption key manager vendor must to take to show full compliance: The next arena in which you can protect your encryption keys is by logically separating the different cryptographic components housing the keys from the rest of the larger network. There are three main items to consider: |