视频内容安全保护技术分析与实现

近年来，视频已逐渐成为互联网内容的主流，如何保障视频内容的安全，防止非法盗版，传播成为众多企业关注的重点。在LiveVideoStackCon 2018 大会中，OnVideo视频云创作平台联合创始人刘歧详细介绍了防盗链的基本策略以及HLS/DASH加密等视频媒资保护技术手段的原理与实现。

文 / 刘歧

整理 / LiveVideoStack

大家好，我是来自OnVideo视频云创作平台的刘歧，本次我将从以下几个方面与大家分享我们在视频媒资版权保护技术方面的探索。

1. 需求来源

对于视频内容提供商来说，最宝贵的资源便是流量。如果某一平台花重金购入一项视频内容版权或自主生产一颇具价值的视频内容后发现有非法组织对其进行盗链，面临的问题就是经由平台访问此视频内容的流量仅占全网此内容总访问流量的很少一部分，也许经由侵权方访问资源的流量高达上百TB但通过平台正版渠道访问资源的流量仅有几百GB，这无疑对平台来说是一笔巨大的损失。因为用户流量的规模直接影响到视频平台与广告投放主的议价能力，仅生产或购买了内容却无法将其价值高效转化为实际收益，这是被盗链后企业面临的难题之一；除此之外，对于一些采用会员订阅制将独家拥有的版权的资源为购买了VIP的用户推送的平台来说，其花重金实现的独版权家拥有优势将不复存在，这无疑使企业蒙受巨大损失，同时也严重损害到了那些已经付费的用户的公平与对平台的忠诚度。以上说明了视频媒资保护的原因，为了保护视频内容我们需要做的不单单是为视频添加水印等那么简单，而需进一步实现主被动保护，从源头阻止像视频盒子、聚合APP等非法方获取正版视频内容，同时确保收费节目与视频内容生产过程的版权不受侵犯。

2. 直播内容保护技术

首先我们需要了解直播内容保护技术中不可或缺的封装方案与传输协议。常见的封装方案除了Adobe的FLV还有HDS与RTMP，其中FLV与RTMP在国内的使用较为广泛，HDS虽没有像前两种方案那样被广泛应用，但却被个别企业当作一种技术门槛用于竞争。HDS、HLS与DASH均通过对文件进行切片实现数据封装，而HDS相对于FLV与RTMP的优势在于其支持动态多码率切换，适时切换高清与低清以保证播放视频的流畅体验。虽然DASH在国内并未被广泛使用，但在国外DASH的使用更为普及，例如FFmpeg中就有开发者使用CNN,BBC,youtube的流测试DASH支持情况。使用这些封装方案之前我们应当清楚每种方案其字段中存储着哪些数据，从而更高效使用并发挥其全部功能。

Adobe的HTTP+FLV支持Token、Referer、User-Agent与ACL四种防盗链，其中ACL类似于白名单机制，Token则通过对时间有关的字符串进行签名，将时间、签名信息通过一定的方式传递给 CDN 节点服务器作为判定依据， CDN 边缘节点依据约定的算法判断来访的 URL 是否有访问权限；Referer则通过判断请求数据地址对请求方进行限制与筛选，而User-Agent则主要用于限制有未知方使用Wget客户端或FFmpeg拉取数据的非法行为。不过虽然国内多使用FFmpeg，却鲜有人在写代码时考虑使用User-Agent实现对FFmpeg非法拉取数据的限制。RTMP除了支持Token、Referer、User-Agent与ACL，还支持SWF防盗链。SWF多用于仅PC端播放的场景，使用SWF对视频内容进行加密并在借助RTMP传输数据时添加校验密钥，如果在Handshake时校验不通过则阻止访问，整个过程需要服务端的支持才能进行。需要提醒的是，上图表格所列标准均为Adobe的私有标准，所以像HEVC、AV1等虽然可以使用上述防盗策略，但集成防盗链后如何使用RTMP播放器播放则是难以实现的。

2017年苹果正式全面支持HEVC，主要使用了MPEGTS与Fragment MP4（FMP4）两种方案，其中MPEGTS支持AES-128、SAMPLE-AES。而FMP4支持AES-128，但SAMPLE-AES仅支持CBCS。苹果宣布支持HEVC后不久我们很快实现了。防盗链对HLS封装的兼容，使得HLS支持Token、Referer、User-Agent与ACL的同时也支持Session。

DASH协议中比较常见的同为FMP4与MPGEGTS，其中MPEGTS支持AES-128、SAMPLE-AES而FMP4支持AES-128与全部SAMPLE-AES。 DASH相对于HLS的优势在于其支持所有内容加密方式。

上面展示的就是四种加密标准的全称。Google之前并未对这种counter加密提供支持，现在实现了支持，而苹果的标准只支持NAL的局部采样加密，且除了支持以上标准也支持AES128。

如果给根据不同的特务特点进行标准选型，我们需综合考虑不同协议对多种加密方式的兼容性与Codec等其他因素。例如FLV、HDS与RTMP，由于以上三种协议均由Adobe开发而Adobe很少更新，所以他们在Codec上仅支持AVC；而AVC相对于HEVC的缺陷在于其带宽占有率更高。如果使用HEVC我们建议采用国际标准以确保内容在所有平台与全链路上的良好兼容，私有标准会为其他播放或处理端带来不必要的麻烦。HLS与DASH可实现对HEVC的良好支持，甚至DASH也可支持VP9等。需要提醒的是，RTMP如果使用加密则仅支持RTMPE与RTMPS两套加密方案。

如果希望实现类似于DRM基础加密技术，不考虑服务器端仅实现内容加密则推荐使用Shaka Packager。FFmpeg本身仅支持CENS，不支持CBCS的加密方式。如果希望实现HLS加密可以考虑Shaka Packager与MP4Box。

尽管有上述那么多加密方式，视频内容的盗版依旧防不胜防，主要原因就是以下三个抓包工具：Wireskark、Firebug与WebBrowser。仅需通过抓包工具抓取并分析包中内容，即可提取其中所有字段与内容信息。如上图展示的那样，获取网页原始信息之后，其中的URL就可被盗链的人通过wget或FFmpeg/ffplay保存或播放内容。

也可通过模拟对应项目的Referer与Token盗取内容。

经过HLS与DASH保护的内容同样可被盗取。当盗链者盗取对应m3u8内容中的Key信息之后会首先获取内容链接，然后使用Key解锁对应内容。大家可以留意一下中央电视台CNTV的网络流即使被抓取后播放也显示花屏，我推测其关键在于Key信息并非存储在m3u8或mpd中，而使用部分内容加密的策略使得传统破解方式得到的IDR信息不准确从而导致非法播放不正常。

限制播放次数也是一种直播内容保护措施，其策略是宁可错杀不可错放，其原因在于盗版侵权为企业带来的经济与法律上的损失远比极个别用户无法正常播放内容要严重；除此之外，使用非标准协议如私有Codec封装也是一种颇为有效的加密方式；最后也可实现类似3DES双边协定的对称加密方式，虽然需要自己频繁更新但其优势在于不需要添加传输中的内容加密。

3. 攘外安内的技术

对于任何一家以内容版权为核心资产的视频公司来说，出现内鬼从企业内部盗取资源所带来的损害无疑是最严重的，这就对内容保护提出了更高的要求。

为了解决此类问题我们需要引入一些其他的内容保护措施，具体来说就是为视频添加水印，并仅给用户观看预览片段而非原片；预览的部分片段需要经过重新转码处理，在这里我们考虑使用傅立叶变换。我们知道一般的信号分为时域和频域，通过傅立叶变换可实现时域与频域的分离，随后我们根据内容生成对应水印并加入频域当中，最后再将时域和频域合成为原始图像。这样处理虽然用户端不会看出视频有什么变化，但通过我们自己的识别系统可识别水印并追溯视频盗取源头。

以上图为例，用户可以看到的原始画面是湖水，而我们将Logo作为水印添加至画面中后用户所看到的画面不会受到任何影响；通过傅立叶变换、转码等一系列操作后图片当中的水印就可被机器识别，而这种方案的缺陷在于如果画面背景为黑色或暗色会造成水印不清楚难以被机器察觉。这也提醒我们单纯的一种内容保护技术并不能完美解决所有盗链侵权行为，最好的方案是将多种防盗策略与技术综合使用，虽然成本会相应提高。

4. 未来展望

我们目前接触到的FLV或RTMP都是标准的TCP传输，而在未来私有Codec实现的非标准封装可有效保证内容的安全；除了封装标准，传输协议也可以实现自定义从而进一步强化防盗链的稳固，例如现在斗鱼便使用了自主传输协议，使用非真实的后缀达到掩人耳目的效果；融合区块链技术强化版权保护也是未来的发展趋势，具体来说就是分布式鉴别，去中心化的版权验证方式也是现在各大公司探索的热点。