AWS Key Management Service features

If you have AWS CloudTrail enabled for your AWS account, each request you make to AWS KMS is recorded in a log file. This log file is delivered to the Amazon Simple Storage Service (Amazon S3) bucket that you specified when you enabled AWS CloudTrail. The information recorded includes details of the user, time, date, API action, and the key used, when relevant.

AWS KMS is a fully managed service. As your use of encryption grows, the service automatically scales to meet your needs. It helps you manage tens of thousands of KMS keys in your account and to use them whenever you want. It defines default limits for number of keys and request rates, but you can request increased limits if necessary.

The KMS keys you create or ones that are created on your behalf by other AWS services cannot be exported from the service. Therefore, AWS KMS takes responsibility for their durability. To help verify that your keys and your data are highly available, AWS KMS stores multiple copies of encrypted versions of your keys in systems that are designed for 99.999999999% durability.

For encrypted data or digital signature workflows that move across Regions (disaster recovery, multi-Region high availability architectures, DynamoDB Global Tables, and globally distributed consistent digital signatures), you can create KMS multi-Region keys. KMS multi-Region keys are a set of interoperable keys with the same key material and key IDs that can be replicated into multiple Regions.

AWS KMS is designed to be a highly available service with a Regional API endpoint. As most AWS services rely on it for encryption and decryption, AWS KMS is architected to provide a level of availability. This availability supports the rest of AWS and is backed by the AWS KMS Service Level Agreement.

AWS KMS is designed so that no one, including AWS employees, can retrieve your plaintext keys from the service. The service uses hardware security modules (HSMs) that are continually validated under the U.S. National Institute of Standards and Technology (NIST) Federal Information Processing Standards (FIPS) 140-2 Cryptographic Module Validation Program to protect the confidentiality and integrity of your keys. AWS KMS HSMs are the cryptographic root of trust for protecting KMS keys. They create a secure hardware-protected boundary for all cryptographic operations that occur in KMS. All key material for KMS keys generated within AWS KMS HSMs and all operations that require decrypted KMS key material occur strictly within FIPS 140-2 Security Level 3 boundary of these HSMs. Updates to the AWS KMS HSM firmware are controlled by a multi-party access control that is audited and reviewed by an independent group within Amazon; per FIPS 140 requirements, all firmware changes to KMS HSMs are submitted to a NIST accredited lab for validation in compliance with FIPS 140-2 Security Level 3.

Your plaintext keys are never written to disk and only ever used in volatile memory of the HSMs for the time needed to perform your requested cryptographic operation. This is true regardless of whether you request AWS KMS to create keys on your behalf, import them into the service, or create them in an AWS CloudHSM cluster using the custom key store feature. You choose whether to create single Region or multi-Region keys. Single Region keys are never transmitted outside of the AWS Region in which they were created and can be used in only the Region in which they were created.
 

To learn more about how AWS KMS is architected and the cryptography it uses to secure your keys, read the AWS KMS Cryptographic Details whitepaper.

* In the AWS China (Beijing) Region, operated by Beijing Sinnet Technology Co., Ltd. ("Sinnet")Sinnet and the AWS China (Ningxia) Region, operated by Ningxia Western Cloud Data Technology Co., Ltd. ("NWCD") NWCD, the HSMs are Chinese government approved (not FIPS 140-2 validated), and the Cryptographic Details Whitepaper mentioned above does not apply.  

AWS KMS helps you create and use asymmetric KMS keys and data key pairs. You can designate a KMS key for use as a signing key pair, an encryption key pair, or a key agreement key pair. Key pair generation and asymmetric cryptographic operations using these KMS keys are performed inside HSMs. You can request the public portion of the asymmetric KMS key for use in your local applications, while the private portion never leaves the service. You can import the private portion of an asymmetric key from your own key management infrastructure.

You can also request the service to generate an asymmetric data key pair. This operation returns a plaintext copy of the public key, private key, and a copy of the private key encrypted under a symmetric KMS key that you specify. You can use the plaintext public or private key in your local application and store the encrypted copy of the private key for future use.

* Asymmetric keys are not supported with custom key stores.

You can generate and verify Hash-Based Message Authentication Code (HMACs) from within AWS KMS’s FIPS 140-2 validated HSMs. HMACs are a cryptographic building block that incorporate secret key material within a hash function to create a unique keyed message authentication code. HMAC KMS keys provide an advantage over HMACs from application software because the key material is generated and used entirely within AWS KMS. They are also subject to the access controls that you set on the key. The HMAC KMS keys and the HMAC algorithms that AWS KMS uses conform to industry standards defined in RFC 2104. HMAC KMS keys are generated in AWS KMS hardware security modules that are certified under the FIPS 140-2 Cryptographic Module Validation Program and never leave AWS KMS unencrypted. You can also import your own HMAC key from your own key management infrastructure.

*AWS KMS HMAC keys are not supported in custom key stores.
** FIPS 140-2 does not apply to AWS KMS in the AWS China (Beijing) Region, operated by Sinnet and the AWS China (Ningxia) Region, operated by NWCD. The HSMs in China Regions are instead approved for use by the Chinese government.

Security and quality controls in AWS KMS have been validated and certified by the following compliance regimes:

• AWS System and Organization Controls (SOC) reports (SOC 1, SOC 2, and SOC 3). You can download a copy of the reports from AWS Artifact.
• Cloud Computing Compliance Controls Catalog (C5). Learn more the German Government-backed attestation scheme C5.
• Payment Card Industry Data Security Standard (PCI DSS) Level 1. Learn more about PCI DSS compliant services in AWS at PCI DSS FAQs.
• Federal Information Processing Standards (FIPS) 140-2. The AWS KMS cryptographic module is validated at FIPS 140-2 Security Level 3 by the U.S. National Institute of Standards and Technology (NIST). Learn more by viewing the FIPS 140-2 certificate for AWS KMS HSM along with the associated Security Policy.
• Federal Risk and Authorization Management Program (FedRAMP). Learn more about AWS FedRAMP compliance at FedRAMP Compliance.
• Health Insurance Portability and Accountability Act (HIPAA). Learn more on the HIPAA Compliance webpage.

AWS KMS is validated and certified against other compliance regimes listed here.

* FIPS 140-2 does not apply to AWS KMS in the AWS China (Beijing) Region, operated by Sinnet and the AWS China (Ningxia) Region, operated by NWCD. The HSMs in China Regions are instead approved for use by the Chinese government.

Custom key stores combine the convenient and comprehensive key management interface of AWS KMS with the ability to own and control the device(s) where key material and cryptographic operations occur. As a result, you assume more responsibility for the availability and durability of cryptographic keys and for the operation of the HSMs. AWS KMS offers two types of custom key stores:

CloudHSM backed key store

You can create a KMS key in an AWS CloudHSM custom key store, where all keys are generated and stored in an AWS CloudHSM cluster that you own and manage. When you use a KMS key in a custom key store, the cryptographic operations under that key are performed solely in your AWS CloudHSM cluster.

The use of a custom key store involves the additional cost of the AWS CloudHSM cluster and you become responsible for the availability of the key material in that cluster. For guidance on whether custom key stores are a good fit for your requirements you can read this blog.

External key store

If you have a regulatory need to store and use your encryption keys on premises or outside of the AWS Cloud, you can create a KMS key in an AWS KMS external key store (XKS), where all keys are generated and stored in an external key manager outside of AWS that you own and manage. When using an XKS, your key material never leaves your HSM.

Unlike standard KMS keys or a key in a CloudHSM custom key store, you are responsible for the durability, availability, latency, performance, and security of the key material and the cryptographic operations of external keys when using an external key store. The performance and availability of KMS operations can be affected by the hardware, software, or networking components of the XKS infrastructure you use. To learn more about XKS, you can read this AWS News blog.

*Custom key stores are not available in the AWS China (Beijing) Region operated by Sinnet, and the AWS China (Ningxia) Region operated by NWCD.
**Custom key stores are not available for asymmetric KMS keys.
*** CodeArtifact does not support KMS keys in an XKS.

You can use AWS KMS with client-side encryption libraries to protect data directly within your application on AWS, or in hybrid and multicloud environments. You can use these libraries to encrypt data before storing in AWS services, or any other storage medium and third-party services that you desire. These libraries are designed to help you encrypt and decrypt data using industry standards and best practices. The encryption libraries enable you to focus on the core functionality of your application rather than on how to encrypt and decrypt your data.

• The AWS Encryption SDK is a general-purpose encryption library for implementing encryption and decryption operations on all types of data.
• The AWS Database Encryption SDK is an encryption library that helps you protect sensitive data stored in your database and provides additional features around searching and querying on encrypted data.
• The Amazon S3 Encryption Client is an encryption library for encrypting and decrypting objects stored in your S3 bucket.

To learn more, please visit AWS Crypto Tools Documentation.