View a markdown version of this page

Using hybrid post-quantum TLS with Amazon KMS - Amazon Key Management Service
How to use itLearn more
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Using hybrid post-quantum TLS with Amazon KMS

The data that you send to Amazon Key Management Service (Amazon KMS) is protected in transit by the encryption provided by a Transport Layer Security (TLS) connection. The classic cipher suites that Amazon KMS supports for TLS sessions make brute force attacks on the key exchange mechanisms infeasible with current technology. However, if large-scale quantum computing becomes practical, the classic cipher suites used in TLS key exchange mechanisms will be susceptible to these attacks.

In August 2024, NIST finalized its first post-quantum cryptography standards. These include Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) specified in FIPS 203 on the NIST website. Amazon KMS now supports a hybrid post-quantum key exchange option for TLS which combines Elliptic Curve Diffie-Hellman (ECDH) with ML-KEM. This hybrid key exchange retains the strength of today's classic cipher suites while adding resilience against future quantum-capable adversaries. For more information, see ML-KEM post-quantum TLS now supported in Amazon KMS, ACM, and Secrets Manager in the Amazon Security Blog.

If your applications rely on the long-term confidentiality of data passed over a TLS connection, you should use post-quantum cryptography. Otherwise, an adversary might be able to capture data encrypted with classic cipher suites today and decrypt it once quantum computers become available. This threat is known as harvest now, decrypt later.

Using hybrid post-quantum TLS with Amazon KMS

You can use hybrid post-quantum TLS for all your API calls to Amazon KMS. When setting up your HTTP client, be aware of the following information.

Amazon KMS Endpoints

Amazon KMS supports hybrid post-quantum TLS in all Amazon Web Services Regions where it is available, on all endpoints including FIPS 140-3 validated endpoints. For a list of Amazon KMS endpoints for each Amazon Web Services Region, see Amazon Key Management Service endpoints and quotas in the Amazon Web Services General Reference. For information about FIPS endpoints, see FIPS endpoints in the Amazon Web Services General Reference.

Supported Systems

Many Amazon SDKs support hybrid post-quantum TLS, as described in Enabling hybrid post-quantum TLS in the Amazon SDKs and Tools Reference Guide. For a Java example, see Configure hybrid post-quantum TLS.

Verifying and Monitoring Hybrid Post-Quantum TLS

You can confirm that a specific Amazon KMS API call used hybrid post-quantum TLS by inspecting its CloudTrail log entry. Find the tlsDetails section in the log entry for the call. The keyExchange field names the key exchange algorithm that was used. For a hybrid post-quantum connection, this field shows a hybrid algorithm such as X25519MLKEM768. For an example log entry, see Decrypt with a standard symmetric encryption key over a post-quantum TLS connection.

Note

The tlsDetails field is not present in the log entry when an Amazon service calls Amazon KMS on your behalf. In that case, the invokedBy field in the userIdentity element identifies the calling service. For details about the fields in a CloudTrail log entry and when they are present, see CloudTrail record contents in the Amazon CloudTrail User Guide.

To be alerted when a client calls Amazon KMS without hybrid post-quantum TLS, create a CloudWatch metric filter and alarm. The metric filter finds calls where the keyExchange field is missing or its value does not contain MLKEM. It ignores calls that an Amazon service makes on your behalf. Otherwise, they would appear as calls made without post-quantum TLS. For information about log group metric filters, see Creating metrics from log events using filters in the Amazon CloudWatch Logs User Guide.

To create the metric filter and alarm, complete the following steps.

  1. Send your CloudTrail events to Amazon CloudWatch Logs. For instructions, see Sending events to CloudWatch Logs in the Amazon CloudTrail User Guide.

  2. Create a CloudWatch metric filter that parses CloudTrail logs. For instructions on creating this metric filter, see Create a metric filter for a log group in the Amazon CloudWatch Logs User Guide. Use the following required values. For other fields, accept the default values and provide names as requested.

    Field Value
    Filter pattern

    { ($.eventSource = "kms.amazonaws.com") && ($.userIdentity.invokedBy NOT EXISTS) && (($.tlsDetails.keyExchange != "*MLKEM*") || ($.tlsDetails.keyExchange NOT EXISTS)) }
    Metric value 1

  3. Create a CloudWatch alarm based on the metric filter that you created in Step 2.

    For instructions on creating this alarm, see Alarming on logs in the Amazon CloudWatch User Guide. Use the following required values. For other fields, accept the default values and provide names as requested.

    Field Value
    Metric filter

    The name of the metric filter that you created in Step 2.
    Threshold type Static
    Conditions Whenever metric-name is Greater/Equal than 1
    Data points to alarm 1 out of 1
    Missing data treatment Treat missing data as good (not breaching threshold)
Note

This alarm helps you find clients that call Amazon KMS without hybrid post-quantum TLS. However, it doesn't identify the specific data that a misconfigured client might have exposed to the harvest now, decrypt later threat described earlier. CloudTrail log entries don't include sensitive values, such as the plaintext data key in the GenerateDataKey API response or the shared secret returned by Encapsulate and Decapsulate. To determine what might be affected, review other details in the log entry. These include the caller, the request time, the KMS key ID, and the encryption context. Then match those details against your application's own records.

Performance

Hybrid key exchange slightly increases the size and processing time of some TLS handshake messages, but the overall performance impact is imperceptible for most workloads. Because these messages are larger, we recommend that you test your Amazon KMS API calls from different locations on your network.

Depending on the network path your request takes, legacy intermediate hosts, proxies, or firewalls with deep packet inspection (DPI) might block the request. This can result from the new key exchange groups in the ClientHello part of the TLS handshake, or from the larger key exchange messages. If you have trouble resolving these issues, work with your security team or IT administrators to unblock the new TLS key exchange groups.

Encryption in Transit

The hybrid cipher suites are used only for encryption in transit. They protect your data while it is traveling from your client to the Amazon KMS endpoint. Amazon KMS does not use these cipher suites to encrypt data under Amazon KMS keys.

Instead, when Amazon KMS encrypts your data under KMS keys, it uses symmetric cryptography with 256-bit keys and the Advanced Encryption Standard in Galois Counter Mode (AES-GCM) algorithm, which is already quantum resistant. Theoretical future, large-scale quantum computing attacks on ciphertexts created under 256-bit AES-GCM keys reduce the effective security of the key to 128 bits. For more information, see the Quantum Safe Cryptography and Security paper on the ETSI website. This security level is sufficient to make brute force attacks on Amazon KMS ciphertexts infeasible.

Learn more about post-quantum TLS in Amazon KMS

For more information about using hybrid post-quantum TLS in Amazon KMS, see the following resources.