CN1640092A - 用于提供带客户授权验证的密钥管理协议的系统和方法 - Google Patents

Abstract

向客户(102)提供授权数据拷贝的方法和系统，其中该授权数据拷贝是客户可以访问并利用的。该方法非常适合于利用票概念的密钥管理协议。授权数据的两份拷贝，客户拷贝与服务器拷贝，包括在客户请求用于指定应用服务器(106)的票的地方并转发到客户。客户能够访问授权数据的客户拷贝，使得客户可以验证请求并确定所请求内容和/或服务的使用授权。

Description

用于提供带客户授权验证 的密钥管理协议的系统和方法

技术领域

本发明总体上涉及网络安全，更具体而言，涉及用于当从应用服务器请求内容时提供客户保密性的方法和系统。

背景技术

互联网是一种不安全的网络。许多在互联网上使用的协议都不提供任何安全性。没有利用加密术或任何其它类型安全措施在互联网上传输的数据被称作是“显文”传输的。使黑客们“嗅探”出在互联网上显文传输的数据，如口令、信用卡号、客户身份及姓名等的工具很容易得到。因此，在互联网上发送未加密数据的应用是非常容易受到攻击的。

Kerberos是一种设计成通过利用安全密钥加密技术为客户/服务器应用提供鉴别的已知网络鉴别协议的例子。可以从麻省理工学院获得的Kerberos协议利用加密技术，从而据称客户可以通过不安全的网络连接向服务器证明其身份(反之亦然)。在客户与服务器利用Kerberos证明他们的身份后，他们还可以加密他们的所有通信，以便当他们进行交易时据称可以确保保密性及数据的完整性。

本发明就是关于这些及其它与网络安全领域有关的背景信息因素展开的。

发明内容

本发明提供了一种向客户提供可由该客户访问并使用的授权数据拷贝的方法，该方法包括步骤：从客户接收鉴别服务器请求(AS_REQ)消息；产生鉴别服务器应答(AS_REP)消息；向客户发送AS_REP；从客户接收票许可服务器请求(TGS_REQ)消息；产生带两份授权数据拷贝的票许可服务器应答(TGS_REP)消息；及向客户发送带两份授权数据拷贝的TGS_REP。

在另一种实施方案中，本发明提供了一种方法，包括以下步骤：产生包括授权数据第一拷贝的服务票；产生包括该服务票的票许可服务器应答；及向客户发送该票许可服务器应答与授权数据第二拷贝。在一种实施方案中，发送授权数据第二拷贝的步骤包括利用客户会话密钥加密至少授权数据的第二拷贝，使客户能够解密和利用该授权数据的第二拷贝，而产生服务票的步骤包括利用服务器密钥加密至少第一授权数据。

在另一种实施方案中，本发明其特征在于一种当从应用服务器请求内容时提供客户保密性的系统。该系统包括配置成产生包括至少两份授权数据拷贝的票许可服务器应答的密钥分配中心，其中该密钥分配中心与配置成接收票许可服务器应答并利用授权数据的一份拷贝验证授权的客户耦合在一起，而该客户与配置成向客户提供内容的应用服务器耦合在一起，其中客户进一步配置成利用授权数据的一份拷贝验证内容的授权使用。

在另一种实施方案中，本发明其特征在于一种向客户提供内容和/或服务访问的系统。该系统包括用于产生包括授权数据第一拷贝的服务票的装置；用于产生包括该服务票及授权数据第二拷贝的票许可服务器应答的装置；及用于向客户发送票许可服务器应答的装置。用于产生票许可服务器应答的装置可以包括利用客户会话密钥加密至少授权数据的第二拷贝的装置，而加密至少第二授权数据的装置可以包括加密至少授权数据的第二拷贝从而使客户能够解密并利用授权数据第二拷贝的装置。用于产生服务票的装置可以包括利用服务器密钥加密至少授权数据第一拷贝的装置。授权数据的第二拷贝可以配置成允许客户验证来自应用服务器的服务请求。授权数据的第二拷贝还可以配置成允许客户确定所接收内容的授权使用。

通过参考以下对本发明的详细描述及阐述一种说明性实施方案的附图，可以获得对本发明特点及优点的更好理解，其中的实施方案利用了本发明的原理。

附图说明

从以下对其更具体的描述并联系附图，本发明的上述及其它方面、特点及优点将变得很明显，其中：

图1描述了根据本发明一种实施方案制造的系统的简化方框图；

图2描述了根据本发明一种实施方案实现的系统的简化方框图；

图3描述了用于向客户提供由客户使用的授权数据第二拷贝的方法流程图；

图4描述了与图3所述过程类似的一种过程实现的简化流程图；及

图5描述了一种让客户从应用服务器请求并接收内容和/或服务的过程实现的简化流程图。

贯穿所有附图，对应的标号表示对应的元件。

具体实施方式

Kerberos的缺点在于如客户或服务器的网络实体不能够验证提交到应用服务器授权数据以便访问由该应用服务器所提供服务和/或内容。授权数据部分定义了提供给客户的服务和/或内容的限制。授权数据常常是专用于应用服务器106及由应用服务器106所提供内容和/或服务的。由于客户不能够验证授权，因此客户就不能够检查内容请求以确保没有选择未授权的选项。另外，由于客户不能够验证授权数据，因此客户需要另外的通信与信息来确定客户是否被授权可以拷贝交付给客户的内容。这导致错误、过大的网络业务量及网络资源和处理的不必要使用。还有，由于客户不能够验证授权数据，因此客户不能够确定客户是否被授权可以例如不止一次地回放内容而不需要接收另外的通信和信息。

通过向客户交付客户可以访问并使用以提高网络效率、减小网络业务量并将内容和/或服务的访问及使用连成整体的授权数据拷贝，本发明提供了克服这些及其它缺点的方法和系统。通过向客户提供授权数据的客户拷贝，客户能够通过避免在内容请求中包括非法选项来验证请求，并确定客户对所交付内容和/或服务的授权使用，例如确定所交付内容的拷贝是否可以保存及确定内容是否可以不止一次地回放。

本发明非常适合于利用票概念的密钥管理协议，其中票是利用允许客户对指定服务器进行鉴别的对称密钥进行加密的鉴别标记。根据本发明的一种实施方案，当密钥分配中心(KDC)将服务票转发到客户、服务器或其它网络实体时，KDC在服务票中包括两份授权数据的拷贝。其中一份授权拷贝，客户拷贝，配置成使客户(服务器或其它实体)能够访问由客户使用的授权数据，而另一份授权拷贝，服务器拷贝，提供给应用服务器，其中第二拷贝带有来自客户的内容选择和/或密钥请求。通过提供可以由客户或服务器访问并使用的授权数据拷贝，本发明克服了标准Kerberos及以前其它协议的缺点，其中的客户或服务器试图获得对由应用服务器所提供内容和/或服务的访问。

参考图1，说明了根据本发明一种实施方案制造的用于提供安全通信的系统100的简化方框图。包括本发明一种可能实现的例子的系统100使用在如互联网、内联网或可以增加到上百万用户的其它网络的网络上提供安全性与保密性的鉴别密钥管理协议。一般而言，系统100涉及至少一个利用公钥与对称密钥算法同一个或多个集中密钥分配中心(KDC)104交互及利用对称密钥算法同如应用服务器106(及第三方服务器140，见图2)的单独应用服务器交互的客户102。该协议是一般性的，可以很容易地适用于在分布式环境中需要鉴别的不同应用。此外，它还可以同集中管理的用户数据库接口。

客户102可以包括代表用户利用网络服务的过程、应用或设备。作为示例，客户102可以包括任何类型的计算机，或者客户102也可以包括如无线电话、寻呼机、个人数字助理(PDA)、具有低端微处理器的家用电器或基本上任何其它具有弱的或有限处理能力的设备的“瘦客户”。应当指出，在有些情况下，服务器本身也可以是某个其它服务器的客户(例如，打印服务器可以是文件服务器的客户)。

应用服务器106向网络客户提供资源。在所说明的实施方案中，KDC 104包括第一级108和第二级110。在一种实施方案中，第一级是鉴别服务器(AS服务器)108，而第二级是票许可服务器(TGS服务器)110。在验证其证书后，AS服务器108向客户102发票许可票(TGT票)。TGS服务器110向客户102提供应用服务器服务票(ST票)。当客户请求服务时，ST票是客户102提交给应用服务器106的结束服务票。当客户102利用ST票鉴别其自己后，应用服务器106向客户102提供各种服务。

系统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发送到应用服务器106、请求安全(密钥管理)参数的消息；

(F)密钥应答消息(KEY_REP)：从应用服务器106到客户102、带子密钥和应用专用数据的应答消息；

(H)内容和/或服务请求消息(CON_REQ)：从客户102发送到应用服务器106、请求期望内容和/或服务的消息；及

(I)内容和/或服务应答消息(CON_REP)：从应用服务器106发送到客户102、向客户提供期望内容和/或服务的消息。在发送到客户之前，内容一般是加密的。

通常每个消息都包括一个头，后面跟着消息体，对消息而言头是公用的。作为示例，头可以包括消息类型域、协议版本号域及校验和。消息类型域表示消息类型，如AS_REQ、AS_REP等。跟在消息头后面的是优选地具有类型长度值(TLV)格式的属性列表的消息体。

当客户希望获得用于TGS服务器110的TGT票时，客户102产生AS_REQ信息以初始化客户102与AS服务器108(KDC 104的一部分)之间的鉴别服务交换，其中TGS服务器110也是KDC 104的一部分。换句话说，AS_REQ消息是由客户102发送到AS服务器108的，以获得由客户用于请求指定应用服务器，如应用服务器106，的ST票的TGT票。作为示例，AS_REQ消息可以包括客户的身份(如名字)、TGS服务器110的身份及将其绑定到一种响应的特殊时间。它还可以包括客户102支持的对称加密算法列表。为了检查应答，这个消息还可以包括时间戳及用于消息完整性的签名。该签名可以是加密校验和或数字签名。

验证签名的公钥优选地保存在用户数据库中。数字认证可选地可以包括在AS_REQ消息中，而且可以代替所存储的公钥用于验证数字签名。客户102用于验证加密校验和的永久性对称密钥优选地保存在同一个用户数据库中。AS_REQ消息还可以包括密钥一致所必需的公钥信息(例如，椭圆曲线Diffie-Hellman参数)。作为示例，由于其处理速度，椭圆曲线可用于公钥加密。椭圆曲线一般比其它加密算法，如RSA，快一或两个数量级。Rijndael加密标准可用于128位密钥长度。

AS服务器108处理AS_REQ消息，以便验证它。如果AS_REQ处理不产生错误，则AS服务器108响应AS_REQ消息，产生AS_REP消息。一般地，为了随后关于KDC 104的鉴别，AS服务器108在数据库中查找TGS服务器110和客户102的密钥并产生一个随机的客户会话密钥。AS服务器108产生TGT票。TGT票一般既包括显文部分又包括加密部分。TGS服务器110的身份及票的有效期可以在所发出的TGT票中显文提供。票的加密部分可以包括如客户102的名字、客户会话密钥及任何其它要保密的数据等信息。TGT票还可以提供一个由KDC 104支持的加密类型与校验和的列表。票的加密部分可以利用KDC 104的私钥加密。

在一种实施方案中，AS_REP消息是由KDC 104利用与客户102用来为AS_REQ消息产生数字签名的算法完全相同的算法签名的。这个签名可以是数字签名或利用客户102私钥的加密校验和。公钥信息是KDC 104密钥一致参数的公共部分，应当表示与客户102所选算法相同的密钥一致算法。AS_REP消息优选地还包括在AS_REQ消息中由客户产生的特殊时间拷贝的特殊时间，以防止回放。

在一种实施方案中，AS_REP消息的加密部分向客户102提供对其自身授权数据的访问。因为如果客户102知道其自身的授权数据，则由于应用服务器只信任票中加密的客户信息拷贝，他以后就不会去尝试只会被应用服务器拒绝的动作，因此向客户102提供授权数据的客户拷贝为客户(及用户)提供了方便。而且，对于具有防止用户被窃用和改变其自身授权数据的硬件安全性的客户，这个特点可以是一种安全性优点，因为可读的授权数据也可以授权客户进行一些本地动作，如在本地磁盘上保存并回放内容(如电影)的权限。在AS_REP消息中接收的授权数据客户拷贝一般定义通用的客户授权，而不是专用于服务器。授权数据客户拷贝的使用在下面进一步描述。AS_REP消息的加密部分还可以包括客户102的身份，以验证这个应答最初是由KDC 104为这个特定客户102构造的。数据优选地是利用得自密钥一致算法的对称密钥加密的。

客户102处理AS_REP消息以验证其真实性并解密消息中的不公开票部分以获得TGT票。如果AS_REP消息的真实性得不到验证，则客户102优选地不向AS服务器108发回错误消息。在有些情况下，客户可以重发别的AS_REQ消息。

本发明可选地允许在AS_REQ和AS_REP消息中都通过数字认证，以允许客户102和KDC 104利用该数字认证彼此鉴别。没有认证的话，则期望已经为客户102提供了KDC的公钥，且KDC 104已经在其数据库中有了客户102的公钥。AS_REQ上的数字签名是由KDC104利用它在其数据库中查找到的客户公钥验证的。客户102利用预先提供的KDC公钥验证AS_REP上的数字签名。

在客户102通过AS服务器108交换获得TGT票以后，当客户102希望获得对给定或特定应用服务器，如应用服务器106，的鉴别认证时，客户102初始化客户102与KDC 104的TGS服务器110之间的TGS_REQ消息交换。TGS_REQ消息是由客户102产生并发送到TGS服务器110的，以获得用在KEY_REQ消息(在下面进一步描述)中的应用服务器服务票(ST票)。客户102提交从作为TGS_REQ消息一部分的AS_REP消息获得的TGT票。TGS_REQ消息指定一般包含在TGT票中的应用服务器106的身份及客户102的身份，该客户一般包括一个特殊时间。在一种实施方案中，由于客户102的身份处于TGT票的加密部分而不包括在消息的显文部分中，因此它是被保护的。来自TGT票的客户会话密钥可以用于TGS_REQ交换中的加密和解密。因此，探听者就检测不到客户(例如，用户)在请求哪种服务。

客户102优选地保存该特殊时间的值，以便随后确认来自KDC104的匹配TGS_REP消息。客户102优选地保存该特殊时间的值，直到一个可配置的超时值到期。在超时后，客户102就不再能处理对应的TGS_REP了，而必须重发。

TGS服务器110验证TGS_REQ消息并处理TGT票。然后TGS服务器110响应TGS_REQ消息，产生TGS_REP消息。TGS_REP消息包括由KDC 104发出的ST票(这是结束服务票)，其中ST票是当客户试图请求内容和/或服务时客户102提交给应用服务器106的。应用服务器106的身份和票的有效期可以在发出的ST票内部显文提供。ST票的加密部分包括客户102的名字和利用由应用服务器106与KDC 104共享的服务器密钥加密的服务器会话密钥。另外，ST票的加密部分还包括授权数据的第一拷贝(例如，服务器拷贝)，该拷贝部分定义提供给客户的服务和/或内容的限制。该授权数据专用于应用服务器106及由应用服务器106提供的内容和/或服务。在一种实施方案中，该授权数据包括服务和/或内容专用对象及对这些对象的权限。任何需要不公开的附加客户数据也可以作为ST票加密部分的一部分包括在其中。

在一种实施方案中，TGS_REP消息额外地还包括授权数据的第二拷贝(例如，客户拷贝)，该拷贝是利用AS_REP消息中由AS服务器108产生的TGS票的客户会话密钥加密的。如上所述，该会话密钥是TGS服务器110和客户102已知的。由于授权数据的第二拷贝(客户拷贝)是利用来自TGS票的会话密钥加密的，因此如下面所详细描述的，例如为了验证目的及其它目的，客户102可以解密该授权数据并利用该授权数据。在TGS_REP消息中接收的授权数据的第二拷贝可以提供比在AS_REP消息中接收的授权数据的第二拷贝更多的专用授权，包括更多的服务器专用授权。例如，在AS_REP消息中接收的授权数据更通用，定义了非服务器专用的客户授权，而不管客户是否被授权存储内容。

TGS_REP消息是由带加密校验和的KDC 104利用TGT票会话密钥签名的。为了防止回放，TGS_REP消息额外地还包括从TGS_REQ消息复制的特殊时间。

作为示例，TGS服务器110可以利用以下过程产生TGS_REP消息。首先，来自TGS_REQ消息的特殊时间被包括在TGS_REP消息中，以便将其绑定到请求。接下来，KDC 104指定随机ST票会话密钥的类型。如果有多于一种加密算法可用，则KDC 104优选地选择最强大的一种。然后，KDC 104产生包括授权数据第一拷贝，服务器拷贝，的ST票。应用服务器106的私钥用于加密ST票的加密部分，而且还对整个ST票产生加密校验和。ST票的结束时间优选地是由KDC104确定的。如果期望，客户102可以指定比较短的生命期。ST票的加密部分包括客户102的身份、授权数据的第一拷贝、会话密钥及其它的不公开数据。TGS_REP消息还包括加密的数据部分，在此TGT票会话密钥用于产生该加密的数据部分。该加密的数据部分包括授权数据的第二拷贝及利用TGT会话密钥产生的加密校验和，可以加到TGS_REP消息中。同样，这也仅仅是TGS服务器110可以用来产生包括授权数据两份拷贝的TGS_REP消息的过程的一个例子。

由于TGS_REP消息包括授权数据的两份拷贝，其中一份包含在ST票的加密部分中，而另一份利用来自TGT票的会话密钥加密，因此应用服务器106及客户102能够访问和利用这些授权数据。以这种方式，客户能够执行检查和验证，而不需要另外的通信和另外的数据。本发明与Kerberos不同，在Kerberos中来自特定应用服务器客户的票请求的KDC应答只包括授权数据的一份拷贝，该拷贝只能在解密ST票后由应用服务器访问。可选地，通过包括授权数据的两份拷贝，其中一份在ST票中加密，而另一份利用允许客户102解密授权数据的第二拷贝并使用该授权数据的客户TGT票会话密钥加密，本发明中的KDC产生对来自特定应用服务器客户的票请求的应答。

在一种实施方案中，客户102包括授权模块122。授权模块122接收授权数据的第二拷贝并配置成分析该授权数据以确定授权客户何时及如何使用由应用服务器106提供的内容和/或服务。授权模块122可以通过硬件、软件或硬件和软件的组合来实现。在一种实施方案中，授权模块122是硬件模块，用来解码从授权数据中提取出来的授权，验证客户102对内容和/或服务的授权，并且只有当客户没超出该授权时解密所请求的内容和/或服务。为了阻止该硬件模块外部的软件黑客攻击，用于验证授权数据的加密校验和的私钥没有暴露在硬件模块外部的客户中。在一种实施方案中，为了实现这种模块，整个密钥管理协议是在同一个硬件模块122中实现的，而私钥没有显文地暴露在该硬件模块外部的客户中。

作为示例，客户102可以使用以下过程处理TGS_REP消息。在这个例子中，“客户”指的是客户102本身或授权模块122(当其出现在客户内部时)。本领域技术人员应当认识到具有授权模块122的客户一般不允许加密处理发生在授权模块的外面。首先，客户102解析TGS_REP消息头。如果头解析失败，则客户102表现为就象从来没有接收到该TGS_REP消息一样。客户102优选地不向TGS服务器110发回错误消息。在有些情况下，客户102重发别的TGS_REQ消息。如果有未处理完的TGS_REQ消息，则客户102可以继续等待应答直到超时，然后重发。接下来，客户102验证头中的协议版本号。如果该协议版本不被支持，则客户102表现为就象从来没有接收到该TGS_REP消息一样。否则，客户102解析消息的剩余部分。如果发现消息格式非法，则客户102表现为就象从来没有接收到该TGS_REP消息一样。

然后，客户102查找具有相同特殊时间的未处理完的TGS_REQ消息。如果没有找到，则客户表就象从来没有接收到该消息一样继续处理。如果找到了，则客户102利用TGT票会话密钥验证校验和。如果校验和没有通过验证，则这个消息被丢弃，客户102就象从来没有接收到该消息一样继续处理。

然后，客户利用TGT票会话密钥解密TGS_REP消息中不公开的票部分。如果由于TGT票会话密钥类型与加密数据的类型不匹配而使得不公开的票部分不能够解密，则将有一个致命错误报告给用户，而客户102不会重发。如果结果显文文本包括格式化错误，包括这个客户102不支持其类型的会话密钥，或者包括与请求不匹配的客户身份，则也会有一个致命错误报告给用户，而客户102不会重发。如果会话密钥类型被支持且客户能够解密TGS_REP消息中不公开的票部分，则客户提取出授权数据的第二拷贝，验证它并保留，以备后用。

然后客户102处理ST票。如果ST票中有错误，则作为致命错误报告给用户，而客户102不重发别的TGS_REQ消息。如果TGS_REP中没有检测到错误，则客户102在其票缓冲的新记录中保存完整的ST票及显文文本不公开的票部分，包括授权数据的第二拷贝。在一种授权模块122出现在客户102内部的实施方案中，由于客户不拥有为票的修改版本产生校验和的服务器密钥，因此ST票可以存储在客户102内部授权模块122的外面。授权数据可以存储在授权模块122的内部，或者利用加密校验和或数字签名鉴别，然后再存储在客户102内部授权模块122的外面。如果授权数据存储在授权模块122的外面(以便最小化模块的存储需求)，则黑客修改授权数据的企图将会被授权模块122检测到。那是因为用于为授权数据产生加密校验和或数字签名的密钥在授权模块122的外部是不可读的。

KEY_REQ和KEY_REP消息用于客户102与应用服务器106之间的密钥管理和鉴别。KEY_REQ消息由客户102发送到应用服务器106，以便建立新的安全参数集。KEY_REQ消息还可以由客户102用于周期性地建立关于应用服务器106的新密钥。客户102以事先在TGS_REP消息中获得的有效ST票开始。应用服务器106以其可以使用以解密和确认票的服务密钥开始。客户产生包括鉴别客户102所需的ST票及加密校验和的KEY_REQ消息。KEY_REQ消息优选地还包括将其绑定到响应KEY_REP消息的特殊时间及防止回放攻击的客户时间戳。

当客户102产生KEY_REQ消息时，在一种实施方案中，授权数据的第一拷贝及客户102的身份都在ST票的加密部分中。在客户102发出KEY_REQ消息后，它保存客户的特殊时间值，以便以后确认来自应用服务器106的匹配KEY_REP消息。客户102保存该客户的特殊时间值，直到一个可配置的超时值到期。超时后，客户102就不再能处理对应的KEY_REP消息了。客户102可以在超时后重发。

KEY_REP消息是由应用服务器106响应KEY_REQ消息而发送的。作为示例，KEY_REP消息可以包括利用在客户102与应用服务器106之间共享的会话密钥加密的一个或多个随机产生的子密钥。KEY_REP消息还可以包括建立安全参数所需的附加信息。

客户102接收KEY_REP消息并处理KEY_REP消息。客户解析消息头、验证协议版本号、解析剩余的消息、匹配KEY_REP中的特殊时间与现有客户KEY_REQ的特殊时间并利用在客户102与应用服务器106之间共享的会话密钥验证校验和。客户利用共享的会话密钥进一步解密KEY_REP的子密钥，验证所选的密码组是可以接受的，解析加密的DOI对象(授权)，从子密钥产生内容解密及鉴别密钥并保存它们，以备后用。

在一种实施方案中，一旦客户接收并验证了KEY_REP，CON_REQ消息就由客户102发送到应用服务器106。在产生CON_REQ消息的过程中，客户访问解密的授权数据第二拷贝并确认该授权数据以确保CON_REQ消息不包含非法的或未授权的选项，其中这第二拷贝是客户从带ST票的AS_REP消息和/或TGS_REP消息接收并解密的。因此，客户的用户接口改进了，而且可以从一开始就防止用户选择未授权的选项，而不需要向服务器提交CON_REQ消息并等待响应。在一种实施方案中，如果由于某种原因客户102仍然产生了未授权的CON_REQ消息，则授权模块122保留一个为CON_REQ消息产生加密校验和所需的对称密钥，并拒绝为违反或超出如由授权数据第二拷贝定义的客户授权的CON_REQ消息产生这种加密校验和。因此，应用服务器106一般看不到未授权的CON_REQ消息，因为它们在客户端就被拒绝了，但是当这种未授权消息确实传出时，由于CON_REQ没有正确的加密校验和，所以被拒绝了，而不需要服务器106检查客户授权。

通过避免在应用服务器106对未授权消息的处理，授权数据的确认进一步优化了系统，还增强了客户与用户的交互，使得用户能够在本地评价授权，而不需要等待应用服务器106的响应。在一种实施方案中，CON_REQ消息是利用在客户102与应用服务器106之间共享的会话密钥加密的。

接收到CON_REQ消息后，应用服务器106立即处理该CON_REQ消息，并利用作为加密ST票一部分接收的授权数据第一拷贝确认请求。如果没有错误且内容请求不违反授权数据的授权，则应用服务器106产生CON_REP消息并初始化客户所请求内容和/或服务的交付。一般地，所交付的内容是由应用服务器106利用在客户102与服务器106之间共享的会话密钥加密的。

客户102接收内容、解密内容并开始处理和使用内容。在一种实施方案中，由于客户102有一份授权数据的拷贝，因此客户能够确定所接收内容和/或服务的授权使用。例如，通过检查授权数据，客户102可以确定客户是否被授权存储或保存内容的拷贝。授权模块122检查授权数据并确定客户的授权。如果客户被授权，则当内容被接收和解密后，客户能够保存它。此外，由于客户有一份授权数据的拷贝，因此在一种通过授权模块122的实施方案中，客户102可以通过检查授权进一步确定客户是否能够不止一次地回放或重用内容。授权模块122一般包括所存储内容的解密密钥并拒绝解密没有适当授权的内容。确定客户授权的能力是通过使用授权数据的第二拷贝实现的，其中这第二拷贝是客户102在TGS_REP消息中接收并存储以便本地使用的。这改进了客户操作并限制了通过网络的通信。

在一种实施方案中，系统100不需要为了让客户获得ST票及授权数据的客户拷贝而发生TGS_REQ和TGS_REP交换。客户102向指定服务器，如应用服务器106，提交服务票请求AS_REQ。KDC 104处理该AS_REQ并返回用于第一个应用服务器的ST票，该ST票包括授权数据的第一拷贝。KDC还向客户发送授权数据的第二拷贝，这第二拷贝格式化成被客户102访问与使用。一般地，KDC 104返回包括ST票的AS_REP，其中ST票具有授权数据的第一拷贝及授权数据的客户拷贝。因此，客户仍然能够与ST票一起获得授权数据的客户拷贝，而不需要提交TGS_REQ。

图2描述了根据本发明一种实施方案实现的系统101的简化方框图。在一种实施方案中，客户102访问第三方服务器140以选择期望的内容和/或服务，然后访问应用服务器106，以便真正接收所选的内容和/或服务。在选择内容和/或服务的过程中，客户102利用授权数据的客户拷贝。在向第三方服务器140提交对内容和/或服务的选择之前，客户确定期望的内容和/或服务，然后检查授权数据的客户拷贝以避免做出超出客户授权的选择。然后，客户102向第三方服务器140发送该内容和/或服务选择。然后第三方服务器140验证该内容和/或服务选择并向客户102发送内容和/或服务选择应答消息，该应答消息包括应用服务器106用来对客户授权并允许客户获得对选定内容和/或服务的访问的信息。因此，当应用服务器试图根据第三方服务器信息确定客户授权时，客户102参考该授权数据并避免从第三方服务器140请求随后将被应用服务器106拒绝的内容和/或服务授权。

在一种实施方案中，第三方应用服务器140额外地还包括第三方信息的鉴别。这种鉴别由客户102额外地转发到应用服务器106，一般是在KEY_REQ消息中。应用服务器106利用这种鉴别来鉴别由客户102提供给应用服务器的第三方服务器信息，以确保用于对用户授权的信息确实从第三方服务器140提供给了客户，而不是某个其它的网络实体，也不是由客户产生的某种假冒信息。

在向应用服务器106提交KEY_REQ消息的过程中，客户102包括第三方服务器信息及它是否提供给客户的鉴别。应用服务器106处理KEY_REQ消息，鉴别第三方服务器信息，并利用该信息验证客户授权。如上所述，一旦经过了鉴别和验证，应用服务器106就产生KEY_REP。

参考图3，说明了用于向客户提供由客户使用的授权数据第二拷贝及使用来自应用服务器的内容和/或服务的方法200的流程图。作为示例，方法200可以由上述系统100及适当的消息类型实现。在步骤202中，从客户，如客户102，接收TGT票请求。在步骤204中，产生TGT票。步骤204可以由例如AS服务器108执行。在步骤206中，该TGT票发送到客户。这一步也可以由AS服务器108执行。在一种实施方案中，如果授权数据的客户拷贝包括在AS_REP中，则客户提取出该授权数据的客户拷贝。在步骤208中，从客户接收对特定应用服务器的ST票请求。ST票请求包括TGT票，而且一般不会显文地提供客户的身份。在步骤210中，产生包括ST票的TGS_REP消息，具有在ST票中的授权数据第一拷贝及利用来自TGT票的会话密钥加密的授权数据第二拷贝。在一种实施方案中，TGS_REP的产生是由TGS服务器110执行的。在步骤212中，具有两份授权数据拷贝的TGS_REP消息发送到客户，这一步也可以由TGS服务器110执行。在步骤214中，客户接收TGS_REP。在步骤216中，客户从TGS_REP提取出至少授权数据的第二拷贝。在步骤220中，客户产生并发送包括ST票的KEY_REQ消息，其中ST票进一步包括授权数据的第一拷贝。在步骤222中，应用服务器接收并处理KEY_REQ。应用服务器提取出ST票，解密ST票并确认授权数据的第一拷贝。在步骤224中，应用服务器产生KEY_REP消息并向客户发送该KEY_REP消息。在步骤226中，客户验证该KEY_REP消息并将其与KEY_REQ消息匹配。

图4描述了与图3所述过程200类似的过程240一种实现的简化流程图。在步骤242中，客户发送TGT票请求。在步骤244中，KDC104产生TGT票。在步骤246中，KDC 104发送带客户授权数据的客户拷贝的TGT票。在步骤248中，客户接收该TGT票并提取出授权数据的通用客户拷贝。在步骤250中，客户102发送请求ST票的TGS_REQ。在步骤252中，KDC返回TGS_REP。在步骤254中，客户接收该TGS_REP并提取出ST票及服务器专用的授权数据第二拷贝。在步骤256中，客户确定内容和/或服务是期望的，然后访问授权数据的客户拷贝并验证期望的内容和/或服务，以避免请求超出授权的内容和/或服务。在步骤258中，客户102向第三方服务器140提交内容和/或服务选择。在步骤260中，第三方服务器发送内容和/或服务选择应答，该应答包括用于对客户授权的第三方信息及这种信息的鉴别(例如，加密校验和)。第三方信息包括可以用于验证客户授权的信息，例如：客户所选内容的标识符；与该内容关联的各种购买选项，如“转到信用卡”、“允许客户保存这个内容”及其它这类的信息。第三方信息还可以包括与内容关联的约束，如灯火管制区域的列表(例如，基于国家、州或邮政编码的灯火管制区域)及其它这类的约束。在步骤262中，客户102向应用服务器106发送不超出授权数据的KEY_REQ消息。KEY_REQ消息包括第三方信息及其鉴别与ST票，其中ST票进一步包括授权数据的第一拷贝。在步骤264中，应用服务器106利用第三方信息及授权数据的第一拷贝鉴别信息、验证对内容和/或服务的客户授权。在步骤266中，应用服务器106向客户102发送KEY_REP。

图5描述了让客户从应用服务器请求并接收内容和/或服务的过程310一种实现的简化流程图。在一种实施方案中，为了向客户提供授权数据的第二拷贝，过程310跟在图3所示过程200的步骤226后面。在步骤312中，客户，如客户102，确定期望什么内容和/或服务。例如，客户从用户或其它网络实体接收内容请求。在步骤314中，通过检查并比较该内容请求与前面获得并存储的授权数据第二拷贝，客户验证内容和/或服务请求以确保请求是授权的，而且没有超出授权使用。一旦客户验证了请求，则客户产生CON_REQ消息。在步骤316中，客户利用加密校验和进行加密、鉴别，并将CON_REQ消息发送给应用服务器，如应用服务器106(或第三方服务器140)。在步骤320中，根据加密校验和及在ST票中可以找到的授权数据第一拷贝所定义的客户授权访问，应用服务器解密CON_REQ消息并确认请求。在步骤322中，如果ST票和授权数据都通过验证了，则应用服务器加密并发送所请求的内容和/或服务。在一种实施方案中，应用服务器在多个不同的分组中发送所请求的内容，因此全部期望的内容不是包含在单个分组中，而是在几个分组中。在步骤324中，客户接收所请求的内容并处理数据。在步骤330中，客户访问他所存储的授权数据的第二拷贝并确定客户是否可以存储内容和/或服务的拷贝。在步骤332中，如果客户被授权可以存储，则客户存储内容和/或服务。如果不可以，则当其第一次接收时，允许客户访问内容，然后过程前进到步骤340，寻找另外的内容。否则进入步骤344，在此客户确定他是否可以不止一次地回放内容。如果可以，则进入步骤346，在此客户可以访问并回放内容一次或多次。在步骤340中，过程确定是否还有另外的内容和/或服务要接收。如果有，则过程310返回步骤324，接收另外的内容和/或服务。如果在步骤336中确定没有更多的数据和/或内容，则过程310终止。

本发明提供了允许客户存储并访问其自己授权数据拷贝的方法、系统、程序、计算机程序产品。这为内容和/或服务交付提供了改进的用户接口、减少的错误、提高的效率及优化。此外，允许客户访问其自己的授权数据拷贝使得客户能够做出关于所交付内容和/或服务处理与使用的决定。还有，它降低了所需的通信量并降低了整体的网络吞吐量。在一种实施方案中，本发明是在由Motorola公司开发的电子安全代理(ESBroker)协议中实现的，并且作为也是由Motorola公司开发的IP权限管理系统的一部分。

尽管在此已经通过其指定实施方案及应用的方式公开了本发明，但在不背离权利要求所阐明的本发明范围的前提下，本领域技术人员可以对其进行各种修改和变化。

Claims (24)

1、一种当从应用服务器请求内容和/或服务时验证客户授权的方法，包括步骤：

产生包括授权数据的第一拷贝的服务票；及

向客户发送该授权数据的第二拷贝；及

向客户发送所述服务票。

2、如权利要求1所述的方法，还包括步骤：

产生包括服务票和授权数据的第二拷贝的AS_REP；及

向客户发送所述AS_REP。

3、如权利要求1所述的方法，还包括步骤：

产生包括服务票的票许可服务器应答(TGS_REP)；及

向客户发送所述票许可服务器应答。

4、如权利要求3所述的方法，还包括步骤：

从客户接收鉴别服务器请求(AS_REQ)消息；

产生鉴别服务器应答(AS_REP)消息；

向客户发送所述AS_REP；

从客户接收票许可服务器请求(TGS_REQ)消息；及

产生TGS_REP的步骤包括产生具有两份或多份授权数据拷贝的TGS_REP，其中包括授权数据的第二拷贝。

5、如权利要求3所述的方法，还包括步骤：

产生包括授权数据第二拷贝的鉴别服务器应答(AS_REP)消息；及

向客户发送AS_REP包括向客户发送授权数据第二拷贝的步骤。

6、如权利要求3所述的方法，还包括步骤：

配置授权数据的第二拷贝，使得该授权数据的第二拷贝被客户使用。

7、如权利要求6所述的方法，还包括步骤：

利用客户会话密钥加密授权数据的第二拷贝。

8、如权利要求7所述的方法，还包括步骤：

利用服务器服务密钥加密服务票。

9、如权利要求7所述的方法，其中利用客户会话密钥加密的步骤包括利用来自AS_REP中票许可票的会话密钥。

10、如权利要求6所述的方法，还包括步骤：

客户确定期望的内容；

客户利用授权数据的第二拷贝验证期望的内容；

客户产生内容请求；

客户向第三方服务器发送内容请求；及

第三方服务器向客户发送随后应用服务器用于确定所请求内容的客户授权的第三方信息。

11、如权利要求6所述的方法，还包括步骤：

从客户接收密钥请求(KEY_REQ)；

产生密钥应答(KEY_REP)；

向客户转发KEY_REP；

客户产生内容请求；

客户利用授权数据的第二拷贝验证内容请求；及

如果客户验证在内容请求中没有错误，则客户向应用服务器发送该内容请求。

12、如权利要求6所述的方法，还包括步骤：

接收内容请求；

向客户发送至少一部分所请求的内容；及

配置授权数据第二拷贝的步骤包括配置授权数据的第二拷贝，使得客户能够利用该授权数据的第二拷贝确定至少所请求内容的授权使用。

13、如权利要求12所述的方法，还包括步骤：

配置授权数据的第二拷贝，使得客户能够利用该授权数据的第二拷贝确定客户是否被授权存储所请求内容的步骤。

14、如权利要求13所述的方法，还包括步骤：

配置授权数据的第二拷贝，使得客户能够利用该授权数据的第二拷贝确定客户是否被授权回放所请求内容的步骤。

15、一种系统，用于在系统上提供安全通信，包括：

配置成向客户发票许可票(TGT)的密钥分配中心(KDC)第一级；及

配置成响应从客户接收到的TGT产生票许可服务器应答的KDC第二级，该应答包括授权数据的至少两份拷贝。

16、如权利要求15所述的系统，还包括：

配置成接收该票许可服务器应答并利用授权数据的一份拷贝验证授权的客户。

17、如权利要求15所述的系统，还包括：

与应用服务器耦合的客户，其中应用服务器配置成向客户提供内容；及

客户进一步配置成利用授权数据的一份拷贝验证内容的授权使用。

18、一种用于向客户提供对内容和/或服务的访问的系统，包括步骤：

产生包括授权数据第一拷贝的服务票的装置；

产生包括该服务票及授权数据第二拷贝的票许可服务器应答的装置；及

向客户发送该票许可服务器应答的装置。

19、如权利要求18所述的系统，其中产生票许可服务器应答的装置包括利用客户会话密钥加密至少授权数据第二拷贝的装置。

20、如权利要求19所述的系统，其中加密至少授权数据第二拷贝的装置包括加密至少授权数据的第二拷贝，使得客户能够解密并利用该授权数据第二拷贝的装置。

21、如权利要求20所述的系统，其中产生服务票的装置包括利用服务器密钥加密至少授权数据第一拷贝的装置。

22、如权利要求18所述的系统，其中授权数据的第二拷贝配置成允许客户验证来自应用服务器的服务请求。

23、如权利要求18所述的系统，其中授权数据的第二拷贝配置成允许客户确定所接收到内容的授权使用。

24、一种系统，用于在系统上提供安全通信，包括：

配置成向客户发票许可票(TGT)及至少授权数据的客户拷贝的密钥分配中心(KDC)第一级，其中授权数据的客户拷贝配置成使客户能够确定客户授权；及

配置成产生票许可服务器应答的KDC第二级。

Images