AWS 後量子密碼學遷移計劃

亞馬遜網路服務 (Amazon Web Services, AWS) 正在轉向後量子密碼學 (post-quantum cryptography, PQC)。就像 AWS 的其他安全和合規功能一樣，我們將把 PQC 作為我們共同責任模型的一部分來提供。這意味著某些 PQC 功能將自動為所有客戶啟用，而其他功能則是客戶可以選擇實施的選項，以幫助滿足他們的需求。這一過渡將分階段進行，首先針對在不受信任的網路（如互聯網）上進行通信的系統。

大型量子電腦的威脅，有時被稱為與密碼學相關的量子電腦，可能會破壞當前使用的公鑰密碼算法。這些算法在大多數通信協議和數位簽名方案中被使用。在過去的八年裡，AWS 與其他行業領導者、政府機構和學術界一起，倡導、研究和提出抵抗量子計算的新公鑰密碼算法。因為客戶依賴 AWS 進行的密碼學來保護他們的數據，我們早期參與這項工作，以最小化最終轉向 PQC 的努力和影響。雖然目前沒有證據顯示存在足夠強大的量子電腦能夠破壞 AWS 使用的公鑰密碼學，但我們不會等到那時。我們寧願現在就採取保護措施，以保護客戶數據的安全。

這篇文章總結了 AWS 在轉向 PQC 的過程中目前的狀況，並概述了我們的前進路徑。

在過去五年中，我們在開源庫和安全關鍵服務中部署了美國國家標準與技術研究所 (NIST) 評估的 PQC 算法的早期版本，讓客戶測試轉向 PQC 的性能影響。例如，我們的開源算法實現庫 (AWS-LC)、我們的 TLS 實現 (s2n) 和核心安全服務如 AWS 密鑰管理服務 (AWS KMS)、AWS 秘密管理器和 AWS 證書管理器 (ACM) 自 2019 年以來就已經實現了 NIST 提出的 PQC 算法。

在 2024 年 8 月 13 日，NIST 宣布了三個新的後量子密碼學 (PQC) 算法，作為聯邦信息處理標準 (FIPS)。這是 NIST 自 2016 年開始的 PQC 標準化過程的結果。AWS 的員工是許多提議方案的貢獻者，包括這三個新的 FIPS 標準。

我們的許多客戶一直在跟踪標準化過程，包括美國政府的商業國家安全算法 (CNSA) 套件 2.0 對 PQC 採用的要求，以及歐洲委員會關於過渡到後量子密碼學的協調實施路線圖的建議。

現在，第一輪 PQC 算法已經標準化，我們可以開始實施它們以提供長期支持。以下是我們實施 PQC 的方法，以便為依賴我們服務和開源工具進行密碼操作的客戶提供無縫過渡。

AWS 將在未來幾年內採取多層次的方法來轉向 PQC。我們將同時進行的工作流程定義為：

工作流程 1：現有系統的清單，識別和開發新標準，測試和遷移計劃。雖然第一組算法標準已經發布，但還有其他標準將定義如何在特定應用和協議中集成 PQC，以確保互操作性。
工作流程 2：在公共 AWS 端點上集成 PQC 算法，以提供傳輸到 AWS 的客戶數據的長期保密性。
工作流程 3：將 PQC 簽名算法集成到 AWS 密碼服務中，使客戶能夠部署新的後量子長期信任根，用於軟體、韌體和文件簽名等功能。
工作流程 4：將 PQC 簽名算法集成到 AWS 服務中，以便在基於會話的身份驗證中使用後量子簽名，例如伺服器和客戶端證書驗證。

工作流程 1

我們將這裡的工作視為我們遷移計劃的一個持續方面。這已經告知了我們的整體策略，並根據客戶的需求優先考慮了我們的遷移。

與客戶類似，我們必須檢查所有使用密碼學的地方，以確定哪些實現需要遷移以及優先級。 我們做出的重要決定之一是更專注於傳輸中的加密，而不是靜態加密。公鑰（非對稱）密碼學是傳輸中加密的基礎，因為它使兩方能夠在不受信任的網路上協商共享秘密——今天的傳統公鑰算法正面臨被與密碼學相關的量子電腦攻破的風險。根據業界的共識，與 256 位對稱密鑰密碼學相比，與密碼學相關的量子電腦的風險並不需要緩解。由於 AWS 中靜態數據是使用 256 位對稱密碼學進行加密的，我們認為不需要重新加密現有客戶數據或更改我們用於加密未來數據的對稱算法和密鑰。

雖然對稱加密密鑰和算法的安全性不受與密碼學相關的量子電腦的影響，但在某些情況下，公鑰算法用於協商共享的對稱密鑰，因此存在對稱密鑰可能被攻破的風險。我們將轉向 PQC 的 AWS 中公鑰密碼學的第一個使用案例正是這種情況——我們在客戶與 AWS 服務的公共端點之間協商共享的對稱密鑰。客戶用來與 AWS 服務進行通信的網路通常不在 AWS 或客戶的控制之下，因此容易受到壞人捕獲數據的影響，然後使用與密碼學相關的量子電腦進行暴力破解。工作流程 2 對這一計劃進行了更詳細的討論。

在 AWS 中，我們將轉向 PQC 的公鑰密碼學的下一個使用案例是我們提供創建一對密鑰的能力，該密鑰作為長期信任根，通常用於對軟體、韌體或文件進行數位簽名。這些類型的密鑰對可能需要在未來多年內有效，因為它們不容易更新。想想衛星、遊戲主機和其他物聯網設備上的韌體，在設備的使用壽命內可能無法更換公鑰對和簽名算法代碼。工作流程 3 對這一計劃進行了更詳細的討論。

我們將轉向 PQC 的 AWS 中公鑰密碼學的最後一個領域是我們提供創建一對密鑰的能力，該密鑰作為短期信任根，通常用於對單一交易、網路會話或其他短暫消息進行數位簽名。這種用例的最常見例子是數位證書用於在 TLS 會話中驗證伺服器或客戶端。你可能會認為工作流程 2 和 3 處理了 TLS 會話中會話密鑰協商和數位簽名的風險，那麼還剩下什麼需要保護的呢？事實上，公鑰密碼學用於使用數位證書互相驗證兩方以交換消息的方式，嚴重依賴於標準和互操作性，這涉及到大量的互聯網基礎設施。讓業界就這些標準達成一致並測試互操作性將需要時間，直到這個工作流程完成。工作流程 4 對這一計劃進行了更詳細的討論。

我們已經談到了 AWS 如何進行其密碼學清單以及我們的 PQC 遷移計劃。如果你不將所有密碼操作委託給 AWS，你應該做什麼來準備？雖然沒有單一的方法適合所有應用和行業，但以下是一些我們貢獻或用作我們工作的建議的資源：

雖然對你來說，對組織內的密碼學進行清單以優先考慮 PQC 遷移可能是一個多年的工作，但我們有幾個短期的戰術建議可以考慮。首先，努力確保你能夠靈活地分發更新版本的軟體。這是任何組織在漏洞管理和軟體生命週期維護中的關鍵能力。這一能力將是採用我們發布的新 PQ 版本的 AWS 命令列介面 (AWS CLI) 和 AWS 軟體開發工具包 (AWS SDK) 所必需的。你可能還需要更新使用 TLS 或其他與 AWS 服務通信的密碼實現的第三方軟體組件，以確保你能夠利用我們提供的 PQC。

其次，我們強烈建議你開始一個全面的計劃，在整個組織內採用 TLS 1.3。這一版本及以後的 TLS 不僅提供了使用傳統公鑰密碼學的安全性和性能改進，還嚴格要求能夠使用 PQC。即使你最近在客戶端和伺服器上更新到 TLS 1.2，你仍然需要為你的系統準備 PQC 的未來。

工作流程 2

客戶使用基於公鑰密碼學的協議與雲服務進行通信。這些協議（如 TLS）幫助確保客戶的通信是保密的，並且在傳輸過程中無法被更改。為了保護我們客戶對長期保密性的需求，我們開創了一種稱為混合後量子密鑰協商的機制。混合後量子密鑰協商將經典的密鑰交換算法橢圓曲線迪菲-赫爾曼 (ECDH) 與後量子密鑰封裝方法（如新標準化的 ML-KEM 算法）結合在一起。結果是將兩個密鑰結合以建立會話通信密鑰，從而加密網路流量。對手需要破壞這兩個公鑰原語（ECDH 和 ML-KEM）才能破壞混合密鑰協商提供的保密性。

AWS 已經在 AWS-LC 中實施了 ML-KEM，這是我們的開源 FIPS-140-3 驗證的密碼庫。AWS-LC 是整個 AWS 使用的核心密碼庫。與此工作流程相關的是，它用於 s2n-tls，我們的開源 TLS 實現，廣泛用於具有 HTTPS 端點的 AWS 服務。

網際網路工程任務組 (IETF) 正在最終確定包含後量子密碼學的 TLS 協議標準。完成該標準後，AWS 將更新 s2n-tls 以符合這些新規範。在我們將 AWS-LC 中的 ML-KEM 實現與基於 IETF 標準的 s2n 版本集成後，我們將開始在所有提供 HTTPS 接口的 AWS 公共端點上部署這個 s2n 版本。這代表了大多數 AWS 服務，通常通過 AWS SDK 或 AWS CLI 訪問。提供其他接口（如 SFTP、IPsec 或 SSH）的公共端點的 AWS 服務將在 IETF 等標準機構發布這些協議的實現指導後獲得 ML-KEM 支持。

作為將 AWS 管理的服務端點遷移到通過 TLS 的 PQC 的一部分，我們還將啟用為你的工作負載提供伺服器端 TLS 終止的服務，包括彈性負載平衡 (Elastic Load Balancing, ELB)、亞馬遜 API 網關 (Amazon API Gateway) 和亞馬遜 CloudFront。這將允許你使用一直在這些服務中使用的相同數位證書，並讓它們代表你協商伺服器端 TLS 會話，使用 ML-KEM。這將提供你 TLS 會話的長期保密性，而無需你升級底層證書本身到某個尚未定義的 PQC 標準。

為了進一步加強向 ML-KEM 的過渡，AWS 正在與關鍵行業倡議合作，包括國家網絡安全卓越中心 (NCCoE) 的後量子密碼學遷移、Linux 基金會的後量子密碼學聯盟和 Rust TLS 項目。這些合作對於確保不同實現的 PQC 解決方案之間的無縫互操作性至關重要。

工作流程 3

我們的許多客戶製造帶有韌體、操作系統和預裝第三方應用的系統。這些組件使用基於公鑰的信任根進行加密簽名，以維護系統在向最終用戶提供服務時的安全性和真實性。其中一些系統，例如連接到機頂盒的智慧電視，可能在安裝後的十年或更長時間內無法連接到互聯網。

此外，某些客戶必須在製造過程中將長期信任根嵌入到硬體中，這一過程無法逆轉或更新。對於設計用於運行超過 10 年的設備，這些初始信任根的安全性必須保持穩健，即使在與密碼學相關的量子電腦可用的情況下。

為了滿足對於代碼和文件簽名的長期信任根的需求，AWS 將採用 ML-DSA，一種被認為對擁有與密碼學相關的量子電腦的對手是安全的新的數位簽名算法。我們將首先在 AWS 密鑰管理服務 (AWS KMS) 中提供 ML-DSA 作為一項功能，使客戶能夠生成和使用 PQC 密鑰作為簽名操作的信任根，這些操作在 AWS KMS 中的 FIPS-140-3 Level 3 驗證的硬體安全模組 (HSMs) 中進行。這一整合代表了我們 PQC 路線圖中的一個重要里程碑，為客戶提供建立安全的、抗量子攻擊的信任根和身份驗證的能力，以滿足他們的長期安全需求。

這一長期的視角強調了早期實施 PQC 的重要性，幫助確保系統在整個操作生命週期內保持安全，即使它們長時間斷開連接。雖然亞馬遜將利用 AWS KMS 的這一能力來保護我們自己的信任根，但我們鼓勵你考慮這一能力如何幫助你做到同樣的事情。

工作流程 4

在工作流程 2 中，我們討論了如何部署 PQC 以保護共享通信通道中數據的保密性。為了完成這個故事，仍然需要一種方法來保護在後量子世界中通信通道上伺服器和客戶端身份的真實性。

數位簽名今天用於在 TLS 和 SSH 等網路協議中進行最終實體身份驗證。客戶使用來自受信任證書頒發機構 (CA) 的證書，該證書通過數位簽名將公鑰與身份綁定，以驗證服務和客戶端端點。雖然今天可用的一些 PQC 標準（例如 ML-DSA）可以與證書一起實施，以應對後量子風險，但在證書頒發機構和使用數位證書的系統之間進行進一步的標準化和互操作性測試之前，這項工作無法開始。這一延遲的主要原因與今天簽名消息的接收者如何驗證公信證書有關。在 TLS 協議中，例如，連接到伺服器的客戶端需要驗證每個證書中嵌入的所有 PQC 簽名，以確定伺服器是否真實。這些簽名的格式以及證書的發放和管理過程由證書頒發機構 (CA) 瀏覽器論壇管理。互聯網瀏覽器製造商和 CA 瀏覽器論壇的證書發行者成員需要確定 PQC 將如何用於證書的發放和驗證，然後才能安全地在 TLS 會話中使用它們。亞馬遜信任服務是一家證書發行者，也是 CA 瀏覽器論壇的成員；我們正在參與推動這些標準，以加快互操作性測試。

雖然 PQC 故事正在為公信證書的最終確定而進行，但 AWS 私有 CA 服務並不一定因相同原因而被阻止使用 PQC 算法（如 ML-DSA）發放私有信任證書。我們將能夠這樣做，因為私有信任證書不必嚴格遵循 CA 瀏覽器論壇發布的規則。使用私有信任證書的客戶在控制兩端軟體時，有自由實施 PQC 身份驗證方案的客戶端和伺服器部分。當工作流程 3 完成並且 ML-DSA 可用於 AWS KMS 的簽名操作時，AWS 私有 CA 將考慮為那些準備好在其私有網路通道中採用它的客戶提供 PQC 作為證書發放的一部分。我們的開源 AWS-LC 和 s2n 解決方案將可供我們的客戶在需要時實施 PQC 證書驗證功能。

結論

在這篇文章中，我們介紹了 AWS 如何作為我們共同責任模型的一部分遷移到 PQC。我們還為你提供了如何開始你的 PQC 遷移策略的指導，以及你可以期待 AWS 提供的策略部分。未來的道路將帶來新的挑戰和機會，隨著行業向新的密碼算法遷移。要獲取有關我們 PQC 遷移的更多信息、博客文章和定期更新，請持續關注 AWS 後量子密碼學頁面。

如果你想了解更多有關 AWS 的後量子密碼學，請聯繫後量子密碼學團隊。

如果你對這篇文章有反饋，請在下面的評論區提交意見。如果你對這篇文章有問題，請在 AWS 安全、身份與合規的 re:Post 上開始一個新主題或聯繫 AWS 支持。

Melanie Goldsborough
Melanie 是 AWS 的全球高級安全專家，擁有超過 20 年的情報和技術經驗。她為安全服務制定全球市場策略，專注於公共部門組織。Melanie 的專業知識涵蓋內容開發、高層參與和計劃執行，以增強全球客戶和合作夥伴的安全實踐。

Peter M. O’Donnell
Peter 是 AWS 的首席解決方案架構師 (SA)，專注於安全、風險和合規，並與戰略客戶團隊合作。他在 AWS 擔任 SA 已經 9.5 年，支持公司一些最大的和最複雜的戰略客戶，涉及安全和安全相關主題，包括數據保護、密碼學、身份、威脅建模、合規、安全文化、CISO 參與等。