专利名称：用于建立安全通信会话的方法与装置的制作方法
技术领域：
本发明涉及改进的数据处理系统，尤其涉及用于多计算机数据传输的方法与装置。更具体而言，本发明提供用于利用密码进行多计算机通信的方法与装置。
背景技术：
电子商务网站及web应用程序代表用户在计算机网络上执行交易。在基于web的电子商务环境中，在允许访问网站内的受保护资源之前，计算机系统常常实现作为守卫门(sentry gate)形式的认证和/或授权服务。由这些认证和授权服务执行的安全处理可以分成两个阶段。
在第一阶段，客户端和服务器建立安全通信会话，如SSL(安全套接字层)会话，这可以包括客户端和远端服务器之间的证书和密钥交换，以便建立信任关系并协商SSL会话中将用于加密消息的密钥和密码。许多网站都在它们的认证服务中采用SSL协议。SSL或其后续协议，传输层安全(TLS)，是用于建立从客户端到服务器的安全连接以便防止消息伪造、数据篡改及窃听的广泛使用的协议。SSL握手协议允许客户端与服务器在应用协议发送或接收其第一个数据字节之前协商加密算法和密钥。以这种方式，SSL握手提供可以由更高网络层用于安全通信的安全通信会话或连接，包括用于后续认证操作或后续授权操作的凭证信息的后续传输。
在第二阶段，在安全通信会话完成以后，凭证信息从客户端传输到服务器，用于后续的认证操作或后续的授权操作。例如，在SSL会话建立后，服务器请求客户端提供用户凭证，而客户端向服务器提供用户凭证，然后服务器在后续的认证或授权操作中验证该用户凭证。基于用户凭证的验证，服务器或者允许或者阻止客户端对受保护资源的访问。在第一或第二阶段过程中，可以有也可以没有与客户端用户的任何直接交互。
用于建立安全通信会话然后采用该安全通信会话传输凭证信息的两阶段过程允许用户或客户端为安全目的以适当的可靠性等级证明其身份和/或其访问权限。但是，有一种支持单阶段中安全通信会话的建立及用于后续认证或授权操作的凭证信息的后续传输的方法和系统将是有利的，这将比两阶段过程更有效。
发明内容
提出了用于在数据处理系统中支持安全通信会话建立的方法、系统、装置和计算机程序产品。证书请求命令从服务器发送到客户端。在服务器从客户端接收响应该证书请求命令的证书命令，而且该证书命令伴随着公钥证书和由绑定到该公钥证书的私钥数字签名的属性证书。响应成功地验证了公钥证书，建立安全通信会话。属性证书包含用于在安全通信会话建立后执行的认证操作或授权操作的凭证信息。
被认为是本发明特征的新特征在所附权利要求中阐述。通过参考以下具体描述并结合附图一起阅读，本发明本身、更多目的及其优点将得到最好的理解，其中图1A描述了其每一个都可以实现本发明的典型数据处理系统网络；图1B描述了可以在其中本发明可以实现的数据处理系统中使用的典型计算机体系结构；图2描述了显示典型企业数据处理系统的方框图；图3描述了显示当客户端试图访问服务器上受保护资源时可以使用的典型认证处理的数据流程图；图4A描述了显示客户端与服务器之间多阶段典型信息交换的数据流程图，这包括用于创建SSL(安全套接字层)会话的初始化阶段；图4B描述了显示SSL协议中典型客户端-服务器握手的数据流程图；图4C描述了显示客户端和服务器之间多阶段信息交换的数据流程图，其中根据本发明认证/授权处理在单个阶段中发生；图4D描述了显示SSL(安全套接字层)协议中增强客户端-服务器握手的数据流程图，其中根据本发明的实施方式SSL握手包含属性证书从客户端到服务器的传输；图5描述了显示根据本发明实施方式在增强SSL握手过程中CLIENT HELLO命令传输的方框图；图6描述了显示根据本发明的实现可以用于支持增强SSL协议的数据存储器和功能单元的示例集合的方框图；图7描述了显示根据本发明用于生成包含将在增强SSL握手过程中从客户端传输到服务器的用户/客户端凭证的属性证书的处理流程图；图8描述了显示根据本发明用于在增强SSL握手过程中将包含用户/客户端凭证的属性证书从客户端传输到服务器的处理流程图；及图9描述了显示根据本发明用于在增强SSL握手过程中在服务器验证来自客户端的公钥证书及包含用户/客户端凭证的相关属性证书的处理的流程图。
具体实施例方式
总地来说，可以包括或涉及本发明的设备包括很多种数据处理技术。因此，作为背景，在更具体地描述本发明之前，先描述分布式数据处理系统中硬件和软件组件的典型组织。
现在参考附图，图1A描述了其每一个都可以实现本发明一部分的典型数据处理系统网络。分布式数据处理系统100包含网络101，网络101是可用于在分布式数据处理系统100中连接在一起的各种设备和计算机之间提供通信链路的介质。网络101可以包括永久连接，如有线或光纤电缆，或通过电话或无线通信建立的临时连接。在所述例子中，服务器102和服务器103与存储单元104一起连接到网络101。此外，客户端105-107也连接到网络101。客户端105-107与服务器102-103可以由多种计算设备表示，如大型机、个人计算机、个人数字助理(PDA)等。分布式数据处理系统100可以包括未示出的附加服务器、客户端、路由器、其它设备及对等体系结构。
在所述例子中，分布式数据处理系统100可以用网络101包括因特网，表示使用各种协议，如轻量级目录访问协议(LDAP)、传输控制协议/因特网协议(TCP/IP)、文件传输协议(FTP)、超文本传输协议(HTTP)、无线应用协议(WAP)等，彼此通信的网络和网关的全球集合。当然，分布式数据处理系统100也可以包括大量不同类型的网络，例如内联网、局域网(LAN)或广域网(WAN)。例如，服务器102直接支持客户端109和结合了无线通信链路的网络110。网络使能电话111通过无线链路112连接到网络110，而PDA 113通过无线链路114连接到网络110。电话111和PDA 113还可以利用合适的技术，如蓝牙TM无线技术，在无线链路115上在它们之间传输数据，以便创建所谓的私域网(PAN)或个人ad-hoc网。以类似的方式，PDA 113可以通过无线通信链路116向PDA 107传输数据。
本发明可以在多种硬件平台上实现；图1A只是作为异类计算环境的一个例子，而不是作为本发明的体系结构限制。
现在参考图1B，图描述了其中本发明可以实现的如图1A所示数据处理系统的典型计算机体系结构。数据处理系统120包含连接到内部系统总线123的一个或多个中央处理单元(CPU)122，总线123互连了随机存取存储器(RAM)124、只读存储器126和支持如打印机130、磁盘单元132或如音频输出系统等其它未示出设备的各种I/O设备的输入/输出适配器128。系统总线123还连接提供对通信链路136访问的通信适配器134。用户接口适配器148连接各种用户设备，如键盘140和鼠标142或其它未示出设备，如触摸屏、触针、麦克风等。显示适配器144将系统总线123连接到显示设备146。
本领域普通技术人员应当理解图1B中的硬件可以根据系统实现改变。例如，系统可以有一个或多个处理器，如基于IntelPentium的处理器和数字信号处理器(DSP)，及一种或多种类型的易失和非易失存储器。其它外围设备可以与图1B所示的硬件同时使用或代替其使用。所述例子不是要暗示关于本发明的体系结构限制。
除了能够在多种硬件平台上实现，本发明还可以在多种软件环境中实现。典型的操作系统可以用于控制每个数据处理系统中的程序执行。例如，一个设备可以运行Unix操作系统，而另一个设备可以包含简单的Java运行时环境。代表性计算机平台可以包括浏览器，它是众所周知用于访问多种格式的超文本文档的软件应用程序，这些文档如图形文件、文字处理文件、可扩展标记语言(XML)、超文本标记语言(HTML)、手持设备标记语言(HDML)、无线标记语言(WML)及各种其它格式和类型的文件。
如上关于图1A和图1B所描述的，本发明可以在多种硬件和软件平台上实现。但是，更具体而言，本发明针对改进的数据处理环境。在更具体地描述本发明之前，先描述典型数据处理环境的一些方面。
在此对附图的描述可以涉及客户端设备或客户端设备用户的特定动作。本领域普通技术人员应当理解对客户端的响应和/或来自客户端的请求有时候是由用户启动的，而其它时候是由客户端，常常是代表客户端的用户，自动启动的。因此，当在附图的描述中提到客户端或客户端的用户时，应当理解术语“客户端”或“用户”可以互换使用，而不显著影响所述处理的意义。
特定的计算任务在以下可以描述为由功能单元执行。功能单元可以由例程、子例程、处理、子处理、过程、函数、方法、面向对象的对象、软件模块、小应用程序、插件、ActiveXTM控件、脚本或用于执行计算任务的固件或软件的一些其它组件表示。
在此附图的描述可以涉及各种组件之间信息的交换，而且信息的交换可以描述为通过消息的交换实现，例如请求消息后面跟着响应消息。应当指出，当合适的时候，计算组件之间可以包括同步或异步请求/响应交换的信息交换可以通过多种数据交换机制，如消息、方法调用、远程过程调用、事件发信号或其它机制，同等地实现。
现在参考图2，方框图描述了典型的企业数据处理系统。图1A描述了具有客户端与服务器的典型数据处理系统，相反，图2示出了网络中与可用于支持客户端访问资源的请求的一些服务器端实体相关的客户端。就象在典型的计算环境中，企业域200寄存用户202可以通过网络208例如通过使用客户端206上浏览器应用程序204访问的资源；如图1A所示，计算机网络可以是因特网、内联网或其它网络。
企业域200支持多服务器。应用服务器210通过基于web的应用程序或包括传统应用程序的其它类型的后端应用程序支持受控和/或非受控资源。反向代理服务器214，或更简单地说是代理服务器214，对于企业域200执行广泛的功能。例如，代理服务器214可以高速缓冲网页，以便镜像来自应用服务器的内容。输入和输出的数据流可以分别由输入数据流过滤器216和输出数据流过滤器218处理，以便根据各种策略中规定的目标和状态或根据所部署软件模块的配置对输入的请求和输出的响应执行各种处理任务。
会话管理单元220管理会话标识符、高速缓冲的凭证或关于代理服务器214所识别出的会话的其它信息。基于web的应用程序一般使用各种方式来提示用户输入认证信息，常常是作为HTML表格中用户名/口令的组合。在图2所示的例子中，用户202可能需要在客户端206可以访问资源之前被认证，之后为客户端206建立会话。在可选实施方式中，在向用户提供对域200上资源的访问之前不执行认证和授权操作；用户会话可能不伴随认证操作就创建。
以上提到的企业域200中的实体表示许多计算环境中的典型实体。但是，许多企业域具有用于控制对受保护计算资源的访问的安全特征。计算资源可以是应用程序、对象、文档、网页、文件、可执行代码模块或一些其它的计算资源或通信类型资源。受保护或受控资源是只有在发出请求的客户端或发出请求的用户被认证和/或授权后才能访问或检索的资源；在有些情况下，认证用户缺省地是授权用户。认证服务器222可以支持各种认证机制，如用户名/口令、X.509证书或安全标志；多个认证服务器可以专用于专门化的认证方法。授权服务器224可以采用授权数据库226，授权数据库226包含如访问控制列表228、授权策略230、关于用户组或角色的信息232及关于特定管理组内管理用户的信息234的信息。利用这种信息，授权服务器224向代理服务器214提供特定请求是否应当允许继续进行的指示，例如是否应当响应来自客户端206的请求准许对受控资源的访问。应当指出，本发明可以关联多种认证和授权应用程序实现，而且在此所述的本发明实施方式不应当解释为在认证和授权服务的配置方面限制本发明的范围。
现在参考图3，数据流程图说明了当客户端试图服务服务器上的受保护资源时可以使用的典型认证处理。如所说明的，客户端工作站300的用户通过在该客户端工作站上执行的用户web浏览器在计算机网络上搜索服务器302上受保护的资源。受保护的资源可以由只能由认证和授权用户访问的统一资源定位器(URL)，或更通用地说是统一资源标识符(URI)，识别。
当用户请求服务器端的受保护资源，如域“ibm.com”中的网页，时处理启动(步骤304)。术语“服务器端”和“客户端”分别指网络环境中在服务器或客户端的动作或实体。Web浏览器(或关联的应用程序或小应用程序)生成发送到寄存域“ibm.com”的web服务器的HTTP请求(步骤306)。术语“请求”和“响应”应当理解为包括适合于包括在特定操作中的信息，如消息、通信协议信息或其它关联的信息，传输的数据格式化。
服务器确定出它对该客户端没有活动的会话(步骤308)，因此服务器通过向客户端发送某些类型的认证询问来请求用户执行认证处理(步骤310)。认证询问可以是各种格式，如HTML表格。然后，用户提供所请求或要求的信息(步骤312)，如用户标识符及关联的口令，或者客户端可以自动返回特定信息，如数字证书。
认证响应信息发送到服务器(步骤314)，在这个时候，例如通过检索先前提交的注册信息并匹配给出的认证信息和用户所存储的信息，服务器认证用户或客户端(步骤316)。假定认证成功，则为该认证用户或客户端建立活动会话。
然后，服务器检索所请求的网页并向客户端发送HTTP响应消息(步骤318)。在这个时候，用户可以通过在浏览器中点击超文本链接请求“ibm.com”中的其它页面(步骤320)，然后浏览器将另一HTTP请求消息发送到服务器(步骤322)。在这个时候，基于由该服务器维护的会话状态信息，服务器识别出该用户已经具有了活动会话(步骤324)。例如，服务器识别发出请求的用户的适当会话状态，因为用户的客户端在HTTP请求消息中返回了会话ID。基于高速缓冲的用户会话信息，例如通过用户凭证拷贝的可用性，服务器确定用户已经被认证；然后，服务器就可以确定在满足用户请求之前如认证操作的特定操作不需要执行。服务器在另一HTTP响应消息中将所请求的网页发送回客户端(步骤326)，由此满足用户对受保护资源的最初请求。
尽管图3描述了当客户端试图访问服务器上受保护资源时可以使用的典型认证处理，但图3不提供确保认证处理以机密方式在客户端与服务器之间执行的安全处理的细节。相反，图4A说明了用于保护客户端与服务器之间信息交换的处理，因此如认证/授权处理及访问受保护资源的更多请求的后续数据交换可以机密方式执行。
现在参考图4A，数据流程图描述了客户端与服务器之间的多阶段典型信息交换，包括用于创建SSL(安全套接字层)会话的初始化阶段。由企业域的认证服务执行的认证/授权处理可以分成两个典型阶段。在典型的第一阶段402，客户端与服务器加入SSL(安全套接字层)握手，这可以包括证书和密钥交换，以便建立信任关系并协商用于SSL会话中加密消息的密钥和密码。在第一阶段可以有或没有与客户端用户的任何直接交互，尤其是关于错误处理。
在典型的第二阶段404，在SSL握手完成后，服务器请求客户端提供用户凭证，而客户端向服务器提供用户凭证。基于用户凭证的验证，服务器或者断开与客户端的连接，或者继续与客户端的安全连接以便进行进一步的数据交换。在第二阶段可以有或没有与客户端用户的任何直接交互，尤其是关于错误处理。其后，客户端与服务器加入典型交易406，其中服务器响应客户端访问受保护资源的请求。
现在参考图4B，数据流程图描述了SSL协议中典型的客户端-服务器握手，例如在图4A所示认证/授权操作的典型第一阶段可以执行的。SSL协议支持客户端与服务器之间的信息交换，使得后续信息交换可以在SSL会话中机密执行。SSL会话总是以称为SSL握手的消息交换开始。在SSL握手过程中，客户端与服务器协商加密算法并交换不对称加密密钥以产生称为会话密钥的对称加密密钥。其后，会话密钥可以用于加密信息交换。会话密钥可以假定为是对其在其中创建的会话唯一的，由此确保该会话中的信息交换是机密的。
以这种方式，SSL使用公钥加密和对称密钥加密的组合。SSL握手允许服务器通过使用公钥技术向客户端认证它自己。然后，它允许客户端与服务器合作创建在随后SSL会话中用于加密、解密和篡改检测的对称密钥。公钥加密提供了更有效的认证技术，这对生成会话密钥是期望的，同时对称密钥加密比公钥加密快，这在客户端请求访问受保护资源和服务器对这些请求响应的交易中是期望的。图4B通过解释当SSL会话中消息交换时所发生的典型命令序列说明了典型SSL会话。更具体而言，图4B利用对新会话的客户端认证说明了公用SSL握手-SSL版本3和TLS版本1握手流程。应当指出，多个SSL记录可以在单个包中发送。
当客户端向服务器发送CLIENT_HELLO命令时处理开始(步骤412)。CLIENT_HELLO命令包括由客户端支持的最高SSL和TLS版本(可以假定客户端以向后兼容的方式支持更早版本)；由客户端支持并以优先次序列出的密码；由客户端支持的数据压缩方法；如果客户端开始新SSL会话就等于0的会话ID；由客户端生成的用于密钥生成处理的随机数据。密码包是客户端支持的加密算法列表，如带JDES的RSA和带IDEA的RSA。客户端提供它能够或愿意支持的密码的完整列表，使得服务器可以选择一种。压缩算法列表的意思是非常类似于密码包列表的功能，其中客户端提供了它能完成的功能列表，服务器可以选择一种。会话ID可用于指示客户端希望恢复先前协商的会话；其好处是尽管客户端通常发送为0的会话ID来指示新会话必须协商，但是由于不用协商新的会话密钥，因此时间节省了。通称为“nonce”的随机数据是用于生成会话密钥并阻止重放攻击的一个变量。
作为响应，服务器发送多个命令。服务器向客户端发送SERVER_HELLO命令(步骤414)。SERVER_HELLO命令包括将用于SSL会话的SSL或TLS版本；将用于SSL会话的密码；将用于SSL会话的数据压缩方法；用于SSL会话的会话ID；由服务器生成的用于密钥生成处理的随机数据。随机数据或nonce是由服务器生成的以与客户端nonce相同方式使用的随机值。会话ID、密码包及压缩方法都是由服务器选择并施加到客户端的值；客户端先前已经指示了它可以支持的值，服务器在可用选项中进行选择。如果由于某种原因服务器不愿意或者不能够支持客户端，则服务器中止握手并关掉连接。
服务器还向客户端发送CERTIFICATE命令(步骤416)。CERTIFICATE命令伴随着服务器的公钥证书及，可选地，以颁发服务器公钥证书的认证授权(CA)的数字证书开始的数字证书串。此外，服务器还向客户端发送CERTIFICATE_REQUEST命令(步骤418)以请求客户端证书。CERTIFICATE_REQUEST命令包含服务器信任的认证授权的名字，因此客户端可以提供由那些认证授权中一个签名的证书。然后，服务器向客户端发送SERVER_DONE命令(命令420)。SERVER_DONE命令指示服务器已经完成了这个SSL握手阶段。
在响应服务器的命令之前，客户端可用执行几个验证步骤。例如，在客户端接收到服务器的证书或证书串后，客户端可以采取一些步骤来验证证书。客户端可以检查证书上的主体名字并比较它与已用于连接到服务器的域名。如果名字不匹配，则客户端可以中止握手。客户端还可以检查证书上的有效日期，以确保证书还未到期。假定客户端信任颁发者，则客户端还可以试图验证服务器证书上的数字签名。如果客户端不能验证证书，则客户端可以中止握手。在有些情况下，客户端可以通过通知用户已检测到错误然后允许用户选择是否继续来允许客户端的用户确定是否中止握手。
响应接收到服务器的命令，客户端发送多个命令。客户端向服务器发送CERTIFICATE命令(步骤422)，该命令伴随着客户端的公钥证书及，可选地，以颁发客户端公钥证书的认证授权的数字证书开始的数字证书串。客户端还向服务器发送CLIENT_KEY_EXCHANGE命令(步骤424)。这个CLIENT_KEY_EXCHANGE命令包含由客户端创建的预主秘(PreMasterSecret)。预主秘是通过利用来自服务器数字证书的服务器公钥加密保护的；如果服务器是先前发送的数字证书的合法拥有者，则只有该服务器应当拥有解密预主秘所需的私钥。客户端与服务器利用预主秘和伴随SERVER_HELLO与CLIENT_HELLO命令的随机数据分别生成对称加密密钥。如果服务器实际上是装成数字证书拥有者的攻击者，则它将不能解密预主秘，这意味着它不能得到会话密钥；没有会话密钥，因为与FINISHED命令关联的验证步骤，所以服务器不能完成握手，该步骤在下文中描述。
客户端还向服务器发送CERTIFICATE_VERITY命令(步骤426)。CERTIFICATE_VERITY命令包括已经利用客户端私钥签名的SSL握手消息的摘要。服务器计算它自己的摘要并使用从客户端的数字证书获得的客户端公钥来验证由客户端发送的摘要，从而完成验证客户端拥有与来自客户端数字证书的公钥对应的私钥的认证处理。客户端还向服务器发送CHANGE_CIPHER_SPEC命令(步骤428)。CHANGE_CIPHER_SPEC命令指示在SSL会话中由客户端发送到服务器的后续SSL记录数据的内容将要加密；但是，SSL记录头不加密。客户端通过向服务器发送FINISHED命令结束(步骤430)。FINISHED命令是利用会话密钥加密的，而且包括到这个时候为止在客户端与服务器之间流动的所有SSL握手命令的摘要。这个命令的发送是为了验证先前发送的在客户端与服务器之间未加密流动的命令中没有一个在发送中例如被恶意用户采用所谓中间人或重放攻击而改变。在CLIENT_HELLO和SERVER_HELLO消息中发送的nonce值有助于确保来自不同SSL会话的握手消息是不同的，即使会话是在相同的客户端与服务器之间。没有nonce值，在特定的情况下攻击者就有可能捕捉客户端与服务器之间的握手消息并在随后试图欺骗一方时重放它们。
响应客户端命令，服务器随后向客户端发送CHANGE_CIPHER_SPEC命令(步骤432)。这个命令指示在SSL会话中由服务器发送的所有后续数据都将加密。服务器通过向客户端发送FINISHED命令结束(步骤434)，FINISHED命令是利用会话密钥加密的，而且包括到这个时候为止在服务器与客户端之间流动的所有SSL握手命令的摘要；FINISHED命令充当SSL会话已成功建立的通知消息，由此结束典型的SSL握手处理。
给出关于图1A-4B所讨论的背景信息，其余附图的描述关于本发明。应当指出，有多个版本的SSL协议或TLS协议，而且本发明适用于或打算适用于多个版本的SSL协议或TLS协议，包括过去、当前和将来的版本。因此，尽管示例实施方式在此描述为增强SSL握手，但示例实施方式也可以描述为增强TLS握手。而且，这里的例子利用典型HTTP/HTTPS消息交换在基于web的应用程序，包括web浏览器，之间传输网页描述客户端与服务器之间的信息传输。还应当指出，本发明适用于使用和/或支持SSL协议的很多种通信协议及不以web为中心的很多种数据处理环境。
现在参考图4C，数据流程图描述了根据本发明客户端与服务器之间的多阶段信息交的，其中认证/授权处理在单个阶段发生。图4C类似于图4A，因为两个图都说明了认证/授权阶段和后续交易阶段中的至少一个。但是，图4A包含多个认证/授权阶段，而图4C只说明了一个认证/授权阶段。
更具体而言，图4C与图4A的区别在于图4C说明了是包括增强SSL握手的信息交换的初始化阶段452。在阶段452中，增强SSL握手支持服务器对来自客户端的用户凭证的检索，如以下更具体描述的。基于用户凭证的验证，服务器或者断开与客户端的连接，或者继续与客户端的安全连接，以进行进一步的数据交换。其后，客户端与服务器加入后续交易阶段454，其中服务器响应客户端访问受保护资源的请求。
现在参考图4D，数据流程图描述了根据本发明实施方式SSL(安全套接字层)协议中增强的客户端-服务器握手，其中SSL握手包的属性证书从客户端向服务器的传输。图4D类似于图4B之处在于两个图都说明了用于建立SSL会话的握手过程；相同的标号指相同的步骤或命令。
但是，图4B说明了例如在如图4A所示多阶段认证/授权过程的第一阶段中可以使用的典型SSL握手，而图4D说明了本发明实施方式中在如图4C所示单阶段认证/授权过程中可以使用的增强SSL握手。换句话说，不采用其中SSL会话在第一阶段建立而用户凭证在先前建立的SSL会话的第二阶段传输并验证的典型两阶段认证/授权过程，本发明提出了采用支持在单个阶段中用户凭证传输与验证的增强SSL握手的单阶段认证/授权过程。
图4D与图4B的区别在于图4B中的步骤422被步骤462代替。以类似于步骤422的方式，当客户端响应来自服务器的CERTIFICATE_REQUEST命令时，客户端在步骤462发送CERTIFICATE命令，该命令伴随着客户端的数字证书及，可选地，以颁发客户端公钥证书的认证授权的数字证书开始的数字证书串。
步骤462与步骤422的区别是因为客户端的数字证书(及可选地数字证书串)在步骤462附加地伴随着根据客户端数字证书颁发的属性证书。该属性证书包含例如在应用层中SSL层之上客户端/用户用于执行附加认证或授权操作的凭证，由此在增强SSL握手中传输附加凭证使凭证的后续传输不必要，如以下更具体解释的。
属性证书可以看作的客户端证书串的一部分。由于客户端私钥可能已经用于签名属性证书，因此属性证书可以利用客户端数字证书中的客户端公钥验证。以众所周知的验证证书串的方式，如果传输了和/或对于在验证过程中实现的安全等级是必需的，则验证过程还可以涉及客户端证书串中其它数字证书的使用。
现在参考图5，方框图描述了根据本发明实施方式在增强SSL握手中CLIENT_HELLO命令的传输。再次参考图4D，如上所述，本发明的实现包括在增强SSL握手中当客户端向服务器发送证书串时在步骤462的附加信息。应当指出，在本发明增强SSL握手的可选实现中，步骤412中CLIENT_HELLO命令和步骤414中SERVER_HELLO命令的内容还可以包含在典型SSL握手中不使用的增强信息。
现在参考图5，客户端502向服务器506发送CLIENT_HELLO命令504，而CLIENT_HELLO命令504包含一些典型的数据域随机数据508、会话标识符510、密码包数据512及压缩方法数据514。尽管典型CLIENT_HELLO命令中的PROTOCOL_VERSION数据域指示由客户端支持的最高SSL和TLS版本，但本发明的示例实现可以在CLIENT_HELLO命令504中包括新数据值516。在本发明的实施方式中，PROTOCOL_VERSION数据域中的数据值516可以对应其中属性证书交换了的增强SSL协议版本，由此指示客户端能够支持增强SSL握手中属性证书中凭证的传输。以对应的方式，服务器返回到客户端的SERVER_HELLO命令(未示出)也可以包含增强SSL协议版本指示符值。
现在参考图6，方框图描述了根据本发明实现可用于支持增强SSL协议的数据存储器与功能单元的示例集合。如以上关于图4D所讨论的，客户端包括当在增强SSL握手中向服务器发送证书或证书串时的附加信息；更具体而言，客户端的数字证书/证书串伴随着已经利用客户端数字证书颁发和包括某种格式附加安全凭证的属性证书。根据本发明在执行增强SSL握手之前，客户端与服务器需要配置成为增强SSL握手提供支持。图6说明了可能用于配置客户端与服务器以便执行支持增强SSL握手的操作的一些元件。
客户端602支持基于客户端的应用程序登录模块604，该模块包含属性证书生成模块606。基于客户端的应用程序登录模块604的表格因子可以在本发明的不同实现中改变。例如，基于客户端的应用程序登录模块604可以静态地包含在独立应用程序中或管理实用程序中，或者基于客户端的应用程序登录模块604也可以从服务器动态下载。基于客户端的应用程序登录模块604可以是JavaTM认证与授权服务(JAAS)模块；JAAS是启用对用户认证和/或实现访问控制的包。在任何情况下，各种安全策略都可能需要操作基于客户端的应用程序登录模块604，例如，由给定用户拥有的管理个人权限或特定权限。
在合适的时候，客户端用户操作基于客户端的应用程序登录模块604，而基于客户端的应用程序登录模块604获得构成用户凭证基础的凭证信息；例如，客户端可以配置成从特定的目录或数据库检索凭证信息，或者用户可以被提示输入源地址或执行某种其它输入操作。凭证信息的格式可以对许多不同类型的认证/授权操作改变。例如，用户可能被提示输入用户名/口令值对，或者用户可能被提示执行允许生物统计数据从用户获得的动作。可选地，凭证可以由从合适数据库，如数字证书数据库/密钥存储器608，检索的Kerberos票表示，数字证书数据库/密钥存储器608可以是其中访问以某种形式，例如由主口令或附加生物统计过程，被保护的安全数据存储器。
基于客户端的应用程序登录模块604检索凭证信息并生成包含凭证信息612的属性证书610。附加信息也可以绑定到属性证书610，如该属性凭证打算用到的域名。作为颁发处理的一部分，属性证书610利用合适的私钥，例如对应于，即关联域或绑定到，公钥证书614的私钥616，签名。属性证书610可以存储在合适的数据库中，直到随后某个时间点当它需要时，如包含所关联用户/客户端证书串中其它证书的证书数据库/密钥存储器608，其它证书如用户/客户端证书614和CA证书618，CA证书618是颁发用户/客户端证书614的认证授权的公钥证书。
实际上，客户端602充当颁发属性证书610的认证授权，它包含与实体关联的，即属于实体的，属性信息，实体即其身份绑定到私钥和对应数字证书的客户端或用户。公钥证书提供身份与公钥之间的绑定，而属性证书提供身份与该身份的属性信息之间的绑定。利用私钥在属性证书上的数字签名使属性证书依赖对应于该私钥的公钥证书。
一般化属性证书的使用是众所周知的。本发明与用于公钥证书和属性证书的多种格式兼容。在示例实施方式中，公钥证书可以如2002年4月由因特网工程任务组(IETF)Housley等人在“Internet X.509Public Key Infrastructure Certificate and Certificate RevocationList(CRL)Profile”，RFC 3280(请求注释3280)中所描述的那样格式化。同样，属性证书可以如2002年4月由IETF Farrell等人在“AnInternet Attribute Certificate Profile for Authorization”，RFC 3281中所描述的那样格式化。
在某个随后的时间点，客户端602采用增强SSL协议客户端模块620与服务器622交互，以便执行根据本发明的增强SSL握手；服务器622支持用于执行其关于增强SSL握手的动作的对应增强SSL协议服务器模块624。响应来自服务器622的CERTIFICATE_REQUEST命令，客户端602向服务器622发送证书串626。证书串626包含用户/客户端公钥证书614和属性证书610及，可选地，构成证书614的证书串的附加证书。在接收到证书串626后，服务器622可以验证证书614和属性证书610中的凭证。证书串626或其部分，如嵌入在属性证书中的凭证信息或整个属性证书，可以在发送之前由客户端602利用服务器公钥加密，以便保护凭证信息612的机密性。
现在参考图7，流程图描述了根据本发明用于生成包含将在增强SSL握手中从客户端传输到服务器的用户/客户端凭证的属性证书的处理。处理在客户端通过例如从用户或数据仓库获得凭证信息开始(步骤702)。包含凭证信息的属性证书被创建(步骤704)。凭证信息存储在属性证书内部的数据域内；凭证信息的格式可以改变，但凭证信息可以是文本数据、ASCII编码的十六进制数据或某种其它格式。如果凭证包括纯文本口令，则口令可以利用各种机制保护。例如，口令可以利用来自服务器证书的公钥或利用在服务器密钥交换消息中提供的临时RSA密钥加密。可选地，如SHA或MD5的混编算法可以用于混编口令，而且混编值将代替实际口令传输。
然后，属性证书利用来自合适公钥证书的私钥签名(步骤706)。然后，属性证书存储在合适的数据存储器中以备后用(步骤708)，优选地存储在客户端的本地数据库中，处理结束。
现在参考图8，流程图描述了根据本发明用于在增强SSL握手从客户端向服务器传输包含用户/客户端凭证的属性证书的处理。在图8所示的例子中，在所说明处理的初始化步骤之前，增强SSL握手已经启动，因此图8所示处理仅描述整个增强SSL握手的一部分。当在增强SSL握手中客户端从服务器接收CERTIFICATE_REQUEST命令时处理开始(步骤802)。客户端从合适的数据存储器检索属性证书和公钥证书(步骤804)并在CERTIFICATE命令中将它们发送到服务器(步骤806)，由此结束处理。
在图8所说明的例子中，属性证书是在步骤804从数据存储器检索的；例如，属性证书可以利用如图7所示的处理在先前创建。在可选实施方式中，属性证书可以在步骤804利用类似于图7所示的处理动态生成，而不是检索先前创建的属性证书。例如，在一种实施方式中，嵌入在属性证书中的凭证信息可以利用在增强SSL握手协议中由客户端从服务器接收的服务器公钥加密；在那种情况下，属性证书将在接收到服务器公钥后动态生成。但是，在另一种实施方式中，整个属性证书或整个证书串在从客户端发送到服务器之前加密，在这种情况下属性证书可以或者在步骤804从数据存储器检索或者在执行任何合适的加密操作之前在处理中相似的点动态生成。
现在参考图9，流程图描述了根据本发明用于在增强SSL握手中在服务器验证来自客户端的公钥证书和包含用户/客户端凭证的关联属性证书的处理。增强SSL握手在所说明处理的初始化步骤之前已经启动，因此图9所示的处理只描述整个增强SSL握手的一部分。
当服务器从客户端接收CERTIFICATE命令中的属性证书和公钥证书时处理开始(步骤902)。服务器试图验证该公钥证书(步骤904)，如果成功，则服务器还试图验证所关联的属性证书(步骤906)；如果公钥证书和所关联的属性证书都成功地验证了，则增强SSL握手继续，以便建立SSL会话(步骤908)。
应当指出，本发明可以实现成使公钥证书和属性证书既不需要由服务器上某个软件模块验证，也不需要在可能要验证软件模块的同一网络层中验证。在图9所示的例子中，公钥证书和属性证书在SSL会话根据增强SSL握手协议建立时验证；如果属性证书未通过验证，则SSL会话不能建立。可选地，属性证书可以在SSL会话利用增强SSL握手协议建立后验证；以这种方式，SSL会话可以建立而属性证书仍然被拒绝，由此使SSL会话能够继续被使用。
类似地，应当指出，本发明可以实现成使属性证书及其所包含的凭证信息既不需要由相同的软件模块在服务器也不需要在可能要验证该软件模块的同一网络层中验证。在图9所示的例子中，属性证书在SSL会话根据增强SSL握手协议建立时验证，其后凭证信息以某种形式到达期望该凭证信息返回的调用模块。更具体而言，凭证信息是从属性证书提取的(步骤910)。然后，凭证信息到达期望该凭证信息返回的调用模块(步骤912)，处理结束。应当期望请求模块其后将验证凭证信息。以这种方式，SSL会话利用增强SSL握手协议建立，结果是凭证信息返回到请求SSL会话建立的模块。
优选实施方式在图9中示出，使凭证信息在SSL会话建立后验证，从而使处理凭证信息的逻辑可以不嵌入在SSL层，而是在更高层，如应用层。利用本发明所说明的实施方式，安全通信会话在单阶段操作中传输凭证信息时创建，使凭证信息对后续认证过程或后续授权过程可用，即在安全通信会话建立以后可用。
但是，在可选实施方式中，本发明可以实现成使属性证书及其所包含的凭证信息在SSL会话根据增强SSL握手协议建立时验证。在这种可选实施方式中，如果凭证信息也未通过验证，则增强SSL握手可能经历致命错误；换句话说，根据增强SSL握手协议的这种可选实现，公钥证书、属性证书及其所包含的凭证信息需要被验证，以便建立SSL会话。
在另一可选实施方式中，不是只向请求SSL会话建立的模块返回凭证信息，而是整个属性证书都可以返回，由此提供属性证书及嵌入在该属性证书中的凭证信息。
解密操作可以根据需要执行。如果凭证信息在嵌入到属性证书之前例如由客户端利用服务器公钥加密了，则凭证信息在服务器例如利用服务器私钥解密。如果整个属性证书和/或整个证书串都在发送到服务器之前由客户端加密了，则整个属性证书和/或整个证书串将在图9所说明处理中在服务器上合适的时候解密。
本发明还可以实现成关于根据增强SSL会话建立SSL会话时的错误提供错误处理。如果公钥证书或属性证书未通过验证，则产生致命错误(步骤914)，这会终止增强SSL握手。错误消息可以由服务器发送到客户端(步骤916)。错误也可以返回到请求SSL会话建立的模块(步骤918)。在其中产生致命错误的任何情况下，SSL会话都不建立，且处理结束。
在图9所示的例子中，在试图建立SSL会话时试图验证属性证书；由此，如果属性证书未通过验证，则SSL会话不能建立。但是，如上所述，在可选实施方式中，属性证书可以在SSL会话利用增强SSL握手协议建立后验证。在这种情况下，SSL会话可以建立而属性证书仍被拒绝，由此使SSL会话可以继续在客户端与服务器之间被使用。在这种可选实施方式中，将执行附加恢复过程，其中服务器试图获得来自客户端的凭证信息；换句话说，凭证信息可以在SSL会话利用增强SSL握手协议建立后获得，同时采用最近建立的SSL会话安全地传输凭证信息。
应当指出，在关于图6-8所说明的本发明示例实施方式中，属性证书的创建发生在属性证书的使用之前，即，在增强SSL握手的执行之前。但是，在可选实施方式中，属性证书可以在增强SSL握手过程中创建，例如，在客户端从服务器接收到CERTIFICATE_REQUEST命令之后。但是，在这种实施方式中，属性证书将优选地以可编程方式整个自动地创建，而没有任何类型用户动作或用户输入的任何中断。
如上所述，在有些情况下，用户和客户端在本领域中被识别为关于在数据处理系统中所执行操作的受益人的观点有时候可以互换的实体。如客户端设备的用户的自然人可以是数字证书的主体，即，其身份作为公钥证书的命名主体绑定到公钥证书的实体。但是，如客户端设备的设备也可以是其身份绑定到公钥证书的实体。如果客户端设备的用户是属性信息与其关联的实体，则用户的公钥证书用于签名属性证书；如果客户端设备是属性信息与其关联的实体，则客户端的公钥证书用于签名属性证书。以这种方式，依赖于由服务器代表来自客户端请求所执行的安全操作，本发明支持其中凭证从客户端传输到服务器的增强SSL握手，使凭证可以绑定到，即与用户或客户端设备关联或由其处理，其中安全操作可以代表用户或自然人执行。
还应当指出，在上述本发明的示例实施方式中，只有一个属性证书从客户端传输到服务器。但是，如上所述，属性证书可以为特定目的专门创建，例如通过在创建时在属性证书中放置预期接收者的域名。由此，在可选实施方式中，多个属性证书可以在增强SSL握手过程中从客户端发送到服务器；例如，多个属性证书可以与发送的证书串绑定到一起。这多个属性证书中的每一个都已经由也在增强SSL握手中传输的同一公钥证书的私钥签名，而且通过利用属性证书中的指示信息，如域名，客户端将能够识别许多可用属性证书中哪些属性证书需要发送到特定服务器。以这种方式，多个服务器端应用程序或操作的凭证需求可以利用嵌入到本发明增强SSL握手中的单阶段认证/授权过程满足。例如，如果客户端或用户需要登录到多个服务器应用程序中以便有效地执行一组任务，则这多个服务器应用程序每个所需的凭证信息可以在增强SSL握手中传输。
可选地，当属性证书产生时，多组凭证信息可以在单个属性证书绑定到一起；客户端与服务器将拥有嵌入或提取这多组凭证信息的对应逻辑。以这种方式，单个属性证书可以用于传输多组凭证，而多个服务器端应用程序或操作的凭证需求可以利用由本发明增强SSL握手所提供的单阶段过程满足。
尽管本发明是在全功能数据处理系统的环境下描述的，但本领域普通技术人员应当理解本发明的处理能够以计算机可读介质中指令的形式和多种其它形式分布，而不管实际用于执行分布的信号承载介质的特定形式是什么，指出这点是很重要的。计算机可读介质的例子包括如EPROM、ROM、磁带、纸张、软盘、硬盘驱动器、RAM和CD-ROM的介质及如数字和模拟通信链路的传输类型介质。
方法通常被看作是导致期望结果的自相容步骤序列。这些步骤需要物理量的物理操作。通常，但不是必需，这些量采用能够被存储、传输、组合、比较及以其它方式操作的电或磁信号的形式。从原理上讲是出于共同使用的原因，有时候称这些信号为位、值、参数、项目、元素、对象、符号、字符、项、数字等是方便的。但是，应当指出，所有这些术语及类似术语是与合适的物理量关联的而且仅仅是适用于这些量的方便的标记。
本发明的描述是为说明提出的，而不打算是穷尽的或者要限定到所公开的实施方式。许多修改和变体对本领域普通技术人员是显然的。实施方式的选择是为了解释本发明的原理及其实际应用，并使本领域普通技术人员能够理解本发明，以便实现具有可能适合于其它预期使用的各种修改的各种实施方式。
权利要求
1.一种用于在数据处理系统中支持安全通信会话的建立的方法，该方法包括从服务器向客户端发送证书请求命令；在服务器从客户端接收响应该证书请求命令的证书命令，其中证书命令伴随着公钥证书和由绑定到该公钥证书的私钥数字签名的属性证书，而且其中属性证书包含用于在安全通信会话建立后执行的认证操作或授权操作的凭证信息；及响应成功地验证了公钥证书，建立安全通信会话。
2.如权利要求1所述的方法，其中安全通信会话是安全套接字层(SSL)会话。
3.如权利要求2所述的方法，还包括在建立SSL会话后，将凭证信息从服务器的SSL层传递到服务器的应用层。
4.如权利要求2所述的方法，还包括在建立SSL会话后，将属性证书从服务器的SSL层传递到服务器的应用层。
5.如权利要求1所述的方法，还包括在建立SSL会话之前，除了公钥证书的成功验证之外，还需要属性证书的成功验证。
6.如权利要求5所述的方法，还包括在建立SSL会话之前，除了公钥证书和属性证书的成功验证之外，还需要凭证信息的成功验证。
7.如权利要求1所述的方法，还包括由服务器利用服务器的私钥解密凭证信息，其中在客户端接收到证书请求命令之前凭证信息事先由客户端利用客户端从服务器接收的在公钥证书中的公钥加密。
8.如权利要求1所述的方法，其中安全通信会话是传输层安全(TLS)会话。
9.一种用于在数据处理系统中支持安全通信会话的建立的方法，该方法包括在客户端从服务器接收证书请求命令；响应该证书请求命令，从客户端向服务器发送证书命令，其中证书命令伴随着公钥证书和由绑定到该公钥证书的私钥数字签名的属性证书，而且其中属性证书包含用于在安全通信会话建立后执行的认证操作或授权操作的凭证信息；及在客户端从服务器接收安全通信会话已成功建立的通知。
10.如权利要求9所述的方法，其中安全通信会话是安全套接字层(SSL)会话。
11.如权利要求9所述的方法，其中安全通信会话是传输层安全(TLS)会话。
12.一种计算机可读介质上的计算机程序产品，用于数据处理系统中以便支持安全通信会话的建立，该计算机程序产品包括用于实现前面方法权利要求所述的任一方法的装置。
13.一种用于在数据处理系统中支持安全通信会话的建立的装置，该装置包括用于从服务器向客户端发送证书请求命令的装置；用于在服务器从客户端接收响应该证书请求命令的证书命令的装置，其中证书命令伴随着公钥证书和由绑定到该公钥证书的私钥数字签名的属性证书，而且其中属性证书包含用于在安全通信会话建立后执行的认证操作或授权操作的凭证信息；及用于响应成功地验证了公钥证书建立安全通信会话的装置。
14.如权利要求13所述的装置，其中安全通信会话是安全套接字层(SSL)会话。
15.如权利要求14所述的装置，还包括用于在建立SSL会话后将凭证信息从服务器的SSL层传递到服务器的应用层的装置。
16.如权利要求14所述的装置，还包括用于在建立SSL会话后将属性证书从服务器的SSL层传递到服务器的应用层的装置。
17.如权利要求13所述的装置，还包括用于在建立SSL会话之前除了公钥证书的成功验证之外还需要属性证书的成功验证的装置。
18.如权利要求17所述的装置，还包括用于在建立SSL会话之前除了公钥证书和属性证书的成功验证之外还需要凭证信息的成功验证的装置。
19.如权利要求13所述的装置，还包括用于由服务器利用服务器的私钥解密凭证信息的装置，其中在客户端接收到证书请求命令之前凭证信息事先由客户端利用客户端从服务器接收的在公钥证书中的公钥加密。
20.如权利要求13所述的装置，其中安全通信会话是传输层安全(TLS)会话。
21.一种用于在数据处理系统中支持安全通信会话的建立的装置，该装置包括用于在客户端从服务器接收证书请求命令的装置；用于从客户端向服务器发送响应该证书请求命令的证书命令的装置，其中证书命令伴随着公钥证书和由绑定到该公钥证书的私钥数字签名的属性证书，而且其中属性证书包含用于在安全通信会话建立后执行的认证操作或授权操作的凭证信息；及用于在客户端从服务器接收安全通信会话已成功建立的通知的装置。
22.如权利要求21所述的装置，其中安全通信会话是安全套接字层(SSL)会话。
23.如权利要求21所述的装置，其中安全通信会话是传输层安全(TLS)会话。
全文摘要
提出了用于在数据处理系统中支持安全通信会话建立的方法与系统。证书请求命令从服务器发送到客户端。在服务器从客户端接收响应该证书请求命令的证书命令，而且证书命令伴随着公钥证书和由绑定到该公钥证书的私钥数字签名的属性证书。响应成功验证了公钥证书，建立安全通信会话。属性证书包含用于在安全通信会话建立后执行的认证操作或授权操作的凭证信息。
文档编号H04L29/06GK1885771SQ200610088708
公开日2006年12月27日 申请日期2006年5月31日 优先权日2005年6月23日
发明者安托尼·J·纳达林, 布鲁斯·A·里奇, 张晓燕 申请人:国际商业机器公司