在客户机－服务器环境中认证客户机的系统和方法

摘要

本发明用新的数字签名认证过程代替现有基于口令/用户ID的认证过程，其中，优选地独立于目的服务器使用的认证过程且无需服务器请求认证信息，用客户认证信息扩展第一HTTP－请求头部。认证信息优选地包括包含客户机公钥并由认证机构签名的客户机证书，和优选地在HTTP－请求头部数据上计算且用客户机的私钥加密的散列值。可在客户机系统自身中创建HTTP－请求头部时添加该证书和数字签名，或者随后在用作网关、代理或隧道的服务器中添加。不支持该新数字签名认证过程的目的服务器将只是忽略HTTP－请求头部中的证书和数字签名，并自动开始自己的认证过程。本发明简化了现有的数字签名认证过程，同时允许不同认证过程并存，而不改变HTTP－协议或产生不必要的网络通信量。

说明书

技术领域

本发明一般地涉及认证，并具体地涉及在客户机-服务器环境中的认证，尤其涉及因特网中的客户机的认证。

背景技术

认证是确定某人或某事物实际上是否为其被声明是的人或事务的过程。在专用或公共计算机网络中，认证通常通过使用登录口令来完成。通常，每个服务器维护其自己的数据持久性以便存储认证数据。因此，在一个服务器上可由客户机使用的口令，在另一服务器上可能已经被另一客户机阻碍。这使得客户机不得不记住和维护的不同认证集(authentication set)的数量增大。在分布在具有不同用户认证系统的多个服务器上的应用(例如，通过门户服务器访问应用，其中该门户服务器使用其自己的用户数据库)中，客户机会不得不登录一次以上。

允许单次登录的权变措施(workaround)包含诸如将用于应用服务器的登录数据存储在门户服务器上，或者使用集中的用户数据库例如Microsoft^的.NET Passport(http：//www.passport.com)或LibertyAlliance的Liberty(http：//www.projectliberty.org)的方法。这需要客户机愿意在第三方站点上存储个人数据，并承受此方法所带来的所有数据安全问题。另外，如果Passport服务停止，则个人不能登录到希望的服务，即使他希望使用的站点可用。

使用用户身份/口令组来进行认证还存在下面这样的缺陷，即它会带来额外的网络通信量。在客户机请求时，服务器必须通过要求登录数据来应答。只有在提供登录数据之后，最初请求的信息才被送回给客户机(又见下面的图7A)。

最后，口令经常会被窃取、偶然泄漏或者只是忘记。

为此，互联网商务以及许多其他事务需要更严格的认证过程。使用认证机构(CA)颁发和证明的作为公钥基础结构的一部分的数字证书被认为成为在因特网上执行认证的标准方式。

数字签名使得接收者(服务器)能够验证发送者(客户机)的身份和来源以及文件的完整性。

数字签名基于非对称的加密算法。用发送者的私钥将文件签名。接收者可获得发送者的公钥，该公钥是由可信的第三方提供给接收者的，并且验证接收到的文件的完整性。

在已有的口令登录基础结构中实现数字签名过程需要在服务器侧以及客户机侧进行很大的改动，例如具有特定安全应用的附加的读卡机。因此，这种实现导致在成本和时间上的很大花费，结果优选地只有新的客户机-服务器基础结构将使用数字签名过程。客户机-服务器环境中存在这两种认证过程的缺点是，客户机必须首先检查目的服务器是支持口令登录还是支持数字签名过程。根据检查的结果，客户机将使用由服务器支持的需要的认证过程。这会导致在客户机和服务器之间的很多不必要的网络通信量，因为服务器应用自身最终确定认证的类型。

此外，现有的数字签名认证过程的缺点是，客户机和服务器之间的一些屏幕必须在客户机和服务器之间交换，直到客户机可提供它的认证信息。这会导致很多不必要的网络通信量。

由此，本发明的目标是通过避免上述现有技术的缺陷，提供一种用于在客户机-服务器环境中认证客户机的方法和系统。

发明内容

本发明的思想是用新的数字签名过程代替现有的基于口令/用户ID的认证过程，在该新的数字签名过程中，优选地独立于目的服务器使用的认证过程并且无需服务器请求认证信息，用客户机认证信息扩展第一HTTP-请求头部。该认证信息优选地包括客户机证书，该客户机证书包含被认证机构签名的客户机公钥，以及优选地在请求中发送的HTTP-请求头部数据上计算的且用客户机的私钥加密的散列值。可在客户机系统自身中创建HTTP-请求头部期间添加该证书和数字签名，或者随后在用作网关、代理或隧道的服务器中添加该证书和数字签名。

不支持新数字签名认证过程的目的服务器将只是忽略HTTP-请求头部中的证书和数字签名，并且将自动开始其自己的认证过程。本发明简化了现有的数字签名认证过程，并同时允许不同的认证过程并存，而不改变HTTP-协议或造成不必要的网络通信量。

附图说明

在下面详细写成的说明书中可清楚地看到本发明的上述以及其他的目标、特征和优点。

本发明的新颖特征在所附权利要求中提出。但是，通过参照下面的对示例性实施例的详细说明并结合附图阅读，可最好地理解本发明自身及其优选的使用模式、另外的目标以及其优点，在这些附图中：

图1A/B示出了现有技术的HTTP-客户机-服务器环境，其中优选地使用本发明，

图2示出典型的现有技术的HTTP-头部的基本结构，

图3示出具有证书和数字签名的HTTP-头部的发明结构，

图4A-D示出将证书和数字签名一起插入HTTP-请求头部从而导致HTTP-请求头部的发明结构的优选实施例，

图5示出使用本发明的服务器-客户机通信环境的示例，

图6示出使用HTTP-请求的发明结构的根据图1A的客户机-服务器环境中的认证数据流的优选实施例，以及

图7A、B示出基于在线购买事务过程的示例的现有技术的认证过程与本发明的发明性认证过程的比较。

具体实施方式

参照图1A和图1B，其示出了其中优选地使用本发明的客户机-服务器环境。但是，应注意，本发明可用于使用允许头部扩展而不会妨碍正常协议使用的通信协议的每个客户机-服务器环境上。因此，将基于目前公知的HTTP-协议说明和解释本发明及其优选实施例。

HTTP-协议(超文本传输协议)是用于分布式系统的应用层协议。它是一组用于交换文件(文本、图形、图象、声音、视频以及其他多媒体文件)规则。任何web服务器机器3都包含HTTP-守护程序或所谓的HTTP-服务器4，它是一种被设计成等待HTTP-请求并在请求到达时处理该请求的程序。此外，每个客户机机器1包含向web服务器机器3发送请求的web浏览器或所谓的HTTP-客户机2。当浏览器用户通过打开web文件(键入URL)或点击超文本链接输入请求时，浏览器建立一HTTP-请求，并将其发送给在该URL中指示的网际协议地址。目的服务器机器3中的HTTP-服务器4接收到该请求，并在处理之后，返回请求的文件。在另一个客户机-服务器环境中，客户机1经由网关、隧道或代理服务器5与服务器3通信(见图1B)。

通常，HTTP在TCP/IP(传输控制协议/网际协议)上发生，但是HTTP并不依赖于TCP/IP。

TCP定义了一组在信息包层与其他因特网点交换消息的规则，而IP定义了一组在网际地址层发送和接收消息的规则。

HTTP-请求头部包含HTTP方法(GET、HEAD、POST等)、统一资源标识符(URI)、协议版本以及可选的补充信息。

HTTP-响应包括指示请求成功或失败的状态行、响应中的信息的描述(元信息)以及实际信息请求。

参照图2，其示出了现有技术的HTTP-请求头部的基本结构。每个HTTP-请求必须包含至少一个头部。仅HTTP-Post请求包含头部和主体数据。HTTP-请求头部中优选地包含如下信息：

将被该HTTP-请求访问的资源(例如文件、小服务程序)

服务器的主机名(例如www.ibm.com)

浏览器的名称和版本(例如Netscape版本7.1)

客户机的操作系统(例如Windows XP)

浏览器可理解的字符集(例如iso-8859-1)

每个HTTP-头部可包含HTTP-协议没有定义并且不与使用HTTP-协议的现有应用冲突的补充信息。这意味着使用HTTP-协议并且没有被配置成处理该补充信息的应用只是忽略该补充信息而不中断其执行。

参照图3，其示出了根据本发明的HTTP-请求头部的发明性结构。

必须将下面的根据本发明的附加信息包含在HTTP-请求头部中：

包含公钥并且被认证机构签名的客户机证书，以及

在HTTP-请求头部以及如果可用的话HTTP-主体(Post)上计算的数字签名。

证书和数字签名可被服务器上的特定工具处理。客户机证书是由可信的第三方分发的文件，其将公钥绑定在特定人上。可信的第三方保证证书中包含的信息有效且正确。证书由509标准化。它们应包含可信的第三方的数字签名、拥有公钥的人的名称以及公钥本身。

参照图4A-C，其示出了将客户机证书和数字签名插入HTTP-请求头部的优选实施例。

参照图4A，其示出了将客户机的证书16与数字签名18一起插入HTTP-请求头部12的本发明的第一实施例。客户机系统1包含具有签名能力的浏览器2。浏览器2生成HTTP-请求头部12，访问被安全地存储在本地文件系统中的客户机的私钥，用该私钥对在HTTP-请求头部12和如果可用的话主体上生成的散列值加密，从而得到数字签名18。该数字签名18与包含公钥的客户机证书16一起被插入HTTP-请求头部12中。将该扩展的HTTP-请求头部14发送给HTTP-服务器4，该服务器开始认证过程。认证组件6可以是HTTP-服务器的一部分，或者是单独的组件，它验证来自HTTP-请求头部的客户机证书信息16。验证可通过检查认证机构的证书签名或者通过将该证书与其证书数据库9中包含的已知的证书相比较来完成。使用客户机证书16中包含的公钥将HTTP-请求头部12中包含的数字签名18解密，得到客户机1计算的散列值。使用同样的散列算法，在HTTP-请求头部12和如果可用的话主体上计算散列值。如果两个散列值匹配，则验证完成，并且认证成功，从而允许访问应用8。

参照图4B，其示出了将客户机证书16与数字签名18一起插入HTTP-请求头部12的本发明的第二实施例。现在，浏览器2具有经由智能卡读卡机10与智能卡10通信的功能。浏览器2生成HTTP-请求头部，建立与智能卡10的通信，在其安全模块中包含私钥和客户机的证书的智能卡10用该私钥对在HTTP-请求头部12和如果可用的话主体上生成的散列值加密(数字签名)，并将该数字签名18和客户机的证书16一起返回到浏览器2。将该数字签名18与包含公钥的客户机证书16一起插入HTTP-请求头部12。将该扩展的HTTP-请求头部14发送给HTTP-服务器4，该服务器通过使用认证组件开始认证过程(见对图4A的说明)。

参照图4C，其示出了将客户机证书16与数字签名18一起插入HTTP-请求头部12的本发明的第三实施例。在该第三实施例中，客户机系统包含自己的签名组件20。该组件用作在与浏览器2相同的客户机1上运行的代理服务器。浏览器2被配置成使用该代理服务器20。因此，浏览器2将常规的HTTP-请求头部12发送给签名组件20，该组件然后与如上所述的实施例类似地将证书16和数字签名18一起插入。将该扩展的HTTP-请求头部发送给HTTP-服务器4，该服务器通过使用认证组件开始认证过程(见对图4A的说明)。

参照图4D，其示出了将客户机证书16与数字签名18一起插入HTTP-请求头部12的本发明的第四实施例。在该实施例中，经由具有插入组件20的代理服务器22路由客户机请求(1a/2a，1b/2b)。该插入组件20与包含私钥及它们的所分配的签名的加密硬件24通信，该硬件用该私钥对在HTTP-请求头部12和如果可用的话主体上生成的散列值加密(数字签名)，并将数字签名18和客户机证书16返回到插入组件20，该组件将它们插入HTTP-请求头部12。将该扩展的HTTP-请求头部发送给HTTP-服务器4，该服务器通过使用认证组件开始认证过程(见对图4A的说明)。

总之，由于本发明描述了HTTP协议中的附加头部数据，所以能够处理头部中的该附加数据的现有客户机和服务器的所有组合均可一起工作。如果这些系统之一不能处理附加数据，则一切将如目前已知的那样工作。

为了保持数十亿计的已安装的客户机浏览器的现有基础，一附加的签名软件可通过作为本地客户机机器上的代理组件来处理HTTP扩展(见图4C)。在公司网络(例如内联网)内，这甚至可通过一中央代理服务器来处理(图4C)。于是Web浏览器的未来版本可在其中内建该功能(图4A)。以这种方式，到新范式的转变可随着时间的流逝而发生。

可使用签名智能卡或任何其他的签名硬件创建数字签名。具有存储在客户计算机上的加密钥匙的纯软件解决方案也是一种可能的实现。

图5示出了使用本发明的服务器-客户机通信环境的示例。

在此示例中，假设通过门户服务器3访问应用5。在现有技术中，此情况的处理或者是通过将客户机的身份数据存储在可被门户服务器3和应用服务器5访问的服务器上(例如Microsoft^的.NET Passport)，或者需要将用于应用服务器的身份数据存储在门户服务器3上。这两种方法都需要用户将其数据存储在第三方系统上，而这会遇到许多安全问题。

通过如图4A-D所述对该请求进行数字签名，不需要服务器来存储用户数据。门户服务器3可对照其用户数据库4检查请求者的身份，将请求转到应用服务器5，该应用服务器可使用其用户数据库6进行同样的操作。客户机1a通过门户服务器3访问应用服务器5，而客户机1b可直接访问应用服务器5。应用服务器5可使用其自己的用户数据库6来检索用户的简档信息。

由于应用服务器5可能希望仅处理那些通过门户服务器3的请求，所以此方法还提供了更高的安全性。在此情况下，门户服务器3转发请求并另外对其签名。这使得应用服务器能够验证两个签名，以便准许或拒绝对其服务的访问。客户机1a将获得对应用服务器5的访问，而客户机1b将不会得到服务，因为其请求没有通过门户服务器3。

参照图6，其示出了根据本发明的认证数据流。

客户机的浏览器准备对服务器的请求10。在本发明的优选实施例中，将检查是否开通对HTTP-请求头部的签名20。如果没有，则客户机的浏览器将向服务器发送未签名的请求40，并且服务器检查是否需要签名50。如果需要签名，则服务器将向客户机发送错误消息50。如果不需要签名，则服务器将提供对希望的信息的访问60。

如果开通了签名，则客户机的浏览器将证书和数字签名插入HTTP-请求头部，并将该HTTP-请求头部发送给服务器30。通过向HTTP头部请求头部添加附加字段，服务器能够从证书检索请求者的身份(认证)35。

客户机的证书包含请求者的名称和公钥。

由于它被可信的机构签名，所以服务器能够验证它是由可信的机构颁发的有效证书。能够验证该消息确实是由该证书的所有者发送的，因为只有属于该证书的私钥的所有者才能生成该HTTP-请求头部中的、在该HTTP-请求头部数据上计算的数字签名值，并且可通过使用该证书中包含的公钥来验证该所有者。如果认证成功，则服务器允许对被请求的数据的访问60。

参照图7A、7B，其示出了使用现有技术的认证过程与本发明的发明性认证过程的Web浏览器(客户机)和Web服务器(服务器)之间的信息交换的典型情况的比较。

例如，在购买过程中，客户机从代表在线购物系统的服务器接收数据并向其发送数据(例如，一系列文本或html页或格式化的数据例如XML的块)，直到订单被特定数据传输操作确认(例如HTTP Post)。在目前的应用中，在此过程期间，服务器发送请求以从客户机获得用户ID和口令。用户必须在这些信息被客户机应用发送给服务器之前手动提供这些数据(见图7A)。

在根据本发明的应用中(见图7B)，客户机利用数字签名对发送给服务器的HTTP-请求头部进行签名。服务器通过检查该签名容易地识别客户机。因此，不必请求和提供用户ID和口令，因为传递的每个数据项都与该用户的身份相关联。服务器可检索此客户机的存储的信息，并使用此信息来准备将被发送给客户机的数据(“个人化”，简档创建页面)。用于个人化的数据的示例是用户的地址(应当将订购的物品递送到什么地方)、用户的购物历史、用户的购物车、在最近会话期间访问的网页等。

通过检查用户的身份(这可在该流程的任何时间进行)，服务器可发现该用户以前从未访问过该站点。于是该服务器发送包含对指定偏好和详细用户数据的请求的数据(简档创建页面)。用户提供这些数据，客户机应用将该数据发送给服务器，并且服务器将这些用于个性化的数据存储在其数据库中。由于对每个数据传输签名，所以一旦客户机访问第一页面，服务器就知道客户机的用户ID。因此个人化可在此过程的早期发生。

当用户选择关闭签名时，服务器识别此事实，并可发送包含指示开通签名的页面，或作为代替使用传统的用户ID/口令方案(未示出)。