构建DRM系统的重要基石——EMECDMAESCENC和密钥

Posted 2022-03-23 LiveVideoStack_

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了构建DRM系统的重要基石——EMECDMAESCENC和密钥相关的知识，希望对你有一定的参考价值。

▼扫描下图二维码了解音视频技术大会更多信息▼

翻译、编辑：Alex

技术审校：刘姗、周亚桥

本文来自OTTVerse，作者为Krishna Rao Vijayanagar。

Easy-Tech#016#——DRM

任何想要理解DRM（Digital Rights Management，数字版权管理）的人都要遇到AES、CDM、CENC、EME等缩略词。对于初学者来说，这些词很容易混淆，但只有理解了它们，才能真正地理解DRM。我们将在本文中简单介绍DRM的基本构成：EME、CDM、AES、CENC以及密钥和密钥服务器的使用。

DRM系统的简化架构

在上一期文章中，我们已经知道DRM使用加密技术和商业规则控制数字内容访问和消费。

简单来说，DRM系统可以：

为内容供应商加密内容提供工具和基础设施。
围绕加密内容构建生态，从而使内容供应商能够控制由谁来解密并消费内容。

在上一期文章中，我们看到Ram和Shyam将加密后的信息传递给对方。同时，Hari拿着密码本，由他决定谁可以读/写信息，还记得吗？

现在，让我们采用这个简单的系统，并把组件替换成保护和分发视频内容的技术。看看我们得到了什么？

从上图中可以看出，我们想要向认证用户安全地发送一部电影。需要：

向DRM厂商的服务器请求密码本
然后使用密码本加密视频
将电影视频发送给用户
用户向DRM厂商的服务器请求密码本解密视频
现在用户就可以观看电影了

真棒！

这些就是关于DRM的所有知识吗？

不！我们上文只是举了一个简单易懂的例子，说明如何使用DRM安全地传送电影。这个例子很好地描述了DRM的本质，但在现实中无法正常运行。

接下来，我们将一步一步地重新思考、设计这个简单的系统，看看它是如何通过DRM传输视频的。一起来吧！

第1步：回到ABR技术

讨论顺序前，让我们先来修改示例以适应视频传送中的ABR模型。

复习ABR： 通过使用ABR技术，电影可以被编码成不同的码率-分辨率组合（也称为码率阶梯）并被分割成小的视频块或者切片。每个视频切片包含几秒钟视频，可以被单独解码。

打包是指将电影分割成小的视频切片，并使用清单（manifest）或者播放列表对其进行描述。当用户想要播放电影的时候，他需要按照播放列表的信息播放。

根据可用带宽，播放器请求特定码率版本的视频切片，CDN响应后返回被请求切片。

MPEG DASH和HLS是使用ABR进行视频传输的常用手段。想要深入理解这些技术，请阅读：什么是HLS（HTTP Live Streaming）? 和Easy Tech：什么是MPEG-DASH协议。

让我们修改图片来表示ABR视频传送。

打包和基于CDN的视频传输是其中唯一更改的步骤。

好了，现在让我们进入加密环节。

第2步：视频加密

视频加密是指当有人截获我们的数据时，确保他们无法读取数据信息或者观看视频内容。

复习加密： 加密是一种用于保护数据机密并防止未经授权的人读取数据的技术。加密技术使用密钥将输入数据（明文）转化为一种替代形式——密文。没有密钥的情况下，几乎不可能将密文转换为明文。

然而实际上，没有密钥也有可能解密，但是通过逆向工程破解加密算法消耗巨大（包括时间、金钱以及所需计算资源）。

AES（Advanced Encryption Standard）是最流行的加密技术之一。AES也被称为Rijndael（由发明者的名字命名），2001年由美国国家标准技术研究所（NIST）推出标准，用于加密电子数据。

AES的技术要点包括：

对称密钥加密算法：使用同一把密钥进行加密和解密。
基于密钥长度，有三种变体：128bit、192bit和256 bit。密钥长度越长，越难破解。
如果没有密钥的话，破解AES-128需要10亿x10亿年，外加一台超级计算机。

鉴于本人并不是密码学专家，如果你想深入了解AES标准，可以查看AES的维基页面。

注意： 在视频领域，加密不是编码，解密也不同于解码。对于视频而言，编码和解码常常分别指压缩和解压缩。想要对编、解码和视频编解码器有更多了解，请阅读我们的文章：视频编码完全指南。

加密技术只有AES-128吗？

不，还有其他类型的加密技术，让我们用1分钟思考一下这句话的含义。

如果内容供应商决定和三家不同的DRM公司合作，并且它们都使用不同的加密技术，这意味着内容提供商需要加密视频三次，而这么做无疑是对存储空间和其他资源的浪费。

这就是CENC加密格式产生的原因——降低加密市场的碎片化趋势以及减少存储需求。

下文中我们会讲到。

通用加密CENC

在我们深入了解CENC之前，让我们先来看下OTT流媒体协议，尤其是CMAF。

MPEG-DASH和HLS是目前最常用的两个协议。其他协议还有MSS（Microsoft Smooth Streaming）等，但我们今天暂不讨论。

在视频传输中，MPEG-DASH通常使用mp4容器格式，HLS通常使用MPEG-TS (ts)格式。如果某个内容供应商同时使用MPEG-DASH和HLS，那么它需要存储一份mp4和ts文件格式的副本。

现在，我们加上DRM加密问题。假设三个DRM厂商使用三种不同的加密标准，那么内容提供商就需要为每个视频存储2x3=6种副本。这对存储空间是多么大的浪费！

为了解决视频流媒体协议所带来的第一个问题，CMAF标准应运而生，该标准规定可以以分段mp4容器格式（fmp4）存储视频。在MPEG-DASH 和HLS的支持下，你现在只用创建一组视频，以fmp4格式存储，两种协议使用同一组文件即可。

只要确保你创建了两个视频清单（叹气）。

统一加密如何？

如果不同DRM技术使用不同标准，我们仍然需要为每份文件存储不同的副本，对吧？

为此，MPEG开发了CENC（Common Encryption specification），规定视频既可以使用cenc（AES-128 CTR），也可以使用cbcs（AES-128 CBC）加密。CTR代表计数器模式；CBC代表密文分组链接模式。CENC意味着内容提供商仅需加密视频一次，并且任何解密模块都可以解密它。

注意： 只要密钥绝对安全，即使加密算法暴露也不会出问题。

CENC也许听起来像是统一DRM的简单方法，但事实并非如此。

目前市场中有三种主要的DRM技术：Apple FairPlay、Google Widevine和Microsoft PlayReady:

Apple FairPlay仅支持AES-CBC cbcs模式。
HLS仅支持AES-CBC cbcs模式（与CMAF无关）。
Widevine和PlayReady支持AES-128 CTR cenc和AES-128 CBC cbcs 模式。
使用CMAF的MPEG-DASH支持AES-128 CTR cenc 和AES-128 CBC cbcs 模式。
不使用CMAF的MPEG-DASH仅支持AES-128 CTR cenc模式。

如你所见，CMAF和CENC标准引发了流媒体领域的混乱局面和碎片化。

CMAF和AES-CBC cbcs模式的普遍使用可能能够结束混乱的现象，但是它们将如何影响仅支持CTR或者仅支持MPEG-TS的传统设备？

我们下次再讨论。

第3步：密钥、密钥ID和许可证服务器

到目前为止，我们已经确定将使用 AES-128bit对视频进行加密。在这个阶段，出现的几个问题是：

我们在哪里获得AES-128bit的加密密钥？
如何将加密密钥和电影联系起来？
在哪里存储加密密钥？

让我们来一一回答。

从哪里获得AES-128bit的加密密钥？

任何内容供应商都可以使用专业软件手动生成加密密钥。或者，由几个DRM厂商提供生成密钥的必需工具和软件。

如何将加密密钥和电影联系在一起？

让我们先来理解这么做的原因。当你去住酒店的时候，你要向酒店前台报房间号，才能申领房间钥匙，对吧？你做的正是通过告知房间号来为钥匙和房间建立联系。

类似地，当你用一把密钥加密某部电影时，我们就需要建立这种联系，并将它提供给DRM许可证服务器（也就是酒店前台）。

在DRM中，密钥ID提供了加密密钥与电影之间的联系，它是一串独特的字符串，在为特定电影创建加密密钥时生成。

最后，在哪里存储加密密钥和它的密钥ID？

加密密钥和密钥ID存储在和DRM许可证服务器一起工作的KMS（密钥库）中。

当客户端需要播放加密电影时，它通过提供此电影的密钥ID向DRM许可证服务器请求解密密钥。如果DRM许可证服务器对请求（认证请求）认可，它将要求密钥库提供与该密钥ID对应的解密密钥。

审校者注：一般向DRM许可证服务器申请的不是“解密密钥”，而是“许可证”，许可证服务器会根据密钥ID申请解密密钥，然后生成许可证下发给客户端。

加赠一问： 密钥ID是如何传送到播放器的？

基本原理：没有密钥ID，许可证服务器无法查看电影的解密密钥。

答案： 密钥ID与DASH或者HLS清单一起被发送到视频播放器。播放器解析清单，找到密钥ID，然后向DRM许可证服务器请求密钥ID对应的解密密钥。

现在，我们来总结一下围绕加密密钥、密钥ID和许可证服务器的讨论。

加密密钥具有保密性，需要和对应密钥ID存储在一个安全的密钥库。
密钥ID可以“公开”。
任何拥有密钥ID的人都能向许可证服务器请求私密密钥（解密密钥）。由DRM厂商对请求者进行身份验证，然后再提供（或拒绝提供）解密密钥。

下面这张图描绘了我们刚刚所学的密钥、加密和许可证服务器知识。

第4步：在播放器和密钥服务器上解密视频

在客户端（播放器应用），用户按下播放键，开始播放他想观看的电影。现在视频播放器需要一种方法来识别电影是否被加密。否则，播放器将试图播放加密电影，继而崩溃，最终导致糟糕的用户体验。

可以通过以下方式发出电影已加密的信号：

可以在清单中添加注释，说明该电影已加密，且提供密钥ID。
另外一种方法：在视频码流中插入一些包含独特信息的字节。当播放器在播放前检查视频码流时，它就会采集到该独特信息，并确定这部电影已加密。

播放器中接下来几个步骤更为直观：

播放器发现密钥ID并向许可证服务器请求解密密钥。
许可证服务器通过预定义的机制来识别播放器请求是否经过验证。
如果许可证服务器通过了播放器的验证，它将返回带有解密密钥信息的许可证。

我们刚刚描绘了一个简单的方案，但无论在技术上还是商业上，都存在很多问题。让我们来看看最开始出现的一些问题：

1、我们已经描述了一个原型“播放器”，它向 DRM许可证服务器发送解密密钥请求。但是：

许可证服务器如何知道播放器是否可信赖？
如果播放器中的解密软件泄露出密钥和解密内容该怎么办？

2、如果你是一个视频播放器开发者，你必须为每个DRM技术开发解密模块吗？当它们更改界面时，你也必须每次都要跟着更新吗？

此外，播放器（客户端）中的事件序列如下所示：

从CDN获取电影及其清单
在清单中提取出密钥ID
生成许可证请求
将请求发送给许可证服务器
静待许可证服务器的响应
使用来自服务器的解密许可证解密内容
解码解密内容
显示解码后的电影

一个单一程序或者公司无法完成上面所有步骤。

它将形成一个紧密耦合的架构，并无法实现任何具有开放性、即插即用的生态系统。让我们看看可以做些什么。

播放端架构

在播放器层面，前文描述的职责被划分为不同的模块，如下所示：

播放器负责获取电影，解析清单，提取密钥ID，向DRM许可证服务器发送请求等。
一个单独的模块（称为 CDM 或内容解密模块）负责创建许可证请求、解密和解码内容。

现在，让我们来看下CDM。

内容解密模块CDM

每个DRM厂商都会提供：

自己的机制创建许可证请求（通过密钥ID、设备标识符、签署请求等）。
自己的机制来理解从DRM许可证服务器接收到的许可响应（该响应也被加密）并提取解密密钥。
在客户端本地存储许可证，许可证更新以及过期等规则。

通过上文这些细节，CDM模块便能够嵌入如Chrome、Firefox、Microsoft Edge和Safari这样的浏览器中。

DRM厂商测试和验证这些CDM来确保：

许可证请求格式正确且符合规范。
它们不会泄露解密密钥。
它们不会泄露解密和解码电影。
它们能够根据许可证规范安全地存储解密密钥（比如存储密钥时长）。
安全地将视频传输到屏幕，不会泄露。

由于以上原因，浏览器中的CDM都是闭源的，这也是行业和外界争议的根源。因为外界无法看到CDM中的源代码，所以人们无法信任它。

注意： 少数几个浏览器提供关闭CDM的选项，但是如果你这样做了，将无法观看受到DRM保护的内容。这就是行业的权衡。

下面是一张Firefox插件页面中Widevine插件的一张截图（来自我的Ubuntu 20.04计算机）。

等等，另外一个技术细节我们还没有讨论。

加密媒体扩展EME

我们在前文已经知道，播放器应用需要与浏览器中的CDM“对话”，并与许可证服务器交换许可证信息，对吧？

为什么说这既是一个技术问题，也是一个商业问题？

播放器厂商需要集成所有不同的许可证服务器和CDM，并跟踪其界面的更改以保持最新状态。
一家播放器公司说他们不会支持一些广受欢迎的平台，因为这些平台频繁更换界面，就会导致最后极有可能没有人来购买播放器，那就糟糕了！

这就产生了介于播放器和CDM之间的EME（加密媒体扩展）。EME 为播放器（应用程序）提供了一套标准化的 API 来与 CDM 进行通信。

现在让我们来了解EME和CDM是如何一起工作的：

EME是一个javascript API。
CDM是解密视频、解码和显示视频（可选）的软件。
视频播放器是一个JavaScript程序，它使用EME API在CDM和许可证服务器之间传输信息。

EME的优势是： 由于EME带来的互操作性，供应商和播放器厂商可以开发能在不同浏览器观看视频的流媒体服务。你可以开发一个使用EME标准与许可证服务器和CDM通信的App，而不用考虑使用哪个DRM平台和浏览器。

视频解码和显示

视频被解密后，需要进行解码并显示给用户，这个过程是不能暴露解码、解密信息或者原始帧的。CDM是解密数据的第一个接触点，它在阻止数据泄露方面发挥了重要作用。

当播放视频时，CDM分别可以：

解密电影并将码流传送给应用程序（不太安全，因为有人会破解应用并转储视频）。
解密、解码并将解码后的视频帧发送到平台显示引擎。
自己解密、解码和显示视频（最安全）。

这个过程在软件和设备硬件（更安全）中也会发生。

将所有技术集成在播放器（客户端），我们得到了下面的图。

我们的DRM系统原型已经就位。

但是还缺少一些能够吸引内容供应商的重要特性。

第5步：身份验证、证书轮换和支持离线播放

在此阶段，我想将头部DRM技术供应商（比如Apple、谷歌和微软）和围绕这些技术提供服务的DRM厂商区分开来。在这一部分，让我们一起来了解一下行业中对DRM技术（可能由DRM技术供应商或DRM厂商直接提供）所提出的一些商业规则。

用户身份验证

FairPlay、Widevine和PlayReady这样的DRM技术供应商不提供用户身份验证服务。但DRM厂商可以！当用户按下播放键，一个单独的服务器来验证用户资格（比如用户ID）。它根据订阅级别、促销优惠码等信息检查用户是否有权播放该内容。在服务器验证用户权限后，App可以向许可证服务器发出许可证申请。

注意： 以上只是用户身份验证的简化版本，专业的DRM厂商需要更复杂的验证流程。

地域封锁

当内容供应商想要阻止一部电影在某些地区的播放，就会使用地域封锁。和用户身份验证类似，这是大多数DRM厂商的附加服务。当用户按下播放键播放某部特定电影时，DRM厂商的服务器就可以检查这部电影是否可以在用户所在地区观看。根据内容供应商设定的规则，许可证和加密密钥被传送（或者拒接传送）给客户端。

永久和非永久许可证

顾名思义，许可证服务器在接收永久许可证后，可以将其存储在客户端设备上。它可以一直用来播放电影，直到许可证过期。在许可证过期之前，CDM需要生成一个许可证更新请求。

非永久许可证用于立即播放电影。它们并不能长期存储，一般在当前播放会话过期后（或者在会话中间，当设置了短期过期时间时）弃用。

密钥轮换

密钥轮换是指为了减少攻击，使用不同密钥加密视频的不同部分（切片）。假如一个黑客获得了某部电影的密钥，在密钥轮换的情况下，他就只能观看这部电影的一小部分，因为其他部分使用了不同的密钥。除此之外，通过使用多重密钥，你可以将不同的许可规则对应视频内容的不同部分。比如，某部电影的“幕后独家部分”只向Premium会员开放，其他免费订阅用户只能观看余下的电影内容。

离线播放

当网络连接不可用时，某些服务会提供离线播放视频。当我知道我将要长途飞行时，我就会在Netflix上下载几部电影。在这种情况下，播放器无需与许可证服务器通信获取DRM密钥。

同时，DRM供应商需要提供一个能够将密钥安全存储在设备上的选项，这样内容才能被解锁，并在不联网的情况下播放。需要高度安全的CDM实现防止密钥泄露。

视频的优化加密

加密和解密电影有可能会非常昂贵，尤其是在UHD和4K电影中，这个时候就需要优化加密。其中一种优化方法是仅加密每个视频切片的帧内容（关键帧或I帧或IDR帧）。这种方法有几个优势：