背景 & 现状

之前有写过一篇文章，介绍音视频hls加密服务的搭建：媒体处理-音视频 HLS 加密服务设计
KMS服务提供的是token校验的方式（一次性 + 时效性），来保证视频播放的安全性
- token的获取，需要业务后端跟KMS服务器换取，此时我们认为业务后端已经验证了用户身份有权限观看视频
上述方案提供的其实是一种标准的hls解密的流程，由于整个流程都是标准化的，很容易被一些市面上的自动化工具进行解密，安全性方面还是存在不足的
- Safari浏览器可以直接播放带token的m3u8链接
- 一些开源的播放工具（hls-js.netlify.app/demo/），一次性token可以预防
- 通过ffplay工具：ffplay '${url}'

业界推荐的实现方案

相关文档：cloud.tencent.com/document/pr…
- 目前自研加密服务属于hls普通加密（通过一次性token加持，可进一步提高安全性）
HLS 普通加密：cloud.tencent.com/document/pr…
- 通过 QueryString 传递身份认证信息，该方案适用于任意支持 HLS 的播放器
  - 用户登录并派发用于身份验证的token
  - 获取包含key防盗链签名的多码率播放地址
  - 获取视频内容（已加密）
  - 获取视频解密密钥（携带身份验证cookie）
    - 需要app后台自己验证用户信息，验证失败拒绝请求，成功则调用kms换取密钥并返回客户端
HLS 私有加密：cloud.tencent.com/document/pr…
- 原理架构：m3u8 的 keyURL 获取到的其实是加密后的密钥，超级播放器会使用私有协议解密获取到真正的内容密钥
- 局限性：目前该方案只提供于云点播服务，对于对象存储腾讯云也是只提供了标准的hls解密流程

实现方案：
- 根据抓包的请求，目测使用的是腾讯云的HLS私有加密方案
  - 结合使用的是腾讯提供的播放器 TCPlayer
- 通过使用云厂商提供的加密方案结合专用的播放器进行音视频解密播放，整个解密操作在播放器端进行定义，可以有效的防止自动化工具的破解
防盗效果：
- 使用ffplay无法直接播放：
- Safari浏览器打开，不能直接播放，而是被当作附件下载（下载内容是被加密过的，本地无法播放）
- 开源的播放工具打开，能正常下载ts文件，但不能解密播放

vip视频链接：www.mgtv.com/b/445012/16…
实现方案：
- m3u8（非加密）+ referer防盗链 + 时效性
  - m3u8访问链接
  - ts文件访问链接
    - 直接访问会报403
    - 加上referer（www.mgtv.com/）即可正常下载，且本地可以直接播放ts文件（说明视频分片并没有进行加密）
- 时效性：将前一天的m3u8文件进行访问，会报403，应该是在链接中有时效判断，达到防盗链效果
防盗效果： ffplay无法直接播放，加referer请求头可以绕过限制，可以直接播放视频
- ffplay -headers 'referer: https://www.mgtv.com/' '${m3u8-url}'

目前希望解决的问题是防止一些工具或者插件自动化下载我们已经加密的文件，提高安全系数
- 要防止自动化插件，最根本的方式就是打破标准的播放流程，就需要改造播放器，可能涉及到前后端之间约定一定到私有协议
  - 密钥二次加密：密钥服务接口响应密钥时，对明文密钥进行加密，由播放器进行解密
- referer防盗链：最容易实现，对原来域名进行referer白名单限制，前后端都不用改，安全系数一般（参考芒果TV付费视频），可以配合hls加密方案的使用
- 一次性token：有一定的安全系数，一般播放器获取到m3u8后会自动去触发密钥获取，此时token便失效，无法二次使用，除非用户在中途截获带token的URL

要防止自动化下载一般都是打破标准解密流程，就是对数据秘钥做二次加密，播放器侧做一下解密操作，相当于工具自动化下载下来的秘钥是加密过的秘钥。这种也是只能防止部分，对于web播放器来说也没啥秘密可言
这块都是攻防策略，策略都是通过提高成本来提高对应的安全系数
一般这个策略都需要自己去设计，对于做自动化工具的人，一般不会花心思去研究的