A Key Management solution that an enterprise selects must ensure that data encryption does not disrupt organizational functions. Key Management solutions must provide secure administration of keys through their life cycle. This includes generation, use, distribution, storage, recovery, rotation, termination, auditing, and archival.
This is the multi-page printable view of this section. Click here to print.
Key Management
Overview of Key Management to explain its importance and impact on Protegrity products.
- 1: Protegrity Key Management
- 2: Key Management Web UI
- 3: Working with Keys
- 4: Key Points for Key Management
- 5: Keys-Related Terminology
1 - Protegrity Key Management
The Protegrity Data Security platform uses many keys to protect your sensitive data. The Protegrity Key Management solution manages the keys.
The following keys are a part of the Protegrity Key Management solution:
- Key Encryption Key (KEK): The cryptographic key used to protect other keys. It is also known as the Master Key (MK). It protects the Data Store Keys, Repository Keys, Signing Keys, and Data Element Keys.
- Data Encryption Key (DEK): The cryptographic keys used to protect sensitive data. The Data Encryption Keys (DEKs) are categorized as follows:
- Repository Key: It protects the policy information in the ESA.
- Signing Key: The protector utilizes the signing key to sign the audit logs for each data protection operation.
- Data Store Key: These keys are no longer used and are only present due to backward compatibility.
- Data Element Key: The cryptographic key that is used to protect sensitive data linked to an encryption data element.
Key Encryption Key (KEK) in Protegrity
- The Protegrity Key Encryption Key (KEK) is known as the Master Key (MK).
- It uses AES with a 256-bit key.
- The MK is non-exportable and is generated and stored within the active Key Store.
- The MK is responsible for protecting all the DEKs.
- The MK, RK, and signing key are generated when the ESA Policy and Key Management is initialized.
Data Encryption Keys (DEKs) in Protegrity
- The Repository Key (RK), Signing Key, Data Store Keys (DSKs), and Data Element Keys are collectively referred to as the (DEKs).
- The RK, Signing Key, and DSK are AES 256-bit keys.
- The Data Element Keys can be both 128-bit and 256-bit keys depending on the protection method used.
- The DEKs are generated by the active Key Store.
Key Usage Overview
In the Protegrity Data Security Platform, endpoint protection is implemented through policies. The keys form a part of the underlying infrastructure of a policy and are not explicitly visible.
The following figure provides an overview of the key management workflow.
- All MKs are stored in the Key Store.
- In the ESA, all DEKs are stored and protected by the MK.
- In the Protector, the Signing key and Data Element Keys are stored in the memory.
Certificates
Certificates in Protegrity are generated when the ESA is installed. These certificates are used for internal communication between various components in the ESA. Their related keys are used for communication between the ESA and protectors.
For more information about certificates, refer to the section Certificates in ESA in the Certificate Management.
Key Store
A Key Store is a device used to generate keys, store keys, and perform cryptographic operations. The MK is stored in the Key Store and it is used to protect and un-protect DEKs.
When an enterprise implements a data protection solution in their infrastructure, they must carefully consider the type of Key Store to use as part of the implementation strategy. The Key Store can be connected to the Soft HSM, HSM, or KMS.
When the ESA is installed, the internal Protegrity Soft HSM generates the Master Key (MK). When switching Key Store, a new MK is generated in the new Key Store. The existing DEKs are re-protected using this new MK and the old MK is deactivated.
Protegrity Soft HSM: The Protegrity Soft HSM is an internal Soft HSM bundled with the ESA. The Protegrity Soft HSM provides all the functionalities that are provided by an HSM. Using the Protegrity Soft HSM ensures that keys remain within the secure perimeter of the data security solution (ESA).
HSM: The Protegrity Data Security Platform provides you the flexibility, if needed, to switch to an HSM.
Ensure that the HSM supports the PKCS #11 interface.
For more information about switching from the Key Store, refer to the HSM Integration.
Cloud HSM: Cloud-hosted Hardware Security Module (Cloud HSM) service enables you to host encryption keys in a cloud-hosted HSM cluster. You can perform cryptographic operations using this service as well. Protegrity supports both Amazon Web Service (AWS) and Google Cloud Platform (GCP) Cloud HSM. The GCP console is used to define a project where keyrings, keys, and key versions can be created. You can use GCP Cloud HSM to ensure the same key life cycles as on-premise.
Warning: Ensure that the project location supports creating HSM level keys.
For more information about switching Protegrity Soft HSM to Cloud HSM and Configuring the Keystore with the AWS Customer Managed Keys, refer to the Key Management Service (KMS) Integration on the Cloud Platforms.
2 - Key Management Web UI
The Key Management Web UI lets you initialize and manage the master keys, respository keys, data store keys, signing keys, and data element keys.
Master Keys Web UI
Information related to Master Keys, such as, state, timestamps for key creation and modification, and so on is available on the Master Keys Web UI.
The following image shows the Master Keys UI.
Repository Keys Web UI
Information related to Repository keys, such as, state, timestamps for key creation and modification, and so on is available on the Repository Keys Web UI.
The following image shows the Repository Keys UI.
Data Store Keys Web UI
Information related to DSKs, such as, state, timestamps for key creation and modification, and so on is available on the Data Store Keys Web UI.
The following image shows the Data Store Keys UI.
The options available as part of the UI are explained in the following table.
| No. | Option | Description |
|---|---|---|
| 1 | Select multiple Data Store | Select the check box to rotate multiple Data Stores at the same time. |
| 2 | Data Store Name | Click to view information related to Active DSK and older keys. |
| 3 | UID | Unique identifier of the key. |
| 4 | State | Current State of the DSK linked to the Data Store. |
| 5 | OUP | The period of time in the cryptoperiod of a symmetric key during which cryptographic protection may be applied to data. |
| 6 | RUP | The period of time during the cryptoperiod of a symmetric key during which the protected information is processed. |
| 7 | Generated By | Indicates which Key Store has the generated key. |
| 8 | Action | Rotate - Click to rotate the DSK for a Data Store Key. |
| 9 | Rotate | Click to rotate the DSK for multiple selected Data Store Keys. |
If you click the Data Store name, for example DS1, you can view detailed information about the active key and older keys.
The Action column provides an option to change the state of a key to Destroyed or mark the key as Compromised. For more information about the options available for DSK states, refer to Changing Key States.
Signing Key Web UI
The Signing Key is used to add a signature to log records generated for each data protection operation. These signed log records are then sent from the Protector to the ESA. The Signing Key is used to identify if log records have been tampered with and that they are received from the required protection endpoint or Protector.
A single Signing Key is linked and deployed with all the data stores. At a time, only one Signing Key can be in the Active state.
The following image shows the Signing Keys UI.
Data Element Keys Web UI
Information related to Data Element Keys, such as, state, OUP, RUP, and so on is available on the Data Element Keys Web UI.
The following image shows the Data Element Keys UI.
The options available as part of the UI are explained in the following table.
| No | Option | Description |
|---|---|---|
| 1 | Data Element Name | Click to view information related to the Active Data Element Key and older keys. |
| 2 | UID | Unique identifier of the key. |
| 3 | State | Current State of the Data Element Key linked to the Data Element. |
| 4 | OUP | The period of time in the cryptoperiod of a symmetric key during which cryptographic protection may be applied to data. |
| 5 | RUP | The period of time during the cryptoperiod of a symmetric key during which the protected information is processed. |
| 6 | Generated By | Indicates the source of key generation: - Soft HSM - The key has been generated by Protegrity Soft HSM. - Key Store - The Key Store used to generate the key. - Software - This option appears if you have generated the Data Element Key in an earlier version of the ESA before upgrading the ESA to v10.1.0. |
| 7 | Action | Create New Key: Click to create a new key. This option is available only if you have created a Data Element Key with a key ID. |
If you click the Data Element name, for example AeS256KeyID, then you can view detailed information about an active key and older keys.
If key ID is enabled for a data element, then you click Create New Key to create a new key for the data element.
Important: Starting from the ESA v10.1.0, the Data Element Keys are generated by the active Key Store. When MK is rotated, all DEKs needs to be re-protected. As a result, if you are using too many keys, then your system might slow down in the following scenarios:
You are frequently rotating the keys.
You are using too many encryption data elements where the Key ID is enabled. This allows you to create multiple keys for the same encryption data element.
You are using too many data stores.
Your connection to the HSM is slow.
You can find out the total number of keys currently in use from the Keys area in the Policy Management Dashboard.
3 - Working with Keys
In the Protegrity Key Management, you can view information about keys, key stores, and manage the life cycle of different keys including key rotation.
Key rotation involves putting the new encryption key into active use. Key rotation can take place when the key is about to expire or when it needs to be deactivated due to malicious threats.
Master Key (MK), Repository Key (RK), Data Store Key (DSK), and Signing Key
The key rotation for KEKs and DEKs in the Protegrity Data Security Platform can be described as follows:
- The Master Key (MK), Repository Key (RK), Data Store Key (DSK), and Signing Key can be rotated using the ESA Web UI.
- The supported states for the MK, RK, DSK, and Signing Key are Active, Deactivated, Compromised, and Destroyed.
- When the ESA is installed, the MK, RK, and Signing Key are in the Active state.
- When the MK, RK, DSK, and Signing Key is rotated, the old key state changes from Active to Deactivated, while the new key becomes Active.
- The MK, RK, DSK, and Signing Key is set for automatic rotation ten days prior to the Originator Usage Period (OUP) expiration date by default.
- On the ESA Web UI, navigate to Key Management > Key Name to view the key details.
- The rotation for the MK, RK, DSK, and Signing Key from the ESA Web UI requires the user to be assigned with the KeyManager role.
Viewing the Key Information
You can view the MK,RK, DSK, and Signing Key information, such as, state, OUP, RUP,and other details using the Web UI. To view the key information:
- On the ESA Web UI, click Key Management > Required Key tab.
For example; if you select MK, the MK screen appears.
- In the Current key info section, view the current key information.
- The table displays the information related to the older Master Key.
You can rotate the MK, RK, DSK, and Signing Key by clicking the Rotate button.
Changing the Key States
The following table provides information about the possible key states for MK, RK, DSK, and Signing Key that you can change based on their current state.
Current Key State | Can change state to | State Change | |
State | Reason | ||
Active | Deactivated |
| Auto |
Deactivated | Compromised | Key is compromised. | Manual |
Destroyed | Organization requirement | Manual | |
In the Deactivated key state, you can -
- Click Compromised to mark the key as Compromised and display a Compromised label next to the state.
- Click Destroy to mark the key as Destroyed and display a Destroyed label next to the state.
Data Element Keys
Data elements can have key IDs associated with them. Key IDs are a way to correlate a data element with its encrypted data. When a data element is created, and if the protection method is key based, a unique Data Element Key is generated. This key is seen in the Key Management Web UI.
Information related to Data Element Keys, such as, state, OUP, RUP, and so on is available on the Data Element Keys Web UI.
To view information about the Data Element Key:
- On the ESA Web UI, click Key Management > Data Element Keys.
The View and manage Data Element Keys screen displays the list of data element keys. - Click a data element name, for example DE1. The Data Elements tab appears, which displays the current information about the Data Element Key.
- The table displays the information related to the older Data Element Keys.
Data Element Key States
This section describes the key states for the Data Element Keys.
The following table provides information about the possible key states for the Data Element Keys that you can change based on their current state.
Current Key State | Can change state to | State Change | |
State | Reason | ||
| Preactive | Active | Deploying a policy | Auto |
Active | Deactivated | Adding a new key to the data element.If you click the Data Element name, for example AES256KeyID, then you click Create New Key button to create a new key for the data element. | Auto |
When you create a new key, its state is set to Preactive state.
Key Cryptoperiod and States
Cryptoperiods can be defined as the time span for which the key remains available for use across an enterprise. Setting cryptoperiods ensures that the probability of key compromise by external threats is limited. Shorter cryptoperiods ensure that the strength of security is greater.
In the ESA, the Master Key, Repository Key, Signing Key, Data Store Key, and the Data Element Keys are governed by cryptoperiods. For these keys in the ESA, the validity is dictated by the Originator Usage Period (OUP) and the Recipient Usage Period (RUP). The OUP is the period until when the key can be used for protection, while the RUP is the period when the key can be used to unprotect only.
For keys in Protegrity, the following table provides the OUP and RUP information.
| Key Name | OUP | RUP |
|---|---|---|
| Master Key | 1 Year | 1 Year |
| Repository Key | <=2 Years | <=5 Years |
| Data Store Key | <=2 Years | <=5 Years |
| Signing Key | <=2 Years | <=5 Years |
| Data Element Key | <=2 Years | <=5 Years |
For more information about key states, refer to Changing Key States.
4 - Key Points for Key Management
Key Points be followed to leverage the best out of the Protegrity Key Management functionality.
- The user must have the KeyManager role to rotate the Repository Key (RK), Master Key (MK), Signing Key, and Data Store Key (DSK).
- Key Rotation must be performed only after reviewing the existing policies or regulatory compliances followed by your organization.
- It is essential that a Corporate Incident Response Plan is drafted to:
- Understand the security risks of key rotation.
- Handle situations where keys might be compromised.
- Consult with security professionals, such as Protegrity, to understand how to enable key rotation. Minimize the impact on business processes affected by the keys during this process.
5 - Keys-Related Terminology
A definition of terminologies related to the keys.
The following table provides an introduction to terminology related to keys that can help you understand Protegrity Key Management.
| Term | Definition |
|---|---|
| Master Key (MK) | It is generated and stored in the Key Store. When the Key Management is initialized, the Key Store is switched or active key is rotated. MK protects all DEKs in the Policy repository. |
| Repository Key (RK) | It is generated in the configured Key Store when the Key Management is initialized or active key is rotated. It is protected by MK. It protects the Policy Repository in ESA. |
| Data Store Keys (DSK) | It is generated in the configured Key Store when a Data Store is created. It is protected by MK. It is only used to protect staging located on the ESA. |
| Signing Key | It is generated in the configured Key Store when the ESA is installed and key management is initialized. It is protected by MK.It is used to sign the audits generated by protectors. It is used by the Protector to add a signature to the log records generated for each data protection operation, which are then sent from the Protector to the ESA.The Signing Key helps to identify that the log records have not been tampered with and are received from the required protection endpoint or Protector. |
| Key Encryption Keys (KEK) | It protects other keys. In Protegrity Data Security Platform, the MK is the KEK. |
| Data Encryption Keys (DEK) | It is used to protect data. In the Protegrity Data Security Platform, the RK, Signing Key, DSK, and Data Element Keys are the DEKs. |
| Data Element Keys | It is generated when a data element is created. This key protects the sensitive data. |
| Protegrity Soft HSM | It is internally housed in the ESA. It is used to generate keys and stores the Master key. |
| Key Store - HSM or KMS | The Key Store can be a Hardware Security Module (HSM), or other supported Key Management Service (KMS) that can store keys and perform cryptographic operations. |
| NIST 800-57 | NIST Special Publication 800-57 defines best practices and recommendations for the Key Management. |
| FIPS 140-2 | Federal information process standard (FIPS) used to accredit cryptographic modules. |
| PKCS#11 Interface | Standard API for Key Management. |
| Key States | The state of a key during the key life cycle. |
| Cryptoperiods | The time span during which a specific key is authorized for use or in which the keys for a given system or application may remain in effect. |
| Originator Usage Period (OUP) | The period of time in the cryptoperiod of a symmetric key during which cryptographic protection may be applied to data |
| Recipient Usage Period (RUP) | The period of time during the cryptoperiod of a symmetric key during which the protected information is processed. |
| Endpoint | It is the protection endpoint. In most cases, it is the Protector. |
| Policy Repository | Internal storage in ESA, which stores policy information including the Master key properties and all DEK properties. |