专利名称：从公共服务器请求内容时提供客户端保密性的方法和系统的制作方法
技术领域：
本发明一般涉及网络安全，特别涉及用于在从应用服务器请求内容时提供客户端保密性的方法和系统。
背景技术：
因特网是一个不安全的网络。因特网上使用的许多协议都不提供任何安全性。不使用加密或任何其他类型的安全机制就在因特网上传输的数据被认为是在“透明(in the clear)”传输。很容易获得一些工具，使黑客们“嗅出(sniff)”诸如密码、信用卡号、客户端身份和名称等在因特网上透明传输的数据。因此，在因特网上发送未加密数据的应用极易受到攻击。
Kerberos是已知网络认证协议的一个实例，其通过使用机密密钥(secret-key)密码技术为客户端/服务器应用提供认证。Kerberos协议可从麻省理工学院获得，该协议使用密码技术从而据称使得客户端能够通过不安全的网络连接向服务器证明自己的身份(反之亦然)。在客户端和服务器使用Kerberos来证明其身份之后，它们还可以对它们所有的通信进行加密，从而据称在它们进行其商业活动时确保保密性(privacy)和数据完整性(integrity)。
本发明还延展到有关网络安全领域的这些和其他背景信息因素。
发明内容
本发明提供了一种在从应用服务器请求内容时提供客户端保密性的方法。本方法包括步骤从客户端接收对票据授予票据(ticket grantingticket，TGT票据)的请求；产生TGT票据，在其中加密客户端身份；将TGT票据发送到客户端；从客户端接收对用于应用服务器的服务票据(ST票据)的请求，该请求包括TGT票据且不透明提供客户端身份；产生ST票据，在其中加密客户端身份；和将ST票据发送到客户端，而并不透明地提供客户端的身份。
在另一实施例中，本发明的特征在于一种用于在从应用服务器请求内容时提供客户端保密性的系统。该系统包括认证服务器，用于从客户端接收TGT票据请求，产生TGT票据以及在其中加密客户端身份，并将TGT票据发送到客户端。票据授予服务器用于从客户端接收用于应用服务器的ST票据请求，该请求包括TGT票据并且不透明地提供客户端身份，票据授予服务器还用于产生ST票据以及在其中加密客户端身份，并将ST票据发送到客户端，而并不透明地提供客户端的身份。
通过参考下面阐释运用本发明原理的说明性实施例的本发明的详细描述以及附图，可以更好地理解本发明的特点和优点。
图1是说明根据本发明实施例的系统的方框图；和图2是说明根据本发明实施例、在从应用服务器请求内容时提供客户端保密性的方法的流程图。
具体实施例方式
Kerberos的缺点在于密钥分发中心(KDC)回复来自客户端、用于特殊应用服务器的票据请求的内容透明地包括客户端名称。因为Kerberos规定在这样的回复中也要透明地提供特殊应用服务器的身份，所以客户端的身份会被轻易地链接到内容。这意味着严重地危及到了客户端的(即用户的)保密性，因为可能会有人轻易地识别特殊的服务器，而客户端正从这些特殊的服务器中请求内容。从公共服务器请求内容的网络用户可能不希望被关联到其请求的内容。本发明提供了一种方法和系统，能够克服这些和其他缺点，并在从服务器(诸如公共服务器)请求内容时提供改善的用户保密性。
本发明适用于使用票据概念的密钥管理协议，该协议是通过对称密钥加密的认证令牌，允许客户端向特定的服务器认证。根据本发明的实施例，客户端名称或身份在所有密钥管理消息中被加密，其中客户端或者请求用于特定应用服务器(例如内容提供商)的票据或者直接跟内容提供商对话。用户(客户端)名称在所有密钥管理消息中被加密，这些消息或者直接寻址到应用服务器或者透明地包含服务器名称。这些密钥管理消息是在客户端和KDC之间以及客户端和应用服务器之间。标准Kerberos票据以加密的形式携带客户端名称，而KDC对特殊服务器的票据请求的回复透明地包括了客户端名称，本发明克服了标准Kerberos的缺点。
参看图1，图示说明了根据本发明实施例的系统100的模型。系统100包括本发明一个可能实现的例子，使用认证密钥管理协议，该协议在网络(诸如因特网)上提供安全性和保密性并且可以对应于成百万的用户。一般地，系统100包括客户端102，其使用公共密钥和对称密钥算法与中心化的密钥分发中心(KDC)104交互以及仅通过使用对称密钥算法与个人应用服务器(诸如应用服务器106)交互。协议是普适的并且能够轻易地适应于在分布式环境中需要认证的不同应用。而且，其可以与中央管理的用户数据库对接。
客户端102可以包括使用代表用户的网络服务的过程或设备。举例来说，客户端102可包括任意类型的计算机，或者客户端102可包括“薄客户端(thin client)”，诸如无线电话或者具有低端微处理器的家庭用具。注意到在某些情况中，服务器本身可以是某些其他服务器的客户端(例如，打印服务器可以是文件服务器的客户端)。应用服务器106向网络客户端提供资源。在所示实施例中，KDC 104包括认证服务器(AS服务器)108和票据授予服务器(TGS服务器)110。AS服务器108在验证了证书之后，发布票据授予票据(TGT票据)到客户端102。TGS服务器110提供应用服务器服务票据(ST票据)到客户端102。当客户端102请求服务时，ST票据是客户端102提交给应用服务器106的端服务票据。当客户端102使用ST票据认证其自身时，应用服务器106向客户端102提供多种服务。
系统100使用的基本消息类型如下(A)认证服务器请求消息(AS_REQ)来自客户端102的消息，用以从AS服务器108请求TGT票据；(B)认证服务器回复消息(AS_REP)从AS服务器到客户端102的回复消息，带有TGT票据；(C)票据授予服务器请求消息(TGS_REQ)来自客户端102的消息，用以从TGS服务器110请求ST票据；(D)票据授予服务器回复消息(TGS_REP)从TGS服务器110到客户端102的消息，带有ST票据；(E)票据询问消息(TKT_CHALLENGE)从应用服务器106发送到客户端102的消息，用以启动密钥管理；(F)密钥请求消息(KEY_REQ)从客户端102发往应用服务器106的消息，用以请求安全(密钥管理)参数；(G)密钥回复消息(KEY_REP)从应用服务器106到客户端102的回复消息，带有子密钥和应用特定数据；和(H)安全建立消息(SEC_ESTABLISHED)从客户端102到应用服务器106的消息，用以说明建立了安全性。
每种消息通常将包括报头，然后是消息正文，报头对于所有消息来说是公共的。举例来说，报头可包括消息类型字段、协议版本号字段和校验和。消息类型字段指示消息类型，诸如AS_REQ、AS_REP等。紧跟消息报头的是消息的正文，优选地具有“类型-长度-值”格式的特征列表。
当客户端102希望得到TGT票据时，客户端102产生AS_REQ消息以启动客户端102和AS服务器108(部分KDC 104)之间的认证服务交换，TGT票据是用于TGS服务器110、也是部分KDC 104的票据。换句话说，客户端102发送AS_REQ消息到AS服务器108以获得TGT票据，客户端使用该票据来请求用于特定应用服务器(诸如应用服务器106)的ST票据。举例来说，AS_REQ消息可包括客户端的身份(例如名称)、TGS服务器110的身份以及不重性标志(nonce)以将其绑定到回复。它还可包括客户端102所支持的一系列对称加密算法。为了检查重放，该消息还可包括时间戳以及用于消息完整性的签名。签名可以说加密的检验和或数字签名。
优选地，在用户数据库中保留有用于验证签名的公共密钥。可选地，可将数字证书包括在AS_REQ消息中并且可以代替储存的公共密钥来验证数字签名。客户端102用于验证加密校验和的永久对称密钥优选地保留在相同的用户数据库中。AS_REQ消息还可包括密钥协定所必需的公共密钥信息(例如椭圆曲线Diffie-Hellman参数)。举例来说，椭圆曲线因为其处理速度而可用于公共密钥加密。其量级比RSA快一阶或二阶。Rijndael加密标准可使用128比特密钥长度。
AS服务器108处理AS_REQ消息来验证它。如果AS_REQ处理不产生任何差错，AS服务器108产生AS_REP消息来响应AS_REQ消息。具体地说，AS服务器108在数据库中寻找TGS服务器110和客户端102的密钥，并产生随机的会话密钥，用于随后对KDC 104的认证。AS服务器108产生TGT票据，该票据具有透明的和加密的部分。可在发布的TGT票据内透明地提供TGT服务器110的身份和票据有效周期。票据的加密部分包含客户端102的名称、会话密钥和任何用于保护隐私的其他数据。票据优选地还提供一系列KDC 104支持的加密类型和校验和类型。可使用KDC 104的机密密钥(secret key)来对票据的加密部分进行加密。
AS_REP消息优选地应该由KDC 104使用与客户端102产生用于AS_REQ消息的签名所使用的算法相同的算法来签发。该签名可以是数字签名或者是使用客户端102的机密密钥加密的校验和。公共密钥信息是KDC 104的密钥协定参数的公共部分，应该指示与客户端102所选的算法相同的密钥协定算法。最后，AS_REP消息优选地包含从AS_REQ复制来的不重性标志，以防止回复。
AS_REP消息的加密部分优选地包含与TGT票据中相同的信息，从而使得客户端102具有只读访问其自身授权数据的能力，但是这并不是本发明的要求。这个可选的特征向用户提供了便利，因为如果客户端102知道它自身的授权数据，它就不会想要做哪些无论如何会被应用服务器拒绝的操作，因为应用服务器将只信任在票据中加密的客户端信息的副本。同时，对于具有硬件安全性的客户端来说，硬件安全性防止用户被黑和改变其自身授权数据，上述可选特征也可以是一个安全性的优势，因为可读的授权数据可能也授权客户端进行某些本地操作，诸如在本地磁盘上保存和重放电影的权力。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的公共密钥。KDC 104通过在其数据库中寻找到的客户端公共密钥来验证AS_REQ上的数字签名。客户端102通过预备好的KDC公共密钥来验证AS_REP上的数字签名。
在客户端102通过AS服务器108交换而获得TGT票据之后，当客户端102希望获得用于给定或特殊应用服务器(诸如应用服务器106)的认证信任时，客户端102在客户端102和TGS服务器110之间启动TGS_REQ消息交换。客户端102产生并发送TGS_REQ消息到TGS服务器110以获得应用服务器服务票据(ST票据)(其可用于KEY_REQ消息中)。客户端102提供从AS_REP消息获得的TGT票据，作为部分TGS_REQ消息。TGS_REQ消息指定了应用服务器106的身份以及客户端102的身份(在TGT票据内)。客户端102的身份被保护起来，这是因为它是在TGT票据中的加密部分内，不包括在该消息的透明部分中。来自TGT票据的会话密钥可能用于TGS_REQ交换中的加密和解密。因此，窃听者无法检测客户端(即用户)正在请求哪项服务。
客户端102发出TGS_REQ消息之后，优选地，它保存不重性标志值以在稍后证实来自KDC 104的匹配TGS_REP消息。客户端102优选地保留该不重性标志值，直到可配置的定时值到时。到时之后，客户端102将不再能够处理相应的TGS_REP而必须再次尝试。
TGS服务器110验证TGS_REQ消息并处理TGT票据。TGS服务器110然后产生TGS_REP消息以响应TGS_REQ消息。TGS_REP消息包括由KDC 104发布的ST票据(端服务票据)，它是客户端102在需要请求服务时提供给应用服务器106的。应用服务器106的身份和票据有效周期可以在发布的ST票据中透明地提供。ST票据的加密部分包含客户端102的名称和通过由应用服务器106和KDC 104共享的密钥来加密的会话密钥。任何需要被保密的附加的客户端数据都可以被包括作为部分ST票据的加密部分。TGS_REP消息是由KDC 104通过使用TGT票据会话密钥加密的校验和签发的。最后，TGS_REP消息包含从TGS_REQ消息复制来的不重性标志，用以防止回复。
举例来说，TGS服务器110可使用下面的步骤产生TGS_REP消息。首先，将来自TGS_REQ消息的不重性标志包括在TGS_REP消息中，以将其绑定到请求。接下来KDC 104分配随机(服务票据)类型的会话密钥。如果可以用多个加密算法，KDC 104优选地选择最强大的一个。KDC 104然后产生ST票据。应用服务器106的机密密钥用于加密加密票据部分，还在整个ST票据上产生加密的校验和。优选地，由KDC 104确定ST票据的结束时间。如果客户端102希望，客户端102就可指定更短的作用时间(lifetime)。ST票据的加密部分包含客户端102的身份、会话密钥和其他私密数据。TGT票据会话密钥用于产生TGS_REP消息的加密数据部分，并将(使用TGT会话密钥)加密的校验和添加到TGS_REP消息中。此外，只是作为步骤的一个例子，可以使用TGS服务器110来产生TGS_REP消息。
因为客户端102的名称包含在TGS_REP消息的ST票据的加密部分中，并且不透明地发送，因此客户端的身份是隐藏的，不能够通过客户端102将向应用服务器106请求的内容而链接到。这样，窃听者就不能够确定客户端102希望同哪个应用服务器通信。本发明不同于Kerberos，在Kerberos中，除了在票据中加密客户端名称以外，KDC对来自客户端、用于特殊应用服务器的票据请求的回复透明地包括客户端的名称。事实上，本发明中，只有AS_REQ消息中透明地提供了客户端102的名称，但这并不是问题，因为还没有建立任何安全性，客户端102还没有请求或识别特定的应用服务器。
举例来说，客户端102可使用下面的步骤来处理TGS_REP消息。首先，客户端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不会再次尝试。
客户端102随后处理ST票据。如果在ST票据中有错误，就作为致命错误向用户报告，客户端102不会通过另一TGS_REQ消息再次尝试。如果在TGS_REP消息中没有检测到错误，客户端102就将整个ST票据和透明的文本私密票据部分保存在其票据高速缓存中的新条目中。
应用服务器106在它想启动密钥管理的任何时候使用TKT_CHALLENGE消息。为了防止拒绝服务(denial of service)的攻击，该消息包括服务器不重性标志字段，是由应用服务器106产生的随机值。客户端102优选地应该包括随后的KEY_REQ消息中的该服务器不重性标志的确切值。这个TKT_CHALLENGE消息还优选地包括应用服务器106的域名和重要名称，由客户端102使用其来发现或获得用于该应用服务器的正确票据。
KEY_REQ和KEY_REP消息用于客户端102和应用服务器106之间的密钥管理和认证。客户端102发送KEY_REQ消息到应用服务器106，以建立新的一组安全参数。优选地，任意时间客户端102接收到TKT_CHALLENGE消息，它都会用KEY_REQ来响应。KEY_REQ消息还可被客户端102用于周期性地与应用服务器106建立新密钥。客户端102以之前在TGS_REP消息中获得的有效ST票据开始。应用服务器106以其可用于解密和证实票据的服务密钥开始。KEY_REQ消息包括ST票据以及认证客户端102所需的加密的校验和。KEY_REQ消息优选地还包含不重性标志(用以绑定响应KEY_REP消息)和客户端时间戳(用以防止回复攻击)。
当客户端102产生KEY_REQ消息时，客户端102的身份是在ST票据的加密部分中，所以它没有包括在消息的透明部分中。在客户端102发出KEY_REQ消息之后，它保存客户端不重性标志值，以在稍后证实来自应用服务器106的匹配KEY_REP消息。客户端102保留客户端不重性标志值，直到可配置的定时值到时。在到时之后，客户端102将不再能够处理相应的KEY_REP消息。如果KEY_REQ消息由客户端102未经请求地发送，客户端102可以在这次到时之后再次尝试。
应用服务器106发送KEY_REP消息响应KEY_REQ消息。举例来说，KEY_REP消息可包括随机产生的子密钥，其是通过在客户端102和应用服务器106之间共享的会话密钥加密的。KEY_REP消息还可包括建立安全参数所需的附加信息。
最后，客户端102发送SEC_ESTABLISHED消息到应用服务器106，以确认它接收到了KEY_REP消息并成功地建立了新的安全参数。
参看图2，图示说明了方法200，在从应用服务器请求内容时提供客户端保密性。举例来说，方法200可以由KDC 104和上述的适当消息类型来实现。在步骤202，从客户端(诸如客户端102)接收到TGT票据请求。在步骤204，产生TGT票据，其中加密了客户端的身份。例如，可由AS服务器108执行步骤204。在步骤206，TGT票据被发送到客户端。该步骤可由AS服务器108来执行。在步骤208，从客户端接收到用于特殊应用服务器的ST票据请求。ST票据请求包括TGT票据并且不透明地提供客户端的身份。在步骤210，产生ST票据，其中加密有客户端的身份，例如可由TGS服务器110执行该步骤。在步骤212，ST票据被发送到客户端，而不透明地提供客户端的身份，该步骤也可由TGS服务器110来执行。
因此，本发明提供了一种方法和系统，在从诸如公共服务器的服务器请求内容时提供改进的用户保密性。保密性被改进了是因为客户端名称或身份在所有的密钥管理消息中都被加密，在这些消息中客户端正请求用于特定应用服务器(例如内容提供商)的票据，这就克服了标准Kerberos的不足。
虽然这里公开的发明是通过特定实施例和应用而说明的，本领域技术人员应该可以在不背离权利要求所阐述的本发明的范围的情况下做出多种修改与变化。
权利要求
1.一种在从应用服务器请求内容时提供客户端保密性的方法，包括步骤从客户端接收票据授予票据(TGT票据)请求；产生TGT票据，其中加密有客户端的身份；发送TGT票据到客户端；从客户端接收用于应用服务器的服务票据(ST票据)请求，其包括TGT票据并且不透明地提供客户端的身份；产生ST票据，其中加密有客户端的身份；和发送ST票据到客户端，不透明地提供客户端的身份。
2.根据权利要求1所述的方法，其中，所述接收TGT票据请求的步骤包括通过认证服务器接收TGT票据请求的步骤。
3.根据权利要求1所述的方法，其中，所述产生TGT票据的步骤包括通过认证服务器产生TGT票据的步骤。
4.根据权利要求1所述的方法，其中，所述发送TGT票据到客户端的步骤包括发送TGT票据到客户端作为部分认证服务器回复消息的步骤。
5.根据权利要求1所述的方法，其中，所述接收用于应用服务器的ST票据请求的步骤包括通过票据授予服务器接收用于应用服务器的ST票据请求的步骤。
6.根据权利要求1所述的方法，其中，所述用于应用服务器的ST票据请求指定了应用服务器的身份。
7.根据权利要求1所述的方法，其中，所述产生ST票据的步骤包括通过票据授予服务器产生ST票据的步骤。
8.根据权利要求1所述的方法，其中，所述发送ST票据到客户端的步骤包括发送ST票据到客户端作为部分票据授予服务器回复消息的步骤。
9.根据权利要求1所述的方法，其中，所述发送TGT票据到客户端的步骤包括发送TGT票据到客户端而不透明提供客户端的身份的步骤。
10.根据权利要求1所述的方法，其中，所述发送TGT票据到客户端的步骤包括发送TGT票据以及以只读形式发送客户端自身授权数据的副本到客户端的步骤。
11.一种用于当从应用服务器请求内容时提供客户端保密性的系统，包括认证服务器，用于从客户端接收票据授予票据(TGT票据)请求，产生TGT票据，在其中加密有客户端的身份，并且发送TGT票据到客户端；和票据授予服务器，用于从客户端接收用于应用服务器的服务票据(ST票据)请求，所述请求包括TGT票据并且不透明地提供客户端的身份，所述票据授予服务器还用于产生ST票据，其中加密有客户端的身份，并发送ST票据到客户端，而不透明提供客户端的身份。
12.根据权利要求11所述的系统，其中，所述认证服务器和所述票据授予服务器组成至少部分密钥分发中心(KDC)。
13.根据权利要求11所述的系统，其中，所述认证服务器还用于发送TGT票据到客户端作为部分认证服务器回复消息。
14.根据权利要求11所述的系统，其中，所述认证服务器还用于发送TGT票据到客户端而不透明提供客户端的身份。
15.根据权利要求11所述的系统，其中，所述票据授予服务器还用于发送ST票据到客户端作为部分票据授予服务器回复消息。
全文摘要
本发明公开一种方法和系统(100)，用于在客户端(102)从公共服务器(106)请求内容时在因特网上提供客户端保密性。本方法适于使用票据概念的密钥管理协议。客户端(102)名称或身份在所有密钥管理消息中被加密，在这些消息中客户端请求用于特定应用服务器(106)的票据(TGS_REQ)。密钥管理消息在客户端和密钥分发中心(KDC)(104)之间以及客户端(102)和特定应用服务器(106)之间。KDC(104)不在这样的消息中透明地提供客户端(102)的名称或身份。这防止了客户端的身份被通过特定应用服务器(106)提供的内容而链接，从而得到了改进的用户保密性。
文档编号G06F21/24GK1611031SQ02819718
公开日2005年4月27日 申请日期2002年9月24日 优先权日2001年10月5日
发明者亚历山大·梅德温斯基 申请人:通用仪表公司