签名信息的验证方法以及信息签名方法

摘要

本发明公开了一种签名信息的验证方法以及信息签名方法。该签名信息的验证方法包括：客户端获取至少两组签名参数组合以及初始待签名信息，将签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密，得到最终签名结果，其中每次签名加密得到的签名结果作为下一次签名加密的待签名信息。客户端将最终签名结果发送至服务器端。服务器端获取至少两组签名参数组合和初始待签名信息；将签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密，得到目标签名结果；若服务器端判断最终签名结果匹配目标签名结果，则判定验证通过。通过上述方式，本发明能够提高信息签名加密的安全性。

说明书

技术领域

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

背景技术

安全攻防场景中，客户端请求篡改，是最常见的攻防场景之一。相应的防御策略主要包括：客户端签名、应用加固、代码混淆以及反调试等等。

目前较为常见的签名方案主要是通过固定的密钥和哈希算法对客户端请求进行加密，生成相应的签名结果，服务器端使用同样的方法进行签名验证，以此保证请求的完整性，一定程度上能够防止中间人对客户端请求进行篡改。但是，若攻击者通过反编译手段获取了固定的秘钥及哈希算法，则可以任意篡改客户端请求，使得签名算法的作用大打折扣。

发明内容

有鉴于此，本发明主要解决的技术问题是提供一种签名信息的验证方法以及信息签名方法，能够提高信息签名加密的安全性。

为解决上述技术问题，本发明采用的一个技术方案是：提供一种信息签名方法，该信息签名方法包括：获取至少两组签名参数组合以及初始待签名信息，其中每组签名参数组合分别包括签名算法和密钥，签名算法和密钥用于对待签名信息进行签名加密；将各签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密，直至遍历所有签名参数组合，得到最终签名结果，其中每次签名加密得到的签名结果作为下一次签名加密的待签名信息；将最终签名结果发送至服务器端。

在本发明的一实施例中，获取至少两组签名参数组合的步骤包括：发送身份标识信息至服务器端，以由服务器端生成对应身份标识信息的至少两组签名参数组合；接收至少两组签名参数组合。

在本发明的一实施例中，将各签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密的步骤包括：发送签名参数请求至服务器端，以由服务器端响应于签名参数请求，将签名参数请求对应的签名参数反馈客户端，或将存储签名参数的地址信息反馈客户端；接收签名参数或接收地址信息。

在本发明的一实施例中，获取至少两组签名参数组合的步骤之后包括：将每组签名参数组合分别存储于不同的文件。

在本发明的一实施例中，获取至少两组签名参数组合的步骤包括：根据每组签名参数组合的签名算法和密钥分别生成对应的签名函数；将各签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密的步骤包括：将各签名函数按照第一预定顺序逐一对初始待签名信息进行签名加密。

在本发明的一实施例中，初始待签名信息包括客户端的设备唯一标识和时间戳；将最终签名结果发送至服务器端的步骤包括：发送最终签名结果、设备唯一标识以及时间戳至服务器端，以由服务器端判断设备唯一标识是否匹配目标设备唯一标识，目标设备唯一标识由服务器端根据客户端的身份标识信息而确定；以及判断当前时间点至时间戳对应的时间点的间隔时长是否超过预设时长。

为解决上述技术问题，本发明采用的又一个技术方案是：提供一种签名信息的验证方法，该签名信息的验证方法包括：接收客户端发送的最终签名结果；获取至少两组签名参数组合以及初始待签名信息，其中每组签名参数组合分别包括签名算法和密钥，签名算法和密钥用于对待签名信息进行签名加密；将各签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密，直至遍历所有签名参数组合，得到目标签名结果，其中每次签名加密得到的签名结果作为下一次签名加密的待签名信息；判断最终签名结果是否匹配目标签名结果；若是，则判定验证通过。

在本发明的一实施例中，接收客户端发送的最终签名结果的步骤之前包括：接收客户端发送的身份标识信息；根据不同的身份标识信息生成不同的至少两组签名参数组合；将至少两组签名参数组合发送至客户端。

在本发明的一实施例中，接收客户端发送的最终签名结果的步骤之前包括：接收客户端发送的签名参数请求；响应于签名参数请求，获取签名参数请求对应的签名参数，或获取存储签名参数的地址信息；将签名参数或地址信息发送至客户端。

在本发明的一实施例中，接收客户端发送的签名参数请求的步骤之后包括：响应于签名参数请求，判断签名参数请求是否处于异常状态；若是，则将错误的签名参数或地址信息发送至客户端，或对签名参数请求不予处理。

在本发明的一实施例中，初始待签名信息包括客户端的设备唯一标识和时间戳；接收客户端发送的最终签名结果的步骤包括：接收客户端发送的最终签名结果、设备唯一标识以及时间戳；判定验证通过的步骤之前还包括：判断设备唯一标识是否匹配目标设备唯一标识，其中目标设备唯一标识由服务器端根据客户端的身份标识信息而确定；以及判断当前时间点至时间戳对应的时间点的间隔时长是否超过预设时长；若设备唯一标识匹配目标设备唯一标识且当前时间点至时间戳对应的时间点的间隔时长未超过预设时长，则判定验证通过。

为解决上述技术问题，本发明采用的又一个技术方案是：提供一种签名信息的验证方法，该签名信息的验证方法包括：客户端获取至少两组签名参数组合以及初始待签名信息，其中每组签名参数组合分别包括签名算法和密钥，签名算法和密钥用于对待签名信息进行签名加密，至少两组签名参数组合以及初始待签名信息由服务器根据客户端信息生成；客户端将各签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密，直至遍历所有签名参数组合，得到最终签名结果，其中每次签名加密得到的签名结果作为下一次签名加密的待签名信息；客户端将最终签名结果发送至服务器端；服务器端获取至少两组签名参数组合和初始待签名信息；服务器端将各签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密，直至遍历所有签名参数组合，得到目标签名结果；服务器端判断最终签名结果是否匹配目标签名结果；若是，则判定验证通过。

为解决上述技术问题，本发明采用的又一个技术方案是：提供一种签名信息的验证方法，该方法包括：客户端获取至少两组签名参数组合以及初始待签名信息，其中每组签名参数组合分别包括签名算法和密钥，签名算法和密钥用于对待签名信息进行签名加密；客户端将各签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密，直至遍历所有签名参数组合，得到最终签名结果，其中每次签名加密得到的签名结果作为下一次签名加密的待签名信息；客户端将最终签名结果发送至服务器端；服务器端获取至少两组解密参数组合和初始待签名信息，其中解密参数组合与签名参数组合一一对应，并且每组解密参数组合分别包括解密算法和密钥，每组解密参数组合的解密算法和密钥用于对应签名参数组合的签名结果的解密；服务器端将各解密参数组合按照第二预定顺序逐一对最终签名结果进行解密，直至遍历所有解密参数组合，得到目标解密信息，其中每次解密得到的解密信息作为下一次解密的待解密信息；服务器端判断目标解密信息是否匹配初始待签名信息；若是，则判定验证通过。

为解决上述技术问题，本发明采用的又一个技术方案是：提供一种签名信息的验证方法，该签名信息的验证方法包括：接收客户端发送的最终签名结果，其中最终签名结果由至少两组签名参数组合签名加密而得；获取至少两组解密参数组合和初始待签名信息，其中解密参数组合与签名参数组合一一对应，并且每组解密参数组合分别包括解密算法和密钥，每组解密参数组合的解密算法和密钥用于对应签名参数组合的签名结果的解密；将各解密参数组合按照第二预定顺序逐一对最终签名结果进行解密，直至遍历所有解密参数组合，得到目标解密信息，其中每次解密得到的解密信息作为下一次解密的待解密信息；判断目标解密信息是否匹配初始待签名信息；若是，则判定验证通过。

本发明的有益效果是：区别于现有技术，本发明提供一种签名信息的验证方法以及信息签名方法。该验证方法中客户端将各签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密，并且其中每次签名加密得到的签名结果作为下一次签名加密的待签名信息。而服务器端将各签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密，直至遍历所有签名参数组合，得到目标签名结果，并且同样每次签名加密得到的签名结果作为下一次签名加密的待签名信息；或是服务器端将各解密参数组合按照第二预定顺序逐一对最终签名结果进行解密，直至遍历所有解密参数组合，得到目标解密信息，其中每次解密得到的结果作为下一次解密的待解密信息。如此一来，当最终签名结果匹配目标签名结果或目标解密信息匹配初始待签名信息时，服务器端判定验证通过，也就意味着攻击者需要破译本发明所应用的所有算法及密钥，极大程度地提高了篡改的复杂度，因而能够提高信息签名加密的安全性。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。此外，这些附图和文字描述并不是为了通过任何方式限制本发明构思的范围，而是通过参考特定实施例为本领域技术人员说明本发明的概念。

图1是本发明签名信息的验证方法第一实施例的流程示意图；

图2是本发明签名信息的验证方法第二实施例的流程示意图；

图3是本发明客户端获取签名参数的方法一实施例的流程示意图；

图4是本发明信息签名方法一实施例的流程示意图；

图5是本发明签名信息的验证方法第三实施例的流程示意图；

图6是本发明签名信息的验证方法第四实施例的流程示意图；

图7是本发明签名信息的验证方法第五实施例的流程示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合本发明的实施例，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。在不冲突的情况下，下述的实施例及实施例中的特征可以相互组合。

为解决现有技术中信息签名加密的安全性不足的技术问题，本发明一实施例提供了一种签名信息的验证方法。该签名信息的验证方法包括：客户端获取至少两组签名参数组合以及初始待签名信息，其中每组签名参数组合分别包括签名算法和密钥，签名算法和密钥用于对待签名信息进行签名加密；客户端将各签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密，直至遍历所有签名参数组合，得到最终签名结果，其中每次签名加密得到的签名结果作为下一次签名加密的待签名信息；客户端将最终签名结果发送至服务器端；服务器端获取至少两组签名参数组合和初始待签名信息；服务器端将各签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密，直至遍历所有签名参数组合，得到目标签名结果；服务器端判断最终签名结果是否匹配目标签名结果；若是，则判定验证通过。以下进行详细阐述。

请参阅图1，图1是本发明签名信息的验证方法第一实施例的流程示意图。

需要说明的是，在本实施例中，签名信息的验证方法的实施主体为客户端与服务器端所构成的系统，以下对签名信息的验证方法第一实施例的具体实施方式进行详细阐述，但本实施例所阐述的签名信息的验证方法并不局限于以下步骤：

S101：客户端获取至少两组签名参数组合以及初始待签名信息；

在本实施例中，客户端预先获取至少两组签名参数组合以及初始待签名信息，其中，每组签名参数组合分别包括签名算法和密钥，签名算法和密钥用于对待签名信息进行签名加密，初始待签名信息即为初始待加密信息，从而减少客户端获取信息并进行处理的负担。

S102：客户端将各签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密，直至遍历所有签名参数组合，得到最终签名结果；

在本实施例中，客户端获取至少两组签名参数组合以及初始待签名信息后，客户端将各签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密，直至遍历所有签名参数组合，得到最终签名结果，从而增加信息签名方法的安全性，增加攻击者破译的复杂度。

其中，每次签名加密得到的签名结果作为下一次签名加密的待签名信息，从而攻击者在破译时，需要破译全部的签名算法以及密钥，极大程度地提高了篡改的复杂度，进而能够提高信息签名加密的安全性。

S103：客户端将最终签名结果发送至服务器端；

在本实施例中，客户端得到最终签名结果后，将最终签名结果发送至服务器端，以实现通过服务器端对最终签名结果进行验证，从而增加签名信息验证的安全性。

S104：服务器端获取至少两组签名参数组合和初始待签名信息；

在本实施例中，服务器端获取至少两组签名参数组合和初始待签名信息，其中，每组签名参数组合分别包括签名算法和密钥，签名算法和密钥用于对待签名信息进行签名加密，初始待签名信息即为初始待加密信息。并且，服务器端所获取的至少两组签名参数组合和初始待签名信息，应当与客户端所获取的至少两组签名参数组合和初始待签名信息的一致，从而才能实现通过服务器端对最终签名结果进行验证。

S105：服务器端将各签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密，直至遍历所有签名参数组合，得到目标签名结果；

在本实施例中，服务器端获取至少两组签名参数组合和初始待签名信息后，于服务器端再次将各签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密，直至遍历所有签名参数组合，得到目标签名结果。服务器端的签名加密过程应当与步骤S102所阐述的客户端的加密过程相同，从而服务器端能够得到对初始待签名信息进行加密，得到未被篡改的目标签名结果，以便于对最终签名结果进行验证。

S106：服务器端判断最终签名结果是否匹配目标签名结果；

在本实施例中，服务器端得到目标签名结果后，将判断最终签名结果是否匹配目标签名结果，从而根据判断结果做出自主响应行为，提高信息签名加密的安全性。

S107：若是，则判定验证通过；

在本实施例中，若服务器端判断最终签名结果匹配目标签名结果，可以认为最终目标结果未被攻击者破译及篡改，则判定验证通过，故服务器端与客户端可以继续执行正常的业务逻辑。

其中，最终签名结果的内容与目标签名结果中相应内容一致时，可以认为最终签名结果与目标签名结果相匹配，在此不做限定。

在传统的信息签名方案中，若攻击者通过反编译手段获取签名参数组合的签名算法以及密钥，便可以任意篡改客户端请求。一般来说，此时客户端通常的应对方案为更新签名算法以及密钥，重新发布更新后的客户端，但是没有由于攻击者已经记录有加密代码所在地址，对于重新发布的客户端版本，攻击者依然可以轻易反编译得到更新后的签名算法以及密钥，使得签名参数组合的作用大打折扣。

然而本实施例所提供的签名信息的验证方法，客户端将各签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密，并且其中每次签名加密得到的签名结果作为下一次签名加密的待签名信息。而服务器端将各签名参数组合按照相同的第一预定顺序逐一对初始待签名信息进行签名加密，直至遍历所有签名参数组合，得到目标签名结果，并且同样每次签名加密得到的签名结果作为下一次签名加密的待签名信息。如此一来，当最终签名结果匹配目标签名结果时，服务器判定验证通过，也就意味着攻击者需要破译本实施例所应用的所有签名算法及密钥，极大程度地提高了篡改的复杂度，因而能够提高信息签名加密的安全性。

请参阅图2，图2是本发明签名信息的验证方法第二实施例的流程示意图。

需要说明的是，在本实施例中，签名信息的验证方法的实施主体为客户端与服务器端所构成的系统，以下对签名信息的验证方法第二实施例的具体实施方式进行详细阐述，但本实施例所阐述的签名信息的验证方法并不局限于以下步骤：

S201：客户端发送身份标识信息至服务器端；

在本实施例中，客户端预先将签名信息验证过程中所需的信息打包发送至服务器端，即客户端发送身份标识信息至服务器端，从而服务器端能够预先存储有客户端的身份标识信息。

其中，身份标识信息可以包括客户端的类型信息以及版本信息。

S202：服务器端生成对应身份标识信息的至少两组签名参数组合；

在本实施例中，服务器接收客户端发送的身份标识信息后，服务器端能够生成对应身份标识信息的至少两组签名参数组合，其中，每组签名参数组合分别包括签名算法和密钥，签名算法和密钥用于对待签名信息进行签名加密。也就是说，服务器根据不同的客户端的身份标识信息，能够生成不同的至少两组签名参数组合，从而在攻击者在破译不同客户端时，由于身份标识信息不同攻击者无法在破译其中一种后，破译其他客户端的签名参数组合，进而提高信息签名加密的安全性。

可选地，签名算法可以为哈希算法等，基于不同客户端之间存在差异，不同客户端获取的至少两组签名参数组合可以并不相同，以此避免攻击者破译一个客户端时，能够同时破译其他客户端的签名信息，从而提升信息签名方法的安全性。

具体地，客户端获取的签名参数组合的数量可以为两组、三组甚至更多，理论上来说，签名参数组合的数量越多，信息签名方法的安全性越高。

举例而言，服务器端可以生成三组签名参数组合，分别为签名参数组合A1、签名参数组合A2以及签名参数组合A3，具体如下：

签名参数组合A1：签名算法X1，密钥Y1；

签名参数组合A2：签名算法X2，密钥Y2；

签名参数组合A3：签名算法X3，密钥Y3。

并且，在本实施例中，至少两组签名参数组合以及初始待签名信息可以预存于客户端，也可以是客户端于服务器端获取得到的，在此不做限定。

S203：客户端获取至少两组签名参数组合；

在本实施例中，服务端生成对应身份标识信息的至少两组签名参数组合后，服务器端将至少两组签名参数组合发送至客户端，客户端获取该至少两组签名参数组合。其中，与前述实施例相同，本实施例中的每组签名参数组合分别包括签名算法和密钥，签名算法和密钥用于对待签名信息进行签名加密。

S204：客户端生成签名函数；

在本实施例中，客户端在获取至少两组签名参数组合后，将每组签名参数组合生成一组签名函数，即基于一组相对应的签名算法和密钥生成相应的签名函数，从而后续步骤中调用签名参数组合时，能够直接调用相应的签名函数，以方便调用相对应的签名算法和密钥，从而减少数据处理量。

在一替代实施例中，上述实施例中所阐述的至少两组签名参数组合可以预先存储于客户端，客户端能够直接获取存储于本地的签名参数组合对待签名信息进行加密，以及生成签名函数。并且，客户端将该至少两组签名参数组合发送至服务器端，使得服务器端能够获取用于签名加密的签名参数组合，从而使用相同的签名参数组合对待加密信息进行签名加密。

S205：客户端将每组签名参数组合分别存储于不同的文件；

在本实施例中，客户端获取至少两组签名参数组合后，将每组签名参数组合随机分别存储于不同的模块和/或文件中，即实现代码混淆。使得攻击者在破译时需花费较长时间获取不同签名参数组合的签名算法以及密钥，并且由于不同客户端的签名参数组合所处位置不同，进一步增加攻击者所需要进行的工作量，从而提升攻击者破译的难度，进而提高签名信息的验证方法的安全性。并且，进一步进行打包发布。

可选地，客户端可以是将所生成签名函数随机分别存储于不同文件，以方便后续调用相关的签名算法和密钥。

其中，上述的模块和/或文件可以是APK(Android application package，Android应用程序包)文件等。

S206：客户端获取初始待签名信息；

在本实施例中，客户端获取初始待签名信息。其中，前述实施例中的初始待签名信息与本实施例中的初始待签名信息相同，初始待签名信息包括客户端的类型信息以及版本信息、客户端的设备唯一标识以及时间戳等，即初始待签名信息为前述步骤中客户端的身份标识信息。

其中，客户端的设备唯一标识用于标识安装有客户端的设备的身份，且不同设备之间的客户端的设备唯一标识不同，以此表征该设备身份的唯一性。时间戳是使用数字签名技术产生的数据，用来产生和管理时间戳，对签名对象进行数字签名产生时间戳，以证明原始文件在签名时间之前已经存在。

具体地，初始待签名信息可以是预存于客户端，也可以是客户端从服务器端所获取的。

S207：客户端将各签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密，得到最终签名结果；

在本实施例中，客户端获取至少两组签名参数组合以及初始待签名信息后，客户端将各签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密，直至遍历所有签名参数组合，得到最终签名结果，从而增加信息签名方法的复杂性，增加攻击者破译难度。其中，每次签名加密得到的签名结果作为下一次签名加密的待签名信息，从而攻击者在破译时，需要破译全部的签名算法以及密钥，极大程度地提高了篡改的复杂度，进而能够提高信息签名加密的安全性。

举例来说，客户端通过第一组签名参数组合对初始待签名信息进行签名加密，得到第一签名结果；进一步通过第二组签名参数组合对第一签名结果进行加密，得到第二签名结果，以此类推，直至客户端按照第一预定顺序遍历所有签名参数组合，得到最终签名结果。以下结合前述步骤中以当前客户端获取了三组签名参数组合进行详细阐述：

预设客户端获取的三组签名参数组合分别为签名参数组合A1、签名参数组合A2以及签名参数组合A3，第一预定顺序为依次执行签名参数组合A1、签名参数组合A2以及签名参数组合A3。

具体地，签名参数组合A1所包括的签名算法为MD5(信息摘要算法，MD5 Message-Digest Algorithm)，对应的密钥为KEY1；

签名参数组合A2所包括的签名算法为SHA1(安全散列算法1，Secure HashAlgorithm 1)，对应的密钥为KEY2；

签名参数组合A3所包括的签名算法为SHA256(安全散列算法256，Secure HashAlgorithm 256)，对应的密钥为KEY3。

客户端获取的初始待签名信息如下：客户端的类型信息(client_id)为CLIENT_A，客户端的版本信息(verison)为1.0，客户端的唯一标识(device_id)为DEVICE_A，时间戳(timestamp)为1500000000。

由于部分签名算法可能需要于服务器端获取签名参数，具体实施方式在下文进行详细阐述。

具体地，首先，生成客户端所获取的初始待签名信息：

client_id＝CLIENT_Adevice_id＝DEVICE_Arequest＝EXAMPLEtimestamp＝1500000000version＝1.0；

其次，通过第一组签名参数组合A1(签名算法MD5和密钥KEY1)对初始待签名信息进行签名加密，得到第一签名结果：

sign＝md5(client_id＝CLIENT_Adevice_id＝DEVICE_Arequest＝EXAMPLEtimestamp＝1500000000version＝1.0KEY1)＝0ae10a1639005479b699815bd4a21050；

然后，通过第二组签名参数组合A2(签名算法SHA1和密钥KEY2)对第一签名结果进行加密，得到第二签名结果：

sign＝sha1(0ae10a1639005479b699815bd4a21050KEY2)＝b4b4b9886b58972483a8580af9349a05b506f161；

接着，通过第三组签名参数组合A3(签名算法SHA256和密钥KEY3)对第二签名结果进行加密，得到最终签名结果：

sign＝sha256(b4b4b9886b58972483a8580af9349a05b506f161KEY3)＝03592d71e1713bfe2c8345b973527681903d65f6d762e95f0e63439a661f2cdb；

此时，客户端通过前述三组签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密，得到最终签名结果，最终签名结果即为03592d71e1713bfe2c8345b973527681903d65f6d762e95f0e63439a661f2cdb。

由此可见，通过至少两组的签名参数组合实现签名加密，使得攻击者在试图篡改客户端请求时需破译全部签名算法，从而提升了篡改客户端请求复杂度，提升了信息签名方法的安全性，进而提升了签名信息的验证方法的安全性。

S208：客户端发送最终签名结果服务器端；

在本实施例中，客户端得到最终签名结果后，将最终签名结果发送至服务器端，以实现通过服务器端对最终签名结果进行验证，从而增加签名信息验证的安全性。

进一步地，客户端还发送初始待签名信息至服务器端，从而能够通过初始待签名信息标记最终签名结果，以便于服务器端得知所获得的最终签名结果的来源。

S209：服务器端获取至少两组签名参数组合和初始待签名信息；

在本实施例中，服务器端获取至少两组签名参数组合和初始待签名信息，其中，每组签名参数组合分别包括签名算法和密钥，签名算法和密钥用于对待签名信息进行签名加密，初始待签名信息即为初始待加密信息。并且，服务器端所获取的至少两组签名参数组合和初始待签名信息，应当与客户端所获取的至少两组签名参数组合和初始待签名信息的一致，从而才能实现通过服务器端对最终签名结果进行验证。

具体地，服务器端所获取的初始待签名信息即为客户端身份标识信息，从而服务器端根据所获取的初始待签名信息，即可获取前述步骤中生成且发送至客户端的至少两组签名参数组合，从而使得客户端与服务器端能够通过相同的至少两组签名参数组合对待签名信息进行签名加密。

S210：服务器端将各签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密，得到目标签名结果；

在本实施例中，服务器端获取至少两组签名参数组合和初始待签名信息后，于服务器端再次将各签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密，直至遍历所有签名参数组合，得到目标签名结果。服务器端的签名加密过程应当与步骤S207所阐述的客户端的加密过程相同，从而服务器端能够得到对初始待签名信息进行加密，得到未被篡改的目标签名结果，以便于对最终签名结果进行验证。

以下结合上述步骤中获取三组签名参数组合的举例进行阐述：

与客户端所获取的三组签名参数组合相同，分别为签名参数组合A1、签名参数组合A2以及签名参数组合A3，第一预定顺序为依次执行签名参数组合A1、签名参数组合A2以及签名参数组合A3。

具体地，签名参数组合A1所包括的签名算法为MD5，对应的密钥为KEY1；

签名参数组合A2所包括的签名算法为SHA1，对应的密钥为KEY2；

签名参数组合A3所包括的签名算法为SHA256，对应的密钥为KEY3。

首先，服务器端获取初始待签名信息，初始待签名信息即为前述步骤中用于指示客户端身份的身份标识信息；其次，通过第一组签名参数组合A1(签名算法MD5和密钥KEY1)对初始待签名信息进行签名加密，得到第一签名结果；然后，通过第二组签名参数组合A2(签名算法SHA1和密钥KEY2)对第一签名结果进行加密，得到第二签名结果；接着，通过第三组签名参数组合A3(签名算法SHA256和密钥KEY3)对第二签名结果进行加密，得到最终签名结果。

S211：服务器端判断所述最终签名结果是否匹配目标签名结果；

在本实施例中，若服务器端判断最终签名结果匹配目标签名结果，则执行步骤S212；若服务器端判断最终签名结果不匹配目标签名结果，则流程结束。

服务器端得到目标签名结果后，将判断最终签名结果是否匹配目标签名结果，从而根据判断结果做出自主响应行为，提高信息签名加密的安全性。

具体地，若最终签名结果匹配目标签名结果，则认为服务器端获取的最终签名结果未被攻击者篡改，即为客户端所发送的最终签名结果，可以执行后续步骤。若最终签名结果不匹配目标签名结果，则认为服务器端获取的最终签名结果已被攻击者篡改，此时服务器端所获取的“最终签名结果”并非客户端所发送的最终签名结果，故不执行后续步骤，流程结束。

其中，最终签名结果的内容与目标签名结果中相应内容一致，可以认为最终签名结果与目标签名结果相匹配，在此不做限定。

进一步地，服务器端还判断设备唯一标识是否匹配目标设备唯一标识，以及判断当前时间点至时间戳对应的时间的间隔是否超过预设时长。以当服务器端判断设备唯一标识匹配目标设备唯一标识，并且当前时间点至时间戳对应的时间的间隔未超过预设时长时，执行步骤S212，从而对所获取的最终签名结果进一步地进行确认，进而提高信息签名加密的安全性。

具体地，客户端的设备唯一标识包含在初始待签名信息内，用于指示客户端设备，不同的客户端设备其所具有的客户端的设备唯一标识应当不同。目标设备唯一标识由服务器端根据客户端的身份标识信息而确定，通过判断设备唯一标识和目标设备标识是否匹配，以判断服务器端所获取的最终签名结果是否来自客户端。可选地，设备唯一标识匹配目标设备唯一标识可以表现为，设备唯一标识与目标设备唯一标识一致。

并且，服务器端还会判断当前时间点至时间戳对应的时间的间隔超过预设时长，从而保证最终签名结果的时效性，避免最终签名结果被滥用，并降低最终签名结果被篡改的可能性。

S212：验证通过；

在本实施例中，当服务器端判断最终签名结果匹配目标签名结果，并且设备唯一标识匹配目标设备唯一标识，以及当前时间点至时间戳对应的时间的间隔未超过预设时长时，则认为最终签名结果未被攻击者篡改，服务器端判定验证通过，从而服务器端与客户端之间能够执行正常的业务逻辑。

综上所述，本实施例所提供的签名信息的验证方法，客户端获取至少两组签名参数组合，通过多组签名算法和密钥对初始待签名信息进行加密，攻击者试图篡改任意请求时需要破击所有的签名算法，从而提高信息签名加密的安全性。

进一步地，不同的客户端的类型信息以及版本信息所获取的签名参数组合也并不相同，独立使用相对应的签名参数组合对初始待签名信息进行加密，并且签名参数组合分散位置不同，即使某一客户端版本的签名算法泄露或被破译，不会对其他版本、类型的客户端造成负面影响。

再进一步地，通过在签名信息的验证方法过程中引入时间戳，使得最终签名结果与客户端强相关且具有失效性，最终签名结果只能一个设备以及一定时间内使用，以此避免签名结果被滥用的情况发生。

请参阅图3，图3是本发明客户端获取签名参数的方法一实施例的流程示意图。

如步骤S207的具体实施方式中所阐述的，部分签名参数组合中签名算法需从服务器端获取签名参数，以下进行详细阐述。需要说明的是，本实施例所阐述的客户端获取签名参数的方法是上述实施例步骤S207中进行客户端获取签名参数的方法的一个示例性实施例，其并不局限于以下步骤：

S2071：客户端发送签名参数请求至服务器端；

在本实施例中，当签名算法需要获取签名参数时，客户端发送签名参数请求至服务端，以通过服务器端对签名参数请求做出自主响应，从而服务器端能够介入信息签名过程，以增强信息签名过程的可靠性。

S2072：服务器端响应于签名参数请求，判断签名参数请求是否处于异常状态；

在本实施例中，若签名参数请求处于异常状态，则执行步骤S2073；若签名参数请求未处于异常状态，则执行步骤S2074。

客户端发送签名参数请求至服务器端后，服务器端响应于签名参数请求，服务器端判断签名参数请求是否处于异常状态。

具体地，本实施例具有完整的判断签名参数请求是否处于异常状态的判断机制，服务器端可以对客户端发送签名参数请求的频率、客户端发送签名参数请求的时间端以及当前客户端是否已经处于黑名单内等进行判断，以对签名参数请求是否处于异常状态进行判断。

举例而言，当攻击者对签名进行破译时，其需要不断地发送签名参数请求以进行验证，当发送签名请求的频率较高时，可以认为此时攻击者在破译签名算法；客户端发送签名参数请求的时间端与平时存在较大时间差时，也可以认为是攻击者在破译签名算法，此时由服务器端做出自主响应行为。

需要说明的是，服务器端判断签名参数请求是否处于异常状态并非是单一地依托于其中一种条件，而是相应建立完善的判断机制，以对签名参数请求的状态进行较为客观的判断，提升判断结果的准确性，避免在用户发送签名参数请求时产生误判，影响用户的正常使用。

S2073：将错误的签名参数或地址信息反馈客户端，或对签名参数请求不予处理；

在本实施例中，若服务器端判断签名参数请求处于异常状态，则服务器端将错误的签名参数或地址信息反馈客户端，从而服务器端能够介入信息签名的过程中，对签名参数请求异常的客户端发送误导性的结果，从而能够发送错误的相关信息至攻击者，避免攻击者发现服务器已察觉到自身被攻击，使得攻击者有所警觉，同时还能够增加攻击者的理解成本，提高信息签名加密的安全性。或对签名参数请求不予处理，流程结束。

S2074：将签名参数请求对应的签名参数反馈客户端，或将存储签名参数的地址信息反馈客户端；

在本实施例中，若服务器端判断签名参数请求未处于异常状态，则服务器端将签名参数请求对应的签名参数反馈客户端，或将存储签名参数的地址信息反馈客户端，以促使签名算法能够继续执行。

可选地，存储签名参数的地址信息可以是URL(Uniform Resource Locator,统一资源定位器)信息，URL为信息资源统一的且在网上唯一的地址。

S2075：客户端接收签名参数或接收地址信息；

在本实施例中，服务器端将签名参数请求对应的签名参数反馈客户端，或将存储签名参数的地址信息反馈客户端后，客户端接收相应的签名参数或地址信息，并获取相应的签名参数，从而签名算法能够被正确执行，通过签名参数组合或相应的签名参数对待加密信息进行加密，进而提高信息加密过程的安全性。

请参阅图4，图4是本发明信息签名方法一实施例的流程示意图。

需要说明的是，本实施例的执行主体为客户端，客户端能够实现信息签名，以下对信息签名方法一实施例的具体实施方式进行详细阐述，但本实施例所阐述的信息签名方法并不局限于以下步骤：

S401：获取至少两组签名参数组合以及初始待签名信息；

在本实施例中，客户端获取至少两组签名参数以及初始待签名信息，其中，每组签名参数组合分别包括签名算法和密钥，签名算法和密钥用于对待签名信息进行签名加密，初始待签名信息即为初始待加密信息，从而减少客户端获取信息并进行处理的负担。

S402：将各签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密，直至遍历所有签名参数组合，得到最终签名结果；

在本实施例中，客户端获取至少两组签名参数组合以及初始待签名信息后，客户端将各签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密，直至遍历所有签名参数组合，得到最终签名结果，从而增加信息签名方法的安全性，增加攻击者破译的复杂度。其中，每次签名加密得到的签名结果作为下一次签名加密的待签名信息，以减少客户端加密的数据处理量。

S403：将最终签名结果发送至服务器端；

在本实施例中，客户端得到最终签名结果后，将最终签名结果发送至服务器端，从而服务器端能够同步获取客户端的最终签名结果，进而能够通过服务器端实现签名信息的验证。

请参阅图5，图5是本发明签名信息的验证方法第三实施例的流程示意图。

需要说明的是，本实施例的执行主体为服务器端，服务器端能够实现签名信息的验证，以下对签名信息的验证方法第三实施例的具体实施方式进行详细阐述，但本实施例所阐述的签名信息的验证方法并不局限于以下步骤：

S501：接收客户端发送的最终签名结果；

在本实施例中，服务器端接收客户端发送的最终签名结果，该最终签名结果即为签名信息验证的对象，从而根据验证结果自主做出响应行为。

S502：获取至少两组签名参数组合和初始待签名信息；

在本实施例中，服务器端还需要获取至少两组签名参数组合和初始待签名信息。其中，每组签名参数组合分别包括签名算法和密钥，签名算法和密钥用于对待签名信息进行签名加密，初始待签名信息即为初始待加密信息。并且，服务器端所获取的至少两组签名参数组合和初始待签名信息，应当与客户端所获取的至少两组签名参数组合和初始待签名信息的一致，从而才能实现通过服务器端对最终签名结果进行验证。

S503：将各签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密，直至遍历所有签名参数组合，得到目标签名结果；

在本实施例中，服务器端获取至少两组签名参数组合和初始待签名信息后，于服务器端再次将各签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密，直至遍历所有签名参数组合，得到目标签名结果。服务器端的签名加密过程应当与前述实施例中步骤S402中所阐述的客户端的加密过程相同，从而服务器端能够得到对初始待签名信息进行加密，得到未被篡改的目标签名结果，以便于对最终签名结果进行验证。

S504：判断最终签名结果是否匹配目标签名结果；

在本实施例中，服务器端得到目标签名结果后，则判断从客户端所获取的最终签名结果是否匹配目标签名结果，从而根据判断结果做出自主响应行为，提高信息签名加密的安全性。

S505：若是，则判定验证通过；

在本实施例中，若服务器端判断最终签名结果与目标签名结果相匹配，可以认为最终目标结果未被攻击者破译及篡改，则判定验证通过，故服务器端与客户端可以继续执行正常的业务逻辑。

其中，最终签名结果的内容与目标签名结果中相应内容一致时，可以认为最终签名结果与目标签名结果相匹配，在此不做限定。

请参阅图6，图6是本发明签名信息的验证方法第四实施例的流程示意图。

需要说明的是，在本实施例中，签名信息的验证方法的实施主体为客户端与服务器端所构成的系统，以下对签名信息的验证方法第四实施例的具体实施方式进行详细阐述，但本实施例所阐述的签名信息的验证方法并不局限于以下步骤：

S601：客户端获取至少两组签名参数组合以及初始待签名信息；

在本实施例中，客户端预先获取至少两组签名参数组合以及初始待签名信息，其中，每组签名参数组合分别包括签名算法和密钥，签名算法和密钥用于对待签名信息进行签名加密，初始待签名信息即为初始待加密信息，从而减少客户端获取信息并进行处理的负担。具体实施方式与前述实施例的实施方式相似，在此就不再赘述。

可选地，签名算法可以是对称加密算法等，从而服务器端能够通过与签名算法对应的解密算法进行解密。

举例来说，客户端获取三组签名参数组合，分别为签名参数组合A1、签名参数组合A2以及签名参数组合A3，签名参数组合A1包括签名算法X1以及密钥Y1，签名参数组合A2包括签名算法X2以及密钥Y2，签名参数组合A3包括签名算法X3以及密钥Y3。

S602：客户端将各签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密，直至遍历所有签名参数组合，得到最终签名结果；

在本实施例中，客户端获取至少两组签名参数组合以及初始待签名信息后，客户端将各签名参数组合按照第一预定顺序逐一对初始待签名信息进行签名加密，直至遍历所有签名参数组合，得到最终签名结果，从而增加信息签名方法的安全性，增加攻击者破译的复杂度。其中，每次签名加密得到的签名结果作为下一次签名加密的待签名信息，以减少客户端加密的数据处理量。

基于步骤S601的举例进行解释说明，第一预定顺序依次为依次执行签名参数组合A1、签名参数组合A2、签名参数组合A3，即依次通过签名算法X1以及密钥Y1、签名算法X2以及密钥Y2、签名算法X3以及密钥Y3对待加密信息进行加密。

S603：客户端将最终签名结果发送至服务器端；

在本实施例中，客户端得到最终签名结果后，将最终签名结果发送至服务器端，以实现通过服务器端对最终签名结果进行验证，从而增加签名信息验证的安全性。

S604：服务器端获取至少两组解密参数组合和初始待签名信息；

在本实施例中，服务器端获取至少两组解密参数组合和初始待签名信息，其中解密参数组合与签名参数组合一一对应，并且每组解密参数组合分别包括解密算法和密钥，每组解密参数组合的解密算法和密钥用于对应签名参数组合的签名结果的解密。

并且，服务器端所获取的初始待签名信息，应当与客户端所获取的初始待签名信息的一致，从而才能实现通过服务器端对初始待签名信息进行验证。

S605：服务器端将各解密参数组合按照第二预定顺序逐一对最终签名结果进行解密，直至遍历所有参数解密组合，得到目标解密信息；

在本实施例中，服务器端获取至少两组解密参数组合和初始待签名信息后，服务器端将各解密参数组合按照第二预定顺序逐一对最终签名结果进行解密，直至遍历所有参数解密组合，得到目标解密信息。

其中，每次解密得到的解密信息作为下一次签名解密的待解密信息，相当于逆向重复步骤S602的过程。

具体地，第二预定顺序中解密参数组合的执行顺序，为第一预定顺序中相对应签名参数组合的执行顺序的逆序，即解密参数组合中的解密算法的执行顺序对应签名参数组合中该签名算法的执行顺序的逆序。

以下结合上述步骤的举例进行阐述：

与签名参数组合A1、签名参数组合A2以及签名参数组合A3相对应的解密参数组合分别为：解密参数组合B1、解密参数组合B2以及解密参数组合B3，具体如下：

解密参数组合B1：解密算法x1，密钥Y1，其中解密算法x1是签名算法X3对应的解密算法；

解密参数组合B2：解密算法x2，密钥Y2，其中解密算法x2是签名算法X2对应的解密算法；

解密参数组合B3：解密算法x3，密钥Y3，其中解密算法x3是签名算法X1对应的解密算法。

其中，第二预定顺序为依次执行解密参数组合B1、解密参数组合B2、解密参数组合B3。

举例而言，当所选用的签名算法为对称加密算法时，则对应解密参数组合即为相同的对称加密算法和密钥，从而第二预定顺序为依次执行解密参数组合B1、解密参数组合B2、解密参数组合B3，即依次通过解密算法x1以及密钥Y1、解密算法x2以及密钥Y2、解密算法x3以及密钥Y3对待解密信息进行解密，从而减少计算量小、提升解密速度以及解密效率。

S606：服务器端判断目标解密信息是否匹配初始待签名结果；

在本实施例中，服务器端得到目标解密信息后，则判断目标解密信息是否匹配初始待签名结果，从而根据判断结果做出自主响应行为，提高信息签名加密的安全性。

S607：若是，则判定验证通过；

在本实施例中，若服务器端判断目标解密信息匹配初始待签名信息，可以认为最终目标结果未被攻击者破译及篡改，则判定验证通过，故服务器端与客户端可以继续执行正常的业务逻辑。

其中，目标解密信息与初始待签名信息中相应内容一致时，可以认为目标解密信息与初始待签名信息相匹配，在此不做限定。

请参阅图7，图7是本发明签名信息的验证方法第五实施例的流程示意图。

需要说明的是，本实施例的执行主体为服务器端，未对客户端的信息签名方法再进行举例说明的原因在于，客户端的信息签名方法与前述实施例中所阐述的方法相同，在此就不再赘述。以下对签名信息的验证方法第五实施例的具体实施方式进行详细阐述，但本实施例所阐述的签名信息的验证方法并不局限于以下步骤：

S701：接收客户端发送的最终签名结果；

在本实施例中，服务器端接收客户端发送的最终签名结果，通过对最终签名结果进行处理而对签名信息进行验证，从而根据验证结果自主做出响应行为。

S702：获取至少两组解密参数组合和初始待签名信息；

在本实施例中，服务器端获取至少两组解密参数组合和初始待签名信息，其中解密参数组合与签名参数组合一一对应，并且每组解密参数组合分别包括解密算法和密钥，每组解密参数组合的解密算法和密钥用于对应签名参数组合的签名结果的解密。

并且，服务器端所获取的初始待签名信息，应当与客户端所获取的初始待签名信息的一致，从而才能实现通过服务器端对初始待签名信息进行验证。

S703：将各解密参数组合按照第二预定顺序逐一对最终签名结果进行解密，直至遍历所有解密参数组合得到目标解密信息；

在本实施例中，服务器端获取至少两组解密参数组合和初始待签名信息后，服务器端将各解密参数组合按照第二预定顺序逐一对最终签名结果进行解密，直至遍历所有参数解密组合，得到目标解密信息。

具体地，第二预定顺序中解密参数组合的执行顺序，为第一预定顺序中相对应签名参数组合的执行顺序的逆序，即解密参数组合中的解密算法的执行顺序对应签名参数组合中该签名算法的执行顺序的逆序。

S704：判断目标解密信息是否匹配初始待签名信息；

在本实施例中，服务器端得到目标解密信息后，则判断目标解密信息是否匹配初始待签名结果，从而根据判断结果做出自主响应行为，提高信息签名加密的安全性。

S705：若是，则判定验证通过；

在本实施例中，若服务器端判断目标解密信息匹配初始待签名信息，可以认为最终目标结果未被攻击者破译及篡改，则判定验证通过，故服务器端与客户端可以继续执行正常的业务逻辑。

综上所述，本发明提供的签名信息的验证方法，客户端获取至少两组签名参数组合，通过多组签名算法和密钥对初始待签名信息进行加密，攻击者试图篡改任意请求时需要破击所有的签名算法，从而提高信息签名加密的安全性。

进一步地，不同的客户端的类型信息以及版本信息所获取的签名参数组合也并不相同，独立使用相对应的签名参数组合对初始待签名信息进行加密，并且签名参数组合分散位置不同，即使某一客户端版本的签名算法泄露或被破译，不会对其他版本、类型的客户端造成负面影响。

并且，通过在签名信息的验证方法过程中引入时间戳，使得最终签名结果与客户端强相关且具有失效性，最终签名结果只能一个设备以及一定时间内使用，以此避免签名结果被滥用的情况发生。

再进一步地，服务器端能够介入信息签名的过程中，对签名参数请求异常的客户端发送误导性的结果，能够在迷惑攻击者的同时增加攻击者的理解成本，进一步提高信息签名加密的安全性。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。