为大型 OTT 服务迁移 DRM 解决方案提供商

DRM 是 OTT 生态系统的重要组成部分。OTT 服务提供商/广播公司支付数百万美元购买内容版权，然后对内容进行处理并提供给用户。

最重要的是，要防止未经授权观看内容。DRM 在这方面发挥着重要作用。

在 Zee5，我们使用以下 DRM 加密参数对所有电影/原版/电视节目进行加密。

ABR协议和容器	加密演算法	DRM 系统
DASH fMp4	AES CTR	Widevine 和 Playready
HLS CMAF	AES CBCS	Fairplay

从 2023 年 3 月起，Zee5 OTT 解决方案使用的 DRM 密钥和许可证提供商已发生变化。

这是一个极具挑战性的迁移，因为它不仅意味着所有新加密的内容，而且意味着Zee5 平台上数以百万计的现有内容（使用现有密钥提供商或某些旧解决方案的密钥进行加密）将在所有客户端设备上无缝播放，而无需任何操作。不便（无缝的用户体验至关重要）。

这就像在高速公路上以 200 公里/小时的速度行驶时更换汽车的发动机一样，期望这些变化对乘客来说是透明的！

商业要求意味着 2023 年 2 月 28 日是我们可以使用现有（当时）DRM 密钥/许可证解决方案提供商获取播放许可证（并获取用于 ABR 后加密打包的密钥）的最后一天。因此，端到端软件和所需部署的整个变更必须在此之前完成。

我们实际上只有 1.5 个月的时间来完成整个迁移（同时我们对 Zee5 的第一个体育赛事进行 OTT 直播）。整个 Zee5 Tech 团队齐心协力，确保我们克服了这一巨大的挑战，我们确实取得了出色的成绩！

以下各节将深入探讨有关此迁移如何工作的更多技术细节。

内容加密和观看流程

在进入解决方案之前，我们先来了解一下 OTT 内容的加密和解密是如何进行的。

加密 OTT 内容

在 OTT 内容处理流程中，加密通常是在包装后进行的。以下是加密步骤：

打包商生成 HLS 和 DASH 打包片段后，会请求 DRM 密钥提供商提供用于加密该资产的密钥。通常，作为请求的一部分，打包商会提供以下信息：
- 所需元数据的 DRM 系统（Widevine、Playready、Fairplay 等）
- 资源/资产 ID（申请密钥的资产的唯一标识符）。
- DRM 密钥 ID。
请求应符合 CPIX 规范（通常应将 CPIX 定义的 XML 作为请求体）。
DRM 密钥提供商收到请求后，将创建加密密钥，并在其数据库中存储 <resource Id, DRM key ID and Key>用符合 CPIX 标准的 XML 响应请求。
打包程序会解析返回的 XML，并获取 DRM 系统专用加密元数据和密钥等信息。这种特定于 DRM 系统的元数据（用于 Widevine 的 cenc:pssh、用于 Playready 的 mspr:pro、用于 Fairplay 的 skd/IV 等）会被打包程序嵌入到相关的清单中。
打包程序使用加密密钥，以适当的算法对片段进行加密。
加密完成！

在 OTT 内容播放期间获取 DRM 许可证

关于 OTT 内容解密流程，步骤如下：

需要先下载Manifest，并从Manifest中获取加密特定的元数据。
之后，播放器选择首选 DRM 系统（对于 DASH）或唯一可用的 DRM 系统（对于 HLS），然后为该系统准备适当的 DRM 许可证请求，并将其发送给 DRM 代理。
DRM 代理基本上可以更好地控制向 DRM 许可证提供商发出的请求。
DRM 代理将许可证请求转发给 DRM 许可证提供商，并将许可证提供商的响应转发给播放器。
收到的许可证应该是可解析的，只有符合要求的设备才支持获取密钥。
一旦接收并处理了许可证，播放器就具备了解密片段所需的一切条件！

迁移到新的 DRM 密钥提供商

通过去年早些时候与新的 DRM 密钥/许可证解决方案提供商进行的 POC，我们了解到新解决方案提供商的许可证服务器所要求的 Fairplay 许可证请求正文格式与我们传递给现有 DRM 许可证服务器的格式有很大不同。

不过，对于 Widevine 和 Playready 来说，相同的有效载荷格式（用于许可证请求）适用于两个密钥服务器。

此外，我们发现的另一个关键问题是，当 DRM 代理向解决方案提供商的许可证服务器发送许可证请求时，需要作为标头传递一个令牌，该令牌需要根据名为 drmResourceId 的新字段生成（该字段的值实际上与加密密钥请求期间为获取密钥而传递的名为 contentId/resourceId 的标识符的值相同）。

向现有 DRM 许可证服务器申请许可证时不需要该令牌和 drmResourceId。

以下部分描述了客户端和 OTT 内容生成/后端方面的变化，以便成功实现迁移。

在这些迁移活动中，需要牢记的关键一点是，没有开关可以打开，从而确保所有内容都能过渡到新系统。在这一阶段，DRM 代理需要根据内容到两个服务器上申请许可证。

服务器端更改

我们决定将所需的活动分成多个步骤来执行。我们采取的步骤按时间顺序排列如下：

一个后台脚本不断向传入的密钥/许可证提供商 DB 中填充所有现有加密内容的密钥和 DRM 密钥 ID（有些内容是在 2018 年或更早的时候创建和加密的！）。

更新转码数据库，添加一个名为 drmResourceId 的新字段，其值与每个加密内容的 resourceId /contentId 相同。

对于所有要转码的新内容，从现有密钥服务器获取密钥，但将三元组存储到传入的密钥/许可证提供商数据库中。因此，对于所有新内容，所需的详细信息都会存储在两个密钥服务器的数据库中。

这里有一项艰巨的任务等待着我们，那就是如何向 DRM 代理传递 resourceId（与 drmResourceId 字段的值相同，将是生成令牌的成分，而令牌将是许可证请求的一部分）？
- 相关后端组件（DRM 代理）从中获取资产详细信息的数据库/缓存中没有条目。
- 从转码数据库到将这些信息传输到 DRM 代理的输入数据库，有四个数据库作为下一个下游数据库的源，这些数据库是 SQL 和非 SQL 的混合体！
- 将所有这些数据库与数百万内容的新字段同步，这本身就是一项巨大的成就！
- 该机制适用于现有内容（已使用现有许可证服务器或旧版解决方案加密的内容）。我们在数据库
- 将此字段称为 drmResourceId，以避免与任何其他已命名为 resourceId 的字段冲突，并规定此字段仅用于 DRM 令牌生成。

随着 drmResourceId 传播的开始，我们开始在打包过程中将传入的密钥/许可证提供商用作密钥源。这确保了我们不再使用现有解决方案提供商的密钥服务器来生成（和存储）新密钥，而新密钥只会填充到传入的密钥/许可证提供商数据库中。我们改变了上述数据库之间的同步机制，允许将这个新字段（drmResourceId）带入输入数据库，以便 DRM 代理获取新生成/发布的内容。

由于上述对已有内容的同步需要一段时间，因此 DRM 代理开始向输入的密钥/许可证提供商服务器查询内容（我们可以为其生成令牌）的许可证。

最终，当 drmResourceId 的 100%填充完成后，对于所有许可证请求，DRM 代理都开始转到传入密钥/许可证提供商的服务器。

最后，在二月底，我们开始从传入的解决方案提供商许可证服务器上获取在客户端设备上的所有 Zee5 应用程序上播放的所有加密内容的许可证。

客户端变更

对于使用 Fairplay 加密内容的设备（iOS 设备、Apple TV 和 Safari 浏览器），播放器生成的用于从传入解决方案提供商的许可证服务器获取许可证的许可证请求正文需要与许可证请求正文不同现有许可证服务器所需。它主要与请求格式（二进制与 ASCII）有关。
因此，作为迁移的一部分，软件版本的强制升级支持根据后端的信号生成两种类型的许可证正文格式。