視頻內(nèi)容加密封裝技術(shù)研究

郭曉霞，王 磊，沈 陽(yáng)

（國(guó)家新聞出版廣電總局 廣播科學(xué)研究院，北京 100866）

視頻內(nèi)容加密封裝技術(shù)研究

郭曉霞，王 磊，沈 陽(yáng)

（國(guó)家新聞出版廣電總局 廣播科學(xué)研究院，北京 100866）

基于HTTP的動(dòng)態(tài)自適應(yīng)流媒體技術(shù)面向多種智能終端提供視頻服務(wù)是目前互聯(lián)網(wǎng)視頻服務(wù)的主流模式，內(nèi)容加密封裝是互聯(lián)網(wǎng)視頻數(shù)字版權(quán)保護(hù)的關(guān)鍵技術(shù)之一。對(duì)主流互聯(lián)網(wǎng)視頻格式的封裝方法、加密方法進(jìn)行分析，并提出基于網(wǎng)絡(luò)提取層的視頻內(nèi)容加密方案，為互聯(lián)網(wǎng)視頻服務(wù)提供商實(shí)現(xiàn)視頻內(nèi)容保護(hù)提供技術(shù)支撐。

內(nèi)容加密；數(shù)字版權(quán)管理；互聯(lián)網(wǎng)視頻；HLS；MPEG-DASH；CENC

目前，采用基于HTTP的動(dòng)態(tài)自適應(yīng)流媒體技術(shù)面向智能手機(jī)、平板電腦、智能電視機(jī)頂盒以及PC等提供多屏互動(dòng)的視頻服務(wù)已經(jīng)成為互聯(lián)網(wǎng)視頻服務(wù)的主流模式。互聯(lián)網(wǎng)視頻服務(wù)的廣泛開(kāi)展，亟需有效的技術(shù)手段抑制網(wǎng)絡(luò)視頻盜版問(wèn)題，保障互聯(lián)網(wǎng)視頻服務(wù)運(yùn)營(yíng)可管可控。內(nèi)容加密封裝是互聯(lián)網(wǎng)視頻內(nèi)容版權(quán)保護(hù)的關(guān)鍵技術(shù)之一，互聯(lián)網(wǎng)視頻的加密內(nèi)容封裝格式，加密后的內(nèi)容應(yīng)包含內(nèi)容標(biāo)識(shí)及獲取許可證所必須的信息。根據(jù)不同的應(yīng)用場(chǎng)景，需要定義不同的加密內(nèi)容封裝格式，目前主流的加密封裝格式包括基于ISO基礎(chǔ)媒體文件格式的通用加密格式（CENC）、基于HTTP動(dòng)態(tài)自適應(yīng)流媒體協(xié)議（MPEG DASH）的加密內(nèi)容封裝格式、Ap?ple公司的加密內(nèi)容格式（HLS）。

1 視頻封裝格式概述

目前主流的視頻壓縮編碼格式是H.264/AVC，H.264/ AVC是ITU-T VCEG和ISO/IEC MPEG共同開(kāi)發(fā)的視頻處理標(biāo)準(zhǔn)，ITU-T作為標(biāo)準(zhǔn)建議H.264，ISO/IEC作為國(guó)際標(biāo)準(zhǔn)14496-10（MPEG-4第10部分）高級(jí)視頻編碼（AVC）。H.264的算法在概念上可以分為兩層：視頻編碼層（Video Coding Layer，VCL）和網(wǎng)絡(luò)提取層（Network Abstraction Layer，NAL），NAL層為視頻內(nèi)容提供了與網(wǎng)絡(luò)無(wú)關(guān)的統(tǒng)一接口，支持多種網(wǎng)絡(luò)情況下的傳輸。

視頻信號(hào)以H.264編碼壓縮到NAL單元中，NAL層之上是根據(jù)不同的內(nèi)容封裝格式或傳輸格式對(duì)NAL單元的打包。例如視頻流可以被打包到PES包中，PES包又被封裝成188 byte大小TS包作為T(mén)S流輸出；視頻流也可以被打包成Sample，然后增加頭部信息等封裝成MP4文件，如圖1所示。

圖1 視頻內(nèi)容格式

因此對(duì)于視頻內(nèi)容的加密，可以有多種選擇。例如對(duì)VCL層視頻編碼數(shù)據(jù)的加密，如對(duì)編碼的DCT系數(shù)進(jìn)行加密，對(duì)熵編碼的數(shù)據(jù)進(jìn)行加密等；在編碼層對(duì)NAL層不同類(lèi)型的幀選擇性加密，如HLS的NAL層加密；在視頻封裝層對(duì)數(shù)據(jù)進(jìn)行加密，如對(duì)TS包進(jìn)行加密（HLS的全文加密），或?qū)P4文件的sample進(jìn)行加密（基于14496-12基本文件格式的CENC加密和PDCF打包格式）；解決方案層的加密，如MPEG-DASH加密。

視頻加密方案的具體選擇需要結(jié)合視頻來(lái)源的內(nèi)容格式來(lái)考慮，如果視頻來(lái)源是ES基本碼流，則選擇在編碼層對(duì)NAL單元加密可以提供與上層封裝及切片無(wú)關(guān)的加密方案；如果視頻來(lái)源是已經(jīng)封裝好的內(nèi)容格式，例如TS包或MP4文件，則應(yīng)該根據(jù)具體的封裝格式選擇相應(yīng)的加密方案（后文在敘述中較多使用了標(biāo)準(zhǔn)中的代碼描述）。

2 DASH加密

2.1 DASH概述

基于HTTP的動(dòng)態(tài)自適應(yīng)流媒體DASH以媒體流模式提交媒體內(nèi)容，其控制只依賴于客戶端。客戶端通過(guò)HTTP協(xié)議從標(biāo)準(zhǔn)的Web服務(wù)器請(qǐng)求數(shù)據(jù)，服務(wù)器不需要做適應(yīng)于DASH的配置。23009-1中定義了從標(biāo)準(zhǔn)HTTP服務(wù)器到HTTP客戶端間媒體內(nèi)容分發(fā)和緩存所需的格式，主要包括MPD和媒體分片格式。MPEG-DASH的加密格式在23009-4中描述[1-2]。

2.2 MPD文件

媒體內(nèi)容編碼和提交版本，以及適合的描述形成媒體表述（MPD文件），MPD文件層次機(jī)構(gòu)如圖2所示。

圖2 DASH基礎(chǔ)段加密

1）媒體內(nèi)容由單獨(dú)或多個(gè)時(shí)間上連續(xù)的媒體內(nèi)容時(shí)期（periods）組成。

2）每個(gè)period都由一個(gè)或多個(gè)媒體內(nèi)容組件組成，例如不同語(yǔ)言的音頻組件和視頻組件。媒體內(nèi)容組件由媒體內(nèi)容組件類(lèi)型標(biāo)識(shí)，例如音頻或視頻。

3）每個(gè)媒體內(nèi)容組件可能有幾個(gè)不同的編碼版本，即媒體流。每個(gè)媒體流繼承媒體內(nèi)容的屬性，包括媒體內(nèi)容peri?od、編碼參數(shù)、編碼率等。

4）段可以被分為子段，每個(gè)子段包含若干個(gè)完整單元，客戶端可以發(fā)起請(qǐng)求來(lái)請(qǐng)求子段。

DASH中不同媒體內(nèi)容組件的所有編碼版本共享相同的時(shí)間線。媒體內(nèi)容里的單元被定位到全局通用的時(shí)間線，同步不同的媒體單元，便于相同媒體組件在不同編碼版本之間切換。

客戶端可以在一個(gè)Adaptation Set的不同Representation之間切換。切換過(guò)程為：首先播放到這個(gè)Representation的段或子段的結(jié)尾，然后播放新的Representation的下一個(gè)段或子段。

2.3 數(shù)據(jù)加密

ISO/IEC 23009-4定義了DASH的內(nèi)容保護(hù)框架，用于獲取媒體段的解密方法以及解密參數(shù)。MPD文件提供加密接口，定義key/IV的獲取方式，并支持多個(gè)加密系統(tǒng)加密同一份內(nèi)容。

1）加密方式

DASH段加密有兩種方式：基礎(chǔ)段加密方式和基于許可證的DRM方式。

（1）基礎(chǔ)段加密

DASH中基礎(chǔ)的段加密方式采用AES-CBC算法實(shí)現(xiàn)，使用HTTP（S）實(shí)現(xiàn)密鑰傳輸。DASH的客戶端能夠識(shí)別出每個(gè)段的KEY和IV，并發(fā)起請(qǐng)求獲取KEY實(shí)現(xiàn)媒體段的解密，如圖2所示。

（2）DRM系統(tǒng)加密

DASH支持基于許可證的DRM系統(tǒng)。在這種方式中，客戶端獲取許可證，通過(guò)許可證獲取KEYID，并通過(guò)KEY和MPD中包含的加密信息實(shí)現(xiàn)媒體段的解密。每個(gè)DRM系統(tǒng)可以采用該系統(tǒng)的許可證和KEYID的映射方式。

2）段加密

DASH中媒體分塊如果是加密的，其加密相關(guān)信息通過(guò)ContentProtection來(lái)指定。

內(nèi)容加密方法定義：通過(guò)SegmentEncryption@schemeI?dUri指定，DASH規(guī)定客戶端應(yīng)該強(qiáng)制支持AES-128 CBC加密，可選支持AES-128 GCM加密。

Key/IV的獲取：MPD優(yōu)先從License元素獲取key/IV信息，如果License元素不存在，則從CryptoPeriod和CryptoTime?line獲取key/IV信息。

許可證獲取：對(duì)于基于許可證的內(nèi)容保護(hù)系統(tǒng)，通過(guò)Li?cense元素可獲取許可證URL，DASH支持相同內(nèi)容的多個(gè)內(nèi)容保護(hù)系統(tǒng)加密。

密碼有效期：每個(gè)加密段都同一個(gè)密碼有效期關(guān)聯(lián)，同一個(gè)密碼有效期的加密段使用相同的key/IV，密碼有效期的持續(xù)時(shí)間以段的數(shù)目為量度。

3）命名空間定義

MPD文件的開(kāi)始處增加命名空間定義。內(nèi)容保護(hù)的描述在命名空間urn:mpeg:dash:schema:mpd:2011中定義。Seg?mentEncryption，CryptoPeriod和 CryptoTimeline在命名空間urn:mpeg:dash:schema:sea:2013中定義。

4）內(nèi)容保護(hù)元素定義

（1）ContentProtection

DASH中媒體分塊如果是加密的，其加密相關(guān)信息通過(guò)ContentProtection來(lái)指定，相關(guān)描述見(jiàn)表1。DASH中Content?Protection的@schemeIdUri屬性應(yīng)為urn:mpeg:dash:sea:enc: 2013。

表1 ContentProtection屬性說(shuō)明

@schemeIdUri:23009-4中規(guī)定@schemeIdUri屬性為urn: mpeg:dash:sea:enc:2013。GY/T 277—2014中增加擴(kuò)展@sche?meIdUri的值為ChinaDRM申請(qǐng)的唯一編號(hào)。

（2）SegmentEncryption

SegmentEncryption描述應(yīng)用在所有密碼有效期的段加密屬性，相關(guān)描述見(jiàn)表2。

表2 SegmentEncryption屬性說(shuō)明

（3）License

License元素作用于整個(gè)密碼有效期，ContentProtection內(nèi)可以有一個(gè)以上的License元素。如果License缺省，則加密參數(shù)由cryptoPeriod和cryptoTimeline指定，相關(guān)描述見(jiàn)表3。

表3 License屬性說(shuō)明

（4）CryptoPeriod通用屬性

CryptoPeriod指加密參數(shù)的持續(xù)時(shí)間。CryptoPeriod代表一個(gè)單獨(dú)的密碼有效期，CryptoTimeline代表多個(gè)類(lèi)似的CryptoPeriod，相關(guān)描述見(jiàn)表4。

表4 CryptoPeriod通用屬性說(shuō)明

（5）CryptoPeriod

CryptoPeriod定義一個(gè)密碼有效期，提供key和IV，同時(shí)定義哪些段加密，相關(guān)描述見(jiàn)表5。CryptoPeriod唯一對(duì)應(yīng)一個(gè)加密起始段，CryptoPeriod可能是有限的時(shí)間（即段的數(shù)量），也可能是無(wú)限制的（到當(dāng)前Period結(jié)束）。

表5 CryptoPeriod屬性說(shuō)明

（6）CryptoTimeline

CryptoTimeline用來(lái)定義持續(xù)長(zhǎng)度的多個(gè)CryptoPeriod，相關(guān)描述見(jiàn)表6。

表6 CryptoTimeline屬性說(shuō)明

2.4 數(shù)據(jù)認(rèn)證

MPD文件提供獲取附加認(rèn)證數(shù)據(jù)（AAD）接口。認(rèn)證框架同內(nèi)容保護(hù)框架無(wú)關(guān)，即認(rèn)證可應(yīng)用在加密段，也可以應(yīng)用在不加密的段。如果認(rèn)證和加密同時(shí)進(jìn)行，則操作模式應(yīng)該是“認(rèn)證，然后加密”，這種方式可確保認(rèn)證獨(dú)立于加密，認(rèn)證數(shù)據(jù)不隨加密參數(shù)的改變而改變。

MPD中增加段認(rèn)證定義的步驟：

1）增加EssentialProperty或SupplementalProperty定義。其中EssentialProperty代表認(rèn)證是必選的，SupplementalProp?erty代表認(rèn)證可選。

2）EssentialProperty或SupplementalProperty中@schemeI?dUri的取值應(yīng)該為urn:mpeg:dash:sea:auth:2013。

3）EssentialProperty或SupplementalProperty中增加Con?tentAuthenticity元素。ContentAuthenticity中定義認(rèn)證算法，和用來(lái)下載認(rèn)證數(shù)據(jù)的URL模板。

DASH支持的認(rèn)證算法包括SHA-256和HMAC-SHA1，見(jiàn)表7。

表7 DASH支持的認(rèn)證算法

3 ISO媒體內(nèi)容通用加密方法（CENC）

3.1 CENC概述

通用加密格式CENC是基于ISO/IEC 14496-12的一種加密格式，CENC加密標(biāo)準(zhǔn)在ISO 23001-7及補(bǔ)充文檔ISO 23001-7 Amendment1中描述[3-4]。

3.2 加密機(jī)制

CENC加密對(duì)sample entry做如下替換：

1）在每個(gè)track中添加Protection Scheme Information Box('sinf')，標(biāo)識(shí)內(nèi)容為加密內(nèi)容。

2）Protection SchemeInformation Box('sinf')中 包 含Scheme Type Box('schm')：定義相應(yīng)的加密算法，其中scheme_type定義了加密類(lèi)型，scheme_version定義模式版本。CENC加密方式中，模式類(lèi)型為scheme_type='cenc'，CENC采用AES-CTR算法加密；模式版本為scheme_version= 0x00010000。

3）Protection Scheme Information Box('sinf')中應(yīng)包含Scheme Information Box('schi')。

4）Scheme Information Box('schi')中包含Track Encryp?tion Box('tenc')，描述該track的加密參數(shù)。

CENC通用加密格式定義的相關(guān)參數(shù)包含在如下box中：

1）內(nèi)容保護(hù)系統(tǒng)的方案相關(guān)信息，例如許可證和授權(quán)獲取信息，包含在ProtectionSystemSpecificHeaderBox('pssh')中。

2）用于每個(gè)track的加密參數(shù)（包括KID、初始化向量、加密標(biāo)志位），包含在TrackEncryptionBox('tenc')中。

3）用于samples groups的加密參數(shù)（包括KID、初始化向量、加密標(biāo)志位）包含在SampleGroupDescriptionBox('sgpd')中。

4）單獨(dú)sample的加密參數(shù)（包括初始化向量，sub sample加密數(shù)據(jù)）包含在樣本附加信息中，由SampleAuxiliaryInfor?mationSizesBox ('saiz')和 SampleAuxiliaryInformationOffsets?Box('saio')引用。

3.3 加密方式

CENC定義了兩種加密方式：全樣本加密和子樣本加密。全樣本加密把整個(gè)sample作為一個(gè)完整的單元加密；子樣本加密中的sample分為一個(gè)或多個(gè)subsample，每一個(gè)sub?sample都由不加密區(qū)域和加密區(qū)域交替組成，Sample中的所有加密區(qū)域被看作一個(gè)邏輯上連續(xù)的塊，計(jì)數(shù)器值的增加與切換NAL單元無(wú)關(guān)。

3.4 box定義

1）Protection System Specific Header Box('pssh')

Protection System Specific Header Box('pssh')包含內(nèi)容保護(hù)系統(tǒng)，回放內(nèi)容必要的信息。封裝在數(shù)據(jù)域中的信息可以提供解密密鑰獲取方式，對(duì)基于許可證授權(quán)的內(nèi)容保護(hù)系統(tǒng)，信息頭包括許可證服務(wù)器或授權(quán)中心的URL信息和嵌入的許可證等。通過(guò)為每個(gè)DRM系統(tǒng)分配一個(gè)“pssh”，CENC能夠支持一份媒體文件被多個(gè)密鑰和多個(gè)DRM系統(tǒng)播放。

ProtectionSystemSpecificHeaderBox('pssh')的語(yǔ)法如下：

aligned(8)class ProtectionSystemSpecificHeaderBox extends Full?Box('pssh'，version=0，flags=0)

{

unsigned int(8)[16]SystemID;

unsigned int(32)DataSize;

unsigned int(8)[DataSize]Data;

}

SystemID：UUID，唯一標(biāo)識(shí)對(duì)應(yīng)的內(nèi)容保護(hù)系統(tǒng)。GY/T 277—2014中規(guī)定，將16 byte長(zhǎng)度的SystemID的前8 byte設(shè)置為“ChinaDRM”，后8 byte保留為0x00。

DataSize：數(shù)據(jù)域的長(zhǎng)度，以字節(jié)為單位。

Data：存儲(chǔ)內(nèi)容保護(hù)系統(tǒng)的特定數(shù)據(jù)，例如許可證服務(wù)器的URL地址等。

2）Track Encryption Box('tenc')

Track Encryption Box包含整個(gè)track的IsEncrypted flag、IV_size以及KID，這3個(gè)參數(shù)作為track中的sample的加密參數(shù)。對(duì)于每個(gè)track只有一個(gè)密鑰的文件，Track Encryption Box允許基礎(chǔ)加密參數(shù)在每個(gè)track定義一次，而不需要在每個(gè)sample做重復(fù)定義。

Track Encryption Box('tenc')的語(yǔ)法如下：

aligned(8)class TrackEncryptionBox extends FullBox('tenc'，ver?sion=0，flags=0)

{

unsigned int(24)default_IsEncrypted;

unsigned int(8)default_IV_size;

unsigned int(8)[16]default_KID;}

default_IsEncypted：加密標(biāo)志位，標(biāo)識(shí)track中samples的默認(rèn)加密狀態(tài)，可以包含如下取值，0x0表示沒(méi)有加密，0x1表示采用AES_CTR 128加密。

GY/T 277—2014中將此項(xiàng)擴(kuò)展為[5]：采用AES_CTR加密時(shí)，保護(hù)模式信息盒(sinf)中的模式類(lèi)型盒(schm)中的模式類(lèi)型scheme_type=‘cenc’；采用AES_CBC加密時(shí)，保護(hù)模式信息盒(sinf)中的模式類(lèi)型盒(schm)中的模式類(lèi)型scheme_type= 'cbc1'；采用SM4_CTR加密時(shí)，保護(hù)模式信息盒(sinf)中的模式類(lèi)型盒(schm)中的模式類(lèi)型 scheme_type='sm41'；采用SM4_CBC加密時(shí)，保護(hù)模式信息盒(sinf)中的模式類(lèi)型盒(schm)中的模式類(lèi)型 scheme_type='sm42'；取 0x000002～0xFFFFFF表示保留。

default_IV_size：默認(rèn)初始化向量的size，字節(jié)為單位，0表示IsEncrypted取值為0x0時(shí)，沒(méi)有加密，8:64或16:128位初始化向量。

default_KID：track中所有sampls的默認(rèn)加密密鑰標(biāo)識(shí)，允許每個(gè)文件或track有多個(gè)加密密鑰。

加密track中的非加密sample將做如下取值：IsEncrypt?ed=0x0，IV_size=0x0，KID=0x0。

4 HLS中的內(nèi)容加密

4.1 HLS概述

HLS是Apple公司推出的動(dòng)態(tài)碼率自適應(yīng)技術(shù)，HLS內(nèi)容格式在HTTP Live Streaming draft-pantos-http-live-stream?ing-10中描述[6]。

4.2 加密方式

HTTP Live Streaming中內(nèi)容加密有兩種，一種是對(duì)TS切片文件直接加密；另一種是對(duì)H.264編碼文件中類(lèi)型為1和5的NAL單元進(jìn)行加密，其他類(lèi)型的NAL單元不加密。

4.3 加密機(jī)制

HLS中媒體分塊如果是加密的，其加密密鑰通過(guò)M3U8文件中的#EXT-X-KEY來(lái)指定，密鑰文件由客戶端從服務(wù)器請(qǐng)求認(rèn)證獲得。一個(gè)播放列表可以有一個(gè)以上的#EXT-X-KEY，同一個(gè)媒體段也可以有多個(gè)不同KEYFOR?MAT屬性值的#EXT-X-KEY。如果播放列表僅有一個(gè)#EXT-X-KEY，則密鑰文件的生命期從當(dāng)前#EXT-X-KEY開(kāi)始到播放列表結(jié)束；如果播放列表有兩個(gè)或以上的#EXT-X-KEY，則密鑰文件的生命期從當(dāng)前#EXT-X-KEY開(kāi)始到下一個(gè)#EXT-X-KEY結(jié)束。客戶端每次申請(qǐng)密鑰文件都會(huì)發(fā)起一個(gè)新的HTTP請(qǐng)求，設(shè)置過(guò)多的#EXT-X-KEY會(huì)增加授權(quán)服務(wù)器的負(fù)擔(dān)。

#EXT-X-KEY的格式如下：

#EXT-X-KEY:＜attribute-list＞

屬性包括METHOD，URI，IV，KEYFORMAT和KEYFOR?MATVERSIONS，屬性說(shuō)明見(jiàn)表8。

表8 屬性說(shuō)明

METHOD屬性為NONE時(shí)，表示媒體內(nèi)容未加密，這種情況下不允許出現(xiàn)URI，IV，KEYFORMAT，KEYFORMAT?VERSIONS等屬性。

METHOD屬性為AES-128時(shí)，表示媒體內(nèi)容采用AES-128方式對(duì)TS切片文件直接加密，這種情況下URI屬性必須出現(xiàn)，IV屬性可以出現(xiàn)也可以不出現(xiàn)。

METHOD屬性為SAMPLE-AES時(shí)，表示對(duì)媒體段的部分或全部ES流加密，ES可以為音頻、視頻或其他樣本，每一種ES的具體加密方式依賴于媒體編碼，這種情況下IV屬性可以出現(xiàn)也可以不出現(xiàn)。

IV為十六進(jìn)制整數(shù)，代表加密初始向量。采用AES-128方式加密時(shí)，如果IV屬性存在，則必須使用IV作為初始向量實(shí)現(xiàn)加密；如果IV屬性不存在，使用媒體段的序列碼作為初始向量實(shí)現(xiàn)加密。

KEYFORMAT標(biāo)識(shí)密鑰在密鑰文件中的存儲(chǔ)方式。默認(rèn)是“identity”。GY/T 277—2014中增加擴(kuò)展，如果KEY?FORMAT='chinadrm'，表示URI中給出的ChinaDRM規(guī)定的獲取許可證的相關(guān)信息，包括許可證服務(wù)器地址和內(nèi)容標(biāo)識(shí)。

1）TS層加密

如果屬性METHOD的值為AES-128，并且播放列表中包含#EXT-X-I-FRAMES-ONLY標(biāo)簽（只包含I幀流），則整個(gè)媒體段使用AES-128 CBC加密。

如果屬性METHOD的值為AES-128，并且播放列表中不包含#EXT-X-I-FRAMES-ONLY標(biāo)簽，則CBC不能跨越媒體段，每個(gè)媒體段單獨(dú)使用AES-128 CBC加密，從而實(shí)現(xiàn)整個(gè)媒體段全部?jī)?nèi)容的加密。

上述的兩種加密方式，對(duì)TS切片文件直接加密，這種加密方式在切片時(shí)實(shí)現(xiàn)，需要在網(wǎng)絡(luò)電視臺(tái)及CDN系統(tǒng)編碼器中集成加密功能，實(shí)施復(fù)雜度大，成本高。

2）ES流加密

METHOD屬性為SAMPLE-AES時(shí)，表示媒體在內(nèi)容打包封裝之前對(duì)ES流加密。ES層的加密對(duì)每個(gè)包含16 byte整數(shù)倍的數(shù)據(jù)塊以AES-128 CBC方式加密。對(duì)于視頻數(shù)據(jù)，媒體段從第一個(gè)16 byte數(shù)據(jù)塊開(kāi)始，每間隔10的整倍數(shù)的16 byte的數(shù)據(jù)塊加密（即1，16，26，…），對(duì)于音頻數(shù)據(jù)，所有的16 byte數(shù)據(jù)塊都必須加密。

SAMPLE-AES加密方式加密后的ES流不受上層封裝及切片的影響，因此可以在不影響網(wǎng)絡(luò)電視臺(tái)現(xiàn)有系統(tǒng)及CDN部署的情況下實(shí)現(xiàn)對(duì)視頻內(nèi)容的加密，滿足網(wǎng)絡(luò)電視臺(tái)等對(duì)視頻內(nèi)容保護(hù)的要求。

（1）視頻流的加密

ES類(lèi)型為視頻流時(shí)，H.264編碼文件中類(lèi)型為1和5的NAL單元必須加密，其他類(lèi)型的NAL單元不加密，加密NAL單元的數(shù)據(jù)格式如下：

Encrypted_NAL-Unit(){

NAL_unit_type_byte //1 byte

unencrypted_leader //31 bytes

while(bytes_remaining()＞16){

protected_block_one_in_ten //16 bytes

}

unencrypted_trailer //1-16 bytes

}

加密的NAL單元需要增加預(yù)防二義性的前綴，該前綴是未加密的。NAL單元中第1個(gè)字節(jié)的NAL_unit_type和隨后的31個(gè)字節(jié)是不加密的，其后是加密的數(shù)據(jù)段，數(shù)據(jù)段的長(zhǎng)度必須是16的整數(shù)倍（因此長(zhǎng)度小于48 byte的NAL單元是不被加密的），被保護(hù)的數(shù)據(jù)段采用10%跳躍加密，即每16 byte的加密數(shù)據(jù)塊，跟隨9個(gè)16 byte不加密的數(shù)據(jù)塊，以此類(lèi)推。加密H.264流時(shí)，類(lèi)型為1或5并且長(zhǎng)度大于48 byte的NAL單元必須基于上述方式加密，加密完成后為這些加密單元加上前綴碼；解密H.264流時(shí)，類(lèi)型為1和5，且長(zhǎng)度大于48 byte的NAL單元需要解密，首先移除前綴碼，然后按上述方式定位加密數(shù)據(jù)并解密。

（2）音頻流的加密

ES類(lèi)型為AAC音頻幀時(shí)，包含ADTS頭的音頻幀為加密幀。AAC的加密幀不需要增加預(yù)防二義性的前綴，AAC幀中7～9 byte的ADTS頭，以及之后的首個(gè)16 byte不加密，其后是加密數(shù)據(jù)段，加密數(shù)據(jù)段的長(zhǎng)度應(yīng)該為16的整數(shù)倍，余下的0～15 byte不加密。AAC音頻數(shù)據(jù)加密格式如下：

Encrypted_AAC_Frame(){

ADTS_Header //7 byte or 9 byte

unencrypted_leader //16 byte

while(bytes_remaining()＞=16){

protected_block //16 byte

}

unencrypted_trailer //0～15 byte

}

ES類(lèi)型為AC-3音頻幀時(shí)，全部的音頻幀都加密。AC-3的加密幀不需要增加預(yù)防二義性的前綴，AC-3幀中的首個(gè)16 byte不加密，其后是加密數(shù)據(jù)段，加密數(shù)據(jù)段的長(zhǎng)度應(yīng)該為16的整數(shù)倍，余下的0～15 byte不加密。AC-3數(shù)據(jù)加密格式如下：

Encrypted_AC3_Frame(){

unencrypted_leader //16 byte

while(bytes_remaining()＞=16){

protected_block //16 byte

}

unencrypted_trailer //0～15 byte

}

5 視頻加密方案

提出的視頻內(nèi)容加密方案是在NAL單元層對(duì)視頻內(nèi)容進(jìn)行加密。H.264編碼的視頻流是由連續(xù)的NAL單元組成。每個(gè)NAL單元包含標(biāo)志位表示該NAL單元數(shù)據(jù)類(lèi)型，常見(jiàn)的NAL單元數(shù)據(jù)類(lèi)型見(jiàn)表9。

表9 NAL單元類(lèi)型

選擇NAL類(lèi)型為1和5的幀進(jìn)行加密，加密后重新封裝為新的NAL單元，其余NAL單元保持不變，如圖3所示。

圖3 基于NAL層的加密方案

加密后NAL單元描述為：

aligned(8)class CrypNAL{

bit(1)forbidden_zero_bit;

bit(2)NAL_ref_idc;bit(5)NAL_unit_type;

unsigned int(8*IV_length)IV;

unsigned int(8*key_indicator_length)key_indicator;

unsigned int(8)data[];

}

forbidden_zero_bit：長(zhǎng)度為1 bit，定義為0；H.264規(guī)范聲明為1時(shí)說(shuō)明有比特流錯(cuò)誤或?yàn)殄e(cuò)誤語(yǔ)法。

NAL_ref_idc：長(zhǎng)度為2 bit；00表示該NALU不是用來(lái)構(gòu)造I幀預(yù)測(cè)的參考幀，這種NALU可以丟棄而不影響參考幀的完整性；非00用來(lái)保持參考幀的完整性。

NAL_unit_type：長(zhǎng)度為5 bit；加密后的NAL單元類(lèi)型采用自定義的值，加密前 NAL_unit_type=1，則加密后NAL_unit_type=25；加密前 NAL_unit_type=5，則加密后NAL_unit_type=26。

IV：為初始向量，在AES-128 CTR模式[114-115]下，該值用來(lái)計(jì)算counter的值。

Key_indicator：內(nèi)容加密密鑰標(biāo)示，用以標(biāo)示該NAL單元由哪個(gè)內(nèi)容加密密鑰進(jìn)行加密。

6 總結(jié)

互聯(lián)網(wǎng)視頻服務(wù)的開(kāi)展，亟需有效的數(shù)字版權(quán)管理技術(shù)支撐，保護(hù)運(yùn)營(yíng)各方的合法權(quán)益，保障互聯(lián)網(wǎng)視頻服務(wù)運(yùn)營(yíng)的可管可控。內(nèi)容加密封裝是互聯(lián)網(wǎng)視頻內(nèi)容版權(quán)保護(hù)的關(guān)鍵技術(shù)之一，本文研究了主流互聯(lián)網(wǎng)視頻格式的內(nèi)容加密封裝技術(shù)，并在此基礎(chǔ)上提出適應(yīng)多碼率、多格式、多切片加密封裝需求的內(nèi)容加密方案，為開(kāi)展多元化、靈活的互聯(lián)網(wǎng)視頻服務(wù)提供有效的技術(shù)支撐。

[1] Internet-draft，HTTP live streaming:draft-pantos-http-live-strea ming[S].2012.

[2]GY/T 277—2014，互聯(lián)網(wǎng)電視數(shù)字版權(quán)管理技術(shù)規(guī)范[S].2014.

[3]ISO 14496-12，信息技術(shù)——音視頻對(duì)象編碼第12部分：ISO基礎(chǔ)媒體文件格式[S].2005.

[5]ISO 23001-7，信息技術(shù)——MPEG系統(tǒng)技術(shù)第7部分：ISO基本媒體文件格式文件通用加密[S].2012.

[6]ISO 23009-1，信息技術(shù)——基于HTTP的動(dòng)態(tài)自適應(yīng)流媒體（DASH）第1部分：媒體展現(xiàn)描述與分段格式[S].2012.

[7]ISO 23009-4信息技術(shù)——基于HTTP的動(dòng)態(tài)自適應(yīng)流媒體（DASH）第4部分：分段加密與認(rèn)證[S].2013.

責(zé)任編輯：許 盈

Research on Content Encryption

GUO Xiaoxia，WANG Lei，SHEN Yang
（Academy of Broadcasting Science,SARFT，Beijing 100866，China）

Content encryption package is one of the key technology of digital rights management for Internet TV The encryption method for mainstream internet video is studied,an encryption scheme is proposd based on NAL layer, technical support of video content protection for internet video provider is provided.

content encryption；DRM；Internet TV；HLS；MPEG-DASH；CENC

TP37

B

10.16280/j.videoe.2015.08.007

2014-09-23

【本文獻(xiàn)信息】郭曉霞，王磊，沈陽(yáng).視頻內(nèi)容加密封裝技術(shù)研究[J].電視技術(shù)，2015，39（8）.