带有加密功能的HTTP实时流式传输

我想了解Apple在其iOS设备以及Safari上支持的HTTP实时流式传输协议如何保护解锁内容的密钥。带有加密功能的HTTP实时流式传输

我的理解是，.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源代码 - 浏览器中的合法客户端如何区分用户，只需将它输入地址栏？这一定是真的很明显，但我没有看到它......

一切顺利，

dansch

来源

2010-12-20 dansch

优秀的问题，尤其是因为在大多数情况下，HTTPS只是基于服务器信任的实现，而不是客户端信任。在广泛的Web上，这很有用，因为用户数据正在传递给服务器而不是其他方式。因此，用户需要确保他们将数据发送到受信任的站点。然而，在视频的情况下，内容几乎已经消失，服务器更需要信任用户，反之亦然。但是，由于需要服务数千个用户，因此客户端身份验证不可行。最后，我只是在一片泡菜 – 2012-03-13 21:09:05

苹果实现HTTP实时流不支持DRM。在http://developer.apple.com/library/ios/#documentation/networkinginternet/conceptual/streamingmediaguide/FrequentlyAskedQuestions/FrequentlyAskedQuestions.html

来源

2011-01-19 23:11:28 Ronan

这个问题特别提到加密问题，常见问题解答＃16说：“媒体可以加密，并且当客户端从HTTPS服务器获取密钥时要求认证，可以限制密钥访问。”这个答案完全忽略了这一点。 – 2014-03-19 04:20:07

那么加密段的要点是什么？ – 2015-08-20 08:18:44

参见常见问题解答16号我怎么能确保用户不只是在他浏览器中输入HTTPS URL并保存关键他的硬盘驱动器？

您可以在应用程序中拥有SSL客户端密钥/证书，从而验证用于播放内容的“应用程序”。那么你应该避免将你的内容泄漏到除你的应用之外的其他设备上。

但是，这意味着你需要以某种方式隐藏你的SSL密钥/密码短语内的应用程序。而且不幸的是，iOS上的视频播放器使用ssl密钥验证也存在问题...

来源

2012-03-29 16:26:23 janfrode

答案根本不明显。如果你希望安全，你基本上需要发明你自己的密钥交付。一种选择是为授权用户设置cookie，并验证密钥服务器中的cookie。这将使人们无法使用密钥url来绕过安全。

请记住，它仍然只需要一个合法的客户端泄漏您的安全失效的关键。

来源

2013-02-02 14:00:56 vipw

作为一项后续行动，Apple已经为几款最新的iOS设备推出了安全密钥传送机制。他们称之为FairPlay Streaming。你可以在Apple的网站上阅读它：https：//developer.apple.com/streaming/fps/ – vipw 2015-08-18 06:57:08

浏览器中的合法客户端如何区别于用户只需将其输入地址栏？

有趣的区别，该建议是玩的时候嵌入在网页中的视频，并非法在通过地址栏访问用户使用的浏览器是合法的。

但是没有实际的区别，我不认为你错过了任何东西。

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

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

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

在我看来，如果一个用户被授权播放视频，他们很可能也会复制视频 - 因为无法阻止将视频的显示重定向到不再加密的内容 - 至少在浏览器中播放视频的台式电脑的环境中。

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

来源

2014-02-15 06:56:50

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

看看播放列表必须指定每个段的重要标签。所以玩家将能够识别解密段所需的密钥。

浏览器不支持DRM开箱即用。 HTML5指定它可以通过EME（加密媒体扩展）完成，无论谁没有实现atm。

所以你的选择是：

使用闪光灯，并通过自己的算法取钥匙
编写自己的插件（扩展）
是大如Netflix和与浏览器同意厂商支持您的DRM aka内容保护和密钥分发。

来源

2016-05-26 21:22:25 Dorin

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

来源

2016-08-19 07:04:59

一些有趣的指针可以在这里找到：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。为了获得最大的可靠性，如果到期日期在不久的将来，服务器应该更新cookie的到期日期以响应未来的GET请求。
使用应用定义的URL方案指定.m3u8文件中的密钥。应用程序应该注册一个自定义的NSURLProtocol来处理这些URL的请求。玩家在需要加载关键字网址时会回到您的应用中;然后，您的应用可以使用安全的辅助通道获取密钥，并将其提供给玩家。

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

来源

2016-10-19 09:45:44 pcoucke

带有加密功能的HTTP实时流式传输

回答

相关问题