使用混合后量子密钥交换 AWS Transfer Family - AWS Transfer Family
关于 SSH 中的后量子混合密钥交换使用方法测试方法

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

使用混合后量子密钥交换 AWS Transfer Family

Transfer Family 支持安全外壳 (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 支持后量子混合密钥交换密码套件，该套件同时使用经典的 El liptic Curve Diffie-Hellman (ECDH) 密钥交换算法和 ML- KEM。ML-KEM是一种后量子公钥加密和密钥建立算法，美国国家标准与技术研究所（NIST）已将其指定为其第一个标准的后量子密钥协议算法。

客户端和服务器仍进行 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 后量子密码学项目标准化和批准的唯一一种后量子密钥交换算法。标准机构已经在将 ML-KEM 整合到协议中。 AWS 已在某些 AWS API 端点中支持 TLS 中的 ML-KEM。

作为该承诺的一部分， AWS 已向IETF提交了一份后量子加密提案草案，该提案将ML-KEM与NIST批准的曲线（例如用于SSH的P256）相结合。为了帮助增强客户的安全性，在 SFTP 和 SSH 中 AWS 实施后量子密钥交换遵循了该草案。在我们的提案被 IETF 采纳并成为标准之前，我们计划支持未来更新。

随着草案向标准化发展，新的密钥交换方法（列于本节后量子混合密钥创建如何在 Transfer Family 中运行）可能会发生变化。

注意

后量子算法支持在 TLS 中用于后量子混合密钥交换 AWS KMS （参见使用混合后量子 TLS AWS KMS）和 AWS Secrets Manager API AWS Certificate Manager端点。

后量子混合 SSH 密钥交换和加密要求 (FIPS 140)

对于需要符合 FIPS 标准的客户，Transfer Family 使用 FIPS 140 认证的开源加密库-LC 在 SSH 中提供 AWS FIPS 认可的加密。 AWS根据NIST的SP 800-56Cr2（第2节），Tran TransferSecurityPolicy sfer Family中-FIPS-2025-03中支持的后量子混合密钥交换方法已获得FIPS的批准。德国联邦信息安全办公室 (BSI) 和法国国家信息系统安全局 (ANSSI) 也推荐了这种后量子混合密钥交换方法。

在 Transfer Family 中测试后量子混合密钥交换

本节介绍测试后量子混合密钥交换所需步骤。

  1. 在 SFTP 端点启用后量子混合密钥交换.

  2. 遵循上述规范草案中的指导，使用支持后量子混合密钥交换的 SFTP 客户端 (例如 设置支持后量子混合密钥交换的 SFTP 客户端)。

  3. 通过 Transfer Family 服务器传输文件。

  4. 确认 SFTP 中的后量子混合密钥交换.

在 SFTP 端点启用后量子混合密钥交换

当您在 Transfer Family 创建 SFTP 服务器端点时，您可选择 SSH 策略，或在现有 SFTP 端点编辑加密算法选项。以下快照显示了您在 AWS 管理控制台 何处更新 SSH 策略的示例。

显示为加密算法选项选定的后量子策略。

支持后量子密钥交换的 SSH 策略名称为 TransferSecurityPolicy-2025-03 和-FIPS-2025-03。TransferSecurityPolicy有关 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 \
   -i username_private_key_PEM_file \
   username@server-id.server.transfer.region-id.amazonaws.com

在上一个命令中，将以下项目替换为您自己的信息：

  • username_private_key_PEM_file替换为 SFTP 用户的私钥 PEM 编码文件

  • 替换username为 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 -i username_private_key_PEM_file username@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 会话的客户端协商。