服务协议的认可的制作方法

专利名称：服务协议的认可的制作方法
技术领域：
本发明通常涉及现代通信系统(如移动通信系统)中，保证用户和服务提供商之间交易安全可靠的方法。
背景技术：
今天的很多通信系统，包括移动通信系统，为增强系统安全性和健壮性而采用鉴定和加密过程。
如在移动通信系统中，用户向网络和/或服务提供者鉴定，以便获得对基本网络服务以及其它服务的访问，并且该鉴定还充作给用户记帐的基础。现代通信系统的基本安全协议通常涉及询问-响应鉴定过程，通常主要基于密钥加密。询问-响应鉴定在本领域中是众所周知的，并且存在若干种用于GSM(全球移动通信系统)和UMTL(通用移动电信系统)的基本询问-响应鉴定上的标准。
在电子商务尤其是小型付款系统中，服务提供者最基本的是能够证明用户已经同意为一项服务付费(服务费用/服务协议的用户认可)。
已知用于认可的技术通常采用基于公共密钥加密方案的数字签名，从计算角度讲这种方法很昂贵。

发明内容
本发明克服了现有技术装置的这些和其它缺点。
本发明的一个一般目标是提供为通信系统中的服务提供者和用户之间的服务协议的认可提供有效健壮的方案。
本发明的一个目标是提供一种使服务提供者能够证明或验证用户的确已经接受了给出的服务协议的方案。
例如，服务提供者可能会对能够证明用户已经同意为一项服务付费感兴趣，包括接受的服务费用的验证。
本发明的另一目标是为通信系统中改进的基于询问-响应的鉴定和密钥协定(AKA)提供一种机制。
这些和其它目标由所附权利要求定义的本发明来满足。
简单地说，本发明通常引入第三可信方，所谓的服务协议管理器。本发明所基于的思想是，服务协议管理器与用户终端共享一个密钥并且服务提供者与服务协议管理器有信用关系。本发明提出的认可方案还基于对相关服务协议信息的准备，根据共享密钥对这个信息的加密处理，以便生成用户签署的服务协议验证信息。用户签署的验证信息随后被转发给服务提供者，以使能够根据服务提供者和服务协议管理器之间的信用关系实现对该服务协议的验证。
服务协议管理器可以是管理或参与管理服务提供者和用户之间的服务协议的任意可信方，如可以实现在通信系统的网络运营商端。
服务协议管理器甚至可以分散在不同结点或不同方之间，如可以包括用户身份代理和安排在服务提供者和身份代理之间的付款代理。这种情况下，在服务提供者、付款代理和身份代理之间建起了一个信用链，而用户终端通常与身份代理共享密钥。
服务协议信息的准备通常是由服务提供者完成或初始化，但应该理解，只要用户和服务提供者都接受该协议，这个信息就可以由所涉及各方中的任一方来准备。
对服务协议信息的加密处理通常在用户端完成，但有些情况下也可以涉及服务协议管理器。优选地，用户终端根据从共享密钥局部导出的认可密钥进行加密处理，以便生成所需验证信息。
服务提供者接收用户签署的验证信息并有能力存储这个信息的起码的事实可以阻止用户否认输入的服务协议。如果希望或合适，可由服务协议管理器、甚至直接由服务提供者在线或离线进行实际验证。
例如，服务协议管理器可以至少部分根据准备的服务协议信息和共享密钥生成期望的验证信息，并在需要时验证从服务提供者转发来的用户签署的验证信息是否对应于期望的验证信息。
用户签署的验证信息可以由用户终端响应从服务协议管理器发起的询问或基于用户端发起的记帐单而方便地生成，这两种情况下都要结合给出的服务协议信息。
但是，也可在服务协议管理器端和用户端都对服务协议信息进行加密处理。这种情况下，服务协议管理器优选地根据共享密钥生成服务协议信息的加密表示并把这个表示转发给用户终端(通常是通过服务提供者)，然后在用户端会根据共享密钥处理接收到的加密表示以生成正确的验证信息。
例如，对基于记帐单的解决方案，服务协议管理器侧的加密处理可以包括对基于准备的服务协议信息生成的记帐单的加密，用户端处理则一般包括对加密的记帐单的解密。
应该理解，服务协议信息可以是一般的电子合同。但是，本发明已经证明在服务协议信息包括服务收费信息并且服务协议管理器充当付款提供者或代表服务提供者充当收费中心的应用中尤其有用。
对一般的合同签署，一个允许服务提供者离线验证的特殊设计的实施方案涉及通过相同掩蔽函数的本地实例掩蔽由服务协议管理器生成的期望的验证信息以及用户签署的验证信息。由服务协议管理器掩蔽根据共享密钥和一般合同生成的期望的验证信息并转发给服务提供者。服务提供者从用户端接收到用户签署的验证信息并掩蔽它，因而能够通过比较掩蔽后的期望验证信息和掩蔽后的用户签署的验证信息在服务提供者端验证服务协议。
有利地，服务协议管理器通过作为基于正常询问-响应的验证和密钥协定过程中的随机询问施加对合同的加密散列而生成期望的服务协议验证信息。
在一系列特别有用的实施方案中，服务协议的认可与用于网络接入的基于询问-响应的验证和密钥协定(AKA)(例如GMS/UMTS AKA)过程集成在一起，使用通常用于AKA的相同共享密钥。这意味着可以复用已有的基础结构。
与本发明明显相反，用于提供服务协议认可的现有技术是基于服务提供者和用户终端之间直接的公共密钥加密方案，采用不对称密钥对。
尽管不必要，但已经证明把用于服务协议认可的密钥材料和用于普通AKA的密钥材料分开还是有好处的。在这方面，用于认可的键控材料甚至可以被绑定到和鉴定管理器协同工作的特定付款代理，其中用户终端与鉴定管理器共享密钥。
在本发明的另一相关方面，采用了上述隔离方案以改进基于询问-响应的验证和密钥协定(AKA)。简单地说，通过用预定的函数(如伪随机函数)把用于访问由网络运营商管理的网络的第一组AKA参数同用于访问由服务提供商提供的服务的第二组AKA参数分开，可以改进普通的AKA过程，用第一组AKA参数的至少一部分的表示作为生成第二组AKA参数的输入。这样做的优势是，即使用于服务访问的密钥材料丢失或被盗，它也不能被用于基础网络访问。
本发明提供下列优势对通信系统中服务协议的有效健壮的认可防止用户否认输入的服务协议为网络运营商提供充当可信服务协议管理器的新的商业可能。例如，运营商可以获得付款过程中的自然角色。
扩展基本的询问-响应过程(如UMTS/GSM AKA)的有效途径，使得能够将付款协议绑定到用户鉴定。
用现有基础结构方便迁移。
容易实现，不必引入新的GSM或UMTS用户标识模块(SIM)。反正总要改变终端以容纳新的付款协议。
在阅读下面对本发明实施方案的描述后会理解本发明所提供的其它优势。
附图概述参考下面结合附图所作的描述能够最好地理解本发明以及其中的更多目标和优势，附图中

图1是依照本发明的优选实施方案的基本参与者和它们的相互关系的示意简图；图2是当移动用户漫游到一个被访网络时移动通信系统中主位置鉴定的信号交换示意图；图3是用于以今天通常实现在蜂窝系统中的方式带有委托验证的鉴定的信号交换示意图；图4是依照本发明的优选实施方案为所提出的服务协议认可通用方案示出整体结构和基础的示意图；图5是使用专用认可密钥的服务协议认可以及可能的离线验证的示例性信号交换示意图；图6A是使用专用认可密钥的服务协议在线验证的示例性信号交换示意图；图6B是使用已有的AKA密钥作为认可密钥的服务协议在线验证的示例性信号交换示意图；
图7A是通过掩蔽后的鉴定数据结合服务协议的离线验证建立用户鉴定证据的示例性信号交换示意图；图7B是对服务协议的认可使用专用密钥或已有的AKA密钥，通过掩蔽后的鉴定数据结合鉴定及服务协议的在线验证建立用户鉴定证据的示例性信号交换示意图；图8A是基于记帐单的认可以及可能的在线验证的示例性信号交换示意图；图8B是基于记帐单的认可以及在线验证的示例性信号交换示意图；图9是基于记帐单的认可的示例性信号交换示意图，其中基本记帐单是由鉴定/付款管理器代表用户准备的；图10是基于引入允许服务提供者离线验证的掩蔽后的验证数据的合同签署的示例性信号交换示意图；图11是图10的合同签署实现的示例性信号交换示意图；图12A是基于不同的分离的密钥组的AKA-集成服务协议认可以及可能的离线验证的示例性信号交换示意图；图12B是基于不同的分离的密钥组的AKA-集成服务协议认可以及在线验证的示例性信号交换示意图；图13是引入身份代理以及付款代理，采用身份代理、付款代理和服务提供者之间建立起的信用链的分布式实现的示例性示意框图；图14是图13所示配置的后付费场景中服务协议认可的示例性信号交换示意图；图15是图13所示配置的预付费场景中服务协议认可的示例性信号交换示意图；图16是依照本发明的优选实施方案示出服务协议管理器的一个示例的示意框图；图17是依照本发明的优选突施方案示出服务提供者的一个示例的示意框图；图18依照本发明的优选实施方案示出用户终端的一个示例的示意框图。
发明实施方案详述贯穿这些图中，相同的参考字符将用于相应或相同的部件。
综述从参考图1概述基本参与者和他们的相互关系开始可能会有益一些，图1是依照所提出的发明的通信系统的示意概观。
基本参与者包括用户10、服务提供者20和通常称为信用提供者30的附加方，信用提供者可以代表服务提供者和/或用户完成不同的任务。信用提供者30和用户(或者是正确配置的用户终端)之间有通过共享密钥建立起的信用关系。信用提供者30和服务提供者20可以有一个表明为契约形式的信用关系的协议。用户10和服务提供者20之间的关系通常看作是导出的信用关系，这种信用关系是在请求或启动由服务提供者提供的服务时建立的。
信用提供者可以和用户与之有信用关系的网络运营商相关，例如这种信用关系是通过订购或预付费帐户而建立的。
这个建立的信用关系通常通过激活询问-响应过程(如用于GSM/UMTS的AKA(验证与密钥协定)过程和/或类似的过程)的共享密钥以加密关系表明。网络运营商可以和服务提供者有协议，该协议通常由类似的加密关系表明。服务提供者随后可以为和它们的服务的终端用户进行间接相互验证采用询问-响应过程，例如GSM/UMTSAMA。
已知当一个移动用户漫游到由所谓被访运营商管理的另一网络中时，使用归属运营商作为用户验证的信用基础，如图2和图3的示意说明。
图2是当一个移动用户漫游到一个被访网络中时由移动通信系统中的归属运营商用在线验证进行用户鉴定的信号交换示意图。
基本的UMTS AMA过程采用共享密钥Ki，例如与用户-运营商订购相关的订购密钥或从中导出的密钥，以产生对询问的响应以及两个会话密钥，一个用于机密性保护(Ck)，一个用于用户和被访运营商之间流量完整性保护(Ik)。归属运营商，或者更确切地说是HSS/AuC(主用户服务器/鉴定中心)和HLR/AuC(HLR，归属位置寄存器)，生成一个随机询问(RAND)以及鉴定令牌(AUTN)，鉴定令牌后来由用户用来验证询问是新的并且是由归属运营商生成的。从这个询问用共享密钥计算响应(RES/XRES)和密钥(Ck，Ik)。在GSM AKA中，不生成完整性密钥或鉴定令牌，但基本的询问-响应过程是相同的。共享密钥通常实现在GSM移动装置中所用的SIM卡或UMTS移动装置中所用的UMTS SIM卡(USIM)，取决于AKA实现。
参考图2，它或多或少地与标准可扩展鉴定协议(EAP)对应，下面总结了实现所需信令的一种途径在初始阶段，用户发送标识符到被访运营商，并且被访运营商将该标识符转发到归属运营商。根据这个标识符，归属运营商端的HSS/AuC或等效单元获取相应的密钥，生成一个五位字节(RAND、AUTN、Ck、Ik、XRES)并发送1.询问(RAND)、鉴定令牌(AUTN)到被访运营商。这些参数由被访运营商转发给用户。
2.询问(RAND)、鉴定令牌(AUTN)用户检查该AUTN，如果没有问题，就计算响应(RES)、机密性密钥(Ck)和完整性密钥(Ik)。响应通过被访运营商发回归属运营商3.响应(RES)4.响应(RES)归属运营商检查RES是否等于期望的响应(XRES)。如果是就把密钥安全地传送到被访运营商。
5.完整性和机密性密钥(Ik和Ck)。
归属运营商看到来自终端用户的RES并证实该终端用户已经通过被访运营商通过鉴定。但是，归属运营商没有该用户已经接受了什么服务的证据。
如果以今天在蜂窝系统中所做的方式实现该信令，那么归属运营商甚至将没有用户鉴定的证据。这种情况下，参考图3，信令如下1.RAND、AUTN、Ik、Ck、XRES2.RAND、AUTN用户检验AUTN，如果没有问题，就计算响应RES、机密性密钥Ck和完整性密钥Ik。
3.RES被访网络检查RES是否等于XRES。如果是，则该用户通过验证。
对服务协议认可的示例性通用方案图4是为依照本发明的优选实施方案所提出的服务协议认可通用方案示出整体结构和基础的示意图。
发明人已经认识到服务提供者必须能够证明用户已经接受了给出的用户协议，尤其是用户已经同意为该服务付费，包括接受的服务费用的验证(服务协议/服务费用的用户认可)。这在通过或借助第三可信方(如网络运营商或等效方)进行用户鉴定和付款/收费时尤其重要。
因此，为了服务提供者和用户之间的服务协议认可起见，提议信用提供者30代表服务提供者和/或用户充当通用服务协议管理器。依照本发明的优选基本实施方案的认可方案包括对相关服务协议信息的准备，以及根据服务协议管理器和用户终端之间共享的密钥对准备的信息的加密处理，以便生成用户签署的服务协议验证信息。用户签署的验证信息随后被转发给服务提供者，以能够根据服务提供者和服务协议管理器之间的信用关系实现对服务协议的验证。
适当电子形式的服务协议信息(电子合同)的准备通常是由服务提供者在合同准备/初始化单元22中完成或至少由它初始化的，但这个信息可以由涉及到的任意一方准备，只要用户和服务提供者接受该协议。例如，服务协议管理器30可以选择代表服务提供者20准备该服务协议信息。
对服务协议信息的加密处理通常是在用户端在用户终端10中的防篡改模块12中完成。优选地，用户终端10根据从共享密钥局部导出的认可密钥在加密引擎14中完成加密处理，以便生成所需的验证信息。但是，在一些实现中，加密处理可以由用户终端10在加密引擎14中并且由服务协议管理器30在加密引擎34中完成。
用户签署的验证信息被安全地从用户终端10转发到服务提供者20的起码的事实可能有拒绝-阻止效果。但是，优选地，验证是由服务协议管理器在线或离线进行的，或者由服务提供者直接进行。在离线过程中，验证信息包括至少用户签署的验证部分，并且优选地还包括相应的询问或和用户身份一块儿的其它输入，验证信息通常被存储在一个存储单元中，服务提供者20随后可从该存储单元获取验证信息并提供其作为用户已经接受该服务协议的证据。在在线过程中，验证信息通常被从服务提供者20或多或少地直接转发给服务协议管理器30，由此激活在线证据。根据给出的验证信息，服务协议管理器30随后可以进行相关的计算和/或比较，以在验证单元36中验证用户是否已经实际接受了该服务协议。
服务协议管理器可以方便地与包括用户ID和一组用户的相关密钥Ki的数据库相关联。这使得服务协议管理器能够出于各种目的(例如生成用户鉴定参数、服务协议信息和/或服务协议验证的加密处理)根据相应的用户ID访问给定用户的相关密钥。
如后所述，验证还可以由服务提供者20在验证单元26中直接进行。
服务提供者20和服务协议管理器30之间的信用关系应该为服务提供者关于所做声明或由服务协议管理器提供的数据提供保证。因为发送的信息(例如，服务协议信息、计费数据、鉴定参数和/或其它适当的信息)通常被看作是敏感的并且通信方的身份是上述保证所必需的，所以服务提供者和服务协议管理器之间的通信链路应该是安全的。这可以通过(如)使用TLS或IPSec或加密/签署单个消息而实现。
服务协议的AKA-集成认可/验证从在服务协议的AKA-集成认可/验证环境中开始描述本发明可能会有用一些。
在一系列优选实施方案中，服务协议的认可尤其是服务费用是和用于网络访问的基于询问-响应的鉴定和密钥协定(AKA)(例如GMS/UMTS AMA或类似的鉴定)集成在一起的，使用通常为AKA所采用的相同共享密钥。采用AKA-集成的认可的很大优势是可以复用已有的基础结构。
在这个上下文中，通常假定可信服务协议管理器为鉴定用户、授权用户访问服务和/或建立用户已经同意服务使用条件的证据而充当鉴定/付款管理器。在典型场景中，网络运营商可以将鉴定/付款管理器实现为用于建立用户和访问点之间的可靠和安全通信的安全系统。运营商还和服务提供者有信用关系并在这些安全链路上与它们通信。响应服务访问请求，鉴定/付款管理器采用与发出请求的用户共享的密钥(通常表示为Ki)以帮助鉴定、受权、认可和/或付款或收费过程。
关于服务费用，为服务付费的用户协议可以被绑定到UMTS/GSMAMA或类似鉴定。这优选地应该以可以向服务提供者确保用户不会在后来阶段拒绝服务协议的这种方式来实现。
图5是使用专用认可密钥的服务协议认可以及可能的离线验证的示例性信号交换示意图。在这个例子中，用附加会话密钥以及附加服务协议信息的获取扩展了普通的询问-响应(AKA)方案，所获取的附加会话密钥将只在用户和运营商之间共享。
考虑到想要访问由服务提供者提供的服务的用户。通常在提供服务之前必须鉴定该用户。用户ID不必是一个公共标识符，但它应该允许映射到一个用户相关的密钥Ki，它能使得对正确的帐户正确地进行收费。例如，如果用户和归属运营商有订购关系，密钥Ki可以是订购密钥，或者是与预付费帐号相关的加密密钥。用户ID的传输通常由虚线表示，因为这可以看作是初始化阶段，还部分因为这可能是服务提供者和运营商之间的鉴定向量批处理的一部分。通常需要服务提供者从用户接收能够用于确定与用户相关的鉴定/付款管理器的身份的信息；例如用户的归属运营商的身份。这使得服务提供者能够在对AKA参数的请求中转发用户ID到相关鉴定/付款管理。根据接收到的用户ID，鉴定/付款管理器识别出密钥Ki并生成适当的AKA参数。鉴定/付款管理器生成随机询问RAND并根据密钥Ki和随机询问RAND为给定函数g的输入而计算出期望的响应XRES，并且还根据Ki和RAND生成普通的完整性和机密性密钥Ik和Ck。
用户应该还同意为该服务付费。协议应该使得服务提供者以后能够证明用户确实同意了协议。这里的思想是在进行用户鉴定和密钥协定并且生成鉴定参数(如RAND和XRES，以及完整性和机密性密钥Ik、Ck)的同时，生成附加的服务协议认可密钥，表示为Rk。
下面总结了基本的示例性信号交换1.RAND、AUTN、Ik、Ck、XRES服务提供者生成服务协议信息，所生成的服务协议信息包括一个或多个信息项，如服务标识、服务费用、有效次数、服务提供者标识符等等。下面，通过表示一个给定值(服务单元费用)的费用参数COST_UNIT举例说明服务协议信息。如果希望的话，这个费用参数还可伴随一个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一起被返回给服务提供者。服务提供者绝不能伪造系统的COST_MAC以实现认可目的。
3.RES、COST_MAC服务提供者检查RES是否匹配XRES。服务提供者还保留验证信息，例如用户ID、RAND、COST_UNIT和COST_MAC以用用户协议以后的证据。
如果需要或受到请求，服务提供者可在以后将验证信息转发给运营商端的鉴定/付款管理器。
4.COST_UNIT、COST_MAC、USER ID、RAND运营商端的鉴定/付款管理器随后充当验证器并检查COST_MAC是否等于期望的XMAC＝MAC(Rk，RAND||COST_UNIT)以验证用户已经接受了服务协议和服务费用。
当然，存在用户伪造COST_MAC的可能。为此目的，可以用一些策略对COST_MAC进行随机的在线测试，以防止用户有这种动作。
本质上，这个示例性方法是基于用运营商和用户之间共享的认可密钥扩展基本AKA，但这个认可密钥并没有发布给服务提供者。这个认可密钥可由用户用来“签署”消息，而运营商能够验证用户“签署”了的消息。如上所述，一个示例性解决方案是用从RAND导出的密钥将MAC数据连同RAND一起发送给用户并验证数据的可靠性。
应该理解，首先完成普通AKA信令、在服务提供者处验证RES是否等于XRES、并且随后当用户在安全链路上向服务提供者请求服务时完成认可信令同样可行。这意味着服务提供者在成功的用户鉴定后，在接收到来自用户的服务请求时发送费用参数COST_UNIT和相关信息给用户。用户随后计算COST_MAC并返回COST_MAC给服务提供者，以激活对服务协议的验证。
图6A是用专用认可密钥对服务协议进行在线验证的示例性信号交换示意图。这个示例涉及在线用户鉴定和服务协议验证。
下面总结了基本的示例性信号交换1.RAND、AUTN服务提供者生成相关的服务协议信息，如服务费用参数COST_UNIT以传输给用户。
2.RAND、AUTN、COST_UNIT用户检查AUTN，如果没有问题，就计算响应RES、机密性密钥Ck、完整性密钥Ik以及认可密钥Rk。计算COST_MAC并将它和对鉴定的响应RES一起返回给服务提供者。
3.RES、COST_MAC对在线验证，服务提供者转发RES到运营商端。也可同时把COST_UNIT和COST_MAC附加到RES后。
4.RES、COST_UNIT、COST_MAC鉴定/付款管理器检查RES是否等于期望的响应(XRES)以及COST_MAC是否等于期望的XMAC。如果用户有一个预付费帐户，管理器还可以检查该用户在他的帐号上是否有足够的存款。如果这些条件都满足就把密钥发送给服务提供者。
5.Ik、Ck当服务提供者接收到用于保护用户和服务提供者之间的会话的密钥时，这还表示服务协议没有问题。
另外，如前参考离线情况所述，首先完成普通AKA信令、并且随后当用户在安全链路上向服务提供者请求服务时再完成认可信令是可行的。这通常意味着验证RES并将密钥Ik、Ck发送给服务提供者，并且随后由服务提供者在收到服务请求时启动特殊的认可信令。但是，下面将主要用集成AKA和认可信令描述AKA-集成的示例。
图6B是使用已有的AKA密钥作为认可密钥对服务协议进行在线验证的示例性信号交换示意图。如果服务提供者总是在从运营商端送出密钥之前就进行服务协议的在线验证，那么COST_MAC将和Ik结合在一起作为认可密钥并且不必扩展AKA，以生成特殊的认可密钥Rk。但是，服务提供者将没有记录并保持服务协议证据的能力，因为他随后将接收密钥Ik用于会话的完整性保护。运营商可以保持对协议的散列，以使服务提供者不能回去改变数据。
结合掩蔽后的鉴定数据的认可如图7A和图7B所示，可以更改用户鉴定以通过引入掩蔽后的验证数据而允许标识证据，因而使服务提供者能够提供用户已经被实际鉴定通过的有效证据。
该总体鉴定最初是基于询问-响应过程，在该过程中鉴定/付款管理器生成期望响应XRES并且用户随后生成相应的响应RES。这里的基本思想是引入一个掩蔽函数f，它掩蔽生成的期望响应，并传输掩蔽后的期望响应XRES’而不是最初的期望响应XRES给服务提供者。用户以传统方式生成并传输相应的用户响应RES，并且服务提供者因而从运营商端接收掩蔽后的期望响应XRES’，以及从用户接收普通用户响应RES。服务提供者随后通过在运营商端所用相同掩蔽函数的一个实例计算掩蔽后的用户响应RES’。为了鉴定用户，服务提供者简单地验证计算出的掩蔽后的用户响应RES’是否与从运营商端接收到的掩蔽后的期望响应XRES’对应。该掩蔽过程使得服务提供者能够证明用户已经被正确地鉴定通过，并且同时还防止和/或解除了窃取攻击。
随后可以在付款被传输之前询问服务提供者以提供响应值、或者优选地响应-询问对和/或服务协议验证信息，以证明该用户已经实际位于该网络中和/或使用了其它服务。
显然，鉴定/付款管理器和服务提供者之间有关系，它们之间的关系意味着已经在鉴定/付款管理器和服务提供者之间交换了掩蔽函数。这对那些必须对两方共同的类似信息和/或函数也是正确的。
图7A是通过掩蔽后的鉴定数据结合服务协议的离线验证建立用户鉴定证据的示例性信号交换示意图。除了普通AKA参数之外，鉴定/付款管理器按照XRES和可选掩蔽随机询问SALT的函数生成掩蔽后的期望响应XRES’。例如，掩蔽随机询问可以基于随机询问RAND或者生成为完全独立的随机值。随后，发送掩蔽后的期望响应XRES’和随机询问RAND到服务提供者，可能连同可选的掩蔽随机SALT。如果使用带Rk的服务协议离线验证，那么就能够连同RAND、AUTN和XRES’一起发布Ik和Ck。
下面总结了基本的示例性信号交换1.RAND、AUTN、XRES’、Ik、Ck、[SALT]2.RAND、AUTN、COST_UNIT3.RES、COST_MAC服务提供者随后用相同掩蔽函数f的一个实例和相同随机输入RAND/SALT生成RES’并检查掩蔽后的响应RES’是否等于掩蔽后的期望响应XRES’。服务提供者优选地在适当位置(以为后来获取)存储RES、RAND、USER作为鉴定证据信息，连同COST_UNIT、COST_MAC作为服务协议验证信息，如果必要的话还作为用户鉴定和服务协议的证据。如果受到鉴定/付款管理器或一些其它相关方面询问要求提供给定用户的鉴定证据和接受的服务协议，服务提供者可以把该信息发送给运营商一方。
4.RES、RAND、USER ID、COST_UNIT、COST_MAC应该注意到可以离线传输由服务提供者提供的多种服务的多批随机的服务协议验证信息而不需要任何重新验证。
优选地，鉴定/付款管理器随后取出与给定用户相关的密钥Ki并根据接收到的RAND和密钥Ki计算期望响应值XRES，并最后比较接收到的RES值和计算出的XRES值，以验证用户是否已经在服务器提供者处被鉴定通过。如果RES值匹配XRES值，就认为证明信息有效。用相同的方式，鉴定/付款管理器根据从服务提供者接收的认可密钥Rk和RAND、COST_MAC计算期望的服务协议验证信息XMAC。鉴定/付款管理器随后比较COST_MAC和XMAC以验证服务协议。
另外，服务提供者简单地传输给定用户的RES值和用户ID。这种情况下，鉴定/付款管理器通常需要为用户存储XRES值(或者允许重新计算相应XRES值的RAND值)以使能够在RES和XRES之间进行比较。
如果从鉴定/付款管理器没有显式地发送可选的掩蔽随机询问SALT，服务提供者可以在鉴定的验证之前导出它，优选地根据随机询问RAND。随后由服务提供者通过用户响应RES和可选的、接收到的或导出的掩蔽随机询问SALT作为掩蔽函数f的输入，计算掩蔽后的用户响应RES’。
如上，掩蔽随机询问SALT是可选的，并且可以从鉴定过程忽略掉。这种情况下，没有随机询问SALT分别是用于计算掩蔽后的期望响应XRES’和掩蔽后的用户响应RES’的掩蔽函数f的输入。但是，为了增加安全性，尤其是战胜预计算攻击，优选地包括掩蔽随机询问SALT作为掩蔽函数输入。因而，掩蔽随机询问SALT可以由鉴定/付款管理器生成为完全的随机值并且随后和掩蔽后的期望响应XRES’和随机询问RAND一起被发送到服务提供者。但是，为了避免运营端和服务器提供者之间的额外信令，也可以从随机询问RAND导出掩蔽随机询问SALT。这种情况下，鉴定/付款管理器优选的由随机询问RAND的某一函数h生成掩蔽随机询问SALT。因此，不需要向服务提供者发送特殊的掩蔽随机询问SALT，而可以用相同的函数h从随机询问RAND生成掩蔽随机询问SALT。可用掩蔽后的随机询问SALT的示例只是简单地复用随机询问RAND作为掩蔽后的随机询问SALT，而h因此被表示为单一函数。
函数h可以是公共函数或与服务提供者和鉴定/付款管理器的法人(例如归属运营商)之间的商业协议相关或一起发布的函数。
一方面由鉴定/付款管理器用它来生成掩蔽后的期望响应，别一方面由服务提供者用它计算掩蔽后的用户响应的函数f可以是单向函数和/或散列函数。优选地，掩蔽函数是加密散列函数，具备使之不能适合找到两个散列到一个公共值的不同输入的单路功能和属性。
掩蔽函数f可以是公共函数，或者鉴定/付款管理器和服务提供者所知道的专用函数。在后一种情况中，专用掩蔽函数可以和鉴定/付款管理器的法人(例如给定的归属运营商)和服务提供者之间的商业协议相关。如果鉴定/付款管理器的法人，例如归属运营商，和几个不同的服务提供者有这种商业协议，可以由该运营商为每个服务提供者使用一个相应的专用函数，即每个运营商-提供者协议以一个专用掩蔽函数表明。
为了能够顺利进行与已有的基础结构有关的迁移，优选地当计算分布的期望响应时，要通知服务提供者是否已经采用了掩蔽函数。因而，优选地用这样的指示扩展用于发布鉴定参数的协议。同样，如果存在不同掩蔽函数之间的选择，还可以在协议中包括要使用哪个掩蔽函数的指示。
如果希望在线过程，如图7B所示，就或多或少地直接把鉴定证明信息和服务协议验证信息从服务提供者转发到鉴定/付款管理顺。
下面总结了基本的示例性信号交换1.RAND、AUTN、XRES’、[SALT]2.RAND、AUTN、COST_UNIT3.RES、COST_MAC服务提供者生成RES’并检查掩蔽后的响应RES’是否等于掩蔽后的期望响应XRES’。然后信令继续进行。
4.RES、COST_UNIT、COST_MAC在运营商一方，分别比较RES、COST_MAC和XRES、XMAC。如果验证成功，就把密钥安全地传输给服务器提供者。
5.Ik、Ck如前所述，对服务协议的在线验证，可以使用专用认可密钥Rk或完整性密钥Ik作为计算COST_MAC和XMAC参数的认可密钥。
对于掩蔽过程上的更多信息，参考我们的共同未决US专利申请序列号10/278,362，2002年10月22号提交，在此引入它。
示例性基于记帐单的方法下面我们将描述采用基于记帐单的方法的服务协议AKA-集成认可的一些例子。
在文献中基于记帐单的付款系统通常是众所周知的，如参见US专利5,739,511.
一种特别的记帐单系统是基于由已知散列函数重复(给定数量的)N次散列BASE_TICKET到START_TICKET中的思想START_TICKET＝HASH(HASH(..HASH(BASE_TICKET)))，其中BASE_TICKET通常对应于TICKET_N，而START_TICKET对应于TICKET_0.付费方生成START_TICKET或所用的最终TICKET的原象。接收付款的一方随后可以检查该原象是否散列到那个记帐单中。因为记帐单是由散列函数或者其它适当的单向函数相互关联的，可以通过重复应用该函数而从任意更多的记帐单获得START_TICKET。这意味着不需要重复进行复杂耗时的验证过程就能获得对付款事务进度的检查。必须应用散列函数以获得起始记帐单的次数与服务的用户所消耗的记帐单的数量直接相关。
这种基于记帐单的系统要安全的一个条件是基本记帐单是不可预测的。因而可以通过级联一些随机实体和其它已知信息元素的散列形成基本记帐单。
依照本发明，可以用这种方式扩展先前描述的认可方案以及它的变型，以使用户能够返回START_TICKET和START_TICKET和COST_UNIT的加密认可MAC(表示为TICKET_MAC)以使能够对若干事件/服务进行认可的付款，而不必和运营商之间有重复协议或者执行新的用户鉴定。
怎样生成START_TICKET有若干变型。主要的特征是服务提供者应该能够验证START_TICKET是真实的，并且是由鉴定通过的用户发出或者是代表鉴定通过的用户而发出的。
记帐单生成的一个特定解决方案是用户生成BASE_TICKET并导出START_TICKET。用户随后使用认可密钥(如Rk)并在START_TICKET和COST_UNIT之上计算认可TICKET_MAC，并且发送START_TICKET和TICKET_MAC给服务提供者。服务提供者或者为离线过程中可能的后来验证存储验证信息，或者把该消息在线发送给运营商一方验证TICKET_MAC以接受该记帐单。
图8A是基于记帐单的认可以及可能的离线验证的示例性信号交换示意图。
下面总结了基本的示范性信号交换1.RAND、AUTN、Ik、Ck、XRES服务提供者生成相关的服务协议信息，这里通过费用参数COST_UNIT举列说明，并且优选地把这个信息以及必需的AKA参数发送给用户。
2.RAND、AUTN、COST_UNIT用户检查AUTN，如果没有问题，就计算RES、密钥Ik、Ck，优选地还有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服务提供者为以后的服务协议证明保留验证信息，例如用户ID、RAND、COST_UNIT和COST_MAC。
因为记帐单是由用户使用的，服务提供者可以为每个帐单检查TICKET-i-＝HASH(TICKET-i)，或者可以通过反复应用散列函数获得START-TICKET。如果需要或者请求，服务提供者可以在以后转发验证信息，如COST_UNIT、START_TICKET、LAST_TICKET和TICKET_MAC，给运营商端的鉴定/付款管理器。这使得鉴定/付款管理器能够验证TICKET_MAC并确定所消耗的记帐单数量以便向用户收取适当的费用。
图8B是基于记帐单的认可以及离线验证的示例性信号交换示意图。这个例子涉及在线用户鉴定以及对服务协议基于记帐单的验证。
下面总结了基本示例性信号交换1.RAND、AUTN服务提供者生成相关的服务协议信息以传输给用户，如服务费用参数COST_UNIT。
2.RAND、AUTN、COST_UNIT用户检查AUTN，如果没有问题，就计算RES、密钥Ik和Ck，优选地还有Rk。用户生成BASE_TICKET并得到START_TICKET，然后计算TICKET_MAC。TICKET_MAC和START_TICKET连同RES都被返回给服务提供者。
3.RES、START_TICKET、TICKET_MAC对于在线鉴定和验证，服务提供者转发RES到运营商端。可以同时向RES附加COST_UNIT、START_TICKET和TICKET_MAC。
4.RES、COST_UNIT、START_TICKET、TICKET_MAC鉴定/付款管理器检查RES是否等于期望响应(XRES)以及TICKET_MAC是否等于期望的XMAC。如果这些条件都满足，就把密钥发给服务提供者。
5.Ik、Ck用户随后开始使用记帐单，并且服务提供者检查记帐单。接收到的LAST_TICkET最终被从服务提供者转发给运营商端，以进行验证和付款的后续处理。
图9是基于记帐单的认可的示例性信号交换示意图，其中基础记帐单是由鉴定/付款管理器代表用户准备的。在这个例子中，运营商端生成根据COST_UNIT信息和从服务提供者接收到的(或由运营商代表服务提供者准备的)其它相关信息生成BASE_TICKET，并导出START_TICKET。运营商随后用认可密钥(如Rk)把BASE_TICKET加密为ENC_TICKET＝ENC(Rk，BASE_TICKET)并将它连同START_TICKET一起发送给服务提供者。服务提供者随后转发ENC_TICKET，优选地连同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，优选地还有Rk。用户通过用Rk解密ENC_TICKET而方便地生成BASE_TICkET，并随后得到START_TICkET。用户返回RES给服务提供者。
3.RES对于在线用户鉴定，服务提供者转发RES给运营商端。
4.RES鉴定/付款管理器检查RES是否等于期望响应XRS，并在鉴定成功后发送会话密钥给服务提供者。
5.Ik、Ck用户随后启动消耗记帐单，并且服务提供者检查记帐单。接收到的LAST_TICKET最被从服务提供者转发给运营商进行验证和付款的后续处理。
应该理解在整个信令的鉴定阶段不必包括填写记帐单过程，但以后必须执行。
一般合同签署如前所示，服务协议信息可以是一般的电子合同。对于一般的电子合同签署，一个允许服务提供者离线验证的特别设计的实施方案涉及通过相同掩蔽函数的本地实例对由服务协议管理器生成期望验证信息和用户签署的验证信息都进行掩蔽。
下面用于签署包括多个不同服务协议信息的合同的解决方案在它的基本形式上和上述基于记帐单的付款系统有相似之处，它还利用和用于用户鉴定认可相同的掩蔽机制。
该解决方案基于用户和通用服务协议管理器有共享密钥的假设。当稍微更加集中在整个过程的付款部分上时，下面服务协议管理器有时被称作是付款提供者。如果付款提供者是一个蜂窝GSM/UMTS运营商，就存在这样的共享密钥且并且存储在用户端的(U)SIM中。图10中示出了相对一般的设置。
优选地，服务提供者20或付款提供者30准备将由用户10签署的合同。通常，该合同随后被安全地发布给所有有关各方。运营商端的付款提供者，使用键控散列函数中的共享密钥计算合同的键控散列，表示为合同签名MAC。键控散列函数可以作为真实的键控散列或后跟键控函数的散列来执行。适合AKA和(U)SIM情况的特定解决方案是在AKA过程中把合同散列到与普通RAND对应的变量RAND_CONT中，然后把这个RAND_CONT传入AKA过程，并以这种方式生成与普通RES对应的签名MAC。签名AMC还可在出自AKA过程的密钥之一的帮助下生成。这通常假定正确的AUTN变量可用或者序列号检查机制被禁止。
签名MAC随后经过(公共)掩蔽函数(这指前述掩蔽函数f的一般化)。掩蔽函数是加密散列函数，即它在实践中不可能找到该函数的输出的原象。掩蔽后的签名MAC被发送到服务提供者20由他用来验证用户的合同签署。
当用户签署合同时他还采用了共享密钥并通过键控散列函数计算签名MAC。用户发送签名MAC到服务提供者，服务提供者知道公共掩蔽函数并因此检查签名。
为了给用户一个简单的过程检查合同的可靠性，可以在发送合同本身的同时把掩蔽后的签名MAC发给用户。合同还可包含完整的付款过程中所用的其它信息，例如公共掩蔽函数中所用的SALT。
当使用AKA过程时，合同签署思想等于让AKA过程中的RAND成为用户将要签署的合同数据的HASH。
图11是当再使用AKA过程时，图10的合同签署实现的示例性信号交换示意图。
在接收到来自用户的服务请求时，服务提供者把接收到的用户ID、如果合同CONT是由服务提供者准备的话还要连同它一起，转发给服务协议管理器。服务协议管理器按照合同CONT的函数y生成RAND_CONT。服务协议管理器随后根据Ki和RAND_CONTXMAC＝g(Ki，RAND_CONT)计算期望的签名MAC，表示为XMAC。这个签名MAC随后由通用掩蔽函数m掩蔽为掩蔽后的期望签名MAC，表示为XMAC’，还可选择用随机掩蔽询问RAND/SALT作为该掩蔽函数的附加输入。
1.XMAC’、RAND/SALT服务提供者随后转发合同CONT给用户。
2.CONT如果RAND_CONT不是从运营商端转发来的，用户就用函数y的实例生成它，并且根据Ki和RAND_CONT计算用户签名MACMAC＝g(Ki，RAND_CONT)。这个MAC被转发给服务提供者。
3.MAC服务提供随后可用通用掩蔽函数m的实例计算掩蔽后的用户签名MAC，表示为MAC’，并最终比较计算出的MAC’和从运营商端接收到的XMAC’以验证合同。优选地，服务提供者保留像MAC、RAND_CONT/CONT和USER ID这样的验证信息。如果受到服务协议管理器询问或者希望服务协议管理器的在线过程，服务提供者可以把这个验证信息转发给服务协议管理器。
服务协议管理器随后验证MAC是否等于XMAC，相等则意味着基于合同的服务协议得到了最终验证并且用户至少是隐含地通过了鉴定。
一般合同签署过程的新特性是它允许由服务提供者通过引入掩蔽后的验证数据进行离线验证。换句话说，服务提供者(SP)和运营商之间进行的合同准备在时间上可以从用户和服务提供者(SP)之间进行的合同签署/验证分开。这个方案的自然应用包括当在一个SP-运营商会话中为不同条件下的相同用户(例如，在不同时间或不同服务级别)或者相似条件下的多个用户(例如，当提供订购意向时)准备多份合同时的情况。
密钥材料的分离在另一方法中，再次返回服务协议的AKA-集成认可，AkA数据可以用作伪-随机函数(PRF)的安全输入以导出一组新的AKA数据和/或认可密钥。
通过这个例子，不是对AKA过程进行直接扩展以生成附加密钥Rk，而是密钥Ck和Ik可以用作伪随机函数的安全输入，伪随机函数用来获得新的机密性密钥Ck’和完整性密钥Ik’、认可密钥(Rk)以及新的响应(RES’)。使用并发布Ck’和Ik’而不是Ck和Ik。采用这种方式就可以不必改变通常实现在智能卡中的AKA方案。
一个主要的好处是当访问服务时，可以分离GSM/UMTS使用的密钥材料和用于用户鉴定和认可的密钥材料。因而即使用于服务的键控材料丢失或被盗，它也不能被用来访问基础通信服务。
采用分离步骤的一个变型是用它来生成完整的AKA方案中所用的新的共享密钥。
如果我们通常用K(i)表示键控材料，那么导出步骤可以表示K(i+1)＝PRF(K(i)，SALT)，其中PRF是伪随机函数。SALT应该包括随机信息，并可以包含如对服务和/或服务提供者唯一的信息。例如，PRF可以被实现为安全实时传输协议(SRTP)。
尽管K(i)通常是来自基本AKA的输出数据，但应该理解其它数据也可用作PRF函数的参数。另外，输入参数的个数和结果变量根据实际上的特定应用可能会有所变化。
图12A是基于不同的分离的键控组的服务协议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’，并存储验证信息以为以后需要时取回。如果受到询问或者自己主动，服务提供者可以转发验证信息给运营商端进行服务协议验证。
图12B是基于不同的分离的键控组的服务协议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’，并转发验证信息给运营商侧以进行服务协议验证。
4.COST_UNIT、COST_MAC如果COST_MAC匹配XMAC，就将会话密钥Ik’、Ck’传输到服务提供者以用于服务提供者和用户之间的通信中。
5.Ck’、Ik’当然，上述基于记帐单的解决方案还可以基于从初始AKA参数导出的密钥材料。
应该理解用于普通网络接入的密钥材料和用于访问由服务提供者提供的服务的鉴定和密钥材料的分离是本发明的一个一般的独立特征，它并不限于与服务协议认可的任意组合。
在上述过程中，假定SALT在运营商端以及用户那里都可用。如果SALT等于RAND，这一般是对的，但是如果应该使用像时间戳或独立于RAND值的SALT这样的其它信息，这些值必须得到用户同意或者发送给用户。一个尤其重要的情况是，当用户不能从上下文确定真实的SP_ID(服务提供者身份)但又不得不依赖于接收到的信息而且这个SP_ID是用来分离用于不同服务提供者的参数。这种情况下可以在标准AKA过程中的AUTN参数中传输该信息，或者如上为合同签署所描述的MACed消息中发送，即键控MAC保护敏感参数。用于键控MAC的密钥应该只有在运营商和用户之间共享，例如Ik或Rk。
这一般对应于从基本AKA过程生成服务相关的AKA参数。
涉及付款代理的示性性应用图13是涉及身份代理及付款代理并采用身份代理、付款代理和服务提供者之间建立的信用链的分布式实现的示例性示意框图。
在将要描述的场景中，我们引入了一个附加参与者，即付款代理40。因而图13的设置包括用户10、服务提供者20、与用户10共享密钥的鉴定管理器30以及付款代理40。付款代理可以和若干运营商/鉴定管理器有关系并调停运营商和服务提供者之间的用户鉴定信息，帮助验证支付并处理付款/收费数据的付款/用户能力。付款代理可以充当可信第三方的角色，该角色能够验证用户服务协议。
付款可以被链接到用户已经和其有付款关系的运营商，或者通过独立方或由付款代理自己链接或执行。
我们还引入用户身份代理的概念，通常配置在与鉴定管理器相关的运营商端。用户可能想要对不同的服务使用不同的身份。身份代理通常把用于服务访问的用户身份映射到用于运营商的用户身份(即IMSI)。身份代理可以在多个步骤发生。
用户的服务ID和用户在运营商处的ID之间的关系必须交给身份代理。通常运行身份代理的运营商将生成这个配对。出于安全原因，自然要由运营商运行最后的身份代理功能。
服务ID可以有若干部分。单个部分可以指示要使用的付款代理和身份代理。一个用户当然可以对给定的运营商身份使用若干付款代理。付款代理可以保持当无法从用户服务ID获得该信息时显示哪个运营商与给定用户服务ID相关的记录。
下面，将参考图13所示场景描述两个信令方案。第一个方案用于后付费订购用户，第二个方案用于预付费服务。
后付费场景图14是图13所示设置中后付费场景中的服务协议认可的示例性信号交换示意图。
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”并确定用户的鉴定级别。服务提供者现在用Ck”和Ik”启动对到用户的安全连接的使用。
当调用一个用户必须为之付费的服务时，该用户应该发送COST_MAC。
8.COST_MAC9.COST_UNIT、COST_MAC付款代理验证COST_MAC，并启动付款过程。
10.OK预付费场景图15是图13所示设置中预付费场景中服务协议认可的示例性信号交换示意图。
这种情况下我们示出了当用户使用预付费账户并得到由付款代理生成的记帐单时的情况。这里，忽略了为导出分离的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#发给付款代理。
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启动对到用户的安全连接的使用。
当调用了用户必须为其付费的服务时，用户应该发送TICKET给服务提供者。为此用户解密ENC_TICkET并重复HASH函数以检查他拥有的记帐单的数量并检查START_TICKET是否有效。
然后用户发送TICKET，称为TICKET_i。
8.TICKET_i服务提供者检查接收到的记帐单。当会话被关闭时，服务提供者将接收到的最后一个记帐单发给付款代理。
9.LAST_TICKET付款代理检查接收到的记帐单并生成收费记录，收费记录被发给运营商。
10.CHARGING_RECORD最后，据此调整用户帐户。
重-鉴定服务提供者出于不同原因可能想要有重新鉴定用户的可能。实现此一目标的一种途径是重复生成K(n)，即当第n次鉴定发生时，使用键控材料K(n+1)＝PRF[K(n)，[RAND，SP_ID]]。这意味着服务提供者访问伪随机函数PRF的一个实例PRF，以便能够生成所需鉴定参数和会话密钥。简单地说，服务提供者用伪随机函数生成第n+1阶的新会话密钥和期望响应，并在重-鉴定请求中发送RAND给用户。用户随后用随机伪函数生成新的会话密钥和n+1阶用户响应，并返回生成的n+1阶用户响应给服务提供者。服务提供者随后可以验证接收到的响应，并根据新会话密钥开始和用户通信。
优选地，n被发送给用户，用户可以保持一个简单的重放列表以免受重放攻击。
实现方面上的更多上述步骤、动作和算法可以用软/硬件或其中的任意组合来实现。对于硬件实现，可以使用ASIC(专用集成电路)技术或任意其它传统电路技术。尽管出于安全原因首选特殊的防篡改硬件，但受到适当保护的软件实现通常更方便。
图16是依照本发明的优选实施方案示出服务协议管理器的一个实例的示意框图。图16的服务协议管理器30主要包括到外部通信链路的通信接口31、数据库32、鉴定和键控单元33、验证单元36、可选记帐单元37以及付款/收费单元38。数据库32包括像用户ID和相关密钥Ki信息这样的信息。鉴定和键控单元33用于生成相关鉴定和密钥参数，并且可以保存不同实施方案中所用的可选的掩蔽和伪随机函数。验证单元36执行相关计算和/或比较，以验证用户是否已经接受了给出的服务协议。可选的记帐单元37可以代表用户生成相关记帐单并/或完成记帐单验证。顾名思义，付款单元38处理付款的传输并确保对正确的帐户正确地执行了收费。
图17是依照本发明的优选实施方案说明服务提供者的一个实例的示意性框图。图17的服务提供者20主要包括到外部通信链路的通信接口21、合同准备单元22、可选鉴定单元23、信息转发和/或存储单元25、以及可选的验证单元26。在合同准备单元22中，服务提供者通常依照所请求的服务以及服务使用的当前条件准备相关服务协议信息。另外，合同准备是由另一方代表服务提供者完成的，但通常这种外部合同准备无论如何都要从服务提供者发起。对掩蔽后的合同签署和/或用户鉴定，服务提供者可以在验证单元26和/或鉴定单元23中完成对接受的服务协议的验证和/或用户鉴定。在离线过程中，服务提供者为了以后想转发验证信息给服务协议管理器30或由服务协议管理器指定的其它方可能想在单元25中存储验证信息。
图18是依照本发明的优选实施方案说明用户终端的一个实例的示意性框图。图18的用户终端10主要包括到外部通信链路的通信接口11和防篡改模块12。防篡改模块可能类似于可以移动装置的SIM或USIM卡，包括I/O单元101、AKA算法单元102、安全实现(封装)的共享密钥Ki 103、用于像MAC/解密等目的的加密处理单元104，以及用于基于记帐单的认可的可选记帐单元105。甚至可以通过作为(U)SIM的(U)SIM应用工具包环境中的软件实现像加密处理这样的功能，在AKA单元和应用工具包环境之间有适当的接口。
仅作为示例给出了上述实施方案，应该理解本发明不止于此。保持这里所公开和提出权利要求的基本的基础原理的更多更改、变化和改进都在本发明的范围和精神内。
权利要求
1.用于通信系统中用户和服务提供者之间的服务协议认可的一种方法，所述方法包括以下步骤-在用户终端和服务协议管理器之间安全地共享密钥，所述服务提供者和所述服务协议管理器有信用关系；-准备服务协议信息；-根据所述共享密钥对所述服务协议信息进行加密处理以生成用户签署的服务协议验证信息；-转发所述用户签署的验证信息给所述服务提供者，以使能够根据所述服务提供者和所述服务协议管理器之间的信用关系验证服务协议。
2.依照权利要求1的方法，其中所处对服务协议信息进行加密处理的步骤被安全实现在所述用户终端中，以生成所述用户签署的验证信息。
3.依照权利要求1或2的方法，其中所述对服务协议信息进行加密处理的步骤是根据从所述共享密钥局部导出的认可密钥执行的。
4.依照权利要求2的方法，还包括下列步骤-在所述服务协议管理器至少部分根据所述服务协议信息和所述共享密钥生成期望的验证信息；-在所述服务协议管理器验证所述用户签署的验证信息是否对应于所述期望的验证信息。
5.依照权利要求2的方法，其中所述用户签署的验证信息是响应自所述服务协议管理器启动的随机询问和所述服务协议信息而在所述用户终端中生成的。
6.依照权利要求2的方法，其中所述用户签署的验证信息是根据用户端初始化的记帐单和所述服务协议信息而在所述用户端中生成的。
7.依照权利要求1的方法，其中所述准备服务协议信息的步骤是由所述服务提供者初始化的。
8.依照权利要求1的方法，其中所述对服务协议信息进行加密处理的步骤包括下列步骤-所述服务协议管理器根据所述共享密钥对所述服务协议信息进行加密处理，以生成所述服务协议信息的加密表示，所述加密表示被转发给所述用户；和-所述用户终端根据所述共享密钥对所述加密表示进行加密处理，以生成所述用户签署的验证信息。
9.依照权利要求8的方法，其中所述服务协议管理器完成加密处理的步骤包括以下步骤-根据所述服务协议信息生成记帐单；和-根据从所述共享密钥局部导出的认可密钥加密所述记帐单；并且所述用户终端进行加密处理的步骤包括，根据从所述共享密钥局部导出的所述认可密钥对所述加密的记帐单解密的步骤。
10.依照权利要求的方法，其中所述服务协议信息是一般的电子合同，并且所述方法还包括下列步骤-所述服务协议管理器根据所述共享密钥和所述电子合同生成期望的服务协议验证信息；-所述服务协议管理器通过一个掩蔽函数掩蔽所述期望的验证信息；-所述服务协议管理器转发所述掩蔽后的期望验证信息给所述服务提供者；-所述服务提供者通过相同掩蔽函数的一个实例掩蔽所述用户签署的验证信息，以生成掩蔽后的用户签署的验证信息；-所述服务提供者验证所述掩蔽后的用户签署的验证信息是否对应于从所述服务协议管理器获得的所述掩蔽后的期望验证信息。
11.依照权利要求10的方法，其中所述服务协议管理器生成期望的服务协议验证信息的步骤包括，应用合同的一个散列作为基于普通询问-响应的鉴定和密钥协定过程中的随机询问的步骤。
12.依照权利要求10的方法，其中所述掩蔽函数是加密散列函数。
13.依照权利要求1的方法，其中所述认可方法被和用于网络接入的基于询问-响应的鉴定和密钥协定(AKA)过程集成在一起，所述共享密钥与用于AKA的密钥相同。
14.依照权利要求13的方法，其中用于服务协议认可的键控材料与用于所述基于询问-响应的AKA过程的键控材料隔离。
15.依照权利要求14的方法，其中所述用于认可的键控材料是根据作为所述伪随机函数的输入的AKA的键控材料通过所述伪随机函数生成。
16.依照权利要求14的方法，其中所述用于认可的键控材料被绑定到和鉴定管理器合作的一个具体的付款代理，所述鉴定管理器和所述用户终端共享所述密钥。
17.依照权利要求14的方法，其中所述用于认可的键控材料被绑定到所述服务提供者，以便将所述键控材料同另一服务提供者的相应键控材料隔开。
18.依照权利要求1的方法，其中所述服务协议信息包括服务收费信息和，并且所述服务协议管理器是代表用户处理所述服务的付款的付款提供者。
19.依照权利要求1的方法，其中所述服务协议管理器包括用户身份代理和安排在所述服务提供者和所述身份代理之间的付款代理，在服务提供者、付款代理和身份代理之间建立起了一个信用链，所述身份代理与所述用户终端共享所述密钥。
20.依照权利要求19的方法，还包括所述付款代理根据从所述身份代理获得、根据所述共享密钥导出的认可密钥验证用户签署的验证信息的步骤。
21.用于通信系统中用户和服务提供者之间的服务协议认可的一种系统，所述系统包括-在用户终端和服务协议管理器之间共享密钥的装置，所述服务提供者和所述服务协议管理器之间有信用关系；-准备服务协议信息的装置；-根据所述共享密对所述服务协议信息进行加密处理，以生成用户签署的服务协议验证信息的装置；和-转发所述用户签署的验证信息到所述服务提供者，以使能够根据所述服务提供者和所述服务协议管理器之间的信用关系对服务协议进行验证的装置；22.依照权利要求21的系统，其中对所述服务协议信息进行加密处理的所述装置被安全实现在所述用户终端中。
23.依照权利要求21或22的系统，其中对所述服务协议信息进行加密处理的所述装置根据从所述共享密钥局部导出的认可密钥操作。
24.依照权利要求22的系统，还包括-在所述服务协议管理器，至少部分根据所述服务协议信息和所述共享密钥生成期望的验证信息的装置；和-在所述服务协议管理器，验证所述用户签署的验证信息是否对应于所述期望的验证信息的装置。
25.依照权利要求22的系统，其中所述用户签署的验证信息是响应从服务协议管理器启动的随机询问以及所述服务协议信息而在所述用户终端中生成的。
26.依照权利要求22的系统，其中所述用户签署的验证信息是根据用户端初始化的记帐单和所述服务协议信息在所述用户终端中生成的。
27.依照权利要求21的系统，其中所述服务协议信息是由所述服务提供者准备的。
28.依照权利要求21的系统，其中对所述服务协议信息进行加密处理的所述装置包括-在所述服务协议管理器，根据所述共享密钥对所述服务协议信息进行加密处理，以生成所述服务协议信息的加密表示的装置，所述加密表示被转发给所述用户；和-在所述用户终端，根据所述共享密钥对所述加密表示进行加密处理，以生成所述用户签署的验证信息的装置。
29.依照权利要求28的系统，其中在所述服务协议管理器进行加密处理的所述装置包括-根据所述服务协议信息生成记帐单的装置；和-根据从所述共享密钥局部导出的认可密钥加密所述记帐单的装置；并且在用户终端中进行加密处理的所述装置包括，根据从所述共享密钥局部导出的所述认可密钥对所述加密的记帐单解密的装置。
30.依照权利要求21的系统，基中所述服务协议信息是一般电子合同，并且所述系统还包括-在所述服务协议管理器根据所述共享密钥和所述电子合同生成期望的服务协议验证信息的装置；-在所述服务协议管理器由掩蔽函数掩蔽所述期望的验证信息的装置；-在所述服务协议管理器转发所述掩蔽后的期望的验证信息给所述服务提供者的装置；-在所述服务提供者由相同掩蔽函数的实例掩蔽所述用户签署的验证信息以生成掩蔽后的用户签署的验证信息的装置；-在所述服务提供者验证所述掩蔽后的用户签署的验证信息是否对应于从所述服务协议管理器获得的掩蔽后的期望的验证信息的装置。
31.依照权利要求30的系统，其中生成期望的服务协议验证信息的所述装置包括，应用合同的加密散列作为基于普通询问-响应的鉴定和密钥协定过程中的随机询问的装置。
32.依照权利要求30的系统，其中掩蔽函数是加密散列函数。
33.依照权利要求21系统，其中所述认可系统被和用于网络访问的基于询问-响应的鉴定和密钥协定(AKA)过程的系统集成在一起，所述共享密钥与用于AKA的共享密钥相同。
34.依照权利要求33的系统，还包括将用于服务协议认可的键控材料同用于所述基于询问-响应的AkA的键控材料隔离的装置。
35.依照权利要求34的系统，其中所述用于认可的键控材料是根据用于AKA的键控材料作为所述伪随机函数的输入通过所述伪随机函数而生成的。
36.依照权利要求34的系统，其中所述用于认可的键控材料被绑定到与鉴定管理器合作的一个具体付款代理，所述鉴定管理器和所述用户终端共享所述密钥。
37.依照权利要求34的系统，其中所述用于认可的键控材料被绑定到所述服务提供者，以便将所述键控材料与用于别的服务提供者的相应键控材料隔离。
38.依照权利要求21的系统，其中所述服务协议信息包括服务收费信息，并且所述服务协议管理器是用于代表用户处理所述服务的付款的付款提供者。
39.依照权利要求21的系统，其中所述服务协议管理器包括用户身份代理和安排在所述服务提供者和所述身份代理之间的付款代理，并在服务提供者、付款代理和身份代理之间建立了一个信用链，所述身份代理与所述用户共享所述密钥。
40.依照权利要求39的系统，还包括在所述付款代理根据从所述身份代理获得的根据所述共享密钥导出的认可密钥验证所述用户签署的验证信息的装置。
41.一种用户终端包括-安全地保存与外部服务协议管理器共享的密钥的装置，所述服务协议管理器与服务提供者之间有信用关系；-接收代表用户和所述服务提供者之间的服务协议的信息的装置；-根据所述共享密钥对所述服务协议表示信息安全地进行加密处理，以生成用户签署的服务协议验证信息的装置；-转发所述用户签署的验证信息到所述服务提供者，以能够根据所述服务提供者和所述服务协议管理器之间的信用关系对服务协议进行验证的装置。
42.帮助管理通信系统中用户和服务提供者之间的服务协议的一种服务协议管理器，所述服务协议管理器包括-安全保存与用户终端共享的密钥的装置，所述服务协议管理器与所述服务提供者有信用关系；-接收由用户终端根据所述服务协议的信息表示和所述共享密钥生成的用户签署的服务协议验证信息的装置；-根据所述共享密钥验证用户签署的验证信息，并因此而确认用户对服务协议的接受的装置。
43.通信系统中依照用户和服务提供者之间给定的服务协议向用户提供服务的一种服务提供者，所述服务提供者包括-与服务协议管理器建立信用装置的装置，所述服务协议管理器与用户终端共享密钥；-从所述用户终端接收至少部分根据所述服务协议的信息表示和所述共享密钥生成的用户签署的验证信息的装置；-通过掩蔽函数生成掩蔽后的用户签署的验证信息的装置；-从所述服务协议管理器接收由相同掩蔽函数的一个实例掩蔽后的期望的验证信息的装置，所述期望的验证信息是至少部分根据所述服务协议信息和所述共享密钥生成的；-验证掩蔽后的用户签署的验证信息是否与所述掩蔽后的期望的验证信息对应，以确认用户对服务协议的接受的装置。
44.用于改进的基于询问-响应的鉴定和密钥协定(AKA)的一种方法涉及用户、服务提供者以及和所述服务提供者有信用关系的网络运营商，所述网络运营商与所述用户共享密钥以相互生成AkA参数，其中改进是通过将由网络运营商管理的用于访问网络的第一组AKA参数与用于访问由服务提供者提供的服务的第二组AKA参数分开而实现的，而将这两组AKA参数分开是通过将所述第一组AKA参数的部分表示用作所述第二组AKA参数的输入的预定函数。
45.依照权利要求44的方法，其中所述第一组AKA参数和所述第二组AKA参数是在网络运营商端以及用户端根据所述共享密钥和在网络运营商端启动的询问而生成的，所述第二组AkA参数被从所述网络运营商安全地传输到所述服务提供者。
46.依照权利要求45的方法，其中所述服务提供者还通过将所述第二组AkA参数的至少一部分用作输入的所述预定函数为重-鉴定目的而生成另一组AKA参数。
47.依照权利要求44的方法，其中所述预定函数是一个伪随机函数。
全文摘要
本发明通常涉及通信系统中的用户(10)和服务提供者(20)之间的有效认可。引入了一个额外的可信方(30)，所谓的服务协议管理器，并且本发明基于该服务协议管理器(30)与用户终端(10)共享一个密钥(Ki)并且服务提供者(20)与该服务协议管理器(30)有信用关系的思想。本发明提出的认可方案还基于相关服务协议信息的准备、根据共享密钥(Ki)对这个信息的加密处理(14/34)以便生成用户签署的服务协议验证信息。用户签署的验证信息随后被转发到服务提供者(20)以根据服务提供者(20)和服务协议管理器(30)之间的信用关系实现对服务协议的验证(26/36)。
文档编号G06Q20/00GK1659820SQ03813707
公开日2005年8月24日 申请日期2003年6月4日 优先权日2002年6月12日
发明者R·布罗姆, A·梅赫斯 申请人:艾利森电话股份有限公司