证书与签名（二）：数字签名流程与签名认证流程

1. 数字签名的流程：

发方将原文用哈希算法求得数字摘要，用签名私钥对数字摘要加密得数字签名，发方将原文与数字签名一起发送给接受方。
数字签名的操作过程需要有发方的签名数字证书的私钥及其验证公钥。具体过程如下：首先是生成被签名的电子文件（《电子签名法》中称数据电文），然后对电子文件用哈希算法做数字摘要，再对数字摘要用签名私钥做非对称加密，即做数字签名；之后是将以上的签名和电子文件原文以及签名证书的公钥加在一起进行封装，形成签名结果发送给收方，待收方验证。

2. 数字签名的认证流程：

接收方收到数字签名的结果，其中包括数字签名、电子原文和发方公钥，即待验证的数据。接收方进行签名验证。验证过程是：接收方首先用发方公钥解密数字签名，导出数字摘要，并对电子文件原文作同样哈希算法得一个新的数字摘要，将两个摘要的哈希值进行结果比较，结果相同签名得到验证，否则签名无效。这就作到了《电子签名法》中所要求的对签名不能改动，对签署的内容和形式也不能改动的要求。
　　

3. 解决第三方攻击情况：

如果利用非对称加密算法进行双方通信，会引入第三方攻击。比如有通信双方A和B，A和B的公钥大家都可以得到。
A主动和B通信，先获取B的公钥：
A –>B，用B的公钥加密，并且把自己的公钥附在后面。
B –>A , B接收到后，同时也获取A的公钥，用A的公钥加密发送回A。
这样就可以防止第三者监听发送者的内容。但问题是无法解决第三者攻击，比如中间有一个M，M冒充A给B发送内容。
事实上无法解决对方到底是谁的问题！

解决方法是发送内容进行二次加密，并且通讯双方有可靠的途径知道对方的公钥：
A发送给B时候，先用A的私钥加密，然后再用B的公钥加密。
B收到后，先用B的私钥解密，再用A的公钥解密，得到明文。

获取公钥的可靠途径不一样，就可以有不容的实现方式：
1. 通信双方事先有对方的公钥，这种方法比较麻烦，要面对面交换。显然不适合大规模应用，用在夫妻之间到是比较好的！
2. 第三方的数字签名，这个就比较好了，大家都把公钥放在第三方CA那里，通信发起方问CA要双方的公钥，并传给对方。

比如A发起请求给B。 A先去第三放CA那边请求B的公钥，CA返回给A后，A用私钥加密后并用B的公钥加密HASH值后，发送给B。B收到后，先用自己的私钥解密，再传给CA解密，解密后传回给B。B由此知道A的公钥，同时也可以验证A传过的来的自己的公钥对不对。

中间人攻击不可能了：无法冒充A了，B无法用A的公钥解开任何冒充A的中间人。
A抵赖不可能：B收到后，出示加密后的报文即可，只有A有自己的私钥。
B不能说没收到：去过第三方了，或者已经A把收到的B过来过的报文出示就行，因为只有B自己有私钥。

Java代码实现：http://blog.csdn.net/lijiecong/archive/2011/04/21/6337932.aspx

4. 参考：

http://blog.csdn.net/lijiecong/article/details/6096289
http://blog.csdn.net/zh521zh/article/details/51819950
https://zhidao.baidu.com/question/560323951.html