新型通用格式多媒體數(shù)字版權(quán)管理系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

黃勤龍，馬兆豐，莫佳，鈕心忻，楊義先

（1. 北京郵電大學(xué) 信息安全中心，北京 100876；2. 北京國(guó)泰信安科技有限公司，北京 100876；3. 電子科技大學(xué) 計(jì)算機(jī)科學(xué)與工程學(xué)院，四川 成都 611731）

1 引言

隨著 Internet技術(shù)的快速發(fā)展，數(shù)字多媒體內(nèi)容的分發(fā)、復(fù)制和編輯變得越來(lái)越普遍，移動(dòng)互聯(lián)網(wǎng)的飛速發(fā)展使得多媒體內(nèi)容的制作、分享和下載越來(lái)越簡(jiǎn)單，由此帶來(lái)的大量多媒體內(nèi)容盜鏈、盜版以及不規(guī)范使用行為對(duì)數(shù)字媒體產(chǎn)業(yè)造成巨大的沖擊。數(shù)字多媒體內(nèi)容的非法復(fù)制和傳播損害了版權(quán)所有人和內(nèi)容運(yùn)營(yíng)商的合法權(quán)益，如何防止數(shù)字多媒體內(nèi)容的非法復(fù)制與擴(kuò)散，保護(hù)多媒體內(nèi)容的版權(quán)是數(shù)字內(nèi)容產(chǎn)業(yè)發(fā)展所面臨的關(guān)鍵問題，數(shù)字版權(quán)管理技術(shù)正是為了解決這一關(guān)鍵問題而產(chǎn)生的。

數(shù)字版權(quán)管理（DRM，digital rights management）是通過數(shù)字內(nèi)容的制作、發(fā)行、安全許可和計(jì)費(fèi)等一系列手段防止數(shù)字內(nèi)容的非法誤用，確保數(shù)字內(nèi)容在公平、合理、安全許可框架下的條件使用和消費(fèi)[1]。

2 相關(guān)工作

隨著DRM技術(shù)的應(yīng)用越來(lái)越廣泛，學(xué)術(shù)界和工業(yè)界進(jìn)行了大量的研究和實(shí)踐[2～11]。

馬兆豐等人提出了一種新的支持時(shí)空約束的數(shù)字版權(quán)管理安全許可協(xié)議[2]，將內(nèi)容對(duì)象與版權(quán)對(duì)象相分離，通過內(nèi)容加密密鑰 CEK保護(hù)數(shù)字內(nèi)容本身，在用戶與許可證中心之間采用動(dòng)態(tài)實(shí)時(shí)密鑰協(xié)商算法實(shí)現(xiàn)雙向認(rèn)證和動(dòng)態(tài)許可申請(qǐng)。

針對(duì)P2P網(wǎng)絡(luò)，Jung-Shian Li等人提出了一個(gè)新的端對(duì)端音樂內(nèi)容分發(fā)的 DRM 框架[8]，內(nèi)容分發(fā)的頑健性通過使用基于拉格朗日插值法的網(wǎng)絡(luò)編碼方法來(lái)實(shí)現(xiàn)，不會(huì)對(duì)音頻質(zhì)量產(chǎn)生影響，但該框架分發(fā)到用戶的內(nèi)容將不受控制。針對(duì)IPTV內(nèi)容，Boseung Kim等人提出了一種采用幀加密的內(nèi)容保護(hù)的方法[9]，該方法使用一種干擾加密方法，即使用散列函數(shù)而不是復(fù)雜的加密過程，通過改變像素值來(lái)重新排列每幀的圖像，從而實(shí)現(xiàn)簡(jiǎn)單而又比較有效的IPTV內(nèi)容保護(hù)，然而該方法安全性較低，缺少密鑰管理和許可證管理。Yeonjeong Jeong等人提出了一種在不同音頻DRM系統(tǒng)之間可以互相轉(zhuǎn)換的方法[10]，目前音頻內(nèi)容受多種DRM系統(tǒng)，每個(gè)采用不同的DRM技術(shù)，DRM內(nèi)容也不相同，該方法使得已經(jīng)受DRM保護(hù)的音頻內(nèi)容可以在其他DRM兼容的設(shè)備上使用，但該方法適用范圍有限。鐘勇等人提出了一種面向DRM的責(zé)任授權(quán)模型及其實(shí)施框架[11]，該模型基于分布式時(shí)態(tài)邏輯和Active-U-Datalog語(yǔ)法規(guī)則，具有表達(dá)事件驅(qū)動(dòng)、事件驅(qū)動(dòng)和責(zé)任補(bǔ)償?shù)雀鞣N責(zé)任授權(quán)的語(yǔ)義能力，具有良好的可實(shí)施性，提高了DRM系統(tǒng)對(duì)數(shù)據(jù)使用控制的靈活性和能力。

工業(yè)界目前有多種 DRM 解決方案，如 OMA DRM[12]、Marlin DRM[13]、蘋果的 FairPlay 系統(tǒng)[14]、微軟的Media DRM系統(tǒng)[15]和Adobe 的Flash Access系統(tǒng)[16]等，推動(dòng)了DRM的發(fā)展和應(yīng)用，但OMA DRM 不支持版權(quán)對(duì)象[17]的重新發(fā)行，F(xiàn)airPlay、Media DRM和Flash Access等均只支持有限的幾種格式。

現(xiàn)有針對(duì)多媒體內(nèi)容的DRM系統(tǒng)存在如下一些問題和局限性。

1) 現(xiàn)有基于內(nèi)容格式加密或者幀結(jié)構(gòu)加密的多媒體DRM系統(tǒng)，其加密過程復(fù)雜，內(nèi)容解密播放時(shí)處理性能較低，如Boseung Kim等人[9]提出的一種干擾的幀加密方法，其加密速率比采用 AES算法的非結(jié)構(gòu)化加密方法要低。

2) 現(xiàn)有的音視頻等多媒體DRM系統(tǒng)，多與音視頻的格式相關(guān)，一般只支持少數(shù)的幾種視頻格式，如微軟的Media DRM[15]只支持WMV、WMA和ASF 3種格式，Adobe的Flash Access[16]只支持FLV和F4V 2種格式，目前，DRM系統(tǒng)未能支持通用格式的多媒體，不同格式之間的多媒體無(wú)法統(tǒng)一訂購(gòu)和使用，無(wú)法滿足不同內(nèi)容提供商提供的不同多媒體內(nèi)容保護(hù)需求。

3) 現(xiàn)有的多媒體 DRM 系統(tǒng)存在權(quán)利許可無(wú)法重新發(fā)行或者轉(zhuǎn)讓的不足，當(dāng)權(quán)利許可丟失或損壞時(shí)，用戶無(wú)法繼續(xù)使用版權(quán)內(nèi)容，如OMA DRM，同時(shí)用戶也不能將自己購(gòu)買的權(quán)利許可轉(zhuǎn)讓給他人，如微軟的Media DRM和Adobe 的Flash Access等。

因此，本文在支持時(shí)空約束的數(shù)字版權(quán)管理安全許可協(xié)議[2]的基礎(chǔ)上，廣泛參考國(guó)內(nèi)外 DRM 標(biāo)準(zhǔn)和規(guī)范，綜合考慮現(xiàn)有DRM系統(tǒng)存在的問題以及多媒體內(nèi)容消費(fèi)的需求，設(shè)計(jì)了一種新型通用格式多媒體數(shù)字版權(quán)管理模型（CPSec media DRM,content protection security），該模型通過非結(jié)構(gòu)化加密方法，不依賴多媒體內(nèi)容格式，支持通用格式多媒體內(nèi)容。另外，為了解決許可證重新發(fā)行和轉(zhuǎn)讓的問題，采用許可證提取碼作為下載許可證的憑證，并支持細(xì)粒度使用控制[18]方式。

在此模型的基礎(chǔ)上，本文實(shí)現(xiàn)了基于固定與移動(dòng)融合（FMC，fixed mobile convergence）[19]業(yè)務(wù)的多媒體數(shù)字版權(quán)管理系統(tǒng)，該系統(tǒng)與運(yùn)營(yíng)商業(yè)務(wù)平臺(tái)結(jié)合，綜合了內(nèi)容加密與打包、許可證管理與分發(fā)和DRM客戶端等重要功能，運(yùn)營(yíng)商在運(yùn)營(yíng)版權(quán)內(nèi)容的同時(shí)，保護(hù)內(nèi)容提供商的權(quán)益，同時(shí)用戶在訂購(gòu)獲取內(nèi)容并下載許可證后可以按需使用內(nèi)容。

3 CPSec Media DRM模型技術(shù)目標(biāo)

3.1 支持通用音視頻多媒體格式

為了支持不同業(yè)務(wù)，內(nèi)容平臺(tái)包含了大量不同格式的音視頻多媒體，包括H263、H264、MPEG-4、MPEG-2、MP3和AC3等，CPSec Media DRM設(shè)計(jì)時(shí)同時(shí)支持以上通用的音視頻格式和未來(lái)的新格式，支持不同內(nèi)容提供商提供的不同格式的版權(quán)內(nèi)容，為DRM系統(tǒng)的融合、流通和推廣奠定了基礎(chǔ)。

3.2 支持許可證重新發(fā)行和轉(zhuǎn)讓

為了解決許可證丟失無(wú)法使用內(nèi)容和許可證無(wú)法轉(zhuǎn)讓的問題，CPSec Media DRM系統(tǒng)設(shè)計(jì)了隨機(jī)的許可證提取碼，每個(gè)許可證對(duì)應(yīng)一個(gè)提取碼，用戶在 DRM 客戶端通過許可證提取碼下載許可證，并可將許可證提取碼轉(zhuǎn)讓給其他人，許可證丟失時(shí)可以重新通過許可證提取碼下載許可證。

3.3 支持細(xì)粒度使用控制方式

DRM 許可證描述了用戶使用內(nèi)容時(shí)的各項(xiàng)權(quán)利，CPSec Media DRM設(shè)計(jì)時(shí)支持細(xì)粒度使用控制方式，包括使用時(shí)間、使用次數(shù)、用戶綁定、設(shè)備綁定等，通過不同權(quán)利的動(dòng)態(tài)組合滿足試用、包月和贈(zèng)送等使用場(chǎng)景。

4 CPSec Media DRM模型設(shè)計(jì)方案

CPSec Media DRM 同消費(fèi)平臺(tái)和內(nèi)容平臺(tái)等進(jìn)行業(yè)務(wù)、內(nèi)容和用戶數(shù)據(jù)的交互，完成內(nèi)容的加密與打包，同時(shí)向用戶提供控制內(nèi)容使用的許可證。CPSec Media DRM功能架構(gòu)如圖1所示，包括內(nèi)容加密與打包系統(tǒng)、密鑰管理系統(tǒng)、安全引擎系統(tǒng)、許可證管理與分發(fā)系統(tǒng)、DRM客戶端和DRM管理系統(tǒng)等功能單元。

圖1 CPSec Media DRM模型

1) 內(nèi)容加密與打包系統(tǒng)

內(nèi)容加密與打包系統(tǒng)接收內(nèi)容平臺(tái)需要進(jìn)行DRM 保護(hù)的內(nèi)容，使用密鑰管理系統(tǒng)提供的內(nèi)容加密密鑰對(duì)內(nèi)容按照非結(jié)構(gòu)化加密方法進(jìn)行加密。內(nèi)容打包系統(tǒng)按照DRM系統(tǒng)相關(guān)規(guī)范對(duì)加密后的內(nèi)容打包，然后將受DRM保護(hù)的內(nèi)容傳送到內(nèi)容平臺(tái)，供用戶下載使用。

2) 密鑰管理系統(tǒng)

密鑰管理系統(tǒng)負(fù)責(zé)管理DRM系統(tǒng)中使用的各種密鑰，并維護(hù)媒體文件與內(nèi)容主控密鑰的映射關(guān)系。內(nèi)容加密系統(tǒng)從密鑰管理系統(tǒng)申請(qǐng)用于加密媒體文件的內(nèi)容主控密鑰；許可證管理與分發(fā)系統(tǒng)根據(jù)內(nèi)容標(biāo)識(shí)從密鑰管理系統(tǒng)申請(qǐng)對(duì)應(yīng)的內(nèi)容主控密鑰，以加密形式封裝到許可證中。

3) 安全引擎系統(tǒng)

安全引擎系統(tǒng)向密鑰管理系統(tǒng)提供以下服務(wù)：內(nèi)容及其主控密鑰的加解密、許可證的簽名與驗(yàn)證、生成內(nèi)容主控密鑰、對(duì)指定內(nèi)容計(jì)算散列值。

4) 許可證管理與分發(fā)系統(tǒng)

許可證管理與分發(fā)系統(tǒng)主要負(fù)責(zé)許可證的生成、分發(fā)和管理，包括許可證生成、許可證分發(fā)和許可證策略管理等模塊。許可證生成模塊接收業(yè)務(wù)系統(tǒng)的許可證創(chuàng)建請(qǐng)求，根據(jù)權(quán)利信息為用戶創(chuàng)建許可證，同時(shí)向密鑰管理系統(tǒng)申請(qǐng)相應(yīng)的內(nèi)容主控密鑰，以密文形式封裝到許可證；許可證分發(fā)模塊實(shí)現(xiàn)許可證的分發(fā)和下載功能；許可證策略管理模塊實(shí)現(xiàn)許可證策略的管理功能。

5) DRM客戶端

DRM 客戶端執(zhí)行與媒體文件使用相關(guān)的許可和約束，控制用戶對(duì)媒體文件的使用。用戶播放受DRM 保護(hù)的媒體文件時(shí)，如果終端沒有相應(yīng)的許可證，媒體播放器會(huì)提示用戶需要相應(yīng)的權(quán)限才能使用，并通過瀏覽器將用戶重定向到業(yè)務(wù)系統(tǒng)進(jìn)行訂購(gòu)，獲取許可證下載信息。DRM 客戶端獲取許可證后，利用內(nèi)容主控密鑰對(duì)媒體文件密文進(jìn)行解密，并根據(jù)許可證中的權(quán)利信息控制用戶對(duì)媒體文件的播放及使用。

6) DRM管理系統(tǒng)

DRM 管理系統(tǒng)負(fù)責(zé)內(nèi)容加密情況、許可證分發(fā)與使用情況的統(tǒng)計(jì)、分析工作。系統(tǒng)管理負(fù)責(zé)DRM系統(tǒng)角色管理、權(quán)限管理和工作狀態(tài)的檢測(cè)。

4.1 內(nèi)容加密與打包系統(tǒng)

4.1.1 內(nèi)容加密與打包格式

在CPSec Media DRM中，通用媒體文件加密后打包成CPSec Media DRM內(nèi)容格式（DCF），定義如下。

1) 媒體文件頭

媒體文件頭長(zhǎng)度為20字節(jié)。其中，預(yù)留4字節(jié)，即(‘CDRM’)；文件類型4字節(jié)；CPSec DCF整體標(biāo)記4字節(jié)；CPSec DCF規(guī)范版本標(biāo)識(shí)4字節(jié)；CPSec DCF兼容性標(biāo)記4字節(jié)。圖2是文件類型、標(biāo)記、版本與其他媒體文件內(nèi)容之間的關(guān)系。

圖2 CPSec DCF媒體頭格式

2) 媒體文件體

圖3是對(duì)媒體文件格式的全面描述。DCF文件體由若干個(gè)CPSec DCF容器組成，每個(gè)CPSec DCF容器只包含一個(gè)DCF頭和一個(gè)DRM內(nèi)容對(duì)象容器。

圖3 CPSec DCF整體格式

3) 非結(jié)構(gòu)化內(nèi)容加密

內(nèi)容加密與打包系統(tǒng)使用分組加密算法（如使用CBC模式或者CTR模式的AES算法）將不同格式媒體文件按照分塊加密，并按照 DCF整體格式打包。該方法克服了基于內(nèi)容格式加密方法的局限性，將媒體文件當(dāng)作整體分塊加密，不依賴于多媒體內(nèi)容的編碼格式，因此支持通用格式媒體文件的加密。

4.1.2 內(nèi)容加密與打包系統(tǒng)工作流程

內(nèi)容加密與打包系統(tǒng)接收到DRM管理系統(tǒng)或內(nèi)容平臺(tái)的媒體文件加密請(qǐng)求后，對(duì)需要加密的媒體文件按照非結(jié)構(gòu)化加密方法進(jìn)行加密，同時(shí)按照規(guī)定的 DCF對(duì)加密后的媒體文件進(jìn)行打包，內(nèi)容加密與打包系統(tǒng)參數(shù)如表1所示。

表1 內(nèi)容加密與打包系統(tǒng)參數(shù)

內(nèi)容加密與打包系統(tǒng)工作流程如圖4所示。

step1內(nèi)容加密與打包引擎獲取內(nèi)容主控密鑰CPK及內(nèi)容輔助密鑰CRK，安全引擎產(chǎn)生內(nèi)容加密密鑰CEK，該密鑰用于加密媒體內(nèi)容

CEK = ECPK(CRK)

step2內(nèi)容加密與打包引擎獲取加密和打包參數(shù)，包括AID和RID等。

step3內(nèi)容加密與打包引擎對(duì)CP提供的原始媒體文件進(jìn)行加密，并計(jì)算加密內(nèi)容散列值ECH。

ECD = ECEK(PCD, AID, RID)

ECH = Hash(ECD)

step4內(nèi)容加密與打包引擎對(duì)加密后的數(shù)據(jù)按照規(guī)定的DCF進(jìn)行打包，DCD即是受DRM保護(hù)的媒體內(nèi)容。

DCD = {CID || CRK || ECD}

step5所有加密打包過程的參數(shù)都保存到數(shù)據(jù)庫(kù)中，加密打包后的內(nèi)容DCD提供用戶使用。

圖4 內(nèi)容加密與打包系統(tǒng)工作流程

4.2 密鑰管理系統(tǒng)

密鑰管理系統(tǒng)負(fù)責(zé)內(nèi)容主控密鑰 CPK的生成和管理、加密后內(nèi)容散列值ECH的存儲(chǔ)和管理等，包括密鑰生成、密鑰分發(fā)、密鑰存儲(chǔ)和密鑰更新等。

密鑰管理系統(tǒng)參數(shù)如表2所示。

表2 密鑰管理系統(tǒng)參數(shù)

step1密鑰管理系統(tǒng)產(chǎn)生內(nèi)容主控密鑰CPK，并使用密鑰保護(hù)MK加密存儲(chǔ)在數(shù)據(jù)庫(kù)中

EPK = EMK(CPK)

step2接受內(nèi)容加密與打包系統(tǒng)的請(qǐng)求，使用密鑰保護(hù)密鑰MK解密存儲(chǔ)在數(shù)據(jù)庫(kù)中加密的內(nèi)容主控密鑰EPK，返回內(nèi)容主控密鑰CPK

CPK = DMK(EPK)

step3接受許可證管理與分發(fā)系統(tǒng)的請(qǐng)求，返回使用用戶的公鑰PUK加密的內(nèi)容主控密鑰CPK得到的UEK和內(nèi)容散列值ECH

4.3 安全引擎系統(tǒng)

安全引擎系統(tǒng)為密鑰管理系統(tǒng)提供安全計(jì)算，主要包括對(duì)稱加密算法、公鑰算法和散列算法等，并支持證書的操作。

4.4 許可證管理與分發(fā)系統(tǒng)

許可證管理與分發(fā)系統(tǒng)主要包括許可證生成和分發(fā)等功能。

1) 許可證生成

許可證生成模塊負(fù)責(zé)根據(jù)從業(yè)務(wù)平臺(tái)接收的訂購(gòu)信息和用戶許可證請(qǐng)求信息生成許可證。

2) 許可證分發(fā)

許可證分發(fā)模塊接收和響應(yīng) DRM 客戶端的許可證下載請(qǐng)求，將相應(yīng)的許可證分發(fā)到 DRM客戶端。

4.4.1 許可證生成流程

許可證管理與分發(fā)系統(tǒng)負(fù)責(zé)根據(jù)從業(yè)務(wù)平臺(tái)接收的訂購(gòu)信息，包括用戶標(biāo)識(shí)、內(nèi)容標(biāo)識(shí)以及權(quán)限信息等，生成許可證，并返回給業(yè)務(wù)平臺(tái)。許可證管理與分發(fā)系統(tǒng)參數(shù)如表3所示。

表3 許可證管理與分發(fā)系統(tǒng)參數(shù)

許可證管理與分發(fā)系統(tǒng)流程如圖5所示。

圖5 許可證生成流程

step1業(yè)務(wù)平臺(tái)處理用戶的訂購(gòu)請(qǐng)求，將訂購(gòu)信息（包括用戶標(biāo)識(shí)UID、內(nèi)容標(biāo)識(shí)CID和權(quán)限信息 REX等）發(fā)送到許可證管理與分發(fā)系統(tǒng)，許可證管理與分發(fā)系統(tǒng)創(chuàng)建該許可證信息。

step2許可證管理與分發(fā)系統(tǒng)根據(jù)訂購(gòu)信息中的內(nèi)容標(biāo)識(shí)從內(nèi)容加密與打包系統(tǒng)中查詢加密內(nèi)容信息，并保存到許可證信息中。

step3許可證管理與分發(fā)系統(tǒng)將完整的權(quán)限信息保存到許可證數(shù)據(jù)庫(kù)。

step4許可證管理與分發(fā)系統(tǒng)將許可證下載信息返回給業(yè)務(wù)平臺(tái)，業(yè)務(wù)平臺(tái)將許可證下載信息返回給用戶瀏覽器，供用戶下載許可證。

4.4.2 許可證分發(fā)流程

許可證分發(fā)模塊接收DRM客戶端的許可證下載請(qǐng)求，包含設(shè)備標(biāo)識(shí)DID、用戶的公鑰證書及下載請(qǐng)求簽名信息，并將上述信息發(fā)送到許可證生成模塊，許可證生成模塊將最終的許可證內(nèi)容返回到許可證分發(fā)模塊，許可證分發(fā)模塊將許可證分發(fā)到DRM客戶端，如圖6所示。

圖6 許可證分發(fā)流程

step1許可證管理與分發(fā)系統(tǒng)收到DRM客戶端發(fā)起的許可證下載請(qǐng)求，包含許可證下載信息URL，用戶標(biāo)識(shí)UID，設(shè)備標(biāo)識(shí)DID、用戶的公鑰PUK及下載請(qǐng)求簽名信息LQS等

step2許可證管理與分發(fā)系統(tǒng)將用戶的公鑰及下載請(qǐng)求簽名信息發(fā)送到密鑰管理服務(wù)器請(qǐng)求驗(yàn)證下載請(qǐng)求和用戶身份

驗(yàn)證以下等式是否成立

step3許可證管理與分發(fā)系統(tǒng)根據(jù)下載請(qǐng)求查找到內(nèi)容標(biāo)識(shí)CID和許可證信息，然后將內(nèi)容標(biāo)識(shí)CID發(fā)送給密鑰管理服務(wù)器，獲得密鑰管理服務(wù)器返回的經(jīng)過加密后的內(nèi)容主控密鑰 UEK和內(nèi)容散列值ECH。

step4許可證管理與分發(fā)系統(tǒng)將權(quán)限信息REX基于許可證權(quán)利描述語(yǔ)言生成待簽名的許可證LCC

step5許可證管理與分發(fā)系統(tǒng)將待簽名的許可證發(fā)送給密鑰管理服務(wù)器請(qǐng)求簽名得到LCS

step6許可證管理與分發(fā)系統(tǒng)在得到密鑰管理服務(wù)器返回的簽名信息LCS后，生成最終的許可證文件LIC

4.5 DRM客戶端

DRM 客戶端負(fù)責(zé)管理包括加密媒體解析和解密、安全引擎調(diào)用、許可證下載和管理、客戶端管理等。

DRM 客戶端的基本工作流程包括：許可證下載和媒體文件解密播放等。

1) 許可證下載

用戶訂購(gòu)?fù)瓿珊螳@取許可證下載信息，通過許可證下載代理模塊完成許可證的下載。用戶也可以在DRM客戶端管理提供的許可證下載界面上輸入許可證提取碼，發(fā)起許可證下載請(qǐng)求。

如圖7所示，在下載許可證之前，客戶端需要向許可證管理與分發(fā)服務(wù)器提供用戶的公鑰，在這里，用戶的公私鑰對(duì)由客戶端產(chǎn)生和維護(hù)。許可證管理與分發(fā)服務(wù)器和密鑰管理服務(wù)器協(xié)作完成許可證的封裝，并把許可證下發(fā)到客戶端。

圖7 DRM客戶端下載許可證時(shí)序

2) 媒體文件解密播放

DRM客戶端獲取許可證后，使用DRM播放器按照許可證描述播放內(nèi)容，時(shí)序如圖8所示。

DRM 客戶端使用許可證管理與分發(fā)服務(wù)器的公鑰來(lái)驗(yàn)證許可證簽名，許可證和設(shè)備的綁定是通過用戶的公鑰加密內(nèi)容主控密鑰 UEK和用戶設(shè)備標(biāo)識(shí)DID實(shí)現(xiàn)，在判斷綁定關(guān)系正確后，DRM客戶端使用用戶的私鑰從許可證解密出內(nèi)容主控密鑰 CPK，然后和 DRM 頭中的內(nèi)容輔助密鑰 CRK導(dǎo)出CEK

DRM客戶端使用CEK調(diào)用安全引擎解密受保護(hù)的媒體內(nèi)容ECD，將待播放的明文數(shù)據(jù)PCD交給播放器進(jìn)行播放

5 CPSec Media DRM系統(tǒng)實(shí)現(xiàn)方案

5.1 內(nèi)容加密與打包系統(tǒng)

內(nèi)容加密與打包系統(tǒng)以任務(wù)的形式提供服務(wù)，支持單個(gè)和批量任務(wù)的提交，系統(tǒng)后臺(tái)自動(dòng)伺服對(duì)內(nèi)容按照指定參數(shù)進(jìn)行加密和打包，任務(wù)完成后通知用戶和系統(tǒng)。系統(tǒng)支持高、較高、一般、較低、低等5個(gè)優(yōu)先級(jí)，管理員可根據(jù)內(nèi)容要求動(dòng)態(tài)調(diào)整任務(wù)優(yōu)先級(jí)。

圖8 DRM媒體解密播放時(shí)序

5.2 密鑰管理系統(tǒng)

密鑰管理系統(tǒng)采用3層密鑰管理模型，其中第一層負(fù)責(zé)媒體內(nèi)容加密，采用分組密碼算法；第二層負(fù)責(zé)內(nèi)容密鑰保護(hù)，所用密鑰稱為內(nèi)容主控密鑰，采用分組密碼算法；第三層負(fù)責(zé)將內(nèi)容主控密鑰分發(fā)給授權(quán)用戶，采用非對(duì)稱算法。

5.3 安全引擎系統(tǒng)

安全引擎系統(tǒng)基于OpenSSL算法庫(kù)，提供相關(guān)加解密算法，支持對(duì)稱加密算法、非對(duì)稱加密算法、散列算法和X.509證書操作等，實(shí)現(xiàn)公私鑰對(duì)的生成、數(shù)字簽名、身份認(rèn)證、散列值計(jì)算、解密內(nèi)容主控密鑰CMK等功能。

5.4 許可證管理與分發(fā)系統(tǒng)

許可證管理與分發(fā)系統(tǒng)負(fù)責(zé)根據(jù)從業(yè)務(wù)平臺(tái)接收的訂購(gòu)信息，生成許可證提取碼，并返回給業(yè)務(wù)平臺(tái)，用戶獲取許可證提取碼后在終端輸入許可證提取碼下載許可證，系統(tǒng)根據(jù)許可證提取碼分發(fā)許可證到客戶端。

CPSec Media DRM 系統(tǒng)定義的權(quán)利表達(dá)語(yǔ)言REL（rights expression language）規(guī)定的是基于ODRL[20]控制 DRM 內(nèi)容使用權(quán)利的語(yǔ)法和語(yǔ)義，即權(quán)利表達(dá)語(yǔ)言是用于規(guī)范定義權(quán)利對(duì)象的語(yǔ)法和語(yǔ)義，包括基礎(chǔ)模版、協(xié)議模版、背景模版、許可模版、約束模版、繼承模版和安全模版，約束模板包括的細(xì)粒度使用控制如表4所示。

表4 許可證約束模板中細(xì)粒度使用控制

5.5 DRM客戶端

DRM 客戶端包括加密文件解析解密、安全引擎、許可證下載代理、許可證管理、本地許可證庫(kù)、客戶端管理、播放器插件和瀏覽器插件等單元。

6 CPSec Media DRM實(shí)驗(yàn)結(jié)果分析

通過實(shí)驗(yàn)對(duì)比CPSec Media DRM系統(tǒng)加密的性能，同時(shí)對(duì)比原始內(nèi)容和受DRM保護(hù)后的內(nèi)容播放的資源占用等性能，驗(yàn)證本文方案的性能和實(shí)時(shí)性。

6.1 實(shí)驗(yàn)1

比較CPSec Media DRM系統(tǒng)采用的非結(jié)構(gòu)化加密和幀加密的加密性能。實(shí)驗(yàn)數(shù)據(jù)選取水平分辨率分別為320 p、480 p、720 p和1 080 p的不同媒體，實(shí)驗(yàn)環(huán)境為IBM X3650服務(wù)器，非結(jié)構(gòu)化加密算法采用AES算法。

實(shí)驗(yàn)過程中分別對(duì)上述4組DRM媒體進(jìn)行加密處理，并統(tǒng)計(jì)其加密時(shí)間。

實(shí)驗(yàn)中本文的非結(jié)構(gòu)化加密結(jié)果和文獻(xiàn)[9]的幀加密進(jìn)行了對(duì)比測(cè)試，結(jié)果如表5所示。實(shí)驗(yàn)結(jié)果表顯示非結(jié)構(gòu)化加密平均速度為10 Mbit/s，而幀加密平均速度為8.4 Mbit/s。與幀加密相比，非結(jié)構(gòu)化加密速度平均高出 15%～20%，并且非結(jié)構(gòu)化加密速度符合線性關(guān)系，而幀加密隨著媒體內(nèi)容大小和幀數(shù)量的不斷增多，其速度呈逐漸降低趨勢(shì)。

表5 非結(jié)構(gòu)化加密結(jié)果

與非結(jié)構(gòu)化加密相比，幀加密需要耗費(fèi)時(shí)間在多媒體內(nèi)容幀結(jié)構(gòu)的解析上，并且?guī)用芎蟮拿襟w依然能夠播放，只不過畫面出現(xiàn)錯(cuò)亂，而非結(jié)構(gòu)化加密方法將媒體結(jié)構(gòu)信息等全部加密，用戶無(wú)法播放加密后的媒體，安全性較高。

實(shí)驗(yàn)結(jié)果表明非結(jié)構(gòu)化加密方法有著較高的加密效率和較好的實(shí)用性，并且能夠支持不同格式和大小的多媒體內(nèi)容的加密處理。

6.2 實(shí)驗(yàn)2

比較CPSec Media DRM系統(tǒng)播放的性能。實(shí)驗(yàn)數(shù)據(jù)選取水平分辨率分別為320 p、480 p、720 p和1 080 p的同一媒體，實(shí)驗(yàn)環(huán)境CPU主頻大小為雙核2.2 GHz，內(nèi)存大小為2 GB。

實(shí)驗(yàn)過程中分別對(duì)上述4組DRM視頻進(jìn)行下載播放，并統(tǒng)計(jì)其CPU平均占用率。

實(shí)驗(yàn)中CPU平均占用率如圖9所示。實(shí)驗(yàn)結(jié)果表顯示多媒體比特率越高，受DRM保護(hù)的多媒體播放時(shí)CPU平均占用率比原始媒體播放時(shí)高出越多。

總體來(lái)看，DRM保護(hù)的媒體使用時(shí)資源占用平均高出3%～5%，在不影響多媒體質(zhì)量的前提下，保持著較低的資源占用，能夠支持不同硬件性能的終端。

圖9 資源占用實(shí)驗(yàn)結(jié)果對(duì)比

7 CPSec Media DRM對(duì)比分析

目前，主流的多媒體DRM方案包括OMA DRM 2.0、Adobe Flash Access和微軟Media DRM等，CPSec Media DRM在支持的媒體格式、內(nèi)容加密方法、支持的終端平臺(tái)、許可證重新發(fā)行、許可證轉(zhuǎn)讓、許可證用戶綁定、許可證設(shè)備綁定和許可證離線使用等方面與這些方案的對(duì)比分析如表 6所示。本文所提的方案支持通用媒體格式，許可證支持重新發(fā)行、轉(zhuǎn)讓、用戶綁定、設(shè)備綁定和離線使用。

針對(duì)DRM的攻擊主要包括協(xié)議中的客戶端和服務(wù)器之間缺乏相互認(rèn)證，轉(zhuǎn)儲(chǔ)內(nèi)容加密密鑰或未加密的內(nèi)容等，本文所提的方案中媒體內(nèi)容使用內(nèi)容加密密鑰加密，保證內(nèi)容的安全性，許可證下載時(shí)客戶端和服務(wù)器之間使用 HTTPS加密協(xié)議，保證下載申請(qǐng)和許可證的安全性，同時(shí)下載申請(qǐng)使用用戶的私鑰簽名，提供給服務(wù)器認(rèn)證用戶身份，下載的許可證使用服務(wù)器的私鑰簽名，保證許可證的完整性，許可證中的內(nèi)容密鑰使用用戶的公鑰加密，保證內(nèi)容加密密鑰的安全性。

表6 多媒體DRM對(duì)比分析

目前，多媒體內(nèi)容逐漸成為互聯(lián)網(wǎng)主流，為了適應(yīng)多媒體技術(shù)和移動(dòng)終端的快速發(fā)展，本方案下一步重點(diǎn)研究許可證的離線分發(fā)和用戶域的支持。

8 結(jié)束語(yǔ)

本文提出一種新型通用格式多媒體數(shù)字版權(quán)管理的模型，該模型通過非結(jié)構(gòu)化加密方法以支持通用多媒體格式，支持不同內(nèi)容提供商提供的不同類型的版權(quán)內(nèi)容。同時(shí)，本模型實(shí)現(xiàn)中引入了許可證提取碼的概念，用戶通過許可證提取碼下載許可證，解決許可證重新發(fā)行和轉(zhuǎn)讓的問題，滿足試用、贈(zèng)送等復(fù)雜的使用場(chǎng)景。

與現(xiàn)有的多媒體DRM方案相比，本文提出的CPSec Media DRM方案，支持通用多媒體格式，支持許可證的重新發(fā)行和轉(zhuǎn)讓，并且支持細(xì)粒度使用控制方式，效率及安全性較高，具有較好的實(shí)用性。

[1] WIPO - world intellectual property organization[EB/OL]. http：//www.wipo.int.

[2] 馬兆豐，范科峰，陳銘等. 支持時(shí)空約束的可信數(shù)字版權(quán)管理安全許可協(xié)議[J]. 通信學(xué)報(bào), 2008,29(10)：153-164.MA Z F, FAN K F, CHEN M, et al. Trusted digital rights management protocol supporting for time and space constraint[J]. Journal of Communicartions, 2008, 29(10)：153-164.

[3] 莊超. 一種新型的 Internet內(nèi)容版權(quán)保護(hù)的計(jì)算機(jī)制[J]. 計(jì)算機(jī)學(xué)報(bào), 2000,23(10)：1088-1091.ZHUANG C. A new computing mechanism for Internet content copyright protection[J]. Chinese Journal of Computers, 2000,23(10)： 1088-1091.

[4] 譚建龍，莊超，白碩. 一種實(shí)用的Internet內(nèi)容版權(quán)保護(hù)系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J]. 計(jì)算機(jī)研究與發(fā)展, 2001,38(10)：1119-1203.TAN J L, ZHUANG C, BAI S. Design and implementation of a practical Internet content copyright protection system[J]. Journal of Computer Research and Development, 2001,38(10)：1119-1203.

[5] 俞銀燕，湯幟. 數(shù)字版權(quán)保護(hù)技術(shù)研究綜述[J]. 計(jì)算機(jī)學(xué)報(bào),2005,28(12)：957-968.YU Y Y, TANG Z. A survey of the research on digital rights management[J]. Chinese Journal of Computers, 2005,28(12)：957-968.

[6] 馬兆豐，馮博琴. 基于動(dòng)態(tài)許可證的信任版權(quán)安全認(rèn)證協(xié)議[J]. 軟件學(xué)報(bào), 2004,15(1)：131-140.MA Z F, FENG B Q. Secure authentication protocol for trusted copyright management based on dynamic license[J]. Journal of Software,2004,15(1)：131-140.

[7] 范科峰，莫瑋，曹山等. 數(shù)字版權(quán)管理技術(shù)及應(yīng)用研究進(jìn)展[J]. 電子學(xué)報(bào), 2007,35(6)：1139-1147.FAN K F, MO W, CAO S, et al. Advances in digital rights management technology and application[J]. Acta Electronica Sinica,2007,35(6)：1139-1147.

[8] LI J S, HSIEH C J, HUNG C F. A novel DRM framework for peer-to-peer music content delivery[J]. Journal of Systems and Software, 2010,83(10)：1689-1700.

[9] KIM B, CHOI J, KIM J, et al. A study on frame encryption for protecting IPTV contents[A]. Advanced Communication Technology(ICACT)[C]. 2011. 1484-1488.

[10] JEONG Y, KIM J, YOON K. Consumer electronics[A]. Audio DRM Conversion between Different DRM Content Formats[C]. 2008. 1-2.

[11] 鐘勇，秦小麟，劉鳳玉. 一種面向DRM的責(zé)任授權(quán)模型及其實(shí)施框架[J]. 軟件學(xué)報(bào), 2010,21(8)：2059-2069.ZHONG Y, QIN X L, LIU F Y. Obligation authorization model and its implementation framework for DRM[J]. Journal of Software, 2010,21(8)：2059-2069.

[12] OMA DRM[EB/OL]. http：//www.openmobilealliance.org.

[13] Marlin DRM[EB/OL]. http：//www.marlin-community.com.

[14] Apple Inc. Thoughts on music[EB/OL]. http：//www.apple.com/ hotnews/ thoughtsonmusic.

[15] Microsoft media rights server. microsoft corp[EB/OL]. http：//www.microsoft.com/windows/windowsmedia/drm/default.aspx.

[16] Adobe flash access[EB/OL]. http：//www.adobe.com/products/adobeaccess. html.

[17] 魏景芝，楊義先，鈕心忻. OMA DRM技術(shù)體系研究綜述[J]. 電子與信息學(xué)報(bào), 2008,30(3)：746-751.WEI J Z, YANG Y X, NIU X X. Overview of study on the technical architecture of OMA DRM[J]. Journal of Electronics & Information Technology, 2008,30(3)：746-751.

[18] SANDHU R, PARK J. Usage control： a vision for next generation access control[A]. Proc of the MMM-ACNS-2003[C]. Heidelberg：Springer-Verlag, 2003. 17-31.

[19] WONG C C, LOW A L Y, HIEW P L. Fixed-mobile convergence：creating values with appropriate business models[A]. Information and Communication Technologies, ICTTA '06, 2nd[C]. 2006. 17-22.

[20] ODRL： open digital rights language[EB/OL]. http：//www.odrl.net.