數(shù)字權利管理的制作方法
【專利摘要】公開了一種控制由多個客戶端終端對經(jīng)加密的內(nèi)容的使用的方法，每個客戶端終端被提供有數(shù)字權利管理（DRM)客戶端和與所述DRM客戶端分離的內(nèi)容解密模塊。提供第一密鑰信息以供所述DRM客戶端中的一個或多個所選DRM客戶端使用，并且提供第二密鑰信息以供所述內(nèi)容解密模塊中的一個或多個所選內(nèi)容解密模塊使用。對內(nèi)容密鑰信息進行加密以形成經(jīng)加密的內(nèi)容密鑰信息，使得所述第二密鑰信息使所述內(nèi)容解密模塊中的所選內(nèi)容解密模塊能夠從經(jīng)加密的內(nèi)容密鑰信息恢復所述內(nèi)容密鑰信息。對經(jīng)加密的內(nèi)容密鑰信息進行進一步加密以形成經(jīng)超級加密的內(nèi)容密鑰信息，使得所述第一密鑰信息使所述DRM客戶端中的所選DRM客戶端能夠從經(jīng)超級加密的內(nèi)容密鑰信息恢復經(jīng)加密的內(nèi)容密鑰信息。還公開了對應的頭端和客戶端終端裝置。
【專利說明】數(shù)字權利管理
【技術領域】
[0001] 本發(fā)明涉及數(shù)字權利管理。特別地，本發(fā)明涉及在遞送到客戶端終端之前使用內(nèi) 容的加密在多個客戶端終端處對內(nèi)容的控制以及被遞送到客戶端終端以在對內(nèi)容進行解 密時使用的客戶端密鑰信息的控制。
【背景技術】
[0002] 隨著寬帶因特網(wǎng)訪問的可用性增加以及被提供有IP連接性的消費者設備的數(shù)目 增加，數(shù)字內(nèi)容(諸如音樂和電影）的分發(fā)已經(jīng)從使用諸如CD、DVD和藍光盤之類的物理內(nèi) 容載體轉到在線分發(fā)。典型地，在在線內(nèi)容獲取和分發(fā)中，消費者從零售商在線購買數(shù)字 內(nèi)容。在購買內(nèi)容之后，消費者可以從與零售商相關聯(lián)的下載服務提供商（DSP)下載該內(nèi) 容。由消費者使用以訪問從零售商獲取的內(nèi)容的設備在本文檔中被稱作客戶端終端(在文 獻中，客戶端終端也被稱作消費者場所裝備)。個人計算機、移動設備和付費電視機頂盒是 客戶端終端的示例。
[0003] 可以使用數(shù)字權利管理（DRM)系統(tǒng)來控制對數(shù)字內(nèi)容的訪問并實施內(nèi)容使用規(guī) 貝1J。在DRM系統(tǒng)中，在內(nèi)容被分發(fā)給消費者（S卩，被分發(fā)到消費者的客戶端終端)之前對該內(nèi) 容進行加密，以控制對該內(nèi)容的訪問。如果消費者購買內(nèi)容，則DSP生成針對該內(nèi)容的DRM 許可并將該DRM許可分發(fā)給消費者的客戶端終端。該DRM許可包含解密(或訪問)該內(nèi)容和 與該內(nèi)容相關聯(lián)的使用規(guī)則的集合所需的內(nèi)容密鑰。該DRM許可和經(jīng)加密的內(nèi)容被輸入到 客戶端終端處的DRM客戶端。DRM客戶端驗證該DRM許可中包含的使用規(guī)則。如果這些使 用規(guī)則被滿足，則DRM客戶端提供對該內(nèi)容的訪問，從而使客戶端終端能夠呈現(xiàn)該內(nèi)容。存 在多種不同類型的DRM系統(tǒng)，每一種具有其自身的內(nèi)容封裝方法、內(nèi)容加密方法、DRM許可 格式和內(nèi)容使用規(guī)則。
[0004] 典型地，DRM系統(tǒng)支持DRM域的構思。DRM域由一個或多個DRM客戶端構成，且與 包含該DRM域的DRM客戶端的客戶端終端相關聯(lián)。在下文中，與DRM域相關聯(lián)的客戶端終 端的域還將被稱作客戶端終端的域。例如，客戶端終端的域可以包括特定消費者所擁有的 多個客戶端終端。在從零售商購買內(nèi)容之后，關聯(lián)的DSP生成針對內(nèi)容和DRM域的DRM許 可。接下來，DSP將內(nèi)容和DRM許可分發(fā)給DRM域中的客戶端終端之一。DRM許可使DRM域 中的所有客戶端終端能夠訪問內(nèi)容。換言之，消費者可以將內(nèi)容和DRM許可從客戶端終端 的域中的一個客戶端終端拷貝到客戶端終端的域中的另一客戶端終端，從而允許該另一客 戶端終端訪問（或呈現(xiàn)）內(nèi)容而不用獲取新的DRM許可（并且在拷貝內(nèi)容和DRM許可的時刻 與使用該另一客戶端終端呈現(xiàn)內(nèi)容的時刻之間不需要在線連接)。典型地，DRM系統(tǒng)支持動 態(tài)DRM域，其中，DRM客戶端(及其關聯(lián)的客戶端終端）可以加入或離開DRM域。例如，消費 者可以被允許選擇客戶端終端的域中的客戶端終端，只要其總數(shù)不超過客戶端終端的預定 義最大數(shù)目即可。一般地，DRM客戶端(及其關聯(lián)的客戶端終端）可以與多于一個DRM域相 關聯(lián)。
[0005] 典型地，現(xiàn)有技術DRM系統(tǒng)允許任何DSP服務于客戶端終端處的DRM客戶端(在 DSP與關聯(lián)的DRM供應商有協(xié)議的假設下)。換言之，典型地，現(xiàn)有技術DRM系統(tǒng)允許任何 DSP管理與DRM客戶端相關聯(lián)的一個或多個DRM域（DRM域由每個DSP獨立地定義)、生成 DRM許可并將內(nèi)容和DRM許可分發(fā)給客戶端終端。
[0006] 在分發(fā)內(nèi)容之前，首先以DRM系統(tǒng)所支持的文件格式對內(nèi)容進行封裝。接下來，使 用DRM系統(tǒng)所支持的加密方法來對經(jīng)封裝的內(nèi)容進行加密。圖1示出了現(xiàn)有技術DSP 10 的示例，其包括內(nèi)容封裝模塊12和內(nèi)容加密模塊14。實踐中，內(nèi)容可能在其被遞送至DSP 時已經(jīng)被封裝和加密，例如，內(nèi)容提供商可能已經(jīng)執(zhí)行這些操作。
[0007] 圖1的DSP 10使用DRM密鑰管理模塊16來管理DRM客戶端。DRM密鑰管理模塊 生成密鑰管理消息。密鑰管理消息用于將密碼密鑰（不同于用于對使用DRM許可而分發(fā)的 內(nèi)容進行加密的密鑰，如稍后所詳述）分發(fā)給客戶端終端20,客戶端終端20包括DRM客戶 端22。例如，密鑰管理消息可以用于允許客戶端終端加入DRM域，如稍后所討論。
[0008] DRM許可由DSP 10處的DRM許可管理模塊18創(chuàng)建。DRM許可允許客戶端終端20 訪問與DRM許可相關聯(lián)的內(nèi)容。DRM許可與特定DRM客戶端相關聯(lián)，或與特定DRM域相關 聯(lián)。由于DRM域可以由單個DRM客戶端構成，因此與特定DRM客戶端相關聯(lián)的DRM密鑰管理 和DRM許可管理類似于與包括一個DRM客戶端的特定DRM域相關聯(lián)的DRM密鑰管理和DRM 許可管理。因此，為了易于闡述，本文檔中描述的示例不失一般性地假定DRM許可與DRM域 相關聯(lián)。
[0009] 在下文中，Ei(K，M)表示使用加密方法Ei和加密密鑰K對消息Μ的加密。加密方法 Ei由加密算法和該加密算法的操作模式定義。本文檔中描述的方案的加密方法Ei-般使 用對稱加密算法。對稱加密算法具有下述屬性：容易從加密密鑰導出解密密鑰以及反過來。 不失一般性，假定在本文檔中考慮的所有加密方法Ei中加密密鑰等于解密密鑰。例如，具有 128比特的塊大小和128比特的密鑰大小的公知的高級加密標準（AES)可以被用作針對在 本文檔中考慮的所有加密方法E i的加密算法。在這方面請參見NIST文檔"Specification for the advanced encryption standard (AES), Federal Information Processing Standards Publication 197， 2001"。
[0010] 實踐中，通常使用電子碼本（ECB)操作模式來對密鑰進行加密和解密。用于對內(nèi) 容進行加密和解密的操作模式取決于DRM系統(tǒng)的類型；用于對內(nèi)容進行加密和解密的兩種 流行模式是密碼塊鏈接模式和計數(shù)器模式。貫穿本文檔，Di(K，C)表示使用解密方法0 1和 密鑰K對密文C的解密，具有下述屬性：對于所有消息Μ以及對于所有密鑰K (并且對于在 本文檔中考慮的1的所有值)，〇1〇(31〇(，)）=皿。
[0011] 然而，如果期望的話，通過在必要時以本領域技術人員將熟知的方式對所描述的 實施例進行適當調(diào)整，可以使用非對稱加密算法(在文獻中也被稱作公鑰加密方案）以及或 取代對稱方案。
[0012] 受DRM系統(tǒng)保護的內(nèi)容(例如，電影)一般是使用內(nèi)容密鑰CK來加密的。為了對內(nèi) 容進行加密，DSP 10可以首先生成內(nèi)容密鑰CK (例如，AES密鑰）。DSP 10使用內(nèi)容加密函 數(shù)EjPCK來對該內(nèi)容進行加密，以產(chǎn)生經(jīng)加密的內(nèi)容E1(CK，內(nèi)容）。DSP 10將經(jīng)加密的 內(nèi)容存儲在包含可被分發(fā)給客戶端終端20的所有內(nèi)容的數(shù)據(jù)庫中。另外，DSP 10安全地 存儲內(nèi)容密鑰CK。
[0013] 如果客戶端終端20加入DRM域，則可以使用由DRM密鑰管理模塊16生成的密鑰 管理消息將DRM客戶端密鑰DCK分發(fā)給與該客戶端終端相關聯(lián)或被嵌入到該客戶端終端中 的DRM客戶端。這里假定DCK是對稱密鑰，但是取而代之，如果使用公鑰加密方案，則DCK可 以是非對稱密鑰對中的私鑰。該DCK是共享的密鑰，其中，DRM域中的所有客戶端終端需要 對該密鑰的訪問，以處理與DRM域相關聯(lián)的DRM許可。如果客戶端終端20是加入DRM域的 第一客戶端終端，則DRM密鑰管理模塊20可以首先生成DCK (例如，使用偽隨機數(shù)生成器)。 在將DCK分發(fā)給客戶端終端20之前，DRM密鑰管理模塊16典型地使用一個或多個更高級 DRM密鑰來保護DCK的機密性和真實性。例如，DRM密鑰管理模塊16可以使用更高級DRM 密鑰來對DCK進行加密，并使用另一更高級DRM密鑰來生成消息認證碼或數(shù)字簽名。該消 息認證碼或數(shù)字簽名可以被附加到經(jīng)加密的DCK，從而產(chǎn)生初始化消息DCKinit。一般地， DCKinit可以是與客戶端終端20相關聯(lián)的DRM客戶端能夠從其導出密鑰DCK的任何消息。 DRM密鑰管理模塊16將DCKinit包括在密鑰管理消息中，并將該密鑰管理消息分發(fā)給客戶 立而終纟而20。
[0014] 在一些情況下，密鑰DCK或DCKinit消息被預加載在DRM客戶端中（例如，在DRM 客戶端被安裝在客戶端終端20中之前，DCK或DCKinit可能已經(jīng)被加載在DRM客戶端中）。 如果DCK或DCKinit消息被預加載在DRM客戶端中，則不需要將包含DCKinit的密鑰管理 消息分發(fā)給客戶端終端20。另外，如果DCK被預加載在DRM客戶端中，則不需要生成對應的 DCKinit 消息。
[0015] 在消費者從零售商購買內(nèi)容之后，關聯(lián)的DSP 10生成與該內(nèi)容和DRM域相關聯(lián)的 DRM許可。為了做到這一點，DSP從安全儲存器檢索被用于對該內(nèi)容進行加密的內(nèi)容密鑰CK 和與DRM域相關聯(lián)的DCK。然后，使用DCK和加密函數(shù)E2來對內(nèi)容密鑰CK進行加密，從而 產(chǎn)生密文E 2 (DCK, CK)。該密文被包括在DRM許可中，DRM許可被分發(fā)給與DRM域相關聯(lián)的 客戶端終端20。DRM許可還可以包括內(nèi)容使用規(guī)則。
[0016] 由于DSP已經(jīng)存儲內(nèi)容密鑰CK，因此DSP 10可以針對不同DRM域生成包含相同內(nèi) 容密鑰CK的DRM許可。此外，由于與不同DRM域相關聯(lián)的DCK將不同，因此經(jīng)加密的內(nèi)容 密鑰將在這些DRM許可中不同，從而使DRM許可專用于DRM域。特別地，如果經(jīng)加密的內(nèi)容 被拷貝到另一 DRM域中的一個或多個客戶端終端(例如，如果使用對等網(wǎng)絡在不同DRM域之 間共享經(jīng)加密的內(nèi)容)，則可以針對該另一 DRM域生成新DRM許可并將該新DRM許可分發(fā)給 該另一 DRM域中的客戶端終端，從而使該另一 DRM域中的客戶端終端能夠呈現(xiàn)所拷貝的內(nèi) 容。另外，如果DSP 10在客戶端終端上(例如，在與不同DRM域相關聯(lián)的客戶端終端上）預 加載經(jīng)加密的內(nèi)容，則可以針對DRM域生成DRM許可并將該DRM許可分發(fā)給該DRM域中的 客戶端終端，以使該DRM域中的客戶端終端能夠呈現(xiàn)預加載的內(nèi)容。在現(xiàn)有技術中，這種分 發(fā)方法一般被稱作內(nèi)容超級分發(fā)。
[0017] 圖2示出了可在現(xiàn)有技術客戶端終端20處呈現(xiàn)內(nèi)容的一種方式。DRM客戶端22 首先在導出DCK函數(shù)30處從初始化消息DCKinit導出DCK，初始化消息DCKinit是在密鑰 管理消息31中遞送的。例如，導出DCK函數(shù)30可以使用更高級DRM密鑰來驗證初始化消 息的真實性，并且如果初始化消息是真實的，則導出DCK函數(shù)30可以使用更高級DRM密鑰 來對初始化消息進行解密，從而產(chǎn)生DCK。其次，將經(jīng)加密的內(nèi)容EJCK，內(nèi)容）和DRM許 可32輸入到DRM客戶端。如果DRM許可包含內(nèi)容使用規(guī)則，則DRM客戶端22驗證這些內(nèi) 容使用規(guī)則。如果內(nèi)容使用規(guī)則被滿足，則DRM客戶端使用解密函數(shù)D 2和DCK來對經(jīng)加密 的內(nèi)容密鑰E2(DCK，CK)進行解密，從而產(chǎn)生內(nèi)容密鑰CK。再次，DRM客戶端22使用內(nèi)容 解密函數(shù)〇1和內(nèi)容密鑰CK來對經(jīng)加密的內(nèi)容EJCK，內(nèi)容）進行解密，從而產(chǎn)生明文內(nèi)容 34,明文內(nèi)容34可以由客戶端終端20呈現(xiàn)。
[0018] 實踐中，典型地，現(xiàn)有技術DSP 10將DCK用于生成多個DRM許可32 (與DRM域的 多段內(nèi)容相關聯(lián))。這意味著：DRM域中的DRM客戶端22將DCK用于訪問經(jīng)加密的多段內(nèi) 容。如果重用DCK，則不需要隨每個DRM許可分發(fā)包含對應DCKinit消息的密鑰管理消息31 (回顧：如果密鑰DCK或DCKinit消息被預加載在DRM客戶端中，則不需要將包含DCKinit 的密鑰管理消息分發(fā)給客戶端終端20)。
[0019] 如果客戶端終端離開DRM域，則客戶端終端20可以刪除其存儲的與DRM域相關聯(lián) 的DCKinit消息和DCK，并且DSP(例如，其DRM密鑰管理模塊16)可以生成新DCK并使用新 DCKinit消息和新密鑰管理消息將該新DCK分發(fā)給DRM域中的其他客戶端終端。一般地， DSP和/或客戶端終端可以采取防止離開DRM域的客戶端終端進一步處理與DRM域相關聯(lián) 的DRM許可的任何動作。
[0020] 圖2中圖示的現(xiàn)有技術DRM客戶端22可以是以在客戶端終端中的集成電路上執(zhí) 行的軟件實現(xiàn)的?？商鎿Q地，現(xiàn)有技術DRM客戶端22可以被實現(xiàn)在可拆卸硬件模塊內(nèi)部。 可以使用軟件和/或硬件保護技術來使DRM客戶端防篡改和防讀取(例如，防止對手損害秘 密密鑰或修改內(nèi)容使用規(guī)則)。另外，可以實現(xiàn)用于將DRM客戶端22綁定/鎖定到客戶端 終端20的手段。這種手段可以防止對手使用DRM客戶端22不合法地在另一客戶端終端上 呈現(xiàn)明文內(nèi)容34 (S卩，在DRM域外部的客戶端終端上呈現(xiàn)明文內(nèi)容34)。
[0021] 出于性能原因，通常在硬件解密模塊(在現(xiàn)有技術文獻中也被稱作硬件加速器）中 實現(xiàn)內(nèi)容解密算法或方法。這種實現(xiàn)在圖3中示出，其中，DRM客戶端22輸出內(nèi)容密鑰CK。 內(nèi)容密鑰CK和經(jīng)加密的內(nèi)容Ei (CK，內(nèi)容）被提供作為對內(nèi)容解密模塊36的輸入。內(nèi)容 解密模塊使用內(nèi)容解密函數(shù)Di和內(nèi)容密鑰CK來對經(jīng)加密的內(nèi)容Ei (CK，內(nèi)容）進行解密， 從而產(chǎn)生明文內(nèi)容34，明文內(nèi)容34可以由客戶端終端20或連接到客戶端終端20的內(nèi)容呈 現(xiàn)設備呈現(xiàn)(例如，客戶端終端可以是連接到電視的付費TV機頂盒)。
[0022] 在圖3中描繪的示例中，假定內(nèi)容解密模塊36被實現(xiàn)在客戶端終端20的集成電 路中。DRM客戶端22可以被實現(xiàn)在相同集成電路中?？商鎿Q地，DRM客戶端22可以被實現(xiàn) 在客戶端終端20的分離的集成電路中，或者DRM客戶端22可以被實現(xiàn)在可拆卸硬件模塊 中。
[0023] 可以使用軟件和/或硬件保護技術來使DRM客戶端22和/或內(nèi)容解密模塊36防 篡改和防讀取(例如，防止對手損害秘密密鑰或修改內(nèi)容使用規(guī)則)。此外，可以實現(xiàn)用于防 護CK從DRM客戶端22分發(fā)給內(nèi)容解密模塊36的手段。例如，DRM客戶端22可以使用在 DRM客戶端與內(nèi)容解密模塊36之間共享的更高級密鑰來對內(nèi)容密鑰CK進行加密，并將經(jīng)加 密的內(nèi)容密鑰傳遞至內(nèi)容解密模塊(而不是將明文內(nèi)容密鑰CK傳遞至內(nèi)容解密模塊)。接 下來，內(nèi)容解密模塊36可以使用共享的更高級密鑰來對從DRM客戶端22接收到的經(jīng)加密 的內(nèi)容密鑰進行解密，從而產(chǎn)生明文內(nèi)容密鑰CK。
[0024] 另外，可以實現(xiàn)用于將DRM客戶端22綁定/鎖定到客戶端終端20的手段。這種 手段可以防止對手使用DRM客戶端22不合法地在另一客戶端終端上呈現(xiàn)明文內(nèi)容34(即， 在DRM域外部的客戶端終端上呈現(xiàn)明文內(nèi)容34)。例如，DRM客戶端22可以以下述這種方 式對CK進行加密：所得到的密文僅可以由客戶端終端22的內(nèi)容解密模塊36正確地解密 (例如，通過使用于對CK進行加密和解密的共享的更高級密鑰對DRM客戶端和內(nèi)容解密模 塊的該組合來說唯一)。
[0025] DRM客戶端22的實現(xiàn)（以及在使用硬件加速器的情況下，內(nèi)容解密算法或方法的 實現(xiàn))通常必須服從如DRM供給者所定義的DRM服從性和魯棒性規(guī)則的集合。例如，DRM供 給者可能要求：在客戶端終端20的制造(也被稱作客戶端終端的個性化）期間將唯一號碼 加載到客戶端終端20中。典型地，該唯一號碼用于將DRM客戶端22綁定/鎖定到客戶端 終端20。例如，DRM客戶端22可以實現(xiàn)用于驗證該唯一號碼的值并僅在該號碼的值如所期 望的那樣的情況下提供其功能的例程。
[0026] 在現(xiàn)有技術中頻繁地，DRM客戶端22可以在其操作階段期間被分發(fā)給客戶端終端 20 (例如，通過將包含DRM客戶端22的新的可拆卸硬件模塊分發(fā)給客戶端終端，或者通過 在客戶端終端處下載包含DRM客戶端22的新軟件圖像)。然而，僅在客戶端終端滿足關聯(lián) 的DRM供給者的DRM服從性和魯棒性規(guī)則的情況下，客戶端終端20才可以使用DRM客戶端 22。例如，DRM服從性和魯棒性規(guī)則可能要求：在客戶端終端的制造階段期間針對該類型的 DRM系統(tǒng)來對客戶端終端進行個性化。換言之，不能在客戶端終端上使用客戶端終端不滿足 關聯(lián)DRM服從性和魯棒性規(guī)則的DRM客戶端的類型。
[0027] 實踐中，客戶端終端制造商可以選擇特定類型的DRM系統(tǒng)并僅生廣?兩足針對該類 型的DRM系統(tǒng)的DRM服從性和魯棒性規(guī)則的客戶端終端，并且不同客戶端終端制造商從而 可以針對其客戶端終端選擇不同類型的DRM系統(tǒng)。由此，DSP可以對被嵌入到其想要服務 于的客戶端終端中的DRM系統(tǒng)的類型沒有影響。這意味著：DSP可能需要實現(xiàn)多個DRM系 統(tǒng)以服務于其客戶端終端群體。
[0028] 在客戶端終端群體中對多個DRM系統(tǒng)的使用可能具有多個缺陷，例如： 1. 內(nèi)容封裝方法和/或內(nèi)容加密方法可能專用于該類型的DRM系統(tǒng)。這可能意味著 DSP需要存儲經(jīng)加密的內(nèi)容的多個拷貝（例如，針對每種類型的DRM系統(tǒng)一個拷貝）。此外， 可能的情況是，在實現(xiàn)不同類型的DRM客戶端的設備之間不可能進行內(nèi)容分發(fā)； 2. 典型地，DRM許可是DRM系統(tǒng)專用的。這意味著：實現(xiàn)不同類型的DRM客戶端的兩 個客戶端終端不能處于相同DRM域中。例如，如果消費者擁有包括與兩種不同類型的DRM 系統(tǒng)相關聯(lián)的DRM客戶端的兩個客戶端終端，則需要兩個DRM許可能夠在這兩個客戶端終 端上呈現(xiàn)所獲取的內(nèi)容，而不是在客戶端終端將已處于相同DRM域中的情況下那樣需要一 個DRM許可； 3. DSP需要與所有關聯(lián)的DRM系統(tǒng)供給者有協(xié)定，并且DSP需要實現(xiàn)這些DRM系統(tǒng)（內(nèi) 容封裝、內(nèi)容加密、DRM密鑰管理和DRM許可管理）中的每一個。這可能增加 DSP或關聯(lián)零 售商的成本； 4. 系統(tǒng)安全性的級別由供應最低安全性級別的DRM系統(tǒng)的類型定義。
[0029] 如果DSP可以選擇和實現(xiàn)一種類型的DRM系統(tǒng)并將該類型的DRM系統(tǒng)的DRM客戶 端分發(fā)給其所服務于的每個客戶端終端，則可以解決如上列出的1至4點。這可以是使用 硬件分發(fā)(例如，通過分發(fā)包含DRM客戶端的可拆卸硬件模塊）以及或取代軟件分發(fā)(例如， 通過下載包含DRM客戶端的新軟件圖像）來實現(xiàn)的。這種分發(fā)機制還可以用于升級DRM客 戶端，例如提高安全性級別或擴展DRM系統(tǒng)的功能。另外，該分發(fā)機制使DSP能夠利用不同 的類型的DRM系統(tǒng)來替換其所使用的DRM系統(tǒng)，從而將新類型的DRM系統(tǒng)的DRM客戶端分 發(fā)給其所服務于的每個客戶端終端。例如，當另一類型的DRM系統(tǒng)供應更高安全性級別時， 這可以是期望的。具有這些屬性的DRM方案可以被稱作可交換DRM，并且對于可交換DRM系 統(tǒng)，需要用于將DRM客戶端鎖定/綁定到由多個DRM系統(tǒng)(也被稱作服從DRM系統(tǒng)）支持的 客戶端終端(或者到與DRM域相關聯(lián)的多個客戶端終端）的方法。
[0030] 作為示例，可以定義DRM客戶端與客戶端終端之間的挑戰(zhàn)-響應機制?？蛻舳私K 端實現(xiàn)該機制，從而使該客戶端終端能夠接收挑戰(zhàn)并生成對該客戶端終端來說唯一的對該 挑戰(zhàn)的響應。服從DRM系統(tǒng)的DRM客戶端也實現(xiàn)該機制，從而使DRM客戶端能夠通過將挑 戰(zhàn)發(fā)送至客戶端終端且通過僅在從客戶端終端接收到的響應如所期望的那樣的情況下提 供其功能來將其自身綁定/鎖定到客戶端終端?？商鎿Q地，對于圖3中所示的架構，鎖定/ 綁定機制可以基于由DRM客戶端使用在DRM客戶端與內(nèi)容解密模塊之間共享的更高級密鑰 對內(nèi)容密鑰CK的加密。如果共享的更高級密鑰對DRM客戶端和內(nèi)容解密模塊的該組合來 說唯一，則僅該內(nèi)容解密模塊能夠從DRM客戶端的輸出正確地導出CK。觀察到，這些示例要 求：在DRM客戶端中實現(xiàn)用于將DRM客戶端綁定/鎖定到客戶端終端的安全性手段。
[0031] 將期望在對現(xiàn)有DRM系統(tǒng)的架構具有較小影響的客戶端終端處提供經(jīng)加密的內(nèi) 容的DRM控制，使得需要極小努力使現(xiàn)有DRM系統(tǒng)變成服從DRM系統(tǒng)。
【發(fā)明內(nèi)容】
[0032] 在根據(jù)本發(fā)明的布置中，DRM客戶端是作為與客戶端終端的內(nèi)容解密模塊分離的 元件而提供的(如在圖3中所示的現(xiàn)有技術示例中那樣)。實踐中，該分離可以憑借不同且 分離的硬件或集成電路元件而進行，但是其也可以通過分離DRM客戶端和內(nèi)容解密模塊兩 者所使用的一個或多個集成電路和/或軟件程序和結構上的功能或電路而進行。此外，可 以利用被稱作內(nèi)容解密模塊的主密鑰的唯一秘密密鑰來對內(nèi)容解密模塊進行個性化。例 如，該主密鑰可以是對稱密鑰，或者其可以是非對稱密鑰對中的私鑰。主密鑰被用作在內(nèi) 容解密模塊中實現(xiàn)的機制的根密鑰，該機制使內(nèi)容解密模塊能夠接收和解密經(jīng)加密的內(nèi)容 密鑰CK或者更一般地接收和解密由客戶端終端中的內(nèi)容解密模塊使用以導出內(nèi)容密鑰 CK的經(jīng)加密的內(nèi)容密鑰信息CKI。這種機制的示例在ETSI TS 103 162 vl. 1.1 "Access, Terminals, Transmission and Multiplexing (ATTM): Integrated Broadband Cable and Television Networks: K-LAD Functional Specification〃中有描述。
[0033] 在本文檔中提出的方案中，DSP首先使用內(nèi)容解密模塊密鑰CDMK來對內(nèi)容密鑰CK 或內(nèi)容密鑰信息CKI進行加密，從而產(chǎn)生經(jīng)加密的CK或CKI。接下來，DSP使用DRM客戶端 密鑰DCK來對經(jīng)加密的CK或CKI進行超級加密，從而產(chǎn)生經(jīng)超級加密的CK或CKI。將經(jīng)超 級加密的CK或CKI包括在DRM許可中，并且將DRM許可分發(fā)給客戶端終端。在接收到DRM 許可之后，客戶端終端中的DRM客戶端使用DCK來對經(jīng)超級加密的CK或CKI進行解密，從 而產(chǎn)生經(jīng)加密的CK或CKI。DRM客戶端將經(jīng)加密的CK或CKI傳遞至內(nèi)容解密模塊。內(nèi)容 解密模塊使用內(nèi)容解密模塊密鑰CDMK和在內(nèi)容解密模塊中實現(xiàn)的機制來接收和解密經(jīng)加 密的CK或CKI，從而產(chǎn)生明文CK或CKI。
[0034] 超級加密方案確保明文CK或CKI在DRM客戶端內(nèi)部或在DRM客戶端與內(nèi)容解密 模塊之間的接口處不可用。
[0035] 盡管內(nèi)容解密模塊密鑰CDMK或內(nèi)容解密模塊能夠從其導出CDMK的初始化模式 CDMKinit可以被預加載在內(nèi)容解密模塊中（例如，CDMK可以是內(nèi)容解密模塊的主密鑰)，但 是優(yōu)選地，內(nèi)容解密模塊實現(xiàn)了使內(nèi)容解密模塊能夠在其操作階段期間接收和導出內(nèi)容解 密模塊密鑰CDMK (例如，由DSP生成的CDMK)的機制。這種機制使DSP能夠更新CDMK。例 如，DSP可能想要在CDMK已被損害之后更新CDMK。另外，這種機制可以用于管理內(nèi)容解密 模塊的動態(tài)域，如稍后詳述的那樣。下文中，內(nèi)容解密模塊的域也被稱作CDM域。CDM域用 于維持DRM系統(tǒng)的DRM域功能。換言之，CDM域使消費者能夠將來自一個客戶端終端的內(nèi) 容和對應DRM許可拷貝到DRM域中的另一客戶端終端，從而允許該另一客戶端終端在不獲 取新DRM許可的情況下（以及在不需要拷貝內(nèi)容和DRM許可的時刻與使用該另一客戶端終 端呈現(xiàn)內(nèi)容的時刻之間的在線連接的情況下）訪問（或呈現(xiàn)）內(nèi)容。典型地，CDM域與由DRM 域定義的客戶端終端的域相關聯(lián)。
[0036] 該新方案可以使用密鑰管理消息來允許內(nèi)容解密模塊加入CDM域和/或更新CDMK (例如，強制內(nèi)容解密模塊離開CDM域)。由這些附加密鑰管理消息導致的帶寬開銷可以很 小。
[0037] 所描述的超級加密方法將DRM域中的DRM客戶端鎖定/綁定到CDM域中的內(nèi)容解 密模塊。更精確地，DRM許可中的經(jīng)超級加密的CK或CKI的外加密將DRM許可鎖定/綁定 到特定DRM域中的DRM客戶端，其中，僅該DRM域中的DRM客戶端可以正確地移除該外加密。 DRM許可中的經(jīng)超級加密的CK或CKI的內(nèi)加密將DRM許可鎖定/綁定到CDM域中的內(nèi)容解 密模塊，其中，僅該CDM域中的內(nèi)容解密模塊可以正確地移除該內(nèi)加密。
[0038] 然后，通過超級加密進行的該鎖定/綁定由被設計成使用該方案的所有DRM系統(tǒng) (被稱作服從DRM系統(tǒng))使用。鎖定/綁定方法是間接的，其中，包含經(jīng)超級加密的CK或CKI 的DRM許可被鎖定到DRM域，并且該DRM許可被鎖定到CDM域。這意味著：與現(xiàn)有技術解決 方案不同，該新方法不要求DRM客戶端實現(xiàn)用于將DRM客戶端鎖定/綁定到特定客戶端終 端的安全性手段。此外，如稍后更詳細討論的那樣，該新方案可以對現(xiàn)有DRM系統(tǒng)的DRM客 戶端和DRM許可生成器來說透明。這些屬性意味著：對現(xiàn)有DRM系統(tǒng)需要微小改變或不需 要改變以服從該新方法。
[0039] 相應地，本發(fā)明提供了一種控制由多個客戶端終端對經(jīng)加密的內(nèi)容的使用的方 法，每個客戶端終端被提供有數(shù)字權利管理（DRM)客戶端和與所述DRM客戶端分離的內(nèi)容 解密模塊，所述方法包括：提供第一密鑰信息以供所述DRM客戶端中的一個或多個所選DRM 客戶端使用；提供第二密鑰信息以供所述內(nèi)容解密模塊中的一個或多個所選內(nèi)容解密模塊 使用；對內(nèi)容密鑰信息進行加密以形成經(jīng)加密的內(nèi)容密鑰信息，使得所述第二密鑰信息使 所述內(nèi)容解密模塊中的所選內(nèi)容解密模塊能夠從經(jīng)加密的內(nèi)容密鑰信息恢復所述內(nèi)容密 鑰信息；對經(jīng)加密的內(nèi)容密鑰信息進行加密以形成經(jīng)超級加密的內(nèi)容密鑰信息，使得所述 第一密鑰信息使所述DRM客戶端中的所選DRM客戶端能夠從經(jīng)超級加密的內(nèi)容密鑰信息恢 復經(jīng)加密的內(nèi)容密鑰信息；以及將經(jīng)超級加密的內(nèi)容密鑰信息轉發(fā)至所述客戶端終端中的 包括所選DRM客戶端和所選內(nèi)容解密模塊兩者在內(nèi)的至少一個客戶端終端。
[0040] 所述方法還可以包括：將經(jīng)加密的內(nèi)容轉發(fā)至所述客戶端終端中的所述至少一個 客戶端終端，所述內(nèi)容被加密以使得所述客戶端終端中的所述至少一個客戶端終端的所選 內(nèi)容解密模塊能夠使用所述內(nèi)容密鑰信息來對所述內(nèi)容進行解密。密鑰信息可以例如是在 解密過程中使用的合適密鑰或者能夠從其導出在解密過程中使用的合適密鑰的信息，并可 以被通過使用一個或多個合適密鑰管理消息而提供給相關客戶端終端，或者可以被提供為 預安裝在相關客戶端終端處，或者被嵌入到向客戶端終端下載的軟件中或被包含在對這種 軟件的更新中，或者上述各項的混合。例如，所述第一密鑰信息可以是DRM客戶端密鑰DCK， 并可以被預安裝在DRM客戶端中?？商鎿Q地，所述第一密鑰信息可以是DRM客戶端能夠從 其導出DCK的DCKinit消息。所述DCKinit消息可以在第一密鑰管理消息中被提供給DRM 客戶端，或者DCKinit消息可以被提供為預安裝在DRM客戶端中，或者兩者的混合。類似地， 所述第二密鑰信息可以是內(nèi)容解密模塊密鑰CDMK，并可以被預安裝在客戶端終端中?？商?換地，所述第二密鑰信息可以是所述內(nèi)容解密模塊能夠從其導出CDMK的CDMKinit消息。所 述CDMKinit消息可以在第二密鑰管理消息中被提供給客戶端終端，或者所述CDMKinit消 息可以被提供為預安裝在客戶端終端中，或者兩者的混合。
[0041] 相應地，所述方法可以進一步包括：生成包含所述第一密鑰信息的第一密鑰管理 消息以供所述DRM客戶端中的一個或多個所選DRM客戶端使用；以及將所述第一密鑰管理 消息引導到所述客戶端終端中的包括所選DRM客戶端和所選內(nèi)容解密模塊兩者在內(nèi)的所 述至少一個客戶端終端，以在從經(jīng)超級加密的內(nèi)容密鑰信息恢復經(jīng)加密的內(nèi)容密鑰信息時 使用。所述方法可以進一步包括：生成包含所述第二密鑰信息的第二密鑰管理消息，以供所 述內(nèi)容解密模塊中的一個或多個所選內(nèi)容解密模塊使用；以及將所述第二密鑰管理消息引 導到所述客戶端終端中的包括所選DRM客戶端和所選內(nèi)容解密模塊兩者在內(nèi)的所述至少 一個客戶端終端，以在從經(jīng)加密的內(nèi)容密鑰信息恢復所述內(nèi)容密鑰信息時使用。
[0042] 所述內(nèi)容密鑰信息可以是例如被用于對內(nèi)容進行加密且可用于對內(nèi)容進行解密 的對稱內(nèi)容密鑰，或者其可以是可用于對內(nèi)容進行解密的非對稱密鑰對中的私鑰，或者其 可以是客戶端終端可使用以導出用于對內(nèi)容進行解密的內(nèi)容密鑰的另一段信息。
[0043] 可以在向包括所選DRM客戶端和所選內(nèi)容解密模塊兩者在內(nèi)的至少一個客戶端 終端轉發(fā)的DRM許可中將經(jīng)超級加密的內(nèi)容密鑰信息遞送至一個或多個客戶端終端。這種 DRM許可可以給所述至少一個客戶端終端提供至少一個內(nèi)容使用規(guī)則，進一步控制在所述 至少一個客戶端終端處對所述內(nèi)容的使用。
[0044] 所述一個或多個所選DRM客戶端可以處于與彼此相同的DRM域中。然后，該DRM 域中的DRM客戶端均可以在所述第一密鑰管理消息中接收使每個所述DRM客戶端能夠導出 相同DRM客戶端密鑰的DCKinit消息。然后，所述DRM域中的每個所述DRM客戶端可以被 適配成使用相同DRM客戶端密鑰來從經(jīng)超級加密的內(nèi)容密鑰信息恢復經(jīng)加密的內(nèi)容密鑰 信息，經(jīng)超級加密的內(nèi)容密鑰信息可以被包含在意圖在所述DRM域中使用的DRM許可中。
[0045] 所述一個或多個所選內(nèi)容解密模塊可以處于與彼此相同的內(nèi)容解密模塊域中。然 后，該內(nèi)容解密模塊域中的內(nèi)容解密模塊均可以在所述第二密鑰管理消息中接收使每個所 述內(nèi)容解密模塊能夠導出相同內(nèi)容解密模塊密鑰的CDMKinit消息。然后，所述內(nèi)容解密模 塊域中的每個所述內(nèi)容解密模塊可以被適配成使用相同內(nèi)容解密模塊密鑰來從接收自與 所述內(nèi)容解密模塊相關聯(lián)的DRM客戶端的經(jīng)加密的內(nèi)容密鑰信息恢復內(nèi)容密鑰信息，經(jīng)加 密的內(nèi)容密鑰信息可以被包含在意圖在所述內(nèi)容解密模塊域中使用的DRM許可中。
[0046] 所述客戶端終端中的至少一個可以包括所選DRM客戶端和所選內(nèi)容解密模塊中 的一個而不是全部兩個，使得不使這種客戶端終端能夠從所述經(jīng)超級加密的內(nèi)容密鑰信息 恢復所述內(nèi)容密鑰信息。
[0047] 所述內(nèi)容密鑰信息可以包括用于對所述經(jīng)加密的內(nèi)容進行解密的密鑰?？商鎿Q 地，所述內(nèi)容密鑰信息可以使所述一個或多個所選內(nèi)容解密模塊能夠恢復用于對所述經(jīng)加 密的內(nèi)容進行解密的內(nèi)容密鑰。
[0048] 經(jīng)加密的內(nèi)容密鑰信息可以與內(nèi)容密鑰相同大小，或者可替換地小于內(nèi)容密鑰， 使得經(jīng)加密的內(nèi)容密鑰信息能夠對DRM許可生成器來說顯得與內(nèi)容密鑰沒有不同，以及使 得經(jīng)超級加密的內(nèi)容密鑰信息能夠對處理經(jīng)超級加密的內(nèi)容密鑰信息的DRM客戶端來說 顯得與經(jīng)加密的內(nèi)容密鑰沒有不同。
[0049] 可以將新(包括更新的）DRM客戶端安裝在客戶端終端中的一個或多個中，例如通 過將新DRM軟件、控制數(shù)據(jù)或者對現(xiàn)有軟件或控制數(shù)據(jù)的更新從服務器(諸如DSP服務器） 發(fā)送至要更新的每個客戶端終端。然后，可以將新密鑰管理消息和/或經(jīng)超級加密的內(nèi)容 密鑰信息遞送至客戶端終端，以使這些經(jīng)更新的客戶端終端能夠實現(xiàn)對在這些終端處存儲 的經(jīng)加密的內(nèi)容的持續(xù)訪問或者實現(xiàn)對隨后被遞送至這些終端的新的經(jīng)加密的內(nèi)容的訪 問。
[0050] 本發(fā)明還提供了一種操作客戶端終端的對應方法，包括：在與所述客戶端終端相 關聯(lián)的DRM客戶端處提供第一密鑰信息；在所述客戶端終端處提供第二密鑰信息；接收經(jīng) 超級加密的內(nèi)容密鑰信息；向所述DRM客戶端傳遞經(jīng)超級加密的內(nèi)容密鑰信息，并從所述 DRM客戶端接收回使用所述第一密鑰信息從經(jīng)超級加密的內(nèi)容密鑰信息導出的經(jīng)加密的內(nèi) 容密鑰信息；以及使用所述第二密鑰信息來對經(jīng)加密的內(nèi)容密鑰信息進行解密，以產(chǎn)生內(nèi) 容密鑰信息。
[0051] 如上所述，所述第一密鑰信息可以包括DRM客戶端密鑰DCK或所述DRM客戶端能 夠從其導出DCK的DCKinit消息。所述DCK或所述DCKinit消息可以被預安裝在DRM客戶端 中，或者所述DCKinit消息可以在第一密鑰管理消息中被提供給DRM客戶端。所述第二密鑰 信息可以包括內(nèi)容解密模塊密鑰CDMK或所述內(nèi)容解密模塊能夠從其導出CDMK的CDMKinit 消息。所述CDMK或CDMKinit消息可以被預安裝在客戶端終端中，或者所述CDMKinit消息 可以在第二密鑰管理消息中被提供給客戶端終端。因此，所述方法可以包括：接收和向與所 述客戶端終端相關聯(lián)的DRM客戶端傳遞第一密鑰管理消息，所述第一密鑰管理消息包括所 述第一密鑰信息；以及使所述DRM客戶端能夠導出DRM客戶端密鑰，所述DRM客戶端密鑰然 后被所述DRM客戶端使用以從經(jīng)超級加密的內(nèi)容密鑰信息導出經(jīng)加密的內(nèi)容密鑰信息。類 似地，所述方法可以包括：接收包括所述第二密鑰信息的第二密鑰管理消息；以及在所述 客戶端終端處從此導出內(nèi)容解密模塊密鑰，所述內(nèi)容解密模塊密鑰然后被用于從經(jīng)加密的 內(nèi)容密鑰信息導出所述內(nèi)容密鑰信息。
[0052] 所述DRM客戶端可以被安裝在所述客戶端終端處。
[0053] 所述方法還可以包括：接收經(jīng)加密的內(nèi)容并使用所導出的內(nèi)容密鑰信息來對經(jīng)加 密的內(nèi)容進行解密。
[0054] 導出內(nèi)容解密模塊密鑰、對經(jīng)加密的內(nèi)容密鑰信息進行解密以及對經(jīng)加密的內(nèi)容 進行解密的步驟是在與所述DRM客戶端分離的內(nèi)容解密模塊中執(zhí)行的。
[0055] 所述方法可以進一步包括：在所述DRM客戶端處，使用所述第一密鑰管理消息來 導出所述DRM客戶端密鑰，接收經(jīng)超級加密的內(nèi)容密鑰信息，使用所述DRM客戶端密鑰來對 經(jīng)超級加密的內(nèi)容密鑰信息進行解密以形成經(jīng)加密的內(nèi)容密鑰信息，以及返回經(jīng)加密的內(nèi) 容密鑰信息以供進一步解密和使用。
[0056] 所述方法可以進一步包括在所述客戶端終端處接收和安裝新DRM客戶端，并可以 進一步包括接收和向所述新DRM客戶端傳遞新的第一密鑰管理消息、和/或新的第一密鑰 信息、和/或新的經(jīng)超級加密的內(nèi)容密鑰信息，例如以新DRM許可的形式來進行。
[0057] 本發(fā)明還提供了對應于且提供用于實現(xiàn)上述方法的手段和功能的裝置。
[0058] 特別地，本發(fā)明提供了用于控制由多個客戶端終端對經(jīng)加密的內(nèi)容的使用的裝 置，諸如下載服務提供商或DRM服務器，每個客戶端終端被提供有數(shù)字權利管理（DRM)客戶 端和與所述DRM客戶端分離的內(nèi)容解密模塊，所述裝置包括：內(nèi)容密鑰信息加密功能，被布 置成形成經(jīng)加密的內(nèi)容密鑰信息；內(nèi)容密鑰信息超級加密功能，被布置成對經(jīng)加密的內(nèi)容 密鑰信息進行加密以形成經(jīng)超級加密的內(nèi)容密鑰信息。所述裝置可以進一步包括DRM密鑰 管理模塊，所述DRM密鑰管理模塊被布置成：生成第一密鑰管理消息，所述第一密鑰管理消 息用于使所述DRM客戶端中的一個或多個所選DRM客戶端能夠從經(jīng)超級加密的內(nèi)容密鑰信 息恢復經(jīng)加密的內(nèi)容密鑰消息；以及生成第二密鑰管理消息，所述第二密鑰管理消息用于 使所述內(nèi)容解密模塊中的一個或多個所選內(nèi)容解密模塊能夠從經(jīng)加密的內(nèi)容密鑰信息恢 復內(nèi)容密鑰信息。
[0059] 所述裝置可以進一步被布置成將第一和第二密鑰管理消息(如果使用DRM密鑰管 理模塊)、經(jīng)加密的內(nèi)容和經(jīng)超級加密的內(nèi)容密鑰信息轉發(fā)至所述客戶端終端中的包括所 選DRM客戶端和所選內(nèi)容解密模塊兩者在內(nèi)的至少一個客戶端終端，所述內(nèi)容被加密以使 得所述至少一個內(nèi)容解密模塊能夠使用所述內(nèi)容密鑰信息來對所述內(nèi)容進行解密。
[0060] 本發(fā)明還提供了一種客戶端終端，其被適配成與關聯(lián)于所述客戶端終端的DRM客 戶端一起使用，且被布置成接收經(jīng)超級加密的內(nèi)容密鑰信息和經(jīng)加密的內(nèi)容，所述客戶端 終端被布置成向所述DRM客戶端傳遞經(jīng)超級加密的內(nèi)容密鑰信息，并從所述DRM客戶端接 收使用DRM客戶端密鑰從經(jīng)超級加密的內(nèi)容密鑰信息導出的經(jīng)加密的內(nèi)容密鑰信息，所述 客戶端終端具有：內(nèi)容密鑰信息解密功能，被布置成使用內(nèi)容解密模塊密鑰來對經(jīng)加密的 內(nèi)容密鑰信息進行解密以產(chǎn)生內(nèi)容密鑰信息；以及內(nèi)容解密功能，被布置成使用所述內(nèi)容 密鑰信息來對經(jīng)加密的內(nèi)容進行解密。
[0061] 所述客戶端終端可以進一步被布置成接收第一和第二密鑰管理消息，所述客戶端 終端被布置成向所述DRM客戶端傳遞所述第一密鑰管理消息，所述第一密鑰管理消息使所 述DRM客戶端能夠導出所述DRM客戶端密鑰，所述客戶端終端進一步包括：內(nèi)容解密模塊密 鑰導出功能，其被布置成從所述第二密鑰管理消息導出所述內(nèi)容解密模塊密鑰。
[0062] 所述客戶端終端可以包括所述DRM客戶端。
[0063] 所述內(nèi)容解密模塊密鑰導出功能、所述內(nèi)容密鑰信息解密功能和所述內(nèi)容解密功 能可以位于與所述DRM客戶端分離的消費者設備的內(nèi)容解密模塊中。所述內(nèi)容解密模塊可 以是例如作為客戶端終端集成電路或作為其一部分而提供的，或者被包括在客戶端終端集 成電路內(nèi)。
[0064] 本發(fā)明還提供了將下載服務提供商或服務器和多個客戶端終端進行組合的裝置， 每個客戶端終端如上文或本文檔中其他地方所闡述的那樣。
[0065] 本發(fā)明還提供了軟件或計算機程序代碼，并且這種軟件或計算機程序代碼被攜帶 在一個或多個計算機可讀介質(zhì)上，具有被適配成提供和/或被布置成實施客戶端終端和下 載服務提供商或DRM服務器的一個或多個部分以及如本文描述的對應方法的功能。
【專利附圖】
【附圖說明】
[0066] 現(xiàn)在將參照附圖，僅作為示例，描述本發(fā)明的實施例，在附圖中： 圖1圖示了如可在現(xiàn)有技術中使用的下載服務提供商或DRM服務器和關聯(lián)的DRM客戶 端； 圖2示出了用于在圖1的DRM客戶端中恢復和使用內(nèi)容密鑰CK的布置； 圖3示出了用于在圖1的DRM客戶端中恢復和使用內(nèi)容密鑰CK的可替換布置； 圖4圖示了根據(jù)本發(fā)明實施例的DRM許可管理模塊； 圖5圖示了與圖4的DRM許可管理模塊一起使用的根據(jù)本發(fā)明的DRM密鑰管理模塊； 圖6示出了用于接收和處理從圖5和圖4的DRM密鑰管理模塊和DRM許可管理模塊接 收的密鑰管理消息和DRM許可的客戶端終端； 圖7圖示了根據(jù)本發(fā)明實施例的下載服務提供商或DRM服務器和關聯(lián)的DRM客戶端； 圖8圖示了在服務于客戶端終端時對多于一個下載服務提供商或DRM服務器的使用； 以及 圖9示出了根據(jù)本發(fā)明實施例可以如何交換DRM系統(tǒng)。
【具體實施方式】
[0067] 圖4描繪了根據(jù)本發(fā)明的在下載服務提供商110處對DRM許可132的生成。DRM 許可供具有作為DRM域和CDM域兩者的成員的DRM客戶端和內(nèi)容解密模塊兩者的一個或多 個客戶端終端使用，如稍后將更詳細討論的那樣。特別地，DRM許可生成可以在DSP 110的 DRM許可管理模塊118處進行。
[0068] 內(nèi)容密鑰CK被保持在DSP 110處的安全CK存儲器130中。在生成DRM許可 132時，從安全CK存儲器130檢索內(nèi)容密鑰CK并從安全CDMK存儲器135檢索內(nèi)容解密 模塊密鑰CDMK。接下來，在內(nèi)容密鑰加密函數(shù)E 5處使用CDMK對CK進行加密，以產(chǎn)生密文 E5 (CDMK，CK)。該密文被輸入到DRM許可生成器136。DRM許可生成器136從安全DCK存儲 器137檢索DRM客戶端密鑰DCK，并使用超級加密函數(shù)E 2和DCK來對密文E5(CDMK，CK)進 行超級加密，從而產(chǎn)生密文E2 (DCK, E5 (CDMK, CK))。
[0069] 如果使用沒有消息擴充的加密方案，則通過內(nèi)容密鑰加密函數(shù)而對內(nèi)容密鑰的加 密(而不是簡單地直接傳遞內(nèi)容密鑰)對DRM許可生成器136來說透明。例如，這是在CK是 128比特AES密鑰時和在內(nèi)容密鑰加密函數(shù)在ECB模式中使用AES時的情況。
[0070] 密文E2 (DCK, E5 (CDMK, CK))被包括在DRM許可132中，并且DRM許可132被分發(fā) 給DRM域中的一個或多個客戶端終端。
[0071] 觀察到，與圖2和3中描繪的現(xiàn)有技術示例相比，圖4中描繪的方案使用附加加密 函數(shù)E 5，該附加加密函數(shù)E5將CDMK用作加密密鑰。該附加加密將DRM許可綁定/鎖定到 CDM域，其中，僅CDM域中的內(nèi)容解密模塊可以正確地移除該附加加密，如稍后詳述的那樣。 由DRM許可生成器136執(zhí)行的加密將DRM許可綁定/鎖定到DRM域，其中，僅DRM域中的 DRM客戶端可以正確地移除該加密，如在現(xiàn)有技術示例中那樣。
[0072] 盡管在圖4中使用對稱內(nèi)容密鑰CK，但是DRM許可132可以更一般地包含內(nèi)容密 鑰信息CKI。換言之，圖4中的CK可以被內(nèi)容密鑰信息CKI替換，從該內(nèi)容密鑰信息CKI， 可以由有資格的客戶端終端的內(nèi)容解密模塊導出內(nèi)容密鑰CK，并且然后，內(nèi)容密鑰加密函 數(shù)E 5變成內(nèi)容密鑰信息加密函數(shù)。例如,這種內(nèi)容密鑰信息可以是使用密碼散列函數(shù)來在 有資格的客戶端終端的內(nèi)容解密模塊中處理的。該密碼散列函數(shù)可以具有一個或多個附加 輸入，并且密碼散列函數(shù)的輸出包括內(nèi)容密鑰CK。以這種方式，散列函數(shù)可以用于保護該一 個或多個附加輸入的真實性，其中，內(nèi)容解密模塊僅在對密碼散列函數(shù)的所有輸入都真實 的情況下才可以正確地導出CK。
[0073] 在圖5中描繪了由DSP處的DRM密鑰管理模塊116為了實現(xiàn)根據(jù)圖4生成的DRM 許可而進行的DRM密鑰管理。
[0074] 如果客戶端終端120中的DRM客戶端122加入DRM域，則可以使用由DSP處的DRM 客戶端密鑰管理模塊140生成的第一密鑰管理消息131將DRM客戶端密鑰DCK分發(fā)給DRM 客戶端122。這里假定DCK是對稱密鑰，但是如果使用公鑰加密方案，則取而代之，DCK可以 是非對稱密鑰對中的私鑰。該DCK是共享的密鑰，其中，DRM域中的所有客戶端終端需要對 該密鑰的訪問以處理與DRM域相關聯(lián)的DRM許可。
[0075] 如果客戶端終端120是加入DRM域的第一客戶端終端，則DRM客戶端密鑰管理模 塊140可以首先生成DCK (例如，使用偽隨機數(shù)生成器)。
[0076] 在將DCK分發(fā)給客戶端終端120之前，典型地，DRM客戶端密鑰管理模塊140使用 一個或多個更高級DRM密鑰來保護DCK的機密性和真實性。例如，DRM客戶端密鑰管理模 塊140可以使用更高級DRM密鑰來對DCK進行加密，并使用另一更高級DRM密鑰來生成消 息認證碼或數(shù)字簽名。該消息認證碼或數(shù)字簽名可以被附加到經(jīng)加密的DCK，從而產(chǎn)生第一 密鑰管理消息131中包含的DCKinit消息。一般地，DCKinit可以是與客戶端終端120相 關聯(lián)的DRM客戶端能夠從其導出密鑰DCK的任何消息。第一密鑰管理消息131被分發(fā)給客 戶端終端120 (或者更精確地，被分發(fā)給客戶端終端中的DRM客戶端122)。
[0077] 在一些情況下，密鑰DCK或DCKinit消息被預加載在DRM客戶端122中（例如，在 DRM客戶端被安裝在客戶端終端120中之前，DCK或DCKinit可能已經(jīng)被加載在DRM客戶端 中）。如果DCK或DCKinit消息被預加載在DRM客戶端中，則不需要將包含DCKinit的第一 密鑰管理消息分發(fā)給客戶端終端120。另外，如果DCK被預加載在DRM客戶端122中，則不 需要生成對應的DCKinit消息。
[0078] 附加于此，DSP使用CDM密鑰管理模塊142來使客戶端終端中的內(nèi)容解密模塊150 能夠加入CDM域。首先，CDM密鑰管理模塊從安全CDMK存儲器130檢索與CDM域相關聯(lián)的 內(nèi)容解密模塊密鑰CDMK。這里假定CDMK是對稱密鑰，但是如果使用公鑰加密方案，則取而 代之，CDMK可以是非對稱密鑰對中的私鑰。在CDM域中的所有內(nèi)容解密模塊之間共享密鑰 CDMK。
[0079] 如果客戶端終端120是加入CDM域的第一設備，則CDM密鑰管理模塊可能有必要 使用CDMK生成器144來首先生成CDMK。CDMK的生成可以由偽隨機數(shù)生成器執(zhí)行。如果 CDMK被更新，則也使用CDMK生成器144,如稍后詳述的那樣。
[0080] CDMK被輸入到CDMKinit生成器146, CDMKinit生成器146生成意圖用于客戶端 終端中的內(nèi)容解密模塊150的CDMKinit消息。例如，CDMKinit生成器146可以使用更高 級內(nèi)容解密模塊密鑰來保護CDMK的機密性，并且其可以使用更高級內(nèi)容解密模塊密鑰來 保護CDMK的真實性。一般地，CDMKinit可以是與客戶端終端120相關聯(lián)的內(nèi)容解密模塊 能夠從其導出密鑰CDMK的任何消息。CDMKinit被包括在第二密鑰管理消息133中，第二密 鑰管理消息133被分發(fā)給客戶端終端(或更精確地，被分發(fā)給客戶端終端的內(nèi)容解密模塊)。 客戶端終端的內(nèi)容解密模塊可以使用CDMKinit消息來導出CDMK，如稍后討論的那樣。
[0081] 在一些情況下，密鑰CDMK或CDMKinit消息被預加載在內(nèi)容解密模塊150中。例 如，如果CDM域包括一個內(nèi)容解密模塊，則CDMK可以是內(nèi)容解密模塊150的主密鑰。如果 CDMK或CDMKinit消息被預加載在DRM客戶端中，則不需要將包含CDMKinit的第二密鑰管 理消息分發(fā)給客戶端終端120。另外，如果CDMK被預加載在內(nèi)容解密模塊中，則不需要生成 對應的CDMKinit消息。
[0082] 圖6圖示了使用圖4的DRM許可管理模塊118生成的DRM許可132和使用圖5的 DRM密鑰管理模塊116生成的一個或多個密鑰管理消息131、133如何在客戶端終端120處 被接收到時被使用?？蛻舳私K端還接收經(jīng)加密的內(nèi)容EJCK，內(nèi)容）?？蛻舳私K端可以存 儲密鑰管理消息、經(jīng)加密的內(nèi)容和關聯(lián)的DRM許可以供未來使用。包含DCKinit的第一密 鑰管理消息131被輸入到DRM客戶端122。DRM客戶端122使用DRM客戶端密鑰導出函數(shù) 124 (在圖6中被示作"導出DCK"）來從DCKinit消息導出DCK。例如，該函數(shù)可以使用更 高級DRM密鑰來驗證DCKinit的真實性，并且如果DCKinit是真實的，則該函數(shù)可以使用更 高級DRM密鑰來對DCKinit進行解密，從而產(chǎn)生DCK。DRM客戶端密鑰導出函數(shù)124的輸出 是明文DCK。
[0083] 在一些情況下，密鑰DCK或DCKinit消息被預加載在DRM客戶端122中。如果DCK 或DCKinit被預加載在DRM客戶端122中，則不需要將包含DCKinit的第一密鑰管理消息 131分發(fā)給客戶端終端120。另外，如果DCK被預加載在DRM客戶端122中，則不需要DRM 客戶端密鑰導出函數(shù)124。
[0084] 包含CDMKinit消息的第二密鑰管理消息被輸入到內(nèi)容解密模塊150。內(nèi)容解密模 塊150使用CDMK導出函數(shù)152 (在圖6中被示作"導出CDMK"）來從CDMKinit導出CDMK。 例如，內(nèi)容解密模塊可以使用更高級內(nèi)容解密模塊密鑰來驗證CDMKinit的真實性，并且如 果CDMKinit是真實的，則內(nèi)容解密模塊可以使用更高級內(nèi)容解密模塊密鑰來對CDMKinit 進行解密。一般地，CDMK導出函數(shù)152可以是能夠從CDMKinit導出CDMK的任何函數(shù)。CDMK 導出函數(shù)152的輸出是明文CDMK。
[0085] 包含CDMKinit消息的第二密鑰管理消息的使用允許DSP將CDMK分發(fā)給內(nèi)容解密 模塊(例如，使內(nèi)容解密模塊能夠加入CDM域或更新CDMK，如稍后描述的那樣)。由于CDMK 可以典型地用于處理多個DRM許可，因此由這些附加第二密鑰管理消息導致的帶寬開銷可 以是可忽略不計的。
[0086] 在一些情況下，密鑰CDMK或CDMKinit消息被預加載在內(nèi)容解密模塊150中。如 果CDMK或CDMKinit被預加載在內(nèi)容解密模塊150中，則不需要將包含CDMKinit的第二密 鑰管理消息133分發(fā)給客戶端終端120。另外，如果CDMK被預加載在內(nèi)容解密模塊中，則不 需要CDMK導出函數(shù)152。
[0087] 如果DRM許可132包含內(nèi)容使用規(guī)則，則DRM客戶端122驗證這些使用規(guī)則。如 果使用規(guī)則被滿足，則使用解密函數(shù)D 2和DCK來對密文E2 (DCK，E5 (CDMK，CK))進行解密， 從而產(chǎn)生密文E5 (CDMK，CK)。如圖6中所示，DRM客戶端122將密文E5 (CDMK，CK)傳遞至內(nèi) 容解密模塊150。注意，DRM客戶端122與圖3的現(xiàn)有技術示例中所示的DRM客戶端22類 似。特別地，如果消息E5(CDMK，CK)具有與CK相同的大小(換言之，如果使用沒有消息擴充 的加密函數(shù)E 5)，則本發(fā)明的超級加密方案可以對DRM客戶端122來說透明。如果使內(nèi)容解 密模塊150能夠恢復內(nèi)容密鑰以在對內(nèi)容而不是內(nèi)容密鑰本身進行解密時使用的內(nèi)容密 鑰信息CKI被包括在DRM許可132中，并且如果E 5(CDMK，CKI)的大小不大于CK的大小，則 類似推理適用。
[0088] 在密文E5(CDMK，CK)被內(nèi)容解密模塊150接收到之后，內(nèi)容解密模塊使用內(nèi)容密 鑰解密函數(shù)DjPCDMK來計算CK。最后，經(jīng)加密的內(nèi)容E 1(CK，內(nèi)容）和CK被輸入到內(nèi)容 解密函數(shù)〇1。內(nèi)容解密函數(shù)01的輸出是明文內(nèi)容34,明文內(nèi)容34可以由客戶端終端120 呈現(xiàn)。如果在DRM許可132中使用內(nèi)容密鑰信息CKI代替內(nèi)容密鑰本身，則可以使用內(nèi)容 解密模塊150中的進一步的功能來從內(nèi)容密鑰信息CKI導出內(nèi)容密鑰CK以供內(nèi)容解密函 數(shù)〇 1使用。
[0089] 典型地，CDMK和DCK與客戶端終端的相同域相關聯(lián)。換言之，CDM域包括與DRM域 相關聯(lián)的客戶端終端的所有內(nèi)容解密模塊。出于兩個原因，這可以是期望的。第一，如果與 CDMK相關聯(lián)的CDM域包含處于與DCK相關聯(lián)的DRM域外的客戶端終端的一個或多個內(nèi)容 解密模塊，則可以使用DRM域中的DRM客戶端的輸出E 5(CDMK，CK)來合法地在處于DRM域 外的客戶端終端的一個或多個內(nèi)容解密模塊上呈現(xiàn)與CK相關聯(lián)的內(nèi)容。第二，如果DRM域 包含與CDM域外的客戶端終端相關聯(lián)的一個或多個DRM客戶端，則需要多個DRM許可來在 DRM域中的所有客戶端終端上呈現(xiàn)內(nèi)容(S卩，在這種情況下，不維持DRM域功能)。
[0090] 在一些情況下，CDMK和DCK與客戶端終端的不同域相關聯(lián)。例如，如果DSP利用 不同類型的DRM系統(tǒng)(也被稱作交換DRM系統(tǒng)）來替換DRM系統(tǒng)，則這可以是有利的。另一 示例是下述情況：服從本發(fā)明的經(jīng)超級加密的CK或CKI DRM許可的客戶端終端以及非服從 客戶端終端兩者處于一個DRM域中。稍后將更詳細描述這些示例。
[0091] 可以更新CDMK。如果DSP想要更新CDMK，則首先使用CDMK生成器114來生成新 CDMK (參見圖5)。針對CDM域中的內(nèi)容解密模塊生成一個或多個新CDMKinit消息（典型 地，針對CDM域中的每個內(nèi)容解密模塊生成一個新CDMKinit消息)，并且將每個新CDMKinit 消息包括在新的第二密鑰管理消息中。該新的第二密鑰管理消息被分發(fā)給CDM域中的客戶 端終端。在CDM域中的所有客戶端終端已經(jīng)接收到它們的新CDMKinit消息之后，DSP可以 使用新CDMK來生成新DRM許可。注意，迫使CDM域中的客戶端終端在處理這些新DRM許可 時使用新CDMK ; S卩，一旦DSP開始使用新CDMK，就調(diào)用先前CDMK。一般地，客戶端終端需要 識別哪個CDMKinit消息與DRM許可相關聯(lián)以處理該DRM許可。為了解決這一點，可以將 CDMK標識符與每個DRM許可132和每個CDMKinit消息一起進行分發(fā)。注意，典型地，CDMK 和DCK可以具有獨立的密鑰生命周期。
[0092] 如果客戶端終端120中的DRM客戶端122離開DRM域，則客戶端終端120可以刪 除其存儲的與DRM域相關聯(lián)的DCKinit消息和DCK，并且DSP (例如，其DRM客戶端密鑰管 理模塊140)可以生成新DCK并使用新DCKinit消息和新的第一密鑰管理消息將該新DCK 分發(fā)給DRM域中的其他客戶端終端。一般地，DSP和/或客戶端終端可以采取防止離開DRM 域的客戶端終端進一步處理與DRM域相關聯(lián)的DRM許可的任何動作。
[0093] 如果客戶端終端120中的內(nèi)容解密模塊150離開CDM域，則客戶端終端可以刪除 其存儲的與CDM域相關聯(lián)的CDMKinit消息和CDMK，并且DSP (例如，其CDM密鑰管理模塊 142)可以生成新CDMK并使用新CDMKinit消息和新的第二密鑰管理消息將該新CDMK分發(fā) 給CDM域中的其他客戶端終端。一般地，DSP或客戶端終端可以采取防止離開CDM域的客 戶端終端進一步處理與CDM域相關聯(lián)的DRM許可的任何動作。
[0094] 內(nèi)容密鑰CK或內(nèi)容密鑰信息CKI的超級加密供應了 CK或CKI的端對端保護（即， DSP與內(nèi)容解密模塊之間的保護)。特別地，明文CK或CKI在DRM客戶端中從不可用。該端 對端保護還意味著：DRM客戶端與解密模塊之間的接口被保護。
[0095] 所描述的方法和裝置可以以對DRM許可生成器136和DRM客戶端122來說透明的 方式實現(xiàn)，這意味著：對現(xiàn)有DRM系統(tǒng)需要微小改變或不需要改變以實現(xiàn)新方法和裝置。
[0096] 圖7圖示了實現(xiàn)對經(jīng)加密的內(nèi)容的生成和分發(fā)、以及如上結合圖4和5討論的DRM 許可和DRM密鑰管理消息、以及如上結合圖6討論的多個客戶端終端的下載服務提供商 110。DSP 110包括內(nèi)容封裝模塊112和內(nèi)容加密模塊114。實踐中，內(nèi)容可能已經(jīng)在其被 遞送至DSP時被封裝和/或加密。典型地，要被遞送至客戶端終端的經(jīng)加密的內(nèi)容采取如 上討論的形式EJCK，內(nèi)容）。
[0097] DSP 110還包括如上討論的DRM密鑰管理模塊116和DRM許可管理模塊118。DRM 密鑰管理模塊116生成圖5和6中圖示的第一和第二密鑰管理消息，以分發(fā)給一個或多個 客戶端終端120,并且DRM許可管理模塊生成如圖4和6中圖示的DRM許可132,以分發(fā)給 一個或多個客戶端終端120。
[0098] 為了使用所描述的安全性架構，DSP 110可以首先選擇服從DRM類型或方案（即， 服從內(nèi)容解密模塊架構的DRM類型）且然后將DRM客戶端以軟件或軟件更新的形式或作為 可拆卸硬件模塊分發(fā)給其想要服務于的每個客戶端終端?？商鎿Q地，DRM客戶端可以被預 安裝在客戶端終端中(例如，在客戶端終端的制造階段期間)，或者DRM客戶端可以是從不同 的源分發(fā)的。還可以使用DRM客戶端分發(fā)機制來升級DRM客戶端(例如，可以使用升級來提 高安全性級別或供應更多功能)，和/或可以使用該機制以利用不同類型的DRM系統(tǒng)(也被 稱作交換DRM系統(tǒng)）來替換DRM系統(tǒng)，如稍后詳述的那樣。
[0099] DRM客戶端122可以以軟件實現(xiàn)，和/或DRM客戶端122可以被實現(xiàn)在可拆卸硬件 模塊中。可以使用軟件保護技術和/或硬件保護技術來使DRM客戶端122防篡改和防讀取 (例如，防止對手損害秘密密鑰或修改內(nèi)容使用規(guī)則)。然而，本文描述的方案不要求：DRM客 戶端122實現(xiàn)用于將DRM客戶端122綁定/鎖定到客戶端終端120的安全性手段或機制。 換言之，DRM客戶端不需要被直接鎖定到客戶端終端，這是由于該功能由包含經(jīng)超級加密的 CK或CKI的DRM許可提供，如上所討論。
[0100] 典型地，圖7的DSP 110將特定DCK和CDMK用于創(chuàng)建多個不同DRM許可132,使得 DCK和CDMK可以用于訪問多段內(nèi)容。在這種場景中，不需要隨每段經(jīng)加密的內(nèi)容和關聯(lián)的 DRM許可分發(fā)對應的第一和第二密鑰管理消息。另外，如果密鑰DCK或DCKinit消息被預加 載在DRM客戶端中，則不需要包含DCKinit的第一密鑰管理消息。類似地，如果密鑰CDMK 或CDMKinit消息被預加載在內(nèi)容解密模塊中，則不需要包含CDMKinit的第二密鑰管理消 肩、。
[0101] 如果DSP 110利用相同類型的DRM系統(tǒng)服務于服從客戶端終端（S卩，被適配成使用 經(jīng)超級加密CK或CKI的客戶端終端）和非服從客戶端終端兩者，則與服從客戶端終端和非 服從客戶端終端相關聯(lián)的受保護的內(nèi)容密鑰和/或內(nèi)容密鑰信息的遞送有所不同。更特 別地，針對服從客戶端終端的DRM許可內(nèi)包含的受保護的CK或CKI可以被表達為E 2 (DCK， E5 (CDMK，CK))或E2 (DCK，E5 (CDMK，CKI))，但針對非服從客戶端終端，被表達為E2 (DCK，CK) 或& (DCK，CKI)。圖7的DSP 110可以通過分別針對服從客戶端終端和非服從客戶端終端生 成不同DRM許可來管理該情形。如果服從客戶端終端和非服從客戶端終端處于相同DRM域 中，則缺陷是：消費者不能將針對服從客戶端終端的DRM許可用作對非服從終端的輸入(或 者反過來）以呈現(xiàn)關聯(lián)的內(nèi)容。取而代之，需要獲取新DRM許可，并且為此，DSP 110可以自 動地將兩個DRM許可分發(fā)給包含服從和非服從客戶端終端兩者的DRM域中的客戶端終端。 可替換地，DRM系統(tǒng)可以支持對兩個分離的經(jīng)加密的內(nèi)容密鑰或兩段內(nèi)容密鑰信息的包括 (例如，DRM系統(tǒng)可以在一個DRM許可中包括E 2(DCK，E5(CDMK，CK)) 和E2(DCK，CK))。注意， 在該場景中，CDM域小于DRM域。
[0102] 如果DSP 110想要升級DRM客戶端，則DSP 110將升級DRM客戶端以軟件或軟件更 新的形式或作為可拆卸硬件模塊分發(fā)給其想要服務于的每個客戶端終端，在圖7中被示作 "分發(fā)DRM客戶端"步驟。在客戶端終端安裝該升級DRM客戶端之后，DRM客戶端可以訪問被 分發(fā)給先前安裝的DRM客戶端的所存儲的內(nèi)容。如果關聯(lián)的DCK對該升級DRM客戶端來說 可用，并且如果關聯(lián)的CDMK對內(nèi)容解密模塊來說可用，則與所存儲的內(nèi)容相關聯(lián)的所存儲 的DRM許可可以被重用作對該升級DRM客戶端的輸入。關聯(lián)的DCK或新的對應DCKinit消 息可以被預加載在該升級DRM客戶端中，或者包含新的對應DCKinit的新的第一密鑰管理 消息可以被發(fā)布給該升級DRM客戶端以訪問DCK?？商鎿Q地，如果處理所存儲的DCKinit所 需的更高級DRM密鑰(或多個密鑰)對該升級DRM客戶端來說可用，則包含所存儲的DCKinit 的所存儲的第一密鑰管理消息可以被該升級DRM客戶端重用以訪問DCK。與DRM許可相關 聯(lián)的CDMK或CDMKinit消息可以被預加載在內(nèi)容解密模塊中，或者包含CDMKinit的所存儲 的第二密鑰管理消息可以被內(nèi)容解密模塊重用以訪問CDMK。換言之，如果第二密鑰管理消 息被存儲，則DSP不需要生成和分發(fā)新的第二密鑰管理消息。
[0103] 如果DSP 110將新DCK發(fā)布給升級DRM客戶端(例如，通過在DRM客戶端中預加載 新DCK或者通過將包含新DCKinit的新的第一密鑰管理消息發(fā)布給DRM客戶端）和/或如 果DSP 110將新CDMK發(fā)布給內(nèi)容解密模塊(例如，通過將新的第二密鑰管理消息發(fā)布給內(nèi) 容解密模塊)，則可以在使用新DCK和/或新CDMK來對相關CK或CKI進行超級加密的情況 下發(fā)布已經(jīng)在客戶端終端處存儲的內(nèi)容的新DRM許可。
[0104] 圖8圖示了兩個或更多個不同DSP 110'和110' '服務于多個客戶端終端120' 的情形，其中使每個D SP能夠使用每個客戶端終端的內(nèi)容解密模塊15 0 '，例如，使用 在 ETSI TS 103 162 vl. 1. 1 ''Access, Terminals, Transmission and Multiplexing (ATTM): Integrated Broadband Cable and Television Networks: K-LAD Functional Specification〃中描述的布置。在圖8中，第一 DSP 110'使用客戶端終端中的第一 DRM客 戶端122'，并且第二DSP 110''使用客戶端終端中的第二DRM客戶端122''。每個DSP可以 通過生成其自身的CDMK和第二密鑰管理消息、獨立于另一 DSP來操作內(nèi)容解密模塊150'。 以這種方式，支持DRM客戶端的并發(fā)使用，其中每個DSP獨立地管理其自身的DRM和CDM域。 如果這兩個DSP使用相同類型的DRM系統(tǒng)，則DSP 110'、110''可以附加地共享客戶端終端 中的DRM客戶端122。
[0105] 圖9圖示了在利用不同類型的DRM系統(tǒng)(也被稱作交換DRM系統(tǒng)）替換已經(jīng)實現(xiàn) 的DRM系統(tǒng)時可以如何操作DSP 110和客戶端終端120。交換DRM系統(tǒng)的可能原因是：新 DRM系統(tǒng)可以比當前DRM系統(tǒng)更有成本效益(例如，新DRM系統(tǒng)可以供應更高的安全性級別， 從而降低或消除內(nèi)容盜版)。在選擇了新DRM系統(tǒng)(在圖9中被稱為類型2 DRM)之后，DSP 110將類型2 DRM客戶端122-b分發(fā)給其想要服務于的每個客戶端終端?？商鎿Q地，類型2 DRM客戶端122-b可以被預安裝在客戶端終端中，或者類型2 DRM客戶端122-b可以是從不 同的源分發(fā)的。
[0106] 注意，DSP 110需要實現(xiàn)包括類型1 DRM客戶端的類型1 DRM系統(tǒng)以及類型2 DRM 系統(tǒng)二者，只要不是所有客戶端終端都已經(jīng)接收到類型2 DRM客戶端122-b即可。附加地， 就在這兩個系統(tǒng)之間以下不同而言，在仍使用這兩種類型的DRM系統(tǒng)的同時，需要支持針 對這兩種類型的內(nèi)容封裝、內(nèi)容加密、DRM密鑰管理和DRM許可管理的支持。
[0107] 典型地，將給新安裝的初始類型2 DRM客戶端提供新DCK(由于DRM許可典型地是 DRM系統(tǒng)專用的，因此類型2 DRM客戶端不能處于與類型1 DRM系統(tǒng)相關聯(lián)的DRM域中）。例 如，該新DCK或新的關聯(lián)DCKinit可以被預加載在初始類型2 DRM客戶端中，或者包括新的 關聯(lián)DCKinit的新的第一密鑰管理消息可以被發(fā)布給初始類型2 DRM客戶端。然而，觀察 至IJ，可以針對類型2 DRM系統(tǒng)重用針對類型1 DRM系統(tǒng)而生成和分發(fā)的所存儲的CDMKinit 消息和CDMK。注意，在交換場景中，在從類型1 DRM到類型2 DRM的轉移階段期間，CDM域 可以大于對應的DRM域。
[0108] 如果相同的內(nèi)容封裝和內(nèi)容加密方案被這兩種類型的DRM系統(tǒng)支持，則在客戶端 終端獲得并安裝新類型2 DRM客戶端之后以及在客戶端終端獲得針對該所存儲的內(nèi)容的新 的類型2 DRM許可之后，經(jīng)更新的客戶端終端可以呈現(xiàn)與類型1 DRM系統(tǒng)相關聯(lián)的所存儲 的內(nèi)容。新的類型2 DRM許可由DSP發(fā)布，并包含使用新DCK而超級加密的相關CK或CKI。
[0109] 在客戶端終端已經(jīng)接收到并安裝類型2 DRM客戶端122-b之后，類型1 DRM客戶 端(在圖9中未示出）可以被刪除。不刪除類型1 DRM客戶端的原因可以是：允許客戶端設 備繼續(xù)使用所存儲的類型1 DRM許可來訪問/呈現(xiàn)所存儲的類型1 DRM內(nèi)容。不刪除類型 1 DRM客戶端的另一原因可以是：類型1 DRM客戶端可能正被不同的DSP使用。
[0110] 將理解的是，在不脫離如所附權利要求中限定的本發(fā)明范圍的情況下，可以對所 描述的實施例作出變型和修改。例如，應當理解，關于任一個實施例描述的任何特征可以被 單獨地使用或者結合關于該實施例或其他實施例描述的其他特征使用。
【權利要求】
1. 一種控制由多個客戶端終端對經(jīng)加密的內(nèi)容的使用的方法，每個客戶端終端被提供 有數(shù)字權利管理（DRM)客戶端和與所述DRM客戶端分離的內(nèi)容解密模塊，所述方法包括： 提供第一密鑰信息以供所述DRM客戶端中的一個或多個所選DRM客戶端使用； 提供第二密鑰信息以供所述內(nèi)容解密模塊中的一個或多個所選內(nèi)容解密模塊使用； 對內(nèi)容密鑰信息進行加密以形成經(jīng)加密的內(nèi)容密鑰信息，使得所述第二密鑰信息使所 述內(nèi)容解密模塊中的所選內(nèi)容解密模塊能夠從經(jīng)加密的內(nèi)容密鑰信息恢復所述內(nèi)容密鑰 信息； 對經(jīng)加密的內(nèi)容密鑰信息進行加密以形成經(jīng)超級加密的內(nèi)容密鑰信息，使得所述第一 密鑰信息使所述DRM客戶端中的所選DRM客戶端能夠從經(jīng)超級加密的內(nèi)容密鑰信息恢復經(jīng) 加密的內(nèi)容密鑰信息。
2. 根據(jù)權利要求1所述的方法，進一步包括： 將經(jīng)加密的內(nèi)容和經(jīng)超級加密的內(nèi)容密鑰信息引導到所述客戶端終端中的包括所選 DRM客戶端和所選內(nèi)容解密模塊兩者在內(nèi)的至少一個客戶端終端，該內(nèi)容被加密以使得所 述客戶端終端中的所述至少一個客戶端終端的所選內(nèi)容解密模塊能夠使用所述內(nèi)容密鑰 信息來對該內(nèi)容進行解密。
3. 根據(jù)權利要求1或2所述的方法，進一步包括：生成包含所述第一密鑰信息的第一 密鑰管理消息以供所述DRM客戶端中的一個或多個所選DRM客戶端使用；以及將所述第一 密鑰管理消息引導到所述客戶端終端中的包括所選DRM客戶端和所選內(nèi)容解密模塊兩者 在內(nèi)的所述至少一個客戶端終端，以在從經(jīng)超級加密的內(nèi)容密鑰信息恢復經(jīng)加密的內(nèi)容密 鑰信息時使用。
4. 根據(jù)前述任一權利要求所述的方法，進一步包括：生成包含所述第二密鑰信息的第 二密鑰管理消息，以供所述內(nèi)容解密模塊中的一個或多個所選內(nèi)容解密模塊使用；以及將 所述第二密鑰管理消息引導到所述客戶端終端中的包括所選DRM客戶端和所選內(nèi)容解密 模塊兩者在內(nèi)的所述至少一個客戶端終端，以在從經(jīng)加密的內(nèi)容密鑰信息恢復所述內(nèi)容密 鑰信息時使用。
5. 根據(jù)前述任一權利要求所述的方法，其中，存在多個所述所選DRM客戶端，并且所述 多個所選DRM客戶端處于相同DRM域中。
6. 根據(jù)前述任一權利要求所述的方法，其中，所述客戶端終端中的至少一個包括所選 DRM客戶端和所選內(nèi)容解密模塊中的一個而不是全部兩個。
7. 根據(jù)前述任一權利要求所述的方法，其中，所述內(nèi)容密鑰信息包括用于對所述經(jīng)加 密的內(nèi)容進行解密的密鑰。
8. 根據(jù)權利要求1至6中任一項所述的方法，其中，所述內(nèi)容密鑰信息包括所述一個或 多個所選內(nèi)容解密模塊能夠從其恢復用于對所述經(jīng)加密的內(nèi)容進行解密的內(nèi)容密鑰的信 肩、。
9. 根據(jù)權利要求7或8所述的方法，其中，經(jīng)加密的內(nèi)容密鑰信息不大于所述內(nèi)容密 鑰。
10. 根據(jù)前述任一權利要求所述的方法，進一步包括：將經(jīng)超級加密的內(nèi)容密鑰信息 封裝在向包括所選DRM客戶端和所選內(nèi)容解密模塊兩者在內(nèi)的所述至少一個客戶端終端 轉發(fā)的DRM許可中，所述DRM許可給所述至少一個客戶端終端提供至少一個內(nèi)容使用規(guī)則， 所述至少一個內(nèi)容使用規(guī)則進一步控制在包括所選DRM客戶端和所選內(nèi)容解密模塊兩者 在內(nèi)的所述至少一個客戶端終端處對所述內(nèi)容的使用。
11. 根據(jù)前述任一權利要求所述的方法，進一步包括：使所述所選客戶端終端中的至 少一個安裝新DRM客戶端。
12. -種操作客戶端終端的方法，包括： 在與所述客戶端終端相關聯(lián)的DRM客戶端處提供第一密鑰信息； 在所述客戶端終端處提供第二密鑰信息； 接收經(jīng)超級加密的內(nèi)容密鑰信息和經(jīng)加密的內(nèi)容； 向所述DRM客戶端傳遞經(jīng)超級加密的內(nèi)容密鑰信息，并從所述DRM客戶端接收回使用 所述第一密鑰信息從經(jīng)超級加密的內(nèi)容密鑰信息導出的經(jīng)加密的內(nèi)容密鑰信息； 使用所述第二密鑰信息來對經(jīng)加密的內(nèi)容密鑰信息進行解密，以產(chǎn)生內(nèi)容密鑰信息； 以及 使用所述內(nèi)容密鑰信息來對經(jīng)加密的內(nèi)容進行解密。
13. 根據(jù)權利要求12所述的方法，進一步包括：接收和向與所述客戶端終端相關聯(lián)的 DRM客戶端傳遞第一密鑰管理消息，所述第一密鑰管理消息包括所述第一密鑰信息。
14. 根據(jù)權利要求12或13所述的方法，進一步包括：接收包括所述第二密鑰信息的第 二密鑰管理消息。
15. 根據(jù)權利要求12至14中任一項所述的方法，其中，對經(jīng)加密的內(nèi)容密鑰信息進行 解密以及對經(jīng)加密的內(nèi)容進行解密的步驟是在與所述DRM客戶端分離的內(nèi)容解密模塊中 執(zhí)行的。
16. 根據(jù)權利要求12至15中任一項所述的方法，進一步包括：在所述DRM客戶端處，使 用所述第一密鑰信息來提供DRM客戶端密鑰，接收經(jīng)超級加密的內(nèi)容密鑰信息，使用所述 DRM客戶端密鑰來對經(jīng)超級加密的內(nèi)容密鑰信息進行解密以形成經(jīng)加密的內(nèi)容密鑰信息， 以及返回經(jīng)加密的內(nèi)容密鑰信息以供進一步解密和使用。
17. 根據(jù)權利要求12至16中任一項所述的方法，其中，所述DRM客戶端被安裝在所述 客戶端終端處。
18. 根據(jù)權利要求12至17中任一項所述的方法，進一步包括：在所述客戶端終端處接 收和安裝新DRM客戶端。
19. 用于控制由多個客戶端終端對經(jīng)加密的內(nèi)容的使用的裝置，每個客戶端終端被提 供有數(shù)字權利管理（DRM)客戶端和與所述DRM客戶端分離的內(nèi)容解密模塊，所述裝置包括： 內(nèi)容密鑰信息加密功能，被布置成形成經(jīng)加密的內(nèi)容密鑰信息；以及 內(nèi)容密鑰信息超級加密功能，被布置成對經(jīng)加密的內(nèi)容密鑰信息進行加密以形成經(jīng)超 級加密的內(nèi)容密鑰信息。
20. 根據(jù)權利要求19所述的裝置，進一步被布置成：將經(jīng)加密的內(nèi)容和經(jīng)超級加密的 內(nèi)容密鑰信息引導到所述客戶端終端中的包括所選DRM客戶端和所選內(nèi)容解密模塊兩者 在內(nèi)的至少一個客戶端終端，該內(nèi)容被加密以使得至少一個內(nèi)容解密模塊能夠使用所述內(nèi) 容密鑰信息來對該內(nèi)容進行解密。
21. 根據(jù)權利要求19或20所述的裝置，進一步被布置成生成第一密鑰管理消息以使所 述DRM客戶端中的一個或多個所選DRM客戶端能夠從經(jīng)超級加密的內(nèi)容密鑰信息恢復經(jīng)加 密的內(nèi)容密鑰信息，所述裝置進一步被布置成將所述第一密鑰管理消息轉發(fā)到所述客戶端 終端中的包括所選DRM客戶端和所選內(nèi)容解密模塊兩者在內(nèi)的所述至少一個客戶端終端。
22. 根據(jù)權利要求19至21中任一項所述的裝置，進一步被布置成生成第二密鑰管理消 息，以使所述內(nèi)容解密模塊中的一個或多個所選內(nèi)容解密模塊能夠從經(jīng)加密的內(nèi)容密鑰信 息恢復內(nèi)容密鑰信息，所述裝置進一步被布置成將所述第二密鑰管理消息轉發(fā)到所述客戶 端終端中的包括所選DRM客戶端和所選內(nèi)容解密模塊兩者在內(nèi)的所述至少一個客戶端終 端。
23. -種客戶端終端，其被適配成與關聯(lián)于所述客戶端終端的DRM客戶端一起使用，且 被布置成接收經(jīng)超級加密的內(nèi)容密鑰信息和經(jīng)加密的內(nèi)容， 所述客戶端終端被布置成向所述DRM客戶端傳遞經(jīng)超級加密的內(nèi)容密鑰信息，并從所 述DRM客戶端接收使用DRM客戶端密鑰從經(jīng)超級加密的內(nèi)容密鑰信息導出的經(jīng)加密的內(nèi)容 密鑰信息， 所述客戶端終端具有：內(nèi)容密鑰信息解密功能，被布置成使用內(nèi)容解密模塊密鑰來對 經(jīng)加密的內(nèi)容密鑰信息進行解密以產(chǎn)生內(nèi)容密鑰信息；以及內(nèi)容解密功能，被布置成使用 所述內(nèi)容密鑰信息來對經(jīng)加密的內(nèi)容進行解密。
24. 根據(jù)權利要求23所述的客戶端終端，進一步被布置成接收第一密鑰管理消息，所 述客戶端終端被布置成向所述DRM客戶端傳遞所述第一密鑰管理消息，所述第一密鑰管理 消息使所述DRM客戶端能夠導出所述DRM客戶端密鑰。
25. 根據(jù)權利要求23或24所述的客戶端終端，進一步被布置成接收第二密鑰管理消 息，所述客戶端終端進一步包括：內(nèi)容解密模塊密鑰導出功能，其被布置成從所述第二密鑰 管理消息導出所述內(nèi)容解密模塊密鑰。
26. 根據(jù)權利要求23至25中任一項所述的客戶端終端，進一步包括所述DRM客戶端。
27. 根據(jù)權利要求26所述的客戶端終端，其中，所述內(nèi)容密鑰信息解密功能、所述內(nèi)容 解密功能、以及在從屬于權利要求25的情況下所述內(nèi)容解密模塊密鑰導出功能位于與所 述DRM客戶端分離的消費者設備的內(nèi)容解密模塊中。
28. 根據(jù)權利要求23至27中任一項所述的客戶端終端，其中，所述內(nèi)容解密模塊被包 括在客戶端終端集成電路內(nèi).
28. -種系統(tǒng)，包括根據(jù)權利要求19至22中任一項所述的裝置與根據(jù)權利要求23至 28中任一項的多個客戶端終端相結合。
29. -種或多種包括計算機程序代碼的計算機可讀介質(zhì)，所述計算機程序代碼被布置 成在合適的計算機設備上被執(zhí)行時實施根據(jù)權利要求1至18中任一項所述的方法。
【文檔編號】G06F21/10GK104221023SQ201280072457
【公開日】2014年12月17日 申請日期:2012年2月17日 優(yōu)先權日:2012年2月17日
【發(fā)明者】P.羅爾塞 申請人:耶德托公司