感谢您的反馈。

全球数百万用户依赖 Webex 进行安全协作。 从企业董事会和政府立法会议到敏感的医患咨询，Webex 都是关键通信的可信平台。

随着远程办公需求的增长，对强大、保密的协作工具的需求也在增长。 Webex 解决这一需求的时间比任何其他供应商都长。 随着人工智能模拟和复杂的深度伪造威胁的兴起，对身份验证、策略驱动的协作要求至关重要。 对于我们的客户而言，安全不仅仅是一项功能，它是整个会议生命周期的组成部分，涵盖日程安排、参与者身份和内容保护。

Webex 在支持强大的端到端加密 (E2EE) 方面有着悠久的历史。 我们的 Webex 零信任安全模式通过三个主要支柱发展了这一传统：

• 为基于标准的、经过正式验证的密码学奠定基础
• 使用经过验证的端到端身份增强端到端加密
• 将支持扩展到当前的 Webex 设备以及 Webex 应用程序

本技术文件提供了端到端安全的背景信息，并阐述了 WebexZero Trust Security 工作原理的技术基础。 有关会议运营安全性，例如会议会话类型、预定会议与个人会议室之间的安全差异、管理员和主持人控制、会议内容共享和保留以及会议体验中更广泛的人工智能和深度伪造弹性，请参阅配套的 WSMP Meetings Securit y 技术论文。

提供 E2E 安全的 18 年传统

2008 年，Webex 率先推出了会议端到端加密技术。 顾名思义，端到端安全性可确保内容从发送之日起一直到收件人显示内容都经过加密，从而防止云提供商或任何第三方访问或篡改数据。

视视频会议提供商在端到端安全机制上的投资而定，他们可以提供不同级别的保护，如图 1 所示。 任何 E2E 安全性都比仅在传输和静态时加密要好。

保护级别	网络攻击者	被动攻击（窃听）	主动攻击（模仿）	示例
传输中和静态加密	是	否	否	非 E2EE 应用程序
端到端加密	是	是	否	传统的 E2EE 和消费者应用程序
端到端加密和 E2E 身份	是	是	是	Webex 零信任安全

大多数声称提供端到端安全性的应用程序仅提供针对被动攻击的保护。 仅限被动的保护措施仍然很有价值，因为它们使不良行为者只能在会议进行期间窃听会议。 但是，最好的方法是防范被动和主动攻击，在这种情况下，会议提供商本身可能会假装自己是合法参与者进入会议。 为此，除了 E2E 加密外，还需要一个 E2E 身份层。

借助 Zero Trust Security，Webex 为会议带来了更强大的加密技术，并通过端到端验证身份增强了端到端加密，以帮助确保会议免受各种攻击。

在深入研究技术细节之前，了解用户体验会很有帮助。 要创建 E2E 加密会议，主持人在 Webex 应用程序中安排会议期间选择相应的会议类型（图 2）。

当参与者加入时，他们会看到一个 “带锁的盾牌” 图标，表示会议已通过 E2E 加密（图 3）。 点击此图标可提供有关会议保护的详细信息。

最后，在会议参与者列表中，Webex 应用程序会指明参与者的身份是否已通过端到端安全方式的验证，即是否有除思科以外的其他人为参与者的身份提供担保（图 4）。

参与者还可以检查他们是否都有相同的安全码，以确认他们对会议的看法相同，因此可以免受冒充攻击。 在使用客户提供的端到端身份证书的部署中，名册状态提供了身份保障的透明度。

零信任安全建立在行业标准的加密协议之上，思科正在与谷歌、Cloudflare、Wickr和Wire等其他安全和隐私领域的领导者共同推动该协议。 思科凭借安全实时协议 (SRTP)、DTLS-SRTP、STIR/SHAKEN和WebRTC等技术，引领了第一代安全IP语音 (VoIP)，思科在零信任安全方面也在做同样的事情（图 5）。

层	今天	零信任安全
身份	SSO（SAML、OpenID）	X.509 证书
密钥交换	SDES/DTLS	消息层安全 (MLS)
媒体加密	SRTP	安全框架 (sFrame)

该系统基本上有三层，在每一层我们都采用了旧的逐跳技术，并通过额外的端到端保护层对其进行加强。 这三层包括：

• 身份 — E2E 身份要求客户拥有证明其身份的凭证。 借助 Zero Trust E2E 身份，客户的凭证由 Webex 独立人士提供。Certificate Authority
• 密钥交换 — 参加 E2E 会议的客户需要设置用于 E2E 加密的密钥，而会议提供商无法访问这些密钥。 消息层安全 (MLS) 协议是一项经过批准的标准，即 RFC 9420，它建立在开源社区开发的技术基础上，并将其置于严格的、经过正式验证的环境中。
• 内容保护——最后，会议的实际媒体内容需要端到端保护。 sFrame（用于 “安全框架”）是 RFC 9605。 它是一种用于加密实时媒体的快速而简单的加密框架，它允许以最小的开销添加额外的加密层。

让我们从自下而上开始更详细地了解这些技术。

媒体加密方案是一种获取会议参与者共享的密钥并使用它来保护会议中共享的实际内容（例如音频、视频和屏幕共享）的方法。 在协议级别，加密方案需要使用每个加密数据单元发送额外的信息，最重要的是：

1. 告诉接收方如何解密数据包的标头，以及
2. 接收方用来验证数据包未被篡改的身份验证标签。

例如，在 SRTP 中，加密单位是 RTP 数据包；SRTP 依赖于 RTP 标头进行设置，并在数据包末尾附加身份验证标签。

由于所有这些额外信息都增加了端到端加密会议所需的带宽，因此 sFrame 提供了所需的最小框架量。 sFrame 标头指示应使用哪个密钥，允许密钥轮换，并提供定义初始化向量的唯一序列号。 其次是使用 E2E 密钥和身份验证标签加密的内容。 然后，将 sFrame 标头、内容和标签封装在 SRTP 数据包中，这样 SRTP 可以防范网络攻击者的检查或修改，而 sFrame 可以防范会议提供商的媒体元素（参见图 6 中的示例）。

这种极简主义方法还有其他好处。 sFrame 独立于底层传输，因此它与基于 QUIC 的 RTP 和 RIPT 等新兴技术向前兼容。 也可以配置 sFrame，使其适用于多数据包单元，例如整帧，以进一步减少加密开销。

当群组只能访问不可信频道时，在群组中设置密钥似乎很神奇。 实现此目的的技术最早是在20世纪80年代开发出来的，如今，超过90％的网络浏览使用传输层安全（TLS）来做到这一点。 消息层安全 (MLS) 将此功能扩展到群组，而 TLS 只能点对点起作用，因此，即使会议提供商不受信任，Webex 也可以使用 MLS 设置会议密钥。

MLS 提供三种关键安全功能：

1. 共享密钥 —只有经过身份验证的群组成员才知道密钥。
2. 一致性 —确保所有成员对小组名册的看法一致。
3. 旋转 —成员加入或离开时自动更新密钥。

第一个功能为我们提供了用于使用SFrame加密媒体的密钥。 与第二个功能一起，它为 E2E 身份提供了起点。 第三项功能确保唯一可以解密媒体的人是现在正在开会的人——你无法解密加入之前或离开（或被赶出去）之后的媒体。

为了完成所有这些工作，会议中的客户在会议的关键时刻交换 MLS 消息，以维护一个完全包含任何时间点会议参与者的 MLS 群组。 Webex 在客户端之间路由消息，但是 MLS 会保护这些消息，因此 Webex 可以安全地处理它们。 图 7 显示了消息的流向。

创建：第一个加入会议的人，无论是否主持人，都会为会议创建 MLS 群组，并成为 MLS 的 “领导者”。 在任何给定时间点，会议中的一位参与者被指定为领导人。 在大多数情况下，该参与者将是会议主持人。 会议开始后，MLS 确保每位会议参与者都拥有充当领导者的加密信息；Webex 仅指定一位领导者以避免混淆。

加入：当新参与者想要加入会议时，他们通过向领导者发送 MLS 密钥包消息来要求获准加入，领导者会提供他们的公钥和身份验证信息。 领导者以欢迎消息回应，向参加者介绍会议的其他参与者。 领导者还向群组广播 “添加” 消息和 “提交” 消息。 “添加” 消息会向已参加会议的人宣布新的加入者。 提交消息使所有当前参与者对旧群组密钥进行哈希处理，以获得现已扩展群组的新密钥；欢迎消息将此密钥提供给加入者。

离开：当有人离开会议时，领导者的职责是将他们拒之门外。 领导者通过向会议中剩下的所有人广播 MLS “移除和提交” 消息来实现此目的。 移除消息告诉剩余的参与者是谁离开了，Commit 会为所有剩余的参与者加密一个新密钥，但不会加密给离开的人。 其余的参与者使用旧的群组密钥对新密钥进行哈希处理，以获得离开者没有的密钥。 如果离开的参与者是领导者，Webex 会任命新的领导者，而新领导者则移除旧领导者。

密钥轮换可能意味着加入会议或删除某人需要多花几秒钟，但它提供了明确的安全保障：如果某人没有出现在会议的参与者列表中，则他们没有解密内容的密钥。

E2E 加密会议中的参与者列表显示每个用户的身份验证。 从思科无法篡改的意义上说，使用客户颁发的身份证书可提供真正的 E2E 验证身份。 在这些情况下，参与者列表以蓝色文本显示参与者所属的域。 例如，在图 8 所示的会议中，您可以看到 Kevin 有一个来自 example.com 的经过验证的电子邮件地址，而 Isabella 有一个来自 company.com 的经过验证的电子邮件地址。

由 Webex Certificate Authority 颁发的身份证书（例如视频设备身份）提供的保护更为有限。 只有入侵 Webex 的攻击者Certificate Authority才能冒充用户。 尽管这比完全没有身份保护要好，但会议中的此类参与者不会以蓝色标记为 Zero Trust 端到端身份已验证。 它们以灰色文本显示，以表示 Webex 信任身份验证。

作为这些程序的支持，Webex 还为会议提供了安全码。 安全代码是一个简短的、人类可读的字符串，计算为 MLS 过程的输出。 安全码汇总了会议的加密状态，包括小组的密钥和参与者颁发的证书。 此代码可用于检测模拟攻击，因为这种攻击会导致至少一个参与者的加密状态与其他所有人不同。 但是，只有当每个人都验证他们有相同的代码时，它才会排除冒充的可能性。 如果一部分参与者确认他们拥有相同的密码，他们就会知道自己的身份被忠实地呈现给对方，但是没有确认密码的人可能会被冒充。 图 9 显示了如何在会议中显示安全代码的示例。

此代码为抵御模拟攻击提供了非常强大的防御能力。 它是MLS协议的一部分，因此它进行了强大的安全分析。 由于它与会议状态紧密相关，因此每次有人加入会议时，安全码都会发生变化。 因此，每次有人加入会议时，会议参与者都需要重新验证其安全码。 当有人离开时，代码不会旋转，因为离开不会引入模仿者。

Webex Zero Trust Security 于 2021 年推出。 2026 年，Ultra Secure Webex 会议在 E2E 加密的 Webex 会议、带视频网状节点 (VMN) 的全功能 Zero Trust E2EE 会议以及标准会议的端到端加密和身份识别功能中引入了对更多端点的支持：

• 基于标准的、经过正式验证的密码学
• 零信任 E2E 加密
• Zero Trust E2E 验证身份
• 支持所有可供销售的 Webex 设备
• 支持桌面、移动设备和 Web 上的 Webex 应用程序
• 支持 Webex Web 应用程序和 Web SDK（计划在 Q1CY27 上线）
• 支持Webex Calling手机（计划在 Q3CY26 上线）
• 支持视频网格节点
• 支持在预定会议和个人会议室中进行 E2E 加密

零信任有一些局限性。 E2E 加密会议不支持：

• 思科云服务提供的需要访问纯文本媒体的功能，包括：
  • Webex 基于云的录制和AI Assistant服务。 这些服务可以使用带有视频网格节点 (VMN) 的混合部署来提供。
  • 保存会议聊天、文件、白板和注释。
  • PSTN 或 SIP 互操作性。

展望未来，Webex 将遵循授予云端所需的最低权限和让客户控制其数据的原则，在多个维度上改进 E2E 加密会议。

无处不在的 E2E 安全：一切都应该是 E2E 安全的，而不仅仅是部分会议。 Webex Web App 和云连接的思科电话的端到端安全已经达到了实现这一愿景的第一步。 最终，开放的、基于标准的端到端架构也将使 Webex 能够引入会话初始协议 (SIP) 基础架构。

本文讨论的创新为实现永续在线端到端加密的长期愿景指明了道路。 一旦用户可以从任何地方进行连接，并且客户可以安全地选择在会议中使用他们想要的功能，那么每次 Webex 会议都可以使用 E2E 加密——从开启所有功能的非正式临时会议，一直到锁定的、高度安全的会议。 E2E 加密将始终确保会议内容仅供授权的参与者使用，客户和用户将决定哪组参与者适合给定会议。

支持人工智能的模仿和深度伪造的韧性

Webex 通过补充 Zero Trust 端到端加密模型的分层方法来应对基于人工智能的模拟威胁。 虽然本文重点介绍端到端验证身份的技术基础，包括客户提供的基于证书的验证和满足加密完整性检查，但Webex还在会议体验中提供了操作安全控制，以降低未经授权的访问和有害互动的风险。

有关会议会话类型、预定会议与个人会议室的安全差异、Control Hub 中的主持人和管理员控制，以及更广泛的会议体验中的其他 AI 和 deepfake 检测和预防，请参阅配套的 WSMP Meetings 安全技术论文。

Webex 正在通过基于标准的加密和经过验证的身份来定义安全会议的未来。 对开放生态系统的承诺可确保无论会议场景如何，客户都能保持对数据的绝对控制权。