新聞

網際網路工程任務小組（IETF）今年8月發布RFC 10024，正式為TLS 1.3訂定3種結合傳統金鑰交換技術與後量子密碼學（Post-Quantum Cryptography，PQC）演算法的混合式金鑰建立機制。由於相關技術已陸續導入主流瀏覽器及雲端服務，企業規畫PQC轉型時，除了確認產品是否支援相關混合式金鑰交換機制，也需要了解實際TLS連線採用的金鑰交換機制。

混合式金鑰交換讓TLS連線同時採用傳統與抗量子密碼演算法，而不是直接以後者取代前者。RFC 10024將橢圓曲線Diffie-Hellman暫時性金鑰交換（ECDHE），與模組格基式金鑰封裝機制（Module-Lattice-Based Key-Encapsulation Mechanism，ML-KEM）結合，並將兩者產生的共享祕密用於建立TLS連線金鑰。即使其中一種演算法不再安全，只要另一種仍安全，便可維持混合式金鑰交換的安全性。

RFC 10024共同作者、後量子密碼學業者PQShield的Krzysztof Kwiatkowski指出，Chrome、Firefox等主流瀏覽器及AWS部分雲端服務早在RFC 10024發布前就已採用混合式PQC金鑰交換。Google Cloud也已在部分API端點提供混合式PQC金鑰交換，部分負載平衡服務也可啟用這項機制。Oracle今年9月發布的Java 27及AWS隨後推出的Amazon Corretto 27，也都納入JEP 527，支援TLS 1.3混合式PQC金鑰建立機制。

不過，產品支援混合式PQC金鑰交換，不代表企業所有TLS連線都已採用相同機制。以透過內容傳遞網路（CDN）提供網站服務的企業為例，使用者與CDN之間，以及CDN與企業原始伺服器（Origin Server）之間，可分別建立TLS連線，並採用不同的金鑰交換機制。因此，即使使用者與CDN之間已採用混合式PQC金鑰交換，也不能據此判斷CDN與原始伺服器之間是否採用相同機制。

企業評估TLS的PQC轉型進度時，也需要注意金鑰交換與伺服器身分驗證的差異。RFC 10024規範的是TLS 1.3的混合式金鑰交換，並未涵蓋伺服器身分驗證使用的數位憑證及數位簽章。即使TLS連線已採用混合式PQC金鑰交換，伺服器仍可能使用傳統數位簽章演算法進行身分驗證，因此不能僅憑金鑰交換已採用PQC，就認定伺服器身分驗證也已完成PQC轉型。