周源:視訊加密和DRM實施實踐
在上週落幕的LiveVideoStackCon音視訊技術大會,阿里雲高階技術專家周源進行了《視訊加密和DRM的實施實踐》專題分享。周源,有十多年音視訊研發經驗,之前在淘寶視訊負責開放平臺,目前在阿里雲視訊雲部門負責媒體處理,在大規模系統建設和雲端計算方面都有非常豐富的實戰經驗。本文為演講原文,由雲棲社群整理,並授權LiveVideoStack轉發。
文 / 周源
整理 / 雲棲社群
在視訊加密這塊,其實是一個攻防戰,攻防的手段非常多,還會不斷的翻新,有很多技術手段,技術的發展也是日新月異。視訊保護技術其實已經升級了好幾代,我會給大家介紹下每一代技術是怎麼做的、背後的原理、遇到的問題以及業界的解法。會從資料加密、全鏈路保護、數字版權管理、內容識別四個方面來介紹。
資料加密原理——演算法的選擇
最初,資料加密原理非常簡單,我們在生活中如果有一樣東西你想保護它,你會怎麼辦,你的第一反應可能就是拿把鎖把他鎖起來,自己保護好鑰匙。在數字領域,這個“鎖”有好多種,一種叫對稱型的,一種叫非對稱型的。
這兩種演算法分別有各自的優缺點,對稱型演算法的優點是計算量非常小,速度快,效率高。而它的缺點是金鑰的管理和分發非常困難,如果別人配了相同的一把鑰匙,就可以開啟這把鎖了,不夠安全。常見的演算法包括AES、EDS。非對稱型演算法的優缺點其實和對稱型是相對的,優點是演算法是公開的,你可以看到所有細節,即使這樣,安全性也非常高。非對稱演算法有兩種型別的鑰匙:公鑰和私鑰。公鑰可以開放給所有人,內容只能通過私鑰加密,加密完成後,使用公鑰就可以解密,但是不能進行加密。但是缺點是加密和解密花費的時間長,速度慢,所以不適合對大量資料加密,只適合少量資料的加密。常見的演算法包括RSA、ECC。
在視訊場景下,怎麼去權衡對稱加密和非對稱加密?
媒體介質經歷了幾次升級,最早是文字,幾十KB就是非常大的一個小說了;到了圖片就發展到了幾百KB,甚至MB的級別;如今視訊時代,量級上到GB級別。所以視訊的第一個特點是資料量大,加密演算法速度不行的話是不夠實用化的。
視訊的應用越來越廣泛,它不僅僅侷限於某一個平臺。使用者會在各種作業系統、各種終端裝置上去觀看視訊,在選擇演算法的同時,一定要考慮平臺標準化這塊。
更進一步的話,需要考慮移動端的功耗問題,大家做視訊都在能耗和發熱做鬥爭,選擇演算法的時候,一定要考慮功耗問題。
最終的選擇——AES演算法
基於以上考慮,業界大家最終會選擇AES演算法。它具有以下特點:
1. 安全性,AES演算法從數學上證明是安全的。把加密好的檔案給到你,你沒拿到鑰匙的情況下,暴力破解需要花2104億年的時間,這幾乎是一個不可能完成的任務。現在也存在一種旁路攻擊的方法,攻擊的是實現方法,不是演算法本身。攻擊成本比較高,在增加成本的前提下,實現上是有規避的方法。所以安全性還是有保障的。
2. 這個演算法衡量了時-空佔比,速度快、消耗小,適合小型系統上工作。
3. 演算法也非常標準化,也在絕大部分的硬體晶片、軟體平臺中進行內建,可以用硬體本身的能力快速做計算。
一般情況下金鑰越長,安全性越高。但是金鑰短並不代表運算速度一定會快。同時,因為均衡了時-空佔比,AES演算法的資源消耗也是最低的。所以,AES演算法在對稱演算法中是首選。
AES演算法的經典應用——HLS資料加密
舉個例子,HLS協議使用M3U8檔案格式。關鍵性的資訊是下圖中橙色的一行,這裡加了KEY的資訊。它的原理是播放器從網上把m3u8下載下來,解析後得到KEY,並且傳遞給伺服器詢問請求通過不通過,伺服器如果認證通過,會把真實的KEY返回給播放器進行播放。
僅僅使用AES加密來包含內容時,它的安全問題出在哪裡呢?它的最關鍵的問題是——鑰匙URL。因為URL要被寫在檔案裡的,不管你做什麼變化,無論加session、referer、token,它都是標準的HTTP請求,這是HLS加密的最大風險點。
因為網路請求是公開的,我們怎麼保障網路傳輸安全性?防禦中間人攻擊?
而在客戶端拿到鑰匙後,實際上是明文內容,客戶端的安全性又該如何保障?
如此我們便有了新解法——全鏈路保護
這裡有兩個很重要的原則,第一個是中間網路是不可信的,第二個是客戶端是不可信的。接下來看看這兩個問題如何解決。
關於中間網路不可信,HTTPS是最經典的方案。因為HTTPS整個流程保證了沒有任何人能竊取中間的資訊,安全的從服務端傳遞到客戶端。
它整個流程是:黑色的部分是公開的,誰看到都不會影響安全性。客戶端向服務端請求一次,服務端會返回公鑰,客戶端用公鑰去把自己的對稱鑰匙保護一次。接著把加密後的對稱鑰匙傳遞給服務端,服務端使用祕鑰解碼後得到對稱鑰匙。這時候客戶端和服務端雙方都知道對稱鑰匙了,然後用對稱鑰匙對資料加密進行傳遞。這個方案即解決了安全性問題,又解決了效率問題。
關於客戶端不可信。通常客戶端是非常複雜的,常見的是瀏覽器,標準也很多(如下圖)。但是在整個規劃中,很重要的一點是:“有定義,但沒有實現”。每個瀏覽器都支援H5的DRM方案,但是每個瀏覽器的支援方式都是不一樣的。
H5整個流程是,當解碼器拿到加密資料之後,資料流會經過CDM,這個模組會和外部系統進行通訊,去和License服務獲取內容鑰匙和授權規則,經過了這一步才能真正把流解密成明文資料去做渲染。所以,雖然有了H5的規範,但是實際上還是會被廠商繫結,客戶端安全性完全由廠商提供的CDM來決定。
移動端方面,分為Web端和APP。Web端瀏覽器是非常複雜的,各種定製的WebKit引擎不支援內容解碼模組(Content Decryption Module),只能採用JavaScript去寫程式碼,它是明文程式碼,安全性很差。現在有一個新的技術WebAssembly,它是把JS編譯一下,增加了破解的難度,但是還是沒有從源頭解決這個問題。APP是沒有任何標準了,都靠自己去定製。
如此看來,我們想解決客戶端不可信這件事,其實還有很多障礙在裡面。同時,客戶端不可信帶來了很多問題,你沒法知道你客戶端裡是好人還是壞人,如果是惡意使用者,他的破壞力普通比較強,會給平臺帶來很大的損失。
全鏈路的保護解決了網路傳輸的安全,但是客戶端的安全問題沒有得到徹底完全的解決,所以在業界有了第三種解法:數字版權保護(DRM)。
更安全的加密方式——數字版權保護DRM
DRM基本是三足鼎立的情況,微軟的PlayReady,谷歌的Widevine,蘋果的FairPlay。不同作業系統、瀏覽器和移動平臺需要不同的方案,所以看起來我們沒辦法用一套方案把所有的加密都做完。
所以如何跨平臺把問題解決掉?——多重DRM解決方案
我們分別來看看三個廠商的方案:PlayReady方案中,當你的裝置和服務得到一個認證後,才能接著發起License請求,分了兩個階段來提交。Widevine方案中,通過第一段來控制是否有許可權複雜的鑰匙,再從License去拿真正的鑰匙。FairPlay方案中,播放器第一個流程是認證,第二個流程是獲取License。
如此,我們有了多重DRM解決方案,它的流程是Player去問認證服務允不允許訪問視訊,後臺經過認證後,會給一個認證後的token。當認證允許訪問的時候,通過CDN分發網路從源站獲取內容,當拿到內容後,有了token和視訊KEY ID,就會把License返回,這裡才有真正能解密內容的鑰匙。
多重DRM可以降低加密成本,對於不同平臺,把整個流程做一致化,只需要一份加密資產,降低了加密流程成本和管理成本。同時,因為原生 DRM 客戶端在其原生平臺上通常是免費提供的,也可以消除客戶端的許可成本。
從技術角度上,整個業界有通用加密格式的規範,可以很好的把加密內容安全地傳輸到客戶端。但是有一個現實情況,FairPlay的加密演算法是不同的,為了實現多重DRM方案,我們需要兩份加密資產,才能真正做到跨平臺的保護。
那麼DRM是否是最終的加密方案呢?從安全性上來講,DRM用了非對稱演算法,但是依然會面臨主金鑰洩露這個問題,網上也出現HDCP主祕鑰洩露、4K視訊版權保護技術被破解等案例。
我們用鑰匙去保護視訊、在全鏈路保護上做了很多改進,並且採用了更安全的多重DRM方案,我們試圖用各種方法把內容保護起來,這些思路都叫被動保護。被動包含的每種方法都有自己的缺陷,所以我們給出一種新的思路,叫內容識別。
主動保護——內容識別
目前,版權保護遇到的問題是“內容所有權”跟“版權”的關係越來越複雜,這使我想起凱文.凱利在《必然》中曾提出:“對已有事物的重新排列和再利用,而對傳統的財產觀念和所有權概念產生巨大的影響。”
這裡面就延伸出來很多問題,使用者是否對原有素材做了一定的轉化,還是僅僅複製了原作?我們應該是嚴格禁止還是開放包容的態度?在這個全民導演的時代,我們可以看到很多使用者把自己錄製或者網上收集的素材重混起來,就成為了很成功的新作品。當然,版權方也有真實的案例,即使得內容得到了很好的二次傳播,還驚喜地獲得額外的收益。面對這樣的情況,我們該如何進行高效地內容識別和保護?
視訊指紋——給視訊賦予唯一身份
阿里雲視訊雲團隊自研了視訊指紋技術,它是一種識別、提取、壓縮視訊的技術,可以產生唯一的“指紋”來代表視訊檔案進行視訊查詢。你可以通過演算法得到指紋資訊,用這個指紋資訊和版權庫中的視訊進行檢索匹配,就可以很迅速地找到相似的視訊源。它不僅判斷唯一性,還可以找到究竟使用了視訊源的哪一段。
視訊指紋技術可以解決如下的場景的問題:
1. 版權保護
新增視訊與版權庫做比對,對存在版權風險的視訊進行播放控制,降低侵權風險;對自有版權的視訊資源,從公網抓取視訊資料鑑別,防止自有版權內容被侵權。
2. 原創識別
能識別這段視訊是從哪個片子剪輯出來的,識別視訊是否是原創視訊、剪輯後視訊、自媒體再創造視訊。
3. 廣告分成
傳播不要緊,當能做到視訊回溯的時候,就可以判斷新上傳的視訊原創性,檢索分成庫召回認領視訊,找到真正的視訊版權主,從而支撐廣告分成業務生態。
回顧
整體視訊保護技術歷經了幾次升級,最後,我們進行一個回顧和總結。
資料加密
它是有安全基礎,有演算法保障的,但是沒有解決問題
全鏈路保護
整體的保護方案,但是無法落地,沒辦法大規模使用
數字版權管理(DRM)
更完善、更安全的保護方案,但是依舊存在風險
內容識別
改變思路,變被動為主動,開拓更廣闊的空間
相關文章
- 最佳實踐丨企業上雲後資源容量如何規劃和實施
- 如何實現視訊加密全平臺播放加密
- RabbitMQ實戰:訊息通訊模式和最佳實踐MQ模式
- 海海DRM視訊保護解密流程分析解密
- 視訊通訊關鍵技術探索及實踐
- 短視訊 SDK 架構設計實踐架構
- 愛奇藝短視訊智慧標籤生成實踐
- 視訊:豆瓣資料架構實踐DX架構
- 短視訊影象處理 OpenGL ES 實踐
- 視訊直播和實時音視訊區別調研
- 阿里雲周源:一篇文章讀懂四代視訊加密技術演進阿里加密
- 【騰訊課堂】視訊點播上雲實踐
- 網易戲精ARCore短視訊新玩法實踐
- Cocos2d-x 資源加密解密實踐總結加密解密
- 代理重加密原理與實踐加密
- 網頁端實時音視訊服務架構與實踐網頁架構
- 自動化專案基類實踐--視訊演示
- 圓形視訊和圓角視訊的一種實現方式
- 印度央行加密貨幣交易禁令實施日期已到加密
- 帶你用AVPlayer實現音訊和視訊播放音訊
- CC視訊CTO慄偉:CDN系統架構及CC視訊應用實踐架構
- CMDB實踐指南:專案規劃與實施策略解析
- AR實踐:基於ARKit實現電影中的全息視訊會議
- 圖片視訊瀑布流長列表效能優化實踐優化
- 開發者實踐丨Agora Home AI 音視訊的未來GoAI
- 視訊影像色彩增強的主要方法與落地實踐
- 機器學習業務實踐之路-李博-專題視訊課程機器學習
- 複雜資料操作最佳實踐 | 公開課視訊
- Docker通訊全視角:原理、實踐與技術洞察Docker
- Android 列表視訊的全屏、自動小視窗優化實踐Android優化
- Fairplay DRM與混淆實現AI
- 融合技術設施的實踐應用
- Oracle RAC DRM介紹和關閉DRMOracle
- Service Mesh實踐指南-周晶-極客時間
- 實施零信任網路訪問的五個最佳實踐
- js實現視訊截圖,視訊批量截圖,canvas實現JSCanvas
- Android視訊開發進階(part5-安卓的DRM,視訊版權保護)Android安卓
- ERP“失落” 資訊化實施的資料來源和流(轉)