紅帽 OpenShift 4.22 預設支援 ML‑KEM，TLS 1.3 可使用抗量子金鑰交換

Red Hat（紅帽）在最新的 OpenShift 4.22 版本中，將 模組格基式金鑰封裝機制（ML‑KEM） 設為預設功能。這意味著，支援 TLS 1.3 的連線在協商過程中，會自動採用 X25519 + MLKEM768 的混合式金鑰建立機制，無需額外設定，即可使用抗量子密碼演算法產生會話金鑰，降低「先擷取流量、後以量子電腦解密」的風險。

背景與技術脈絡

PQC（後量子密碼學）：針對未來量子電腦可能破解傳統公鑰演算法（如 RSA、ECC）而研發的加密技術。
ML‑KEM：NIST 後量子標準化比賽的首選金鑰封裝機制，屬於「格基」類演算法，具備較高的安全性與效能。
支援堆疊：OpenShift 能夠使用 ML‑KEM，得益於底層軟體的逐步升級——Go 1.24 已內建 ML‑KEM 與 X25519MLKEM768 混合金鑰；RHEL 9.8 與 10.2 加入 ML‑KEM 支援；而 OpenShift 控制層自 4.19 起即支援 TLS 1.3。

相較於一年前仍處於藍圖階段的概念，ML‑KEM 現已成為 OpenShift 4.22 的預設功能，顯示紅帽在量子抗性部署上的落實速度。

企業層面的影響

即時防護：現有的 TLS 1.3 服務只要啟用相容的金鑰交換，即可自動受益於抗量子保護，無需更換憑證。
降低升級成本：ML‑KEM 不需要重新簽發 X.509 憑證，企業可在不中斷服務的情況下提升安全等級。
未來挑戰：紅帽已規畫將 ML‑DSA（抗量子數位簽章演算法） 納入生態系。與金鑰封裝不同，ML‑DSA 牽涉到憑證、容器映像檔、程式碼簽章等多項資產，必須同步更新驗證元件，過渡期間將同時維持傳統與 ML‑DSA 憑證鏈。

後續建議與展望

在 ML‑DSA 完全導入前，紅帽建議企業先盤點密碼學資產：包括應用程式產生的憑證、CI/CD 流程使用的簽章金鑰、以及身份提供者發放的 JWT 權杖。了解憑證數量、輪替機制與失敗風險，才能在未來重新核發憑證時避免服務中斷。

展望未來，隨著更多底層元件支援 ML‑DSA，OpenShift 將能提供完整的抗量子 金鑰交換 + 數位簽章 解決方案，為企業的雲原生環境打造從傳輸層到供應鏈的全方位量子抗性防護。對於關注資安的決策者而言，現在正是把握 OpenShift 4.22 先行優勢、規劃量子安全路線圖的最佳時機。

紅帽 OpenShift 4.22 預設支援 ML‑KEM，TLS 1.3 可使用抗量子金鑰交換