Key Management Service concepts

Available in Classic and VPC

Data encryption

Encryption refers to the process of converting plaintext data into unintelligible ciphertext using an arbitrary key, thereby providing confidentiality to the data. You can retrieve the original plaintext data by undergoing a decryption process using the appropriate key for the ciphertext. The most crucial element in this process is the "key." If the key is securely protected, the likelihood of plaintext exposure is minimal. If the sending and receiving parties have a securely shared key, they can ensure data confidentiality by using the key for encryption and decryption during communication. While there are various methods for securely sharing keys between sender and receiver for data encryption and decryption, the most commonly known method is using the SSL/TLS protocol. Encryption can be used not only for exchanging data but also for secure storage. In cases where data needs to be stored in an encrypted form in databases or other storage systems, it is crucial to manage the encryption key securely to prevent external exposure.

Key lifecycle

Encryption keys used for data encryption have a series of lifecycle stages from creation to destruction. According to the lifecycle, keys are classified as available, disabled, requested for deletion, or deleted. The key status is inherited by all versions of that key. For example, if a key with 3 versions is transitioned to a disabled state, all versions of that key also become disabled. If the key is reactivated and changed to an available state, each version is automatically restored to its previous state.

Key Management Service allows you to create and manage up to 100 versions of a key. The status of a key is inherited to all versions of that key. For example, if the status of a key with 3 versions is transitioned to disabled, all 3 versions of that key also become disabled. If the key is reactivated and changed to an available state, each version is automatically restored to its previous state. Each status of a lifecycle key is described as follows:

• Created
  When a key is requested to be created, it is securely created and given a unique identifier, following key generation procedures in accordance with key management recommendations. Created keys are securely stored in encrypted storage, and a backup point is created for emergency.

• Available
  A key that can be used for all encryption/decryption requests. Created keys are automatically enabled and put into the available state, and can be disabled at any time. Keys in the available state are subject to billing for management.

• Disabled
  A key that has been disabled and can be reactivated at any time to return it to the available state. Keys in a disabled state still follow the rotation cycle and are updated to a new version on the next rotation date. Disabled keys cannot be used for encryption/decryption requests, but management costs are still incurred.

• Requested for deletion
  These are keys that are no longer in use and have been requested for deletion by the user to prevent misuse and reduce unnecessary maintenance/management. Keys in the requested for deletion state are permanently deleted 72 hours after the user's request to delete the keys. Keys deleted at the user's request cannot be recovered, so it's crucial to carefully verify that no keys are in use when making a deletion request. However, you can cancel the deletion request before final deletion, and a key with a canceled deletion request is immediately placed in a disabled status. Keys in the requested for deletion state also follow the rotation cycle and are subject to management charges. If there are no users, you can also click the Delete immediatelybutton to process the deletion right away.

• Deleted
  These are keys that have been permanently and finally deleted, with the raw key (the actual cryptographic key bit data) being deleted immediately. Management information other than the key value is completely deleted after the monthly settlement process. Keys that have been finally deleted cannot be recovered under any circumstances.

Envelope encryption

There are various methods of encrypting data using keys. Among these, Envelope Encryption is recommended because it satisfies both data confidentiality and control through hierarchical key management. This document introduces the concept of envelope encryption and explains the key hierarchy structure and policies that should be understood when using envelope encryption with Key Management Service.

Hierarchical key management

While encryption is generally used to protect data, encryption alone does not guarantee perfect data protection. The level of data protection depends not simply on whether encryption is used, but on how the encryption keys are managed. As there are many complex factors in key management, it is most desirable to use a secure key management solution. An important element in this process is ensuring control over the data. Data control means not only being able to access data when needed, but also adhering to access control principles that block unauthorized access. Storing keys externally can increase threats to data control by creating more external points where data decryption is possible.

One of the best-known secure key management methods is to manage keys hierarchically. This means protecting the key that encrypts the data by encrypting it with another higher-level key. This method, known as key Sealing or key Wrapping, can ensure a certain level of data control when using remote cryptographic key management solutions. The higher-level key that protects the key encrypting the data is generally called a master key. Managing the master key with an internal or external key management solution can reduce threats to data control. This hierarchical key management method is called Envelope Encryption, which doesn't directly encrypt the data but protects the key that encrypts the data, thus simultaneously satisfying data confidentiality and control.

In envelope encryption, the key that actually encrypts and decrypts the data is the data key. By applying the envelope encryption type using Key Management Service, you can securely manage the data key by sealing it. However, when actually encrypting or decrypting data, you use the unsealed data key. Once you receive the unsealed key through the Key Management Service, the responsibility for managing that key lies with you, the user. Therefore, it is recommended to immediately delete the key after encrypting or decrypting the data, and to only store the data key in its sealed form.

Key management policies

Due to the hierarchical key structure in Key Management Service, it's necessary to understand the concepts and roles of key keys at each level.

Data Encryption Key

The key used for data encryption/decryption should be securely stored in the user-managed area. Using Key Management Service to protect the data encryption key can reduce the administrative burden. There are two methods to protect the data encryption key. One is to generate your own key and "seal" it by encrypting it with a user-managed key, and the other is to use Create User Custom Key, which is the custom key generation API of Key Management Service. Using the API is very useful as it allows you to obtain both a securely generated random key and its encrypted form using a user-managed key at once.

User-Managed Key

Keys created by users in Key Management Service are operated under user management throughout their entire lifecycle, including creation, rotation, and deletion. Key Management Service administrators or key managers with permissions for specific keys can conveniently manage keys through the NAVER Cloud Platform console. When a user-managed key is used to protect a data encryption key, it is referred to as a Key Encryption Key (KEK) or master key. User-managed keys are encrypted with the root key, which is the topmost key in the KMS system, and stored in the core security storage of Key Management Service.

Root Key

The root key is generated through a secure process and is then operated according to the same management policies as user-managed keys. For example, the root key is also rotated and renewed on a 1 year basis, and strict key access permission management is implemented. The only differences from user-managed keys are that key storage and management are done through Hardware Security Module (HSM), and the key activation procedure is performed offline. To protect against loss or malicious actions by administrators, the root key is stored in HSM, ensuring FIPS 140-3 Level 3 protection. Additionally, all access records to HSM are logged.

Key isolation

Personal information and other sensitive data are subject to strict legal regulations that vary by country. Key Management Service limits the usage scope of keys that encrypt sensitive data to reduce the risk of overseas exposure and support compliance with relevant laws.

Key boundary

Key boundary defines the physical scope for key usage and storage. You can specify this setting when protecting sensitive data or complying with country-specific regulations.

• You can select either Global or Region-based boundaries when creating a key.
• Currently, Region-based boundaries are only supported in Korea (KR) and Japan (JP) Regions. All other Regions apply the Global boundary setting.
• Only the following operations are allowed within the specified Region-based boundary:
  • API calls: each Region has a dedicated endpoint for boundary-specific calls. These endpoints can only be accessed within that Region's network.
  • Key storage: keys are redundantly stored only in the region set as the boundary.
• Keys set to any boundary other than Global cannot be accessed from outside the Region or synchronized across Regions.

Region-wide keys

• Keys with a Global boundary are classified as Region-wide keys.
• Region-wide keys can be used and stored without Region restrictions and support inter-Region synchronization.
• The existing key API endpoints continue to function as the endpoint for Region-wide keys.
• All services operate under Korean legal regulations and follow policies based on the Korea Region.

Example: when a key is set to a Global boundary

Region-isolated keys

• Keys set with a Region-based boundary are classified as Region-isolated keys.
• Region-isolated keys are stored within the specified Region and can only be used in that Region.
• Region-isolated keys do not support replication or synchronization across Regions.
• Currently, they are supported only in the Korea (KR) and Japan (JP) Regions.
• Each Region has its unique endpoint, which can be called only through the network of that specific Region.
• While the basic features policy remains the same, handling of personal and sensitive information is subject to legal restrictions specific to each Region.

Example: when a key is set to the Korea (KR) Region as its boundary