HTTP实时streamencryption
我正试图了解Apple在其iOS设备以及Safari上支持的HTTP Live Streaming协议如何保护解锁内容的密钥。
我的理解是，.m3u8文件将整个东西放在一起，并引用内容（在MPEG2 TS容器中，AES 128encryption）和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传送密钥，我如何确保用户不会在浏览器中inputhttps URL并将密钥保存到他的硬盘中？ 我理解这种机制的方式是，使用浏览器的https堆栈播放m3u8源文件时，关键的下载是通过<video>标记完成的 – 浏览器内的合法客户端如何区别于用户，只需在地址栏中input？ 这一定是显而易见的，但我只是没有看到它…
祝一切顺利，
dansch
我怎样才能确保用户不在他的浏览器中inputhttps URL并将密钥保存到他的硬盘？
您可以在应用程序中拥有SSL客户端密钥/证书，从而validation用于播放内容的“应用程序”。 那么你就不要把你的内容泄漏到你的应用以外的其他设备上。
但是这意味着你需要以某种方式隐藏你的SSL密钥/密码短语内的应用程序。 而不幸的是也有问题让iOS上的video播放器使用SSL密钥validation…
苹果公司实施的HTTP直播不支持DRM。
答案根本不明显。 如果您希望安全，您基本上需要发明自己的密钥交付。 一种select是为授权用户设置一个cookie，并validation密钥服务器中的cookie。 这将使人们无法使用关键的url来绕过你的安全。
请记住，它仍然只需要一个合法的客户端泄漏您的安全的关键是无效的。
最好的方法是使用Apple HLS支持的encryption.HLS支持128位AESencryption，客户端播放器需要对stream进行解码。
一些有趣的指针可以在这里find： https : //developer.apple.com/library/content/documentation/AudioVideo/Conceptual/AirPlayGuide/EncryptionandAuthentication/EncryptionandAuthentication.html
这将需要在iOS中进行自定义工作，而且还需要在Android和networking播放器中进行。
- 从受保护的HTTPS领域提供密钥 。 在播放开始之前，您的应用程序可以使用NSURLConnection进行身份validation，提供隐藏的凭据。
- 通过HTTPS使用Cookie 。 您的应用可以连接到HTTPS服务器，并以应用定义的方式validation应用。 您的服务器然后可以发出适用于关键URL的Cookie。 播放完成后，您应该将Cookie设置为过期很长时间。 然后，服务器必须在以后的密钥GET请求中要求存在有效的会话cookie。 为了获得最大的可靠性，如果到期date在不久的将来，服务器应该在未来的GET请求中更新cookie的到期date。
- 使用应用程序定义的URLscheme指定.m3u8文件中的密钥 。 应用程序应该注册一个自定义NSURLProtocol来处理这些URL的请求。 玩家在需要加载关键字url时，会回到您的应用程序; 然后您的应用程序可以使用安全的辅助通道获取密钥，并可以将其提供给玩家。
如果您只针对iOS，那么您应该使用处理密钥validation的Apple Fairplay DRM。
浏览器内部的合法客户端如何区别于用户只需在地址栏中input？
有趣的区别是，build议用户使用的浏览器在播放网页中embedded的video时是合法的，在通过地址栏访问时是不合法的。
但是那里没有实际的区别，我不认为你错过了什么。
你如何给浏览器而不是用户权利？ 用户不能只写自己的浏览器吗？
我知道，用户似乎不太可能编写浏览器，但是这些types的讨论始终是不太可能发生的。 一个不太可能的用户可能会find一种方法来将m3u8视为纯文本，他们可能会直接下载密钥，他们可能会使用这些密钥来解密和最终拼接video片段。
或者，更有可能的是 – 使用屏幕录制软件来复制他们可以在浏览器中播放的video。
在我看来，如果一个用户被授权播放video，他们可以，不幸的是也复制video – 因为没有办法阻止video显示redirect到不再encryption的东西 – 至less在在浏览器中播放video的桌面电脑。
无论如何，我的理解是，你可以通过授权获得密钥来保护密钥，但是如果用户拥有授权，那么 – 他们可以获得密钥。
看看这里https://tools.ietf.org/html/draft-pantos-http-live-streaming-13#section-6.3.6
播放列表将不得不为每个分段指定一个键标记。 所以玩家将能够识别解密段所需的密钥。
浏览器不支持开箱即用的DRM。 HTML5指定可以通过EME（encryption媒体扩展）来完成，而不使用atm。
所以你的select是：
- 使用闪光灯并通过您自己的algorithm获取密钥
- 编写自己的插件（扩展名）
- 像Netflix一样大，并同意浏览器供应商支持您的DRM aka内容保护和密钥分发。