LWN：内核中适合offload的网络加密！

关注了就能看到更多这么棒的文章哦～

Offload-friendly network encryption in the kernel

By Daroc Alden
July 9, 2024
Gemini-1.5-flash translation
https://lwn.net/Articles/980430/

PSP 安全协议 (PSP) 是一种通过将加密和解密操作高效地卸载（offload）到 Google 数据中心内部连接使用的网络接口卡 (NIC) 上来透明加密数据包的方式。该协议类似于 IPsec，因为这一层允许对任意流量内容进行封装加密。不同之处在于 PSP 被封装在 UDP 中，并且从一开始就旨在减少 NIC 为了发送和接收加密流量而必须跟踪的状态数量，从而允许更多的并发连接。Jakub Kicinski 希望为该协议添加 到 Linux 内核中的支持。

协议

PSP 是一种相当精简的协议。它完全避免了如何进行安全密钥交换的问题，假设连接两端的应用程序将能够以某种方式交换对称加密密钥。这并非不合理的架构设计决策，因为 IPsec 也执行相同的操作。存在几种用于安全交换密钥的现有协议，例如 Internet Key Exchange 或 Kerberized Internet Negotiation of Keys。通常，这些协议对对称密钥的来源漠不关心。PSP 则略有不同。为了支持硬件卸载，PSP 要求 NIC 本身生成 PSP 连接的密钥。PSP 架构规范 详细介绍了 NIC 如何执行此操作。

主要要求是 NIC 应该能够从相当有限的信息量中重新推导出会话密钥——具体而言，是从 32 位“安全参数索引” (SPI) 值和存储在设备上的密钥中重新推导出。该密钥由 NIC 生成并用于根据需要使用安全的密钥导出函数为每个连接推导出特定于会话的加密密钥。因此，仅靠 SPI 不足以解密数据包；这允许将 SPI 包含在 PSP 数据包中，让 NIC 能够实时地为数据包重新推导出加密密钥。反过来，这意味着 NIC 实际上并不需要存储加密密钥来接收和处理数据包，从而极大地减少了设备所需的内存量。

不幸的是，这种重新推导密钥的要求也带来了一些代价——PSP 连接是单向的。对于需要双向通信的实际用例，应用程序需要为每个方向设置一个独立的 PSP 连接。由于重新推导出密钥需要访问存储在 NIC 上的设备密钥，因此只有接收 NIC 才能重新推导出密钥，所以发送设备仍然需要在某个地方存储密钥。虽然这可以在 NIC 上完成，但 PSP 规范仍然保留了硬件实现的可能性，该硬件实现需要计算机将加密密钥与任何传输的数据包一起发送到 NIC。

为了加密数据包，PSP 使用 AES-128-GCM 或 AES-256-GCM。这两种算法都是 带有关联数据的认证加密 (AEAD) 方案——它们保证收到的数据没有被篡改（认证）并将一些加密数据与一些关联的明文数据捆绑在一起。在 PSP 的情况下，这用于实现一个偏移量，允许发送方将封装在 PSP 中的协议的报头保持未加密状态，同时仍然保护内容。仅支持两种 AES 模式可以降低 PSP 的实现复杂性。

PSP 还定义了一个数据包布局，该布局旨在通过在报头中提供明确的长度并使用比 IPsec 更少的可选报头来提高硬件解析数据包的效率。结合独特的密钥导出方案，PSP 最终比 IPsec 或 TLS 等其他加密协议更便于硬件实现。

虽然 Google 是 PSP 的创始人，也是目前最大的用户，但该协议也可能对其他用户有用。与其他加密协议相比，PSP 需要更少的设备内存，使其能够扩展到更多数量的连接。由于该协议没有强制规定密钥交换标准，因此对于用户控制连接两端，但仍然希望确保流量可以加密的环境来说，PSP 可能是不错的选择。

讨论

尽管 Google 发现该协议非常有用，但内核开发人员对在内核中添加另一个加密协议持怀疑态度，内核已经处理了 IPsec、WireGuard、TLS 等协议。Paul Wouters 在看到 Kicinski 想要将 PSP 添加到内核中时表示惊讶 ，因为 IETF 拒绝将该协议标准化，理由是它与 IPsec 太相似。

Steffen Klassert 分享了 IPsecME 工作组一直在整理的 草案，该草案涵盖了与 PSP 相同的一些用例。然而，这可能不像看起来那样有用，因为已经存在实现 PSP 的硬件设备，Willem de Bruijn 指出：“有必要努力制定一个捕获相同优势的 IETF 标准协议。但这与启用已实现的功能无关。”

这个答案 没有让 Wouters 满意，他问道：“Linux 内核应该有多少种不同的数据包加密方法？”他说，等待协议标准化可以提供互操作性，以及确保协议实际上对不止一个用例有用。他还指出，PSP 和 IPsec 可以使用很多相同的 NIC 硬件。

“我当然不会反对标准化流程的优点。但是就 PSP 而言，现在讨论它已经没有意义了，” de Bruijn 回答道。Klassert 同意 需要支持现有的 PSP 用户，但认为仍然需要努力将现代加密协议标准化，以满足每个人的需求。他邀请 Google 派代表参加 IETF IPsecME 工作组会议，讨论这个话题。De Bruijn 表示该公司会参加。

但一些审阅者也对 Kicinski 的补丁集提出了技术方面的不同意见。他提出的 API 允许用户空间在套接字上设置 PSP 加密密钥，之后通过该套接字传输的数据将被加密。问题在于这究竟是如何跟重传功能配合起来？PSP 被封装在 UDP 中，无法保证数据会完整或按顺序到达，将此细节留给更高级别的协议处理。但 Kicinski 主要对 PSP 作为 TLS 替代品感兴趣——当然，TLS 是基于 TCP 之上的。PSP 支持包装 TCP，但只是通过加密单个数据包，而不是通过参与 TCP 的重传逻辑。

这些因素共同创造了一些边缘情况，de Bruijn 指出。内核应该如何处理在将 PSP 密钥与套接字关联后对明文数据的重传？“就像 TLS 卸载一样，数据在排队时被标记为‘待加密’ ”。因此，较早排队的数据或此类数据的重传永远不会被加密，” Kicinski 解释道。

De Bruijn 对此并不完全满意，指出它仍然存在边缘情况。如果一个对等体在另一个对等体决定丢弃连接的同时升级连接会发生什么？“如果（如果真的会发生）这种情况发生，那么连接就无法干净地关闭。” 作为回应，Kicinski 建议：“只有在我们看到一些加密数据后才强制对无数据段进行加密。” De Bruijn 同意这可能有所帮助，但仍然担心内核 API 仍然可以用违反协议正确性的方式使用，并建议可能需要更全面的文档。

作为回应，Kicinski 整理了 一些序列图，显示了如何设置和拆除 PSP 保护的套接字。De Bruijn 认为这是一个实质性的改进，但仍然不相信所有边缘情况都已得到处理。

Lance Richardson 提出了一些关于内核 API 的问题，指出似乎没有真正的支持重新对套接字进行密钥管理，而 PSP 每 24 小时就需要重新管理密钥。在 后续消息中，Richardson 建议这可能与在重新管理密钥后将旧密钥保留一两分钟一样简单。Kicinski 同意这有道理，并承诺将其添加到下一版本的补丁集中。

虽然有很多理由使用 PSP，并且支持 PSP 的硬件的存在是一个好兆头，但缺乏标准以及围绕实现的疑问表明，可能要过一段时间才能最终确定支持。尽管如此，在未来，我们可能会看到另一个加密协议进入内核。具体的操作细节还有待观察。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～