在短視訊開發中，移動端音視訊加密、防盜播實作方案

為了增加平台及使用者的盈利方式，有些短視訊源碼在開發設定了短視訊檢視的付費功能，要想保證該功能的正常使用，就需要對移動端的音視訊進行加密、防盜播處理，今天我們就一起來看看在短視訊開發中，移動端音視訊加密、防盜播實作方案吧。

注意：保證使用者體驗是前提。否則再好短視訊源碼，使用者體驗垃圾，也無法發展。

如今市面上，移動端加密、防盜播的方式很多。這裡隻是讨論一種：​<code>​我認為的使用者體驗較好，技術實作成熟，又有效防盜播的方式​</code>​。

注意：防止盜播，并不能100%杜絕盜播。隻能不斷增加短視訊源碼的破解成本，完全無法破解的短視訊源碼是不存在的。是以，想100%防止盜播也是不可能實作的。

這裡采用的方案是：​<code>​用戶端播放AES-128加密的m3u8媒體資源​</code>​

為什麼是m3u8 ？

m3u8采用AES-128對稱加密算法加密，技術成熟穩定

前邊說了，保證短視訊源碼使用者體驗為前提

短視訊源碼音視訊播放過程中，使用者進入播放頁後，音視訊的​<code>​秒開率​</code>​（1秒内成功加載的播放數/播放總數）是影響使用者體驗的重要名額；m3u8媒體資源是一個文本檔案，其由一個個ts視訊片段的播放位址構成，選擇合适的ts切片大小，能有效提高音視訊的秒開率，保證使用者的觀看體驗。

使用者體驗的大前提滿足了，那如何實作呢？

用戶端播放的視訊源為 ​<code>​AES-128對稱加密的 m3u8​</code>​ 媒體資源；

播放位址最終組織形式如下：

播放位址 ​<code>​https://domain/course101.m3u8​</code>​ 與​<code>​playKey​</code>​ 需從服務端擷取；

​<code>​加密m3u8的解密關鍵就在于playKey​</code>​，是以，​<code>​防止playKey被破解是防盜播的一個關鍵點​</code>​

将最終播放位址交于播放器播放

對于m3u8媒體資源，無論是 ​<code>​視訊切片加密​</code>​、​<code>​ts視訊片段解密播放​</code>​ 在技術實作上已經非常成熟，不存在技術壁壘，實作已經不是問題。

那麼擺在移動端最主要的問題就是：防止短視訊源碼媒體資源被盜播，維護内容生産者的利益

注：雖然技術實作已經不是問題，但這裡還是會把 ​<code>​移動端技術實作的細節​</code>​和 ​<code>​防破解（防盜播）​</code>​的實作細節進行呈現。

技術實作上，大概分為以下幾個步驟：

擷取短視訊源碼媒體資源播放位址

擷取媒體資源的解密token (playKey)

拼接最終播放位址，播放m3u8媒體資源

下面我們從短視訊源碼移動端請求音視訊内容清單，到成功播放的全過程來舉一個例子：

首先通過音視訊ID 101向服務端發起請求，擷取該音視訊的内容清單。請求方式和傳回結果如下：

為了簡單易懂，這裡簡單模拟一個get請求：

請求參數 ​<code>​courseId​</code>​ 為 ​<code>​101​</code>​；

請求位址為 ​<code>​https://domain/xxx/getCourseList.do​</code>​；

擷取id為101的音視訊，其對應的内容清單。

音視訊101的音視訊内容清單如下：

正如注釋中寫的：

​<code>​mediaId​</code>​ 是​<code>​媒體資源id​</code>​ ；

​<code>​mediaUrl​</code>​是​<code>​媒體資源的m3u8播放位址​</code>​；

可能會疑問： n3GuNo5Rc44anmLGrRU8Rne/JU9cHzc1vXZWiYEwcD0= 是什麼鬼，為什麼不像播放位址？

這裡正是​<code>​防止媒體資源被盜播，維護内容生産者的利益的 第二步​</code>​

這裡将資源位址​<code>​https://domain/course101.m3u8​</code>​進行了一個簡單的AES加密

對于其資源位址的加解密，會在下文進行詳細說明。

​<code>​encryptId​</code>​ 則是 ​<code>​用于擷取媒體資源的解密playKey​</code>​。

encryptId的具體作用，會在下文中詳細說明

注：這裡伺服器要做一個使用者權限的校驗：未購買使用者不傳回其 mediaUrl 和 encryptId

未購買使用者不傳回其 mediaUrl 和 encryptId

正是預防短視訊源碼移動端被不良用心的人員，惡意采用Http抓包進行破解。​<code>​是防止媒體資源被盜播，維護内容生産者的利益的 第一步​</code>​，也是很重要的一步。 因為：

短視訊源碼移動端無論如何防破解，總不能100%保證無法破解；

想要擷取播放位址，必須購買音視訊内容，對于用心不了的人員，增加了其破解成本；

未購買使用者，通過音視訊ID 101向服務端發起請求，傳回資料如下：

注：未購買使用者，請求某音視訊清單接口時，不要傳回 ​<code>​媒體資源的m3u8播放位址​</code>​ 和 ​<code>​擷取媒體資源playKey的encryptId​</code>​。這很重要

為防止移動端短視訊源碼被Http抓包，​<code>​mediaUrl​</code>​ 與 ​<code>​encryptId​</code>​ 都不是明文傳輸的。是以移動端拿到課程的内容清單後，首先需要對​<code>​mediaUrl​</code>​ 與 ​<code>​encryptId​</code>​進行解密。

關于解密：

對稱加密算法，大家可以根據實際需求，自行進行選擇；

解密相關代碼，​<code>​建議由C語言實作，打成SO添加到移動用戶端中​</code>​；

原因是​<code>​增加短視訊源碼移動端破解難道，提高破解成本​</code>​。

這裡隻是采用了簡單的AES對稱加密：

完成解密後的資料格式如下：

在第1步中，已成功擷取到媒體資源的播放位址 ​<code>​https://domain/course101.m3u8​</code>​與​<code>​encryptId​</code>​。為了播放短視訊源碼媒體資源，下面來擷取到加密m3u8視訊的解密​<code>​playKey​</code>​

這裡 ​<code>​playKey​</code>​ 仍然需要從服務端進行擷取，擷取方式如下：

發起請求：

傳回結果：

這裡仍然模拟一個簡單get請求：

請求參數 ​<code>​encryptId​</code>​ 為 ​<code>​qazwsx101​</code>​；

請求參數 ​<code>​mediaId​</code>​ 為 ​<code>​101​</code>​；

請求位址為 ​<code>​https://domain/xxx/getMediaToken.do​</code>​；

注：playKey是加密m3u8解密的關鍵，是防止短視訊源碼媒體資源被破解的重中之重。

這裡是​<code>​防止媒體資源被盜播，維護内容生産者的利益的 第三步和第四步​</code>​

1、​<code>​playKey​</code>​ 服務端需​<code>​加密傳輸​</code>​；

2、請求​<code>​getMediaToken.do​</code>​接口時，短視訊源碼服務端需對該使用者的購買狀态進行驗證，未購使用者不傳回其對應的playKey；

3、移動端擷取到playKey後，在SO（C層代碼達成的）中對playKey進行解密；

4、解密後的playKey存在一定的過期時間；或者使用次數限制（建議服務端限定隻能使用一次）

加密算法要與mediaUrl 和encryptId 的解密算法區分開，增加破解成本

經過以上步驟，購買使用者成功擷取到 ​<code>​播放位址 https://domain/xxx/getMediaToken.do​</code>​和​<code>​解密key I_am_playkey_001​</code>​。

将mediaUrl 與playKey 拼接起來，可以交給播放器播放了：

到此，移動端的工作完成。

OK. ​<code>​移動端完事大吉​</code>​。

到這裡短視訊源碼播放器與服務端的互動剛剛開始。

這裡有必要先介紹一下，加密m3u8視訊的檔案格式：

加密m3u8視訊的檔案格式

以上為加密m3u8視訊的檔案格式：

短視訊源碼播放器在播放前，會用該位址 ​<code>​http://domain//hls.key​</code>​向業務​<code>​伺服器​</code>​發起請求，請求加密m3u8視訊的​<code>​解密秘鑰​</code>​；

解密秘鑰如下圖所示：

加密m3u8視訊的​<code>​解密秘鑰​</code>​并非​<code>​playKey=i_am_decrypting_key101​</code>​，而是一個16位元組的檔案。

m3u8的解密秘鑰實際是一個16位元組的檔案。

這裡肯定會有很多疑問，别着急，我們繼續前邊的話題​<code>​播放器​</code>​與​<code>​服務端​</code>​互動。

播放器 與 服務端 互動

當 ​<code>​播放器​</code>​ 向 ​<code>​服務端​</code>​ 發起​<code>​https://domain/course101.m3u8?playKey=i_am_decrypting_key101​</code>​ 請求後；

​<code>​服務端​</code>​ 處理相對複雜

a、首先校驗​<code>​playKey=i_am_decrypting_key101​</code>​是否有效；

b、若有效則将加密m3u8視訊中的​<code>​http://domain//hls.key​</code>​更換為​<code>​http://domain//hls.key?playKey=i_am_decrypting_key101​</code>​；

c、下發m3u8檔案給播放器；

​<code>​播放器​</code>​收到​<code>​服務端​</code>​下發的​<code>​加密m3u8​</code>​檔案後：

a、​<code>​播放器​</code>​讀取​<code>​加密m3u8​</code>​檔案，擷取​<code>​解密秘鑰​</code>​的請求位址​<code>​http://domain//hls.key?playKey=i_am_decrypting_key101​</code>​；

b、​<code>​播放器​</code>​向​<code>​服務端​</code>​發起 ​<code>​http://domain//hls.key?playKey=i_am_decrypting_key101​</code>​請求，請求解密秘鑰；

​<code>​服務端​</code>​收到​<code>​播放器​</code>​的請求後，需對​<code>​playKey=i_am_decrypting_key101​</code>​進行校驗，檢視是否過期或者被使用過，若存在異常則不下發秘鑰；若正常，則下發秘鑰

​<code>​播放器​</code>​收到秘鑰檔案後，正常播放；

OK. 這次是真的 ​<code>​完事大吉​</code>​。

如果僅僅做到上一步就結束了，短視訊源碼移動端被破解的機率還是很高。因為SO任然可以被反編譯破解，而且SO的反編譯技術也已經相當成熟。

是以，​<code>​無論在SO中采用了怎樣複雜的加密算法，SO被反編譯後，還是有被破解的可能​</code>​。

是以，以上步驟都完成後，我們仍然要對我們最終生成的短視訊源碼進行一次加密。​<code>​Android端推薦采用短視訊源碼加強處理​</code>​。

以上步驟都做完，如果短視訊源碼仍然被破解了。我們可以再加一層防破解處理：​<code>​動态下發SO，定期更新加密算法​</code>​。

這樣就算線上短視訊源碼被破解了，也可以在不發版的情況下從容應對，更新一下加密算法就可以了。

這裡來簡單總結一下，上邊介紹的實作步驟 ：

a、移動端拿 courseId 向服務端發起Http請求，​<code>​擷取課程的内容清單​</code>​；

b、服務端對使用者進行權限驗證，​<code>​未購買使用者不傳回其對應的播放位址​</code>​；

c、移動端​<code>​在SO層中對 mediaUrl與 encryptId 進行解密​</code>​；

d、移動端 用解密後的encryptId，​<code>​向服務端請求對應媒體資源的 playKey​</code>​

e、服務端對使用者進行權限驗證，​<code>​未購買使用者不傳回其對應的 playKey​</code>​；

f、移動端 ​<code>​在SO層中對 playKey 進行解密​</code>​；

注意，一定要與第三步的解密算法區分開

g、​<code>​拼接mediaUrl 與 playKey​</code>​ ，交給短視訊源碼播放器播放；

到此，移動端工作完成。

h、​<code>​播放器​</code>​向​<code>​服務端​</code>​發起下發m3u8請求

i、​<code>​服務端​</code>​校驗playKey；并動态替換m3u8中的URI字段

j、​<code>​播放器​</code>​從m3u8檔案中取出URI字段後，向短視訊源碼服務端請求解密秘鑰；

k、​<code>​服務端​</code>​校驗playKey；并傳回解密秘鑰檔案；

l、​<code>​播放器​</code>​播放

到此，加密m3u8 終于播放出來了。

m、移動端短視訊源碼加強處理；

n、為增強破解難度，這裡解密​<code>​SO可由動态下發，定期更新加密算法​</code>​；

m、如果仍然擔心短視訊源碼被破解，服務端下發的​<code>​解密秘鑰檔案​</code>​可以設定為非明文狀态；用戶端拿到解密秘鑰後，以本地代理的方式設定給播放器進行播放。

注：這裡有三個關鍵步驟：1、服務端對使用者進行權限驗證，未購買使用者不傳回其對應的播放位址；2、移動端 在SO層中對 playKey 進行解密；3、移動端App加強處理。

這三個關鍵步驟缺一不可，缺少任何一個移動端的破解難度和成本都将大大降低。

未購買使用者不傳回其對應的短視訊源碼播放位址

可以極大的降低付費音視訊内容被大面積破解的情況出現。因為購買音視訊内容亦需要成本。破解的音視訊内容越多，那需要購買的音視訊内容就越多，破解成本也就越高。

在SO層中對 playKey 進行解密

對于加密m3u8媒體資源，破解的關鍵就在于playKey，是以playKey的加密算法應足夠的複雜

移動端短視訊源碼加強處理

移動端短視訊源碼加強，是移動端代碼反編譯非常重要的一環。如果沒有這一環​<code>​在SO層中對 playKey 進行解密​</code>​的作用不是很大，因為無論SO中加密算法如何複雜，隻要SO被翻遍後，再複雜的加密算法也沒有意義了。

以上為全部處理流程

如果以上步驟都做了，付費音視訊被盜播的可能性應該不大；但仍然存在Http抓包的可能性：

http抓包時，會抓到​<code>​https://domain/course101.m3u8?playKey=i_am_decrypting_key101​</code>​請求

由于playKey隻有一次使用有效，或者幾個小時的逾時時間。是以該内容無法被大規模傳播；

http抓包時，會抓到短視訊源碼播放器的秘鑰下發請求 ​<code>​http://domain//hls.key?playKey=i_am_decrypting_key101​</code>​；

由于服務端存在playKey有效性的校驗，下次使用失效，是以也無法大規模傳播；

如果對服務端明文秘鑰檔案下發存在疑慮，可以做以上流程圖的“防盜播9”；

​<code>​防盜播9​</code>​ 加上​<code>​短視訊源碼加強​</code>​，在實作上應該是比較安全了

以上就是“在短視訊源碼開發中，移動端音視訊加密、防盜播實作方案"的全部内容，希望對大家在短視訊開發時能有幫助。