专利名称：一种电子签名的身份验证方法
技术领域：
本发明涉及电子签名领域，尤其涉及一种电子签名的身份验证方法。
背景技术：
现有数字签名的过程为首先，将待签名文件按双方约定的哈希算法计算得到一段代码，即数字摘要，在数学上保证，只要改动报文中任何一位，重新计算出的数字摘要值就会与原先的值不相符，这样就保证了待签名文件的不可更改性；其次，将该数字摘要值用发送者的私人密钥加密，然后连同原待签名文件一起发送给接收者，而产生的数字摘要即称数字签名；最后，接收方收到数字签名后，用同样的哈希算法对报文计算摘要值，然后与用发送者的公开密钥进行解密解开的报文摘要值相比较，如相等则说明报文确实来自所称的发送者。
可见，在上述的过程中，签名人的身份是否被盗用，或者说对所述待签名文件进行电子签名的签名者是否就是该签名的本人，这一点上述过程无法保证，即无法保证该签名文件所生成的签名人就是该对该签名文件进行签名人，也就是无法保证签名人的唯一性。这是因为，在上述的签名体系中，签名者的身份只在申请数字证书时才被验证，而数字证书和公私钥都是是一串数字符号，不太可能被记忆，因此，一般只能保存在磁盘上，而这就存在证书被盗的可能，因而也就出现身份被冒用进行签名的可能。
所以，现有的电子签名体系无法解决身份被冒用的问题。另外，从数字签名技术也无法得知是否一个数字签名是在签名人神志清醒时进行的，是否是在被胁迫下进行的和是否是由其他人代签。这些疑问均可导致电子签名的法律效力上的缺陷。因此，亟待出现一种能够对签名者的真实身份和真实签名意愿进行验证的方法。
发明内容
本发明要解决的技术问题在于提供一种对电子签名的签名用户的身份的真实性进行验证的方法。
为了解决上述问题，本发明提出了一种电子签名的身份验证方法，其包括以下步骤
a、服务器向接收方发出确认请求；b、接收方根据所述确认请求进行验证并产生验证结果；c、服务器根据所述验证结果确定是否为真实签名。
其中，所述步骤a具体为根据预留方式向电子签名的签名用户发出确认请求。
优选的，所述预留方式包括以下方式中的至少一种电子邮件、固定电话、移动电话、互联网即时通讯工具、人工方式。
其中，步骤b具体为所述签名用户根据所述确认请求对所述电子签名的真实性进行验证并产生肯定或否定的验证结果。
优选的，所述确认请求至少包括下述信息中的一种签名时间、签名地点、签名文件标题、签名文件摘要、所述签名文件唯一性标识。
另外，所述确认请求为对所述电子签名的身份验证通知，其发送至验证人员。
其中，步骤b具体为所述验证人员根据所述验证通知进行验证并产生肯定或否定的验证结果。
优选的，所述验证人员至少按照下述各种方式中的一种进行验证人工电话验证、人工移动电话验证、生物样本验证。
优选的，所述验证通知至少包括下述信息中的一种签名时间、签名地点、签名文件标题、签名文件摘要、所述签名文件唯一性标识。
其中，步骤c具体为若步骤b产生肯定的验证结果，则认为所述电子签名为有效签名；若步骤b产生否定的验证结果，则认为所述电子签名为无效签名。
实施本发明能够实现对电子签名的用户的身份的真实性的验证，而且确定是否是所述签名的签名者的真实意愿的签名，以确保签名的真实性即签名人的唯一性。
图1是本发明所基于的系统的一个实施例的网络结构框图；图2是基于图1所示的网络结构的工作过程的一个实施例的流程图；图3是图2中步骤20的具体注册过程的一个实施例的流程图；图4是图2中步骤21的具体电子签名过程的一个实施例的流程图；图5是目标签名页添加边框的示意图；图6是添加签名信息后的签名页的示意图；
图7是图2中步骤21的具体电子签名过程的另一个实施例的流程图；图8是图2中步骤22的具体验证过程的一个实施例的流程图；图9是图2中步骤22的具体验证过程的另一个实施例的流程图；图10是图2中步骤22的具体验证过程的再一个实施例的流程图；图11是图2中步骤21的具体电子签名过程的再一个实施例的流程图。
具体实施例方式
下面将结合附图系统地阐述本发明的整个过程。
参考图1，图示了本发明所基于的系统的一个实施例的网络结构框图。如图所示，本实施例中所述系统采用SOA(Service Oriented Architecture，面向服务架构)网络架构实现，其具体包括客户端10，用于根据用户的要求对待签名文件进行电子签名，并进行用户注册过程。；服务器11，用于根据客户端10的请求提供签名信息，并接收包括已签名文件及相关信息的文件记录，同时在注册过程中收集用户信息，以及完成身份验证的过程；数据库12，用于存储服务器11所接收的包括已签名的文件及相关信息的文件记录，以及客户端用户资料。
其中，服务器11首先通过注册过程13收集客户端10的用户资料并存储于数据库12中，所述用户资料包括身份验证信息及用户登记信息，该用户登记信息包括客户端登陆用户名、登陆密码，所述身份验证信息包括能够唯一确定该登记用户的信息，例如该用户对某问题的唯一答案、身份证号码、手印或其它生物样本等信息，还包括用户的联系信息，例如电话号码、手机号码、电子邮件地址等，或者还包括另一个只在身份验证时用到的验证密码等。其中，所述服务器10与客户端11之间可以采用以太网连接通信，例如国际互联网等，或采用无线通信方式通信，例如GPRS(Gerneral Packer Radio Service，通用无线分组业务)数据传输方式等。
参考图2，图示了基于图1所示的网络结构的工作过程的一个实施例的流程图。如图所示，包括以下步骤步骤20，客户端用户向服务器端的系统管理员进行注册登记；步骤21，客户端根据用户需求对待签名文件进行电子签名并将相关文件记录上传至服务器端的数据库中保存；步骤22，服务器端对客户端签名用户的身份进行验证；
步骤23，结束整个工作过程。
参考图3，图示了图2中步骤20的具体注册过程的一个实施例的流程图。在本实施例中采用客户端用户登录服务器的WEB注册页面进行注册操作的方式。如图所示，包括以下步骤步骤201，客户端用户发出注册请求；即客户端用户向服务器端的系统管理员发起注册请求，请求方式不仅可以采用WEB的表单的形式向所述系统管理员所在的主机发送请求，也可以采用人工的通过电子邮件的方式等；步骤202，服务器端系统管理员接受所述请求并通知所述客户端用户发送个人资料；所述的个人资料包括用户身份验证信息及用户登记信息，该用户登记信息包括用于客户端登陆的用户名、相应的登陆密码，所述身份验证信息包括能够唯一确定该登记用户的信息，例如身份证号码、手印或其它生物样本(例如声音片断)等信息，还包括用户的联系信息，例如电话号码、手机号码、电子邮件地址等，或者还包括另一个只在身份验证时用到的验证密码等。
步骤203，客户端用户收到所述系统管理员发出的上载个人资料的通知后便按照所述个人资料的需求发送个人资料至系统管理员；步骤204，系统管理员收到所述个人资料后，判断所述的个人资料有无非法资料；例如，身份证号码、手机号码、电子邮件地址是否符合规定，是否与已登记的用户的个人资料有冲突，手印、声音片断等生物样本资料是否清晰清楚符合要求，以及判断该用户的是否是该系统所面向的用户，例如对一个企业来说，则判断该用户是否是企业的员工，或者判断该用户的权限是否符合要求等等；若合法则执行步骤205，否则执行步骤207；步骤205，为该客户端用户创建用户名、初始登陆密码并将其发送至客户端用户。这里为了安全的原因，可以采用电子邮件的方式，或者手机短信的方式发送至用户，或者仍然采用WEB方式发送；步骤206，将所述客户端用户的个人资料及步骤205中创建的用户名及密码存储至服务器端的数据库的对应字段中，然后执行步骤208。
步骤207，结束注册过程并向客户端用户报错。即结束本次注册，并将出错原因发送至用户；这一点类似于电子邮件帐号的注册过程出现错误时的报错方式；步骤208，该客户端用户的本次注册过程结束。
上述实施例只是采用了WEB注册的方式，这里还可以采用Email注册的方式，或者通过客户端的注册界面进行注册的方式等，本发明不限于此。
参考图4，图示了图2中步骤21的具体电子签名过程的一个实施例的流程图。在阐述本实施例之前，首先描述两种电子签名的含义真实图像框签，是指签名页与签名信息及相应的边框作为一个图片被存储；虚拟图像框签，是指签名页与签名信息被分开存储，并不合成为一个图片进行存储，这样最大的好处是可以节省存储空间。
本实施例中以待签名文件为文本格式，并以其一部分或全部转换为图片格式作为目标签名页为例进行说明，这种签名方式实际上为真实图像框签的一种情况。如图所示，包括以下步骤步骤210，获得待签名文件。所述待签名文件是指需要进行签名操作的文档，例如公文、审批单等等，获得这些待签名文件的方法可以通过网络下载相关的文件，或者签名者本人自行输入文字或图像材料等等。
步骤211，生成目标签名页。因为待签名文件为文本格式，因此将所述待签名文件在屏幕上显示，并利用截屏工具将所述的文本格式的待签名文件转换为图片格式作为目标签名页，若所述文本格式的待签名文件无法在屏幕上一屏完全显示，可以通过多次截屏并将截屏后的图片合成的方式来生成一个完整的目标签名页，或者如果还有其他已存储的图片文件可以打开该文件并将其与所截取的图片合成为目标签名页，或者也可以仅选取所述待签名文件的一部分转换为图片格式作为目标签名页，剩余部分与所述目标签名页合并作为目标签名文件；其中，将多个图片合成为一个图片的技术可以通过简单2D图像处理工具合成(客户端程序提供了2D签名页图像的合成工具，用户也可选用第三方的工具例如photoshop，firework等等)，通过调用2D图形函数(例如，Java 2D图像函数库中的drawImage函数)来实现，由于是公知技术在此不进行详细的描述。
步骤212，获得签名信息。其具体过程为，首先客户端的用户通过输入用户名、密码来向服务器发出请求，请求下载所述签名信息；然后，服务器接收到所述请求并核对所述用户名和密码是否匹配，若匹配，则将签名信息下传至客户端用户；所述用户名和密码为上述注册过程中所分配，所述签名信息包括用户姓名、签名时间、签名操作所在的位置(例如所述客户端所位于的域，或者所在主机的IP地址、MAC(media access control，媒体接入控制)地址、处理器ID等)、服务器的URL(Uniform Resource Location，统一资源定位符)地址等信息；其中，所述签名操作所在的位置首先由用户所在的客户端在本地主机上获取，然后将该位置信息上传至服务器，并由服务器对所述位置信息的真伪进行验证，当然，这里也可以不进行验证。
步骤213，为目标签名页添加边框。所述的边框为在所述目标签名页周围的环形的矩形框，根据其在所述目标签名页的不同的位置又分为上边框、下边框、左边框、右边框，其中所述下边框的面积最大，具体情形可以参考图5，图中虚线框为所述的边框；当然，这仅为一个实施方式，所述各个边框的大小取决于步骤212中所获得的签名信息的多少以及下述步骤214中将所述签名信息添加至哪个边框中来决定。其中，所述边框的添加方法可以参考下面所述(假设目标签名页的的宽度为X，长度为Y)首先，使用2D图像函数工具生成一个空白图像，其宽度为X加上左右边框的宽度的2倍，其长度为Y加上上边框的宽度和下边框的宽度；所述的左右边框的宽度，上下边框的宽度可以根据需要进行设定；其次，使用2D图像函数工具按设计的位置将所述目标签名页复制到所述空白图像上；这里可以以不同图层的方式来实现，所述按设计的位置是指上一步中所定义的上、下、左、右边框的宽度；最后，生成新的目标签名页；即，可以通过合并图层的方式实现。
步骤214，将所述签名信息添加至所述边框生成签名页。客户端利用2D图像函数工具(例如，Java 2D图像函数库中的drawstring函数等)将所述签名信息以图片的形式写入所述边框中，具体可添加至下边框中，详细情形可以参考图6所示。另外，用户可以根据个人需要选择是否添加备注信息等。本步骤完成后，所述目标签名页和边框及边框上的内容即一起作为签名页。
步骤215，判断所述待签名文件有无附件，若有则执行步骤216，否则执行步骤220。
步骤216，生成目标签名文件。当步骤211中所述文本格式的待签名文件被全部转换为图片格式作为目标签名页，并最终转换为签名页时，则将所述签名页与所述附件合并一个文件作为目标签名文件；当步骤211中所述文本格式的待签名文件被部分转换为图片格式作为目标签名页，并最终转换为签名页时，则将所述签名页、剩余的所述待签名文件以及所述附件合并作为目标签名文件。其中，合并为一个文件的过程可以采用以下方法客户端程序使用ZIP(一种常用的压缩格式)工具或其自带的高级语言包(例如Java语言包)中的ZIP Library(ZIP库)将所述签名页与所述附件合并为单一的ZIP文档文件作为目标签名文件，或者是将所述附件继续添加至原来的目标签名文件的ZIP文档中。
步骤217，生成数字摘要或使用PKI(Public Key Infrastructure，公钥基础设施)技术生成数字签名。所述生成数字摘要的过程为以所述目标签名文件的二进制代码为对象利用单向加密Hash算法(哈希算法)生成一段代码，所述单向加密Hash算法(哈希算法)可以采用MD5算法、SHA-1算法等。若使用PKI数字签名，则将所述数字签名模块集成至客户端中以供调用，此时，签名用户要人工输入私钥，或事先将私钥保存在当地主机上(如U盘上)，由客户端读取，或者也可以调用外部数字签名模块进行操作。由于PKI数字签名技术是已经相当成熟的现有技术，在此不再进行进一步的阐述。
需要说明的是，由于所述目标签名文件中包含了签名信息，而该签名信息中又包括签名时间、签名操作所在的位置信息、用户姓名，而且所述签名时间信息从服务器获得，所述签名操作所在的位置信息从签名操作所在主机获得并由服务器验证、所述用户姓名也从服务器获得。因此再将包含上述签名信息的目标签名文件进行PKI(Public Key Infrastructure，公钥基础设施)数字签名，或者直接生成数字摘要，便可以保证PKI数字签名的结果以及直接生成的数字摘要具有基于所述签名时间的时间上的唯一性、具有基于所述签名操作所在位置的空间上的唯一性；并且，通过步骤22的身份验证过程可保证所述用户(即签名人)的签名人的唯一性，防止其他人顶替签名或者逼迫签名人违背其真正意志进行签名。步骤22的具体过程可以参考后续的描述。所述时间唯一性是指即使是同一用户在同一地点对同一文件进行两次签名其结果也是不一样的，因为两次签名的时间不同；所述空间唯一性是指同一用户在同一时间在不同的地点对同一文件进行签名其结果也是不同的；所述签名人唯一性是指即使是不同的用户对同一文件在同一地点、同一时间进行签名其结果是不同的，签名人唯一性本来是不应该有疑问的，但由于身份失窃和找人代签的问题，签名文件的签名人究竟是否就是所声称的签名人就存在了疑问，因此通过步骤22的身份验证过程便可以保证签名人的唯一性。
步骤218，生成文件记录。即将步骤217中所使用的签名方法(使用单向加密算法生成数字摘要，或PKI数字签名等)、签名结果(即所述数字摘要或PKI数字签名结果)以及所述目标签名文件中的内容保存至文件记录中。这里，所述的文件记录的结构可以看作数据库中的数据表的一条记录的结构，结构中包括若干不同的字段用以存储上述信息。
步骤219，上载至服务器端的数据库存储并转向步骤223执行。即将所述文件记录上载至服务器端的数据库中存储。
步骤220，生成数字摘要或使用PKI(Public Key Infrastructure，公钥基础设施)技术生成数字签名。所述生成数字摘要的过程为以所述签名页的二进制代码为对象利用单向加密Hash算法(哈希算法)生成一段代码，所述单向加密Hash算法(哈希算法)可以采用MD5算法或SHA-1算法等等。若使用PKI数字签名，则将所述数字签名模块集成至客户端中以供调用，此时，签名用户要人工输入私钥，或事先将私钥保存在当地主机上(如U盘上)，由客户端读取，或者也可以调用外部数字签名模块进行操作，。由于PKI数字签名技术是已经相当成熟的现有技术，在此不再进行进一步的阐述。
需要说明的是，由于所述签名页中包含了签名信息，而该签名信息中又包括签名时间、签名操作所在的位置信息、用户姓名，而且所述签名时间信息从服务器获得，所述签名操作所在的位置信息从签名操作所在主机获得并由服务器验证、所述用户姓名也从服务器获得。因此再将包含上述签名信息的签名页进行PKI数字签名，或者直接生成数字摘要，便可以保证PKI数字签名的结果以及直接生成的数字摘要具有基于所述签名时间的时间上的唯一性、具有基于所述签名操作所在位置的空间上的唯一性；并且，通过步骤22的身份验证过程可保证所述用户(即签名人)的签名人的唯一性，防止其他人顶替签名或者逼迫签名人违背其真正意志进行签名。步骤22的具体过程可以参考后续的描述。所述时间唯一性是指即使是同一用户在同一地点对同一文件进行两次签名其结果也是不一样的，因为两次签名的时间不同；所述空间唯一性是指同一用户在同一时间在不同的地点对同一文件进行签名其结果也是不同的；所述签名人唯一性是指即使是不同的用户对同一文件在同一地点、同一时间进行签名其结果是不同的，签名人唯一性本来是不应该有疑问的，但由于身份失窃和找人代签的问题，签名文件的签名人究竟是否就是所声称的签名人就存在了疑问，因此通过步骤22的身份验证过程便可以保证签名人的唯一性。
步骤221，生成文件记录。即将步骤220中所使用的签名方法(使用单向加密算法生成数字摘要，或PKI数字签名等)、签名结果(即所述数字摘要或PKI数字签名结果)以及所述目标签名文件中的内容保存至文件记录中，若无所述目标签名文件(即将待签名文件的一部分转换为签名页，而该待签名文件又没有附件的情况)，则将所述签名页保存至文件记录中。
步骤222，上载至服务器端的数据库存储并转向步骤223执行。即将所述文件记录上载至服务器端的数据库中存储。
步骤223，结束本次电子签名的流程。
参考图7，图示了图2中步骤21的具体电子签名过程的另一个实施例的流程图。本实施例中以待签名文件可以为音频、视频或多媒体格式，或者是文本或图片格式等，其通过用户选取任意的图片或输入文字，或者选取名片模版作为目标签名页，这种签名方式也为真实图像框签的一种。如图所示，包括以下步骤步骤2100，获得待签名文件。所述待签名文件是指需要进行签名操作的文档，例如一段音频资料或视频资料等等，获得这些待签名文件的方法可以通过网络下载相关的文件，或者签名者本人自行录入音频或视频信息等等。
步骤2101，判断有无名片模版，若有则执行步骤2102，否则执行步骤2103。其中，所述名片模版为用户事先准备的与该用户相关的信息，其可以是图片格式或是文字格式等。
步骤2102，调用所述名片模版，然后执行步骤2104。即将所述用户事先准备好的名片模版调出，可以是将其显示在屏幕上。
步骤2103，用户选取任意的图片或文字作为模版。所述的文字可以由用户直接在文档编辑窗口中输入，并显示在屏幕上。
步骤2104，生成目标签名页。无论是步骤2102中所述的名片模版，还是步骤2103中所述的用户选取的任意的图片或文字，若不是图片格式均可经过截图转换为图片格式(其具体如何实现可参考步骤211中相关信息)，并作为目标签名页，若是图片格式则直接作为目标签名页；或者，也可以直接将用户选取的任意图片或文字不转换为图片格式，直接作为目标签名页。二者最大的区别在于，若转换为图片格式，则可能会占用较大的存储空间，对于是否转换可以由签名用户决定。
步骤2105，将所述待签名文件与所述目标签名页作为目标签名文件。即，将所述待签名文件以附件的形式附属于所述目标签名页，本步骤可以通过将目标签名页与所述待签名文件打包为ZIP压缩文件来实现。
步骤2106，获得签名信息。本步骤的具体实现可以参考步骤212中的相关描述。
步骤2107，为所述目标签名页添加边框。本步骤的具体实现可以参考步骤213中的相关描述。
步骤2108，将所述签名信息添加至所述边框并生成签名页。本步骤的具体实现可以参考步骤214中的相关描述。
步骤2109，判断所述待签名文件有无附件，若有则执行步骤2110，否则执行步骤2114。
步骤2110，生成目标签名文件。即将原目标签名文件中签名页、待签名文件，以及所述附件合并为新的目标签名文件，本步骤的具体实现可以参考步骤216中的相关描述。
步骤2111，生成数字摘要或使用PKI(Public Key Infrastructure，公钥基础设施)技术生成数字签名。本步骤的具体实现可以参考步骤217中的相关描述。
步骤2112，生成文件记录。同样，本步骤的具体实现可以参考步骤218中的相关描述，。
步骤2113，上载至服务器端的数据库存储并转向步骤2117执行。即将所述文件记录上载至服务器端的数据库中存储。
步骤2114，生成数字摘要或使用PKI(Public Key Infrastructure，公钥基础设施)技术生成数字签名。本步骤的具体过程可以参考步骤220中的相关描述。
步骤2115，生成文件记录。本步骤的具体过程与实现可以参考步骤218中的相关描述。
步骤2116，上载至服务器端的数据库存储。本步骤的具体过程可以参考步骤222中的相关描述。
步骤2117，结束本次电子签名的流程。
参考图11，图示了图2中步骤21的具体电子签名过程的再一个实施例的流程图。本实施例中，所述的待签名文件可以是任何格式的文件。本实施例实际为虚拟图像框签的一种情况，如图所示，包括以下步骤步骤2300，获得待签名文件；所述待签名文件是指需要进行签名操作的文档，例如公文、审批单、音视频会议记录等等，获得这些待签名文件的方法可以通过网络下载相关的文件，或者签名者本人自行输入文字或图像材料等等。
步骤2301，判断有无名片模版，若有，则执行步骤2302，否则执行步骤2303；其中，所述名片模版为用户事先准备的与该用户相关的信息，其可以是图片格式或是文字格式等，或者是用户随机准备的信息等，本发明不受此限制。
步骤2302，调用所述名片模版，然后执行步骤2304。即将所述用户事先准备好的名片模版调出，可以是将其显示在屏幕上，例如所述客户端的窗口中。
步骤2303，用户选取任意的图片或文字作为模版。所述的文字可以由用户直接在文档编辑窗口中输入，并显示在屏幕上，例如所述客户端的窗口中。
步骤2304，将所述模版作为签名页；即，无论是名片模版还是用户临时准备的模版，都将其看作签名页；所述签名页与所述模版在本质上并无变化，本步骤是为了理解上的方便并与前文统一名称。
步骤2305，获得签名信息；本步骤的具体过程可以参考步骤213中的相关描述，在此不进行重复。
步骤2306，显示签名页和签名信息，并将所述签名页、签名信息、待签名文件作为目标签名文件；即，在得到所述签名信息后便将所述签名信息添加到所述签名页中并在屏幕上显示，具体的实现可以采用图4所示实施例中生成一个边框并将所述签名信息添加到该边框的形式，相关内容可以参考图4实施例中的相关描述。同时，将所述签名页、签名信息、待签名文件作为目标签名文件，具体可以通过ZIP压缩来实现。
本实施例与图4所示实施例的最大的不同在于，图4所示的实施例中将生成的边框及该边框上的签名信息都作为所述签名页的一部分，也就是说所述签名页是包括目标签名页、边框及签名信息的一个图像文件，其存储也是作为图像格式来存储；而本实施例中，仅是根据所述签名页和签名信息临时生成一个如步骤214中的签名页并显示于屏幕上，并且所述的签名信息不与所述签名页作为一个整体的图像文件来存储，而是分开存储。这样做可以节省存储空间，因为图片格式的签名页将占用较大的存储空间。
步骤2307，判断所述待签名文件有无附件，若有，则执行步骤2308，否则执行步骤2312；步骤2308，生成目标签名文件；即将原目标签名文件中签名页、签名信息、待签名文件，以及所述附件合并为新的目标签名文件，本步骤的具体实现可以参考步骤216中的相关描述。
步骤2309，生成数字摘要或PKI数字签名；所述生成数字摘要的过程为以所述目标签名文件的二进制代码为对象利用单向加密Hash算法(哈希算法)生成一段代码，所述单向加密Hash算法(哈希算法)可以采用MD5算法或SHA-1算法等等。若使用PKI数字签名，则将所述数字签名模块集成至客户端中以供调用，此时，签名用户要人工输入私钥，或事先将私钥保存在当地主机上(如U盘上)，由客户端读取，或者也可以调用外部数字签名模块进行操作。由于PKI数字签名技术是已经相当成熟的现有技术，在此不再进行进一步的阐述。
需要说明的是，由于所述目标签名文件中包含了签名信息，而该签名信息中又包括签名时间、签名操作所在的位置信息、用户姓名，而且所述签名时间信息从服务器获得，所述签名操作所在的位置信息从签名操作所在主机获得并由服务器验证、所述用户姓名也从服务器获得。因此再将包含上述签名信息的目标签名文件进行PKI数字签名，或者直接生成数字摘要，便可以保证PKI数字签名的结果以及直接生成的数字摘要具有基于所述签名时间的时间上的唯一性、具有基于所述签名操作所在位置的空间上的唯一性；并且，通过步骤22的身份验证过程可保证所述用户(即签名人)的签名人的唯一性，防止其他人顶替签名或者逼迫签名人违背其真正意志进行签名。步骤22的具体过程可以参考后续的描述。所述时间唯一性是指即使是同一用户在同一地点对同一文件进行两次签名其结果也是不一样的，因为两次签名的时间不同；所述空间唯一性是指同一用户在同一时间在不同的地点对同一文件进行签名其结果也是不同的；所述签名人唯一性是指即使是不同的用户对同一文件在同一地点、同一时间进行签名其结果是不同的，签名人唯一性本来是不应该有疑问的，但由于身份失窃和找人代签的问题，签名文件的签名人究竟是否就是所声称的签名人就存在了疑问，因此通过步骤22的身份验证过程便可以保证签名人的唯一性。
步骤2310，生成文件记录；即将步骤2309中所使用的签名方法(使用单向加密算法生成数字摘要，或PKI数字签名等)、签名结果(即所述数字摘要或PKI数字签名结果)以及所述目标签名文件中的内容保存至文件记录中。这里，所述的文件记录的结构可以看作数据库中的数据表的一条记录的结构，结构中包括若干不同的字段用以存储上述信息。
步骤2311，上载至服务器端的数据库存储并转向步骤2315执行。即将所述文件记录上载至服务器端的数据库中存储。
步骤2312，生成数字摘要或PKI数字签名；本步骤的具体过程可以参考步骤2308中的相关描述。
步骤2313，生成文件记录；本步骤的具体过程可以参考步骤2310中的相关描述。
步骤2314，上载至服务器端的数据库存储并转向步骤2315执行。即将所述文件记录上载至服务器端的数据库中存储。
步骤2315，结束本次电子签名的过程。
在图2中步骤21的具体电子签名过程的又一个实施例中，所述待签名文件为已经经过签名的文件，即该实施例具体为一种再签名的方法。下面将简要阐述这种方法第一步，要进行再签名的用户向服务器提交查询文件记录的请求。本步骤的目的在于，使该用户找到他须要进行再次签名的文件记录；第二步，服务器响应所述请求，并在所述用户的客户端显示文件记录。所述文件记录中包括签名页、附件、签名结果(数字摘要或是PKI数字签名结果)、签名方法(形成数字摘要或是PKI数字签名)，还可以包括签名信息等等；第三步，所述用户对所述文件记录进行鉴别判断是否有问题。在这里，其一是对所述电子签名的真实性进行判断，其二是所述用户判断是否同意签署该文件；对于电子签名的真实性判断，可以通过对该文件重复所述文件记录中的签名方法得到签名结果，并将所述签名结果与所述文件记录中的签名结果进行比对是否一致；第四步，若所述用户对该文件无异议，则对其进行电子签名。所述电子签名的过程相对于图4和图7所示的实施例的过程较为简单，因为这里的目标签名页即来自所述文件记录中的签名页，签名的对象还包括所述文件记录中的附件(原始的部分或全部待签名文件，以及该待签名文件的附件等)。因此，其具体过程可以参考图4中步骤212以后的过程，或图7中步骤2106以后的过程，为了避免重复，对于具体过程不作进一步阐述，这里仅就其需要注意的地方进行说明本实施例中，该进行再次签名的用户在电子签名后也需要将所述签名结果、签名方法等信息追加至所述文件记录中，对于虚拟图像框签来说，还需要将该进行再次签名的用户的签名信息追加至所述文件记录中。系统还可以为再次签名用户创建单独的文件记录，该文件记录只需要保存再签名信息和包含原始签名文件的文件记录标识号。
需要说明的是，所述的签名信息记录区域并不限于所述的边框，还可以是仅位于签名页下方的区域，可以是任意的形状，本发明不受此限制。
另外，本具体实施方式
中的进行图像合成或显示等的操作并不限于2D图像工具，还可以采用更为先进的3D图像工具等。
参考图8，图示了图2中步骤22的具体验证过程的一个实施例的流程图。如图所示，包括以下步骤步骤2210，根据预留方式发送确认请求。即服务器端接收到所述签名文件后，便根据预留的方式向所述签名的签名用户发送确认签名的请求。其中，所述预留的方式为所述注册过程20中由用户或系统管理员所提供，其至少包括下述方式中的一种电子邮件、固定电话、移动电话、互联网即时通讯工具、人工方式；所述电子邮件方式是指由服务器端向用户在注册过程20中所留下的电子邮件地址发送确认请求，所述固定电话方式是指由服务器端向用户在注册过程20中所留下的固定电话语音留言确认请求，所述移动电话方式是指由服务器端向用户在注册过程20中所留下的移动电话号码发送短信息形式的确认请求或语音留言式的确认请求，所述互联网即时通讯工具方式是指由服务器端向用户在注册过程20中所留下互联网即时通讯工具(例如OICQ、ICQ、MSN等等)的ID发出确认请求消息，所述人工方式是指由系统中的另一用户(具有身份确认权限的用户，例如系统管理员或聘请的公证员等)在注册过程20中所留下的可能的通信方式，例如打电话的方式，人工传达所述确认请求。
另外，所述确认请求中的内容至少包括下述信息中的一种签名时间、签名地点、签名文件标题、签名文件摘要、所述签名文件唯一性标识等。
步骤2211，用户收到所述确认请求。此时，用户即为所述接收方。
步骤2212，所述用户根据上一步骤中所接收的确认请求判断所述签名是否为自己真实意愿的签名。其中，所述用户可以根据所述签名文件唯一性标识(例如该文件在数据库中的记录号等等)在所述服务器端查找到所述签名文件，从而判断是否为自己真实意愿的签名，或者仅根据所述签名时间、签名地点、签名文件标题、签名文件摘要等做出判断。
若所述用户最终判断所述签名是自己真实意愿的签名，则执行步骤2215，否则执行步骤2213。
步骤2213，用户报告身份失窃。即用户向服务器端上报有人伪造签名，其可以通过电话的方式向系统管理员报告，或者通过网页表单上报等等。
步骤2214，服务器端接收到所述身份失窃的上报信息后，便将所述电子签名视为无效签名，因而对应的签名文件也不具有法律效力。本步骤后执行步骤2217。
步骤2215，所述用户上报确认所述签名。该过程可以是显式的上报，例如通过网页，或者电话等上报，或者为隐式的上报，即服务器端可以设定为若在一定的时间内没有接收到来自该用户的确认签名或否认签名的报告，则认为该用户确认所述签名为其真实意愿的签名。
步骤2216，服务器端接收到所述显式上报或推定为隐式上报后，则将所述签名视为有效签名，相应的文件也具有相应的法律效力。
步骤2217，结束本次签名的验证过程。
参考图9，图示了图2中步骤22的具体验证过程的另一个实施例的流程图。如图所示，包括以下步骤步骤2220，根据预留方式发送确认请求。即服务器端接收到所述签名文件后，便根据预留的方式向所述签名的签名用户发送确认签名的请求。其中的具体过程及实现可以参考步骤2210中的相关阐述。
步骤2221，用户收到所述确认请求。此时，用户即为所述接收方。
步骤2222，所述用户根据上一步骤中所接收的确认请求判断所述签名是否为自己真实意愿的签名，若是，则执行步骤2223，否则执行步骤2225。其中，所述用户可以根据所述签名文件唯一性标识(例如该文件在数据库中的记录号等等)在所述服务器端查找到所述签名文件，从而判断是否为自己真实意愿的签名，或者仅根据所述签名时间、签名地点、签名文件标题、签名文件摘要等做出判断。
步骤2223，用户发送验证信息。即通过上一步判断后，所述用户认为所述电子签名为自己的真实意愿的签名，则该用户可以向所述服务器端发送在所述注册过程20中留下的确认签名的验证码或是回答留下的问题等，该过程同样可以通过人工的方式和非人工的方式来实现，人工的方式可以通过直接与系统管理员进行沟通告知验证码或所述问题的答案等，非人工的方式可以通过网页表单传输验证码或所述问题的答案等。
该过程还可以是一个互动的过程，由系统自动地与签名人互动而确认签名人的身份，例如在确认请求中，签名人用户被要求登陆系统进行身份验证，用户登陆后，系统可以提示用户输入身份确认密码以便验证身份；或者系统提示用户读一段文字，系统录音采集声音样本与数据库中所储存的该用户样本相比较而确认身份。
步骤2224，服务器端判断所述验证信息是否正确，若正确，则执行步骤2226，否则执行步骤2225。对于所述验证码方式来说只需验证与注册过程预留的验证码是否一致，若一致则认为是正确的，否则反之。对于所述回答问题的方式来说，只需判断用户所提供的答案是否与注册过程中所留下的答案一致，若一致则认为是正确的，否则反之。
步骤2225，服务器端将所述电子签名视为无效，因而对应的签名文件也不具有法律效力并转向步骤2227执行。
步骤2226，服务器端将所述电子签名视为有效。
步骤2227，结束本次签名验证过程。
参考图10，图示了图2中步骤22的具体验证过程的再一个实施例的流程图。如图所示，包括以下步骤步骤2230，发送验证通知至验证人员。此过程由服务器端来完成，可以通过电话通知的方式，或电子邮件的方式等。所述验证通知至少包括下述信息中的一种签名时间、签名地点、签名文件标题、签名文件摘要、所述签名文件唯一性标识。
步骤2231，验证人员接收所述验证通知。此时，验证人员即为所述接收方。
步骤2232，所述验证人员根据所述验证通知判断所述签名是否为所述用户的真实意愿的签名，若是，则执行步骤2234，否则执行步骤2233。这里由于是人工进行验证，所以可以采用的方式很灵活，比如直接找所述用户进行面谈确认，或者亲自打电话询问，或者根据在注册过程20中所留下的生物样本(例如声音、指纹等)进行验证等等。例如，该过程可以是一个人工互动的过程，有身份确认权限的用户(例如第三方的具有公证员资格的用户)可以使用多种互动的方式进行身份确认，该用户还起到签名过程目击和公证的作用，从而使该电子签名可以满足更高的法律要求，该用户可使用本文所述的再框签过程进行电子签名而留下目击和公证记录。
步骤2233，服务器端将所述电子签名视为无效签名，因而对应的签名文件也不具有法律效力。本步骤后执行步骤2235。
步骤2234，服务器端将所述电子签名视为有效签名。
步骤2235，结束本次签名验证流程。
本具体实施方式
中接收方均为人工，但是还可以是计算机等等。
总之，不同的身份确认方式解决电子签名中的不同问题，这也是用户和系统管理员在设置身份确认方式时要考虑的。如果身份确认方式为隐式电子邮件和短信的方式，这可以解决身份失窃的问题；如果身份确认方式为显式互动的方式，不仅可以解决身份失窃的问题，而且可以确定签名人是否是自愿的或是否是在神智清醒地情况下签名，这是因为●签名人用户如果是在被胁迫下而非志愿地进行的签名和身份确认，该用户可以故意答错互动的问题或身份密码，系统会向有关系统管理员示警，系统管理员将会采取相应措施。
●签名人用户如果是在非神智清醒地情况，该用户不能答对互动中的问题●签名人用户参与身份确认并答对互动的问题，特别是包裹使用了声音样本对比方法的互动可排除由其他人代签的可能，那么该用户的身份就可得以确认，系统视签名记录为有效，该电子签名符合传统签名的所有法律要求。它除具有不可篡改性外，还具有不可抵赖性。
以上所揭露的仅为本发明一种较佳实施例而已，当然不能以此来限定本发明之权利范围，因此依本发明权利要求所作的等同变化，仍属本发明所涵盖的范围。
权利要求
1.一种电子签名的身份验证方法，其包括以下步骤a、服务器向接收方发出确认请求；b、接收方根据所述确认请求进行验证并产生验证结果；c、服务器根据所述验证结果确定是否为真实签名。
2.如权利要求1所述的方法，其特征在于，所述步骤a具体为根据预留方式向电子签名的签名用户发出确认请求。
3.如权利要求2所述的方法，其特征在于，所述预留方式包括以下方式中的至少一种电子邮件、固定电话、移动电话、互联网即时通讯工具、人工方式。
4.如权利要求2所述的方法，其特征在于，步骤b具体为所述签名用户根据所述确认请求对所述电子签名的真实性进行验证并产生肯定或否定的验证结果。
5.如权利要求1、2、3、4中任一项所述的方法，其特征在于，所述确认请求至少包括下述信息中的一种签名时间、签名地点、签名文件标题、签名文件摘要、所述签名文件唯一性标识。
6.如权利要求1所述的方法，其特征在于，所述确认请求为对所述电子签名的身份验证通知，其发送至验证人员。
7.如权利要求6所述的方法，其特征在于，步骤b具体为所述验证人员根据所述验证通知进行验证并产生肯定或否定的验证结果。
8.如权利要求7所述的方法，其特征在于，所述验证人员至少按照下述各种方式中的一种进行验证身份确认密码验证、人工电话验证、人工移动电话验证、生物样本验证。
9.如权利要求7所述的方法，其特征在于，所述验证通知至少包括下述信息中的一种签名时间、签名地点、签名文件标题、签名文件摘要、所述签名文件唯一性标识。
10.如权利要求4或7所述的方法，其特征在于，步骤c具体为若步骤b产生肯定的验证结果，则认为所述电子签名为有效签名；若步骤b产生否定的验证结果，则认为所述电子签名为无效签名。
全文摘要
本发明公开了一种电子签名的身份验证方法，其包括以下步骤a.服务器向接收方发出确认请求；b.接收方根据所述确认请求进行验证并产生验证结果；c.服务器根据所述验证结果确定是否为真实签名。实施本发明能够根据实际地需要而设计预留使用不同的方法，实现对电子签名的用户的身份的真实性的验证，从而确定是否是所述签名的签名者的身份是否失窃，是否是真实意愿的签名和是否是由其他人代签，以确保签名人身份的真实性和签名的不可抵赖性。
文档编号H04L9/32GK101090320SQ20071001686
公开日2007年12月19日 申请日期2007年7月13日 优先权日2007年7月13日
发明者王少波, 马修·梅叶 申请人:王少波