在上周落幕的LiveVideoStackCon音視頻技術(shù)大會,阿里云高級技術(shù)專家周源進(jìn)行了《視頻加密和DRM的實施實踐》專題分享。周源,有十多年音視頻研發(fā)經(jīng)驗,之前在淘寶視頻負(fù)責(zé)開放平臺,目前在阿里云視頻云部門負(fù)責(zé)媒體處理,在大規(guī)模系統(tǒng)建設(shè)和云計算方面都有非常豐富的實戰(zhàn)經(jīng)驗。本文為演講原文
在視頻加密這塊,其實是一個攻防戰(zhàn),攻防的手段非常多,還會不斷的翻新,有很多技術(shù)手段,技術(shù)的發(fā)展也是日新月異。視頻保護(hù)技術(shù)其實已經(jīng)升級了好幾代,我會給大家介紹下每一代技術(shù)是怎么做的、背后的原理、遇到的問題以及業(yè)界的解法。會從數(shù)據(jù)加密、全鏈路保護(hù)、數(shù)字版權(quán)管理、內(nèi)容識別四個方面來介紹。
數(shù)據(jù)加密原理——算法的選擇
最初,數(shù)據(jù)加密原理非常簡單,我們在生活中如果有一樣?xùn)|西你想保護(hù)它,你會怎么辦,你的第一反應(yīng)可能就是拿把鎖把他鎖起來,自己保護(hù)好鑰匙。在數(shù)字領(lǐng)域,這個“鎖”有好多種,一種叫對稱型的,一種叫非對稱型的。
這兩種算法分別有各自的優(yōu)缺點(diǎn),對稱型算法的優(yōu)點(diǎn)是計算量非常小,速度快,效率高。而它的缺點(diǎn)是密鑰的管理和分發(fā)非常困難,如果別人配了相同的一把鑰匙,就可以打開這把鎖了,不夠安全。常見的算法包括AES、EDS。非對稱型算法的優(yōu)缺點(diǎn)其實和對稱型是相對的,優(yōu)點(diǎn)是算法是公開的,你可以看到所有細(xì)節(jié),即使這樣,安全性也非常高。非對稱算法有兩種類型的鑰匙:公鑰和私鑰。公鑰可以開放給所有人,內(nèi)容只能通過私鑰加密,加密完成后,使用公鑰就可以解密,但是不能進(jìn)行加密。但是缺點(diǎn)是加密和解密花費(fèi)的時間長,速度慢,所以不適合對大量數(shù)據(jù)加密,只適合少量數(shù)據(jù)的加密。常見的算法包括RSA、ECC。
在視頻場景下,怎么去權(quán)衡對稱加密和非對稱加密?
媒體介質(zhì)經(jīng)歷了幾次升級,最早是文本,幾十KB就是非常大的一個小說了;到了圖片就發(fā)展到了幾百KB,甚至MB的級別;如今視頻時代,量級上到GB級別。所以視頻的第一個特點(diǎn)是數(shù)據(jù)量大,加密算法速度不行的話是不夠?qū)嵱没摹?/p>
視頻的應(yīng)用越來越廣泛,它不僅僅局限于某一個平臺。用戶會在各種操作系統(tǒng)、各種終端設(shè)備上去觀看視頻,在選擇算法的同時,一定要考慮平臺標(biāo)準(zhǔn)化這塊。
更進(jìn)一步的話,需要考慮移動端的功耗問題,大家做視頻都在能耗和發(fā)熱做斗爭,選擇算法的時候,一定要考慮功耗問題。
最終的選擇——AES算法
基于以上考慮,業(yè)界大家最終會選擇AES算法。它具有以下特點(diǎn):
1.安全性,AES算法從數(shù)學(xué)上證明是安全的。把加密好的文件給到你,你沒拿到鑰匙的情況下,暴力破解需要花2104億年的時間,這幾乎是一個不可能完成的任務(wù)?,F(xiàn)在也存在一種旁路攻擊的方法,攻擊的是實現(xiàn)方法,不是算法本身。攻擊成本比較高,在增加成本的前提下,實現(xiàn)上是有規(guī)避的方法。所以安全性還是有保障的。
2.這個算法衡量了時-空占比,速度快、消耗小,適合小型系統(tǒng)上工作。
3.算法也非常標(biāo)準(zhǔn)化,也在絕大部分的硬件芯片、軟件平臺中進(jìn)行內(nèi)置,可以用硬件本身的能力快速做計算。
一般情況下密鑰越長,安全性越高。但是密鑰短并不代表運(yùn)算速度一定會快。同時,因為均衡了時-空占比,AES算法的資源消耗也是最低的。所以,AES算法在對稱算法中是首選。
AES算法的經(jīng)典應(yīng)用——HLS數(shù)據(jù)加密
舉個例子,HLS協(xié)議使用M3U8文件格式。關(guān)鍵性的信息是下圖中橙色的一行,這里加了KEY的信息。它的原理是播放器從網(wǎng)上把m3u8下載下來,解析后得到KEY,并且傳遞給服務(wù)器詢問請求通過不通過,服務(wù)器如果認(rèn)證通過,會把真實的KEY返回給播放器進(jìn)行播放。
僅僅使用AES加密來包含內(nèi)容時,它的安全問題出在哪里呢?它的最關(guān)鍵的問題是——鑰匙URL。因為URL要被寫在文件里的,不管你做什么變化,無論加session、referer、token,它都是標(biāo)準(zhǔn)的HTTP請求,這是HLS加密的最大風(fēng)險點(diǎn)。
因為網(wǎng)絡(luò)請求是公開的,我們怎么保障網(wǎng)絡(luò)傳輸安全性?防御中間人攻擊?
而在客戶端拿到鑰匙后,實際上是明文內(nèi)容,客戶端的安全性又該如何保障?
如此我們便有了新解法——全鏈路保護(hù)
這里有兩個很重要的原則,第一個是中間網(wǎng)絡(luò)是不可信的,第二個是客戶端是不可信的。接下來看看這兩個問題如何解決。
關(guān)于中間網(wǎng)絡(luò)不可信,HTTPS是最經(jīng)典的方案。因為HTTPS整個流程保證了沒有任何人能竊取中間的信息,安全的從服務(wù)端傳遞到客戶端。
它整個流程是:黑色的部分是公開的,誰看到都不會影響安全性??蛻舳讼蚍?wù)端請求一次,服務(wù)端會返回公鑰,客戶端用公鑰去把自己的對稱鑰匙保護(hù)一次。接著把加密后的對稱鑰匙傳遞給服務(wù)端,服務(wù)端使用秘鑰解碼后得到對稱鑰匙。這時候客戶端和服務(wù)端雙方都知道對稱鑰匙了,然后用對稱鑰匙對數(shù)據(jù)加密進(jìn)行傳遞。這個方案即解決了安全性問題,又解決了效率問題。
關(guān)于客戶端不可信。通??蛻舳耸欠浅?fù)雜的,常見的是瀏覽器,標(biāo)準(zhǔn)也很多(如下圖)。但是在整個規(guī)劃中,很重要的一點(diǎn)是:“有定義,但沒有實現(xiàn)”。每個瀏覽器都支持H5的DRM方案,但是每個瀏覽器的支持方式都是不一樣的。
H5整個流程是,當(dāng)解碼器拿到加密數(shù)據(jù)之后,數(shù)據(jù)流會經(jīng)過CDM,這個模塊會和外部系統(tǒng)進(jìn)行通訊,去和License服務(wù)獲取內(nèi)容鑰匙和授權(quán)規(guī)則,經(jīng)過了這一步才能真正把流解密成明文數(shù)據(jù)去做渲染。所以,雖然有了H5的規(guī)范,但是實際上還是會被廠商綁定,客戶端安全性完全由廠商提供的CDM來決定。
移動端方面,分為Web端和APP。Web端瀏覽器是非常復(fù)雜的,各種定制的WebKit引擎不支持內(nèi)容解碼模塊(Content Decryption Module),只能采用JavaScript去寫代碼,它是明文代碼,安全性很差?,F(xiàn)在有一個新的技術(shù)WebAssembly,它是把JS編譯一下,增加了破解的難度,但是還是沒有從源頭解決這個問題。APP是沒有任何標(biāo)準(zhǔn)了,都靠自己去定制。
如此看來,我們想解決客戶端不可信這件事,其實還有很多障礙在里面。同時,客戶端不可信帶來了很多問題,你沒法知道你客戶端里是好人還是壞人,如果是惡意用戶,他的破壞力普通比較強(qiáng),會給平臺帶來很大的損失。
全鏈路的保護(hù)解決了網(wǎng)絡(luò)傳輸?shù)陌踩?,但是客戶端的安全問題沒有得到徹底完全的解決,所以在業(yè)界有了第三種解法:數(shù)字版權(quán)保護(hù)(DRM)。
更安全的加密方式——數(shù)字版權(quán)保護(hù)DRM
DRM基本是三足鼎立的情況,微軟的PlayReady,谷歌的Widevine,蘋果的FairPlay。不同操作系統(tǒng)、瀏覽器和移動平臺需要不同的方案,所以看起來我們沒辦法用一套方案把所有的加密都做完。
所以如何跨平臺把問題解決掉?——多重DRM解決方案
我們分別來看看三個廠商的方案:PlayReady方案中,當(dāng)你的設(shè)備和服務(wù)得到一個認(rèn)證后,才能接著發(fā)起License請求,分了兩個階段來提交。Widevine方案中,通過第一段來控制是否有權(quán)限復(fù)雜的鑰匙,再從License去拿真正的鑰匙。FairPlay方案中,播放器第一個流程是認(rèn)證,第二個流程是獲取License。
如此,我們有了多重DRM解決方案,它的流程是Player去問認(rèn)證服務(wù)允不允許訪問視頻,后臺經(jīng)過認(rèn)證后,會給一個認(rèn)證后的token。當(dāng)認(rèn)證允許訪問的時候,通過CDN分發(fā)網(wǎng)絡(luò)從源站獲取內(nèi)容,當(dāng)拿到內(nèi)容后,有了token和視頻KEY ID,就會把License返回,這里才有真正能解密內(nèi)容的鑰匙。
多重DRM可以降低加密成本,對于不同平臺,把整個流程做一致化,只需要一份加密資產(chǎn),降低了加密流程成本和管理成本。同時,因為原生 DRM 客戶端在其原生平臺上通常是免費(fèi)提供的,也可以消除客戶端的許可成本。
從技術(shù)角度上,整個業(yè)界有通用加密格式的規(guī)范,可以很好的把加密內(nèi)容安全地傳輸?shù)娇蛻舳?。但是有一個現(xiàn)實情況,F(xiàn)airPlay的加密算法是不同的,為了實現(xiàn)多重DRM方案,我們需要兩份加密資產(chǎn),才能真正做到跨平臺的保護(hù)。
那么DRM是否是最終的加密方案呢?從安全性上來講,DRM用了非對稱算法,但是依然會面臨主密鑰泄露這個問題,網(wǎng)上也出現(xiàn)HDCP主秘鑰泄露、4K視頻版權(quán)保護(hù)技術(shù)被破解等案例。
我們用鑰匙去保護(hù)視頻、在全鏈路保護(hù)上做了很多改進(jìn),并且采用了更安全的多重DRM方案,我們試圖用各種方法把內(nèi)容保護(hù)起來,這些思路都叫被動保護(hù)。被動包含的每種方法都有自己的缺陷,所以我們給出一種新的思路,叫內(nèi)容識別。
主動保護(hù)——內(nèi)容識別
目前,版權(quán)保護(hù)遇到的問題是“內(nèi)容所有權(quán)”跟“版權(quán)”的關(guān)系越來越復(fù)雜,這使我想起凱文.凱利在《必然》中曾提出:“對已有事物的重新排列和再利用,而對傳統(tǒng)的財產(chǎn)觀念和所有權(quán)概念產(chǎn)生巨大的影響?!?/p>
這里面就延伸出來很多問題,用戶是否對原有素材做了一定的轉(zhuǎn)化,還是僅僅復(fù)制了原作?我們應(yīng)該是嚴(yán)格禁止還是開放包容的態(tài)度?在這個全民導(dǎo)演的時代,我們可以看到很多用戶把自己錄制或者網(wǎng)上收集的素材重混起來,就成為了很成功的新作品。當(dāng)然,版權(quán)方也有真實的案例,即使得內(nèi)容得到了很好的二次傳播,還驚喜地獲得額外的收益。面對這樣的情況,我們該如何進(jìn)行高效地內(nèi)容識別和保護(hù)?
視頻指紋——給視頻賦予唯一身份
阿里云視頻云團(tuán)隊自研了視頻指紋技術(shù),它是一種識別、提取、壓縮視頻的技術(shù),可以產(chǎn)生唯一的“指紋”來代表視頻文件進(jìn)行視頻查找。你可以通過算法得到指紋信息,用這個指紋信息和版權(quán)庫中的視頻進(jìn)行檢索匹配,就可以很迅速地找到相似的視頻源。它不僅判斷唯一性,還可以找到究竟使用了視頻源的哪一段。
視頻指紋技術(shù)可以解決如下的場景的問題:
1. 版權(quán)保護(hù)
新增視頻與版權(quán)庫做比對,對存在版權(quán)風(fēng)險的視頻進(jìn)行播放控制,降低侵權(quán)風(fēng)險;對自有版權(quán)的視頻資源,從公網(wǎng)抓取視頻數(shù)據(jù)鑒別,防止自有版權(quán)內(nèi)容被侵權(quán)。
2. 原創(chuàng)識別
能識別這段視頻是從哪個片子剪輯出來的,識別視頻是否是原創(chuàng)視頻、剪輯后視頻、自媒體再創(chuàng)造視頻。
3. 廣告分成
傳播不要緊,當(dāng)能做到視頻回溯的時候,就可以判斷新上傳的視頻原創(chuàng)性,檢索分成庫召回認(rèn)領(lǐng)視頻,找到真正的視頻版權(quán)主,從而支撐廣告分成業(yè)務(wù)生態(tài)。
回顧
整體視頻保護(hù)技術(shù)歷經(jīng)了幾次升級,最后,我們進(jìn)行一個回顧和總結(jié)。
數(shù)據(jù)加密
它是有安全基礎(chǔ),有算法保障的,但是沒有解決問題
全鏈路保護(hù)
整體的保護(hù)方案,但是無法落地,沒辦法大規(guī)模使用
數(shù)字版權(quán)管理(DRM)
更完善、更安全的保護(hù)方案,但是依舊存在風(fēng)險
內(nèi)容識別
改變思路,變被動為主動,開拓更廣闊的空間
-
視頻
+關(guān)注
關(guān)注
6文章
1942瀏覽量
72884 -
云計算
+關(guān)注
關(guān)注
39文章
7774瀏覽量
137351 -
數(shù)據(jù)加密
+關(guān)注
關(guān)注
0文章
51瀏覽量
12713
原文標(biāo)題:周源:視頻加密和DRM實施實踐
文章出處:【微信號:livevideostack,微信公眾號:LiveVideoStack】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
評論