电子签名方法及装置

本说明书一个或多个实施例涉及计算机技术领域，尤其涉及一种电子签名方法及装置。

传统技术中，当多个用户针对一份相同内容的数据进行签名时，通常需要将签名原文上传到电子签名平台(一种能够协助用户管理私钥、保证电子签名过程可信、提供身份核实、过程存证等能力的第三方平台)。然而，当用户签署的数据比较敏感时，通常不希望通过网络来传输该数据。因此，需要提供一种更安全的电子签名的方案。

本说明书一个或多个实施例描述了一种电子签名方法及装置，可以提升用户体验。

第一方面，提供了一种电子签名方法，包括：

服务端接收签名业务系统发送的电子签名申请请求；所述电子签名申请请求包括参与电子签名的各个用户的用户信息；

根据所述各个用户的用户信息，获取对应的客户端的环境信息；

根据所述环境信息，向所述客户端发送签名指示；所述签名指示用于指示所述客户端获取待签名的数据，并生成对应于所述待签名的数据的摘要信息；还用于指示所述客户端通过预先申领的证书对所述摘要信息进行签名；

接收签名后的摘要信息。

第二方面，提供了一种电子签名方法，包括：

接收服务端发送的签名指示；

根据所述签名指示，获取待签名的数据；

生成对应于所述待签名的数据的第一摘要信息；

通过预先申领的证书对所述第一摘要信息进行签名；

向所述服务端返回签名后的第一摘要信息。

第三方面，提供了一种电子签名装置，包括：

接收单元，用于接收签名业务系统发送的电子签名申请请求；所述电子签名申请请求包括参与电子签名的各个用户的用户信息；

获取单元，用于根据所述各个用户的用户信息，获取对应的客户端的环境信息；

发送单元，用于根据所述获取单元获取的所述环境信息，向所述客户端发送签名指示；所述签名指示用于指示所述客户端获取待签名的数据，并生成对应于所述待签名的数据的摘要信息；还用于指示所述客户端通过预先申领的证书对所述摘要信息进行签名；

所述接收单元，还用于接收签名后的摘要信息。

第四方面，提拱了一种电子签名装置，包括：

接收单元，用于接收服务端发送的签名指示；

获取单元，用于根据所述接收单元接收的所述签名指示，获取待签名的数据；

生成单元，用于生成对应于所述获取单元获取的所述待签名的数据的第一摘要信息；

签名单元，员工与通过预先申领的证书对所述生成单元生成的所述第一摘要信息进行签名；

发送单元，用于向所述服务端返回所述签名单元签名后的第一摘要信息。

本说明书一个或多个实施例提供的电子签名方法及装置，服务端在接收到签名业务系统发送的电子签名申请请求后，根据电子签名申请请求中的参与电子签名的各个用户的用户信息，获取对应的客户端的环境信息。之后，根据客户端的环境信息，向各个用户的客户端发送签名指示。各个客户端在接收到签名指示后，获取待签名的数据，生成对应于待签名的数据的摘要信息，并通过预先申领的证书对摘要信息进行签名。最后，各个客户端将签名后的摘要信息上传到服务端。由此可以看出，本说明提供的方案中，各个客户端可以在本地针对待签名的数据进行签名，也即可以不向服务端上传待签名的数据，这可以保证待签名的数据的安全性，从而可以大大提升用户的体验。

为了更清楚地说明本说明书实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1为本说明书提供的电子签名方法的应用场景示意图；

图2为本说明书提供的证书申领方法信息交互图；

图3为说明书一个实施例提供的电子签名方法信息交互图；

图4为本说明书另一个实施例提供的电子签名方法流程图；

图5为本说明书一个实施例提供的电子签名装置示意图；

图6为本说明书另一个实施例提供的电子签名装置示意图。

下面结合附图，对本说明书提供的方案进行描述。

本说明书提供的电子签名方法可以应用于如图1所示的场景中，图1中，客户端A可以是指与用户A对应的客户端，客户端B可以是指与用户B对应的客户端。用户A与用户B可以是指参与电子签名的两个用户。在本说明书中，客户端A与客户端B的定义可以相同。以客户端A为例来说，其可以实现如下两个功能：本地电子签名和身份核实。对本地电子签名，客户端A在接收到服务端的签名指示之后，可以获取待签名的数据(也称签名原文)，并生成对应的摘要信息。之后，调用独立硬件盾或者本地端软证书对该摘要信息进行本地电子签名。对身份核实，客户端A在接收到服务端的核身指示之后，可以通过如下任意一种或者多种核身方式：短信、指纹、密码、人脸识别以及身份证号等对用户A的身份进行核实。

图1中，客户端A或者客户端B可以对外发送两类请求：客户端正常心跳请求以及证书申领请求(后续进行说明)，其余可以是被动监听服务端发送的请求(如，核身请求等)。需要说明的是，客户端A或者客户端B接收或者发送的请求可以经过所接入网络的安全网关。

图1中的服务端可以向客户端A或者客户端B发送签名指示和核身指示(也称核身请求)，其中签名指示用于指示客户端A或者客户端B对待签名的数据进行本地电子签名。此处，待签名的数据可以包括：电子形式的图片、合同以及音频文件等信息。核身指示用于指示客户端A(或者客户端B)对用户A(或者用户B)的身份进行核实。此外，服务端还可以从第三方认证机构(如，认证授权机构(Certificate Authority，CA))申请证书，请求第三方存证机构对用户想要长久保留或者风险较高的数据进行存储以及请求第三方时间戳机构对签名数据标记时间戳等等。

本说明书描述的电子签名可以是指用户通过预先申领的证书对待签名的数据的摘要信息进行签名的过程。因此，在执行本说明书描述的电子签名方法之前，参与电子签名的各个用户的客户端可以先从第三方认证机构(如，CA)申领对应的证书。

由于各个用户的客户端申领证书的过程类似，本说明书以一个用户的客户端申领证书为例来说，其证书申领(也称本地证书初始化)方法可以如图2所示。图2中，该方法可以包括如下步骤：

步骤210，客户端向服务端发送证书申领请求。

具体地，在用户在终端设备(个人电脑和/或手机)上安装客户端并输入对应的账号之后，该客户端可以向服务端发送上述证书申领请求。该证书申领请求可以包括该客户端当前的环境信息。此处的环境信息可以包括：终端设备的标识(也称设备指纹)、用户的账号和/或名称、客户端所接入网络的网关的地址以及证书类型等。对证书类型，当用户使用的是独立硬件盾，则证书类型可以为：ukey；而当用户使用的是本地端软证书，则证书类型可以为：cert。

服务端在接收到上述证书申领请求之后，可以根据该客户端的环境信息，判断当前的证书类型该用户是否可用(如，该证书类型是否归属于该用户以及该证书类型是否能够下载证书等等)。此外，还可以结合环境信息确定用户可用的核身方式。如，根据终端设备的标识，确定用户的终端设备为手机时，可以用的核身方式包括：短信、指纹、密码、人脸识别以及身份证号等。而在确定用户的终端设备为个人电脑时，可以用的核身方式包括：密码以及身份证号等。需要说明的是，在确定用户可用的核身方式有多种时，可以基于预设规则，将多种核身方式中的任意几种进行组合来设定用户最终的核身方式。

此外，服务端还可以记录上述用户的账号和/或名称、终端设备的标识以及网关的地址的对应关系。在一个例子中，该对应关系可以如表1所示。

表1

当然，在实际应用中，表1所示的对应关系还可以包括其它信息，如，用户类型等，本说明书对此不作限定。

步骤220，服务端根据证书申领请求，向该客户端或者用户的其它在线且可用的客户端发送核身指示。

如，在服务端结合环境信息，判断当前的证书类型该用户可用，且设定了最终的核身方式之后，可以查该用户所有在线且可用的客户端，如果查到两个以上在线且可用的客户端(包括用户通过手机登录的客户端和通过个人电脑登录的客户端等)，则优先向终端设备为手机的客户端发送核身指示。可以理解的是，如果只查到一个客户端(即上述发送证书申领请求的客户端)，则向该客户端发送核身指示。

可以理解的是，上述核身指示发送失败或者未查到在线且可用的客户端(当前客户端掉线)，则证书申领过程结束。

步骤230，该客户端或者其它客户端对用户的身份进行核实。

在一个例子中，该客户端或者其它客户端在接收到核身指示之后，可以向用户显示用于表示需要用户进行身份核实的信息，并对用户的身份进行核实。具体地，可以通过上述最终的核身方式来对用户的身份进行核实。

步骤240，该客户端或者其它客户端向服务端返回核身结果。

步骤250，在核身结果为核身通过时，服务端从第三方认证机构获取证书。

在一种实现方式中，在服务端从第三方证书机构获取证书之前，可以先向该客户端发送用于表示可以开始安装证书的通知消息。需要说明的是，该通知消息可以是服务端根据该客户端所接入网络的网关地址(此处的网关地址可以根据上述对应关系获取)，查到对应的网关，之后通过该网关向该客户端发送的。该客户端在接收到该通知消息之后，如果确定该通知消息合法，则在本地生成公钥私钥秘钥对。在一个例子中，如果该客户端的证书类型为：ukey，则可以调用ukey的驱动来生成公钥私钥秘钥对，并可以调用ukey的驱动采用生成的私钥对公钥进行签名。之后客户端可以将签名后的公钥以及业务信息发送给服务端。此处的业务信息是根据不同的电子签名业务确定的。服务端根据该业务信息，从第三方认证机构获取证书。

步骤260，向该客户端返回证书。

此处，当服务端还接收到客户端发送的签名后的公钥时，服务端可以对签名后的公钥进行验签。并且在验签通过后，通过该公钥对上述证书进行加密。之后，向该客户端返回加密后的证书。

该客户端在接收到服务端发送的证书之后，可以先确认接收到的证书有效。之后，可以根据私钥对加密的证书进行解密，并将解密后的证书写入独立硬件盾或者本地端软证书。在将证书写入本地后，客户端还可以向服务端发送证书写入成功的消息。服务端在接收到该写入成功的消息后，可以存储用户与上述证书之间的对应关系。在一个例子中，该对应关系可以如表2所示。

表2

当然，在实际应用中，表2所示的对应关系还可以包括其它信息，如，修改时间等，本说明书对此不作限定。

在各个用户的客户端完成证书申领的过程之后，就可以执行如下的电子签名方法了。

图3为本说明书一个实施例提供的电子签名方法信息交互图。如图3所示，所述方法具体可以包括：

步骤310，服务端接收签名业务系统发送的电子签名申请请求。

具体地，用户可以在签名业务系统设置参与电子签名的各个用户的描述信息。此处的描述信息可以包括各个用户的用户信息、签名位置以及签名顺序等等。其中，用户信息可以包括用户的名称和/或账号等。在完成上述设置之后，用户可以发起相应的电子签名业务。在用户发起电子签名业务之后，电子签名业务系统可以向服务端发送上述电子签名申请请求。该电子签名申请请求可以包括上述描述信息。此外，还可以包括签名规则(如，配置的摘要算法等)等。

步骤320，根据各个用户的用户信息，获取对应的客户端的环境信息。

此处的环境信息可以包括上述客户端所接入网络的网关的地址。此外，还可以包括上述客户端所在设备的标识等。在一种实现方式中，服务端可以从表1所示的对应关系中，获取客户端的环境信息。

步骤330，根据环境信息，向客户端发送签名指示。

在一种实现方式中，根据环境信息，向客户端发送签名指示的过程可以为：服务端可以根据网关的地址，查到客户端所接入网络的网关。向该网关发送上述签名指示。网关在接收到该签名指示之后，再根据设备的标识，查到客户端所在的终端设备。最后向该终端设备发送上述签名指示。由此，可以实现对本地电子签名的生命周期强管控、签名过程管控。

需要说明的是，在实际应用中，在服务端查某个用户的客户端的过程中，可能会查到两个以上在线且可用的客户端(包括用户通过手机登录的客户端和通过个人电脑登录的客户端等)。如果查到两个以上的客户端，则同时向该两个以上的客户端发送签名指示。

步骤330中，服务端可以根据描述信息中的签名顺序，依次向参与电子签名的各个用户的客户端发送上述签名指示。该签名指示可以包括签名位置以及签名规则等。可以理解的是，在参与电子签名的用户为多个时，则上述服务端发送签名指示的步骤是循环执行的。客户端在接收到上述签名指示之后，可以以弹框的形式告知用户输入待签名的数据。当用户输入待签名的数据之后，客户端就可以根据签名规则中配置的摘要算法，对待签名的数据进行运算，从而生成对应的摘要信息。之后调用独立硬件盾或者本地端软证书，在对应的签名位置对摘要信息进行签名。

步骤340，接收签名后的摘要信息。

客户端向服务端返回的签名后的摘要信息可以采用pkcs