專利名稱：一種數(shù)字版權(quán)管理中的密鑰管理系統(tǒng)及其方法
技術(shù)領(lǐng)域：
本發(fā)明涉及數(shù)字版權(quán)管理(DRM)領(lǐng)域，特別是涉及DRM系統(tǒng)中用于密鑰管理 的方法和系統(tǒng)。
背景技術(shù)：
隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展，信息的傳輸與共享變的非常便利。但是信息共享的便 利帶來了一個(gè)很大的問題，就是信息的版權(quán)管理變得異常困難。如何進(jìn)行信息的版 權(quán)進(jìn)行管理，保障內(nèi)容發(fā)布者CI (Content Issuer)的合法權(quán)益就成為一個(gè)重大課 題。數(shù)字版權(quán)管理DRM (Digital Right Management)就是應(yīng)這樣一個(gè)背景而生的。
目前，DRM的核心思想是加密后的內(nèi)容和版權(quán)相分離的思想。在DRM系統(tǒng)中， 數(shù)字信息產(chǎn)品采用內(nèi)容加密密鑰CEK (Content Encryption Key)加密，加密后的 內(nèi)容表現(xiàn)為加密過的信息流或者加密后的文件形式；而版權(quán)表現(xiàn)為版權(quán)對(duì)象R0 (Right Object)的形式，包括關(guān)于數(shù)字信息產(chǎn)品使用方式、使用次數(shù)、使用時(shí)間 等控制信息，還包括采用客戶終端設(shè)備公鑰加密保護(hù)的CEK。經(jīng)過加密保護(hù)的數(shù)字 信息產(chǎn)品和R0 —般經(jīng)過兩條不同的途徑到達(dá)客戶端設(shè)備。DRM系統(tǒng)一般由后臺(tái)服務(wù) 系統(tǒng)和DRM終端代理DRM Agent構(gòu)成，DRM后臺(tái)服務(wù)系統(tǒng)完成對(duì)客戶端設(shè)備的注冊、 數(shù)字信息產(chǎn)品的加密、RO的生成發(fā)布等操作；DRM Agent (DRM終端代理)駐留在客 戶端設(shè)備，用于向DRM后臺(tái)服務(wù)系統(tǒng)發(fā)出設(shè)備注冊請求、完成RO和加密后的數(shù)字版 權(quán)信息的請求與接收、加密后的數(shù)字信息產(chǎn)品解密，并控制客戶端設(shè)備以RO賦予的 權(quán)限使用數(shù)字信息產(chǎn)品。這就是DRM系統(tǒng)的基本思想。
從上述DRM的基本思想可以看出，客戶端設(shè)備的注冊、RO生成以及CEK的管理 在整個(gè)DRM系統(tǒng)中具有重要作用。在目前的DRM系統(tǒng)中，對(duì)客戶端設(shè)備的注冊已經(jīng)有了較為完善的定義；對(duì)R0的請求、生成與接收機(jī)制定義過于簡單，缺少的必要
RO撤銷與更新機(jī)制；沒有明確的CEK生成機(jī)制；也沒有一個(gè)有效的機(jī)制來保證CEK
在RO處理模塊與CEK生成模塊之間的安全傳輸。這樣容易造成CEK管理不善、易泄
漏等問題；對(duì)RO的管理也缺乏靈活性，不能很好的滿足市場和客戶的需求。

發(fā)明內(nèi)容
針對(duì)上述現(xiàn)有技術(shù)中存在的缺陷，本發(fā)明所要解決的技術(shù)問題是提供一種能同 時(shí)響應(yīng)并完成多個(gè)客戶端設(shè)備注冊請求的，有效管理CEK的，安全傳輸CEK的，靈 活管理RO的數(shù)字版權(quán)管理中的密鑰管理系統(tǒng)(Key Management System簡稱KMS) 及其方法。
為了解決上述技術(shù)問題，本發(fā)明所提供的一種數(shù)字版權(quán)管理中的密鑰管理系統(tǒng)， 其特征在于，包括注冊子系統(tǒng)、RO處理子系統(tǒng)和CEK生成子系統(tǒng)，所述注冊子系統(tǒng) 用于響應(yīng)至少一個(gè)客戶端設(shè)備的注冊請求，并完成對(duì)具有DRM Agent的客戶端設(shè)備 的注冊；R0處理子系統(tǒng)響應(yīng)R0請求，根據(jù)請求的類型做出RO生成、撤銷、更新等 處理；密鑰生成子系統(tǒng)響應(yīng)來自中間件CEK請求，生成相應(yīng)的CEK并作加密保護(hù)； 三個(gè)子系統(tǒng)分別通過通信接口 Interface與外部包括版權(quán)發(fā)布系統(tǒng)RDS、中間件MWS 等其它DRM模塊進(jìn)行通信。
進(jìn)一步的，所述注冊子系統(tǒng)的注冊包括由客戶為了使用DRM系統(tǒng)保護(hù)的數(shù)字信 息產(chǎn)品而主動(dòng)發(fā)起的和DRM Agent在客戶端設(shè)備開機(jī)自檢時(shí)發(fā)現(xiàn)沒有RI Context而 發(fā)起的；所述RI Context是指存儲(chǔ)在客戶端設(shè)備上的關(guān)于版權(quán)發(fā)型者RI (Rights Issuer)的信息，包括RI ID、 RI Certificate和RI URL;其中所述RI ID是指RI 在DRM系統(tǒng)的唯一標(biāo)示，所述RI Certificate是指RI的公鑰證書，所述RI URL是 指RI的網(wǎng)絡(luò)地址址。這些信息對(duì)于客戶端設(shè)備申請RO至關(guān)重要。
進(jìn)一步的，所述注冊過程完成后，KMS通知版權(quán)發(fā)布系統(tǒng)RDS (Right Distribution System)將Device ID、 Device Certificate等客戶端設(shè)備相關(guān)信息存儲(chǔ)到設(shè)備數(shù)據(jù)庫DDB(Device Database)、公鑰數(shù)據(jù)庫PKDB(Public Key Database) 等數(shù)據(jù)庫中；DRM Agent在客戶端設(shè)備本地生成RI Context,其中所述Device ID 是指客戶端設(shè)備在DRM系統(tǒng)中的唯一標(biāo)示，所述Device Certificate是指客戶端設(shè) 備的公鑰證書。
進(jìn)一步的，所述注冊子系統(tǒng)采用4-pass注冊協(xié)議。
本發(fā)明所述的一種數(shù)字版權(quán)管理中的密鑰管理系統(tǒng)中，注冊子系統(tǒng)響應(yīng)并完成 注冊的方法，其特征在于，處理過程如下
1) DRM Agent通過RDS向KMS發(fā)出注冊預(yù)請求Device Hello,其中包含Device ID等相關(guān)信息，提出預(yù)審請；
2) KMS收到Device Hello后，為了支持對(duì)一個(gè)以上的客戶端設(shè)備并發(fā)注冊， KMS將每個(gè)注冊流程標(biāo)記為一個(gè)會(huì)話，并為其分配一個(gè)Session ID;同時(shí)生成一具 有安全意義的隨機(jī)數(shù)RI Nonce，通過RDS向DRM Agent發(fā)出注冊預(yù)請求響應(yīng)RI Hello; 所述RI Hello中除了包括Session ID、 RI Nonce等參數(shù)外，還包括RI ID等相關(guān)
3) DRM Agent根據(jù)接收到的RI Hello判斷，若預(yù)申請成功，繼續(xù)向KMS發(fā)出 注冊請求Registration Request,其中包含Session ID、 一個(gè)具有安全意義隨機(jī)數(shù) Device Nonce、注冊申請時(shí)間Request time;若DRM后臺(tái)服務(wù)器系統(tǒng)沒有客戶端設(shè) 備的公鑰證書，Registration Request還要包含客戶端設(shè)備的公鑰證書； Registration Request還包括采用客戶端設(shè)備私鑰對(duì)Device Hello、 RI Hello以 及Registration Request中其它部分進(jìn)行的簽名。
4) KMS接到Registration Request后，進(jìn)行相應(yīng)的處理，并發(fā)出相應(yīng)的注冊 響應(yīng)Registration Response; Registration Response中包含RI亂重要信息； 若客戶端設(shè)備沒有RI的公鑰證書，Registration Response中還要包括RI的公鑰 證書；Registration Response還包含采用RI禾厶鑰對(duì)Registration Request和Registration Response中其它部分進(jìn)行的簽名。
本發(fā)明所述的一種數(shù)字版權(quán)管理中的密鑰管理系統(tǒng)中，R0處理子系統(tǒng)響應(yīng)RO 請求的處理方法，其特征在于，其中-
所述RO處理子系統(tǒng)響應(yīng)DRM Agent的RO請求RO Request并作出相應(yīng)處理的流 程如下
1) DRM Agent通過RDS向KMS提出RO Request,
本步驟中RO Request請求的RO有兩種情況，其一，DRM Agent請求的是All R0， 也即請求內(nèi)容既包括使用權(quán)限，也包括CEK;其二， DRM Agent請求的是只包含CEK 的CRO;
2) KMS中的RO處理子系統(tǒng)通過RDS向DRM Agent發(fā)出增加RO響應(yīng)Add RO Response
根據(jù)l)中請求RO的不同，本步驟中KMS作出的處理也不盡相同；當(dāng)請求的RO 為步驟1)中所述的第一種情況時(shí)，即請求內(nèi)容既包括使用權(quán)限，也包括CEK， RO 處理子系統(tǒng)根據(jù)請求的權(quán)限信息生成PRO;根據(jù)RO Request所請求的節(jié)目內(nèi)容和RDS 一并發(fā)送過來的加密策略，為其生成CRO;然后，將PRO和CRO—并通過RDS發(fā)送 給DRMAgent。當(dāng)請求的R0為步驟1)中所述的第二種情況時(shí)，即請求內(nèi)容只包含 CEK的CRO，RO處理子系統(tǒng)只需像上述那樣根據(jù)RO Request所請求的節(jié)目內(nèi)容和RDS 一并發(fā)送過來的加密策略，生成CRO，無需生成PRO;此后，將CRO通過RDS發(fā)送給 臓Agent;
所述RO處理子系統(tǒng)響應(yīng)RDS請求生成RO的流程如下
RO處理子系統(tǒng)直接從RDS得到生成RO所需的信息；當(dāng)請求內(nèi)容既包括使用權(quán) 限，也包括CEK， RO處理子系統(tǒng)根據(jù)請求的權(quán)限信息生成PRO;根據(jù)RO Request所 請求的節(jié)目內(nèi)容和RDS—并發(fā)送過來的加密策略，為其生成CRO;然后，將PRO和 CRO —并發(fā)送給RDS;當(dāng)請求內(nèi)容只包含CEK的CRO， RO處理子系統(tǒng)只需像上述那樣根據(jù)R0 Request所請求的節(jié)目內(nèi)容和RDS—并發(fā)送過來的加密策略，生成CRO,無 需生成PR0;此后，將CRO發(fā)送給RDS;
所述RO處理子系統(tǒng)根據(jù)RDS請求做出撤銷客戶終端設(shè)備RO響應(yīng)的流程如下 根據(jù)RDS的請求信息，做出相應(yīng)處理，通過RDS向DRM Agent發(fā)出撤銷客戶端設(shè)備 RO的響應(yīng)RO Delete Response。這里與Add RO Response不同是，RO Delete Response 中無需包含PRO或CRO，只要包含足夠的信息就可以。這些信息可以是RO ID、 Device ID、 Content ID、 RO Type等或其中幾項(xiàng)，只要確且地指明所要?jiǎng)h除RO (可以是一 個(gè)或一組)即可。這里，RO ID是RO的唯一標(biāo)示；Content ID是數(shù)字信息產(chǎn)品在 DRM系統(tǒng)中的唯一標(biāo)示；RO Type表明RO的類型，是PRO還是CRO;
所述RO處理子系統(tǒng)根據(jù)RDS請求做出更新客戶端設(shè)備RO響應(yīng)的流程如下根 據(jù)RDS的請求信息，生成新的PRO或CRO,通過RDS向DRM Agent發(fā)出更新客戶端 設(shè)備RO的響應(yīng)RO Update Response。 DRM Agent接到更新RO的響應(yīng)后，用新的RO 覆蓋舊R0。
進(jìn)一步的，所述RO處理子系統(tǒng)響應(yīng)DRM Agent的RO Request的處理流程的步 驟1)中，RDS向KMS轉(zhuǎn)發(fā)RO Request時(shí)，會(huì)對(duì)其進(jìn)行封裝；經(jīng)封裝后的RO Request 不僅包括DRM Agent發(fā)出的RO Request,還包括KMS為了對(duì)RO Request響應(yīng)而必 需的加密策略。所述加密策略包括DRM Agent所申請RO對(duì)應(yīng)數(shù)字信息產(chǎn)品的CEK的 相關(guān)信息，當(dāng)然所述的CEK是采用KMS的公鑰依據(jù)[X. 944]和[IETF-EKM]中定義的密 鑰交換算法加密保護(hù)加密保護(hù)的。
進(jìn)一步的，所述RO處理子系統(tǒng)將RO分為PRO (Permission R0，權(quán)限RO)和 CRO (CEKRO，密鑰RO)，其中PRO只包含數(shù)字信息產(chǎn)品使用控制權(quán)限，CRO只包含 數(shù)字信息產(chǎn)品CEK， CRO中的CEK采用客戶端設(shè)備公鑰依據(jù)[X. 944]和[IETF-EKM]中 定義的密鑰交換算法加密保護(hù)；CRO和PRO相關(guān)聯(lián)， 一個(gè)以上的CRO可以公用一個(gè) PRO。這樣，當(dāng)只有CEK更換時(shí)，只需更新CRO;當(dāng)只更新權(quán)限時(shí)，只需更新PRO。R0分為PRO和CRO對(duì)減輕DRM后臺(tái)服務(wù)系統(tǒng)和DRM Agent負(fù)擔(dān)、減輕對(duì)網(wǎng)絡(luò)的壓力 有顯著作用。
本發(fā)明所述的一種數(shù)字版權(quán)管理中的密鑰生成子系統(tǒng)響應(yīng)中間件CEK請求做出 處理方法，其特征在于，處理過程如下
1) 中間件向KMS發(fā)送密鑰請求，
中間件向KMS發(fā)送的密鑰請求有以下兩種情況其一，中間件向KMS請求新的 CEK，此時(shí)請求信息中包括所請求密鑰的長度、請求CEK設(shè)備的公鑰證書；其二，中 間件向KMS請求舊CEK，此時(shí)請求信息中要包括采用KEKkms加密保爐的CEK和請求 CEK設(shè)備的公鑰證書；
2) KMS對(duì)中間件的密鑰請求作出響應(yīng)，
針對(duì)步驟1)中請求信息兩種不同的情況，KMS作出的響應(yīng)不盡相同。當(dāng)步驟1) 中請求為上述第一種情況即請求新的CEK時(shí)，KMS中的密鑰生成子系統(tǒng)生成新的密 鑰，采用KEKKMs對(duì)新生成的密鑰進(jìn)行對(duì)稱加密保護(hù)得到Keyl;采用密鑰請求中的公 鑰對(duì)新生成的密鑰依據(jù)[X. 944]和[IETF-EKM]中定義的密鑰交換算法加密保護(hù)得到 Key2;將Keyl和Key2—并發(fā)送給中間件；當(dāng)步驟1)中請求為上述第二種情況即 請求舊CEK時(shí)，密鑰生成子系統(tǒng)無需生成新密鑰，只需將KEKkms加密保爐的CEK的 解密出來，并用請求信息中公鑰信息對(duì)CEK進(jìn)行加密保護(hù)即可，當(dāng)然加密仍是依據(jù) [X. 944]和[IETF-EKM]中定義的密鑰交換算法，將得到的Key發(fā)送給中間件。
進(jìn)一步的，所述CEK的產(chǎn)生包括隨機(jī)數(shù)發(fā)生器產(chǎn)生和軟件產(chǎn)生兩種方法；所述 CEK的加密保護(hù)依據(jù)[X. 944]和[IETF-EKM]中定義的密鑰交換算法，所述KEKre是該 算法中采用的KEK (Key Encryption Key)。
以上所述就是KMS各個(gè)模塊的功能和處理流程。當(dāng)然KMS作為一個(gè)完整的系統(tǒng)， 對(duì)外部其它系統(tǒng)來說只有一個(gè)接口， KMS內(nèi)部的三個(gè)子系統(tǒng)通過這個(gè)接口與外部其 它系統(tǒng)通信。KMS通過對(duì)該接口接收到的請求進(jìn)行判斷，然后分別交給相應(yīng)的子系統(tǒng)進(jìn)行處理。
采用本發(fā)明提出的數(shù)字版權(quán)管理中的密鑰管理系統(tǒng)及其方法，可以同時(shí)響應(yīng)多
個(gè)客戶端設(shè)備的注冊請求，并完成對(duì)多個(gè)客戶端的注冊；響應(yīng)RO的生成、撤銷、更
新請求并作出相應(yīng)的處理，實(shí)現(xiàn)對(duì)R0的靈活有效管理；響應(yīng)CEK請求生成相應(yīng)的
CEK并作加密保護(hù)，保證CEK在DRM系統(tǒng)內(nèi)各模塊之間安全傳輸。


圖1是本發(fā)明實(shí)施例密鑰管理系統(tǒng)KMS整體結(jié)構(gòu)框圖2是本發(fā)明實(shí)施例密鑰管理系統(tǒng)KMS工作的總體流程圖3是本發(fā)明實(shí)施例KMS中注冊子系統(tǒng)完成對(duì)客戶端設(shè)備注冊的流程圖4是本發(fā)明實(shí)施例KMS中R0處理子系統(tǒng)處理DRM Agent R0 Request的流程
圖5是本發(fā)明實(shí)施例KMS中R0處理子系統(tǒng)處理RDS關(guān)于R0相關(guān)操作請求的流 程圖6是本發(fā)明實(shí)施例KMS中密鑰生成子系統(tǒng)處理中間件CEK請求的流程圖。
具體實(shí)施例方式
以下結(jié)合

對(duì)本發(fā)明的實(shí)施例作進(jìn)一步詳細(xì)描述，但本實(shí)施例并不用于 限制本發(fā)明，凡是采用本發(fā)明的相似結(jié)構(gòu)、方法及其相似變化，均應(yīng)列入本發(fā)明的 保護(hù)范圍。
本發(fā)明提出的KMS，用來響應(yīng)客戶端設(shè)備的注冊請求，并根據(jù)請求完成對(duì)客戶 端設(shè)備的注冊；響應(yīng)R0的生成、撤銷、更新請求并作出相應(yīng)的處理，實(shí)現(xiàn)對(duì)RO的 靈活有效管理；響應(yīng)CEK請求，生成相應(yīng)的CEK并作加密保護(hù)，保證CEK在DRM系 統(tǒng)內(nèi)各模塊之間安全傳輸。其特征有以下四個(gè)方面第一，KMS由注冊子系統(tǒng)、R0 處理子系統(tǒng)和密鑰生成子系統(tǒng)構(gòu)成；第二，注冊子系統(tǒng)可以對(duì)多個(gè)客戶端設(shè)備進(jìn)行 并發(fā)注冊；第三，對(duì)R0的請求、生成、撤銷與更新機(jī)制做了完善的定義；第四，對(duì)CEK的生成與加密保護(hù)機(jī)制做了明確的定義。
所述R0處理子系統(tǒng)主要解決R0生成、撤銷、更新等問題；具體來說完成以下 三個(gè)功能其一，應(yīng)DRM Agent或者RDS版權(quán)請求R0 Request,生成新的R0，通過 RDS向DRM Agent發(fā)出Add RO Response;其二，應(yīng)RDS撤銷客戶端設(shè)備RO請求， 做出相應(yīng)處理，通過RDS向DRM Agent發(fā)出RO Delete Response;其三，應(yīng)RDS更 新客戶端設(shè)備RO請求，做出相應(yīng)處理，通過RDS向DRM Agent發(fā)出RO Update Response;上述三項(xiàng)功能中，目前的DRM系統(tǒng)對(duì)第一項(xiàng)功能有了較為完善的定義； 而第二項(xiàng)功能則是本發(fā)明出于實(shí)際應(yīng)用中有可能要撤銷已發(fā)放RO而提出的；第三項(xiàng) 功能則是本發(fā)明考慮到CEK更換(包括定期更換和應(yīng)急更換)或者使用權(quán)限更新而 提出的。
圖l是本發(fā)明提出的密鑰管理系統(tǒng)的整體結(jié)構(gòu)圖，該圖也表明了KMS在DRM系 統(tǒng)中的位置。如圖l所示，KMS由注冊子系統(tǒng)、R0處理子系統(tǒng)、密鑰生成子系統(tǒng)構(gòu) 成。KMS還包含一個(gè)通信接口 Interface,三個(gè)子系統(tǒng)分別通過Interface與外部其 它D賜模塊通信；Interface還具有根據(jù)通信協(xié)議對(duì)接收到的信息進(jìn)行解封裝、對(duì) 發(fā)送信息進(jìn)行封裝的作用。圖1還說明KMS與DRM系統(tǒng)中的版權(quán)發(fā)布系統(tǒng)RDS、中 間件之間有通信聯(lián)系，表明了 KMS在整個(gè)DRM系統(tǒng)中的位置。
圖2是本發(fā)明實(shí)施例KMS的整體流程圖?？傮w處理流程如下KMS Interface 從RDS、中間件接收請求信息；通過判斷消息類型將請求信息分別交給注冊子系統(tǒng)、 RO處理子系統(tǒng)、密鑰生成子系統(tǒng)進(jìn)行處理；處理完成后，KMS Interface將處理結(jié) 果發(fā)送給RDS、中間件。
圖3是本發(fā)明實(shí)施例中注冊子系統(tǒng)完成客戶端設(shè)備注冊的流程圖，其中EDN是 指邊緣發(fā)布節(jié)點(diǎn)(Edge Distribution Note)的英文縮寫，EDN只對(duì)請求與響應(yīng)信 息起轉(zhuǎn)發(fā)作用，不對(duì)請求與響應(yīng)信息作修改；RDS會(huì)根據(jù)通信協(xié)議對(duì)注冊請求與響 應(yīng)信息做一些封裝與處理。如圖3所示，KMS完成對(duì)客戶端設(shè)備注冊的流程如下步驟1) DRM Agent通過RDS向KMS發(fā)出Device Hello，其中包含Device ID 等相關(guān)信息，提出預(yù)審請。
步驟2) KMS收到Device Hello后，為其分配一個(gè)Session ID;同時(shí)生成一具 有安全意義的隨機(jī)數(shù)RI Nonce，通過RDS向DRM Agent發(fā)出RI Hello; RI Hello 中除了包括Session ID、 RI Nonce等參數(shù)外，還包括RI ID等相關(guān)信息。
步驟3) DRM Agent根據(jù)接收到的RI Hello判斷，若預(yù)申請成功，繼續(xù)向KMS 發(fā)出Registration Request,其中包含Session ID、一個(gè)具有安全意義隨機(jī)數(shù)Device Nonce、注冊申請時(shí)間Request time;若DRM后臺(tái)服務(wù)器系統(tǒng)沒有客戶端設(shè)備的公 鑰證書，Registration Request還要包含客戶端設(shè)備的公鑰證書；Registration Request還包括采用客戶端設(shè)備私鑰對(duì)Device Hello、 RI Hello以及Registration Request中其它部分進(jìn)行的簽名。
步驟4) KMS接到Registration Request后，進(jìn)行相應(yīng)的處理，并發(fā)出相應(yīng)的 Registration Response; Registration Response中包含RI亂重要信息；若客 戶端設(shè)備沒有RI的公鑰證書，Registration Response中還要包括RI的公鑰證書； Registration Response 還包含采用 RI 私鑰對(duì) Registration Request 禾口 Registration Response中其它部分進(jìn)行的簽名。
由于KMS可以同時(shí)接收多個(gè)客戶端設(shè)備的注冊請求，因此在某一具體時(shí)刻注冊 子系統(tǒng)需要判斷接收到的注冊請求信息是Device Hello還是Registration Request,然后分別做出相應(yīng)處理。
圖4是本發(fā)明實(shí)施例中R0處理子系統(tǒng)響應(yīng)DRM Agent R0 Request的流程圖。 圖4中的R0請求包括A11 R0請求與CR0請求兩種情況。具體處理流程如下所述
步驟1) DRM Agent通過RDS向KMS提出R0 Request
本步驟中R0 Request請求的R0有All R0與CR0兩種情況，All R0請求同時(shí) 請求pro與CRO。 RDS向KMS轉(zhuǎn)發(fā)R0 Request時(shí)，會(huì)對(duì)其進(jìn)行封裝。經(jīng)封裝后的R0Request不僅包括DRM Agent發(fā)出的RO Request,還包括KMS為了對(duì)RO Request響 應(yīng)而必需的加密策略。這里的加密策略主要包括DRM Agent所申請RO對(duì)應(yīng)數(shù)字信息 產(chǎn)品的CEK的相關(guān)信息，當(dāng)然這里的CEK是采用KMS的公鑰依據(jù)[X. 944]和[IETF-EKM] 中定義的密鑰交換算法加密保護(hù)的。
步驟2) KMS中的RO處理子系統(tǒng)通過RDS向DRM Agent發(fā)出Add RO Response 當(dāng)步驟l)中請求All RO時(shí)，RO處理子系統(tǒng)根據(jù)請求的權(quán)限信息生成PRO，同 時(shí)根據(jù)RO Request所請求的節(jié)目內(nèi)容和RDS —并發(fā)送過來的加密策略為其生成CRO; 然后，將PRO和CRO —并通過RDS發(fā)送給DRM Agent。當(dāng)步驟1)中只請求CRO時(shí)， RO處理子系統(tǒng)只需像上述那樣生成CRO，無需生成PRO;此后，將CRO通過RDS發(fā) 送給DRM Agent 。 RDS在轉(zhuǎn)發(fā)Add RO Response時(shí)，會(huì)根據(jù)通信協(xié)議對(duì)其進(jìn)行一些封 裝處理。
CEK定期更換或者應(yīng)急更換對(duì)于保護(hù)CEK的安全性、保證RI的合法權(quán)益是必要 的。為了便于RO更新，本發(fā)明提出數(shù)字信息產(chǎn)品使用控制權(quán)限與數(shù)字信息產(chǎn)品CEK 相分離的思想，將RO分為PRO (Permission RO)和CRO (CEK RO),其中PRO只包 含數(shù)字信息產(chǎn)品使用控制權(quán)限，CRO只包含數(shù)字信息產(chǎn)品CEK, CRO中的CEK采用客 戶端設(shè)備公鑰依據(jù)[X.944]和[IETF-EKM]中定義的密鑰交換算法加密保護(hù)。CRO和 PRO相關(guān)聯(lián)，多個(gè)CRO可以公用一個(gè)PRO。這樣，當(dāng)只有CEK更換時(shí)，只需更新CRO; 當(dāng)只更新權(quán)限時(shí)，只需更新PRO。 RO分為PRO和CRO對(duì)減輕DRM后臺(tái)服務(wù)系統(tǒng)和DRM Agent負(fù)擔(dān)、減輕對(duì)網(wǎng)絡(luò)的壓力有顯著作用。
圖5是本發(fā)明實(shí)施例中RO處理子系統(tǒng)響應(yīng)RDS請求向DRM Agent發(fā)出 Add/Delete/Update RO Response響應(yīng)的流程圖。圖5與圖4不同之處在于圖5中 的Add/Delete/Update RO Response無需DRM Agent的請求，是RDS以推的方式發(fā) 送給終端的。圖5中的Add RO Response用于RO預(yù)發(fā)布；Delete RO Response用 于通知DRM Agent撤銷客戶端設(shè)備上的RO; Update RO Response用于通知DRM Agent更新客戶端設(shè)備上的R0。
R0處理子系統(tǒng)根據(jù)RDS請求生成R0的流程與圖4中流程基本相似；不同的是 R0處理子系統(tǒng)根據(jù)RDS請求生成R0的流程中沒有上述的步驟1) ， RO處理子系統(tǒng) 直接從RDS得到生成RO所需的信息，并采用上述步驟2)中的方式生成相應(yīng)的RO。
R0處理子系統(tǒng)根據(jù)RDS請求做出撤銷客戶終端設(shè)備RO響應(yīng)的流程如下根據(jù) RDS的請求信息，作出處理，通過RDS向DRM Agent發(fā)出撤銷客戶端設(shè)備RO的響應(yīng) RO Delete Response。這里請求信息與RO Delete Response中均無需包含PRO或 CRO，只要包含足夠的信息就可以。這些信息可以是ROID、 Device ID、 Content ID、 RO Type等或其中幾項(xiàng)，只要確且地指明所要?jiǎng)h除RO (可以是一個(gè)或一組)即可。
RO處理子系統(tǒng)根據(jù)RDS請求做出更新客戶端設(shè)備RO響應(yīng)的流程如下根據(jù)RDS 的請求信息，生成新的PRO或CRO，通過RDS向DRM Agent發(fā)出更新客戶端設(shè)備RO 的響應(yīng)RO Update Response。
圖6是本發(fā)明實(shí)施例中密鑰生成子系統(tǒng)處理中間件MWS (Middleware System) CEK請求的流程圖，這里的CEK包括新CEK和舊CEK兩種情況。本實(shí)施例中密鑰采 用隨機(jī)數(shù)發(fā)生器產(chǎn)生；CEK的加密保護(hù)依據(jù)[X.944]和[IETF-EKM]中定義的密鑰交換 算法，下面所述的KEKKMs就是該算法中采用KEK (Key Encryption Key)。密鑰生成 子系統(tǒng)處理CEK請求的流程如下
步驟l)中間件向KMS發(fā)送密鑰請求New/Old CEK Request,
New CEK Request請求信息中包括所請求密鑰的長度、請求CEK設(shè)備的公鑰證 書；Old CEK Request請求信息中要包括采用KEKkms加密保爐的CEK和請求CEK設(shè)備 的公鑰證書。
步驟2) KMS對(duì)中間件的密鑰請求作出響應(yīng)New/Old CEK Response, 當(dāng)請求為New CEK Request時(shí)，KMS中的密鑰生成子系統(tǒng)生成新的密鑰，釆用 KEKkms對(duì)新生成的密鑰進(jìn)行對(duì)稱加密保護(hù)得到Keyl;采用密鑰請求中的公鑰對(duì)新生成的密鑰依據(jù)[X.944]和[IETF-EKM]中定義的密鑰交換算法加密保護(hù)得到Key2;將 Keyl和Key2 —并發(fā)送給中間件。當(dāng)請求為Old CEK Response時(shí)，密鑰生成子系統(tǒng) 無需生成新密鑰，只需將KEK訓(xùn)s加密保護(hù)的CEK的解密出來，并用請求信息中公鑰 信息對(duì)CEK進(jìn)行加密保護(hù)即可，當(dāng)然仍是依據(jù)[X. 944]和[IETF-EKM]中定義的密鑰交 換算法，將得到的Key發(fā)送給中間件。
權(quán)利要求
1、一種DRM中的密鑰管理系統(tǒng)，其特征在于，包括注冊子系統(tǒng)、RO處理子系統(tǒng)和CEK生成子系統(tǒng)，所述注冊子系統(tǒng)用于響應(yīng)至少一個(gè)客戶端設(shè)備的注冊請求，并完成對(duì)具有DRM Agent的客戶端設(shè)備的注冊；RO處理子系統(tǒng)響應(yīng)RO請求，根據(jù)請求的類型做出RO生成、撤銷、更新等處理；密鑰生成子系統(tǒng)響應(yīng)來自中間件CEK請求，生成相應(yīng)的CEK并作加密保護(hù)；三個(gè)子系統(tǒng)分別通過通信接口與外部包括版權(quán)發(fā)布系統(tǒng)RDS、中間件MWS等其它DRM模塊進(jìn)行通信。
2、 根據(jù)權(quán)利要求1所述的DRM中的密鑰管理系統(tǒng)，其特征在于，所述注冊子 系統(tǒng)的注冊包括由客戶為了使用DRM系統(tǒng)保護(hù)的數(shù)字信息產(chǎn)品而主動(dòng)發(fā)起的和DRM Agent在客戶端設(shè)備開機(jī)自檢時(shí)發(fā)現(xiàn)沒有RI Context而發(fā)起的；所述RI Context 是指存儲(chǔ)在客戶端設(shè)備上的關(guān)于版權(quán)發(fā)型者RI(Rights Issuer)的信息，包括RI ID、 RI Certificate和RI URL;其中所述RI ID是指RI在DRM系統(tǒng)的唯一標(biāo)示，所述 RI Certificate是指RI的公鑰證書，所述RI URL是指RI的網(wǎng)絡(luò)地址址。
3、 根據(jù)權(quán)利要求2所述的DRM中的密鑰管理系統(tǒng)，其特征在于，所述注冊過 程完成后，KMS通知版權(quán)發(fā)布系統(tǒng)RDS將Device ID、 Device Certificate客戶端 設(shè)備相關(guān)信息存儲(chǔ)到設(shè)備數(shù)據(jù)庫DDB、公鑰數(shù)據(jù)庫PKDB數(shù)據(jù)庫中；DRM Agent在客 戶端設(shè)備本地生成RI Context,其中所述Device ID是指客戶端設(shè)備在DRM系統(tǒng)中 的唯一標(biāo)示，所述Device Certificate是指客戶端設(shè)備的公鑰證書。
4、 根據(jù)權(quán)利要求1所述的DRM中的密鑰管理系統(tǒng)，其特征在于，所述注冊子 系統(tǒng)采用4-pass注冊協(xié)議。
5、 一種權(quán)利要求1所述的密鑰管理系統(tǒng)中，所述注冊子系統(tǒng)響應(yīng)并完成注冊的 方法，其特征在于，處理過程如下1) DRM Agent通過RDS向KMS發(fā)出注冊預(yù)請求，其中包含Device ID等相關(guān)信息，提出預(yù)審請；2) KMS收到Device Hello后，為了支持對(duì)一個(gè)以上的客戶端設(shè)備并發(fā)注冊， KMS為每個(gè)注冊流程分配一個(gè)Session ID;同時(shí)生成一具有安全意義的隨機(jī)數(shù)RI Nonce，通過RDS向DRM Agent發(fā)出注冊預(yù)請求響應(yīng)；3) DRM Agent根據(jù)接收到的RI Hello判斷，若預(yù)申請成功，繼續(xù)向KMS發(fā)出 注冊請求，其中包含Session ID、 一個(gè)具有安全意義隨機(jī)數(shù)Device Nonce、注冊申 請時(shí)間Request time;若DRM后臺(tái)服務(wù)器系統(tǒng)沒有客戶端設(shè)備的公鑰證書，注冊請 求還應(yīng)包含客戶端設(shè)備的公鑰證書；注冊請求還應(yīng)包括采用客戶端設(shè)備私鑰對(duì) Device Hello、 RI Hello以及注冊請求中其它部分進(jìn)行的簽名。4) KMS接到注冊請求后，進(jìn)行處理，并發(fā)出注冊響應(yīng)；注冊響應(yīng)中包含RIURL 重要信息；若客戶端設(shè)備沒有RI的公鑰證書，注冊響應(yīng)中還應(yīng)包括RI的公鑰證書； 注冊響應(yīng)還應(yīng)包含采用RI私鑰對(duì)注冊請求和注冊響應(yīng)中其它部分進(jìn)行的簽名。
6、 一種權(quán)利要求1所述的密鑰管理系統(tǒng)中，所述R0處理子系統(tǒng)的處理方法， 其特征在于，其中所述R0處理子系統(tǒng)響應(yīng)DRM Agent的R0請求并作出相應(yīng)處理的流程1) DRM Agent通過RDS向KMS提出R0請求，本步驟中RO請求請求的RO有兩種情況，其一，DRM Agent請求的是All R0， 也即請求內(nèi)容既包括使用權(quán)限，也包括CEK;其二， DRM Agent請求的是只包含CEK 的CRO;2) KMS中的RO處理子系統(tǒng)通過RDS向DRM Agent發(fā)出Add RO Response, 當(dāng)請求的R0為步驟1)中所述的請求內(nèi)容既包括使用權(quán)限，也包括CEK時(shí)，RO處理子系統(tǒng)根據(jù)請求的權(quán)限信息生成PRO;根據(jù)RO請求所請求的節(jié)目內(nèi)容和RDS — 并發(fā)送過來的加密策略，為其生成CRO;然后，將PRO和CRO—并通過RDS發(fā)送給 DRM Agent;當(dāng)請求的RO為步驟1)中所述的請求內(nèi)容只包含CEK的CRO時(shí)，RO處理子系統(tǒng)只需像上述那樣根據(jù)R0請求所請求的節(jié)目內(nèi)容和RDS —并發(fā)送過來的加密 策略，生成CR0，無需生成PRO;此后，將CR0通過RDS發(fā)送給DRM Agent; 所述RO處理子系統(tǒng)響應(yīng)RDS請求生成RO的流程如下RO處理子系統(tǒng)直接從RDS得到生成RO所需的信息；當(dāng)請求內(nèi)容既包括使用權(quán) 限，也包括CEK， RO處理子系統(tǒng)根據(jù)請求的權(quán)限信息生成PRO;根據(jù)RO請求所請求 的節(jié)目內(nèi)容和RDS—并發(fā)送過來的加密策略，為其生成CRO;然后，將PRO和CRO 一并發(fā)送給RDS;當(dāng)請求內(nèi)容只包含CEK的CRO， RO處理子系統(tǒng)只需像上述那樣根 據(jù)RO請求所請求的節(jié)目內(nèi)容和RDS—并發(fā)送過來的加密策略，生成CRO，無需生成 PRO;此后，將CRO發(fā)送給RDS;所述RO處理子系統(tǒng)根據(jù)RDS請求做出撤銷客戶終端設(shè)備RO響應(yīng)的流程如下 根據(jù)RDS的請求信息，做出處理，通過RDS向DRM Agent發(fā)出撤銷客戶端設(shè)備 RO的響應(yīng)RO Delete Response;這些信息包括RO ID、 Device ID、 Content ID、 RO Type,只要確且地指明所要?jiǎng)h除RO即可；所述RO處理子系統(tǒng)根據(jù)RDS請求做出更新客戶端設(shè)備RO響應(yīng)的流程如下 根據(jù)RDS的請求信息，生成新的PRO或CRO，通過RDS向DRM Agent發(fā)出更新 客戶端設(shè)備RO的響應(yīng)RO Update Response; DRM Agent接到更新RO的響應(yīng)后，用 新的RO覆蓋舊R0。
7、 根據(jù)權(quán)利要求6所述的R0處理子系統(tǒng)的處理方法，其特征在于，所述RO處 理子系統(tǒng)響應(yīng)DRM Agent的RO請求的處理流程的步驟1)中，RDS向KMS轉(zhuǎn)發(fā)RO請 求時(shí)，會(huì)對(duì)其進(jìn)行封裝；經(jīng)封裝后的RO請求不僅包括DRM Agent發(fā)出的RO請求， 還包括KMS為了對(duì)RO請求響應(yīng)而必需的加密策略。
8、 根據(jù)權(quán)利要求6所述的R0處理子系統(tǒng)的處理方法，其特征在于，所述RO處 理子系統(tǒng)將RO分為PRO和CRO，其中PRO只包含數(shù)字信息產(chǎn)品使用控制權(quán)限，CRO 只包含數(shù)字信息產(chǎn)品CEK， CRO中的CEK采用客戶端設(shè)備公鑰依據(jù)[X. 944]和[IETF-EKM]中定義的密鑰交換算法加密保護(hù)；CR0和PRO相關(guān)聯(lián)， 一個(gè)以上的CR0 能公用一個(gè)PR0。
9、 一種權(quán)利要求1所述的密鑰管理系統(tǒng)中，所述密鑰生成子系統(tǒng)響應(yīng)中間件 CEK請求做出處理方法，其特征在于，處理過程如下1) 中間件向KMS發(fā)送密鑰請求，中間件向KMS發(fā)送的密鑰請求有以下兩種情況其一，中間件向KMS請求新的 CEK，此時(shí)請求信息中包括所請求密鑰的長度、請求CEK設(shè)備的公鑰證書；其二，中 間件向KMS請求舊CEK，此時(shí)請求信息中要包括采用KEKkms加密保爐的CEK和請求 CEK設(shè)備的公鑰證書；2) KMS對(duì)中間件的密鑰請求作出響應(yīng)，當(dāng)步驟l)中請求為新的CEK時(shí)，KMS中的密鑰生成子系統(tǒng)生成新的密鑰，采用 KEKKMS對(duì)新生成的密鑰進(jìn)行對(duì)稱加密保護(hù)得到Keyl;采用密鑰請求中的公鑰對(duì)新生 成的密鑰加密保護(hù)得到Key2;將Keyl和Key2—并發(fā)送給中間件；當(dāng)步驟1)中請 求為舊CEK時(shí)，密鑰生成子系統(tǒng)只需將KEKKMs加密保護(hù)的CEK的解密出來，并用請 求信息中公鑰信息對(duì)CEK進(jìn)行加密保護(hù)，將得到的Key發(fā)送給中間件。
10、 根據(jù)權(quán)利要求9所述的密鑰生成子系統(tǒng)的處理方法，其特征在于，所述CEK 產(chǎn)生包括隨機(jī)數(shù)發(fā)生器產(chǎn)生和軟件產(chǎn)生兩種生成方法；所述CEK的加密保護(hù)依據(jù) [X. 944]和[IETF-EKM]中定義的密鑰交換算法。
全文摘要
一種DRM的密鑰管理系統(tǒng)及其方法，涉及數(shù)字版權(quán)管理技術(shù)領(lǐng)域；所要解決的是完善CEK管理的技術(shù)問題；該密鑰管理系統(tǒng)，包括注冊子系統(tǒng)、RO處理子系統(tǒng)和CEK生成子系統(tǒng)，所述注冊子系統(tǒng)用于響應(yīng)至少一個(gè)客戶端設(shè)備的注冊請求，并完成對(duì)具有DRM Agent的客戶端設(shè)備的注冊；RO處理子系統(tǒng)響應(yīng)RO請求，根據(jù)請求的類型做出RO生成、撤銷、更新等處理；密鑰生成子系統(tǒng)響應(yīng)來自中間件CEK請求，生成相應(yīng)的CEK并作加密保護(hù)；三個(gè)子系統(tǒng)分別通過通信接口Interface與外部包括版權(quán)發(fā)布系統(tǒng)RDS、中間件MWS等其它DRM模塊進(jìn)行通信。本發(fā)明具有能同時(shí)響應(yīng)并完成多個(gè)客戶端設(shè)備注冊請求，有效管理CEK，安全傳輸CEK，靈活管理RO的特點(diǎn)。
文檔編號(hào)H04L9/08GK101459507SQ20081017716
公開日2009年6月17日 申請日期2008年12月4日 優(yōu)先權(quán)日2007年12月12日
發(fā)明者周玉潔, 飛 李 申請人:上海愛信諾航芯電子科技有限公司