两种密钥协商和交换的方法及解析

        进行安全通信之前，各用户间需要确立加密程序的细节，尤其是密钥。在对称密钥加密系统，各用户间需要确立共同使用的单一密钥，此步骤即密钥交换。交换对称密钥必须透过另一安全的通信管道进行；否则，如果以明文形式在网络发送，将使窃听者能够立即得知密钥以及据其加密的数据。以前，交换密称密钥是非常麻烦的，可能需要使外交邮袋等安全渠道。

         公开密钥加密的出现大大减轻了交换对称密钥的困难，公钥可以公开（透过不安全、可被窃听的渠道）发送，用以加密明文。不过，公钥加密在在计算上相当复杂，性能欠佳、远远不比对称加密。

         因此，在一般实际情况下，往往通过公钥加密来随机创建临时的对称秘钥，亦即对话键，然后才通过对称加密来传输大量、主体的数据。（也叫混合加密算法）

密钥交换/协商机制的几种类型

• 依靠非对称加密算法

• 原理：拿到公钥的一方先生成随机的会话密钥，然后利用公钥加密它；再把加密结果发给对方，对方用私钥解密；于是双方都得到了会话密钥。

• 举例：RSA

• 依靠专门的密钥交换算法

• 原理：这个原理比较复杂，一两句话说不清楚，待会儿聊到 DH 的那个章节会详谈。

• 举例：DH 算法及其变种（ECDH算法）

基于 RSA 的密钥协商

概述：这大概是 SSL 最古老的密钥协商方式——早期的 SSLv2 只支持一种密钥协商机制。

RSA 是一种【非】对称加密算法。特点是：加密和解密用使用【不同的】密钥。

并且“非对称加密算法”既可以用来做“加密/解密”，还可以用来做“数字签名”。

密钥协商的步骤

1. 客户端连上服务端
2. 服务端发送 CA 证书给客户端
3. 客户端验证该证书的可靠性
4. 客户端从 CA 证书中取出公钥
5. 客户端生成一个随机密钥 k，并用这个公钥加密得到 k’
6. 客户端把 k’ 发送给服务端
7. 服务端收到 k’ 后用自己的私钥解密得到 k
8. 此时双方都得到了密钥 k，协商完成

如何防范偷窥（嗅探）

• 攻击方式1

  攻击者虽然可以监视网络流量并拿到公钥，但是【无法】通过公钥推算出私钥（这点由 RSA 算法保证）

• 攻击方式2

  攻击者虽然可以监视网络流量并拿到 k’，但是攻击者没有私钥，【无法解密】 k’，因此也就无法得到 k

如何防范篡改（假冒身份）

• 攻击方式1

  如果攻击者在第2步篡改数据，伪造了证书，那么客户端在第3步会发现（这点由证书体系保证）

• 攻击方式2

  如果攻击者在第6步篡改数据，伪造了k’，那么服务端收到假的k’之后，解密会失败（这点由 RSA 算法保证）。服务端就知道被攻击了。

基于 DH 的密钥协商

概述：DH 算法又称“Diffie–Hellman 算法”。这是两位数学牛人的名称，他们创立了这个算法。该算法用来实现【安全的】“密钥交换”。它可以做到——“通讯双方在完全没有对方任何预先信息的条件下通过不安全信道创建起一个密钥”。这句话比较绕口，通俗地说，可以归结为两个优点：

1. 通讯双方事先【不】需要有共享的秘密。
2. 用该算法协商密码，即使协商过程中被别人全程偷窥（比如“网络嗅探”），偷窥者也【无法】知道协商得出的密钥是啥。

但是 DH 算法本身也有缺点——它不支持认证。

也就是说：它虽然可以对抗“偷窥”，却无法对抗“篡改”，自然也就无法对抗“中间人攻击/MITM”（前一篇已经强调过——缺乏身份认证，【必定会】遭到“中间人攻击/MITM”）。

为了避免遭遇 MITM 攻击，DH 需要与其它签名算法（比如 RSA、DSA、ECDSA）配合——靠签名算法帮忙来进行身份认证。当 DH 与 RSA 配合使用，称之为“DH-RSA”，与 DSA 配合则称为“DH-DSA”，以此类推。

反之，如果 DH 【没有】配合某种签名算法，则称为“DH-ANON”（ANON 是“anonymous”（匿名）的简写）。此时会遭遇“中间人攻击/MITM”。

关于该算法具体数学原理，可以参见迪菲-赫尔曼密钥交换。

密钥协商的步骤

1. 客户端先连上服务端
2. 服务端生成一个随机数 s 作为自己的私钥，然后根据算法参数计算出公钥 S（算法参数通常是固定的）
3. 服务端使用某种签名算法把“算法参数（模数p，基数g）和服务端公钥S”作为一个整体进行签名
4. 服务端把“算法参数（模数p，基数g）、服务端公钥S、签名”发送给客户端
5. 客户端收到后验证签名是否有效
6. 客户端生成一个随机数 c 作为自己的私钥，然后根据算法参数计算出公钥 C
7. 客户端把 C 发送给服务端
8. 客户端和服务端（根据上述 DH 算法）各自计算出 k 作为会话密钥

如何防范偷窥（嗅探）

嗅探者可以通过监视网络传输，得到算法参数（模数p，基数g）以及双方的公钥，但是【无法】推算出双方的私钥，也【无法】推算出会话密钥（这是由 DH 算法在数学上保证的）

如何防范篡改（假冒身份）

• 攻击方式1

  攻击者可以第4步篡改数据（修改算法参数或服务端公钥）。但因为这些信息已经进行过数字签名。篡改之后会被客户端发现。

• 攻击方式2

  攻击者可以在第7步篡改客户端公钥。这步没有签名，服务端收到数据后不会发现被篡改。但是，攻击者篡改之后会导致“服务端与客户端生成的会话密钥【不一致】”。在后续的通讯步骤中会发现这点，并导致通讯终止。

  （协议初始化/握手阶段的末尾，双方都会向对方发送一段“验证性的密文”，这段密文用各自的会话密钥进行【对称】加密，如果双方的会话密钥不一致，这一步就会失败，进而导致握手失败，连接终止）