What Is AWS KMS?
Utilize AWS KMS to create and validate message authentication codes (MACs), digitally sign data, encrypt data inside your apps using AWS Encryption SDK, and encrypt data across your AWS workloads.
You have control over the cryptographic keys that are used to safeguard your data with AWS Key Management Service (KMS). You have centralized control over the permissions and lifecycle of your keys with AWS KMS. You have complete control over who can manage keys and who can use them, and you may create new keys at any time. Because of its integration with other AWS services, it is simpler to encrypt data stored in these services and manage who has access to the decryption keys.
You can audit who used which keys, on which resources, and when with the help of AWS CloudTrail, which is connected with AWS KMS. Using the AWS SDK or directly, AWS KMS makes it easier for developers to incorporate digital signature or encryption features into their application code. In order to help developers that need to encrypt and decode data locally within their applications, the AWS Encryption SDK supports AWS KMS.
Key Features
Audit monitoring
Every request you make to AWS KMS is documented in a log file if your AWS account has AWS CloudTrail enabled. The Amazon Simple Storage Service (Amazon S3) bucket that you designated when you configured AWS CloudTrail receives this log file. The user’s information, time, date, API action, and, if applicable, the key used are all included in the data that is recorded.
Scalability, durability, and high availability
One completely managed service is AWS KMS. The solution adapts to your demands automatically as your encryption usage increases. It enables you to utilize and manage tens of thousands of KMS keys in your account at any time. You can ask for higher limits if needed, although it specifies default limits for the quantity of keys and request rates.
It is not possible to export the KMS keys that you generate or that other AWS services generate for you. As a result, AWS KMS is accountable for their longevity. AWS KMS keeps several encrypted copies of your keys in systems built for 99.999999999% durability to assist ensure that both your keys and your data are highly accessible.
DynamoDB Global Tables, multi-Region high availability architectures, disaster recovery, and globally distributed consistent digital signatures are examples of workflows that use KMS multi-Region keys for encrypted data or digital signatures that go between regions. Interoperable keys that can be copied into several regions using the same key material and key IDs are known as KMS multi-Region keys.
With a regional API endpoint, AWS KMS is intended to be a highly available service. AWS KMS is designed to offer a certain level of availability because the majority of AWS services depend on it for encryption and decryption. The AWS KMS Service Level Agreement supports this availability, which is compatible with the rest of AWS.
Secure
No one, not even AWS staff, can obtain your plaintext keys from the service with AWS KMS’s design. The service protects the confidentiality and integrity of your keys by using hardware security modules (HSMs) that are continuously validated under the Federal Information Processing Standards (FIPS) 140-2 Cryptographic Module Validation Program of the U.S. National Institute of Standards and Technology (NIST). The cryptographic foundation for safeguarding KMS keys is AWS KMS HSMs.
For every cryptographic process that takes place in KMS, they establish a safe, hardware-protected perimeter. All actions requiring decrypted KMS key material take place strictly within the FIPS 140-2 Security Level 3 border of these HSMs, as does all key material for KMS keys generated within AWS KMS HSMs. All firmware updates for AWS KMS HSMs are submitted to a NIST-accredited lab for validation in accordance with FIPS 140-2 Security Level 3, and updates are managed by a multi-party access control that is audited and examined by an impartial group within Amazon.
Your plaintext keys are only ever used in the HSMs’ volatile memory for the duration required to complete the cryptographic operation you have requested; they are never written to disk. This is true whether you import keys into the service, ask AWS KMS to generate keys for you, or use the custom key store option to generate keys in an AWS CloudHSM cluster. Whether you generate a single Region key or many Region keys is up to you. Single Region keys are only used within the AWS Region in which they were generated and are never sent outside of that region.
Asymmetric keys
Asymmetric KMS keys and data key pairs can be created and used with the aid of AWS KMS. A KMS key can be designated as a key agreement key pair, an encryption key pair, or a signing key pair. HSMs are used to generate key pairs and carry out asymmetric cryptographic operations with these KMS keys. While the private part of the asymmetric KMS key is always available, you can request the public part to be used in your local apps. An asymmetric key’s private part can be imported from your own key management system.
An asymmetric data key pair can also be requested from the service. The public key, private key, and a copy of the private key encrypted with a symmetric KMS key you specify are all returned in plaintext by this procedure. You can keep the encrypted copy of the private key for later use and utilize the plaintext public or private key in your local application.
HMAC
Hash-Based Message Authentication Codes (HMACs) can be generated and validated from within AWS KMS‘s FIPS 140-2 approved HSMs. HMACs are a type of cryptographic building block that generates a unique keyed message authentication code by combining secret key material into a hash function. Because the key material is generated and utilized only within AWS KMS, HMAC KMS keys offer an advantage over HMACs from application software. The access controls you establish on the key also apply to them.
RFC 20104 specifies industry standards that are followed by the HMAC KMS keys and HMAC algorithms used by AWS KMS. AWS KMS hardware security modules approved by the FIPS 140-2 Cryptographic Module Validation Program generate HMAC KMS keys, which ensure that AWS KMS is never left unencrypted. Additionally, you can import your own HMAC key from your own key management system.
Compliance
The following compliance regimes have verified and certified the security and quality controls in AWS KMS:
- AWS System and Organization Controls SOC 1, 2, and 3 reports. A copy of the reports is available for download from AWS Artifact.
- Catalog of Cloud Computing Compliance Controls (C5).
- Level 1 PCI Data Security Standard.
- FIPS 140-2 is Federal Information Processing Standards. NIST certified the AWS KMS cryptography module at FIPS 140-2 Security Level 3.
- FedRAMP is Federal Risk and Authorization Management Program.
- HIPAA protects healthcare insurance.
Custom key stores
The capacity to own and govern the device or devices where key material and cryptographic operations take place is combined with the practical and extensive key management interface of AWS KMS in custom key stores. As a result, you take on greater accountability for the HSMs’ functionality as well as the longevity and accessibility of cryptographic keys. Two varieties of custom key stores are available using AWS KMS:
CloudHSM backed key store
All keys are generated and stored in an AWS CloudHSM cluster that you own and manage, and you can create a KMS key in an AWS CloudHSM custom key store. The cryptographic operations under a KMS key are carried out only in your AWS CloudHSM cluster when you use it in a custom key store.
Using a bespoke key store entails paying more for the AWS CloudHSM cluster and puts you in charge of making sure the key material is available in that cluster.
External key store
You can generate a KMS key in an AWS KMS external key store (XKS), where all keys are generated and stored in an external key manager that you own and administer, if you have a regulatory requirement to store and use your encryption keys on-site or outside of the AWS Cloud. Your key material never leaves your HSM when you use an XKS.
When employing an external key store, you are in charge of the cryptographic operations of external keys as well as the durability, availability, latency, performance, and security of the key material, unlike with normal KMS keys or a key in a CloudHSM custom key store. The networking, software, and hardware components of the XKS infrastructure you utilize can have an impact on the availability and performance of KMS operations.
Client-side encryption
Data can be protected directly within your AWS application or in hybrid and multicloud environments by using AWS KMS with client-side encryption libraries. Before storing data in AWS services, or any other storage medium and third-party services you choose, you can use these libraries to encrypt the data. These libraries help you encrypt and decode data using best practices and industry standards. With encryption libraries, you may focus on your application’s core functionality instead of data encryption and decryption.
- The general-purpose AWS Encryption SDK may encrypt and decrypt any data.
- An encryption library called the AWS Database Encryption SDK helps you safeguard private information kept in your database and offers extra functionality for accessing and querying encrypted data.
- An encryption library called the Amazon S3 Encryption Client is used to encrypt and decrypt data kept in your S3 bucket.
