郭曉霞，王 磊，沈 陽

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

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

郭曉霞，王 磊，沈 陽

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

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

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

目前，采用基于HTTP的動態(tài)自適應(yīng)流媒體技術(shù)面向智能手機(jī)、平板電腦、智能電視機(jī)頂盒以及PC等提供多屏互動的視頻服務(wù)已經(jīng)成為互聯(lián)網(wǎng)視頻服務(wù)的主流模式?；ヂ?lián)網(wǎng)視頻服務(wù)的廣泛開展，亟需有效的技術(shù)手段抑制網(wǎng)絡(luò)視頻盜版問題，保障互聯(lián)網(wǎng)視頻服務(wù)運(yùn)營可管可控。內(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)識及獲取許可證所必須的信息。根據(jù)不同的應(yīng)用場景，需要定義不同的加密內(nèi)容封裝格式，目前主流的加密封裝格式包括基于ISO基礎(chǔ)媒體文件格式的通用加密格式（CENC）、基于HTTP動態(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共同開發(fā)的視頻處理標(biāo)準(zhǔn)，ITU-T作為標(biāo)準(zhǔn)建議H.264，ISO/IEC作為國際標(biāo)準(zhǔn)14496-10（MPEG-4第10部分）高級視頻編碼（AVC）。H.264的算法在概念上可以分為兩層：視頻編碼層（Video Coding Layer，VCL）和網(wǎng)絡(luò)提取層（Network Abstraction Layer，NAL），NAL層為視頻內(nèi)容提供了與網(wǎng)絡(luò)無關(guān)的統(tǒng)一接口，支持多種網(wǎng)絡(luò)情況下的傳輸。

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

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

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

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

2 DASH加密

2.1 DASH概述

基于HTTP的動態(tài)自適應(yīng)流媒體DASH以媒體流模式提交媒體內(nèi)容，其控制只依賴于客戶端?？蛻舳送ㄟ^HTTP協(xié)議從標(biāo)準(zhǔn)的Web服務(wù)器請求數(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ú)或多個時間上連續(xù)的媒體內(nèi)容時期（periods）組成。

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

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

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

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

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

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

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

1）加密方式

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

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

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

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

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

2）段加密

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

內(nèi)容加密方法定義：通過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信息。

許可證獲?。簩τ诨谠S可證的內(nèi)容保護(hù)系統(tǒng)，通過Li?cense元素可獲取許可證URL，DASH支持相同內(nèi)容的多個內(nèi)容保護(hù)系統(tǒng)加密。

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

3）命名空間定義

MPD文件的開始處增加命名空間定義。內(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)信息通過ContentProtection來指定，相關(guān)描述見表1。DASH中Content?Protection的@schemeIdUri屬性應(yīng)為urn:mpeg:dash:sea:enc: 2013。

表1 ContentProtection屬性說明

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

（2）SegmentEncryption

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

表2 SegmentEncryption屬性說明

（3）License

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

表3 License屬性說明

（4）CryptoPeriod通用屬性

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

表4 CryptoPeriod通用屬性說明

（5）CryptoPeriod

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

表5 CryptoPeriod屬性說明

（6）CryptoTimeline

CryptoTimeline用來定義持續(xù)長度的多個CryptoPeriod，相關(guān)描述見表6。

表6 CryptoTimeline屬性說明

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

MPD文件提供獲取附加認(rèn)證數(shù)據(jù)（AAD）接口。認(rèn)證框架同內(nèi)容保護(hù)框架無關(guān)，即認(rèn)證可應(yīng)用在加密段，也可以應(yīng)用在不加密的段。如果認(rèn)證和加密同時進(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)證算法，和用來下載認(rèn)證數(shù)據(jù)的URL模板。

DASH支持的認(rèn)證算法包括SHA-256和HMAC-SHA1，見表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加密對sample entry做如下替換：

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

2）Protection SchemeInformation Box('sinf')中 包 含Scheme Type Box('schm')：定義相應(yīng)的加密算法，其中scheme_type定義了加密類型，scheme_version定義模式版本。CENC加密方式中，模式類型為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）用于每個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定義了兩種加密方式：全樣本加密和子樣本加密。全樣本加密把整個sample作為一個完整的單元加密；子樣本加密中的sample分為一個或多個subsample，每一個sub?sample都由不加密區(qū)域和加密區(qū)域交替組成，Sample中的所有加密區(qū)域被看作一個邏輯上連續(xù)的塊，計數(shù)器值的增加與切換NAL單元無關(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ù)域中的信息可以提供解密密鑰獲取方式，對基于許可證授權(quán)的內(nèi)容保護(hù)系統(tǒng)，信息頭包括許可證服務(wù)器或授權(quán)中心的URL信息和嵌入的許可證等。通過為每個DRM系統(tǒng)分配一個“pssh”，CENC能夠支持一份媒體文件被多個密鑰和多個DRM系統(tǒng)播放。

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

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)識對應(yīng)的內(nèi)容保護(hù)系統(tǒng)。GY/T 277—2014中規(guī)定，將16 byte長度的SystemID的前8 byte設(shè)置為“ChinaDRM”，后8 byte保留為0x00。

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

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

2）Track Encryption Box('tenc')

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

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

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)識track中samples的默認(rèn)加密狀態(tài)，可以包含如下取值，0x0表示沒有加密，0x1表示采用AES_CTR 128加密。

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

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

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

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

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

4.1 HLS概述

HLS是Apple公司推出的動態(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)容加密有兩種，一種是對TS切片文件直接加密；另一種是對H.264編碼文件中類型為1和5的NAL單元進(jìn)行加密，其他類型的NAL單元不加密。

4.3 加密機(jī)制

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

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

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

屬性包括METHOD，URI，IV，KEYFORMAT和KEYFOR?MATVERSIONS，屬性說明見表8。

表8 屬性說明

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

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

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

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

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

1）TS層加密

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

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

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

2）ES流加密

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

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

（1）視頻流的加密

ES類型為視頻流時，H.264編碼文件中類型為1和5的NAL單元必須加密，其他類型的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個字節(jié)的NAL_unit_type和隨后的31個字節(jié)是不加密的，其后是加密的數(shù)據(jù)段，數(shù)據(jù)段的長度必須是16的整數(shù)倍（因此長度小于48 byte的NAL單元是不被加密的），被保護(hù)的數(shù)據(jù)段采用10%跳躍加密，即每16 byte的加密數(shù)據(jù)塊，跟隨9個16 byte不加密的數(shù)據(jù)塊，以此類推。加密H.264流時，類型為1或5并且長度大于48 byte的NAL單元必須基于上述方式加密，加密完成后為這些加密單元加上前綴碼；解密H.264流時，類型為1和5，且長度大于48 byte的NAL單元需要解密，首先移除前綴碼，然后按上述方式定位加密數(shù)據(jù)并解密。

（2）音頻流的加密

ES類型為AAC音頻幀時，包含ADTS頭的音頻幀為加密幀。AAC的加密幀不需要增加預(yù)防二義性的前綴，AAC幀中7～9 byte的ADTS頭，以及之后的首個16 byte不加密，其后是加密數(shù)據(jù)段，加密數(shù)據(jù)段的長度應(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類型為AC-3音頻幀時，全部的音頻幀都加密。AC-3的加密幀不需要增加預(yù)防二義性的前綴，AC-3幀中的首個16 byte不加密，其后是加密數(shù)據(jù)段，加密數(shù)據(jù)段的長度應(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單元層對視頻內(nèi)容進(jìn)行加密。H.264編碼的視頻流是由連續(xù)的NAL單元組成。每個NAL單元包含標(biāo)志位表示該NAL單元數(shù)據(jù)類型，常見的NAL單元數(shù)據(jù)類型見表9。

表9 NAL單元類型

選擇NAL類型為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：長度為1 bit，定義為0；H.264規(guī)范聲明為1時說明有比特流錯誤或為錯誤語法。

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

NAL_unit_type：長度為5 bit；加密后的NAL單元類型采用自定義的值，加密前 NAL_unit_type=1，則加密后NAL_unit_type=25；加密前 NAL_unit_type=5，則加密后NAL_unit_type=26。

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

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

6 總結(jié)

互聯(lián)網(wǎng)視頻服務(wù)的開展，亟需有效的數(shù)字版權(quán)管理技術(shù)支撐，保護(hù)運(yùn)營各方的合法權(quán)益，保障互聯(lián)網(wǎng)視頻服務(wù)運(yùn)營的可管可控。內(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)容加密方案，為開展多元化、靈活的互聯(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ù)——音視頻對象編碼第12部分：ISO基礎(chǔ)媒體文件格式[S].2005.

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

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

[7]ISO 23009-4信息技術(shù)——基于HTTP的動態(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)信息】郭曉霞，王磊，沈陽.視頻內(nèi)容加密封裝技術(shù)研究[J].電視技術(shù)，2015，39（8）.