Key Management Service:Overview of asymmetric keys

Supported key types

KMS supports RSA, Elliptic Curve Cryptography (ECC), and SM2 asymmetric key algorithms. Each algorithm supports a fixed set of operations — choose based on your use case.

ECC keys (EC_P256, EC_P256K) support signing and verification only. They cannot be used for encryption or decryption.

Data encryption

Asymmetric encryption protects sensitive data in transit between parties that cannot share a secret key in advance. The typical flow:

1. An information receiver distributes a public key to a transmitter.

2. The transmitter uses the public key to encrypt sensitive information.

3. The transmitter sends the ciphertext to the information receiver.

4. The information receiver calls AsymmetricDecrypt to decrypt the ciphertext using the private key.

The private key can be used only by the information receiver. This ensures that the plaintext of sensitive information cannot be intercepted and decrypted by unauthorized parties during transmission.

Common scenarios include exchanging session keys in TLS handshakes and importing encryption keys between hardware security modules (HSMs).

For a step-by-step implementation, see Encrypt and decrypt data by using an asymmetric CMK.

Digital signatures

Private keys sign data; public keys verify signatures. Because only the private key holder can produce a valid signature, digital signatures provide three guarantees:

• Integrity: If the data was modified after signing, verification fails.

• Authenticity: A valid signature confirms the signer holds the private key.

• Non-repudiation: The signer cannot deny producing a signature that matches the data.

The typical signing flow:

1. The signer calls AsymmetricSign in KMS to sign the data using the private key.

2. The signer distributes the public key (via GetPublicKey) and sends the data and signature to the receiver.

3. The receiver uses the public key with AsymmetricVerify (or a local cryptographic library) to verify the signature.

Use case — code signing: Sign binary artifacts before distribution. Consumers verify the signature to confirm the code has not been tampered with.

Use case — certificate-based identity: A CA signs a digital certificate to bind a public key to an entity's identity. The certificate contains the entity's public key, key purpose, expiration date, and issuer. Receivers verify the certificate using the CA's public key, then use the entity's public key to verify message signatures.

For a step-by-step implementation, see Generate and verify a digital signature by using an asymmetric CMK.

Key versioning

KMS does not support automatic key rotation for asymmetric CMKs. Because the public key is distributed externally, rotating the key pair requires redistributing the new public key to all parties that use it.

To create a new key pair within an existing CMK, call CreateKeyVersion. This generates a new version with a new public/private key pair. After creating a new version, distribute the new public key to all parties before using the new version for signing or encryption.

Unlike symmetric CMKs, asymmetric CMKs have no primary key version. All API calls for asymmetric CMK operations must specify both the CMK ID (or alias) and the key version ID.

API operations

KMS separates public key operations from private key operations.

Public key operations — can be called by any authorized party:

Private key operations — performed exclusively within KMS:

For public key operations, calling GetPublicKey and using a local library (OpenSSL, JCE) avoids per-call logging and RAM enforcement. Use AsymmetricEncrypt or AsymmetricVerify directly when you need call-level audit logs or fine-grained access control via RAM.

What's next

• Encrypt and decrypt data by using an asymmetric CMK

• Generate and verify a digital signature by using an asymmetric CMK

• CreateKeyVersion API reference

• GetPublicKey API reference