TWI469603B

TWI469603B - 一種使用信任處理技術數位權利管理

Info

Publication number: TWI469603B
Application number: TW99114122A
Authority: TW
Inventors: Inhyok Cha; Amit Singhal; Yogendra C Shah
Original assignee: Interdigital Tech Corp
Priority date: 2006-05-05
Filing date: 2007-05-04
Publication date: 2015-01-11
Also published as: EP2495932A1; US9489498B2; CN101573936B; IL195129A0; EP2495932B1; EP2981040A1; KR101018368B1; RU2013124844A; TWI467987B; IL195129A; KR101269698B1; US20080046758A1; AR060774A1; TW201112707A; AU2007347234B2; JP2009536507A; US8769298B2; HK1136412A1; CA2651436A1; JP2012257292A

Description

一種使用信任處理技術數位權利管理

本發明一般與在無線通信網路中的數位版權管理(DRM)方法有關。更具體地，本發明提供了用於提高根據開放行動聯盟(OMA)DRM規範運作的系統中的安全性、完整性與可信性的方法。

OMA DRM是由OMA所規定的一種DRM系統，OMA是行動電話與裝置製造者和行動業務提供者的協會。該方案在許多行動電話上實現，以及由行動內容提供者使用於把DRM增加到他們的產品和業務中。已經發行了OMA DRM的兩個版本：OMA DRM 1.0和OMA DRM 2.0。

OMA DRM 1.0解決方案用於對內容物件的數位版權的基本管理。因而，其不提供對內容物件或者版權物件的有力保護。OMA DRM 1.0規定了傳遞的三種方法：轉發鎖定(其防止用戶從將內容轉發到其他用戶或裝置)、組合傳遞(組合的版權物件與媒體物件)以及單獨傳遞(單獨的版權物件與媒體物件)。OMA DRM 1.0被設計成能處理諸如用於電話的鈴音或者桌布(wallpapers)的小型媒體物件。

OMA DRM 2.0改進並擴展了該OMA DRM 1.0傳遞機制。與OMA DRM 2.0相容的裝置具有基於DRM公鑰基礎結構(PKI)的各自的證書，即，每個裝置具有公鑰、相應的私鑰與驗證這個事實的證書。每個版權物件(RO)被保護以用於機密性(透過加密)與完整性(透過數位簽名)。與該OMA DRM 1.0系統的安全性相比，利用PKI、加密與完整性檢查增強了OMA DRM 2.0系統的安全性。

OMA DRM 2.0也規定了一組協定，共同稱作版權物件獲取協定(ROAP)，包括不同的子協定，其關於在裝置與版權發行者(RI)之間的相互驗證和註冊、請求RO、對RO的傳遞回應或者拒絕傳遞方RO以及加入並離開裝置的域。

以下是在OMA DRM中所定義的一些主要實體：

參與者─參與者是執行使用事件的外部實體。

備份/遠端儲存體─將RO與內容物件(CO)轉移到另一位置，以打算把它們轉移回原始裝置。

組合傳遞─用於傳遞受保護內容與RO的OMA DRM 1.0方法。該RO與受保護內容是在一單一實體也就是DRM訊息中被一起傳遞的。

機密性─資訊不可利用或者對未授權的個人、實體或者處理公開的屬性。

合成物件─透過包含的方式而包含一或多個媒體物件的CO。

連接裝置─能夠使用合適的協定經由合適的廣域傳輸/網路層介面而直接連接到RI的裝置。

內容─一或多個媒體物件。

內容發行者(CI)─製作對DRM代理可用的內容的實體。

內容提供者──為CI或RI的實體。

裝置─具有DRM代理的用戶裝置。其可以是連接裝置，或者是未連接裝置，但是這種區別取決於上下文並且本質上是可變的，因為連接裝置在其失去直接連接到RI的能力時可以變為未連接裝置。

裝置撤銷─指示一裝置對於獲取RO來說不再是可信賴的RI的處理。

裝置RO─藉由裝置的公鑰而專用於特定裝置的RO。

域─一組裝置，其能夠共用域RO。在域中的裝置共用一域密鑰。域是由RI所定義並管理。

域識別碼─域密鑰的唯一串識別碼。

域密鑰─128位元對稱加密密鑰。

DRM代理─在裝置中管理對在該裝置上的媒體物件的許可的實體。

DRM內容─根據RO中的一組許可而消費的媒體物件。

DRM時間─安全的、非用戶可變的時間源。該DRM時間是UTC時間格式。

完整性─資料沒有以未授權的方式改變或者毀壞的屬性。

加入域─在域中包括一裝置的RI的處理。

離開(去加入)域─從域中除去一非撤銷的裝置的RI的處理。

媒體物件─數位作品或者合成物件。

網路服務提供者─對行動裝置提供網路連接的實體。

許可─由RI透過DRM內容所允許的實際的使用或動作。

播放─創造一資源的短暫、可見的再現。

受保護內容─根據RO中的一組許可而消費的媒體物件。

恢復─將受保護內容及/或RO從外部位置轉移回到其曾被備份的裝置。

撤銷─宣佈裝置或者RI證書無效的處理。

版權發行者(RI)─將RO發行到OMA DRM一致性裝置的實體。

RI上下文─在4傳(4-pass)註冊協定期間與給定的RI協商的資訊，諸如RI ID、RI證書鏈、版本、演算法和其他資訊。除註冊協定之外，RI上下文是裝置成功參與該ROAP組的所有協定所必需的。

版權物件(RO)─鏈結到受保護內容的許可和其他屬性的集合。

版權物件獲取協定(ROAP)─使裝置能夠從RI請求並獲取RO的協定。

ROAP觸發器─可擴展標註語言(XML)文件，包括當被裝置接收時啟動該ROAP的URL。

無狀態版權─該裝置不必對其維持狀態資訊的RO。

有狀態版權─該裝置必須對其明確維持狀態資訊的RO，以便可以正確地加強在RO中表示出的限制條件和許可。包含任何以下限制條件或者許可的RO被認為是有狀態版權：<interval>、<count>、<timed-count>、<datetime>、<accumulated>或<export>。

超分配─一種機制，(1)允許用戶把受保護內容經由潛在地非保密通道分配到其他裝置，和(2)對於超分配的受保護內容，使該裝置的用戶去獲得RO。

未連接裝置─能夠經由連接裝置使用合適的協定透過本地連接技術例如透過IrDA的OBEX(透過紅外的對象交換)、藍牙或通用串列匯流排(USB)連接到RI的裝置。未連接裝置可以支援DRM時間。

用戶─裝置的人類用戶。用戶不必擁有該裝置。

第1圖是現有OMA DRM 2.0功能架構100的概述。該架構100包括DRM系統102、內容提供者104和用戶106。DRM系統102包括CI 110、RI 112、DRM代理114、網路記憶體116和可行動媒體118。CI 110分配受保護內容122，RI 112分配RO 124。DRM代理114重新分配受保護內容122。

CI 110是傳遞DRM內容122的實體。該OMA DRM定義要傳送到DRM代理114的DRM內容122的格式，以及該DRM內容122使用不同的傳送機制從CI 110傳遞到DRM代理114的方式。CI 110可以自己執行該DRM內容122的實際封裝，或者其可以從其他的來源接收預封裝的內容。

該RI 112是對DRM內容122分配許可和限制條件、以及產生RO 124的實體。RO 124是表達與DRM內容122相關的許可與限制條件的XML文件。RO 124管理如何可以使用DRM內容122；缺少相關的RO 124是不能使用該DRM內容122的，僅僅可以按照其相關的RO所規定的而使用DRM內容122。DRM內容可以相關於一個以上的RO，例如，如果RO具有時間期限(例如10天)，以及在時間期限之後，將需要新的RO來存取內容。

DRM代理114是負責管理DRM內容122的消費點實施的邏輯實體。DRM代理114具體化為裝置的可信元件，並且其負責對裝置上的DRM內容122增強許可和約束條件、控制對裝置上的DRM內容的存取(僅僅可以經由DRM代理114來存取)等等。

封裝該DRM內容122以防止其在被傳遞之前被未授權的存取。該CI 110傳遞DRM內容122，並且RI 112產生RO 124。在該系統102中，CI 110與RI 112具體化邏輯任務，而不是物理實體。例如，在一個應用中，內容擁有者可以預封裝DRM內容，其然後由作為CI與RI二者的內容分配者來分配。

RO 124管理如何可以使用DRM內容122。缺少相關的RO 124是不能使用DRM內容122的，並且僅僅根據在RO 124中所規定的許可與限制條件而使用DRM內容122。OMA DRM進行將DRM內容從RO的邏輯分離。可以分別地或一起請求DRM內容與RO，並且可以分別地或者同時傳送它們。在DRM內容與RO被同時傳遞時，它們典型地都是由CI 110提供，以RO與內容嵌入在DRM內容格式(DCF)的形式。

RO 124是由一組密鑰密碼地(cryptographically)綁定到特定的DRM代理114，因此僅僅特定的DRM代理114可以存取RO 124。DRM內容122只能利用有效的RO 124被存取，因此可以自由地分配或者超分配該內容122。

OMA DRM 2.0允許一個RO綁定到一組DRM代理。這種組被稱作域。分配到域的DRM內容和RO可以由屬於該域的所有DRM代理共用並存取。例如，用戶可以購買DRM內容以在她的電話和她的PDA上使用。

OMA DRM規範定義了DRM內容(或者DCF)的格式與保護機制、RO的格式(版權表達語言(REL))與保護機制以及加密密鑰的管理的安全模型。OMA DRM規範還定義了如何使用傳送機制的範圍以將DRM內容與RO傳送到裝置，傳送機制包括拉出(pull)(HTTP拉出、OMA下載)、推入(push)(WAP推入、MMS)以及流動。然而，OMA DRM規範不能解決在網路實體之間的任何互動，例如在CI 110與RI 112之間。

以下是由OMA DRM 2.0規範所涵蓋的使用情況的非詳盡列表。

1.基本拉出模型

用戶透過瀏覽到網站來選擇內容以下載，並且確認購買的項目。該CI 110識別並保護內容122，即對其進行封裝。內容122是使用內容加密密鑰(CEK)加密的。該裝置能力可以使用通告的MIME類型支援等來檢測。RI 112產生對於內容122的RO 124和目標DRM代理114。RO 124包括對於內容事務的許可和CEK。最後，RO 124是透過加密(使用RO加密密鑰或REK)和數位簽名而密碼地保護的，以及僅僅被綁定到目標DRM代理114。該DRM內容122和受保護的RO 124然後被傳遞到DRM代理114。

2.DRM內容的推入

可替代的分配模型是在沒有預先發現處理之前，使用多媒體訊息服務(MMS)、WAP推入或者類似方法把該內容直接地推入到裝置。在這種使用情形中有兩個變化。

2A.內容推入

CI 110及/或RI 112可以具有對用戶和特定的DRM代理114的某些先驗知識，這樣該內容122和RO 124可以被格式化和封裝，以用於傳遞。

2B.推入啟動的拉出

在這種情況下，CI 110及/或RI 112可以沒有關於用戶或者他們的DRM代理114的先前知識，但是仍然可以希望傳送內容，例如，允許用戶預覽內容122，以吸引他們購買該內容。代替將DRM內容122直接地推入到用戶，可以發送鏈結到該內容的鏈路或者鏈結到該內容的預覽的鏈路。之後，該鏈路將帶用戶到特定的位置，然後這個程序以基本拉出模型的方式繼續。

3.DRM內容的流動

基本的拉出和推入使用情況二者都假定全面封裝和傳送該內容。或者，該內容可以作為資料流而被封裝並傳送。在這種情況下，該資料流本身是受保護的(加密的)。該加密的確切格式已經不在OMA DRM的範圍中，但可以從現有加密標準中選擇。該資料流可以是用不同於由OMA對於下載所規定的加密方案的加密方案所保護，以解決可能的封包丟失等等。在加密該資料流之後，可以透過先前描述的用於分離內容的相同程序來控制該資料流。產生RO，該資料流加密密鑰就像CEK一樣被放入到RO中，然後該RO被密碼地綁定到DRM代理。

4.域

域是可選特徵，並且不可以由所有RI所支援。域擴展該OMA DRM 2.0的基本模型，其中RO和CEK被綁定到特定的DRM代理114，以及允許RI 112把版權和CEK綁定到一組DRM代理，而不是僅僅一個單一DRM代理。用戶然後可以共用在屬於相同域的所有DRM代理之間脫機的DRM內容122。RI 112可以使用該域概念來提供新服務，諸如使用戶能從他們所擁有的若干裝置存取DRM內容122，或者對未連接裝置提供支援，其中用戶經由一個裝置(例如PC)購買DRM內容和版權，以用於稍後在另一個裝置(例如可擕式播放器)上使用。

5.備份

DRM內容122可以被儲存在可行動媒體118上、在網路記憶體116中、或者在一些其他形式的儲存體中。該DRM內容122是以加密形式儲存的，並且只能由特定的目標DRM代理114使用相關的RO 124來存取。如果RO僅僅包含無狀態許可，RO 124可以為了備份目的而儲存。安全模型保證該RO 124是受保護的，並且只能由預定的DRM代理114所存取，即使該RO 124是離開裝置而儲存的。某些許可需要由DRM代理114的狀態維護，例如有限次數的播放。這樣的RO不能離開裝置而儲存，這是因為這可能導致狀態資訊的丟失。

6.超分配

DRM內容122可以被複製並且傳送到其他DRM代理114，例如用戶發送DRM內容122給一朋友。為了存取該內容122，該朋友經由在DRM內容封裝中的鏈結被帶到RI 112以獲取RO 124。

7.出口(到非OMA DRM系統)

DRM內容122可以被輸出到其他DRM系統，用於在不相容OMA DRM但是支援某些其他的DRM機制的裝置上使用。如果希望，該OMA DRM架構允許RI 112表示對於DRM代理114的許可，以執行到特定的其他DRM系統的轉換，可能是由其他DRM系統所規定。該RI 112可以限制該輸出僅僅到特定的外部DRM系統。

8.未連接裝置的支援

OMA DRM使得連接裝置能夠作為媒介，以協助未連接裝置去購買並下載內容122與RO 124。例如，用戶可以具有無網路連接性的OMA DRM相容的可擕式裝置(未連接裝置)、具有網路連接性的OMA DRM相容的行動裝置(連接裝置)。在使用連接裝置來瀏覽並購買DRM內容122、以及下載DRM內容122到連接裝置之後，用戶可能希望在未連接裝置上播放該DRM內容122。在這種情況下，在連接裝置上的DRM代理114從RI 112請求並下載一域RO 124。在連接裝置上的DRM代理114然後在DCF中嵌入域RO 124。然後可以使用合適的協定透過本地連接技術(例如藍牙或USB)而將DCF傳送到未連接裝置。連接裝置與未連接裝置二者必須是OMA DRM相容以支持這個功能。未連接裝置也必須屬於與連接裝置相同的域。

安全性與信任

以下是OMA DRM 2.0安全性與信任測量的概述。通常，任一DRM解決辦法需要滿足兩個安全性要求：(1)受保護內容必須僅僅由正確認證並授權的DRM代理來存取；以及(2)對受保護內容的許可必須是由所有DRM代理認可。與DRM內容相關的許可與限制條件的實施是任何DRM方案的安全性與信任測量的主要問題。對DRM內容的未授權存取超出了由相關的RO規定的內容，以及DRM內容的非法備份與重新分配構成了任何DRM系統的主要問題。

該OMA DRM系統提供了用於在OMA環境中受保護內容的安全分配與管理的裝置，並滿足了以上所規定的要求。OMA DRM透過使用DRM代理來執行內容與RO在消費時的使用與保護，DRM代理依靠該RO的限制條件來確保內容的受保護使用。

用於分配DRM內容的基本步驟可以概述如下：

1.內容封裝。內容被封裝在安全內容貯存器(DCF)中。DRM內容是以對稱內容加密密鑰(CEK)所加密。該內容可以是預封裝的，即內容封裝不必即時地發生。對於一個內容的所有情況不使用相同的CEK，儘管這在OMA DRM中是不要求的。

2.DRM代理認證。所有DRM代理具有唯一的私/公鑰對與證書。該證書包括諸如裝置製造者、裝置類型、軟體版本、序列號等等的附加資訊。這允許CI與RI安全認證DRM代理。

3.RO產生。該RO包含CEK，CEK保證缺少相關的RO是不能使用DRM內容。RO由許可(例如播放、顯示與執行)與限制條件(例如播放持續一個月、顯示十次)組成。RO還可以包括限制條件，其在內容被存取時需要特定用戶在場(例如由用戶身份所確定)。這些許可與限制條件與其他資訊(例如版權資訊)一起具體化在RO中，可以呈現在用戶面前。

4.RO保護。在傳送RO之前，該RO的靈敏部分(諸如CEK)是用版權加密密鑰(REK)加密的，並且該RO然後被密碼地綁定到目標DRM代理。這保證了僅僅目標DRM代理可以存取該RO、該CEK和該DRM內容。另外，RI數位地簽名該RO。RO還透過包含CEK來管理對DRM內容的存取。OMA DRM版權表達語言(REL)規定了管理DRM內容的使用的語法(XML)以及許可與限制條件的語義。RO具有其自己的MIME內容類型。

5.傳遞。RO與DCF現在可以被傳遞到目標DRM代理。由於兩個項目是內在安全，所以可以使用任何傳送機制(例如HTTP/WSP、WAP推入、MMS)傳送它們。RO與DCF可以被一起傳遞，例如在MIME多部分訊息中，或者可以被單獨地傳遞。

對於RO的OMA DRM可信模型是基於公鑰基礎結構(PKI)，藉此存在多組負責人、證明人和由二者所識別並信任的一或多個認證權限。單一實體可以依據所選擇的環境與解決辦法的需要來充當負責人和證明人。PKI在證明人和負責人透過開放、不安全網路通信時使得證明人認證負責人的身份與其他屬性。在這種系統中，典型地，為了認證的目的，證明人不必保持關於與其互動的負責人的任何敏感資訊。另外，鑒定權限(CA)不直接地涉及負責人與證明人之間的事務中。如果DRM代理的證書是由RI所認證並且還沒有被撤銷，那麼RI信任DRM代理，以正確地運轉。類似地，如果RI的證書是由DRM代理所認證並且還沒有被撤銷，那麼DRM代理信任RI，以正確地運轉。

應用於OMA DRM的PKI的主要實體是CA、該裝置以及RI。OMA DRM的認證與密鑰傳送協定需要該RI能夠認證該裝置，並且該裝置能夠認證該RI。這種相互認證是由該ROAP所實現。

另外，假定裝置被提供(在製造時或者之後)有具有裝置公鑰與私鑰以及由適當的CA所簽名的相關證書。根據由該RI表示的證書優選項，該裝置必須提供合適的證書。要求該裝置在具有完整性與保密性保護的本地儲存體中儲存私鑰。

RI還具有公鑰、私鑰與由CA所簽名的證書。該證書鏈(一系列的多個證書，包括由一個CA所簽名的公鑰擁有者的證書，以及由其他CA所簽名的零個或者多個附加的CA證書)在用於對可信的證書鏈驗證的認證協定時出現在該裝置面前。

要注意到在該DRM系統中可以存在多個CA。該ROAP協定要求簽名RI證書的CA運行一線上認證狀態協定(OCSP)應答器，以用於在該協定的執行期間使用。該CA還要求定義合適的證書策略以管理所發行的證書的使用。

以下描述OMA DRM安全性的主要方面。

1.機密性，其保證資料不可由未授權方所存取。如上該，受保護內容必須僅是由正確認證並授權的DRM代理所存取。為了實現這個目的，對受保護內容進行加密。加密密鑰對每個媒體物件是唯一的，並且RO攜帶隱藏在密鑰中的僅僅由預期的接收方存取的加密密鑰。

2.認證，其是用於一方向另一方識別本身的方法。在OMA DRM中，以4傳註冊協定、2傳(2-pass)RO獲取協定與2傳加入域協定來實現相互的DRM代理與RI認證。依據所使用的協定與所發送的訊息，經由在當時、或者在時間戳上的數位簽名來實現認證。1傳(1-pass)RO獲取協定經由在時間戳上的數位簽名實現RI認證。其不對該RI認證DRM代理，但是由於受保護內容是用接收方公鑰隱藏的，因此可以經由密鑰綁定來間接地執行認證。2傳離開域協定經由在時間戳上的數位簽名對RI認證DRM代理。其不對DRM代理認證RI。要求RI在RO的傳遞期間對DRM代理自行認證。這提供了關於該RI可信賴性的一些保證等級。

3.資料完整性保護確保用於檢測對資料未授權的修改的能力。在OMA DRM中，在適當的時候，資料完整性保護是經由在ROAP訊息和RO上的數位簽名來實現。

4.密鑰確認確保包含受保護密鑰的訊息的接收方，該密鑰值是訊息發送方知道的。在該DRM環境中，這個屬性防止由一個RI被另一個RI對RO的未授權的再發行。在OMA DRM系統中，密鑰確認是由經受保護密鑰的媒體存取控制(MAC)和透過使用受保護密鑰的一部分作為MAC密鑰的發送方身份而實現。

根據正確的性能與安全的實現二者，DRM代理必須被RI所信任。在OMA DRM中，每個DRM代理是用唯一的密鑰對與關聯的證書所提供的，以識別該DRM代理並證明在該代理與這個密鑰對之間的綁定。這允許RI使用標準PKI程序來安全地認證DRM代理。

在該證書中的資訊使RI能夠根據其商業規則、其內容的值等來應用策略。例如，RI可以信任某些製造者，或者其可以保持DRM代理的更新列表，根據由RI定義的一些標準知道該DRM代理可信任或不可信任。

該DRM內容格式(DCF)是對於加密內容的以其自己的MIME內容類型的安全內容封裝。除加密內容之外，其包含附加資訊，諸如內容說明(原始內容類型、廠家、版本等等)、RI統一的資源識別碼(URI)(可以獲得RO的位置)等等。這個附加資訊是不加密的，並且可以在檢索到RO之前出現在用戶面前。解鎖在DCF內部的DRM內容所需要的CEK被包含在該RO內。由此，缺少RO不可能存取DRM內容，並且DRM內容只能以在該RO中規定的形式而使用。OMA DRM包括允許DRM代理去驗證DCF的完整性、防止由未授權實體對該內容的修改的機制。

OMA DRM系統假定DRM時間在該DRM代理中出現。由於用戶不能改變該DRM時間，其定義了一個機制，該DRM時間可以與由OCSP應答器所保持的時間同步。一些限制條件(例如絕對時間限制條件)，以及RO的傳遞協定的一些方面，依賴於具有安全時間源的DRM代理。在OMA DRM規範的上下文中的DRM時間意味著不可由用戶改變的精確時間以及時間值。在需要時，例如如果在長時間的電源故障之後丟失DRM時間，OMA DRM規範提供用於同時發生電源故障DRM時間的機制。一些能力受限的未連接裝置可以不支援即時時鐘，由此可以不支援DRM時間。然而，連接裝置必須支援DRM時間。

OMA DRM防止RO重放保護攻擊。RO重放攻擊的例子是其中中間物截取RO在對DRM代理的傳遞期間的有限次數的播放。當在該DRM代理上的版權期滿時，可以再次從中間物傳送(重放)所截取的RO。OMA DRM防止這種以及類似的攻擊發生。

OMA DRM系統經由使用上面列出的安全性機制提供應用程式層安全性。因此，其不依賴或假定傳輸層安全性。

ROAP在OMA DRM 2.0中的允許安全、與RO有關資訊的基於認證的交換方面處於中心地位。ROAP是在RI與裝置中的DRM代理之間的一組DRM安全性協定的通用名稱。該協定組包含若干子協定：

1.用於利用RI註冊裝置的4傳協定，如第2圖所示。

2.包含對RO的請求和傳遞的2傳RO獲取協定，如第3圖所示。

3.與RO從RI到裝置的傳遞有關(例如發出訊息/推入)的1傳RO獲取協定，如第4圖所示。

4.用於裝置加入一域的2傳加入域協定，如第5圖所示。

5.用於裝置離開一域的2傳脫離域協定，如第6圖所示。

第2圖是4傳註冊協定200的流程圖。該協定200利用裝置202、RI 204與OCSP應答器206。該裝置202一透過發送一裝置問候訊息(Device Hello message)來啟動(可能在接收ROAP觸發器時)與RI 204的聯繫(步驟210)，裝置問候訊息包含諸如裝置ID(RI 204可以稍後檢查OCSP應答器206的裝置證書的散列)以及其他資訊的資訊。表1示出了在裝置問候訊息中的主要組成。在裝置問候訊息中的資訊都沒有被完整性保護，即，沒有對於該訊息的簽名。

回應於裝置問候訊息(步驟210)，RI 204發送RI問候訊息到裝置202(步驟212)，其包含諸如RI的證書憑證(以RI ID的形式)、一些會話相關的(防回覆目的)場合與會話數量的資訊，以及諸如有關RI 204可識別的裝置的信任鏈的資訊的其他可選資訊。表2示出了RI問候訊息的格式。注意到在RI問候訊息中的資訊都沒有被完整性保護。

在包含在RI問候訊息的資訊的成功驗證下，該裝置202發送註冊請求訊息(步驟214)，該註冊請求訊息包括強制資訊，諸如請求時間、會話ID以及簽名和諸如證書鏈、可信RI授權錨點、擴展等的可選資訊。表3示出了註冊請求訊息的格式。該註冊請求訊息在其結尾包含了在裝置202和RI 204之間所交換且直至在註冊請求訊息中的簽名欄位的所有訊息的數位簽名，即整個裝置問候訊息、整個RI問候訊息以及直至(並排除)簽名欄位的註冊請求訊息的欄位。這個數位簽名是使用裝置的私鑰形成的。包括數位簽名提供對關聯的ROAP訊息的一些完整性保護。

除非裝置202經由在擴展中的資訊指示：不需要或者不支援OCSP驗證，否則RI 204發送OCSP請求訊息到該OCSP應答器206(步驟216)，以請求對由裝置202提供給RI 204的資訊的驗證。該OCSP應答器206在請求訊息中查找資訊以試圖驗證該資訊，並返回包含請求結果的OCSP應答訊息(步驟218)。

RI 204發送註冊應答訊息到裝置202(步驟220)，該訊息包含對註冊是成功還是不成功的指示和其他資訊。表4示出了註冊應答訊息的格式。該註冊應答訊息在其結尾包含註冊請求訊息和註冊應答訊息的SHA-1散列(直到以及排除該簽名欄位)。這個數字簽名是使用RI的私鑰形成的。包括數位簽名可提供對關聯的ROAP訊息的一些完整性保護。注意到在該SHA-1散列被用於數位簽名時，可以使用用於應用數位簽名的任何適當的演算法。

第3圖是2傳RO獲取協定300的流程圖。該協定300使用裝置202和RI 204，並且在已經完成4傳註冊協定200以及裝置202已經接收關於該RI 204的有效證書鏈之後進行操作。協定300是由裝置202使用以從該RI 204請求RO。裝置202發送RO請求訊息到RI 204，以請求RO(步驟310)。表5示出了RO請求訊息的格式。RO請求訊息包含對訊息的數位簽名(排除簽名欄位)。

表5.RO請求訊息的格式

回應該請求訊息，RI 204發送RO應答訊息到裝置202(步驟312)。RO應答訊息包括RO或者包括將不發送RO的指示。

表6示出RO應答訊息的格式。在成功的狀態情況中，RO應答訊息包含數位簽名，也就是除簽名欄位外的RO請求訊息和RO應答訊息的SHA-1散列。

第4圖是1傳RO獲取協定400的流程圖。該協定400利用裝置202與RI 204。在協定400中，缺少裝置202的請求，RI 204單方面地發送包含RO的RO應答訊息到裝置202(步驟410)。例如，協定400應用於推入使用的情況。表7示出了RO應答訊息的格式。

第5圖是2傳RO加入域協定500的流程圖。該協定500利用裝置202與RI 204。當裝置202想要加入一域時，裝置202發送加入域請求訊息到RI 204(步驟510)。RI 204估計該請求並發送加入域應答訊息到裝置202(步驟512)。表8示出了加入域請求訊息的格式，表9示出了加入域應答訊息的格式。

第6圖是2傳RO離開域協定600的流程圖。該協定600利用裝置202和RI 204。當裝置202想要離開一域時，裝置202發送一離開域請求訊息到RI 204(步驟610)。RI 204估計該請求，並發送一離開域應答訊息到裝置202(步驟612)。表10示出了離開域請求訊息的格式，而表11示出了離開域應答訊息的格式。

除1傳RO獲取協定之外，可以使用ROAP觸發器啟動包括在該ROAP組中的所有協定。作為用戶互動的結果，裝置202還可以單方面地啟動協定。RI 204也可以產生並發送ROAP觸發器到裝置202，以觸發ROAP協定交換。或者，RI 204可以透過提供必要的資訊(諸如RO識別碼和域識別碼)來授權對這些系統的ROAP觸發器產生。ROAP觸發器(不論由RI 204直接地或者間接地產生)還可以由其他系統(例如由CI)發送到裝置202。

當裝置202接收ROAP觸發器時，其儘快啟動ROAP協定交換。作為接收ROAP觸發器的結果，必須已經在啟動任何ROAP協定前獲得合適的用戶允許。由於該ROAP包括幾個協定，ROAP觸發器包括待由裝置202開始的實際協定(例如註冊、RO獲取、加入域或者離開域)的指示。

ROAP訊息以及如何由該協定處理該訊息，不僅提供該RO和它們的相關處理，而且還提供圍繞在OMA DRM 2.0中的RO的安全性功能。更具體地，由ROAP協定解決以下安全性與信任方面：

1.在該RI與該裝置之間的相互驗證；

2.透過使用在多個訊息中的場合來計數重放攻擊；

3.保護該ROAP訊息或者部分該ROAP訊息的完整性；以及

4.在ROAP訊息或者部分ROAP訊息中的安全DRM時間的驗證。

可信計算技術

近來，可信計算技術已經出現在文學與產品中，主要是在可信計算組(TCG)的技術傘下。該TCG技術提供了方法，藉此計算實體可以透過信任鏈的使用而為自己並為其他裝置建立可信度，這樣在這種裝置上的處理或計算可以為：

1.對平臺與多個硬體(HW)以及軟體(SW)元件的可信度被評定；

2.只有當建立合適的信任等級時有效，並且可以基於外界請求對本身以及對於其他裝置有效；和

3.外部方可以執行對資訊交換的評定與判定，且以其他裝置處理，以及基於這種目標裝置的明顯的信任等級。

該TCG定義核心處理模組，稱作可信處理模組(TPM)，其具有以下特徵：

1.對模組及其介面進行實體保護；

2.受保護的揮發與非揮發性儲存空間；

3.在模組內部的受保護的加密函數，其可以執行加密與數位簽名；

4.平臺配置暫存器(PCR)的使用，PCR透過散列擴展以連續地獲得平臺及其SW組分的“狀態(state)”；

5.裝置指定與安全認可密鑰(EK)的存在，根據充當該裝置的認證根但不是以直接方式的PKI。該EK從不暴露在外，但是其別名稱作認證身份密鑰(AIK)，被用來旗標平臺的完整性測量值；和

6.使用在記憶體“二進位大物件(blobs)”中的資料“隱藏”連同由AIK所簽字的PCR值，使得只有當驗證平臺或者SW完整性(由來自TPM和來自密封的記憶體blob的匹配PCR值測量和驗證)時才可以存取或者擷取資料。

特別是在行動電話裝置的環境中，對於在保護這種行動裝置上的DRM應用中的可能應用，檢查可信計算技術。先前的方法透過利用包括在某些方法中的TCG技術來保護該DRM應用，該的某些方法使用TPM密封的程序，並且在該TPM與具有密鑰保護的儲存區中，該記憶體二進位大物件為在ROAP協定處理之後使用TCG密鑰而安全地儲存DRM相關資料。

然而，現有技術既沒有明確地解決也不沒有順序地解決如何在平臺及/或DRM軟體上建立和使用“信任”。現有技術也沒解決特定的技術以保護ROAP訊息中的完整性，而增強在OMA DRM 2.0系統中的完整性處理。本發明包括為了這些目的的新技術。

當前的OMA DRM 2.0規範根據涉及的CA、RI與該裝置的PKI提供了有力的安全性方法。然而，存在具有與平臺、SW、代理和訊息的安全性與完整性相關的易損壞性，這是在OMA DRM 2.0規範本身以及與裝置和RI的適應OMA DRM 2.0的非規定實現有關的二者內。

該OMA DRM規範已經應答了任何裝置或者RI可能面對的各種惡兆和易損壞性，即使它們是符合OMA DRM 2.0規範的。這些易損壞性包括：

1.實體損害，其中攻擊者可以試圖在物理上或其他方面損害DRM系統的實體。實體損害攻擊的類型包括對該裝置上的DRM代理的損害和對該RI中的DRM SW的損害。對實體損害的結果包括私鑰、域密鑰、RO加密密鑰、內容加密密鑰和受保護內容的公開，與對DRM代理的重放快取記憶體的完整性保護的丟失一樣，例如，及/或對內部儲存在DRM代理中的保護的損失。而且，還可能發生DRM時間的丟失。諸如參照IETF RFC3280論述了對受損害的CA或者OCSP應答器的PKI的影響。

該OMA DRM系統依賴證書撤銷，以最小化由受損害的實體引起的損害。DRM代理和RI必須總是透過檢查實體的證書狀態來驗證與其通信的實體沒有受到損害。實體損害攻擊可能發生在“前向”和“反向”路徑二者中。前向損害攻擊是在該DRM實體(RI、DRM代理、CI、CA或OCSP應答器)上導致未授權的行為。反向損害攻擊壓制或者減弱DRM代理的安全性、完整性設定以及配置。

2.訊息移除，藉此攻擊者可以刪除在DRM代理與RI之間所發送的訊息，典型地引起拒絕服務(DoS)攻擊。訊息移除攻擊可以包括：在註冊協定或者RO獲取協定期間的訊息移除、重放場合移除、對ROAP觸發器的移除等等。

3.訊息修改，藉此攻擊者可以修改在DRM代理與RI之間發送的任何訊息，典型地引起DoS攻擊。訊息修改攻擊可以包括在註冊協定期間、在加入域與離開域協定期間以及各種ROAP觸發器的修改。

4.訊息***，藉此攻擊者可以在RI與DRM代理之間的任一點將訊息***到通信通道中。攻擊者還可以記錄訊息，並設法在稍後的時間點重放它們。訊息***攻擊可以包括在註冊協定時、在2傳與1傳RO獲取協定時以及在各種ROAP觸發器時的訊息***。

5.諸如一般DoS攻擊的其他攻擊，被動的攻擊諸如訊務分析與秘密公開。

確定對當前OMA DRM規範與實現的以下問題。定義了“完整性”的擴展概念，如應用於該OMA DRM方案。傳統上意義上，OMA DRM規範僅僅解決小範圍的ROAP訊息完整性。在本發明定義的完整性的擴展概念中，注意到在下文中可以考慮何處以及何種類型的完整性。

1.DRM平臺完整性。這涉及在平臺實體上或者內部的完整性，即在包括該裝置、RI與內容功能的物理實體。不同的實體包括作業系統(OS)、啟動碼(例如在PC範例中的BIOS)、用於記憶體存取的HW/韌體(FW)/SW、各種HW/FW/SW實體(其處理涉及安全性的功能(諸如密碼學與密鑰管理，以及諸如策略、證書等的保密資料的特權儲存)以及網路與本地連接性HW/FW/SW。平臺完整性是確定平臺是否是有效、真實的、除了合理的處理之外沒有被修改並且僅如預期操作。

2.DRM SW完整性。DRM SW是指在該裝置、RI或者CI中駐留的軟體實體與元件，其執行對OMA DRM規範以及它們的程序所特定的功能。在該裝置處，DRM代理由DRM SW組成。在RI與CI處，DRM SW合起來指執行諸如RO封裝、DCF格式化、內容加密、內容或者RO傳遞、驗證、ROAP處理等等的DRM特定的功能的SW組。如果DRM SW是有效、真實、除了合理的處理之外沒有被修改並且僅如預期操作，這樣就保持DRM SW完整性。

3.ROAP訊息和資訊的完整性。如果資訊是有效的、真實的並且除了合理的處理之外沒有被修改，這樣就保持該ROAP訊息與其組成資訊的完整性。在OMA DRM 2.0規範中，利用數位簽名完整保護了ROAP訊息與其組成資訊的某些子集。

4.媒體物件和DRM內容的完整性。媒體物件與DRM內容也必須被完整性保護的，即必須不能被修改、刪除或者錯誤地***，不論它們是儲存在該裝置、RI、或者CI、或者是在任何兩方之間的傳送或者傳遞中。特定的興趣是內容的透過空中(OTA)的傳遞，如適用於對行動裝置的內容的傳送，其中該DRM內容實質上是使用開放通道所傳送。

5.有關DRM資訊的完整性。必須安全地保護諸如實體ID(裝置ID、RI ID等等)、加密密鑰(CEK、REK)以及簽名密鑰、RO自身、上下文資訊、證書以及與其他信任鏈有關的資訊的有關DRM資訊，這意味著應該不僅為了機密性而且還為了完整性而保護它們。

注意到當前OMA DRM 2.0規範、現有技術都不具有對實體損害或者完整性問題的提議的解決辦法。解決辦法的缺乏由於以下問題：即使根據OMA DRM 2.0規範正確地實現所有ROAP程序，例如裝置如何能夠真實地知道RI的平臺是否是可信？換句話說，該裝置如何能夠知道RI的平臺是否不濫用該裝置以ROAP協定的一部分發送的資料或者濫用DRM處理本身？例如，該裝置不知道RI是否因為RI的平臺SW受到損害而將任意且不正確地限制裝置的使用版權，以及其限制對該裝置的其他有效使用版權。類似的問題在DRM軟體的完整性的問題上也存在。更具體地，以下是從如上該的完整性擴展概念的角度看的當前OMA DRM 2.0系統的一些問題。

1.缺乏對平臺和DRM SW的完整性的檢查和報告的方法。作為有關上面所識別的實體損害惡兆，在現有技術中沒有方法用於明確並架構該裝置與RI之間的平臺完整性驗證與SW代理完整性驗證，不論是由OMA DRM 2.0規範所規定或者作為該TCG 1.2使用範例的一部分。對於平臺完整性驗證這是特別真實的，而不是僅僅對DRM代理。

2.會有意地損害平臺(諸如PC或者PDA，如與該裝置或伺服器相關的，如對於RI)，其可以導致阻止正確地執行DRM代理與RI代理SW，甚至阻止給定的受保護的正確與保密性和受完整性保護的資訊。例如，另外的較好保護的DRM代理SW可以用來經加密的文件把一些資訊在處理期間或者之後儲存在共用的記憶體中。在此情況下，受損害的平臺過份地存取共用記憶體並刪除資訊、改變資訊或者***新的假資訊，然後這些資訊可能隨後由可以感知這種假資訊為真實的DRM代理SW處理。這可以導致DoS攻擊、對保密資訊的非法洩密、或者未授權的傳遞、分配、或者DRM RO或DRM內容的消耗。

3.是處理DRM有關資訊的SW部分的DRM代理SW和RI SW可以由於種種理由而變為受損的。例如，這種SW可能由病毒或者其他惡意的SW實體改變。在平臺或DRM SW中的這種損害的一個結果將是對OMA DRM 2.0考慮的訊息和資訊的完整性的後續損害，尤其是對ROAP協定訊息。因為僅僅一些而不是所有的ROAP訊息是受完整性保護的，它們理論上可以在損害的裝置與欺詐或受損的RI之間以同步的方式被處理。可以在裝置和RI二者上同時修改訊息，並且訊息仍舊展現成“完整性驗證”，這是由於以同樣的方法修改該訊息。

4.ROAP訊息的不充分完整性保護。由於涉及訊息完整性，由多個訊息欄位所攜帶的ROAP訊息和資訊是易損壞的，也就是不由該OMA DRM 2.0規範解決。例如，在OMA DRM 2.0規範中現在規定的ROAP訊息完整性保護留下這樣的漏洞，如：

4A.不是所有ROAP訊息是受完整性保護的。在某些情況下，在所有訊息中包括數位簽名不可以形成易損壞性。

4B.即使當ROAP訊息或者資訊的某些欄位是由數位簽名進行完整保護的，一旦這種資訊已經被解密、完整性檢查，並且然後被以純文本“使用”，惡意的實體可以存取明文資訊以及刪除、改變或者重新分配先前的完整性檢查過的資訊。由此，需要增強的完整性保護。

5.易損壞性涉及該DRM內容與其傳遞的完整性。更具體地，存在以下問題：

5A.內容完整性檢查機制是未完成。例如，當該內容是在運送中或者傳遞(例如OTA下載)中時，內容的完整性是未規定的。例如對於DCF的簽名僅僅產生用於ROAP程序。直到並在該ROAP程序發生之前，當儲存在CI中時，沒有管理內容完整性的完整性檢查機制。

5B.內容加密、甚至是在ROAP協定中使用是強制的，但是完整性檢查僅僅是可選的。

5C.尤其對於用於流動服務的封包內容，PDCF格式具有時序問題。在可以檢查整個資料流的完整性之前，可以下載甚至可以消耗(即在媒體播放器上播放)已被非法修改的封包。

中心問題變為：多方(裝置、RI與CI)如何可以確信平臺完整性與DRM SW完整性？由此，需要去增強並驗證平臺(例如OS、BIOS、驅動器、媒體播放器、通信軟體、共用記憶體等等)的完整性的方法，基於其可以信任DRM代理SW或者RI SW。本發明解決了現有技術的缺點。

本發明揭露幾種方法，用於增強與OMA DRM規範v2.0有關的實體、訊息以及處理的完整性。該方法使用通常稱為可信計算技術的技術，其由工業論壇可信計算組(TCG)規定。在本發明第一實施方式中，揭露一種用於驗證平臺與DRM SW完整性或者可信度的技術，可以修改以及不修改DRM ROAP與DCF規範。在第二實施方式中，揭露一種在不改變現有ROAP協定的前提下，增強OMA DRM ROAP訊息、組成資訊以及處理的完整性的技術。在第三實施方式中，對現有ROAP協定進行一些改變的前提下，揭露一種用於增強ROAP訊息、資訊以及處理的完整性的技術。

在下文中，術語“無線發送/接收單元”(WTRU)包括但不侷限於用戶裝置、行動站、固定或行動用戶單元、傳呼機或者能夠在有線或無線環境中運作的任何其他類型的裝置。當下文提及時，術語“基地台”包括但不侷限於B節點(Node B)、站點控制器、存取點或者在無線環境中的任何其他類別的周邊裝置。

本發明揭露了這些方法，藉此關於信任狀態或者DRM實體(例如裝置、RI或者CI)的完整性的資訊是明確地、互相地請求並在任何兩個DRM實體之間作為對OMA DRM程序的預必備資訊。

第7圖中顯示出這個方法的一般架構700。該架構包括四個DRM實體：裝置702、RI 704、CI 706以及專用認證權限(PCA)708。平臺完整性檢查假定PCA 708具有對用於其他DRM實體(例如裝置702、RI 704以及CI 706)的可信計算(例如TCG)證書的記錄，並提供了對用於TCG證書的認證的信任的根源。

想要在它們自己之間進行相互的平臺完整性檢查的任一對實體(例如裝置702與RI 704、裝置702與CI 706、或者RI 704與CI 706)有可信計算能力(例如配備TCG可信處理模組(TPM)710)。這暗示該可信計算能力DRM實體不僅具有TPM 710(或等同物)，而且還具有相關的TCG資源，諸如AIK 712、SML 714以及使用二進位大物件716的受保護記憶體。還給出的是OS或者平臺軟體718以及DRM軟體720。

當滿足以上要求時，任何不同的DRM實體對可以使用PCA 708以及可信計算能力互相檢查它們的平臺完整性或者平臺可信狀態。例如，對於在裝置702與RI 704之間相互完整性檢查的程序如下。

裝置702、RI 704以及CI 706都能夠執行OS或者其他平臺軟體元件的自我檢查(步驟730)，以及對DRM軟體的自我檢查(步驟732)。自我檢查可以作為大的驗證處理的一部分而請求(如在以下詳情論述的)或者可以獨立的處理。如果任何一個自檢查失敗，那可能指示實體已被損害並不應被信任。

裝置702發送關於其平臺TCG證書的資訊到RI 704(步驟740)。平臺TCG證書的例子包括但不侷限於簽名的TCG平臺證書或者簽名的TPM證書。作為證書的一部分，裝置702還可以對RI 704發送自證明的已經檢查了可信狀態或平臺完整性的旗標(flag)作為補充資訊。如果裝置702將要驗證RI 704的平臺完整性，在步驟740中所發送的證書資訊還將包含裝置702的指示，其指示裝置702需要RI 704啟動用於驗證其平臺完整性的程序。注意到裝置702只有在RI的平臺完整性狀態的驗證是可選特性時才能作出關於是否驗證RI 704的平臺完整性的決定；在一個實施方式中，驗證RI的平臺完整性是強制特性。

在從裝置702接收證書資訊時，RI 704把該證書資訊中繼轉發到PCA 708(步驟742)，並且還請求PCA 708驗證關於裝置702的證書，尤其是裝置的當前最大可信度。PCA 708然後發送關於裝置702的當前最大可信度資訊到RI 704(步驟744)。一接收到來自PCA 708的裝置平臺可信度資訊以及可選擇性地接收到來自裝置702的補充資訊，RI 704估計裝置702的信任等級。RI 704判斷是否對該裝置平臺的完整性給予充分信任，以進一步開始DRM程序，諸如註冊協定或者RO獲取協定。

裝置702，或者作為強制程序或者作為可選程序，可以用與步驟740-744類似的可逆的方式估計RI 704的平臺完整性。更具體地，RI 704發送關於其平臺TCG證書的資訊到裝置702(步驟750)。作為證書的一部分，RI 704還可以對裝置702發送自證明的已經檢查了可信狀態或平臺完整性的旗標作為補充資訊。

在從RI 704接收到有關TCG的資訊時，裝置702把該資訊中繼轉發到PCA(步驟752)，並且也請求PCA 708驗證關於RI 704的證書，尤其是RI的當前最大可信度。PCA 708然後發送關於RI 704的當前最大可信度資訊到裝置702(步驟754)。一旦從PCA 708接收到關於RI 704的RI平臺可信度資訊以及還可選擇性地接收到來自RI本身的補充資訊，裝置702估計RI 704的信任等級。裝置702判斷是否對RI平臺的完整性上給予充分信任，以開始進一步的DRM程序，諸如註冊協定或者RO獲取協定。

裝置702，或者作為強制程序或者作為可選程序，可以估計CI 706的平臺完整性。CI 706發送關於自己的平臺TCG證書的資訊到裝置702(步驟760)。作為證書的一部分，CI 706還可以對裝置702發送自證明的已經檢查了可信狀態或者平臺完整性的旗標作為補充資訊。

在從CI 706接收有關TCG的資訊時，裝置702把該資訊中繼轉發到PCA(步驟762)，並且還請求PCA 708驗證關於CI 706的證書，尤其是CI的當前最大可信度。PCA 708然後發送關於RI 706的當前最大可信度資訊到裝置702(步驟764)。一旦從PCA 708接收到關於RI 706的CI平臺可信度資訊以及還可選地接收到來自CI本身的補充資訊，裝置702估計CI 706的信任等級。裝置702判斷是否對CI平臺的完整性給予充分信任，以開始進一步的DRM程序。

裝置702的平臺完整性可以由CI 706進行如下驗證。裝置702發送關於其平臺TCG證書的資訊到CI 706(步驟770)。作為證書的一部分，裝置702還可以對CI 706發送自證明的已經檢查了可信狀態或者平臺完整性的旗標作為補充資訊。如果裝置702將要驗證CI 706的平臺完整性，在步驟770中所發送的證書資訊還將包含裝置702的指示，其指示裝置702需要CI 706啟動驗證CI 706的平臺完整性的程序。注意到裝置702只有在CI 706的平臺完整性狀態的驗證是可選特性時才能作出是否驗證CI 706的平臺完整性的決定；在一個實施方式中，驗證CI 的平臺完整性是強制特性。

在從裝置702接收證書資訊時，CI 706把該證書資訊中繼轉發到PCA 708(步驟772)，並且還請求PCA 708驗證關於裝置702的證書，尤其是裝置的當前最大可信度。PCA 708然後發送關於裝置702的當前最大可信度資訊到CI 706(步驟774)。一接收到來自PCA 708的裝置平臺可信度資訊，以及還可選地接收到來自裝置702的補充資訊，CI 706估計裝置702的信任等級。CI 706判斷是否對裝置平臺的完整性給予充分信任，以開始進一步的DRM程序。

注意到在上面的例子中，步驟740-744對於裝置702向RI 704驗證自身的完整性狀態是本發明的強制特徵。然而，向裝置702驗證RI 704的平臺完整性(步驟750-754)，或者向裝置702驗證CI 706的平臺完整性(步驟760-764)，以及向CI 706驗證裝置702的平臺完整性(步驟770-774)是DRM系統中可選的、目前高度推薦的特徵。

注意到這些程序不需要由需要驗證的實體主動啟動而開始。完整性驗證程序可以從希望驗證對方完整性的實體的請求開始。在此情況下，步驟740、750、760或者770各步驟將被另一步驟領先，藉此希望對對方平臺完整性驗證的實體呼叫或者請求對方發送相關的涉及信任的資訊。

在另外的實施方式中，對於實際的OMA DRM系統實現，為了如上該建議的平臺完整性驗證程序的條件或者觸發器機制可以包括以下：

1.裝置平臺完整性驗證程序(即步驟740-744)，可以由以下的一個或多個執行。

1A.在裝置希望啟動新的4傳ROAP註冊協定之前。

1B.每一RI一次，在與特定RI的第一次註冊發生之前。

在這種情況下，RI在第一次註冊之前將接收該裝置的TCG證書一次，然後RI透過綁定該證書資訊與TPM密鑰來保護該裝置的證書資訊在其擁有的TPM下面。該RI稍後解開所儲存的TCG證書，並週期地或者基於一些事件驗證其已經接收的該裝置的TCG證書是否仍然是有效的，例如經由與OCSP CA協商。

1C.週期性地，每次規定的持續時間，例如，TDEV-PLATFORM-LAST-REG，為從該裝置利用相同RI完成上一次註冊協定時起耗費的時間。

1D.週期性地，每次規定的持續時間，例如，TDEV-PLATFORM-LAST-REPORT，為該裝置上一次向相同RI驗證了其平臺完整性狀態時起耗費的時間。

2.如果以及當實現該RI平臺完整性驗證程序(即步驟750-754)時，可以經由以下一個或多個來執行。

2A.每一裝置一次，在與特定的裝置進行第一次註冊之前。在這種情況下，該裝置在第一次註冊之前將接收該RI的TCG證書一次，然後該裝置透過綁定該證書資訊與TPM密鑰來保護該RI的證書資訊在其擁有的TPM下面。該裝置稍後解開所儲存的TCG證書，並週期地或者基於一些事件驗證其已經接收的該RI的TCG證書是否仍然是有效的，例如經由與OCSP CA協商。

2B.在任何時候RI從該裝置接收指示，該裝置希望RI驗證其對該裝置的完整性狀態，或者作為獨立的訊息或者作為修改的ROAP協定訊息的一部分。

2C.週期性地，每次規定的安全持續時間，例如，TRI-PLATFORM-LAST-REPORT，為該RI上一次對該裝置驗證了其平臺完整性狀態時起耗費的時間。

3.由於用於在裝置與CI之間的平臺完整性驗證，對於完整性驗證處理的週期的/或事件驅動的發生，可以考慮類似於以上的機制。此外，在該裝置對該CI的平臺完整性驗證的情況下，還可以每次在必須購買或者下載內容之前執行，也可能反之亦然(即必須對該CI驗證該裝置的平臺完整性)。

現有技術已經考慮連同強健DRM的應用程式的使用了TCG技術的“安全的啟動程式”。在這種方案中，每當裝置被啟動，該平臺的OS與其他啟動相關的代碼是經完整性檢查的，隱含地在可以運行任何DRM應用程式之前執行平臺完整性檢查。本發明提供了對啟動時間平臺完整性檢查的更系統化且明確的使用，以及其他時間根據預定時段和某些事件發生時的平臺完整性檢查。本發明也歸納了從該裝置到RI以及到CI的平臺完整性檢查。因為正是由於裝置已經正確地接收了特定的有效CO，連續平臺完整性檢查是有益的，這不意味著應該從那時到將來認為RI或CI是不明確可信的。週期性及/或事件驅動的連續的對可信度的驗證提供了好的保護機制。

此外，由於對在該裝置與CI之間的完整性檢查的需要，即使該內容在RO之前到達，當該CI的平臺或者該CI的DRM SW被損害時，該內容可能是損害的。例如，假定用戶已經下載了檔案。即使當還沒有獲得該RO，用戶可能無意中點擊該內容、或者可能在該內容上執行有效性檢查。如果該內容是被損害的(例如其上已經附加了病毒)，即使沒有RO，該內容也能破壞裝置。此外，在裝置與CI之間的預下載互動中(例如在發現步驟期間)，損害的裝置能傷害CI，例如藉由將附加到內容的病毒增加到為該CI設計的訊息上。另外，從商業觀點，CI不想要將內容發送到損害的裝置；例如，損害的裝置可能對未授權的接收方免費再分配內容。由此，在裝置與CI之間的相互的平臺(與SW)完整性驗證具有保護整個系統的優點。

還注意到可以有對包含在以上結構的論述中列出的中心思想的幾個不同的方式。以下論述兩個這種例子，但是注意到這些僅僅是根據以上段落描述的架構對主要原理的說明性例子。

平臺完整性驗證

第8圖是在兩個實體之間執行平臺完整性驗證的方法800的流程圖。兩個實體可以是裝置與RI、裝置與CI、或者RI與CI。該方法800利用請求實體(RE)與目標實體(TE)；注意到該對的任何一個實體(裝置、RI或者CI)都可以是RE。該方法800以同樣的方式操作，無論哪個實體是RE以及哪個實體是TE。

該方法800從RE對TE發送請求以請求TE報告其平臺完整性狀態開始(步驟802)。回應於該請求，TE發送其TCG證書到該RE(步驟804)。例如，該TCG證書可以包括平臺證書、TPM證書或者一致性證書。RE然後發送該TE的證書到OCSP應答器，用於對該證書的驗證(步驟806)。該OCSP應答器檢查TE的TCG證書，並對該RE報告該驗證狀態(步驟808)。

RE發送一請求到該TE，以報告其擁有的平臺完整性狀態(步驟810)。該TE檢查其平臺完整性狀態(步驟812)，發送平臺完整性狀態旗標到該RE(步驟814)，並且該方法終止(步驟816)。

該方法800可以不加任何修改而應用到ROAP協定(以下結合第9圖進行論述)，或者稍加改變而應用到ROAP協定(以下結合第10圖進行論述)。

不作改變對ROAP協定的完整性驗證

第9圖是在裝置902與RI 904之間使用分別來自ROAP協定的TCG技術(即利用OCSP應答器/PCA 906)交換有關完整性的資訊的方法900的流程圖。注意到在方法900中，相同實體906被描述為用於DRM處理的PCA以及用於TCG處理的OCSP應答器。在方法900中，在ROAP 4傳註冊協定之前執行平臺完整性驗證(由虛線矩形所示)。在註冊協定之前執行平臺完整性驗證是有用的，因為註冊協定不是常常執行，並且平臺完整性驗證處理花費一些時間才能完成；如果對每個訊息執行平臺完整性驗證，系統的整個操作可能不必要地減緩。所屬技術領域中具有通常知識者可以假定在執行平臺完整性驗證之後，RI僅僅接收一個裝置問候訊息，由於其將指示可信裝置。如果由RI從相同裝置接收多於一個裝置問候訊息，其可以是對DoS攻擊的指示。還可以結合認證協定與物件獲取協定一起來執行平臺完整性驗證。

在用RI 904啟動4傳註冊協定之前，裝置902利用RI 904開始單獨程式組，以執行平臺完整性的相互驗證。裝置902首先向RI 904發送其自己的TCG證書(例如平臺證書、TPM證書、一致性證書等等)或者包含或與該TCG證書有關的其他資訊(步驟910)。可選地，裝置902還發送請求到RI 904，以對裝置902檢查並報告其自己的平臺完整性狀態；這個請求是被包含在裝置證書中的。

RI 904請求PCA 906驗證裝置的TCG證書(步驟912)。PCA 906回應於RI的請求，並發送有關裝置的TCG證書的資訊(步驟914)。

RI 904請求裝置902報告裝置902自己的平臺完整性狀態旗標(步驟916)。此外，如果裝置902已經在步驟910中請求RI 904驗證並報告其平臺完整性狀態，並且如果RI 904希望並能夠對該請求表示感謝，在步驟916中，RI 904對裝置902發送其自己的TCG證書或者包含或與該TCG證書有關的其他資訊。如果RI 904不能或不希望對該請求表示感謝，其發送“不感謝”訊息到該裝置。RI 904可以因為許多理由不回應該請求，包括資源受限的RI(即該RI已經沒有充分的可用資源去回應該請求)或者裝置可信性檢查失敗。該裝置可以依據裝置對該RI具有的置信程度中斷該協定；如果該裝置信任RI，其或許繼續該協定，即使RI拒絕回應該請求。在接收來自RI 904檢查平臺狀態的請求下，裝置902檢查其自己的平臺完整性狀態(步驟918)。

該裝置902請求PCA 906驗證RI的TCG證書(步驟920)。在這種接收來自裝置902的請求的情況下，PCA 906返回有關RI的TCG證書的資訊(步驟922)。裝置902發送其平臺完整性狀態旗標到RI 904(步驟924)。如果RI 904接收到來自裝置902檢查其完整性狀態的請求，並且如果RI 904希望並能夠對該請求表示感謝，RI 904檢查其自己的平臺完整性(步驟926)。RI然後返回其平臺完整性狀態旗標到裝置902(步驟928)。有關RI完整性檢查的可選步驟可以以任何次序執行；那些步驟不需要與如第9圖所示的裝置完整性檢查有交叉。另外，RI可以啟動其自己的完整性檢查。此外，如果RI由於任何可能的理由而拒絕完全地回應對其自己的TCG證書資訊的請求，其可以以合適的方式對裝置指示這種事實，例如在步驟922中。

方法900使裝置902與RI 904能實現相互的平臺完整性驗證。在這種驗證下，裝置然後可以開始ROAP註冊協定。在第9圖中所顯示對註冊協定的步驟(步驟930-940)與如上該的方法200的步驟210-220是相同的。注意到可以在定期的間隔觸發或者重複這些程序。

改變對ROAP註冊協定的完整性驗證

在另一個具體實施例中，第10圖示出了一種方法1000，其中裝置1002與RI 1004交換有關完整性的資訊，此外利用OCSP應答器/PCA 1006的服務。在方法1000中，修改了ROAP註冊協定的現有裝置問候與RI問候訊息，以將TCG證書與請求二者傳送到對方，而用於平臺完整性驗證。

裝置1002發送修改後裝置問候訊息到RI 1004(步驟1010)，訊息包含裝置TCG證書與對RI1004的可選請求以報告其平臺完整性。RI 1004將裝置證書轉發到PCA 1006，以用於驗證(步驟1012)。PCA 1006然後將裝置TCG證書返回到RI 1004(步驟1014)。RI 1004用修改後的RI問候訊息回應裝置1002(步驟1016)，該訊息選擇性地包含RI的TCG證書。

其次，裝置1002選擇性地發送請求到PCA 1006，以檢查RI的TCG證書(步驟1018)。PCA 1006檢查RI的證書，並把結果報告回到裝置1002(步驟1020)。裝置1002檢查其自己的完整性狀態(步驟1022)，並對RI 1004報告完整性狀態(步驟1024)。

如果裝置1002已經請求RI 1004報告其完整性狀態，RI 1004執行平臺完整性檢查(步驟1026)，並把完整性狀態(例如其信任的狀態旗標)報告回到裝置1002(步驟1028)。該步驟1030-1036與如第2圖所示的ROAP註冊協定的步驟214-220是相同的。

檢查DRM軟體的完整性

第11圖是用於檢查在任何DRM實體對中的DRM SW(例如在裝置處的駐留的DRM用戶代理SW、在RI或者CI處駐留的DRM SW)的完整性的方法1100的流程圖。請求實體(RE)發送請求到目標實體(TE)，以執行DRM SW完整性檢查(步驟1102)。TE檢查自己的DRM SW完整性(步驟1104)，發送DRM SW完整性旗標到RE(步驟1106)，並且該方法終止(步驟1108)。注意到當TE是裝置時，如果裝置驅動器和媒體播放器SW這兩個部件分別存在於該裝置上，那麼可以分別地從DRM SW的完整性來檢查這兩個部件的完整性。

方法1100僅僅涉及RE從TE獲得DRM SW完整性檢查。為了執行相互的DRM SW完整性檢查，將需要執行兩次方法1100，一次從RE到TE，然後從TE到RE(用RE與TE交換角色)。在相互的DRM SW完整性檢查期間，該請求可以是交叉的(如第12圖所示)或者可以是如第11圖所示分離的。如果正在執行相互的DRM SW完整性檢查，則不改變該方法的操作。

OMA DRM 2.0規範假定，沒有建議如何有根據地實現這種假定，可以絕對信任DRM用戶代理SW(或者在本發明中使用的術語，裝置DRM SW)以及RI(或者RI的DRM SW)。因此，在OMA DRM 2.0規範中的認證協定僅僅規定了在實體之間實際的認證程序，也就是已經認為是可信的。由於明顯的理由，這種暗示的SW信任假定實際上不能被自動地假定，缺少實際的步驟以實現並驗證它們。在本節中所描述的方法涉及這種具體的步驟。

第12圖是用於應用連同ROAP RO獲取協定的DRM SW檢查的方法1200的流程圖。該方法1200利用裝置1202、RI 204以及OCSP應答器/PCA 1206。首先，PCA 1206與裝置1202和RI 1204通信，以執行平臺完整性檢查與ROAP註冊協定(步驟1210)。裝置1202和RI 1204執行相互的平臺完整性檢查、單向的DRM SW完整性檢查或相互的DRM SW完整性檢查(步驟1212)。

RI 1204發送請求到裝置1202，以檢查並報告裝置的DRM用戶代理(UA)SW完整性(步驟1214)。裝置1202檢查其最後的DRM UA SW完整性(步驟1216)。裝置1202選擇性地發送請求到RI 1204，以檢查並報告RI的DRM SW完整性(步驟1218)。如果被請求，RI 1204檢查其最後的DRM SW完整性(步驟1220)。裝置1202發送一裝置DRM SW完整性狀態旗標到RI 1204(步驟1222)。如果預先地請求，RI 1204發送RI DRM SW完整性狀態旗標到裝置1202(步驟1224)。注意到對可選RI完整性檢查的步驟可以任何次序來執行，並且不需要與如第12圖所示的裝置完整性檢查有交叉。

注意到方法1200可以改歸為用於在裝置與CI之間的相互的DRM SW完整性驗證，代替所示的裝置/RI互動。在步驟1210-1224完成時，例如，裝置1202可以在步驟1226與1228中開始2傳RO獲取協定，如上結合第3圖所描述的步驟310與312相同。還注意到，儘管該方法1200是結合RO獲取協定示出的，但是其可用於結合任何其他ROAP協定，但是為了最小化與方法1200有關的開銷，其可以僅僅用適當選擇的ROAP協定子集在任何給定時間來執行。對於實際的OMA DRM系統實現，如上用於建議的平臺及/或DRM SW完整性驗證程序的一些條件或者觸發機制可以包括：

1.裝置DRM SW完整性驗證程序可以由以下的一或多個來觸發。

1A.在裝置希望啟動新的2傳ROAP註冊協定、2傳加入域協定、或者2傳離開域協定之前。

1B.週期性地，每次規定的持續時間，例如TDEV-DRM-LAST-ROAP，為裝置上一次用相同的RI完成了2傳ROAP註冊協定、2傳加入域協定、或者2傳離開域協定經過的時間。

1C.週期性地，每次規定的持續時間，例如TDEV-DRM-LAST-REPORT，為裝置上一次向相同的RI驗證並報告了其DRM SW完整性狀態經過的時間。

1D.無論何時裝置更新其DRM SW時。

1E.無論何時更新或者改變平臺SW時。

2.可以由以下的一或多個執行RIDRM完整性檢查程序。

2A.在任何時候RI從裝置接收指示，該指示為裝置希望RI向裝置驗證其DRM SW完整性狀態，或者作為獨立的訊息或者作為修改後ROAP協定訊息的一部分。

2B.週期性地，每次規定的持續時間，例如TRI-DRM-LAST-REPORT，為RI上一次向裝置驗證並報告了其DRM SW完整性狀態經過的時間。

2C.無論何時RI已經更新其DRM SW時。

2D.每次在裝置發送RO請求之前時，在用戶在頻繁的基礎上獲得內容的程序中，諸如流動內容。

由於用於在裝置與CI之間的平臺完整性驗證，對於DRM SW完整性驗證處理週期性及/或事件驅動的出現，可以考慮類似於以上的機制。

可以相互獨立地執行用於DRM平臺驗證與DRM SW驗證的建議的方法，但是還期待這些驗證程序可以組合為一組程序的一部分。在這種實施方式中，對於DRM SW驗證步驟必須考慮DRM平臺驗證步驟。例如，對於在裝置與RI之間的完整性驗證，裝置與RI首先透過執行如上該的平臺驗證程序在相互的整個平臺上建立信任。該觸發機制包括通用平臺驗證觸發條件。然後，在DRM SW驗證觸發的條件一出現，接著進行DRM SW驗證程序。注意到當滿足它們各自的觸發條件時，將執行驗證程序的兩個類型。然而，DRM SW驗證步驟將控制對DRM平臺驗證步驟的成功完成，即，如果在裝置與RI之間的DRM平臺驗證失敗，那麼在DRM SW驗證中的進一步處理和實際的DRM ROAP處理及關於使用的處理將失敗。

密封的簽名與綁定

為保護ROAP協定完整性的OMA DRM 2.0規範的現有機制被限制以包含一些、但不是全部的ROAP訊息的數位簽名(或者訊息完整性檢查)。給定了ROAP協定是在安全的DRM進程實現中的中心環節，重要的是去保護並不斷地驗證在ROAP協定中使用並交換的資訊的完整性。

因此，在本發明另外的實施方式中，揭露了用於增強ROAP協定完整性的方法，藉此以DRM裝置與RI之間的可靠認證和完整性驗證為中心的資訊可以：(1)使用TCG技術被安全儲存，以及(2)在被發送至另一方之前、或者在儲存資訊的一側在用於處理之前被預先驗證。

這種方法涉及兩個基本程序，其使用密封簽名(即，對稱地加密目標資訊，然後不對稱地簽上對稱密鑰加上一組PCR值，PCR值指示對平臺或者特定的SW元件的當前完整性狀態)和綁定(用密鑰不對稱地加密目標資訊，其專用解密密鑰保持在諸如TPM的受保護模組中)的TCG技術。密封簽名對於透過由受保護的PCR值所指示的非對稱加密、數位簽名和綁定到裝置DRM用戶代理SW的信任狀態而提供的資訊安全性的給予最高等級。綁定對使用非對稱加密的保護(其中解密密鑰是在TPM內部保護的)給予最高等級。

以下系統的原理使用密封的簽名與綁定來保護在ROAP訊息中所使用資訊的機密性和完整性，由此間接地提高ROAP協定本身的完整性的強度。在下面論述中，裝置和RI二者(或者RI處理這種特定裝置的部分)假定為配備有TPM，並支援全面的TPM功能。

裝置與RI每一個可以留出與使用一組的兩個儲存密鑰，以將與ROAP處理有關的特定資訊密碼地綁定與安全地儲存到信任的平臺，在該平臺上具有裝置或者RI。對於該裝置，這些密鑰是K_DEV_BIND_A與K_DEV_BIND_B。對於該RI，這些密鑰是K_RI_BIND_A與K_RI_BIND_B。這些是TPM保持的不對稱密鑰(即，加密是用公鑰執行，解密是用在TPM內部的私鑰執行)。

該裝置與該RI各使用單一PCR或者一組PCR，以用於DRM處理。該裝置與該RI還留出與使用認證身份密鑰(AIK)，以將有關ROAP處理的特定資訊密封地簽名到該信任的平臺以及其特定的PCR值。注意到該TCG AIK密鑰僅僅用於簽名PCR值。對於該裝置，其AIK是K_DEV_AIK，以及對於該RI，其AIK是K_RI_AIK。此外，該密封的簽名需要用於目標資料的加密運算的不對稱儲存密鑰。由此，每個裝置與該RI各留出與使用對於這個目的的儲存密鑰。對於該裝置的儲存密鑰是K_DEV_STO_SEAL，對於該RI的儲存密鑰是K_RI_STO_SEAL。

該方法然後使用密封的簽名與綁定以及與完整一樣的保護的保密性的增加的測量，去提高儲存包含在該ROAP處理中的不同資訊元素的強度。例如，第13圖是方法1300的流程圖，其中TPM密封的簽名與綁定操作是用來保護在多個訊息中的資訊的保密性與完整性，其包括4傳ROAP註冊協定。在方法1300中，裝置1302與RI 1304各密封地簽名一選擇的有關ROAP的資訊組，使用兩組儲存密鑰綁定該資訊，每組儲存密鑰在4傳註冊協定的過程中或者發送(到另一方)或者接收(從另一方)。

該裝置1302首先用加密密鑰K_DEV_STO_SEAL與裝置特定的AIKK_DEV_AIK密封地簽名裝置ID資訊元素(在OMA DRM範例中是OMA DRM公鑰的SHA-1散列)(步驟1310)。這個資訊被綁定(使用非對稱加密)到其他資訊，以用於具有儲存密鑰K_DEV_BIND_A的裝置問候訊息(步驟1310)。裝置問候訊息然後從裝置1302被發送到RI 1304(步驟1312)。

透過密封地簽名諸如裝置ID的資訊並綁定包括裝置問候訊息的其他資訊，裝置1302可以建立策略，即只有當裝置問候訊息將被發送時以及如果裝置1302從它們的保護儲存體恢復(即開封簽名與解開)先前密封地簽名與綁定的資訊，比較它們與該DRM SW可以使用的這種資訊元素的當前值，並驗證當前值的真實性與完整性。注意到僅僅作為例子給出了在這個方案中密封地簽名的比較綁定的資訊元素的選擇。其他資訊元素可以被密封地簽名和綁定在不同的組合中，而不影響本發明的操作。其他組合可以從諸如系統時間、在訊息中的任何資訊元素、演算法與場合的項目導出。保護場合的一個理由是確定該場合是否是真隨機的，如一些亂數發生器特別是可能被有害地損害、可以重複相同式樣並產生相同號碼作為在未接受的短時間內的輸出。

一接收到裝置問候訊息，RI 1304就用其綁定密鑰、K_RI_BIND_A綁定包含於裝置問候訊息中的資訊(步驟1314)。這個步驟允許對密鑰資訊的安全的、完整性保護的儲存，該密鑰資訊是該RI 1304從裝置1302接收的。或者，該RI 1304還可以從裝置問候訊息擷取裝置ID(或者其他資訊元素)，以及使用該AIK K_RI_AIK與加密密鑰K_RI_STO_SEAL分別密封地簽名資訊元素。

RI 1304用加密密鑰K_RI_STO_SEAL與AIK K_RI_AIK密封地簽名該RI ID與RI URL資訊元素(步驟1316)。RI 1304還用儲存密鑰K_RI_BIND_A綁定包含於其RI問候訊息中的其他資訊(步驟1316)。RI 1304然後發送RI問候訊息到裝置1302(步驟1318)。

只有當以及如果RI 1304首先從保護的儲存體恢復(即，開封地簽名與解開)先前密封地簽名與綁定的資訊時，RI 1304發送RI問候訊息到該裝置1302，把恢復後的簽名和資訊與RI DRM SW可能使用的這種資訊元素的當前值比較，並驗證當前值的真實性與完整性。

一接收到RI問候訊息，該裝置1302就用第二綁定密鑰即K_DEV_BIND_B綁定包含在RI問候訊息中的資訊(步驟1320)。這個步驟允許對密鑰資訊的安全的、完整性保護的儲存，該密鑰資訊是該裝置從該RI 1304接收的。或者，裝置1302還可以從接收的RI問候訊息(諸如RI ID及/或RI URL)擷取所選擇的資訊元素，並當使用K_DEV_BIND_B簡單地綁定在RI問候訊息中所接收的其餘資訊時，使用AIK K_DEV_AIK與加密密鑰K_DEV_STO_SEAL密封地簽名它們。

裝置1302用K_DEV_AIK與K_DEV_STO_SEAL密封地簽名證書鏈、DCF散列與請求時間(步驟1322)。裝置1302然後用K_DEV_BIND_A綁定要用於註冊請求訊息的其他資訊(步驟1322)。裝置1302然後發送該註冊請求訊息到RI 1304(步驟1324)。如果裝置恢復(即開封簽名與解開)先前密封地簽名與綁定的資訊，裝置1302僅僅發送註冊請求訊息，比較所恢復的值與在DRM SW記憶體中使用的當前臨時值，並驗證當前值的真實性與完整性。一接收到註冊請求訊息，RI 1304用綁定密鑰K_RI_BIND_B綁定來自註冊請求訊息的資訊(步驟1326)。

RI 1304用K_RI_AIK與K_RI_STO_SEAL密封地簽名該密鑰、證書鏈與RO(步驟1328)。RI 1304然後用綁定密鑰K_RI_BIND_A將此綁定到欲包括在註冊應答訊息中的其他資訊(步驟1328)。RI 1304然後發送註冊應答訊息到裝置1302(步驟1330)。如果RI恢復(即開封簽名並解開綁定)先前密封地簽名與綁定的資訊，RI 1304僅僅發送註冊應答訊息，比較所恢復的值與在DRM SW記憶體中使用的當前臨時值，以及驗證當前值的真實性與完整性。一接收到註冊應答訊息，裝置1302用綁定密鑰K_DEV_BIND_B綁定來自註冊應答訊息的RI產生的資訊(步驟1332)。

注意到密封的簽名與綁定可以與任何其他ROAP協定一起使用。如上該的方法1300是示範性的，其原理可以同樣應用於任何其他ROAP協定。

如果密封的或者密封地簽名資料的實體已經更新了其平臺OS或者DRM SW，在OMA DRM ROAP訊息交換期間所獲得的資料將需要被解密封和重新密封到新的配置PCR值。當這種事件發生時，已經密封或者密封地簽名到特定狀態(或者，相當於到PCR值當前狀態特定組)的DRM ROAP相關資料將必須被首先解密封並然後重新密封到更新的平臺OS的更當前狀態。在現有技術中處理這個程序要求並且假定這種程序的現有技術將產生，以確保對任何DRM ROAP相關資料的恰當的解密封與重新密封，也就是使用在這裏建議的密封或者密封地簽名來儲存。

一個附加的改進是增加欄位到現有ROAP訊息格式中，以指示發送裝置的TCG能力。該TCG能力欄位可以透過形成早期的確定來幫助增加與傳統裝置的互用性，該確定是該接收實體是否支援TCG有關的資訊與程序。

裝置問候訊息的修改及其推導

第一修改是增加新的裝置TPM能力指示(DTCI)，其是裝置的TPM能力的指示符，或者在裝置問候訊息的現有擴展參數的新元素中，或者可替代地且較佳地，增加該DTCI作為在裝置問候訊息的標頭中的新的第一個參數。該DTCI可以是一個位元(指示裝置TPM的缺少或者出現)或者一些位元(指示有關裝置的TPM能力的更多資訊)。如果該DTCI是作為新的參數而***，較佳地應該是作為第一個參數而***在裝置ID參數之前，以便RI可以提前知道裝置具有一定的TPM能力的其他參數，以及利用該DTCI處理來自後面參數(例如裝置ID)的資訊。該DTCI資訊的優點是，其允許RI估計在與剩餘ROAP協定中的裝置的進一步互動中的裝置的可信度。

第二修改是使用裝置特定的TCG EK證書或者TCG AIK證書來散列並導出該DRM裝置ID。這個修改的優點是EK證書及/或AIK證書受到該裝置內部的TPM高度的保護，由此，從這些證書的任何一個導出該DRM裝置ID增強了該DRM裝置ID資訊的完整性。

第三修改是增加其中有裝置問候訊息的新簽名參數，直到除該簽名之外，其用該裝置的AIK私鑰簽名，由RI所驗證。這個修改的優點是保護了在裝置與該RI之間第一互動的該裝置TPM能力的完整性。裝置的AIK私鑰的利用增強了簽名操作的完整性，該私鑰是很好地由該TPM安全地保護的。

表12與表13顯示出對於修改後的裝置問候訊息的兩個可能格式。表12顯示出用DTCI位元作為第一參數的訊息格式。表13顯示出其中DTCI是現有擴展參數的新元素的裝置問候訊息的格式。

RI問候訊息的修改及其推導

第一修改是增加新的RI TPM能力指示(RTCI)，其是RI的TPM能力的指示符，或者作為RI問候訊息的現有擴展參數的新元素，或者可替代地並較佳地添加該RTCI作為在RI問候訊息的標頭中的新的第一參數。這個修改的優點是，其允許該裝置使用該RTCI資訊來估計RI的可信度，並且在其與剩餘ROAP協定程序中的該RI的進一步互動中利用這種資訊。

第二修改是使用RI TPM來提供用於會話ID的偽亂數。這個修改的優點是，TPM提供了高度安全的基於硬體的偽亂數產生器。使用該TPM來產生用於作為會話ID的偽亂數增強了協定的安全性。

第三修改是使用屬於RI的TPM的RI TCG EK證書或者TCG AIK證書來導出RI ID。這個修改的優點是EK證書及/或AIK證書是由該裝置內部的TPM所高度保護，並且從這些證書的任何一個導出DRM裝置ID增強了DRM裝置ID資訊的完整性。

第四修改是使用RI TPM來提供RI場合。這個修改的優點是，TPM提供了高度安全的基於硬體的偽亂數產生器。使用TPM來產生RI場合增強了在RI問候訊息中所使用的該場合的完整性。

第五修改是在裝置可信RI錨點中包含裝置TCG證書。裝置的TCG證書包含EK證書、AIK證書、平臺證書以及RI已經從可信TCG CA預先獲得的相容性證書。這個修改的優點是，增強了裝置可以具有RI問候訊息的信任。

第六修改是添加RI問候訊息的簽名，直到且排除用RI的AIK私鑰所簽名的該簽名，其中RI的AIK公鑰已經預先地分配給該裝置作為RI問候訊息的一部分。這個修改的優點是保護了在裝置與RI之間第一次互動的RTCI的完整性。RI的AIK私鑰的利用，增強了簽名操作的完整性，該私鑰是由該RI的TPM高度安全地保護。

表14與表15顯示出用於修改後RI問候訊息的兩個可能的格式。表14顯示出用RTCI位元作為第一參數的RI問候訊息的格式。表15顯示出其中RTCI是現有擴展參數的新元素的RI問候訊息的格式。

註冊請求訊息的修改及其推導

第一修改是使用裝置TPM來提供裝置場合。這個修改的優點是，TPM提供了適合於該場合使用的安全且可靠的偽亂數。

第二修改是在證書鏈中包含裝置TCG證書。包含裝置TCG證書可以是對現有OMA DRM 2.0裝置證書的替代或者是添加其他內容。包含TCG證書(諸如該EK證書、AIK證書、平臺證書或者相容性證書)的優點是增加裝置的可信度。

第三修改是在可信RI錨點元素中包含RI信任的TCG CA的列表。包含RI信任的TCG CA可以是對現有的OMA DRM 2.0 RI可信錨點元素列表的替代或是添加其他。包含由RI信任的TCG CA的列表的優點是增加裝置的可信度。

第四修改是在擴展參數的裝置詳細資料元素中包含關於該裝置TPM的資訊。包括這個資訊的優點是，增強了裝置對該RI的可信度。

第五修改是使用用於簽名該修改後裝置問候訊息的裝置AIK來簽名該簽名。這個修改的優點是由於很好地保護了該裝置AIK的特性，增加了該裝置和註冊請求訊息的可信度。

表16顯示出用於修改後的註冊請求訊息的格式。

註冊應答訊息的修改及其推導

第一修改是使用RI TPM來提供用於會話ID的偽亂數。這個修改的優點是，TPM提供了高度安全的基於硬體的偽亂數產生器。使用TPM來產生用於作為會話ID的偽亂數可增強協定的安全性。

第二修改是使用屬於RI的TPM的RI TCG EK證書或者TCG AIK證書來導出該RI ID。這個修改的優點是EK證書及/或AIK證書是由該裝置內部的TPM所高度保護，並且從這些證書的任何一個導出該DRM裝置ID增強了DRM裝置ID資訊的完整性。

第三修改是使用RI TPM來提供RI場合。這個修改的優點是，RI TPM提供了適合於該場合的安全且可靠的偽亂數。。

第四修改是在可信裝置錨點元素中包含裝置所信任的TCG CA的列表。包含該裝置信任的TCG CA可以是對現有的OMA DRM 2.0可信裝置錨點元素列表的替代或是添加。包含由該裝置信任的TCG CA的列表的優點是增加RI的可信度。

第五修改是使用用於簽名修改後RI問候訊息的RI AIK來簽名該簽名。這個修改的優點是由於很好地保護了RI AIK的特性，增加了RI和註冊應答訊息的可信度。

表17示出了用於修改後註冊應答訊息的格式。

RO請求訊息的修改及其推導

第一修改是使用TPM來創造作為裝置ID的選擇的TCG證書(EK證書、AIK證書、平臺證書或者相容性證書)的SHA-1散列。這個修改的優點是該證書由TPM所高度保護，並且由此，從這些證書其中之一導出裝置ID增強了該裝置ID資訊的完整性。

第二修改是使用裝置TPM來產生裝置場合。這個修改的好處是由該TPM產生的場合是安全的，這是由於TPM的受保護的偽亂數產生能力。

第三修改是在證書鏈中包含裝置TCG證書。包含裝置TCG證書可以是對現有OMA DRM 2.0裝置證書的代替或者附加。包含TCG證書的優點是增加裝置的可信度。

第四修改是用擴展參數中的裝置AIK來簽名可選DCF散列(Hash)。這個修改的優點是高度保護了裝置AIK，由此使得該DCF簽名更安全。

第五修改是使用用於標記最近成功地回應註冊請求訊息的裝置AIK來簽名該RO請求訊息。這個修改的優點是由於高度保護了該RI AIK的特性，增加了RI和RO請求訊息的可信度。

表18描述了修改後RO請求訊息的格式。

RO應答訊息的修改及其推導

一個修改是使用RI的TPM以在簽最近成功的註冊應答訊息中使用的相同RI TPM AIK來簽名RO應答訊息。這個修改的優點是由於高度地保護了該RI AIK的特性，增加了RI和RO應答訊息的可信度。

表19描述出了修改後RO請求訊息的格式。

雖然本發明的特徵和元件在較佳的實施方式中以特定的結合進行了描述，但每個特徵或元件可以(在沒有該較佳實施方式的其他特徵和元件的情況下)單獨使用，或在與或不與本發明的其他特徵和元件結合的各種情況下使用。

【實施例】

1.一種用於在請求實體(RE)和目標實體(TE)之間執行平臺完整性檢查的方法，包括以下步驟：從RE發送一請求到TE，以請求TE報告其可信計算組(TCG)證書；從TE發送TE的TCG證書到RE；從RE轉發TE的TCG證書到線上認證狀態協定(OCSP)應答器以用於驗證；將來自OCSP應答器的TE的TCG證書的驗證狀態報告給RE；從RE發送一請求到TE，以請求TE報告自己的平臺完整性狀態；檢查TE的平臺完整性狀態；以及從TE發送一平臺完整性狀態指示符到RE。

2.如實施例1所述的方法，其中RE是版權發行者(RI)，而TE是裝置。

3.如實施例2所述的方法，其中該方法透過裝置發送觸發器到RI而開始，並在該裝置利用RI啟動一版權物件獲取協定(ROAP)註冊協定之前被執行。

4.如實施例2或3所述的方法，其中該方法根據從該裝置最近利用RI註冊時起的耗費時間而被週期性地執行。

5.如實施例2-4中任一實施例所述的方法，其中該方法根據從該裝置最近對RI驗證其平臺完整性狀態時起所耗費的時間而被週期性地執行。

6.如實施例1所述的方法，其中RE是裝置，而TE是版權發行者(RI)。

7.如實施例6所述的方法，其中該方法根據從RI最近對該裝置驗證其平臺完整性狀態時起耗費的時間而被週期性地執行。

8.如實施例1所述的方法，其中RE是內容發行者(CI)，而TE是裝置。

9.如實施例8所述的方法，其中該方法根據從該裝置最近對CI驗證其平臺完整性狀態時起耗費的時間而被週期性地執行。

10.如實施例8或9所述的方法，其中該方法在該裝置從CI購買內容時被執行。

11.如實施例1所述的方法，其中RE是裝置，而TE是內容發行者(CI)。

12.如實施例11所述的方法，其中該方法根據從CI最近對該裝置驗證其平臺完整性狀態時起耗費的時間而被週期性地執行。

13.如實施例11或12所述的方法，其中該方法在該裝置從CI購買內容時被執行。

14.如實施例1所述的方法，其中該方法作為版權物件獲取協定(ROAP)處理的一部分而被執行。

15.如實施例14所述的方法，其中該方法在該ROAP處理之前被執行。

16.如實施例14或15所述的方法，其中修改該ROAP處理，以合併該方法作為ROAP處理的一部分。

17.一種用於在請求實體(RE)和目標實體(TE)之間執行數位版權管理(DRM)軟體完整性檢查的方法，包括以下步驟：從RE發送一請求到TE，請求TE執行DRM軟體完整性檢查；由該TE檢查DRM軟體完整性；以及從TE發送DRM軟體完整性狀態指示符到RE。

18.如實施例17所述的方法，其中RE是版權發行者(RI)，而TE是裝置。

19.如實施例18所述的方法，其中該裝置發送一觸發器到RI，以在該裝置啟動版權物件獲取協定(ROAP)處理之前開始該方法。

20.如實施例19所述的方法，其中ROAP處理是從由2傳註冊、2傳加入域以及2傳離開域組成的群組中選擇。

21.如實施例19或20所述的方法，其中該方法在該裝置已經利用RI完成版權物件獲取協定(ROAP)處理之後被週期性地執行。

22.如實施例19-21中任一實施例所述的方法，其中ROAP處理是從由2傳註冊、2傳加入域以及2傳離開域組成的組中選擇。

23.如實施例18-22中任一實施例所述的方法，其中該方法在該裝置已經對RI驗證並報告其DRM軟體完整性狀態之後被週期性地執行。

24.如實施例18-23中任一實施例所述的方法，其中該方法在該裝置更新其DRM軟體之後被執行。

25.如實施例18-24中任一實施例所述的方法，其中RI請求該裝置對該裝置上的媒體播放器執行DRM軟體完整性檢查。

26.如實施例17所述的方法，其中RE是裝置，而TE是版權發行者(RI)。

27.如實施例26所述的方法，其中該方法由該裝置在啟動時執行。

28.如實施例26或27所述的方法，其中該方法是獨立的處理。

29.如實施例26-28中任一實施例所述的方法，其中該方法是修改的版權物件獲取協定處理的一部分。

30.如實施例26-29中任一實施例所述的方法，其中該方法在RI已經對該裝置驗證並報告其DRM軟體完整性狀態之後被週期性地執行。

31.如實施例26-30中任一實施例所述的方法，其中該方法在RI更新其DRM軟體之後被執行。

32.如實施例26-31中任一實施例所述的方法，其中該方法在該裝置發送版權物件請求到RI之前被執行。

33.如實施例26-32中任一實施例所述的方法，其中該方法在用於流動內容的請求從該裝置到RI的期間被週期性地執行。

34.如實施例17所述的方法，其中RE是內容發行者(CI)，而TE是裝置。

35.如實施例34所述的方法，其中該裝置發送一觸發器到CI，以在該裝置啟動版權物件獲取協定(ROAP)處理之前開始該方法。

36.如實施例34或35所述的方法，其中該方法在該裝置已經用CI完成版權物件獲取協定(ROAP)處理之後被週期性地執行。

37.如實施例34-36中任一實施例所述的方法，其中該方法在該裝置已經對CI驗證並報告其DRM軟體完整性狀態之後被週期性地執行。

38.如實施例34-37中任一實施例所述的方法，其中該方法在該裝置更新其DRM軟體之後被執行。

39.如實施例34-38中任一實施例所述的方法，其中CI請求該裝置對該裝置上的媒體播放器執行DRM軟體完整性檢查。

40.如實施例17所述的方法，其中RE是裝置，而TE是內容發行者(CI)。

41.如實施例40所述的方法，其中該方法由該裝置在啟動時執行。

42.如實施例40或41所述的方法，其中該方法是獨立的處理。

43.如實施例40-42中任一實施例所述的方法，其中該方法是修改的版權物件獲取協定處理的一部分。

44.如實施例40-43中任一實施例所述的方法，其中該方法在CI已經對該裝置驗證並報告其DRM軟體完整性狀態之後被週期性地執行。

45.如實施例40-44中任一實施例所述的方法，其中該方法在CI更新其DRM軟體之後被執行。

46.如實施例40-45中任一實施例所述的方法，其中該方法在該裝置發送版權物件請求到CI之前被執行。

47.如實施例40-46中任一實施例所述的方法，其中該方法在用於流動內容的請求從該裝置到CI的期間被週期性地執行。

48.一種用於增強在兩個實體之間所交換的版權物件獲取協定(ROAP)訊息的完整性的方法，包括以下步驟：使用可信計算技術在每個實體安全地儲存將在該ROAP訊息中使用的資訊；以及在該訊息被用於連接ROAP訊息之前，預先驗證將在該ROAP訊息中使用的該資訊。

49.如實施例48所述的方法，其中該儲存步驟包括密封地簽名該資訊並綁定該資訊。

50.如實施例49所述的方法，其中該密封地簽名步驟包括用對稱加密密鑰對稱地加密該資訊，以及不對稱地簽名該對稱加密密鑰和指示物件的當前完整性狀態的一組值。

51.如實施例50所述的方法，其中該簽名步驟包括使用該實體所操作平臺的完整性狀態。

52.如實施例50或51所述的方法，其中該簽名步驟包括使用該實體的軟體元件的完整性狀態。

53.如實施例49-52中任一實施例所述的方法，其中該綁定步驟包括用密鑰不對稱地加密該資訊，該密鑰的解密私鑰被儲存在該實體的受保護模組中。

54.如實施例53所述的方法，其中受保護模組是可信處理模組(TPM)。

55.如實施例54所述的方法，其中TPM被用於推導出在ROAP訊息中使用的參數。

56.如實施例48-55中任一實施例所述的方法，其中該資訊是從由裝置識別、版權發行者識別、證書、證書鏈、數位版權管理相關的時間值、版權物件、演算法和場合組成的組中選擇。

57.如實施例48-56中任一實施例所述的方法，其中該方法被應用於所有ROAP訊息。

58.如實施例48-56中任一實施例所述的方法，其中該方法與ROAP訊息分開地應用。

59.如實施例48-56中任一實施例所述的方法，其中該方法被集成到ROAP訊息的產生和傳送中。

60.如實施例48-56中任一實施例所述的方法，更包括步驟：對現有ROAP訊息增加欄位，以指示發送實體的可信計算能力。

61.一種被配置以執行如實施例1-60中任一實施例所述的方法的系統。

62.一種被配置以執行如實施例1-60中任一實施例所述的方法的積體電路。

100．．．架構

200．．．註冊協定

204、704、904、1004、1204．．．版權發行者

300．．．RO獲取協定

400．．．RO獲取協定

500．．．RO加入域協定

600．．．RO離開域協定

700．．．一般架構

706．．．內容發行者

800．．．平臺完整性驗證的方法

900．．．完整性的資訊的方法

1000．．．一種方法

1100．．．完整性的方法

1200．．．檢查的方法

1300．．．方法

700．．．一般架構

AIK．．．認證身份密鑰

BLOB．．．二進位大物件

CI．．．內容發行者

DRM．．．數位版權管理

K_DEV_BIND_A、K_DEV_BIND_B K_RI_BIND_A、K_RI_BIND_B．．．密鑰

K_DEV_STO_SEAL．．．儲存密鑰

OCSP．．．線上認證狀態協定

OS．．．作業系統

PCA．．．專用認證權限

RO．．．版權物件

SW．．．軟體

TCG．．．可信計算組

TPM．．．指示裝置

UA．．．用戶代理

從以下關於較佳實施方式的描述中可以更詳細地瞭解本發明，這些較佳實施方式是作為實例而提供，並且是結合所附圖式而被理解的，其中：

第1圖是現有OMA DRM 2.0功能架構的方塊圖；

第2圖是現有OMA DRM 2.0 ROAP 4傳註冊協定的流程圖；

第3圖是現有OMA DRM 2.0 ROAP 2傳RO獲取協定的流程圖；

第4圖是現有OMA DRM 2.0 ROAP 1傳RO獲取協定的流程圖；

第5圖是現有OMA DRM 2.0 ROAP 2傳加入域協定的流程圖；

第6圖是現有OMA DRM 2.0 ROAP 1傳離開域協定的流程圖；

第7圖是在OMA DRM 2.0實體之間的多方平臺完整性檢查的方塊圖；

第8圖是用於在兩個實體之間執行平臺完整性驗證的方法的流程圖，其中兩個實體可以是裝置與RI或者裝置與CI；

第9圖是用於在使用在前信任檢查的裝置與RI之間執行相互的平臺完整性檢查的4傳ROAP註冊協定的流程圖；

第10圖是用於在使用修改的裝置問候與RI問候訊息的裝置與RI之間執行相互的平臺完整性檢查的4傳ROAP註冊協定的流程圖；

第11圖是用於在兩個實體之間執行DRM軟體完整性檢查的方法的流程圖，其中兩個實體可以是裝置與RI或者裝置與CI；

第12圖是用於在裝置與RI之間執行相互的DRM軟體完整性檢查的2傳ROAP RO獲取協定的流程圖；

第13圖是用於改進ROAP訊息的完整性和使用包括密封綁定與記憶體分區的TCG技術處理的方法的流程圖。

700．．．一般架構

AIK．．．認證身份密鑰

BLOB．．．二進位大物件

CI．．．內容發行者

DRM．．．數位版權管理

OS．．．作業系統

PCA．．．專用認證權限

SW．．．軟體

TPM．．．指示裝置

Claims

一種用於一無線通信的方法，該方法包括：從位於一目標實體(TE)的一請求實體(RE)接收一用以報告複數個信任的證書的請求；傳輸該複數個信任的證書到該RE；從位於該TE的該RE接收一用以報告該TE的一平臺完整性狀態的請求；於該TE檢查該TE的該平臺完整性狀態；以及從該TE傳輸一平臺完整性狀態指示符到該RE。
如申請專利範圍第1項所述的方法，其中該RE是一版權發行者(RI)以及該TE是一裝置。
如申請專利範圍第2項所述的方法，其中該方法透過該裝置傳輸一觸發到該RI而開始，並在該裝置利用該RI啟動一版權物件獲取協定(ROAP)註冊協定之前被執行。
如申請專利範圍第2項所述的方法，其中該方法根據從該裝置最近利用該RI註冊時起的一耗費時間而被週期性地執行。
如申請專利範圍第2項所述的方法，其中該方法根據從該裝置最近對該RI驗證其平臺完整性狀態時起的一耗費時間而被週期性地執行。
如申請專利範圍第1項所述的方法，其中該RE是一內容發行者(CI)，而該TE是一裝置。
如申請專利範圍第6項所述的方法，其中該方法根據從該裝置最近對該CI驗證其平臺完整性狀態時起的一耗費時間而被週期性地執行。
如申請專利範圍第1項所述的方法，其中該方法在該裝置從該CI購買內容時被執行。
一種無線發送/接收單元(WTRU)，包括：一接收器，被配置用於從位於該WTRU上的一目標實體(TE)上的一請求實體(RE)接收一用以報告複數個信任的證書的請求一傳輸器，被配置用於傳輸該複數個信任的證書到該RE；該接收器更被配置用於從位於該TE的該RE接收一用以報告該TE的一平臺完整性狀態的請求；一處理器，被配置用於該TE的該平臺完整性狀態；以及該處理器被配置用於傳輸一平臺完整性狀態指示符到該RE。
如申請專利範圍第9項所述的WTRU，其中該RE是一版權發行者(RI)。
如申請專利範圍第10項所述的WTRU，其中透過傳送一觸發到該RI，在該WTRU利用該RI啟動一版權物件獲取協定(ROAP)註冊協定之前，該複數個信任的證書以及該平臺完整性狀態指示符被該WTRU傳輸。
如申請專利範圍第10項所述的WTRU，其中根據從該WTRU最近利用該RI註冊時起的一耗費時間，該複數個信任的證書以及該平臺完整性狀態指示符被週期性地傳輸。
如申請專利範圍第10項所述的WTRU，其中根據從該裝置最近對該RI驗證其平臺完整性狀態時起的一耗費時間，該複數個信任的證書以及該平臺完整性狀態指示符被週期性地傳輸。
如申請專利範圍第9項所述的WTRU，其中該RE是一內容發行者(CI)。
如申請專利範圍第9項所述的WTRU，其中根據從該WTRU 最近對該CI驗證其平臺完整性狀態時起的一耗費時間，該複數個信任的證書以及該平臺完整性狀態指示符被週期性地傳輸。