專利名稱：服務協(xié)議的認可的制作方法
技術領域：
本發(fā)明通常涉及現(xiàn)代通信系統(tǒng)(如移動通信系統(tǒng))中，保證用戶和服務提供商之間交易安全可靠的方法。
背景技術：
今天的很多通信系統(tǒng)，包括移動通信系統(tǒng)，為增強系統(tǒng)安全性和健壯性而采用鑒定和加密過程。
如在移動通信系統(tǒng)中，用戶向網絡和/或服務提供者鑒定，以便獲得對基本網絡服務以及其它服務的訪問，并且該鑒定還充作給用戶記帳的基礎?，F(xiàn)代通信系統(tǒng)的基本安全協(xié)議通常涉及詢問-響應鑒定過程，通常主要基于密鑰加密。詢問-響應鑒定在本領域中是眾所周知的，并且存在若干種用于GSM(全球移動通信系統(tǒng))和UMTL(通用移動電信系統(tǒng))的基本詢問-響應鑒定上的標準。
在電子商務尤其是小型付款系統(tǒng)中，服務提供者最基本的是能夠證明用戶已經同意為一項服務付費(服務費用/服務協(xié)議的用戶認可)。
已知用于認可的技術通常采用基于公共密鑰加密方案的數字簽名，從計算角度講這種方法很昂貴。

發(fā)明內容
本發(fā)明克服了現(xiàn)有技術裝置的這些和其它缺點。
本發(fā)明的一個一般目標是提供為通信系統(tǒng)中的服務提供者和用戶之間的服務協(xié)議的認可提供有效健壯的方案。
本發(fā)明的一個目標是提供一種使服務提供者能夠證明或驗證用戶的確已經接受了給出的服務協(xié)議的方案。
例如，服務提供者可能會對能夠證明用戶已經同意為一項服務付費感興趣，包括接受的服務費用的驗證。
本發(fā)明的另一目標是為通信系統(tǒng)中改進的基于詢問-響應的鑒定和密鑰協(xié)定(AKA)提供一種機制。
這些和其它目標由所附權利要求定義的本發(fā)明來滿足。
簡單地說，本發(fā)明通常引入第三可信方，所謂的服務協(xié)議管理器。本發(fā)明所基于的思想是，服務協(xié)議管理器與用戶終端共享一個密鑰并且服務提供者與服務協(xié)議管理器有信用關系。本發(fā)明提出的認可方案還基于對相關服務協(xié)議信息的準備，根據共享密鑰對這個信息的加密處理，以便生成用戶簽署的服務協(xié)議驗證信息。用戶簽署的驗證信息隨后被轉發(fā)給服務提供者，以使能夠根據服務提供者和服務協(xié)議管理器之間的信用關系實現(xiàn)對該服務協(xié)議的驗證。
服務協(xié)議管理器可以是管理或參與管理服務提供者和用戶之間的服務協(xié)議的任意可信方，如可以實現(xiàn)在通信系統(tǒng)的網絡運營商端。
服務協(xié)議管理器甚至可以分散在不同結點或不同方之間，如可以包括用戶身份代理和安排在服務提供者和身份代理之間的付款代理。這種情況下，在服務提供者、付款代理和身份代理之間建起了一個信用鏈，而用戶終端通常與身份代理共享密鑰。
服務協(xié)議信息的準備通常是由服務提供者完成或初始化，但應該理解，只要用戶和服務提供者都接受該協(xié)議，這個信息就可以由所涉及各方中的任一方來準備。
對服務協(xié)議信息的加密處理通常在用戶端完成，但有些情況下也可以涉及服務協(xié)議管理器。優(yōu)選地，用戶終端根據從共享密鑰局部導出的認可密鑰進行加密處理，以便生成所需驗證信息。
服務提供者接收用戶簽署的驗證信息并有能力存儲這個信息的起碼的事實可以阻止用戶否認輸入的服務協(xié)議。如果希望或合適，可由服務協(xié)議管理器、甚至直接由服務提供者在線或離線進行實際驗證。
例如，服務協(xié)議管理器可以至少部分根據準備的服務協(xié)議信息和共享密鑰生成期望的驗證信息，并在需要時驗證從服務提供者轉發(fā)來的用戶簽署的驗證信息是否對應于期望的驗證信息。
用戶簽署的驗證信息可以由用戶終端響應從服務協(xié)議管理器發(fā)起的詢問或基于用戶端發(fā)起的記帳單而方便地生成，這兩種情況下都要結合給出的服務協(xié)議信息。
但是，也可在服務協(xié)議管理器端和用戶端都對服務協(xié)議信息進行加密處理。這種情況下，服務協(xié)議管理器優(yōu)選地根據共享密鑰生成服務協(xié)議信息的加密表示并把這個表示轉發(fā)給用戶終端(通常是通過服務提供者)，然后在用戶端會根據共享密鑰處理接收到的加密表示以生成正確的驗證信息。
例如，對基于記帳單的解決方案，服務協(xié)議管理器側的加密處理可以包括對基于準備的服務協(xié)議信息生成的記帳單的加密，用戶端處理則一般包括對加密的記帳單的解密。
應該理解，服務協(xié)議信息可以是一般的電子合同。但是，本發(fā)明已經證明在服務協(xié)議信息包括服務收費信息并且服務協(xié)議管理器充當付款提供者或代表服務提供者充當收費中心的應用中尤其有用。
對一般的合同簽署，一個允許服務提供者離線驗證的特殊設計的實施方案涉及通過相同掩蔽函數的本地實例掩蔽由服務協(xié)議管理器生成的期望的驗證信息以及用戶簽署的驗證信息。由服務協(xié)議管理器掩蔽根據共享密鑰和一般合同生成的期望的驗證信息并轉發(fā)給服務提供者。服務提供者從用戶端接收到用戶簽署的驗證信息并掩蔽它，因而能夠通過比較掩蔽后的期望驗證信息和掩蔽后的用戶簽署的驗證信息在服務提供者端驗證服務協(xié)議。
有利地，服務協(xié)議管理器通過作為基于正常詢問-響應的驗證和密鑰協(xié)定過程中的隨機詢問施加對合同的加密散列而生成期望的服務協(xié)議驗證信息。
在一系列特別有用的實施方案中，服務協(xié)議的認可與用于網絡接入的基于詢問-響應的驗證和密鑰協(xié)定(AKA)(例如GMS/UMTS AKA)過程集成在一起，使用通常用于AKA的相同共享密鑰。這意味著可以復用已有的基礎結構。
與本發(fā)明明顯相反，用于提供服務協(xié)議認可的現(xiàn)有技術是基于服務提供者和用戶終端之間直接的公共密鑰加密方案，采用不對稱密鑰對。
盡管不必要，但已經證明把用于服務協(xié)議認可的密鑰材料和用于普通AKA的密鑰材料分開還是有好處的。在這方面，用于認可的鍵控材料甚至可以被綁定到和鑒定管理器協(xié)同工作的特定付款代理，其中用戶終端與鑒定管理器共享密鑰。
在本發(fā)明的另一相關方面，采用了上述隔離方案以改進基于詢問-響應的驗證和密鑰協(xié)定(AKA)。簡單地說，通過用預定的函數(如偽隨機函數)把用于訪問由網絡運營商管理的網絡的第一組AKA參數同用于訪問由服務提供商提供的服務的第二組AKA參數分開，可以改進普通的AKA過程，用第一組AKA參數的至少一部分的表示作為生成第二組AKA參數的輸入。這樣做的優(yōu)勢是，即使用于服務訪問的密鑰材料丟失或被盜，它也不能被用于基礎網絡訪問。
本發(fā)明提供下列優(yōu)勢對通信系統(tǒng)中服務協(xié)議的有效健壯的認可防止用戶否認輸入的服務協(xié)議為網絡運營商提供充當可信服務協(xié)議管理器的新的商業(yè)可能。例如，運營商可以獲得付款過程中的自然角色。
擴展基本的詢問-響應過程(如UMTS/GSM AKA)的有效途徑，使得能夠將付款協(xié)議綁定到用戶鑒定。
用現(xiàn)有基礎結構方便遷移。
容易實現(xiàn)，不必引入新的GSM或UMTS用戶標識模塊(SIM)。反正總要改變終端以容納新的付款協(xié)議。
在閱讀下面對本發(fā)明實施方案的描述后會理解本發(fā)明所提供的其它優(yōu)勢。
附圖概述參考下面結合附圖所作的描述能夠最好地理解本發(fā)明以及其中的更多目標和優(yōu)勢，附圖中

圖1是依照本發(fā)明的優(yōu)選實施方案的基本參與者和它們的相互關系的示意簡圖；圖2是當移動用戶漫游到一個被訪網絡時移動通信系統(tǒng)中主位置鑒定的信號交換示意圖；圖3是用于以今天通常實現(xiàn)在蜂窩系統(tǒng)中的方式帶有委托驗證的鑒定的信號交換示意圖；圖4是依照本發(fā)明的優(yōu)選實施方案為所提出的服務協(xié)議認可通用方案示出整體結構和基礎的示意圖；圖5是使用專用認可密鑰的服務協(xié)議認可以及可能的離線驗證的示例性信號交換示意圖；圖6A是使用專用認可密鑰的服務協(xié)議在線驗證的示例性信號交換示意圖；圖6B是使用已有的AKA密鑰作為認可密鑰的服務協(xié)議在線驗證的示例性信號交換示意圖；
圖7A是通過掩蔽后的鑒定數據結合服務協(xié)議的離線驗證建立用戶鑒定證據的示例性信號交換示意圖；圖7B是對服務協(xié)議的認可使用專用密鑰或已有的AKA密鑰，通過掩蔽后的鑒定數據結合鑒定及服務協(xié)議的在線驗證建立用戶鑒定證據的示例性信號交換示意圖；圖8A是基于記帳單的認可以及可能的在線驗證的示例性信號交換示意圖；圖8B是基于記帳單的認可以及在線驗證的示例性信號交換示意圖；圖9是基于記帳單的認可的示例性信號交換示意圖，其中基本記帳單是由鑒定/付款管理器代表用戶準備的；圖10是基于引入允許服務提供者離線驗證的掩蔽后的驗證數據的合同簽署的示例性信號交換示意圖；圖11是圖10的合同簽署實現(xiàn)的示例性信號交換示意圖；圖12A是基于不同的分離的密鑰組的AKA-集成服務協(xié)議認可以及可能的離線驗證的示例性信號交換示意圖；圖12B是基于不同的分離的密鑰組的AKA-集成服務協(xié)議認可以及在線驗證的示例性信號交換示意圖；圖13是引入身份代理以及付款代理，采用身份代理、付款代理和服務提供者之間建立起的信用鏈的分布式實現(xiàn)的示例性示意框圖；圖14是圖13所示配置的后付費場景中服務協(xié)議認可的示例性信號交換示意圖；圖15是圖13所示配置的預付費場景中服務協(xié)議認可的示例性信號交換示意圖；圖16是依照本發(fā)明的優(yōu)選實施方案示出服務協(xié)議管理器的一個示例的示意框圖；圖17是依照本發(fā)明的優(yōu)選突施方案示出服務提供者的一個示例的示意框圖；圖18依照本發(fā)明的優(yōu)選實施方案示出用戶終端的一個示例的示意框圖。
發(fā)明實施方案詳述貫穿這些圖中，相同的參考字符將用于相應或相同的部件。
綜述從參考圖1概述基本參與者和他們的相互關系開始可能會有益一些，圖1是依照所提出的發(fā)明的通信系統(tǒng)的示意概觀。
基本參與者包括用戶10、服務提供者20和通常稱為信用提供者30的附加方，信用提供者可以代表服務提供者和/或用戶完成不同的任務。信用提供者30和用戶(或者是正確配置的用戶終端)之間有通過共享密鑰建立起的信用關系。信用提供者30和服務提供者20可以有一個表明為契約形式的信用關系的協(xié)議。用戶10和服務提供者20之間的關系通常看作是導出的信用關系，這種信用關系是在請求或啟動由服務提供者提供的服務時建立的。
信用提供者可以和用戶與之有信用關系的網絡運營商相關，例如這種信用關系是通過訂購或預付費帳戶而建立的。
這個建立的信用關系通常通過激活詢問-響應過程(如用于GSM/UMTS的AKA(驗證與密鑰協(xié)定)過程和/或類似的過程)的共享密鑰以加密關系表明。網絡運營商可以和服務提供者有協(xié)議，該協(xié)議通常由類似的加密關系表明。服務提供者隨后可以為和它們的服務的終端用戶進行間接相互驗證采用詢問-響應過程，例如GSM/UMTSAMA。
已知當一個移動用戶漫游到由所謂被訪運營商管理的另一網絡中時，使用歸屬運營商作為用戶驗證的信用基礎，如圖2和圖3的示意說明。
圖2是當一個移動用戶漫游到一個被訪網絡中時由移動通信系統(tǒng)中的歸屬運營商用在線驗證進行用戶鑒定的信號交換示意圖。
基本的UMTS AMA過程采用共享密鑰Ki，例如與用戶-運營商訂購相關的訂購密鑰或從中導出的密鑰，以產生對詢問的響應以及兩個會話密鑰，一個用于機密性保護(Ck)，一個用于用戶和被訪運營商之間流量完整性保護(Ik)。歸屬運營商，或者更確切地說是HSS/AuC(主用戶服務器/鑒定中心)和HLR/AuC(HLR，歸屬位置寄存器)，生成一個隨機詢問(RAND)以及鑒定令牌(AUTN)，鑒定令牌后來由用戶用來驗證詢問是新的并且是由歸屬運營商生成的。從這個詢問用共享密鑰計算響應(RES/XRES)和密鑰(Ck，Ik)。在GSM AKA中，不生成完整性密鑰或鑒定令牌，但基本的詢問-響應過程是相同的。共享密鑰通常實現(xiàn)在GSM移動裝置中所用的SIM卡或UMTS移動裝置中所用的UMTS SIM卡(USIM)，取決于AKA實現(xiàn)。
參考圖2，它或多或少地與標準可擴展鑒定協(xié)議(EAP)對應，下面總結了實現(xiàn)所需信令的一種途徑在初始階段，用戶發(fā)送標識符到被訪運營商，并且被訪運營商將該標識符轉發(fā)到歸屬運營商。根據這個標識符，歸屬運營商端的HSS/AuC或等效單元獲取相應的密鑰，生成一個五位字節(jié)(RAND、AUTN、Ck、Ik、XRES)并發(fā)送1.詢問(RAND)、鑒定令牌(AUTN)到被訪運營商。這些參數由被訪運營商轉發(fā)給用戶。
2.詢問(RAND)、鑒定令牌(AUTN)用戶檢查該AUTN，如果沒有問題，就計算響應(RES)、機密性密鑰(Ck)和完整性密鑰(Ik)。響應通過被訪運營商發(fā)回歸屬運營商3.響應(RES)4.響應(RES)歸屬運營商檢查RES是否等于期望的響應(XRES)。如果是就把密鑰安全地傳送到被訪運營商。
5.完整性和機密性密鑰(Ik和Ck)。
歸屬運營商看到來自終端用戶的RES并證實該終端用戶已經通過被訪運營商通過鑒定。但是，歸屬運營商沒有該用戶已經接受了什么服務的證據。
如果以今天在蜂窩系統(tǒng)中所做的方式實現(xiàn)該信令，那么歸屬運營商甚至將沒有用戶鑒定的證據。這種情況下，參考圖3，信令如下1.RAND、AUTN、Ik、Ck、XRES2.RAND、AUTN用戶檢驗AUTN，如果沒有問題，就計算響應RES、機密性密鑰Ck和完整性密鑰Ik。
3.RES被訪網絡檢查RES是否等于XRES。如果是，則該用戶通過驗證。
對服務協(xié)議認可的示例性通用方案圖4是為依照本發(fā)明的優(yōu)選實施方案所提出的服務協(xié)議認可通用方案示出整體結構和基礎的示意圖。
發(fā)明人已經認識到服務提供者必須能夠證明用戶已經接受了給出的用戶協(xié)議，尤其是用戶已經同意為該服務付費，包括接受的服務費用的驗證(服務協(xié)議/服務費用的用戶認可)。這在通過或借助第三可信方(如網絡運營商或等效方)進行用戶鑒定和付款/收費時尤其重要。
因此，為了服務提供者和用戶之間的服務協(xié)議認可起見，提議信用提供者30代表服務提供者和/或用戶充當通用服務協(xié)議管理器。依照本發(fā)明的優(yōu)選基本實施方案的認可方案包括對相關服務協(xié)議信息的準備，以及根據服務協(xié)議管理器和用戶終端之間共享的密鑰對準備的信息的加密處理，以便生成用戶簽署的服務協(xié)議驗證信息。用戶簽署的驗證信息隨后被轉發(fā)給服務提供者，以能夠根據服務提供者和服務協(xié)議管理器之間的信用關系實現(xiàn)對服務協(xié)議的驗證。
適當電子形式的服務協(xié)議信息(電子合同)的準備通常是由服務提供者在合同準備/初始化單元22中完成或至少由它初始化的，但這個信息可以由涉及到的任意一方準備，只要用戶和服務提供者接受該協(xié)議。例如，服務協(xié)議管理器30可以選擇代表服務提供者20準備該服務協(xié)議信息。
對服務協(xié)議信息的加密處理通常是在用戶端在用戶終端10中的防篡改模塊12中完成。優(yōu)選地，用戶終端10根據從共享密鑰局部導出的認可密鑰在加密引擎14中完成加密處理，以便生成所需的驗證信息。但是，在一些實現(xiàn)中，加密處理可以由用戶終端10在加密引擎14中并且由服務協(xié)議管理器30在加密引擎34中完成。
用戶簽署的驗證信息被安全地從用戶終端10轉發(fā)到服務提供者20的起碼的事實可能有拒絕-阻止效果。但是，優(yōu)選地，驗證是由服務協(xié)議管理器在線或離線進行的，或者由服務提供者直接進行。在離線過程中，驗證信息包括至少用戶簽署的驗證部分，并且優(yōu)選地還包括相應的詢問或和用戶身份一塊兒的其它輸入，驗證信息通常被存儲在一個存儲單元中，服務提供者20隨后可從該存儲單元獲取驗證信息并提供其作為用戶已經接受該服務協(xié)議的證據。在在線過程中，驗證信息通常被從服務提供者20或多或少地直接轉發(fā)給服務協(xié)議管理器30，由此激活在線證據。根據給出的驗證信息，服務協(xié)議管理器30隨后可以進行相關的計算和/或比較，以在驗證單元36中驗證用戶是否已經實際接受了該服務協(xié)議。
服務協(xié)議管理器可以方便地與包括用戶ID和一組用戶的相關密鑰Ki的數據庫相關聯(lián)。這使得服務協(xié)議管理器能夠出于各種目的(例如生成用戶鑒定參數、服務協(xié)議信息和/或服務協(xié)議驗證的加密處理)根據相應的用戶ID訪問給定用戶的相關密鑰。
如后所述，驗證還可以由服務提供者20在驗證單元26中直接進行。
服務提供者20和服務協(xié)議管理器30之間的信用關系應該為服務提供者關于所做聲明或由服務協(xié)議管理器提供的數據提供保證。因為發(fā)送的信息(例如，服務協(xié)議信息、計費數據、鑒定參數和/或其它適當的信息)通常被看作是敏感的并且通信方的身份是上述保證所必需的，所以服務提供者和服務協(xié)議管理器之間的通信鏈路應該是安全的。這可以通過(如)使用TLS或IPSec或加密/簽署單個消息而實現(xiàn)。
服務協(xié)議的AKA-集成認可/驗證從在服務協(xié)議的AKA-集成認可/驗證環(huán)境中開始描述本發(fā)明可能會有用一些。
在一系列優(yōu)選實施方案中，服務協(xié)議的認可尤其是服務費用是和用于網絡訪問的基于詢問-響應的鑒定和密鑰協(xié)定(AKA)(例如GMS/UMTS AMA或類似的鑒定)集成在一起的，使用通常為AKA所采用的相同共享密鑰。采用AKA-集成的認可的很大優(yōu)勢是可以復用已有的基礎結構。
在這個上下文中，通常假定可信服務協(xié)議管理器為鑒定用戶、授權用戶訪問服務和/或建立用戶已經同意服務使用條件的證據而充當鑒定/付款管理器。在典型場景中，網絡運營商可以將鑒定/付款管理器實現(xiàn)為用于建立用戶和訪問點之間的可靠和安全通信的安全系統(tǒng)。運營商還和服務提供者有信用關系并在這些安全鏈路上與它們通信。響應服務訪問請求，鑒定/付款管理器采用與發(fā)出請求的用戶共享的密鑰(通常表示為Ki)以幫助鑒定、受權、認可和/或付款或收費過程。
關于服務費用，為服務付費的用戶協(xié)議可以被綁定到UMTS/GSMAMA或類似鑒定。這優(yōu)選地應該以可以向服務提供者確保用戶不會在后來階段拒絕服務協(xié)議的這種方式來實現(xiàn)。
圖5是使用專用認可密鑰的服務協(xié)議認可以及可能的離線驗證的示例性信號交換示意圖。在這個例子中，用附加會話密鑰以及附加服務協(xié)議信息的獲取擴展了普通的詢問-響應(AKA)方案，所獲取的附加會話密鑰將只在用戶和運營商之間共享。
考慮到想要訪問由服務提供者提供的服務的用戶。通常在提供服務之前必須鑒定該用戶。用戶ID不必是一個公共標識符，但它應該允許映射到一個用戶相關的密鑰Ki，它能使得對正確的帳戶正確地進行收費。例如，如果用戶和歸屬運營商有訂購關系，密鑰Ki可以是訂購密鑰，或者是與預付費帳號相關的加密密鑰。用戶ID的傳輸通常由虛線表示，因為這可以看作是初始化階段，還部分因為這可能是服務提供者和運營商之間的鑒定向量批處理的一部分。通常需要服務提供者從用戶接收能夠用于確定與用戶相關的鑒定/付款管理器的身份的信息；例如用戶的歸屬運營商的身份。這使得服務提供者能夠在對AKA參數的請求中轉發(fā)用戶ID到相關鑒定/付款管理。根據接收到的用戶ID，鑒定/付款管理器識別出密鑰Ki并生成適當的AKA參數。鑒定/付款管理器生成隨機詢問RAND并根據密鑰Ki和隨機詢問RAND為給定函數g的輸入而計算出期望的響應XRES，并且還根據Ki和RAND生成普通的完整性和機密性密鑰Ik和Ck。
用戶應該還同意為該服務付費。協(xié)議應該使得服務提供者以后能夠證明用戶確實同意了協(xié)議。這里的思想是在進行用戶鑒定和密鑰協(xié)定并且生成鑒定參數(如RAND和XRES，以及完整性和機密性密鑰Ik、Ck)的同時，生成附加的服務協(xié)議認可密鑰，表示為Rk。
下面總結了基本的示例性信號交換1.RAND、AUTN、Ik、Ck、XRES服務提供者生成服務協(xié)議信息，所生成的服務協(xié)議信息包括一個或多個信息項，如服務標識、服務費用、有效次數、服務提供者標識符等等。下面，通過表示一個給定值(服務單元費用)的費用參數COST_UNIT舉例說明服務協(xié)議信息。如果希望的話，這個費用參數還可伴隨一個nonce以將其隨機化、伴隨一個時間戳以指示有效時間、還可伴隨服務標識符和服務提供者標識符。
2.RAND、AUTN、COST_UNIT用戶檢查AUTN，如果沒有問題，就按照標準AKA方案計算響應RES、機密性密鑰Ck和完整性密鑰Ik。除此之外，擴展AKA方案生成認可密鑰Rk，它也基于共享密鑰Ki和RAND。Rk隨后被用來在RAND和COST_UNIT之上計算MAC(消息鑒定碼)COST_MAC。COST_MAC＝MAC(Rk，RAND||COST_UNIT)。COST_MAC和鑒定響應RES一起被返回給服務提供者。服務提供者絕不能偽造系統(tǒng)的COST_MAC以實現(xiàn)認可目的。
3.RES、COST_MAC服務提供者檢查RES是否匹配XRES。服務提供者還保留驗證信息，例如用戶ID、RAND、COST_UNIT和COST_MAC以用用戶協(xié)議以后的證據。
如果需要或受到請求，服務提供者可在以后將驗證信息轉發(fā)給運營商端的鑒定/付款管理器。
4.COST_UNIT、COST_MAC、USER ID、RAND運營商端的鑒定/付款管理器隨后充當驗證器并檢查COST_MAC是否等于期望的XMAC＝MAC(Rk，RAND||COST_UNIT)以驗證用戶已經接受了服務協(xié)議和服務費用。
當然，存在用戶偽造COST_MAC的可能。為此目的，可以用一些策略對COST_MAC進行隨機的在線測試，以防止用戶有這種動作。
本質上，這個示例性方法是基于用運營商和用戶之間共享的認可密鑰擴展基本AKA，但這個認可密鑰并沒有發(fā)布給服務提供者。這個認可密鑰可由用戶用來“簽署”消息，而運營商能夠驗證用戶“簽署”了的消息。如上所述，一個示例性解決方案是用從RAND導出的密鑰將MAC數據連同RAND一起發(fā)送給用戶并驗證數據的可靠性。
應該理解，首先完成普通AKA信令、在服務提供者處驗證RES是否等于XRES、并且隨后當用戶在安全鏈路上向服務提供者請求服務時完成認可信令同樣可行。這意味著服務提供者在成功的用戶鑒定后，在接收到來自用戶的服務請求時發(fā)送費用參數COST_UNIT和相關信息給用戶。用戶隨后計算COST_MAC并返回COST_MAC給服務提供者，以激活對服務協(xié)議的驗證。
圖6A是用專用認可密鑰對服務協(xié)議進行在線驗證的示例性信號交換示意圖。這個示例涉及在線用戶鑒定和服務協(xié)議驗證。
下面總結了基本的示例性信號交換1.RAND、AUTN服務提供者生成相關的服務協(xié)議信息，如服務費用參數COST_UNIT以傳輸給用戶。
2.RAND、AUTN、COST_UNIT用戶檢查AUTN，如果沒有問題，就計算響應RES、機密性密鑰Ck、完整性密鑰Ik以及認可密鑰Rk。計算COST_MAC并將它和對鑒定的響應RES一起返回給服務提供者。
3.RES、COST_MAC對在線驗證，服務提供者轉發(fā)RES到運營商端。也可同時把COST_UNIT和COST_MAC附加到RES后。
4.RES、COST_UNIT、COST_MAC鑒定/付款管理器檢查RES是否等于期望的響應(XRES)以及COST_MAC是否等于期望的XMAC。如果用戶有一個預付費帳戶，管理器還可以檢查該用戶在他的帳號上是否有足夠的存款。如果這些條件都滿足就把密鑰發(fā)送給服務提供者。
5.Ik、Ck當服務提供者接收到用于保護用戶和服務提供者之間的會話的密鑰時，這還表示服務協(xié)議沒有問題。
另外，如前參考離線情況所述，首先完成普通AKA信令、并且隨后當用戶在安全鏈路上向服務提供者請求服務時再完成認可信令是可行的。這通常意味著驗證RES并將密鑰Ik、Ck發(fā)送給服務提供者，并且隨后由服務提供者在收到服務請求時啟動特殊的認可信令。但是，下面將主要用集成AKA和認可信令描述AKA-集成的示例。
圖6B是使用已有的AKA密鑰作為認可密鑰對服務協(xié)議進行在線驗證的示例性信號交換示意圖。如果服務提供者總是在從運營商端送出密鑰之前就進行服務協(xié)議的在線驗證，那么COST_MAC將和Ik結合在一起作為認可密鑰并且不必擴展AKA，以生成特殊的認可密鑰Rk。但是，服務提供者將沒有記錄并保持服務協(xié)議證據的能力，因為他隨后將接收密鑰Ik用于會話的完整性保護。運營商可以保持對協(xié)議的散列，以使服務提供者不能回去改變數據。
結合掩蔽后的鑒定數據的認可如圖7A和圖7B所示，可以更改用戶鑒定以通過引入掩蔽后的驗證數據而允許標識證據，因而使服務提供者能夠提供用戶已經被實際鑒定通過的有效證據。
該總體鑒定最初是基于詢問-響應過程，在該過程中鑒定/付款管理器生成期望響應XRES并且用戶隨后生成相應的響應RES。這里的基本思想是引入一個掩蔽函數f，它掩蔽生成的期望響應，并傳輸掩蔽后的期望響應XRES’而不是最初的期望響應XRES給服務提供者。用戶以傳統(tǒng)方式生成并傳輸相應的用戶響應RES，并且服務提供者因而從運營商端接收掩蔽后的期望響應XRES’，以及從用戶接收普通用戶響應RES。服務提供者隨后通過在運營商端所用相同掩蔽函數的一個實例計算掩蔽后的用戶響應RES’。為了鑒定用戶，服務提供者簡單地驗證計算出的掩蔽后的用戶響應RES’是否與從運營商端接收到的掩蔽后的期望響應XRES’對應。該掩蔽過程使得服務提供者能夠證明用戶已經被正確地鑒定通過，并且同時還防止和/或解除了竊取攻擊。
隨后可以在付款被傳輸之前詢問服務提供者以提供響應值、或者優(yōu)選地響應-詢問對和/或服務協(xié)議驗證信息，以證明該用戶已經實際位于該網絡中和/或使用了其它服務。
顯然，鑒定/付款管理器和服務提供者之間有關系，它們之間的關系意味著已經在鑒定/付款管理器和服務提供者之間交換了掩蔽函數。這對那些必須對兩方共同的類似信息和/或函數也是正確的。
圖7A是通過掩蔽后的鑒定數據結合服務協(xié)議的離線驗證建立用戶鑒定證據的示例性信號交換示意圖。除了普通AKA參數之外，鑒定/付款管理器按照XRES和可選掩蔽隨機詢問SALT的函數生成掩蔽后的期望響應XRES’。例如，掩蔽隨機詢問可以基于隨機詢問RAND或者生成為完全獨立的隨機值。隨后，發(fā)送掩蔽后的期望響應XRES’和隨機詢問RAND到服務提供者，可能連同可選的掩蔽隨機SALT。如果使用帶Rk的服務協(xié)議離線驗證，那么就能夠連同RAND、AUTN和XRES’一起發(fā)布Ik和Ck。
下面總結了基本的示例性信號交換1.RAND、AUTN、XRES’、Ik、Ck、[SALT]2.RAND、AUTN、COST_UNIT3.RES、COST_MAC服務提供者隨后用相同掩蔽函數f的一個實例和相同隨機輸入RAND/SALT生成RES’并檢查掩蔽后的響應RES’是否等于掩蔽后的期望響應XRES’。服務提供者優(yōu)選地在適當位置(以為后來獲取)存儲RES、RAND、USER作為鑒定證據信息，連同COST_UNIT、COST_MAC作為服務協(xié)議驗證信息，如果必要的話還作為用戶鑒定和服務協(xié)議的證據。如果受到鑒定/付款管理器或一些其它相關方面詢問要求提供給定用戶的鑒定證據和接受的服務協(xié)議，服務提供者可以把該信息發(fā)送給運營商一方。
4.RES、RAND、USER ID、COST_UNIT、COST_MAC應該注意到可以離線傳輸由服務提供者提供的多種服務的多批隨機的服務協(xié)議驗證信息而不需要任何重新驗證。
優(yōu)選地，鑒定/付款管理器隨后取出與給定用戶相關的密鑰Ki并根據接收到的RAND和密鑰Ki計算期望響應值XRES，并最后比較接收到的RES值和計算出的XRES值，以驗證用戶是否已經在服務器提供者處被鑒定通過。如果RES值匹配XRES值，就認為證明信息有效。用相同的方式，鑒定/付款管理器根據從服務提供者接收的認可密鑰Rk和RAND、COST_MAC計算期望的服務協(xié)議驗證信息XMAC。鑒定/付款管理器隨后比較COST_MAC和XMAC以驗證服務協(xié)議。
另外，服務提供者簡單地傳輸給定用戶的RES值和用戶ID。這種情況下，鑒定/付款管理器通常需要為用戶存儲XRES值(或者允許重新計算相應XRES值的RAND值)以使能夠在RES和XRES之間進行比較。
如果從鑒定/付款管理器沒有顯式地發(fā)送可選的掩蔽隨機詢問SALT，服務提供者可以在鑒定的驗證之前導出它，優(yōu)選地根據隨機詢問RAND。隨后由服務提供者通過用戶響應RES和可選的、接收到的或導出的掩蔽隨機詢問SALT作為掩蔽函數f的輸入，計算掩蔽后的用戶響應RES’。
如上，掩蔽隨機詢問SALT是可選的，并且可以從鑒定過程忽略掉。這種情況下，沒有隨機詢問SALT分別是用于計算掩蔽后的期望響應XRES’和掩蔽后的用戶響應RES’的掩蔽函數f的輸入。但是，為了增加安全性，尤其是戰(zhàn)勝預計算攻擊，優(yōu)選地包括掩蔽隨機詢問SALT作為掩蔽函數輸入。因而，掩蔽隨機詢問SALT可以由鑒定/付款管理器生成為完全的隨機值并且隨后和掩蔽后的期望響應XRES’和隨機詢問RAND一起被發(fā)送到服務提供者。但是，為了避免運營端和服務器提供者之間的額外信令，也可以從隨機詢問RAND導出掩蔽隨機詢問SALT。這種情況下，鑒定/付款管理器優(yōu)選的由隨機詢問RAND的某一函數h生成掩蔽隨機詢問SALT。因此，不需要向服務提供者發(fā)送特殊的掩蔽隨機詢問SALT，而可以用相同的函數h從隨機詢問RAND生成掩蔽隨機詢問SALT?？捎醚诒魏蟮碾S機詢問SALT的示例只是簡單地復用隨機詢問RAND作為掩蔽后的隨機詢問SALT，而h因此被表示為單一函數。
函數h可以是公共函數或與服務提供者和鑒定/付款管理器的法人(例如歸屬運營商)之間的商業(yè)協(xié)議相關或一起發(fā)布的函數。
一方面由鑒定/付款管理器用它來生成掩蔽后的期望響應，別一方面由服務提供者用它計算掩蔽后的用戶響應的函數f可以是單向函數和/或散列函數。優(yōu)選地，掩蔽函數是加密散列函數，具備使之不能適合找到兩個散列到一個公共值的不同輸入的單路功能和屬性。
掩蔽函數f可以是公共函數，或者鑒定/付款管理器和服務提供者所知道的專用函數。在后一種情況中，專用掩蔽函數可以和鑒定/付款管理器的法人(例如給定的歸屬運營商)和服務提供者之間的商業(yè)協(xié)議相關。如果鑒定/付款管理器的法人，例如歸屬運營商，和幾個不同的服務提供者有這種商業(yè)協(xié)議，可以由該運營商為每個服務提供者使用一個相應的專用函數，即每個運營商-提供者協(xié)議以一個專用掩蔽函數表明。
為了能夠順利進行與已有的基礎結構有關的遷移，優(yōu)選地當計算分布的期望響應時，要通知服務提供者是否已經采用了掩蔽函數。因而，優(yōu)選地用這樣的指示擴展用于發(fā)布鑒定參數的協(xié)議。同樣，如果存在不同掩蔽函數之間的選擇，還可以在協(xié)議中包括要使用哪個掩蔽函數的指示。
如果希望在線過程，如圖7B所示，就或多或少地直接把鑒定證明信息和服務協(xié)議驗證信息從服務提供者轉發(fā)到鑒定/付款管理順。
下面總結了基本的示例性信號交換1.RAND、AUTN、XRES’、[SALT]2.RAND、AUTN、COST_UNIT3.RES、COST_MAC服務提供者生成RES’并檢查掩蔽后的響應RES’是否等于掩蔽后的期望響應XRES’。然后信令繼續(xù)進行。
4.RES、COST_UNIT、COST_MAC在運營商一方，分別比較RES、COST_MAC和XRES、XMAC。如果驗證成功，就把密鑰安全地傳輸給服務器提供者。
5.Ik、Ck如前所述，對服務協(xié)議的在線驗證，可以使用專用認可密鑰Rk或完整性密鑰Ik作為計算COST_MAC和XMAC參數的認可密鑰。
對于掩蔽過程上的更多信息，參考我們的共同未決US專利申請序列號10/278,362，2002年10月22號提交，在此引入它。
示例性基于記帳單的方法下面我們將描述采用基于記帳單的方法的服務協(xié)議AKA-集成認可的一些例子。
在文獻中基于記帳單的付款系統(tǒng)通常是眾所周知的，如參見US專利5,739,511.
一種特別的記帳單系統(tǒng)是基于由已知散列函數重復(給定數量的)N次散列BASE_TICKET到START_TICKET中的思想START_TICKET＝HASH(HASH(..HASH(BASE_TICKET)))，其中BASE_TICKET通常對應于TICKET_N，而START_TICKET對應于TICKET_0.付費方生成START_TICKET或所用的最終TICKET的原象。接收付款的一方隨后可以檢查該原象是否散列到那個記帳單中。因為記帳單是由散列函數或者其它適當的單向函數相互關聯(lián)的，可以通過重復應用該函數而從任意更多的記帳單獲得START_TICKET。這意味著不需要重復進行復雜耗時的驗證過程就能獲得對付款事務進度的檢查。必須應用散列函數以獲得起始記帳單的次數與服務的用戶所消耗的記帳單的數量直接相關。
這種基于記帳單的系統(tǒng)要安全的一個條件是基本記帳單是不可預測的。因而可以通過級聯(lián)一些隨機實體和其它已知信息元素的散列形成基本記帳單。
依照本發(fā)明，可以用這種方式擴展先前描述的認可方案以及它的變型，以使用戶能夠返回START_TICKET和START_TICKET和COST_UNIT的加密認可MAC(表示為TICKET_MAC)以使能夠對若干事件/服務進行認可的付款，而不必和運營商之間有重復協(xié)議或者執(zhí)行新的用戶鑒定。
怎樣生成START_TICKET有若干變型。主要的特征是服務提供者應該能夠驗證START_TICKET是真實的，并且是由鑒定通過的用戶發(fā)出或者是代表鑒定通過的用戶而發(fā)出的。
記帳單生成的一個特定解決方案是用戶生成BASE_TICKET并導出START_TICKET。用戶隨后使用認可密鑰(如Rk)并在START_TICKET和COST_UNIT之上計算認可TICKET_MAC，并且發(fā)送START_TICKET和TICKET_MAC給服務提供者。服務提供者或者為離線過程中可能的后來驗證存儲驗證信息，或者把該消息在線發(fā)送給運營商一方驗證TICKET_MAC以接受該記帳單。
圖8A是基于記帳單的認可以及可能的離線驗證的示例性信號交換示意圖。
下面總結了基本的示范性信號交換1.RAND、AUTN、Ik、Ck、XRES服務提供者生成相關的服務協(xié)議信息，這里通過費用參數COST_UNIT舉列說明，并且優(yōu)選地把這個信息以及必需的AKA參數發(fā)送給用戶。
2.RAND、AUTN、COST_UNIT用戶檢查AUTN，如果沒有問題，就計算RES、密鑰Ik、Ck，優(yōu)選地還有Rk。用戶生成BASE_TICKET并通過重復散列選定的次數而得到START_TICKET。Rk隨后被用來在START_TICKET和COST_UNIT之上計算TICKET_MAC，TICKET_MAC＝MAC(Rk，START_TICKET||COST_UNIT)。如果希望有明顯的隨機化，也可以按照MAC(Rk，START_TICKET||COST_UNIT||RAND)計算TICKET_MAC。TICKET_MAC和START_TICKET連同RES都被返回給服務提供者。
3.RES、START_TICKET、TICKET_MAC服務提供者為以后的服務協(xié)議證明保留驗證信息，例如用戶ID、RAND、COST_UNIT和COST_MAC。
因為記帳單是由用戶使用的，服務提供者可以為每個帳單檢查TICKET-i-＝HASH(TICKET-i)，或者可以通過反復應用散列函數獲得START-TICKET。如果需要或者請求，服務提供者可以在以后轉發(fā)驗證信息，如COST_UNIT、START_TICKET、LAST_TICKET和TICKET_MAC，給運營商端的鑒定/付款管理器。這使得鑒定/付款管理器能夠驗證TICKET_MAC并確定所消耗的記帳單數量以便向用戶收取適當的費用。
圖8B是基于記帳單的認可以及離線驗證的示例性信號交換示意圖。這個例子涉及在線用戶鑒定以及對服務協(xié)議基于記帳單的驗證。
下面總結了基本示例性信號交換1.RAND、AUTN服務提供者生成相關的服務協(xié)議信息以傳輸給用戶，如服務費用參數COST_UNIT。
2.RAND、AUTN、COST_UNIT用戶檢查AUTN，如果沒有問題，就計算RES、密鑰Ik和Ck，優(yōu)選地還有Rk。用戶生成BASE_TICKET并得到START_TICKET，然后計算TICKET_MAC。TICKET_MAC和START_TICKET連同RES都被返回給服務提供者。
3.RES、START_TICKET、TICKET_MAC對于在線鑒定和驗證，服務提供者轉發(fā)RES到運營商端?？梢酝瑫r向RES附加COST_UNIT、START_TICKET和TICKET_MAC。
4.RES、COST_UNIT、START_TICKET、TICKET_MAC鑒定/付款管理器檢查RES是否等于期望響應(XRES)以及TICKET_MAC是否等于期望的XMAC。如果這些條件都滿足，就把密鑰發(fā)給服務提供者。
5.Ik、Ck用戶隨后開始使用記帳單，并且服務提供者檢查記帳單。接收到的LAST_TICkET最終被從服務提供者轉發(fā)給運營商端，以進行驗證和付款的后續(xù)處理。
圖9是基于記帳單的認可的示例性信號交換示意圖，其中基礎記帳單是由鑒定/付款管理器代表用戶準備的。在這個例子中，運營商端生成根據COST_UNIT信息和從服務提供者接收到的(或由運營商代表服務提供者準備的)其它相關信息生成BASE_TICKET，并導出START_TICKET。運營商隨后用認可密鑰(如Rk)把BASE_TICKET加密為ENC_TICKET＝ENC(Rk，BASE_TICKET)并將它連同START_TICKET一起發(fā)送給服務提供者。服務提供者隨后轉發(fā)ENC_TICKET，優(yōu)選地連同RAND和AUTN一起給用戶，用戶可以通過解密提取BASE_TICKET。用戶隨后能夠導出START_TICKET，并且一旦服務提供者訪問必要的會話密鑰Ik、Ck就開始消耗記帳單。因為只有用戶能夠解密BASE_TICKET并因而生成正確的原象，認可就得到了確保。
下面總結了基本的示例性信號交換1.RAND、AUTN、ENC_TICkET、START_TICKET2.RAND、AUTN、ENC_TICKET用戶檢查AUTN，如果沒有問題，就計算RES、密鑰Ik和Ck，優(yōu)選地還有Rk。用戶通過用Rk解密ENC_TICKET而方便地生成BASE_TICkET，并隨后得到START_TICkET。用戶返回RES給服務提供者。
3.RES對于在線用戶鑒定，服務提供者轉發(fā)RES給運營商端。
4.RES鑒定/付款管理器檢查RES是否等于期望響應XRS，并在鑒定成功后發(fā)送會話密鑰給服務提供者。
5.Ik、Ck用戶隨后啟動消耗記帳單，并且服務提供者檢查記帳單。接收到的LAST_TICKET最被從服務提供者轉發(fā)給運營商進行驗證和付款的后續(xù)處理。
應該理解在整個信令的鑒定階段不必包括填寫記帳單過程，但以后必須執(zhí)行。
一般合同簽署如前所示，服務協(xié)議信息可以是一般的電子合同。對于一般的電子合同簽署，一個允許服務提供者離線驗證的特別設計的實施方案涉及通過相同掩蔽函數的本地實例對由服務協(xié)議管理器生成期望驗證信息和用戶簽署的驗證信息都進行掩蔽。
下面用于簽署包括多個不同服務協(xié)議信息的合同的解決方案在它的基本形式上和上述基于記帳單的付款系統(tǒng)有相似之處，它還利用和用于用戶鑒定認可相同的掩蔽機制。
該解決方案基于用戶和通用服務協(xié)議管理器有共享密鑰的假設。當稍微更加集中在整個過程的付款部分上時，下面服務協(xié)議管理器有時被稱作是付款提供者。如果付款提供者是一個蜂窩GSM/UMTS運營商，就存在這樣的共享密鑰且并且存儲在用戶端的(U)SIM中。圖10中示出了相對一般的設置。
優(yōu)選地，服務提供者20或付款提供者30準備將由用戶10簽署的合同。通常，該合同隨后被安全地發(fā)布給所有有關各方。運營商端的付款提供者，使用鍵控散列函數中的共享密鑰計算合同的鍵控散列，表示為合同簽名MAC。鍵控散列函數可以作為真實的鍵控散列或后跟鍵控函數的散列來執(zhí)行。適合AKA和(U)SIM情況的特定解決方案是在AKA過程中把合同散列到與普通RAND對應的變量RAND_CONT中，然后把這個RAND_CONT傳入AKA過程，并以這種方式生成與普通RES對應的簽名MAC。簽名AMC還可在出自AKA過程的密鑰之一的幫助下生成。這通常假定正確的AUTN變量可用或者序列號檢查機制被禁止。
簽名MAC隨后經過(公共)掩蔽函數(這指前述掩蔽函數f的一般化)。掩蔽函數是加密散列函數，即它在實踐中不可能找到該函數的輸出的原象。掩蔽后的簽名MAC被發(fā)送到服務提供者20由他用來驗證用戶的合同簽署。
當用戶簽署合同時他還采用了共享密鑰并通過鍵控散列函數計算簽名MAC。用戶發(fā)送簽名MAC到服務提供者，服務提供者知道公共掩蔽函數并因此檢查簽名。
為了給用戶一個簡單的過程檢查合同的可靠性，可以在發(fā)送合同本身的同時把掩蔽后的簽名MAC發(fā)給用戶。合同還可包含完整的付款過程中所用的其它信息，例如公共掩蔽函數中所用的SALT。
當使用AKA過程時，合同簽署思想等于讓AKA過程中的RAND成為用戶將要簽署的合同數據的HASH。
圖11是當再使用AKA過程時，圖10的合同簽署實現(xiàn)的示例性信號交換示意圖。
在接收到來自用戶的服務請求時，服務提供者把接收到的用戶ID、如果合同CONT是由服務提供者準備的話還要連同它一起，轉發(fā)給服務協(xié)議管理器。服務協(xié)議管理器按照合同CONT的函數y生成RAND_CONT。服務協(xié)議管理器隨后根據Ki和RAND_CONTXMAC＝g(Ki，RAND_CONT)計算期望的簽名MAC，表示為XMAC。這個簽名MAC隨后由通用掩蔽函數m掩蔽為掩蔽后的期望簽名MAC，表示為XMAC’，還可選擇用隨機掩蔽詢問RAND/SALT作為該掩蔽函數的附加輸入。
1.XMAC’、RAND/SALT服務提供者隨后轉發(fā)合同CONT給用戶。
2.CONT如果RAND_CONT不是從運營商端轉發(fā)來的，用戶就用函數y的實例生成它，并且根據Ki和RAND_CONT計算用戶簽名MACMAC＝g(Ki，RAND_CONT)。這個MAC被轉發(fā)給服務提供者。
3.MAC服務提供隨后可用通用掩蔽函數m的實例計算掩蔽后的用戶簽名MAC，表示為MAC’，并最終比較計算出的MAC’和從運營商端接收到的XMAC’以驗證合同。優(yōu)選地，服務提供者保留像MAC、RAND_CONT/CONT和USER ID這樣的驗證信息。如果受到服務協(xié)議管理器詢問或者希望服務協(xié)議管理器的在線過程，服務提供者可以把這個驗證信息轉發(fā)給服務協(xié)議管理器。
服務協(xié)議管理器隨后驗證MAC是否等于XMAC，相等則意味著基于合同的服務協(xié)議得到了最終驗證并且用戶至少是隱含地通過了鑒定。
一般合同簽署過程的新特性是它允許由服務提供者通過引入掩蔽后的驗證數據進行離線驗證。換句話說，服務提供者(SP)和運營商之間進行的合同準備在時間上可以從用戶和服務提供者(SP)之間進行的合同簽署/驗證分開。這個方案的自然應用包括當在一個SP-運營商會話中為不同條件下的相同用戶(例如，在不同時間或不同服務級別)或者相似條件下的多個用戶(例如，當提供訂購意向時)準備多份合同時的情況。
密鑰材料的分離在另一方法中，再次返回服務協(xié)議的AKA-集成認可，AkA數據可以用作偽-隨機函數(PRF)的安全輸入以導出一組新的AKA數據和/或認可密鑰。
通過這個例子，不是對AKA過程進行直接擴展以生成附加密鑰Rk，而是密鑰Ck和Ik可以用作偽隨機函數的安全輸入，偽隨機函數用來獲得新的機密性密鑰Ck’和完整性密鑰Ik’、認可密鑰(Rk)以及新的響應(RES’)。使用并發(fā)布Ck’和Ik’而不是Ck和Ik。采用這種方式就可以不必改變通常實現(xiàn)在智能卡中的AKA方案。
一個主要的好處是當訪問服務時，可以分離GSM/UMTS使用的密鑰材料和用于用戶鑒定和認可的密鑰材料。因而即使用于服務的鍵控材料丟失或被盜，它也不能被用來訪問基礎通信服務。
采用分離步驟的一個變型是用它來生成完整的AKA方案中所用的新的共享密鑰。
如果我們通常用K(i)表示鍵控材料，那么導出步驟可以表示K(i+1)＝PRF(K(i)，SALT)，其中PRF是偽隨機函數。SALT應該包括隨機信息，并可以包含如對服務和/或服務提供者唯一的信息。例如，PRF可以被實現(xiàn)為安全實時傳輸協(xié)議(SRTP)。
盡管K(i)通常是來自基本AKA的輸出數據，但應該理解其它數據也可用作PRF函數的參數。另外，輸入參數的個數和結果變量根據實際上的特定應用可能會有所變化。
圖12A是基于不同的分離的鍵控組的服務協(xié)議AKA-集成認可以及可能的在線驗證的示例性信號交換示意圖。
鑒定/付款管理器根據安全密鑰Ki和隨機詢問RAND生成普通AKA數據。讓K(0)＝[Ck，Ik，XRES]]。鑒定/付款管理器計算K(1)＝[Ck’，Ik’，Rk，XRES’]＝PRF(K(0)，RAND/SALT)。SALT可以等于RAND與服務提供者ID SP_ID的組合。
1.RAND、AUTN、Ik’、Ck’、XRES’、[SALT]2.RAND、AUTN、COST_UNIT、[SALT]用戶照常檢查AUTN。然后他運行AKA以得到K(0)＝Ik，Ck，RES并在K(0)上應用PRF以得到K(1)＝Ck’，Ik’，Rk和RES’。用戶還用Rk在RAND和COST_UNIT之上生成COST_MAC。
3.RES’、COST_MAC服務提供者檢查RES’是否匹配從運營商端接收到的XRES’，并存儲驗證信息以為以后需要時取回。如果受到詢問或者自己主動，服務提供者可以轉發(fā)驗證信息給運營商端進行服務協(xié)議驗證。
圖12B是基于不同的分離的鍵控組的服務協(xié)議AKA-集成認可以及在線驗證的示例性信號交換示意圖。
1.RAND、AUTN、XRES’、[SALT]2.RAND、AUTN、COST_UNIT、[SALT]用戶照常檢查AUTN，然后運行AKA以導出K(0)＝Ik，Ck，RES并在K(0)上應用PRF以導出K(1)＝Ck’，Ik’，Rk和RES’。用戶還用Rk在RAND和COST_UNIT之上生成COST_MAC。
3.RES’、COST_MAC服務提供者檢查RES’是否匹配從運營商端接收到的XRES’，并轉發(fā)驗證信息給運營商側以進行服務協(xié)議驗證。
4.COST_UNIT、COST_MAC如果COST_MAC匹配XMAC，就將會話密鑰Ik’、Ck’傳輸到服務提供者以用于服務提供者和用戶之間的通信中。
5.Ck’、Ik’當然，上述基于記帳單的解決方案還可以基于從初始AKA參數導出的密鑰材料。
應該理解用于普通網絡接入的密鑰材料和用于訪問由服務提供者提供的服務的鑒定和密鑰材料的分離是本發(fā)明的一個一般的獨立特征，它并不限于與服務協(xié)議認可的任意組合。
在上述過程中，假定SALT在運營商端以及用戶那里都可用。如果SALT等于RAND，這一般是對的，但是如果應該使用像時間戳或獨立于RAND值的SALT這樣的其它信息，這些值必須得到用戶同意或者發(fā)送給用戶。一個尤其重要的情況是，當用戶不能從上下文確定真實的SP_ID(服務提供者身份)但又不得不依賴于接收到的信息而且這個SP_ID是用來分離用于不同服務提供者的參數。這種情況下可以在標準AKA過程中的AUTN參數中傳輸該信息，或者如上為合同簽署所描述的MACed消息中發(fā)送，即鍵控MAC保護敏感參數。用于鍵控MAC的密鑰應該只有在運營商和用戶之間共享，例如Ik或Rk。
這一般對應于從基本AKA過程生成服務相關的AKA參數。
涉及付款代理的示性性應用圖13是涉及身份代理及付款代理并采用身份代理、付款代理和服務提供者之間建立的信用鏈的分布式實現(xiàn)的示例性示意框圖。
在將要描述的場景中，我們引入了一個附加參與者，即付款代理40。因而圖13的設置包括用戶10、服務提供者20、與用戶10共享密鑰的鑒定管理器30以及付款代理40。付款代理可以和若干運營商/鑒定管理器有關系并調停運營商和服務提供者之間的用戶鑒定信息，幫助驗證支付并處理付款/收費數據的付款/用戶能力。付款代理可以充當可信第三方的角色，該角色能夠驗證用戶服務協(xié)議。
付款可以被鏈接到用戶已經和其有付款關系的運營商，或者通過獨立方或由付款代理自己鏈接或執(zhí)行。
我們還引入用戶身份代理的概念，通常配置在與鑒定管理器相關的運營商端。用戶可能想要對不同的服務使用不同的身份。身份代理通常把用于服務訪問的用戶身份映射到用于運營商的用戶身份(即IMSI)。身份代理可以在多個步驟發(fā)生。
用戶的服務ID和用戶在運營商處的ID之間的關系必須交給身份代理。通常運行身份代理的運營商將生成這個配對。出于安全原因，自然要由運營商運行最后的身份代理功能。
服務ID可以有若干部分。單個部分可以指示要使用的付款代理和身份代理。一個用戶當然可以對給定的運營商身份使用若干付款代理。付款代理可以保持當無法從用戶服務ID獲得該信息時顯示哪個運營商與給定用戶服務ID相關的記錄。
下面，將參考圖13所示場景描述兩個信令方案。第一個方案用于后付費訂購用戶，第二個方案用于預付費服務。
后付費場景圖14是圖13所示設置中后付費場景中的服務協(xié)議認可的示例性信號交換示意圖。
1.包括付款代理ID的用戶服務ID，USER_SERVICE_ID，PB_ID2.USER_SERVICE_ID、SP_ID
付款代理知道該用戶服務ID與哪個運營商/身份代理相關。
3.USER_SERVICE_ID、SP_ID、PB_ID充當身份代理角色的運營商將USER_SERVICE_ID映射到運營商內部ID(IMSI)并獲取相應的AKA參數RAND、AUTN和K(0)＝[Ck，Ik，XRES]。運營商導出K(1)＝[Ck’，Ik’，XRES]＝PRF(K(0)，[RAND，PB_ID])，其中PB_ID是付款代理ID，RAND是可選的。通過顯式地讓K(1)取決于PB_ID，就將鍵控材料綁定到了特定的付款代理。
4.RAND、AUTN、Ck’、Ik’、(SP_ID||PB_ID，鍵控的MAC(Ik，SP_ID||PB_ID))密鑰Ck’和Ik’用于付款代理和用戶之間的安全通信。因而Ik’可以用作如計算COST_MAC時的認可密鑰，Ck’可以用來導出如ENC_TICKET。
付款代理隨后導出K(2)＝[Ck”，I”k，XRES”]＝PRF[K(1)，[RAND，SP_ID]]。
5.RAND、AUTN、Ck”、Ik”，XRES”，SP_ID||PB_ID，鍵控的MAC(Ik，SP_ID||PB_ID))6.RAND、AUTN、COST_UNIT、SP_ID||PB_ID，鍵控的MAC(Ik，SP_ID||PB_ID))用戶檢查AUTN并用共享密鑰Ki、接收到的RAND和偽隨機函數計算K(0)，K(1)和K(2)。
7.RES”服務提供者檢查RES”并確定用戶的鑒定級別。服務提供者現(xiàn)在用Ck”和Ik”啟動對到用戶的安全連接的使用。
當調用一個用戶必須為之付費的服務時，該用戶應該發(fā)送COST_MAC。
8.COST_MAC9.COST_UNIT、COST_MAC付款代理驗證COST_MAC，并啟動付款過程。
10.OK預付費場景圖15是圖13所示設置中預付費場景中服務協(xié)議認可的示例性信號交換示意圖。
這種情況下我們示出了當用戶使用預付費賬戶并得到由付款代理生成的記帳單時的情況。這里，忽略了為導出分離的AKA參數所需要的對上下文信息的傳輸。
1.USER_SERVICE_ID、PB_ID2.USER_SERVICE_ID、COST_UNIT、SP_ID付款代理知道USER_SERIVCE_ID與哪個運營商/身份代理相關。
3.USER_SERVICE_ID、COST_UNIT、SP_ID、PB_ID運營商將USER_SERVICE_ID映射到運營商內部ID(IMSI)并獲取對應的AKA參數RAND、AUTN并生成K(0)＝[Ck，Ik，XRES]。運營商導出K(1)＝[Ck’，Ik’，XRES’]＝PRF(K(0)，[RAND，PB_ID])，其中PB_ID是付款代理ID，RAND是可選的。通過顯式地讓K(1)取決于PB_ID，就將XRES’和密鑰材料綁定到了特定付款代理。
運營商還檢查用戶預付費帳戶。根據所采用的策略，運營商在用戶帳戶上保留COST_UNITS的號碼N#并將N#發(fā)給付款代理。
4.RAND、AUTN、Ck’、Ik’、N#付款代理生成BASE_TICKET并用Ck’作為加密密鑰計算START_TICKET和ENC_TICKET。生成START_TICkET以使它對小于COST_UNITS的N#的一些數N’#有效。
付款代理接著導出K(2)＝[Ck”，Ik”，RES”]＝PRF[k(1)，[RAND，SP-Id]]5.RAND、AUTN、C”k、I”k、XRES”、ENC_TICKET、START_TICKET6.RAND、AUTN、COST_UNIT、START_TICKET、ENC_TICKET用戶檢查AUTN并用共享密鑰Ki、接收到的RAND和偽隨機函數計算K(0)、K(1)和K(2)。
7.RES”服務提供者檢查RES”并用Ck”和I”k啟動對到用戶的安全連接的使用。
當調用了用戶必須為其付費的服務時，用戶應該發(fā)送TICKET給服務提供者。為此用戶解密ENC_TICkET并重復HASH函數以檢查他擁有的記帳單的數量并檢查START_TICKET是否有效。
然后用戶發(fā)送TICKET，稱為TICKET_i。
8.TICKET_i服務提供者檢查接收到的記帳單。當會話被關閉時，服務提供者將接收到的最后一個記帳單發(fā)給付款代理。
9.LAST_TICKET付款代理檢查接收到的記帳單并生成收費記錄，收費記錄被發(fā)給運營商。
10.CHARGING_RECORD最后，據此調整用戶帳戶。
重-鑒定服務提供者出于不同原因可能想要有重新鑒定用戶的可能。實現(xiàn)此一目標的一種途徑是重復生成K(n)，即當第n次鑒定發(fā)生時，使用鍵控材料K(n+1)＝PRF[K(n)，[RAND，SP_ID]]。這意味著服務提供者訪問偽隨機函數PRF的一個實例PRF，以便能夠生成所需鑒定參數和會話密鑰。簡單地說，服務提供者用偽隨機函數生成第n+1階的新會話密鑰和期望響應，并在重-鑒定請求中發(fā)送RAND給用戶。用戶隨后用隨機偽函數生成新的會話密鑰和n+1階用戶響應，并返回生成的n+1階用戶響應給服務提供者。服務提供者隨后可以驗證接收到的響應，并根據新會話密鑰開始和用戶通信。
優(yōu)選地，n被發(fā)送給用戶，用戶可以保持一個簡單的重放列表以免受重放攻擊。
實現(xiàn)方面上的更多上述步驟、動作和算法可以用軟/硬件或其中的任意組合來實現(xiàn)。對于硬件實現(xiàn)，可以使用ASIC(專用集成電路)技術或任意其它傳統(tǒng)電路技術。盡管出于安全原因首選特殊的防篡改硬件，但受到適當保護的軟件實現(xiàn)通常更方便。
圖16是依照本發(fā)明的優(yōu)選實施方案示出服務協(xié)議管理器的一個實例的示意框圖。圖16的服務協(xié)議管理器30主要包括到外部通信鏈路的通信接口31、數據庫32、鑒定和鍵控單元33、驗證單元36、可選記帳單元37以及付款/收費單元38。數據庫32包括像用戶ID和相關密鑰Ki信息這樣的信息。鑒定和鍵控單元33用于生成相關鑒定和密鑰參數，并且可以保存不同實施方案中所用的可選的掩蔽和偽隨機函數。驗證單元36執(zhí)行相關計算和/或比較，以驗證用戶是否已經接受了給出的服務協(xié)議?？蛇x的記帳單元37可以代表用戶生成相關記帳單并/或完成記帳單驗證。顧名思義，付款單元38處理付款的傳輸并確保對正確的帳戶正確地執(zhí)行了收費。
圖17是依照本發(fā)明的優(yōu)選實施方案說明服務提供者的一個實例的示意性框圖。圖17的服務提供者20主要包括到外部通信鏈路的通信接口21、合同準備單元22、可選鑒定單元23、信息轉發(fā)和/或存儲單元25、以及可選的驗證單元26。在合同準備單元22中，服務提供者通常依照所請求的服務以及服務使用的當前條件準備相關服務協(xié)議信息。另外，合同準備是由另一方代表服務提供者完成的，但通常這種外部合同準備無論如何都要從服務提供者發(fā)起。對掩蔽后的合同簽署和/或用戶鑒定，服務提供者可以在驗證單元26和/或鑒定單元23中完成對接受的服務協(xié)議的驗證和/或用戶鑒定。在離線過程中，服務提供者為了以后想轉發(fā)驗證信息給服務協(xié)議管理器30或由服務協(xié)議管理器指定的其它方可能想在單元25中存儲驗證信息。
圖18是依照本發(fā)明的優(yōu)選實施方案說明用戶終端的一個實例的示意性框圖。圖18的用戶終端10主要包括到外部通信鏈路的通信接口11和防篡改模塊12。防篡改模塊可能類似于可以移動裝置的SIM或USIM卡，包括I/O單元101、AKA算法單元102、安全實現(xiàn)(封裝)的共享密鑰Ki 103、用于像MAC/解密等目的的加密處理單元104，以及用于基于記帳單的認可的可選記帳單元105。甚至可以通過作為(U)SIM的(U)SIM應用工具包環(huán)境中的軟件實現(xiàn)像加密處理這樣的功能，在AKA單元和應用工具包環(huán)境之間有適當的接口。
僅作為示例給出了上述實施方案，應該理解本發(fā)明不止于此。保持這里所公開和提出權利要求的基本的基礎原理的更多更改、變化和改進都在本發(fā)明的范圍和精神內。
權利要求
1.用于通信系統(tǒng)中用戶和服務提供者之間的服務協(xié)議認可的一種方法，所述方法包括以下步驟-在用戶終端和服務協(xié)議管理器之間安全地共享密鑰，所述服務提供者和所述服務協(xié)議管理器有信用關系；-準備服務協(xié)議信息；-根據所述共享密鑰對所述服務協(xié)議信息進行加密處理以生成用戶簽署的服務協(xié)議驗證信息；-轉發(fā)所述用戶簽署的驗證信息給所述服務提供者，以使能夠根據所述服務提供者和所述服務協(xié)議管理器之間的信用關系驗證服務協(xié)議。
2.依照權利要求1的方法，其中所處對服務協(xié)議信息進行加密處理的步驟被安全實現(xiàn)在所述用戶終端中，以生成所述用戶簽署的驗證信息。
3.依照權利要求1或2的方法，其中所述對服務協(xié)議信息進行加密處理的步驟是根據從所述共享密鑰局部導出的認可密鑰執(zhí)行的。
4.依照權利要求2的方法，還包括下列步驟-在所述服務協(xié)議管理器至少部分根據所述服務協(xié)議信息和所述共享密鑰生成期望的驗證信息；-在所述服務協(xié)議管理器驗證所述用戶簽署的驗證信息是否對應于所述期望的驗證信息。
5.依照權利要求2的方法，其中所述用戶簽署的驗證信息是響應自所述服務協(xié)議管理器啟動的隨機詢問和所述服務協(xié)議信息而在所述用戶終端中生成的。
6.依照權利要求2的方法，其中所述用戶簽署的驗證信息是根據用戶端初始化的記帳單和所述服務協(xié)議信息而在所述用戶端中生成的。
7.依照權利要求1的方法，其中所述準備服務協(xié)議信息的步驟是由所述服務提供者初始化的。
8.依照權利要求1的方法，其中所述對服務協(xié)議信息進行加密處理的步驟包括下列步驟-所述服務協(xié)議管理器根據所述共享密鑰對所述服務協(xié)議信息進行加密處理，以生成所述服務協(xié)議信息的加密表示，所述加密表示被轉發(fā)給所述用戶；和-所述用戶終端根據所述共享密鑰對所述加密表示進行加密處理，以生成所述用戶簽署的驗證信息。
9.依照權利要求8的方法，其中所述服務協(xié)議管理器完成加密處理的步驟包括以下步驟-根據所述服務協(xié)議信息生成記帳單；和-根據從所述共享密鑰局部導出的認可密鑰加密所述記帳單；并且所述用戶終端進行加密處理的步驟包括，根據從所述共享密鑰局部導出的所述認可密鑰對所述加密的記帳單解密的步驟。
10.依照權利要求的方法，其中所述服務協(xié)議信息是一般的電子合同，并且所述方法還包括下列步驟-所述服務協(xié)議管理器根據所述共享密鑰和所述電子合同生成期望的服務協(xié)議驗證信息；-所述服務協(xié)議管理器通過一個掩蔽函數掩蔽所述期望的驗證信息；-所述服務協(xié)議管理器轉發(fā)所述掩蔽后的期望驗證信息給所述服務提供者；-所述服務提供者通過相同掩蔽函數的一個實例掩蔽所述用戶簽署的驗證信息，以生成掩蔽后的用戶簽署的驗證信息；-所述服務提供者驗證所述掩蔽后的用戶簽署的驗證信息是否對應于從所述服務協(xié)議管理器獲得的所述掩蔽后的期望驗證信息。
11.依照權利要求10的方法，其中所述服務協(xié)議管理器生成期望的服務協(xié)議驗證信息的步驟包括，應用合同的一個散列作為基于普通詢問-響應的鑒定和密鑰協(xié)定過程中的隨機詢問的步驟。
12.依照權利要求10的方法，其中所述掩蔽函數是加密散列函數。
13.依照權利要求1的方法，其中所述認可方法被和用于網絡接入的基于詢問-響應的鑒定和密鑰協(xié)定(AKA)過程集成在一起，所述共享密鑰與用于AKA的密鑰相同。
14.依照權利要求13的方法，其中用于服務協(xié)議認可的鍵控材料與用于所述基于詢問-響應的AKA過程的鍵控材料隔離。
15.依照權利要求14的方法，其中所述用于認可的鍵控材料是根據作為所述偽隨機函數的輸入的AKA的鍵控材料通過所述偽隨機函數生成。
16.依照權利要求14的方法，其中所述用于認可的鍵控材料被綁定到和鑒定管理器合作的一個具體的付款代理，所述鑒定管理器和所述用戶終端共享所述密鑰。
17.依照權利要求14的方法，其中所述用于認可的鍵控材料被綁定到所述服務提供者，以便將所述鍵控材料同另一服務提供者的相應鍵控材料隔開。
18.依照權利要求1的方法，其中所述服務協(xié)議信息包括服務收費信息和，并且所述服務協(xié)議管理器是代表用戶處理所述服務的付款的付款提供者。
19.依照權利要求1的方法，其中所述服務協(xié)議管理器包括用戶身份代理和安排在所述服務提供者和所述身份代理之間的付款代理，在服務提供者、付款代理和身份代理之間建立起了一個信用鏈，所述身份代理與所述用戶終端共享所述密鑰。
20.依照權利要求19的方法，還包括所述付款代理根據從所述身份代理獲得、根據所述共享密鑰導出的認可密鑰驗證用戶簽署的驗證信息的步驟。
21.用于通信系統(tǒng)中用戶和服務提供者之間的服務協(xié)議認可的一種系統(tǒng)，所述系統(tǒng)包括-在用戶終端和服務協(xié)議管理器之間共享密鑰的裝置，所述服務提供者和所述服務協(xié)議管理器之間有信用關系；-準備服務協(xié)議信息的裝置；-根據所述共享密對所述服務協(xié)議信息進行加密處理，以生成用戶簽署的服務協(xié)議驗證信息的裝置；和-轉發(fā)所述用戶簽署的驗證信息到所述服務提供者，以使能夠根據所述服務提供者和所述服務協(xié)議管理器之間的信用關系對服務協(xié)議進行驗證的裝置；22.依照權利要求21的系統(tǒng)，其中對所述服務協(xié)議信息進行加密處理的所述裝置被安全實現(xiàn)在所述用戶終端中。
23.依照權利要求21或22的系統(tǒng)，其中對所述服務協(xié)議信息進行加密處理的所述裝置根據從所述共享密鑰局部導出的認可密鑰操作。
24.依照權利要求22的系統(tǒng)，還包括-在所述服務協(xié)議管理器，至少部分根據所述服務協(xié)議信息和所述共享密鑰生成期望的驗證信息的裝置；和-在所述服務協(xié)議管理器，驗證所述用戶簽署的驗證信息是否對應于所述期望的驗證信息的裝置。
25.依照權利要求22的系統(tǒng)，其中所述用戶簽署的驗證信息是響應從服務協(xié)議管理器啟動的隨機詢問以及所述服務協(xié)議信息而在所述用戶終端中生成的。
26.依照權利要求22的系統(tǒng)，其中所述用戶簽署的驗證信息是根據用戶端初始化的記帳單和所述服務協(xié)議信息在所述用戶終端中生成的。
27.依照權利要求21的系統(tǒng)，其中所述服務協(xié)議信息是由所述服務提供者準備的。
28.依照權利要求21的系統(tǒng)，其中對所述服務協(xié)議信息進行加密處理的所述裝置包括-在所述服務協(xié)議管理器，根據所述共享密鑰對所述服務協(xié)議信息進行加密處理，以生成所述服務協(xié)議信息的加密表示的裝置，所述加密表示被轉發(fā)給所述用戶；和-在所述用戶終端，根據所述共享密鑰對所述加密表示進行加密處理，以生成所述用戶簽署的驗證信息的裝置。
29.依照權利要求28的系統(tǒng)，其中在所述服務協(xié)議管理器進行加密處理的所述裝置包括-根據所述服務協(xié)議信息生成記帳單的裝置；和-根據從所述共享密鑰局部導出的認可密鑰加密所述記帳單的裝置；并且在用戶終端中進行加密處理的所述裝置包括，根據從所述共享密鑰局部導出的所述認可密鑰對所述加密的記帳單解密的裝置。
30.依照權利要求21的系統(tǒng)，基中所述服務協(xié)議信息是一般電子合同，并且所述系統(tǒng)還包括-在所述服務協(xié)議管理器根據所述共享密鑰和所述電子合同生成期望的服務協(xié)議驗證信息的裝置；-在所述服務協(xié)議管理器由掩蔽函數掩蔽所述期望的驗證信息的裝置；-在所述服務協(xié)議管理器轉發(fā)所述掩蔽后的期望的驗證信息給所述服務提供者的裝置；-在所述服務提供者由相同掩蔽函數的實例掩蔽所述用戶簽署的驗證信息以生成掩蔽后的用戶簽署的驗證信息的裝置；-在所述服務提供者驗證所述掩蔽后的用戶簽署的驗證信息是否對應于從所述服務協(xié)議管理器獲得的掩蔽后的期望的驗證信息的裝置。
31.依照權利要求30的系統(tǒng)，其中生成期望的服務協(xié)議驗證信息的所述裝置包括，應用合同的加密散列作為基于普通詢問-響應的鑒定和密鑰協(xié)定過程中的隨機詢問的裝置。
32.依照權利要求30的系統(tǒng)，其中掩蔽函數是加密散列函數。
33.依照權利要求21系統(tǒng)，其中所述認可系統(tǒng)被和用于網絡訪問的基于詢問-響應的鑒定和密鑰協(xié)定(AKA)過程的系統(tǒng)集成在一起，所述共享密鑰與用于AKA的共享密鑰相同。
34.依照權利要求33的系統(tǒng)，還包括將用于服務協(xié)議認可的鍵控材料同用于所述基于詢問-響應的AkA的鍵控材料隔離的裝置。
35.依照權利要求34的系統(tǒng)，其中所述用于認可的鍵控材料是根據用于AKA的鍵控材料作為所述偽隨機函數的輸入通過所述偽隨機函數而生成的。
36.依照權利要求34的系統(tǒng)，其中所述用于認可的鍵控材料被綁定到與鑒定管理器合作的一個具體付款代理，所述鑒定管理器和所述用戶終端共享所述密鑰。
37.依照權利要求34的系統(tǒng)，其中所述用于認可的鍵控材料被綁定到所述服務提供者，以便將所述鍵控材料與用于別的服務提供者的相應鍵控材料隔離。
38.依照權利要求21的系統(tǒng)，其中所述服務協(xié)議信息包括服務收費信息，并且所述服務協(xié)議管理器是用于代表用戶處理所述服務的付款的付款提供者。
39.依照權利要求21的系統(tǒng)，其中所述服務協(xié)議管理器包括用戶身份代理和安排在所述服務提供者和所述身份代理之間的付款代理，并在服務提供者、付款代理和身份代理之間建立了一個信用鏈，所述身份代理與所述用戶共享所述密鑰。
40.依照權利要求39的系統(tǒng)，還包括在所述付款代理根據從所述身份代理獲得的根據所述共享密鑰導出的認可密鑰驗證所述用戶簽署的驗證信息的裝置。
41.一種用戶終端包括-安全地保存與外部服務協(xié)議管理器共享的密鑰的裝置，所述服務協(xié)議管理器與服務提供者之間有信用關系；-接收代表用戶和所述服務提供者之間的服務協(xié)議的信息的裝置；-根據所述共享密鑰對所述服務協(xié)議表示信息安全地進行加密處理，以生成用戶簽署的服務協(xié)議驗證信息的裝置；-轉發(fā)所述用戶簽署的驗證信息到所述服務提供者，以能夠根據所述服務提供者和所述服務協(xié)議管理器之間的信用關系對服務協(xié)議進行驗證的裝置。
42.幫助管理通信系統(tǒng)中用戶和服務提供者之間的服務協(xié)議的一種服務協(xié)議管理器，所述服務協(xié)議管理器包括-安全保存與用戶終端共享的密鑰的裝置，所述服務協(xié)議管理器與所述服務提供者有信用關系；-接收由用戶終端根據所述服務協(xié)議的信息表示和所述共享密鑰生成的用戶簽署的服務協(xié)議驗證信息的裝置；-根據所述共享密鑰驗證用戶簽署的驗證信息，并因此而確認用戶對服務協(xié)議的接受的裝置。
43.通信系統(tǒng)中依照用戶和服務提供者之間給定的服務協(xié)議向用戶提供服務的一種服務提供者，所述服務提供者包括-與服務協(xié)議管理器建立信用裝置的裝置，所述服務協(xié)議管理器與用戶終端共享密鑰；-從所述用戶終端接收至少部分根據所述服務協(xié)議的信息表示和所述共享密鑰生成的用戶簽署的驗證信息的裝置；-通過掩蔽函數生成掩蔽后的用戶簽署的驗證信息的裝置；-從所述服務協(xié)議管理器接收由相同掩蔽函數的一個實例掩蔽后的期望的驗證信息的裝置，所述期望的驗證信息是至少部分根據所述服務協(xié)議信息和所述共享密鑰生成的；-驗證掩蔽后的用戶簽署的驗證信息是否與所述掩蔽后的期望的驗證信息對應，以確認用戶對服務協(xié)議的接受的裝置。
44.用于改進的基于詢問-響應的鑒定和密鑰協(xié)定(AKA)的一種方法涉及用戶、服務提供者以及和所述服務提供者有信用關系的網絡運營商，所述網絡運營商與所述用戶共享密鑰以相互生成AkA參數，其中改進是通過將由網絡運營商管理的用于訪問網絡的第一組AKA參數與用于訪問由服務提供者提供的服務的第二組AKA參數分開而實現(xiàn)的，而將這兩組AKA參數分開是通過將所述第一組AKA參數的部分表示用作所述第二組AKA參數的輸入的預定函數。
45.依照權利要求44的方法，其中所述第一組AKA參數和所述第二組AKA參數是在網絡運營商端以及用戶端根據所述共享密鑰和在網絡運營商端啟動的詢問而生成的，所述第二組AkA參數被從所述網絡運營商安全地傳輸到所述服務提供者。
46.依照權利要求45的方法，其中所述服務提供者還通過將所述第二組AkA參數的至少一部分用作輸入的所述預定函數為重-鑒定目的而生成另一組AKA參數。
47.依照權利要求44的方法，其中所述預定函數是一個偽隨機函數。
全文摘要
本發(fā)明通常涉及通信系統(tǒng)中的用戶(10)和服務提供者(20)之間的有效認可。引入了一個額外的可信方(30)，所謂的服務協(xié)議管理器，并且本發(fā)明基于該服務協(xié)議管理器(30)與用戶終端(10)共享一個密鑰(Ki)并且服務提供者(20)與該服務協(xié)議管理器(30)有信用關系的思想。本發(fā)明提出的認可方案還基于相關服務協(xié)議信息的準備、根據共享密鑰(Ki)對這個信息的加密處理(14/34)以便生成用戶簽署的服務協(xié)議驗證信息。用戶簽署的驗證信息隨后被轉發(fā)到服務提供者(20)以根據服務提供者(20)和服務協(xié)議管理器(30)之間的信用關系實現(xiàn)對服務協(xié)議的驗證(26/36)。
文檔編號G06Q20/00GK1659820SQ03813707
公開日2005年8月24日 申請日期2003年6月4日 優(yōu)先權日2002年6月12日
發(fā)明者R·布羅姆, A·梅赫斯 申請人:艾利森電話股份有限公司