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. Users 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, scheduled for deletion, or deleted. The key status is inherited by all versions of that key. For example, if a key with three 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 switched to disabled, all , 3 versions are 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 life cycle key is described below.

• 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.

• Scheduled for deletion
  These are keys that are no longer in use and have been scheduled for deletion by the user to prevent misuse and reduce unnecessary maintenance/management. Keys in the delete requested status 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 scheduled 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 method 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:1. The user directly generates the key and 'seals' it by encrypting it with a user-managed key.2. Using 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 Keys

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 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 one (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 Hardware Security Module (HSM), ensuring FIPS 140-3 Level 3 protection. Additionally, all access records to HSM are logged.