阿里云周源：一篇文章读懂四代视频加密技术演进

在刚刚圆满落幕的LiveVideoStackCon峰会上，阿里云高级技术专家周源进行了《视频加密和DRM的实施实践》主题分享。周源，有十多年音视频研发经验，之前在淘宝视频负责开放平台，目前在阿里云视频云部门负责媒体处理，在大规模系统建设和云计算方面都有非常丰富的实战经验。本文为演讲原文，希望对视频内容安全从业者有一些启发。

在视频加密这块，其实是一个攻防战，攻防的手段非常多，还会不断的翻新，有很多技术手段，技术的发展也是日新月异。视频保护技术其实已经升级了好几代，我会给大家介绍下每一代技术是怎么做的、背后的原理、遇到的问题以及业界的解法。会从数据加密、全链路保护、数字版权管理、内容识别四个方面来介绍。

数据加密原理——算法的选择

最初，数据加密原理非常简单，我们在生活中如果有一样东西你想保护它，你会怎么办，你的第一反应可能就是拿把锁把他锁起来，自己保护好钥匙。在数字领域，这个“锁”有好多种，一种叫对称型的，一种叫非对称型的。

这两种算法分别有各自的优缺点，对称型算法的优点是计算量非常小，速度快，效率高。而它的缺点是密钥的管理和分发非常困难，如果别人配了相同的一把钥匙，就可以打开这把锁了，不够安全。常见的算法包括AES、EDS。非对称型算法的优缺点其实和对称型是相对的，优点是算法是公开的，你可以看到所有细节，即使这样，安全性也非常高。非对称算法有两种类型的钥匙：公钥和私钥。公钥可以开放给所有人，内容只能通过私钥加密，加密完成后，使用公钥就可以解密，但是不能进行加密。但是缺点是加密和解密花费的时间长，速度慢，所以不适合对大量数据加密，只适合少量数据的加密。常见的算法包括RSA、ECC。

在视频场景下，怎么去权衡对称加密和非对称加密？

媒体介质经历了几次升级，最早是文本，几十KB就是非常大的一个小说了；到了图片就发展到了几百KB，甚至MB的级别；如今视频时代，量级上到GB级别。所以视频的第一个特点是数据量大，加密算法速度不行的话是不够实用化的。

视频的应用越来越广泛，它不仅仅局限于某一个平台。用户会在各种操作系统、各种终端设备上去观看视频，在选择算法的同时，一定要考虑平台标准化这块。

更进一步的话，需要考虑移动端的功耗问题，大家做视频都在能耗和发热做斗争，选择算法的时候，一定要考虑功耗问题。

最终的选择——AES算法

基于以上考虑，业界大家最终会选择AES算法。它具有以下特点：

安全性，AES算法从数学上证明是安全的。把加密好的文件给到你，你没拿到钥匙的情况下，暴力破解需要花2104亿年的时间，这几乎是一个不可能完成的任务。现在也存在一种旁路攻击的方法，攻击的是实现方法，不是算法本身。攻击成本比较高，在增加成本的前提下，实现上是有规避的方法。所以安全性还是有保障的。
这个算法衡量了时-空占比，速度快、消耗小，适合小型系统上工作。
算法也非常标准化，也在绝大部分的硬件芯片、软件平台中进行内置，可以用硬件本身的能力快速做计算。

一般情况下密钥越长，安全性越高。但是密钥短并不代表运算速度一定会快。同时，因为均衡了时-空占比，AES算法的资源消耗也是最低的。所以，AES算法在对称算法中是首选。

AES算法的经典应用——HLS数据加密

举个例子，HLS协议使用M3U8文件格式。关键性的信息是下图中橙色的一行，这里加了KEY的信息。它的原理是播放器从网上把m3u8下载下来，解析后得到KEY，并且传递给服务器询问请求通过不通过，服务器如果认证通过，会把真实的KEY返回给播放器进行播放。

仅仅使用AES加密来包含内容时，它的安全问题出在哪里呢？

它的最关键的问题是——钥匙URL。因为URL要被写在文件里的，不管你做什么变化，无论加session、referer、token，它都是标准的HTTP请求，这是HLS加密的最大风险点。

因为网络请求是公开的，我们怎么保障网络传输安全性？防御中间人攻击？
而在客户端拿到钥匙后，实际上是明文内容，客户端的安全性又该如何保障？

如此我们便有了新解法——全链路保护

这里有两个很重要的原则，第一个是中间网络是不可信的，第二个是客户端是不可信的。接下来看看这两个问题如何解决。

关于中间网络不可信，HTTPS是最经典的方案。因为HTTPS整个流程保证了没有任何人能窃取中间的信息，安全的从服务端传递到客户端。

它整个流程是：黑色的部分是公开的，谁看到都不会影响安全性。客户端向服务端请求一次，服务端会返回公钥，客户端用公钥去把自己的对称钥匙保护一次。接着把加密后的对称钥匙传递给服务端，服务端使用秘钥解码后得到对称钥匙。这时候客户端和服务端双方都知道对称钥匙了，然后用对称钥匙对数据加密进行传递。这个方案即解决了安全性问题，又解决了效率问题。

关于客户端不可信。通常客户端是非常复杂的，常见的是浏览器，标准也很多（如下图）。但是在整个规划中，很重要的一点是：“有定义，但没有实现”。每个浏览器都支持H5的DRM方案，但是每个浏览器的支持方式都是不一样的。

H5整个流程是，当解码器拿到加密数据之后，数据流会经过CDM，这个模块会和外部系统进行通讯，去和License服务获取内容钥匙和授权规则，经过了这一步才能真正把流解密成明文数据去做渲染。所以，虽然有了H5的规范，但是实际上还是会被厂商绑定，客户端安全性完全由厂商提供的CDM来决定。

移动端方面，分为Web端和APP。Web端浏览器是非常复杂的，各种定制的WebKit引擎不支持内容解码模块（Content Decryption Module），只能采用JavaScript去写代码，它是明文代码，安全性很差。现在有一个新的技术WebAssembly，它是把JS编译一下，增加了破解的难度，但是还是没有从源头解决这个问题。APP是没有任何标准了，都靠自己去定制。

如此看来，我们想解决客户端不可信这件事，其实还有很多障碍在里面。同时，客户端不可信带来了很多问题，你没法知道你客户端里是好人还是坏人，如果是恶意用户，他的破坏力普通比较强，会给平台带来很大的损失。

全链路的保护解决了网络传输的安全，但是客户端的安全问题没有得到彻底完全的解决，所以在业界有了第三种解法：数字版权保护（DRM）。

更安全的加密方式——数字版权保护DRM

DRM基本是三足鼎立的情况，微软的PlayReady，谷歌的Widevine，苹果的FairPlay。不同操作系统、浏览器和移动平台需要不同的方案，所以看起来我们没办法用一套方案把所有的加密都做完。

所以如何跨平台把问题解决掉？——多重DRM解决方案

我们分别来看看三个厂商的方案：PlayReady方案中，当你的设备和服务得到一个认证后，才能接着发起License请求，分了两个阶段来提交。Widevine方案中，通过第一段来控制是否有权限复杂的钥匙，再从License去拿真正的钥匙。FairPlay方案中，播放器第一个流程是认证，第二个流程是获取License。

如此，我们有了多重DRM解决方案，它的流程是Player去问认证服务允不允许访问视频，后台经过认证后，会给一个认证后的token。当认证允许访问的时候，通过CDN分发网络从源站获取内容，当拿到内容后，有了token和视频KEY ID，就会把License返回，这里才有真正能解密内容的钥匙。

多重DRM可以降低加密成本，对于不同平台，把整个流程做一致化，只需要一份加密资产，降低了加密流程成本和管理成本。同时，因为原生 DRM 客户端在其原生平台上通常是免费提供的，也可以消除客户端的许可成本。

从技术角度上，整个业界有通用加密格式的规范，可以很好的把加密内容安全地传输到客户端。但是有一个现实情况，FairPlay的加密算法是不同的，为了实现多重DRM方案，我们需要两份加密资产，才能真正做到跨平台的保护。

那么DRM是否是最终的加密方案呢？从安全性上来讲，DRM用了非对称算法，但是依然会面临主密钥泄露这个问题，网上也出现HDCP主秘钥泄露、4K视频版权保护技术被破解等案例。

我们用钥匙去保护视频、在全链路保护上做了很多改进，并且采用了更安全的多重DRM方案，我们试图用各种方法把内容保护起来，这些思路都叫被动保护。被动包含的每种方法都有自己的缺陷，所以我们给出一种新的思路，叫内容识别。

主动保护——内容识别

目前，版权保护遇到的问题是“内容所有权”跟“版权”的关系越来越复杂，这使我想起凯文.凯利在《必然》中曾提出：“对已有事物的重新排列和再利用，而对传统的财产观念和所有权概念产生巨大的影响。”

这里面就延伸出来很多问题，用户是否对原有素材做了一定的转化，还是仅仅复制了原作？我们应该是严格禁止还是开放包容的态度？在这个全民导演的时代，我们可以看到很多用户把自己录制或者网上收集的素材重混起来，就成为了很成功的新作品。当然，版权方也有真实的案例，即使得内容得到了很好的二次传播，还惊喜地获得额外的收益。面对这样的情况，我们该如何进行高效地内容识别和保护？