李吉廣
(北京騰銳視訊科技有限公司,北京 100176)
?
IPTV視頻硬件加密傳輸系統的設計
李吉廣
(北京騰銳視訊科技有限公司,北京 100176)
摘要:目前IPTV都是清流直接播出,容易盜鏈。鑒于視頻數據量非常大,實時性、連續性要求高,軟件文件加解密的方式用于IPTV有一定的局限性,設計實現了一套IPTV硬件加密傳輸播控系統。闡述了整體的設計架構,3DES與224位ECC加密算法的使用、密鑰的管理方式、3DES密鑰的傳輸方法、系統的實現、關鍵技術、安全性等。
關鍵詞:IPTV;硬件加密;數據安全;安全播出;盜鏈;ECC算法;3DES算法
1設計需求及背景技術
近年來互聯網電視發展迅速。互聯網電視可以提供高質量的視頻節目,用戶可以自由地選擇寬帶IP網上視頻節目,實現媒體提供者和媒體消費者的實質性互動,為網絡發展商和節目提供商提供了廣闊的新興市場。但是目前IPTV存在著盜鏈、不易收費、很容易被截獲看到等問題。盜鏈的服務提供商自己不提供服務的內容,通過技術手段繞過其他有利益的最終用戶界面(如廣告),直接在自己的網站上向最終用戶提供其他服務提供商的服務內容,騙取最終用戶的瀏覽和點擊率。受益者不提供資源或提供很少的資源,而真正的服務提供商卻得不到收益。由于內容傳送的是清流,視頻內容很容易被截獲看到,視頻傳輸的安全性大大降低。本項目使用硬件將視頻流(也特別適合很大的、實時性要求高的大數據量的文件)進行加密傳輸,并設計了用戶授權管理系統,為收費提供了手段,從根本上徹底解決了上述問題[1-2]。
2設計構思
網絡上傳輸的視頻數據量非常大,實時性、連續性要求高。因此常用的文件加密方式在傳輸視頻時不適用。視頻數據現在基本上是通過清流傳輸。由于數據量相對很少,文件加密基本上是通過軟件或處理運算能力很低的輔助硬件例如類似銀行U盾的設備完成的。多套節目同時播出的IPTV視頻流數據量非常巨大,不可能通過處理普通文件的處理方法和處理能力進行處理。本文中視頻流在整個傳輸過程中通過專用的硬件設備進行實時的加密與解密處理,在互聯網上傳輸加密的實時或非實時的大數據量的視頻,核心是設計了使用硬件對視頻流進行加密的加密數據打包服務器和解密的USB視頻硬件解密盤,本文設計了一整套視頻加密傳輸IPTV播控系統,這套系統對視頻流進行加密,保證傳輸過程中在互聯網上傳輸的是加密視頻流,這樣即使被截獲后也不能被看到。本文設計了用戶授權管理軟件及系統,從而完成了用戶的授權、收費與管理。
3整體架構、工作原理與數據流程
特別重點設計了系統的整體結構、協議及數據結構、由硬件對視頻流進行加密運算的加密數據打包服務器和由硬件解密的USB視頻硬件解密盤。整個系統由加密數據打包服務器(簡稱打包服務器)、用戶授權管理服務器(簡稱管理服務器)、節目存儲視頻服務器、通用清流IPTV機頂盒(簡稱機頂盒)、USB視頻硬件解密盤構成(簡稱解密盤),如圖1所示。每個解密盤都有唯一的一個識別號,這有助于提高系統的安全性。

圖1 IPTV視頻加密傳輸系統框圖
密鑰傳輸的邏輯關系如圖2所示。

圖2 密鑰傳輸的邏輯關系
數據包的結構(圖3)如下:各種標準例如MPEG-1、MPEG-2、H.264、H.265等的視頻節目或者大數據量的文件在該系統中均視為大數據量的數據文件。打包服務器首先將數據文件分割成長度為8 byte的等長的數據小塊,接著使用3DES將數據小塊加密。然后將固定數量(例如1 024個)加密后的數據小塊連接成1個數據大塊,對該數據大塊做SHA265運算,將得到的哈希值與當前的和下一個的3DES密鑰識別號、用戶管理服務器地址連接在一起,構成特征信息,然后對該特征信息做224位ECC運算,將得到的加密特征信息再與包頭同步字、包長、包識別號連接在一起,放在數據大塊前面,共同封裝成加密數據包。

圖3 加密數據包結構
3DES密鑰的傳輸時序安排如下:加密數據包通過互聯網傳輸給接收端,3DES密鑰持續一定時間后要變換成下一個密鑰,變化時間間隔通過打包服務器的人機界面設定。在加密數據包頭里傳輸下一個密鑰的識別號的目的是為了給3DES解密模塊提前準備下一個密鑰提供信息,從而保證解密盤有足夠的時間從授權管理服務器上獲得下一個密鑰,進而保證密鑰切換時視頻播放的連續性。機頂盒上的應用程序將收到的加密數據包傳輸給解密盤,解密盤內軟件接收加密數據包后分拆數據包,獲得當前的和下一個3DES密鑰識別號。
密鑰請求指令的生成:解密盤內的軟件獲取本身的解密盤識別號,與當前的和下一個3DES密鑰識別號一起組成請求密鑰明文,然后用事先存在于解密盤內的使用224位ECC算法的用戶獨有私鑰加密,再次加入解密盤識別號,然后再使用ECC算法的用戶共有公鑰加密,形成經過兩次224位ECC加密的3DES密鑰請求指令,發送給用戶授權管理服務器去請求密鑰。
ECC算法使用的兩個密鑰對:用戶管理信息的加密傳輸使用了兩個密鑰對,用戶獨有密鑰對和用戶共有密鑰對。用戶獨有密鑰對是指ECC公鑰保存在管理服務器內的數據庫中,私鑰保存于解密盤內的針對每一個用戶都不相同的解密盤與管理服務器單獨通信使用的密鑰對。用戶共有密鑰對指的是ECC私鑰保存于加密打包機內的硬件加密打包板卡內的,而公鑰保存于所有的解密盤內,并且所有解密盤的公鑰都相同的一個密鑰對,該密鑰對在服務器無法確知具體的解密盤的用戶識別號時與所有解密盤通信時使用。
解密盤身份的驗證及密鑰的發放:在接到用戶終端的請求指令后,管理服務器首先使用用戶共有密鑰對中的私鑰對收到的加密的請求指令進行一次解密,得到請求指令中的解密盤識別號,然后將解密盤識別號與數據庫中的數據比較,從而判別該用戶號是否為合法授權用戶,如果是合法用戶,那么根據該識別號在數據庫內找出相對應的用戶獨有密鑰對中的公鑰對指令進行二次解密。將二次解密后得到的解密盤識別號與一次解密后得到的解密盤識別號進行比較,如果一致說明解密盤身份真實,則繼續進行下一步,如果不一致說明解密盤身份被偽造了。如果身份真實,服務器會根據3DES密鑰的識別號在數據庫中找出對應的密鑰,然后使用用戶獨有ECC密鑰對中的公鑰對相應的3DES密鑰進行加密,通過互聯網發送給相應的解密盤。解密盤收到加密的3DES密鑰后使用用戶獨有ECC密鑰對中的私鑰解密出相對應的3DES密鑰。并將密鑰存儲在內部存儲器中[3-4]。
ECC加密的特征信息:打包服務器使用用戶共有密鑰對中的私鑰對特征信息進行加密,解密盤使用用戶共有密鑰對中的公鑰對加密特征信息進行解密。
解密盤對加密數據包的解密:解密盤首先使用SHA256函數計算3DES加密的數據大塊的哈希值,如果得到的哈希值與特征信息里收到的哈希值相同,證明加密數據包是原始的數據包,沒有被改變。解密盤將加密的大數據拆分成數據小塊,然后用得到的3DES密鑰對加密的數據小塊解密,恢復出原始的數據。
開戶授權:每一個用戶在開戶時,人工核實身份后,管理服務器對解密盤進行授權,在授權過程中,服務器接收被授權用戶解密盤給出的用戶獨有ECC密鑰對中的公鑰,其中的私鑰由解密盤自己生成并保存在內部。同時服務器將用戶共有ECC密鑰對中的公鑰輸出給解密盤,硬件加密打包板卡保存相應的私鑰。服務器上運行MySQL數據庫。
用戶端構成:用戶端由機頂盒、機頂盒應用程序(APP)及解密盤構成。采用通用機頂盒保證了該系統可以更好地商業化,針對不同的機頂盒平臺例如安卓平臺需要安裝不同的支持相應系統的應用程序。解密盤是核心部分,機頂盒輸出加密視頻流給解密盤,解密盤將解密后的清流通過USB接口輸出給機頂盒,然后機頂盒對清流進行解碼輸出。
4系統的實現方式
1)節目存儲視頻服務器:購買或租用標準的商用視頻服務器。
2)清流IP機頂盒:采用通用的可以解碼清流的商用機頂盒軟硬件平臺作為清流IPTV機頂盒,本文提供應用程序接口,與機頂盒設計者聯合開發支持本系統的應用程序軟件,將開發的軟件安裝在機頂盒上。
3)用戶授權管理服務器:該服務器的硬件采用標準商業用服務器,軟件中的數據庫采用標準商業用數據庫軟件。自己開發了用戶授權管理軟件,安裝在服務器上運行,該軟件實現了用戶的開戶、銷戶、服務分類、有效期管理、用戶的授權、反授權、收費、發送指令、公告等用戶管理功能。
4)打包服務器:服務器的硬件采用標準商業用服務器。為了提高視頻流的處理速度,設計了硬件加密打包板卡模塊。該模塊是由一塊插入服務器內部的使用了PCI總線的硬件板卡來完成,該板卡上使用了加密打包芯片,該芯片內部具有強大的CPU、加密算法硬件協處理器[7-8]。軟件硬件結合完成了數據的打包、密鑰的生成與管理等功能。
5)USB視頻硬件解密盤:由一個外觀類似USB存儲盤的裝置完成,該裝置內部使用了解密芯片。該芯片內部具有強大的CPU、硬件3DES算法、硬件ECC算法協處理器。該芯片完成了3DES解密、3DES密鑰的獲取,ECC密鑰的生成與管理,ECC的加密解密、解密盤識別號管理等功能。
5實現系統的關鍵技術
該系統實現涉及以下幾項關鍵技術:數據的加密打包方法及格式的定義、加密算法的選擇、密鑰的交換方法與體系、硬件加密打包板卡、硬件包服務器和USB視頻硬件解密盤等的設計與實現。
6系統的安全性分析
3DES與224位的ECC算法的安全性在很多文獻中有非常詳細的分析,算法本身在每一個密鑰的生命周期內是非常安全的。3DES 與ECC 算法均在解密盤的內部芯片中運行,密鑰全部存儲于解密盤的內部芯片中,在整個運行過程中,全部敏感數據都在芯片內部,不出現在任何外部總線上。每一個解密盤都有一個唯一的識別碼,對應著不同的ECC密鑰對,并且3DES密鑰是經過雙層224位ECC算法加密的,因此加密強度非常高,破解難度非常大[6-7]。
節目被加密后,服務器上的節目內容就沒有盜鏈的意義了,盜了也沒用,普通用戶根本看不了,必須持有后端的USB視頻硬件解密盤,并且使用此系統的解密應用軟件才有可能對視頻數據進行解密,達到設計目的。
7系統的數據處理能力
該系統中打包服務器的一個加密打包模塊處理數據的速度可達500 Mbit/s,還可以疊加多個加密打包板卡模塊。后端解密盤解密時處理數據的速度可達40 Mbit/s。可加密實時直播數據,只要總帶寬沒達到上限,可同時加密處理的直播節目總數幾乎沒有上限。對于直播節目,目前支持的數據傳輸協議有UDP、HTTP、HLS等協議,對于音視頻節目的壓縮標準沒有限制,MPEG-1、MPEG-2、H.264、H.265等都支持。可加密非實時的用于點播的文件,對非實時文件采取“預處理”、“預加密”的方式,
8數據管理和用戶管理功能
加解密可將不同的節目分成不同的產品包和套餐包,方便采用不同的價格來管理。用戶管理很靈活,由于每一個USB視頻硬件解密盤都有一個唯一識別號,前端服務器就很容易對用戶進行管理,可以通過前端服務器和后端的視頻解密軟件,來對單獨的用戶進行“開授權”和“關授權”。當然也可以批量“開授權”、“關授權”。開戶很便捷,可通過文件批量導入來批量開戶,也允許每一個用戶獨立登錄網站開戶,也支持二維碼掃描開戶。充值續費很方便,支持每一個用戶獨立登錄網站續費,也支持掃描二維碼來續費,也支持發短信續費。
9系統的實際試驗情況
目前,這套系統已經全部開發完成,在實驗室搭建了測試試驗平臺,目前已經試驗約3個月的時間。系統現在平穩運行,在運行過程中,有時會發現一些小的問題與缺陷,經過不斷的改進,目前系統運營情況比較好。下一步準備進入商業推廣階段。
參考文獻:
[1]陳翔.數字電視條件接收系統的安全性分析[J].電視技術,2010,34(2):43-45.
[2]陳文全,付國映,趙利,等.數字電視條件接收系統的安全性分析[J].電視技術,2004,28(1):53-55.
[3]閆茂德,賀昱曜,張陽.AES與ECC混合加密算法的無線數據通信系統設計[J].微電子學與計算機,2007(7):135-138.
[4]馬擎宇,張東.基于AES和ECC的遙測數據加密技術研究與實現[J].艦船電子工程,2015(4):78-81.
[5]王紅珍,李竹林. 基于AES和ECC的混合加密系統的設計與實現[J].電子設計工程, 2012(4): 9-11.
[6]王紅珍, 李竹林. ECC算法在軟件保護中的應用及安全性分析[J].計算機技術與發展,2012(8): 155-158.
[7]潘崢嶸, 朱麗麗. ECC與AES混合加密算法在射頻CPU卡安全機制中的應用[J].計算機系統應用,2012(9):162-165.
責任編輯:時雯
Design of IPTV video hardware encryption transmission system
LI Jiguang
(BeijingTengrui(Topreal)TechnologiesCo.Ltd.,Beijing100176,China)
Abstract:Currently the clear video data flow is directly broadcasted in IPTV systems. Hot link is easy. Software data encryption methods are not suitable for IPTV because the video data are very considerable, real-time and consistent. In this article an IPTV hardware encryption transmission broadcasting control system is designed and implemented. The infrastructure,usage of 3DES and 224bit ECC algorithms, key management, transmission methods of the 3DES keys, system implementation, kernel technologies, security, etc are illustrated.
Key words:IPTV; hardware encryption; data security; securely broadcasting; hotlink; ECC algorithm; 3DES algorithm
中圖分類號:TN919.81
文獻標志碼:A
DOI:10.16280/j.videoe.2016.05.016
收稿日期:2015-11-25
文獻引用格式:李吉廣. IPTV視頻硬件加密傳輸系統的設計[J].電視技術,2016,40(5):74-77.
LI J G. Design of IPTV video hardware encryption transmission system [J].Video engineering,2016,40(5):74-77.