帶有加密功能的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實時流式傳輸

回答

相關問題