密钥协商算法的演变 —— RSA算法 - DH算法 - DHE算法 - ECDHE算法

---

1. RSA算法

传统的 TLS 握⼿基本都是使⽤ RSA 算法来实现密钥交换的。在 RSA 密钥协商算法中，客户端会⽣成随机密钥，并使⽤服务端的公钥加密后再传给服务端。根据⾮对称加密算法，公钥加密的消息仅能通过私钥解密，这样服务端解密后，双⽅就得到了相同的密钥，再⽤它加密应⽤消息。

RSA握手过程

TLS第一次握手：

客户端⾸先会发⼀个「Client Hello」消息，消息⾥⾯有客户端使⽤的 TLS 版本号、⽀持的密码套件列表，以及⽣成的随机数（Client Random），这个随机数会被服务端保留，它是⽣成对称加密密钥的材料之⼀。

TLS第二次握手：

当服务端收到客户端的「Client Hello」消息后，会确认 TLS 版本号是否⽀持，和从密码套件列表中选择⼀个密码套件，以及⽣成随机数（Server Random）。

接着，返回「Server Hello」消息，消息⾥⾯有服务器确认的 TLS 版本号，也给出了随机数（Server Random），然后从客户端的密码套件列表选择了⼀个合适的密码套件。

可以看到，服务端选择的密码套件是 “Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256”。

这个密码套件看起来真让⼈头晕，好⼀⼤串，但是其实它是有固定格式和规范的。基本的形式是「密钥交换算法 +签名算法 + 对称加密算法 + 摘要算法」， ⼀般 WITH 单词前⾯有两个单词，第⼀个单词是约定密钥交换的算法，第⼆个单词是约定证书的验证算法。
⽐如刚才的密码套件的意思就是：由于 WITH 单词只有⼀个 RSA，则说明握⼿时密钥交换算法和签名算法都是使⽤ RSA；握⼿后的通信使⽤ AES 对称算法，密钥⻓度 128 位，分组模式是 GCM；摘要算法 SHA384 ⽤于消息认证和产⽣随机数；就前⾯这两个客户端和服务端相互「打招呼」的过程，客户端和服务端就已确认了 TLS 版本和使⽤的密码套件，⽽且你可能发现客户端和服务端都会各⾃⽣成⼀个随机数，并且还会把随机数传递给对⽅。

然后，服务端为了证明⾃⼰的身份，会发送「Server Certificate」给客户端，这个消息⾥含有数字证书。

随后，服务端发了「Server Hello Done」消息，⽬的是告诉客户端，我已经把该给你的东⻄都给你了，本次打招呼完毕。

【补充】：

CA 签发证书的过程：

• ⾸先 CA 会把持有者的公钥、⽤途、颁发者、有效时间等信息打成⼀个包，然后对这些信息进行 Hash 计算，得到⼀个 Hash 值；

• 然后 CA 会使⽤自己的私钥将该 Hash 值加密，⽣成 Certificate Signature，也就是 CA 对证书做了签名；

• 最后将 Certificate Signature 添加在⽂件证书上，形成数字证书；

客户端校验服务端的数字证书的过程：

• ⾸先客户端会使用同样的 Hash 算法获取该证书的 Hash 值 H1(数字摘要)；

• 通常浏览器和操作系统中集成了 CA 的公钥信息，浏览器收到证书后可以使⽤ CA 的公钥解密 Certificate

  Signature 内容，得到⼀个 Hash 值 H2(数字摘要)。

• 最后⽐较 H1 和 H2，如果值相同，则为可信赖的证书，否则则认为证书不可信。

TLS第三次握手：

客户端验证完证书后，认为可信则继续往下⾛。接着，客户端就会⽣成⼀个新的随机数 (pre-master预主秘钥)，⽤服务器的 RSA 公钥加密该随机数，通过「Change Cipher Key Exchange」消息传给服务端。

服务端收到后，⽤ RSA 私钥解密，得到客户端发来的随机数 (pre-master)。

⾄此，客户端和服务端双⽅都共享了三个随机数，分别是 Client Random、Server Random、pre-master。

于是，双⽅根据已经得到的三个随机数，⽣成会话密钥（Master Secret），它是对称密钥，⽤于对后续的 HTTP请求/响应的数据加解密。

⽣成完会话密钥后，然后客户端发⼀个「Change Cipher Spec」，告诉服务端开始使⽤加密⽅式发送消息。

然后，客户端再发⼀个「Encrypted Handshake Message（Finishd）」消息，把之前所有发送的数据做个摘要，再⽤会话密钥（master secret）加密⼀下，让服务器做个验证，验证加密通信是否可⽤和之前握⼿信息是否有被中途篡改过。

可以发现，「Change Cipher Spec」之前传输的 TLS 握⼿数据都是明⽂，之后都是对称密钥加密的密⽂。

TLS第四次握手：

服务器也是同样的操作，发「Change Cipher Spec」和「Encrypted Handshake Message」消息，如果双⽅都验证加密和解密没问题，那么握⼿正式完成。

最后，就⽤「会话密钥」加解密 HTTP 请求和响应了。

RSA秘钥协商算法最大的缺陷

使用 RSA 密钥协商算法的最⼤问题是不⽀持前向保密。因为客户端传递随机数（⽤于⽣成对称加密密钥的条件之⼀）给服务端时使⽤的是公钥加密的，服务端收到到后，会⽤私钥解密得到随机数。所以⼀旦服务端的私钥泄漏了，过去被第三⽅截获的所有 TLS 通讯密⽂都会被破解。

为了解决这⼀问题，于是就有了 DH 密钥协商算法，这⾥简单介绍它的⼯作流程。

客户端和服务端各⾃会⽣成随机数，并以此作为私钥，然后根据公开的 DH 计算公示算出各⾃的公钥，通过 TLS握⼿双⽅交换各⾃的公钥，这样双⽅都有⾃⼰的私钥和对⽅的公钥，然后双⽅根据各⾃持有的材料算出⼀个随机数，这个随机数的值双⽅都是⼀样的，这就可以作为后续对称加密时使⽤的密钥。

DH 密钥交换过程中，即使第三⽅截获了 TLS 握⼿阶段传递的公钥，在不知道的私钥的情况下，也是⽆法计算出密钥的，而且每⼀次对称加密密钥都是实时生成的，实现前向保密。

但因为 DH 算法的计算效率问题，后⾯出现了 ECDHE 密钥协商算法，我们现在⼤多数⽹站使⽤的正是 ECDHE 密钥协商算法。

2. DH算法

离散对数应用于DH算法：

解析：小红、小明各自生成自己的私钥(a、b)，通过公开公共参数(G、P)，算出各自的公钥(A、B)，随之双方交换公钥后，⼩红手上共有 5 个数：P、G、a、A、B，小明手上也同样共有 5 个数：P、G、b、B、 A。

然后小红执行运算： B ^ a ( mod P )，其结果为 K，因为离散对数的幂运算有交换律，所以小明执行运算： A ^ b (mod P )，得到的结果也是 K。

这个 K 就是小红和小明之间⽤的对称加密密钥，可以作为会话密钥使⽤。

因为在DH密钥协商算法中，服务器的公私密钥是固定的，只有客户端的公钥是会话时当即随机生成，所以安全隐患很大，也就被废弃了！

3. DHE算法

根据私钥生成的方式，DH 算法分为两种实现：

• static DH 算法，这个是已经被废弃了；(服务器方公钥固定，所以 static DH 算法不具备前向安全性）

• DHE 算法，现在常用的；

DHE（E全程为ephemeral（临时性的））：

既然固定⼀⽅的私钥有被破解的⻛险，那么⼲脆就让双⽅的私钥在每次密钥交换通信时，都是随机⽣成的、临时的，这个⽅式也就是 DHE 算法。所以，即使有个⽜逼的⿊客破解了某⼀次通信过程的私钥，其他通信过程的私钥仍然是安全的，因为每个通信过程的私钥都是没有任何关系的，都是独⽴的，这样就保证了「前向安全」。

4. ECDHE算法

DHE 算法由于计算性能不佳，因为需要做⼤量的乘法，为了提升 DHE 算法的性能，所以就出现了现在⼴泛⽤于密钥交换算法 —— ECDHE 算法。

ECDHE 算法是在 DHE 算法的基础上利⽤了 ECC 椭圆曲线特性，可以⽤更少的计算量计算出公钥，以及最终的会话密钥。

下面通过一个故事来叙述一下ECDHE密钥协商算法的原理

小红和小明使用 ECDHE 密钥交换算法的过程：

• 双⽅事先确定好使⽤哪种椭圆曲线，和曲线上的基点 G，这两个参数都是公开的；

• 双⽅各⾃随机⽣成⼀个随机数作为私钥d，并与基点 G相乘得到公钥Q（Q =dG），此时⼩红的公私钥为 Q1和 d1，⼩明的公私钥为 Q2 和 d2；

• 双⽅交换各⾃的公钥，最后⼩红计算点（x1，y1） = d1Q2，⼩明计算点（x2，y2） = d2Q1，由于椭圆曲线上是可以满⾜乘法交换和结合律，所以 d1Q2 = d1d2G = d2d1G = d2Q1 ，因此双方的 x 坐标是⼀样的，所以它是共享密钥，也就是会话密钥。

这个过程中，双方的私钥都是随机、临时⽣成的，都是不公开的，即使根据公开的信息（椭圆曲线、公钥、基点G）也是很难计算出椭圆曲线上的离散对数（私钥）。

ECDHE秘钥协商算法的TSL握手：

TLS第一次握手：

客户端⾸先会发⼀个「Client Hello」消息，消息⾥⾯有客户端使⽤的 TLS 版本号、⽀持的密码套件列表，以及生成的随机数（Client Random）。

TLS第二次握手：

服务端收到客户端的「打招呼」，同样也要回礼，会返回「Server Hello」消息，消息⾯有服务器确认的 TLS 版本号，也给出了⼀个随机数（Server Random），然后从客户端的密码套件列表选择了⼀个合适的密码套件。

不过，这次选择的密码套件就和 RSA 不⼀样了，我们来分析⼀下这次的密码套件的意思。

「 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384」

密钥协商算法使⽤ ECDHE；

签名算法使⽤ RSA；

握⼿后的通信使⽤ AES 对称算法，密钥⻓度 256 位，分组模式是 GCM；

摘要算法使⽤ SHA384；

接着，服务端为了证明自己的身份，发送「Certificate」消息，会把证书也发给客户端。

这⼀步就和 RSA 握⼿过程有很⼤到区别了，因为服务端选择了 ECDHE 密钥协商算法，所以会在发送完证书后，发送「Server Key Exchange」消息。

这个过程服务器做了三件事：

• 选择了名为 named_curve 的椭圆曲线，选好了椭圆曲线相当于椭圆曲线基点 G 也定好了，这些都会公开给客户端；

• ⽣成随机数作为服务端椭圆曲线的私钥，保留到本地；

• 根据基点 G 和私钥计算出服务端的椭圆曲线公钥，这个会公开给客户端。

为了保证这个椭圆曲线的公钥不被第三⽅篡改，服务端会⽤ RSA 签名算法给服务端的椭圆曲线公钥做个签名。

随后，就是「Server Hello Done」消息，服务端跟客户端表明：“这些就是我提供的信息，打招呼完毕”。

⾄此，TLS 两次握⼿就已经完成了，⽬前客户端和服务端通过明⽂共享了这⼏个信息：Client Random、Server Random 、使用的椭圆曲线、椭圆曲线基点 G、服务端椭圆曲线的公钥，这⼏个信息很重要，是后续⽣成会话密钥的材料。

TLS第三次握手：

客户端收到了服务端的证书后，⾃然要校验证书是否合法，如果证书合法，那么服务端到身份就是没问题的。校验证书到过程，会⾛证书链逐级验证，确认证书的真实性，再⽤证书的公钥验证签名，这样就能确认服务端的身份了，确认⽆误后，就可以继续往下⾛。

客户端会⽣成⼀个随机数作为客户端椭圆曲线的私钥，然后再根据服务端前⾯给的信息，⽣成客户端的椭圆曲线公钥，然后⽤「Client Key Exchange」消息发给服务端。

⾄此，双⽅都有对⽅的椭圆曲线公钥、⾃⼰的椭圆曲线私钥、椭圆曲线基点 G。于是，双⽅都就计算出点（x，y），其中 x 坐标值双⽅都是⼀样的，前⾯说 ECDHE 算法时候，说 x 是会话密钥，但实际应⽤中，x 还不是最终的会话密钥。

还记得 TLS 握⼿阶段，客户端和服务端都会⽣成了⼀个随机数传递给对⽅吗？

最终的会话密钥，就是⽤「客户端随机数 + 服务端随机数 + x（ECDHE 算法算出的共享密钥） 」三个材料生成的。

之所以这么麻烦，是因为 TLS 设计者不信任客户端或服务器「伪随机数」的可靠性，为了保证真正的完全随机，把三个不可靠的随机数混合起来，那么「随机」的程度就⾮常⾼了，⾜够让⿊客计算出最终的会话密钥，安全性更⾼。

算好会话密钥后，客户端会发⼀个「Change Cipher Spec」消息，告诉服务端后续改⽤对称算法加密通信。

接着，客户端会发「Encrypted Handshake Message」消息，把之前发送的数据做⼀个摘要，再⽤对称密钥加密⼀下，让服务端做个验证，验证下本次⽣成的对称密钥是否可以正常使⽤。

TLS第四次握手：

最后，服务端也会有⼀个同样的操作，发「Change Cipher Spec」和「Encrypted Handshake Message」消息，如果双⽅都验证加密和解密没问题，那么握⼿正式完成。于是，就可以正常收发加密的 HTTP 请求和响应了。