- 10024：這份 IETF 標準文件的編號，正式名稱為 RFC 10024。
- 3 種：RFC 10024 為 TLS 1.3 訂定的混合式金鑰建立機制數量。
- TLS 1.3：這次標準化的適用版本，規範的是金鑰交換環節。
- 今年 8 月：RFC 10024 的發布時間。
- 今年 9 月：Oracle 發布 Java 27、納入 JEP 527 支援混合式金鑰建立的時間點。
網際網路工程任務小組（IETF）在今年 8 月發布 RFC 10024，正式為 TLS 1.3 訂定 3 種結合傳統金鑰交換技術與後量子密碼學演算法的混合式金鑰建立機制。這意味著企業在規畫抗量子轉型時，終於有了一份正式的標準文件可以依循。
混合式金鑰交換的核心概念是「雙保險」：TLS 連線同時採用傳統與抗量子密碼演算法，而不是直接以後者取代前者。RFC 10024 把橢圓曲線 Diffie-Hellman 暫時性金鑰交換（ECDHE），與模組格基式金鑰封裝機制（ML-KEM）結合起來，兩者產生的共享祕密共同用於建立 TLS 連線金鑰。好處是：即使其中一種演算法未來被證明不安全，只要另一種仍然安全，整體連線的安全性就能維持。
這份標準的共同作者、後量子密碼學業者 PQShield 的 Krzysztof Kwiatkowski 指出，Chrome、Firefox 等主流瀏覽器，以及 AWS 的部分雲端服務，早在 RFC 10024 發布之前就已經採用混合式金鑰交換。Google Cloud 也已在部分 API 端點提供這項機制，部分負載平衡服務同樣可以啟用。換句話說，標準的發布是在追認一個業界已經開始落地的實務。
標準發布後，實作支援也在跟進。Oracle 在今年 9 月發布的 Java 27，以及 AWS 隨後推出的 Amazon Corretto 27，都納入了 JEP 527，支援 TLS 1.3 的混合式金鑰建立機制。對企業來說，這降低了導入門檻：主流執行環境開始內建支援，不必再靠額外的函式庫或客製化實作。
不過，對企業而言，產品支援混合式金鑰交換，不等於所有 TLS 連線都已採用相同機制。舉例來說，透過內容傳遞網路（CDN）提供網站服務的企業，使用者與 CDN 之間、CDN 與企業原始伺服器之間會分別建立 TLS 連線，兩段連線可以採用不同的金鑰交換機制。因此，即使使用者到 CDN 這段已經是混合式金鑰交換，也不能據此推定 CDN 到原始伺服器那段同樣採用。企業在評估轉型進度時，必須逐段確認實際連線採用的機制。
還有一個常見的誤解需要釐清。RFC 10024 規範的是 TLS 1.3 的混合式「金鑰交換」，並未涵蓋伺服器身分驗證所用的數位憑證與數位簽章。也就是說，即使一條 TLS 連線已經採用混合式金鑰交換，伺服器仍可能用傳統數位簽章演算法做身分驗證。不能只因為金鑰交換完成了抗量子升級，就認定整條連線的身分驗證環節也完成了轉型。
對正在規畫後量子轉型的企業來說，RFC 10024 的發布提供了一個明確的檢查起點：先確認產品是否支援這 3 種混合式機制，再逐段盤點實際 TLS 連線採用的金鑰交換方式，最後別忘了身分驗證環節是另一個獨立的戰場。
對企業與政府機關來說，後量子轉型已經不是遙遠的議題。金融、醫療、電信等高度監管產業，資料的保密期限往往長達數十年，「先蒐集、後解密」的威脅讓金鑰交換的抗量子升級變得迫切。RFC 10024 的發布，等於給了這些產業的資安團隊一份明確的採購與驗收依據：要求供應商支援標準化的混合式機制，而不是各自為政的私有實作。
不過，標準只是起點。企業在導入時還要面對效能開銷、舊設備相容性、憑證體系升級等實務挑戰。資安團隊可以從盤點開始：先弄清楚哪些系統的 TLS 連線承載長期敏感資料，再依風險高低排定升級順序，逐步把混合式金鑰交換納入基礎架構的預設配置。
