HTTP 直播加密
我试图了解 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
假设基于浏览器的播放，其中 元素被提供给“src”属性中的 m3u8 文件。在这种情况下，即使密钥是通过 https 传递的，我如何确保用户不会简单地在浏览器中输入 https URL 并将密钥保存到硬盘上？根据我理解该机制的方式，密钥下载是通过 标签完成的，因为它使用浏览器的 https 堆栈播放 m3u8 源代码 - 如何区分浏览器内的合法客户端与用户只需在地址栏中输入它？这一定是非常明显的，但我只是看不到它......
祝一切顺利，
dansch
I am trying to understand how the HTTP Live Streaming protocol that Apple supports on their iOS devices as well as on Safari protects the key that unlocks the content.
The way I understand it, the .m3u8 file holds the whole thing together and references the content (in MPEG2 TS container, AES 128 encrypted) and the key to the TS file.
Like in this example:
#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
Assuming a browser based playback where the <video> element is fed a m3u8 file in the "src" attribute. In this case, even if the key is delivered via https, how can I make sure that the user does not simply enter the https URL in his browser and saves the key to his hard drive? The way I understand the mechanism, the key download is done by the <video> tag as it plays the m3u8 source using the browser's https stack -- how is the legitimate client inside the browser distinguished from the user just typing it into the address bar? This must be really obvious, but I just don't see it...
All the best,
dansch
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
您可以在应用程序中拥有 SSL 客户端密钥/证书，从而验证“应用程序”播放内容的身份。这样您就可以避免将内容泄露到应用程序以外的其他设备。
但这意味着您需要以某种方式将您的 ssl 密钥/密码隐藏在应用程序内。不幸的是，让 iOS 上的视频播放器使用 ssl 密钥身份验证也存在问题......
You can have an SSL client key/certificate in the app, and thereby authenticate "the app" for playing the content. Then you'd avoid leaking your content to other devices than your app.
But that would mean you'd need to somehow hide your ssl-key/passphrase inside the app. And there are unfortunately also problems getting the video player on iOS to use the ssl key authentication...
可以在这里找到一些有趣的指针： https:/ /developer.apple.com/library/content/documentation/AudioVideo/Conceptual/AirPlayGuide/EncryptionandAuthentication/EncryptionandAuthentication.html
这将需要在 iOS 中进行自定义工作，但也需要在 Android 和网络播放器中进行自定义工作。
为了获得最大的可靠性，如果过期日期在不久的将来，服务器应该在响应未来的 GET 请求时更新 cookie 的过期日期。
如果您仅针对 iOS，那么您应该使用 Apple Fairplay DRM，它可以处理密钥的身份验证。
Some interesting pointers can be found here: https://developer.apple.com/library/content/documentation/AudioVideo/Conceptual/AirPlayGuide/EncryptionandAuthentication/EncryptionandAuthentication.html
This will require custom work in iOS, but also in Android and web players.
For maximum reliability, if the expiration date is in the near future, the server should update the cookie’s expiration date in its response to future GET requests.
If you're only targeting iOS, then you should use Apple Fairplay DRM which handles the authentication of the keys.
答案根本不明显。如果您希望它是安全的，您基本上需要发明自己的密钥传递。一种选择是为授权用户设置 cookie，并在密钥服务器中验证该 cookie。这将阻止某人仅使用密钥 URL 来绕过您的安全措施。
请记住，仍然只需要一个合法客户端泄露密钥即可使您的安全性失效。
The answer is not obvious at all. You're essentially required to invent your own key delivery if you want it to be secure. One option is to set a cookie for authorized users, and to verify the cookie in the key server. This will keep someone from being able to just use the key url to bypass your security.
Keep in mind that it still only takes one legitimate client to leak the key for your security to be invalidated.
最好的方法是使用Apple HLS支持的加密。HLS支持128位AES加密，客户端播放器需要解码流。
The best way is to use Apple HLS supported encryption.HLS support 128 bit AES encryption and the client player need to decode the stream.
有趣的区别，建议用户在播放网页中嵌入的视频时使用的浏览器是合法的，并且通过地址栏访问时是非法的。
但那里没有实际的区别，我不认为你错过了任何东西。
您如何将权限授予浏览器而不是用户？用户不能编写自己的浏览器吗？
我知道，用户似乎不太可能编写浏览器，但无论如何，这些类型的讨论总是关于不太可能发生的情况。不太可能的用户可能会找到一种以纯文本形式查看 m3u8 的方法，他们可能会直接下载密钥，他们可能会使用这些密钥来解密并最终将视频片段拼凑在一起。
或者，更有可能的事情是使用屏幕录制软件复制可以在浏览器中播放的任何视频。
在我看来，如果用户被授权播放视频，不幸的是他们也可以复制视频 - 因为没有办法阻止视频的显示被重定向到不再加密的内容 - 至少在以下环境中在浏览器中播放视频的台式计算机。
无论如何，我的理解是，您可以通过要求授权来获取密钥来保护密钥，但如果用户拥有该授权，那么 - 他们就可以获取密钥。
Interesting distinction, the suggestion is the browser the user is using is legitimate when playing the video embedded in the web page, and illegitimate when accessed via the address bar.
But there is no actual distinction there, I don't think you are missing anything.
How would you give rights to a browser and not a user? Cannot a user just write their own browser?
I know, it seems unlikely a user would write a browser, but these types of discussions are always about unlikely scenarios anyway. An unlikely user might find a way to view the m3u8 as plain text, they might download the keys directly, they may use those keys to unencrypt and eventual piece together the video segments.
Or, something that is far more likely - use screen recording software to copy any video that they can play in the browser.
In my opinion, if a user is authorized to play the video, they can, unfortunately also copy the video - because there's no way to prevent the display of the video being redirected into something that is no longer encrypted - at least in the environment of a desktop computer that is playing a video in a browser.
Anyway, my understanding is that you can protect the keys by requiring authorization to get the keys, but if the user has that authorization, then - well they can get the keys.
看看这里
https://datatracker. ietf.org/doc/html/draft-pantos-http-live-streaming-13#section-6.3.6
播放列表必须为每个片段指定一个关键标签。因此玩家将能够识别解密片段所需的密钥。
浏览器不支持开箱即用的 DRM。 HTML5 规定，无论谁没有实现 atm，都可以通过 EME（加密媒体扩展）来完成。
所以你的选择是：
供应商支持您的 DRM 又名内容保护和密钥
分配。
Have a look here
https://datatracker.ietf.org/doc/html/draft-pantos-http-live-streaming-13#section-6.3.6
the playlist will have to specify a key tag for each segment. so a player will be able to identify a key required to decrypt a segment.
Browsers do not support DRM out of the box. HTML5 specify that it can be done via EME (Encrypted media extensions) whoever not implemented atm.
so your options are:
vendors to support your DRM aka content protection and key
distribution.
Apple 的 HTTP 实时流媒体实现不支持 DRM。
请参阅 https://developer 上的常见问题解答 16 .apple.com/library/archive/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/FrequentlyAskedQuestions/FrequentlyAskedQuestions.html
Apple's implementation of HTTP live streaming does not support DRM.
See FAQ number 16 on https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/FrequentlyAskedQuestions/FrequentlyAskedQuestions.html