專利名稱：用于提供帶客戶授權(quán)驗證的密鑰管理協(xié)議的系統(tǒng)和方法
技術(shù)領(lǐng)域：
本發(fā)明總體上涉及網(wǎng)絡安全，更具體而言，涉及用于當從應用服務器請求內(nèi)容時提供客戶保密性的方法和系統(tǒng)。
背景技術(shù)：
互聯(lián)網(wǎng)是一種不安全的網(wǎng)絡。許多在互聯(lián)網(wǎng)上使用的協(xié)議都不提供任何安全性。沒有利用加密術(shù)或任何其它類型安全措施在互聯(lián)網(wǎng)上傳輸?shù)臄?shù)據(jù)被稱作是“顯文”傳輸?shù)摹Ｊ购诳蛡儭靶崽健背鲈诨ヂ?lián)網(wǎng)上顯文傳輸?shù)臄?shù)據(jù)，如口令、信用卡號、客戶身份及姓名等的工具很容易得到。因此，在互聯(lián)網(wǎng)上發(fā)送未加密數(shù)據(jù)的應用是非常容易受到攻擊的。
Kerberos是一種設計成通過利用安全密鑰加密技術(shù)為客戶/服務器應用提供鑒別的已知網(wǎng)絡鑒別協(xié)議的例子?？梢詮穆槭±砉W院獲得的Kerberos協(xié)議利用加密技術(shù)，從而據(jù)稱客戶可以通過不安全的網(wǎng)絡連接向服務器證明其身份(反之亦然)。在客戶與服務器利用Kerberos證明他們的身份后，他們還可以加密他們的所有通信，以便當他們進行交易時據(jù)稱可以確保保密性及數(shù)據(jù)的完整性。
本發(fā)明就是關(guān)于這些及其它與網(wǎng)絡安全領(lǐng)域有關(guān)的背景信息因素展開的。

發(fā)明內(nèi)容
本發(fā)明提供了一種向客戶提供可由該客戶訪問并使用的授權(quán)數(shù)據(jù)拷貝的方法，該方法包括步驟從客戶接收鑒別服務器請求(AS_REQ)消息；產(chǎn)生鑒別服務器應答(AS_REP)消息；向客戶發(fā)送AS_REP；從客戶接收票許可服務器請求(TGS_REQ)消息；產(chǎn)生帶兩份授權(quán)數(shù)據(jù)拷貝的票許可服務器應答(TGS_REP)消息；及向客戶發(fā)送帶兩份授權(quán)數(shù)據(jù)拷貝的TGS_REP。
在另一種實施方案中，本發(fā)明提供了一種方法，包括以下步驟產(chǎn)生包括授權(quán)數(shù)據(jù)第一拷貝的服務票；產(chǎn)生包括該服務票的票許可服務器應答；及向客戶發(fā)送該票許可服務器應答與授權(quán)數(shù)據(jù)第二拷貝。在一種實施方案中，發(fā)送授權(quán)數(shù)據(jù)第二拷貝的步驟包括利用客戶會話密鑰加密至少授權(quán)數(shù)據(jù)的第二拷貝，使客戶能夠解密和利用該授權(quán)數(shù)據(jù)的第二拷貝，而產(chǎn)生服務票的步驟包括利用服務器密鑰加密至少第一授權(quán)數(shù)據(jù)。
在另一種實施方案中，本發(fā)明其特征在于一種當從應用服務器請求內(nèi)容時提供客戶保密性的系統(tǒng)。該系統(tǒng)包括配置成產(chǎn)生包括至少兩份授權(quán)數(shù)據(jù)拷貝的票許可服務器應答的密鑰分配中心，其中該密鑰分配中心與配置成接收票許可服務器應答并利用授權(quán)數(shù)據(jù)的一份拷貝驗證授權(quán)的客戶耦合在一起，而該客戶與配置成向客戶提供內(nèi)容的應用服務器耦合在一起，其中客戶進一步配置成利用授權(quán)數(shù)據(jù)的一份拷貝驗證內(nèi)容的授權(quán)使用。
在另一種實施方案中，本發(fā)明其特征在于一種向客戶提供內(nèi)容和/或服務訪問的系統(tǒng)。該系統(tǒng)包括用于產(chǎn)生包括授權(quán)數(shù)據(jù)第一拷貝的服務票的裝置；用于產(chǎn)生包括該服務票及授權(quán)數(shù)據(jù)第二拷貝的票許可服務器應答的裝置；及用于向客戶發(fā)送票許可服務器應答的裝置。用于產(chǎn)生票許可服務器應答的裝置可以包括利用客戶會話密鑰加密至少授權(quán)數(shù)據(jù)的第二拷貝的裝置，而加密至少第二授權(quán)數(shù)據(jù)的裝置可以包括加密至少授權(quán)數(shù)據(jù)的第二拷貝從而使客戶能夠解密并利用授權(quán)數(shù)據(jù)第二拷貝的裝置。用于產(chǎn)生服務票的裝置可以包括利用服務器密鑰加密至少授權(quán)數(shù)據(jù)第一拷貝的裝置。授權(quán)數(shù)據(jù)的第二拷貝可以配置成允許客戶驗證來自應用服務器的服務請求。授權(quán)數(shù)據(jù)的第二拷貝還可以配置成允許客戶確定所接收內(nèi)容的授權(quán)使用。
通過參考以下對本發(fā)明的詳細描述及闡述一種說明性實施方案的附圖，可以獲得對本發(fā)明特點及優(yōu)點的更好理解，其中的實施方案利用了本發(fā)明的原理。


從以下對其更具體的描述并聯(lián)系附圖，本發(fā)明的上述及其它方面、特點及優(yōu)點將變得很明顯，其中圖1描述了根據(jù)本發(fā)明一種實施方案制造的系統(tǒng)的簡化方框圖；圖2描述了根據(jù)本發(fā)明一種實施方案實現(xiàn)的系統(tǒng)的簡化方框圖；圖3描述了用于向客戶提供由客戶使用的授權(quán)數(shù)據(jù)第二拷貝的方法流程圖；圖4描述了與圖3所述過程類似的一種過程實現(xiàn)的簡化流程圖；及圖5描述了一種讓客戶從應用服務器請求并接收內(nèi)容和/或服務的過程實現(xiàn)的簡化流程圖。
貫穿所有附圖，對應的標號表示對應的元件。
具體實施例方式
Kerberos的缺點在于如客戶或服務器的網(wǎng)絡實體不能夠驗證提交到應用服務器授權(quán)數(shù)據(jù)以便訪問由該應用服務器所提供服務和/或內(nèi)容。授權(quán)數(shù)據(jù)部分定義了提供給客戶的服務和/或內(nèi)容的限制。授權(quán)數(shù)據(jù)常常是專用于應用服務器106及由應用服務器106所提供內(nèi)容和/或服務的。由于客戶不能夠驗證授權(quán)，因此客戶就不能夠檢查內(nèi)容請求以確保沒有選擇未授權(quán)的選項。另外，由于客戶不能夠驗證授權(quán)數(shù)據(jù)，因此客戶需要另外的通信與信息來確定客戶是否被授權(quán)可以拷貝交付給客戶的內(nèi)容。這導致錯誤、過大的網(wǎng)絡業(yè)務量及網(wǎng)絡資源和處理的不必要使用。還有，由于客戶不能夠驗證授權(quán)數(shù)據(jù)，因此客戶不能夠確定客戶是否被授權(quán)可以例如不止一次地回放內(nèi)容而不需要接收另外的通信和信息。
通過向客戶交付客戶可以訪問并使用以提高網(wǎng)絡效率、減小網(wǎng)絡業(yè)務量并將內(nèi)容和/或服務的訪問及使用連成整體的授權(quán)數(shù)據(jù)拷貝，本發(fā)明提供了克服這些及其它缺點的方法和系統(tǒng)。通過向客戶提供授權(quán)數(shù)據(jù)的客戶拷貝，客戶能夠通過避免在內(nèi)容請求中包括非法選項來驗證請求，并確定客戶對所交付內(nèi)容和/或服務的授權(quán)使用，例如確定所交付內(nèi)容的拷貝是否可以保存及確定內(nèi)容是否可以不止一次地回放。
本發(fā)明非常適合于利用票概念的密鑰管理協(xié)議，其中票是利用允許客戶對指定服務器進行鑒別的對稱密鑰進行加密的鑒別標記。根據(jù)本發(fā)明的一種實施方案，當密鑰分配中心(KDC)將服務票轉(zhuǎn)發(fā)到客戶、服務器或其它網(wǎng)絡實體時，KDC在服務票中包括兩份授權(quán)數(shù)據(jù)的拷貝。其中一份授權(quán)拷貝，客戶拷貝，配置成使客戶(服務器或其它實體)能夠訪問由客戶使用的授權(quán)數(shù)據(jù)，而另一份授權(quán)拷貝，服務器拷貝，提供給應用服務器，其中第二拷貝帶有來自客戶的內(nèi)容選擇和/或密鑰請求。通過提供可以由客戶或服務器訪問并使用的授權(quán)數(shù)據(jù)拷貝，本發(fā)明克服了標準Kerberos及以前其它協(xié)議的缺點，其中的客戶或服務器試圖獲得對由應用服務器所提供內(nèi)容和/或服務的訪問。
參考圖1，說明了根據(jù)本發(fā)明一種實施方案制造的用于提供安全通信的系統(tǒng)100的簡化方框圖。包括本發(fā)明一種可能實現(xiàn)的例子的系統(tǒng)100使用在如互聯(lián)網(wǎng)、內(nèi)聯(lián)網(wǎng)或可以增加到上百萬用戶的其它網(wǎng)絡的網(wǎng)絡上提供安全性與保密性的鑒別密鑰管理協(xié)議。一般而言，系統(tǒng)100涉及至少一個利用公鑰與對稱密鑰算法同一個或多個集中密鑰分配中心(KDC)104交互及利用對稱密鑰算法同如應用服務器106(及第三方服務器140，見圖2)的單獨應用服務器交互的客戶102。該協(xié)議是一般性的，可以很容易地適用于在分布式環(huán)境中需要鑒別的不同應用。此外，它還可以同集中管理的用戶數(shù)據(jù)庫接口。
客戶102可以包括代表用戶利用網(wǎng)絡服務的過程、應用或設備。作為示例，客戶102可以包括任何類型的計算機，或者客戶102也可以包括如無線電話、尋呼機、個人數(shù)字助理(PDA)、具有低端微處理器的家用電器或基本上任何其它具有弱的或有限處理能力的設備的“瘦客戶”。應當指出，在有些情況下，服務器本身也可以是某個其它服務器的客戶(例如，打印服務器可以是文件服務器的客戶)。
應用服務器106向網(wǎng)絡客戶提供資源。在所說明的實施方案中，KDC 104包括第一級108和第二級110。在一種實施方案中，第一級是鑒別服務器(AS服務器)108，而第二級是票許可服務器(TGS服務器)110。在驗證其證書后，AS服務器108向客戶102發(fā)票許可票(TGT票)。TGS服務器110向客戶102提供應用服務器服務票(ST票)。當客戶請求服務時，ST票是客戶102提交給應用服務器106的結(jié)束服務票。當客戶102利用ST票鑒別其自己后，應用服務器106向客戶102提供各種服務。
系統(tǒng)100所使用的基本消息類型如下(A)鑒別服務器請求消息(AS_REQ)來自客戶102、從AS服務器108請求TGT票的消息；(B)鑒別服務器應答消息(AS_REP)從AS服務器108到客戶102、帶TGT票的應答消息；(C)票許可服務器請求消息(TGS_REQ)來自客戶102、從TGS服務器110請求ST票的消息；(D)票許可服務器應答消息(TGS_REP)從TGS服務器110到客戶102、帶ST票的應答消息；(E)密鑰請求消息(KEY_REQ)從客戶102發(fā)送到應用服務器106、請求安全(密鑰管理)參數(shù)的消息；(F)密鑰應答消息(KEY_REP)從應用服務器106到客戶102、帶子密鑰和應用專用數(shù)據(jù)的應答消息；(H)內(nèi)容和/或服務請求消息(CON_REQ)從客戶102發(fā)送到應用服務器106、請求期望內(nèi)容和/或服務的消息；及(I)內(nèi)容和/或服務應答消息(CON_REP)從應用服務器106發(fā)送到客戶102、向客戶提供期望內(nèi)容和/或服務的消息。在發(fā)送到客戶之前，內(nèi)容一般是加密的。
通常每個消息都包括一個頭，后面跟著消息體，對消息而言頭是公用的。作為示例，頭可以包括消息類型域、協(xié)議版本號域及校驗和。消息類型域表示消息類型，如AS_REQ、AS_REP等。跟在消息頭后面的是優(yōu)選地具有類型長度值(TLV)格式的屬性列表的消息體。
當客戶希望獲得用于TGS服務器110的TGT票時，客戶102產(chǎn)生AS_REQ信息以初始化客戶102與AS服務器108(KDC 104的一部分)之間的鑒別服務交換，其中TGS服務器110也是KDC 104的一部分。換句話說，AS_REQ消息是由客戶102發(fā)送到AS服務器108的，以獲得由客戶用于請求指定應用服務器，如應用服務器106，的ST票的TGT票。作為示例，AS_REQ消息可以包括客戶的身份(如名字)、TGS服務器110的身份及將其綁定到一種響應的特殊時間。它還可以包括客戶102支持的對稱加密算法列表。為了檢查應答，這個消息還可以包括時間戳及用于消息完整性的簽名。該簽名可以是加密校驗和或數(shù)字簽名。
驗證簽名的公鑰優(yōu)選地保存在用戶數(shù)據(jù)庫中。數(shù)字認證可選地可以包括在AS_REQ消息中，而且可以代替所存儲的公鑰用于驗證數(shù)字簽名。客戶102用于驗證加密校驗和的永久性對稱密鑰優(yōu)選地保存在同一個用戶數(shù)據(jù)庫中。AS_REQ消息還可以包括密鑰一致所必需的公鑰信息(例如，橢圓曲線Diffie-Hellman參數(shù))。作為示例，由于其處理速度，橢圓曲線可用于公鑰加密。橢圓曲線一般比其它加密算法，如RSA，快一或兩個數(shù)量級。Rijndael加密標準可用于128位密鑰長度。
AS服務器108處理AS_REQ消息，以便驗證它。如果AS_REQ處理不產(chǎn)生錯誤，則AS服務器108響應AS_REQ消息，產(chǎn)生AS_REP消息。一般地，為了隨后關(guān)于KDC 104的鑒別，AS服務器108在數(shù)據(jù)庫中查找TGS服務器110和客戶102的密鑰并產(chǎn)生一個隨機的客戶會話密鑰。AS服務器108產(chǎn)生TGT票。TGT票一般既包括顯文部分又包括加密部分。TGS服務器110的身份及票的有效期可以在所發(fā)出的TGT票中顯文提供。票的加密部分可以包括如客戶102的名字、客戶會話密鑰及任何其它要保密的數(shù)據(jù)等信息。TGT票還可以提供一個由KDC 104支持的加密類型與校驗和的列表。票的加密部分可以利用KDC 104的私鑰加密。
在一種實施方案中，AS_REP消息是由KDC 104利用與客戶102用來為AS_REQ消息產(chǎn)生數(shù)字簽名的算法完全相同的算法簽名的。這個簽名可以是數(shù)字簽名或利用客戶102私鑰的加密校驗和。公鑰信息是KDC 104密鑰一致參數(shù)的公共部分，應當表示與客戶102所選算法相同的密鑰一致算法。AS_REP消息優(yōu)選地還包括在AS_REQ消息中由客戶產(chǎn)生的特殊時間拷貝的特殊時間，以防止回放。
在一種實施方案中，AS_REP消息的加密部分向客戶102提供對其自身授權(quán)數(shù)據(jù)的訪問。因為如果客戶102知道其自身的授權(quán)數(shù)據(jù)，則由于應用服務器只信任票中加密的客戶信息拷貝，他以后就不會去嘗試只會被應用服務器拒絕的動作，因此向客戶102提供授權(quán)數(shù)據(jù)的客戶拷貝為客戶(及用戶)提供了方便。而且，對于具有防止用戶被竊用和改變其自身授權(quán)數(shù)據(jù)的硬件安全性的客戶，這個特點可以是一種安全性優(yōu)點，因為可讀的授權(quán)數(shù)據(jù)也可以授權(quán)客戶進行一些本地動作，如在本地磁盤上保存并回放內(nèi)容(如電影)的權(quán)限。在AS_REP消息中接收的授權(quán)數(shù)據(jù)客戶拷貝一般定義通用的客戶授權(quán)，而不是專用于服務器。授權(quán)數(shù)據(jù)客戶拷貝的使用在下面進一步描述。AS_REP消息的加密部分還可以包括客戶102的身份，以驗證這個應答最初是由KDC 104為這個特定客戶102構(gòu)造的。數(shù)據(jù)優(yōu)選地是利用得自密鑰一致算法的對稱密鑰加密的。
客戶102處理AS_REP消息以驗證其真實性并解密消息中的不公開票部分以獲得TGT票。如果AS_REP消息的真實性得不到驗證，則客戶102優(yōu)選地不向AS服務器108發(fā)回錯誤消息。在有些情況下，客戶可以重發(fā)別的AS_REQ消息。
本發(fā)明可選地允許在AS_REQ和AS_REP消息中都通過數(shù)字認證，以允許客戶102和KDC 104利用該數(shù)字認證彼此鑒別。沒有認證的話，則期望已經(jīng)為客戶102提供了KDC的公鑰，且KDC 104已經(jīng)在其數(shù)據(jù)庫中有了客戶102的公鑰。AS_REQ上的數(shù)字簽名是由KDC104利用它在其數(shù)據(jù)庫中查找到的客戶公鑰驗證的。客戶102利用預先提供的KDC公鑰驗證AS_REP上的數(shù)字簽名。
在客戶102通過AS服務器108交換獲得TGT票以后，當客戶102希望獲得對給定或特定應用服務器，如應用服務器106，的鑒別認證時，客戶102初始化客戶102與KDC 104的TGS服務器110之間的TGS_REQ消息交換。TGS_REQ消息是由客戶102產(chǎn)生并發(fā)送到TGS服務器110的，以獲得用在KEY_REQ消息(在下面進一步描述)中的應用服務器服務票(ST票)?？蛻?02提交從作為TGS_REQ消息一部分的AS_REP消息獲得的TGT票。TGS_REQ消息指定一般包含在TGT票中的應用服務器106的身份及客戶102的身份，該客戶一般包括一個特殊時間。在一種實施方案中，由于客戶102的身份處于TGT票的加密部分而不包括在消息的顯文部分中，因此它是被保護的。來自TGT票的客戶會話密鑰可以用于TGS_REQ交換中的加密和解密。因此，探聽者就檢測不到客戶(例如，用戶)在請求哪種服務。
客戶102優(yōu)選地保存該特殊時間的值，以便隨后確認來自KDC104的匹配TGS_REP消息。客戶102優(yōu)選地保存該特殊時間的值，直到一個可配置的超時值到期。在超時后，客戶102就不再能處理對應的TGS_REP了，而必須重發(fā)。
TGS服務器110驗證TGS_REQ消息并處理TGT票。然后TGS服務器110響應TGS_REQ消息，產(chǎn)生TGS_REP消息。TGS_REP消息包括由KDC 104發(fā)出的ST票(這是結(jié)束服務票)，其中ST票是當客戶試圖請求內(nèi)容和/或服務時客戶102提交給應用服務器106的。應用服務器106的身份和票的有效期可以在發(fā)出的ST票內(nèi)部顯文提供。ST票的加密部分包括客戶102的名字和利用由應用服務器106與KDC 104共享的服務器密鑰加密的服務器會話密鑰。另外，ST票的加密部分還包括授權(quán)數(shù)據(jù)的第一拷貝(例如，服務器拷貝)，該拷貝部分定義提供給客戶的服務和/或內(nèi)容的限制。該授權(quán)數(shù)據(jù)專用于應用服務器106及由應用服務器106提供的內(nèi)容和/或服務。在一種實施方案中，該授權(quán)數(shù)據(jù)包括服務和/或內(nèi)容專用對象及對這些對象的權(quán)限。任何需要不公開的附加客戶數(shù)據(jù)也可以作為ST票加密部分的一部分包括在其中。
在一種實施方案中，TGS_REP消息額外地還包括授權(quán)數(shù)據(jù)的第二拷貝(例如，客戶拷貝)，該拷貝是利用AS_REP消息中由AS服務器108產(chǎn)生的TGS票的客戶會話密鑰加密的。如上所述，該會話密鑰是TGS服務器110和客戶102已知的。由于授權(quán)數(shù)據(jù)的第二拷貝(客戶拷貝)是利用來自TGS票的會話密鑰加密的，因此如下面所詳細描述的，例如為了驗證目的及其它目的，客戶102可以解密該授權(quán)數(shù)據(jù)并利用該授權(quán)數(shù)據(jù)。在TGS_REP消息中接收的授權(quán)數(shù)據(jù)的第二拷貝可以提供比在AS_REP消息中接收的授權(quán)數(shù)據(jù)的第二拷貝更多的專用授權(quán)，包括更多的服務器專用授權(quán)。例如，在AS_REP消息中接收的授權(quán)數(shù)據(jù)更通用，定義了非服務器專用的客戶授權(quán)，而不管客戶是否被授權(quán)存儲內(nèi)容。
TGS_REP消息是由帶加密校驗和的KDC 104利用TGT票會話密鑰簽名的。為了防止回放，TGS_REP消息額外地還包括從TGS_REQ消息復制的特殊時間。
作為示例，TGS服務器110可以利用以下過程產(chǎn)生TGS_REP消息。首先，來自TGS_REQ消息的特殊時間被包括在TGS_REP消息中，以便將其綁定到請求。接下來，KDC 104指定隨機ST票會話密鑰的類型。如果有多于一種加密算法可用，則KDC 104優(yōu)選地選擇最強大的一種。然后，KDC 104產(chǎn)生包括授權(quán)數(shù)據(jù)第一拷貝，服務器拷貝，的ST票。應用服務器106的私鑰用于加密ST票的加密部分，而且還對整個ST票產(chǎn)生加密校驗和。ST票的結(jié)束時間優(yōu)選地是由KDC104確定的。如果期望，客戶102可以指定比較短的生命期。ST票的加密部分包括客戶102的身份、授權(quán)數(shù)據(jù)的第一拷貝、會話密鑰及其它的不公開數(shù)據(jù)。TGS_REP消息還包括加密的數(shù)據(jù)部分，在此TGT票會話密鑰用于產(chǎn)生該加密的數(shù)據(jù)部分。該加密的數(shù)據(jù)部分包括授權(quán)數(shù)據(jù)的第二拷貝及利用TGT會話密鑰產(chǎn)生的加密校驗和，可以加到TGS_REP消息中。同樣，這也僅僅是TGS服務器110可以用來產(chǎn)生包括授權(quán)數(shù)據(jù)兩份拷貝的TGS_REP消息的過程的一個例子。
由于TGS_REP消息包括授權(quán)數(shù)據(jù)的兩份拷貝，其中一份包含在ST票的加密部分中，而另一份利用來自TGT票的會話密鑰加密，因此應用服務器106及客戶102能夠訪問和利用這些授權(quán)數(shù)據(jù)。以這種方式，客戶能夠執(zhí)行檢查和驗證，而不需要另外的通信和另外的數(shù)據(jù)。本發(fā)明與Kerberos不同，在Kerberos中來自特定應用服務器客戶的票請求的KDC應答只包括授權(quán)數(shù)據(jù)的一份拷貝，該拷貝只能在解密ST票后由應用服務器訪問?？蛇x地，通過包括授權(quán)數(shù)據(jù)的兩份拷貝，其中一份在ST票中加密，而另一份利用允許客戶102解密授權(quán)數(shù)據(jù)的第二拷貝并使用該授權(quán)數(shù)據(jù)的客戶TGT票會話密鑰加密，本發(fā)明中的KDC產(chǎn)生對來自特定應用服務器客戶的票請求的應答。
在一種實施方案中，客戶102包括授權(quán)模塊122。授權(quán)模塊122接收授權(quán)數(shù)據(jù)的第二拷貝并配置成分析該授權(quán)數(shù)據(jù)以確定授權(quán)客戶何時及如何使用由應用服務器106提供的內(nèi)容和/或服務。授權(quán)模塊122可以通過硬件、軟件或硬件和軟件的組合來實現(xiàn)。在一種實施方案中，授權(quán)模塊122是硬件模塊，用來解碼從授權(quán)數(shù)據(jù)中提取出來的授權(quán)，驗證客戶102對內(nèi)容和/或服務的授權(quán)，并且只有當客戶沒超出該授權(quán)時解密所請求的內(nèi)容和/或服務。為了阻止該硬件模塊外部的軟件黑客攻擊，用于驗證授權(quán)數(shù)據(jù)的加密校驗和的私鑰沒有暴露在硬件模塊外部的客戶中。在一種實施方案中，為了實現(xiàn)這種模塊，整個密鑰管理協(xié)議是在同一個硬件模塊122中實現(xiàn)的，而私鑰沒有顯文地暴露在該硬件模塊外部的客戶中。
作為示例，客戶102可以使用以下過程處理TGS_REP消息。在這個例子中，“客戶”指的是客戶102本身或授權(quán)模塊122(當其出現(xiàn)在客戶內(nèi)部時)。本領(lǐng)域技術(shù)人員應當認識到具有授權(quán)模塊122的客戶一般不允許加密處理發(fā)生在授權(quán)模塊的外面。首先，客戶102解析TGS_REP消息頭。如果頭解析失敗，則客戶102表現(xiàn)為就象從來沒有接收到該TGS_REP消息一樣?？蛻?02優(yōu)選地不向TGS服務器110發(fā)回錯誤消息。在有些情況下，客戶102重發(fā)別的TGS_REQ消息。如果有未處理完的TGS_REQ消息，則客戶102可以繼續(xù)等待應答直到超時，然后重發(fā)。接下來，客戶102驗證頭中的協(xié)議版本號。如果該協(xié)議版本不被支持，則客戶102表現(xiàn)為就象從來沒有接收到該TGS_REP消息一樣。否則，客戶102解析消息的剩余部分。如果發(fā)現(xiàn)消息格式非法，則客戶102表現(xiàn)為就象從來沒有接收到該TGS_REP消息一樣。
然后，客戶102查找具有相同特殊時間的未處理完的TGS_REQ消息。如果沒有找到，則客戶表就象從來沒有接收到該消息一樣繼續(xù)處理。如果找到了，則客戶102利用TGT票會話密鑰驗證校驗和。如果校驗和沒有通過驗證，則這個消息被丟棄，客戶102就象從來沒有接收到該消息一樣繼續(xù)處理。
然后，客戶利用TGT票會話密鑰解密TGS_REP消息中不公開的票部分。如果由于TGT票會話密鑰類型與加密數(shù)據(jù)的類型不匹配而使得不公開的票部分不能夠解密，則將有一個致命錯誤報告給用戶，而客戶102不會重發(fā)。如果結(jié)果顯文文本包括格式化錯誤，包括這個客戶102不支持其類型的會話密鑰，或者包括與請求不匹配的客戶身份，則也會有一個致命錯誤報告給用戶，而客戶102不會重發(fā)。如果會話密鑰類型被支持且客戶能夠解密TGS_REP消息中不公開的票部分，則客戶提取出授權(quán)數(shù)據(jù)的第二拷貝，驗證它并保留，以備后用。
然后客戶102處理ST票。如果ST票中有錯誤，則作為致命錯誤報告給用戶，而客戶102不重發(fā)別的TGS_REQ消息。如果TGS_REP中沒有檢測到錯誤，則客戶102在其票緩沖的新記錄中保存完整的ST票及顯文文本不公開的票部分，包括授權(quán)數(shù)據(jù)的第二拷貝。在一種授權(quán)模塊122出現(xiàn)在客戶102內(nèi)部的實施方案中，由于客戶不擁有為票的修改版本產(chǎn)生校驗和的服務器密鑰，因此ST票可以存儲在客戶102內(nèi)部授權(quán)模塊122的外面。授權(quán)數(shù)據(jù)可以存儲在授權(quán)模塊122的內(nèi)部，或者利用加密校驗和或數(shù)字簽名鑒別，然后再存儲在客戶102內(nèi)部授權(quán)模塊122的外面。如果授權(quán)數(shù)據(jù)存儲在授權(quán)模塊122的外面(以便最小化模塊的存儲需求)，則黑客修改授權(quán)數(shù)據(jù)的企圖將會被授權(quán)模塊122檢測到。那是因為用于為授權(quán)數(shù)據(jù)產(chǎn)生加密校驗和或數(shù)字簽名的密鑰在授權(quán)模塊122的外部是不可讀的。
KEY_REQ和KEY_REP消息用于客戶102與應用服務器106之間的密鑰管理和鑒別。KEY_REQ消息由客戶102發(fā)送到應用服務器106，以便建立新的安全參數(shù)集。KEY_REQ消息還可以由客戶102用于周期性地建立關(guān)于應用服務器106的新密鑰。客戶102以事先在TGS_REP消息中獲得的有效ST票開始。應用服務器106以其可以使用以解密和確認票的服務密鑰開始?？蛻舢a(chǎn)生包括鑒別客戶102所需的ST票及加密校驗和的KEY_REQ消息。KEY_REQ消息優(yōu)選地還包括將其綁定到響應KEY_REP消息的特殊時間及防止回放攻擊的客戶時間戳。
當客戶102產(chǎn)生KEY_REQ消息時，在一種實施方案中，授權(quán)數(shù)據(jù)的第一拷貝及客戶102的身份都在ST票的加密部分中。在客戶102發(fā)出KEY_REQ消息后，它保存客戶的特殊時間值，以便以后確認來自應用服務器106的匹配KEY_REP消息。客戶102保存該客戶的特殊時間值，直到一個可配置的超時值到期。超時后，客戶102就不再能處理對應的KEY_REP消息了。客戶102可以在超時后重發(fā)。
KEY_REP消息是由應用服務器106響應KEY_REQ消息而發(fā)送的。作為示例，KEY_REP消息可以包括利用在客戶102與應用服務器106之間共享的會話密鑰加密的一個或多個隨機產(chǎn)生的子密鑰。KEY_REP消息還可以包括建立安全參數(shù)所需的附加信息。
客戶102接收KEY_REP消息并處理KEY_REP消息?？蛻艚馕鱿㈩^、驗證協(xié)議版本號、解析剩余的消息、匹配KEY_REP中的特殊時間與現(xiàn)有客戶KEY_REQ的特殊時間并利用在客戶102與應用服務器106之間共享的會話密鑰驗證校驗和。客戶利用共享的會話密鑰進一步解密KEY_REP的子密鑰，驗證所選的密碼組是可以接受的，解析加密的DOI對象(授權(quán))，從子密鑰產(chǎn)生內(nèi)容解密及鑒別密鑰并保存它們，以備后用。
在一種實施方案中，一旦客戶接收并驗證了KEY_REP，CON_REQ消息就由客戶102發(fā)送到應用服務器106。在產(chǎn)生CON_REQ消息的過程中，客戶訪問解密的授權(quán)數(shù)據(jù)第二拷貝并確認該授權(quán)數(shù)據(jù)以確保CON_REQ消息不包含非法的或未授權(quán)的選項，其中這第二拷貝是客戶從帶ST票的AS_REP消息和/或TGS_REP消息接收并解密的。因此，客戶的用戶接口改進了，而且可以從一開始就防止用戶選擇未授權(quán)的選項，而不需要向服務器提交CON_REQ消息并等待響應。在一種實施方案中，如果由于某種原因客戶102仍然產(chǎn)生了未授權(quán)的CON_REQ消息，則授權(quán)模塊122保留一個為CON_REQ消息產(chǎn)生加密校驗和所需的對稱密鑰，并拒絕為違反或超出如由授權(quán)數(shù)據(jù)第二拷貝定義的客戶授權(quán)的CON_REQ消息產(chǎn)生這種加密校驗和。因此，應用服務器106一般看不到未授權(quán)的CON_REQ消息，因為它們在客戶端就被拒絕了，但是當這種未授權(quán)消息確實傳出時，由于CON_REQ沒有正確的加密校驗和，所以被拒絕了，而不需要服務器106檢查客戶授權(quán)。
通過避免在應用服務器106對未授權(quán)消息的處理，授權(quán)數(shù)據(jù)的確認進一步優(yōu)化了系統(tǒng)，還增強了客戶與用戶的交互，使得用戶能夠在本地評價授權(quán)，而不需要等待應用服務器106的響應。在一種實施方案中，CON_REQ消息是利用在客戶102與應用服務器106之間共享的會話密鑰加密的。
接收到CON_REQ消息后，應用服務器106立即處理該CON_REQ消息，并利用作為加密ST票一部分接收的授權(quán)數(shù)據(jù)第一拷貝確認請求。如果沒有錯誤且內(nèi)容請求不違反授權(quán)數(shù)據(jù)的授權(quán)，則應用服務器106產(chǎn)生CON_REP消息并初始化客戶所請求內(nèi)容和/或服務的交付。一般地，所交付的內(nèi)容是由應用服務器106利用在客戶102與服務器106之間共享的會話密鑰加密的。
客戶102接收內(nèi)容、解密內(nèi)容并開始處理和使用內(nèi)容。在一種實施方案中，由于客戶102有一份授權(quán)數(shù)據(jù)的拷貝，因此客戶能夠確定所接收內(nèi)容和/或服務的授權(quán)使用。例如，通過檢查授權(quán)數(shù)據(jù)，客戶102可以確定客戶是否被授權(quán)存儲或保存內(nèi)容的拷貝。授權(quán)模塊122檢查授權(quán)數(shù)據(jù)并確定客戶的授權(quán)。如果客戶被授權(quán)，則當內(nèi)容被接收和解密后，客戶能夠保存它。此外，由于客戶有一份授權(quán)數(shù)據(jù)的拷貝，因此在一種通過授權(quán)模塊122的實施方案中，客戶102可以通過檢查授權(quán)進一步確定客戶是否能夠不止一次地回放或重用內(nèi)容。授權(quán)模塊122一般包括所存儲內(nèi)容的解密密鑰并拒絕解密沒有適當授權(quán)的內(nèi)容。確定客戶授權(quán)的能力是通過使用授權(quán)數(shù)據(jù)的第二拷貝實現(xiàn)的，其中這第二拷貝是客戶102在TGS_REP消息中接收并存儲以便本地使用的。這改進了客戶操作并限制了通過網(wǎng)絡的通信。
在一種實施方案中，系統(tǒng)100不需要為了讓客戶獲得ST票及授權(quán)數(shù)據(jù)的客戶拷貝而發(fā)生TGS_REQ和TGS_REP交換?？蛻?02向指定服務器，如應用服務器106，提交服務票請求AS_REQ。KDC 104處理該AS_REQ并返回用于第一個應用服務器的ST票，該ST票包括授權(quán)數(shù)據(jù)的第一拷貝。KDC還向客戶發(fā)送授權(quán)數(shù)據(jù)的第二拷貝，這第二拷貝格式化成被客戶102訪問與使用。一般地，KDC 104返回包括ST票的AS_REP，其中ST票具有授權(quán)數(shù)據(jù)的第一拷貝及授權(quán)數(shù)據(jù)的客戶拷貝。因此，客戶仍然能夠與ST票一起獲得授權(quán)數(shù)據(jù)的客戶拷貝，而不需要提交TGS_REQ。
圖2描述了根據(jù)本發(fā)明一種實施方案實現(xiàn)的系統(tǒng)101的簡化方框圖。在一種實施方案中，客戶102訪問第三方服務器140以選擇期望的內(nèi)容和/或服務，然后訪問應用服務器106，以便真正接收所選的內(nèi)容和/或服務。在選擇內(nèi)容和/或服務的過程中，客戶102利用授權(quán)數(shù)據(jù)的客戶拷貝。在向第三方服務器140提交對內(nèi)容和/或服務的選擇之前，客戶確定期望的內(nèi)容和/或服務，然后檢查授權(quán)數(shù)據(jù)的客戶拷貝以避免做出超出客戶授權(quán)的選擇。然后，客戶102向第三方服務器140發(fā)送該內(nèi)容和/或服務選擇。然后第三方服務器140驗證該內(nèi)容和/或服務選擇并向客戶102發(fā)送內(nèi)容和/或服務選擇應答消息，該應答消息包括應用服務器106用來對客戶授權(quán)并允許客戶獲得對選定內(nèi)容和/或服務的訪問的信息。因此，當應用服務器試圖根據(jù)第三方服務器信息確定客戶授權(quán)時，客戶102參考該授權(quán)數(shù)據(jù)并避免從第三方服務器140請求隨后將被應用服務器106拒絕的內(nèi)容和/或服務授權(quán)。
在一種實施方案中，第三方應用服務器140額外地還包括第三方信息的鑒別。這種鑒別由客戶102額外地轉(zhuǎn)發(fā)到應用服務器106，一般是在KEY_REQ消息中。應用服務器106利用這種鑒別來鑒別由客戶102提供給應用服務器的第三方服務器信息，以確保用于對用戶授權(quán)的信息確實從第三方服務器140提供給了客戶，而不是某個其它的網(wǎng)絡實體，也不是由客戶產(chǎn)生的某種假冒信息。
在向應用服務器106提交KEY_REQ消息的過程中，客戶102包括第三方服務器信息及它是否提供給客戶的鑒別。應用服務器106處理KEY_REQ消息，鑒別第三方服務器信息，并利用該信息驗證客戶授權(quán)。如上所述，一旦經(jīng)過了鑒別和驗證，應用服務器106就產(chǎn)生KEY_REP。
參考圖3，說明了用于向客戶提供由客戶使用的授權(quán)數(shù)據(jù)第二拷貝及使用來自應用服務器的內(nèi)容和/或服務的方法200的流程圖。作為示例，方法200可以由上述系統(tǒng)100及適當?shù)南㈩愋蛯崿F(xiàn)。在步驟202中，從客戶，如客戶102，接收TGT票請求。在步驟204中，產(chǎn)生TGT票。步驟204可以由例如AS服務器108執(zhí)行。在步驟206中，該TGT票發(fā)送到客戶。這一步也可以由AS服務器108執(zhí)行。在一種實施方案中，如果授權(quán)數(shù)據(jù)的客戶拷貝包括在AS_REP中，則客戶提取出該授權(quán)數(shù)據(jù)的客戶拷貝。在步驟208中，從客戶接收對特定應用服務器的ST票請求。ST票請求包括TGT票，而且一般不會顯文地提供客戶的身份。在步驟210中，產(chǎn)生包括ST票的TGS_REP消息，具有在ST票中的授權(quán)數(shù)據(jù)第一拷貝及利用來自TGT票的會話密鑰加密的授權(quán)數(shù)據(jù)第二拷貝。在一種實施方案中，TGS_REP的產(chǎn)生是由TGS服務器110執(zhí)行的。在步驟212中，具有兩份授權(quán)數(shù)據(jù)拷貝的TGS_REP消息發(fā)送到客戶，這一步也可以由TGS服務器110執(zhí)行。在步驟214中，客戶接收TGS_REP。在步驟216中，客戶從TGS_REP提取出至少授權(quán)數(shù)據(jù)的第二拷貝。在步驟220中，客戶產(chǎn)生并發(fā)送包括ST票的KEY_REQ消息，其中ST票進一步包括授權(quán)數(shù)據(jù)的第一拷貝。在步驟222中，應用服務器接收并處理KEY_REQ。應用服務器提取出ST票，解密ST票并確認授權(quán)數(shù)據(jù)的第一拷貝。在步驟224中，應用服務器產(chǎn)生KEY_REP消息并向客戶發(fā)送該KEY_REP消息。在步驟226中，客戶驗證該KEY_REP消息并將其與KEY_REQ消息匹配。
圖4描述了與圖3所述過程200類似的過程240一種實現(xiàn)的簡化流程圖。在步驟242中，客戶發(fā)送TGT票請求。在步驟244中，KDC104產(chǎn)生TGT票。在步驟246中，KDC 104發(fā)送帶客戶授權(quán)數(shù)據(jù)的客戶拷貝的TGT票。在步驟248中，客戶接收該TGT票并提取出授權(quán)數(shù)據(jù)的通用客戶拷貝。在步驟250中，客戶102發(fā)送請求ST票的TGS_REQ。在步驟252中，KDC返回TGS_REP。在步驟254中，客戶接收該TGS_REP并提取出ST票及服務器專用的授權(quán)數(shù)據(jù)第二拷貝。在步驟256中，客戶確定內(nèi)容和/或服務是期望的，然后訪問授權(quán)數(shù)據(jù)的客戶拷貝并驗證期望的內(nèi)容和/或服務，以避免請求超出授權(quán)的內(nèi)容和/或服務。在步驟258中，客戶102向第三方服務器140提交內(nèi)容和/或服務選擇。在步驟260中，第三方服務器發(fā)送內(nèi)容和/或服務選擇應答，該應答包括用于對客戶授權(quán)的第三方信息及這種信息的鑒別(例如，加密校驗和)。第三方信息包括可以用于驗證客戶授權(quán)的信息，例如客戶所選內(nèi)容的標識符；與該內(nèi)容關(guān)聯(lián)的各種購買選項，如“轉(zhuǎn)到信用卡”、“允許客戶保存這個內(nèi)容”及其它這類的信息。第三方信息還可以包括與內(nèi)容關(guān)聯(lián)的約束，如燈火管制區(qū)域的列表(例如，基于國家、州或郵政編碼的燈火管制區(qū)域)及其它這類的約束。在步驟262中，客戶102向應用服務器106發(fā)送不超出授權(quán)數(shù)據(jù)的KEY_REQ消息。KEY_REQ消息包括第三方信息及其鑒別與ST票，其中ST票進一步包括授權(quán)數(shù)據(jù)的第一拷貝。在步驟264中，應用服務器106利用第三方信息及授權(quán)數(shù)據(jù)的第一拷貝鑒別信息、驗證對內(nèi)容和/或服務的客戶授權(quán)。在步驟266中，應用服務器106向客戶102發(fā)送KEY_REP。
圖5描述了讓客戶從應用服務器請求并接收內(nèi)容和/或服務的過程310一種實現(xiàn)的簡化流程圖。在一種實施方案中，為了向客戶提供授權(quán)數(shù)據(jù)的第二拷貝，過程310跟在圖3所示過程200的步驟226后面。在步驟312中，客戶，如客戶102，確定期望什么內(nèi)容和/或服務。例如，客戶從用戶或其它網(wǎng)絡實體接收內(nèi)容請求。在步驟314中，通過檢查并比較該內(nèi)容請求與前面獲得并存儲的授權(quán)數(shù)據(jù)第二拷貝，客戶驗證內(nèi)容和/或服務請求以確保請求是授權(quán)的，而且沒有超出授權(quán)使用。一旦客戶驗證了請求，則客戶產(chǎn)生CON_REQ消息。在步驟316中，客戶利用加密校驗和進行加密、鑒別，并將CON_REQ消息發(fā)送給應用服務器，如應用服務器106(或第三方服務器140)。在步驟320中，根據(jù)加密校驗和及在ST票中可以找到的授權(quán)數(shù)據(jù)第一拷貝所定義的客戶授權(quán)訪問，應用服務器解密CON_REQ消息并確認請求。在步驟322中，如果ST票和授權(quán)數(shù)據(jù)都通過驗證了，則應用服務器加密并發(fā)送所請求的內(nèi)容和/或服務。在一種實施方案中，應用服務器在多個不同的分組中發(fā)送所請求的內(nèi)容，因此全部期望的內(nèi)容不是包含在單個分組中，而是在幾個分組中。在步驟324中，客戶接收所請求的內(nèi)容并處理數(shù)據(jù)。在步驟330中，客戶訪問他所存儲的授權(quán)數(shù)據(jù)的第二拷貝并確定客戶是否可以存儲內(nèi)容和/或服務的拷貝。在步驟332中，如果客戶被授權(quán)可以存儲，則客戶存儲內(nèi)容和/或服務。如果不可以，則當其第一次接收時，允許客戶訪問內(nèi)容，然后過程前進到步驟340，尋找另外的內(nèi)容。否則進入步驟344，在此客戶確定他是否可以不止一次地回放內(nèi)容。如果可以，則進入步驟346，在此客戶可以訪問并回放內(nèi)容一次或多次。在步驟340中，過程確定是否還有另外的內(nèi)容和/或服務要接收。如果有，則過程310返回步驟324，接收另外的內(nèi)容和/或服務。如果在步驟336中確定沒有更多的數(shù)據(jù)和/或內(nèi)容，則過程310終止。
本發(fā)明提供了允許客戶存儲并訪問其自己授權(quán)數(shù)據(jù)拷貝的方法、系統(tǒng)、程序、計算機程序產(chǎn)品。這為內(nèi)容和/或服務交付提供了改進的用戶接口、減少的錯誤、提高的效率及優(yōu)化。此外，允許客戶訪問其自己的授權(quán)數(shù)據(jù)拷貝使得客戶能夠做出關(guān)于所交付內(nèi)容和/或服務處理與使用的決定。還有，它降低了所需的通信量并降低了整體的網(wǎng)絡吞吐量。在一種實施方案中，本發(fā)明是在由Motorola公司開發(fā)的電子安全代理(ESBroker)協(xié)議中實現(xiàn)的，并且作為也是由Motorola公司開發(fā)的IP權(quán)限管理系統(tǒng)的一部分。
盡管在此已經(jīng)通過其指定實施方案及應用的方式公開了本發(fā)明，但在不背離權(quán)利要求所闡明的本發(fā)明范圍的前提下，本領(lǐng)域技術(shù)人員可以對其進行各種修改和變化。
權(quán)利要求
1.一種當從應用服務器請求內(nèi)容和/或服務時驗證客戶授權(quán)的方法，包括步驟產(chǎn)生包括授權(quán)數(shù)據(jù)的第一拷貝的服務票；及向客戶發(fā)送該授權(quán)數(shù)據(jù)的第二拷貝；及向客戶發(fā)送所述服務票。
2.如權(quán)利要求1所述的方法，還包括步驟產(chǎn)生包括服務票和授權(quán)數(shù)據(jù)的第二拷貝的AS_REP；及向客戶發(fā)送所述AS_REP。
3.如權(quán)利要求1所述的方法，還包括步驟產(chǎn)生包括服務票的票許可服務器應答(TGS_REP)；及向客戶發(fā)送所述票許可服務器應答。
4.如權(quán)利要求3所述的方法，還包括步驟從客戶接收鑒別服務器請求(AS_REQ)消息；產(chǎn)生鑒別服務器應答(AS_REP)消息；向客戶發(fā)送所述AS_REP；從客戶接收票許可服務器請求(TGS_REQ)消息；及產(chǎn)生TGS_REP的步驟包括產(chǎn)生具有兩份或多份授權(quán)數(shù)據(jù)拷貝的TGS_REP，其中包括授權(quán)數(shù)據(jù)的第二拷貝。
5.如權(quán)利要求3所述的方法，還包括步驟產(chǎn)生包括授權(quán)數(shù)據(jù)第二拷貝的鑒別服務器應答(AS_REP)消息；及向客戶發(fā)送AS_REP包括向客戶發(fā)送授權(quán)數(shù)據(jù)第二拷貝的步驟。
6.如權(quán)利要求3所述的方法，還包括步驟配置授權(quán)數(shù)據(jù)的第二拷貝，使得該授權(quán)數(shù)據(jù)的第二拷貝被客戶使用。
7.如權(quán)利要求6所述的方法，還包括步驟利用客戶會話密鑰加密授權(quán)數(shù)據(jù)的第二拷貝。
8.如權(quán)利要求7所述的方法，還包括步驟利用服務器服務密鑰加密服務票。
9.如權(quán)利要求7所述的方法，其中利用客戶會話密鑰加密的步驟包括利用來自AS_REP中票許可票的會話密鑰。
10.如權(quán)利要求6所述的方法，還包括步驟客戶確定期望的內(nèi)容；客戶利用授權(quán)數(shù)據(jù)的第二拷貝驗證期望的內(nèi)容；客戶產(chǎn)生內(nèi)容請求；客戶向第三方服務器發(fā)送內(nèi)容請求；及第三方服務器向客戶發(fā)送隨后應用服務器用于確定所請求內(nèi)容的客戶授權(quán)的第三方信息。
11.如權(quán)利要求6所述的方法，還包括步驟從客戶接收密鑰請求(KEY_REQ)；產(chǎn)生密鑰應答(KEY_REP)；向客戶轉(zhuǎn)發(fā)KEY_REP；客戶產(chǎn)生內(nèi)容請求；客戶利用授權(quán)數(shù)據(jù)的第二拷貝驗證內(nèi)容請求；及如果客戶驗證在內(nèi)容請求中沒有錯誤，則客戶向應用服務器發(fā)送該內(nèi)容請求。
12.如權(quán)利要求6所述的方法，還包括步驟接收內(nèi)容請求；向客戶發(fā)送至少一部分所請求的內(nèi)容；及配置授權(quán)數(shù)據(jù)第二拷貝的步驟包括配置授權(quán)數(shù)據(jù)的第二拷貝，使得客戶能夠利用該授權(quán)數(shù)據(jù)的第二拷貝確定至少所請求內(nèi)容的授權(quán)使用。
13.如權(quán)利要求12所述的方法，還包括步驟配置授權(quán)數(shù)據(jù)的第二拷貝，使得客戶能夠利用該授權(quán)數(shù)據(jù)的第二拷貝確定客戶是否被授權(quán)存儲所請求內(nèi)容的步驟。
14.如權(quán)利要求13所述的方法，還包括步驟配置授權(quán)數(shù)據(jù)的第二拷貝，使得客戶能夠利用該授權(quán)數(shù)據(jù)的第二拷貝確定客戶是否被授權(quán)回放所請求內(nèi)容的步驟。
15.一種系統(tǒng)，用于在系統(tǒng)上提供安全通信，包括配置成向客戶發(fā)票許可票(TGT)的密鑰分配中心(KDC)第一級；及配置成響應從客戶接收到的TGT產(chǎn)生票許可服務器應答的KDC第二級，該應答包括授權(quán)數(shù)據(jù)的至少兩份拷貝。
16.如權(quán)利要求15所述的系統(tǒng)，還包括配置成接收該票許可服務器應答并利用授權(quán)數(shù)據(jù)的一份拷貝驗證授權(quán)的客戶。
17.如權(quán)利要求15所述的系統(tǒng)，還包括與應用服務器耦合的客戶，其中應用服務器配置成向客戶提供內(nèi)容；及客戶進一步配置成利用授權(quán)數(shù)據(jù)的一份拷貝驗證內(nèi)容的授權(quán)使用。
18.一種用于向客戶提供對內(nèi)容和/或服務的訪問的系統(tǒng)，包括步驟產(chǎn)生包括授權(quán)數(shù)據(jù)第一拷貝的服務票的裝置；產(chǎn)生包括該服務票及授權(quán)數(shù)據(jù)第二拷貝的票許可服務器應答的裝置；及向客戶發(fā)送該票許可服務器應答的裝置。
19.如權(quán)利要求18所述的系統(tǒng)，其中產(chǎn)生票許可服務器應答的裝置包括利用客戶會話密鑰加密至少授權(quán)數(shù)據(jù)第二拷貝的裝置。
20.如權(quán)利要求19所述的系統(tǒng)，其中加密至少授權(quán)數(shù)據(jù)第二拷貝的裝置包括加密至少授權(quán)數(shù)據(jù)的第二拷貝，使得客戶能夠解密并利用該授權(quán)數(shù)據(jù)第二拷貝的裝置。
21.如權(quán)利要求20所述的系統(tǒng)，其中產(chǎn)生服務票的裝置包括利用服務器密鑰加密至少授權(quán)數(shù)據(jù)第一拷貝的裝置。
22.如權(quán)利要求18所述的系統(tǒng)，其中授權(quán)數(shù)據(jù)的第二拷貝配置成允許客戶驗證來自應用服務器的服務請求。
23.如權(quán)利要求18所述的系統(tǒng)，其中授權(quán)數(shù)據(jù)的第二拷貝配置成允許客戶確定所接收到內(nèi)容的授權(quán)使用。
24.一種系統(tǒng)，用于在系統(tǒng)上提供安全通信，包括配置成向客戶發(fā)票許可票(TGT)及至少授權(quán)數(shù)據(jù)的客戶拷貝的密鑰分配中心(KDC)第一級，其中授權(quán)數(shù)據(jù)的客戶拷貝配置成使客戶能夠確定客戶授權(quán)；及配置成產(chǎn)生票許可服務器應答的KDC第二級。
全文摘要
向客戶(102)提供授權(quán)數(shù)據(jù)拷貝的方法和系統(tǒng)，其中該授權(quán)數(shù)據(jù)拷貝是客戶可以訪問并利用的。該方法非常適合于利用票概念的密鑰管理協(xié)議。授權(quán)數(shù)據(jù)的兩份拷貝，客戶拷貝與服務器拷貝，包括在客戶請求用于指定應用服務器(106)的票的地方并轉(zhuǎn)發(fā)到客戶?？蛻裟軌蛟L問授權(quán)數(shù)據(jù)的客戶拷貝，使得客戶可以驗證請求并確定所請求內(nèi)容和/或服務的使用授權(quán)。
文檔編號H04L29/06GK1640092SQ03804561
公開日2005年7月13日 申請日期2003年1月2日 優(yōu)先權(quán)日2002年2月4日
發(fā)明者亞歷山大·梅德文斯基 申請人:通用儀器公司