# AWS KMS keys
The KMS keys that you create and manage for use in your own cryptographic applications are of a type known as *customer managed keys*. Customer managed keys can also be used in conjunction with AWS services that use KMS keys to encrypt the data the service stores on your behalf. Customer managed keys are recommended for customers who want full control over the lifecycle and usage of their keys. There is a monthly cost to have a customer managed key in your account. In addition, requests use and/or manage the key incur a usage cost. See [AWS Key Management Service Pricing](https://aws.amazon.com/kms/pricing/) for more details.
There are cases where a customer might want an AWS service to encrypt their data, but they don’t want the overhead of managing keys and don’t want to pay for a key. An *AWS managed key* is a KMS key that exists in your account, but can only be used under certain circumstances. Specifically, it can only be used in the context of the AWS service you’re operating in and it can only be used by principals within the account that the key exists. You cannot manage anything about the lifecycle or permissions of these keys. As you use encryption features in AWS services, you may see AWS managed keys; they use an alias of the form “aws”. For example, an `aws/ebs` key can only be used to encrypt EBS volumes and only for volumes used by IAM principals in the same account as the key. Think of an AWS managed key that is scoped down for use only by users in your account for resources in your account. You cannot share resources encrypted under an AWS managed key with other accounts. While an AWS managed key is free to exist in your account, you are charged for any use of this key type by the AWS service that is assigned to the key.
AWS managed keys are a legacy key type that is no longer being created for new AWS services as of 2021. Instead, new (and legacy) AWS services are using what’s known as an *AWS owned key* to encrypt customer data by default. An AWS owned key is a KMS key that is in an account managed by the AWS service, so the service operators have the ability to manage its lifecycle and usage permissions. By using AWS owned keys, AWS services can transparently encrypt your data and allow for easy cross-account or cross-region sharing of data without you needing to worry about key permissions. Use AWS owned keys for encryption-by-default workloads that provide easier, more automated data protection. Because these keys are owned and managed by AWS, you are not charged for their existence or their usage, you cannot change their policies, you cannot audit activities on these keys, and you cannot delete them. Use customer managed keys when control is important, but use AWS owned keys when convenience is most important.
| | | | |
| --- |--- |--- |--- |
| | Customer managed keys | AWS managed keys | AWS owned keys |
| Key policy | Exclusively controlled by the customer | Controlled by service; viewable by customer | Exclusively controlled and only viewable by the AWS service that encrypts your data |
| Logging | CloudTrail customer trail or event data store | CloudTrail customer trail or event data store | Not viewable by the customer |
| Lifecycle management | Customer manages rotation, deletion and Regional location | AWS KMS manages rotation (annual), deletion, and Regional location | AWS service manages rotation, deletion, and Regional location |
| Pricing | Monthly fee for existence of keys (pro-rated hourly). Also charged for key usage | No monthly fee; but the caller is charged for API usage on these keys | No charges to customer |
The KMS keys that you create are [customer managed keys](#customer-mgn-key). AWS services that use KMS keys to encrypt your service resources often create keys for you. KMS keys that AWS services create in your AWS account are [AWS managed keys](#aws-managed-key). KMS keys that AWS services create in a service account are [AWS owned keys](#aws-owned-key).
| Type of KMS key | Can view KMS key metadata | Can manage KMS key | Created in my AWS account | [Automatic rotation](rotate-keys.md) | [Pricing](https://aws.amazon.com/kms/pricing/) |
| --- | --- | --- | --- | --- | --- |
| [Customer managed key](#customer-mgn-key) | Yes | Yes | Yes | Optional. | Monthly fee (pro-rated hourly)Per-use fee |
| [AWS managed key](#aws-managed-key) | Yes | No | Yes | Required. Every year (approximately 365 days). | No monthly feePer-use fee (some AWS services pay this fee for you) |
| [AWS owned key](#aws-owned-key) | No | No | No | The AWS service manages the rotation strategy | No fees |
[AWS services that integrate with AWS KMS](service-integration.md) differ in their support for KMS keys. Some AWS services encrypt your data by default with an AWS owned key or an AWS managed key. Some AWS services support customer managed keys. Other AWS services support all types of KMS keys to allow you the ease of an AWS owned key, the visibility of an AWS managed key, or the control of a customer managed key. For detailed information about the encryption options that an AWS service offers, see the *Encryption at Rest* topic in the user guide or the developer guide for the service.
## Customer managed keys
The KMS keys that you create are *customer managed keys*. Customer managed keys are KMS keys in your AWS account that you create, own, and manage. You have full control over these KMS keys, including establishing and maintaining their [key policies, IAM policies, and grants](control-access.md), [enabling and disabling](enabling-keys.md) them, [rotating their cryptographic material](rotate-keys.md), [adding tags](tagging-keys.md), [creating aliases](alias-create.md) that refer to the KMS keys, and [scheduling the KMS keys for deletion](deleting-keys.md).
Customer managed keys appear on the **Customer managed keys** page of the AWS Management Console for AWS KMS. To definitively identify a customer managed key, use the [DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html) operation. For customer managed keys, the value of the `KeyManager` field of the `DescribeKey` response is `CUSTOMER`.
You can use your customer managed key in cryptographic operations and audit usage in AWS CloudTrail logs. In addition, many [AWS services that integrate with AWS KMS](service-integration.md) let you specify a customer managed key to protect the data stored and managed for you.
Customer managed keys incur a monthly fee and a fee for use in excess of the free tier. They are counted against the AWS KMS [quotas](limits.md) for your account. For details, see [AWS Key Management Service Pricing](https://aws.amazon.com/kms/pricing/) and [Quotas](limits.md).
## AWS managed keys
*AWS managed keys* are KMS keys in your account that are created, managed, and used on your behalf by an [AWS service integrated with AWS KMS](https://aws.amazon.com/kms/features/#AWS_Service_Integration).
Some AWS services let you choose an AWS managed key or a customer managed key to protect your resources in that service. In general, unless you are required to control the encryption key that protects your resources, an AWS managed key is a good choice. You don't have to create or maintain the key or its key policy, and there's never a monthly fee for an AWS managed key.
You have permission to [view the AWS managed keys](viewing-keys.md) in your account, [view their key policies](key-policy-viewing.md), and [audit their use](logging-using-cloudtrail.md) in AWS CloudTrail logs. However, you cannot change any properties of AWS managed keys, rotate them, change their key policies, or schedule them for deletion. And, you cannot use AWS managed keys in cryptographic operations directly; the service that creates them uses them on your behalf.
[Resource control policies](resource-control-policies.md) in your organization do not apply to AWS managed keys.
AWS managed keys appear on the **AWS managed keys** page of the AWS Management Console for AWS KMS. You can also identify AWS managed keys by their aliases, which have the format `aws/service-name`, such as `aws/redshift`. To definitively identify an AWS managed keys, use the [DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html) operation. For AWS managed keys, the value of the `KeyManager` field of the `DescribeKey` response is `AWS`.
All AWS managed keys are automatically rotated every year. You cannot change this rotation schedule.
**Note**
In May 2022, AWS KMS changed the rotation schedule for AWS managed keys from every three years (approximately 1,095 days) to every year (approximately 365 days).
There is no monthly fee for AWS managed keys. They can be subject to fees for use in excess of the free tier, but some AWS services cover these costs for you. For details, see the *Encryption at Rest* topic in the user guide or developer guide for the service. For details, see [AWS Key Management Service Pricing](https://aws.amazon.com/kms/pricing/).
AWS managed keys do not count against resource quotas on the number of KMS keys in each Region of your account. But when used on behalf of a principal in your account, the KMS keys count against request quotas. For details, see [Quotas](limits.md).
## AWS owned keys
*AWS owned keys* are a collection of KMS keys that an AWS service owns and manages for use in multiple AWS accounts. Although AWS owned keys are not in your AWS account, an AWS service can use an AWS owned key to protect the resources in your account.
Some AWS services let you choose an AWS owned key or a customer managed key. In general, unless you are required to audit or control the encryption key that protects your resources, an AWS owned key is a good choice. AWS owned keys are completely free of charge (no monthly fees or usage fees), they do not count against the [AWS KMS quotas](limits.md) for your account, and they're easy to use. You don't need to create or maintain the key or its key policy.
The rotation of AWS owned keys varies across services. For information about the rotation of a particular AWS owned key, see the *Encryption at Rest* topic in the user guide or developer guide for the service.
## AWS KMS key hierarchy
Your key hierarchy starts with a top-level logical key, an AWS KMS key. A KMS key represents a container for top-level key material and is uniquely defined within the AWS service namespace with an Amazon Resource Name (ARN). The ARN includes a uniquely generated key identifier, a *key ID.* A KMS key is created based on a user-initiated request through AWS KMS. Upon reception, AWS KMS requests the creation of an initial HSM backing key (HBK) to be placed into the KMS key container. The HBK is generated on an HSM in the domain and is designed never to be exported from the HSM in plaintext. Instead, the HBK is exported encrypted under HSM-managed domain keys. These exported HBKs are referred to as exported key tokens (EKTs).
The EKT is exported to a highly durable, low-latency storage. For example, suppose you receive an ARN to the logical KMS key. This represents the top of a key hierarchy, or cryptographic context, for you. You can create multiple KMS keys within your account and set policies on your KMS keys like any other AWS named resource.
Within the hierarchy of a specific KMS key, the HBK can be thought of as a version of the KMS key. When you want to rotate the KMS key through AWS KMS, a new HBK is created and associated with the KMS key as the active HBK for the KMS key. The older HBKs are preserved and can be used to decrypt and verify previously protected data. But only the active cryptographic key can be used to protect new information.
![\[AWS KMS key hierarchy.\]](http://docs.aws.amazon.com/kms/latest/developerguide/images/CMK-Hierarchy.png)
You can make requests through AWS KMS to use your KMS keys to directly protect information or request additional HSM-generated keys that are protected under your KMS key. These keys are called customer data keys, or CDKs. CDKs can be returned encrypted as ciphertext (CT), in plaintext, or both. All objects encrypted under a KMS key (either customer-supplied data or HSM-generated keys) can be decrypted only on an HSM via a call through AWS KMS.
The returned ciphertext, or the decrypted payload, is never stored within AWS KMS. The information is returned to you over your TLS connection to AWS KMS. This also applies to calls made by AWS services on your behalf.
The key hierarchy and the specific key properties appear in the following table.
| Key | Description | Lifecycle |
| --- | --- | --- |
| **Domain key** | A 256-bit AES-GCM key only in memory of an HSM used to wrap versions of the KMS keys, the HSM backing keys. | Rotated daily1 |
| **HSM backing key** | A 256-bit symmetric key or RSA or elliptic curve private key, used to protect customer data and keys and stored encrypted under domain keys. One or more HSM backing keys comprise the KMS key, represented by the keyId. | Rotated yearly2 (optional config.) |
| **Derived encryption key** | A 256-bit AES-GCM key only in memory of an HSM used to encrypt customer data and keys. Derived from an HBK for each encryption. | Used once per encrypt and regenerated on decrypt |
| **Customer data key** | User-defined symmetric or asymmetric key exported from HSM in plaintext and ciphertext. Encrypted under an HSM backing key and returned to authorized users over TLS channel. | Rotation and use controlled by application |
1 AWS KMS might from time to time relax domain key rotation to at most weekly to account for domain administration and configuration tasks.
2 Default AWS managed keys created and managed by AWS KMS on your behalf are automatically rotated annually.
## Key identifiers (KeyId)
Key identifiers act like names for your KMS keys. They help you to recognize your KMS keys in the console. You use them to indicate which KMS keys you want to use in AWS KMS API operations, key policies, IAM policies, and grants. The key identifier values are completely unrelated to the key material associated with the KMS key.
AWS KMS defines several key identifiers. When you create a KMS key, AWS KMS generates a key ARN and key ID, which are properties of the KMS key. When you create an [alias](kms-alias.md), AWS KMS generates an alias ARN based on the alias name that you define. You can view the key and alias identifiers in the AWS Management Console and in the AWS KMS API.
In the AWS KMS console, you can view and filter KMS keys by their key ARN, key ID, or alias name, and sort by key ID and alias name. For help finding the key identifiers in the console, see [Find the key ID and key ARN](find-cmk-id-arn.md).
In the AWS KMS API, the parameters you use to identify a KMS key are named `KeyId` or a variation, such as `TargetKeyId` or `DestinationKeyId`. However, the values of those parameters are not limited to key IDs. Some can take any valid key identifier. For information about the values for each parameter, see the parameter description in the AWS Key Management Service API Reference.
**Note**
When using the AWS KMS API, be careful about the key identifier that you use. Different APIs require different key identifiers. In general, use the most complete and practical key identifier for your task.
AWS KMS supports the following key identifiers.
**Key ARN**
The key ARN is the Amazon Resource Name (ARN) of a KMS key. It is a unique, fully qualified identifier for the KMS key. A key ARN includes the AWS account, Region, and the key ID. For help finding the key ARN of a KMS key, see [Find the key ID and key ARN](find-cmk-id-arn.md).
The format of a key ARN is as follows:
```
arn::kms:::key/
```
The following is an example key ARN for a single-Region KMS key.
```
arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab
```
The *key-id* element of the key ARNs of [multi-Region keys](multi-region-keys-overview.md) begin with the `mrk-` prefix. The following is an example key ARN for a multi-Region key.
```
arn:aws:kms:us-west-2:111122223333:key/mrk-1234abcd12ab34cd56ef1234567890ab
```
**Key ID**
The key ID uniquely identifies a KMS key within an account and Region. For help finding the key ID of a KMS key, see [Find the key ID and key ARN](find-cmk-id-arn.md).
The following is an example key ID for a single-Region KMS key.
```
1234abcd-12ab-34cd-56ef-1234567890ab
```
The key IDs of [multi-Region keys](multi-region-keys-overview.md) begin with the `mrk-` prefix. The following is an example key ID for a multi-Region key.
```
mrk-1234abcd12ab34cd56ef1234567890ab
```
**Alias ARN**
The alias ARN is the Amazon Resource Name (ARN) of an AWS KMS alias. It is a unique, fully qualified identifier for the alias, and for the KMS key it represents. An alias ARN includes the AWS account, Region, and the alias name.
At any given time, an alias ARN identifies one particular KMS key. However, because you can change the KMS key associated with the alias, the alias ARN can identify different KMS keys at different times. For help finding the alias ARN of a KMS key, see [Find the alias name and alias ARN for a KMS key](alias-view.md).
The format of an alias ARN is as follows:
```
arn::kms:::alias/
```
The following is the alias ARN for a fictitious `ExampleAlias`.
```
arn:aws:kms:us-west-2:111122223333:alias/ExampleAlias
```
**Alias name**
The alias name is a string of up to 256 characters. It uniquely identifies an associated KMS key within an account and Region. In the AWS KMS API, alias names always begin with `alias/`. For help finding the alias name of a KMS key, see [Find the alias name and alias ARN for a KMS key](alias-view.md).
The format of an alias name is as follows:
```
alias/
```
For example:
```
alias/ExampleAlias
```
The `aws/` prefix for an alias name is reserved for [AWS managed keys](#aws-managed-key). You cannot create an alias with this prefix. For example, the alias name of the AWS managed key for Amazon Simple Storage Service (Amazon S3) is the following.
```
alias/aws/s3
```
# Asymmetric keys in AWS KMS
An *asymmetric KMS key* represents a mathematically related public key and private key pair. You can give the public key to anyone, even if they're not trusted, but the private key must be kept secret.
In an asymmetric KMS key, the private key is created in AWS KMS and never leaves AWS KMS unencrypted. To use the private key, you must call AWS KMS. You can use the public key within AWS KMS by calling the AWS KMS API operations. Or, you can [download the public key](download-public-key.md) and use it outside of AWS KMS.
If your use case requires encryption outside of AWS by users who cannot call AWS KMS, asymmetric KMS keys are a good choice. However, if you are creating a KMS key to encrypt the data that you store or manage in an AWS service, use a symmetric encryption KMS key. [AWS services that are integrated with AWS KMS](https://aws.amazon.com/kms/features/#AWS_Service_Integration) use only symmetric encryption KMS keys to encrypt your data. These services do not support encryption with asymmetric KMS keys.
When signing messages larger than 4 KB with AWS KMS, you must hash the message outside of AWS KMS before signing. AWS KMS provides three `MessageType` options for handling message input: `RAW` for plaintext messages (where AWS KMS performs the hashing), `DIGEST` for pre-hashed messages (where AWS KMS skips the hashing step), and `EXTERNAL_MU` specifically for ML-DSA KMS key specs where the input is a 64-byte representative μ value. For large messages exceeding the 4 KB limit, hash the message externally and use [https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html#KMS-Sign-request-MessageType](https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html#KMS-Sign-request-MessageType) (or [https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html#KMS-Sign-request-MessageType](https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html#KMS-Sign-request-MessageType) for ML-DSA KMS keys) when calling AWS KMS [Sign](https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html) and AWS KMS [Verify](https://docs.aws.amazon.com/kms/latest/APIReference/API_Verify.html) operations.
AWS KMS supports several types of asymmetric KMS keys.
**RSA KMS keys**
A KMS key with an RSA key pair for encryption and decryption or signing and verification (but not both). AWS KMS supports several key lengths for different security requirements.
For technical details about the encryption and signing algorithms that AWS KMS supports for RSA KMS keys, see [RSA key specs](symm-asymm-choose-key-spec.md#key-spec-rsa).
**Elliptic Curve (ECC) KMS keys**
A KMS key with an elliptic curve key pair for signing and verification or deriving shared secrets (but not both). AWS KMS supports several commonly-used curves.
For technical details about the signing algorithms that AWS KMS supports for ECC KMS keys, see [Elliptic curve key specs](symm-asymm-choose-key-spec.md#key-spec-ecc).
**ML-DSA KMS keys**
A KMS key with an ML-DSA key pair for signing and verification. ML-DSA is a post-quantum cryptography standard developed by the US National Institute of Standards and Technology (NIST) to protect against the security threats posed by quantum computing. ML-DSA is the recommended digital signature algorithm for organizations transitioning from RSA or Elliptic Curve digital signature algorithms to post-quantum safe cryptography.
AWS KMS supports several key lengths for different security requirements. For technical details about the signing algorithms that AWS KMS supports for ML-DSA KMS keys, see [ML-DSA key spec](symm-asymm-choose-key-spec.md#key-spec-mldsa).
**SM2 KMS keys (China Regions only)**
A KMS key with an SM2 key pair for encryption and decryption, signing and verification, or deriving shared secrets (you must choose one [Key usage](create-keys.md#key-usage) type).
For technical details about the encryption and signing algorithms that AWS KMS supports for SM2 KMS keys (China Regions only), see [SM2 key spec](symm-asymm-choose-key-spec.md#key-spec-sm).
For help choosing your asymmetric key configuration, see [Choosing what type of KMS key to create](create-keys.md#symm-asymm-choose).
**Regions**
Asymmetric KMS keys and asymmetric data key pairs are supported in all AWS Regions that AWS KMS supports.
**Learn more**
+ To create asymmetric KMS keys, see [Create an asymmetric KMS key](asymm-create-key.md).
+ To create multi-Region asymmetric KMS keys, see [Create multi-Region primary keys](create-primary-keys.md).
+ To learn how to sign messages and verify signatures with asymmetric KMS keys, see [Digital signing with the new asymmetric keys feature of AWS KMS](https://aws.amazon.com/blogs/security/digital-signing-asymmetric-keys-aws-kms/) in the *AWS Security Blog*.
+ To learn about special considerations for deleting asymmetric KMS keys, see [Deleting asymmetric KMS keys](deleting-keys.md#deleting-asymmetric-cmks).
+ To identify and view asymmetric KMS keys, see [Identify asymmetric KMS keys](identify-key-types.md#identify-asymm-keys).
# HMAC keys in AWS KMS
Hash-Based Message Authentication Code (HMAC) KMS keys are symmetric keys that you use to generate and verify HMACs within AWS KMS. The unique key material associated with each HMAC KMS key provides the secret key that HMAC algorithms require. You can use an HMAC KMS key with the `[GenerateMac](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateMac.html)` and [https://docs.aws.amazon.com/kms/latest/APIReference/API_VerifyMac.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_VerifyMac.html) operations to verify the integrity and authenticity of data within AWS KMS.
HMAC algorithms combine a cryptographic hash function and a shared secret key. They take a message and a secret key, such as the key material in an HMAC KMS key, and return a unique, fixed-size code or *tag*. If even one character of the message changes, or if the secret key is not identical, the resulting tag is entirely different. By requiring a secret key, HMAC also provides authenticity; it is impossible to generate an identical HMAC tag without the secret key. HMACs are sometimes called *symmetric signatures*, because they work like digital signatures, but use a single key for both signing and verification.
HMAC KMS keys and the HMAC algorithms that AWS KMS uses conform to industry standards defined in [RFC 2104](https://datatracker.ietf.org/doc/html/rfc2104). The AWS KMS [GenerateMac](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateMac.html) operation generates standard HMAC tags. HMAC KMS keys are generated in AWS KMS hardware security modules that are certified under the [FIPS 140-3 Cryptographic Module Validation Program](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4884) (except in China (Beijing) and China (Ningxia) Regions) and never leave AWS KMS unencrypted. To use an HMAC KMS key, you must call AWS KMS.
You can use HMAC KMS keys to determine the authenticity of a message, such as a JSON Web Token (JWT), tokenized credit card information, or a submitted password. They can also be used as secure Key Derivation Functions (KDFs), especially in applications that require deterministic keys.
HMAC KMS keys provide an advantage over HMACs from application software because the key material is generated and used entirely within AWS KMS, subject to the access controls that you set on the key.
**Tip**
Best practices recommend that you limit the time during which any signing mechanism, including an HMAC, is effective. This deters an attack where the actor uses a signed message to establish validity repeatedly or long after the message is superseded. HMAC tags do not include a timestamp, but you can include a timestamp in the token or message to help you detect when its time to refresh the HMAC.
**Supported cryptographic operations**
HMAC KMS keys support only the [https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateMac.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateMac.html) and [https://docs.aws.amazon.com/kms/latest/APIReference/API_VerifyMac.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_VerifyMac.html) cryptographic operations. You cannot use HMAC KMS keys to encrypt data or sign messages, or use any other type of KMS key in HMAC operations. When you use the `GenerateMac` operation, you supply a message of up to 4,096 bytes, an HMAC KMS key, and the MAC algorithm that is compatible with the HMAC key spec, and `GenerateMac` computes the HMAC tag. To verify an HMAC tag, you must supply the HMAC tag, and the same message, HMAC KMS key, and MAC algorithm that `GenerateMac` used to compute the original HMAC tag. The `VerifyMac` operation computes the HMAC tag and verifies that it is identical to the supplied HMAC tag. If the input and computed HMAC tags are not identical, verification fails.
HMAC KMS keys *do not* support [automatic key rotation](rotate-keys.md) and you cannot create an HMAC KMS key in a [custom key store](key-store-overview.md#custom-key-store-overview).
If you are creating a KMS key to encrypt data in an AWS service, use a symmetric encryption key. You cannot use an HMAC KMS key.
**Regions**
HMAC KMS keys are supported in all AWS Regions that AWS KMS supports.
**Learn more**
+ To create HMAC KMS keys, see [Create an HMAC KMS key](hmac-create-key.md).
+ To create multi-Region HMAC KMS keys, see [Multi-Region keys in AWS KMS](multi-region-keys-overview.md).
+ To examine the difference in the default key policy that the AWS KMS console sets for HMAC KMS keys, see [Allows key users to use a KMS key for cryptographic operations](key-policy-default.md#key-policy-users-crypto).
+ To identify and view HMAC KMS keys, see [Identify HMAC KMS keys](identify-key-types.md#hmac-view).
+ To learn about using HMACs to create JSON web tokens, see [How to protect HMACs inside AWS KMS](https://aws.amazon.com/blogs/security/how-to-protect-hmacs-inside-aws-kms/) in the *AWS Security Blog*.
+ Listen to a podcast: [Introducing HMACs for AWS Key Management Service](https://aws.amazon.com/podcasts/introducing-hmacs-apis-in-aws-key-management-service) on *The Official AWS Podcast*.
# ML-DSA keys in AWS KMS
AWS Key Management Service (AWS KMS) supports Module-Lattice Digital Signature Algorithm (ML-DSA) for post-quantum cryptographic signatures. This implementation follows the [Federal Information Processing Standards (FIPS) 204 standard](https://csrc.nist.gov/pubs/fips/204/final) to help protect against future quantum computing threats. AWS KMS creates and protects all ML-DSA keys and signature operations in FIPS 140-3 Security Level 3 validated hardware security modules. To help balance security with performance, ML-DSA in AWS KMS offers three distinct security levels through different key specifications, ML\$1DSA\$144, ML\$1DSA\$165, and ML\$1DSA\$187.
AWS KMS supports asymmetric key signatures for messages up to 4 KB using the `RAW` message type. For larger messages, you must externally compute the 64-byte message representation μ used in ML-DSA signing as defined in NIST FIPS 204 section 6.2. Use the `EXTERNAL_MU` message type in the AWS KMS [Sign](https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html) operation to specify this pre-processed 64-byte message. The signatures produced by the externally computed μ are the same as the `RAW` ones when using the same message and private key. Note that this signing is different from the "pre-hash" ML-DSA or HashML-DSA from section 5.4 of NIST FIPS 204.
For more information about using ML-DSA and the EXTERNAL\$1MU message type, see [ML-DSA key specs](symm-asymm-choose-key-spec.md#key-spec-mldsa).
For an example of using ML-DSA and the EXTERNAL\$1MU message type, see [Offline verification with ML-DSA key pairs](offline-operations.md#mldsa-offline-verification).
# Multi-Region keys in AWS KMS
AWS KMS supports *multi-Region keys*, which are AWS KMS keys in different AWS Regions that can be used interchangeably – as though you had the same key in multiple Regions. Each set of *related* multi-Region keys has the same key material and [key ID](concepts.md#key-id-key-id), so you can encrypt data in one AWS Region and decrypt it in a different AWS Region without re-encrypting or making a cross-Region call to AWS KMS.
Like all KMS keys, multi-Region keys never leave AWS KMS unencrypted. You can create symmetric or asymmetric multi-Region keys for encryption or signing, create HMAC multi-Region keys for generating and verifying HMAC tags, and create multi-Region keys with [imported key material](importing-keys.md) or key material that AWS KMS generates. You must manage each multi-Region key independently, including creating aliases and tags, setting their key policies and grants, and enabling and disabling them selectively. You can use multi-Region keys in all cryptographic operations that you can do with single-Region keys.
Multi-Region keys are a flexible and powerful solution for many common data security scenarios.
**Disaster recovery **
In a backup and recovery architecture, multi-Region keys let you process encrypted data without interruption even in the event of an AWS Region outage. Data maintained in backup Regions can be decrypted in the backup Region, and data newly encrypted in the backup Region can be decrypted in the primary Region when that Region is restored.
**Global data management**
Businesses that operate globally need globally distributed data that is available consistently across AWS Regions. You can create multi-Region keys in all Regions where your data resides, then use the keys as though they were a single-Region key without the latency of a cross-Region call or the cost of re-encrypting data under a different key in each Region.
**Distributed signing applications**
Applications that require cross-Region signature capabilities can use multi-Region asymmetric signing keys to generate identical digital signatures consistently and repeatedly in different AWS Regions.
If you use certificate chaining with a single global trust store (for a single root certificate authority (CA), and Regional intermediate CAs signed by the root CA, you don't need multi-Region keys. However, if your system doesn't support intermediate CAs, such as application signing, you can use multi-Region keys to bring consistency to Regional certifications.
**Active-active applications that span multiple Regions**
Some workloads and applications can span multiple Regions in active-active architectures. For these applications, multi-Region keys can reduce complexity by providing the same key material for concurrent encrypt and decrypt operations on data that might be moving across Region boundaries.
You can use multi-Region keys with client-side encryption libraries, such as the [AWS Encryption SDK](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/), the [AWS Database Encryption SDK](https://docs.aws.amazon.com/dynamodb-encryption-client/latest/devguide/), and [Amazon S3 client-side encryption](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingClientSideEncryption.html).
Most [AWS services that integrate with AWS KMS](https://aws.amazon.com/kms/features/) for encryption at rest or digital signatures currently treat multi-Region keys as though they were single-Region keys. For example, Amazon S3 cross-Region replication decrypts and re-encrypts the data keys used to encrypt object data under the KMS key in the destination Region, even when the KMS key in both Regions is a related multi-Region key. Refer to service-specific documentation to understand how a service replicates encrypted data and if it treats multi-Region keys differently.
Multi-Region keys are not global. You create a multi-Region primary key and then replicate it into Regions that you select within an [AWS partition](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html). Then you manage the multi-Region key in each Region independently. Neither AWS nor AWS KMS ever automatically creates or replicates multi-Region keys into any Region on your behalf. [AWS managed keys](concepts.md#aws-managed-key), the KMS keys that AWS services create in your account for you, are always single-Region keys.
In China Regions, you can use the multi-Region key feature to replicate KMS keys within the China Regions partition (`aws-cn`). For example, you can replicate a key from the China (Beijing) Region to the China (Ningxia) Region, or the reverse. By replicating a key from one China region to another, you agree to use the AWS Key Management Service of the destination region and comply with all applicable terms of agreement for the destination region. You cannot replicate a key from the Beijing and Ningxia Regions into an AWS Region outside of the China Regions partition. Similarly, you cannot replicate a key from a region outside of the China Regions partition into the Beijing and Ningxia Regions.
You cannot convert an existing single-Region key to a multi-Region key. This design ensures that all data protected with existing single-Region keys maintain the same data residency and data sovereignty properties.
For most data security needs, the Regional isolation and fault tolerance of Regional resources make standard AWS KMS single-Region keys a best-fit solution. However, when you need to encrypt or sign data in client-side applications across multiple Regions, multi-Region keys might be the solution.
**Regions**
Multi-Region keys are supported in all AWS Regions that AWS KMS supports.
**Pricing and quotas**
Every key in a set of related multi-Region keys counts as one KMS key for pricing and quotas. [AWS KMS quotas](limits.md) are calculated separately for each Region of an account. Use and management of the multi-Region keys in each Region count toward the quotas for that Region.
**Supported KMS key types**
You can create the following types of multi-Region KMS keys:
+ Symmetric encryption KMS keys
+ Asymmetric KMS keys
+ HMAC KMS keys
+ KMS keys with imported key material
You cannot create multi-Region keys in a custom key store.
**Learn more**
+ To learn how to control access to multi-Region KMS keys, see [Control access to multi-Region keys](multi-region-keys-auth.md).
+ To create multi-Region primary KMS keys of any type, see [Create multi-Region primary keys](create-primary-keys.md).
+ To create multi-Region replica KMS keys, see [Create multi-Region replica keys](multi-region-keys-replicate.md).
+ To update the primary Region, see [Change the primary key in a set of multi-Region keys](multi-region-update.md).
+ To identify and view multi-Region KMS keys, see [Identify HMAC KMS keys](identify-key-types.md#hmac-view).
+ To learn about special considerations for deleting multi-Region KMS keys, see [Deleting multi-Region keys](deleting-keys.md#deleting-mrks).
## Terminology and concepts
The following terms and concepts are used with multi-Region keys.
### Multi-Region key
A *multi-Region key* is one of a set of KMS keys with the same key ID and key material (and other [shared properties](#mrk-replica-key)) in different AWS Regions. Each multi-Region key is a fully functioning KMS key that can be used entirely independently of its related multi-Region keys. Because all *related* multi-Region keys have the same key ID and key material, they are *interoperable*, that is, any related multi-Region key in any AWS Region can decrypt ciphertext encrypted by any other related multi-Region key.
You set the multi-Region property of a KMS key when you create it. You cannot change the multi-Region property on an existing key. You cannot convert a single-Region key to multi-Region key or a convert a multi-Region key to a single-Region key. To move existing workloads into multi-Region scenarios, you must re-encrypt your data or create new signatures with new multi-Region keys.
A multi-Region key can be [symmetric or asymmetric](symmetric-asymmetric.md) and it can use AWS KMS key material or [imported key material](importing-keys.md). You cannot create multi-Region keys in a [custom key store](key-store-overview.md#custom-key-store-overview).
In a set of related multi-Region keys, there is exactly one [primary key](#mrk-primary-key) at any time. You can create [replica keys](#mrk-replica-key) of that primary key in other AWS Regions. You can also [update the primary region](multi-region-update.md#update-primary-console), which changes the primary key to a replica key and changes a specified replica key to the primary key. However, you can maintain only one primary key or replica key in each AWS Region. All of the Regions must be in the same [AWS partition](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
You can have multiple sets of related multi-Region keys in the same or different AWS Regions. Although related multi-Region keys are interoperable, unrelated multi-Region keys are not interoperable.
### Primary key
A multi-Region *primary key* is a KMS key that can be replicated into other AWS Regions in the same partition. Each set of multi-Region keys has just one primary key.
A primary key differs from a replica key in the following ways:
+ Only a primary key can be [replicated](multi-region-keys-replicate.md).
+ The primary key is the source for [shared properties](#mrk-replica-key) of its [replica keys](#mrk-replica-key), including the key material and key ID.
+ You can enable and disable [automatic key rotation](rotate-keys.md) only on a primary key.
+ You can [schedule the deletion of a primary key](deleting-keys.md#deleting-mrks) at any time. But AWS KMS will not delete a primary key until all of its replica keys are deleted.
However, primary and replica keys don't differ in any cryptographic properties. You can use a primary key and its replica keys interchangeably.
You are not required to replicate a primary key. You can use it just as you would any KMS key and replicate it if and when it is useful. However, because multi-Region keys have different security properties than single-Region keys, we recommend that you create a multi-Region key only when you plan to replicate it.
### Replica key
A multi-Region *replica key* is a KMS key that has the same [key ID](concepts.md#key-id-key-id) and key material as its [primary key](#mrk-primary-key) and related replica keys, but exists in a different AWS Region.
A replica key is a fully functional KMS key with it own key policy, grants, alias, tags, and other properties. It is not a copy of or pointer to the primary key or any other key. You can use a replica key even if its primary key and all related replica keys are disabled. You can also convert a replica key to a primary key and a primary key to a replica key. Once it is created, a replica key relies on its primary key only for [key rotation](rotate-keys.md#multi-region-rotate) and [updating the primary Region](multi-region-update.md).
Primary and replica keys don't differ in any cryptographic properties. You can use a primary key and its replica keys interchangeably. Data encrypted by a primary or replica key can be decrypted by the same key, or by any related primary or replica key.
### Replicate
You can *replicate* a multi-Region [primary key](#mrk-primary-key) into a different AWS Region in the same partition. When you do, AWS KMS creates a multi-Region [replica key](#mrk-replica-key) in the specified Region with the same [key ID](concepts.md#key-id-key-id) and other [shared properties](#mrk-sync-properties) as its primary key. For KMS keys with `AWS_KMS` origin, AWS KMS securely transports the key material across the Region boundary and associates it with the new replica key, all within AWS KMS. For KMS keys with `EXTERNAL` origin, you must import the same key material that you imported into the primary Region key into reach replica Region key individually.
### Shared properties
*Shared properties* are properties of a multi-Region primary key that are shared with its replica keys. AWS KMS creates the replica keys with the same shared property values as those of the primary key. Then, it periodically synchronizes the shared property values of the primary key to its replica keys. You cannot set these properties on a replica key.
The following are the shared properties of multi-Region keys.
+ [Key ID](concepts.md#key-id-key-id) — (The `Region` element of the [key ARN](concepts.md#key-id-key-ARN) differs.)
+ [Key material](create-keys.md#key-origin) — The primary and replica keys in a set of related multi-Region keys share the same key material. For multi-Region keys whose key material is generated by AWS KMS (`AWS_KMS` origin), AWS KMS securely transports all key materials from the primary to each replica when the replica is created or when new key material is created via automatic or on-demand rotation. For multi-Region keys with imported key material (`EXTERNAL` origin), AWS KMS synchronizes the key material identifier from the primary key but you must import key material into each replica key independently.
+ [Key material origin](create-keys.md#key-origin)
+ [Key spec](create-keys.md#key-spec) and encryption algorithms
+ [Key usage](create-keys.md#key-usage)
+ [Automatic key rotation](rotating-keys-enable.md) — You can enable and disable automatic key rotation only on the primary key. New replica keys are created with all versions of the shared key material. For details, see [Rotating multi-Region keys](rotate-keys.md#multi-region-rotate).
+ [On-demand rotation](rotating-keys-on-demand.md) — You can perform on-demand rotation only on the primary key. For multi-region keys whose key material is generated by AWS KMS (`AWS_KMS` origin), AWS KMS creates replica keys with all versions of the shared key material. For multi-region keys with imported key material (`EXTERNAL` origin), AWS KMS propagates the key material Id and key material description from the primary key to the replica keys, but not the key material. You must import the correct key material into each replica key individually. For details, see [Rotating multi-Region keys](rotate-keys.md#multi-region-rotate).
You can also think of the primary and replica designations of related multi-Region keys as shared properties. When you [create new replica keys](#mrk-replica-key) or [update the primary key](multi-region-update.md#update-primary-console), AWS KMS synchronizes the change to all related multi-Region keys. When these changes are complete, all related multi-Region keys list their primary key and replica keys accurately.
All other properties of multi-Region keys are *independent properties*, including the key description, [key policy](key-policies.md), [grants](grants.md), [enabled and disabled key states](enabling-keys.md), [aliases](kms-alias.md), and [tags](tagging-keys.md). You can set the same values for these properties on all related multi-Region keys, but if you change the value of an independent property, AWS KMS does not synchronize it.
You can track the synchronization of the shared properties of your multi-Region keys. In your AWS CloudTrail log, look for the [SynchronizeMultiRegionKey](ct-synchronize-multi-region-key.md) event.
# Security considerations for multi-Region keys
Use an AWS KMS multi-Region key only when you need one. Multi-Region keys provide a flexible and scalable solution for workloads that move encrypted data between AWS Regions or need cross-Region access. Consider a multi-Region key if you must share, move, or back up protected data across Regions or need to create identical digital signatures of applications operating in different Regions.
However, the process of creating a multi-Region key moves your key material across AWS Region boundaries within AWS KMS. The ciphertext generated by a multi-Region key can potentially be decrypted by multiple related keys in multiple geographic locations. There are also significant benefits to Regionally-isolated services and resources. Each AWS Region is isolated and independent of the other Regions. Regions provide fault tolerance, stability, and resilience, and can also reduce latency. They enable you to create redundant resources that remain available and unaffected by an outage in another Region. In AWS KMS, they also ensure that every ciphertext can be decrypted by only one key.
Multi-Region keys also raise new security considerations:
+ Controlling access and enforcing data security policy is more complex with multi-Region keys. You need to ensure that policy is audited consistently on key across multiple, isolated regions. And you need to use policy to enforce boundaries, instead of relying on separate keys.
For example, you need to set policy conditions on data to prevent payroll teams in one Region from being able to read payroll data for a different Region. Also, you must use access control to prevent a scenario where a multi-Region key in one Region protects one tenant's data and a related multi-Region key in another Region protects a different tenant's data.
+ Auditing keys across Regions is also more complex. With multi-Region keys, you need to examine and reconcile audit activities across multiple Regions to gain a complete understanding of key activities on protected data.
+ Compliance with data residency mandates can be more complex. With isolated Regions, you can ensure data residency and data sovereignty compliance. KMS keys in a given Region can decrypt sensitive data only in that Region. Data encrypted in one Region can remain completely protected and inaccessible in any other Region.
To verify data residency and data sovereignty with multi-Region keys, you need to implement access policies and compile AWS CloudTrail events across multiple Regions.
To make it easier for you to manage access control on multi-Region keys, the permission to replicate a multi-Region key ([kms:ReplicateKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_ReplicateKey.html)) is separate from the standard permission to create keys ([kms:CreateKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateKey.html)). Also, AWS KMS supports several policy conditions for multi-Region keys, including `kms:MultiRegion`, which allows or denies permission to create, use, or manage multi-Region keys and `kms:ReplicaRegion`, which restricts the Regions into which a multi-Region key can be replicated. For details, see [Control access to multi-Region keys](multi-region-keys-auth.md).
# How multi-Region keys work
You begin by creating a symmetric or asymmetric [multi-Region primary key](multi-region-keys-overview.md#mrk-primary-key) in an AWS Region that AWS KMS supports, such as US East (N. Virginia). You decide whether a key is single-Region or multi-Region only when you create it; you can't change this property later. As with any KMS key, you set a key policy for the multi-Region key, and you can create grants, and add aliases and tags for categorization and authorization. (These are [independent properties](multi-region-keys-overview.md#mrk-sync-properties) that aren't shared or synchronized with other keys.) You can use your multi-Region primary key in cryptographic operations for encryption or signing.
You can [create a multi-Region primary key](create-primary-keys.md) in the AWS KMS console or by using the [CreateKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateKey.html) API with the `MultiRegion` parameter set to `true`. Notice that multi-Region keys have a distinctive key ID that begins with `mrk-`. You can use the `mrk-` prefix to identify MRKs programmatically.
![\[Multi-Region primary key icon with red key symbol and sample key ID format.\]](http://docs.aws.amazon.com/kms/latest/developerguide/images/multi-region-primary-key.png)
If you choose, you can [replicate](multi-region-keys-overview.md#replicate) the multi-Region primary key into one or more different AWS Regions in the same [AWS partition](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html), such as Europe (Ireland). When you do, AWS KMS creates a [replica key](multi-region-keys-overview.md#mrk-replica-key) in the specified Region with the same key ID and other [shared properties](multi-region-keys-overview.md#mrk-sync-properties) as the primary key. The result is two *related* multi-Region keys — a primary key and a replica key — that can be used interchangeably.
You can [create a multi-Region replica key](multi-region-keys-replicate.md) in the AWS KMS console or by using the [ReplicateKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_ReplicateKey.html) API.
![\[Diagram showing multi-Region primary and replica keys in US East and EU regions with key IDs.\]](http://docs.aws.amazon.com/kms/latest/developerguide/images/multi-region-replica-key.png)
The resulting [multi-Region replica key](multi-region-keys-overview.md#mrk-replica-key) is a fully-functional KMS key with the same [shared properties](multi-region-keys-overview.md#mrk-sync-properties) as the primary key. In all other respects, it is an independent KMS key with its own description, key policy, grants, aliases, and tags. Enabling or disabling a multi-Region key has no effect on related multi-Region keys. You can use the primary and replica keys independently in cryptographic operations or coordinate their use. For example, you can encrypt data with the primary key in the US East (N. Virginia) Region, move the data to the Europe (Ireland) Region and use the replica key to decrypt the data.
Related multi-Region keys have the same key ID. Their key ARNs (Amazon Resource Names) differ only in the Region field. For example, the multi-Region primary key and replica keys might have the following example key ARNs. The key ID – the last element in the key ARN – is identical. Both keys have the distinctive key ID of multi-Region keys, which begins with **mrk-**.
```
Primary key: arn:aws:kms:us-east-1:111122223333:key/mrk-1234abcd12ab34cd56ef12345678990ab
Replica key: arn:aws:kms:eu-west-1:111122223333:key/mrk-1234abcd12ab34cd56ef12345678990ab
```
Having the same key ID is required for interoperability. When encrypting, AWS KMS binds the key ID of the KMS key to the ciphertext so the ciphertext can be decrypted only with that KMS key or a KMS key with the same key ID. This feature also makes related multi-Region keys easy to recognize, and it makes it easier to use them interchangeably. For example, when using them in an application, you can refer to related multi-Region keys by their shared key ID. Then, if necessary, specify the Region or ARN to distinguish them.
As your data needs change, you can replicate the primary key to other AWS Regions in the same partition, such as US West (Oregon) and Asia Pacific (Sydney). The result is four *related* multi-Region keys with the same key material and key IDs, as shown in the following diagram. You manage the keys independently. For multi-region keys with imported key material, you are responsible for importing key material into each related key individually. You can use them independently or in a coordinated fashion. For example, you can encrypt data with the replica key in Asia Pacific (Sydney), move the data to US West (Oregon), and decrypt it with the replica key in US West (Oregon).
![\[The primary and replica keys in a multi-Region key\]](http://docs.aws.amazon.com/kms/latest/developerguide/images/multi-region-keys.png)
Other considerations for multi-Region keys include the following.
*Synchronizing shared properties* — If a [shared property](multi-region-keys-overview.md#mrk-sync-properties) of the multi-Region keys changes, AWS KMS automatically synchronizes the change from the [primary key](multi-region-keys-overview.md#mrk-primary-key) to all of its [replica keys](multi-region-keys-overview.md#mrk-replica-key). You cannot request or force a synchronization of shared properties. AWS KMS detects and synchronizes all changes for you. However, you can audit synchronization by using the [SynchronizeMultiRegionKey](ct-synchronize-multi-region-key.md) event in CloudTrail logs.
For example, if you enable automatic key rotation on a symmetric multi-Region primary key with `AWS_KMS` origin, AWS KMS copies that setting to all of its replica keys. When the key material is rotated, the rotation is synchronized among all of the related multi-Region keys, so they continue to have the same current key material, and access to all older versions of the key material. If you create a new replica key, it has the same current key material of all related multi-Region keys and access to all previous versions of the key material. For details, see [Rotating multi-Region keys](rotate-keys.md#multi-region-rotate).
*Changing the primary key* — Every set of multi-Region keys must have exactly one primary key. The [primary key](multi-region-keys-overview.md#mrk-primary-key) is the only key that can be replicated. It's also the source of the shared properties of its replica keys. But you can change the primary key to a replica and promote one of the replica keys to primary. You might do this so you can delete a multi-Region primary key from a particular Region, or locate the primary key in a Region closer to project administrators. For details, see [Change the primary key in a set of multi-Region keys](multi-region-update.md).
*Deleting multi-Region keys* — Like all KMS keys, you must schedule the deletion of multi-Region keys before AWS KMS deletes them. While the key is pending deletion, you cannot use it in any cryptographic operations. However, AWS KMS will not delete a multi-Region primary key until all of its replica keys are deleted. For details, see [Deleting multi-Region keys](deleting-keys.md#deleting-mrks).
# Importing key material for AWS KMS keys
You can create an AWS KMS keys (KMS key) with key material that you supply.
A KMS key is a logical representation of a data key. The metadata for a KMS key includes the ID of the key material used to perform cryptographic operations. When you [create a KMS key](create-keys.md), by default, AWS KMS generates the key material for that KMS key. But you can create a KMS key without key material and then import your own key material into that KMS key, a feature often known as "bring your own key" (BYOK).
![\[Key icon that highlights the key material that it represents.\]](http://docs.aws.amazon.com/kms/latest/developerguide/images/import-key.png)
**Note**
AWS KMS does not support decrypting any AWS KMS ciphertext encrypted by a symmetric encryption KMS key outside of AWS KMS, even if the ciphertext was encrypted under a KMS key with imported key material. AWS KMS does not publish the ciphertext format this task requires, and the format might change without notice.
When you use imported key material, you remain responsible for the key material while allowing AWS KMS to use a copy of it. You might choose to do this for one or more of the following reasons:
+ To prove the key material was generated using a source of entropy that meets your requirements.
+ To use key material from your own infrastructure with AWS services, and to use AWS KMS to manage the lifecycle of that key material within AWS.
+ To use existing, well-established keys in AWS KMS, such as keys for code signing, PKI certificate signing, and certificate pinned applications
+ To set an expiration time for the key material in AWS and to [manually delete it](importing-keys-delete-key-material.md), but to also make it available again in the future. In contrast, [scheduling key deletion](deleting-keys.md#deleting-keys-how-it-works) requires a waiting period of 7 to 30 days, after which you cannot recover the deleted KMS key.
+ To own the original copy of the key material, and to keep it outside of AWS for additional durability and disaster recovery during the complete lifecycle of the key material.
+ For asymmetric keys and HMAC keys, importing creates compatible and interoperable keys that operate within and outside of AWS.
**Supported KMS key types**
AWS KMS supports imported key material for the following types of KMS keys. You cannot import key material into KMS keys in [custom key stores](key-store-overview.md#custom-key-store-overview).
+ [Symmetric encryption KMS keys](symm-asymm-choose-key-spec.md#symmetric-cmks)
+ [Asymmetric KMS keys (except ML-DSA keys)](symmetric-asymmetric.md)
+ [HMAC KMS keys](hmac.md)
+ [Multi-Region keys](multi-region-keys-overview.md) of all supported types.
**Regions**
Imported key material is supported in all AWS Regions that AWS KMS supports.
In China Regions, the key material requirements for symmetric encryption KMS keys differ from other Regions. For details, see [Step 3: Encrypt the key material](importing-keys-encrypt-key-material.md).
**Learn more**
+ To create KMS keys with imported key material, see [Create a KMS key with imported key material](importing-keys-conceptual.md).
+ To create an alarm that notifies you when the imported key material in a KMS key is approaching its expiration time, see [Create a CloudWatch alarm for expiration of imported key material](imported-key-material-expiration-alarm.md).
+ To reimport key material into a KMS key, see [Reimport key material](importing-keys-import-key-material.md#reimport-key-material).
+ To import new key material into a KMS key for on-demand rotation, see [Import new key material](importing-keys-import-key-material.md#import-new-key-material) and [Perform on-demand key rotation](rotating-keys-on-demand.md).
+ To identify and view KMS keys with imported key material, see [Identify KMS keys with imported key material](identify-key-types.md#identify-imported-keys).
+ To learn about special considerations for deleting KMS keys with imported key material, see [Deleting KMS keys with imported key material](deleting-keys.md#import-delete-key).
# Special considerations for imported key material
Before you decide to import key material into AWS KMS, you should understand the following characteristics of imported key material.
**You generate the key material**
You are responsible for generating the key material using a source of randomness that meets your security requirements.
**You're responsible for availability and durability**
AWS KMS is designed to keep imported key material highly available. But AWS KMS does not maintain the durability of imported key material at the same level as key material that AWS KMS generates. For details, see [Protecting imported key material](import-keys-protect.md).
**You can delete the key material**
You can [delete imported key material](importing-keys-delete-key-material.md) from a KMS key, immediately rendering the KMS key unusable. Also, when you import key material into a KMS key, you can determine whether the key expires and [set its expiration time](importing-keys-import-key-material.md#importing-keys-expiration). When the expiration time arrives, AWS KMS [deletes the key material](importing-keys-delete-key-material.md). Without key material, the KMS key cannot be used in any cryptographic operation. To restore the key, you must reimport the same key material into the key.
**You cannot change the key material for asymmetric, and HMAC keys**
When you import key material into a KMS key, the KMS key is permanently associated with that key material. You can [reimport the same key material](importing-keys-import-key-material.md#reimport-key-material), but you cannot import different key material into that KMS key. Also, you cannot [enable automatic key rotation](rotate-keys.md) for a KMS key with imported key material. However, you can [manually rotate a KMS key](rotate-keys-manually.md) with imported key material.
**You can perform on-demand rotation on symmetric encryption keys**
Symmetric encryption keys with imported key material support on-demand rotation. You can [import multiple key materials ](importing-keys-import-key-material.md#import-new-key-material) into these keys and use [on-demand rotation](rotating-keys-on-demand.md) to update the current key material. The current key material is used for both encryption and decryption but other (non-current) key materials can only be used for decryption.
**You cannot change the key material origin**
KMS keys designed for imported key material have an [origin](create-keys.md#key-origin) value of `EXTERNAL` that cannot be changed. You cannot convert a KMS key for imported key material to use key material from any other source, including AWS KMS. Similarly, you cannot convert a KMS key with AWS KMS key material into one designed for imported key material.
**You cannot export key material**
You cannot export any key material that you imported. AWS KMS cannot return the imported key material to you in any form. You must maintain a copy of your imported key material outside of AWS, preferably in a key manager, such as a hardware security module (HSM), so you can reimport the key material if you delete it or it expires.
**You can create multi-Region keys with imported key material**
Multi-Region with imported key material have the features of KMS keys with imported key material, and can interoperate between AWS Regions. To create a multi-Region key with imported key material, you must import the same key material into the primary KMS key and into each replica key. For more details on importing key materials for multi-Region keys, see [Import new key material](importing-keys-import-key-material.md#import-new-key-material).
**Asymmetric keys and HMAC keys are portable and interoperable**
You can use your asymmetric key material and HMAC key material outside of AWS to interoperate with AWS KMS keys with the same imported key material.
Unlike the AWS KMS symmetric ciphertext, which is inextricably bound to the KMS key used in the algorithm, AWS KMS uses standard HMAC and asymmetric formats for encryption, signing, and MAC generation. As a result, the keys are portable and support traditional escrow key scenarios.
When your KMS key has imported key material, you can use the imported key material outside of AWS to perform the following operations.
+ HMAC keys — You can verify a HMAC tag that was generated by the HMAC KMS key with imported key material. You can also use the HMAC KMS key with the imported key material to verify an HMAC tag that was generated by the key material outside of AWS.
+ Asymmetric encryption keys — You can use your private asymmetric encryption key outside of AWS to decrypt a ciphertext encrypted by the KMS key with the corresponding public key. You can also use your asymmetric KMS key to decrypt an asymmetric ciphertext that was generated outside of AWS.
+ Asymmetric signing keys — You can use your asymmetric signing KMS key with imported key material to verify digital signatures generated by your private signing key outside of AWS. You can also use your asymmetric public signing key outside of AWS to verify signatures generated by your asymmetric KMS key.
+ Asymmetric key agreement keys — You can use your asymmetric key agreement KMS key with imported key material to derive shared secrets with a peer outside of AWS.
If you import the same key material into different KMS keys in the same AWS Region, those keys are also interoperable. To create interoperable KMS keys in different AWS Regions, create a multi-Region key with imported key material.
**RSA private keys**
+ AWS KMS requires imported RSA private keys to have prime factors that conform to the test described in [FIPS 186-5, Section A. 1.3](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf). Other software or devices may use different algorithms for validating these prime factors of RSA private keys. In rare instances, keys validated using other algorithms may not be accepted by AWS KMS.
**Symmetric encryption keys are not portable or interoperable**
The symmetric ciphertexts that AWS KMS produces are not portable or interoperable. AWS KMS does not publish the symmetric ciphertext format that portability requires, and the format might change without notice.
+ AWS KMS cannot decrypt symmetric ciphertexts that you encrypt outside of AWS, even if you use key material that you have imported.
+ AWS KMS does not support decrypting any AWS KMS symmetric ciphertext outside of AWS KMS, even if the ciphertext was encrypted under a KMS key with imported key material.
+ KMS keys with the same imported key material are not interoperable. The symmetric ciphertext that AWS KMS generates ciphertext that is specific to each KMS key. This ciphertext format guarantees that only the KMS key that encrypted data can decrypt it.
Also, you cannot use any AWS tools, such as the [AWS Encryption SDK](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/) or [Amazon S3 client-side encryption](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingClientSideEncryption.html), to decrypt AWS KMS symmetric ciphertexts.
As a result, you cannot use keys with imported key material to support key escrow arrangements where an authorized third party with conditional access to key material can decrypt certain ciphertexts outside of AWS KMS. To support key escrow, use the [AWS Encryption SDK](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/java-example-code.html#java-example-multiple-providers) to encrypt your message under a key that is independent of AWS KMS.
# Protecting imported key material
The key material that you import is protected in transit and at rest. Before importing the key material, you encrypt (or "wrap") the key material with the public key of an RSA key pair generated in AWS KMS hardware security modules (HSMs) validated under the [FIPS 140-3 Cryptographic Module Validation Program](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4884). You can encrypt the key material directly with the wrapping public key, or encrypt the key material with an AES symmetric key, and then encrypt the AES symmetric key with the RSA public key.
Upon receipt, AWS KMS decrypts the key material with the corresponding private key in a AWS KMS HSM and re-encrypts it under an AES symmetric key that exists only in the volatile memory of the HSM. Your key material never leaves the HSM in plain text. It is decrypted only while it is in use and only within AWS KMS HSMs.
Use of your KMS key with imported key material is determined solely by the [access control policies](control-access.md) that you set on the KMS key. In addition, you can use [aliases](kms-alias.md) and [tags](tagging-keys.md) to identify and [control access](abac.md) to the KMS key. You can [enable and disable](enabling-keys.md) the key, [view](viewing-keys.md), and [monitor](monitoring-overview.md) it using services like AWS CloudTrail.
However, you maintain the only failsafe copy of your key material. In return for this extra measure of control, you are responsible for durability and overall availability of the imported key material. AWS KMS is designed to keep imported key material highly available. But AWS KMS does not maintain the durability of imported key material at the same level as key material that AWS KMS generates.
This difference in durability is meaningful in the following cases:
+ When you [set an expiration time](importing-keys-import-key-material.md#importing-keys-expiration) for your imported key material, AWS KMS deletes the key material after it expires. AWS KMS does not delete the KMS key or its metadata. You can [create a Amazon CloudWatch alarm](imported-key-material-expiration-alarm.md) that notifies you when imported key material is approaching its expiration date.
You cannot delete key material that AWS KMS generates for a KMS key and you cannot set AWS KMS key material to expire.
+ When you [manually delete imported key material](importing-keys-delete-key-material.md), AWS KMS deletes the key material but does not delete the KMS key or its metadata. In contrast, [scheduling key deletion](deleting-keys.md#deleting-keys-how-it-works) requires a waiting period of 7 to 30 days, after which AWS KMS permanently deletes the KMS key, its metadata, and its key material.
+ In the unlikely event of certain region-wide failures that affect AWS KMS (such as a total loss of power), AWS KMS cannot automatically restore your imported key material. However, AWS KMS can restore the KMS key and its metadata.
You *must* retain a copy of the imported key material outside of AWS in a system that you control. We recommend that you store an exportable copy of the imported key material in a key management system, such as an HSM. As a best practice, you should store a reference to the KMS key ARN and the key material ID generated by AWS KMS alongside the exportable copy of the key material. If your imported key material is deleted or expires, its associated KMS key becomes unusable until you reimport the same key material. If your imported key material is permanently lost, any ciphertext encrypted under the KMS key is unrecoverable.
**Important**
Symmetric encryption keys can have multiple key materials associated with them. The entire KMS key becomes unusable as soon as you delete any one of those key materials or if any one of those key materials expires (unless the deleted or expiring key material is `PENDING_ROTATION` or `PENDING_MULTI_REGION_IMPORT_AND_ROTATION`). You must reimport any expired or deleted key materials associated with such a key before the key becomes usable for cryptographic operations.
# KMS keys in a CloudHSM key store
You can create, view, manage, use, and schedule deletion of the AWS KMS keys in an AWS CloudHSM key store. The procedures that you use are very similar to those you use for other KMS keys. The only difference is that you specify an AWS CloudHSM key store when you create the KMS key. Then, AWS KMS creates non-extractable key material for the KMS key in the AWS CloudHSM cluster that is associated with the AWS CloudHSM key store. When you use a KMS key in an AWS CloudHSM key store, the [cryptographic operations](#use-cmk-keystore) are performed in the HSMs in the cluster.
**Supported features**
In addition to the procedures discussed in this section, you can do the following with KMS keys in an AWS CloudHSM key store:
+ Use key policies, IAM policies, and grants to [authorize access](control-access.md) to the KMS keys.
+ [Enable and disable](enabling-keys.md) the KMS keys.
+ Assign [tags](tagging-keys.md) and create [aliases](kms-alias.md), and use attribute-based access control (ABAC) to authorize access to the KMS keys.
+ Use the KMS keys to perform the following cryptographic operations:
+ [Encrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Encrypt.html)
+ [Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html)
+ [GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html)
+ [GenerateDataKeyWithoutPlaintext](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKeyWithoutPlaintext.html)
+ [ReEncrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_ReEncrypt.html)
The operations that generate asymmetric data key pairs, [GenerateDataKeyPair](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKeyPair.html) and [GenerateDataKeyPairWithoutPlaintext](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKeyPairWithoutPlaintext.html), are *not* supported in custom key stores.
+ Use the KMS keys with [AWS services that integrate with AWS KMS](service-integration.md) and support customer managed keys.
+ Track use of your KMS keys in [AWS CloudTrail logs](logging-using-cloudtrail.md) and [Amazon CloudWatch monitoring tools](monitoring-overview.md).
**Unsupported features**
+ AWS CloudHSM key stores support only symmetric encryption KMS keys. You cannot create HMAC KMS keys, asymmetric KMS keys, or asymmetric data key pairs in an AWS CloudHSM key store.
+ You cannot [import key material](importing-keys.md) into a KMS key in an AWS CloudHSM key store. AWS KMS generates the key material for the KMS key in the AWS CloudHSM cluster.
+ You cannot enable or disable [automatic rotation](rotate-keys.md) of the key material for a KMS key in an AWS CloudHSM key store.
**Using KMS keys in an AWS CloudHSM key store**
When you use your KMS key in a request, identify the KMS key by its ID or alias; you do not need to specify the AWS CloudHSM key store or AWS CloudHSM cluster. The response includes the same fields that are returned for any symmetric encryption KMS key.
However, when you use a KMS key in an AWS CloudHSM key store, the cryptographic operation is performed entirely within the AWS CloudHSM cluster that is associated with the AWS CloudHSM key store. The operation uses the key material in the cluster that is associated with the KMS key that you chose.
To make this possible, the following conditions are required.
+ The [key state](key-state.md) of the KMS key must be `Enabled`. To find the key state, use the **Status** field in the [AWS KMS console](finding-keys.md#viewing-console-details) or the `KeyState` field in the [DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html) response.
+ The AWS CloudHSM key store must be connected to its AWS CloudHSM cluster. Its **Status** in the [AWS KMS console](view-keystore.md) or `ConnectionState` in the [DescribeCustomKeyStores](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeCustomKeyStores.html) response must be `CONNECTED`.
+ The AWS CloudHSM cluster that is associated with the custom key store must contain at least one active HSM. To find the number of active HSMs in the cluster, use the [AWS KMS console](view-keystore.md), the AWS CloudHSM console, or the [DescribeClusters](https://docs.aws.amazon.com/cloudhsm/latest/APIReference/API_DescribeClusters.html) operation.
+ The AWS CloudHSM cluster must contain the key material for the KMS key. If the key material was deleted from the cluster, or an HSM was created from a backup that did not include the key material, the cryptographic operation will fail.
If these conditions are not met, the cryptographic operation fails, and AWS KMS returns a `KMSInvalidStateException` exception. Typically, you just need to [reconnect the AWS CloudHSM key store](connect-keystore.md). For additional help, see [How to fix a failing KMS key](fix-keystore.md#fix-cmk-failed).
When using the KMS keys in an AWS CloudHSM key store, be aware that the KMS keys in each AWS CloudHSM key store share a [custom key store request quota](requests-per-second.md#rps-key-stores) for cryptographic operations. If you exceed the quota, AWS KMS returns a `ThrottlingException`. If the AWS CloudHSM cluster that is associated with the AWS CloudHSM key store is processing numerous commands, including those unrelated to the AWS CloudHSM key store, you might get a `ThrottlingException` at an even lower rate. If you get a `ThrottlingException` for any request, lower your request rate and try the commands again. For details about the custom key store request quota, see [Custom key store request quotas](requests-per-second.md#rps-key-stores).
**Learn more**
+ To learn more about AWS CloudHSM key stores, see [AWS CloudHSM key stores](keystore-cloudhsm.md).
+ To create KMS keys in an AWS CloudHSM key store, see [Create a KMS key in an AWS CloudHSM key store](create-cmk-keystore.md).
+ To identify and view KMS keys in an AWS CloudHSM key store, see [Identify KMS keys in AWS CloudHSM key stores](identify-key-types.md#identify-key-hsm-keystore).
+ To find KMS keys and key material in an AWS CloudHSM key store, see [Find KMS keys and key material in an AWS CloudHSM key store](find-key-material.md).
+ To learn about special considerations for deleting KMS keys in an AWS CloudHSM key store, see [Deleting KMS keys from an AWS CloudHSM key store](deleting-keys.md#delete-cmk-keystore).
# KMS keys in external key stores
To create, view, manage, use, and schedule deletion of the KMS keys in an external key store, you use procedures that are very similar to those you use for other KMS keys. However, when you create a KMS key in an external key store, you specify an [external key store](keystore-external.md#concept-external-key-store) and an [external key](keystore-external.md#concept-external-key). When you use a KMS key in an external key store, [encryption and decryption operations](keystore-external.md#xks-how-it-works) are performed by your external key manager using the specified external key.
AWS KMS cannot create, view, update, or delete any cryptographic keys in your external key manager. AWS KMS never directly accesses your external key manager or any external key. All requests for cryptographic operations are mediated by your [external key store proxy](keystore-external.md#concept-xks-proxy). To use a KMS key in an external key store, the external key store that hosts the KMS key must be [connected](xks-connect-disconnect.md) to its external key store proxy.
**Supported features**
In addition to the procedures discussed in this section, you can do the following with KMS keys in an external key store:
+ Use [key policies](key-policies.md), [IAM policies](iam-policies.md), and [grants](grants.md) to control access to the KMS keys.
+ [Enable and disable](enabling-keys.md) the KMS keys. These actions do not affect the external key in your external key manager.
+ Assign [tags](tagging-keys.md) and create [aliases](kms-alias.md), and use [attribute-based access control](abac.md) (ABAC) to authorize access to the KMS keys.
+ Use the KMS keys to perform the following cryptographic operations:
+ [Encrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Encrypt.html)
+ [Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html)
+ [GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html)
+ [GenerateDataKeyWithoutPlaintext](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKeyWithoutPlaintext.html)
+ [ReEncrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_ReEncrypt.html)
The operations that generate asymmetric data key pairs, [GenerateDataKeyPair](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKeyPair.html) and [GenerateDataKeyPairWithoutPlaintext](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKeyPairWithoutPlaintext.html), are *not* supported in custom key stores.
+ Use the KMS keys with [AWS services that integrate with AWS KMS](https://aws.amazon.com/kms/features/#AWS_Service_Integration) and support [customer managed keys](concepts.md#customer-mgn-key).
**Unsupported features**
+ External key stores support only [symmetric encryption KMS keys](symm-asymm-choose-key-spec.md#symmetric-cmks). You cannot create HMAC KMS keys or asymmetric KMS keys in an external key store.
+ [GenerateDataKeyPair](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKeyPair.html) and [GenerateDataKeyPairWithoutPlaintext](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKeyPairWithoutPlaintext.html) are not supported on KMS keys in an external key store.
+ You cannot use an [AWS::KMS::Key CloudFormation template](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-kms-key.html) to create an external key store or a KMS key in an external key store.
+ [Multi-Region keys](multi-region-keys-overview.md) are not supported in an external key store.
+ KMS keys with [imported key material](importing-keys.md) are not supported in an external key store.
+ [Automatic key rotation](rotate-keys.md) is not supported for KMS keys in an external key store.
**Using KMS keys in an external key store**
When you use your KMS key in a request, identify the KMS key by its [key ID, key ARN, alias, or alias ARN](concepts.md#key-id). You do not need to specify the external key store. The response includes the same fields that are returned for any symmetric encryption KMS key. However, when you use a KMS key in an external key store, encryption and decryption operations are performed by your external key manager using the external key that is associated with the KMS key.
To ensure that ciphertext encrypted by a KMS key in an external key store is at least as secure as any ciphertext encrypted by a standard KMS key, AWS KMS uses [double encryption](keystore-external.md#concept-double-encryption). Data is first encrypted in AWS KMS using AWS KMS key material. Then it is encrypted by your external key manager using the external key for the KMS key. To decrypt double-encrypted ciphertext, the ciphertext is first decrypted by your external key manager using the external key for the KMS key. Then it is decrypted in AWS KMS using the AWS KMS key material for the KMS key.
To make this possible, the following conditions are required.
+ The [key state](key-state.md) of the KMS key must be `Enabled`. To find the key state, see the **Status** field for customer managed keys the [AWS KMS console](finding-keys.md#viewing-console-details) or the `KeyState` field in the [DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html) response.
+ The external key store that hosts the KMS key must be connected to its [external key store proxy](keystore-external.md#concept-xks-proxy), that is, the [connection state](xks-connect-disconnect.md#xks-connection-state) of the external key store must be `CONNECTED`.
You can view the connection state on the **External key stores** page in the AWS KMS console or in the [DescribeCustomKeyStores](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeCustomKeyStores.html) response. The connection state of the external key store is also displayed on the detail page for the KMS key in the AWS KMS console. On the detail page, choose the **Cryptographic configuration** tab and see the **Connection state** field in the **Custom key store** section.
If the connection state is `DISCONNECTED`, you must first connect it. If the connection state is `FAILED`, you must resolve the problem, disconnect the external key store, and then connect it. For instructions, see [Connect and disconnect external key stores](xks-connect-disconnect.md).
+ The external key store proxy must be able to find the external key.
+ The external key must be enabled and it must perform encryption and decryption.
The status of the external key is independent of and not affected by changes in the [key state](key-state.md) of the KMS key, including enabling and disabling the KMS key. Similarly, disabling or deleting the external key doesn't change the key state of the KMS key, but cryptographic operations using the associated KMS key will fail.
If these conditions are not met, the cryptographic operation fails, and AWS KMS returns a `KMSInvalidStateException` exception. You might need to [reconnect the external key store](xks-connect-disconnect.md) or use your external key manager tools to reconfigure or repair your external key. For additional help, see [Troubleshooting external key stores](xks-troubleshooting.md).
When using the KMS keys in an external key store, be aware that the KMS keys in each external key store share a [custom key store request quota](requests-per-second.md#rps-key-stores) for cryptographic operations. If you exceed the quota, AWS KMS returns a `ThrottlingException`. For details about the custom key store request quota, see [Custom key store request quotas](requests-per-second.md#rps-key-stores).
**Learn more**
+ To learn more about external key stores, see [External key stores](keystore-external.md).
+ To learn more about key material in external key stores, see [External key](keystore-external.md#concept-external-key).
+ To create KMS keys in an external key store, see [Create a KMS key in external key stores](create-xks-keys.md).
+ To identify and view KMS keys in an external key store, see [Identify KMS keys in external key stores](identify-key-types.md#view-xks-key).
+ To learn about special considerations for deleting KMS keys in an external key store, see [Deleting KMS keys from an external key store](deleting-keys.md#delete-xks-key).