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

文章目录

  • 1. RSA算法
    • RSA握手过程
    • RSA秘钥协商算法最大的缺陷
  • 2. DH算法
  • 3. DHE算法
  • 4. ECDHE算法
    • ECDHE秘钥协商算法的TSL握手:


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 密钥协商算法,这⾥简单介绍它的⼯作流程。

密钥协商算法的演变 —— RSA算法 - DH算法 - DHE算法 - ECDHE算法_第1张图片

客户端和服务端各⾃会⽣成随机数,并以此作为私钥,然后根据公开的 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 请求和响应了。

你可能感兴趣的:(计算机网络,https,加密解密,网络安全,网络协议,http)