2 --＞ TLS 通讯握手解析

(1). 典型的TLS 通信握手过程

• ClientHello

由客户端发送"client hello"消息向服务器发起握手请求。该消息包括支持的协议版本, 如 TLS 1.2; 一个客户端生成的随机数; 支持的密码学套件（一个套件是诸如身份验证算法，密钥协商算法，对称加密算法以及摘要计算算法的组合），比如 SM2_WITH_SM4_SM3（即使用国密的 SM2 做签名验签，SM3 做 MAC 摘要计算，SM4 做对称加密，密钥协商为使用 SM2 非对称加密，由于 SM2 本身是 ECC 椭圆曲线算法的实现，因此也称 ECC 协商），ECDHE_SM2_WITH_SM4_SM3（ECDHE：临时椭圆曲线迪菲赫尔曼密钥交换算法）；支持的压缩方法（几乎没有 tls 实现使用）

• ServerHello

一个服务端生成的随机数

确认与客户端使用的加密通信协议版本，如果客户端发送了不支持的版本，服务器将关闭加密通信

确认接下来协商会话密钥使用的加密方法，从客户端发送的加密方法列表中选择安全性最高的一个

• ServerCertficate
  服务器的证书，客户端会根据设置的 CA 来验证服务器的身份。客户端还可以从中取出对应的公钥，用于会话密钥协商。

• ServerKeyExchange
  这是会话密钥协商的里程碑的第一步，服务器端会首先提供密钥原材料，但是 RSA 密钥协商算法除外（此时悬空，不做任何事情）。

• CertificateRequest
  这是一个可选消息，服务器根据对客户端的认证级别（即是否开启双验证）来选择是否发送，目的是请求客户端的证书，用来验证客户端的身份，并保证消息不被篡改，只有特别指定了不需要客户端证书（最低安全级别），才不会发送该消息

• ServerHelloDone
  向客户端发送 Server Hello Done 消息，通知客户端，服务端已经发送了全部的相关信息。

• ClientCertificate
  客户端如果收到服务端的证书请求，则在该消息中包含自己的证书。

• ClientKeyExchange
  客户端根据 ServerKeyExchange 中的密钥原材料，生成对应的另一半密钥原材料，如果是 RSA 加密，此时客户端从服务端证书中取出公钥，并加密一串随机的长度为 48 字节的预主密钥（Pre Master Secret）。

• CertificateVerify
  前文中提到 TLS 协议设计的一个目标是防止消息被篡改，前提是没有设置最低的安全级别（即不要求验证客户端证书），在这步之前，客户端会使用对应的签名算法更新前面每个步骤的签名 hash，到这一步使用自己的私钥做最后的签名，并将签名结果发送至服务端，相应的服务器接收到该消息后，也会将之前所有的步骤进行 hash 运算 ，并从客户端证书中取出公钥，做验签的操作，一旦发现签名不通过，就说明消息是被篡改了（因此防止中间人攻击最安全的手段是只信任指定的证书，某些组织出于流量监管的目的，会让用户信任组织的证书，否则无法联网，此时组织内是有个 HTTPS 流量代理的）

• ChangeCihperSpec
  通知服务器端，密钥协商完毕，接下来需要使用协商好的会话密钥来通信，由于该消息不参与消息 hash 的计算，因此往往被各个 tls 实现用于携带自定义的扩展字段。

对TLS进行国密化需要重点改造什么?
通过前文我们知道，TLS 安全通信的本质根据协商生成的对称加密密钥对后续通信内容进行安全加密。因此改造工作的重要抓手是对通信消息中的密钥协商部分进行国密化适配。从前文的通信过程分析得知，如果要适配国密的 TLS 需要改造如下消息：

• ClientHello
  根据国密标准中描述的 ECC 和 ECDHE 密钥协商算法魔数（Magic Number) 加入到支持的密码学套件列表中，分别是 0xe013 和 0xe011

• ServerHello
  同上

• ServerCertficate
  根据国密标准中定义，服务器必须双证书模式，即签名证书和加密证书必须分开，因此服务器发送证书需要改为发送两张证书。

关于双证书，国密标准中有如下描述：

服务端密钥为非对称密码算法的密钥对，包括签名密钥对和加密密钥对，其中签名密钥对由 VPN 自身密码模块产生，加密密钥对应通过 CA 认证中心向 KMC（密钥管理中心， Key management center） 申请，用于握手过程中服务器端身份鉴别和与主密钥的协商。一言以蔽之，分离签名加密密钥对的作用是满足监管要求。

• ServerKeyExchange & ClientKeyExchange
  根据握手选择的密钥协商算法，需要分别适配 ECC 和 ECDHE 协商算法

(2). 国密 TLS ECDHE 协商

在正式介绍国密 ECDHE 协商算法之前，我们简要介绍下 DH 算法的原理。

我们知道共享密钥的传递一直是个头疼的问题，因为过程中始终有被窃听的可能性。1976年，两位密码学专家怀特菲尔德·迪菲和马丁·赫尔曼发表一篇开创性的论文《密码学的新方向》，他们提出一种双方不需要传递密钥就能得到共享密钥的方法，也就是迪菲·赫尔曼密钥交换算法，简称 DH。这篇论文奠定了现代密码学的基础。为了方便大家理解，我们使用类比的方法来解释迪菲·赫尔曼密钥交换的原理。顺便提一句，想要精确掌握算法原理，需要去学习群论和数论相关的数学知识。

我们假设 Alice 和 Bob 想要协商出一个共享密钥，而有个坏人 Eve 在暗中窃听他们交换密钥的过程。那么怎么能保证 Alice 和 Bob 成功获得共享密钥，同时 Eve 没法获得呢？

1. Alice 和 Bob 先商量一份公开的信息，Eve 也可以获取这份信息。自然，这条信息是无法作为密钥。在上图左1以三条横杠表示。

2. Alice 和 Bob 分别选取自己秘密的信息，然后同第一步中的公开信息进行混合。我们需要假设这种混合是不可逆的，即从混合后的图形推导不出来 Alice 和 Bob 的秘密信息是什么，然后将各自混合后的产物发送给对方。在上面的中间图示展示这一结果，Alice 选取了三条斜向上的杠作为密钥，而 Bob 选取了三条斜向下的杠作为密钥。混合之后的结果 Eve 都可以获取。

3. 最后一步，Alice 和 Bob 分别用自己的密钥同对方发来的信息进行混合，就能得到同样的密钥，这就是他们后续通信的共享密钥了。如图右边所示，对于 Eve 而言，因为无法获取 Alice 和 Bob 的密钥，所以它是混合得出共享密钥的。

以上就是 DH 密钥交换算法的类比解释，从中我们不难发现一个重要的假设，即从公开信息中无法（非常难以）计算出原始的密钥。而这基本就是非对称密码学的数学根基——找到一种单向函数。

(3). 关于 SM2 密钥协商算法的适配
国密 TLS ECDHE 协商算法主要参考国密标准 GMT 0009-2012 SM2 密码算法（国密非对称密码）规范，其中该规范有如下描述：

密钥协商是在两个用户之间建立一个共享秘密密钥的协商过程，通过这种方式能够确定一个共享秘密密钥的值。

设密钥协商双方为A、B，其密钥对分别为 (dA,QA) 和 (dB, QB)，双方需要获得的密钥数据的比特长度为 klen，密钥协商协议分为两个阶段：

第一阶段：产生临时密钥对用户A：

调用生成密钥算法产生临时密钥对（rA，RA），将 RA 和用户 A 的用户身份标识 IDA发送给用户 B

用户B：

调用生成密钥算法产生临时密钥对（rB，RB），将 RB 和用户 B 的用户身份标识 IDB发送给用户 A

第二阶段：计算共享秘密密钥

具体计算步骤可参考规范，改造中需要注意如下几点：

1. 上述的非临时公钥和私钥都对应于国密多出的加密证书

2. 上述的临时公钥对应于客户端和服务端的 KeyExchange 消息中的公钥，临时私钥只在本次握手会话中有效，握手结束后就被释放

3. 用户身份标识须硬编码为 ‘1234567812345678’ 对应的 ASCII 值

4. 输出的 K 须为 48 字节长度

总结
我们日常依赖的安全通信协议切换成国密算法，不仅出于政策合规需要，更关乎通信基础设施的安全可控。
TLS也许是安全通信传输最重要的协议之一，可以称得上是互联网安全的基石。但是协商过程中涉及到签名，验签，以及相应的密钥交换等多种加密算法，都有可能因为某个潜在后门漏洞面临巨大安全风险。
TLS 安全通信的本质根据协商生成的对称加密密钥对后续通信内容进行安全加密。因此改造工作的重要抓手是对通信消息中的密钥协商部分进行国密化适配。

参考链接:
https://zhuanlan.zhihu.com/p/358933339