大型网站的HTTPS实践一：HTTPS协议和原理二

4.1.1.1.2 握手过程中的 RSA 密钥协商

介绍完了 RSA 的原理，那最终会话所需要的对称密钥是如何生成的呢？跟 RSA 有什么关系？

以 TLS1.2 为例简单描述一下，省略跟密钥交换无关的握手消息。过程如下：

1、浏览器发送 client_hello，包含一个随机数 random1。

2、服务端回复 server_hello，包含一个随机数 random2，同时回复 certificate，携带了证书公钥 P。

3、浏览器接收到 random2 之后就能够生成 premaster_secrect 以及 master_secrect。其中 premaster_secret 长度为 48 个字节，前 2 个字节是协议版本号，剩下的 46 个字节填充一个随机数。结构如下：

• Struct {byte Version[2];bute random[46];}

master secrect 的生成算法简述如下：

Master_key = PRF(premaster_secret, “master secrect”, 随机数1+随机数2)其中 PRF 是一个随机函数，定义如下：PRF(secret, label, seed) = P_MD5(S1, label + seed)  XOR  P_SHA-1(S2, label + seed)

从上式可以看出，把 premaster_key 赋值给 secret，”master key”赋值给 label，浏览器和服务器端的两个随机数做种子就能确定地求出一个 48 位长的随机数。

而 master secrect 包含了六部分内容，分别是用于校验内容一致性的密钥，用于对称内容加解密的密钥，以及初始化向量（用于 CBC 模式），客户端和服务端各一份。

至此，浏览器侧的密钥已经完成协商。

4、浏览器使用证书公钥 P 将 premaster_secrect 加密后发送给服务器。

5、服务端使用私钥解密得到 premaster_secrect。又由于服务端之前就收到了随机数 1，所以服务端根据相同的生成算法，在相同的输入参数下，求出了相同的 master secrect。

RSA 密钥协商握手过程图示如下：

图 6 RSA 密钥协商过程

可以看出，密钥协商过程需要 2 个 RTT，这也是 HTTPS 慢的一个重要原因。而 RSA 发挥的关键作用就是对 premaster_secrect 进行了加密和解密。中间者不可能破解 RSA 算法，也就不可能知道 premaster_secrect，从而保证了密钥协商过程的安全性。

4.1.1.2 ECDHE 密钥协商

4.1.1.2.1 DH 与 ECC 算法原理

ECDHE 算法实现要复杂很多，主要分为两部分：diffie-hellman 算法（简称为 DH）及 ECC（椭圆曲线算术）。他们的安全性都是建立在离散对数计算很困难的基础上。

简单介绍一下 dh 算法的实现，先介绍两个基本概念：

• 本原根：如果整数 a 是素数 p 的本原根，则 a, a^2, …, a^(p-1) 在 mod p 下都不相同。  

• 离散对数：对任意整数 b 和素数 p 的本原根 a，存在唯一的指数 i 满足:

b ≡ a^i mod p (0≤i≤p-1)

则称 i 是 b 的以 a 为底的模 p 的离散对数。

理解这两个概念，dh 算法就非常简单了，示例如下：

假设 client 和 server 需要协商密钥，p=2579，则本原根 a = 2。

1、Client 选择随机数 Kc = 123 做为自己的私钥，计算 Yc = a^Kc  mod p = 2^123 mod 2579 = 2400，把 Yc 作为公钥发送给 server。

2、Server 选择随机数 Ks = 293 作为私钥，计算 Ys = a^Ks  mod p = s^293 mod 2579 = 968，把 Ys 作为公钥发送给 client。

3、Client 计算共享密钥：secrect =  Ys^Kc mod (p) = 968^123  mod(2579) = 434

4、Server 计算共享密钥：secrect = Yc^Ks mod(p) =2400^293 mod(2579) =434

上述公式中的 Ys,Yc,P, a, 都是公开信息，可以被中间者查看，只有 Ks,Kc 作为私钥没有公开，当私钥较小时，通过穷举攻击能够计算出共享密钥，但是当私钥非常大时，穷举攻击肯定是不可行的。

DH 算法有一个比较大的缺陷就是需要提供足够大的私钥来保证安全性，所以比较消耗 CPU 计算资源。ECC 椭圆曲线算术能够很好的解决这个问题，224 位的密钥长度就能达到 RSA2048 位的安全强度。

ECC 的曲线公式描述的其实不是椭圆，只是跟椭圆曲线周长公式形似才叫椭圆曲线加密算术。ECC 涉及到了有限域、群等近世代数的多个概念，就不做详细介绍了。

ECC 安全性依赖于这样一个事实：

P = kQ, 已知 k, Q 求出 P 相对简单，但是已知 P 和 Q 求出 k 却非常困难。

上式看起来非常简单，但有如下约束条件：

1、Q 是一个非常大的质数，p, k, q 都是椭圆曲线有限域上的离散点。

2、有限域定义了自己的加法和乘法法则，即使 kQ 的运算也非常复杂。

ECC 应用于 Diffie-Hellman 密钥交换过程如下：

1、定义一个满足椭圆方程的有限域，即挑选 p, a, b 满足如下方程：

y^2 mod p = (x^3+ax +b) mod p

2、挑选基点 G = (x, y)，G 的阶为 n。n 为满足 nG = 0 的最小正整数。

3、Client 选择私钥 Kc (0 <Kc

4、server 选择私钥 Ks 并产生公钥 Ys =Ks*G

5、client 计算共享密钥 K = Kc*Ys   ，server 端计算共享密钥 Ks*Yc ，这两者的结果是一样的，因为：

 Kc*Ys = Kc*(Ks*G) = Ks*(Kc*G) = Ks*Yc

由上面描述可知，只要确定 p, a, b 就能确定一条有限域上的椭圆曲线，由于不是所有的椭圆曲线都能够用于加密，所以 p, a, b 的选取非常讲究，直接关系曲线的安全性和计算速度。

Openssl 实现的，也是 FIPS 推荐的 256 位素数域上的椭圆曲线参数定义如下：

质数 p = 115792089210356248762697446949407573530086143415290314195533631308867097853951 阶 n = 115792089210356248762697446949407573529996955224135760342422259061068512044369SEED = c49d3608 86e70493 6a6678e1 139d26b7 819f7e90c = 7efba166 2985be94 03cb055c 75d4f7e0 ce8d84a9 c5114abcaf317768 0104fa0d 椭圆曲线的系数 a = 0 椭圆曲线的系统 b = 5ac635d8 aa3a93e7 b3ebbd55 769886bc 651d06b0 cc53b0f63bce3c3e 27d2604b 基点 G x = 6b17d1f2 e12c4247 f8bce6e5 63a440f2 77037d81 2deb33a0f4a13945 d898c296 基点 G y = 4fe342e2 fe1a7f9b 8ee7eb4a 7c0f9e16 2bce3357 6b315ececbb64068 37bf51f5

4.1.1.2.2 握手过程中的 ECDHE 密钥协商

简单介绍了 ECC 和 DH 算法的数学原理，我们看下 ECDHE 在 TLS 握手过程中的应用。

相比 RSA，ECDHE 需要多发送一个 server_key_exchange 的握手消息才能完成密钥协商。

同样以 TLS1.2 为例，简单描述一下过程：

1、浏览器发送 client_hello，包含一个随机数 random1，同时需要有 2 个扩展：

a)    Elliptic_curves：客户端支持的曲线类型和有限域参数。现在使用最多的是 256 位的素数域，参数定义如上节所述。

b)   Ec_point_formats：支持的曲线点格式，默认都是 uncompressed。

2、服务端回复 server_hello，包含一个随机数 random2 及 ECC 扩展。

3、服务端回复 certificate，携带了证书公钥。

4、服务端生成 ECDH 临时公钥，同时回复 server_key_exchange，包含三部分重要内容：

a)    ECC 相关的参数。

b)   ECDH 临时公钥。

c)    ECC 参数和公钥生成的签名值，用于客户端校验。

5、浏览器接收 server_key_exchange 之后，使用证书公钥进行签名解密和校验，获取服务器端的 ECDH 临时公钥，生成会话所需要的共享密钥。

至此，浏览器端完成了密钥协商。

6、浏览器生成 ECDH 临时公钥和 client_key_exchange 消息，跟 RSA 密钥协商不同的是，这个消息不需要加密了。

7、服务器处理 client_key_exchang 消息，获取客户端 ECDH 临时公钥。

8、服务器生成会话所需要的共享密钥。

9、Server 端密钥协商过程结束。

图示如下：

图 7 ECDHE 密钥协商过程