带加密的 HTTP 实时流式传输答案

【问题标题】：HTTP live streaming with encryption带加密的 HTTP 实时流式传输
【发布时间】：2011-05-28 09:04:40
【问题描述】：

我正在尝试了解 Apple 在其 iOS 设备以及 Safari 上支持的 HTTP Live Streaming 协议如何保护解锁内容的密钥。

按照我的理解，.m3u8 文件将整个内容放在一起并引用内容（在 MPEG2 TS 容器中，AES 128 加密）和 TS 文件的密钥。

就像这个例子：

   #EXTM3U
   #EXT-X-MEDIA-SEQUENCE:7794
   #EXT-X-TARGETDURATION:15

   #EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=52"

   #EXTINF:15,
   http://media.example.com/fileSequence52-1.ts
   #EXTINF:15,
   http://media.example.com/fileSequence52-2.ts
   #EXTINF:15,
   http://media.example.com/fileSequence52-3.ts

   #EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=53"

   #EXTINF:15,
   http://media.example.com/fileSequence53-1.ts

假设基于浏览器的播放，其中<video> 元素在“src”属性中提供了一个 m3u8 文件。在这种情况下，即使密钥是通过 https 传递的，我如何确保用户不会简单地在浏览器中输入 https URL 并将密钥保存到他的硬盘中？我理解机制的方式，密钥下载是由<video> 标签完成的，因为它使用浏览器的 https 堆栈播放 m3u8 源 - 浏览器内的合法客户端如何与仅在地址栏中输入的用户区分开来?这一定很明显，但我只是没有看到它......

一切顺利，

舞蹈

【问题讨论】：

很好的问题，特别是因为在大多数情况下，HTTPS 只是基于服务器信任的实现，而不是客户端信任。在万维网上，这是可以理解的有用的，因为用户数据被传递到服务器而不是相反。所以用户需要确保他们将数据发送到受信任的站点。然而，在视频的情况下，内容几乎被泄露，服务器更需要信任用户，反之亦然。但是，客户端身份验证是不可行的，因为要为成千上万的用户提供服务。最终，我只是在泡菜

标签： ios http safari http-live-streaming live-streaming

【解决方案1】：

Apple 实现的 HTTP 直播不支持 DRM。

请参阅https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/FrequentlyAskedQuestions/FrequentlyAskedQuestions.html 上的常见问题解答第 16 号

【讨论】：

该问题专门询问加密，FAQ #16 说：“可以加密媒体，并且可以通过在客户端从您的 HTTPS 服务器检索密钥时要求身份验证来限制密钥访问。”这个答案完全没有抓住重点。

【解决方案2】：

可以在这里找到一些有趣的指针：https://developer.apple.com/library/content/documentation/AudioVideo/Conceptual/AirPlayGuide/EncryptionandAuthentication/EncryptionandAuthentication.html

这需要在 iOS、Android 和网络播放器中进行自定义工作。

从受保护的 HTTPS 领域提供密钥。在开始播放之前，您的应用可以使用 NSURLConnection 进行身份验证，提供隐藏的凭据。
通过 HTTPS 使用 cookie。您的应用可以连接到 HTTPS 服务器并以应用定义的方式对应用进行身份验证。然后，您的服务器可以发出适用于关键 URL 的 cookie。您应该将 cookie 设置为在播放完成后很久才过期。然后，服务器必须要求在未来对密钥的 GET 请求中存在有效的会话 cookie。为了获得最大的可靠性，如果到期日期在不久的将来，服务器应在其对未来 GET 请求的响应中更新 cookie 的到期日期。
使用应用定义的 URL 方案指定 .m3u8 文件中的键。应用应该注册一个自定义的 NSURLProtocol 来处理对这些 URL 的请求。然后，播放器在需要加载关键 URL 时回调到您的应用程序；然后，您的应用可以使用安全侧通道获取密钥并将其提供给播放器。

如果您只针对 iOS，那么您应该使用处理密钥身份验证的 Apple Fairplay DRM。

【讨论】：

【解决方案3】：

最好的方法是使用Apple HLS支持的加密。HLS支持128位AES加密，客户端播放器需要解码流。

【讨论】：

【解决方案4】：

看这里 https://datatracker.ietf.org/doc/html/draft-pantos-http-live-streaming-13#section-6.3.6

播放列表必须为每个片段指定一个关键标签。因此玩家将能够识别解密片段所需的密钥。

浏览器不支持开箱即用的 DRM。 HTML5 指定可以通过未实现 atm 的 EME（加密媒体扩展）来完成。

所以你的选择是：

使用闪存并通过您自己的算法获取密钥
编写自己的插件（扩展）
像Netflix一样大并同意浏览器供应商支持您的 DRM aka 内容保护和密钥分布。

【讨论】：

【解决方案5】：

浏览器内的合法客户端与在地址栏中输入的用户有何区别？

有趣的区别，提示用户使用的浏览器在播放网页嵌入的视频时是合法的，而通过地址栏访问时是非法的。

但那里并没有真正的区别，我认为你没有遗漏任何东西。

您如何将权限授予浏览器而不是用户？用户不能只写自己的浏览器吗？

我知道，用户似乎不太可能编写浏览器，但无论如何，这些类型的讨论总是关于不太可能发生的情况。不太可能的用户可能会找到一种将 m3u8 视为纯文本的方法，他们可能会直接下载密钥，他们可能会使用这些密钥来解密并最终将视频片段拼凑在一起。

或者，更有可能 - 使用屏幕录制软件复制他们可以在浏览器中播放的任何视频。

在我看来，如果用户被授权播放视频，不幸的是，他们也可以复制视频 - 因为无法阻止视频的显示被重定向到不再加密的内容 - 至少在在浏览器中播放视频的台式计算机环境。

无论如何，我的理解是，您可以通过要求获得密钥的授权来保护密钥，但如果用户拥有该授权，那么 - 他们可以获得密钥。

【讨论】：

【解决方案6】：

答案一点也不明显。如果您希望它是安全的，那么您基本上需要发明自己的密钥传递。一种选择是为授权用户设置 cookie，并在密钥服务器中验证 cookie。这将使某人无法仅使用密钥 URL 绕过您的安全性。

请记住，仍然只需要一个合法客户端泄露密钥即可使您的安全失效。

【讨论】：

作为后续行动，Apple 为几款最新的 iOS 设备引入了安全密钥传递机制。他们称之为 FairPlay Streaming。您可以在 Apple 网站上阅读：developer.apple.com/streaming/fps

【解决方案7】：

我怎样才能确保用户不只是在他的浏览器并将密钥保存到他的硬盘？

您可以在应用中拥有 SSL 客户端密钥/证书，从而验证“应用”以播放内容。这样您就可以避免将您的内容泄露给您的应用以外的其他设备。

但这意味着您需要以某种方式将您的 ssl-key/passphrase 隐藏在应用程序中。不幸的是，让 iOS 上的视频播放器使用 ssl 密钥身份验证也存在问题......

【讨论】：