公开密钥算法的另外一个用途就是数字签名技术，数字签名技术很重要，是因为截止目前，我们已经实现了密码学的前两个目标：
-
（1）机密性
-
（2）完整性
-
（3）身份验证和不可抵赖性
但尚未实现身份认证和防抵赖这个目标，本篇文章来谈谈数字签名技术是如何实现此目标的。
一、数字签名的用途
先说明消息为什么可能被篡改，比如A、B、C三个人共享一个对称加密算法密钥，现在A和B互相通信，A和B只认为是双方在发送消息。由于C有同样的密钥，它可以拦截A发往B的消息，然后篡改消息并用同样的密钥加密后发送给B，B能够正确解密，但是该消息其实已经被篡改。
接下来解释为什么不能防止抵赖，还是用同样的例子说明，A、B、C三个人共享一个对称加密算法密钥，A向B发送了一条消息，但是A可以抵赖说这条消息并不是他发送的，理由就是C有同样的密钥，这条加密消息可能是C发送给B的，B也无法向第三方证明就是A给他发送了这条消息。
抵赖出现的根本原因就在于通信双方无法确认对方的身份，也就不能进行身份验证，那么在密码学中有没有对应的解决方案呢？可以使用数字签名技术防抵赖。
如何来做的呢？古代认罪需要签字画押，因为指纹是唯一性，指纹可以并且只能代表这一个人。
回到密码学中，如果一个消息也含有特殊的指纹，那么它是否就不能抵赖呢？
比如公开密钥算法的典范RSA算法，私钥由生成者保管，若不考虑私钥泄露问题，私钥拥有者使用私钥签署一条消息（注意不是加密操作），然后发送给任意的接收方，接收方只要拥有对应的公钥，就可以反解出来签署的消息，由于只有私钥持有者才能“签署”消息，因此不能抵赖说这条签署消息不是他发送的。
这就是数字签名技术的基本思想。
二、数字签名的流程
生成签名的流程为：
-
发送者对消息计算摘要值；
-
发送者用私钥对摘要值进行签名得到签名值；
-
发送者将原始消息和签名值一同发给接收者；
签名验证流程为：
-
接收者接收到消息后，拆分出消息和消息签名值A；
-
接收者使用公钥对消息进行运算得到摘要值B；
-
接收者对摘要值B和签名值A进行比较，如果相同表示签名验证成功；
为什么不直接对消息进行签名，而是对消息的摘要值进行签名？
签名值除了比较之外并没有其他用途，那么基于消息生成签名和基于消息摘要值生成签名并无本质区别，但考虑到公开密钥算法运行是相对缓慢的，数字签名算法建议对消息摘要值进行签名，因为摘要值长度是固定的，运算速度会比较快。
公开密钥算法中的典型代表RSA用途十分广泛，可进行数字签名。
RSA在运用于加密时，RSA通过公钥加密、私钥解密，而在数字签名这里，RSA签名算法是私钥签名，公钥验证签名（简称验签）。
三、小小的总结
至此，我们实现了密码学的三个目标，分别如下：
-
我们可以使用公开密钥算法进行密钥协商，产生一个密钥；
-
接下来的内容即可借助此密钥完成数据加密和解密工作，且密钥为会话密钥，只在某个TCP连接中生效，一旦连接关闭，则此密钥将消失于内存中；
-
为了解决消息的完整性校验问题，我们引入了消息验证码MAC算法，此算法同样需要用到一个密钥，只有拥有密钥的通信双方才能生成和验证消息验证码；
-
为了实现身份验证和防抵赖，我们又引入了数字签名技术，这是公开密钥算法的另一个重要使用场景；
我们是不是已经完成了所有工作呢？到目前为止，只能说完成了一大半，因为有个极其恐怖的问题发生在密钥协商这一步，这一步一旦出问题，剩下的所有步骤都将不安全，包括对称加密和MAC算法，因为他们核心就是依靠协商出来的密钥，到底是什么问题呢？
那就是大名鼎鼎的中间人攻击问题，我们来仔细看下中间人是如何攻击的。
四、中间人攻击问题
通过RSA或者DH密钥协商算法 ，服务器需要提供一对密钥，将其公钥传输给对方，方案看起来已经很完美了，实际上却存在一个致命问题：中间人攻击问题。
所谓中间人攻击就是服务器传递给客户端的公钥可能被攻击者替换，这样安全性就荡然无存了。
下面用RSA密钥协商算法协商密钥的例子说明中间人攻击过程。
-
客户端向服务器端发起连接请求，期望获取服务器的RSA公钥，攻击者劫持了这个请求；
-
攻击者自己生成RSA密钥对，然后将攻击者的RSA公钥发送给客户端；
-
攻击者然后再向服务器端发送请求，服务器生成RSA密钥对，将RSA公钥发送给客户端，实际上是发送给攻击者；
-
客户端通过攻击者的公钥加密密钥块A并发送给服务器，实际上是发送给攻击者；
-
攻击者用自己的RSA私钥解密了密钥块A，然后自己生成一个密钥块B，用服务器的RSA公钥加密后发送给服务器端；
-
服务器端接收到请求后，用自己的RSA私钥解密出攻击者的密钥块B；
-
客户端使用密钥块A，采用AES算法加密数据并发送给服务器端，实际上是发送给攻击者；
-
攻击者知晓密钥块A，因此可以解密数据，并使用密钥块B做AES加密，发给服务端；
-
服务端使用密钥块B可以解密得到明文，并且给出回执的加密信息，此加密信息依然是服务端使用密钥块B做的AES加密内容，发给了攻击者；
-
攻击者使用密钥块B解密获取明文数据；
此时，攻击者同时可以解密客户端和服务端的加密数据，这就是大名鼎鼎的中间人攻击，是不是十分巧妙？
发生这个问题的关键是客户端无法确认服务端的真实身份，因此无法确定请求到的公钥是来自真实服务器还是第三方，如何解决这个难题呢？HTTPS的方案是引入PKI体系解决身份认证问题，而PKI技术的核心就是证书，而证书的验证核心是数字签名技术，我们下篇文章来浅谈浅谈PKI体系和证书那些事。
本文完，下篇见！
原文始发于微信公众号（幕后哈土奇）：六十九、进阶篇-浅谈数字签名技术和中间人攻击问题
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/113151.html
