# 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](https://csrc.nist.gov/pubs/fips/203/final) on the NIST website. Amazon KMS now supports a hybrid post-quantum key exchange option for TLS which combines [Elliptic Curve Diffie-Hellman](https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman) (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](https://amazonaws-china.com/blogs/security/ml-kem-post-quantum-tls-now-supported-in-aws-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](https://docs.amazonaws.cn/general/latest/gr/kms.html). For a list of Amazon KMS endpoints for each Amazon Web Services Region, see [Amazon Key Management Service endpoints and quotas](https://docs.amazonaws.cn/general/latest/gr/kms.html) in the *Amazon Web Services General Reference*. For information about FIPS endpoints, see [FIPS endpoints](https://docs.amazonaws.cn/general/latest/gr/rande.html#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](https://docs.amazonaws.cn/sdkref/latest/guide/pqtls-details.html) in the *Amazon SDKs and Tools Reference Guide*. For a Java example, see [Configure hybrid post-quantum TLS](pqtls-how-to.md). ### 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](ct-decrypt.md#ct-decrypt-default-pqtls). **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](https://docs.amazonaws.cn/awscloudtrail/latest/userguide/cloudtrail-event-reference-record-contents.html) 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](https://docs.amazonaws.cn/AmazonCloudWatch/latest/logs/MonitoringLogData.html) 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](https://docs.amazonaws.cn/awscloudtrail/latest/userguide/send-cloudtrail-events-to-cloudwatch-logs.html) in the Amazon CloudTrail User Guide. 1. 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](https://docs.amazonaws.cn/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html) in the Amazon CloudWatch Logs User Guide. Use the following required values. For other fields, accept the default values and provide names as requested.
FieldValue
Filter pattern{ ($.eventSource = "kms.amazonaws.com") && ($.userIdentity.invokedBy NOT EXISTS) && (($.tlsDetails.keyExchange != "*MLKEM*") || ($.tlsDetails.keyExchange NOT EXISTS)) }
Metric value1
1. 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](https://docs.amazonaws.cn/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html) in the Amazon CloudWatch User Guide. Use the following required values. For other fields, accept the default values and provide names as requested.
FieldValue
Metric filterThe name of the metric filter that you created in Step 2.
Threshold typeStatic
ConditionsWhenever {{metric-name}} is Greater/Equal than 1
Data points to alarm1 out of 1
Missing data treatmentTreat 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](https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.2) 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](https://www.etsi.org/images/files/ETSIWhitePapers/QuantumSafeWhitepaper.pdf) 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. + To learn about post-quantum cryptography at Amazon, including links to blog posts and research papers, see [Post-Quantum Cryptography](https://aws.amazon.com/security/post-quantum-cryptography/). + Amazon KMS uses s2n-tls, the open source TLS implementation from Amazon, for the server side of its hybrid post-quantum TLS connections. For information about s2n-tls, see [Introducing s2n-tls, a New Open Source TLS Implementation](https://amazonaws-china.com/blogs/security/introducing-s2n-a-new-open-source-tls-implementation/) and [Using s2n-tls](https://github.com/aws/s2n-tls/tree/main/docs/usage-guide) on GitHub. + For information about the Amazon Common Runtime HTTP Client, see [Configuring the Amazon CRT-based HTTP client](https://docs.amazonaws.cn/sdk-for-java/latest/developer-guide/http-configuration-crt.html) in the *Amazon SDK for Java 2.x Developer Guide*. + For information about the post-quantum cryptography project at the National Institute for Standards and Technology (NIST), see [Post-Quantum Cryptography](https://csrc.nist.gov/Projects/Post-Quantum-Cryptography). + For information about NIST post-quantum cryptography standardization, see [Post-Quantum Cryptography Standardization](https://csrc.nist.gov/Projects/post-quantum-cryptography/post-quantum-cryptography-standardization).