打包和基于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 进行通信。
