如何流式播放仅用户持有密钥的端侧加密S3远程视频文件

原m3u8播放方案跑不通，核心是没对齐HLS对AES-CBC加密的规则要求，和整文件AES-CBC加密的逻辑存在本质冲突：

• HLS原生支持的AES-128-CBC加密要求每个TS分片独立加密、独立做PKCS7填充、每个分片对应独立IV，分片之间不存在CBC模式的块链式依赖；如果是对整个视频文件做单次AES-CBC加密，直接按字节偏移切分片挂m3u8，播放器拿到分片后因为缺少前序密文段作为CBC解密输入，解密结果会完全乱码。
• 若m3u8里的EXT-X-KEY标签配置不符合规范，或者密钥请求走了公网/跨域地址被浏览器拦截，播放器拿不到密钥也会直接播放失败。

所有方案都不需要上传密钥到S3或其他第三方服务，带宽仅消耗实际播放的片段，不会拉取全量文件。

方案1：改造为标准HLS分片加密（最优解，带宽最低，兼容性最好） #

不需要额外转码算力，兼容所有支持HLS的播放器，带宽利用率最高：

• 本地预处理（全程离线完成，密钥不流出本地）：
  • 将原视频按2-10秒的固定时长切为TS分片，不要对整文件做一次性AES-CBC加密
  • 每个分片单独做AES-CBC加密：可复用你持有的同一个密钥，IV按分片序号生成16字节大端值（符合HLS标准要求），每个分片独立做PKCS7填充，加密时不要保留跨分片的CBC链式状态
  • 生成标准m3u8索引文件，在文件头添加#EXT-X-KEY:METHOD=AES-128,URI="local://key"标记，注意URI不要填公网可访问的密钥地址
  • 把加密后的分片和m3u8文件上传到S3即可
• 播放逻辑：
  • 前端加载m3u8后，通过S3的Range请求按需拉取当前播放位置需要的分片，不会下载全量文件
  • 用hls.js或原生HLS播放器的请求拦截能力，拦截到local://key的密钥请求时，直接从本地内存返回你持有的密钥，不需要发起公网请求
  • 播放器会自动完成分片解密、拼接、播放，不需要额外开发解密逻辑

存量整文件加密的视频不需要重新全量下载重处理：可以通过S3 Range请求拉取对应位置的密文，在本地内存完成CBC块对齐、解密、重分片，直接喂给播放器即可，全程不落地全量文件。

方案2：MSE+分块Range拉取+端侧解密（适配现有整文件加密资产，无需重加密） #

如果不想改动已经上传的整文件AES-CBC加密视频，用这个方案，带宽消耗和方案1一致：

• 核心原理：AES-CBC的块大小固定为16字节，解密仅依赖当前密文块+前16字节密文作为IV，不需要拿到全量文件就能解密任意位置的内容
• 实现步骤：
  • 前端初始化MediaSource，创建对应编码的视频源Buffer
  • 监听播放进度，提前10-20秒计算接下来需要播放的内容对应的密文偏移：拉取Range时往前多偏移16字节，保证CBC块对齐
  • 发起S3 Range请求拉取对应区间的密文，在本地内存用持有的密钥完成AES-CBC解密，将解密后的明文分片追加到MSE缓冲队列
  • 缓冲即将耗尽时自动拉取下一段密文，拖动进度条时直接终止未完成的请求，按新的播放位置重新计算偏移拉取即可，不会产生多余带宽消耗
• 优化点：单次拉取的块大小设置为1-2MB即可，平衡加载速度和带宽浪费。

方案3：流式fetch+边下边解（实现成本最低，适合快速上线） #

如果不想做复杂的分片和MSE逻辑，可以用这个方案，带宽比全量下载低40%以上：

• 给S3上的加密视频生成短时有效的预签名URL，前端用fetch的流式读取能力逐块拉取密文
• 拉取到密文后直接在本地内存做AES-CBC解密，将解密后的明文流通过Blob URL喂给video标签
• 缺点是进度条拖动体验不如前两个方案，跳转未下载位置时需要重新发起Range请求做块对齐。

• 不要整文件加密后直接按字节偏移切m3u8分片：CBC块链式依赖会导致非首个分片解密失败，出现花屏、卡顿
• 不要把密钥放到公网地址：所有密钥返回逻辑都在前端本地完成，避免密钥泄露
• 注意填充规则：分片加密时每个分片要独立做PKCS7填充，不要复用整文件加密的填充逻辑，否则最后一个块解密会报错

内容的提问来源于stack exchange，提问作者mufumade