Class: Aws::KMS::Client
- Inherits:
-
Seahorse::Client::Base
- Object
- Seahorse::Client::Base
- Aws::KMS::Client
- Includes:
- ClientStubs
- Defined in:
- lib/aws-sdk-kms/client.rb
Overview
An API client for KMS. To construct a client, you need to configure a ‘:region` and `:credentials`.
client = Aws::KMS::Client.new(
region: region_name,
credentials: credentials,
# ...
)
For details on configuring region and credentials see the [developer guide](/sdk-for-ruby/v3/developer-guide/setup-config.html).
See #initialize for a full list of supported configuration options.
Class Attribute Summary collapse
- .identifier ⇒ Object readonly private
API Operations collapse
-
#cancel_key_deletion(params = {}) ⇒ Types::CancelKeyDeletionResponse
Cancels the deletion of a KMS key.
-
#connect_custom_key_store(params = {}) ⇒ Struct
Connects or reconnects a [custom key store] to its backing key store.
-
#create_alias(params = {}) ⇒ Struct
Creates a friendly name for a KMS key.
-
#create_custom_key_store(params = {}) ⇒ Types::CreateCustomKeyStoreResponse
Creates a [custom key store] backed by a key store that you own and manage.
-
#create_grant(params = {}) ⇒ Types::CreateGrantResponse
Adds a grant to a KMS key.
-
#create_key(params = {}) ⇒ Types::CreateKeyResponse
Creates a unique customer managed [KMS key] in your Amazon Web Services account and Region.
-
#decrypt(params = {}) ⇒ Types::DecryptResponse
Decrypts ciphertext that was encrypted by a KMS key using any of the following operations:.
-
#delete_alias(params = {}) ⇒ Struct
Deletes the specified alias.
-
#delete_custom_key_store(params = {}) ⇒ Struct
Deletes a [custom key store].
-
#delete_imported_key_material(params = {}) ⇒ Struct
Deletes key material that was previously imported.
-
#derive_shared_secret(params = {}) ⇒ Types::DeriveSharedSecretResponse
Derives a shared secret using a key agreement algorithm.
-
#describe_custom_key_stores(params = {}) ⇒ Types::DescribeCustomKeyStoresResponse
Gets information about [custom key stores] in the account and Region.
-
#describe_key(params = {}) ⇒ Types::DescribeKeyResponse
Provides detailed information about a KMS key.
-
#disable_key(params = {}) ⇒ Struct
Sets the state of a KMS key to disabled.
-
#disable_key_rotation(params = {}) ⇒ Struct
Disables [automatic rotation of the key material] of the specified symmetric encryption KMS key.
-
#disconnect_custom_key_store(params = {}) ⇒ Struct
Disconnects the [custom key store] from its backing key store.
-
#enable_key(params = {}) ⇒ Struct
Sets the key state of a KMS key to enabled.
-
#enable_key_rotation(params = {}) ⇒ Struct
Enables [automatic rotation of the key material] of the specified symmetric encryption KMS key.
-
#encrypt(params = {}) ⇒ Types::EncryptResponse
Encrypts plaintext of up to 4,096 bytes using a KMS key.
-
#generate_data_key(params = {}) ⇒ Types::GenerateDataKeyResponse
Returns a unique symmetric data key for use outside of KMS.
-
#generate_data_key_pair(params = {}) ⇒ Types::GenerateDataKeyPairResponse
Returns a unique asymmetric data key pair for use outside of KMS.
-
#generate_data_key_pair_without_plaintext(params = {}) ⇒ Types::GenerateDataKeyPairWithoutPlaintextResponse
Returns a unique asymmetric data key pair for use outside of KMS.
-
#generate_data_key_without_plaintext(params = {}) ⇒ Types::GenerateDataKeyWithoutPlaintextResponse
Returns a unique symmetric data key for use outside of KMS.
-
#generate_mac(params = {}) ⇒ Types::GenerateMacResponse
Generates a hash-based message authentication code (HMAC) for a message using an HMAC KMS key and a MAC algorithm that the key supports.
-
#generate_random(params = {}) ⇒ Types::GenerateRandomResponse
Returns a random byte string that is cryptographically secure.
-
#get_key_policy(params = {}) ⇒ Types::GetKeyPolicyResponse
Gets a key policy attached to the specified KMS key.
- #get_key_rotation_status(params = {}) ⇒ Types::GetKeyRotationStatusResponse
-
#get_parameters_for_import(params = {}) ⇒ Types::GetParametersForImportResponse
Returns the public key and an import token you need to import or reimport key material for a KMS key.
-
#get_public_key(params = {}) ⇒ Types::GetPublicKeyResponse
Returns the public key of an asymmetric KMS key.
-
#import_key_material(params = {}) ⇒ Struct
Imports or reimports key material into an existing KMS key that was created without key material.
-
#list_aliases(params = {}) ⇒ Types::ListAliasesResponse
Gets a list of aliases in the caller’s Amazon Web Services account and region.
-
#list_grants(params = {}) ⇒ Types::ListGrantsResponse
Gets a list of all grants for the specified KMS key.
-
#list_key_policies(params = {}) ⇒ Types::ListKeyPoliciesResponse
Gets the names of the key policies that are attached to a KMS key.
-
#list_key_rotations(params = {}) ⇒ Types::ListKeyRotationsResponse
Returns information about all completed key material rotations for the specified KMS key.
-
#list_keys(params = {}) ⇒ Types::ListKeysResponse
Gets a list of all KMS keys in the caller’s Amazon Web Services account and Region.
-
#list_resource_tags(params = {}) ⇒ Types::ListResourceTagsResponse
Returns all tags on the specified KMS key.
-
#list_retirable_grants(params = {}) ⇒ Types::ListGrantsResponse
Returns information about all grants in the Amazon Web Services account and Region that have the specified retiring principal.
-
#put_key_policy(params = {}) ⇒ Struct
Attaches a key policy to the specified KMS key.
-
#re_encrypt(params = {}) ⇒ Types::ReEncryptResponse
Decrypts ciphertext and then reencrypts it entirely within KMS.
-
#replicate_key(params = {}) ⇒ Types::ReplicateKeyResponse
Replicates a multi-Region key into the specified Region.
-
#retire_grant(params = {}) ⇒ Struct
Deletes a grant.
-
#revoke_grant(params = {}) ⇒ Struct
Deletes the specified grant.
-
#rotate_key_on_demand(params = {}) ⇒ Types::RotateKeyOnDemandResponse
Immediately initiates rotation of the key material of the specified symmetric encryption KMS key.
-
#schedule_key_deletion(params = {}) ⇒ Types::ScheduleKeyDeletionResponse
Schedules the deletion of a KMS key.
-
#sign(params = {}) ⇒ Types::SignResponse
Creates a [digital signature] for a message or message digest by using the private key in an asymmetric signing KMS key.
-
#tag_resource(params = {}) ⇒ Struct
Adds or edits tags on a [customer managed key].
-
#untag_resource(params = {}) ⇒ Struct
Deletes tags from a [customer managed key].
-
#update_alias(params = {}) ⇒ Struct
Associates an existing KMS alias with a different KMS key.
-
#update_custom_key_store(params = {}) ⇒ Struct
Changes the properties of a custom key store.
-
#update_key_description(params = {}) ⇒ Struct
Updates the description of a KMS key.
-
#update_primary_region(params = {}) ⇒ Struct
Changes the primary key of a multi-Region key.
-
#verify(params = {}) ⇒ Types::VerifyResponse
Verifies a digital signature that was generated by the Sign operation.
-
#verify_mac(params = {}) ⇒ Types::VerifyMacResponse
Verifies the hash-based message authentication code (HMAC) for a specified message, HMAC KMS key, and MAC algorithm.
Class Method Summary collapse
- .errors_module ⇒ Object private
Instance Method Summary collapse
- #build_request(operation_name, params = {}) ⇒ Object private
-
#initialize(options) ⇒ Client
constructor
A new instance of Client.
- #waiter_names ⇒ Object deprecated private Deprecated.
Constructor Details
#initialize(options) ⇒ Client
Returns a new instance of Client.
451 452 453 |
# File 'lib/aws-sdk-kms/client.rb', line 451 def initialize(*args) super end |
Class Attribute Details
.identifier ⇒ Object (readonly)
This method is part of a private API. You should avoid using this method if possible, as it may be removed or be changed in the future.
10789 10790 10791 |
# File 'lib/aws-sdk-kms/client.rb', line 10789 def identifier @identifier end |
Class Method Details
.errors_module ⇒ Object
This method is part of a private API. You should avoid using this method if possible, as it may be removed or be changed in the future.
10792 10793 10794 |
# File 'lib/aws-sdk-kms/client.rb', line 10792 def errors_module Errors end |
Instance Method Details
#build_request(operation_name, params = {}) ⇒ Object
This method is part of a private API. You should avoid using this method if possible, as it may be removed or be changed in the future.
10762 10763 10764 10765 10766 10767 10768 10769 10770 10771 10772 10773 10774 10775 10776 10777 10778 |
# File 'lib/aws-sdk-kms/client.rb', line 10762 def build_request(operation_name, params = {}) handlers = @handlers.for(operation_name) tracer = config.telemetry_provider.tracer_provider.tracer( Aws::Telemetry.module_to_tracer_name('Aws::KMS') ) context = Seahorse::Client::RequestContext.new( operation_name: operation_name, operation: config.api.operation(operation_name), client: self, params: params, config: config, tracer: tracer ) context[:gem_name] = 'aws-sdk-kms' context[:gem_version] = '1.96.0' Seahorse::Client::Request.new(handlers, context) end |
#cancel_key_deletion(params = {}) ⇒ Types::CancelKeyDeletionResponse
Cancels the deletion of a KMS key. When this operation succeeds, the key state of the KMS key is ‘Disabled`. To enable the KMS key, use EnableKey.
For more information about scheduling and canceling deletion of a KMS key, see [Deleting KMS keys] in the *Key Management Service Developer Guide*.
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: No. You cannot perform this operation on a KMS key in a different Amazon Web Services account.
**Required permissions**: [kms:CancelKeyDeletion] (key policy)
**Related operations**: ScheduleKeyDeletion
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html [2]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [3]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [4]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
533 534 535 536 |
# File 'lib/aws-sdk-kms/client.rb', line 533 def cancel_key_deletion(params = {}, = {}) req = build_request(:cancel_key_deletion, params) req.send_request() end |
#connect_custom_key_store(params = {}) ⇒ Struct
Connects or reconnects a [custom key store] to its backing key store. For an CloudHSM key store, ‘ConnectCustomKeyStore` connects the key store to its associated CloudHSM cluster. For an external key store, `ConnectCustomKeyStore` connects the key store to the external key store proxy that communicates with your external key manager.
The custom key store must be connected before you can create KMS keys in the key store or use the KMS keys it contains. You can disconnect and reconnect a custom key store at any time.
The connection process for a custom key store can take an extended amount of time to complete. This operation starts the connection process, but it does not wait for it to complete. When it succeeds, this operation quickly returns an HTTP 200 response and a JSON object with no properties. However, this response does not indicate that the custom key store is connected. To get the connection state of the custom key store, use the DescribeCustomKeyStores operation.
This operation is part of the [custom key stores] feature in KMS, which combines the convenience and extensive integration of KMS with the isolation and control of a key store that you own and manage.
The ‘ConnectCustomKeyStore` operation might fail for various reasons. To find the reason, use the DescribeCustomKeyStores operation and see the `ConnectionErrorCode` in the response. For help interpreting the `ConnectionErrorCode`, see CustomKeyStoresListEntry.
To fix the failure, use the DisconnectCustomKeyStore operation to disconnect the custom key store, correct the error, use the UpdateCustomKeyStore operation if necessary, and then use ‘ConnectCustomKeyStore` again.
**CloudHSM key store**
During the connection process for an CloudHSM key store, KMS finds the CloudHSM cluster that is associated with the custom key store, creates the connection infrastructure, connects to the cluster, logs into the CloudHSM client as the ‘kmsuser` CU, and rotates its password.
To connect an CloudHSM key store, its associated CloudHSM cluster must have at least one active HSM. To get the number of active HSMs in a cluster, use the [DescribeClusters] operation. To add HSMs to the cluster, use the [CreateHsm] operation. Also, the [ ‘kmsuser` crypto user] (CU) must not be logged into the cluster. This prevents KMS from using this account to log in.
If you are having trouble connecting or disconnecting a CloudHSM key store, see [Troubleshooting an CloudHSM key store] in the *Key Management Service Developer Guide*.
**External key store**
When you connect an external key store that uses public endpoint connectivity, KMS tests its ability to communicate with your external key manager by sending a request via the external key store proxy.
When you connect to an external key store that uses VPC endpoint service connectivity, KMS establishes the networking elements that it needs to communicate with your external key manager via the external key store proxy. This includes creating an interface endpoint to the VPC endpoint service and a private hosted zone for traffic between KMS and the VPC endpoint service.
To connect an external key store, KMS must be able to connect to the external key store proxy, the external key store proxy must be able to communicate with your external key manager, and the external key manager must be available for cryptographic operations.
If you are having trouble connecting or disconnecting an external key store, see [Troubleshooting an external key store] in the *Key Management Service Developer Guide*.
**Cross-account use**: No. You cannot perform this operation on a custom key store in a different Amazon Web Services account.
**Required permissions**: [kms:ConnectCustomKeyStore] (IAM policy)
**Related operations**
-
CreateCustomKeyStore
-
DeleteCustomKeyStore
-
DescribeCustomKeyStores
-
DisconnectCustomKeyStore
-
UpdateCustomKeyStore
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/custom-key-store-overview.html [2]: docs.aws.amazon.com/cloudhsm/latest/APIReference/API_DescribeClusters.html [3]: docs.aws.amazon.com/cloudhsm/latest/APIReference/API_CreateHsm.html [4]: docs.aws.amazon.com/kms/latest/developerguide/key-store-concepts.html#concept-kmsuser [5]: docs.aws.amazon.com/kms/latest/developerguide/fix-keystore.html [6]: docs.aws.amazon.com/kms/latest/developerguide/xks-troubleshooting.html [7]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [8]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
674 675 676 677 |
# File 'lib/aws-sdk-kms/client.rb', line 674 def connect_custom_key_store(params = {}, = {}) req = build_request(:connect_custom_key_store, params) req.send_request() end |
#create_alias(params = {}) ⇒ Struct
Creates a friendly name for a KMS key.
<note markdown=“1”> Adding, deleting, or updating an alias can allow or deny permission to the KMS key. For details, see [ABAC for KMS] in the *Key Management Service Developer Guide*.
</note>
You can use an alias to identify a KMS key in the KMS console, in the DescribeKey operation and in [cryptographic operations], such as Encrypt and GenerateDataKey. You can also change the KMS key that’s associated with the alias (UpdateAlias) or delete the alias (DeleteAlias) at any time. These operations don’t affect the underlying KMS key.
You can associate the alias with any customer managed key in the same Amazon Web Services Region. Each alias is associated with only one KMS key at a time, but a KMS key can have multiple aliases. A valid KMS key is required. You can’t create an alias without a KMS key.
The alias must be unique in the account and Region, but you can have aliases with the same name in different Regions. For detailed information about aliases, see [Using aliases] in the *Key Management Service Developer Guide*.
This operation does not return a response. To get the alias that you created, use the ListAliases operation.
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: No. You cannot perform this operation on an alias in a different Amazon Web Services account.
**Required permissions**
- kms:CreateAlias][5
-
on the alias (IAM policy).
- kms:CreateAlias][5
-
on the KMS key (key policy).
For details, see [Controlling access to aliases] in the *Key Management Service Developer Guide*.
**Related operations:**
-
DeleteAlias
-
ListAliases
-
UpdateAlias
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/abac.html [2]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#cryptographic-operations [3]: docs.aws.amazon.com/kms/latest/developerguide/kms-alias.html [4]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [5]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [6]: docs.aws.amazon.com/kms/latest/developerguide/kms-alias.html#alias-access [7]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
812 813 814 815 |
# File 'lib/aws-sdk-kms/client.rb', line 812 def create_alias(params = {}, = {}) req = build_request(:create_alias, params) req.send_request() end |
#create_custom_key_store(params = {}) ⇒ Types::CreateCustomKeyStoreResponse
Creates a [custom key store] backed by a key store that you own and manage. When you use a KMS key in a custom key store for a cryptographic operation, the cryptographic operation is actually performed in your key store using your keys. KMS supports [CloudHSM key stores] backed by an [CloudHSM cluster] and [external key stores] backed by an external key store proxy and external key manager outside of Amazon Web Services.
This operation is part of the [custom key stores] feature in KMS, which combines the convenience and extensive integration of KMS with the isolation and control of a key store that you own and manage.
Before you create the custom key store, the required elements must be in place and operational. We recommend that you use the test tools that KMS provides to verify the configuration your external key store proxy. For details about the required elements and verification tests, see [Assemble the prerequisites (for CloudHSM key stores)] or
- Assemble the prerequisites (for external key stores)][6
-
in the *Key
Management Service Developer Guide*.
To create a custom key store, use the following parameters.
-
To create an CloudHSM key store, specify the ‘CustomKeyStoreName`, `CloudHsmClusterId`, `KeyStorePassword`, and `TrustAnchorCertificate`. The `CustomKeyStoreType` parameter is optional for CloudHSM key stores. If you include it, set it to the default value, `AWS_CLOUDHSM`. For help with failures, see
- Troubleshooting an CloudHSM key store][7
-
in the *Key Management
Service Developer Guide*.
-
To create an external key store, specify the ‘CustomKeyStoreName` and a `CustomKeyStoreType` of `EXTERNAL_KEY_STORE`. Also, specify values for `XksProxyConnectivity`, `XksProxyAuthenticationCredential`, `XksProxyUriEndpoint`, and `XksProxyUriPath`. If your `XksProxyConnectivity` value is `VPC_ENDPOINT_SERVICE`, specify the `XksProxyVpcEndpointServiceName` parameter. For help with failures, see [Troubleshooting an external key store] in the *Key Management Service Developer Guide*.
<note markdown=“1”> For external key stores:
Some external key managers provide a simpler method for creating an
external key store. For details, see your external key manager documentation.
When creating an external key store in the KMS console, you can upload
a JSON-based proxy configuration file with the desired values. You cannot use a proxy configuration with the ‘CreateCustomKeyStore` operation. However, you can use the values in the file to help you determine the correct values for the `CreateCustomKeyStore` parameters.
</note>
When the operation completes successfully, it returns the ID of the new custom key store. Before you can use your new custom key store, you need to use the ConnectCustomKeyStore operation to connect a new CloudHSM key store to its CloudHSM cluster, or to connect a new external key store to the external key store proxy for your external key manager. Even if you are not going to use your custom key store immediately, you might want to connect it to verify that all settings are correct and then disconnect it until you are ready to use it.
For help with failures, see [Troubleshooting a custom key store] in the *Key Management Service Developer Guide*.
**Cross-account use**: No. You cannot perform this operation on a custom key store in a different Amazon Web Services account.
**Required permissions**: [kms:CreateCustomKeyStore] (IAM policy).
**Related operations:**
-
ConnectCustomKeyStore
-
DeleteCustomKeyStore
-
DescribeCustomKeyStores
-
DisconnectCustomKeyStore
-
UpdateCustomKeyStore
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/custom-key-store-overview.html [2]: docs.aws.amazon.com/kms/latest/developerguide/keystore-cloudhsm.html [3]: docs.aws.amazon.com/cloudhsm/latest/userguide/clusters.html [4]: docs.aws.amazon.com/kms/latest/developerguide/keystore-external.html [5]: docs.aws.amazon.com/kms/latest/developerguide/create-keystore.html#before-keystore [6]: docs.aws.amazon.com/kms/latest/developerguide/create-xks-keystore.html#xks-requirements [7]: docs.aws.amazon.com/kms/latest/developerguide/fix-keystore.html [8]: docs.aws.amazon.com/kms/latest/developerguide/xks-troubleshooting.html [9]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [10]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
1201 1202 1203 1204 |
# File 'lib/aws-sdk-kms/client.rb', line 1201 def create_custom_key_store(params = {}, = {}) req = build_request(:create_custom_key_store, params) req.send_request() end |
#create_grant(params = {}) ⇒ Types::CreateGrantResponse
Adds a grant to a KMS key.
A grant is a policy instrument that allows Amazon Web Services principals to use KMS keys in cryptographic operations. It also can allow them to view a KMS key (DescribeKey) and create and manage grants. When authorizing access to a KMS key, grants are considered along with key policies and IAM policies. Grants are often used for temporary permissions because you can create one, use its permissions, and delete it without changing your key policies or IAM policies.
For detailed information about grants, including grant terminology, see [Grants in KMS] in the Key Management Service Developer Guide . For examples of working with grants in several programming languages, see [Programming grants].
The ‘CreateGrant` operation returns a `GrantToken` and a `GrantId`.
-
When you create, retire, or revoke a grant, there might be a brief delay, usually less than five minutes, until the grant is available throughout KMS. This state is known as *eventual consistency*. Once the grant has achieved eventual consistency, the grantee principal can use the permissions in the grant without identifying the grant.
However, to use the permissions in the grant immediately, use the ‘GrantToken` that `CreateGrant` returns. For details, see [Using a grant token] in the Key Management Service Developer Guide .
-
The ‘CreateGrant` operation also returns a `GrantId`. You can use the `GrantId` and a key identifier to identify the grant in the RetireGrant and RevokeGrant operations. To find the grant ID, use the ListGrants or ListRetirableGrants operations.
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: Yes. To perform this operation on a KMS key in a different Amazon Web Services account, specify the key ARN in the value of the ‘KeyId` parameter.
**Required permissions**: [kms:CreateGrant] (key policy)
**Related operations:**
-
ListGrants
-
ListRetirableGrants
-
RetireGrant
-
RevokeGrant
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/grants.html [2]: docs.aws.amazon.com/kms/latest/developerguide/programming-grants.html [3]: docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token [4]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [5]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [6]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
1478 1479 1480 1481 |
# File 'lib/aws-sdk-kms/client.rb', line 1478 def create_grant(params = {}, = {}) req = build_request(:create_grant, params) req.send_request() end |
#create_key(params = {}) ⇒ Types::CreateKeyResponse
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. For details, see [Managing keys] in the *Key Management Service Developer Guide*
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.
<note markdown=“1”> KMS has replaced the term *customer master key (CMK)* with *KMS key* and *KMS key*. The concept has not changed. To prevent breaking changes, KMS is keeping some variations of this term.
</note>
To create different types of KMS keys, use the following guidance:
Symmetric encryption KMS key
: By default, ‘CreateKey` creates 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 for `KeyUsage`,
`ENCRYPT_DECRYPT`, and the default value for `Origin`, `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 ‘KeySpec` parameter to
specify the type of key material in the KMS key. Then, use the
`KeyUsage` parameter 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, 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-recommended ECC key pairs can be used to sign and verify
messages or derive shared secrets (but not both). KMS keys with
`ECC_SECG_P256K1` can be used only 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][3] in the *Key
Management Service Developer Guide*.
HMAC KMS key
: To create an HMAC KMS key, set the ‘KeySpec` parameter to a key spec
value for HMAC KMS keys. Then set the `KeyUsage` parameter to
`GENERATE_VERIFY_MAC`. You must set the key usage even though
`GENERATE_VERIFY_MAC` is 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 Imported key material
: To create a multi-Region *primary key* in the local Amazon Web
Services Region, use the `MultiRegion` parameter with a value of
`True`. 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][4] in the *Key
Management Service Developer Guide*.
: 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 `Origin` parameter
of `CreateKey` with a value of `EXTERNAL`. 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][5] in the <i> <i>Key Management Service Developer
Guide</i> </i>.
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 `Origin` parameter of `CreateKey` with a value of `EXTERNAL` and
the `MultiRegion` parameter with a value of `True`. To create
replicas of the multi-Region primary key, use the ReplicateKey
operation. For instructions, see [Importing key material into
multi-Region keys][6]. For more information about multi-Region keys,
see [Multi-Region keys in KMS][4] 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][8] backed by an CloudHSM cluster
and [external key stores][9] 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.
<note markdown="1"> Some external key managers provide a simpler method for creating a
KMS key in an external key store. For details, see your external key
manager documentation.
</note>
Before you create a KMS key in a custom key store, the
`ConnectionState` of the key store must be `CONNECTED`. To connect
the custom key store, use the ConnectCustomKeyStore operation. To
find the `ConnectionState`, use the DescribeCustomKeyStores
operation.
To create a KMS key in a custom key store, use the
`CustomKeyStoreId`. Use the default `KeySpec` value,
`SYMMETRIC_DEFAULT`, and the default `KeyUsage` value,
`ENCRYPT_DECRYPT` to 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][8], use the `Origin`
parameter with a value of `AWS_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][9], use the `Origin`
parameter with a value of `EXTERNAL_KEY_STORE` and an `XksKeyId`
parameter that identifies an existing external key.
<note markdown="1"> Some external key managers provide a simpler method for creating a
KMS key in an external key store. For details, see your external key
manager documentation.
</note>
**Cross-account use**: No. You cannot use this operation to create a KMS key in a different Amazon Web Services account.
**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:**
-
DescribeKey
-
ListKeys
-
ScheduleKeyDeletion
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms-keys [2]: docs.aws.amazon.com/kms/latest/developerguide/getting-started.html [3]: docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html [4]: docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html [5]: docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html [6]: docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-import.html [7]: docs.aws.amazon.com/kms/latest/developerguide/custom-key-store-overview.html [8]: docs.aws.amazon.com/kms/latest/developerguide/keystore-cloudhsm.html [9]: docs.aws.amazon.com/kms/latest/developerguide/keystore-external.html [10]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [11]: docs.aws.amazon.com/kms/latest/developerguide/iam-policies.html#iam-policy-example-create-key [12]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
2380 2381 2382 2383 |
# File 'lib/aws-sdk-kms/client.rb', line 2380 def create_key(params = {}, = {}) req = build_request(:create_key, params) req.send_request() end |
#decrypt(params = {}) ⇒ Types::DecryptResponse
Decrypts ciphertext that was encrypted by a KMS key using any of the following operations:
-
Encrypt
-
GenerateDataKey
-
GenerateDataKeyPair
-
GenerateDataKeyWithoutPlaintext
-
GenerateDataKeyPairWithoutPlaintext
You can use this operation to decrypt ciphertext that was encrypted under a symmetric encryption KMS key or an asymmetric encryption KMS key. When the KMS key is asymmetric, you must specify the KMS key and the encryption algorithm that was used to encrypt the ciphertext. For information about asymmetric KMS keys, see [Asymmetric KMS keys] in the *Key Management Service Developer Guide*.
The ‘Decrypt` operation also decrypts ciphertext that was encrypted outside of KMS by the public key in an KMS asymmetric KMS key. However, it cannot decrypt symmetric ciphertext produced by other libraries, such as the [Amazon Web Services Encryption SDK] or [Amazon S3 client-side encryption]. These libraries return a ciphertext format that is incompatible with KMS.
If the ciphertext was encrypted under a symmetric encryption KMS key, the ‘KeyId` parameter is optional. KMS can get this information from metadata that it adds to the symmetric ciphertext blob. This feature adds durability to your implementation by ensuring that authorized users can decrypt ciphertext decades after it was encrypted, even if they’ve lost track of the key ID. However, specifying the KMS key is always recommended as a best practice. When you use the ‘KeyId` parameter to specify a KMS key, KMS only uses the KMS key you specify. If the ciphertext was encrypted under a different KMS key, the `Decrypt` operation fails. This practice ensures that you use the KMS key that you intend.
Whenever possible, use key policies to give users permission to call the ‘Decrypt` operation on a particular KMS key, instead of using &IAM; policies. Otherwise, you might create an &IAM; policy that gives the user `Decrypt` permission on all KMS keys. This user could decrypt ciphertext that was encrypted by KMS keys in other accounts if the key policy for the cross-account KMS key permits it. If you must use an IAM policy for `Decrypt` permissions, limit the user to particular KMS keys or particular trusted accounts. For details, see [Best practices for IAM policies] in the *Key Management Service Developer Guide*.
‘Decrypt` also supports [Amazon Web Services Nitro Enclaves], which provide an isolated compute environment in Amazon EC2. To call `Decrypt` for a Nitro enclave, use the [Amazon Web Services Nitro Enclaves SDK] or any Amazon Web Services SDK. Use the `Recipient` parameter to provide the attestation document for the enclave. Instead of the plaintext data, the response includes the plaintext data encrypted with the public key from the attestation document (`CiphertextForRecipient`). For information about the interaction between KMS and Amazon Web Services Nitro Enclaves, see [How Amazon Web Services Nitro Enclaves uses KMS] in the *Key Management Service Developer Guide*.
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: Yes. If you use the ‘KeyId` parameter to identify a KMS key in a different Amazon Web Services account, specify the key ARN or the alias ARN of the KMS key.
**Required permissions**: [kms:Decrypt] (key policy)
**Related operations:**
-
Encrypt
-
GenerateDataKey
-
GenerateDataKeyPair
-
ReEncrypt
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html [2]: docs.aws.amazon.com/encryption-sdk/latest/developer-guide/ [3]: docs.aws.amazon.com/AmazonS3/latest/dev/UsingClientSideEncryption.html [4]: docs.aws.amazon.com/kms/latest/developerguide/iam-policies.html#iam-policies-best-practices [5]: docs.aws.amazon.com/AWSEC2/latest/UserGuide/nitro-enclave.html [6]: docs.aws.amazon.com/enclaves/latest/user/developing-applications.html#sdk [7]: docs.aws.amazon.com/kms/latest/developerguide/services-nitro-enclaves.html [8]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [9]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [10]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
2696 2697 2698 2699 |
# File 'lib/aws-sdk-kms/client.rb', line 2696 def decrypt(params = {}, = {}) req = build_request(:decrypt, params) req.send_request() end |
#delete_alias(params = {}) ⇒ Struct
Deletes the specified alias.
<note markdown=“1”> Adding, deleting, or updating an alias can allow or deny permission to the KMS key. For details, see [ABAC for KMS] in the *Key Management Service Developer Guide*.
</note>
Because an alias is not a property of a KMS key, you can delete and change the aliases of a KMS key without affecting the KMS key. Also, aliases do not appear in the response from the DescribeKey operation. To get the aliases of all KMS keys, use the ListAliases operation.
Each KMS key can have multiple aliases. To change the alias of a KMS key, use DeleteAlias to delete the current alias and CreateAlias to create a new alias. To associate an existing alias with a different KMS key, call UpdateAlias.
**Cross-account use**: No. You cannot perform this operation on an alias in a different Amazon Web Services account.
**Required permissions**
- kms:DeleteAlias][2
-
on the alias (IAM policy).
- kms:DeleteAlias][2
-
on the KMS key (key policy).
For details, see [Controlling access to aliases] in the *Key Management Service Developer Guide*.
**Related operations:**
-
CreateAlias
-
ListAliases
-
UpdateAlias
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/abac.html [2]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [3]: docs.aws.amazon.com/kms/latest/developerguide/kms-alias.html#alias-access [4]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
2774 2775 2776 2777 |
# File 'lib/aws-sdk-kms/client.rb', line 2774 def delete_alias(params = {}, = {}) req = build_request(:delete_alias, params) req.send_request() end |
#delete_custom_key_store(params = {}) ⇒ Struct
Deletes a [custom key store]. This operation does not affect any backing elements of the custom key store. It does not delete the CloudHSM cluster that is associated with an CloudHSM key store, or affect any users or keys in the cluster. For an external key store, it does not affect the external key store proxy, external key manager, or any external keys.
This operation is part of the [custom key stores] feature in KMS, which combines the convenience and extensive integration of KMS with the isolation and control of a key store that you own and manage.
The custom key store that you delete cannot contain any [KMS keys]. Before deleting the key store, verify that you will never need to use any of the KMS keys in the key store for any [cryptographic operations]. Then, use ScheduleKeyDeletion to delete the KMS keys from the key store. After the required waiting period expires and all KMS keys are deleted from the custom key store, use DisconnectCustomKeyStore to disconnect the key store from KMS. Then, you can delete the custom key store.
For keys in an CloudHSM key store, the ‘ScheduleKeyDeletion` operation makes a best effort to delete the key material from the associated cluster. However, you might need to manually [delete the orphaned key material] from the cluster and its backups. KMS never creates, manages, or deletes cryptographic keys in the external key manager associated with an external key store. You must manage them using your external key manager tools.
Instead of deleting the custom key store, consider using the DisconnectCustomKeyStore operation to disconnect the custom key store from its backing key store. While the key store is disconnected, you cannot create or use the KMS keys in the key store. But, you do not need to delete KMS keys and you can reconnect a disconnected custom key store at any time.
If the operation succeeds, it returns a JSON object with no properties.
**Cross-account use**: No. You cannot perform this operation on a custom key store in a different Amazon Web Services account.
**Required permissions**: [kms:DeleteCustomKeyStore] (IAM policy)
**Related operations:**
-
ConnectCustomKeyStore
-
CreateCustomKeyStore
-
DescribeCustomKeyStores
-
DisconnectCustomKeyStore
-
UpdateCustomKeyStore
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/custom-key-store-overview.html [2]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys [3]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#cryptographic-operations [4]: docs.aws.amazon.com/kms/latest/developerguide/fix-keystore.html#fix-keystore-orphaned-key [5]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [6]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
2877 2878 2879 2880 |
# File 'lib/aws-sdk-kms/client.rb', line 2877 def delete_custom_key_store(params = {}, = {}) req = build_request(:delete_custom_key_store, params) req.send_request() end |
#delete_imported_key_material(params = {}) ⇒ Struct
Deletes key material that was previously imported. This operation makes the specified KMS key temporarily unusable. To restore the usability of the KMS key, reimport the same key material. For more information about importing key material into KMS, see [Importing Key Material] in the *Key Management Service Developer Guide*.
When the specified KMS key is in the ‘PendingDeletion` state, this operation does not change the KMS key’s state. Otherwise, it changes the KMS key’s state to ‘PendingImport`.
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: No. You cannot perform this operation on a KMS key in a different Amazon Web Services account.
**Required permissions**: [kms:DeleteImportedKeyMaterial] (key policy)
**Related operations:**
-
GetParametersForImport
-
ImportKeyMaterial
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html [2]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [3]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [4]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
2955 2956 2957 2958 |
# File 'lib/aws-sdk-kms/client.rb', line 2955 def delete_imported_key_material(params = {}, = {}) req = build_request(:delete_imported_key_material, params) req.send_request() end |
#derive_shared_secret(params = {}) ⇒ Types::DeriveSharedSecretResponse
Derives a shared secret using a key agreement algorithm.
<note markdown=“1”> You must use an asymmetric NIST-recommended elliptic curve (ECC) or SM2 (China Regions only) KMS key pair with a ‘KeyUsage` value of `KEY_AGREEMENT` to call DeriveSharedSecret.
</note>
DeriveSharedSecret uses the [Elliptic Curve Cryptography Cofactor Diffie-Hellman Primitive] (ECDH) to establish a key agreement between two peers by deriving a shared secret from their elliptic curve public-private key pairs. You can use the raw shared secret that DeriveSharedSecret returns to derive a symmetric key that can encrypt and decrypt data that is sent between the two peers, or that can generate and verify HMACs. KMS recommends that you follow [NIST recommendations for key derivation] when using the raw shared secret to derive a symmetric key.
The following workflow demonstrates how to establish key agreement over an insecure communication channel using DeriveSharedSecret.
-
Alice calls CreateKey to create an asymmetric KMS key pair with a ‘KeyUsage` value of `KEY_AGREEMENT`.
The asymmetric KMS key must use a NIST-recommended elliptic curve (ECC) or SM2 (China Regions only) key spec.
-
Bob creates an elliptic curve key pair.
Bob can call CreateKey to create an asymmetric KMS key pair or generate a key pair outside of KMS. Bob’s key pair must use the same NIST-recommended elliptic curve (ECC) or SM2 (China Regions ony) curve as Alice.
-
Alice and Bob **exchange their public keys** through an insecure communication channel (like the internet).
Use GetPublicKey to download the public key of your asymmetric KMS key pair.
<note markdown=“1”> KMS strongly recommends verifying that the public key you receive came from the expected party before using it to derive a shared secret.
</note>
-
Alice calls DeriveSharedSecret.
KMS uses the private key from the KMS key pair generated in **Step 1**, Bob’s public key, and the Elliptic Curve Cryptography Cofactor Diffie-Hellman Primitive to derive the shared secret. The private key in your KMS key pair never leaves KMS unencrypted. DeriveSharedSecret returns the raw shared secret.
-
Bob uses the Elliptic Curve Cryptography Cofactor Diffie-Hellman Primitive to calculate the same raw secret using his private key and Alice’s public key.
To derive a shared secret you must provide a key agreement algorithm, the private key of the caller’s asymmetric NIST-recommended elliptic curve or SM2 (China Regions only) KMS key pair, and the public key from your peer’s NIST-recommended elliptic curve or SM2 (China Regions only) key pair. The public key can be from another asymmetric KMS key pair or from a key pair generated outside of KMS, but both key pairs must be on the same elliptic curve.
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: Yes. To perform this operation with a KMS key in a different Amazon Web Services account, specify the key ARN or alias ARN in the value of the ‘KeyId` parameter.
**Required permissions**: [kms:DeriveSharedSecret] (key policy)
**Related operations:**
-
CreateKey
-
GetPublicKey
-
DescribeKey
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf#page=60 [2]: nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2.pdf [3]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [4]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [5]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
3219 3220 3221 3222 |
# File 'lib/aws-sdk-kms/client.rb', line 3219 def derive_shared_secret(params = {}, = {}) req = build_request(:derive_shared_secret, params) req.send_request() end |
#describe_custom_key_stores(params = {}) ⇒ Types::DescribeCustomKeyStoresResponse
Gets information about [custom key stores] in the account and Region.
This operation is part of the [custom key stores] feature in KMS, which combines the convenience and extensive integration of KMS with the isolation and control of a key store that you own and manage.
By default, this operation returns information about all custom key stores in the account and Region. To get only information about a particular custom key store, use either the ‘CustomKeyStoreName` or `CustomKeyStoreId` parameter (but not both).
To determine whether the custom key store is connected to its CloudHSM cluster or external key store proxy, use the ‘ConnectionState` element in the response. If an attempt to connect the custom key store failed, the `ConnectionState` value is `FAILED` and the `ConnectionErrorCode` element in the response indicates the cause of the failure. For help interpreting the `ConnectionErrorCode`, see CustomKeyStoresListEntry.
Custom key stores have a ‘DISCONNECTED` connection state if the key store has never been connected or you used the DisconnectCustomKeyStore operation to disconnect it. Otherwise, the connection state is CONNECTED. If your custom key store connection state is `CONNECTED` but you are having trouble using it, verify that the backing store is active and available. For an CloudHSM key store, verify that the associated CloudHSM cluster is active and contains the minimum number of HSMs required for the operation, if any. For an external key store, verify that the external key store proxy and its associated external key manager are reachable and enabled.
For help repairing your CloudHSM key store, see the [Troubleshooting CloudHSM key stores]. For help repairing your external key store, see the [Troubleshooting external key stores]. Both topics are in the *Key Management Service Developer Guide*.
**Cross-account use**: No. You cannot perform this operation on a custom key store in a different Amazon Web Services account.
**Required permissions**: [kms:DescribeCustomKeyStores] (IAM policy)
**Related operations:**
-
ConnectCustomKeyStore
-
CreateCustomKeyStore
-
DeleteCustomKeyStore
-
DisconnectCustomKeyStore
-
UpdateCustomKeyStore
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/custom-key-store-overview.html [2]: docs.aws.amazon.com/kms/latest/developerguide/fix-keystore.html [3]: docs.aws.amazon.com/kms/latest/developerguide/xks-troubleshooting.html [4]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [5]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
The returned response is a pageable response and is Enumerable. For details on usage see PageableResponse.
3454 3455 3456 3457 |
# File 'lib/aws-sdk-kms/client.rb', line 3454 def describe_custom_key_stores(params = {}, = {}) req = build_request(:describe_custom_key_stores, params) req.send_request() end |
#describe_key(params = {}) ⇒ Types::DescribeKeyResponse
Provides detailed information about a KMS key. You can run ‘DescribeKey` on a [customer managed key] or an [Amazon Web Services managed key].
This detailed information includes the key ARN, creation date (and deletion date, if applicable), the key state, and the origin and expiration date (if any) of the key material. It includes fields, like ‘KeySpec`, that help you distinguish different types of KMS keys. It also displays the key usage (encryption, signing, or generating and verifying MACs) and the algorithms that the KMS key supports.
For [multi-Region keys], ‘DescribeKey` displays the primary key and all related replica keys. For KMS keys in [CloudHSM key stores], it includes information about the key store, such as the key store ID and the CloudHSM cluster ID. For KMS keys in [external key stores], it includes the custom key store ID and the ID of the external key.
‘DescribeKey` does not return the following information:
-
Aliases associated with the KMS key. To get this information, use ListAliases.
-
Whether automatic key rotation is enabled on the KMS key. To get this information, use GetKeyRotationStatus. Also, some key states prevent a KMS key from being automatically rotated. For details, see
- How Automatic Key Rotation Works][6
-
in the *Key Management Service
Developer Guide*.
-
Tags on the KMS key. To get this information, use ListResourceTags.
-
Key policies and grants on the KMS key. To get this information, use GetKeyPolicy and ListGrants.
In general, ‘DescribeKey` is a non-mutating operation. It returns data about KMS keys, but doesn’t change them. However, Amazon Web Services services use ‘DescribeKey` to create [Amazon Web Services managed keys] from a *predefined Amazon Web Services alias* with no key ID.
**Cross-account use**: Yes. To perform this operation with a KMS key in a different Amazon Web Services account, specify the key ARN or alias ARN in the value of the ‘KeyId` parameter.
**Required permissions**: [kms:DescribeKey] (key policy)
**Related operations:**
-
GetKeyPolicy
-
GetKeyRotationStatus
-
ListAliases
-
ListGrants
-
ListKeys
-
ListResourceTags
-
ListRetirableGrants
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk [2]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk [3]: docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html [4]: docs.aws.amazon.com/kms/latest/developerguide/keystore-cloudhsm.html [5]: docs.aws.amazon.com/kms/latest/developerguide/keystore-external.html [6]: docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html#rotate-keys-how-it-works [7]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [8]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
3841 3842 3843 3844 |
# File 'lib/aws-sdk-kms/client.rb', line 3841 def describe_key(params = {}, = {}) req = build_request(:describe_key, params) req.send_request() end |
#disable_key(params = {}) ⇒ Struct
Sets the state of a KMS key to disabled. This change temporarily prevents use of the KMS key for [cryptographic operations].
For more information about how key state affects the use of a KMS key, see [Key states of KMS keys] in the Key Management Service Developer Guide .
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: No. You cannot perform this operation on a KMS key in a different Amazon Web Services account.
**Required permissions**: [kms:DisableKey] (key policy)
**Related operations**: EnableKey
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#cryptographic-operations [2]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [3]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [4]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
3910 3911 3912 3913 |
# File 'lib/aws-sdk-kms/client.rb', line 3910 def disable_key(params = {}, = {}) req = build_request(:disable_key, params) req.send_request() end |
#disable_key_rotation(params = {}) ⇒ Struct
Disables [automatic rotation of the key material] of the specified symmetric encryption KMS key.
Automatic key rotation is supported only on symmetric encryption KMS keys. You cannot enable automatic rotation of [asymmetric KMS keys], [HMAC KMS keys], KMS keys with [imported key material], or KMS keys in a [custom key store]. To enable or disable automatic rotation of a set of related [multi-Region keys], set the property on the primary key.
You can enable (EnableKeyRotation) and disable automatic rotation of the key material in [customer managed KMS keys]. Key material rotation of [Amazon Web Services managed KMS keys] is not configurable. KMS always rotates the key material for every year. Rotation of [Amazon Web Services owned KMS keys] varies.
<note markdown=“1”> In May 2022, KMS changed the rotation schedule for Amazon Web Services managed keys from every three years to every year. For details, see EnableKeyRotation.
</note>
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: No. You cannot perform this operation on a KMS key in a different Amazon Web Services account.
**Required permissions**: [kms:DisableKeyRotation] (key policy)
**Related operations:**
-
EnableKeyRotation
-
GetKeyRotationStatus
-
ListKeyRotations
-
RotateKeyOnDemand
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html [2]: docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html [3]: docs.aws.amazon.com/kms/latest/developerguide/hmac.html [4]: docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html [5]: docs.aws.amazon.com/kms/latest/developerguide/custom-key-store-overview.html [6]: docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-manage.html#multi-region-rotate [7]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk [8]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk [9]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk [10]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [11]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [12]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
4020 4021 4022 4023 |
# File 'lib/aws-sdk-kms/client.rb', line 4020 def disable_key_rotation(params = {}, = {}) req = build_request(:disable_key_rotation, params) req.send_request() end |
#disconnect_custom_key_store(params = {}) ⇒ Struct
Disconnects the [custom key store] from its backing key store. This operation disconnects an CloudHSM key store from its associated CloudHSM cluster or disconnects an external key store from the external key store proxy that communicates with your external key manager.
This operation is part of the [custom key stores] feature in KMS, which combines the convenience and extensive integration of KMS with the isolation and control of a key store that you own and manage.
While a custom key store is disconnected, you can manage the custom key store and its KMS keys, but you cannot create or use its KMS keys. You can reconnect the custom key store at any time.
<note markdown=“1”> While a custom key store is disconnected, all attempts to create KMS keys in the custom key store or to use existing KMS keys in
- cryptographic operations][2
-
will fail. This action can prevent users
from storing and accessing sensitive data.
</note>
When you disconnect a custom key store, its ‘ConnectionState` changes to `Disconnected`. To find the connection state of a custom key store, use the DescribeCustomKeyStores operation. To reconnect a custom key store, use the ConnectCustomKeyStore operation.
If the operation succeeds, it returns a JSON object with no properties.
**Cross-account use**: No. You cannot perform this operation on a custom key store in a different Amazon Web Services account.
**Required permissions**: [kms:DisconnectCustomKeyStore] (IAM policy)
**Related operations:**
-
ConnectCustomKeyStore
-
CreateCustomKeyStore
-
DeleteCustomKeyStore
-
DescribeCustomKeyStores
-
UpdateCustomKeyStore
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/custom-key-store-overview.html [2]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#cryptographic-operations [3]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [4]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
4115 4116 4117 4118 |
# File 'lib/aws-sdk-kms/client.rb', line 4115 def disconnect_custom_key_store(params = {}, = {}) req = build_request(:disconnect_custom_key_store, params) req.send_request() end |
#enable_key(params = {}) ⇒ Struct
Sets the key state of a KMS key to enabled. This allows you to use the KMS key for [cryptographic operations].
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: No. You cannot perform this operation on a KMS key in a different Amazon Web Services account.
**Required permissions**: [kms:EnableKey] (key policy)
**Related operations**: DisableKey
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#cryptographic-operations [2]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [3]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [4]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
4180 4181 4182 4183 |
# File 'lib/aws-sdk-kms/client.rb', line 4180 def enable_key(params = {}, = {}) req = build_request(:enable_key, params) req.send_request() end |
#enable_key_rotation(params = {}) ⇒ Struct
Enables [automatic rotation of the key material] of the specified symmetric encryption KMS key.
By default, when you enable automatic rotation of a [customer managed KMS key], KMS rotates the key material of the KMS key one year (approximately 365 days) from the enable date and every year thereafter. You can use the optional ‘RotationPeriodInDays` parameter to specify a custom rotation period when you enable key rotation, or you can use `RotationPeriodInDays` to modify the rotation period of a key that you previously enabled automatic key rotation on.
You can monitor rotation of the key material for your KMS keys in CloudTrail and Amazon CloudWatch. To disable rotation of the key material in a customer managed KMS key, use the DisableKeyRotation operation. You can use the GetKeyRotationStatus operation to identify any in progress rotations. You can use the ListKeyRotations operation to view the details of completed rotations.
Automatic key rotation is supported only on [symmetric encryption KMS keys]. You cannot enable automatic rotation of [asymmetric KMS keys], [HMAC KMS keys], KMS keys with [imported key material], or KMS keys in a [custom key store]. To enable or disable automatic rotation of a set of related [multi-Region keys], set the property on the primary key.
You cannot enable or disable automatic rotation of [Amazon Web Services managed KMS keys]. KMS always rotates the key material of Amazon Web Services managed keys every year. Rotation of [Amazon Web Services owned KMS keys] is managed by the Amazon Web Services service that owns the key.
<note markdown=“1”> In May 2022, KMS changed the rotation schedule for Amazon Web Services managed keys from every three years (approximately 1,095 days) to every year (approximately 365 days).
New Amazon Web Services managed keys are automatically rotated one
year after they are created, and approximately every year thereafter.
Existing Amazon Web Services managed keys are automatically rotated
one year after their most recent rotation, and every year thereafter.
</note>
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: No. You cannot perform this operation on a KMS key in a different Amazon Web Services account.
**Required permissions**: [kms:EnableKeyRotation] (key policy)
**Related operations:**
-
DisableKeyRotation
-
GetKeyRotationStatus
-
ListKeyRotations
-
RotateKeyOnDemand
<note markdown=“1”> You can perform on-demand (RotateKeyOnDemand) rotation of the key material in customer managed KMS keys, regardless of whether or not automatic key rotation is enabled.
</note>
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html#rotating-keys-enable-disable [2]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk [3]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#symmetric-cmks [4]: docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html [5]: docs.aws.amazon.com/kms/latest/developerguide/hmac.html [6]: docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html [7]: docs.aws.amazon.com/kms/latest/developerguide/custom-key-store-overview.html [8]: docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-manage.html#multi-region-rotate [9]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk [10]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk [11]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [12]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [13]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
4341 4342 4343 4344 |
# File 'lib/aws-sdk-kms/client.rb', line 4341 def enable_key_rotation(params = {}, = {}) req = build_request(:enable_key_rotation, params) req.send_request() end |
#encrypt(params = {}) ⇒ Types::EncryptResponse
Encrypts plaintext of up to 4,096 bytes using a KMS key. You can use a symmetric or asymmetric KMS key with a ‘KeyUsage` of `ENCRYPT_DECRYPT`.
You can use this operation to encrypt small amounts of arbitrary data, such as a personal identifier or database password, or other sensitive information. You don’t need to use the ‘Encrypt` operation to encrypt a data key. The GenerateDataKey and GenerateDataKeyPair operations return a plaintext data key and an encrypted copy of that data key.
If you use a symmetric encryption KMS key, you can use an encryption context to add additional security to your encryption operation. If you specify an ‘EncryptionContext` when encrypting data, you must specify the same encryption context (a case-sensitive exact match) when decrypting the data. Otherwise, the request to decrypt fails with an `InvalidCiphertextException`. For more information, see [Encryption Context] in the *Key Management Service Developer Guide*.
If you specify an asymmetric KMS key, you must also specify the encryption algorithm. The algorithm must be compatible with the KMS key spec.
When you use an asymmetric KMS key to encrypt or reencrypt data, be sure to record the KMS key and encryption algorithm that you choose. You will be required to provide the same KMS key and encryption algorithm when you decrypt the data. If the KMS key and algorithm do not match the values used to encrypt the data, the decrypt operation fails.
You are not required to supply the key ID and encryption algorithm
when you decrypt with symmetric encryption KMS keys because KMS stores this information in the ciphertext blob. KMS cannot store metadata in ciphertext generated with asymmetric keys. The standard format for asymmetric key ciphertext does not include configurable fields.
The maximum size of the data that you can encrypt varies with the type of KMS key and the encryption algorithm that you choose.
-
Symmetric encryption KMS keys
-
‘SYMMETRIC_DEFAULT`: 4096 bytes
^
-
-
‘RSA_2048`
-
‘RSAES_OAEP_SHA_1`: 214 bytes
-
‘RSAES_OAEP_SHA_256`: 190 bytes
-
-
‘RSA_3072`
-
‘RSAES_OAEP_SHA_1`: 342 bytes
-
‘RSAES_OAEP_SHA_256`: 318 bytes
-
-
‘RSA_4096`
-
‘RSAES_OAEP_SHA_1`: 470 bytes
-
‘RSAES_OAEP_SHA_256`: 446 bytes
-
-
‘SM2PKE`: 1024 bytes (China Regions only)
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: Yes. To perform this operation with a KMS key in a different Amazon Web Services account, specify the key ARN or alias ARN in the value of the ‘KeyId` parameter.
**Required permissions**: [kms:Encrypt] (key policy)
**Related operations:**
-
Decrypt
-
GenerateDataKey
-
GenerateDataKeyPair
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#encrypt_context [2]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [3]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [4]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
4588 4589 4590 4591 |
# File 'lib/aws-sdk-kms/client.rb', line 4588 def encrypt(params = {}, = {}) req = build_request(:encrypt, params) req.send_request() end |
#generate_data_key(params = {}) ⇒ Types::GenerateDataKeyResponse
Returns a unique symmetric data key for use outside of KMS. This operation returns a plaintext copy of the data key and a copy that is encrypted under a symmetric encryption KMS key that you specify. The bytes in the plaintext key are random; they are not related to the caller or the KMS key. You can use the plaintext key to encrypt your data outside of KMS and store the encrypted data key with the encrypted data.
To generate a data key, specify the symmetric encryption KMS key that will be used to encrypt the data key. You cannot use an asymmetric KMS key to encrypt data keys. To get the type of your KMS key, use the DescribeKey operation.
You must also specify the length of the data key. Use either the ‘KeySpec` or `NumberOfBytes` parameters (but not both). For 128-bit and 256-bit data keys, use the `KeySpec` parameter.
To generate a 128-bit SM4 data key (China Regions only), specify a ‘KeySpec` value of `AES_128` or a `NumberOfBytes` value of `16`. The symmetric encryption key used in China Regions to encrypt your data key is an SM4 encryption key.
To get only an encrypted copy of the data key, use GenerateDataKeyWithoutPlaintext. To generate an asymmetric data key pair, use the GenerateDataKeyPair or GenerateDataKeyPairWithoutPlaintext operation. To get a cryptographically secure random byte string, use GenerateRandom.
You can use an optional encryption context to add additional security to the encryption operation. If you specify an ‘EncryptionContext`, you must specify the same encryption context (a case-sensitive exact match) when decrypting the encrypted data key. Otherwise, the request to decrypt fails with an `InvalidCiphertextException`. For more information, see [Encryption Context] in the *Key Management Service Developer Guide*.
‘GenerateDataKey` also supports [Amazon Web Services Nitro Enclaves], which provide an isolated compute environment in Amazon EC2. To call `GenerateDataKey` for an Amazon Web Services Nitro enclave, use the [Amazon Web Services Nitro Enclaves SDK] or any Amazon Web Services SDK. Use the `Recipient` parameter to provide the attestation document for the enclave. `GenerateDataKey` returns a copy of the data key encrypted under the specified KMS key, as usual. But instead of a plaintext copy of the data key, the response includes a copy of the data key encrypted under the public key from the attestation document (`CiphertextForRecipient`). For information about the interaction between KMS and Amazon Web Services Nitro Enclaves, see [How Amazon Web Services Nitro Enclaves uses KMS] in the *Key Management Service Developer Guide*..
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**How to use your data key**
We recommend that you use the following pattern to encrypt data locally in your application. You can write your own code or use a client-side encryption library, such as the [Amazon Web Services Encryption SDK], the [Amazon DynamoDB Encryption Client], or
- Amazon S3 client-side encryption][8
-
to do these tasks for you.
To encrypt data outside of KMS:
-
Use the ‘GenerateDataKey` operation to get a data key.
-
Use the plaintext data key (in the ‘Plaintext` field of the response) to encrypt your data outside of KMS. Then erase the plaintext data key from memory.
-
Store the encrypted data key (in the ‘CiphertextBlob` field of the response) with the encrypted data.
To decrypt data outside of KMS:
-
Use the Decrypt operation to decrypt the encrypted data key. The operation returns a plaintext copy of the data key.
-
Use the plaintext data key to decrypt data outside of KMS, then erase the plaintext data key from memory.
**Cross-account use**: Yes. To perform this operation with a KMS key in a different Amazon Web Services account, specify the key ARN or alias ARN in the value of the ‘KeyId` parameter.
**Required permissions**: [kms:GenerateDataKey] (key policy)
**Related operations:**
-
Decrypt
-
Encrypt
-
GenerateDataKeyPair
-
GenerateDataKeyPairWithoutPlaintext
-
GenerateDataKeyWithoutPlaintext
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#encrypt_context [2]: docs.aws.amazon.com/AWSEC2/latest/UserGuide/nitro-enclave.html [3]: docs.aws.amazon.com/enclaves/latest/user/developing-applications.html#sdk [4]: docs.aws.amazon.com/kms/latest/developerguide/services-nitro-enclaves.html [5]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [6]: docs.aws.amazon.com/encryption-sdk/latest/developer-guide/ [7]: docs.aws.amazon.com/dynamodb-encryption-client/latest/devguide/ [8]: docs.aws.amazon.com/AmazonS3/latest/dev/UsingClientSideEncryption.html [9]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [10]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
4903 4904 4905 4906 |
# File 'lib/aws-sdk-kms/client.rb', line 4903 def generate_data_key(params = {}, = {}) req = build_request(:generate_data_key, params) req.send_request() end |
#generate_data_key_pair(params = {}) ⇒ Types::GenerateDataKeyPairResponse
Returns a unique asymmetric data key pair for use outside of KMS. This operation returns a plaintext public key, a plaintext private key, and a copy of the private key that is encrypted under the symmetric encryption KMS key you specify. You can use the data key pair to perform asymmetric cryptography and implement digital signatures outside of KMS. The bytes in the keys are random; they are not related to the caller or to the KMS key that is used to encrypt the private key.
You can use the public key that ‘GenerateDataKeyPair` returns to encrypt data or verify a signature outside of KMS. Then, store the encrypted private key with the data. When you are ready to decrypt data or sign a message, you can use the Decrypt operation to decrypt the encrypted private key.
To generate a data key pair, you must specify a symmetric encryption KMS key to encrypt the private key in a data key pair. You cannot use an asymmetric KMS key or a KMS key in a custom key store. To get the type and origin of your KMS key, use the DescribeKey operation.
Use the ‘KeyPairSpec` parameter to choose an RSA or Elliptic Curve (ECC) data key pair. In China Regions, you can also choose an SM2 data key pair. KMS recommends that you use ECC key pairs for signing, and use RSA and SM2 key pairs for either encryption or signing, but not both. However, KMS cannot enforce any restrictions on the use of data key pairs outside of KMS.
If you are using the data key pair to encrypt data, or for any operation where you don’t immediately need a private key, consider using the GenerateDataKeyPairWithoutPlaintext operation. ‘GenerateDataKeyPairWithoutPlaintext` returns a plaintext public key and an encrypted private key, but omits the plaintext private key that you need only to decrypt ciphertext or sign a message. Later, when you need to decrypt the data or sign a message, use the Decrypt operation to decrypt the encrypted private key in the data key pair.
‘GenerateDataKeyPair` returns a unique data key pair for each request. The bytes in the keys are random; they are not related to the caller or the KMS key that is used to encrypt the private key. The public key is a DER-encoded X.509 SubjectPublicKeyInfo, as specified in [RFC 5280]. The private key is a DER-encoded PKCS8 PrivateKeyInfo, as specified in [RFC 5958].
‘GenerateDataKeyPair` also supports [Amazon Web Services Nitro Enclaves], which provide an isolated compute environment in Amazon EC2. To call `GenerateDataKeyPair` for an Amazon Web Services Nitro enclave, use the [Amazon Web Services Nitro Enclaves SDK] or any Amazon Web Services SDK. Use the `Recipient` parameter to provide the attestation document for the enclave. `GenerateDataKeyPair` returns the public data key and a copy of the private data key encrypted under the specified KMS key, as usual. But instead of a plaintext copy of the private data key (`PrivateKeyPlaintext`), the response includes a copy of the private data key encrypted under the public key from the attestation document (`CiphertextForRecipient`). For information about the interaction between KMS and Amazon Web Services Nitro Enclaves, see [How Amazon Web Services Nitro Enclaves uses KMS] in the *Key Management Service Developer Guide*..
You can use an optional encryption context to add additional security to the encryption operation. If you specify an ‘EncryptionContext`, you must specify the same encryption context (a case-sensitive exact match) when decrypting the encrypted data key. Otherwise, the request to decrypt fails with an `InvalidCiphertextException`. For more information, see [Encryption Context] in the *Key Management Service Developer Guide*.
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: Yes. To perform this operation with a KMS key in a different Amazon Web Services account, specify the key ARN or alias ARN in the value of the ‘KeyId` parameter.
**Required permissions**: [kms:GenerateDataKeyPair] (key policy)
**Related operations:**
-
Decrypt
-
Encrypt
-
GenerateDataKey
-
GenerateDataKeyPairWithoutPlaintext
-
GenerateDataKeyWithoutPlaintext
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: tools.ietf.org/html/rfc5280 [2]: tools.ietf.org/html/rfc5958 [3]: docs.aws.amazon.com/AWSEC2/latest/UserGuide/nitro-enclave.html [4]: docs.aws.amazon.com/enclaves/latest/user/developing-applications.html#sdk [5]: docs.aws.amazon.com/kms/latest/developerguide/services-nitro-enclaves.html [6]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#encrypt_context [7]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [8]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [9]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
5209 5210 5211 5212 |
# File 'lib/aws-sdk-kms/client.rb', line 5209 def generate_data_key_pair(params = {}, = {}) req = build_request(:generate_data_key_pair, params) req.send_request() end |
#generate_data_key_pair_without_plaintext(params = {}) ⇒ Types::GenerateDataKeyPairWithoutPlaintextResponse
Returns a unique asymmetric data key pair for use outside of KMS. This operation returns a plaintext public key and a copy of the private key that is encrypted under the symmetric encryption KMS key you specify. Unlike GenerateDataKeyPair, this operation does not return a plaintext private key. The bytes in the keys are random; they are not related to the caller or to the KMS key that is used to encrypt the private key.
You can use the public key that ‘GenerateDataKeyPairWithoutPlaintext` returns to encrypt data or verify a signature outside of KMS. Then, store the encrypted private key with the data. When you are ready to decrypt data or sign a message, you can use the Decrypt operation to decrypt the encrypted private key.
To generate a data key pair, you must specify a symmetric encryption KMS key to encrypt the private key in a data key pair. You cannot use an asymmetric KMS key or a KMS key in a custom key store. To get the type and origin of your KMS key, use the DescribeKey operation.
Use the ‘KeyPairSpec` parameter to choose an RSA or Elliptic Curve (ECC) data key pair. In China Regions, you can also choose an SM2 data key pair. KMS recommends that you use ECC key pairs for signing, and use RSA and SM2 key pairs for either encryption or signing, but not both. However, KMS cannot enforce any restrictions on the use of data key pairs outside of KMS.
‘GenerateDataKeyPairWithoutPlaintext` returns a unique data key pair for each request. The bytes in the key are not related to the caller or KMS key that is used to encrypt the private key. The public key is a DER-encoded X.509 SubjectPublicKeyInfo, as specified in [RFC 5280].
You can use an optional encryption context to add additional security to the encryption operation. If you specify an ‘EncryptionContext`, you must specify the same encryption context (a case-sensitive exact match) when decrypting the encrypted data key. Otherwise, the request to decrypt fails with an `InvalidCiphertextException`. For more information, see [Encryption Context] in the *Key Management Service Developer Guide*.
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: Yes. To perform this operation with a KMS key in a different Amazon Web Services account, specify the key ARN or alias ARN in the value of the ‘KeyId` parameter.
**Required permissions**: [kms:GenerateDataKeyPairWithoutPlaintext] (key policy)
**Related operations:**
-
Decrypt
-
Encrypt
-
GenerateDataKey
-
GenerateDataKeyPair
-
GenerateDataKeyWithoutPlaintext
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: tools.ietf.org/html/rfc5280 [2]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#encrypt_context [3]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [4]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [5]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
5417 5418 5419 5420 |
# File 'lib/aws-sdk-kms/client.rb', line 5417 def generate_data_key_pair_without_plaintext(params = {}, = {}) req = build_request(:generate_data_key_pair_without_plaintext, params) req.send_request() end |
#generate_data_key_without_plaintext(params = {}) ⇒ Types::GenerateDataKeyWithoutPlaintextResponse
Returns a unique symmetric data key for use outside of KMS. This operation returns a data key that is encrypted under a symmetric encryption KMS key that you specify. The bytes in the key are random; they are not related to the caller or to the KMS key.
‘GenerateDataKeyWithoutPlaintext` is identical to the GenerateDataKey operation except that it does not return a plaintext copy of the data key.
This operation is useful for systems that need to encrypt data at some point, but not immediately. When you need to encrypt the data, you call the Decrypt operation on the encrypted copy of the key.
It’s also useful in distributed systems with different levels of trust. For example, you might store encrypted data in containers. One component of your system creates new containers and stores an encrypted data key with each container. Then, a different component puts the data into the containers. That component first decrypts the data key, uses the plaintext data key to encrypt data, puts the encrypted data into the container, and then destroys the plaintext data key. In this system, the component that creates the containers never sees the plaintext data key.
To request an asymmetric data key pair, use the GenerateDataKeyPair or GenerateDataKeyPairWithoutPlaintext operations.
To generate a data key, you must specify the symmetric encryption KMS key that is used to encrypt the data key. You cannot use an asymmetric KMS key or a key in a custom key store to generate a data key. To get the type of your KMS key, use the DescribeKey operation.
You must also specify the length of the data key. Use either the ‘KeySpec` or `NumberOfBytes` parameters (but not both). For 128-bit and 256-bit data keys, use the `KeySpec` parameter.
To generate an SM4 data key (China Regions only), specify a ‘KeySpec` value of `AES_128` or `NumberOfBytes` value of `16`. The symmetric encryption key used in China Regions to encrypt your data key is an SM4 encryption key.
If the operation succeeds, you will find the encrypted copy of the data key in the ‘CiphertextBlob` field.
You can use an optional encryption context to add additional security to the encryption operation. If you specify an ‘EncryptionContext`, you must specify the same encryption context (a case-sensitive exact match) when decrypting the encrypted data key. Otherwise, the request to decrypt fails with an `InvalidCiphertextException`. For more information, see [Encryption Context] in the *Key Management Service Developer Guide*.
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: Yes. To perform this operation with a KMS key in a different Amazon Web Services account, specify the key ARN or alias ARN in the value of the ‘KeyId` parameter.
**Required permissions**: [kms:GenerateDataKeyWithoutPlaintext] (key policy)
**Related operations:**
-
Decrypt
-
Encrypt
-
GenerateDataKey
-
GenerateDataKeyPair
-
GenerateDataKeyPairWithoutPlaintext
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#encrypt_context [2]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [3]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [4]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
5632 5633 5634 5635 |
# File 'lib/aws-sdk-kms/client.rb', line 5632 def generate_data_key_without_plaintext(params = {}, = {}) req = build_request(:generate_data_key_without_plaintext, params) req.send_request() end |
#generate_mac(params = {}) ⇒ Types::GenerateMacResponse
Generates a hash-based message authentication code (HMAC) for a message using an HMAC KMS key and a MAC algorithm that the key supports. HMAC KMS keys and the HMAC algorithms that KMS uses conform to industry standards defined in [RFC 2104].
You can use value that GenerateMac returns in the VerifyMac operation to demonstrate that the original message has not changed. Also, because a secret key is used to create the hash, you can verify that the party that generated the hash has the required secret key. You can also use the raw result to implement HMAC-based algorithms such as key derivation functions. This operation is part of KMS support for HMAC KMS keys. For details, see [HMAC keys in KMS] in the Key Management Service Developer Guide .
<note markdown=“1”> 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.
</note>
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: Yes. To perform this operation with a KMS key in a different Amazon Web Services account, specify the key ARN or alias ARN in the value of the ‘KeyId` parameter.
**Required permissions**: [kms:GenerateMac] (key policy)
**Related operations**: VerifyMac
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: datatracker.ietf.org/doc/html/rfc2104 [2]: docs.aws.amazon.com/kms/latest/developerguide/hmac.html [3]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [4]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [5]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
5778 5779 5780 5781 |
# File 'lib/aws-sdk-kms/client.rb', line 5778 def generate_mac(params = {}, = {}) req = build_request(:generate_mac, params) req.send_request() end |
#generate_random(params = {}) ⇒ Types::GenerateRandomResponse
Returns a random byte string that is cryptographically secure.
You must use the ‘NumberOfBytes` parameter to specify the length of the random byte string. There is no default value for string length.
By default, the random byte string is generated in KMS. To generate the byte string in the CloudHSM cluster associated with an CloudHSM key store, use the ‘CustomKeyStoreId` parameter.
‘GenerateRandom` also supports [Amazon Web Services Nitro Enclaves], which provide an isolated compute environment in Amazon EC2. To call `GenerateRandom` for a Nitro enclave, use the [Amazon Web Services Nitro Enclaves SDK] or any Amazon Web Services SDK. Use the `Recipient` parameter to provide the attestation document for the enclave. Instead of plaintext bytes, the response includes the plaintext bytes encrypted under the public key from the attestation document (`CiphertextForRecipient`).For information about the interaction between KMS and Amazon Web Services Nitro Enclaves, see
- How Amazon Web Services Nitro Enclaves uses KMS][3
-
in the *Key
Management Service Developer Guide*.
For more information about entropy and random number generation, see [Key Management Service Cryptographic Details].
**Cross-account use**: Not applicable. ‘GenerateRandom` does not use any account-specific resources, such as KMS keys.
**Required permissions**: [kms:GenerateRandom] (IAM policy)
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/AWSEC2/latest/UserGuide/nitro-enclave.html [2]: docs.aws.amazon.com/enclaves/latest/user/developing-applications.html#sdk [3]: docs.aws.amazon.com/kms/latest/developerguide/services-nitro-enclaves.html [4]: docs.aws.amazon.com/kms/latest/cryptographic-details/ [5]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [6]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
5921 5922 5923 5924 |
# File 'lib/aws-sdk-kms/client.rb', line 5921 def generate_random(params = {}, = {}) req = build_request(:generate_random, params) req.send_request() end |
#get_key_policy(params = {}) ⇒ Types::GetKeyPolicyResponse
Gets a key policy attached to the specified KMS key.
**Cross-account use**: No. You cannot perform this operation on a KMS key in a different Amazon Web Services account.
**Required permissions**: [kms:GetKeyPolicy] (key policy)
**Related operations**: [PutKeyPolicy]
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [2]: docs.aws.amazon.com/kms/latest/APIReference/API_PutKeyPolicy.html [3]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
6000 6001 6002 6003 |
# File 'lib/aws-sdk-kms/client.rb', line 6000 def get_key_policy(params = {}, = {}) req = build_request(:get_key_policy, params) req.send_request() end |
#get_key_rotation_status(params = {}) ⇒ Types::GetKeyRotationStatusResponse
Provides detailed information about the rotation status for a KMS key, including whether [automatic rotation of the key material] is enabled for the specified KMS key, the [rotation period], and the next scheduled rotation date.
Automatic key rotation is supported only on [symmetric encryption KMS keys]. You cannot enable automatic rotation of [asymmetric KMS keys], [HMAC KMS keys], KMS keys with [imported key material], or KMS keys in a [custom key store]. To enable or disable automatic rotation of a set of related [multi-Region keys], set the property on the primary key..
You can enable (EnableKeyRotation) and disable automatic rotation (DisableKeyRotation) of the key material in customer managed KMS keys. Key material rotation of [Amazon Web Services managed KMS keys] is not configurable. KMS always rotates the key material in Amazon Web Services managed KMS keys every year. The key rotation status for Amazon Web Services managed KMS keys is always ‘true`.
You can perform on-demand (RotateKeyOnDemand) rotation of the key material in customer managed KMS keys, regardless of whether or not automatic key rotation is enabled. You can use GetKeyRotationStatus to identify the date and time that an in progress on-demand rotation was initiated. You can use ListKeyRotations to view the details of completed rotations.
<note markdown=“1”> In May 2022, KMS changed the rotation schedule for Amazon Web Services managed keys from every three years to every year. For details, see EnableKeyRotation.
</note>
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
-
Disabled: The key rotation status does not change when you disable a KMS key. However, while the KMS key is disabled, KMS does not rotate the key material. When you re-enable the KMS key, rotation resumes. If the key material in the re-enabled KMS key hasn’t been rotated in one year, KMS rotates it immediately, and every year thereafter. If it’s been less than a year since the key material in the re-enabled KMS key was rotated, the KMS key resumes its prior rotation schedule.
-
Pending deletion: While a KMS key is pending deletion, its key rotation status is ‘false` and KMS does not rotate the key material. If you cancel the deletion, the original key rotation status returns to `true`.
**Cross-account use**: Yes. To perform this operation on a KMS key in a different Amazon Web Services account, specify the key ARN in the value of the ‘KeyId` parameter.
**Required permissions**: [kms:GetKeyRotationStatus] (key policy)
**Related operations:**
-
DisableKeyRotation
-
EnableKeyRotation
-
ListKeyRotations
-
RotateKeyOnDemand
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html [2]: docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html#rotation-period [3]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#symmetric-cmks [4]: docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html [5]: docs.aws.amazon.com/kms/latest/developerguide/hmac.html [6]: docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html [7]: docs.aws.amazon.com/kms/latest/developerguide/custom-key-store-overview.html [8]: docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-manage.html#multi-region-rotate [9]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk [10]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [11]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [12]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
6150 6151 6152 6153 |
# File 'lib/aws-sdk-kms/client.rb', line 6150 def get_key_rotation_status(params = {}, = {}) req = build_request(:get_key_rotation_status, params) req.send_request() end |
#get_parameters_for_import(params = {}) ⇒ Types::GetParametersForImportResponse
Returns the public key and an import token you need to import or reimport key material for a KMS key.
By default, KMS keys are created with key material that KMS generates. This operation supports [Importing key material], an advanced feature that lets you generate and import the cryptographic key material for a KMS key. For more information about importing key material into KMS, see [Importing key material] in the *Key Management Service Developer Guide*.
Before calling ‘GetParametersForImport`, use the CreateKey operation with an `Origin` value of `EXTERNAL` to create a KMS key with no key material. You can import key material for a symmetric encryption KMS key, HMAC KMS key, asymmetric encryption KMS key, or asymmetric signing KMS key. You can also import key material into a [multi-Region key] of any supported type. However, you can’t import key material into a KMS key in a [custom key store]. You can also use ‘GetParametersForImport` to get a public key and import token to
- reimport the original key material][4
-
into a KMS key whose key
material expired or was deleted.
‘GetParametersForImport` returns the items that you need to import your key material.
-
The public key (or “wrapping key”) of an RSA key pair that KMS generates.
You will use this public key to encrypt (“wrap”) your key material while it’s in transit to KMS.
-
A import token that ensures that KMS can decrypt your key material and associate it with the correct KMS key.
The public key and its import token are permanently linked and must be used together. Each public key and import token set is valid for 24 hours. The expiration date and time appear in the ‘ParametersValidTo` field in the `GetParametersForImport` response. You cannot use an expired public key or import token in an ImportKeyMaterial request. If your key and token expire, send another `GetParametersForImport` request.
‘GetParametersForImport` requires the following information:
-
The key ID of the KMS key for which you are importing the key material.
-
The key spec of the public key (“wrapping key”) that you will use to encrypt your key material during import.
-
The wrapping algorithm that you will use with the public key to encrypt your key material.
You can use the same or a different public key spec and wrapping algorithm each time you import or reimport the same key material.
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: No. You cannot perform this operation on a KMS key in a different Amazon Web Services account.
**Required permissions**: [kms:GetParametersForImport] (key policy)
**Related operations:**
-
ImportKeyMaterial
-
DeleteImportedKeyMaterial
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html [2]: docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html [3]: docs.aws.amazon.com/kms/latest/developerguide/custom-key-store-overview.html [4]: docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html#reimport-key-material [5]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [6]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [7]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
6410 6411 6412 6413 |
# File 'lib/aws-sdk-kms/client.rb', line 6410 def get_parameters_for_import(params = {}, = {}) req = build_request(:get_parameters_for_import, params) req.send_request() end |
#get_public_key(params = {}) ⇒ Types::GetPublicKeyResponse
Returns the public key of an asymmetric KMS key. Unlike the private key of a asymmetric KMS key, which never leaves KMS unencrypted, callers with ‘kms:GetPublicKey` permission can download the public key of an asymmetric KMS key. You can share the public key to allow others to encrypt messages and verify signatures outside of KMS. For information about asymmetric KMS keys, see [Asymmetric KMS keys] in the *Key Management Service Developer Guide*.
You do not need to download the public key. Instead, you can use the public key within KMS by calling the Encrypt, ReEncrypt, or Verify operations with the identifier of an asymmetric KMS key. When you use the public key within KMS, you benefit from the authentication, authorization, and logging that are part of every KMS operation. You also reduce of risk of encrypting data that cannot be decrypted. These features are not effective outside of KMS.
To help you use the public key safely outside of KMS, ‘GetPublicKey` returns important information about the public key in the response, including:
-
[KeySpec]: The type of key material in the public key, such as ‘RSA_4096` or `ECC_NIST_P521`.
-
[KeyUsage]: Whether the key is used for encryption, signing, or deriving a shared secret.
- EncryptionAlgorithms][4
-
or [SigningAlgorithms]: A list of the
encryption algorithms or the signing algorithms for the key.
Although KMS cannot enforce these restrictions on external operations, it is crucial that you use this information to prevent the public key from being used improperly. For example, you can prevent a public signing key from being used encrypt data, or prevent a public key from being used with an encryption algorithm that is not supported by KMS. You can also avoid errors, such as using the wrong signing algorithm in a verification operation.
To verify a signature outside of KMS with an SM2 public key (China Regions only), you must specify the distinguishing ID. By default, KMS uses ‘1234567812345678` as the distinguishing ID. For more information, see [Offline verification with SM2 key pairs].
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: Yes. To perform this operation with a KMS key in a different Amazon Web Services account, specify the key ARN or alias ARN in the value of the ‘KeyId` parameter.
**Required permissions**: [kms:GetPublicKey] (key policy)
**Related operations**: CreateKey
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html [2]: docs.aws.amazon.com/kms/latest/APIReference/API_GetPublicKey.html#KMS-GetPublicKey-response-KeySpec [3]: docs.aws.amazon.com/kms/latest/APIReference/API_GetPublicKey.html#KMS-GetPublicKey-response-KeyUsage [4]: docs.aws.amazon.com/kms/latest/APIReference/API_GetPublicKey.html#KMS-GetPublicKey-response-EncryptionAlgorithms [5]: docs.aws.amazon.com/kms/latest/APIReference/API_GetPublicKey.html#KMS-GetPublicKey-response-SigningAlgorithms [6]: docs.aws.amazon.com/kms/latest/developerguide/asymmetric-key-specs.html#key-spec-sm-offline-verification [7]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [8]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [9]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
6578 6579 6580 6581 |
# File 'lib/aws-sdk-kms/client.rb', line 6578 def get_public_key(params = {}, = {}) req = build_request(:get_public_key, params) req.send_request() end |
#import_key_material(params = {}) ⇒ Struct
Imports or reimports key material into an existing KMS key that was created without key material. ‘ImportKeyMaterial` also sets the expiration model and expiration date of the imported key material.
By default, KMS keys are created with key material that KMS generates. This operation supports [Importing key material], an advanced feature that lets you generate and import the cryptographic key material for a KMS key. For more information about importing key material into KMS, see [Importing key material] in the *Key Management Service Developer Guide*.
After you successfully import key material into a KMS key, you can
- reimport the same key material][2
-
into that KMS key, but you cannot
import different key material. You might reimport key material to replace key material that expired or key material that you deleted. You might also reimport key material to change the expiration model or expiration date of the key material.
Each time you import key material into KMS, you can determine whether (‘ExpirationModel`) and when (`ValidTo`) the key material expires. To change the expiration of your key material, you must import it again, either by calling `ImportKeyMaterial` or using the [import features](kms/latest/developerguide/importing-keys-import-key-material.html#importing-keys-import-key-material-console) of the KMS console.
Before calling ‘ImportKeyMaterial`:
-
Create or identify a KMS key with no key material. The KMS key must have an ‘Origin` value of `EXTERNAL`, which indicates that the KMS key is designed for imported key material.
To create an new KMS key for imported key material, call the CreateKey operation with an ‘Origin` value of `EXTERNAL`. You can create a symmetric encryption KMS key, HMAC KMS key, asymmetric encryption KMS key, or asymmetric signing KMS key. You can also import key material into a [multi-Region key](kms/latest/developerguide/multi-region-keys-overview.html) of any supported type. However, you can’t import key material into a KMS key in a [custom key store](kms/latest/developerguide/custom-key-store-overview.html).
-
Use the DescribeKey operation to verify that the ‘KeyState` of the KMS key is `PendingImport`, which indicates that the KMS key has no key material.
If you are reimporting the same key material into an existing KMS key, you might need to call the DeleteImportedKeyMaterial to delete its existing key material.
-
Call the GetParametersForImport operation to get a public key and import token set for importing key material.
-
Use the public key in the GetParametersForImport response to encrypt your key material.
Then, in an ‘ImportKeyMaterial` request, you submit your encrypted key material and import token. When calling this operation, you must specify the following values:
-
The key ID or key ARN of the KMS key to associate with the imported key material. Its ‘Origin` must be `EXTERNAL` and its `KeyState` must be `PendingImport`. You cannot perform this operation on a KMS key in a [custom key store](kms/latest/developerguide/custom-key-store-overview.html), or on a KMS key in a different Amazon Web Services account. To get the `Origin` and `KeyState` of a KMS key, call DescribeKey.
-
The encrypted key material.
-
The import token that GetParametersForImport returned. You must use a public key and token from the same ‘GetParametersForImport` response.
-
Whether the key material expires (‘ExpirationModel`) and, if so, when (`ValidTo`). For help with this choice, see [Setting an expiration time] in the *Key Management Service Developer Guide*.
If you set an expiration date, KMS deletes the key material from the KMS key on the specified date, making the KMS key unusable. To use the KMS key in cryptographic operations again, you must reimport the same key material. However, you can delete and reimport the key material at any time, including before the key material expires. Each time you reimport, you can eliminate or reset the expiration time.
When this operation is successful, the key state of the KMS key changes from ‘PendingImport` to `Enabled`, and you can use the KMS key in cryptographic operations.
If this operation fails, use the exception to help determine the problem. If the error is related to the key material, the import token, or wrapping key, use GetParametersForImport to get a new public key and import token for the KMS key and repeat the import procedure. For help, see [How To Import Key Material] in the *Key Management Service Developer Guide*.
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: No. You cannot perform this operation on a KMS key in a different Amazon Web Services account.
**Required permissions**: [kms:ImportKeyMaterial] (key policy)
**Related operations:**
-
DeleteImportedKeyMaterial
-
GetParametersForImport
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html [2]: docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html#reimport-key-material [3]: docs.aws.amazon.com/en_us/kms/latest/developerguide/importing-keys.html#importing-keys-expiration [4]: docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html#importing-keys-overview [5]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [6]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [7]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
6821 6822 6823 6824 |
# File 'lib/aws-sdk-kms/client.rb', line 6821 def import_key_material(params = {}, = {}) req = build_request(:import_key_material, params) req.send_request() end |
#list_aliases(params = {}) ⇒ Types::ListAliasesResponse
Gets a list of aliases in the caller’s Amazon Web Services account and region. For more information about aliases, see CreateAlias.
By default, the ‘ListAliases` operation returns all aliases in the account and region. To get only the aliases associated with a particular KMS key, use the `KeyId` parameter.
The ‘ListAliases` response can include aliases that you created and associated with your customer managed keys, and aliases that Amazon Web Services created and associated with Amazon Web Services managed keys in your account. You can recognize Amazon Web Services aliases because their names have the format `aws/<service-name>`, such as `aws/dynamodb`.
The response might also include aliases that have no ‘TargetKeyId` field. These are predefined aliases that Amazon Web Services has created but has not yet associated with a KMS key. Aliases that Amazon Web Services creates in your account, including predefined aliases, do not count against your [KMS aliases quota].
**Cross-account use**: No. ‘ListAliases` does not return aliases in other Amazon Web Services accounts.
**Required permissions**: [kms:ListAliases] (IAM policy)
For details, see [Controlling access to aliases] in the *Key Management Service Developer Guide*.
**Related operations:**
-
CreateAlias
-
DeleteAlias
-
UpdateAlias
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/limits.html#aliases-limit [2]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [3]: docs.aws.amazon.com/kms/latest/developerguide/kms-alias.html#alias-access [4]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
The returned response is a pageable response and is Enumerable. For details on usage see PageableResponse.
6990 6991 6992 6993 |
# File 'lib/aws-sdk-kms/client.rb', line 6990 def list_aliases(params = {}, = {}) req = build_request(:list_aliases, params) req.send_request() end |
#list_grants(params = {}) ⇒ Types::ListGrantsResponse
Gets a list of all grants for the specified KMS key.
You must specify the KMS key in all requests. You can filter the grant list by grant ID or grantee principal.
For detailed information about grants, including grant terminology, see [Grants in KMS] in the Key Management Service Developer Guide . For examples of working with grants in several programming languages, see [Programming grants].
<note markdown=“1”> The ‘GranteePrincipal` field in the `ListGrants` response usually contains the user or role designated as the grantee principal in the grant. However, when the grantee principal in the grant is an Amazon Web Services service, the `GranteePrincipal` field contains the [service principal], which might represent several different grantee principals.
</note>
**Cross-account use**: Yes. To perform this operation on a KMS key in a different Amazon Web Services account, specify the key ARN in the value of the ‘KeyId` parameter.
**Required permissions**: [kms:ListGrants] (key policy)
**Related operations:**
-
CreateGrant
-
ListRetirableGrants
-
RetireGrant
-
RevokeGrant
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/grants.html [2]: docs.aws.amazon.com/kms/latest/developerguide/programming-grants.html [3]: docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#principal-services [4]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [5]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
The returned response is a pageable response and is Enumerable. For details on usage see PageableResponse.
7187 7188 7189 7190 |
# File 'lib/aws-sdk-kms/client.rb', line 7187 def list_grants(params = {}, = {}) req = build_request(:list_grants, params) req.send_request() end |
#list_key_policies(params = {}) ⇒ Types::ListKeyPoliciesResponse
Gets the names of the key policies that are attached to a KMS key. This operation is designed to get policy names that you can use in a GetKeyPolicy operation. However, the only valid policy name is ‘default`.
**Cross-account use**: No. You cannot perform this operation on a KMS key in a different Amazon Web Services account.
**Required permissions**: [kms:ListKeyPolicies] (key policy)
**Related operations:**
-
GetKeyPolicy
- PutKeyPolicy][2
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [2]: docs.aws.amazon.com/kms/latest/APIReference/API_PutKeyPolicy.html [3]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
The returned response is a pageable response and is Enumerable. For details on usage see PageableResponse.
7292 7293 7294 7295 |
# File 'lib/aws-sdk-kms/client.rb', line 7292 def list_key_policies(params = {}, = {}) req = build_request(:list_key_policies, params) req.send_request() end |
#list_key_rotations(params = {}) ⇒ Types::ListKeyRotationsResponse
Returns information about all completed key material rotations for the specified KMS key.
You must specify the KMS key in all requests. You can refine the key rotations list by limiting the number of rotations returned.
For detailed information about automatic and on-demand key rotations, see [Rotating KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: No. You cannot perform this operation on a KMS key in a different Amazon Web Services account.
**Required permissions**: [kms:ListKeyRotations] (key policy)
**Related operations:**
-
EnableKeyRotation
-
DisableKeyRotation
-
GetKeyRotationStatus
-
RotateKeyOnDemand
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html [2]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [3]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
The returned response is a pageable response and is Enumerable. For details on usage see PageableResponse.
7415 7416 7417 7418 |
# File 'lib/aws-sdk-kms/client.rb', line 7415 def list_key_rotations(params = {}, = {}) req = build_request(:list_key_rotations, params) req.send_request() end |
#list_keys(params = {}) ⇒ Types::ListKeysResponse
Gets a list of all KMS keys in the caller’s Amazon Web Services account and Region.
**Cross-account use**: No. You cannot perform this operation on a KMS key in a different Amazon Web Services account.
**Required permissions**: [kms:ListKeys] (IAM policy)
**Related operations:**
-
CreateKey
-
DescribeKey
-
ListAliases
-
ListResourceTags
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [2]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
The returned response is a pageable response and is Enumerable. For details on usage see PageableResponse.
7530 7531 7532 7533 |
# File 'lib/aws-sdk-kms/client.rb', line 7530 def list_keys(params = {}, = {}) req = build_request(:list_keys, params) req.send_request() end |
#list_resource_tags(params = {}) ⇒ Types::ListResourceTagsResponse
Returns all tags on the specified KMS key.
For general information about tags, including the format and syntax, see [Tagging Amazon Web Services resources] in the *Amazon Web Services General Reference*. For information about using tags in KMS, see [Tagging keys].
**Cross-account use**: No. You cannot perform this operation on a KMS key in a different Amazon Web Services account.
**Required permissions**: [kms:ListResourceTags] (key policy)
**Related operations:**
-
CreateKey
-
ReplicateKey
-
TagResource
-
UntagResource
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/general/latest/gr/aws_tagging.html [2]: docs.aws.amazon.com/kms/latest/developerguide/tagging-keys.html [3]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [4]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
The returned response is a pageable response and is Enumerable. For details on usage see PageableResponse.
7654 7655 7656 7657 |
# File 'lib/aws-sdk-kms/client.rb', line 7654 def (params = {}, = {}) req = build_request(:list_resource_tags, params) req.send_request() end |
#list_retirable_grants(params = {}) ⇒ Types::ListGrantsResponse
Returns information about all grants in the Amazon Web Services account and Region that have the specified retiring principal.
You can specify any principal in your Amazon Web Services account. The grants that are returned include grants for KMS keys in your Amazon Web Services account and other Amazon Web Services accounts. You might use this operation to determine which grants you may retire. To retire a grant, use the RetireGrant operation.
For detailed information about grants, including grant terminology, see [Grants in KMS] in the Key Management Service Developer Guide . For examples of working with grants in several programming languages, see [Programming grants].
**Cross-account use**: You must specify a principal in your Amazon Web Services account. This operation returns a list of grants where the retiring principal specified in the ‘ListRetirableGrants` request is the same retiring principal on the grant. This can include grants on KMS keys owned by other Amazon Web Services accounts, but you do not need `kms:ListRetirableGrants` permission (or any other additional permission) in any Amazon Web Services account other than your own.
**Required permissions**: [kms:ListRetirableGrants] (IAM policy) in your Amazon Web Services account.
<note markdown=“1”> KMS authorizes ‘ListRetirableGrants` requests by evaluating the caller account’s kms:ListRetirableGrants permissions. The authorized resource in ‘ListRetirableGrants` calls is the retiring principal specified in the request. KMS does not evaluate the caller’s permissions to verify their access to any KMS keys or grants that might be returned by the ‘ListRetirableGrants` call.
</note>
**Related operations:**
-
CreateGrant
-
ListGrants
-
RetireGrant
-
RevokeGrant
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/grants.html [2]: docs.aws.amazon.com/kms/latest/developerguide/programming-grants.html [3]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [4]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
The returned response is a pageable response and is Enumerable. For details on usage see PageableResponse.
7809 7810 7811 7812 |
# File 'lib/aws-sdk-kms/client.rb', line 7809 def list_retirable_grants(params = {}, = {}) req = build_request(:list_retirable_grants, params) req.send_request() end |
#put_key_policy(params = {}) ⇒ Struct
Attaches a key policy to the specified KMS key.
For more information about key policies, see [Key Policies] in the *Key Management Service Developer Guide*. For help writing and formatting a JSON policy document, see the [IAM JSON Policy Reference] in the Identity and Access Management User Guide . For examples of adding a key policy in multiple programming languages, see [Setting a key policy] in the *Key Management Service Developer Guide*.
**Cross-account use**: No. You cannot perform this operation on a KMS key in a different Amazon Web Services account.
**Required permissions**: [kms:PutKeyPolicy] (key policy)
**Related operations**: GetKeyPolicy
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/key-policies.html [2]: docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html [3]: docs.aws.amazon.com/kms/latest/developerguide/programming-key-policies.html#put-policy [4]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [5]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
7950 7951 7952 7953 |
# File 'lib/aws-sdk-kms/client.rb', line 7950 def put_key_policy(params = {}, = {}) req = build_request(:put_key_policy, params) req.send_request() end |
#re_encrypt(params = {}) ⇒ Types::ReEncryptResponse
Decrypts ciphertext and then reencrypts it entirely within KMS. You can use this operation to change the KMS key under which data is encrypted, such as when you [manually rotate] a KMS key or change the KMS key that protects a ciphertext. You can also use it to reencrypt ciphertext under the same KMS key, such as to change the
- encryption context][2
-
of a ciphertext.
The ‘ReEncrypt` operation can decrypt ciphertext that was encrypted by using a KMS key in an KMS operation, such as Encrypt or GenerateDataKey. It can also decrypt ciphertext that was encrypted by using the public key of an [asymmetric KMS key] outside of KMS. However, it cannot decrypt ciphertext produced by other libraries, such as the [Amazon Web Services Encryption SDK] or [Amazon S3 client-side encryption]. These libraries return a ciphertext format that is incompatible with KMS.
When you use the ‘ReEncrypt` operation, you need to provide information for the decrypt operation and the subsequent encrypt operation.
-
If your ciphertext was encrypted under an asymmetric KMS key, you must use the ‘SourceKeyId` parameter to identify the KMS key that encrypted the ciphertext. You must also supply the encryption algorithm that was used. This information is required to decrypt the data.
-
If your ciphertext was encrypted under a symmetric encryption KMS key, the ‘SourceKeyId` parameter is optional. KMS can get this information from metadata that it adds to the symmetric ciphertext blob. This feature adds durability to your implementation by ensuring that authorized users can decrypt ciphertext decades after it was encrypted, even if they’ve lost track of the key ID. However, specifying the source KMS key is always recommended as a best practice. When you use the ‘SourceKeyId` parameter to specify a KMS key, KMS uses only the KMS key you specify. If the ciphertext was encrypted under a different KMS key, the `ReEncrypt` operation fails. This practice ensures that you use the KMS key that you intend.
-
To reencrypt the data, you must use the ‘DestinationKeyId` parameter to specify the KMS key that re-encrypts the data after it is decrypted. If the destination KMS key is an asymmetric KMS key, you must also provide the encryption algorithm. The algorithm that you choose must be compatible with the KMS key.
When you use an asymmetric KMS key to encrypt or reencrypt data, be sure to record the KMS key and encryption algorithm that you choose. You will be required to provide the same KMS key and encryption algorithm when you decrypt the data. If the KMS key and algorithm do not match the values used to encrypt the data, the decrypt operation fails.
You are not required to supply the key ID and encryption algorithm
when you decrypt with symmetric encryption KMS keys because KMS stores this information in the ciphertext blob. KMS cannot store metadata in ciphertext generated with asymmetric keys. The standard format for asymmetric key ciphertext does not include configurable fields.
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: Yes. The source KMS key and destination KMS key can be in different Amazon Web Services accounts. Either or both KMS keys can be in a different account than the caller. To specify a KMS key in a different account, you must use its key ARN or alias ARN.
**Required permissions**:
- kms:ReEncryptFrom][7
-
permission on the source KMS key (key policy)
- kms:ReEncryptTo][7
-
permission on the destination KMS key (key
policy)
To permit reencryption from or to a KMS key, include the ‘“kms:ReEncrypt*”` permission in your [key policy]. This permission is automatically included in the key policy when you use the console to create a KMS key. But you must include it manually when you create a KMS key programmatically or when you use the PutKeyPolicy operation to set a key policy.
**Related operations:**
-
Decrypt
-
Encrypt
-
GenerateDataKey
-
GenerateDataKeyPair
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html#rotate-keys-manually [2]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#encrypt_context [3]: docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-concepts.html#asymmetric-cmks [4]: docs.aws.amazon.com/encryption-sdk/latest/developer-guide/ [5]: docs.aws.amazon.com/AmazonS3/latest/dev/UsingClientSideEncryption.html [6]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [7]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [8]: docs.aws.amazon.com/kms/latest/developerguide/key-policies.html [9]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
8271 8272 8273 8274 |
# File 'lib/aws-sdk-kms/client.rb', line 8271 def re_encrypt(params = {}, = {}) req = build_request(:re_encrypt, params) req.send_request() end |
#replicate_key(params = {}) ⇒ Types::ReplicateKeyResponse
Replicates a multi-Region key into the specified Region. This operation creates a multi-Region replica key based on a multi-Region primary key in a different Region of the same Amazon Web Services partition. You can create multiple replicas of a primary key, but each must be in a different Region. To create a multi-Region primary key, use the CreateKey operation.
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*.
A *replica key* is a fully-functional KMS key that can be used independently of its primary and peer replica keys. A primary key and its replica keys share properties that make them interoperable. They have the same [key ID] and key material. They also have the same [key spec], [key usage], [key material origin], and [automatic key rotation status]. KMS automatically synchronizes these shared properties among related multi-Region keys. All other properties of a replica key can differ, including its [key policy], [tags], [aliases], and [Key states of KMS keys]. KMS pricing and quotas for KMS keys apply to each primary key and replica key.
When this operation completes, the new replica key has a transient key state of ‘Creating`. This key state changes to `Enabled` (or `PendingImport`) after a few seconds when the process of creating the new replica key is complete. While the key state is `Creating`, you can manage key, but you cannot yet use it in cryptographic operations. If you are creating and using the replica key programmatically, retry on `KMSInvalidStateException` or call `DescribeKey` to check its `KeyState` value before using it. For details about the `Creating` key state, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
You cannot create more than one replica of a primary key in any Region. If the Region already includes a replica of the key you’re trying to replicate, ‘ReplicateKey` returns an `AlreadyExistsException` error. If the key state of the existing replica is `PendingDeletion`, you can cancel the scheduled key deletion (CancelKeyDeletion) or wait for the key to be deleted. The new replica key you create will have the same [shared properties] as the original replica key.
The CloudTrail log of a ‘ReplicateKey` operation records a `ReplicateKey` operation in the primary key’s Region and a CreateKey operation in the replica key’s Region.
If you replicate a multi-Region primary key with imported key material, the replica key is created with no key material. You must import the same key material that you imported into the primary key. For details, see [Importing key material into multi-Region keys] in the *Key Management Service Developer Guide*.
To convert a replica key to a primary key, use the UpdatePrimaryRegion operation.
<note markdown=“1”> ‘ReplicateKey` uses different default values for the `KeyPolicy` and `Tags` parameters than those used in the KMS console. For details, see the parameter descriptions.
</note>
**Cross-account use**: No. You cannot use this operation to create a replica key in a different Amazon Web Services account.
**Required permissions**:
-
‘kms:ReplicateKey` on the primary key (in the primary key’s Region). Include this permission in the primary key’s key policy.
-
‘kms:CreateKey` in an IAM policy in the replica Region.
-
To use the ‘Tags` parameter, `kms:TagResource` in an IAM policy in the replica Region.
**Related operations**
-
CreateKey
-
UpdatePrimaryRegion
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html [2]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-id-key-id [3]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-spec [4]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-usage [5]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-origin [6]: docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html [7]: docs.aws.amazon.com/kms/latest/developerguide/key-policies.html [8]: docs.aws.amazon.com/kms/latest/developerguide/tagging-keys.html [9]: docs.aws.amazon.com/kms/latest/developerguide/kms-alias.html [10]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [11]: docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html#mrk-sync-properties [12]: docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-import.html [13]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
8672 8673 8674 8675 |
# File 'lib/aws-sdk-kms/client.rb', line 8672 def replicate_key(params = {}, = {}) req = build_request(:replicate_key, params) req.send_request() end |
#retire_grant(params = {}) ⇒ Struct
Deletes a grant. Typically, you retire a grant when you no longer need its permissions. To identify the grant to retire, use a [grant token], or both the grant ID and a key identifier (key ID or key ARN) of the KMS key. The CreateGrant operation returns both values.
This operation can be called by the *retiring principal* for a grant, by the *grantee principal* if the grant allows the ‘RetireGrant` operation, and by the Amazon Web Services account in which the grant is created. It can also be called by principals to whom permission for retiring a grant is delegated. For details, see [Retiring and revoking grants] in the *Key Management Service Developer Guide*.
For detailed information about grants, including grant terminology, see [Grants in KMS] in the Key Management Service Developer Guide . For examples of working with grants in several programming languages, see [Programming grants].
**Cross-account use**: Yes. You can retire a grant on a KMS key in a different Amazon Web Services account.
**Required permissions**: Permission to retire a grant is determined primarily by the grant. For details, see [Retiring and revoking grants] in the *Key Management Service Developer Guide*.
**Related operations:**
-
CreateGrant
-
ListGrants
-
ListRetirableGrants
-
RevokeGrant
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/grants.html#grant_token [2]: docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#grant-delete [3]: docs.aws.amazon.com/kms/latest/developerguide/grants.html [4]: docs.aws.amazon.com/kms/latest/developerguide/programming-grants.html [5]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
8787 8788 8789 8790 |
# File 'lib/aws-sdk-kms/client.rb', line 8787 def retire_grant(params = {}, = {}) req = build_request(:retire_grant, params) req.send_request() end |
#revoke_grant(params = {}) ⇒ Struct
Deletes the specified grant. You revoke a grant to terminate the permissions that the grant allows. For more information, see [Retiring and revoking grants] in the Key Management Service Developer Guide .
When you create, retire, or revoke a grant, there might be a brief delay, usually less than five minutes, until the grant is available throughout KMS. This state is known as *eventual consistency*. For details, see [Eventual consistency] in the Key Management Service Developer Guide .
For detailed information about grants, including grant terminology, see [Grants in KMS] in the Key Management Service Developer Guide . For examples of working with grants in several programming languages, see [Programming grants].
**Cross-account use**: Yes. To perform this operation on a KMS key in a different Amazon Web Services account, specify the key ARN in the value of the ‘KeyId` parameter.
**Required permissions**: [kms:RevokeGrant] (key policy).
**Related operations:**
-
CreateGrant
-
ListGrants
-
ListRetirableGrants
-
RetireGrant
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#grant-delete [2]: docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-eventual-consistency [3]: docs.aws.amazon.com/kms/latest/developerguide/grants.html [4]: docs.aws.amazon.com/kms/latest/developerguide/programming-grants.html [5]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [6]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
8892 8893 8894 8895 |
# File 'lib/aws-sdk-kms/client.rb', line 8892 def revoke_grant(params = {}, = {}) req = build_request(:revoke_grant, params) req.send_request() end |
#rotate_key_on_demand(params = {}) ⇒ Types::RotateKeyOnDemandResponse
Immediately initiates rotation of the key material of the specified symmetric encryption KMS key.
You can perform [on-demand rotation] of the key material in customer managed KMS keys, regardless of whether or not [automatic key rotation] is enabled. On-demand rotations do not change existing automatic rotation schedules. For example, consider a KMS key that has automatic key rotation enabled with a rotation period of 730 days. If the key is scheduled to automatically rotate on April 14, 2024, and you perform an on-demand rotation on April 10, 2024, the key will automatically rotate, as scheduled, on April 14, 2024 and every 730 days thereafter.
<note markdown=“1”> You can perform on-demand key rotation a **maximum of 10 times** per KMS key. You can use the KMS console to view the number of remaining on-demand rotations available for a KMS key.
</note>
You can use GetKeyRotationStatus to identify any in progress on-demand rotations. You can use ListKeyRotations to identify the date that completed on-demand rotations were performed. You can monitor rotation of the key material for your KMS keys in CloudTrail and Amazon CloudWatch.
On-demand key rotation is supported only on [symmetric encryption KMS keys]. You cannot perform on-demand rotation of [asymmetric KMS keys], [HMAC KMS keys], KMS keys with [imported key material], or KMS keys in a [custom key store]. To perform on-demand rotation of a set of related [multi-Region keys], invoke the on-demand rotation on the primary key.
You cannot initiate on-demand rotation of [Amazon Web Services managed KMS keys]. KMS always rotates the key material of Amazon Web Services managed keys every year. Rotation of [Amazon Web Services owned KMS keys] is managed by the Amazon Web Services service that owns the key.
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: No. You cannot perform this operation on a KMS key in a different Amazon Web Services account.
**Required permissions**: [kms:RotateKeyOnDemand] (key policy)
**Related operations:**
-
EnableKeyRotation
-
DisableKeyRotation
-
GetKeyRotationStatus
-
ListKeyRotations
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html#rotating-keys-on-demand [2]: docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html#rotating-keys-enable-disable [3]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#symmetric-cmks [4]: docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html [5]: docs.aws.amazon.com/kms/latest/developerguide/hmac.html [6]: docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html [7]: docs.aws.amazon.com/kms/latest/developerguide/custom-key-store-overview.html [8]: docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-manage.html#multi-region-rotate [9]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk [10]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk [11]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [12]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [13]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
9033 9034 9035 9036 |
# File 'lib/aws-sdk-kms/client.rb', line 9033 def rotate_key_on_demand(params = {}, = {}) req = build_request(:rotate_key_on_demand, params) req.send_request() end |
#schedule_key_deletion(params = {}) ⇒ Types::ScheduleKeyDeletionResponse
Schedules the deletion of a KMS key. By default, KMS applies a waiting period of 30 days, but you can specify a waiting period of 7-30 days. When this operation is successful, the key state of the KMS key changes to ‘PendingDeletion` and the key can’t be used in any cryptographic operations. It remains in this state for the duration of the waiting period. Before the waiting period ends, you can use CancelKeyDeletion to cancel the deletion of the KMS key. After the waiting period ends, KMS deletes the KMS key, its key material, and all KMS data associated with it, including all aliases that refer to it.
Deleting a KMS key is a destructive and potentially dangerous operation. When a KMS key is deleted, all data that was encrypted under the KMS key is unrecoverable. (The only exception is a [multi-Region replica key], or an [asymmetric or HMAC KMS key with imported key material](kms/latest/developerguide/importing-keys-managing.html#import-delete-key).) To prevent the use of a KMS key without deleting it, use DisableKey.
You can schedule the deletion of a multi-Region primary key and its replica keys at any time. However, KMS will not delete a multi-Region primary key with existing replica keys. If you schedule the deletion of a primary key with replicas, its key state changes to ‘PendingReplicaDeletion` and it cannot be replicated or used in cryptographic operations. This status can continue indefinitely. When the last of its replicas keys is deleted (not just scheduled), the key state of the primary key changes to `PendingDeletion` and its waiting period (`PendingWindowInDays`) begins. For details, see [Deleting multi-Region keys] in the *Key Management Service Developer Guide*.
When KMS [deletes a KMS key from an CloudHSM key store], it makes a best effort to delete the associated key material from the associated CloudHSM cluster. However, you might need to manually [delete the orphaned key material] from the cluster and its backups. [Deleting a KMS key from an external key store] has no effect on the associated external key. However, for both types of custom key stores, deleting a KMS key is destructive and irreversible. You cannot decrypt ciphertext encrypted under the KMS key by using only its associated external key or CloudHSM key. Also, you cannot recreate a KMS key in an external key store by creating a new KMS key with the same key material.
For more information about scheduling a KMS key for deletion, see
- Deleting KMS keys][5
-
in the *Key Management Service Developer
Guide*.
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: No. You cannot perform this operation on a KMS key in a different Amazon Web Services account.
**Required permissions**: kms:ScheduleKeyDeletion (key policy)
**Related operations**
-
CancelKeyDeletion
-
DisableKey
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-delete.html [2]: docs.aws.amazon.com/kms/latest/developerguide/delete-cmk-keystore.html [3]: docs.aws.amazon.com/kms/latest/developerguide/fix-keystore.html#fix-keystore-orphaned-key [4]: docs.aws.amazon.com/kms/latest/developerguide/delete-xks-key.html [5]: docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html [6]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [7]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
9186 9187 9188 9189 |
# File 'lib/aws-sdk-kms/client.rb', line 9186 def schedule_key_deletion(params = {}, = {}) req = build_request(:schedule_key_deletion, params) req.send_request() end |
#sign(params = {}) ⇒ Types::SignResponse
Creates a [digital signature] for a message or message digest by using the private key in an asymmetric signing KMS key. To verify the signature, use the Verify operation, or use the public key in the same asymmetric KMS key outside of KMS. For information about asymmetric KMS keys, see [Asymmetric KMS keys] in the *Key Management Service Developer Guide*.
Digital signatures are generated and verified by using asymmetric key pair, such as an RSA or ECC pair that is represented by an asymmetric KMS key. The key owner (or an authorized user) uses their private key to sign a message. Anyone with the public key can verify that the message was signed with that particular private key and that the message hasn’t changed since it was signed.
To use the ‘Sign` operation, provide the following information:
-
Use the ‘KeyId` parameter to identify an asymmetric KMS key with a `KeyUsage` value of `SIGN_VERIFY`. To get the `KeyUsage` value of a KMS key, use the DescribeKey operation. The caller must have `kms:Sign` permission on the KMS key.
-
Use the ‘Message` parameter to specify the message or message digest to sign. You can submit messages of up to 4096 bytes. To sign a larger message, generate a hash digest of the message, and then provide the hash digest in the `Message` parameter. To indicate whether the message is a full message or a digest, use the `MessageType` parameter.
-
Choose a signing algorithm that is compatible with the KMS key.
When signing a message, be sure to record the KMS key and the signing algorithm. This information is required to verify the signature.
<note markdown=“1”> Best practices recommend that you limit the time during which any signature is effective. This deters an attack where the actor uses a signed message to establish validity repeatedly or long after the message is superseded. Signatures do not include a timestamp, but you can include a timestamp in the signed message to help you detect when its time to refresh the signature.
</note>
To verify the signature that this operation generates, use the Verify operation. Or use the GetPublicKey operation to download the public key and then use the public key to verify the signature outside of KMS.
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: Yes. To perform this operation with a KMS key in a different Amazon Web Services account, specify the key ARN or alias ARN in the value of the ‘KeyId` parameter.
**Required permissions**: [kms:Sign] (key policy)
**Related operations**: Verify
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: en.wikipedia.org/wiki/Digital_signature [2]: docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html [3]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [4]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [5]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
9434 9435 9436 9437 |
# File 'lib/aws-sdk-kms/client.rb', line 9434 def sign(params = {}, = {}) req = build_request(:sign, params) req.send_request() end |
#tag_resource(params = {}) ⇒ Struct
Adds or edits tags on a [customer managed key].
<note markdown=“1”> Tagging or untagging a KMS key can allow or deny permission to the KMS key. For details, see [ABAC for KMS] in the *Key Management Service Developer Guide*.
</note>
Each tag consists of a tag key and a tag value, both of which are case-sensitive strings. The tag value can be an empty (null) string. To add a tag, specify a new tag key and a tag value. To edit a tag, specify an existing tag key and a new tag value.
You can use this operation to tag a [customer managed key], but you cannot tag an [Amazon Web Services managed key], an [Amazon Web Services owned key], a [custom key store], or an [alias].
You can also add tags to a KMS key while creating it (CreateKey) or replicating it (ReplicateKey).
For information about using tags in KMS, see [Tagging keys]. For general information about tags, including the format and syntax, see
- Tagging Amazon Web Services resources][8
-
in the *Amazon Web Services
General Reference*.
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: No. You cannot perform this operation on a KMS key in a different Amazon Web Services account.
**Required permissions**: [kms:TagResource] (key policy)
**Related operations**
-
CreateKey
-
ListResourceTags
-
ReplicateKey
-
UntagResource
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk [2]: docs.aws.amazon.com/kms/latest/developerguide/abac.html [3]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk [4]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk [5]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#keystore-concept [6]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#alias-concept [7]: docs.aws.amazon.com/kms/latest/developerguide/tagging-keys.html [8]: docs.aws.amazon.com/general/latest/gr/aws_tagging.html [9]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [10]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [11]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
9560 9561 9562 9563 |
# File 'lib/aws-sdk-kms/client.rb', line 9560 def tag_resource(params = {}, = {}) req = build_request(:tag_resource, params) req.send_request() end |
#untag_resource(params = {}) ⇒ Struct
Deletes tags from a [customer managed key]. To delete a tag, specify the tag key and the KMS key.
<note markdown=“1”> Tagging or untagging a KMS key can allow or deny permission to the KMS key. For details, see [ABAC for KMS] in the *Key Management Service Developer Guide*.
</note>
When it succeeds, the ‘UntagResource` operation doesn’t return any output. Also, if the specified tag key isn’t found on the KMS key, it doesn’t throw an exception or return a response. To confirm that the operation worked, use the ListResourceTags operation.
For information about using tags in KMS, see [Tagging keys]. For general information about tags, including the format and syntax, see
- Tagging Amazon Web Services resources][4
-
in the *Amazon Web Services
General Reference*.
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: No. You cannot perform this operation on a KMS key in a different Amazon Web Services account.
**Required permissions**: [kms:UntagResource] (key policy)
**Related operations**
-
CreateKey
-
ListResourceTags
-
ReplicateKey
-
TagResource
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk [2]: docs.aws.amazon.com/kms/latest/developerguide/abac.html [3]: docs.aws.amazon.com/kms/latest/developerguide/tagging-keys.html [4]: docs.aws.amazon.com/general/latest/gr/aws_tagging.html [5]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [6]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [7]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
9660 9661 9662 9663 |
# File 'lib/aws-sdk-kms/client.rb', line 9660 def untag_resource(params = {}, = {}) req = build_request(:untag_resource, params) req.send_request() end |
#update_alias(params = {}) ⇒ Struct
Associates an existing KMS alias with a different KMS key. Each alias is associated with only one KMS key at a time, although a KMS key can have multiple aliases. The alias and the KMS key must be in the same Amazon Web Services account and Region.
<note markdown=“1”> Adding, deleting, or updating an alias can allow or deny permission to the KMS key. For details, see [ABAC for KMS] in the *Key Management Service Developer Guide*.
</note>
The current and new KMS key must be the same type (both symmetric or both asymmetric or both HMAC), and they must have the same key usage. This restriction prevents errors in code that uses aliases. If you must assign an alias to a different type of KMS key, use DeleteAlias to delete the old alias and CreateAlias to create a new alias.
You cannot use ‘UpdateAlias` to change an alias name. To change an alias name, use DeleteAlias to delete the old alias and CreateAlias to create a new alias.
Because an alias is not a property of a KMS key, you can create, update, and delete the aliases of a KMS key without affecting the KMS key. Also, aliases do not appear in the response from the DescribeKey operation. To get the aliases of all KMS keys in the account, use the ListAliases operation.
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: No. You cannot perform this operation on a KMS key in a different Amazon Web Services account.
**Required permissions**
- kms:UpdateAlias][3
-
on the alias (IAM policy).
- kms:UpdateAlias][3
-
on the current KMS key (key policy).
- kms:UpdateAlias][3
-
on the new KMS key (key policy).
For details, see [Controlling access to aliases] in the *Key Management Service Developer Guide*.
**Related operations:**
-
CreateAlias
-
DeleteAlias
-
ListAliases
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/abac.html [2]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [3]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [4]: docs.aws.amazon.com/kms/latest/developerguide/kms-alias.html#alias-access [5]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
9792 9793 9794 9795 |
# File 'lib/aws-sdk-kms/client.rb', line 9792 def update_alias(params = {}, = {}) req = build_request(:update_alias, params) req.send_request() end |
#update_custom_key_store(params = {}) ⇒ Struct
Changes the properties of a custom key store. You can use this operation to change the properties of an CloudHSM key store or an external key store.
Use the required ‘CustomKeyStoreId` parameter to identify the custom key store. Use the remaining optional parameters to change its properties. This operation does not return any property values. To verify the updated property values, use the DescribeCustomKeyStores operation.
This operation is part of the [custom key stores] feature in KMS, which combines the convenience and extensive integration of KMS with the isolation and control of a key store that you own and manage.
When updating the properties of an external key store, verify that the updated settings connect your key store, via the external key store proxy, to the same external key manager as the previous settings, or to a backup or snapshot of the external key manager with the same cryptographic keys. If the updated connection settings fail, you can fix them and retry, although an extended delay might disrupt Amazon Web Services services. However, if KMS permanently loses its access to cryptographic keys, ciphertext encrypted under those keys is unrecoverable.
<note markdown=“1”> For external key stores:
Some external key managers provide a simpler method for updating an
external key store. For details, see your external key manager documentation.
When updating an external key store in the KMS console, you can upload
a JSON-based proxy configuration file with the desired values. You cannot upload the proxy configuration file to the ‘UpdateCustomKeyStore` operation. However, you can use the file to help you determine the correct values for the `UpdateCustomKeyStore` parameters.
</note>
For an CloudHSM key store, you can use this operation to change the custom key store friendly name (‘NewCustomKeyStoreName`), to tell KMS about a change to the `kmsuser` crypto user password (`KeyStorePassword`), or to associate the custom key store with a different, but related, CloudHSM cluster (`CloudHsmClusterId`). To update any property of an CloudHSM key store, the `ConnectionState` of the CloudHSM key store must be `DISCONNECTED`.
For an external key store, you can use this operation to change the custom key store friendly name (‘NewCustomKeyStoreName`), or to tell KMS about a change to the external key store proxy authentication credentials (`XksProxyAuthenticationCredential`), connection method (`XksProxyConnectivity`), external proxy endpoint (`XksProxyUriEndpoint`) and path (`XksProxyUriPath`). For external key stores with an `XksProxyConnectivity` of `VPC_ENDPOINT_SERVICE`, you can also update the Amazon VPC endpoint service name (`XksProxyVpcEndpointServiceName`). To update most properties of an external key store, the `ConnectionState` of the external key store must be `DISCONNECTED`. However, you can update the `CustomKeyStoreName`, `XksProxyAuthenticationCredential`, and `XksProxyUriPath` of an external key store when it is in the CONNECTED or DISCONNECTED state.
If your update requires a ‘DISCONNECTED` state, before using `UpdateCustomKeyStore`, use the DisconnectCustomKeyStore operation to disconnect the custom key store. After the `UpdateCustomKeyStore` operation completes, use the ConnectCustomKeyStore to reconnect the custom key store. To find the `ConnectionState` of the custom key store, use the DescribeCustomKeyStores operation.
Before updating the custom key store, verify that the new values allow KMS to connect the custom key store to its backing key store. For example, before you change the ‘XksProxyUriPath` value, verify that the external key store proxy is reachable at the new path.
If the operation succeeds, it returns a JSON object with no properties.
**Cross-account use**: No. You cannot perform this operation on a custom key store in a different Amazon Web Services account.
**Required permissions**: [kms:UpdateCustomKeyStore] (IAM policy)
**Related operations:**
-
ConnectCustomKeyStore
-
CreateCustomKeyStore
-
DeleteCustomKeyStore
-
DescribeCustomKeyStores
-
DisconnectCustomKeyStore
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/custom-key-store-overview.html [2]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [3]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
10148 10149 10150 10151 |
# File 'lib/aws-sdk-kms/client.rb', line 10148 def update_custom_key_store(params = {}, = {}) req = build_request(:update_custom_key_store, params) req.send_request() end |
#update_key_description(params = {}) ⇒ Struct
Updates the description of a KMS key. To see the description of a KMS key, use DescribeKey.
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: No. You cannot perform this operation on a KMS key in a different Amazon Web Services account.
**Required permissions**: [kms:UpdateKeyDescription] (key policy)
**Related operations**
-
CreateKey
-
DescribeKey
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [2]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [3]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
10225 10226 10227 10228 |
# File 'lib/aws-sdk-kms/client.rb', line 10225 def update_key_description(params = {}, = {}) req = build_request(:update_key_description, params) req.send_request() end |
#update_primary_region(params = {}) ⇒ Struct
Changes the primary key of a multi-Region key.
This operation changes the replica key in the specified Region to a primary key and changes the former primary key to a replica key. For example, suppose you have a primary key in ‘us-east-1` and a replica key in `eu-west-2`. If you run `UpdatePrimaryRegion` with a `PrimaryRegion` value of `eu-west-2`, the primary key is now the key in `eu-west-2`, and the key in `us-east-1` becomes a replica key. For details, see [Updating the primary Region] in the *Key Management Service Developer Guide*.
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*.
The *primary key* of a multi-Region key is the source for properties that are always shared by primary and replica keys, including the key material, [key ID], [key spec], [key usage], [key material origin], and [automatic key rotation]. It’s the only key that can be replicated. You cannot [delete the primary key] until all replica keys are deleted.
The key ID and primary Region that you specify uniquely identify the replica key that will become the primary key. The primary Region must already have a replica key. This operation does not create a KMS key in the specified Region. To find the replica keys, use the DescribeKey operation on the primary key or any replica key. To create a replica key, use the ReplicateKey operation.
You can run this operation while using the affected multi-Region keys in cryptographic operations. This operation should not delay, interrupt, or cause failures in cryptographic operations.
Even after this operation completes, the process of updating the primary Region might still be in progress for a few more seconds. Operations such as ‘DescribeKey` might display both the old and new primary keys as replicas. The old and new primary keys have a transient key state of `Updating`. The original key state is restored when the update is complete. While the key state is `Updating`, you can use the keys in cryptographic operations, but you cannot replicate the new primary key or perform certain management operations, such as enabling or disabling these keys. For details about the `Updating` key state, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
This operation does not return any output. To verify that primary key is changed, use the DescribeKey operation.
**Cross-account use**: No. You cannot use this operation in a different Amazon Web Services account.
**Required permissions**:
-
‘kms:UpdatePrimaryRegion` on the current primary key (in the primary key’s Region). Include this permission primary key’s key policy.
-
‘kms:UpdatePrimaryRegion` on the current replica key (in the replica key’s Region). Include this permission in the replica key’s key policy.
**Related operations**
-
CreateKey
-
ReplicateKey
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-manage.html#multi-region-update [2]: docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html [3]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-id-key-id [4]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-spec [5]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-usage [6]: docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-origin [7]: docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html [8]: docs.aws.amazon.com/kms/latest/APIReference/API_ScheduleKeyDeletion.html [9]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [10]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
10369 10370 10371 10372 |
# File 'lib/aws-sdk-kms/client.rb', line 10369 def update_primary_region(params = {}, = {}) req = build_request(:update_primary_region, params) req.send_request() end |
#verify(params = {}) ⇒ Types::VerifyResponse
Verifies a digital signature that was generated by the Sign operation.
Verification confirms that an authorized user signed the message with the specified KMS key and signing algorithm, and the message hasn’t changed since it was signed. If the signature is verified, the value of the ‘SignatureValid` field in the response is `True`. If the signature verification fails, the `Verify` operation fails with an `KMSInvalidSignatureException` exception.
A digital signature is generated by using the private key in an asymmetric KMS key. The signature is verified by using the public key in the same asymmetric KMS key. For information about asymmetric KMS keys, see [Asymmetric KMS keys] in the *Key Management Service Developer Guide*.
To use the ‘Verify` operation, specify the same asymmetric KMS key, message, and signing algorithm that were used to produce the signature. The message type does not need to be the same as the one used for signing, but it must indicate whether the value of the `Message` parameter should be hashed as part of the verification process.
You can also verify the digital signature by using the public key of the KMS key outside of KMS. Use the GetPublicKey operation to download the public key in the asymmetric KMS key and then use the public key to verify the signature outside of KMS. The advantage of using the ‘Verify` operation is that it is performed within KMS. As a result, it’s easy to call, the operation is performed within the FIPS boundary, it is logged in CloudTrail, and you can use key policy and IAM policy to determine who is authorized to use the KMS key to verify signatures.
To verify a signature outside of KMS with an SM2 public key (China Regions only), you must specify the distinguishing ID. By default, KMS uses ‘1234567812345678` as the distinguishing ID. For more information, see [Offline verification with SM2 key pairs].
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: Yes. To perform this operation with a KMS key in a different Amazon Web Services account, specify the key ARN or alias ARN in the value of the ‘KeyId` parameter.
**Required permissions**: [kms:Verify] (key policy)
**Related operations**: Sign
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html [2]: docs.aws.amazon.com/kms/latest/developerguide/asymmetric-key-specs.html#key-spec-sm-offline-verification [3]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [4]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [5]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
10613 10614 10615 10616 |
# File 'lib/aws-sdk-kms/client.rb', line 10613 def verify(params = {}, = {}) req = build_request(:verify, params) req.send_request() end |
#verify_mac(params = {}) ⇒ Types::VerifyMacResponse
Verifies the hash-based message authentication code (HMAC) for a specified message, HMAC KMS key, and MAC algorithm. To verify the HMAC, ‘VerifyMac` computes an HMAC using the message, HMAC KMS key, and MAC algorithm that you specify, and compares the computed HMAC to the HMAC that you specify. If the HMACs are identical, the verification succeeds; otherwise, it fails. Verification indicates that the message hasn’t changed since the HMAC was calculated, and the specified key was used to generate and verify the HMAC.
HMAC KMS keys and the HMAC algorithms that KMS uses conform to industry standards defined in [RFC 2104].
This operation is part of KMS support for HMAC KMS keys. For details, see [HMAC keys in KMS] in the *Key Management Service Developer Guide*.
The KMS key that you use for this operation must be in a compatible key state. For details, see [Key states of KMS keys] in the *Key Management Service Developer Guide*.
**Cross-account use**: Yes. To perform this operation with a KMS key in a different Amazon Web Services account, specify the key ARN or alias ARN in the value of the ‘KeyId` parameter.
**Required permissions**: [kms:VerifyMac] (key policy)
**Related operations**: GenerateMac
**Eventual consistency**: The KMS API follows an eventual consistency model. For more information, see [KMS eventual consistency].
[1]: datatracker.ietf.org/doc/html/rfc2104 [2]: docs.aws.amazon.com/kms/latest/developerguide/hmac.html [3]: docs.aws.amazon.com/kms/latest/developerguide/key-state.html [4]: docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html [5]: docs.aws.amazon.com/kms/latest/developerguide/programming-eventual-consistency.html
10753 10754 10755 10756 |
# File 'lib/aws-sdk-kms/client.rb', line 10753 def verify_mac(params = {}, = {}) req = build_request(:verify_mac, params) req.send_request() end |
#waiter_names ⇒ Object
This method is part of a private API. You should avoid using this method if possible, as it may be removed or be changed in the future.
10782 10783 10784 |
# File 'lib/aws-sdk-kms/client.rb', line 10782 def waiter_names [] end |