总结数字签名实现身份验证

article/2025/9/18 18:18:45

消息篡改和不可抵赖性

TCP协议确保数据能够正确发送到通信双方，加上数据加密算法保证数据安全传输，但是在HTTP应用中通信双方通常不清楚发送方的身份，尤其在客户端服务器通信下，通常一个服务器会处理多个客户端连接，结合前一篇日志讲到的密钥协商，对于服务器来说，它不需要知道客户端是谁，在建立连接，协商好密钥后，只要接收到的HTTP请求格式正确，数据解密无误后便会发送相应信息，对于客户端来说也是一样。表面上来看，客户端和服务器端只要数据能对应加密解密，正确，安全地发送到对方处，似乎就没什么问题。没错，数据加密保证了数据的机密性，消息验证码MAC算法保证了数据的完整性，接收方能够确保接收到的数据是发送方的原始数据，没有被篡改过，但是没有解决的问题是身份验证问题，无法确保和你通信的，发送数据的对方，是你正确的通信对象，这会出现的一个问题就是，第三方可以冒充你的通信方，给你发送消息。

在对称加密中，如果密钥泄露了，那么别人就可以使用你们的密钥进行加密解密，或者冒充通信方给你发消息，当你收到一条消息后，使用密钥解密，解出可读可理解的明文时，你可能就会误认为这条消息就是你的目标通信方发来的。在公开密钥算法下，公钥参数甚至可以是公开的，不需要对其做任何保护，在使用如DH密钥协商算法时，目的是协商出解密私钥，即使公钥，p，g等参数泄露了也没关系。公钥只是加密时采用到，这就导致了由于公钥公开，任何人都可以使用它来进行加密，并给你发送消息。

总的来说，如果不去验证消息发送方的身份，会出现两个问题：消息篡改和消息抵赖。消息篡改，假设A和B共享密钥进行通信，过程中由于密钥泄露，被C截获了，C就可以使用密钥进行加密解密，给A和B发送消息，无论是A和B，只要收到消息，就进行解密，如果解密出可读可理解的明文，就容易误认为该消息就是对方发来的，殊不知这条消息其实是经过C篡改过，甚至是C无中生有捏造的。

消息抵赖问题，即无论假设A，B和C三方进行共同通信，共享相同的密钥，A给C发送了一条消息后，A可以抵赖说这条消息不是他发送的，因为B也有共同的密钥，B也可以给C发送消息。对于C来说，他确实无法确认该加密数据是来自A还是来自B，因为他们都共同拥有密钥。相似的情况还有，假如A给C发送了一条消息，但是C无法向B证明这条消息是来自于A的，对于B来说，由于C也拥有密钥，该消息可能是C自己使用密钥加密来的，C无法像B证明消息的来源。

出现上述的消息篡改和消息抵赖性问题，原因都在于通信的一方无法确定消息发送方的身份，所以除了进行消息加密，消息验证外，还需要解决的问题，是身份验证。

数字签名-验证过程

数字签名算法和消息验证码类似，消息验证码完成消息验证，数字签名完成身份验证。在消息验证码MAC算法中，通信双方使用共同的密钥对消息进行MAC运算生成唯一的摘要值，然后与消息一起发送，接收方接收到数据后，先使用相同的密钥对消息进行MAC运算得到摘要值，然后与一同发送来的摘要值比较，相同则表示MAC验证正确。数字签名类似，拿公开密钥RSA算法来举例，客户端拥有自己的私钥和服务器端的公钥，服务器端拥有自己的私钥和客户端的公钥，那么对于双方来说，什么东西可以唯一标识自己？就是他们各自持有的私钥，客户端可以用自己的私钥“签名”一条消息，然后发送给服务器端，服务器端拥有客户端的公钥，可以反解出该消息，由于这条消息是使用服务器端的私钥“签名“的，服务器端的私钥从来没有公开过，发送过出去，所以服务器端无法抵赖说这条消息不是来自他的。

生成签名

拿公开密钥RSA算法举例，生成签名的过程总结如下：

对消息进行Hash运算（如SHA-256）得到摘要值。
发送方使用自己的私钥对摘要值进行“签名“运算，得到签名值。
将原始信息和签名值一起发送给接收者。

验证签名

接收方收到信息后，首先验证签名：

对数据拆分出原始消息和签名值。
接收方使用自己的公钥对签名值进行签名算法运算，得到摘要值。
再对原始消息进行Hash运算得到另一个摘要值。
最后比较两个摘要值是否相等，相等则表明信息来自对方，无法抵赖。

RSA数字签名

RSA公开密钥在密钥协商完成后，使用公钥进行加密，私钥进行解密。而上面的流程图可以看到，在数字签名里，私钥用来签名消息，公钥用来验证签名。虽然这样做任何拥有公钥的人都可以验证这个消息，但是没关系，数字签名是用来做身份验证的，防抵赖，目的是验证发送方的身份，防止其发送了消息后又抵赖这消息不是他发出的，所以，任何人可以验证消息签名也不会造成什么影响。