Mã hóa hậu lượng tử của OpenSSH
(openssh.com)- OpenSSH hỗ trợ thuật toán mật mã hậu lượng tử để chống lại các cuộc tấn công của máy tính lượng tử
- Từ phiên bản 9.0, mặc định áp dụng thuật toán sntrup761x25519-sha512; từ phiên bản 10.0 chuyển sang áp dụng mlkem768x25519-sha256 làm cơ chế kết nối mặc định
- Từ phiên bản 10.1 có thay đổi là sẽ hiển thị thông báo cảnh báo khi không dùng trao đổi khóa hậu lượng tử
- Hầu như tất cả thuật toán chữ ký hiện có (như RSA, ECDSA) cũng sẽ sớm được bổ sung hỗ trợ
- Để bảo vệ lưu lượng truy cập hiện tại một cách an toàn, cả máy chủ và máy khách đều cần áp dụng thuật toán hậu lượng tử
Việc triển khai mã hóa hậu lượng tử trong OpenSSH
OpenSSH hỗ trợ nhiều thuật toán thỏa thuận khóa an toàn trước các tấn công từ máy tính lượng tử. OpenSSH khuyến nghị sử dụng các thuật toán này cho mọi kết nối SSH.
Từ OpenSSH 9.0 (2022), KexAlgorithms đã mặc định hỗ trợ thỏa thuận khóa hậu lượng tử thông qua sntrup761x25519-sha512, và từ phiên bản 9.9 đã bổ sung mlkem768x25519-sha256. OpenSSH 10.0 đánh dấu mlkem768x25519-sha256 là cơ chế mã hóa mặc định.
Để thúc đẩy việc áp dụng thuật toán hậu lượng tử, OpenSSH 10.1 trở đi sẽ hiển thị cảnh báo sau đây nếu không sử dụng thỏa thuận khóa kháng lượng tử:
** WARNING: connection is not using a post-quantum kex exchange algorithm. **
This session may be vulnerable to "store now, decrypt later" attacks.
The server may need to be upgraded. See https://openssh.com/pq.html
Cảnh báo này mặc định sẽ xuất hiện, nhưng có thể vô hiệu hóa bằng tuỳ chọn WarnWeakCrypto trong ssh_config(5).
Bối cảnh
Máy tính lượng tử là thiết bị tính toán bằng cách mã hóa thông tin trong trạng thái lượng tử, có thể giải một số bài toán toán học rất nhanh so với máy tính thông thường.
Nguyên lý toán học của nhiều thuật toán mật mã dựa trên các bài toán có thể bị máy tính lượng tử giải nhanh. Khi xuất hiện một máy tính lượng tử đủ mạnh (ở mức có ý nghĩa về mật mã), các hệ mật mã này có thể bị phá vỡ. Đặc biệt, các thuật toán dùng cho trao đổi khóa và chữ ký số sẽ chịu ảnh hưởng lớn nhất.
Mặc dù máy tính lượng tử như vậy vẫn chưa xuất hiện, giới chuyên môn dự báo có thể xuất hiện trong 5-20 năm tới, hoặc vào giữa thập kỷ 2030.
Bảo mật quyền riêng tư của kết nối SSH dựa trên mật mã trao đổi khóa. Nếu kẻ tấn công phá được thuật toán trao đổi khóa, toàn bộ nội dung phiên có thể bị giải mã. Ngoài ra, kể cả khi không có tấn công thời gian thực, kẻ tấn công có thể lưu lại phiên mã hóa rồi chờ đến khi máy tính lượng tử ra đời để giải mã theo kiểu tấn công 'store now, decrypt later' (lưu lại rồi giải mã sau).
OpenSSH đang tăng cường hỗ trợ mã hóa hậu lượng tử để đối phó với kiểu tấn công này.
FAQ
Q: Nhận cảnh báo trong SSH, nên làm gì?
- OpenSSH 10.1 trở lên cảnh báo cho người dùng khi dùng mật mã không an toàn trước lượng tử.
- Nếu gặp tình trạng này, có thể có nghĩa là máy chủ kết nối chưa cung cấp thuật toán trao đổi khóa hậu lượng tử (mlkem768x25519-sha256, sntrup761x25519-sha512).
- Cách tốt nhất là cập nhật máy chủ lên OpenSSH 9.0 trở lên (phiên bản thứ hai từ 9.9 trở lên), sau đó kiểm tra trong KexAlgorithms xem các thuật toán liên quan có đang bị vô hiệu hóa hay không.
- Nếu không thể nâng cấp máy chủ hoặc chấp nhận chấp nhận rủi ro, có thể chỉ cần ẩn cảnh báo bằng tuỳ chọn WarnWeakCrypto trong ssh_config(5).
- Nếu cần, nên áp dụng cho từng host cụ thể như sau
Match host unsafe.example.com WarnWeakCrypto no
Q: Vì sao cần chuẩn bị trước khi có máy tính lượng tử?
- Do tấn công kiểu 'store now, decrypt later' đã nêu ở trên.
- Kể cả lưu lượng hôm nay cũng có nguy cơ bị giải mã sau này, vì vậy nên ưu tiên kết nối an toàn hậu lượng tử ngay từ bây giờ.
Q: Bài viết nói chữ ký cũng nguy hiểm, tại sao vẫn không phải vấn đề cấp bách?
- Hầu như mọi thuật toán chữ ký hiện nay (RSA, ECDSA...) cũng có thể bị vô hiệu hóa bởi máy tính lượng tử.
- Tuy nhiên trong trường hợp này, lưu lượng đã trao đổi không có nguy cơ bị lưu và giải mã về sau.
- Việc cấp bách với thuật toán chữ ký là chuẩn bị thay thế khóa ký hiện có khi máy tính lượng tử tiến sát chúng ta.
- OpenSSH cũng dự kiến sẽ hỗ trợ thuật toán chữ ký hậu lượng tử trong tương lai.
Q: Tôi nghĩ máy tính lượng tử sẽ không bao giờ khả thi, tại sao lại quan trọng?
- Một số người tin rằng máy tính lượng tử không thể thực hiện được, nhưng rào cản hiện tại là vấn đề kỹ thuật chứ không phải vật lý cơ bản.
- Nếu máy tính lượng tử khả thi, các bước chuẩn bị hiện tại sẽ giúp bảo vệ một lượng lớn dữ liệu người dùng.
- Dù cuối cùng có thể không cần dùng đến, thì việc chuyển sang mật mã toán học mạnh hơn vẫn chỉ là một sự chuyển đổi cần thiết.
Q: Liệu thuật toán hậu lượng tử có thể vẫn bị tấn công được không?
- OpenSSH cũng tiếp cận rất thận trọng.
- Chỉ những thuật toán đã được đánh giá kỹ trong vài năm gần đây mới được chọn, nhưng vẫn có khả năng xuất hiện các phương pháp tấn công mới.
- Vì vậy, OpenSSH chọn các thuật toán có khoảng an toàn dư lớn, để ngay cả khi dự kiến rằng chúng yếu hơn mong đợi, xác suất đạt được mức an toàn thực chiến vẫn cao.
- Hơn nữa, tất cả thuật toán hậu lượng tử của OpenSSH đều theo cơ chế "hybrid".
- Ví dụ: mlkem768x25519-sha256 kết hợp giữa ML-KEM (hậu lượng tử) và thuật toán cổ điển ECDH/x25519.
- Nhờ đó, nếu thuật toán hậu lượng tử bị vô hiệu hóa trong tương lai, mức an toàn cơ bản của hệ thống vẫn được giữ ở mức tối thiểu như trước
1 bình luận
Ý kiến trên Hacker News
Ở cuối trang có một nội dung quan trọng bị giấu. Tất cả các thuật toán hậu lượng tử được áp dụng trên OpenSSH đều theo kiểu "hybrid": dùng đồng thời cơ chế trao đổi khóa hậu lượng tử (ví dụ: ML-KEM) và cơ chế truyền thống (x25519). Khi dùng hai thuật toán cùng lúc, ngay cả khi một trong những thuật toán hậu lượng tử tương lai bị bẻ gãy hoàn toàn, mức bảo mật cơ bản vẫn được giữ ở ngưỡng trước đó. Điểm cốt lõi của hybrid là không mất đi mức bảo mật so với cách cũ.
Cách hybrid có lợi thế là chỉ cần một bên còn lại bị hỏng vẫn có thể phục hồi nhờ thuật toán kia. Nhưng ngược lại, phạm vi lỗi triển khai, lỗ hổng side-channel cũng tăng hơn một bậc. Trong thực tế, đe dọa máy tính lượng tử chưa phải chuyện hiện tại, song các lỗi và điểm yếu đó là vấn đề đang diễn ra ngay. Dù vậy, trong 10 năm gần đây đã có lượng lớn nghiên cứu, rà soát bảo mật; vì thế mức đánh đổi này có thể chấp nhận được.
Toàn ngành công nghiệp phần lớn đang chuyển sang cấu trúc hybrid PQC-cổ điển. Trước khi xuất hiện máy tính lượng tử đủ mạnh để thực sự bẻ gãy RSA, ECC, DH, giải pháp cài hai khóa song song vẫn có vẻ là lựa chọn an toàn nhất lúc này. Ở một phía khác, thuật toán CNSA 2.0 của NSA (liên kết) chỉ chấp nhận dải hậu lượng tử và trong FAQ chính thức nói hybrid không cần thiết.
Xét đến bài báo vừa công bố, khá thiên kiến mà cũng gây tiếng cười (liên kết), tôi tự hỏi việc áp dụng mật mã hậu lượng tử ở tốc độ hiện tại có thật sự cần thiết không. Theo như tôi biết, khóa hậu lượng tử hiện lớn hơn rất nhiều so với trước nên lưu lượng mạng và CPU tiêu thụ đều tăng đáng kể.
Bài này chỉ nói về việc áp dụng PQC trong trao đổi khóa của SSH, nên overhead chỉ ở mức rất nhỏ. Và như FAQ đã nêu, câu hỏi "vì sao chuẩn bị trước khi chưa có máy tính lượng tử" bắt nguồn từ rủi-ro "store now, decrypt later": lưu lượng truyền hôm nay có thể bị giải mã sau này. Có người cho rằng máy tính lượng tử là không thể thực hiện được, nhưng trở ngại chính không phải luật vật lý mà là kỹ thuật triển khai. Nếu máy tính lượng tử thực sự ra đời, nó có thể giải mã được lượng dữ liệu người dùng khổng lồ. Tôi vẫn khuyên đọc bài đó cho biết để tham khảo, nhưng đừng quá lạnh lùng với nó.
Dù bài viết này gây cười, không nên chỉ xem là đùa cợt. Thực tế vẫn có tiến triển đáng kể. Nên xem bài trình bày của Sam Jacques tại PQCrypto 2025 (liên kết). Trong 10 năm qua, chi phí phân tích thừa số với máy tính lượng tử đã giảm 1000 lần, và tỉ lệ lỗi phần cứng cũng giảm đáng kể (liên kết1, liên kết2, liên kết3, liên kết4). Nếu muốn theo dõi tiến triển của máy tính lượng tử, chỉ cần theo dõi độ bền tăng dần. Nhiễu là trở ngại lớn; khi chất lượng hai phía được giải quyết thì có thể đợi tiến triển thực sự.
Bài đó gần như tưởng như đùa. Nếu coi đây là phản biện nghiêm túc, thì giống như năm 1951 than phiền transistor không tính được π. Nhu cầu áp dụng PQC phụ thuộc vào hai câu hỏi: 1) bạn có tin rằng trong cả đời mình sẽ không bao giờ có máy tính lượng tử không; 2) bạn đánh giá giá trị nhạy cảm của dữ liệu mình giao phó ở mức nào. Nếu bạn không quan tâm cả hai điểm, PQC có thể là lãng phí thời gian. Nhưng khi tôi vận hành hệ thống mật mã, tôi không có quyền xem dữ liệu người dùng là không quan trọng.
Hầu hết thảo luận hiện tại liên quan đến trao đổi khóa. Trao đổi khóa không diễn ra thường xuyên nên overhead nhìn chung không gánh nặng. Tóm tắt các điểm chính:
Ngoài thông tin công khai, việc các cơ quan tình báo của chúng ta khuyến nghị triển khai PQ cho hệ thống cần giữ bí mật trên 20 năm cũng là một điểm đáng chú ý. Chia sẻ thêm: năm 2014, cơ quan tình báo Hà Lan nói giai đoạn 2030~2040 khả năng xuất hiện máy tính lượng tử không cao nhưng không thể bỏ qua; năm 2021 họ cho rằng trước 2030 khả năng đó thấp nhưng vẫn cần chú ý. Năm 2025, 18 quốc gia đã cùng đưa ra thông cáo chung khuyến nghị phòng thủ trước cuộc tấn công "store now, decrypt later" đến năm 2030 (tài liệu1, tài liệu2, thông cáo chung).
Ứng dụng Secretive trên macOS lưu SSH key trong Secure Enclave. Với các thuật toán hiện hỗ trợ, nó đang dùng ecdsa-sha2-nistp256, nhưng có vẻ Secure Enclave chưa hỗ trợ thuật toán PQ. Liệu có thể ghép hybrid như mlkem768×ecdsa-sha2-nistp256, để phần ECDSA do SE xử lý, không? (Secretive GitHub)
Tôi nghĩ công cụ ssh-audit (liên kết) nên bổ sung mục kiểm tra các thuật toán lý thuyết (PQC hybrid). Có vẻ ngay cả khi khóa cứng một số thuật toán vẫn có thể vẫn hiện "A". Hiện tôi chỉ dùng chả-chả.
Tôi muốn biết liệu có thuật toán hybrid PQC cho OpenSSH nào phù hợp chuẩn FIPS 140-3 không.
Cách đi trước để chuẩn bị là hợp lý, nhất là khi thay khóa chỉ là thao tác tương đối nhỏ. Tôi cũng tò mò giữa hai lựa chọn nào mạnh hơn, có lẽ 512 mạnh hơn?
Hai thuật toán này hoàn toàn khác nhau. mlkem768x25519-sha256 là cơ chế hybrid trộn trao đổi khóa ML-KEM hậu lượng tử với ECDH/x25519 cổ điển. Do đó, nếu một bên bị hỏng, vẫn giữ được mức an toàn kiểu cũ. Phiên bản 256 (mlkem768) thực chất ra muộn hơn phiên bản 512 (sntrup761). OpenSSH đã hỗ trợ sntrup761x25519-sha512 từ 9.0, và hỗ trợ mlkem768x25519-sha256 từ 9.9.
Vấn đề 256-bit/512-bit hiện không cần lo ngay. Chưa có động lực nào đủ lớn để duyệt hết không gian 128-bit, và cũng chưa có máy tính như vậy. Chưa phải thời điểm phải bận tâm.
mlkem hiện là mặc định hợp lý. Chuẩn ngành đang hội tụ theo hướng này.
Tôi đang cân nhắc chuyển ứng dụng microblog/chat chạy trên terminal của mình sang hướng an toàn hậu lượng tử. Sau khi xem nhiều lần phỏng vấn Paul Durov và nghe chuyện ông ấy trải qua, tôi càng cân nhắc hơn.
Tôi băn khoăn liệu sntrup761x25519-sha512 hay mlkem768x25519-sha256 cái nào tốt hơn.
MLKEM768 có hiệu năng tốt hơn và khóa nhỏ hơn. SNTRUP761 có giả thiết an toàn chặt chẽ hơn và khả năng chống các đợt tấn công mật mã phân tích tiềm tàng tốt hơn.
NTRU Prime (sntrup) là thứ đã được đưa vào vì lý do lịch sử (lúc đó chưa có mlkem). Dùng cái nào cũng ổn; sntrup giống như thời GPG từng mặc định CAST, giống một mặc định của thời điểm.
Tôi muốn biết khi nào sẽ có chứng chỉ PQ (cho khóa xác thực host/user).
Việc đi trước trong các thử nghiệm như vậy là điều tốt. Dù tương lai có giải pháp an toàn hơn xuất hiện, nếu không làm cho tình hình tệ hơn, thì nỗ lực hiện tại vẫn có ý nghĩa.