采用端到端加密的视频监控

“作为一家云视频监控服务公司的共同所有者兼首席执行官，我并没有把自家乡间住宅院子里的摄像机接入本公司的服务。

我太清楚了：拥有媒体服务器管理权限的人，从技术上讲可以看到我家里正在发生什么。我不希望任何人有可能监视我的私人生活。”——亚历山大·瓦西里耶夫，LANTA 公司前首席执行官兼共同所有者。

由此产生了这样一种系统构想：云服务运营商可以存储客户的视频，却无法观看视频内容。

现在，SesameDVR 已经具备了这项能力。

摄像机旁的小盒子

要进行加密，无须更换摄像机，也无须等待新的 RTSP 标准出现。

只需在家庭网络中安装一个小型 Sesame Agent，并将它接入路由器或交换机上的空闲 LAN 端口。

Agent 会自行连接本地摄像机，接收其 RTSP 流，对视频进行加密，然后才将视频发送到 SesameDVR。

所有连接都是从家庭网络向外建立的，因此无须：

• 开放入站端口；
• 将摄像机暴露在互联网上；
• 允许云端直接访问本地网络；
• 更改摄像机固件。

SesameDVR 实际上无法直接访问摄像机。云端接收到的只有已经加密的视频流。

Agent 不会对视频进行解码或转码。它会重新封装现成的 H.264 或 H.265 视频流，对其加密，然后发送到服务器。因此，与执行转码的完整视频服务器相比，它对处理器性能的要求要低得多。

根据型号不同，Sesame Agent 可以支持 16 路到数百路摄像机。

具体性能取决于：

• 摄像机的总码率；
• 具体设备的性能；
• 内存和网络接口的速度；
• 互联网连接的带宽；
• 加密参数和系统配置。

密钥的工作方式

视频流所有者在自己的设备上本地创建一对加密密钥：

• 公钥，用于加密数据；
• 私钥，用于解密数据。

公钥会上传到 SesameDVR 并传递给 Agent。使用公钥可以为所有者加密数据，但无法执行反向的解密操作。

私钥始终只由所有者持有。它不在 SesameDVR 中创建，不会传给运营商，也不会存储在服务器上。

随后，Sesame Agent 会定期生成一个随机的内容加密密钥，即 CEK（Content Encryption Key）。

视频正是使用这个密钥进行加密。

默认情况下，每小时生成一个新的 CEK，但可以更改这一周期。密钥也可以更频繁地轮换：实际限制主要取决于需要与视频存档一同保存的加密密钥数量。

每个新的 CEK 都使用所有者的公钥进行加密。

因此，SesameDVR 接收并存储的是：

• 加密后的视频片段；
• 用于保护这些片段的加密 CEK。

明文 CEK 只存在于 Agent 的内存中，并且仅在其有效期内存在。密钥轮换后，Agent 会忘记上一个 CEK。

在录制过程中，明文 CEK 绝不会传输到服务器。

Agent 的源代码是开放的。系统用户可以自行确认密钥处理方式是否与声明一致，检查 Agent 向云端传输了哪些数据，以及加密是如何执行的。此外，用户还可以自行构建 Agent 的可执行文件，并使用自己构建的版本。

防范的不只是运营商员工

云视频监控的问题不仅在于运营商员工可能查看录像。

运营商可能诚信经营，妥善保护基础设施，并严格控制访问权限。但这并不能保证数据始终留在其系统内部并始终处于其控制之下。

视频存档或其副本可能因以下情况落入第三方手中：

• 媒体服务器遭到入侵；
• 管理员账户被攻破；
• 备份发生泄露；
• 云存储配置错误；
• 设备或存储介质被盗；
• 承包商或数据中心的行为；
• 在搜查或其他调查措施中，服务器、磁盘或备份被扣押。

在普通云系统中，任何获得运营商基础设施足够完整访问权限的人，往往也可能获得解密视频的能力。

在 SesameDVR 架构中，仅仅复制或扣押服务器端存储，并不会泄露录像内容。

运营商一侧只有：

• 加密后的视频片段；
• 加密后的 CEK；
• 组织视频存档和播放所需的服务数据。

其中不包含所有者的私钥。

即使有人完整复制了 SesameDVR 的存储——无论是由于入侵、备份泄露、设备被盗还是服务器被扣押——他得到的也只有加密视频和加密密钥。

云存储本身并不包含观看录像所需的完整数据。

我们并非只是限制允许观看视频的员工范围。我们力求从根本上确保运营商一侧不存在解密视频所需的全部要素。

什么是 CBCS 1:9 Partial

视频采用标准 CMAF 格式存储，使用 SAMPLE-AES 和 cbcs 1:9 加密方案。

这不是 SesameDVR 自有的容器格式，也不是什么新的专有视频编解码器。

视频数据会被拆分成 16 字节的 AES 块，然后应用以下循环模式：

加密 1 个块
跳过 9 个块
加密 1 个块
跳过 9 个块
...

因此，视频流受保护部分中约有 10% 会经过 AES 加密。

但这并不意味着没有密钥就能看到其余 90% 的画面。H.264 或 H.265 视频流并不是由彼此独立的像素或独立的图像片段组成的。

它是一系列经过压缩且相互依赖的数据。加密块分布在视频样本内部，因此没有正确的 CEK，解码器就无法正确还原画面。

这里的部分加密是一项有意的优化。它大幅降低了紧凑型硬件 Agent 的负载，同时保留了标准 CMAF 格式，并保持与内置媒体解码器的兼容性。

音频数据则会被完全加密。

用户如何观看视频

系统提供两种播放模式。

完全在客户端解密

在主要模式下，SesameDVR 会向浏览器发送：

• 加密后的视频片段；
• 所选时间段对应的加密 CEK。

用户在本地加载自己的私钥。用户设备上的浏览器会解密所需的 CEK，并将其传递给 ClearKey。

ClearKey 是浏览器标准 Encrypted Media Extensions（EME）的一部分。它是一个标准接口，Web 应用可以通过该接口将密钥交给浏览器内置的媒体子系统，以播放加密的 CMAF 视频流。

在这里，ClearKey 既不是商业 DRM 系统，也不是限制用户的手段。它充当本地解密后的 CEK 与设备硬件或软件视频解码器之间的标准桥梁。

在这种播放方式下：

• 私钥始终留在用户设备上；
• 明文 CEK 不会传输到 SesameDVR；
• 服务器不会收到明文视频；
• 解密会在播放过程中直接执行。

此模式主要面向现代 Chromium 系浏览器和 Firefox。特定视频流能否播放，还取决于编解码器、操作系统以及设备的硬件能力。

该架构的核心特性得以保留：运营商负责传输数据，却不会获得能够观看数据内容的密钥。

兼容模式

Safari、iOS 和部分内置播放器在使用 ClearKey 及所选播放方案时存在限制。

针对这些设备，系统提供一种需要单独确认的兼容模式。

用户只在本地解密所选录像时间段所需的 CEK，并在短期会话期间将这些密钥临时传给服务器。

SesameDVR 仅在内存中解密用户请求的片段，并以普通播放器可以播放的格式将其发送给设备。

明文视频和临时密钥不会保存到：

• 磁盘；
• 持久化存储；
• 共享 CDN 缓存；
• 长期服务器缓存。

这是唯一一种服务器会暂时获得技术能力、可以解密用户所选存档片段的模式。

因此，兼容模式不如完全客户端解密严格。它只能在用户明确同意后启用，并且只能在有限时间内启用。

但这种模式能够让不支持完全客户端方案的设备播放视频存档。

可以共享访问权限

视频流所有者可以为不同用户创建彼此独立的密钥对：

• 为自己；
• 为家庭成员；
• 为安保人员；
• 为员工；
• 为临时接收者；
• 为外部系统。

在授予访问权限时，所选 CEK 会额外使用接收者的公钥进行加密。

每个接收者都使用自己的私钥解密这些 CEK，无须将所有者的私钥交给任何人。

通过这种方式，可以授予以下访问权限：

• 访问整个视频存档；
• 仅访问特定摄像机；
• 仅访问特定时间段；
• 仅访问新录像；
• 允许多名用户使用各自独立的密钥访问。

要撤销访问权限，只需停止使用相应接收者的公钥加密新的 CEK。

同时，也必须如实说明任何访问控制系统都存在的自然限制：如果某人已经保存了解密后的录像，或者已经获得某一时间段的明文密钥，就无法在事后强制他删除这些数据。

撤销访问权限可以阻止对方获取新录像，但无法撤销已经发生的信息传递。

运营商可以做什么

在这种架构中，云视频监控运营商可以：

• 接收加密视频流；
• 将其写入视频存档；
• 构建时间轴；
• 存储服务元数据；
• 控制保留期限；
• 删除旧片段；
• 将加密录像传给所有者；
• 提供访问权限管理基础设施。

但如果没有所有者的私钥，运营商就无法自行观看视频内容。

即使管理员拥有媒体服务器和存储的完整访问权限，看到的也只有加密片段和加密密钥。

同样的情况也适用于获得数据库副本的攻击者、能够接触存储介质的承包商，或者控制了被扣押服务器基础设施的人。

这并不意味着绝对安全

这种架构解决的是一个具体问题：防止云服务运营商查看视频存档内容，并防止服务器端存储遭到入侵后泄露其中的内容。

但这并不意味着系统的其他部分不再需要保护。

例如，攻击者仍可能尝试：

• 在加密前直接访问摄像机；
• 入侵家庭网络；
• 替换或攻破 Sesame Agent；
• 窃取所有者的私钥；
• 访问用户已经解锁的设备；
• 在播放过程中录制屏幕画面。

此外，对视频流进行加密并不一定会隐藏所有元数据。

运营商仍然可能知道：

• 摄像机是否存在；
• 视频片段到达的时间；
• 视频存档的时长；
• 传输的数据量；
• 用户在界面中的操作。

SesameDVR 并不能让视频在任何情况下都无懈可击。它消除了传统云视频监控中最重要的问题之一：运营商一侧长期具备查看客户视频存档的技术能力。

为什么此类解决方案很少见

市场上存在少数由客户管理密钥的企业级产品。

但大众化云视频监控系统通常采用另一种模式：平台自行管理密钥，并可在需要时解密客户数据。

SesameDVR 方法的独特之处并不在于发明新的加密算法，而在于将以下特性结合起来：

• 支持普通 RTSP 摄像机；
• 使用无须转码的独立本地 Agent；
• 云端不能直接访问摄像机；
• 采用带有 cbcs 的标准 CMAF；
• 通过浏览器标准机制播放；
• 私钥保存在本地；
• 可以通过额外加密 CEK 来授予访问权限；
• Agent 源代码开放。

存储并不意味着持有密钥

在云视频监控多年的发展过程中，我们已经习惯认为：如果视频存储在运营商的服务器上，那么运营商就必然能够观看它。

但这并不是必然条件。

服务器可以存储数 TB 的录像，对其建立索引，在保留期限结束后将其删除，并将其传给所有者——同时却不持有观看录像所需的密钥。

运营商不必只靠承诺来保证其员工不会观看您的视频。

仅仅把服务器保护好也不够：理论上，任何服务器都可能遭到入侵、被复制、被盗或被扣押。

我们可以这样构建系统：无论是普通管理员、获得存储副本的攻击者，还是控制了服务器磁盘的人，都不会在得到视频存档的同时获得解密它的能力。

存储视频，并不一定意味着能够访问其内容。

这正是我们在 SesameDVR 中实现的模式。