Encryption key management administers the whole cryptographic key lifecycle. This includes: generation, use, storage, archiving and key deletion. Protection of the encryption keys involves controlling physical, logical and user / role access to the keys.
Security best practices and PCI DSS compliance require protection of sensitive data with encryption and physical or logical separation of data encryption keys (DEK) from sensitive data and protection with strong key encryption keys (KEK).
Anyone in their database who needs to protect sensitive data needs to know that storing the encryption keys at the same location puts data at risk of breach.
In addition to PCI DSS, compliance regulations may apply depending on what type of information is being stored and under what industry guidance your project / company falls within.
In PCI DSS requirement 3.5, organizations processing, storing, or transmitting cardholder data should record and enforce procedures to protect keys that are used to secure stored cardholder data from disclosure and misuse. This includes:
Similarly, PCI DSS requirement 3.6 requires you to document all key management processes and procedures for cryptographic keys used to encrypt cardholder data in full and implement them. This includes securely:
NIST notes that proper management of cryptographic keys is important for the successful use of security cryptography. If an attacker knows about a safe combination, the best safe does not provide any protection against intrusion. Similarly, weak key management can compromise strong algorithms easily.
NIST definition shows a detailed picture. Like the combination of a safe, your key to encryption is only as good as the security you use to protect it. There is a complete physical and digital cryptosystem that must be taken into account, as well as the full lifecycle of each key. Hence, a robust key management system and policies for encryption include:
The same encryption key is used in symmetric key cryptography for both encryption and decryption of the data. This method of encryption is mainly used for data security during rest periods. An example would be to encrypting and decrypting sensitive data in ciphertext when stored in a database when accessed by an authorized person, and vice versa.
By comparison, asymmetric keys are a pair of keys to encrypt and decrypt the data. Both keys are both related and created simultaneously. They are called a public and a private key:
First, let’s sort out a few definitions:
Now, with the meanings in order, a step-by-step example is given below as to how an authorized user accesses encrypted data:
The key life-cycle of encryption, defined by NIST as having stages of pre-operation, operation, post-operation, and deletion, includes, among other things, the concept of an operational crypto time for each key.
A crypto-period is the time duration over which a particular key is allowed to be used, and the crypto-period is calculated in Section 5.3 of the NIST Guide by comparing the approximate time during which encryption will be applied to the data with the time when it will be decrypted for use.
So, as an example:
Nonetheless, when an enterprise may fairly want to encrypt and decrypt the same data on end for years, other considerations can come into play when factoring the crypto period:
You may want to restrict this to:
That can be comes down to a few important questions:
As the complexity of data being encrypted increases, the general rule is that the lifespan of an encryption key decreases.
Because of this, your encryption key may have an active life shorter than the access to the data by an authorized user. Which means you need to store deactivated keys and then use them for decryption. Once the data has been decrypted by the old key, the new key will encrypt it, and the old key will no longer be used to encrypt / decrypt data, and can be deleted over time.
The key to encryption is created and stored on the server for key management. The key manager generates the encryption key by using a cryptographically secure random bit generator, and stores the key in the key storage database along with all its attributes.
The key attributes stored include its name, date of activation, size, instance, ability to delete the key, and also their rollover, mirroring, key access and other features. Upon formation or configuration, the key can be triggered automatically or manually at a later time. The encryption key manager will monitor the encryption key in both current and past instances.
You need to be able to select whether the key can be removed or not, mirrored to a failover device and open to users or groups. Your key manager will let the administrator alter at any time several of the key attributes.
The key manager will allow approved systems and users to retrieve an active key for processes of encryption or decryption. It should also be able to manage current and past encryption key instances seamlessly.
For eg, if a new key is created and the old one deactivated every year, then the key manager will maintain previous versions of the key but dispense only the current instance and enable previous versions for decryption processes.
Previous releases can still be retrieved to decrypt encrypted data with such key versions. The key manager may also roll the key either via a schedule previously set, or allow an administrator to roll the key manually.
An administrator should be able to revoke a key using the key manager, so that it is no longer used for requests for encryption and decryption. If required, an administrator may reactivate a revoked key, such that in certain situations the key can be used to decrypt previously encrypted data with it, such as old backups. But even that can be curtailed.
NIST requires that an archive for deactivated keys should be stored. The archive should prevent unauthorized modification, deletion and insertion of the archived material. At the end of its cryptoperiod, the encryption keys must be recoverable and the device must be configured to allow the reconstruction of the keys should they need to be reactivated for use in decrypting the data it once encrypted.
If a key is no longer in use or has been compromised somehow, an administrator can choose to remove the key entirely from the encryption key manager’s key storage database. The key manager can fully delete it and all its instances, or only those instances, and make it impossible to recover the key.
This should be available as an alternative in case confidential data in its encrypted state is compromised. If the key is removed, the vulnerable data would be absolutely protected and unrecoverable, because recreating the encryption key for that data will not be feasible.
In Key Management Recommendation, NIST describes duties separation as a concept of protection that separates critical functions among different staff members in an effort to ensure that no one has sufficient information or privileges to perpetrate harmful fraud.
Practice separation of duties limits the likelihood for fraud or misconduct by splitting related responsibilities between different individuals within an organization for critical activities. It is common in most organizations’ financial and accounting procedures.
For instance, the person who prints checks at a firm wouldn’t be the person who signs the checks. Likewise, the person who signs the checks would not reconcile the bank statements. A company would ensure the classification of business critical duties into four types of functions: authorization, custody, record keeping, and reconciliation. No-one can do more than one form of feature in a perfect program.
In the area of encryption key management, adoption of Separation of Duties is important with respect to information security activities. It is important that the person who manages encryption keys does not have the ability to access protected data, and vice versa, to prevent unwanted access to protected data.
In an information technology context this is no more difficult to accomplish than in a financial context, but is often overlooked or misunderstood in complex computer systems.
NIST, in its Key Management Guideline, describes dual control as a mechanism utilizing two or more different organizations acting in conjunction to protect sensitive functions or information. No one person may access or use the resources, for example cryptographic keys.
Although Separation of Duties includes allocation to different persons of various sections of a process, Dual Control requires that at least two or more entities control a single process.
Due Dual Control criteria for encryption key management functions are generally found in data security practice. Since a key management system can be storing encryption keys for various applications and business organizations, it is critically important to secure encryption keys.
The Split Knowledge principle refers to any access or handling of insecure cryptographic content such as encryption keys or passphrases used to construct encryption keys, and implies that nobody knows the full value of an encryption key.
When creating encryption keys using passphrases, no one should know the entire passphrase. Rather, two or more people should each know only a part of the transfer phrase, and all of them should be present to build or recreate a key for encryption.
