Cloud security guidance
Pages
Page 7 of 29
Choosing and configuring a KMS for secure key management in the cloud
Key management services (KMSs) are a common component in cloud services. These are typically used to generate, store, use and destroy cryptographic key material. When designed, operated and used well, a cloud KMS provides functionality for secure storage of encryption keys and use of encryption and digital signature algorithms.
A KMS will typically be a foundational component of the cloud service itself. In cloud platforms, where customers deploy their own applications, the KMS is often made available to customers to secure the services they have built on the cloud platform. For example, you might use the KMS to encrypt database passwords or virtual machine disk images. This is covered in more detail below.
Effective data encryption relies on secure key management, so you should make full use of a cloud provider’s KMS if it meets your needs and meets the requirements for a secure KMS given below.
If you are not satisfied that your service’s KMS offers adequate protection, you should look for a service that is better suited to your security needs.
Public key infrastructure (PKI)
This guidance explains how to identify a secure cloud KMS and how to use it to encrypt data securely. If you need a public key infrastructure (PKI) in the cloud, you should use a managed PKI service, assessed against the NCSC’s PKI guidance. The PKI should use the KMS to store and protect private keys. You should avoid building a PKI yourself. As described in the guidance, you should also be certain that a PKI is the best solution to the problem. In a cloud service, using keys protected and managed by a KMS, alongside robust identity and access management procedures, will often be a better alternative.
How a KMS protects data
The goal of a KMS is to enable strong data encryption by effectively securing access to cryptographic keys. This includes using a combination of cryptography and secure hardware to generate keys securely, to manage access to keys, and to (eventually) destroy keys.
Some KMSs will also perform cryptographic operations for you, allowing you to use keys without the risk of compromise in the process.
A KMS will normally use envelope encryption to manage many keys efficiently and securely. Envelope encryption combines a symmetric encryption algorithm, data encryption keys (DEKs) and key encryption keys (KEKs).
The data encryption key (DEK)
When a piece of data needs to be encrypted, a new DEK is generated and is then used to encrypt the data.
The key encryption key (KEK)
The DEK is then encrypted using a KEK, and the encrypted DEK is stored with the encrypted data. Provided KEKs are stored securely, this gives effective data protection at scale. KEKs are often protected by other KEKs, forming a tree structure. At the top of the tree is a root key encryption key (root KEK), which is protected using secure software or hardware (such as an HSM), rather than encryption.
Use of the keys
The keys protected by a KMS are used in the wider cloud service to support different security functions, such as attestation, data encryption and code signing. Some cloud services will perform these functions directly in the KMS, while others will implement that functionality elsewhere in the cloud service, just using the KMS for key management.
Choosing a secure KMS
When you choose your cloud service, you should be confident that its key management service meets your security needs. To gain the necessary confidence, you should ensure that the KMS meets the following requirements and can be used as described below in using a KMS well.
Encryption of data in transit
It should only be possible to connect to the KMS using an approved protocol with secure settings, such as well-configured TLS. For more details, see Principle 1: Data in transit protection.
Backup of encryption keys
If a key is lost, then all data encrypted under that key (whether it is user data, or another key) is unrecoverable. The cloud provider should therefore automatically facilitate backup of keys to ensure availability of user data. The backups should have at least as much protection as the original keys, during storage and retrieval. You should not expect to be able to export the keys from the backup system. Some cloud providers might duplicate keys across multiple hardware security modules (HSMs), to always ensure availability.
Rotation of encryption keys
Key rotation involves periodically retiring a previously used key and creating a new one to be used in its place. Keys can be rotated, either automatically by the cloud provider, or via user intervention. If regulations or policy require keys to be rotated, you should ensure your cloud provider can perform key rotation for you.
Deletion or revocation of encryption keys
When the data protected by a key is no longer required, it should be possible to delete the key so that the data can no longer be accessed. See Principle 2.4: Data sanitisation and equipment disposal for more details. Similarly, if a key is believed to have been compromised, it should be possible to revoke the key to limit the impact of the compromise.
Such actions could result in a loss of data, so the permissions needed to revoke or delete keys should be carefully assigned as part of your identity and access management system. You may prefer behaviour where a key is disabled and marked for deletion, but not deleted until a fixed time later. This allows you to stop the key being used, while allowing the deletion to be cancelled later avoid unwanted deletion.
Monitor access to encryption keys
KMS activities should be logged, ideally using a logging system provided by the cloud provider which integrates with the KMS. Using the native logging mechanisms allows better automated cross-correlation with activity on other resources in your tenancy and better protects those logs against malicious alteration.
Ensure you can audit the logs to respond to incidents or to look for suspicious activity. Examples of suspicious activity could include a request to access a key for a purpose for which a given service does not have permission, or a significant number of requests from a single user to access a key resource in a short period.
You should be confident that sensitive data such as key material is not logged. You should also apply the principle of least privilege when configuring access to KMS logs, giving access only to those who need it.
Adhere to modern cryptographic standards
As understanding of cryptography and cyber security grows, standards evolve, and recommendations may change. As a result, cryptographic algorithms that are no longer considered secure may be deprecated.
You should be confident that your cloud provider has a strong track record of evolving their approach to cryptography over time, upgrading both hardware and software functionality as required.
This is particularly important with the increased threat to asymmetric cryptography posed by developments in quantum computing. See our guidance on quantum-safe cryptography for more detail.
Using a KMS well
Once you have established the security of the KMS, you should ensure it is used effectively. This may mean configuring the cloud service to meet the requirements below, but you may also need to use the KMS directly.
The KMS is a fundamental part of the cloud and you must rely on the security of the KMS to trust the cloud. Do not try to avoid trusting the KMS. The cloud service’s integrated KMS will provide the best possible security. Creating your own KMS is technically very challenging and the consequences of an implementation error can be disastrous.
Protect access to keys and cryptographic operations
Authentication and authorisation to the KMS should rely on the wider identity and access management offered by the cloud provider. This allows cryptographic permissions to be assigned alongside other permissions and roles for a unified interface. See Principle 9: Secure user management and Principle 10: Identity and authentication for more details.
Permissions should be assigned on a per-key, per-role, per-operation basis to ensure that a service or user only has access to the keys they require and can only use them for authorised purposes. For example, while many users/services might have access to a key so they can encrypt data, only the users who need to be able to decrypt that data should be able to call decrypt routines using that key.
Encrypt data at rest
For protection, user data should always be stored in encrypted form, and only decrypted when needed. For more details, see Principle 2.3: Data encryption.
Encrypt encryption keys
The KMS should use a suitable algorithm and mode of operation for key encryption, along with an appropriate key size, when a KEK is used to encrypt another key. Examples of NIST-approved algorithms include those from NIST-SP-800-131A, such as AES in Key-Wrap mode, as well as authenticated encryption modes, such as AES-GCM.
Protect root key encryption keys
Protections for root KEKs are physical and procedural rather than cryptographic. Ideally, these should be stored in a hardware security module (HSM) with a suitable level of accreditation, eg FIPS-140-2 or FIPS 140-3. You should prefer an independent accreditation of level 3 or higher, as this means that the root key cannot be physically extracted from the hardware without being detected, and that the root key cannot leave the HSM unencrypted.
If an HSM is used, and is shared with other users of the cloud service, separation must be maintained between the keys of different users. Where further control of the HSM is required for policy or regulatory requirements, some cloud providers offer single-tenancy HSMs.
If the KMS offers a choice between storing keys in software and in HSMs, you should configure the KMS to store keys in HSMs. If there is a choice, choose HSMs managed by your cloud provider over HSMs that you must manage, even if this means you need to use multi-tenant HSMs.
Use asymmetric keys appropriately
It may be possible for the KMS to store and use keys for asymmetric cryptography, such as digital signatures, or public key encryption/decryption. If these services are required, only suitable algorithms, key sizes and parameters should be used. For digital signatures, examples of NIST-approved algorithms can be found in FIPS 186-4, which at the time of writing includes ECDSA on the NIST P.256 curve and 2048-bit RSA-PSS digital signatures.
Public key encryption/decryption primitives, such as DEKs, are only designed to encrypt small amounts of data. We recommend that they only be used as a component of an accepted scheme. For example, NIST SP-800-56B approves the use of 2048-bit RSA-OAEP encryption as part of a key transport scheme.
Use different root KEKs for different resources
Ideally, each resource or application protected by your cloud KMS solution should use a different root KEK. If one service is compromised, it will not then spread to other parts of your system.
Note that depending on your cloud provider, there may be limits on the number of root KEKs that can be stored in the KMS, and how often they can be used.
Generate encryption keys appropriately
You should prefer encryption keys generated by the cloud provider. This gives better protection than customer-generated keys (CGK) or customer-managed keys (CMK), also known as bring your own key (BYOK). A similar approach, called hold your own key (HYOK), involves storing encryption keys in your own infrastructure and providing key material to the cloud service whenever data is decrypted. This has all the disadvantages of BYOK, but adds even more complexity and risk of key compromise. You should avoid using BYOK or HYOK unless regulations require it.
Keys generated by the cloud provider in the KMS do not leave the KMS, so they are hard to steal. If you generate your own keys and import them into the KMS, you do not gain any extra security but introduce additional complexity. FIPS 140-2 requires the KMS to have suitable entropy in its key generation.
If regulations require CGK or CMK, you must ensure keys are stored securely and sent to the KMS securely, using encryption in transit as described above.
Integrate key management with data storage services
Many other cloud services will rely on the KMS to protect data. Some services may give you a choice between managing the interaction with the KMS yourself, or having the service handle it for you. You should prefer configurations where the service manages its integration with the KMS, as this gives a more consistent configuration and makes it easier for your cloud provider to identify any issues. Similarly, you should prefer managed services for protecting sensitive data over encrypting the data yourself using the KMS directly. Common services that should rely on the KMS to protect data include:
- VM disk encryption
- encryption in blob storage buckets
- managed PKI services
- secrets management services
