專利名稱：：傳送對(duì)受保護(hù)內(nèi)容的策略更新的制作方法傳送對(duì)受保護(hù)內(nèi)容的策略更新些旦NT爾數(shù)字權(quán)限管理(DRM)指的是用于諸如通過控制或限制電子設(shè)備上對(duì)數(shù)字媒體內(nèi)容的使用來保護(hù)內(nèi)容的技術(shù)。DRM的一個(gè)特征是它可將媒體內(nèi)容綁定到給定機(jī)器或設(shè)備。由此，涉及特定一段內(nèi)容并定義了與該段內(nèi)容相關(guān)聯(lián)的權(quán)限和限制的許可證通常被綁定到給定的機(jī)器或設(shè)備。結(jié)果，用戶通常不能取得該段內(nèi)容并將其移至另一機(jī)器來回放該內(nèi)容。某些受DRM保護(hù)的內(nèi)容的另一特征是諸如ASF文件等某些內(nèi)容類型僅允許一組權(quán)限和限制，即"策略"應(yīng)用于整個(gè)文件。例如，當(dāng)呈現(xiàn)視頻文件時(shí)，或者需要在對(duì)整個(gè)文件的模擬視頻輸出上啟用宏視覺(Macrovision)，或者完全不需要宏視覺。對(duì)于這些特定類型的文件，不能在文件中間或流中間改變與內(nèi)容相關(guān)聯(lián)的策略。概述各實(shí)施例允許對(duì)給定一段受保護(hù)內(nèi)容傳送并更新諸如DRM策略更新等策略更新。在至少某些實(shí)施例中，可擴(kuò)展各種協(xié)議以允許該協(xié)議來表示并承載策略更新。在一個(gè)實(shí)施例中，利用超文本傳輸協(xié)議，即HTTP來承載策略更新。在另一實(shí)施例中，使用實(shí)時(shí)流傳送協(xié)議，即RTSP來承載策略更新。附圖簡(jiǎn)述圖1示出了在一個(gè)實(shí)施例中可用于本發(fā)明實(shí)施例的協(xié)議的示例性注冊(cè)過程。圖2示出了在一個(gè)實(shí)施例中可用于本發(fā)明實(shí)施例的協(xié)議的示例性鄰近性檢測(cè)過程。圖3是在一個(gè)實(shí)施例中可用于本發(fā)明實(shí)施例的協(xié)議的示例性會(huì)話建立過程。圖4示出了在一個(gè)實(shí)施例中可用于本發(fā)明實(shí)施例的協(xié)議的示例性數(shù)據(jù)傳輸過程。圖5示出了在一個(gè)實(shí)施例中可用于本發(fā)明實(shí)施例的流傳送協(xié)議的各方面。圖6示出了根據(jù)一個(gè)實(shí)施例的與根許可證和葉許可證相關(guān)聯(lián)的各方面。圖7是描述根據(jù)一個(gè)實(shí)施例的方法中的各步驟的流程圖。圖8示出了根據(jù)一個(gè)實(shí)施例的根和葉許可證的通信。圖9示出了根據(jù)一個(gè)實(shí)施例的根和葉許可證的通信。詳細(xì)描述概述各實(shí)施例允許對(duì)給定一段受保護(hù)內(nèi)容傳送并更新諸如DRM策略更新等策略更新。在至少某些實(shí)施例中，可擴(kuò)展各種協(xié)議以允許由協(xié)議來表示和承載策略更新。在一個(gè)實(shí)施例中，利用超文本傳輸協(xié)議，即HTTP來承載策略更新。在另一實(shí)施例中，使用實(shí)時(shí)流傳送協(xié)議，即RTSP來承載策略更新。在以下討論中，提供了題為"內(nèi)容安全和許可證傳輸協(xié)議"的小節(jié)，該節(jié)描述了其中可采用本發(fā)明技術(shù)的一個(gè)特定系統(tǒng)。在此之后，提供了題為"RTSP"的小節(jié)，以向不熟悉RTSP的讀者給出用于理解RTSP空間中的本發(fā)明技術(shù)的至少某些上下文。在本節(jié)之后，提供了題為"用于傳送更新的策略的鏈許可證"的小節(jié)，該節(jié)描述了鏈許可證的概念以及可如何在本發(fā)明的上下文中利用鏈許可證。在該節(jié)之后，提供了題為"使用HTTP來傳送更新的策略"的小節(jié)，該節(jié)描述了如何可在HTTP的上下文中使用鏈許可證來傳送策略更新。在該節(jié)之后，提供了題為"使用RTSP來承載根和葉許可證"的小節(jié)，該節(jié)描述了如何可在RTSP的上下文中使用鏈許可證來傳送策略更新。內(nèi)容安全和許可證傳輸協(xié)議以下提供了為在數(shù)字鏈路上流動(dòng)的內(nèi)容提供安全和傳輸許可證的示例性協(xié)議的討論。該協(xié)議僅構(gòu)成了可使用的各種發(fā)明技術(shù)的一個(gè)示例性協(xié)議?？梢岳斫夂兔靼?，可利用其它協(xié)議而不脫離所要求保護(hù)的主題的精神和范圍。在此描述中使用以下密碼表示法&{數(shù)據(jù)}用機(jī)密密鑰K加密的數(shù)據(jù)K[數(shù)據(jù)]用機(jī)密密鑰K簽署的數(shù)據(jù){數(shù)據(jù)}^用設(shè)備的公鑰加密的數(shù)據(jù)[數(shù)據(jù)]m用設(shè)備的私鑰簽署的數(shù)在該特定協(xié)議中，有五個(gè)主要過程茲〕欽、_^>新嫁"、鄰近絲^^資/、會(huì)話建J和教薪傳翰。在^SM程中，發(fā)送器(即，具有要發(fā)送到另一設(shè)備的內(nèi)容的設(shè)備)可唯一并安全地標(biāo)識(shí)一預(yù)期接收器(即，要向其發(fā)送內(nèi)容的設(shè)備)。在該特定協(xié)議中，發(fā)送器維護(hù)具有注冊(cè)的接收器的數(shù)據(jù)庫(kù)，并且確保不會(huì)同時(shí)使用多于一較小的預(yù)定數(shù)目的接收器。在注冊(cè)過程期間，發(fā)送器還采用了鄰^近絲^^i^:程來確保接收器在網(wǎng)絡(luò)中位于發(fā)送器"附近"，以防止受保護(hù)內(nèi)容的大范圍分發(fā)。^1^:潘^(過程用于確保接收器持續(xù)地在發(fā)送器的"附近"。除非接收器已在過去的一段預(yù)定時(shí)間內(nèi)注冊(cè)或重新確認(rèn)，否則不向其傳送內(nèi)容。會(huì)話建J過程在接收器向發(fā)送器請(qǐng)求內(nèi)容的任何時(shí)候使用。發(fā)送器強(qiáng)制設(shè)備必須在完成會(huì)話^^J^前注冊(cè)并最近被確認(rèn)。一旦建立了會(huì)話，所請(qǐng)求內(nèi)容的J^游/^^可用一安全的方式來進(jìn)行。接收器可重復(fù)使用該會(huì)話來檢索內(nèi)容的特定部分(尋找)，但是必須建立新的會(huì)話來檢索不同的內(nèi)容?，F(xiàn)在結(jié)合圖1以及下表來考慮)^，過程，下表描述了在注冊(cè)期間在發(fā)送器和接收器之間傳遞的各種消息。消總位描述注冊(cè)請(qǐng)求消息版本8位協(xié)議版本證書接收器的XML數(shù)字證書。設(shè)備標(biāo)識(shí)128位序列號(hào)。注冊(cè)響應(yīng)消息版本8位協(xié)議版本{種子}設(shè)備用于導(dǎo)出內(nèi)容加密密鑰和內(nèi)容完整性密鑰的128位種子。序列號(hào)128位序列號(hào)地址發(fā)送器傳入和傳出的鄰近分組套接字的地址。會(huì)話標(biāo)識(shí)128位隨機(jī)會(huì)話標(biāo)識(shí)。鄰近性檢測(cè)算法在帶外執(zhí)行鄰近性檢測(cè)算法。此處，接收器發(fā)送除其它信息外還包含接收器的數(shù)字證書的注冊(cè)請(qǐng)求消息。響應(yīng)于接收該注冊(cè)請(qǐng)求消息，發(fā)送器驗(yàn)證接收器的證書，生成種子和隨機(jī)會(huì)話標(biāo)識(shí)，在注冊(cè)響應(yīng)消息中按上述格式向接收器返回同樣內(nèi)容。接收器然后驗(yàn)證發(fā)送器的簽名，獲取會(huì)話標(biāo)識(shí)并執(zhí)行附圖中所示的其它動(dòng)作。接收器和發(fā)送器然后可經(jīng)歷以下描述的鄰近性檢測(cè)過程。對(duì)于^^^P裙W，執(zhí)行與上述相同的過程，區(qū)別在于，在_^#:潘^(期間，接收器已在數(shù)據(jù)庫(kù)中注冊(cè)。對(duì)于鄰近絲檢漱，結(jié)合圖2考慮以下。在鄰^近絲^^i5i程期間，接收器向發(fā)送器發(fā)送包含鄰近性檢測(cè)初始化消息中指示的會(huì)話標(biāo)識(shí)的消息。發(fā)送器然后向接收器發(fā)送包含現(xiàn)時(shí)值(Nonce)(128位隨機(jī)值)的消息，并測(cè)量接收器以使用內(nèi)容加密密鑰加密的現(xiàn)時(shí)值來答復(fù)所花的時(shí)間。最后，發(fā)送器向接收器發(fā)送指示鄰近性檢測(cè)成功與否的消息。接收器可重復(fù)該過程，直到它確認(rèn)鄰近性檢測(cè)成功。當(dāng)該特定協(xié)議在基于IP的網(wǎng)絡(luò)上使用時(shí)，通過UDP來交換鄰近性檢測(cè)消息。接收器經(jīng)由注冊(cè)響應(yīng)消息知道發(fā)送器的地址。接收器的地址不需要單獨(dú)傳送，因?yàn)榭赏ㄟ^檢査承載鄰近性檢測(cè)初始化消息的UDP分組的傳入IP報(bào)頭來確定。下表描述了在鄰近性檢測(cè)期間交換的消息:<table>tableseeoriginaldocumentpage8</column></row><table><table>tableseeoriginaldocumentpage9</column></row><table>在此示例中，從接收器向發(fā)送器發(fā)送許可證請(qǐng)求消息，它包含上述信息。作為響應(yīng)，發(fā)送器可發(fā)送包含上述信息的許可證響應(yīng)消息。在該特定示例中，用XMR格式表示許可證，許可證包括內(nèi)容加密密鑰、內(nèi)容完整性密鑰、發(fā)送器CRL的版本、128位權(quán)限標(biāo)識(shí)和128位序列號(hào)。許可證還包含使用OMAC用內(nèi)容完整性密鑰計(jì)算的OMAC。對(duì)于^"薪傳薪過程，結(jié)合圖4考慮以下。一旦會(huì)話;^J^成，即以控制協(xié)議專用的方式執(zhí)行數(shù)據(jù)傳輸。^"薪傳激請(qǐng)求和響應(yīng)兩者必須為控制協(xié)議和內(nèi)容類型特別定義。這概念性地表示在圖4中。現(xiàn)在提供了可用于本發(fā)明實(shí)施例的示例性協(xié)議的簡(jiǎn)要概觀，現(xiàn)在考慮RTSP的一些背景信息。RTSP如本領(lǐng)域的技術(shù)人員所理解的，實(shí)時(shí)流傳送協(xié)議，即RTSP是用于對(duì)具有實(shí)時(shí)特性的數(shù)據(jù)傳送(即流傳送)進(jìn)行控制的應(yīng)用層協(xié)議。RTSP提供允許對(duì)諸如音頻和視頻等實(shí)時(shí)數(shù)據(jù)進(jìn)行受控的、按需的傳送的可擴(kuò)展框架。數(shù)據(jù)源可包括實(shí)況數(shù)據(jù)饋送和已存儲(chǔ)的剪輯兩者。該協(xié)議旨在控制多個(gè)數(shù)據(jù)傳送會(huì)話，提供用于選擇諸如UDP、組播UDP和TCP等傳送信道的手段，并提供用于基于RTP選擇傳送機(jī)制的手段。RTSP建立并控制單個(gè)或多個(gè)時(shí)間同步的連續(xù)媒體流，諸如音頻和視頻。它自己一般不傳送連續(xù)流，盡管連續(xù)媒體流與控制流的交織是可能的。換言之，RTSP用作多媒體服務(wù)器的"網(wǎng)絡(luò)遙控器"。要被控制的流的集合由演示描述來定義。在RTSP中，不存在RTSP連接的概念；相反，服務(wù)器維護(hù)由標(biāo)識(shí)符標(biāo)記的會(huì)話。RTSP會(huì)話決不綁定至傳輸層連接，諸如TCP連接。在RTSP會(huì)話期間，RTSP客戶機(jī)可打開或關(guān)閉至服務(wù)器的眾多可靠的傳輸連接以發(fā)出RTSP請(qǐng)求?；蛘撸绫绢I(lǐng)域的技術(shù)人員可以理解的，可使用諸如UDP等無連接傳輸協(xié)議。由RTSP控制的流可使用RTP，但RTSP的操作不依賴于用于承載連續(xù)媒體的傳輸機(jī)制?，F(xiàn)在結(jié)合圖5考慮客戶機(jī)/接收器500與服務(wù)器/發(fā)送器502之間的典型的RTSP請(qǐng)求/響應(yīng)交換。初步地，RTSP請(qǐng)求/響應(yīng)具有為簡(jiǎn)潔起見未作描述的報(bào)頭。在RTSP中，客戶機(jī)/接收器500—般發(fā)出被稱為描述的請(qǐng)求，它針對(duì)從服務(wù)器502檢索由請(qǐng)求URL標(biāo)識(shí)的演示或媒體對(duì)象的描述。服務(wù)器502用以會(huì)話描述協(xié)議(SDP)表示的被請(qǐng)求資源的描述作出響應(yīng)。描述響應(yīng)(SDP)包含其所描述的資源的所有媒體初始化"(曰息。接著，客戶機(jī)500發(fā)送對(duì)指定要用于流傳送媒體的傳輸機(jī)制的URI的設(shè)置請(qǐng)求。在圖5的示例中，為音頻和視頻兩者發(fā)送設(shè)置請(qǐng)求。客戶機(jī)500還在設(shè)置請(qǐng)求中指示它將利用的傳輸參數(shù)。設(shè)置請(qǐng)求中的傳輸報(bào)頭指定客戶機(jī)可接受用于數(shù)據(jù)傳輸?shù)膫鬏攨?shù)。來自服務(wù)器502的響應(yīng)包含由服務(wù)器所選的傳輸參數(shù)。服務(wù)器還響應(yīng)于該設(shè)置請(qǐng)求生成會(huì)話標(biāo)識(shí)符。此時(shí)，客戶機(jī)可發(fā)出播放請(qǐng)求，它告知服務(wù)器以經(jīng)由設(shè)置中指定的機(jī)制來開始發(fā)送數(shù)據(jù)。響應(yīng)于接收播放請(qǐng)求，服務(wù)器可開始流傳送內(nèi)容，在此示例中，該內(nèi)容為音頻/視頻內(nèi)容。如本領(lǐng)域的技術(shù)人員可以理解的，在此示例中，流傳送的內(nèi)容使用RTP分組封裝并通過UDP發(fā)送。RTSP協(xié)議具有感興趣的其它方法，包括暫停、拆卸、獲取參數(shù)、設(shè)置參數(shù)、重定向和記錄。對(duì)關(guān)于RTSP的其它背景，讀者應(yīng)査詢1998年4月的RTSP草案中Schulzrinne,H.，Rao，A.禾卩R.Lanphier的"RealTimeStreamingProtocol(實(shí)時(shí)流傳送協(xié)議)(RTSP)"，RFC2326，可在http:〃www.ietf.org/rfc/rfc2326.txt獲得。用于傳送更新的策略的鏈許可證在所示并描述的實(shí)施例中，在策略更新過程中利用了許可證鏈的概念。在該特定實(shí)施例中，采用了裙/f^證和^/f^證的概念。此處，利用根許可證來設(shè)置內(nèi)容密鑰并將其安全地傳送到客戶機(jī)/接收器，使得客戶機(jī)/接收器可使用該內(nèi)容密鑰來解密隨后傳送的策略更新。一旦將初始內(nèi)容密鑰安全地傳送到客戶機(jī)/接收器，就可由服務(wù)器/發(fā)送器使用該最初傳送的內(nèi)容密鑰加密后續(xù)內(nèi)容密鑰并將其發(fā)送給客戶機(jī)/接收器。使用最初傳送的內(nèi)容密鑰，客戶機(jī)可解密相關(guān)聯(lián)的策略更新。為提供關(guān)于可如何實(shí)現(xiàn)該特定方案的一個(gè)示例，結(jié)合圖6考慮以下。在該特定示例中，圖6的系統(tǒng)被配置成對(duì)公鑰密碼操作使用1024位RSA密鑰，而對(duì)對(duì)稱密碼操作使用128位AES密鑰。當(dāng)然，這僅作為一個(gè)示例來提供，并不旨在限制所要求保護(hù)的主題的應(yīng)用。在此示例中，客戶機(jī)/接收器600具有公鑰/私鑰對(duì)650，而服務(wù)器/發(fā)送器602具有客戶機(jī)/接收器的公鑰。在此示例中，客戶機(jī)/接收器的公鑰和私鑰中的每一個(gè)都是1024位RSA密鑰。使用客戶機(jī)/接收器的公鑰，服務(wù)器/發(fā)送器構(gòu)建一包含用客戶機(jī)/接收器的公鑰加密的初始內(nèi)容密鑰的根許可證。該初始內(nèi)容密鑰是128位AES內(nèi)容密鑰。該根許可證然后被發(fā)送到客戶機(jī)/接收器。在圖6中，這被示為在客戶機(jī)/接收器和服務(wù)器/發(fā)送器之間發(fā)生的第一通信，其中加密的內(nèi)容密鑰被表示為(內(nèi)容密鑰iHm。然而，可以理解，在所示的通信之前可發(fā)生其它通信。從服務(wù)器/發(fā)送器接收到加密的內(nèi)容密鑰之后，客戶機(jī)/接收器現(xiàn)在可使用其私鑰來解密該內(nèi)容密鑰，并且可安全地儲(chǔ)存解密的內(nèi)容密鑰以供將來使用。在以下描述中，該第一內(nèi)容密鑰被稱為衣^#/^#麥勢(shì)。此時(shí)，考慮發(fā)生了什么事情。服務(wù)器/發(fā)送器已向客戶機(jī)/接收器安全地傳送了現(xiàn)在可用作后續(xù)密碼操作的基礎(chǔ)的密鑰。更具體地，現(xiàn)在考慮要在流傳送期間作出涉及一段特定的受DRM保護(hù)的內(nèi)容的策略更新。在這一情況下，服務(wù)器/發(fā)送器可準(zhǔn)備一包含該更新的策略的葉許可證。該葉許可證包含策略更新以及加密版本的內(nèi)容密鑰2。在此示例中，內(nèi)容密鑰2是使用初始內(nèi)容密鑰來加密的128位AES內(nèi)容密鑰。由此，客戶機(jī)/接收器所經(jīng)歷并導(dǎo)致的、與解密新的以及附加的內(nèi)容密鑰相關(guān)聯(lián)的計(jì)算復(fù)雜度和開銷相對(duì)于與1024位RSA密鑰操作相關(guān)聯(lián)的計(jì)算復(fù)雜度開銷被減小，因?yàn)楝F(xiàn)在客戶機(jī)/接收器只需使用128位的AES內(nèi)容密鑰(即，初始內(nèi)容密鑰)來解密。對(duì)于其中利用XMR來表示許可證和許可證更新的實(shí)現(xiàn)示例，考慮以下。使用許可證鏈的一個(gè)目的是減少在許可證更新期間執(zhí)行的非對(duì)稱密鑰操作的數(shù)目。在此實(shí)現(xiàn)示例中，沒有強(qiáng)調(diào)將根許可證用作傳達(dá)權(quán)限和限制的機(jī)制。結(jié)果，根許可證是非常簡(jiǎn)單的，并且沒有傳達(dá)任何權(quán)限或限制。然而，可以理解，在至少某些實(shí)現(xiàn)中，根許可證可隨其承載權(quán)限和限制。在此示例中，葉許可證經(jīng)由上行鏈接KID對(duì)象被鏈接到根許可證。以下小節(jié)著重于根據(jù)一個(gè)實(shí)施例在這些許可證中存在的對(duì)象。對(duì)于根許可證，以下描述了用于回放的根許可證上存在的一組XMR對(duì)象。XMR報(bào)頭結(jié)構(gòu)XMR容器對(duì)象I+--全局策略容器對(duì)象III+--最小環(huán)境對(duì)象III+--權(quán)限設(shè)置對(duì)象I+--回放策略容器對(duì)象III+--輸出保護(hù)對(duì)象I+--密鑰資料容器對(duì)象III+--內(nèi)容密鑰對(duì)象I+--乂1^11簽名對(duì)象回放策略容器對(duì)象必須存在，以允許進(jìn)行回放。另一方面，用于復(fù)制動(dòng)作的根許可證應(yīng)當(dāng)包含復(fù)制權(quán)限容器對(duì)象而非回放策略容器。以下是存在于用于復(fù)制的根許可證上的一組XMR對(duì)象。XMR報(bào)頭結(jié)構(gòu)XMR容器對(duì)象I+__全局策略容器對(duì)象III+—最小環(huán)境對(duì)象III+--權(quán)限設(shè)置對(duì)象I+--回放策略容器對(duì)象III+—輸出保護(hù)對(duì)象I+--復(fù)制權(quán)限容器對(duì)象I+--密鑰資料容器對(duì)象III+--內(nèi)容密鑰對(duì)象I+--XMR簽名對(duì)象在此實(shí)施例中，復(fù)制權(quán)限容器對(duì)象必須存在，以指示復(fù)制是被允許的。注意，回放策略容器對(duì)象仍存在，因?yàn)榛胤诺臋?quán)限必須總是被授予。對(duì)于此具體實(shí)施例中的葉許可證，考慮以下。葉許可證可包含可經(jīng)由XMR來表達(dá)的任何類型的權(quán)限或限制。葉許可證與鏈和非鏈許可證之間的一個(gè)主要區(qū)別在于使用對(duì)稱密鑰來加密內(nèi)容密鑰，且其經(jīng)由上行鏈接KID對(duì)象向上鏈接到其它許可證o以下是用于回放的葉許可證的一個(gè)示例XMR報(bào)頭結(jié)構(gòu)XMR容器對(duì)象I+--全局策略容器對(duì)象III+--最小環(huán)境對(duì)象I+—回放策略容器對(duì)象III+--輸出保護(hù)對(duì)象III+—下采樣輸出列表對(duì)象III+--顯示模擬視頻輸出保護(hù)對(duì)象I+--密鑰資料容器對(duì)象III+--內(nèi)容密鑰對(duì)象III+--上行鏈接1^0對(duì)象I+--乂1^1簽名對(duì)象內(nèi)容密鑰對(duì)象必須將密鑰加密密碼類型設(shè)為0x0002(鏈許可證)，并將對(duì)稱密碼類型設(shè)為0x0001(AESCTR)。上行鏈接KID對(duì)象必須將上行鏈接KID字段設(shè)為根許可證的KID。以下是此具體實(shí)施例中用于復(fù)制的葉許可證的一個(gè)示例XMR報(bào)頭結(jié)構(gòu)XMR容器對(duì)象I+--全局策略容器對(duì)象III最小環(huán)境對(duì)象I—-回放策略容器對(duì)象III+--輸出保護(hù)對(duì)象I+復(fù)制權(quán)限容器對(duì)象III+--復(fù)制計(jì)數(shù)限制對(duì)象III+_-復(fù)制保護(hù)級(jí)別限制對(duì)象I+--密鑰資料容器對(duì)象III+--內(nèi)容密鑰對(duì)象III+—上行鏈接KID對(duì)象I+--乂1^簽名對(duì)象在此實(shí)施例中，復(fù)制權(quán)限容器對(duì)象必須存在，以指示復(fù)制是被允許的。如果對(duì)允許的復(fù)制次數(shù)有限制，則復(fù)制計(jì)數(shù)限制對(duì)象存在。如果對(duì)用作復(fù)制的目的地的系統(tǒng)有限制，則復(fù)制保護(hù)級(jí)別限制對(duì)象存在。注意，回放策略容器對(duì)象仍存在，因?yàn)榛胤诺臋?quán)限必須總是被授予。圖7是描述根據(jù)一個(gè)實(shí)施例的方法中的各步驟的流程圖。該方法可結(jié)合任何適當(dāng)?shù)挠布④浖?、固件或其組合來執(zhí)行。在一個(gè)實(shí)施例中，該方法可結(jié)合諸如以上示出并描述的那些系統(tǒng)來實(shí)現(xiàn)。另外，在以下討論中，所執(zhí)行的動(dòng)作中的某一些被描述為由服務(wù)器/發(fā)送器來執(zhí)行，而其它動(dòng)作被描述為由客戶機(jī)/接收器來執(zhí)行。服務(wù)器/發(fā)送器和客戶機(jī)/接收器的示例在上文中提供。步驟700使用客戶機(jī)/接收器的公鑰來加密初始內(nèi)容密鑰?？衫萌魏芜m當(dāng)?shù)膬?nèi)容密鑰，以上僅給出了其一個(gè)示例。步驟702將包含加密的初始內(nèi)容密鑰的根許可證發(fā)送給客戶機(jī)/接收器?？衫萌魏芜m當(dāng)?shù)姆椒▉韺?shí)現(xiàn)此步驟。在以下討論中，提供了利用兩種不同協(xié)議的兩個(gè)具體示例?？梢岳斫夂兔靼?，這些僅構(gòu)成示例，且并不旨在將所要求保護(hù)的主題的應(yīng)用僅限于所描述的特定協(xié)議。步驟704接收服務(wù)器/發(fā)送器發(fā)送的根許可證，且步驟706解密該加密的初始內(nèi)容密鑰。在此示例中，該步驟通過使用客戶機(jī)/接收器的私鑰解密該加密的初始內(nèi)容密鑰來執(zhí)行。步驟708準(zhǔn)備葉許可證，并用初始內(nèi)容密鑰來加密新內(nèi)容密鑰。步驟710將葉許可證發(fā)送給客戶機(jī)/接收器?？梢曰叵?，葉許可證可以且通常的確包含用于受DRM保護(hù)的內(nèi)容的策略和策略更新。應(yīng)當(dāng)理解和明白，步驟708和710可以對(duì)給定的一段受DRM保護(hù)的內(nèi)容執(zhí)行多次。g卩，當(dāng)策略對(duì)于特定的一段受DRM保護(hù)的內(nèi)容改變時(shí)，可準(zhǔn)備相應(yīng)的葉許可證并將其發(fā)送給客戶機(jī)/接收器。步驟712接收葉許可證，且步驟714通過使用先前接收到的初始內(nèi)容密鑰來解密新內(nèi)容密鑰。步驟716然后使用解密的新內(nèi)容密鑰來解密內(nèi)容，并更新葉許可證中包含的策略?？梢岳斫夂兔靼?，步驟712、714和716可對(duì)客戶機(jī)/接收器接收到的每一新的葉許可證執(zhí)行。使用HTTP來傳送更新的策略討論了根和葉許可證的概念以及其各自可如何在上述上下文中采用之后，現(xiàn)在考慮可如何使用HTTP來傳送根和葉許可證。當(dāng)利用HTTP來承載受DRM保護(hù)的內(nèi)容時(shí)，客戶機(jī)向服務(wù)器/發(fā)送器發(fā)出兩個(gè)請(qǐng)求。首先，客戶機(jī)發(fā)出檢索根許可證的提出(POST)請(qǐng)求。其次，客戶機(jī)發(fā)出檢索受DRM保護(hù)的內(nèi)容的獲取(GET)請(qǐng)求。在此示例中客戶機(jī)發(fā)出請(qǐng)求，因?yàn)樵贖TTP中，服務(wù)器不能啟動(dòng)與客戶機(jī)的通信。具體地，結(jié)合以下討論考慮圖8。當(dāng)客戶機(jī)希望接收根許可證時(shí)，它向服務(wù)器發(fā)出提出請(qǐng)求。提出請(qǐng)求如上所述包含許可證請(qǐng)求消息。響應(yīng)于接收到此通信，服務(wù)器用包含根許可證的許可證響應(yīng)消息來響應(yīng)，在至少一個(gè)實(shí)施例中，該根許可證用XMR來表達(dá)。接收到根許可證并相應(yīng)地處理它之后，客戶機(jī)向服務(wù)器發(fā)出要求受DRM保護(hù)的內(nèi)容的獲取請(qǐng)求。響應(yīng)于獲取請(qǐng)求，服務(wù)器用與一個(gè)或多個(gè)許可證響應(yīng)消息交錯(cuò)的所請(qǐng)求內(nèi)容的各段來回復(fù)。許可證響應(yīng)消息各自包含涉及該受DRM保護(hù)的內(nèi)容的一特定部分的葉許可證?？墒褂萌魏芜m當(dāng)?shù)臋C(jī)制或交錯(cuò)技術(shù)來形成服務(wù)器的回復(fù)。僅作為一個(gè)實(shí)現(xiàn)示例，在一個(gè)特定上下文中，考慮以下。在僅一個(gè)示例中，使用四字節(jié)的成幀報(bào)頭來封裝數(shù)據(jù)和控制塊。成幀報(bào)頭包含一字節(jié)的ASCII美元符號(hào)(0x24)，之后是一字節(jié)的塊類型標(biāo)識(shí)符，之后是兩字節(jié)的封裝數(shù)據(jù)的長(zhǎng)度，以網(wǎng)絡(luò)字節(jié)順序來表示。<table>tableseeoriginaldocumentpage16</column></row><table>控制塊使用ASCII'c'字符(0x63)作為其類型標(biāo)識(shí)符。該塊包含消息，通常是許可證響應(yīng)消息。數(shù)據(jù)塊使用ASCII'd'字符(0x63)作為其類型標(biāo)識(shí)符。該塊包含數(shù)據(jù)段描述符，后面直接跟有媒體數(shù)據(jù)。數(shù)據(jù)段描述符可與加密的或明文的內(nèi)容相關(guān)聯(lián)。描述符中的已加密標(biāo)志傳達(dá)此信息。數(shù)據(jù)段描述符與所發(fā)送的文件的一部分相關(guān)聯(lián)，對(duì)該部分，如果其被加密，則向其應(yīng)用單個(gè)策略和內(nèi)容加密密鑰。換言之，內(nèi)容加密密鑰和策略不能在段內(nèi)改變。根據(jù)一個(gè)實(shí)施例，一典型的具有鏈接加密的HTTP響應(yīng)由以下塊組成-1.承載具有鏈許可證的許可證響應(yīng)消息的控制塊[Sc]。2.—個(gè)或多個(gè)數(shù)據(jù)塊[Sd]。在文件傳輸期間存在密鑰或策略改變的情況下，則增加以下步驟3.承載具有新的鏈許可證的許可證響應(yīng)消息的新控制塊[Sc]。4.一個(gè)或多個(gè)數(shù)據(jù)塊[Sd]。注意，在多次密鑰或策略改變的情況下，步驟3和4可發(fā)生多次。使用RTSP來承載根和葉許可證討論了根和葉許可證的概念以及其各自如何可使用HTTP來傳送之后，現(xiàn)在考慮如何可使用RTSP來傳送根和葉許可證。RTSP和HTTP之間的區(qū)別之一是RTSP比HTTP要復(fù)雜得多。具體地，RTSP具有對(duì)服務(wù)器發(fā)起的請(qǐng)求的規(guī)定，它允許服務(wù)器在任何時(shí)刻向客戶機(jī)發(fā)送命令。根據(jù)此實(shí)施例，結(jié)合圖9考慮以下。當(dāng)客戶機(jī)/接收器希望播放受DRM保護(hù)的內(nèi)容時(shí)，客戶機(jī)發(fā)送包含許可證請(qǐng)求消息的描述(DESCRIBE)請(qǐng)求。響應(yīng)于接收到該消息，服務(wù)器用嵌入了許可證響應(yīng)消息的會(huì)話描述協(xié)議(SESSIONDESCRIPTIONPROTOCOL)(SDP)來響應(yīng)。許可證響應(yīng)消息包含根證書，在此具體實(shí)施例中，根證書用XMR來表達(dá)?，F(xiàn)在，當(dāng)客戶機(jī)希望接收受DRM保護(hù)的內(nèi)容時(shí)，客戶機(jī)向服務(wù)器發(fā)送啟動(dòng)流的PLAY(播放)請(qǐng)求。在任何適當(dāng)?shù)臅r(shí)刻，服務(wù)器可向客戶機(jī)發(fā)送承載包含葉許可證的許可證響應(yīng)消息的通知(ANNOUNCE)請(qǐng)求。作為一個(gè)實(shí)現(xiàn)示例，考慮以下。首先考慮以下根據(jù)一個(gè)實(shí)施例的描述請(qǐng)求摘錄，它結(jié)合了許可證請(qǐng)求消息。DESCRIBErtsp:〃eduardo01/file.麗vRTSP/l.OAccept:application/sdpCSeq:1Supported:com.microsoft.wmdrm-nd,com.microsoft.wm.eosmsg,method.announceRequire:com.microsoft.wmdrm-ndContent-Type:application/vnd.ms-麗d:rm-license-requestContent-:Length:1078/f^"ff請(qǐng)求教富在該示例中使用"R叫uire(要求)com.microsoft.wmdrm-nd"以指示接收器期望服務(wù)器為特定類型的發(fā)送器。在該示例中使用"Content-Type(內(nèi)容類型)application/vnd.ms-wmdrm-license-request"以指示該描述的正文包含許可證請(qǐng)求消息。除非存在錯(cuò)誤，否則發(fā)送器應(yīng)以SDP描述來回復(fù)，該描述包括在下一節(jié)中描述的許可證響應(yīng)消息。接收到在正文中包含許可證請(qǐng)求消息的描述請(qǐng)求之后，服務(wù)器可返回許可證響應(yīng)消息。在此示例中，服務(wù)器返回不僅包含前述各個(gè)參數(shù)而且包含許可證響應(yīng)消息的SDP描述。在此實(shí)施例中，如前所述，許可證響應(yīng)消息將承載指定將對(duì)內(nèi)容應(yīng)用哪些策略的XMR許可證。僅作為一個(gè)實(shí)現(xiàn)示例，考慮以下根據(jù)一個(gè)實(shí)施例的SDP摘錄，它結(jié)合了許可證響應(yīng)消息。RTSP/1.0200OKLast-Modified:Thu,19Dec200215:36:18GMTContent-:Length:1891Content-Typeapplication/sdpCSeq:1Supported:com.microsoft.wmdrm畫nd,com.microsoft.wm.eosmsg,method.announceSDP箱述所返回的許可證對(duì)應(yīng)于將在會(huì)話期間使用的根許可證。該特定葉許可證在稍后的時(shí)刻經(jīng)由以下描述的通知請(qǐng)求來返回。根據(jù)一個(gè)實(shí)施例，由發(fā)送器返回的SDP包括根據(jù)RFC-2397中的規(guī)范(http:〃www.ietf.org/rfc/rfc2397.txt)被編碼在數(shù)據(jù)URL中的許可證響應(yīng)消息。在一個(gè)示例中，包含在數(shù)據(jù)URL中的數(shù)據(jù)必須是Base64編碼的，且MIME類型必須被設(shè)置為"application/vnd.ms-wmdrm-license-response"。作為句法的示例，考慮以下data:application/vnd.ms-wmdrm-license-response;base64,AggAAAAAAAABOFhNUgAAAAAB+TTbzXCRwls+/jfQQYOwADAAEAAAEgAAMAAgAAADwAAQADAAAAEAAEgBkAGQAZABkAGQAAwAJAAAApgABAAoAAACeajiAiUBMGrAGUA0IqMGBggABAAEAgC7VlQF54EzdtXlWx/AAEACwAAABwAAQAQZZaX5nGEUAV8w6p6BQr++Q==在該示例中，根據(jù)SDP密鑰管理擴(kuò)展規(guī)范，數(shù)據(jù)URL必須使用"a-key-mgmt"屬性被插入到SDP會(huì)話層，該規(guī)范迄今為止仍是進(jìn)展中的工作。句法如下a=key-mgmt:wmdrm-ndURL參數(shù)為上述數(shù)據(jù)URL?，F(xiàn)在考慮使用通知請(qǐng)求在流的中間傳送更新的策略。具體地，根據(jù)一個(gè)實(shí)施例，以下通知請(qǐng)求摘錄示出了如何可傳送葉許可證。ANNOUNCErtsp:〃eduardo01/file.麗vRTSP/l.OCSeq:27Session:8322364901836665746Supported:com.microsoft.wmdrm-nd,com.microsoftwm.eosmsg,method.announceRequire:method.announceEvent-Type:4000wmdrm-nd-messageContent-Type:application/vnd.ms-wmdrm-license-responseContent-Liength:924許可證響應(yīng)消息在此示例中，必須使用"Content-Type(內(nèi)容類型)application/vnd.ms-wmdrm-license-response"J艮頭來f旨示i青求的正文包含i午可i正響應(yīng)消息。在此示例中，必須使用"Event-Type(事件類型)4000wmdrm-nd-message"來指示這是承載WMDRM-ND消息的事件。接收器應(yīng)當(dāng)處理許可證響應(yīng)消息，以確保權(quán)限標(biāo)識(shí)匹配許可證請(qǐng)求中的權(quán)限標(biāo)識(shí)。除非存在錯(cuò)誤，否則接收器必須向發(fā)送器返回200OK響應(yīng)，諸如以下所示的。RTSP/1.0200OKCSeq:27Session:8322364901836665746Supported:com.microsoft.麗drm-nd,com.microsoft.wm.eosmsg,method.a皿oimce注意，由于描述請(qǐng)求中返回的許可證對(duì)應(yīng)于根證書。發(fā)送器在啟動(dòng)數(shù)據(jù)傳送之前必須傳送允許接收器解密該內(nèi)容的葉許可證。這意味著緊接在接收器發(fā)送第一個(gè)PLAY請(qǐng)求之后，發(fā)送器要負(fù)責(zé)在啟動(dòng)數(shù)據(jù)流之前在通知請(qǐng)求中發(fā)送葉許可證。對(duì)于發(fā)送器傳送通知消息和需要新許可證來解密內(nèi)容的時(shí)刻之間沒有嚴(yán)格的關(guān)系。這意味著發(fā)送器可在其開始傳送包含相關(guān)聯(lián)的受保護(hù)內(nèi)容的分組之前或甚至在此之后傳送通知?？捎糜诔休d受保護(hù)內(nèi)容的一種方法是如本領(lǐng)域的技術(shù)人員所理解的通過使用RTP分組。結(jié)論上述各實(shí)施例允許對(duì)給定的一段受保護(hù)內(nèi)容傳送并更新諸如DRM策略更新等策略更新。在至少某些實(shí)施例中，可擴(kuò)展各種協(xié)議以允許由該協(xié)議來表示和承載策略更新。盡管用結(jié)構(gòu)特征和/或方法步驟專用的語(yǔ)言描述了本發(fā)明，但可以理解，所附權(quán)利要求書中定義的本發(fā)明不必限于所述的特定特征或步驟。相反，這些特定特征和步驟是作為實(shí)現(xiàn)所要求保護(hù)的本發(fā)明的優(yōu)選形式而公開的。權(quán)利要求1.一種計(jì)算機(jī)實(shí)現(xiàn)的方法，包括構(gòu)建包含已加密初始內(nèi)容密鑰的根許可證，所述已加密初始密鑰是使用預(yù)期接收器的公鑰來加密的，所述根許可證涉及要流傳送到所述預(yù)期接收器的內(nèi)容；將所述根許可證發(fā)送到所述預(yù)期接收器；準(zhǔn)備鏈接到所述根許可證的一個(gè)或多個(gè)葉許可證，所述一個(gè)或多個(gè)葉許可證涉及與所述流傳送內(nèi)容相關(guān)聯(lián)的經(jīng)更新的策略，其中所述一個(gè)或多個(gè)葉許可證各自包含使用所述初始內(nèi)容密鑰來加密的不同內(nèi)容密鑰，其中所述不同內(nèi)容密鑰可由所述接收器用于解密受保護(hù)內(nèi)容；以及將所述一個(gè)或多個(gè)葉許可證發(fā)送到所述預(yù)期接收器。2.如權(quán)利要求l所述的方法，其特征在于，所述初始內(nèi)容密鑰具有比所述公鑰少的位。3.如權(quán)利要求2所述的方法，其特征在于，所述初始內(nèi)容密鑰包括128位AES密鑰。4.如權(quán)利要求l所述的方法，其特征在于，所述不同內(nèi)容密鑰具有比所述公鑰少的位。5.如權(quán)利要求4所述的方法，其特征在于，所述不同內(nèi)容密鑰包括128位AES密鑰。6.如權(quán)利要求1所述的方法，其特征在于，所述發(fā)送根許可證和一個(gè)或多個(gè)葉許可證的動(dòng)作是使用HTTP來執(zhí)行的。7.如權(quán)利要求l所述的方法，其特征在于，所述發(fā)送根許可證和--個(gè)或多個(gè)葉許可證的動(dòng)作是使用HTTP來執(zhí)行的，并且其中，所述發(fā)送一個(gè)或多個(gè)葉許可證的動(dòng)作包括將受保護(hù)內(nèi)容與包括所述一個(gè)或多個(gè)葉許可證的數(shù)據(jù)交錯(cuò)。8.如權(quán)利要求l所述的方法，其特征在于，所述發(fā)送根許可證和一個(gè)或多個(gè)葉許可證的動(dòng)作是使用RTSP來執(zhí)行的。9.一種計(jì)算機(jī)實(shí)現(xiàn)的方法，包括-接收請(qǐng)求要流傳送到接收器的受保護(hù)內(nèi)容的根許可證的HTTP提出請(qǐng)求；響應(yīng)于所述接收，向所述接收器發(fā)送根許可證；接收請(qǐng)求受保護(hù)內(nèi)容的HTTP獲取請(qǐng)求；以及響應(yīng)于所述接收HTTP獲取請(qǐng)求，發(fā)送與包括鏈接到所述根許可證的一個(gè)或多個(gè)葉許可證的數(shù)據(jù)交錯(cuò)的所請(qǐng)求的受保護(hù)內(nèi)容的各段。10.如權(quán)利要求9所述的方法，其特征在于，所述HTTP提出請(qǐng)求包含許可證請(qǐng)求消息。11.如權(quán)利要求9所述的方法，其特征在于，所述發(fā)送根許可證的動(dòng)作是通過向所述接收器發(fā)送許可證響應(yīng)消息來執(zhí)行的。12.如權(quán)利要求9所述的方法，其特征在于，所述包括一個(gè)或多個(gè)葉許可證的數(shù)據(jù)分別包括一個(gè)或多個(gè)許可證響應(yīng)消息。13.—種計(jì)算機(jī)實(shí)現(xiàn)的方法，包括接收請(qǐng)求要流傳送到接收器的受保護(hù)內(nèi)容的根許可證的RTSP描述請(qǐng)求；向接收器發(fā)送根許可證；以及發(fā)送鏈接到所述根許可證的一個(gè)或多個(gè)葉許可證，其中所述發(fā)送一個(gè)或多個(gè)葉許可證是在內(nèi)容流傳送期間執(zhí)行的。14.如權(quán)利要求13所述的方法，其特征在于，所述描述請(qǐng)求包含許可證請(qǐng)求消息。15.如權(quán)利要求13所述的方法，其特征在于，所述發(fā)送根許可證的動(dòng)作包括發(fā)送嵌入了包含根許可證的許可證響應(yīng)消息的RTSP會(huì)話描述協(xié)議(SDP)。16.如權(quán)利要求13所述的方法，其特征在于，所述發(fā)送一個(gè)或多個(gè)葉許可證的動(dòng)作分別是使用一個(gè)或多個(gè)RTSP通知請(qǐng)求來執(zhí)行的。17.如權(quán)利要求13所述的方法，其特征在于，所述發(fā)送一個(gè)或多個(gè)葉許可證的動(dòng)作分別是使用一個(gè)或多個(gè)RTSP通知請(qǐng)求來執(zhí)行的，并且其中，所述RTSP通知請(qǐng)求各自包含許可證響應(yīng)消息。18.如權(quán)利要求13所述的方法，其特征在于所述描述請(qǐng)求包含許可證請(qǐng)求消息；以及所述發(fā)送根許可證的動(dòng)作包括發(fā)送嵌入了包含所述根許可證的許可證響應(yīng)消息的RTSP會(huì)話描述協(xié)議(SDP)。19.如權(quán)利要求13所述的方法，其特征在于所述發(fā)送根許可證的動(dòng)作包括發(fā)送嵌入了包含所述根許可證的許可證響應(yīng)消息的RTSP會(huì)話描述協(xié)議(SDP》以及所述發(fā)送一個(gè)或多個(gè)葉許可證的動(dòng)作分別是使用一個(gè)或多個(gè)RTSP通知請(qǐng)求來執(zhí)行的。20.如權(quán)利要求13所述的方法，其特征在于所述描述請(qǐng)求包含許可證請(qǐng)求消息；所述發(fā)送根許可證的動(dòng)作包括發(fā)送嵌入了包含所述根許可證的許可證響應(yīng)消息的RTSP會(huì)話描述協(xié)議(SDP);以及所述發(fā)送一個(gè)或多個(gè)葉許可證的動(dòng)作分別是使用一個(gè)或多個(gè)RTSP通知請(qǐng)求來執(zhí)行的。全文摘要各實(shí)施例允許對(duì)給定的一段受保護(hù)內(nèi)容傳送并更新諸如DRM策略更新等策略更新。在至少某些實(shí)施例中，可擴(kuò)展各種協(xié)議來允許由該協(xié)議表示和承載策略更新。在一個(gè)實(shí)施例中，利用超文本傳輸協(xié)議，即HTTP來承載策略更新。在另一實(shí)施例中，使用實(shí)時(shí)流傳送協(xié)議，即RTSP來承載策略更新。文檔編號(hào)H04L9/00GK101218778SQ200680025291公開日2008年7月9日申請(qǐng)日期2006年7月11日優(yōu)先權(quán)日2005年7月12日發(fā)明者A·E·克萊門茨,E·P·奧利夫拉,J·M·阿爾科夫申請(qǐng)人:微軟公司