深度伪造时代，实时视频安全需要补上“真人验证”

看见对方，不再等于确认对方身份

过去的视频会议有一个隐含假设：只要账号正确、连接安全，并且摄像头里出现熟悉的脸，就足以相信屏幕另一端的人。

实时深度伪造正在打破这个假设。

2024 年，一名工程公司财务人员参加了一场视频会议，画面中出现了公司的 CFO 和多名同事，并在会议中收到转账指令。他随后进行了 15 笔转账，总额达到 2 亿港元，约合 2560 万美元。事后发现，会议中其他参与者均为深度伪造内容。

关键问题在于：传统安全机制并没有失效。连接可以是真的，会议系统可以正常运行，账号也可能拥有合法权限，但这些机制验证的并不是“镜头前究竟是谁”。

实时视频系统可以拆成四个相互独立的安全层：

前三层分别保护连接、媒体和账户。只有第四层真正回答：现在出现在摄像头前的人，到底是不是我们以为的那个人？

WebRTC 通常使用 DTLS 为实时通信建立安全连接，并为 SRTP 音视频加密提供密钥。文章认为，在 2026 年的视频基础设施中，DTLS 1.3 已经是值得要求的安全基线。

但群组视频通常依赖 SFU（选择性转发单元）进行扩展。在这种架构下，传统传输加密属于逐跳保护：客户端与服务器之间的链路受到保护，但服务器仍可能需要处理媒体数据。

因此，“连接已经加密”和“服务器无法读取媒体”并不是一回事。

如果希望 SFU 负责转发却不能读取音视频内容，就需要进一步对媒体帧进行端到端加密。SFrame 的思路是加密媒体内容，同时保留服务器进行路由所必需的结构信息。

这也带来实际的产品取舍。服务器一旦无法解密媒体，依赖服务端读取音视频的功能就可能受到影响，包括云端录制、字幕、转写和 AI 摘要等。

因此，E2EE 并非简单增加一个加密开关，而涉及密钥管理、参与者加入和退出后的密钥轮换，以及媒体服务器与客户端之间的协议协同。

Token、角色和权限控制解决的是“谁可以进入会议，以及进入后可以做什么”。对于敏感业务，文章建议采用更严格的策略，包括：

这些措施可以降低账户和权限滥用风险，但仍然只能证明某个账号获得了授权，无法证明摄像头里的脸属于账号本人。

这正是实时深度伪造带来的新问题。

假设攻击者已经成功登录合法账户，设备和会议连接也完全正常，甚至媒体已经进行了端到端加密。但浏览器获取的视频来自一个虚拟摄像头，而虚拟摄像头正在实时输出深度伪造画面。

此时，底层安全机制可能全部正常工作：传输层负责加密它，媒体层继续加密它，Token 也成功通过权限检查。问题发生在更靠近视频采集和人的一侧。

因此，真人验证需要成为独立的安全层。

当前的身份验证方案实际上存在两种不同目标。

一种是真人证明（proof of humanity）：确认参与者是真实、唯一的人类，但不一定公开其具体身份。这适合抵御机器人以及需要保持匿名性的场景。

另一种是身份匹配：确认当前真人与某个已经验证的具体身份一致，例如将实时自拍与身份证件照片进行匹配。这更适合审批、合规和其他受监管业务。

两者不能简单互相替代。不同产品应该先确定自己需要证明什么，再选择对应的验证机制。

真人验证不一定需要覆盖每一分钟的视频通话。更现实的方式，是根据业务风险分层。

普通视频可以使用传输加密、服务端签发的短期 Token 和最小权限；涉及医疗、法律、人事等敏感内容时，可以进一步采用媒体端到端加密；涉及付款、审批、账号找回等不可逆操作时，则应增加针对人的验证。

尤其值得注意的是“决策时刻验证”：即使用户已经通过会议入口验证，当会议中突然出现转账、修改账号或授权重要操作的请求时，也可以要求重新完成 MFA、Passkey、活体检测，或者通过另一个独立渠道进行确认。

这种设计把安全检查放在风险真正发生的位置，而不是仅仅依赖“成功进入会议”这一事实。

实时视频安全过去主要回答三个问题：连接有没有被窃听，媒体有没有泄露，账号有没有权限。

深度伪造增加了第四个问题：正在使用这个合法连接和合法账号的人，究竟是不是他声称的那个人？

这意味着未来的视频安全不能再用一个笼统的“安全”概念覆盖所有问题。传输加密、媒体加密、账户授权和真人验证解决的是四种不同风险。

对于普通社交视频，前三层可能已经足够；但对于付款、审批、账号恢复等高风险流程，仅仅看到熟悉的脸、合法的账号和加密标识，已经不能作为最终身份凭证。