專利名稱：：承載使用用于流傳送的控制協(xié)議和傳輸協(xié)議保護的內(nèi)容的制作方法和傳輸協(xié)議保護的內(nèi)容背景數(shù)字權(quán)限管理(DRM)指的是用于諸如通過控制或限制對數(shù)字媒體內(nèi)容在電子設(shè)備上的使用來保護內(nèi)容的技術(shù)。DRM的一個特性在于，它可將媒體內(nèi)容綁定到給定的機器或設(shè)備。因此，一般將關(guān)于特定內(nèi)容并定義與該內(nèi)容相關(guān)聯(lián)的權(quán)限和限制的許可證綁定至該給定的機器或設(shè)備。因此，用戶一般不能夠取得該內(nèi)容，并將其移動至另一機器以便回放該內(nèi)容。存在許可受到DRM保護的內(nèi)容被移動至其它機器以便于在這些機器上回放該內(nèi)容的某些技術(shù)，但這些技術(shù)傾向于使用不適于同時傳送和回放內(nèi)容的非實時內(nèi)容傳送協(xié)議。概述各種實施例利用保護內(nèi)容的各種方法，諸如數(shù)字權(quán)限管理(DRM)，來允許在諸如家庭媒體網(wǎng)絡(luò)等的局域網(wǎng)內(nèi)的多個機器和設(shè)備上安全地回放內(nèi)容。在至少某些實施例中，分別使用用于流傳送的控制協(xié)議和傳輸協(xié)議來傳遞消息和內(nèi)容。在至少某些實施例中，用于流傳送的控制協(xié)議是實時流傳送協(xié)議(RTSP)，而傳輸協(xié)議為實時傳輸協(xié)議(RTP)。附圖簡述圖1示出了可用其來在一個實施例中采用本發(fā)明實施例的一協(xié)議的示例性注冊過程。圖2示出了可用其來在一個實施例中采用本發(fā)明實施例的一協(xié)議的示例性鄰近檢測過程。圖3示出了可用其來在一個實施例中采用本發(fā)明實施例的一協(xié)議的示例性會話建立過程。圖4示出了可用其來在一個實施例中采用本發(fā)明實施例的一協(xié)議的示例性數(shù)據(jù)傳送過程。4圖5示出了可用其來根據(jù)一個實施例來利用本發(fā)明實施例的流傳送協(xié)議的各個方面。圖6示出了結(jié)合一個實施例來利用的圖5中的流傳送協(xié)議。圖7示出了結(jié)合一個實施例來利用的圖5中的流傳送協(xié)議。圖8是描述根據(jù)一個實施例的一方法中各步驟的流程圖。圖9示出了根據(jù)一個實施例的分組。圖IO示出了根據(jù)一個實施例的樣本加密。圖11示出了根據(jù)一個實施例的分組。詳細描述概觀此處描述的各個實施例利用了用于保護內(nèi)容的各方法，諸如數(shù)字權(quán)限管理(DRM)以允許在諸如家庭媒體網(wǎng)絡(luò)的局域網(wǎng)內(nèi)的多個機器和設(shè)備上安全地回放內(nèi)容。在至少某些實施例中，分別使用用于流傳送的控制協(xié)議和傳輸協(xié)議來傳遞消息和內(nèi)容。在至少某些實施例中，用于流傳送的控制協(xié)議為實時流傳送協(xié)議(RTSP)，而傳輸協(xié)議為實時傳輸協(xié)議(RTP)。如由本領(lǐng)域的技術(shù)人員所理解的，在這些實施例中，引入了協(xié)議擴展，它們享受由RTSP/RTP提供的優(yōu)點，包括通過用戶數(shù)據(jù)報協(xié)議(UDP)和客戶機與服務器之間的雙向通信來進行數(shù)據(jù)傳遞。具體地，在至少某些實施例中，協(xié)議擴展使用RTSP安全地建立一會話，傳輸用RTP封裝的受保護數(shù)據(jù)，提供根據(jù)RTP有效負荷格式來加密和傳送數(shù)據(jù)的各種方案，以及用于同經(jīng)加密的內(nèi)容數(shù)據(jù)一起傳送加密參數(shù)的各種方法。在以下的討論中，提供了題為"內(nèi)容安全和許可證傳送協(xié)議的章節(jié)，它描述了可在其中采用本發(fā)明技術(shù)的一個特定系統(tǒng)。在其之后，提供了題為"RTSP"的章節(jié)以向不熟悉RTSP的讀者給出RTSP領(lǐng)域中用于理解本發(fā)明技術(shù)的至少某些上下文。在該章節(jié)之后，提供了題為"使用RTSP的示例性實現(xiàn)"的章節(jié)，它描述了采用RTSP以建立控制流并利用RTP來建立數(shù)據(jù)流的各種本發(fā)明技術(shù)。內(nèi)容安全和許可證傳送協(xié)議以下提供了一示例性協(xié)議的討論，該協(xié)議提供用于內(nèi)容通過數(shù)字鏈路流動的安全和傳送許可證。該協(xié)議僅構(gòu)成了可用其來采用各種發(fā)明的技術(shù)的一個示例性協(xié)議?？梢岳斫夂皖I(lǐng)會，可利用其它協(xié)議，而不背離所要求保護的本主體的精神和范圍。在描述中使用以下密碼記號K(數(shù)據(jù))使用秘密密鑰K來加密數(shù)據(jù)。K[數(shù)據(jù)]使用秘密密鑰K來簽署數(shù)據(jù)。{數(shù)據(jù)}^用設(shè)備的公鑰來加密數(shù)據(jù)。m用設(shè)備的私鑰來簽署數(shù)據(jù)。在此特定協(xié)議中，有五個主要過程茲〕欽、^M;新驗f、鄰近檢/jf、會話;^i、在^^屋過程中，發(fā)送機(即，有內(nèi)容要發(fā)送給另一設(shè)備的一設(shè)備)可唯一且安全地表示預期的接收機(即，要向其發(fā)送內(nèi)容的設(shè)備)。在該特定協(xié)議中，發(fā)送機維護具有已注冊接收機的數(shù)據(jù)庫，并確保不同時使用超過少量預定數(shù)目的接收機。在該注冊過程期間，發(fā)送機還采用鄰if澄,/i^^確保接收機位于網(wǎng)絡(luò)中發(fā)送機的"附近"，以防止受保護內(nèi)容的廣泛分發(fā)。_^^#:邀^^過程被用來確保接收機繼續(xù)在發(fā)送機"附近"。除非接收機在過去的一預定時間段內(nèi)已注冊或已重新驗證，否則內(nèi)容不被傳遞給該接收機。只要接收機向發(fā)送機請求內(nèi)容就使用會話一建J過程。發(fā)送機強制在完成會話;^J2^前該設(shè)備必須經(jīng)過注冊或最近經(jīng)過驗證。一旦建立了會話，所請求內(nèi)容的^"嚴/^^可用安全的方式進行。接收機可再次使用該會話來檢索該內(nèi)容的特定部分(查找)，但必須建立一新會話以便檢索不同的內(nèi)容。現(xiàn)在結(jié)合圖1和描述注冊期間在發(fā)送機和接收機之間傳遞的各個消息的下表來考慮注I過程。消息值描述<table>tableseeoriginaldocumentpage6</column></row><table>地址發(fā)送機傳入和傳出的鄰近分組套接字的地址。SId(會話Id)128位隨機會話Id。鄰近檢測算法在頻帶外執(zhí)行鄰近檢測算法。此處，接收機發(fā)送除其它信息外還包含接收機的數(shù)字證書的注冊請求消息。響應于接收該注冊請求消息，發(fā)送機驗證接收機的證書，生成種子和隨機會話ID，在注冊響應消息中按上述格式向接收機返回同樣內(nèi)容。接收機然后驗證發(fā)送機的簽名，獲取會話ID并執(zhí)行附圖中所示的其它動作。接收機和發(fā)送機然后可經(jīng)歷以下描述的鄰近檢測過程。對于^if邀,，執(zhí)行與上述相同的過程，區(qū)別在于，在羞、齊教證期間，接收機已在數(shù)據(jù)庫中注冊。對于鄰近澄#/，結(jié)合圖2考慮以下。在汆^近澄^f過程期間，接收機向發(fā)送機發(fā)送包含鄰近檢測初始化消息中指示的會話Id的消息。發(fā)送機然后向接收機發(fā)送包含現(xiàn)時值(Nonce)(128位隨機值)的消息，并測量接收機以使用內(nèi)容加密密鑰加密的現(xiàn)時值來答復所花的時間。最后，發(fā)送機向接收機發(fā)送指示鄰近檢測成功與否的消息。接收機可重復該過程，直到它確認鄰近檢測成功。當該特定協(xié)議在基于IP的網(wǎng)絡(luò)上使用時，通過UDP來交換鄰近檢測消息。接收機經(jīng)由注冊響應消息知道發(fā)送機的地址。接收機的地址不需要單獨傳送，因為可通過檢查承載鄰近檢測初始化消息的UDP分組的傳入IP頭來確定。下表描述了在鄰近檢測期間交換的消息:消息值描述鄰近開始消息1SId(會話Id)由發(fā)送機發(fā)送的同一128位會話Id值。鄰近質(zhì)詢消息Seq(序號)8位遞增序號。SId(會話Id)同一128位會話Id?，F(xiàn)時值128位隨機值。鄰近響應消息Seq(序號)由發(fā)送機確定的同一序號。SId(會話Id)同一128位會話Id。KC(現(xiàn)時值〉使用內(nèi)容加密密鑰加密的128位現(xiàn)時值。鄰近結(jié)果消息SId(會話Id)同一128位會話Id。結(jié)果指示注冊過程成功還是失敗的狀態(tài)碼。7對于會話;^立，結(jié)合圖3和描述在會話^^li期間交換的消息的下表考慮以下。<table>tableseeoriginaldocumentpage8</column></row><table>在此示例中，從接收機向發(fā)送機發(fā)送許可證請求消息，它包含上述信息。作為響應，發(fā)送機可發(fā)送包含上述信息的許可證響應消息。在該特定示例中，用XMR格式表示許可證，許可證包括內(nèi)容加密密鑰、內(nèi)容完整性密鑰、發(fā)送機CRL的版本、128位權(quán)限Id和128位序列號。許可證還包含使用OMAC用內(nèi)容完整性密鑰計算的OMAC。對于^"嚴傳送過程，結(jié)合圖4考慮以下。一旦會話;^J^成，即以控制協(xié)議專用的方式執(zhí)行數(shù)據(jù)傳送。^"嚴傳送請求和響應兩者必須為控制協(xié)議和內(nèi)容類型特別定義。這概念性地表示在圖4中?，F(xiàn)在提供了可用其來采用本發(fā)明實施例的示例性協(xié)議的簡要概觀，現(xiàn)在考慮RTSP的一些背景信息。RTSP如本領(lǐng)域的技術(shù)人員所理解，實時流傳送協(xié)議即RTSP是用于對具有實時特性的數(shù)據(jù)傳遞(即流傳送)進行控制的應用層協(xié)議。RTSP提供允許對諸如音頻和視頻的實時數(shù)據(jù)進行受控、按需傳遞的可擴展框架。數(shù)據(jù)源可包括實況數(shù)據(jù)饋送和已存儲的剪輯兩者。該協(xié)議旨在控制多個數(shù)據(jù)傳遞會話，提供用于選擇諸如UDP、組播UDP和TCP的傳遞信道的手段，并提供用于基于RTP選擇傳遞機制的手段。RTSP建立并控制單個或多個時間同步的連續(xù)媒體流，諸如音頻和視頻。它自己一般不傳遞連續(xù)流，盡管連續(xù)媒體流與控制流的交織是可能的。換言之，RTSP用作多媒體服務器的"網(wǎng)絡(luò)遙控器"。要被控制的流的集合由演示描述定義。在RTSP中，不存在RTSP連接的概念；相反，服務器維護由標識符標記的會話。RTSP會話決不綁定至傳輸層連接，諸如TCP連接。在RTSP會話期間，RTSP客戶機可打開或關(guān)閉至服務器的眾多可靠的傳輸連接以發(fā)出RTSP請求。或者，如本領(lǐng)域的技術(shù)人員可以理解，可使用諸如UDP的無連接傳輸協(xié)議。由RTSP控制的流可使用RTP，但RTSP的操作不依賴于用于承載連續(xù)媒體的傳輸機制。現(xiàn)在結(jié)合圖5考慮客戶機/接收機500與服務器/發(fā)送機502之間的典型的RTSP請求/響應交換。初步地，RTSP請求/響應具有為簡潔起見未做描述的標頭。在RTSP中，客戶機/接收機500—般發(fā)出被稱為描述的請求，它針對從服務器502檢索由請求URL標識的演示或媒體對象的描述。服務器502用以會話描述協(xié)議(SDP)表示的被請求資源的描述作出響應。描述響應(SDP)包含其所描述的資源的所有媒體初始化信息。接著，客戶機500發(fā)送對指定要用于流傳送媒體的傳輸機制的URI的設(shè)置請求。在圖5的示例中，為音頻和視頻兩者發(fā)送設(shè)置請求。客戶機500還在設(shè)置請求中指示它將利用的傳輸參數(shù)。設(shè)置請求中的傳輸標頭指定客戶機可接受用于數(shù)據(jù)傳輸?shù)膫鬏攨?shù)。來自服務器502的響應包含由服務器所選的傳輸參數(shù)。服務器還響應于該設(shè)置請求生成會話標識符。此時，客戶機可發(fā)出播放請求，它告知服務器以經(jīng)由設(shè)置中指定的機制來開始發(fā)送數(shù)據(jù)。響應于接收播放請求，服務器可開始流傳送內(nèi)容，在此示例中，該內(nèi)容為音頻/視頻內(nèi)容。如本領(lǐng)域的技術(shù)人員可以理解，在此示例中，流傳送的內(nèi)容9使用RTP分組封裝并通過UDP發(fā)送。RTSP協(xié)議具有感興趣的其它方法，包括暫停、拆卸、獲取參數(shù)、設(shè)置參數(shù)、重定向和記錄。對關(guān)于RTSP的其它背景，讀者應查詢1998年4月的RTSP草案，Schulzrinne,H.,Rao,A.和R.Lanphier的"RealTimeStreamingProtocol(實時流傳送協(xié)議)(RTSP)"，草案2326，可在http:〃www.ietf.org/rfc/rfc2326.txt提供。使用RTSP的示例性實現(xiàn)在以下討論中，有兩個主要的子章節(jié)，一個題為"控制流"，描述如何使用RTSP建立受DRM保護的內(nèi)容的控制流，另一個題為"數(shù)據(jù)流"，描述了如何使用RTSP建立受DRM保護的內(nèi)容的數(shù)據(jù)流。這些主要子章節(jié)中的每一個都具有與之相關(guān)聯(lián)的描述本發(fā)明的實施例的各方面的子章節(jié)。在以下討論中，提供了如何根據(jù)一個實施例使用RTSP/RTP來實現(xiàn)上述協(xié)議的會話;^J和^"嚴傳送過程的描述。更具體地，在以下的"控制流"章節(jié)中，提供了如何使用RTSP實現(xiàn)會話^J的描述。在"數(shù)據(jù)流"章節(jié)中，提供了如何使用RTP實現(xiàn)J^嚴傳送的描述。控制流根據(jù)該實施例，由希望回放受DRM保護的內(nèi)容——即，具有相關(guān)聯(lián)許可證的內(nèi)容的接收機設(shè)備發(fā)起會話^^立?；叵胍陨蠈?nèi)容安全和許可證協(xié)議的討論，客戶機/接收機可相應地向服務器/發(fā)送機發(fā)送許可證請求消息，服務器/發(fā)送機可以許可證響應消息來對其答復。許可證響應消息又承載一許可證，在以上示例中該許可證是以可擴展媒體權(quán)限(XMR)來表示的。許可證包含與所請求的內(nèi)容相關(guān)聯(lián)的策略和內(nèi)容密鑰。在描述請求中承載許可證請求消息現(xiàn)在結(jié)合圖6考慮內(nèi)容安全和許可證協(xié)議與RTSP的匯合。具體地，圖6示出了根據(jù)一個實施例的客戶機/接收機600和服務器/發(fā)送機602。根據(jù)該實施例，當客戶機/接收機600希望訪問受DRM保護的內(nèi)容時，客戶機在描述請求的正文中插入許可證請求消息。僅作為一個實現(xiàn)示例，考慮以下根據(jù)一個實施例包括許可證請求消息的描述請求消息摘錄。DESCRIBErtsp:〃eduardoOl/file.麗vRTSP/1.0Accept:application/sdpCSeq:1Supported:com.microsoft.wmdrm-nd,com.microsoft.wra.eosmsg,method.announceRequire:com.microsoft.wmdnn-ndContent-Type:application/vnd.ms-wmdrm-license-requestContent-Liength:1078License—iegxzest一Message在該示例中使用"R叫uire(要求)com.microsoft.wmdrm-nd"以指示接收機期望服務器為特定類型的發(fā)送機。在該示例中使用"Content-Type(內(nèi)容類型)application/vnd.ms-wmdrm-license-r叫uest"以指示該描述的正文包含許可證請求消息。除非存在錯誤，否則發(fā)送機應以SDP描述來答復，該描述包括在下一章節(jié)中描述的許可證響應消息。將許可證響應消息嵌入到SDP描述中接收到在正文中包含許可證請求消息的描述請求之后，服務器可返回許可證響應消息。在此示例中，服務器返回不僅包含前述各個參數(shù)而且包含許可證響應消息的SDP描述。在此實施例中，如前所述，許可證響應消息將承載指定將對內(nèi)容應用哪些策略的XMR許可證。僅作為一個實現(xiàn)示例，考慮以下根據(jù)一個實施例包括許可證響應請求的SDP摘錄。RTSP/1.0200OKLast-Modified:Thu,19Dec200215:36:18GMTContent-Length:1891Content-Type:application/sdpCSeq:1Supported:com.microsoft.wmdrm-nd,com.microsoft.麗.eosmsg,method.announceSDP一Description根據(jù)一個實施例，由發(fā)送機返回的SDP包括根據(jù)2397草案(http:〃www.ietf.org/rfc/rfc2397.txt)的規(guī)范被編碼在數(shù)據(jù)URL中的許可證響應消息。在一個示例中，包含在數(shù)據(jù)URL中的數(shù)據(jù)必須是Base64編碼的，且MIME類型i^、多頁牟皮設(shè)置為"application/vnd.ms-wmdrm-license陽response"。11作為句法的示例，考慮以下data:application/vnd.ms-wmdrm-license-responsebase64OAAQANAAAACgABAAMABAAAABoAAQAFAAAAEgBkAGQAZABkAGQAAwAJAAAApgA在該示例中，根據(jù)SDP密鑰管理擴展規(guī)范，數(shù)據(jù)URL必須使用"a:key-mgmt"屬性被插入到SDP會話層，該規(guī)范迄今為止仍是進展中的工作。句法如下a=key-mgmt:wmdrm-ndURL參數(shù)為上述數(shù)據(jù)URL。在通告(announce)請求中承載許可證響應消息現(xiàn)在考慮一些媒體文件包含需要實施不同策略的片段。作為示例，采取由Windows媒體中心TV錄制版生成的文件的情況。這樣的文件受到WMDRM的保護，并具有與之相關(guān)聯(lián)的多個策略。例如，對TV演出可能要求Macrovision,但對出現(xiàn)在同一錄制內(nèi)的商業(yè)廣告片段則不需要。該要求導致需要定義用于在流中間傳遞經(jīng)更新的策略的機制。根據(jù)一個實施例，可使用RTSP的通告請求在流中間傳遞經(jīng)更新的策略。在此實施例中，通告請求可承載包含新的XMR許可證的許可證響應消息。在此示例中，有兩種與流傳送媒體相關(guān)聯(lián)的策略可能改變的情況。在第一種情況中，僅與特定流相關(guān)的策略可能改變。第二種情況中，策略和內(nèi)容格式本身均可改變?？紤]其中僅與流傳送媒體相關(guān)聯(lián)的策略可能改變的第一種情況。該情況的一個示例為TV演出片段與商業(yè)廣告之間的切換，其中TV片段需要在模擬輸出上啟用Macrovision,而商業(yè)廣告不需要。注意到，在該示例中，僅策略改變諸如比特率、編解碼器等編碼參數(shù)保持不變?？紤]其中策略和內(nèi)容格式兩者均改變的第二種情況。該情況的一個示例也是TV演出片段與商業(yè)廣告之間的切換，對策略有相同類型的改變。然而，在該示例12中，TV演出和商業(yè)廣告是使用不同編碼參數(shù)編碼的，諸如從高清晰度編碼過渡到標準清晰度編碼。這樣的場景一般被命名為"格式改變"。該情況的另一示例涉及通常被稱為"條目改變"的情況。條目改變一般是在作為"服務器方播放列表"的一部分由服務器傳遞的媒體文件之間切換的結(jié)果。這些播放列表一般由不必共有任何編碼參數(shù)或策略的媒體文件的集合組成。只要策略改變時格式未變，如在第一種情況中示出，服務器僅將新策略發(fā)送給客戶機，作為通告請求的正文的一部分。在這種情況中，許可證響應消息被包括在通告消息的正文中。作為示例，考慮圖7，它示出了示例性的客戶機/接收機700和向客戶機/接收機發(fā)出通告請求以續(xù)接(articulate)帶有經(jīng)更新策略的新許可證的服務器/發(fā)送機702。只要策略改變且格式改變，如第二種情況中所示，服務器向客戶機傳遞經(jīng)更新的SDP描述。要求該SDP描述以描述發(fā)生的格式改變。在該示例中，SDP描述在格式改變的情況中也被作為通告請求傳遞。因此代替?zhèn)鬟f其中一個包含格式改變、另一包含策略改變的兩個連續(xù)通告請求，服務器可僅發(fā)送承載SDP描述的一個通告請求。然后將策略改變作為嵌入在SDP描述中的許可證響應請求發(fā)送。再次考慮圖7，它示出了其正文包含具有嵌入的許可證響應消息的經(jīng)更新SDP的通告請求。用于將許可證響應消息嵌入到作為通告請求的一部分的SDP描述中的格式與前述用于嵌入作為描述響應的一部分的SDP描述的格式相同。圖8是描述根據(jù)一個實施例的方法中各步驟的流程圖。該方法可結(jié)合任何合適的硬件、軟件、固件或其組合來實現(xiàn)。在一個實施例中，該方法被實現(xiàn)為具體化成某種類型的計算機可讀介質(zhì)的一組計算機可讀指令或軟件代碼。步驟800試圖通過經(jīng)由流傳送協(xié)議發(fā)送對受DRM內(nèi)容的許可證的請求來建立控制流。在所示和所述實施例中，該步驟由客戶機/接收機執(zhí)行。對許可證的請求的一個具體示例為上述的許可證請求消息?？衫闷渌恼埱箢愋突蚋袷?，而不背離所要求保護的主題的精神和范圍。此外，以上描述了流傳送協(xié)議的一個示例(即，RTSP)?？墒褂闷渌鱾魉蛥f(xié)議，而不背離所要求保護的主題的精神和范圍。在RTSP實施例中，將請求插入描述請求的正文內(nèi)。步驟802試圖通過接收該對許可證的請求來建立控制流。該步驟在此示例中由服務器/發(fā)送機實現(xiàn)。響應于接收請求，步驟804可使用流傳送協(xié)議向客戶機/接收機發(fā)送許可證。以上提供了將許可證返回給客戶機/接收機的一個具體示例，其13中向客戶機/接收機發(fā)送了許可證響應消息形式的許可證。可利用其它響應類型或格式，而不背離所要求保護的主題的精神和范圍。此外，以上描述了流傳送協(xié)議的一個示例(即，RTSP)?？衫闷渌鱾魉蛥f(xié)議，而不背離所要求保護的主題的精神和范圍。在RTSP實施例中，響應是用SDP發(fā)送的。可以理解和領(lǐng)會，步驟804也可被實現(xiàn)成向客戶機/接收機發(fā)送更新。在此情況和RTSP示例的上下文中，可使用上述通告請求來傳遞更新。步驟806經(jīng)由流傳送協(xié)議接收許可證。在所示和所述實施例中，該步驟由客戶機/接收機實現(xiàn)。在接收許可證之后，客戶機可根據(jù)許可證中定義的條款來訪問并消費內(nèi)容。以下描述跟隨許可證獲取過程的數(shù)據(jù)流。數(shù)據(jù)流描述了結(jié)合受DRM保護的內(nèi)容利用RTSP的控制流的示例性實施例，現(xiàn)在考慮包含實際受DRM保護的內(nèi)容或允許其通信的數(shù)據(jù)流。在以下描述的實施例中，使用RTP作為數(shù)據(jù)傳送協(xié)議在發(fā)送機和接收機之間傳輸受DRM保護的內(nèi)容。艮P，受DRM保護的內(nèi)容傳輸自發(fā)送機并傳輸至接收機。在提供的特定示例中，描述了兩種不同的方法。在第一種方法中，所利用的RTP有效負荷格式支持擴展，進而允許諸如密鑰ID擴展和初始化向量的加密參數(shù)被包括在RTP分組中，使得經(jīng)加密的有效負荷數(shù)據(jù)可經(jīng)歷解密過程并被解密。在第二種方法中，RTP有效負荷格式不支持擴展。因此，在該方法中，定義了^"述)伊，它與包含經(jīng)加密的有效負荷的RTP分組相關(guān)聯(lián)。描述符包含諸如密鑰ID擴展和初始化向量等可在解密過程中使用來對經(jīng)加密的有效負荷數(shù)據(jù)解密的加密參數(shù)。通過Windows媒體有效負荷格式來承載樣本加密的有效負荷圖9示出了根據(jù)一個實施例、整體在900處的RTP分組的示例性部分。在該實施例中，所利用的RTP有效負荷格式以允許諸如密鑰ID擴展和初始化向量等的加密參數(shù)連同經(jīng)加密的有效負荷內(nèi)容一起被包括在RTP分組中的方式來支持擴展。這樣的格式的一個示例為Windows媒體RTP有效負荷格式，它在http:〃download.microsoft.com/download/5/5/a/55a7b886-b742-4613-8ea8國d8b8b5c27bbc/RTPPayloadFormatforWMAandWMVvl.doc描述。然而，可利用其他格式，而不背離所要求保護的主題的精神和范圍。在該示例中，分組900包括RTP標頭902和有效負荷格式標頭卯4。有效負荷格式標頭在該示例中允許擴展。因此，分組900還包括密鑰ID擴展906和初始化向量908，以及與密鑰ID擴展906和初始化向量908相關(guān)聯(lián)并可用其來解密的經(jīng)加密有效負荷數(shù)據(jù)910(音頻或視頻數(shù)據(jù)中任一)。此外，RTP分組900可包括多個其它經(jīng)加密的有效負荷。在此特定示例中，分組900還包括另一有效負荷格式標頭904a、密鑰ID擴展卯6a、初始化向量908a、以及與密鑰ID擴展906a和初始化向量908a相關(guān)聯(lián)并可用其來解密的經(jīng)加密有效負荷數(shù)據(jù)910a(音頻或視頻數(shù)據(jù)中任一)。在該特定實施例中，一個RTP分組可包含多個不同的經(jīng)加密的有效負荷。作為僅在一個特定上下文中的特定實現(xiàn)示例，結(jié)合Windows媒體音頻和視頻內(nèi)容考慮以下。當承載受上述許可證保護的Windows媒體內(nèi)容時，必須在RTP分組中設(shè)置以下值和字段。1."MAU屬性"部分中位字段(BitField)2中的"加密"位(E)必須被設(shè)置為1。2."MAU定時"部分中"擴展存在"位(X)必須為設(shè)置為1，以指示擴展字段的存在性。3."經(jīng)加密有效負荷邊界"擴展不允許存在。4.必須包括"WMDRM初始化向量"擴展。以下值必須被設(shè)置a."擴展類型"必須被設(shè)置為2。b."擴展長度"必須被設(shè)置為8(意為64位)。c.必須用如以下在題為"樣本加密"的章節(jié)中定義的樣本ID值來設(shè)置"擴展數(shù)據(jù)"。d.必須為每個MAU的第一有效負荷包括該擴展。如果MAU被分成多個有效負荷，則該擴展應僅存在于第一有效負荷中。5.必須包括"WMDRM密鑰ID"。以下值必須被設(shè)置a."擴展類型"必須被設(shè)置為3。b."擴展長度"必須被設(shè)置為16(意為128位)。c.在承載ASF內(nèi)容時必須用來自ASF內(nèi)容加密對象的密鑰ID值來設(shè)置"擴展數(shù)據(jù)"。或者，在承載諸如DVR-MS的非ASF內(nèi)容時，它被設(shè)置為表示所使用的加密密鑰的密鑰ID值。d.必須為每個多有效負荷RTP分組中的第一有效負荷包括該擴展以解決分組丟失問題。15樣本加密作為對以上項目4(C)的進一步解釋，考慮以下。在該實施例中，每一樣本應使用計數(shù)器模式的AES加密。圖IO示出了用于使用該技術(shù)對單個樣本加密的過程。在該實施例中，計數(shù)器模式創(chuàng)建字節(jié)流，這些字節(jié)然后與媒體樣本的明文字節(jié)異或(XOR)以創(chuàng)建經(jīng)加密的媒體樣本。密鑰流生成器使用AES輪來一次生成16字節(jié)塊的密鑰流。對AES輪的輸入為內(nèi)容加密密鑰(Kc)以及樣本ID與樣本內(nèi)塊號的128位級聯(lián)。密鑰流生成器的輸出應與來自媒體樣本的相應塊(i)的數(shù)據(jù)逐個字節(jié)地異或。在媒體樣本未被按16字節(jié)平均劃分的情況中，僅來自最后一塊的媒體數(shù)據(jù)的有效字節(jié)應與密鑰流異或并被保留為經(jīng)加密的樣本。當加密來自ASF文件的樣本時，樣本ID等效于來自有效負荷擴展的樣本ID。因此，在該實施例中，根據(jù)"樣本"邊界來加密和解密數(shù)據(jù)，這些邊界是給定媒體類型的自然邊界，例如視頻流的視頻幀或音頻流的音頻樣本塊。使用數(shù)據(jù)片段描述符通過RTP有效負荷格式來承載鏈路加密的有效負荷圖11示出了根據(jù)另一個實施例、整體在1100處的分組的各個方面。在該示例中，分組1100可包括IP標頭1102、UDP標頭1104、RTP標頭1106、有效負荷格式標頭1108、有效負荷數(shù)據(jù)1110和描述符1112。在該特定示例中，將描述符追加到有效負荷數(shù)據(jù)的尾部，盡管它可被置于任何合適的位置。如本領(lǐng)域的技術(shù)人員可以理解的，將描述符置于有效負荷數(shù)據(jù)的尾部可減輕后向兼容問題。在該實施例中，除RTP標頭以外的RTP分組被視為與描述符1112相關(guān)聯(lián)的數(shù)據(jù)片段來處理。描述符1112又承載了可在能夠解密有效負荷數(shù)據(jù)1110的解密過程中使用的加密參數(shù)。在該特定實施例中，對有效負荷數(shù)據(jù)iiio應用了單個策略和內(nèi)容加密密鑰。根據(jù)一個實施例，描述符1112包括如下的數(shù)據(jù)結(jié)構(gòu):部分字段標志8位標志擴展8位擴展個數(shù)多個可變長度擴展長度數(shù)據(jù)片段描述符長度在該示例中，標志部分為指示數(shù)據(jù)屬性的位字段。當前定義以下值0x01指示經(jīng)加密數(shù)據(jù)。當該標志被置位時，它指示數(shù)據(jù)處于加密形式。否則，該數(shù)據(jù)為明文。對于擴展部分，擴展個數(shù)字段指示包括在該描述符中的可變長度擴展的個數(shù)。對于可變長度擴展字段，每一擴展具有以下格式8位擴展類型16位擴展長度可變長度擴展根據(jù)一個實施例，密鑰ID擴展和數(shù)據(jù)片段ID擴展被如下定義密鑰ID擴展擴展類型對于密鑰ID擴展，必須被設(shè)置為0x01。擴展長度必須被設(shè)置為16，表示28位U6字節(jié))。擴展必須包含同該描述符一起傳遞的經(jīng)加密媒體的密鑰ID值。該擴展僅在加密數(shù)據(jù)標志被置位時才使用。數(shù)據(jù)片段ID擴展擴展類型對于數(shù)據(jù)片段ID擴展，必須被設(shè)置為0x02。擴展長度必須被設(shè)置為8，表示64位(8字節(jié))。擴展必須包含同該描述符一起傳遞的經(jīng)加密媒體的數(shù)據(jù)片段ID值。該擴展僅在加密數(shù)據(jù)標志被置位時才使用。對于長度部分，在該實施例中，該部分必須包含以字節(jié)為單位的數(shù)據(jù)片段描述符的總長度。該長度并不包括同該描述符一起傳遞的媒體數(shù)據(jù)的大小。結(jié)論上述各個實施例利用保護內(nèi)容的各種方法，諸如數(shù)字權(quán)限管理(DRM)來允許在諸如家庭媒體網(wǎng)絡(luò)的局域網(wǎng)內(nèi)的多個機器和設(shè)備上安全地回放內(nèi)容。在至少某些實施例中，經(jīng)由實時流傳送協(xié)議(RTSP)和實時傳輸協(xié)議(RTP)來傳遞消息和內(nèi)容，且引入了協(xié)議擴展，它享受由RTSP/RTP提供的優(yōu)點，包括通過用戶數(shù)據(jù)報協(xié)議(UDP)以及客戶機與服務器之間雙向通信來進行數(shù)據(jù)傳遞。盡管用結(jié)構(gòu)特征和/或方法步驟專用的語言描述了本發(fā)明，但可以理解，所附權(quán)利要求書中定義的本發(fā)明不必限于所述的特定特征或步驟。相反，特定特征和步驟被公開為實現(xiàn)所要求保護的本發(fā)明的優(yōu)選形式。1權(quán)利要求1.一種計算機實現(xiàn)的方法，包括試圖使用用于流傳送的控制協(xié)議來建立用于交換受保護內(nèi)容的控制流數(shù)據(jù)流；以及允許使用數(shù)據(jù)流來傳輸受保護內(nèi)容，其中所述數(shù)據(jù)流使用一傳輸協(xié)議。2.如權(quán)利要求1所述的方法，其特征在于，所述試圖建立控制流的動作包括向被配置成發(fā)送所述受保護內(nèi)容的發(fā)送機發(fā)送許可證請求消息；以及從所述發(fā)送機接收包含一許可證的許可證響應消息。3.如權(quán)利要求1所述的方法，其特征在于，所述試圖建立控制流的動作包括:從被配置成播放所述受保護內(nèi)容的接收機接收許可證請求消息；以及向所述接收機發(fā)送包含一許可證的許可證響應消息。4.如權(quán)利要求l所述的方法，其特征在于，所述試圖建立控制流的動作是使用RTSP實現(xiàn)的。5.如權(quán)利要求4所述的方法，其特征在于，所述試圖建立控制流的動作還包括在RTSP描述請求的正文中向發(fā)送機發(fā)送許可證請求消息；以及從所述發(fā)送機接收包括含有許可證的許可證響應消息的RTSP會話描述協(xié)議(SDP)。6.如權(quán)利要求4所述的方法，其特征在于，所述試圖建立控制流的動作還包括從接收機接收RTSP描述請求的正文中的許可證請求消息；以及向所述接收機發(fā)送包括含有許可證的許可證響應消息的RTSP會話描述協(xié)議(SDP)。7.如權(quán)利要求l所述的方法，其特征在于，所述允許的動作是使用RTP來實現(xiàn)的。8.如權(quán)利要求l所述的方法，其特征在于，還包括在所述受保護內(nèi)容的流傳送期間更新與所述受保護內(nèi)容相關(guān)聯(lián)的策略或格式信息。9.如權(quán)利要求8所述的方法，其特征在于，所述更新的動作包括經(jīng)由所述用于流傳送的控制協(xié)議來發(fā)送更新。10.如權(quán)利要求9所述的方法，其特征在于，所述用于流傳送的控制協(xié)議包括RTSP，且所述更新是經(jīng)由RTSP通告請求來發(fā)送的。11.如權(quán)利要求8所述的方法，其特征在于，所述更新的動作包括經(jīng)由用于流傳送的控制協(xié)議來接收更新。12.如權(quán)利要求U所述的方法，其特征在于，所述用于流傳送的控制協(xié)議包括RTSP，且所述更新是經(jīng)由RTSP通告請求來接收的。13.—種計算機實現(xiàn)的方法，包括使用RTSP來建立用于交換受保護內(nèi)容的控制流；以及允許使用數(shù)據(jù)流來傳送受保護內(nèi)容，其中受保護內(nèi)容是使用RTP封裝的。14.如權(quán)利要求13所述的方法，其特征在于，所述允許的動作包括在包含經(jīng)加密的受保護內(nèi)容的RTP分組中包括可在將所述經(jīng)加密的內(nèi)容解密的解密過程中使用的加密參數(shù)。15.如權(quán)利要求14所述的方法，其特征在于，所述RTP分組可包含多個不同的經(jīng)加密的有效負荷。16.如權(quán)利要求15所述的方法，其特征在于，所述加密參數(shù)包括用于每一經(jīng)加密的有效負荷的密鑰ID擴展和初始化向量。17.如權(quán)利要求13所述的方法，其特征在于，所述允許的動作包括定義包含可在將經(jīng)加密的受保護內(nèi)容解密的解密過程中使用的加密參數(shù)的描述符；以及使所述描述符與所述受保護內(nèi)容相關(guān)聯(lián)。18.如權(quán)利要求17所述的方法，其特征在于，所述關(guān)聯(lián)的動作包括將所述描述符追加在所述RTP分組的尾部。19.如權(quán)利要求17所述的方法，其特征在于，所述經(jīng)加密的受保護內(nèi)容可使用由所述描述符引用的單個密鑰來解密。20.如權(quán)利要求13所述的方法，其特征在于，所述允許的動作還包括在RTSP描述請求的正文中向發(fā)送機發(fā)送許可證請求消息；從接收機接收所述RTSP描述請求的正文中的所述許可證請求消息；向所述接收機發(fā)送包括含有許可證的許可證響應消息的RTSP會話描述協(xié)議(SDP);從所述發(fā)送機接收包括含有所述許可證的所述許可證響應消息的所述RTSP會話描述協(xié)議(SDP)。全文摘要各個實施例利用保護內(nèi)容的各種方法，諸如數(shù)字權(quán)限管理(DRM)，來允許在諸如家庭媒體網(wǎng)絡(luò)等的局域網(wǎng)內(nèi)的多個機器和設(shè)備上安全地回放內(nèi)容。在至少某些實施例中，分別使用用于流傳送的控制協(xié)議和傳輸協(xié)議來傳遞消息和內(nèi)容。在至少某些實施例中，用于流傳送的控制協(xié)議是實時流傳送協(xié)議(RTSP)，而傳輸協(xié)議為實時傳輸協(xié)議(RTP)。文檔編號G06F15/16GK101506790SQ200680024443公開日2009年8月12日申請日期2006年6月22日優(yōu)先權(quán)日2005年7月7日發(fā)明者A·E·克萊門茨,A·帕卡,E·P·奧利弗拉,S·巴哈塔申請人:微軟公司