Encryption Key Management Essentials

June 13, 2020

10916

WHAT IS ENCRYPTION KEY MANAGEMENT?

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.

ENCRYPTION KEY MANAGEMENT and PCI COMPLIANCE

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:

Preserving “recorded architecture definition” for data protection
Limiting ‘access to the fewest number of custodians available for cryptographic keys’
Store encryption keys ‘at any time in one (or more) of the following forms:’
- Crypt key for data encryption with main encryption key
- In a secure cryptographic device

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:

Generating of cryptographically strong encryption keys
Secure key-distribution
Secure storage of keys
Cryptoperiod setting for all keys
Retiring and destroying the keys

NIST Recommendation for Key Management

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:

Key lifecycle: generation of key, pre-activation, activation, expiry, post-activation, escrow and destruction
Physical access to key servers
Access to Key Servers logically
Access to the encryption keys by user / role

TYPES OF ENCRYPTION KEYS

Symmetric Keys: Data-at-Rest

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.

Asymmetric Keys: Data-in-Motion

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:

Public Key: This key is primarily used for data encryption and can be freely given as it is used for data encryption, not decryption.
Private Key: This key is used to decrypt the data which has been encrypted by its equivalent, the public key. This key must be secured, since it is the only key that can decrypt encrypted data.
Asymmetric keys are used primarily for the data-in-motion security. An example may be the connection to a virtual private network (VPN). Using a VPN to:
- To encrypt the data with an AES symmetric session key
  - Use a public key to encrypt the session key
- After obtaining the encrypted data the private key is used to decrypt the session key
  - So that the data can be decrypted.

HOW ENCRYPTION KEY SYSTEMS WORK

Symmetric Key Systems

First, let’s sort out a few definitions:

Data encryption key (DEK): Is an encryption key which has the function of encrypting and decrypting data.
Key encryption key (KEK): Is an encryption key which has the function of encrypting and decrypting the DEK.
Key application program interface (KM API): Is a programming interface designed to safely retrieve and transfer encryption keys to the client requesting the keys from a key management server.
Certificate Authority (CA): Is an entity creating public and private keys, creating certificates, verifying certificates and performing other PKI functions.
Transport layer security (TLS): Is a cryptographic protocol providing protection for data-in-motion over a computer network via mutual authentication.
Key Management System (KMS): is the key management software house system

Now, with the meanings in order, a step-by-step example is given below as to how an authorized user accesses encrypted data:

User requests access to encrypted data.
The database, application, file system, or storage will then send a request to the client for DEK retrieval (KM API).
Afterwards, the client (KM API) and KM check each other’s certificates:
- A certificate is sent to KM by the client (KM API) for verification.
- The KM then verifies authentication of the certificate against the CA.
- When the client (KM API) certificate has been checked, the KM will then forward its authentication and approval certificate to the KM API.
Once the certificates have been approved, a stable TLS connection between the client (KM API) and the KM will be created.
The KM then decipheres the DEK requested with the KEK
Over the encrypted TLS session the KM sends the DEK to the client (KM API).
Afterwards, the KM API sends the DEK to the database, application, file system or storage.
The database (may) stores the DEK in protected temporary memory.
The database, program, file system, or storage would then submit user information on the plaintext.

Asymmetric Key Systems

The Sender and Recipient verify the certificates of each other:
- For verification the sender sends the certificate to the recipient.
- The receiver then checks the certificate for authentication against their Certificate Authority (CA) or an external Validation Authority (VA).
- If the sender’s certificate has been confirmed, the receiver must then send their certificate for authentication and approval to the sender.
If it has mutual acceptance between the sender and the recipient:
- The sender demands public key from the receiver.
- The receiver sends the sender its public key.
The sender creates a symmetric ephemeral key and encrypts the file to be sent.
The sender uses the public key to encrypt the symmetric key.
The sender then sends data encrypted with the symmetric key encrypted.
The receiver receives the packet, and the private key decrypts the symmetric key.
The receiver decipheres the data using the symmetric key.

THE FULL LIFE-CYCLE OF KEYS

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:

Let’s assume a database is encrypted, and objects are added to it for the next 6 months. Then, there’s:
- The 6 month OUP
The database is also used by permitted users for 2 years. Then, there’s:
- The RUP is 2 years old
The crypto-period would then be equivalent to 2 years and the encryption key would need to be active at that time.

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:

Info mount protected by a given key
Exposure amount in case a single key is compromised
Time spent trying to reach physical, procedural and logical access
Duration during which knowledge can be compromised by inadvertent revelation
Time for computer intensive cryptanalytic attacks

That can be comes down to a few important questions:

How long the data will be used
How the data is used
How much data it contains
How sensitive the data is
How much damage if the data is exposed or the keys are lost

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.

Key Creation

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.

Key Use and Rollover

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.

Key Revocation

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.

Back Up

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.

Key Deletion

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.

SEGREGATED ROLES IN KEY MANAGEMENT

Separation of Duties for Encryption Key Management

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.

Dual Control for Encryption Key Management

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.

Split Knowledge for Encryption Key Management

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.

NIST Key Management Guidelines