專利名稱：因特網(wǎng)上用于安全內(nèi)容遞送的密鑰管理協(xié)議與認證系統(tǒng)的制作方法
相關申請交叉引用本申請要求于2001年11月15日提交、題為“KEY MANAGEMENTPROTOCOL AND AUTHENTICATION SYSTEM FOR SECUREINTERNET PROTOCOL RIGHTS MANAGEMENT ARCHITECTURE(用于安全網(wǎng)際協(xié)議權利管理架構的密鑰管理協(xié)議與認證系統(tǒng))”、申請?zhí)枮?0/334,721的美國臨時專利申請，以及于2001年9月26日提交、題為“UNIQUE ON-LINE PROVISIONING OF USER SYSTEMSALLOWING USER AUTHENTICATION(允許用戶認證的用戶系統(tǒng)的獨特的在線供應)”、申請?zhí)枮?9/966,552的美國專利申請的權益；在這里通過引用將其結合進來，如其在本文中一樣，以用于所有目的。本申請涉及下列美國非臨時申請于2001年＿＿提交、題為“KEYMANAGEMENT INTERFACE TO MULTIPLE AND SIMULTANEOUSPROTOCOLS(同時多協(xié)議的密鑰管理界面)”、申請?zhí)枮椋撸叩拿绹鴮＠暾?；?001年＿＿提交、題為“ACCESS CONTROLAND KEY MANAGEMENT SYSTEM FOR STREAMING MEDIA(流媒體的接入控制與密鑰管理系統(tǒng))”、申請?zhí)枮椋撸叩拿绹鴮＠暾?；?001年＿＿提交、題為“ENCRYPTION OF STREAMINGCONTROL PROTOCOLS SUCH AS RTCP AND RTSP AND THEIRHEADERS TO PRESERVE ADDRESS POINTERS TO CONTENT ANDPREVENT DENIAL OF SERVICE(加密流控制協(xié)議，例如RTCP與RTSP，及其報頭，以保護內(nèi)容的地址指針，并防止拒絕服務)”、申請?zhí)枮椋撸叩拿绹鴮＠暾?；以及?001年＿＿提交、題為“ASSOCIATION OF SECURITY PARAMETERS FOR ACOLLECTION OF RELATED STREAMING PROTOCOLSRTP，RTSP，RTCP(用于一組相關流傳輸協(xié)議RTP、RTSP、RTCP的安全參數(shù)關聯(lián))”、申請?zhí)枮椋撸叩拿绹鴮＠暾垼辉谶@里通過引用將其結合進來，如其在本文中一樣，以用于所有目的。
背景技術：
一般地，本發(fā)明涉及數(shù)據(jù)通信領域，更特別地，涉及數(shù)字權利管理功能，其用于在網(wǎng)絡組件間安全地傳輸內(nèi)容。
傳統(tǒng)的用于保障通過通信網(wǎng)絡(例如因特網(wǎng))傳輸?shù)膬?nèi)容的安全性的數(shù)字權利管理系統(tǒng)正變得眾所周知。由于內(nèi)容提供商面臨的一個基本問題是如何防止數(shù)字內(nèi)容的未授權的使用與分發(fā)，需要權利管理系統(tǒng)。內(nèi)容提供商關心從他們的內(nèi)容取得報酬，并從未授權的消費者那里剝奪這些內(nèi)容。
典型地，許多數(shù)字權利管理方案使用數(shù)字內(nèi)容的“加密/解密”來實現(xiàn)。加密是將數(shù)據(jù)轉換到難以理解的形式，例如密文，其難以為未授權的客戶端所理解。解密是將被加密的內(nèi)容轉換回其原始形式，使其變得可以理解的過程。簡單的加密包括字母表內(nèi)的字母旋轉，以字母代替數(shù)字，以及通過轉化邊帶頻率對話音信號進行“擾動”。更復雜的加密按照復雜的計算機算法工作，這些算法重新安排數(shù)字信息內(nèi)容內(nèi)的數(shù)據(jù)比特。
為了容易地恢復被加密的信息內(nèi)容，需要正確的解碼密鑰。該密鑰是加密和解密算法的參數(shù)，其中在加密與解密過程中，密鑰的不同值產(chǎn)生不可預測的不同的結果。密鑰的大小越大，在不知道密鑰時就更難猜中密鑰的值并從而對通信進行解碼。一般地，存在兩種類型的用于加密/解密系統(tǒng)的密鑰方案，也就是(1)PKS(公鑰系統(tǒng))或非對稱系統(tǒng)，其利用兩個不同的密鑰，一個用于加密，或者簽名，一個用于解密，或者驗證；和(2)非公鑰系統(tǒng)，也稱為對稱或密鑰系統(tǒng)，在該系統(tǒng)中，典型地，加密和解密密鑰是相同的。在公鑰與密鑰系統(tǒng)中，使用密鑰管理來分發(fā)密鑰并恰當?shù)卣J證接收密鑰的各方。
一種在MIT開發(fā)的相關技術的密鑰管理系統(tǒng)稱為Kerberos協(xié)議。Kerberos是一種密鑰管理協(xié)議，其允許一方與不同的網(wǎng)絡服務建立共享的會話密鑰，其通過使用KDC(密鑰分發(fā)中心)與票據(jù)的概念。票據(jù)被用于將會話密鑰連同客戶端(該票據(jù)即為該客戶端發(fā)出)的標識安全地傳遞到服務器。票據(jù)可防止篡改，并可被客戶端安全地存儲，從而允許服務器保持無狀態(tài)(stateless)(服務器可在每次客戶端向其傳遞票據(jù)時重學會話密鑰)。這樣，在可支持客戶端數(shù)量方面，票據(jù)的概念改進了服務器的可擴展性。不利地，Kerberos相對地復雜，并包括很多不同的選項，其并不總適用于特定應用。此外，修改這樣一個復雜系統(tǒng)不是一種選擇，這是因為這樣的對不熟悉的系統(tǒng)的修改增加了引入額外錯誤的風險。Kerberos的另一個缺點是它不確定一旦獲取票據(jù)，在客戶端與服務器之間進行密鑰管理的細節(jié)(只提供一些基本的構造部件)。
對在網(wǎng)際協(xié)議(IP)網(wǎng)絡上多媒體內(nèi)容的流分發(fā)的日益增長的興趣導致對密鑰管理系統(tǒng)的日益增長的需要。一種這樣的流分發(fā)系統(tǒng)是加利福尼亞州圣地亞哥的Aerocast公司開發(fā)的Aerocast網(wǎng)絡TM。如參照圖1討論的那樣，盡管現(xiàn)有的第一期Aerocast網(wǎng)絡便利了內(nèi)容的遞送，但它缺乏安全性和用于該網(wǎng)絡的密鑰管理系統(tǒng)。
圖1是(Aerocast的)網(wǎng)絡100的框圖，該網(wǎng)絡用于便利通信網(wǎng)絡上的內(nèi)容的流傳送。除其它組件之外，網(wǎng)絡100包括內(nèi)容提供商102，其生成針對消費者116的內(nèi)容，因特網(wǎng)114，內(nèi)容通過其流傳送，以及中央服務器104，內(nèi)容提供商102向其發(fā)布內(nèi)容。中央服務器104包含數(shù)據(jù)庫108，其用于存儲內(nèi)容信息，以及搜索引擎110，其用于搜索數(shù)據(jù)庫108。網(wǎng)絡100進一步包括供應中心106，以及緩存服務器112、113和115。
在操作中，希望訪問內(nèi)容提供商102的內(nèi)容的消費者116，從最近的緩存服務器(在此情形中，緩存服務器115)流傳送內(nèi)容。在沒有緩存服務器的傳統(tǒng)系統(tǒng)中，需要這樣的內(nèi)容流的消費者116直接從內(nèi)容提供商102獲取內(nèi)容。這不僅導致糟糕的內(nèi)容質(zhì)量，還可能導致與不充分的帶寬相關聯(lián)的延時。通過使用緩存服務器，網(wǎng)絡100避免了與直接從內(nèi)容提供商202流傳送數(shù)字內(nèi)容相關聯(lián)的缺點。例如，緩存服務器112、113與115可以是本地DSL(數(shù)字用戶線)提供商。
網(wǎng)絡100提供了進一步的優(yōu)點。當搜索內(nèi)容時，消費者116無需搜索因特網(wǎng)114上的任何和所有數(shù)據(jù)庫。所有網(wǎng)絡100上的內(nèi)容提供商(包括內(nèi)容提供商102)向單獨的中央數(shù)據(jù)庫108發(fā)布它們的內(nèi)容描述。例如，對于視頻內(nèi)容，該描述可包括電影名稱、演員等等。通過這種方式，當想要內(nèi)容時，消費者116使用搜索引擎110搜索數(shù)據(jù)庫108。當找到內(nèi)容時，數(shù)據(jù)庫108其后提供到具有所要內(nèi)容的內(nèi)容提供商202的鏈接。之后，消費者116訪問內(nèi)容提供商102，以查看更詳細的描述和其它與該內(nèi)容相關聯(lián)的元數(shù)據(jù)。
提供一種機制，由此消費者116將最靠近它的緩存服務器的列表提供給內(nèi)容提供商102。作為對消費者116的請求的響應，內(nèi)容提供商102選擇合適的最靠近消費者116的緩存服務器，以流傳送內(nèi)容。然而，應該觀察到，在今天的Aerocast網(wǎng)絡中，內(nèi)容為網(wǎng)絡100透明地(in the clear)流傳送。不利地，由于未受保護，內(nèi)容可能為未授權的消費者截取，導致內(nèi)容提供商與消費者的實質(zhì)損失。
網(wǎng)絡100的其它不利之處包括缺乏認證、隱私、消息完整性與持續(xù)保護。
因此，存在對解決上述問題的需求，本發(fā)明滿足了這一需求。

發(fā)明內(nèi)容
本發(fā)明涉及一種數(shù)字權利管理架構，其用于向授權消費者安全地遞送內(nèi)容，并用于在各種網(wǎng)絡組件之間安全地傳輸數(shù)據(jù)。
根據(jù)本發(fā)明的第一方面，該架構包括消費者系統(tǒng)，其通過IP(網(wǎng)際協(xié)議)通信網(wǎng)絡連接到內(nèi)容提供商。架構進一步包括KDC(密鑰分發(fā)中心)和緩存服務器，其也連接到通信網(wǎng)絡。授權用戶可能希望訪問來自內(nèi)容提供商的內(nèi)容。用戶采用消費者系統(tǒng)，比方說，以從內(nèi)容提供商URL選擇想要的內(nèi)容。依次地，內(nèi)容提供商向消費者系統(tǒng)提供會話權利對象，該會話權利對象用于訪問請求的內(nèi)容。會話權利對象可包含用戶選擇的購買選項?；蛘?，它可包含內(nèi)容訪問規(guī)則。購買選項刻畫內(nèi)容的特征，也就是它是否是免費的，還是僅供訂閱的，按查看次數(shù)付費的，等等。內(nèi)容訪問規(guī)則的一個例子是指定地理位置之外的區(qū)域不能進行內(nèi)容訪問。
在接收到會話權利對象之后，用戶被重定向到緩存服務器。從該緩存服務器，請求的內(nèi)容被流傳送到用戶。注意用戶可能先前已從KDC獲得緩存服務器票據(jù)。票據(jù)是認證令牌(token)，它可包括客戶端、服務器名、會話密鑰等等。票據(jù)進一步包含授權數(shù)據(jù)，其指示訂閱的服務、用戶支付方式等等。其后，將該票據(jù)和會話權利對象呈現(xiàn)給緩存服務器，其將會話權利對象內(nèi)的用戶選擇和/或內(nèi)容訪問規(guī)則與來自票據(jù)的授權數(shù)據(jù)進行比較。如果信息匹配，內(nèi)容被流傳送到用戶。以這種方式，提供了一種架構，其向授權用戶安全地提供內(nèi)容，而拒絕未授權用戶的訪問。
根據(jù)本發(fā)明的另一方面，教導了一種權利管理架構，其用于向授權用戶安全地遞送內(nèi)容。架構包括內(nèi)容提供商與從內(nèi)容提供商請求內(nèi)容消費者系統(tǒng)。內(nèi)容提供商生成會話權利對象，其具有消費者選擇的購買選項。KDC其后向消費者系統(tǒng)提供授權數(shù)據(jù)。另外，提供緩存服務器，其用于比較購買選項與授權數(shù)據(jù)。如果購買選項匹配授權數(shù)據(jù)，緩存服務器將請求的內(nèi)容轉發(fā)給消費者系統(tǒng)。注意緩存服務器采用實時流來安全地發(fā)送加密的內(nèi)容，并且請求的內(nèi)容被加密，以發(fā)送給消費者系統(tǒng)。進一步地，緩存服務器與消費者系統(tǒng)交換加密的(并且是被認證的)控制消息，以支持傳輸請求的內(nèi)容。以這種方式，組件之間的所有接口受到加密保護和/或認證。
根據(jù)本發(fā)明的另一方面，使用了一種權利管理方法，其用于在緩存服務器上安全地預布置內(nèi)容。該方法包括提供內(nèi)容提供商、緩存服務器與密鑰管理協(xié)議的步驟。該協(xié)議采用多種消息，以安全地傳輸內(nèi)容。一種消息是密鑰請求消息，其由內(nèi)容提供商發(fā)送到緩存服務器。該消息用于初始化密鑰管理的目的。作為對其的響應，密鑰應答消息由緩存服務器發(fā)送到內(nèi)容提供商。在交換密鑰請求/密鑰應答消息之后，建立起一套密鑰，其用于建立從內(nèi)容提供商向緩存服務器的安全內(nèi)容遞送。
根據(jù)本發(fā)明的另一方面，公開了一種協(xié)議，其用于在通信網(wǎng)絡的組件之間保護數(shù)據(jù)傳輸安全。協(xié)議包括提供具有數(shù)據(jù)庫的中央服務器的步驟。接著，從內(nèi)容提供商向中央服務器公布內(nèi)容。進一步地，協(xié)議包括提供記賬中心服務器的步驟，并從緩存服務器向記賬中心服務器報告記賬信息。另外，提供供應數(shù)據(jù)庫，其中數(shù)據(jù)庫使用消費者信息來更新。其后，協(xié)議使用一種密鑰管理協(xié)議，以保護公布到中央服務器的數(shù)據(jù)的安全。另外，當報告記賬信息和更新供應數(shù)據(jù)庫時，數(shù)據(jù)安全受到保護。
有利地，本發(fā)明混合公鑰技術與對稱密鑰方案，在快速獲得時間與最小的代碼復雜度的限制下，獲得了用于內(nèi)容分發(fā)的最好的“軟件”實現(xiàn)的安全性。而且，在本架構下，網(wǎng)絡與服務提供商相互獨立，并且有能力簡便地與特定網(wǎng)絡集成。


圖1是網(wǎng)絡的框圖，該網(wǎng)絡用于便利通信網(wǎng)絡上的內(nèi)容的流傳送。
圖2是IPRM(網(wǎng)際協(xié)議權利管理)系統(tǒng)的框圖，該系統(tǒng)集成ESBrokerTM協(xié)議，以將密鑰管理與安全性應用到圖1的網(wǎng)絡，其遵照本發(fā)明的一個示例性的實施例。
圖3是當消費者(客戶端)向緩存服務器(服務器)發(fā)起密鑰管理時，安全性與密鑰管理協(xié)議的高層流圖，其遵照本發(fā)明的一個示例性的實施例。
圖4是當緩存服務器(服務器)向內(nèi)容提供商(客戶端)發(fā)起密鑰管理時，安全性與密鑰管理協(xié)議的高層流圖，其遵照本發(fā)明的一個示例性的實施例。
圖5是框圖，其描述消費者的初始注冊與內(nèi)容的接收，其遵照本發(fā)明的一個示例性的實施例。
通過參照說明書的余下部分與附圖，可實現(xiàn)對本發(fā)明的本性與優(yōu)點的進一步理解。對本發(fā)明的“步驟”的引用不應被理解為限于“步驟加功能”方法，并且無意指代實現(xiàn)本發(fā)明的特定次序。下面參照所附的附圖詳細地描述本發(fā)明的進一步的特性與優(yōu)點，以及本發(fā)明的各種實施例的結構和操作。在附圖中，相同的引用編號指示同樣的或功能上類似的組件。
具體實施例方式
圖2是IPRM(網(wǎng)際協(xié)議權利管理)系統(tǒng)200的框圖，該系統(tǒng)集成ESBrokerTM協(xié)議，以將密鑰管理與安全性應用到圖1的網(wǎng)絡100，其遵照本發(fā)明的一個示例性的實施例。
除其它組件之外，IPRM系統(tǒng)200包括內(nèi)容提供商202，消費者216，因特網(wǎng)214，供應中心206，中央服務器205(其包含數(shù)據(jù)庫208與搜索引擎210)，緩存服務器212、213與215，所有上述組件的功能與圖1中的對應組件相似。另外，IPRM系統(tǒng)200包括KDC(密鑰分發(fā)中心)204，其包含AS(認證服務器)207(其用于向消費者206發(fā)布TGT(票據(jù)授予票據(jù)))，TGS(票據(jù)授予服務器)209(其用于提供服務器票據(jù)，以訪問特定服務器)，供應服務器220，以及記賬中心211。KDC 204、記賬中心211、供應中心206與中央服務器205均位于中央單元218之內(nèi)，以便利IPRM系統(tǒng)200內(nèi)的服務的供應。
進一步地，IPRM系統(tǒng)200包含IPRM代理202A(其用于為內(nèi)容提供商202管理權利管理)，會話權利對象202B(其用于包含用戶選擇與內(nèi)容規(guī)則)，IPRM代理212A(其用于為緩存服務器212管理權利管理)，IPRM代理213A(其用于為緩存服務器213管理權利管理)，IPRM代理215A(其用于為緩存服務器215管理權利管理)，IPRM代理216A(其用于為消費者216管理權利管理)，以及查看器(未顯示)(其位于消費者216之內(nèi)，用于接收想要的內(nèi)容)。盡管未顯示，前述組件可以位于其相關聯(lián)的組件之內(nèi)。例如，IPRM代理202A可以位于內(nèi)容提供商202之內(nèi)，而不是之外，如所顯示的那樣。
如所注解的那樣，IPRM系統(tǒng)200一般用于便利內(nèi)容以安全的方式流傳送到消費者216，其使用緩存服務器212、213與215。內(nèi)容提供商202僅提供內(nèi)容一次，其后它可被移動到緩存服務器之間。緩存服務器的目的是將內(nèi)容移動到離IPRM系統(tǒng)200的邊沿更近的地方。這改善了流傳送的性能，并且允許更小的內(nèi)容提供商銷售它們的內(nèi)容，而無需購買用于流媒體的昂貴的硬件。這也允許僅在緩存服務器引入IP組播(在網(wǎng)絡上的單個發(fā)送者與多個接收者之間進行通信)。在目前的技術下，將IP組播限制在局域網(wǎng)要比在因特網(wǎng)上進行IP組播更容易。
遵照第一實施例的本發(fā)明通過KDC 204，IPRM代理202A、212A、213A、215A與216A向IPRM系統(tǒng)200提供安全性。IPRM代理和KDC204與供應中心206向IPRM系統(tǒng)200的所有方面提供認證、隱私、完整性與訪問控制工具。例如，在消費者能夠利用系統(tǒng)來流傳送內(nèi)容之前，必須進行注冊過程。IPRM系統(tǒng)200向消費者提供安全注冊。這樣，在注冊過程中，其它人不可能通過截取消費者216與KDC 204之間的消息來復制消費者216的標識。KDC 204是受信任的實體，并向網(wǎng)絡組件提供密鑰分發(fā)，其使用對稱與非對稱算法的混合。這些算法可使用一種或多種軟件指令來實現(xiàn)。或者，它們可在安全加密硬件中提供。
本系統(tǒng)的另一個提供安全性的方面是當內(nèi)容在節(jié)點之間傳輸時，緩存服務器與內(nèi)容提供商202之間的接口。其它提供安全性的方面是緩存服務器的安裝，內(nèi)容從內(nèi)容提供商到緩存服務器的遞送，在緩存服務器之間移動內(nèi)容，使用數(shù)據(jù)的報告，記賬，消費者資料更新，內(nèi)容公布；以及初始消費者簽約。盡管沒有指示，本領域普通技術人員將意識到，還可以保護其它方面的安全，其與本發(fā)明的精神與范圍相一致。
KDC 204與IPRM組件可以是純軟件保護，其對于消費者216給于有限信任，或者可以是硬件安全模塊，對于從要求高安全級別的權利所有者獲取高質(zhì)量內(nèi)容的權利，其可以是強制性的，或者可以是軟件與硬件的組合。IPRM使用一種認證密鑰管理協(xié)議，其具有高可擴展性，可以擴展到以百萬計的用戶。該密鑰管理協(xié)議稱為ESBrokerTM(電子安全性經(jīng)紀人)，是加利福尼亞州圣地亞哥Motorola公司的產(chǎn)品，為本說明書全篇所引用。
ESBrokerTM協(xié)議部分地基于Kerberos框架，其包括客戶端與集中式的密鑰分發(fā)中心(KDC 204)以及各個應用服務器的交互。KDC客戶端是任何主機，其能夠向KDC發(fā)送請求。在IPRM系統(tǒng)之內(nèi)，這包括消費者、緩存服務器與其它IPRM系統(tǒng)組件。應用服務器是任何在KDC上注冊的服務器，客戶端可以要求用于該服務器的服務票據(jù)(例如緩存服務器、記賬中心等等)。
如這里所使用的，票據(jù)是由KDC給予客戶端的認證令牌。除其它信息之外，票據(jù)包含客戶端的名字、特定服務器的名字與會話密鑰(對稱加密密鑰)?？蛻舳嗣峙c會話密鑰需要保密，并用另一個稱為服務密鑰的密鑰加密。服務密鑰是保密密鑰，其僅為KDC和票據(jù)內(nèi)指定的服務器所知。因為客戶端也并不擁有該服務密鑰，它沒有能力解密該票據(jù)并改變其內(nèi)容。正常地，客戶端還需要知道會話密鑰，并且由于它不能從票據(jù)中取得它，KDC向該客戶端發(fā)送同一會話密鑰的單獨的副本。
為了認證帶有票據(jù)(例如ESBroker密鑰請求消息)的消息，客戶端在該消息內(nèi)包括票據(jù)和用于票據(jù)內(nèi)的會話密鑰的校驗和的值。注意票據(jù)內(nèi)的會話密鑰被用服務器的服務密鑰加密。當票據(jù)內(nèi)指定的服務器從客戶端接收到該消息，它能夠用它的服務密鑰解密票據(jù)，驗證客戶端名字并取得會話密鑰。其后，使用會話密鑰來驗證加密的校驗和，從而認證整個消息。
這種基于票據(jù)的認證是Kerberos IETF(因特網(wǎng)工程任務組)標準(RFC 1510)的一部分，并且也為ESBroker協(xié)議利用。本領域技術人員也理解，可以采用基于其它標準的其它認證技術。票據(jù)可以有其它信息，包括有效期(開始時間與過期時間)、各種標記、客戶授權數(shù)據(jù)等等。授權數(shù)據(jù)字段可包含訂閱的服務、地理位置、用戶支付方式以及與用戶授權相關的其它數(shù)據(jù)。
同一主機在同一時間可以既是KDC客戶端，又是應用服務器。對于IPRM系統(tǒng)200，協(xié)議采用了一系列消息，以實現(xiàn)系統(tǒng)的客戶端與服務器接口之間的密鑰管理。該密鑰管理協(xié)議被設計為通用于建立安全會話，而不是局限于IPRM系統(tǒng)。這些消息列于下面的表1，并在題為IPRM協(xié)議消息的小節(jié)中進一步地描述。
表1


在操作中，客戶端與服務器之間的密鑰管理過程分為兩個階段(1)通用階段，其中客戶端與KDC 204保持聯(lián)系，以獲取服務器票據(jù)訪問服務器；和(2)非通用階段，其中客戶端使用服務器票據(jù)，以形成給服務器的KEY_REQ(密鑰請求)消息。在非通用階段中，DOI(解釋域)對象包含信息，其特定于通用ESBroker密鑰管理協(xié)議的特定應用(例如特定于IPRM系統(tǒng))。例如，在消費者216(客戶端)與緩存服務器215(服務器)之間的密鑰管理過程中，通用階段涉及消費者216從KDC 204獲取服務器票據(jù)，以訪問緩存服務器215。非通用過程涉及使用服務器票據(jù)來生成KEY_REQ消息，以訪問緩存服務器215，其中KEY_REQ包含DOI對象，其包含會話權利，會話權利包含用戶選擇以及(可選地)內(nèi)容規(guī)則。典型地，比如說，內(nèi)容規(guī)則可以是對特定地理區(qū)域的限制。需要注意的是，內(nèi)容規(guī)則一般適用于所有用戶。進一步地，協(xié)議中使用哪個消息取決于密鑰管理由客戶端還是服務器發(fā)起。如果服務器發(fā)起，則除其它消息之外，還可以采用TKT_CHALLENGE(票據(jù)詢問)消息，如參照圖4所更清晰地顯示的那樣。
圖3是當消費者216(客戶端)向緩存服務器215(服務器)發(fā)起密鑰管理時，安全性與密鑰管理協(xié)議的高層流圖，其遵照本發(fā)明的一個示例性的實施例。
如所顯示的那樣，希望從緩存服務器215以安全的方式流傳送內(nèi)容的消費者216發(fā)起密鑰管理過程。這通過向KDC 204發(fā)送AS_REQ消息，以獲取用于TGS服務器209的TGT(票據(jù)授予票據(jù))來做到。AS_REQ消息包含消費者216的標識，KDC 204的標識，更特定地，KDC領域或管理域，以及不重性(nonce)，以將其與響應聯(lián)系起來。它還可包含對稱加密算法列表，其為消費者216所支持。當然，做出了這樣的假設，消費者216與緩存服務器215均已通過KDC 204注冊，KDC 204作為受信任的認證者，能夠驗證兩個節(jié)點的標識。
如所顯示的那樣，作為對AS_REQ消息的響應，KDC 204驗證TGT請求，與供應服務器220檢查消費者216的有效性，并在其后響應以包含TGT的AS_REP消息。需要注意的是，TGT的私密部分被用KDC204的服務密鑰加密，該密鑰僅為KDC 204所知。同一KDC 204服務密鑰也被用于認證包含加密的哈希值的TGT。由于消費者216不知道KDC 204服務密鑰，它不能修改它，也不能讀取票據(jù)的私密部分。因為消費者216在其后到KDC 204的認證中仍然需要知道會話密鑰，使用密鑰協(xié)議算法(例如，橢圓曲線Diffie-Hellman)向消費者216遞送會話密鑰的另一份副本。
在接收和存儲TGT之后，消費者216準備開始請求網(wǎng)絡上的流內(nèi)容。向KDC 204(TGS服務器209)發(fā)送包含TGT的TGS_REQ消息，以從緩存服務器215請求票據(jù)。需要注意的是，消費者216可以進行額外的供應行動，例如訂制特定的內(nèi)容提供商。另外，消費者216可以創(chuàng)建偏好的緩存服務器的列表。
作為對TGS_REQ消息的響應，從KDC 204向消費者216發(fā)送TGS_REP消息，其具有緩存服務器票據(jù)。如果存在另外的偏好的緩存服務器，消費者216可使用TGT來聯(lián)系KDC 204，以獲取用于偏好的緩存服務器的緩存服務器票據(jù)。這些緩存服務器票據(jù)之后可被緩存，以備將來之用。否則，在從適當?shù)木彺娣掌髡埱髢?nèi)容時獲取緩存服務器票據(jù)。
對于一些消費者而言，在發(fā)布緩存服務器票據(jù)之前，KDC 204首先需要向供應服務器220查詢訂閱者授權數(shù)據(jù)。這通過在KDC 204和供應服務器220之間交換AUTH_DATA_REQ/AUTH_DATA_REP來完成。用戶授權數(shù)據(jù)可插入到票據(jù)。緩存服務器票據(jù)具有與TGT相同的格式，它包括會話密鑰，用于到緩存服務器215的認證。票據(jù)的私密部分被用緩存服務器215的服務密鑰加密，該密鑰僅為它和KDC 204所知。票據(jù)也用哈希值認證，該哈希值使用同一服務密鑰加密。如TGT的情形那樣，消費者216不能修改該票據(jù)。消費者216需要來自緩存服務器票據(jù)的會話密鑰，以向服務器認證自己。該會話密鑰的一份副本被遞送給消費者216，其被用TGT會話密鑰加密。
從AS_REQ消息開始到TGS_REP消息的過程對應于上面標注的通用階段，其中客戶端與KDC 204聯(lián)系，以獲取服務器票據(jù)，以訪問服務器。因為它是通用的，同一過程被用于保護其它接口，包括從內(nèi)容提供商到緩存服務器的內(nèi)容遞送；使用報告；記賬，等等。進一步地，這導致更安全的IPRM系統(tǒng)，而無需不必要的或復雜的選項。而且，由于復雜度的減小，問題被迅速地鑒別和矯正。
在接收包含緩存服務器票據(jù)的TGS_REP消息時，向緩存服務器215發(fā)送包含該票據(jù)的KEY_REQ消息。除緩存服務器票據(jù)之外，KEY_REQ消息包含消息的MAC(消息認證代碼)，DOI(解釋域)對象與時間戳。DOI對象用于攜帶與該安全會話相關聯(lián)的應用特定的信息。在本實施例中，DOI對象包含用于消費者216的會話權利信息。會話權利由內(nèi)容提供商202提供。將會話權利封裝到DOI對象的原因在于會話權利特定于(包含緩存服務器的)本特定內(nèi)容遞送架構，而ESBroker協(xié)議提供通用密鑰管理服務。ESBroker可以應用到其它類型的安全會話，其應用特定的信息也封裝在DOI對象之中。
當緩存服務器215接收到通用KEY_REQ消息時，它提取出非通用的DOI對象。緩存服務器215之后檢查，比如說，用于流傳送的應用特定的代碼，驗證DOI對象和授權信息。如果會話權利匹配票據(jù)內(nèi)的授權數(shù)據(jù)，則向消費者216轉發(fā)包含會話密鑰的KEY_REP消息。注意，授權數(shù)據(jù)來自票據(jù)，且會話權利對象包含用戶選擇和/或內(nèi)容規(guī)則。將用戶選擇與授權數(shù)據(jù)和內(nèi)容規(guī)則進行比較。如果內(nèi)容規(guī)則不在會話權利對象之內(nèi)，緩存服務器必然是業(yè)已使用某種其它方法從內(nèi)容提供商取得它們。進一步地，可能有一些內(nèi)容規(guī)則來自其它來源，例如電纜提供商。
當會話權利匹配授權數(shù)據(jù)時，從這一點開始，兩邊都具有協(xié)議密鑰，并且能夠開始加密它們的最終消息，例如流內(nèi)容。如果授權失敗，則向消費者轉發(fā)錯誤消息。需要注意的是，在一些實例中，KEY_REP消息包含通用DOI對象，其中緩存服務器215需要向消費者216返回某些應用特定的信息。例如，在IPRM系統(tǒng)中，當緩存服務器向內(nèi)容提供商發(fā)送票據(jù)詢問，以請求安全會話時，會話ID在晚些時候由緩存服務器提供于KEY_REP消息內(nèi)的DOI對象之內(nèi)。票據(jù)詢問消息是未經(jīng)認證的，因此不包含DOI對象。
此階段(KEY_REQ/KEY_REP)對應于非通用階段，其中客戶端使用服務器票據(jù)來形成給服務器的密鑰請求。此階段是非通用的，這是因為DOI對象隨受保護的接口而變化。例如，涉及自內(nèi)容提供商向緩存服務器遞送內(nèi)容的DOI對象與用于從緩存服務器向訂閱者遞送同一內(nèi)容的DOI對象不同。
圖4是當緩存服務器215(服務器)向內(nèi)容提供商202(客戶端)發(fā)起密鑰管理時，安全性與一種可能的密鑰管理協(xié)議的高層流圖，其遵照本發(fā)明的一個示例性的實施例。注意，緩存服務器也可以使用密鑰請求消息來與內(nèi)容提供商發(fā)起密鑰管理，如圖3所示。圖4所示的方法提供了對服務器發(fā)起的密鑰管理的優(yōu)化，消除了服務器獲取然后緩存潛在大量的客戶端票據(jù)的需要。
當接收到對內(nèi)容的請求，并且緩存服務器215沒有所請求的內(nèi)容時，緩存服務器215發(fā)起密鑰管理。如所顯示的那樣，可通過從緩存服務器215向內(nèi)容提供商202發(fā)送TKT_CHALLENGE(票據(jù)詢問)消息來發(fā)起密鑰管理。TKT_CHALLENGE供服務器使用，以引導客戶發(fā)起密鑰管理。
在決定框224，如果內(nèi)容提供商202有先前獲得的緩存服務器票據(jù)，它向緩存服務器215轉發(fā)包含該票據(jù)的KEY_REQ消息。作為響應，緩存服務器215發(fā)送KEY_REP消息，如上面先前所討論的那樣。另一方面，返回決定框224，如果內(nèi)容提供商202沒有緩存服務器票據(jù)，也沒有TGT，它向KDC 204發(fā)送AS_REQ消息，KDC 204答復以AS_REP消息。如果內(nèi)容提供商有其TGT，則跳過AS_REQ/REP。
其后，內(nèi)容提供商202向KDC 204發(fā)送TGS_REQ消息，并接收包含緩存服務器票據(jù)的TGS_REP消息。當?shù)玫骄彺嫫睋?jù)時，內(nèi)容提供商202發(fā)送KEY_REQ消息，在此情形中，其不含DOI對象。會話ID可以在應答或請求或兩者之內(nèi)；會話權利不適用，因為內(nèi)容提供商202與緩存服務器215都不是消費者。一旦建立起共享密鑰，內(nèi)容提供商202向緩存服務器215發(fā)送SEC_ESTABLISHED消息(未顯示)。由于服務器發(fā)起密鑰管理，SEC_ESTABLISHED消息通知服務器安全性已建立。
有利地，應該觀察到的是，同樣的消息，也就是TKT_CHALLENGE、AS_REQ/AS_REP、TGS_REQ/TGS_REP、KEY_REQ/KEY_REP、SECURITY_ESTABLISHED，被用在多個協(xié)議與場景內(nèi)，其取決于由客戶端還是服務器發(fā)起密鑰管理。如果服務器請求密鑰管理，則可以使用所有消息，包括TKT_CHALLENGE消息。反之，如果客戶端發(fā)起密鑰管理，則采用除TKT_CHALLENGE之外的所有消息。應該觀察到的是，當客戶端發(fā)起密鑰管理時，也常常跳過安全性建立消息。有利地，由于在所有接口上利用單個密鑰管理協(xié)議，更易于分析系統(tǒng)是否安全。另外，系統(tǒng)使用同樣的密鑰管理來保護流內(nèi)容與非流內(nèi)容，包括記賬數(shù)據(jù)，僅對DOI對象字段有所變化。
圖5是框圖，其描述消費者216的初始注冊與內(nèi)容的接收，其遵照本發(fā)明的一個示例性的實施例。
希望從緩存服務器215接收內(nèi)容的新消費者216可以與中央單元218初始地簽約。
在框502，消費者216使用網(wǎng)頁瀏覽器來訪問中央單元218提供的網(wǎng)站(未顯示)。消費者216來到初始簽約與軟件下載頁面，下載并安裝查看器應用程序，包括任何IPRM組件。作為另一種可供選擇的方案，查看器應用程序與IPRM組件可以使用可移除式介質(zhì)，例如CD-ROM，分發(fā)給消費者。
在框504，消費者216啟動查看器，以發(fā)起到供應服務器220的SSL(安全套接字層)會話。使用中央單元218證書(未顯示)來發(fā)起會話。證書是消費者216先前獲取的簽名的中央單元218的公鑰。在SSL會話開始后，消費者216填寫初始簽約表單，其包括用于用戶ID的表單?；蛘?，用戶ID可由中央單元自動分配。消費者216接著確定本地主機標識符，并將它以及其它信息發(fā)送給供應服務器220。(這由查看器透明地完成)。
在框506，供應服務器220提取出用戶ID，并將其轉換為ESBrokerTM當事人名字。當事人名字是唯一地命名的消費者或服務器實例，其參與IPRM系統(tǒng)200。在此情形中，查看器當事人名字與分配給該查看器的訂閱者ID相同。在將用戶ID轉換為ESBrokerTM當事人名字之后，供應服務器220向KDC 204發(fā)送命令，以在KDC 204數(shù)據(jù)庫(未顯示)中生成新的ESBrokerTM當事人。該命令也包括消費者主機標識符。
在框508，KDC 204為消費者216生成包含供應密鑰(會話密鑰)的供應票據(jù)。在本發(fā)明的一個實施例中，供應密鑰可以是對稱密鑰。KDC 204使用供應密鑰來認證其自身與消費者216之間的消息。其后，將供應票據(jù)以及SKS(會話密鑰種子)返回給供應服務器220。由于消費者216不能訪問供應密鑰(其被使用KDC 204密鑰加密)，消費者216使用SKS來重構位于供應票據(jù)之內(nèi)的供應密鑰。
在框510，除供應票據(jù)之外，消費者216下載配置參數(shù)，包括用戶ID、票據(jù)過期時間(已包含在票據(jù)的未加密部分)、KDC 204名字和/或地址等等，以及(可選地)軟件組件，包括ESBrokerTM守護進程。應該觀察到的是，軟件組件可能已在本注冊過程之前下載，如Aerocast網(wǎng)絡中的情形那樣。之后，SSL連接被終止。
在框512，ESBrokerTM守護進程被使用下載的配置參數(shù)初始化。
在框514，生成公鑰/私鑰對，用于認證消費者216與KDC 204之間的AS_REQ消息。公鑰從消費者216轉發(fā)到KDC 204。這通過使用CLIENT_ENROLL_REQ消息來實現(xiàn)。該消息包含公鑰，消費者216使用派生自SKS的供應密鑰對其(對稱地)簽名。由于不能訪問供應票據(jù)內(nèi)的供應密鑰，消費者216使用單向函數(shù)從SFS派生出供應密鑰。向軟件客戶端分發(fā)票據(jù)與供應密鑰的問題在于軟件客戶端可能拷貝票據(jù)與密鑰，以轉發(fā)給未授權的軟件客戶端。為解決這一問題，消費者216接收SKS，而不是實際的供應密鑰。聯(lián)合SKS與獨特的主機標識符使用單向方程生成供應密鑰。SKS特定于特定主機，不能用于其它任何地方。在本實施例中，消費者216執(zhí)行下面的函數(shù)來重新產(chǎn)生供應密鑰Provisioning key＝SKGen-1(Host ID，SKS)其中SKGen-1()是單向函數(shù)；SKGen-1()不可能在合理的時間之內(nèi)(例如在小于票據(jù)生命期的時間內(nèi))計算出來。
在框516，當接收到CLIENT_ENROLL_REQ消息時，KDC 204在其本地數(shù)據(jù)庫內(nèi)查找消費者216，以驗證該請求。如果請求有效，KDC 204將公鑰存儲到客戶端數(shù)據(jù)庫內(nèi)，其可以位于KDC本地，或者存儲到可安全訪問的某個其它的遠程位置。作為另一種可供選擇的方案，KDC 204可使用公鑰生成證書，以轉發(fā)給消費者216。之后，向消費者216轉發(fā)CLIENT_ENROL_REP消息，其確認密鑰已被存儲(或者，作為另一種可供選擇的方案，其包含客戶端證書)。
在框518，消費者216現(xiàn)已登記，并且可以聯(lián)系網(wǎng)站(未顯示)，網(wǎng)站包含數(shù)據(jù)庫208，具有一系列來自各個提供商(包括內(nèi)容提供商202)的內(nèi)容。當查找到想要的內(nèi)容時，消費者216被重定向到內(nèi)容提供商202。
在框520，消費者216然后聯(lián)系被重定向到的內(nèi)容提供商202，并傳送其偏好的緩存服務器列表、訂閱服務列表、其支付內(nèi)容的能力等等。
在框522，內(nèi)容提供商202提供購買選項的優(yōu)化子集，其依賴于特定消費者與服務的前后關系。例如，對于已訂閱該服務的消費者，可以繞過價格選擇屏幕。
在框524，內(nèi)容提供商202生成會話權利對象，其封裝消費者216選擇的購買選項，可選的內(nèi)容訪問規(guī)則(例如管制區(qū)域)的集合和對所選內(nèi)容的引用。例如，當消費者216從內(nèi)容提供商請求這些會話權利時，消費者216生成的會話ID，其為隨機數(shù)。會話權利對象可能具有結束時間(在該時間之后，這些會話權利不再有效)，提供商ID，等等?？蛇x地，會話權利對象可包含內(nèi)容規(guī)則。作為另一種可供選擇的方案，這些規(guī)則可使用某種帶外方法遞送給緩存服務器。
在框526，內(nèi)容提供商202將消費者216重定向到適當?shù)木彺娣掌?。在此情形中，?nèi)容將流傳送自離消費者216最近的緩存服務器215。如果簽約時消費者216先前已緩存用于緩存服務器215的緩存服務器票據(jù)，則它重新得到該票據(jù)。如果沒有緩存的票據(jù)，它使用TGT聯(lián)系KDC 204，以獲取正確的緩存服務器票據(jù)。
在框528，消費者216使用緩存服務器票據(jù)向緩存服務器215認證自己，同時(在同一KEY_REQ消息內(nèi))向緩存服務器215轉發(fā)自內(nèi)容提供商202獲取的會話權利對象。消費者216與緩存服務器215之間的通信使用上述KEY_REQ/KEY_REP消息來完成。
在框530，緩存服務器215將會話權利對象內(nèi)的訪問規(guī)則與票據(jù)內(nèi)包含的消費者216的權利以及會話權利對象內(nèi)的用戶選擇(消費者選擇的購買選項)進行核對。權利基本上是特定于消費者216的授權數(shù)據(jù)，其允許對內(nèi)容的訪問。內(nèi)容訪問規(guī)則集是可選的，這是因為它可以與內(nèi)容一起直接遞送到緩存服務器215。進一步地，緩存服務器215能夠可選地從多個來源收集額外的內(nèi)容訪問規(guī)則。例如，接入網(wǎng)絡提供商(例如電纜系統(tǒng)運營商)可能對通過其網(wǎng)絡的遞送施加某些限制。
在框532，如果訪問被批準，消費者216與緩存服務器215協(xié)商內(nèi)容加密密鑰(CEK)，其用于內(nèi)容的遞送。
在框534，消費者216開始向緩存服務器215發(fā)布加密的RTSP命令，以取得內(nèi)容的描述(RTSP URL)，并于其后請求播放該內(nèi)容。
在框536，緩存服務器215接收RTSP命令，將其解碼并返回加密的RTSP響應。當RTSP命令請求播放特定URL時，緩存服務器215驗證該特定URL是會話權利對象為該安全會話(由會話ID標識)所指定者。
在框538，在接收到播放RTSP URL的請求之后，緩存服務器215開始發(fā)送加密的RTP分組，并且緩存服務器215與消費者216均周期性地發(fā)送加密的RTCP報告分組。與同一RTSP URL相關聯(lián)的全部RTP與RTCP分組使用同一會話ID加密，該會話ID在緩存服務器215開始從消費者216接收加密的RTSP消息時錄制。
在框540，消費者216解密并播放內(nèi)容。同時，消費者216可發(fā)布額外的RTSP命令(例如暫?；蚧謴筒シ艃?nèi)容)，其仍使用同一會話ID加密。緩存服務器215保持跟蹤誰查看了內(nèi)容，內(nèi)容被查看了多長時間，內(nèi)容以何種機制被購買。該信息之后被用于記帳目的，無論其被引導到消費者216還是廣告者。有利地，本系統(tǒng)允許在來自各個提供商的多個內(nèi)容之間容易地轉換，而只需輸入一次記賬信息，例如信用卡號。當請求內(nèi)容時，關于消費者的信息被透明地傳輸給內(nèi)容提供商。消費者體驗是相對地容易的，這是由于無需記住多個訪問代碼。
公布內(nèi)容當內(nèi)容提供商202想要將內(nèi)容公布到中央服務器205時，使用與上面所述相同的協(xié)議步驟。例如，中央服務器205建立與內(nèi)容提供商202的安全聯(lián)系，向它發(fā)送KEY_REQ消息，繼之以KEY_REP，如上面所描述的那樣。
在緩存服務器之間遞送內(nèi)容要求內(nèi)容的緩存服務器通過提供源緩存服務器票據(jù)來發(fā)起認證與密鑰遞送過程。如果它尚未處理該票據(jù)，它使用其TGT從KDC 204請求它。
報告記賬數(shù)據(jù)當KDC 204發(fā)布消費者216用于緩存服務器(也就是緩存服務器215)的服務票據(jù)時，它向該票據(jù)添加消費者授權數(shù)據(jù)，例如訂閱數(shù)據(jù)與許可的購買選項。基于消費者216授權數(shù)據(jù)和由內(nèi)容提供商202生成并由消費者216轉發(fā)的安全對象，緩存服務器215將向消費者216授予對內(nèi)容的訪問權限，并記錄使用與購買信息。周期性地，緩存服務器將聯(lián)系記賬中心211，以報告記賬信息。緩存服務器將使用記賬中心票據(jù)向記賬中心認證自己。一旦完成認證，緩存服務器將記錄的記賬信息安全地傳輸給記賬中心211。記賬中心211可從供應中心維護的消費者數(shù)據(jù)庫重新得到消費者數(shù)據(jù)(記賬地址、信用卡等等)。中央單元218可通過協(xié)同定位的記賬系統(tǒng)來記賬，或者與居于本地網(wǎng)絡運營商或內(nèi)容提供商站點的記賬系統(tǒng)協(xié)調(diào)。
緩存服務器的初始安裝一般地，緩存服務器215使用與上面所述相類似的機制取得供應，除了SERVICE_KEY_REQ/SERVICE_KEY_REQ之外，其用于初始地獲取以及其后更新它的服務密鑰。這允許自動地按時間表更新服務密鑰，從而降低了特定服務密鑰受到危害的機會。
流內(nèi)容與非流內(nèi)容有兩種基本類型的受保護內(nèi)容流內(nèi)容與非流內(nèi)容。使用下面的協(xié)議來遞送實際的流內(nèi)容或與該內(nèi)容相關的信息流內(nèi)容RTP(實時協(xié)議)/RTCP(實時控制協(xié)議)、RTSP(實時流協(xié)議)。內(nèi)容在服務器之間的非流傳輸流描述包含SDP(會話描述協(xié)議)的RTSP。其它非流內(nèi)容HTTP(供應，發(fā)布到目錄的內(nèi)容)；基于TCP(傳輸控制協(xié)議)或UDP(用戶數(shù)據(jù)報協(xié)議)的定制協(xié)議(內(nèi)容使用報告)。流內(nèi)容。在基于標準的系統(tǒng)中，典型地，流內(nèi)容使用RTP遞送。本IPRM系統(tǒng)中還可保護另外的專有流協(xié)議，例如Real與Microsoft的WindowsMedia。
RTP安全服務實現(xiàn)了認證、加密與消息完整性，以確保未授權方不能查看付費內(nèi)容。
RTP加密機制每個媒體RTP分組均被加密，以保證隱私。兩個端點有能力協(xié)商出特定的加密算法，如由系統(tǒng)配置定義并由服務器控制的那樣。加密適用于分組的有效載荷。RTP報頭具有RFC-1889格式。頭十二個字節(jié)出現(xiàn)于每個RTP分組，而CSRC標識符列表僅在被混合器插入時才出現(xiàn)。
RTP分組編碼可使用下面的過程編碼每個分組發(fā)送方為該分組查找會話ID。查找可基于SSRC(RTP同步源)或目的IP地址與UDP端口。(在點到點遞送的情形中，會話ID為隨機數(shù)，在該連接的兩個端點上均唯一)。依次地，會話ID標識用于加密該分組的安全參數(shù)集。這些參數(shù)是(1)EKRTP加密密鑰。該加密密鑰僅用于加密一個方向上的通信(例如總是從緩存服務器到其消費者216)。在IPRM系統(tǒng)中，存在雙向RTP會話，因此每個會話僅有一個RTP加密密鑰。(2)16字節(jié)初始化矢量(IV)。在第一方面，分組主體(不包括RTP報頭)使用所選的CBC模式中的塊密碼來加密。在一個實施例中，使用AES(高級加密標準)密碼。AES操作于128比特塊。如果最后的塊比它短，可使用特殊處理來加密它，稱為RBT(殘留塊終止)。
RTP分組解碼使用下面的過程解碼每個分組接收方為該分組查找會話ID。查找可基于SSRC(RTP同步源)或源IP地址與UDP端口。(在點到點遞送的情形中，會話ID為隨機數(shù)，在該連接的兩個端點上均唯一)。依次地，會話ID標識用于解密該分組的安全參數(shù)集。這些參數(shù)是EKRTP加密密鑰；初始化矢量(IV)，其使用單向函數(shù)自RTP分組報頭派生。應該觀察到的是，由于每個RTP分組報頭包含不同的序列號或時間戳，導致每個分組有唯一的IV。
RTCP分組編碼編碼的RTCP分組包含原始的加密的RTCP分組加上一些另外的字段●安全會話標識符●分組序列號●IV(初始化矢量)，僅在所選加密算法是CBC模式(密碼塊鏈)的塊密碼時需要●MAC消息認證代碼，以提供消息完整性使用下面的過程編碼每個分組使用源IP地址與UDP端口來為該分組查找會話ID。(在點到點遞送的情形中，會話ID為隨機數(shù)，在該連接的兩個端點上均唯一)。依次地，會話ID標識用于加密該分組的安全參數(shù)集。這些參數(shù)是EK媒體流加密密鑰(與RTP相同)，KMAC消息認證密鑰。
接著，確定序列號。對于第一個使用當前安全參數(shù)發(fā)送的RTCP消息，它是0，此后遞增1。接著，生成隨機初始化矢量(IV)，其大小與密碼塊大小相同。接著，使用所選的CBC模式的塊密碼來加密RTCP消息。目前，可使用AES密碼。AES操作于128比特塊。如果最后的塊比它短，可使用特殊處理來加密它，稱為RBT(殘留塊終止)。其后，裝配除MAC之外的編碼的RTCP消息，并且計算RTCP消息的MAC，并將其添加到相同的消息。
RTCP分組解碼使用下面的過程解碼每個分組使用報頭內(nèi)的會話ID來查找安全參數(shù)集，以解密該分組。這些參數(shù)是EK媒體流加密密鑰(與RTP相同)KMAC消息認證密鑰。計算編碼消息的MAC，不包括MAC字段自身。驗證計算出的MAC與編碼消息內(nèi)的值匹配。如果它們不匹配，中止進一步的解碼并報告錯誤。驗證序列號，如下面的子節(jié)中指定的那樣。如果驗證失敗，消息被作為重播而拒絕。使用所選的CBC模式的塊密碼來解密加密的RTCP消息。用于該消息的IV被包含在編碼消息之中。
序列號驗證有兩種情形的序列號驗證當消息通過UDP接收時和當它通過TCP接收時。盡管RTCP消息始終通過UDP發(fā)送，同樣的消息解碼規(guī)則適用于RTCP之外的協(xié)議。
對通過TCP發(fā)送的應用消息的序列號驗證接收的消息的序列號比先前接收的消息的序列號大。當序列號比先前的消息增加超過一時，接收者接受消息。(如果接收者的內(nèi)部緩沖區(qū)上溢，丟失某些尚未處理的進來的消息，這一情況就可能發(fā)生。)對通過UDP發(fā)送的應用消息的序列號驗證使用滑動窗口協(xié)議來驗證序列號滑動窗口的大小W取決于UDP傳輸?shù)目煽啃?，并在每個端點本地配置。參數(shù)W可以是32或64。滑動窗口的最有效率的實現(xiàn)是使用比特掩碼與比特移位操作。在接收者處理來自安全會話的UDP流內(nèi)的第一分組之前，滑動窗口內(nèi)的第一序列號被初始化為0，最后一個為W-1。所有窗口之內(nèi)的序列號在第一次(出現(xiàn))時被接收，但在重復時被拒絕。所有比窗口的“左”邊沿更小的序列號被拒絕。當接收到的受認證的分組的序列號比窗口的“右”邊沿更大時，接受該序列號，并且以該序列號替代窗口的“右”邊沿。更新窗口的“左”邊沿，以維持同樣的窗口大小。當對于窗口(SRIGHT-W+1，SRIGHT)，接收到序列號SNEW，并且SNEW＞SRIGHT，則新窗口變?yōu)?SNEW-WRTCP+1，SNEW)RTSP編碼如果編碼的RTSP消息直接為代理接收，其立刻解碼它們，則它們可以以二進制格式編碼。然而，如果RTSP消息由某個中間HTTP接力代理轉發(fā)，它們可以以可打印的ASCII編碼。RTSP消息的二進制編碼與RTCP消息的編碼相同。在要求可打印的ASCII編碼的情形中，然后對RTSP的二進制編碼進行基-64(base-64)編碼。以如下方式編碼RTSP分組使用與RTCP分組相同的過程來創(chuàng)建二進制編碼。如果要求可打印的ASCII，對二進制編碼進行基-64編碼。在基-64編碼的每80個字符后插入<CR><LF>。如果最后一行少于80個字符長，在末尾添加另一個<CR><LF>。
RTSP消息解碼以如下方式解碼每個編碼的RTSP消息如果RTSP消息是基-64編碼，首先去處<CR><LF>字符，并將ASCII消息基-64解碼為二進制編碼。解碼二進制編碼，其與上面用于RTCP分組的(過程)完全相同。在某些情形中，要求客戶端(例如查看器)獲取會話權利，以從第三方(原始服務器)接收該內(nèi)容。在這些情形中，客戶可將其對于該內(nèi)容的會話權利置于密鑰請求消息內(nèi)的DOI對象之內(nèi)來傳遞。對于點到點的遞送，一般使用RTSP協(xié)議自身來請求以RTSP URL標識的特定內(nèi)容的流傳送。RTSP客戶端軟件應該驗證以安全RTSP消息請求的RTSP URL確實對應于與該安全會話(其以會話ID標識)相關聯(lián)的會話權利內(nèi)的RTSP URL。
IPRM協(xié)議消息下面是對表1內(nèi)列出的協(xié)議消息的進一步討論。
消息AS_REQ消息AS_REQ被發(fā)送到ESBrokerTM認證服務器(KDC 204)，以獲取票據(jù)授予票據(jù)，KDC客戶端使用其來從服務器請求票據(jù)。消息包含客戶端的標識、服務器的標識以及該客戶端支持的對稱加密算法的列表。為了核對重播，該消息也包含時間戳。提供簽名，以保證消息的完整性。簽名可以是加密的校驗和(例如HMAC)或者數(shù)字簽名。數(shù)字證書可選地可以包括在該消息中，并且可以替代保存的公鑰，在后面的階段中驗證數(shù)字簽名。用于驗證加密的校驗和的客戶端的永久對稱密鑰可保存于同一用戶數(shù)據(jù)庫內(nèi)。消息也包括公鑰信息，其為密鑰協(xié)定所必需(例如橢圓曲線Diffie-Hellman參數(shù))。
消息AS_REPAS_REP由KDC 204生成，以響應AS_REQ。KDC 204在數(shù)據(jù)庫內(nèi)查找服務器與客戶端的密鑰，并生成會話密鑰，以用于KDC 204其后的認證。KDC 204生成票據(jù)授予票據(jù)，其具有明文與加密部分。TGT內(nèi)的服務器的標識必須始終是‘KDC’(無引號)，并且KDC領域在AS_REQ消息的服務器領域(Srealm)字段中單獨列出。服務器的標識與票據(jù)有效期在發(fā)出的票據(jù)內(nèi)的明文中提供。票據(jù)的加密部分包含客戶端的名字、會話密鑰以及任何其它必須保密的數(shù)據(jù)。票據(jù)也提供KDC 204支持的加密類型與校驗和類型的列表。票據(jù)的加密部分使用KDC 204的私密密鑰加密。消息由KDC 204簽名，其使用與客戶端在AS_REQ內(nèi)指定的公鑰相對應的私鑰，并使用AS_REQ內(nèi)指定的簽名算法。公鑰信息是密鑰協(xié)定參數(shù)的KDC 204的公開部分，并指示與客戶端所選相同的密鑰協(xié)定算法。用以驗證KDC 204的數(shù)字簽名的公鑰可由其客戶端在供應期間獲取。
AS REP的加密部分消息的加密部分包含與票據(jù)內(nèi)同樣的信息，使得客戶可以訪問自己的授權數(shù)據(jù)。它也包含客戶端的標識，以驗證該應答最初由KDC 204為此特定客戶端創(chuàng)建。數(shù)據(jù)使用自密鑰協(xié)定算法派生的對稱密鑰加密。然而，AS_REP的加密部分內(nèi)的密鑰與票據(jù)內(nèi)的會話密鑰不同。作為替代，它是SKS會話密鑰種子，客戶端將使用其組合自己的主機ID來產(chǎn)生實際的會話密鑰。
TGS_REQ消息當希望獲取用于給定服務器的認證證書時，客戶端發(fā)起客戶端與票據(jù)授予服務器之間的TGS交換。客戶端可能已經(jīng)使用AS交換取得了用于票據(jù)授予服務的票據(jù)。TGS交換的消息格式與AS交換的相似。主要的差別是TGS交換內(nèi)的加密與解密不在密鑰協(xié)定算法下進行。作為替代，使用來自票據(jù)授予票據(jù)的會話密鑰。該消息由客戶端發(fā)送給票據(jù)授予服務器，以獲取緩存服務器票據(jù)(其可以用于KEY_REQ內(nèi))。客戶端將自AS_REP獲得的TGT作為消息的一部分。消息指定服務器的標識和客戶端的標識(其在TGT內(nèi))。由于其標識在TGT內(nèi)被加密，客戶端隱私受到保護(在IPRM系統(tǒng)內(nèi)該特性對于消費者216是有用的)。窺探者不能檢測用戶正在請求何種服務。服務器使用客戶端的時間戳來檢測重播。TGT內(nèi)的會話密鑰被用于計算消息的校驗和。
消息TGS REPTGS_REP消息由KDC 204生成，以響應TGS_REQ。它包含端服務票據(jù)(由KDC 204發(fā)給，當必須請求服務時，客戶將其呈現(xiàn)給服務器)。服務器的標識與票據(jù)有效期在發(fā)出的票據(jù)內(nèi)的明文中提供。票據(jù)的加密部分包含客戶端的領域、客戶端的名字以及使用為服務器和KDC 204所共享的密鑰加密的會話密鑰。任何其它必須為私有的客戶端數(shù)據(jù)被包括作為票據(jù)的加密部分的一部分。消息的加密部分包括SKS(在會話密鑰字段內(nèi))，客戶端可使用其(以及主機ID)來生成實際的會話密鑰，其可用于認證到特定的應用服務器。消息的加密部分還可包括要被呈現(xiàn)給服務器的客戶端授權數(shù)據(jù)。KDC 204使用TGT會話密鑰以加密的校驗和對消息進行簽名。IPRM系統(tǒng)2000目前利用發(fā)給消費者216的票據(jù)內(nèi)的授權數(shù)據(jù)。
消息票據(jù)詢問無論何時想要發(fā)起密鑰管理，服務器利用票據(jù)詢問消息。該消息是不受認證的，但它確實在其報頭內(nèi)包含STID()。如這里所使用的那樣，STID(源交易標識符)是由密鑰管理消息的發(fā)起者選擇的唯一的隨機值。
客戶端的響應將在應答的DTID報頭字段內(nèi)包括該STID的值。甚至在沒有認證的情況下，這防止了拒絕服務攻擊，其中敵手能夠觸發(fā)不希望的密鑰管理交換。該消息也包含服務器領域與當事人名字，客戶端使用其來查找或獲取用于該服務器的正確的票據(jù)。在IPRM系統(tǒng)2000之內(nèi)，應用服務器以票據(jù)詢問在內(nèi)容提供商(客戶端)與緩存服務器(應用服務器)之間的接口上發(fā)起密鑰管理。票據(jù)詢問消息還包括如下字段●目標協(xié)議的標識符，密鑰即為該協(xié)議建立●應用角色標識特定應用程序，密鑰即為該應用程序建立。當密鑰管理器進程從另一主機接收到建立密鑰的請求時，它將使用應用角色來查找本地應用程序，建立的密鑰將交給其，且其將驗證DOI對象的內(nèi)容。
●應用服務器名字與領域消息密鑰請求密鑰請求由客戶發(fā)送，以建立新的安全參數(shù)集。無論何時客戶端接收到票據(jù)詢問消息，它可應之以密鑰請求?？蛻舳艘部墒褂么讼碇芷谛缘亟⑴c服務器的新密鑰?？蛻舳碎_始時具有有效票據(jù)，其先前自TGS應答中獲取。服務器開始時具有其服務密鑰，它可使用其來解密和驗證票據(jù)。密鑰請求包括客戶票據(jù)與加密的校驗和，其為認證客戶端所需要。消息也包含時間戳(以防止重播攻擊)。消息包括以下字段●目標協(xié)議的標識符，密鑰即為該協(xié)議建立。
●應用角色標識特定應用程序，密鑰即為該應用程序建立。
●客戶端的主機的當前時間●自TGS_REP獲取的服務票據(jù)，其用于標識客戶端。
●客戶端支持的加密算法(密碼套件)的列表。
●DOI數(shù)據(jù)，其為協(xié)議特定的、應用特定的，并且可以是加密的。
●認證符，其驗證DOI數(shù)據(jù)的內(nèi)容，其中該認證符由第三方(例如，內(nèi)容提供商)生成。
●客戶端生成的MAC，其用于提供消息完整性。
密鑰應答密鑰應答消息由服務器發(fā)送，以響應密鑰請求消息。密鑰應答可包括隨機地生成的子密鑰，其使用客戶端與服務器之間共享的會話密鑰加密。子密鑰的長度是DOI特定的。密鑰應答包括某些額外的信息，其為建立安全參數(shù)所需要。密鑰應答消息包括以下字段●目標協(xié)議的標識符，密鑰即為該協(xié)議建立。
●應用角色標識特定應用程序，密鑰即為該應用程序建立。
●加密的子密鑰，其用于派生密鑰，以保護目標協(xié)議或?qū)ο蟮陌踩?br> ●加密與認證算法，其應被用于保護目標協(xié)議或?qū)ο蟆?br> ●加密的DOI對象，其包含某些應用特定的或協(xié)議特定的參數(shù)。
●子密鑰有效的期限。
●標志，其指示新的子密鑰是否應在舊的到期之前自動地協(xié)商。
●標志，其指示此消息的接收者是否應該應之以安全性建立消息。
●MAC，其用于提供消息完整性。
安全性建立安全性建立消息由客戶端發(fā)送給服務器，以確認它已接收到密鑰應答并成功地建立起新的安全參數(shù)。僅當密鑰應答內(nèi)的ACK_REQ標志被設定時，發(fā)送此消息。在服務器以票據(jù)詢問發(fā)起密鑰管理的情形中，它可能想看到此確認，因此可能請求它，在密鑰應答內(nèi)設置要求的ACK標志。此消息包括以下字段●目標協(xié)議的標識符，密鑰即為該協(xié)議建立。
●應用角色標識特定應用程序，密鑰即為該應用程序建立。
●MAC，其覆蓋此消息與前面的密鑰應答消息。
消息CLIENT_ENROLL_REQ消息CLIENT_ENROLL_REQ由客戶端發(fā)送給KDC 204，該客戶端希望更新其公鑰，或者指定新的公鑰，其尚不在KDC 204數(shù)據(jù)庫內(nèi)，并且不具有相應的數(shù)字證書。此消息可用供應票據(jù)與校驗和進行認證，該校驗和用供應密鑰(供應票據(jù)內(nèi)的會話密鑰)加密。供應服務器可代表某個ESBrokerTM當事人使用INIT_PRINCIPAL_REQ消息獲取供應票據(jù)。供應服務器之后將使用一種帶外方法，以將供應票據(jù)與相應的供應密鑰轉發(fā)給客戶端，其之后將生成此CLIENT_ENROLL_REQ?？蛻舳艘部梢灾付ㄋ鼘⒔邮苣姆N類型的KDC204證書(在AS_REP消息內(nèi))。如果相應的屬性(KDC 204證書類型)不存在，此客戶端不支持任何類型的KDC 204證書。在接收到此消息時，KDC 204將基于其政策來決定它是否應該存儲公鑰，向客戶發(fā)布證書，或者進行這兩者。KDC 204也將決定發(fā)布哪種類型的證書?？蛻舳瞬魂P心KDC 204將發(fā)布哪種類型的證書，因為它無需解析自己的證書。當客戶端被發(fā)布證書時，它必須將其作為不透明塊?？蛻舳藘H負責存儲自己的證書，并將它包含在AS_REQ消息內(nèi)。
消息CLIENT_ENROLL_REP此消息是對CLIENT_ENROLL_REQ的應答。它確認客戶端公鑰已被更新，或者為公鑰指定新的客戶端證書，或者進行這兩者。KDC 204在發(fā)送此消息之前采取的行動基于其配置的政策。此消息用加密的校驗和認證，其使用與認證請求相同的供應密鑰。盡管未顯示，本領域普通技術人員將認識到可使用與本發(fā)明的精神與范圍相一致的各種其它消息。
媒體流密鑰管理媒體流密鑰管理是特定于IPRM的協(xié)議，如在票據(jù)詢問、KEY_REQ、KEY_REP與安全性建立消息內(nèi)使用的DOI_ID屬性標識的那樣。
可選地，這些消息可攜帶對應于DOI對象的第三方認證符。在DOI對象的生成者不是密鑰管理消息的發(fā)送者，而是某個其它的第三方的情形中，該認證符是有用的。對于媒體流安全性，在某些情形中，這樣的認證符是必需的，而在其它情形中則不是。
IPRM DOI對象包含會話權利對象或會話ID一個隨機數(shù)，其唯一地標識點到點安全會話。會話ID的生成不要求強隨機數(shù)生成器，任何基于軟件的偽隨機數(shù)生成器即已足夠。當端點之一生成會話ID時，它確保它對于該主機是唯一的。無論何時檢測到會話ID沖突，發(fā)生沖突的端點可返回應用錯誤代碼，生成此會話ID的端點將生成另一個隨機值并且重試。注意，正常地，DOI對象在KEY_REQ或KEY_REP消息之內(nèi)被加密。
媒體流DOI對象有多種類型的IPRM DOI對象可用于媒體流密鑰管理中●會話權利
●會話ID會話權利DOI對象正常地，當消費者216希望自緩存服務器請求安全會話以觀看節(jié)目時，會話權利同KEY_REQ消息一起被發(fā)送。會話權利由消費者216自內(nèi)容提供商202獲取。消費者216(查看器軟件)之后將此DOI對象置于KEY_REQ消息之內(nèi)，該消息之后由適當?shù)木彺娣掌黩炞C。會話權利由第三方認證符伴隨，使得緩存服務器可以驗證是內(nèi)容提供商202生成了會話權利與此認證符。
會話權利包括會話ID，其標識特定內(nèi)容流或者分發(fā)會話，以及過期時間，其用于這些會話權利。會話權利也包括用戶選擇，比如說，其包括●消費者216選擇的購買選項。例如，購買選項可指示內(nèi)容是免費的，基于訂閱選擇，按查看次數(shù)付費，或者按時間付費(價格依據(jù)觀看了多少內(nèi)容而變化)。
●內(nèi)容的購買價格同樣的會話權利還可包括內(nèi)容規(guī)則，例如●限制將此內(nèi)容分發(fā)到特定國家●限制將此內(nèi)容分發(fā)到特定地理區(qū)域●服務ID列表，此內(nèi)容在這些服務ID下被提供，以供訂閱大體上，這些規(guī)則與選擇可以是任意地復雜，并可用不同的格式表達，這些格式包括TLV(類型—長度—值)編碼、XML、等等。
會話ID DOI對象會話ID DOI對象用于KEY_REQ和KEY_REP消息。當緩存服務器從另一臺緩存服務器請求內(nèi)容時，會話ID DOI對象將被包括到自請求緩存服務器發(fā)出的KEY_REQ消息中。當緩存服務器從內(nèi)容提供商202請求內(nèi)容時，會話ID DOI對象被作為KEY_REP消息的一部分發(fā)送。在此情形中，緩存服務器使用TKT_CHALLENGE消息發(fā)起密鑰管理交換，并且沒有機會指定會話ID，直到它發(fā)送KEY_REP消息。由于此類型的DOI對象不是由第三方創(chuàng)建，它不要求額外的第三方認證符。
密鑰派生此密鑰派生過程特定于IPRM DOI_ID值，并且適用于媒體流以及處于同一DOI_ID之下的其它目標協(xié)議。在目標應用秘密(TAS)(會話密鑰與子密鑰的連接)已同密鑰管理一起建立時，它被用于以指定次序派生如下的密鑰集。客戶端派生出EK，用于輸出消息的內(nèi)容加密密鑰。長度取決于選擇的密碼。
出KMAC，MAC(消息認證代碼)密鑰，其用于生成MAC，以認證輸出消息。密鑰長度取決于選擇的消息認證算法。
入EK，用于輸入消息的內(nèi)容加密密鑰。
入KMAC，MAC密鑰，其用于認證輸入消息。
應用服務器派生入EK入KMAC出EK出KMAC注意，入與出密鑰在客戶端與服務器上的派生次序是相反的，這是因為在一邊用于加密出通信的密鑰在另一邊被用于解密入通信。類似地，在一邊用于為出消息生成MAC的MAC密鑰在另一邊用于驗證入消息的MAC值。
另外，應該觀察到的是，不是所有的密鑰都被用于每個協(xié)議。例如，RTP僅使用EK，加密密鑰，并且僅用于一個方向上的流量，這是因為在IPRM內(nèi)，沒有雙向的RTP會話(客戶端不向流服務器回發(fā)RTP分組)。密鑰派生函數(shù)是單向函數(shù)。給定一個派生的密鑰，確定TAS(目標應用秘密)的值是不可行的。
盡管上面是對本發(fā)明的示例性的特定實施例的完全描述，另外的實施例也是可能的。因此，不應當將上面的描述看作是對本發(fā)明的范圍的限制，該范圍由所附的權利要求書連同其等同物的全部范圍確定。
權利要求
1.一種權利管理架構，其用于向授權的消費者安全地遞送內(nèi)容，所述架構包括內(nèi)容提供商；消費者系統(tǒng)，其從所述內(nèi)容提供商請求內(nèi)容；所述內(nèi)容提供商生成會話權利對象，其用于訪問所述內(nèi)容；KDC(密鑰分發(fā)中心)，其向所述消費者系統(tǒng)提供授權數(shù)據(jù)，所述授權數(shù)據(jù)用于訪問所述內(nèi)容；緩存服務器，其將所述會話權利對象內(nèi)的信息與所述授權數(shù)據(jù)進行比較；和如果所述信息匹配所述授權數(shù)據(jù)，所述緩存服務器將所述的請求的內(nèi)容轉發(fā)給所述消費者系統(tǒng)。
2.如權利要求1所述的架構，其中所述消費者系統(tǒng)被重定向到所述緩存服務器，以接收所述的請求的內(nèi)容。
3.如權利要求1所述的架構，其中，所述緩存服務器與所述內(nèi)容提供商組合為單個被標識的系統(tǒng)。
4.如權利要求1所述的架構，其中所述緩存服務器采用實時流傳送，以安全地轉發(fā)所述的加密的內(nèi)容。
5.如權利要求1所述的架構，其中所述的請求的內(nèi)容被加密，以轉發(fā)到所述消費者系統(tǒng)。
6.如權利要求4所述的架構，其中所述緩存服務器與所述消費者系統(tǒng)交換控制消息，以支持所述的請求的內(nèi)容的傳輸。
7.如權利要求6所述的架構，其中，所述控制消息被加密與認證。
8.如權利要求5所述的架構，其中所述緩存服務器包括一個或多個緩存盤，以存儲加密的內(nèi)容。
9.如權利要求5所述的架構，其中所述KDC分發(fā)密碼密鑰，所述KDC采用對稱與公開算法的混合，以分發(fā)所述密碼密鑰。
10.如權利要求5所述的架構，其進一步包括密鑰管理協(xié)議，其用于在所述緩存服務器與所述消費者系統(tǒng)之間建立密鑰。
11.如權利要求10所述的架構，其中，所述密鑰管理協(xié)議包括密鑰請求消息，其用于從所述緩存服務器請求會話密鑰；和作為對其響應的密鑰應答消息，其用于向所述消費者系統(tǒng)提供所述會話密鑰。
12.如權利要求11所述的架構，其中所述會話權利對象與所述授權數(shù)據(jù)被包括于所述密鑰請求消息內(nèi)；其中，所述緩存服務器將所述會話權利對象內(nèi)的信息與所述授權數(shù)據(jù)進行比較；和如果所述信息匹配所述授權數(shù)據(jù)，則向所述消費者系統(tǒng)提供所述會話密鑰。
13.如權利要求12所述的架構，其中所述內(nèi)容提供商生成所述會話權利對象，其指定所述用戶對所述內(nèi)容的訪問權限。
14.一種權利管理方法，其用于在從緩存服務器請求時安全地遞送內(nèi)容，所述方法包括提供內(nèi)容提供商，其可通信地連接到所述緩存服務器；提供密鑰管理協(xié)議，其包括如下步驟，從所述緩存服務器向所述內(nèi)容提供商轉發(fā)票據(jù)詢問消息，所述詢問消息用于發(fā)起密鑰管理；作為對其的響應，從所述內(nèi)容提供商向所述緩存服務器發(fā)送密鑰請求消息；作為對其的響應，從所述緩存服務器向所述內(nèi)容提供商發(fā)送密鑰應答消息；作為對其的響應，從所述內(nèi)容提供商向所述緩存服務器發(fā)送安全性建立消息；和作為對其的響應，從所述內(nèi)容提供商向所述緩存服務器發(fā)送安全性建立消息；和建立密鑰集，其用于從所述內(nèi)容提供商向所述緩存服務器安全地遞送內(nèi)容。
15.如權利要求14所述的方法，其進一步包括提供消費者系統(tǒng)，其從所述緩存服務器流傳送內(nèi)容。
16.如權利要求14所述的方法，其進一步包括提供密鑰分發(fā)中心，其用于在所述緩存服務器與所述內(nèi)容提供商之間建立信任。
17.一種權利管理方法，其用于在緩存服務器上安全地預布置內(nèi)容，所述方法包括提供內(nèi)容提供商，其可通信地連接到所述緩存服務器；提供密鑰管理協(xié)議，其包括如下步驟，從所述內(nèi)容提供商向所述緩存服務器轉發(fā)密鑰請求消息，所述密鑰請求消息用于發(fā)起密鑰管理；作為對其的響應，從所述緩存服務器向所述內(nèi)容提供商發(fā)送密鑰應答消息；和建立密鑰集，其用于從所述內(nèi)容提供商向所述緩存服務器安全地遞送內(nèi)容。
18.如權利要求17所述的方法，其進一步包括提供消費者系統(tǒng)，其從所述緩存服務器流傳送內(nèi)容。
19.如權利要求17所述的方法，其進一步包括提供密鑰分發(fā)中心，其用于在所述緩存服務器與所述內(nèi)容提供商之間建立信任。
20.一種認證系統(tǒng)，其允許認證的用戶從計算網(wǎng)絡內(nèi)的緩存服務器流傳送內(nèi)容，所述系統(tǒng)包括內(nèi)容提供商，其向所述緩存服務器提供所述內(nèi)容，以供所述用戶訪問；密鑰分發(fā)中心，其從所述內(nèi)容提供商接收第一請求，其請求訪問所述緩存服務器，并且如果被認證，所述內(nèi)容提供商向所述緩存服務器遞送所述內(nèi)容；和所述密鑰分發(fā)中心從所述用戶接收第二請求，其請求訪問所述緩存服務器，并且如果被認證，所述用戶被允許從所述緩存服務器流傳送所述內(nèi)容。
21.如權利要求20所述的認證系統(tǒng)，其中，所述第二請求用于緩存服務器票據(jù)，以訪問所述緩存服務器。
22.一種用于保護通信網(wǎng)絡的組件之間的數(shù)據(jù)傳輸安全的協(xié)議a)提供中央服務器，其具有數(shù)據(jù)庫；b)從內(nèi)容提供商向所述中央服務器公布內(nèi)容元數(shù)據(jù)；c)提供記賬中心服務器，其可通信地連接到所述中央服務器；d)從緩存服務器向所述記賬中心服務器報告記賬信息；e)提供供應數(shù)據(jù)庫，其連接到所述中央服務器；f)以消費者信息更新所述供應數(shù)據(jù)庫；和g)使用密鑰管理協(xié)議，以在步驟b)、步驟d)與步驟f)的任何一個或多個的期間安全地傳輸數(shù)據(jù)。
23.如權利要求22所述的協(xié)議，其中所述密鑰管理協(xié)議包括轉發(fā)密鑰請求消息，所述密鑰請求消息用于請求會話密鑰；和接收密鑰應答消息，所述密鑰應答消息用于提供會話密鑰。
全文摘要
本發(fā)明公開一種數(shù)字權利管理架構，其用于向授權的消費者安全地遞送內(nèi)容。所述架構包括內(nèi)容提供商(202)和從內(nèi)容提供商請求內(nèi)容的消費者系統(tǒng)(216)。內(nèi)容提供商生成會話權利對象(202B)，其具有消費者選擇的購買選項。KDC(204)其后向消費者系統(tǒng)提供授權數(shù)據(jù)。同時，提供緩存服務器(215)，用于比較購買選項和授權數(shù)據(jù)。如果購買選項匹配授權數(shù)據(jù)，緩存服務器(215)將請求的內(nèi)容轉發(fā)給消費者系統(tǒng)(216)。注意緩存(215)服務器采用實時流來安全地轉發(fā)加密的內(nèi)容，并且請求的內(nèi)容被加密，以轉發(fā)給消費者系統(tǒng)(216)。進一步地，緩存服務器(215)與消費者系統(tǒng)(216)交換加密的(并且是被認證的)控制消息，以支持傳輸請求的內(nèi)容。以這種方式，組件之間的所有接口受到加密保護和/或認證。
文檔編號H04L9/08GK1631000SQ02822760
公開日2005年6月22日 申請日期2002年11月15日 優(yōu)先權日2001年11月15日
發(fā)明者亞歷山大·麥德文斯基, 彼得·彼得卡, 保羅·莫羅尼, 埃里克·斯普龍克 申請人:通用儀表公司