Tác giả: Alex Weibel 

Ngày đăng: 07 Tháng 4 2025 

Danh mục:  Announcements, AWS Certificate Manager, AWS Key Management Service, AWS Secrets Manager, Intermediate (200), Security, Identity, & Compliance

Amazon Web Services (AWS) rất vui thông báo rằng các tiêu chuẩn thỏa thuận khóa lai post-quantum mới nhất cho TLS đã được triển khai trên ba dịch vụ của AWS. Hiện nay, các endpoint của AWS Key Management Service (AWS KMS), AWS Certificate Manager (ACM), và AWS Secrets Manager đã hỗ trợ Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) cho thỏa thuận khóa lai post-quantum trên các endpoint không thuộc FIPS ở tất cả các vùng AWS trong partition “aws”. Agent của AWS Secrets Manager, được xây dựng dựa trên AWS SDK for Rust, hiện cũng hỗ trợ tùy chọn (opt-in) cho thỏa thuận khóa lai post-quantum. Với điều này, khách hàng có thể đưa secrets vào ứng dụng của họ thông qua TLS được kích hoạt post-quantum ở hai đầu.

Ba dịch vụ này được chọn vì chúng là các dịch vụ quan trọng về bảo mật của AWS, có nhu cầu cấp thiết nhất về bảo mật dữ liệu trong môi trường post-quantum. Trước đây, ba dịch vụ này đã triển khai hỗ trợ cho CRYSTALS-Kyber, tiền thân của ML-KEM. Việc hỗ trợ CRYSTALS-Kyber sẽ tiếp tục đến hết năm 2025, nhưng sẽ bị loại bỏ trên tất cả các endpoint dịch vụ AWS vào năm 2026 để chuyển hoàn toàn sang ML-KEM.

Quá trình chuyển đổi của chúng tôi sang mật mã học post-quantum

AWS cam kết thực hiện kế hoạch chuyển đổi sang mật mã học post-quantum. Là một phần của cam kết này, và cũng là một phần trong mô hình trách nhiệm chia sẻ post-quantum của AWS, AWS dự định triển khai hỗ trợ ML-KEM cho tất cả các dịch vụ AWS có endpoint HTTPS trong những năm tới. Khách hàng AWS cần cập nhật client TLS và SDK của họ để hỗ trợ ML-KEM khi kết nối đến các endpoint HTTPS của dịch vụ AWS. Điều này giúp bảo vệ khỏi các mối đe dọa “thu thập dữ liệu bây giờ, giải mã sau” có thể xảy ra do sự phát triển của máy tính lượng tử. Trong khi đó, các endpoint HTTPS của dịch vụ AWS sẽ chịu trách nhiệm chọn sử dụng ML-KEM khi client cung cấp hỗ trợ.

Cam kết của AWS trong việc đàm phán các thuật toán thỏa thuận khóa lai post-quantum được hỗ trợ bởi AWS Libcrypto (AWS-LC) — thư viện mật mã nguồn mở đạt chứng nhận FIPS 140-3, được sử dụng rộng rãi trong hệ thống AWS — và s2n-tls, triển khai TLS nguồn mở được dùng trong các endpoint HTTPS của dịch vụ AWS. AWS-LC đã được cấp nhiều chứng chỉ FIPS từ NIST (#4631, #4759, và #4816), và là mô-đun mật mã nguồn mở đầu tiên bao gồm ML-KEM trong quá trình chứng nhận FIPS 140-3.

Ảnh hưởng của ML-KEM lai post-quantum đối với hiệu năng TLS

Việc chuyển từ thỏa thuận khóa chỉ dùng Elliptic Curve Diffie-Hellman (ECDH) sang thỏa thuận khóa lai ECDH+ML-KEM đòi hỏi quá trình bắt tay TLS phải truyền thêm dữ liệu và thực hiện nhiều phép toán mật mã hơn. Khi chuyển từ thỏa thuận khóa cổ điển sang thỏa thuận khóa lai post-quantum, sẽ có khoảng 1.600 byte bổ sung được truyền trong quá trình bắt tay TLS và cần thêm khoảng 80–150 micro giây thời gian tính toán để thực hiện các phép toán mật mã ML-KEM. Đây là chi phí khởi tạo TLS chỉ xảy ra một lần và sẽ được phân bổ dần trong suốt thời gian tồn tại của kết nối TLS đối với các yêu cầu HTTP được gửi qua kết nối đó.

AWS đang nỗ lực cung cấp quá trình chuyển đổi mượt mà sang thỏa thuận khóa lai post-quantum cho TLS. Công việc này bao gồm thực hiện các bài kiểm thử hiệu năng trên các khối lượng công việc mẫu nhằm giúp khách hàng hiểu rõ tác động của việc bật thỏa thuận khóa lai post-quantum với ML-KEM.

Sử dụng AWS SDK for Java v2, AWS đã đo lường số lượng yêu cầu AWS KMS GenerateDataKey mỗi giây mà một luồng đơn có thể gửi tuần tự giữa client Amazon EC2 C6in.metal và endpoint công khai của AWS KMS, cả hai đều đặt tại vùng us-west-2. Các kết nối TLS cổ điển với AWS KMS đã đàm phán (negotiated) sử dụng đường cong elliptic P256 cho thỏa thuận khóa, trong khi các kết nối TLS lai post-quantum đã đàm phán sử dụng đường cong X25519 kết hợp với ML-KEM-768 cho thỏa thuận khóa lai.

Hiệu năng thực tế của bạn có thể khác và phụ thuộc vào môi trường của bạn, bao gồm loại instance, đặc điểm khối lượng công việc, mức độ song song và số lượng luồng sử dụng, cũng như vị trí và băng thông mạng. Tốc độ xử lý giao dịch HTTP được đo với cả hai trường hợp: bật và tắt tái sử dụng kết nối TLS.

Hình 1 cho thấy số lượng yêu cầu mỗi giây được thực hiện ở các phân vị khác nhau khi tái sử dụng kết nối TLS 1.3 bị tắt. Trong kịch bản xấu nhất — khi chi phí của mỗi lần bắt tay TLS không được phân bổ và mọi yêu cầu HTTP đều phải thực hiện đầy đủ quá trình bắt tay TLS — việc bật TLS lai post-quantum làm giảm số giao dịch mỗi giây (TPS) trung bình khoảng 2,3%, từ 108,7 TPS xuống còn 106,2 TPS.

Hình 1: Số lượng yêu cầu AWS KMS GenerateDataKey mỗi giây khi không tái sử dụng kết nối TLS.

Hình 2 cho thấy số lượng yêu cầu mỗi giây ở các phân vị khác nhau khi tái sử dụng kết nối TLS được bật. Việc tái sử dụng kết nối TLS và phân bổ chi phí bắt tay TLS qua nhiều yêu cầu HTTP là thiết lập mặc định trong AWS SDK for Java v2. Kết quả cho thấy việc bật TLS lai post-quantum khi sử dụng cấu hình SDK mặc định hầu như không ảnh hưởng đến tốc độ TPS, chỉ giảm trung bình 0,05%, từ 216,1 TPS xuống 216,0 TPS.

Hình 2: Số lượng yêu cầu AWS KMS GenerateDataKey mỗi giây khi có tái sử dụng kết nối TLS.

Kết quả cho thấy tác động hiệu năng của việc bật TLS lai post-quantum là không đáng kể khi sử dụng cấu hình SDK thông thường. Các phép đo cho thấy việc bật TLS lai post-quantum trong khối lượng công việc mặc định chỉ làm giảm tốc độ TPS tối đa 0,05%. Ngoài ra, khi ghi đè cấu hình SDK mặc định để buộc chạy trong kịch bản xấu nhất — thực hiện bắt tay TLS mới cho mỗi yêu cầu — tốc độ TPS tối đa chỉ giảm 2,3%.

Bảng sau hiển thị dữ liệu kiểm thử hiệu năng mà AWS đã đo được. Mỗi bài kiểm thử thực hiện 500 phép đo TPS trong 1 giây, với các cấu hình khác nhau về thỏa thuận khóa TLS và tùy chọn tái sử dụng kết nối TLS. Các phép đo được thực hiện bằng AWS SDK for Java v2, phiên bản 2.30.22.

Thỏa thuận khóa TLS được chuyển đổi giữa cổ điển và lai post-quantum bằng cách bật hoặc tắt cấu hình postQuantumTlsEnabled(). Việc tái sử dụng kết nối TLS được bật hoặc tắt bằng cách chèn HTTP header Connection: close vào mỗi yêu cầu HTTP — header này buộc kết nối TLS đóng sau mỗi yêu cầu, khiến mỗi yêu cầu phải tạo kết nối TLS mới.

Thỏa thuận khóa TLS	Tái sử dụng kết nối TLS	Tổng số yêu cầu HTTP	Trung bình (TPS)	p01 (TPS)	p10 (TPS)	p25 (TPS)	p50 (TPS)	p75 (TPS)	p90 (TPS)	p99 (TPS)
Cổ điển (P256)	Không	54,367	108,7	78	86	96	102	129	137	145
Lai post-quantum (X25519MLKEM768)	Không	53,106	106,2	76	85	93	100	126	134	141
Cổ điển (P256)	Có	108,052	216,1	181	194	200	216	233	240	245
Lai post-quantum (X25519MLKEM768)	Có	107,994	216,0	177	194	200	216	233	239	245

Loại bỏ hỗ trợ cho các tiêu chuẩn post-quantum dự thảo (draft)

Các endpoint dịch vụ AWS hiện đang hỗ trợ CRYSTALS-Kyber — tiền thân của ML-KEM — sẽ tiếp tục hỗ trợ CRYSTALS-Kyber đến hết năm 2025. Sau khi khách hàng đã chuyển sang tiêu chuẩn ML-KEM, AWS sẽ dần loại bỏ hỗ trợ cho các triển khai CRYSTALS-Kyber tiền tiêu chuẩn.

Khách hàng đang sử dụng phiên bản cũ của AWS SDK for Java có hỗ trợ CRYSTALS-Kyber nên nâng cấp lên phiên bản SDK mới nhất có hỗ trợ ML-KEM. Việc nâng cấp từ CRYSTALS-Kyber sang ML-KEM không cần thay đổi mã nguồn nếu đang sử dụng bản phát hành AWS SDK for Java v2 được cung cấp công khai.

Những khách hàng hiện đang sử dụng CRYSTALS-Kyber mà không nâng cấp SDK Java v2 trước năm 2026 sẽ thấy client của họ tự động quay lại sử dụng thỏa thuận khóa cổ điển khi CRYSTALS-Kyber bị loại bỏ khỏi các endpoint HTTPS của dịch vụ AWS.

Cách sử dụng thỏa thuận khóa lai post-quantum

Nếu bạn sử dụng AWS SDK for Rust, có thể bật thỏa thuận khóa lai post-quantum bằng cách thêm gói rustls vào crate của bạn và bật cờ tính năng prefer-post-quantum. Tham khảo tài liệu của rustls để biết thêm chi tiết.
Nếu bạn sử dụng AWS SDK for Java 2.x, có thể bật thỏa thuận khóa lai post-quantum bằng cách gọi .postQuantumTlsEnabled(true) khi khởi tạo AWS Common Runtime HTTP client.

Bước 1: Thêm AWS Common Runtime HTTP client vào dependency của Java

Thêm AWS Common Runtime HTTP client vào phần Maven dependencies của bạn. Nên sử dụng phiên bản mới nhất hiện có. Cần dùng phiên bản 2.30.22 trở lên để có thể kích hoạt ML-KEM.

dependency>

    <groupId>software.amazon.awssdk</groupId>

    <artifactId>aws-crt-client</artifactId>

   <version>2.30.22</version>

</dependency>

Bước 2: Bật post-quantum TLS trong cấu hình client của Java SDK

Khi cấu hình client cho dịch vụ AWS, hãy sử dụng AwsCrtAsyncHttpClient được thiết lập với post-quantum TLS.

Java

// Cấu hình AWS Common Runtime HTTP client với Post-Quantum TLS được bật

SdkAsyncHttpClient awsCrtHttpClient = AwsCrtAsyncHttpClient.builder()

          .postQuantumTlsEnabled(true)

          .build();

// Tạo một client dịch vụ AWS sử dụng AWS Common Runtime client

KmsAsyncClient kmsAsync = KmsAsyncClient.builder()

         .httpClient(awsCrtHttpClient)

         .build();

// Thực hiện một yêu cầu qua kết nối TLS sử dụng thỏa thuận khóa post-quantum

ListKeysReponse keys = kmsAsync.listKeys().get();

Xem ứng dụng ví dụ KMS PQ TLS để tham khảo cấu hình TLS post-quantum từ đầu đến cuối.

Những điều nên thử

Dưới đây là một số ý tưởng về cách sử dụng client có hỗ trợ post-quantum này:

• Chạy load tests và benchmark. AwsCrtAsyncHttpClient được tối ưu mạnh mẽ cho hiệu năng và sử dụng AWS Libcrypto trên các môi trường dựa trên Linux. Nếu bạn chưa sử dụng AwsCrtAsyncHttpClient, hãy thử ngay để so sánh lợi ích hiệu năng với HTTP client mặc định của SDK. Sau khi sử dụng AwsCrtAsyncHttpClient, hãy bật hỗ trợ post-quantum TLS. So sánh xem việc dùng AwsCrtAsyncHttpClient với post-quantum TLS có mang lại hiệu năng tổng thể tốt hơn so với việc sử dụng HTTP client mặc định của SDK mà không bật post-quantum TLS hay không.
  
• Thử kết nối từ các vị trí mạng khác nhau. Tùy thuộc vào tuyến mạng mà yêu cầu của bạn đi qua, bạn có thể phát hiện rằng một số máy trung gian, proxy hoặc tường lửa có deep packet inspection (DPI) có thể chặn yêu cầu. Nếu gặp trường hợp này, bạn có thể cần phối hợp với nhóm bảo mật hoặc quản trị IT để cập nhật tường lửa, cho phép các thuật toán TLS mới này. AWS mong muốn nhận phản hồi từ bạn về cách hạ tầng của bạn tương tác với biến thể mới của lưu lượng TLS này.

Kết luận

Hỗ trợ cho thỏa thuận khóa lai dựa trên ML-KEM đã được triển khai trên ba endpoint dịch vụ AWS quan trọng về bảo mật. Ảnh hưởng hiệu năng của việc bật TLS lai post-quantum hầu như không đáng kể khi tái sử dụng kết nối TLS được bật. Các phép đo của AWS chỉ ra rằng hiệu năng tối đa (TPS) chỉ giảm 0,05% khi gọi AWS KMS GenerateDataKey.

Bắt đầu từ phiên bản 2.30.22, AWS SDK for Java v2 hiện hỗ trợ thỏa thuận khóa lai dựa trên ML-KEM trên các nền tảng Linux khi sử dụng AWS Common Runtime HTTP client. Bạn có thể bật thỏa thuận khóa post-quantum cho TLS trong cấu hình client Java SDK của mình ngay hôm nay.

AWS có kế hoạch triển khai hỗ trợ ML-KEM cho tất cả các endpoint HTTPS của dịch vụ AWS trong những năm tới như một phần của kế hoạch chuyển đổi sang mật mã học post-quantum. Khách hàng AWS sẽ cần cập nhật client TLS và SDK để đảm bảo thỏa thuận khóa ML-KEM được sử dụng khi kết nối đến các endpoint HTTPS của dịch vụ AWS. Điều này giúp bảo vệ khỏi các mối đe dọa “thu thập bây giờ, giải mã sau” do sự phát triển của máy tính lượng tử.

Để biết thêm thông tin, bài viết và cập nhật định kỳ về quá trình chuyển đổi sang mật mã học post-quantum, hãy theo dõi trang AWS Post-Quantum Cryptography. Để tìm hiểu thêm, liên hệ với nhóm mật mã học post-quantum của AWS.

Nếu bạn có phản hồi về bài viết này, hãy để lại bình luận bên dưới. Nếu có câu hỏi, hãy tạo chủ đề mới trong AWS Security, Identity & Compliance re:Post hoặc liên hệ AWS Support.

Tài nguyên bổ sung:

• Mật mã hậu lượng tử của AWS
• Kế hoạch di chuyển mật mã hậu lượng tử của AWS
• Tuân thủ và bảo mật của khách hàng trong quá trình di chuyển sang mật mã hậu lượng tử
• AWS-LC FIPS 3.0: Thư viện mật mã đầu tiên bao gồm ML-KEM trong chứng nhận FIPS 140-3
• Tác động của TLS 1.3 hậu lượng tử có khối lượng dữ liệu lớn đến thời gian truyền byte cuối cùng (Time-To-Last-Byte) trong các kết nối thực tế
• Hội thảo AWS: Sử dụng mật mã hậu lượng tử trên AWS
• NIST FIPS 203, Tiêu chuẩn Cơ chế Bao bọc Khóa dựa trên Mạng Lưới Mô-đun (ML-KEM)

Nếu bạn có phản hồi về bài viết này, vui lòng gửi bình luận trong phần Bình luận bên dưới.

Alex Weibel

Alex là Kỹ sư Phát triển Phần mềm Cao cấp tại AWS Cryptography. Anh đóng góp vào Amazon TLS Library s2n-tls, Amazon Corretto Crypto Provider (ACCP) và AWS Libcrypto (AWS-LC). Trước đây, Alex làm việc về chấm dứt TLS (TLS termination) và proxy cho yêu cầu HTTP (HTTP request proxying) cho Amazon S3 và Elastic Load Balancing, phát triển các tính năng mới cho khách hàng. Alex tốt nghiệp Cử nhân Khoa học Máy tính tại Đại học Texas ở Austin.