一文搞懂私钥公钥和数字证书数字签名、https原理、tls握手

对称密码

如Alice和Bob通过信使传递信件进行通信，为了防止信使看到信的内容。 假设这个密码学原语是一个提供了以下两个函数的黑盒子（我们无法看到它的内部构造）

ENCRYPT 和DECRYPT互为逆函数

Alice向Bob传递信息：函数ENCRPT的输入是Message和密钥，输出是加密Message

Bob收到Alice的信息：函数DECRYPT的输入是加密Message和密钥，输出是原始Message

在密码学中，使一个协议变得安全的常见做法就是：使用密钥将消息转变成噪声，使经过变换后的消息与随机数字序列无法区分开来，信使在这个过程中只能接收到像噪声一样的随机数字序列

在对称加密的过程中，不同的函数往往采用相同的密钥。

DH密钥交换

DH 代表 Diffie-Hellman。Diffie-Hellman 算法使用指数计算来得出相同的预主密钥。服务器和客户端各自为计算提供一个参数，当它们组合在一起时，它们会在每一侧产生不同的计算，结果是相等的

生成私钥：Alice和Bob都知道公共形状正方形，Alice拥有的形状是三角形只有他自己知道，Bob拥有的形状是星形也只有他自己知道。只有她们自己知道的形状就是私钥。

双方交换公钥：当Alice和Bob选择完私钥后，他们就各自将他们随机选择的形状与他们起初协商的公共形状（正方形）结合起来。这些组合会产生唯一的新形状，每个新形状表示一个公钥(Public Key)。公钥属于公开信息，因此Alice和Bob可以相互交换他们的公钥。

双方生成共享密钥：为了生成这个密钥，双方都将对方的公钥和自己的私钥结合在一起，而且仅仅通过两个公钥无法生成共享密钥

在消息传输的过程中，攻击者无法通过公钥获取到私钥或共享密钥的信息，但是很容易出现有人伪装成Bob的公钥，就可以攻击该协议

非对称加密

非对称加密有两个密钥分别是公钥和私钥，任何人都可以使用公钥加密发送给Alice的消息，而Alice可以用只有自己拥有的私钥解密消息

第三方没法直接观察到发给Alice的消息 可以用公钥加密内容，私钥解密；也可以用私钥加密内容，用公钥解密

数字签名和数字证书、CA

例1

Alice想给Bob写信，她写完信后先用Hash函数，生成信件的摘要（digest）,之后再用私钥对digest加密，生成数字签名。Alice将这个签名附在信件下面。Bob收到后对摘要后用公钥进行解密，再对信件本身使用Hash函数得到结果，将结果与摘要对比，看是否一致，一致则表明内容没有被修改过

问题：如果有人将Bob电脑的Alice公钥替换成自己的公钥，再用自己的私钥加密内容，就能冒充Alice，如何能保证公钥就是Alice的呢？

Alice去找"证书中心"（certificate authority，简称CA），为公钥做认证。证书中心用自己的私钥，对自己的公钥和一些相关信息一起加密，生成"数字证书"（Digital Certificate）。之后Alice在写信的时候只要在签名的时候再附加上数字证书就可以了。Bob收到信后，用CA的公钥解开数字证书，就可以拿到Alice的公钥了。

例2

Alice想向David证明她信任Bob。这是一个在多方环境中建立信任以及非对称密码技术使用场景的典型例子。Alice通过在一张写有“Alice信任Bob”的纸上签名来表明立场，并告诉David：Bob是可以信任的。如果David信任Alice和她的签名算法，那么他也可以选择信任Bob。

任何人都可以通过以下信息验证这个签名：(1)Alice公钥；(2)待签消息；(3)消息的签名。验证结果只能是真（签名有效）或者假（签名无效）

在实际的web请求过程中应用数字证书的实例：https协议

1.客户端向服务器发出加密请求，服务器用自己的私钥加密网页后，连同本身的数字证书，一起发送给客户端。

2.客户端收到后查找本地的"受信任的根证书颁发机构"列表，客户端根据这张列表，查看解开数字证书的根公钥是否在列表之内（这个证书是CA机构用自己的私钥加密的）。验证证书是否被修改。

3.在证书未被修改的基础上检查证书属性里使用者的URL和请求的URL是否相等，如果不同说明这张证书可能被冒用，浏览器会发出警告。如果数字证书不是由信任机构颁发的，就会告警。如果数字证书是可靠的，客户端就可以使用证书中的服务器公钥对信息加密，然后与服务器交换加密信息。

4.客户端随机生成一个字符串作为密钥，通过证书公钥加密成密文，将密文发送给服务器。发送密文的时候也会对消息内容进行签名操作，对密文内容进行hash计算得到一个hash值，将这个签名加密后和消息内容一起发出去，接收方接收到消息后，通过私钥解密出密文和签名的hash值，同时对接受的消息内容进行同样的计算的到另一个hash值，通过对比两个hash值判断密文是否被修改过。

TLS握手

TLS 握手中的确切步骤将根据所使用的密钥交换算法的类型和双方支持的密码套件而有所不同。RSA 密钥交换算法虽然现在被认为不安全，但在 1.3 之前的 TLS 版本中使用。大致是这样的：

1. 'client hello' 消息： 客户端通过向服务器发送“hello”消息来启动握手。该消息将包括客户端支持的 TLS 版本、支持的密码套件以及称为“客户端随机”的随机字节串。
2. “服务器问候”消息： 作为对客户端问候消息的回复，服务器发送一条消息，其中包含服务器的SSL 证书、服务器选择的密码套件和“服务器随机”，这是服务器生成的另一个随机字节串。
3. 身份验证： 客户端通过颁发它的证书颁发机构验证服务器的 SSL 证书。这确认服务器是它所说的那个人，并且客户端正在与域的实际所有者交互。
4. Premaster secret： 客户端再发送一个随机字节串，即“premaster secret”。premaster secret 用公钥加密，只能由服务器用私钥解密。（客户端从服务器的 SSL 证书中获取公钥。）
5. 使用的私钥： 服务器解密预主密钥。
6. 创建的会话密钥： 客户端和服务器都从客户端随机数、服务器随机数和预主密钥生成会话密钥。他们应该得出相同的结果。
7. 客户端准备就绪： 客户端发送一条用会话密钥加密的“完成”消息。
8. 服务器准备就绪： 服务器发送一条用会话密钥加密的“完成”消息。
9. 实现安全对称加密： 握手完成，使用会话密钥继续通信。

所有 TLS 握手都使用非对称加密（公钥和私钥），但并非所有握手都会在生成会话密钥的过程中使用私钥。例如，短暂的 Diffie-Hellman 握手过程如下：

1. 客户端问候： 客户端发送带有协议版本、客户端随机数和密码套件列表的客户端问候消息。
2. 服务器问候： 服务器回复其 SSL 证书、其选择的密码套件和服务器随机数。与上面描述的 RSA 握手相反，在此消息中，服务器还包括以下内容（步骤 3）：
3. 服务器的数字签名： 服务器计算到目前为止所有消息的数字签名。
4. 数字签名确认： 客户端验证服务器的数字签名，确认服务器是它所说的那个人。
5. 客户端DH参数： 客户端将其DH参数发送给服务器。
6. 客户端和服务器计算预主密码： 客户端和服务器不像在 RSA 握手中那样生成预主密码并将其发送到服务器，而是使用它们交换的 DH 参数分别计算匹配的预主密码。
7. 创建的会话密钥： 现在，客户端和服务器根据预主密钥、客户端随机数和服务器随机数计算会话密钥，就像在 RSA 握手中一样。
8. 客户端准备就绪： 与 RSA 握手相同。
9. 服务器准备就绪
10. 实现安全对称加密

文章内容参考：www.ruanyifeng.com/blog/2011/0…

www.cloudflare.com/learning/ss…

《深入浅出密码学》