createKey method
Creates a unique customer managed KMS key in your Amazon Web Services account and Region. You can use a KMS key in cryptographic operations, such as encryption and signing. Some Amazon Web Services services let you use KMS keys that you create and manage to protect your service resources.
A KMS key is a logical representation of a cryptographic key. In addition to the key material used in cryptographic operations, a KMS key includes metadata, such as the key ID, key policy, creation date, description, and key state.
Use the parameters of CreateKey to specify the type of KMS
key, the source of its key material, its key policy, description, tags,
and other properties.
To create different types of KMS keys, use the following guidance:
- Symmetric encryption KMS key
-
By default,
CreateKeycreates a symmetric encryption KMS key with key material that KMS generates. This is the basic and most widely used type of KMS key, and provides the best performance.To create a symmetric encryption KMS key, you don't need to specify any parameters. The default value for
KeySpec,SYMMETRIC_DEFAULT, the default value forKeyUsage,ENCRYPT_DECRYPT, and the default value forOrigin,AWS_KMS, create a symmetric encryption KMS key with KMS key material.If you need a key for basic encryption and decryption or you are creating a KMS key to protect your resources in an Amazon Web Services service, create a symmetric encryption KMS key. The key material in a symmetric encryption key never leaves KMS unencrypted. You can use a symmetric encryption KMS key to encrypt and decrypt data up to 4,096 bytes, but they are typically used to generate data keys and data keys pairs. For details, see GenerateDataKey and GenerateDataKeyPair.
- Asymmetric KMS keys
-
To create an asymmetric KMS key, use the
KeySpecparameter to specify the type of key material in the KMS key. Then, use theKeyUsageparameter to determine whether the KMS key will be used to encrypt and decrypt or sign and verify. You can't change these properties after the KMS key is created.Asymmetric KMS keys contain an RSA key pair, Elliptic Curve (ECC) key pair, ML-DSA key pair or an SM2 key pair (China Regions only). The private key in an asymmetric KMS key never leaves KMS unencrypted. However, you can use the GetPublicKey operation to download the public key so it can be used outside of KMS. Each KMS key can have only one key usage. KMS keys with RSA key pairs can be used to encrypt and decrypt data or sign and verify messages (but not both). KMS keys with NIST-standard ECC key pairs can be used to sign and verify messages or derive shared secrets (but not both). KMS keys with
ECC_SECG_P256K1can be used only to sign and verify messages. KMS keys with ML-DSA key pairs can be used to sign and verify messages. KMS keys with SM2 key pairs (China Regions only) can be used to either encrypt and decrypt data, sign and verify messages, or derive shared secrets (you must choose one key usage type). For information about asymmetric KMS keys, see Asymmetric KMS keys in the Key Management Service Developer Guide. - HMAC KMS key
-
To create an HMAC KMS key, set the
KeySpecparameter to a key spec value for HMAC KMS keys. Then set theKeyUsageparameter toGENERATE_VERIFY_MAC. You must set the key usage even thoughGENERATE_VERIFY_MACis the only valid key usage value for HMAC KMS keys. You can't change these properties after the KMS key is created.HMAC KMS keys are symmetric keys that never leave KMS unencrypted. You can use HMAC keys to generate (GenerateMac) and verify (VerifyMac) HMAC codes for messages up to 4096 bytes.
- Multi-Region primary keys
-
To create a multi-Region primary key in the local Amazon Web
Services Region, use the
MultiRegionparameter with a value ofTrue. To create a multi-Region replica key, that is, a KMS key with the same key ID and key material as a primary key, but in a different Amazon Web Services Region, use the ReplicateKey operation. To change a replica key to a primary key, and its primary key to a replica key, use the UpdatePrimaryRegion operation.You can create multi-Region KMS keys for all supported KMS key types: symmetric encryption KMS keys, HMAC KMS keys, asymmetric encryption KMS keys, and asymmetric signing KMS keys. You can also create multi-Region keys with imported key material. However, you can't create multi-Region keys in a custom key store.
This operation supports multi-Region keys, an KMS feature that lets you create multiple interoperable KMS keys in different Amazon Web Services Regions. Because these KMS keys have the same key ID, key material, and other metadata, you can use them interchangeably to encrypt data in one Amazon Web Services Region and decrypt it in a different Amazon Web Services Region without re-encrypting the data or making a cross-Region call. For more information about multi-Region keys, see Multi-Region keys in KMS in the Key Management Service Developer Guide.
- Imported key material
-
To import your own key material into a KMS key, begin by creating a KMS
key with no key material. To do this, use the
Originparameter ofCreateKeywith a value ofEXTERNAL. Next, use GetParametersForImport operation to get a public key and import token. Use the wrapping public key to encrypt your key material. Then, use ImportKeyMaterial with your import token to import the key material. For step-by-step instructions, see Importing Key Material in the Key Management Service Developer Guide .You can import key material into KMS keys of all supported KMS key types: symmetric encryption KMS keys, HMAC KMS keys, asymmetric encryption KMS keys, and asymmetric signing KMS keys. You can also create multi-Region keys with imported key material. However, you can't import key material into a KMS key in a custom key store.
To create a multi-Region primary key with imported key material, use the
Originparameter ofCreateKeywith a value ofEXTERNALand theMultiRegionparameter with a value ofTrue. To create replicas of the multi-Region primary key, use the ReplicateKey operation. For instructions, see Importing key material step 1. For more information about multi-Region keys, see Multi-Region keys in KMS in the Key Management Service Developer Guide. - Custom key store
-
A custom
key store lets you protect your Amazon Web Services resources using
keys in a backing key store that you own and manage. When you request a
cryptographic operation with a KMS key in a custom key store, the
operation is performed in the backing key store using its cryptographic
keys.
KMS supports CloudHSM key stores backed by an CloudHSM cluster and external key stores backed by an external key manager outside of Amazon Web Services. When you create a KMS key in an CloudHSM key store, KMS generates an encryption key in the CloudHSM cluster and associates it with the KMS key. When you create a KMS key in an external key store, you specify an existing encryption key in the external key manager. Before you create a KMS key in a custom key store, the
ConnectionStateof the key store must beCONNECTED. To connect the custom key store, use the ConnectCustomKeyStore operation. To find theConnectionState, use the DescribeCustomKeyStores operation.To create a KMS key in a custom key store, use the
CustomKeyStoreId. Use the defaultKeySpecvalue,SYMMETRIC_DEFAULT, and the defaultKeyUsagevalue,ENCRYPT_DECRYPTto create a symmetric encryption key. No other key type is supported in a custom key store.To create a KMS key in an CloudHSM key store, use the
Originparameter with a value ofAWS_CLOUDHSM. The CloudHSM cluster that is associated with the custom key store must have at least two active HSMs in different Availability Zones in the Amazon Web Services Region.To create a KMS key in an external key store, use the
Originparameter with a value ofEXTERNAL_KEY_STOREand anXksKeyIdparameter that identifies an existing external key.
Required permissions: kms:CreateKey
(IAM policy). To use the Tags parameter, kms:TagResource
(IAM policy). For examples and information about related permissions, see
Allow
a user to create KMS keys in the Key Management Service Developer
Guide.
Related operations:
Eventual consistency: The KMS API follows an eventual consistency model. For more information, see KMS eventual consistency.May throw CloudHsmClusterInvalidConfigurationException.
May throw CustomKeyStoreInvalidStateException.
May throw CustomKeyStoreNotFoundException.
May throw DependencyTimeoutException.
May throw InvalidArnException.
May throw KMSInternalException.
May throw LimitExceededException.
May throw MalformedPolicyDocumentException.
May throw TagException.
May throw UnsupportedOperationException.
May throw XksKeyAlreadyInUseException.
May throw XksKeyInvalidConfigurationException.
May throw XksKeyNotFoundException.
Parameter bypassPolicyLockoutSafetyCheck :
Skips ("bypasses") the key policy lockout safety check. The default value
is false.
For more information, see Default key policy in the Key Management Service Developer Guide. Use this parameter only when you intend to prevent the principal that is making the request from making a subsequent PutKeyPolicy request on the KMS key.
Parameter customKeyStoreId :
Creates the KMS key in the specified custom
key store. The ConnectionState of the custom key store
must be CONNECTED. To find the CustomKeyStoreID and
ConnectionState use the DescribeCustomKeyStores operation.
This parameter is valid only for symmetric encryption KMS keys in a single Region. You cannot create any other type of KMS key in a custom key store.
When you create a KMS key in an CloudHSM key store, KMS generates a
non-exportable 256-bit symmetric key in its associated CloudHSM cluster
and associates it with the KMS key. When you create a KMS key in an
external key store, you must use the XksKeyId parameter to
specify an external key that serves as key material for the KMS key.
Parameter customerMasterKeySpec :
Instead, use the KeySpec parameter.
The KeySpec and CustomerMasterKeySpec parameters
work the same way. Only the names differ. We recommend that you use
KeySpec parameter in your code. However, to avoid breaking
changes, KMS supports both parameters.
Parameter description :
A description of the KMS key. Use a description that helps you decide
whether the KMS key is appropriate for a task. The default value is an
empty string (no description).
To set or change the description after the key is created, use
UpdateKeyDescription.
Parameter keySpec :
Specifies the type of KMS key to create. The default value,
SYMMETRIC_DEFAULT, creates a KMS key with a 256-bit AES-GCM
key that is used for encryption and decryption, except in China Regions,
where it creates a 128-bit symmetric key that uses SM4 encryption. For a
detailed description of all supported key specs, see Key
spec reference in the Key Management Service Developer
Guide .
The KeySpec determines whether the KMS key contains a
symmetric key or an asymmetric key pair. It also determines the algorithms
that the KMS key supports. You can't change the KeySpec after
the KMS key is created. To further restrict the algorithms that can be
used with the KMS key, use a condition key in its key policy or IAM
policy. For more information, see kms:EncryptionAlgorithm,
kms:MacAlgorithm,
kms:KeyAgreementAlgorithm,
or kms:SigningAlgorithm
in the Key Management Service Developer Guide .
KMS supports the following key specs for KMS keys:
-
Symmetric encryption key (default)
-
SYMMETRIC_DEFAULT
-
-
HMAC keys (symmetric)
-
HMAC_224 -
HMAC_256 -
HMAC_384 -
HMAC_512
-
-
Asymmetric RSA key pairs (encryption and decryption -or- signing and
verification)
-
RSA_2048 -
RSA_3072 -
RSA_4096
-
-
Asymmetric NIST-standard elliptic curve key pairs (signing and
verification -or- deriving shared secrets)
-
ECC_NIST_P256(secp256r1) -
ECC_NIST_P384(secp384r1) -
ECC_NIST_P521(secp521r1) -
ECC_NIST_EDWARDS25519(ed25519) - signing and verification only-
Note: For ECC_NIST_EDWARDS25519 KMS keys, the ED25519_SHA_512
signing algorithm requires
MessageType:RAW, while ED25519_PH_SHA_512 requiresMessageType:DIGEST. These message types cannot be used interchangeably.
-
Note: For ECC_NIST_EDWARDS25519 KMS keys, the ED25519_SHA_512
signing algorithm requires
-
-
Other asymmetric elliptic curve key pairs (signing and verification)
-
ECC_SECG_P256K1(secp256k1), commonly used for cryptocurrencies.
-
-
Asymmetric ML-DSA key pairs (signing and verification)
-
ML_DSA_44 -
ML_DSA_65 -
ML_DSA_87
-
-
SM2 key pairs (encryption and decryption -or- signing and verification
-or- deriving shared secrets)
-
SM2(China Regions only)
-
Parameter keyUsage :
Determines the cryptographic
operations for which you can use the KMS key. The default value is
ENCRYPT_DECRYPT. This parameter is optional when you are
creating a symmetric encryption KMS key; otherwise, it is required. You
can't change the
KeyUsage value after the KMS key is created. Each KMS
key can have only one key usage. This follows key usage best practices
according to NIST SP 800-57
Recommendations for Key Management, section 5.2, Key usage.
Select only one valid value.
-
For symmetric encryption KMS keys, omit the parameter or specify
ENCRYPT_DECRYPT. -
For HMAC KMS keys (symmetric), specify
GENERATE_VERIFY_MAC. -
For asymmetric KMS keys with RSA key pairs, specify
ENCRYPT_DECRYPTorSIGN_VERIFY. -
For asymmetric KMS keys with NIST-standard elliptic curve key pairs,
specify
SIGN_VERIFYorKEY_AGREEMENT. -
For asymmetric KMS keys with
ECC_SECG_P256K1key pairs, specifySIGN_VERIFY. -
For asymmetric KMS keys with ML-DSA key pairs, specify
SIGN_VERIFY. -
For asymmetric KMS keys with SM2 key pairs (China Regions only), specify
ENCRYPT_DECRYPT,SIGN_VERIFY, orKEY_AGREEMENT.
Parameter multiRegion :
Creates a multi-Region primary key that you can replicate into other
Amazon Web Services Regions. You cannot change this value after you create
the KMS key.
For a multi-Region key, set this parameter to True. For a
single-Region KMS key, omit this parameter or set it to
False. The default value is False.
This operation supports multi-Region keys, an KMS feature that lets you create multiple interoperable KMS keys in different Amazon Web Services Regions. Because these KMS keys have the same key ID, key material, and other metadata, you can use them interchangeably to encrypt data in one Amazon Web Services Region and decrypt it in a different Amazon Web Services Region without re-encrypting the data or making a cross-Region call. For more information about multi-Region keys, see Multi-Region keys in KMS in the Key Management Service Developer Guide.
This value creates a primary key, not a replica. To create a replica key, use the ReplicateKey operation.
You can create a symmetric or asymmetric multi-Region key, and you can create a multi-Region key with imported key material. However, you cannot create a multi-Region key in a custom key store.
Parameter origin :
The source of the key material for the KMS key. You cannot change the
origin after you create the KMS key. The default is AWS_KMS,
which means that KMS creates the key material.
To create
a KMS key with no key material (for imported key material), set this
value to EXTERNAL. For more information about importing key
material into KMS, see Importing
Key Material in the Key Management Service Developer Guide. The
EXTERNAL origin value is valid only for symmetric KMS keys.
To create
a KMS key in an CloudHSM key store and create its key material in the
associated CloudHSM cluster, set this value to AWS_CLOUDHSM.
You must also use the CustomKeyStoreId parameter to identify
the CloudHSM key store. The KeySpec value must be
SYMMETRIC_DEFAULT.
To create
a KMS key in an external key store, set this value to
EXTERNAL_KEY_STORE. You must also use the
CustomKeyStoreId parameter to identify the external key store
and the XksKeyId parameter to identify the associated
external key. The KeySpec value must be
SYMMETRIC_DEFAULT.
Parameter policy :
The key policy to attach to the KMS key.
If you provide a key policy, it must meet the following criteria:
-
The key policy must allow the calling principal to make a subsequent
PutKeyPolicyrequest on the KMS key. This reduces the risk that the KMS key becomes unmanageable. For more information, see Default key policy in the Key Management Service Developer Guide. (To omit this condition, setBypassPolicyLockoutSafetyCheckto true.) - Each statement in the key policy must contain one or more principals. The principals in the key policy must exist and be visible to KMS. When you create a new Amazon Web Services principal, you might need to enforce a delay before including the new principal in a key policy because the new principal might not be immediately visible to KMS. For more information, see Changes that I make are not always immediately visible in the Amazon Web Services Identity and Access Management User Guide.
Implementation
Future<CreateKeyResponse> createKey({
bool? bypassPolicyLockoutSafetyCheck,
String? customKeyStoreId,
CustomerMasterKeySpec? customerMasterKeySpec,
String? description,
KeySpec? keySpec,
KeyUsageType? keyUsage,
bool? multiRegion,
OriginType? origin,
String? policy,
List<Tag>? tags,
String? xksKeyId,
}) async {
final headers = <String, String>{
'Content-Type': 'application/x-amz-json-1.1',
'X-Amz-Target': 'TrentService.CreateKey'
};
final jsonResponse = await _protocol.send(
method: 'POST',
requestUri: '/',
exceptionFnMap: _exceptionFns,
// TODO queryParams
headers: headers,
payload: {
if (bypassPolicyLockoutSafetyCheck != null)
'BypassPolicyLockoutSafetyCheck': bypassPolicyLockoutSafetyCheck,
if (customKeyStoreId != null) 'CustomKeyStoreId': customKeyStoreId,
if (customerMasterKeySpec != null)
'CustomerMasterKeySpec': customerMasterKeySpec.value,
if (description != null) 'Description': description,
if (keySpec != null) 'KeySpec': keySpec.value,
if (keyUsage != null) 'KeyUsage': keyUsage.value,
if (multiRegion != null) 'MultiRegion': multiRegion,
if (origin != null) 'Origin': origin.value,
if (policy != null) 'Policy': policy,
if (tags != null) 'Tags': tags,
if (xksKeyId != null) 'XksKeyId': xksKeyId,
},
);
return CreateKeyResponse.fromJson(jsonResponse.body);
}