端到端加密（E2EE）
技术一种安全系统，只有通信双方能够读取消息，不包括服务器
什么是端到端加密？
\n端到端加密（E2EE）是一种安全系统，只有通信双方能够读取消息。其他任何人——包括服务提供商、服务器基础设施，甚至平台运营商——都无法解密通信内容。可以把它想象成在上锁的盒子里寄信，只有收件人有钥匙，邮政服务无法打开它。
\n在视频通话中，E2EE 意味着你的音视频流在你的设备上加密，并保持加密状态直到到达接收方设备。即使有人在传输过程中拦截数据或入侵路由你通话的服务器，他们看到的也只是加密的乱码。
\nE2EE 是隐私保护的黄金标准。Signal、WhatsApp（用于消息和通话）、FaceTime 以及越来越多的企业视频会议平台都在使用它。截至 2025 年，WebRTC 中的 E2EE 已经显著成熟，新标准和浏览器 API 使生产应用的实现变得实用。
\n\nWebRTC 的内置加密（DTLS-SRTP）
\nWebRTC 强制加密——所有 WebRTC 连接默认使用 DTLS-SRTP 加密：
\n- \n
- DTLS（数据报传输层安全）：建立加密通道并交换加密密钥 \n
- SRTP（安全实时传输协议）：加密实际的媒体数据包（音频和视频） \n
这种加密是强制性和自动的——你无法禁用它。每个 WebRTC 连接都是加密的，可以防止网络上的被动窃听。
\n然而，仅有 DTLS-SRTP 并不是端到端加密。原因如下。
\n\nSFU 问题：为什么标准 WebRTC 不是 E2EE
\n在点对点 WebRTC（两个人直接连接）中，DTLS-SRTP 提供真正的 E2EE。只有两个参与者拥有解密密钥。完美。
\n但大多数视频通话在群组通话中使用 SFU（选择性转发单元）服务器。以下是发生的情况：
\n- \n
- 你的设备使用 DTLS-SRTP 加密媒体并将其发送到 SFU 服务器 \n
- SFU 服务器解密媒体以检查和路由它 \n
- SFU 使用新的 DTLS-SRTP 密钥重新加密媒体 \n
- 重新加密的媒体被发送给接收者 \n
在第 2 步中，SFU 可以访问未加密的媒体——即使只是短暂地在内存中。这破坏了端到端加密。媒体在传输过程中是加密的，但服务器可能会访问它。
\n为什么 SFU 要解密？它们需要检查 RTP 头来确定要转发哪些流、检测关键帧、处理联播层并执行基于质量的切换。传统的 SFU 架构需要对媒体数据包的明文访问。
\n\n使用可插入流实现真正的 E2EE
\n解决方案：添加 SFU 永远不会解密的第二层加密。只有端点（参与者）拥有这一层的密钥。
\n\n工作原理
\n- \n
- 你的设备捕获并编码视频/音频 \n
- 发送前，你的设备添加应用层加密（E2EE 层） \n
- 这个加密的有效载荷然后被包装在 DTLS-SRTP 中（传输加密） \n
- SFU 接收数据包，解密 DTLS-SRTP，但只看到应用层密文 \n
- SFU 将（仍然加密的）媒体转发给接收者 \n
- 接收者解密应用层加密以恢复原始媒体 \n
SFU 从未看到明文媒体。它只看到它盲目转发的加密帧。
\n\n可插入流 API
\n于 2020 年引入并标准化为 RTCRtpScriptTransform，这个浏览器 API 允许 JavaScript 代码在编码的媒体帧被打包和发送之前或在接收后但在解码之前拦截它们。
你的代码可以：
\n- \n
- 读取每个编码的帧 \n
- 使用加密库（如 WebCrypto API）应用额外的加密 \n
- 返回加密的帧以供发送 \n
- 在接收时，在将帧传递给解码器之前解密它们 \n
浏览器支持：基于 Chromium 的浏览器（Chrome、Edge、Opera）完全支持。Safari 部分支持。截至 2025 年，Firefox 支持正在进行中。
\n\nSFrame：新兴标准
\nSFrame（安全帧）是 IETF 标准协议，专门为 WebRTC 群组通话中的媒体帧加密而设计。它针对实时媒体的约束进行了优化：
\n\n关键特性
\n- \n
- 部分加密：只加密媒体有效载荷，保留 RTP 头和一些元数据未加密，以便 SFU 仍然可以路由数据包 \n
- 逐帧加密：每个帧独立加密，允许乱序传递和丢包而不影响其他帧 \n
- 最小开销：每帧约 10-40 字节的加密元数据 \n
- 快速对称加密：使用 AES-GCM 以提高速度（对于实时编码至关重要） \n
- 组密钥管理：支持具有共享组密钥的多个参与者 \n
SFrame 工作原理
\n每个参与者都有一个加密密钥。在发送帧之前：
\n- \n
- 帧被编码（VP8、H.264、Opus 等） \n
- SFrame 添加一个小的头部，指示使用了哪个密钥和一个计数器 \n
- 编码的有效载荷使用 AES-GCM 加密 \n
- 加密的帧通过 WebRTC 发送 \n
接收者从 SFrame 头部识别发送者，使用相应的密钥解密，并解码媒体。
\n\nMLS：组密钥管理
\nE2EE 最困难的部分不是加密帧——而是在多个参与者之间管理加密密钥，特别是当人们加入和离开通话时。
\nMLS（消息层安全），由 IETF 于 2023 年标准化，是专为这个问题设计的组密钥交换协议。
\n\nMLS 特性
\n- \n
- 高效的密钥更新：添加参与者不需要与每个人重新交换密钥 \n
- 前向保密：泄露今天的密钥不会解密过去的通信 \n
- 泄露后安全：从密钥泄露中恢复是可能的 \n
- 可扩展性：可以高效地处理数千名参与者 \n
密钥轮换
\n当有人离开通话时，必须轮换密钥，以便离开的参与者无法解密未来的对话。MLS 高效地处理这个问题：
\n- \n
- 生成新的组密钥 \n
- 通过现有的 E2EE 通道分发给当前参与者 \n
- 所有参与者切换到新密钥 \n
对于加入，哈希棘轮可以派生新密钥而无需完整的密钥交换，从而减少开销。
\n\n实现挑战
\n\n1. 性能开销
\n额外的加密/解密会消耗 CPU。在移动设备或低端硬件上，这会降低视频质量或更快地耗尽电池。AES 的硬件加速有帮助，但开销是真实存在的（通常 CPU 增加 10-30%）。
\n\n2. 部分加密复杂性
\nSFU 需要一些未加密的元数据才能运行：
\n- \n
- 关键帧指示器（优先处理重要帧） \n
- 联播层信息（用于质量切换） \n
- 编解码器特定的元数据 \n
确定什么必须保持未加密因编解码器（VP8、VP9、H.264、Opus）和帧类型而异。弄错这个会破坏 SFU 功能或泄露信息。
\n\n3. 密钥管理复杂性
\n在动态组之间安全地分发、轮换和管理密钥很困难。你需要：
\n- \n
- 安全的初始密钥交换（通常使用公钥加密） \n
- 密钥派生函数 \n
- 同步机制（所有参与者必须使用相同的密钥版本） \n
- 处理竞态条件（同时加入/离开） \n
4. 浏览器支持
\n截至 2025 年，可插入流支持并不完整。Chromium 浏览器完全兼容，但 Safari 和 Firefox 的支持是部分的或正在开发中。跨浏览器 E2EE 需要回退策略或限制支持的平台。
\n\n5. 调试和监控
\n使用 E2EE，你无法在服务器端检查媒体。调试通话质量问题变得更加困难——你无法查看服务器看到的视频帧，因为它只看到加密数据。遥测和诊断必须在客户端进行。
\n\nP2P vs. SFU E2EE
\n\n点对点
\nP2P 的 E2EE 很简单。WebRTC 的内置 DTLS-SRTP 已经提供了 E2EE——只有两个对等方拥有密钥。不需要额外的加密层。
\n这就是 FaceTime、WhatsApp 一对一通话和 Signal 的工作方式。简单性是美丽的：直接连接，通过 DTLS 交换密钥，使用 SRTP 加密。完成。
\n\nSFU（群组通话）
\n使用 SFU 的 E2EE 需要额外的应用层加密（SFrame 或类似）加上组密钥管理（MLS 或类似）。复杂得多，但对于超过 4-5 个参与者的通话是必要的。
\n\n现实世界的实现（2025）
\n\n具有 E2EE 的应用
\n- \n
- WhatsApp：所有通话（一对一和群组）的 E2EE，使用 Signal 协议进行密钥交换 \n
- Signal：所有内容（消息和通话）的 E2EE，现代 E2EE 的先驱 \n
- FaceTime：所有通话的 E2EE，Apple 的专有实现 \n
- Zoom：会议的可选 E2EE（默认禁用，需要主持人启用） \n
- Jitsi Meet：为 Chromium 浏览器提供使用可插入流的 E2EE \n
- Cloudflare Calls：使用 MLS 演示的 E2EE 实现（Orange Meets 项目） \n
没有 E2EE 的应用
\n- \n
- Google Meet：传输中加密（DTLS-SRTP）但不是 E2EE——Google 可以解密 \n
- Microsoft Teams：传输中加密但不是 E2EE——Microsoft 可以解密 \n
- 大多数企业视频平台：默认不是 E2EE，以启用录制、转录、合规监控等功能 \n
为什么不总是使用 E2EE？
\n如果 E2EE 更安全，为什么不是所有平台都使用它？
\n- \n
- 功能限制：服务器端功能（如云录制、实时转录、内容审核和 AI 功能）需要访问媒体——与 E2EE 不兼容 \n
- 合规性：某些行业需要能够审计通信，而 E2EE 阻止了这一点 \n
- 性能：额外的加密开销会降低低端设备上的质量 \n
- 复杂性：E2EE 更难实现和维护，增加了开发成本 \n
- 浏览器支持：截至 2025 年，跨浏览器 E2EE 仍然存在兼容性挑战 \n
对于许多商业应用，权衡有利于传输加密（DTLS-SRTP）而不是 E2EE。对于注重隐私的消费者应用，E2EE 越来越成为标准。
\n\n验证 E2EE
\n你如何判断视频通话是否真正使用了 E2EE？
\n- \n
- 安全码/指纹：像 Signal 和 WhatsApp 这样的应用显示安全码，你可以通过带外方式（亲自、单独渠道）与另一方验证 \n
- 平台文档：检查平台是否明确说明 E2EE 并解释其工作原理 \n
- 开源：开源实现（如 Jitsi）可以被审计 \n
- 第三方审计：信誉良好的公司进行的安全审计提供信心 \n
如果应用提供云录制或 AI 转录，它可能不是 E2EE（这些功能需要服务器访问未加密的媒体）。
\n\nWebRTC 中 E2EE 的未来
\n截至 2025 年，WebRTC 中的 E2EE 正在从"困难和小众"转变为"实用和日益标准"：
\n- \n
- SFrame 正在被标准化并在生产系统中实现 \n
- MLS 提供强大的组密钥管理 \n
- 浏览器对可插入流的支持正在改善 \n
- 主要平台（Zoom、Jitsi）现在提供 E2EE 选项 \n
- libsframe 等库使实现更容易 \n
预计到 2026-2027 年，E2EE 将成为消费者视频通话的默认选项，类似于 HTTPS 如何成为网站的默认选项。
\n\n结论
\n端到端加密是通信隐私的黄金标准。虽然 WebRTC 一直在传输中加密（DTLS-SRTP），但真正的 E2EE——即使服务器也无法解密你的通话——需要使用 SFrame 等技术进行额外的应用层加密以及像 MLS 这样的密钥管理协议。
\n权衡是复杂性和功能减少（没有服务器端录制、转录或 AI 功能）。但对于隐私关键的应用——个人通话、敏感商务讨论、医疗咨询——E2EE 是必不可少的。
\n随着浏览器支持的成熟和标准的巩固，在 WebRTC 应用中实现 E2EE 对于主流开发人员来说正变得实用。理解 E2EE 有助于你就何时使用它以及如何有效实现它做出明智的决策。
\n\n参考资料
\n- \n
- True End-to-End Encryption with WebRTC Insertable Streams - webrtcHacks \n
- Having fun with Insertable Streams and E2EE (and SFrame!) - Meetecho \n
- Does your video call have End-to-End Encryption? Probably not.. - webrtcHacks \n
- WebRTC Security - Is it secure and safe? - Stream \n
- End-to-End Encryption - Dyte \n
- Exploring End-to-End Encryption (E2EE) in WebRTC - DigitalSamba \n
- Orange Me2eets: We made an end-to-end encrypted video calling app - Cloudflare \n
- End-to-End Encryption - Cloudflare Realtime Documentation \n