CN1503932A - 获得数字签字的方法和系统 - Google Patents

Abstract

一种数字签字系统包括保持访问控制规则的一数据库，这些规则识别允许授权的用户对其电子签字的文件，并且该签字系统能够接收来自多个授权用户的签字请求，每一签字请求包括一待签字的文件，其中签字系统分析待签字的文件，并比较由此获得的信息与存储在数据库中的访问控制规则，以确定授权的用户是否被授权具有签字的文件，并其中如果确定授权的用户被授权具有签字文件，则签字系统使用签字系统唯一的鉴定信息签署文件。

Description

获得数字签字的方法和系统

公开的领域

本公开一般涉及数字签字，并特别涉及获得数字签字的方法和系统。

相关技术的说明

加密是最常用的保护数据内容的方法。加密常用来在传输和存储中保护数据。按其基本形式，加密一般涉及使用算法，把明文数据转换为称为加密文本的不可理解的形式。加密中所使用的算法能够由其中称为密钥的所使用的参数定义。两个已知的加密方法是只使用私有密钥的对称方法，及使用公开和私有密钥的非对称方法。

使用对称私有密钥加密，发送器使用私有密钥加密数据。然后接收器使用相同的私有密钥解密该数据。对称私有密钥解密的一个缺陷在于，发送器和接收器都必须知道同一的私有密钥。这样，在发送器和接收器之间改变密钥可能导致安全的风险，这包括私有密钥的泄密或伪造的危险。

公开密钥加密是一种涉及使用密钥对的非对称加密方法。每一密钥对包括一公开密钥和一私有密钥。私有密钥的持有者能够使用私有密钥加密数据。只有对应于私有密钥的公开密钥的持有者才能够使用公开密钥解密数据。公开密钥的持有者转而能够使用公开密钥加密数据。然后被加密的数据能够安全地转发给私有密钥的持有者，因为只有私有密钥的持有者才能够解密该数据。一般，每一用户的公开密钥公布在公开密钥文件上或嵌入在证书中。这样用户的私有密钥能够保守秘密。

由于持有者的私有密钥不需要透露给任何人，因而公开密钥加密提供了比私有密钥加密提高的安全性。公开密钥加密还允许数据的接收者证实数据的来源。例如，发送器使用它们自己的秘密私有密钥加密数据。为了验证数据，接收者使用发送器的公开密钥解密数据。如果使用发送器的公开密钥消息被成功解密，则该消息必定是来源于该发送器，因为只有发送器能访问它们的私有密钥。

此外，数字签字能够提供进一步的保护级别。发送器能够使用它们自己的私有密钥通过加密数据而“签署”该数据。然后发送器能够进而使用接收者的公开密钥对数据加密而封装该签署的数据。在接收端，接收者使用它们自己的私有密钥解密封装，并然后通过进而使用发送器的公开密钥解密而验证发送器的签字。

还能够使用其它方法形成数字签字。例如，能够使用单向散列函数把数据摘要(散列)到单个的块中。单向散列函数有这样的性质，即要构成散列到该值任何数据或找出散列到同一摘要的数据模式，这在计算上是不可实行的。然后摘要能够以发送器的私有密钥加密。然后使用接收者的公开密钥作为签字，结果的加密摘要附加到已加密或未加密的数据上。在接收时，接收者使用发送器的公开密钥解密摘要。接收者还对收到的未加密的数据摘要(散列)。如果数据收到是被加密的，则首先使用接收者私有密钥对它解密，并然后使用由发送器使用的同一单向散列函数对其进行摘要(散列)。通过核对解密的摘要与接收者产生的摘要，就能够验证发送器的签字。这种类型的数字签字提供了数据完整性的验证。就是说，被发送的数据的任何修改将在接收端导致不同的摘要，并这样与发送器产的摘要比较将提供数据已被构成的指示。这种类型的数字签字还提供了原始数据的鉴别。例如，只有对应于用来验证摘要的公开密钥的私有密钥的持有者，才对数据进行了签署。

为了允许用户识别另一用户对以保证用户拥有私有密钥的方式传输数据，第一个用户必须能够从受托源获得另一用户的公开密钥。认证当局(CA)提供这种受托源。CA发出公开密钥证书。每一证书一般包含用户名和公开密钥，发出CA的名称，序列号和有效期。公开密钥证书的构架在CCITT，“X.509：The Directory：AuthenticationFramework”，April，1993(“X.509”)中定义，该文献在此结合以资对比。实际上，公开密钥证书把用户名绑定到公开密钥上并由受托发放者签署(例如CA)。一般，证书由CA当局在分发之前签署。来自用户数据的接收者能够信任签字，如果接收者识别出能够证实CA当局签字的当局公开密钥，并达到接收者信任CA的程度。

使用CA架构的一个困难在于证书不提供任何信任程度的指示，或应当对消息发送器赋予的责任级别。就是说，CA只证明标识的受托当局(CA)把发送器的公开密钥识别为属于该人。

属性证书提供了较高程度的保护。属性证书以一种方式证明数字签字，该方式向被认证方指示已被认可的当局。除了标识公开密钥和被认证方的名称之外，属性证书还包括被认可的当局级别及限制及所加的安全措施。这一信息可指示关于证书的发出。例如，信息可包括对被证实者的货币限额和/或给予被证实者的信任级别。

一般，在公司或商业环境中，对每一雇员指定一它们自己的数字证书。每一雇员可使用它们自己的公开密钥签署它们希望签署的任何文件。然后需要签署的文件的接收器验证签字人的证书没有被拒绝。这一般由接收者检验发送器公司目录证书吊销列表实现。接收者还能够通过从公司目录检索雇员属性证书而检验雇员被授权签署文件。

然而，这些传统的方法是有缺陷的。例如，常常为不同公司工作的接收者比签字者，有检验雇员授权级别的负担。这潜在地对该组织向其发送签署文件的任何人暴露了敏感的内部公司信息。例如，为了严格地检验发送器授权，接收者需要访问关于公司内谁有权签署什么文件这种潜在的敏感的公司信息。

另一限制是，在雇员离开公司时，它们的证书必须被废除。可以通过将其放置在证书废除列表(CRL)上而废除一个证书。然后文件的接收者也必须检验签署者的证书已被废除，这对接收者的任务增加了额外的责任，并对接收者提供了附加的潜在敏感的公司内部信息。

概述

一种数字签字系统包括一保有访问控制规则的数据库，这些规则识别授权用户被允许对其进行电子签字的文件，并且签字系统能够接收来自多个授权用户的签字请求，每一签字请求包括一待签字的文件。签字系统分析待签字的文件，并比较由此获得的信息与存储在数据库中的访问控制规则，以确定授权用户是否被授权对文件签字。如果确定授权用户被授权对文件签字，则签字系统使用签字系统唯一的鉴定信息对文件签字。

访问控制规则可识别每一用户被授权对其签字的文件的类型的和属性至少之一，且签字系统可分析待签字的文件以确定文件的类型和属性至少之一，并比较所确定的文件类型和属性与存储在数据库中的访问控制规则，以确定用户是否被授权对文件签字。

请求可进一步包括请求用户唯一的用户鉴定信息，其中签字系统通过用户鉴定信息鉴定用户，并除非用户得到证实否则不对文件进行分析。用户鉴定信息可包括带有对应的公开密钥和私有密钥数字证书。数字证书可包括一X-509证书。

该系统可进而包括一电子邮件接口，其中签字请求是从定址用户到签字系统的电子邮件的形式，且用户鉴定信息可包括用户电子邮件地址。该签字系统可通过比较用户电子邮件与存储在数据库中的电子邮件地址而鉴定用户。

还公开了使用签字系统的一种数字签字文件方法，并包括存储访问控制规则，这些规则识别授权用户被允许对其进行电子签字的文件，从至少一个用户接收签字请求，签字请求包括待签字的文件，并确定用户是否被授权对文件签字。如果用户已被授权，则对待签字的文件进行分析。比较通过分析获得的信息与存储的访问控制规则，以确定授权用户是否被授权对附加的文件进行签字，并如果确定授权用户被授权对附加文件进行签字，则使用签字系统唯一的鉴定信息对文件进行签字。

附图的简要说明

通过联系附图相考虑参照以下详细说明，易于获得对本系统和方法及其许多附加优点更完全的领会并会有更好的理解，其中：

图1是根据一实施例的签字系统的框图；

图2A是根据另一实施例签字系统的一框图而2B是一功能图；

图3是根据一实施例用于描述提供数字签字的方法的流程图；

图4是根据另一实施例的数字签字系统的功能图；

图5是用于描述根据图4所示的实施例提供数字签字方法的流程图；

图6是根据一实施例用于描述数据库中存储的信息类型的一表；

图7是根据一实施例用于描述数据库中存储的信息类型的一表；

图8是根据一实施例用于描述数字认证当局的一框图；

图9是根据一实施例示出检查日志的图表；

图10是根据一实施例使用的电子邮件的例子。

详细说明

在描述附图所示的优选实施例中，为了简略采用特定的术语。然而，本系统和方法不是要限于所选的这些特定的术语，并应当理解，每一特定的元件包含以类似的方式操作的所有技术等价物。

根据实施例用于签字文件的系统示于图1。该系统包括一签字系统100，用于使用与签字系统100唯一相关的证书或所私有密钥电子签字文件，以及签字策略数据库100a，该数据库存储指示每一授权用户被允许对其签字的文件的类型和属性的信息。至少一个签字请求者102a-102n由签字系统100授权通过签字系统100对特定文件签字。每一请求者102a-102n可提交一请求以便对任何它们希望的文件签字。然而，签字系统100将只对请求者被授权对其签字的那些文件签字，例如，请求者将准备一请求以便对一文件签字，并与该文件向签字系统100一同转发该请求。签字系统100将分析该文件以确定其类型和属性。

文件分析涉及例如使用词法分析和/或其它技术，把文件分隔为记号或词，并然后识别记号或词的模式。例如XML文件可分解为开始标志，结束标志，注释，元素等等。例如一个XML发票可以一组有效的开始和结束标志，与标志相关的属性，及对包含在文件内的元素约束刻画。当分析一文件时，签字系统例如将确定文件是否是一有效XML文件。如果是一有效XML文件，这时该系统将确定该文件是否是一有效XML发票。该系统识别文件的属性(例如总量＝＄1,000)。然后该系统比较这一信息与规定的文件类型。例如这种情形下，发票可分类为“ $2,500以下的发票”。当然，也可使用其它文件类型。

然后签字系统100比较文件类型和属性与存储在其数据库100a中的信息，以确定请求者是否被授权对文件签字。如果请求者被授权对文件签字，则签字系统100使用其自身唯一的签字证书对文件签字。然后签字的文件转发到意向的接收者或多个接收者103b-103n。然后签字的文件接收者必须检验签字系统的签字证书没有被吊销。这样采用签字系统100，检验每一签字者的授权级别的责任能够保持在它所属的业务或机构内。这减少了签字文件减少者的工作。此外，公司内部信息不会没有必要地暴露给外部人，并在雇员离开机构时，公司之外没有明显可见的影响。

现在将参照图2A和2B更为详细地说明根据实施例的签字系统。图2A以框图的形式示出该系统，且图2B以功能的形式示出该系统。根据这一实施例的签字系统包括文件签字服务器(DSS)2，安全核查服务器(SAS)4及文件验证服务器(DVS)6。DSS 2，SAS 4及DVS6这里统称为签字系统1，并如图2A所示每一个装设在网络9上。如图2B所示，DSS 2，SAS 4及DVS 6每一个包括一安全应用程序接口(API)，该接口允许服务器与请求者8和管理员12之间安全通信。

虽然这实施例中网络9是作为局域网(LAN)描述的，但应当理解，网络9例如可以由广域网(WAN)或其它类型的网络诸如因特网代替。为了提供更大程度的安全性，服务器2-6可装设在分开的安全LAN上，该局域网例如通过安全路由器连接到一个或多个LAN或因特网。而且连接到为了9的还有允许管理员访问一个或多个服务器2-6的一个或多个管理员工作站或终端5。虽然未示出，但每一服务器2-6可包括一调制解调器或其它类型的通信系统，以允许由授权人员进行远程访问。网络9还可有与其连接的用户工作站或终端7，它们允许雇员或其它授权人员(请求者)访问签字系统100，以便请求文件签字和/或允许签字的文件由签字系统1验证。每一工作站或终端5，7例如可由个人计算机组成。如图2B所示，每一用户工作站或终端7可包括一个或多个图形用户接口(GUI)25，提供一个或多个请求者8a-8n与签字系统100之间的用户友好界面。此外，运行在工作站或终端7上的其它应用程序19可使用安全API对文件签字。每一管理员工作站或终端5可包括一或多个GUI 26，提供一个或多个管理员12a-12n和签字系统1之间用户友好界面。

根据这一实施例用于获得签字的方法和系统可在一机构范围环境中实现，使得需要数字签字的所有文件由签字系统1签字。例如，一公司能够实现一种策略，使得签字系统1对所有需要电子签字的文件签字。在这一实施例中，每一请求者8a-8n代表公司X的一个雇员。当然，请求者也可以包括由公司X授权对公司文件签字的非雇员。

签字系统1包括一签字策略数据库14，该数据库定义每一授权人被允许签署的文件的类型和/或属性。每一请求者8a-8n能够请求签字系统签署它们希望签署的任何文件。然而，签字系统1将只签署请求者被签署可签署的那些文件。例如，请求者8a可使用在终端7处的签字请求GUI 17准备请求待签字的文件。然后可使用请求者自己的证书10a封装包括待签字的文件的该请求，并通过安全API 2a向DSS 2发送。DSS 2将分析以确定其类型和属性，并可根据预定的公司文件类型对文件分类。DSS 2将检索请求者被允许对其签字的文件的类型和属性。然后DSS 2对文件的类型和属性与数据库信息进行比较。如果雇员被授权可对该类型并具有那些属性的文件签字，则DSS2将只对该文件签字。如果请求者8a被授权对改文件签字，则DSS 2将使用单个的公司范围的证书27对文件签字，该证书在本实施例是X-509证书。然后DSS 2将向请求者8a返回正式签字的文件。然后请求者8a可向接收者按其现状转发该签字的文件，或者通过进一步使用请求者自己的证书(例如X-509正式10a)把签字的文件密封在电子信封中转发。在另一方式中，请求者8a在准备请求时，例如可包括接收者的电子邮件地址，并请求签字的文件在由DSS 2对该文件签字后由DSS 2直接投送到最终接收者。然后DSS 2例如可通过电子邮件把签字的文件以电子的方式直接转发到接收者。

然后接收者，一般是在公司以外的人，但这不是必要的，只需检验签署公司的签字证书27没有被吊销。例如这可通过认证当局(CA)进行。一般，只有当私有密钥已被损毁时，签字系统的证书才被吊销。这时签字文件的接收者知道文件原发者已按公司X的签字策略被授权对文件签字，否则签字系统1将不对文件签字。

使用签字系统1，检验每一签字者的授权级别的责任保持在它所属的业务或机构内。这减少了签字文件接收者的工作量。此外，公司内部信息不会不必要地暴露给外人，并在雇员离开公司时，公司之外可不到明显的影响。

如上所述，系统的签字策略策略存储在签字策略数据库14中。又如上所述，例如策略定义了允许谁对特定的文件类型签字。例如，策略可限制每一请求者可签署的特定的文件类型(合同，报价，标书，公司内部文件等)。策略还可规定文件属性，用于识别每一请求者被允许签字的文件的属性。例如，策略可在请求者被允许进行签字的文件内设置报价价格限制或购买价格限制。签字策略GUI 11允许一个或单个管理员12a-12n访问系统，以便规定和修改存储在签字数据库14中的签字策略。

图6描绘了可存储在数据库14中的信息类型的一例。如例子中所示，每一雇员有一授权限制及购买类型限制，规定了每一请求者被允许进行签字的文件属性的限制。还对每一请求者限制它们被允许进行签字的文件类型(例如合同，报价，标书等)。虽然图6只描述了公司X的一个部门，但数据库14可对公司的每一授权签署文件的雇员存储信息，指示它们可签署的文件类型和属性。在这例子中，每一雇员将只被允许对总购买额小于它们的授权限制，并只对于它们被授权购买的特定的项目类型的文件签字。而且如果文件的类型是它们被授权的类型，则每一雇员才将被允许对文件签字。当然，签字策略数据库可包括识别其它文件类型和属性的信息。

返回图2B，文件验证GUI 23可由请求者8用来请求签字系统1验证一签字的文件。就是说，如果请求者8接收一签字的文件，则请求者可把该签字的文件转发给签字系统1以便对其验证。DVS 6负责响应请求验证签字的文件。DVS 6将分析文件，确定文件的类型和属性，确定文件是否已不签字，并如果已签字，则签字是否有效。DVS6将构成在文件中发现的属性及它们的值的一列表，并然后这一信息可返回请求者。

如以下更为详细的描述，SAS 4保持所有由DSS 2和DVS 6执行的被请求的事务处理的记录。请求者8可使用文件历史GUI 21从SAS 4请求关于签字文件的信息。例如，请求者可请求先前布放的签字请求的状态，以便确定签字的文件是否以及何时被发送到接收者。SAS 4能够响应授权请求查看并搜索其记录，并对请求者提供适当的响应。网络增加安全性，记录可被数字签字并且是防篡改的，使得未经授权方不能对其访问。

现在参照图3中所示的流程图说明签字系统1的一实施例的整个操作。例如对一机构内每一雇员(请求者)赋予一数字证书，这种证书使用任何可用的公开密钥基础结构(PKI)系统产生。就此实施例，对每一雇员提供一X-509证书。在步骤S20，例如请求者8a使用签字请求GUI 17准备一个对DSS 2的请求。例如，签字请求GUI 17可提示请求者为准备该请求所必须的的特定的输入。例如请求可以是请求由DSS 2对特定项目以特定价值购货订单的签字。请求将包括待签字文件(购货订单)的拷贝。然后请求者使用他们自己的证书签署该请求(步骤S22)，并通过安全API 2a把已签字的请求转发给DSS 2(步骤S24)。在收到请求时，DSS 2的数据库14检索请求者的公开密钥并鉴定请求(步骤S26)。如果请求没有鉴定有效(No，步骤S28)，则向请求者提供通知，其请求未能鉴定有效(步骤S30)，且处理结束。这时还可向SAS 4通知，该请求未鉴定有效，使得能够保持一失败请求的记录。如果请求成功鉴定(Yes，步骤S28)，则DSS 2分析待签字的文件以确定其类型和属性(步骤S32)。然后DSS 2比较文件类型与属性与存储在数据库14中的请求者的授权限制(步骤S33)，以确定请求者是否被授权可对请求的文件签字。如果请求者没有授权对请求的文件签字(No，步骤S34)，则就此通知请求者与SAS 4(步骤S32)，且过程结束。如果请求者被授权(Yes，步骤S34)，则DSS 2使用其自身的私有密钥27对文件签字(步骤S38)。然后签字的文件按请求返回给请求者或直接转发给接收者(步骤S40)。还可以通知SAS 4文件已成功签字。如果请求者请求签字的文件返回请求者，则签字的文件不直接到最终接收者，而是返回到请求者。然后请求者可按其现状把文件发送给最终接收者，或者进而使用他们的私有密钥将其封装(例如在电子信封中)，并然后将封装的文件转发给最终接收者。在接收时，如在以下进一步说明，最终接收者使用发送者的公开密钥打开封装，并使用DSS 2的公开密钥鉴定文件。另一方面，如果签字的文件从签字系统1直接发送到接收者，则可使用DSS 2的公开密钥鉴定文件。

除了使用证书之外还可以其它方式识别和授权雇员(请求者)。例如图4描绘了另一实施例，其中通过他们的电子邮件地址识别和授权每一雇员30a-30n。雇员准备如图10所示的电子邮件请求。电子邮件请求包括“DATE”字段，含有由雇员发送的电子邮件日期。电子邮件请求还包含提供用来识别电子邮件的信息的“MESSAGE-ID”字段。“FROM”字段是与发送电子邮件请求的雇员唯一相关的电子邮件地址，并能够用来识别该雇员。“TO”字段是DSS 42的电子邮件地址。“SUBJECT”字段一般用来提供电子邮件中主题事项的快速识别。根据这一实施例，例如电子邮件的“SUBJECT”字段可包括一预定的短语诸如“SUGNATURE REQUEST”，标识这一电子邮件`是作为签字请求。字段“MESSAGE”可以是向DSS 42提供附加信息的消息，例如包括在签字并提供接收者的电子邮件地址之后电子邮件直接向接收者转发的请求。在另一方式中，“MESSAGE”字段可请求签字的文件返回雇员请求者。待签字的文件作为文件附加附加在电子邮件。

在收到电子邮件后，DSS 42分析电子邮件的“SUBJECT”字段，将其识别为签字请求，并提供他们的电子邮件地址识别请求者。DSS 42还分析已经请求的“MESSAGE”字段，确定签字的文件是要直接转发到接收者，并存储接收者的电子邮件地址供后来参照。然后DSS 42下载并分析附加的文件。使用存储在数据库31中的签字策略，DSS 42确定雇员是否被授权对请求的文件签字。如果雇员被授权，则DSS 42使用系统的私有签字密钥47签署文件。然后DSS 42准备一电子邮件，附加签字的文件，向并向在接收者电子邮件地址的接收者转发签字的文件。当然，如果请求是要把签字文件返回给雇员请求者，则签字的文件可电邮回在请求的“FROM”字段中指示的雇员的电子邮件地址。雇员还可从SAS 44使用电子邮件检索关于签字文件的信息，并通过DVS 46验证签字文件。

图5是一流程图，描绘了图4所示系统的整个操作。在步骤S60，雇员准备向DSS 42请求对文件签字的一个电子邮件。该电子邮件可把待签字的文件包括作为附件。该电子邮件，通过将其指向与DSS 42相关的唯一的电子邮件地址，由雇员转发到DSS 42(步骤S62)。在接收时，DSS 42比较请求如电子邮件的“FROM”字段中所示的请求者的电子邮件地址，与存储在数据库31中其存储的电子邮件地址数据库(步骤S64)。存储在数据库31中的信息类型的一例如图7所示。该数据库包括每一授权雇员的电子邮件地址，以及每一雇员授权签字的文件类型和属性。如果请求者的电子邮件地址不能与数据库中的雇员匹配(No，步骤S66)，因而向请求者的电子邮件地址通知返回通知，例如指示他们没有被授权使用该系统(步骤S68)。还可向SAS 44通知授权被拒绝，记录请求的时间，电子邮件请求的message-id，请求者的电子邮件地址等。然后处理结束。如果雇员的电子邮件地址存储在数据库中，雇员被授权使用该系统对文件签字(Yes，步骤S66)。DSS 42从电子邮件附件下载待签字的文件(步骤S70)。然后DSS 42分析文件以确定其类型和属性(步骤S72)。DSS 42对于从数据库31检索的雇员，比较文件类型和属性与授权文件类型和属性(步骤S74)，以确定雇员是否被授权对文件签字。如果雇员没有授权对文件签字(No，步骤S76)，则雇员被拒绝(步骤S78)。还向SAS 44提供通知。然后该处理结束。如果雇员被授权(Yes，步骤S76)，则DSS 42使用其证书对文件签字(步骤S80)。然后DSS 42可准备一个致雇员或接收者的电子邮件(步骤S82)，并按所作的请求把签字的文件电邮回雇员或接收者(步骤S82)。如果返回到雇员，则雇员负责把签字的文件正式转发到接收者。

虽然以上是以分开的实施例表示的，但对于图2A与2B所述的请求者的证书鉴定，以及对于图4所述的请求者电子邮件鉴定，可以在一个系统中实现。这样，取决于用来转发请求的系统类型，系统可通过他们的证书或他们的电子邮件地址鉴定请求者。例如，如果雇员离开办公室且不能访问包含适当的GUI的终端，则雇员仍然可通过电子邮件访问该系统。

图8描绘了用于向机构、公司等提供数字证书，供通过他们的数字签字系统使用的一个系统。数字认证当局86起到证书当局的作用。每一公司的X509证书(80，82，84)存储在数字证书当局86的目录88中。在数字证书当局86处还提供了证书吊销列表90。每一公司X，Y和Z与数字证书当局86有合同与协议，使公司承兑他们的数字签字文件。如果合同或协议过期，或如果公司密钥已经被破坏，则公司的证书被吊销，并添加到证书吊销列表90中。然后将需要向公司发放新的证书。

在接收数字签字文件时，接收者与数字证书当局86联系，其中检查证书吊销列表90以确定发送公司的证书是否已吊销。如果没有被吊销，则向接收者提供公司的公开密钥，这样使接收的文件由接收者打开。如果文件被发送到接收者，也使用发送公司自己的证书密封，则接收者从当局86或发放雇员证书的适当的当局获得发送雇员的公开密钥。然后接收者使用雇员的公开密钥开封签字文件，并然后与数字证书当局86联系，检查吊销列表以确定公司的DSS证书27是否已被吊销，并获得公司的公开密钥。然后接收者可打开签字文件。

再来参见图2B，对每一管理员12可提供X509证书。然后当对系统进行维护时，当进行系统的核查时，使用他们的X509证书鉴定每一管理员。可在签字系统1中提供一数据库(未示出)，该数据库指示每一管理员对系统各范围访问的级别。例如，可赋予一管理员访问安全核查服务器18，并拒绝对DVS 8和DSS 2的访问，同时赋予另一管理员对整个系统的访问。除了签字策略GUI 11之外，供管理员使用的GUI可包括文件类型GUI 15。GUI 15显示预定文件级别的列表(例如文本，HTML，XML，CSV等)，每一级别有数个规定的属性。管理员12可通过选择一文件级别并规定文件类型的名称而生成文件类型。与文件级别相关的属性可被显示，允许管理员规定对于特定的属性可允许的值和/或值的范围。管理员还可在文件类型的文件中规定特定的属性是否被允许，需要，或禁止。在所有信息已被规定文件类型之后，管理员可指令签字系统1生成文件类型。管理员还可使用提供管理员对SAS 4的安全访问的安全核查GUI 13。

如上所述，所有请求和结果能够由SAS 4记录。存储的记录例如可包含访问系统方的名称，被请求的行动的类型，请求的结果，请求拒绝的原因及请求的日期。SAS 4还可维护所有由系统签字的文件的档案。图9示出核查记录单一部分的一例，改记录单可由有适当授权的管理员从SAS 4检索。核查记录单可由管理员例如按日期，按请求者名称，按文件ID或按文件类型汇编和检索。如图9所示的事务处理记录例如可包括请求行动方的名称，所请求的行动，指示请求是被拒绝还是接受的结果，拒绝的原因及活动的日期。当然，各种其它类型的信息也可被记录。例如，请求者的部门，请求的授权量/类型，电子邮件请求Message-Id等可被记录，供定期查看或核查之用。

应当看到，虽然以上实施例，是通过对那些待签字的文件比较授权文件类型和属性，作为确定请求者是否被授权对文件签字而描述的，但可以有变形。例如，可能希望这样配置系统，使得除了具有文件签字服务器数据库中列出的类型和属性的文件之外，雇员被授权签署有任何属性的任何类型的文件。换言之，数据库能够配置为包括请求者不被允许签署的文件。

可使用按本说明书原理编程的一个或多个传统的通用数字计算机和/或服务器，方便地实现上述系统。由熟练的程序员基于本说明书的原理，可易于准备适当的软件编码。所述的系统还可通过准备应用程序专用的集成电路，或通过互连传统部件电路的适用的网络实现。

就上述技术而言可以有所述系统许多另外的修改和变形。因而应当理解，在所附权利要求范围内，这些系统可按与这里具体所述不同的方式实施。

Claims (39)

1.一种数字签字系统，包括：

一个保有访问控制规则的数据库，这些规则识别授权用户被允许对其进行电子签字的文件；以及

一种签字系统，能够接收来自多个授权用户的签字请求，每一签字请求包括一待签字的文件，其中所述签字系统分析待签字的文件，并比较由此获得的信息与存储在数据库中的访问控制规则，以确定授权用户是否被授权对文件签字，并其中如果确定授权用户被授权对文件签字，则签字系统使用签字系统唯一的鉴定信息对文件签字。

2.如权利要求1所述的数字签字系统，其中访问控制规则识别每一用户被授权对其签字的文件的类型的和属性至少之一。

3.如权利要求2所述的数字签字系统，其中签字系统分析待签字的文件以确定文件的类型和属性至少之一，并比较所确定的文件类型和属性与存储在数据库中的访问控制规则，以确定用户是否被授权对文件签字。

4.如权利要求1所述的数字签字系统，其中请求进一步包括请求用户唯一的用户鉴定信息，且其中签字系统通过用户鉴定信息鉴定用户，并除非用户得到证实否则不对文件进行分析。

5.如权利要求4所述的数字签字系统，其中所述用户鉴定信息包括带有对应的公开密钥和私有密钥的数字证书。

6.如权利要求5所述的数字签字系统，其中数字证书包括一X-509证书。

7.如权利要求4所述的数字签字系统，还包括一电子邮件接口，其中签字请求是从定址用户到签字系统的电子邮件的形式。

8.如权利要求7所述的数字签字系统，其中所述用户鉴定信息包括用户电子邮件地址。

9.如权利要求8所述的数字签字系统，其中签字系统通过比较用户电子邮件地址与存储在数据库中的电子邮件地址而鉴定用户。

10.如权利要求1所述的数字签字系统，还包括文件验证服务器，该服务器能够从请求待验证的签字文件用户接收文件验证请求，并响应该请求确定签字的文件是否有效。

11.如权利要求1所述的数字签字系统，其中在文件验证服务器对文件签字之后，签字的文件以电子的方式转发到用户，使得用户能够把签字的文件转发到接收者。

12.如权利要求1所述的数字签字系统，其中在文件签字之后，签字的文件电邮给用户。

13.如权利要求1所述的数字签字系统，其中在文件签字之后，签字的文件自动以电子方式转发给接收者。

14.如权利要求13所述的数字签字系统，其中签字文件电邮给接收者。

15.使用签字系统的一种数字签字文件的方法，包括：

存储访问控制规则，这些规则识别授权用户被允许对其进行电子签字的文件；

从至少一个用户接收签字请求，签字请求包括待签字的文件；

确定用户是否被授权对文件签字；

如果用户已被授权，则分析待签字的文件；

比较通过分析获得的信息与存储的访问控制规则，以确定授权用户是否被授权对附加的文件进行签字；以及

如果确定授权用户被授权对附加文件进行签字，则使用签字系统唯一的鉴定信息对文件签字。

16.权利要求15中所述的方法，其中访问控制规则识别每一用户被授权对其签字的文件的类型的和属性至少之一。

17.权利要求16中所述的方法，其中分析步骤分析待签字的文件以确定文件的类型和属性至少之一，并且比较步骤比较所确定的文件类型和属性与存储在数据库中的访问控制规则，以确定用户是否被授权对文件签字。

18.权利要求15中所述的方法，其中请求进一步包括该请求用户唯一的用户鉴定信息，且其中签字系统通过用户鉴定信息鉴定用户，并除非用户得到证实否则不对文件进行分析。

19.权利要求18中所述的方法，其中所述用户鉴定信息包括带有对应的公开密钥和私有密钥的数字证书。

20.权利要求19中所述的方法，其中数字证书包括一X-509证书。

21.权利要求15中所述的方法，还包括一电子邮件接口，其中签字请求是从定址用户到签字系统的电子邮件的形式。

22.权利要求21中所述的方法，其中通过比较用户电子邮件地址与存储的对应于授权用户的电子邮件地址列表，确定用户是否是授权用户。

23.权利要求15中所述的方法，还包括以电子的方式向用户转发签字的文件，使得用户能够把签字的文件转发到接收者。

24.权利要求15中所述的方法，还包括向用户电邮签字的文件。

25.权利要求15中所述的方法，还包括以电子的方式向一最终接收者转发签字的文件。

26.权利要求25中所述的方法，其中签字的文件电邮给最终接收者。

27.一种用于数字签字文件的签字系统，包括：

存储装置，用于存储访问控制规则，这些规则识别授权用户被允许对其进行电子签字的文件；

接收装置，用于从至少一个用户接收签字请求，签字请求包括待签字的文件；

确定装置，用于确定用户是否被授权对文件签字；

分析装置，用于如果用户已被授权则分析待签字的文件；

比较装置，用于比较通过分析装置获得的信息与存储的访问控制规则，以确定授权用户是否被授权对附加的文件进行签字；以及

签字装置，用于如果确定了授权用户被授权对附加文件进行签字，则使用签字系统唯一的鉴定信息对文件签字。

28.如权利要求27所述的系统，其中访问控制规则识别每一用户被授权对其签字的文件的类型和属性至少之一。

29.如权利要求28所述的系统，其中分析装置分析待签字的文件以确定文件的类型和属性至少之一，且比较装置比较所确定的文件类型和属性与存储在数据库中的访问控制规则，以确定用户是否被授权对文件签字。

30.如权利要求27所述的系统，其中请求进一步包括该请求用户唯一的用户鉴定信息，且其中签字系统通过用户鉴定信息鉴定用户，并除非用户得到证实否则不对文件进行分析。

31.如权利要求30所述的系统，其中所述用户鉴定信息包括带有对应的公开和私有密钥的数字证书。

32.如权利要求31所述的系统，其中数字证书包括一X-509证书。

33.如权利要求27所述的系统，还包括一电子邮件接口装置，其中签字请求是从定址用户到签字系统的电子邮件的形式。

34.如权利要求33所述的系统，其中通过比较用户电子邮件地址与存储的对应于授权用户的电子邮件地址列表，通过确定装置确定用户是否是授权用户。

35.如权利要求27所述的系统，其中还包括转发装置，用于以电子的方式向用户转发签字的文件，使得用户能够把签字的文件转发到接收者。

36.如权利要求27所述的系统，还包括电邮装置，用于向用户电邮签字的文件。

37.如权利要求27所述的系统，还包括用于以电子的方式向一最终接收者转发签字的文件的装置。

38.如权利要求37所述的系统，其中签字的文件电邮给最终接收者。

39.一种数字签字系统，包括：

数据库装置，用于保有访问控制规则，这些规则识别授权用户被允许对其进行电子签字的文件；以及

签字装置，能够接收来自多个授权用户的签字请求，每一签字请求包括一待签字的文件，其中所述签字装置分析待签字的文件，并比较由此获得的信息与存储在所述数据库中的访问控制规则，以确定授权用户是否被授权对文件签字，并其中如果确定授权用户被授权对文件签字，则签字装置使用签字装置唯一的授权信息对文件签字。

Images