本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
搭配 使用混合式後量子金鑰交換 AWS Transfer Family
Transfer Family 支援 Secure Shell (SSH) 通訊協定的混合式後量子金鑰建立選項。需要建立後量子金鑰,因為已經可以記錄網路流量,並儲存它以供量子電腦未來解密,這稱為 store-now-harvest-later 攻擊。
當您連線到 Transfer Family 時,您可以使用此選項進行安全的檔案傳入和傳出 Amazon Simple Storage Service (Amazon S3) 儲存或 Amazon Elastic File System (Amazon EFS)。SSH 中的後量子混合金鑰建立引入後量子金鑰建立機制,它與傳統金鑰交換演算法搭配使用。使用傳統密碼套件建立的 SSH 金鑰可安全防範目前技術的暴力破解攻擊。不過,未來出現大規模量子運算之後,傳統加密並不預期會保持安全。
如果您的組織依賴透過 Transfer Family 連線傳遞的資料的長期機密性,您應該考慮在大規模量子電腦可供使用之前遷移到量子後密碼編譯的計劃。
為了保護今天加密的資料免受潛在的未來攻擊, AWS 正與密碼編譯社群參與開發量子抗性或後量子演算法。我們已在 Transfer Family 中實作混合式後量子金鑰交換密碼套件,結合傳統元素和後量子元素。
這些混合密碼套件可在大多數 AWS 區域中用於您的生產工作負載。不過,由於混合式密碼套件的效能特性和頻寬需求與傳統金鑰交換機制不同,我們建議您在 Transfer Family 連線上測試它們。
在後量子密碼編譯安全部落格文章中進一步了解後量子密碼編譯
內容
關於 SSH 中的後量子混合金鑰交換
Transfer Family 支援後量子混合金鑰交換密碼套件,其同時使用傳統橢圓曲線 Diffie-Hellman (ECDH)
用戶端和伺服器仍會執行 ECDH 金鑰交換。此外,伺服器會將後量子共用秘密封裝至用戶端的後量子 KEM 公有金鑰,該金鑰會在用戶端的 SSH 金鑰交換訊息中公告。此策略結合了傳統金鑰交換的高保證與建議的後量子金鑰交換的安全性,有助於確保只要 ECDH 或後量子共用秘密無法中斷,交握都會受到保護。
後量子混合金鑰建立如何在 Transfer Family 中運作
AWS 最近宣布支援 SFTP 檔案傳輸中的後量子金鑰交換 AWS Transfer Family。Transfer Family 使用 SFTP 和其他通訊協定安全地將business-to-business檔案傳輸擴展至 AWS 儲存服務。SFTP 是透過 SSH 執行的檔案傳輸通訊協定 (FTP) 更安全版本。Transfer Family 的後量子金鑰交換支援提高透過 SFTP 傳輸資料的安全標準。
Transfer Family 中的後量子混合金鑰交換 SFTP 支援包括結合後量子演算法 ML-KEM-768 和 ML-KEM-1024,以及透過 P256, P384 或 Curve25519 曲線的 ECDH。下列對應的 SSH 金鑰交換方法會在後量子混合 SSH 金鑰交換草案
-
mlkem768nistp256-sha256 -
mlkem1024nistp384-sha384 -
mlkem768x25519-sha256
為什麼選擇 ML-KEM?
AWS 致力於支援標準化、可互通的演算法。ML-KEM 是唯一由 NIST 後量子密碼編譯專案標準化和核准的後量子
作為此承諾的一部分, AWS 已提交提案草案給 IETF,以取得量子後密碼編譯,該密碼編譯結合了 ML-KEM 和 NIST 核准的曲線,例如 P256 for SSH。為了協助增強客戶的安全性,SFTP 和 SSH 中的後量子金鑰交換 AWS 實作遵循該草案。我們計劃支援未來的更新,直到 IETF 採用我們的提案並成為標準。
新的金鑰交換方法 (列於第 節後量子混合金鑰建立如何在 Transfer Family 中運作) 可能會隨著草稿朝向標準化發展而變更。
注意
目前, TLS 中的後量子演算法支援可用於後量子混合金鑰交換 AWS KMS (請參閱搭配 使用混合後量子 TLS AWS KMS)AWS Certificate Manager、 和 AWS Secrets Manager API 端點。
量子後混合 SSH 金鑰交換和密碼編譯要求 (FIPS 140)
對於需要 FIPS 合規的客戶,Transfer Family 使用 FIPS 140 認證的開放原始碼密碼編譯程式庫 AWS-LC,在 SSH 中提供 AWS FIPS 核准的密碼編譯。TransferSecurityPolicy-FIPS-2025-03 in Transfer Family 中支援的後量子混合金鑰交換方法是根據 NIST 的 SP 800-56Cr2 (第 2 節)
在 Transfer Family 中測試後量子混合金鑰交換
本節說明測試量子後混合金鑰交換所採取的步驟。
-
遵循上述草案規格中的指引,使用支援量子後混合金鑰交換的 SFTP 用戶端 (例如 設定支援後量子混合金鑰交換的 SFTP 用戶端)。
-
使用 Transfer Family 伺服器傳輸檔案。
在 SFTP 端點上啟用後量子混合金鑰交換
您可以在 Transfer Family 中建立新的 SFTP 伺服器端點時選擇 SSH 政策,或在現有的 SFTP 端點中編輯密碼編譯演算法選項。下列快照顯示 AWS Management Console 您更新 SSH 政策的 範例。
支援後量子金鑰交換的 SSH 政策名稱為 TransferSecurityPolicy-2025-03 和 TransferSecurityPolicy-FIPS-2025-03。如需 Transfer Family 政策的詳細資訊,請參閱 AWS Transfer Family 伺服器的安全政策。
設定支援後量子混合金鑰交換的 SFTP 用戶端
在 SFTP Transfer Family 端點中選取正確的後量子 SSH 政策後,您可以在 Transfer Family 中實驗後量子 SFTP。在本機系統上安裝要測試的最新 OpenSSH 用戶端 (例如 9.9 版)。
注意
請確定您的用戶端支援先前列出的一或多個 ML-KEM 演算法。您可以執行此命令來檢視 OpenSSH 版本的支援演算法:ssh -Q kex。
您可以使用後量子混合金鑰交換方法,執行範例 SFTP 用戶端來連線至 SFTP 端點 (例如 s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com),如下列命令所示。
sftp -v -o \ KexAlgorithms=mlkem768x25519-sha256 \ -iusername_private_key_PEM_file\username@server-id.server.transfer.region-id.amazonaws.com
在先前的命令中,將下列項目取代為您自己的資訊:
-
以 SFTP 使用者的私有金鑰 PEM 編碼檔案取代
username_private_key_PEM_file -
以 SFTP 使用者名稱取代
使用者名稱 -
將
server-id取代為 Transfer Family 伺服器 ID -
將
region-id取代為 Transfer Family 伺服器所在的實際區域
在 SFTP 中確認後量子混合金鑰交換
若要確認在 SFTP 到 Transfer Family 的 SSH 連線期間使用後量子混合金鑰交換,請檢查用戶端輸出。或者,您可以使用封包擷取程式。如果您使用 OpenSSH 9.9 用戶端,輸出看起來應該類似以下內容 (為了簡潔起見而省略不相關的資訊):
% sftp -o KexAlgorithms=mlkem768x25519-sha256 -v -o IdentitiesOnly=yes -iusername_private_key_PEM_fileusername@s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com OpenSSH_9.9p2, OpenSSL 3.4.1 11 Feb 2025 debug1: Reading configuration data /Users/username/.ssh/config debug1: /Users/username/.ssh/config line 146: Applying options for * debug1: Reading configuration data /Users/username/.ssh/bastions-config debug1: Reading configuration data /opt/homebrew/etc/ssh/ssh_config debug1: Connecting to s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com [xxx.yyy.zzz.nnn] port 22. debug1: Connection established. [...] debug1: Local version string SSH-2.0-OpenSSH_9.9 debug1: Remote protocol version 2.0, remote software version AWS_SFTP_1.1 debug1: compat_banner: no match: AWS_SFTP_1.1 debug1: Authenticating to s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com:22 as 'username' debug1: load_hostkeys: fopen /Users/username/.ssh/known_hosts2: No such file or directory [...] debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: mlkem768x25519-sha256 debug1: kex: host key algorithm: ssh-ed25519 debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256-etm@openssh.com compression: none debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256-etm@openssh.com compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: SSH2_MSG_KEX_ECDH_REPLY received debug1: Server host key: ssh-ed25519 SHA256:Ic1Ti0cdDmFdStj06rfU0cmmNccwAha/ASH2unr6zX0 [...] debug1: rekey out after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey in after 4294967296 blocks [...] Authenticated to s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com ([xxx.yyy.zzz.nnn]:22) using "publickey". debug1: channel 0: new session [client-session] (inactive timeout: 0) [...] Connected to s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com. sftp>
輸出顯示使用後量子混合mlkem768x25519-sha256方法進行用戶端交涉,並成功建立 SFTP 工作階段。