專利名稱：一種數(shù)字內(nèi)容格式的解密處理方法
技術(shù)領(lǐng)域：
本發(fā)明涉及數(shù)字版權(quán)保護(hù)技術(shù)，特別是涉及運(yùn)營(yíng)中的數(shù)字內(nèi)容保護(hù)技術(shù)。輸支*
數(shù)字化內(nèi)容服務(wù)具有質(zhì)量高、可交互、可定制的特點(diǎn)，能給用戶帶來(lái)更自由、更豐富也因此更加具有吸引力的消費(fèi)體驗(yàn)，同時(shí)給內(nèi)容提供和運(yùn)營(yíng)商帶來(lái)更大的市場(chǎng)和利潤(rùn)空間；但是強(qiáng)大的需求、高額的利潤(rùn)也吸引了很多盜版集團(tuán)試圖對(duì)數(shù)字化內(nèi)容進(jìn)行非法復(fù)制并贏取暴利。數(shù)字版權(quán)保護(hù)應(yīng)運(yùn)而生，通過(guò)必要、可行、合理的技術(shù)手段對(duì)于運(yùn)營(yíng)的數(shù)字內(nèi)容進(jìn)行保護(hù)，以維護(hù)內(nèi)容提供和運(yùn)營(yíng)商的合法權(quán)利，保障數(shù)字化市場(chǎng)的基本秩序以維護(hù)正向、積極的激勵(lì)，以保證數(shù)字內(nèi)容市場(chǎng)的健康、持久的發(fā)展。
數(shù)字版權(quán)保護(hù)需要三個(gè)基本要素加密后的內(nèi)容密文、用于加解密該數(shù)字內(nèi)容的密鑰和用戶訂購(gòu)的該數(shù)字內(nèi)容的使用權(quán)限。用戶通過(guò)數(shù)字產(chǎn)權(quán)管理(DRM)系統(tǒng)訂購(gòu)并完整獲得數(shù)字內(nèi)容相關(guān)的三個(gè)基本要素，并由終端正確接收、處理相關(guān)內(nèi)容，驗(yàn)證相應(yīng)的使用權(quán)限，才能夠解密還原出數(shù)字內(nèi)容的明文，并享受定制的服務(wù)。
在數(shù)字化內(nèi)容運(yùn)營(yíng)過(guò)程中，現(xiàn)在的內(nèi)容數(shù)據(jù)包普遍使用DCF (DRM ContentFormat)格式。DCF是一種基于ISO基本文件格式的DRM內(nèi)容數(shù)據(jù)包，其中包含受保護(hù)的媒體內(nèi)容以及相關(guān)元數(shù)據(jù)。媒體內(nèi)容可以是視頻、音頻等，元數(shù)據(jù)是與DRM相關(guān)的數(shù)據(jù)。
在實(shí)際的數(shù)字化內(nèi)容運(yùn)營(yíng)的應(yīng)用環(huán)境中，針對(duì)系統(tǒng)開發(fā)周期、成本和信息處理過(guò)程中的速度、效率的需求，可以利用運(yùn)營(yíng)環(huán)境的可知性以及運(yùn)營(yíng)組件和終端之間的可協(xié)調(diào)性，設(shè)定一套新的簡(jiǎn)化的內(nèi)容保護(hù)格式，盡量利用目前規(guī)范的流媒體格式、 成熟的處理技術(shù)，可以快速開發(fā)出穩(wěn)定成熟的商用系統(tǒng)，并加快系統(tǒng)的處理速度， 保證服務(wù)質(zhì)量。
針對(duì)上述現(xiàn)有技術(shù)中存在的問(wèn)題，目前雖然提出了一種簡(jiǎn)化的數(shù)字版權(quán)管理的 內(nèi)容格式(Simplified DRM Content Format簡(jiǎn)稱SDCF)，能大大簡(jiǎn)化了數(shù)字內(nèi)容格 式，以減小網(wǎng)絡(luò)載荷，滿足技術(shù)需求；但其相應(yīng)的解密處理方法沒有變更，影響了 SDCF的推廣和應(yīng)用。

發(fā)明內(nèi)容
針對(duì)上述現(xiàn)有技術(shù)中存在的缺陷，本發(fā)明所要解決的技術(shù)問(wèn)題是提供一種能減 小網(wǎng)絡(luò)載荷，操作簡(jiǎn)便，滿足技術(shù)需求的簡(jiǎn)化的數(shù)字產(chǎn)權(quán)管理保護(hù)格式(SDCF)的 解密處理方法。
為了解決上述技術(shù)問(wèn)題，本發(fā)明提供一種SDCF的解密處理方法，其設(shè)及的平臺(tái) 包括機(jī)頂盒的DRM代理和DRM的版權(quán)發(fā)布系統(tǒng)、中間件，其中DRM代理包括RO管理 模塊、密鑰管理模塊、內(nèi)容解密模塊、監(jiān)視控制模塊和播放器、瀏覽器等，監(jiān)視控 制模塊內(nèi)設(shè)有播前控制子模塊；其特征在于，解密處理方法包括如下步驟
1) 用戶通過(guò)用戶界面選擇節(jié)目，獲得全局唯一的節(jié)目標(biāo)識(shí)ContentID和該 節(jié)目?jī)?nèi)容的URL (統(tǒng)一資源定位符)。
2) 播前控制模塊根據(jù)ContentID在本地搜索對(duì)應(yīng)的RO，并檢査權(quán)限；如果 沒有搜索到對(duì)應(yīng)的RO或者權(quán)限檢查失敗，終端則向版權(quán)發(fā)布系統(tǒng)申請(qǐng)版 權(quán)；如果成功申請(qǐng)到RO，則進(jìn)行權(quán)限檢查；如果不能經(jīng)過(guò)權(quán)限檢查或者 不能申請(qǐng)到相應(yīng)的R0，機(jī)頂盒則會(huì)報(bào)錯(cuò)并返回；如果能夠經(jīng)過(guò)權(quán)限檢查， 并獲取對(duì)應(yīng)數(shù)字內(nèi)容的URL、解密模式和內(nèi)容密鑰，則進(jìn)入步驟3);
3) 內(nèi)容解密模塊根據(jù)傳送數(shù)字內(nèi)容的數(shù)據(jù)包中的URL，從播前控制模塊獲得對(duì)應(yīng)的RO,并獲解密模式和內(nèi)容密鑰，從而完成解密工作。 進(jìn)一步的，所述步驟l)中的節(jié)目包括VOD點(diǎn)播(ISMA數(shù)據(jù)流)節(jié)目和直播(TS 數(shù)據(jù)流)節(jié)目。
進(jìn)一步的，所述步驟l)中播放的是直播節(jié)目，應(yīng)當(dāng)在數(shù)據(jù)包中添加標(biāo)識(shí)密鑰狀 態(tài)的傳輸規(guī)則控制位TSC (Transport Scrambling Control)。
進(jìn)一步的，所述傳輸規(guī)則控制位設(shè)置兩位標(biāo)識(shí)，分別表示節(jié)目沒有加密、節(jié) 目正在正常加密、節(jié)目即將更新密鑰、密鑰已經(jīng)更新密鑰。
進(jìn)一步的，所述步驟l)中節(jié)目為普通節(jié)目(即沒有加密的節(jié)目)，播放器在所 述步驟2)中(播前控制的時(shí)候)控制好權(quán)限后，直接發(fā)送給播放器；不再經(jīng)過(guò)內(nèi) 容解密模塊。
進(jìn)一步的，所述步驟l)中節(jié)目即將更新密鑰，則RO管理模塊需要向后臺(tái)申請(qǐng) 新的RO,以備更換密鑰后解密內(nèi)容。
進(jìn)一步的，所述步驟l)中節(jié)目己經(jīng)更換密鑰，則內(nèi)容解密模塊使用新的版權(quán)對(duì) 象中的解密模式和解密密鑰進(jìn)行數(shù)據(jù)處理，并刪除舊的R0。
進(jìn)一步的，所述步驟l)中節(jié)目正常加密，則內(nèi)容解密模塊正常處理，即通過(guò)播 前控制模塊從該節(jié)目對(duì)應(yīng)的R0中獲得解密模式和內(nèi)容密鑰，并使用內(nèi)容密鑰在解密 模式的算法下解密數(shù)字內(nèi)容。
其中，考慮到點(diǎn)播節(jié)目的節(jié)目有一定長(zhǎng)度、并在媒體服務(wù)器中的指定地址存儲(chǔ)， 因此本專利不推薦點(diǎn)播節(jié)目使用這種復(fù)雜的處理方法，而在系統(tǒng)不忙的時(shí)候(如凌 晨三點(diǎn))切換密鑰，并且在密鑰切換時(shí)刻前的一段時(shí)間內(nèi)， 一般略長(zhǎng)于片長(zhǎng)，關(guān)閉 節(jié)目，即用戶可以不通過(guò)電子節(jié)目菜單EPG (Electronic Program Guide)點(diǎn)播該 節(jié)目。
采用本發(fā)明提出的SDCF的解密處理方法，能滿足SDCF的技術(shù)需求，使簡(jiǎn)化的
6數(shù)字版權(quán)管理的內(nèi)容格式在數(shù)字化內(nèi)容運(yùn)營(yíng)過(guò)程中得到推廣和應(yīng)用。SDCF格式幾乎 不需要在數(shù)據(jù)包頭添加任何數(shù)據(jù)，從而簡(jiǎn)化了操作，同時(shí)彌補(bǔ)了0MA (Open Mobile Alliance)協(xié)議中的DCF (DRM Content Format)格式不能處理數(shù)據(jù)流的局限，擴(kuò)大 了SDCF的推廣和應(yīng)用范圍。


圖1是本發(fā)明的實(shí)施例DRM的系統(tǒng)結(jié)構(gòu)圖2是本發(fā)明的實(shí)施例機(jī)頂盒的DRM代理的結(jié)構(gòu)圖3是本發(fā)明的實(shí)施例密鑰更換期TSC的變化示意圖4是本發(fā)明的實(shí)施例DRM Agent根據(jù)TSC標(biāo)識(shí)位的處理流程示意圖。
具體實(shí)施例方式
以下結(jié)合

對(duì)本發(fā)明的實(shí)施例作進(jìn)一步詳細(xì)描述，但本實(shí)施例并不用于 限制本發(fā)明，凡是采用與本發(fā)明相似的SDCF數(shù)據(jù)格式的解密處理方法，均應(yīng)列入本 發(fā)明的保護(hù)范圍。
本發(fā)明可以應(yīng)用于以下場(chǎng)景
1) 提供VOD點(diǎn)播服務(wù)，對(duì)于SDCF格式的流媒體文件進(jìn)行解密播放；
2) 提供實(shí)時(shí)直播服務(wù)，對(duì)于SDCF格式的流媒體數(shù)據(jù)流進(jìn)行解密播放；
3) 提供時(shí)移播放服務(wù)，對(duì)于滿足SDCF格式的分段流媒體文件進(jìn)行解密播放；
4) 提供其他的數(shù)字內(nèi)容服務(wù)，對(duì)于滿足SDCF格式的相應(yīng)的數(shù)字內(nèi)容進(jìn)行解密 使用。
由于在網(wǎng)絡(luò)傳輸中，SDCF格式的數(shù)據(jù)利用數(shù)據(jù)包源地址判別文件用途，取代DCF 的數(shù)據(jù)頭；對(duì)于下載到本地的數(shù)字內(nèi)容，只需要將相應(yīng)的URL指向本地相應(yīng)存儲(chǔ)空 間，就可以得到完全類似下面介紹的網(wǎng)絡(luò)傳輸中的處理。因此一個(gè)受保護(hù)的數(shù)字內(nèi)容，有如下幾個(gè)重要指標(biāo)
1) 能被終端識(shí)別的標(biāo)志，使終端能夠識(shí)別出受保護(hù)的數(shù)字內(nèi)容，并對(duì)其進(jìn) 行相應(yīng)的解密處理。
2) 能夠唯一地標(biāo)識(shí)受保護(hù)的數(shù)字內(nèi)容的身份認(rèn)證，使終端能夠通過(guò)一定途 徑，獲取該數(shù)字內(nèi)容的授權(quán)及相應(yīng)的內(nèi)容密鑰。
3) 為了平滑過(guò)渡密鑰交換，對(duì)于數(shù)據(jù)流和分段文件， 一般還需要一定的標(biāo) 識(shí)位來(lái)標(biāo)識(shí)密鑰的使用狀態(tài)。
相應(yīng)的，運(yùn)營(yíng)系統(tǒng)為了滿足上述三個(gè)指標(biāo)，提供相應(yīng)的標(biāo)識(shí)位，為了簡(jiǎn)化數(shù)據(jù)
封裝，SDCF做出如下規(guī)定
1) 由于提供數(shù)字內(nèi)容產(chǎn)品的服務(wù)器是固定的，所以使用數(shù)據(jù)包的源地址來(lái) 標(biāo)識(shí)相應(yīng)的文件是否為用戶訂購(gòu)的受保護(hù)的數(shù)字內(nèi)容產(chǎn)品。顯然，在可
自主調(diào)配的系統(tǒng)中，這一方案是很容易實(shí)現(xiàn)的；在不能完全自主調(diào)配系 統(tǒng)或者提供密文的服務(wù)器可能發(fā)生變更的情況下，終端應(yīng)該向用戶提供 相應(yīng)的菜單，根據(jù)系統(tǒng)的具體情況，設(shè)置哪些源地址提供的數(shù)據(jù)包可能 是用戶定購(gòu)的受保護(hù)的數(shù)字內(nèi)容產(chǎn)品。
2) 提供受保護(hù)的數(shù)字內(nèi)容產(chǎn)品的運(yùn)營(yíng)系統(tǒng)，應(yīng)該為每個(gè)數(shù)字產(chǎn)品設(shè)置一個(gè) 全局唯一的身份認(rèn)證(ContentID)。 一般地，用戶在某一時(shí)間只對(duì)一個(gè) 數(shù)字內(nèi)容產(chǎn)品進(jìn)行消費(fèi)，所以只有在用戶通過(guò)用戶界面和相應(yīng)服務(wù)器通 信的時(shí)候需要通過(guò)身份認(rèn)證(ContentID)定位相應(yīng)的數(shù)字產(chǎn)品、付費(fèi)、 申請(qǐng)?jiān)摂?shù)字產(chǎn)品的版權(quán)信息(包含內(nèi)容密鑰)，也就是說(shuō)這個(gè)標(biāo)識(shí)的意義 往往在于服務(wù)器之間的通信過(guò)程，那么在將數(shù)據(jù)發(fā)送給終端的時(shí)候，可 選地不把這個(gè)標(biāo)識(shí)打包發(fā)送；如果終端支持并發(fā)下載，依然可以通過(guò)URL 區(qū)別不同內(nèi)容，分別將目標(biāo)文件下載到終端的不同存儲(chǔ)空間，并與相應(yīng) 的版權(quán)信息(包含內(nèi)容密鑰)綁定。對(duì)于數(shù)據(jù)流、分段文件，在頭文件的擴(kuò)展位中設(shè)置需要的狀態(tài)位，用來(lái)標(biāo)識(shí)密 鑰更換狀態(tài)。 一般的，有如下兩種狀態(tài)數(shù)據(jù)包未加密、數(shù)據(jù)包已加密；或如下四 種狀態(tài)數(shù)據(jù)包未加密、數(shù)據(jù)包已加密且密鑰策略不改變、數(shù)據(jù)包已加密且密鑰策 略將要改變和數(shù)據(jù)包已加密其密鑰策略已經(jīng)改變。所以， 一般地，不需要超過(guò)兩個(gè) 標(biāo)識(shí)位，對(duì)于一般的數(shù)據(jù)規(guī)范，不難找到兩比特的頭文件擴(kuò)展。
本實(shí)施例針對(duì)V0D點(diǎn)播和直播節(jié)目，提供一種對(duì)SDCF數(shù)據(jù)格式的數(shù)據(jù)包進(jìn)行 解密處理的合理實(shí)現(xiàn)。
如圖l所示，本發(fā)明實(shí)施例所提供的一種簡(jiǎn)化的數(shù)字產(chǎn)權(quán)管理保護(hù)格式(SDCF) 的解密處理方法中，DRM包括互相連接的內(nèi)容加密層、授權(quán)/密鑰管理層、流程處理 /用戶界面層、客戶管理層和DRM代理；其中，內(nèi)容加密層主要完成節(jié)目?jī)?nèi)容的加 密，包括實(shí)時(shí)流加密和文件預(yù)加密；授權(quán)/密鑰管理層主要包括R0管理、授權(quán)管理 和KMS;流程處理/用戶界面層主要包括業(yè)務(wù)流程和商業(yè)模式處理及DRM用戶界面； 客戶管理層主要包括客戶追蹤和身份認(rèn)證；DRM代理主要包括RO管理模塊、密鑰管 理模塊、內(nèi)容解密模塊、監(jiān)視控制模塊和播放器、瀏覽器等，監(jiān)視控制模塊內(nèi)設(shè)有 播前控制子模塊。應(yīng)該指出的是，整個(gè)系統(tǒng)的策略都應(yīng)該受一個(gè)服務(wù)器統(tǒng)一調(diào)配， 在本發(fā)明實(shí)施例中使用一個(gè)叫做中間件的服務(wù)器來(lái)實(shí)現(xiàn)該功能，中間件圖1中并未 明確畫出，這個(gè)模塊要和每一個(gè)模塊發(fā)生作用以協(xié)同各個(gè)模塊之間的工作，其作用 主要是協(xié)同作用、幾乎每個(gè)模塊都要和它進(jìn)行交互，為了便于識(shí)別、分析。
其中，對(duì)于SDCF數(shù)據(jù)格式進(jìn)行解密的核心模塊自然是內(nèi)容解密模塊，但是準(zhǔn)確 地說(shuō)，整個(gè)DRM Agent協(xié)同作用，才實(shí)現(xiàn)了對(duì)于SDCF數(shù)據(jù)格式的數(shù)據(jù)包的解密和相 應(yīng)節(jié)目的播放，其中瀏覽器用來(lái)查詢節(jié)目、播放器播放節(jié)目清流，這兩部分和解密 有著比較密切的關(guān)系，本實(shí)施例會(huì)做出較詳盡的描述；而R0管理模塊、密鑰管理模 塊、監(jiān)視控制模塊三部分主要是用于權(quán)限管理，本實(shí)施例不做過(guò)多詳盡地描述，只 對(duì)與解密相關(guān)的功能做出如下定義
91) RO管理模塊可以申請(qǐng)、接收、處理版權(quán)對(duì)象RO，并可以清除、撤回R0。 其中清除無(wú)用R0、處理R0溢出、撤回RO等操作都是為了更好的保護(hù)版 權(quán)信息。
2) 密鑰管理模塊主要針對(duì)直播節(jié)目，為了提高速度，密鑰管理模塊通過(guò)版 權(quán)對(duì)象驗(yàn)證權(quán)限并獲取內(nèi)容密鑰CEK，在內(nèi)存中建立ContentlD+Key的 快速索引表當(dāng)某一版權(quán)對(duì)象過(guò)期后，密鑰管理模塊清除該版權(quán)對(duì)象對(duì) 應(yīng)的內(nèi)容密鑰、相應(yīng)的在ContentlD4Key的快速索引表中刪除相應(yīng)元數(shù) 據(jù)。
3) 監(jiān)視控制模塊定期調(diào)用R0管理模塊輪詢R0狀態(tài)，對(duì)于過(guò)期R0做出相應(yīng) 的處理；定期檢驗(yàn)DRM代理的時(shí)間，如果不準(zhǔn)確，調(diào)用RO管理模塊通過(guò) R0AP協(xié)議與服務(wù)器進(jìn)行時(shí)間同步校準(zhǔn)；定期檢查DRM Agent代碼的完整 性，發(fā)現(xiàn)不安全因素后根據(jù)問(wèn)題的嚴(yán)重性，作出相應(yīng)的反應(yīng)等。監(jiān)視控 制模塊保證DRM Agent的安全性，是整個(gè)解密處理的安全保證，但本實(shí) 施例主要討論解密處理過(guò)程，就不再對(duì)此展開討論了。
SDCF數(shù)據(jù)格式中的三個(gè)指標(biāo)，都是用于調(diào)度解密處理的，所以本實(shí)施例著重描 述播放控制的實(shí)現(xiàn)，圖2正是本實(shí)施例的播前控制模塊的結(jié)構(gòu)圖，尤其是V0D點(diǎn)播， 如上所述本實(shí)施例提供對(duì)V0D點(diǎn)播(ISMA數(shù)據(jù)流)和直播(TS數(shù)據(jù)流)的解密處理， 本實(shí)施例提供的系統(tǒng)統(tǒng)一了兩種解密處理對(duì)外的API接口，但內(nèi)部的處理流程是不 同的，下面將兩種模式分開討論-
一、 V0D文件——ISMA數(shù)據(jù)流
根據(jù)SDCF規(guī)定的V0D文件，即ISMA數(shù)據(jù)流中，沒有標(biāo)識(shí)位標(biāo)識(shí)數(shù)據(jù)流是否為 清流，本實(shí)施例中規(guī)定DRM Agent根據(jù)該節(jié)目對(duì)應(yīng)的RO來(lái)判別數(shù)據(jù)流是否為清流。 整個(gè)與解密處理相關(guān)的流程如下所示
1) 用戶通過(guò)EPG査詢節(jié)目，并選擇某一節(jié)目。2) EPG將用戶選擇的節(jié)目對(duì)應(yīng)的URL和節(jié)目?jī)?nèi)容ID發(fā)送給DRM Agent的播 前控制模塊。
3) RO管理模塊根據(jù)節(jié)目的URL和節(jié)目?jī)?nèi)容ID査詢本機(jī)是否有相應(yīng)的版權(quán) 對(duì)象R0。如果沒有R0，就檢查是否有權(quán)限申請(qǐng)R0。如果有權(quán)限，DRM 就通過(guò)EPG申請(qǐng)、獲取R0。如果Agent不能申請(qǐng)到RO，那么證明數(shù)據(jù)流 是密文，并且用戶的權(quán)限己經(jīng)過(guò)期，作報(bào)錯(cuò)處理。
4) 如有用戶有權(quán)限播放該節(jié)目播前控制模塊將節(jié)目?jī)?nèi)容的URL發(fā)送給播放 器。
5) 播放器的解復(fù)用模塊對(duì)不同URL的數(shù)字內(nèi)容處理，進(jìn)行數(shù)據(jù)包頭的處理 和編解碼處理。
6) 解密引擎從RO管理處獲得權(quán)限和解密密鑰，并進(jìn)行解密播放。
其中，對(duì)于處在密鑰過(guò)渡期的文件，Agent通過(guò)不同的URL選擇使用新的密鑰還 是舊的密鑰進(jìn)行解密處理。
二、 實(shí)時(shí)流——TS數(shù)據(jù)流
根據(jù)SDCF規(guī)定的實(shí)時(shí)流，即MPEG TS over IP數(shù)據(jù)流中，標(biāo)識(shí)位TSC (Transport Scrambling Control)標(biāo)識(shí)數(shù)據(jù)流是否為清流，TSC標(biāo)識(shí)位只有兩位，可以在任何協(xié)議 的包頭擴(kuò)展位上實(shí)現(xiàn)。由它標(biāo)識(shí)的狀態(tài)如圖3所示，因此DRM Agent可以根據(jù)TSC 標(biāo)識(shí)位來(lái)判別數(shù)據(jù)流是否為清流、識(shí)別密鑰狀態(tài)。對(duì)于TSC的處理流程如圖4所示。 整個(gè)與解密處理相關(guān)的流程如下所示
1) 用戶根據(jù)EPG査詢節(jié)目，并選擇某一節(jié)目。
2) EPG將用戶選擇的節(jié)目對(duì)應(yīng)的URL和節(jié)目?jī)?nèi)容ID發(fā)送給DRM Agent。
3) DRM Agent根據(jù)節(jié)目的URL和節(jié)目?jī)?nèi)容ID査詢本機(jī)是否有該節(jié)目的有效 版權(quán)對(duì)象R0。如果沒有具有相應(yīng)權(quán)限的R0，就通過(guò)一定的方式申請(qǐng)、獲 取R0。如果不能夠申請(qǐng)RO，通知EPG用戶沒有使用權(quán)限，EPG提示用戶去訂購(gòu)相關(guān)權(quán)限。
4) DRM Agent確定用戶有觀看該節(jié)目的權(quán)限后，通知EPG用戶有權(quán)收看節(jié) 目。
5) EPG調(diào)用播放器，播放器根據(jù)TSC標(biāo)識(shí)位判別數(shù)據(jù)流是否為清流，如果 TSC為00，那么數(shù)據(jù)流是清流，播放器的標(biāo)識(shí)位設(shè)置為清流播放，開始 播放節(jié)目，直至用戶終止收看節(jié)目。否則，數(shù)據(jù)流是受保護(hù)的，播放器 的標(biāo)識(shí)位設(shè)置為密文播放，并進(jìn)入步驟6)。
6) 播放器將接收到的數(shù)據(jù)流發(fā)送給Agent的解密模塊，如圖5所示，Agent 根據(jù)TSC的標(biāo)識(shí)位選擇處理數(shù)據(jù)的策略-
a) 當(dāng)TSC標(biāo)識(shí)位為01或者10的時(shí)候，解密模塊用當(dāng)前密鑰對(duì)數(shù)據(jù)進(jìn)行解 密，并將數(shù)據(jù)清流發(fā)送給播放器播放。
b) 當(dāng)TSC標(biāo)識(shí)位為11時(shí)，解密模塊用新的密鑰對(duì)數(shù)據(jù)進(jìn)行解密，并將數(shù)據(jù) 清流發(fā)送給播放器播放。
c) 當(dāng)TSC標(biāo)識(shí)位為10或者11的時(shí)候，Agent通過(guò)版權(quán)管理模塊，檢查自 己是否獲得了包含新的內(nèi)容密鑰的版權(quán)對(duì)象，如果沒有，通過(guò)ROAP協(xié)議 申請(qǐng)新的版權(quán)對(duì)象。申請(qǐng)到新的版權(quán)對(duì)象以后，通過(guò)處理解出新的加密 密鑰，并將其放入節(jié)目?jī)?nèi)容ID對(duì)應(yīng)的密鑰列表中。當(dāng)標(biāo)識(shí)位為ll時(shí)， 將新的加密密鑰賦值給當(dāng)前密鑰?！@一部分屬于版權(quán)處理模塊，這 里不作重點(diǎn)闡述了。
應(yīng)該指出的是，本步驟的相應(yīng)操作，都是通過(guò)節(jié)目?jī)?nèi)容ID對(duì)應(yīng)的密鑰列表來(lái) 獲取密鑰的，以加快處理速度。當(dāng)監(jiān)視控制模塊發(fā)現(xiàn)用戶已經(jīng)沒有權(quán)限以后，會(huì)刪 除相應(yīng)的RO和節(jié)目?jī)?nèi)容ID對(duì)應(yīng)的密鑰列表中的相關(guān)元數(shù)據(jù)，并發(fā)送消息給EPG， EPG通知用戶訂購(gòu)相應(yīng)的權(quán)限
權(quán)利要求
1、一種SDCF的解密處理方法，其設(shè)及的平臺(tái)包括機(jī)頂盒的DRM代理和DRM的版權(quán)發(fā)布系統(tǒng)、中間件，其中DRM代理包括RO管理模塊、密鑰管理模塊、內(nèi)容解密模塊、設(shè)有播前控制子模塊的監(jiān)視控制模塊和播放器、瀏覽器；其特征在于，解密處理方法包括如下步驟1)用戶通過(guò)用戶界面選擇節(jié)目，獲得全局唯一的節(jié)目標(biāo)識(shí)ContentID和該節(jié)目?jī)?nèi)容的URL；2)播前控制模塊根據(jù)Content ID在本地搜索對(duì)應(yīng)的RO，并檢查權(quán)限；如果沒有搜索到對(duì)應(yīng)的RO或者權(quán)限檢查失敗，終端則向版權(quán)發(fā)布系統(tǒng)申請(qǐng)版權(quán)；如果成功申請(qǐng)到RO，則進(jìn)行權(quán)限檢查；如果不能經(jīng)過(guò)權(quán)限檢查或者不能申請(qǐng)到相應(yīng)的RO，機(jī)頂盒則會(huì)報(bào)錯(cuò)并返回；如果能夠經(jīng)過(guò)權(quán)限檢查，并獲取對(duì)應(yīng)數(shù)字內(nèi)容的URL、解密模式和內(nèi)容密鑰，則進(jìn)入步驟3)；3)內(nèi)容解密模塊根據(jù)傳送數(shù)字內(nèi)容的數(shù)據(jù)包中的URL，從播前控制模塊獲得對(duì)應(yīng)的RO，并獲解密模式和內(nèi)容密鑰，從而完成解密工作。
2、 根據(jù)權(quán)利要求1所述的SDCF的解密處理方法，其特征在于，所述步驟l)中 的節(jié)目包括V0D點(diǎn)播節(jié)目和直播節(jié)目。
3、 根據(jù)權(quán)利要求1所述的SDCF的解密處理方法，其特征在于，所述步驟l)中 播放的是直播節(jié)目，應(yīng)當(dāng)在數(shù)據(jù)包中添加標(biāo)識(shí)密鑰狀態(tài)的傳輸規(guī)則控制位。
4、 根據(jù)權(quán)利要求3所述的SDCF的解密處理方法，其特征在于，所述傳輸規(guī)則 控制位設(shè)置兩位標(biāo)識(shí)，分別表示節(jié)目沒有加密、節(jié)目正在正常加密、節(jié)目即將更 新密鑰、密鑰已經(jīng)更新密鑰。
5、 根據(jù)權(quán)利要求1所述的SDCF的解密處理方法，其特征在于，所述步驟l)中 節(jié)目為普通節(jié)目，播放器在所述步驟2)中控制好權(quán)限后，直接發(fā)送給播放器；不再經(jīng)過(guò)內(nèi)容解密模塊。
6、 根據(jù)權(quán)利要求1所述的SDCF的解密處理方法，其特征在于，所述步驟l)中 節(jié)目即將更新密鑰，則R0管理模塊需要向后臺(tái)申請(qǐng)新的R0，以備更換密鑰后解密 內(nèi)容。
7、 根據(jù)權(quán)利要求1所述的SDCF的解密處理方法，其特征在于，所述步驟l)中 節(jié)目已經(jīng)更換密鑰，則內(nèi)容解密模塊使用新的版權(quán)對(duì)象中的解密模式和解密密鑰進(jìn) 行數(shù)據(jù)處理，并刪除舊的R0。
8、 根據(jù)權(quán)利要求1所述的SDCF的解密處理方法，其特征在于，所述步驟1) 中節(jié)目正常加密，則內(nèi)容解密模塊正常處理，即通過(guò)播前控制模塊從該節(jié)目對(duì)應(yīng)的 RO中獲得解密模式和內(nèi)容密鑰,并使用內(nèi)容密鑰在解密模式的算法下解密數(shù)字內(nèi)容。
全文摘要
一種SDCF的解密處理方法，涉及數(shù)字版權(quán)保護(hù)技術(shù)領(lǐng)域；所要解決的是SDCF解密處理的技術(shù)問(wèn)題；該解密處理方法，其設(shè)及的平臺(tái)包括機(jī)頂盒的DRM代理和DRM的版權(quán)發(fā)布系統(tǒng)、中間件，其中DRM代理包括RO管理模塊、密鑰管理模塊、內(nèi)容解密模塊、設(shè)有播前控制子模塊的監(jiān)視控制模塊和播放器、瀏覽器等；解密處理方法包括如下步驟1)用戶通過(guò)用戶界面選擇節(jié)目，獲得全局唯一的節(jié)目標(biāo)識(shí)和該節(jié)目?jī)?nèi)容的URL；2)播前控制模塊根據(jù)節(jié)目標(biāo)識(shí)在本地搜索對(duì)應(yīng)的RO，并檢查權(quán)限；3)內(nèi)容解密模塊根據(jù)傳送數(shù)字內(nèi)容的數(shù)據(jù)包中的URL，獲得對(duì)應(yīng)的RO，并獲解密模式和內(nèi)容密鑰，以完成解密。本發(fā)明具有能減小網(wǎng)絡(luò)載荷，操作簡(jiǎn)便，滿足技術(shù)需求的特點(diǎn)。
文檔編號(hào)H04N7/16GK101466020SQ20081017983
公開日2009年6月24日 申請(qǐng)日期2008年12月6日 優(yōu)先權(quán)日2007年12月17日
發(fā)明者周玉潔, 朱念好, 霞 胡 申請(qǐng)人:上海愛信諾航芯電子科技有限公司