为了更好地保护用户隐私，Google 早在十多年前就对数据中心之间的流量进行加密。在随后的发展中，几乎所有 Google 传输的数据都进行了加密。虽然这项工作提供了宝贵的隐私和安全优势，但软件加密付出了巨大的代价：加密和解密 RPC 需要大约 0.7% 的 Google 处理能力，以及相应的内存量。
这些成本促使 Google 使用 PSP（PSP Security Protocol 的简写）将加密 Offload 到网络接口卡（NIC）上。所谓的 Offload 就是将本来该操作系统进行的一些数据包处理（如 TCP 分段、IP分片、重组、checksum、TCP协议处理等）放到网卡硬件中去做， 降低系统 CPU 消耗的同时，提高处理的性能。
鉴于 TLS 不够友好，缺乏对 UDP 的支持，同时在 IPsec 上也存在一些缺陷，因此 Google 自主研发了自己的 Offload 友好协议。PSP 作为他们的解决方案被描述为一种类似 TLS 的、独立于传输的协议，用于每个连接的安全性和 Offload 友好。
对于 PSP，Google Cloud 团队的 Amin Vahdat 解释道
PSP 旨在满足大规模数据中心流量的要求。它不强制要求特定的密钥交换协议，并且为数据包格式和加密算法提供了很少的选择。它通过允许每个第 4 层连接（例如 TCP 连接）使用加密密钥来实现每个连接的安全性。
它支持无状态操作，因为加密状态可以在传输数据包时通过数据包描述符传递给设备，并且可以在使用安全参数索引 (SPI) 和设备上的主密钥接收数据包。这使我们能够在硬件中保持最小状态，与维护大型设备表的典型状态加密技术相比，避免了硬件状态爆炸。
PSP 使用带有自定义标头和尾标的用户数据报协议 (UDP) 封装。一个 PSP 数据包以原始 IP 头开始，然后是预先指定的目标端口上的 UDP 头，然后是包含 PSP 信息的 PSP 头，然后是原始 TCP/UDP 数据包（包括头和有效负载），并以包含完整性校验和值 (ICV) 的 PSP 预告片。
第 4 层数据包（标头和有效负载）可以根据用户提供的称为 Crypt Offset 的偏移量进行加密或验证。例如，此字段可用于保留部分 TCP 标头在传输过程中经过身份验证但未加密，同时保持数据包的其余部分加密以支持网络中的数据包采样和检查（如有必要）。
Google 将 PSP 修补到他们的生产 Linux 内核、他们的 Andromeda 网络虚拟化堆栈和他们的 Snap 网络系统中。据报道，PSP 加密卸载可节省约 0.5% 的 Google 整体处理能力。今天，他们将 PSP 安全协议开源，以鼓励其进一步采用。他们已经发布了他们的架构规范、参考软件实现和一套测试用例。
最新文章