CN110943840B - 一种签名验证方法 - Google Patents

Abstract

本发明提供了一种签名验证方法，该方法主要通过客户端根据业务参数信息和密钥生成第一签名，服务端接收客户端发送的业务参数和签名，服务端基于获得的业务参数信息进行签名验证，将获得的第一签名和已经存储在服务端的签名进行比对验证。业务参数和密钥经过消息摘要算法得到的摘要作为一次一签的验证对象，可以提高验证参数的安全性能，同时可以有效防止出现随机数重复防止正常访问的情况出现。

Description

一种签名验证方法

技术领域

本发明涉及信息安全技术领域，特别涉及一种签名验证方法。

背景技术

重放攻击是现在网络技术领域中常受到的一种攻击方式。重放攻击(ReplayAttacks)又称重播攻击、回放攻击，是指攻击者发送一个目的主机已接收过的包，来达到欺骗***的目的，主要用于身份认证过程，破坏认证的正确性。重放攻击可以由发起者，也可以由拦截并重发该数据的敌方进行。攻击者利用网络监听或者其他方式盗取认证凭据，之后再把它重新发服务器。重放攻击在任何网络通过程中都可能发生。

在现有技术中，例如发明专利200610076227.X中使用的防止重放攻击的方法为在服务器端对接收到的摘要进行签名验证，在签名验证一致的情况下认为客户端发送的消息合法，同时还需要进行时间参数的验证，在时间参数一致的情况下认为接收到的信息为客户端发送的正常信息。另外已经使用的防止重放攻击的方法为通过增加时间戳(timestamp)和随机数(nonce)来防止重放攻击。但是这种防止重放攻击的方式会存在随机数重合，造成误将正常访问的当做攻击的情况。

发明内容

本申请的目的是，提供一种防重放攻击的方法，可以有效地防止重放攻击，以及避免服务端拒绝正常请求。

用户触发业务请求，客户端将业务请求相对应业务参数和密钥等信息进行消息摘要，可以选择的消息摘要算法为哈希消息摘要算法，通过消息摘要得到签名。其中业务参数中可以包含地址信息、时间戳、用户信息等。客户端将业务参数和签名，即数据报文发送给后端服务器。密钥不进行传输。

其中业务参数可以加入时间戳，时间戳通过获取消息摘要时候的时间生成16位时间值为参数。

服务端接收客户端传送的数据报文通过解析得到业务参数和签名。服务端更具客户端传送的业务参数调用对应的密钥。

优选的，可以通过App-Key查找对应的密钥。密钥为服务端发送给客户端的作为安全验证的。

服务端将查找得到的密钥和客户端传送过来的业务参数拼装在一起，通过在客户端相同的消息摘要算法得到第二签名。服务端使用的消息摘要算法和客户端使用的消息摘要算法相同。

服务端将生产的签名即第二签名和客户端传送过来的签名进行比对验证。如果签名一致则说明业务参数没有被篡改。客户端使用了服务端颁发的密钥。此次请求为可信任的正常访问请求，将通过此步骤的验证。

服务端在进行步骤205的验证签名和服务端产生签名是否一致的步骤之后，将要进行该步骤。服务端数据库中存储有在步骤205中比对使用过的签名。在数据库中查找是从客户端传输过来的签名，判断服务端中是否存在和接收到的签名一致的签名。存在一致的签名，则说明客户端发送的签名为已经使用过的签名，此次请求为异常的访问请求。服务端将返回错误信息，验证将无法通过。

所述的签名为将业务参数和密钥通过消息摘要算法得到字符串摘要。

服务端将生产的签名即第二签名和客户端传送过来的签名进行比对验证。如果签名一致则说明业务参数没有被篡改。客户端使用了服务端颁发的密钥。如果判断签名不一致则服务端将返回错误信息给客户端，不再响应客户端发送的请求。

服务端将通过验证的签名存储在服务端数据库中。存储在数据库中的签名用于签名验证。

通过签名验证和一次签名认证。服务端调用后端程序，处理数据中业务参数信息。同时将业务请求结果返回客户端。

所述服务端设置有服务端接收单元、验证单元一、验证单元二、业务处理单元、数据返回单元。

验证单元一，服务端中设置的验证单元一用于验证客户端发送的签名。服务端在接收到客户端数据报文之后解析得到摘要。服务端根据接收到的业务参数在服务端数据库中调用相应的服务端密钥。将服务端调用出来的密钥和业务参数拼接在一起经过消息摘要算法得到第二签名。将两个签名做比对，如果一致则通过验证。

验证单元二，将服务端产生的摘要在数据中查找对应的摘要，如果数据库中存在对应的摘要则将将返回错误信息，无法通过验证。验证单元二可以验证比对一致的摘要是否是已经使用过的摘要。这可以有效防止数据包被非法抓取，避免服务端遭受重放攻击。

业务处理单元，用于处理客户端发送的数据请求协议。更具服务端传送的业务参数处理相应的业务请求。

数据返回单元，用于服务端处理程序处理业务之后将数据信息返回客户端。

与现有技术相比，本发明技术方案的优点在于：

基于上述技术方案，在服务端中将已经通过签名验证的签名存储在数据库中，将通过第一单元验证的签名再次从数据库中查找是否具有相同的签名，以此实现单次签名单次使用的功能。业务参数和密钥经过消息摘要算法得到的摘要作为一次一签的验证对象，可以提高验证参数的安全性能，同时可以有效防止出现随机数重复防止正常访问的情况出现。

附图说明

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

图1是本发明实施例提供的是一种应用场景图；

图2是本发明实施例提供的是一种签名验证方法流程图；

图3是本发明实施例提供的是一种签名验证的一种结构示意图。

具体实施方式

为了使本发明所要解决的技术问题、技术方案及有益效果更加清楚明白，以下结合附图和实施例，对本发明进行详细的说明。应当说明的是，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

本发明要解决的技术问题是：提高网络使用安全性能，预防重放攻击，并且避免正常的访问被拦截。

该使用一次一签的方式防止重放攻击的方法，包括以下步骤：

本发明方法应用于客户端和服务端之间。客户端为与服务端相对应，为客户提供本地服务的程序。客户端在终端设备上使用例如笔记本电脑、手机等。服务端为客户端提供数据服务，处理相应业务。客户端和服务端之间通过网络建立通信连接。当用户使用终端设备时，通过客户端向服务端发送业务请求参数。服务端将对客户端传送的数据报文请求进行验证，服务端将验证客户端发送请求中的签名是否合法。服务端将比对的签名和存储在数据库中的签名，查找数据库中是否存在和客户端发送的签名一致的签名。如果存在说明此次签名已经使用过。服务端将拒绝此次访问。实现一次签名只能使用一次的功能，起到防止重放攻击的作用。

结合图1，具体说明本发明的实施步骤：

步骤201：程序的开始步骤。

步骤202：用户触发业务请求，客户端将业务请求相对应业务参数和密钥等信息进行消息摘要，可以选择的消息摘要算法为哈希消息摘要算法，通过消息摘要得到签名。其中业务参数中可以包含地址信息、时间戳、用户信息等。客户端将业务参数和签名，即数据报文发送给后端服务器。密钥不进行传输。

其中业务参数可以加入时间戳，时间戳通过获取消息摘要时候的时间生成16位时间值为参数。

步骤203：服务端接收客户端传送的数据报文通过解析得到业务参数和签名。服务端更具客户端传送的业务参数调用对应的密钥，其中可以通过App-Key查找对应的密钥。

步骤204；服务端将查找得到的密钥和客户端传送过来的业务参数拼装在一起，通过在客户端相同的消息摘要算法得到第二签名。服务端使用的消息摘要算法和客户端使用的消息摘要算法相同。

步骤205和206：服务端将生产的签名即第二签名和客户端传送过来的签名进行比对验证。如果签名一致则说明业务参数没有被篡改。客户端使用了服务端颁发的密钥。此次请求为可信任的正常访问请求，将通过此步骤的验证。

步骤207：服务端在进行步骤205的验证签名和服务端产生签名是否一致的步骤之后，将要进行该步骤。服务端数据库中存储有在步骤205中比对使用过的签名。在数据库中查找是从客户端传输过来的签名，判断服务端中是否存在和接收到的签名一致的签名。存在一致的签名，则说明客户端发送的签名为已经使用过的签名，此次请求为异常的访问请求。服务端将返回错误信息，验证将无法通过。

所述的签名为将业务参数和密钥通过消息摘要算法得到字符串摘要。

步骤208：服务端将生产的签名即第二签名和客户端传送过来的签名进行比对验证。如果签名一致则说明业务参数没有被篡改。客户端使用了服务端颁发的密钥。如果判断签名不一致则服务端将返回错误信息给客户端，不再响应客户端发送的请求。

步骤209：服务端将通过验证的签名存储在服务端数据库中。存储在数据库中的签名用于签名验证。

步骤210：通过签名验证和一次签名认证。服务端调用后端程序，处理数据中业务参数信息。同时将业务请求结果返回客户端。

步骤211：完成业务请求过程。

具体的通过服务端对客户端传输过来的验证码进行的两次验证。第一次验证过程可以判断请求业务的客户端是否为服务端颁发过密钥，是否为准许访问的对象。此次验证中的数据包如果被截取，利用数据报文中的业务参数和签名对服务端在短时间内发懂重放攻击，服务端将无法抵御重放攻击。将接收到的数据和服务端中已经使用并存储在数据库中的签名进行比对认证，一致则说明已经使用过。数据库中不存在相同的签名，则可以通过验证。

根据图3中的防止重放攻击的验证***示意图，如图所示，本实施例具体包括：服务端接收单元、验证单元一、验证单元二、业务处理单元、数据返回单元。

服务端接收单元301，用于接收客户端发送的数据。

验证单元一302，服务端中设置的验证单元一用于验证客户端发送的签名。服务端在接收到客户端数据报文之后解析得到摘要。服务端根据接收到的业务参数在服务端数据库中调用相应的服务端密钥。将服务端调用出来的密钥和业务参数拼接在一起经过消息摘要算法得到第二签名。将两个签名做比对，如果一致则通过验证。

验证单元二303，将服务端产生的摘要在数据中查找对应的摘要，如果数据库中存在对应的摘要则将将返回错误信息，无法通过验证。验证单元二可以验证比对一致的摘要是否是已经使用过的摘要。这可以有效防止数据包被非法抓取，避免服务端遭受重放攻击。

业务处理单元304，用于处理客户端发送的数据请求协议。更具服务端传送的业务参数处理相应的业务请求。

数据返回单元305，用于服务端处理程序处理业务之后将数据信息返回客户端。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

对所公开的实施例的上述说明，使本领域技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (8)

1.一种签名验证方法，其特征在于，包括：

客户端根据业务参数信息和密钥生成第一签名，生成第一签名的方法为将客户端获得的业务参数信息和密钥通过消息摘要算法得到摘要，其中，所述业务参数信息包括地址信息、时间戳、用户信息，时间戳通过获取消息摘要时候的时间生成16位时间值为参数；

服务端接收客户端发送的业务参数和签名；

服务端基于获得的业务参数信息进行签名验证；

将获得的第一签名和已经存储在服务端的签名进行比对验证；

其中，所述的比对验证为将获得的第一签名和存储在服务器中的已存储签名进行比对验证，所述的存储在服务器中的签名为将已经获得的服务器签名进行存储，如果有比对一致的签名，说明该第一签名为已经使用过的签名，服务器将拒绝此次访问，并返回错误信息，如果不存在相同的签名，则可以通过验证。

2.根据权利要求1所述的方法，其特征在于，所述业务参数包括时间戳、设备ID、业务请求数据信息。

3.根据权利要求1所述的方法，其特征在于，所述签名验证为服务端获取客户端发送的业务参数信息，根据获得的业务参数调用服务端中的密钥，基于获得的业务参数信息和密钥消息摘要获得第二签名，将获得的第一签名和第二签名进行比对验证，如果两个签名相同则验证通过，并进入下一个验证程序即比对验证。

4.根据权利要求2所述的方法，其特征在于，所述服务端在判断签名不存在于服务器数据库中，则存储该签名。

5.根据权利要求3所述的方法，其特征在于，所述服务器将对获取的签名进行签名验证和比对验证，在签名验证和比对验证都成功的情况下，调用服务端程序，完成业务请求。

6.根据权利要求1所述的方法，其特征在于，所述的签名为通过消息摘要算法得到的消息摘要。

7.根据权利要求6所述的方法，其特征在于，所述消息摘要算法为哈希算法。

8.根据权利要求3所述的方法，其特征在于，所述比对验证为在服务端已经存储的签名中查找，是否存在相同的签名，如果存在相同的签名则说明签名已经被使用过，服务器将返回错误信息，服务端无法通过业务请求。