背景

1、一路直播數據流從客戶推流產生媒體數據，直到其它客戶進行播放，中間經過各種服務器和防火墻的轉發，如果出現dns劫持等中間人攻擊的情況，視頻流內容會被篡改而不自知。因此通常使用全鏈路數據加密，或者秘鑰機制加密數據等方式來進行防篡改。

2、當前方案存在如下問題：

2.1 使用全鏈路加密時，在推拉流的每個層級都需要做加解密的動作，從而引入了播放延遲。

2.2 使用秘鑰加密標志位的方法進行防篡改，則需要提前進行秘鑰分發，這會增加直播的復雜性和成本。

方案

通過增加校驗參數來進行篡改識別。包含兩個字段，哈希值和隨機數。兩個字段是跟隨關鍵幀（RTMP/FLV拉流）或者每片數據（ts片的參數）發布的。對關鍵幀或者數據片加上隨機數使用sha256進行計算，結果符合哈希值的，則認為沒有篡改。

當哈希值和與之匹配的隨機數在同一段數據中進行發送時，篡改方會在篡改數據的同時，使用自己重新計算的隨機數和哈希值進行替換從而使該機制失效。如果把需要參與計算的隨機數放在下一次發送的校驗數據中，篡改時無法提前知曉。但篡改方可以通過緩存下一次數據，獲取到隨機數之后再進行篡改。如果把參與計算的隨機數再擴大一幀數據，篡改方就需要再多緩存一次數據。按照普通直播平均10秒的緩存數據，每個gop3秒來計算，連續4次的隨機數參與計算，進行篡改時引入的時延就會過大導致直播無數據斷流。

參與計算的隨機數序列越長，則破解需要引入的時延越長，安全性越高。但同時識別出是否篡改的時間也會變長。

示例

1 每個數據包包含三個部分，媒體數據幀，哈希值和nonce值。

2 當使用兩個序列作為校驗值時，哈希值1由數據幀1+nonce2+nonce3做哈希產生，nonce2的值在下一個關鍵幀中發送，nonce3是在下下次。

3 對任意數據包的內容進行修改，都會造成之前或者之后的哈希值無法匹配，從而識別出篡改。

4 破解方式需要中斷直播流，并且緩存夠兩個序列后再進行篡改。所以當序列長度大于直播的時延需求，如10~30秒的時間，破解行為就會被輕易識別出來。