Mật mã kháng lượng tử (PQC, Post-Quantum Cryptography) và chiến lược chuyển đổi mật mã

1. Tổng quan

Định nghĩa: Mật mã kháng lượng tử (PQC) là công nghệ mật mã được thiết kế để duy trì tính bí mật, tính toàn vẹn và xác thực ngay cả khi máy tính lượng tử đủ lớn xuất hiện, bằng cách thay thế các bài toán cốt lõi của mật mã khóa công khai hiện có bằng những bài toán toán học có khả năng kháng lượng tử.

Các hệ mật RSA, Diffie–Hellman và mật mã đường cong elliptic hiện nay dựa vào độ khó tính toán của bài toán phân tích số nguyên và logarit rời rạc để bảo đảm an toàn. Trên máy tính cổ điển, giải các bài toán này với khóa lớn cần thời gian rất dài, vì vậy chúng được sử dụng rộng rãi trong trao đổi khóa, chữ ký số và hệ thống chứng chỉ của Internet. Tuy nhiên, khi máy tính lượng tử phá mã (CRQC) có khả năng chạy thuật toán Shor trở thành hiện thực, giả định an toàn của các hệ khóa công khai này sẽ bị suy yếu tận gốc.

Mật mã khóa đối xứng và hàm băm cũng chịu ảnh hưởng của tấn công lượng tử, nhưng tính chất ảnh hưởng khác với mật mã khóa công khai. Thuật toán Grover giảm độ phức tạp tìm kiếm của khóa đối xứng và hàm băm xuống khoảng mức căn bậc hai, nên vẫn có dư địa giảm thiểu bằng cách tăng độ dài khóa hoặc độ dài đầu ra. Ngược lại, thuật toán Shor mở ra khả năng giải hiệu quả các bài toán nền tảng của RSA, DH, ECC, nên chỉ tăng độ dài khóa một chút là không đủ.

Chuyển đổi sang PQC không phải là một dự án mã hóa đơn giản chỉ chọn một thuật toán mới rồi thay thế. Cần khảo sát đồng thời chứng chỉ, quản lý khóa, TLS/VPN/SSH, ký mã (code signing), cập nhật firmware, kết nối cơ sở dữ liệu, thư viện mật mã của thiết bị và sự phụ thuộc vào nhà cung cấp. Đặc biệt, mối đe dọa "thu thập trước, giải mã sau (HNDL, Harvest Now, Decrypt Later)" — thu thập bản mã ngay bây giờ để giải mã trong tương lai — là lý do các tổ chức có dữ liệu cần giữ bí mật lâu dài phải chuẩn bị ngay từ bây giờ.

Viện Tiêu chuẩn và Công nghệ Quốc gia Hoa Kỳ (NIST) đã phê duyệt chính thức FIPS 203, 204, 205 vào năm 2024, đưa ra ba trụ cột đầu tiên của tiêu chuẩn PQC. FIPS 203 quy định cơ chế đóng gói khóa ML-KEM, FIPS 204 quy định chữ ký số đa dụng ML-DSA, và FIPS 205 quy định chữ ký số dựa trên hàm băm SLH-DSA. Trong bài làm của Kỹ sư chuyên nghiệp (Professional Engineer), không dừng lại ở việc ghi nhớ tên thuật toán mà phải giải thích được quản trị và kiến trúc đi từ phân tích rủi ro của mật mã hiện tại đến lập danh mục tài sản mật mã, ưu tiên hóa, thử nghiệm và chuyển đổi theo từng giai đoạn.

2. Mối đe dọa lượng tử và sự cần thiết phải chuyển đổi

2.1 Ảnh hưởng của thuật toán lượng tử đối với mật mã hiện có

RSA dựa trên độ khó tính toán của bài toán phân tích số nguyên lớn thành thừa số nguyên tố, còn DH và ECC dựa trên bài toán logarit rời rạc. Trong điện toán cổ điển, tăng đủ độ dài khóa có thể nâng chi phí tấn công lên mức phi thực tế, nhưng trong điện toán lượng tử, thuật toán Shor có khả năng xử lý hiệu quả các bài toán này. Do đó, chứng chỉ RSA, trao đổi khóa ECDH và chữ ký ECDSA sẽ đồng thời trở thành đối tượng cần thay thế khi máy tính lượng tử phát triển đủ mạnh.

Đối với mật mã đối xứng, độ mạnh bảo mật được đánh giá lại có tính đến hiệu quả của thuật toán Grover. Ví dụ, độ an toàn trước tìm kiếm lượng tử của khóa đối xứng 128 bit về lý thuyết có thể giảm xuống, nên ở các lĩnh vực cần bảo vệ lâu dài cần xem xét khóa dài hơn như AES-256. Tuy nhiên, tấn công thực tế đòi hỏi nhiều điều kiện như sửa lỗi lượng tử, số qubit logic, độ sâu mạch, lỗi cài đặt, nên không được khẳng định rằng "ngày mai mọi mật mã sẽ bị phá ngay".

Mục đích của PQC không phải là sử dụng máy tính lượng tử, mà là cung cấp mật mã chạy được trên máy tính cổ điển nhưng vẫn an toàn trước kẻ tấn công sở hữu máy tính lượng tử. Do đó, thuật toán kháng lượng tử cũng không miễn nhiễm với các rủi ro truyền thống như lỗi cài đặt, lỗi sinh số ngẫu nhiên, kênh kề (side-channel), quản lý khóa yếu kém, cấp phát chứng chỉ sai. Dù thay thuật toán, nếu kiểm soát vận hành yếu thì mức bảo mật tổng thể vẫn không được cải thiện.

2.2 HNDL và vòng đời bí mật của dữ liệu

Dù hiện chưa thể phá ngay mật mã, kẻ tấn công vẫn có thể thu thập sẵn lưu lượng mạng và dữ liệu lưu trữ. Khi năng lực điện toán lượng tử đủ mạnh trong tương lai, chúng có thể giải mã các bản mã thu thập trước đây để đánh cắp thông tin y tế, bí mật quốc gia, tài liệu thiết kế công nghiệp, văn bản hợp đồng dài hạn. Mối đe dọa này đặc biệt quan trọng với các tổ chức có thời hạn giữ bí mật dài hơn thời gian cần để chuyển đổi mật mã.

Đánh giá rủi ro phải xem xét đồng thời độ nhạy cảm và vòng đời bí mật của dữ liệu. Tài liệu sẽ công bố sau một tuần và tài liệu công nghệ gốc cần bảo vệ trong 20 năm có mức ưu tiên khác nhau dù cùng sử dụng RSA. Danh mục tài sản mật mã không chỉ ghi thuật toán mà phải ghi cả phân loại dữ liệu, ngày tạo ban đầu, thời hạn lưu giữ, khả năng rò rỉ bản mã, chủ thể giải mã và độ khó thay thế.

2.3 Luồng chuyển đổi tổng thể

flowchart LR
    A[Đánh giá đe dọa lượng tử·HNDL] --> B[Phát hiện·kiểm kê tài sản mật mã]
    B --> C[Ưu tiên hóa rủi ro dữ liệu·hệ thống]
    C --> D[Thiết kế kiến trúc linh hoạt mật mã]
    D --> E[Thử nghiệm PQC·lai]
    E --> F[Chuyển đổi từng giai đoạn PKI·giao thức·ứng dụng]
    F --> G[Kiểm chứng hiệu năng·tương tác·bảo mật]
    G --> H[Giám sát vận hành·hủy bỏ·đánh giá lại]
    H -. Thay đổi·lỗ hổng mới .-> B

Trong luồng này, việc cần làm đầu tiên không phải là chọn thuật toán mà là nắm được các nơi đang sử dụng mật mã hiện nay. Không chỉ các thư viện được gọi trực tiếp mà còn phải bao gồm cả mật mã được sử dụng bên trong hệ điều hành, web server, tổ chức chứng thực, dịch vụ đám mây, thiết bị mạng và SaaS bên ngoài. Kết quả phát hiện phải được gắn với chủ sở hữu hệ thống, và việc sử dụng mật mã không có chủ sở hữu tự nó đã được phân loại là rủi ro quản lý.

Tiếp theo, xác định thứ tự chuyển đổi dựa trên tầm quan trọng của dữ liệu, khả năng bị lộ, độ khó thay thế, sự phụ thuộc chuỗi cung ứng và mức độ ảnh hưởng khi có sự cố. Truyền thông xử lý dữ liệu bí mật dài hạn và ký mã cần được xem xét sớm hơn các máy chủ thử nghiệm đơn giản, nhưng các dịch vụ cốt lõi đề cao tính sẵn sàng thì không được thay thế ngay mà không kiểm thử tương thích. Chuyển đổi không chỉ phải kiểm chứng tính bảo mật mà còn cả hiệu năng, kích thước khóa, kích thước chứng chỉ, MTU mạng, dung lượng lưu trữ và khả năng hỗ trợ của thiết bị cũ.

3. Tiêu chuẩn PQC và các thuật toán cốt lõi

3.1 Phân định vai trò của các tiêu chuẩn NIST

Ba tiêu chuẩn mà NIST đã hoàn thiện không phải là một danh sách cạnh tranh cùng một chức năng. ML-KEM thuộc nhóm đóng gói khóa, giúp hai bên truyền thông thiết lập bí mật chung trên kênh công khai, còn ML-DSA và SLH-DSA thuộc nhóm chữ ký số nhằm bảo đảm tính toàn vẹn của thông điệp và xác thực người ký. TLS hay ứng dụng thực tế có thể cần cả thiết lập khóa cho phiên truyền thông lẫn xác thực máy chủ/máy khách, nên phải thiết kế kết hợp KEM với chữ ký.

Tiêu chuẩn	Thuật toán	Chức năng chính	Toán học nền tảng	Vai trò khi chuyển đổi
FIPS 203	ML-KEM	Đóng gói khóa, thiết lập bí mật chung	Dựa trên lưới module	Thiết lập khóa cho TLS, VPN, mã hóa thông điệp
FIPS 204	ML-DSA	Chữ ký số đa dụng	Dựa trên lưới module	Ký chứng chỉ, mã, tài liệu, token
FIPS 205	SLH-DSA	Chữ ký số dựa trên hàm băm phi trạng thái	Dựa trên hàm băm	Gốc tin cậy thay thế, đa dạng thuật toán

Nếu hiểu sai sự phân định chức năng trong bảng này sẽ dẫn đến những lỗi như dùng ML-KEM để ký tài liệu hoặc dùng ML-DSA làm thuật toán trao đổi khóa. Đóng gói khóa nhằm thỏa thuận an toàn khóa phiên đối xứng, còn chữ ký số nhằm kiểm chứng chữ ký bằng khóa công khai để xác nhận nguồn gốc và việc có bị sửa đổi hay không. Vì vậy, trong phân tích yêu cầu phải tách riêng luồng tập trung vào tính bí mật và luồng tập trung vào xác thực/toàn vẹn, rồi ánh xạ tới tiêu chuẩn phù hợp.

3.2 ML-KEM và đóng gói khóa

ML-KEM là cơ chế đóng gói khóa dựa trên lưới module, bắt nguồn từ bản đề xuất CRYSTALS-Kyber. Bên nhận sinh khóa công khai và khóa bí mật, bên gửi dùng khóa công khai của bên nhận để đóng gói, tạo ra bản mã và bí mật chung. Bên nhận dùng khóa bí mật để mở gói bản mã, thu được cùng bí mật chung, sau đó dữ liệu dung lượng lớn được xử lý bằng mật mã đối xứng như AES-GCM — đây là cấu trúc lai phổ biến.

sequenceDiagram
    participant C as Máy khách
    participant S as Máy chủ
    participant K as Kênh mã hóa đối xứng
    S->>S: Sinh cặp khóa ML-KEM·cung cấp khóa công khai
    C->>C: Sinh bí mật chung·đóng gói
    C->>S: Gửi bản mã KEM
    S->>S: Mở gói bằng khóa bí mật
    C->>K: Dẫn xuất khóa phiên từ cùng bí mật chung
    S->>K: Dẫn xuất khóa phiên từ cùng bí mật chung
    C->>S: Bản mã AEAD·thẻ toàn vẹn
    S-->>C: Phản hồi AEAD

Ưu điểm của đóng gói khóa là không mã hóa trực tiếp toàn bộ bản rõ bằng mật mã khóa công khai mà chỉ thiết lập một bí mật chung ngắn. Tuy nhiên, kích thước khóa công khai và bản mã có thể lớn hơn ECDH hiện tại, nên cần đo kích thước chứng chỉ, handshake, gói tin và độ trễ xử lý. Đặc biệt, với thiết bị IoT nhỏ, thiết bị VPN cũ, mạng có MTU chặt chẽ, việc phân mảnh và giới hạn bộ đệm có thể dẫn đến kết nối thất bại.

3.3 ML-DSA và chữ ký số đa dụng

ML-DSA là tiêu chuẩn chữ ký số dựa trên lưới module, bắt nguồn từ bản đề xuất CRYSTALS-Dilithium. Người ký dùng khóa bí mật để ký thông điệp, người kiểm chứng dùng khóa công khai và chữ ký để xác nhận thông điệp có bị sửa đổi hay không và việc người ký sở hữu khóa công khai. Có thể áp dụng cho chứng chỉ, gói ứng dụng, container image, firmware, API token, văn bản điện tử.

ML-DSA có tính đa dụng cao nhưng kích thước khóa công khai và chữ ký có thể lớn hơn chữ ký ECDSA hiện tại. Khi kích thước chữ ký tăng, kích thước chuỗi chứng chỉ và gói phân phối mã, thời gian kiểm chứng, hiệu quả bộ nhớ đệm, dung lượng lưu log và cơ sở dữ liệu đều bị ảnh hưởng. Vì vậy, không chỉ đơn giản thay tên thuật toán mà phải thực hiện kiểm thử đầu cuối (end-to-end) bao gồm độ dài chuỗi chứng chỉ và kích thước thông điệp tối đa.

Trong ký mã, gốc tin cậy và quy trình khôi phục khi cập nhật thất bại có thể còn quan trọng hơn việc thay thuật toán. Cần kiểm tra khi kiểm chứng chữ ký thất bại thì thiết bị có thể quay về phiên bản an toàn trước đó hay không, có chặn tấn công rollback hay không, và kiểm soát truy cập khóa ký ngoại tuyến như thế nào. Nếu định dạng chữ ký của binary do nhà cung cấp tạo ra và sản phẩm build nội bộ khác nhau, thì phải chuẩn hóa đồng thời toàn bộ pipeline triển khai.

3.4 SLH-DSA và đa dạng thuật toán

SLH-DSA là chữ ký số dựa trên hàm băm phi trạng thái, bắt nguồn từ bản đề xuất SPHINCS+. Do dựa trên tính chất của hàm băm thay vì bài toán lưới có cấu trúc, nó có thể là phương án thay thế với giả định khác với ML-DSA. Nó có ý nghĩa từ góc độ đa dạng thuật toán, nhằm giảm rủi ro toàn bộ hệ thống tin cậy sụp đổ cùng lúc khi một giả định toán học gặp vấn đề.

Đổi lại, kích thước chữ ký và đặc tính xử lý có thể khác ML-DSA nên cần thận trọng khi chọn làm mặc định cho mọi luồng. Với thiết bị bị giới hạn băng thông hoặc dịch vụ có tần suất ký rất cao, cần đo gánh nặng hiệu năng, lưu trữ, truyền tải, và có thể ưu tiên áp dụng cho những lĩnh vực đề cao giả định bảo thủ hơn tốc độ như neo tin cậy dài hạn (trust anchor). Đa dạng thuật toán không phải là bắt buộc dùng đồng thời nhiều thuật toán, mà là nguyên tắc thiết kế cân bằng giữa khả năng thất bại độc lập và độ phức tạp vận hành.

4. Linh hoạt mật mã và chuyển đổi lai

4.1 Khái niệm linh hoạt mật mã

Linh hoạt mật mã (crypto-agility) là năng lực của hệ thống cho phép thay thế thuật toán mật mã, độ dài khóa, giao thức, chứng chỉ mà không phải viết lại quy mô lớn logic nghiệp vụ xung quanh. Nếu tên thuật toán bị hard-code khắp mã nguồn hoặc định dạng chứng chỉ và kho khóa bị gắn chặt vào một bản cài đặt cụ thể, thời gian thay thế sẽ kéo dài khi phát hiện lỗ hổng. Trong chuyển đổi PQC, tính linh hoạt không phải là biện pháp đối phó lượng tử một lần, mà là thuộc tính chất lượng bền vững giúp ứng phó cả với thay đổi tiêu chuẩn và lỗ hổng thuật toán về sau.

Áp dụng API chung trừu tượng hóa dịch vụ mật mã, quản lý khóa tập trung, thương lượng thuật toán dựa trên chính sách, hồ sơ chứng chỉ có phiên bản và thay thế khóa/chứng chỉ tự động có thể thu hẹp phạm vi thay thế. Tuy nhiên, nếu tầng trừu tượng che giấu tham số và hành vi lỗi của thuật toán thực tế, việc kiểm chứng hiệu năng và bảo mật có thể trở nên khó khăn, nên phải thiết kế đồng thời giao diện chuẩn hóa và metadata có thể quan sát được. Tiêu chí thành công của linh hoạt mật mã không phải là tuyên bố "có thể thay bất cứ lúc nào", mà được đo bằng việc một dịch vụ cụ thể có thể thay thuật toán được phê duyệt trong bao nhiêu bước và bao nhiêu lần triển khai.

4.2 Ý nghĩa của mật mã lai

Phương thức lai là cách tiếp cận sử dụng đồng thời phương thức khóa công khai hiện có và phương thức PQC, được thiết kế để khi một bên thất bại vẫn tận dụng được độ an toàn của bên kia. Trong thiết lập khóa, có thể kết hợp bí mật sinh ra từ ECDH cổ điển và ML-KEM để dẫn xuất khóa, còn trong chữ ký có thể đặt chính sách kiểm chứng đồng thời chữ ký hiện có và chữ ký PQC. Phương thức này hỗ trợ kiểm chứng khả năng tương tác và chuyển đổi dần dần, nhưng nếu thiết kế sai phương pháp kết hợp và chính sách kiểm chứng thì ngược lại sẽ sinh ra cấu hình yếu nhất hoặc các đường thất bại phức tạp.

Kết hợp lai không phải là việc đơn thuần nối hai bản mã hay hai chữ ký lại với nhau. Cần ghi rõ nguồn gốc của từng bí mật trong hàm dẫn xuất khóa, và định nghĩa khi một thành phần thất bại thì có xử lý toàn bộ phiên là thất bại hay không, có cho phép hạ cấp (downgrade) hay không, có ghi kết quả thương lượng vào log kiểm toán hay không. Ngoài ra, trong khi kiểm chứng cả hai thuật toán, kích thước handshake và thông lượng sẽ tăng, nên phải thử nghiệm với tổ hợp mạng, thiết bị, máy khách thực tế.

4.3 So sánh mật mã hiện có và PQC

Hạng mục	RSA·DH·ECC	PQC	Hàm ý khi chuyển đổi
Giả định an toàn	Phân tích thừa số, logarit rời rạc	Các bài toán khác như lưới, hàm băm	Xác nhận đa dạng thuật toán và lịch sử kiểm chứng
Tấn công lượng tử	Dễ bị tổn thương trước thuật toán Shor	Được thiết kế có tính đến tấn công lượng tử	Ưu tiên chuyển đổi từ dữ liệu bí mật dài hạn
Kích thước khóa, chữ ký	Tương đối nhỏ	Lớn hơn ở một số cấu hình	Cần đo MTU, chứng chỉ, dung lượng lưu trữ
Hệ sinh thái	Cài đặt và tương tác lâu đời	Hỗ trợ thư viện, thiết bị đang phát triển	Cần lai và áp dụng từng giai đoạn
Rủi ro vận hành	Quen thuộc nhưng có rủi ro dài hạn	Rủi ro thay đổi cài đặt, tiêu chuẩn, chuỗi cung ứng	Bảo đảm kiểm kê mật mã và tính linh hoạt

Trọng tâm của phép so sánh không phải là khẳng định PQC vượt trội hơn mật mã hiện có ở mọi hạng mục. PQC cung cấp mục tiêu an toàn trước mối đe dọa lượng tử nhưng có thể phát sinh chi phí về kích thước khóa, hiệu năng và hệ sinh thái cài đặt. Do đó, quyết định áp dụng lai hay PQC đơn thuần cần phản ánh vòng đời bảo mật của hệ thống, ngân sách hiệu năng, mức chịu lỗi và yêu cầu pháp quy.

5. Kiểm kê tài sản mật mã và quy trình chuyển đổi từng giai đoạn

5.1 Phát hiện và lập danh mục

Kiểm kê tài sản mật mã là danh mục ghi lại loại mật mã nào được dùng với mục đích gì trong hệ thống, ứng dụng, thiết bị và luồng dữ liệu. Các mục tối thiểu gồm thuật toán, chế độ, độ dài khóa, phiên bản thư viện, chủ sở hữu khóa và chứng chỉ, vòng đời, vị trí lưu trữ, giao thức phụ thuộc, nhà cung cấp và cách thay thế. Chỉ phân tích tĩnh mã nguồn thì có thể không tìm ra mô-đun bảo mật phần cứng, chứng chỉ do đám mây quản lý, API bên ngoài, quy trình thủ công của người vận hành, nên phải kết hợp nhiều phương thức phát hiện.

Trong quá trình phát hiện, sử dụng kết hợp quét mạng, phân tích kho chứng chỉ, phân tích thành phần phần mềm, tìm kiếm mã, truy vấn cấu hình đám mây, hỏi nhà cung cấp và phỏng vấn. Mỗi kết quả cần ghi rõ thời điểm phát hiện, độ chính xác, vùng chưa xác minh, và quản lý việc sử dụng mật mã không được phát hiện tự động như rủi ro tồn dư riêng. Danh mục kiểm kê không phải là một bảng tính tĩnh mà phải vận hành như một sản phẩm dữ liệu liên tục gắn với CMDB, quản lý tài sản, quản lý khóa và pipeline triển khai.

5.2 Ưu tiên hóa rủi ro

Mức ưu tiên không được quyết định chỉ bởi việc mật mã đã lỗi thời. Cần đánh giá đồng thời vòng đời bí mật của dữ liệu, mức phơi nhiễm tấn công, tầm quan trọng của hệ thống, thời gian chuẩn bị (lead time) cần cho thay thế, lịch hỗ trợ của nhà cung cấp và mức độ ảnh hưởng nghiệp vụ khi có sự cố. Ví dụ, endpoint TLS công khai ra bên ngoài có rủi ro phơi nhiễm lớn và có thể dễ thay thế, còn thiết bị điều khiển công nghiệp đã ngừng sản xuất dù mức phơi nhiễm hạn chế nhưng thời gian chuẩn bị thay thế và ảnh hưởng an toàn có thể lớn.

Mức ưu tiên	Đối tượng tiêu biểu	Căn cứ phán đoán	Hoạt động khuyến nghị
Rất cao	Dữ liệu bí mật dài hạn, PKI cốt lõi, ký mã/firmware	HNDL, sụp đổ tin cậy, thời gian chuẩn bị thay thế	Lập ngay kiểm kê, thiết kế, kế hoạch với nhà cung cấp
Cao	TLS Internet, VPN, xác thực IAM/API	Phơi nhiễm bên ngoài và ảnh hưởng quy mô lớn	Thử nghiệm lai, lộ trình chứng chỉ và giao thức
Trung bình	Dịch vụ nội bộ thông thường và dữ liệu ngắn hạn	Vòng đời bí mật và ảnh hưởng tương đối thấp	Áp dụng thư viện chuẩn và tính linh hoạt rồi chuyển đổi tuần tự
Thấp	Dữ liệu công khai, tài sản sắp ngừng hỗ trợ	Giá trị bảo vệ hoặc vòng đời còn lại thấp	Phê duyệt ngoại lệ, kế hoạch thay thế hoặc loại bỏ

Bảng này không phải là quy tắc quyết định tự động mà là điểm khởi đầu cho đánh giá rủi ro. Dù có mức ưu tiên cao, trước khi áp dụng thực tế vẫn phải kiểm chứng khả năng tương tác, hiệu năng, khôi phục sự cố; và dù mức ưu tiên thấp, nếu luật hay hợp đồng yêu cầu thời hạn riêng thì phải điều chỉnh thứ tự. Ngoại lệ phải được chủ sở hữu hệ thống, người chịu trách nhiệm bảo mật và các bên liên quan về mua sắm, pháp chế phê duyệt, đồng thời ghi rõ ngày hết hạn và biện pháp kiểm soát bổ sung.

5.3 Cài đặt, thử nghiệm, triển khai

Thí điểm (pilot) bắt đầu từ dịch vụ vừa có tính đại diện vừa có thể giới hạn phạm vi thất bại. Chọn lần lượt các luồng mật mã khác nhau như endpoint TLS công khai, mTLS giữa các dịch vụ nội bộ, ký mã, VPN, kết nối cơ sở dữ liệu, rồi xác nhận thư viện được hỗ trợ và tham số thuật toán. Kết quả thử nghiệm không chỉ gồm độ trễ trung bình mà cả độ trễ handshake p99, kích thước thông điệp tối đa, mức sử dụng CPU/bộ nhớ, tỷ lệ kết nối thất bại, xử lý chuỗi chứng chỉ và thời gian rollback.

Triển khai được chia thành các giai đoạn phát triển, kiểm chứng, một phần lưu lượng và toàn bộ lưu lượng; khi thương lượng thất bại thì trả về lỗi an toàn chứ không lặng lẽ hạ cấp xuống thuật toán yếu. Đặt ngày hết hạn và kiểm tra tự động để các feature flag thử nghiệm không còn sót lại trong môi trường vận hành và kích hoạt lại thuật toán không được phép. Sau khi hoàn tất chuyển đổi, thay vì xóa ngay chứng chỉ và khóa cũ, cần rà soát sự phụ thuộc và nghĩa vụ lưu giữ rồi mới hủy bỏ an toàn và lưu lại bằng chứng hủy bỏ.

6. Tình huống áp dụng và công nghệ liên quan

6.1 Tình huống chuyển đổi kênh bên ngoài của tổ chức tài chính

Giả sử một tổ chức tài chính lớn vận hành TLS cho ứng dụng di động và ngân hàng Internet, mTLS cho API nội bộ, chứng chỉ khách hàng và chữ ký văn bản điện tử. Trước tiên, kiểm kê các luồng cấp phát, gia hạn chứng chỉ và phiên bản máy khách, đồng thời phân biệt văn bản giao dịch được lưu giữ lâu dài với dữ liệu phiên ngắn hạn. Sau đó, thử nghiệm trao đổi khóa lai cho máy chủ, máy khách di động mới nhất và API gateway, rồi đo tỷ lệ thất bại của máy khách cũ và kích thước gói tin truyền thông.

Dù chỉ máy chủ hỗ trợ PQC, nếu thiết bị đầu cuối cũ không xử lý được chứng chỉ và handshake mới thì dịch vụ sẽ gặp sự cố. Vì vậy, cần gộp cập nhật ứng dụng, thư viện mật mã tương thích, chuỗi chứng chỉ, cách xử lý lỗi của trung tâm chăm sóc khách hàng và rollback khi có sự cố vào một kế hoạch phát hành thống nhất. Chữ ký điện tử của văn bản giao dịch là luồng tách biệt với thiết lập khóa, nên cũng phải quyết định đồng thời việc áp dụng ML-DSA/SLH-DSA cùng định dạng chữ ký và chính sách dấu thời gian (timestamp) cho kiểm chứng dài hạn.

6.2 Tình huống ký firmware trong sản xuất và IoT

Tại hiện trường sản xuất có thể tồn tại cảm biến, gateway, PLC, bộ điều khiển xe có vòng đời trên 10 năm. Dù thiết bị không kết nối trực tiếp Internet, firmware độc hại vẫn có thể xâm nhập qua chuỗi cung ứng hoặc máy tính xách tay bảo trì, nên việc bảo vệ dài hạn chữ ký firmware và khóa cập nhật là rất quan trọng.

Kế hoạch chuyển đổi bắt đầu từ việc xác nhận bootloader có kiểm chứng được thuật toán chữ ký mới hay không, có thay được gốc tin cậy cố định trong ROM hay không, có đủ dung lượng flash để lưu kích thước chữ ký hay không. Nếu khó thay thế một lần toàn bộ thiết bị cũ, có thể tăng cường kiểm chứng gói cập nhật tại gateway bảo mật, tích hợp sẵn tính linh hoạt mật mã từ các thiết bị mới, và phản ánh việc kết thúc vòng đời thiết bị cùng ngân sách thay thế vào lộ trình. Tình huống này cho thấy các vấn đề về vòng đời phần cứng, khả năng tiếp cận hiện trường và quy trình dừng an toàn không thể giải quyết chỉ bằng việc chọn thuật toán.

6.3 Liên kết giữa PKI và chuỗi cung ứng phần mềm

Chuyển đổi PQC không chỉ liên quan đến CA gốc, CA trung gian, chứng chỉ lá của PKI mà còn liên quan đến ký mã, container image, kho gói và quy trình build. Khi kích thước chứng chỉ và định dạng chữ ký thay đổi, proxy, thiết bị bảo mật, SDK máy khách, công cụ kiểm chứng chữ ký sẽ lần lượt bị ảnh hưởng dây chuyền. Trong chuỗi cung ứng phần mềm, phải bảo vệ khóa ký của môi trường build và ghi lại cùng provenance việc sản phẩm được ký bằng thuật toán nào, khóa nào, vào lúc nào.

7. Chuyên sâu: Xu hướng tiêu chuẩn hóa, vận hành và liên hệ với đề thi

Sau khi công bố FIPS 203, 204, 205 vào năm 2024, NIST vẫn tiếp tục tiêu chuẩn hóa bổ sung và phát triển các thuật toán dự phòng. Vì vậy, thay vì ghi nhớ danh sách ứng viên tại một thời điểm như đáp án vĩnh viễn, điều quan trọng là phân biệt đó là tiêu chuẩn chính thức hay bản dự thảo, dùng cho thiết lập khóa hay chữ ký số, sản phẩm áp dụng đã được kiểm chứng hay chưa. Tình trạng tiêu chuẩn mới nhất cần được xác nhận dựa trên dự án PQC của NIST và nguyên văn FIPS, đồng thời đánh giá tách biệt mô tả tiếp thị của nhà cung cấp sản phẩm với yêu cầu tiêu chuẩn.

Định hướng chuyển đổi của NIST là xác định việc sử dụng khóa công khai dễ bị tổn thương, ưu tiên hóa hệ thống và dữ liệu, và chuyển sang cấu trúc cho phép thay thế mật mã. Góc nhìn này gắn với quản trị an toàn thông tin, PKI, lập trình an toàn, bảo mật chuỗi cung ứng phần mềm, bảo vệ dữ liệu cá nhân và khôi phục thảm họa. Trong bài làm của Kỹ sư chuyên nghiệp, không nên thu hẹp "áp dụng PQC" thành việc thay thuật toán của nhóm bảo mật mà nên mở rộng trình bày thành sự thay đổi của hệ thống quản lý tài sản, mua sắm, phát triển, vận hành và kiểm toán toàn doanh nghiệp để tăng tính logic.

Đề tự luận dự kiến có thể được xây dựng theo dạng kết hợp nguyên lý mối đe dọa lượng tử và so sánh các thuật toán ứng phó, lộ trình chuyển đổi có tính đến HNDL, xây dựng kiểm kê tài sản mật mã, thiết kế linh hoạt mật mã, ưu nhược điểm của chuyển đổi lai, tình huống áp dụng PKI và ký mã. Bài làm triển khai theo thứ tự đe dọa và sự cần thiết, tiêu chuẩn và thành phần, quy trình chuyển đổi, tình huống và so sánh, rủi ro và quản trị, hàm ý của Kỹ sư chuyên nghiệp thì sẽ đi liền mạch từ nguyên nhân đến thực thi.

8. Các lưu ý và hàm ý

A. Quản lý tiêu chuẩn và khả năng tương tác

Dù tiêu chuẩn PQC đã được hoàn thiện, không phải mọi hệ điều hành, trình duyệt, thiết bị mạng, HSM đều hỗ trợ cùng lúc. Cần xác nhận phiên bản tiêu chuẩn, bộ tham số, tình trạng kiểm chứng mô-đun chứng thực, biện pháp chống kênh kề của bản cài đặt thư viện, giấy phép và chủ thể bảo trì. Thực hiện thử nghiệm chung với nhà cung cấp để xác nhận tổ hợp cài đặt của hai bên trong thương lượng lai có thực sự tương tác được không, và lập tài liệu về ảnh hưởng đến người dùng cũng như đường rollback khi thất bại.

B. Đánh đổi giữa hiệu năng, dung lượng, tính sẵn sàng

Sự gia tăng kích thước khóa, chữ ký, bản mã có thể làm tăng băng thông mạng, MTU, lưu trữ chứng chỉ, bộ nhớ đệm, cột cơ sở dữ liệu và chi phí log. Không ra quyết định chỉ dựa trên hiệu năng trung bình, mà phải thực hiện kiểm thử tải bao gồm đỉnh lưu lượng, bùng nổ kết nối lại, băng thông thấp trên di động, thiết bị thiếu CPU và kiểm chứng hàng loạt khi khôi phục sự cố. Việc tăng độ mạnh bảo mật có thể làm giảm tính sẵn sàng, nên cần chọn tham số và giai đoạn triển khai đáp ứng trải nghiệm người dùng và mục tiêu mức dịch vụ.

C. Quản lý khóa và kiểm soát vận hành

PQC cũng có thể bị tổn thương trước việc đánh cắp khóa bí mật, lỗi sinh số ngẫu nhiên, lộ bản sao lưu khóa và lạm dụng quyền hạn. Định nghĩa bằng chính sách việc hỗ trợ thuật toán của HSM/KMS, sinh và hủy khóa, phê duyệt kép, log truy cập, mã hóa bản sao lưu, tự động gia hạn chứng chỉ và thay thế khẩn cấp. Biến việc đối chiếu định kỳ và xác nhận chủ sở hữu thành kiểm soát vận hành để dữ liệu của danh mục tài sản mật mã và hệ thống quản lý khóa không bị lệch nhau.

D. Quản trị dài hạn và đầu tư

PQC phải được vận hành như một chương trình liên tục phát hiện, ưu tiên hóa, thay thế và kiểm chứng lại, thay vì tuyên bố hoàn thành một dự án ngắn hạn. Xây dựng cơ chế ra quyết định lấy CISO hoặc người chịu trách nhiệm cao nhất về an toàn thông tin làm trung tâm, với sự tham gia của chủ sở hữu hệ thống, mạng, PKI, phát triển, mua sắm, pháp chế, kiểm toán, đồng thời quản lý lịch hỗ trợ và trách nhiệm hợp đồng của nhà cung cấp. Hệ thống mới phải dùng API mật mã đã phê duyệt và hồ sơ chứng chỉ có thể thay thế ngay từ đầu, còn các ngoại lệ di sản (legacy) được gán ngày kết thúc, biện pháp kiểm soát bổ sung và ngân sách.

E. Triển vọng dưới góc nhìn Kỹ sư chuyên nghiệp

Mật mã kháng lượng tử không chỉ là chủ đề riêng của điện toán lượng tử mà là chủ đề thiết kế lại hạ tầng mật mã dài hạn của một xã hội số đáng tin cậy. Trong tương lai, CBOM — theo dõi tài sản mật mã như thành phần phần mềm — cùng quản lý vòng đời chứng chỉ/khóa tự động, bằng chứng chuỗi cung ứng và thương lượng mật mã dựa trên chính sách sẽ ngày càng quan trọng. Kỹ sư chuyên nghiệp không dừng ở việc khuyến nghị một thuật toán cụ thể mà phải đưa ra kiến trúc chuyển đổi và lộ trình khả thi phản ánh rủi ro, vòng đời dữ liệu, chất lượng dịch vụ và ràng buộc mua sắm của tổ chức.

Tài liệu tham khảo

Tóm tắt một câu: Chuyển đổi PQC không phải là việc chọn ML-KEM, ML-DSA, SLH-DSA, mà là chiến lược phát hiện tài sản mật mã, ưu tiên hóa rủi ro, rồi dùng tính linh hoạt mật mã và kiểm chứng từng giai đoạn để đưa PKI, giao thức và chuỗi cung ứng toàn doanh nghiệp sang cấu trúc kháng lượng tử.