CA、数字证书、数字签名

本文介绍 CA、数字证书和数字签名的概念和原理。

---

目录

• 相关概念
• 数字签名
• 数字证书
• 公钥基础设施
• 数字证书认证机构
• HTTPS 证书认证流程
• 场景示例
• 附录

---

相关概念

中文名	英文名	缩写
证书认证中心	Certificate Authority	CA
数字证书	Digital Certificate	DC
数字签名	Digital Signature / Digital Signed	DS
公钥基础设置	Public Key Infrastructure	PKI

---

数字签名

数字签名，又称公钥数字签名、电子签章，是使用公钥加密技术实现的用于鉴别数字信息的方法。
一套数字签名通常定义两个互补的运算，一个用于生成签名，另一个用于验证签名。

生成：

对要传输的消息原文使用消息摘要算法（MD5 / SHA）生成消息摘要，发送方使用自己的私钥对消息摘要进行加密后生成数字签名。

验证：

数字签名同摘要一同传送给接收方，接收方使用发送方的公钥解密数字签名还原消息摘要，并对消息原文使用相同的消息摘要算法（MD5 / SHA）计算出消息摘要，将这两个消息摘要进行对比，如果不同则说明消息在传输过程中被篡改过。

---

数字证书

数字签名依赖于发送方公钥的安全性，如何确保公钥来自真实的发送方而非仿造？这就需要依赖于数字证书。
数字证书的生成和验证：

生成：

1. 申请者（即之前所说的消息发送方）将自己的公钥、身份信息等按照 CA 中心要求提交；
2. CA 中心在认证通过后，将申请者的公钥、身份信息和证书有效期等信息合并作为证书原文 O，内容大致如下：

签发证书方 ID：即是谁签发了这个证书
证书用途
Subject：即证书签发给谁
申请者公钥
申请者加密算法
申请者 Hash 算法
有效期
其它信息

3. CA 中心对证书原文 O 执行 Hash 运算得到摘要 H；
4. CA 中心使用自己的私钥对摘要 H 进行加密得到签名信息 S；
5. CA 中心将 O 和 S 合并成一个文件，这个文件就是数字证书 DC。

验证

接收方收到数字证书后使用 CA 中心的公钥对签名信息 S 进行解密得到摘要 H，然后对证书原文 O 执行相同的 Hash 运算得到摘要 h，通过 H 和 h 的对比可以判断证书内容的真实性和完整性。如果证书原文中的公钥和身份信息都是 CA 中心的，说明是 CA 自签名。

证书的格式和验证方法普遍遵循 X.509 国际标准。

---

公钥基础设施

公钥基础设施（Public Key Infrastructure，PKI），是一组由硬件、软件、参与者、管理政策与流程组成的基础架构，其目的在于创造、管理、分配、使用、存储以及撤销数字证书。
公钥基础设施借助 数字证书认证机构（CA） 将用户的个人身份跟公开密钥链接在一起。

---

数字证书认证机构

数字证书认证机构（Certificate Authority，缩写为CA），是负责发放和管理数字证书的权威机构，并作为受信任的第三方，承担公钥体系中 公钥合法性检验 的责任。
CA 中心为每个使用公开密钥的用户发放一个数字证书，数字证书的作用是证明证书中列出的用户合法拥有证书中列出的公开密钥。
全球权威的 CA 中心的证书已被各软件厂商设置为 可信任的根证书。所谓 根证书 是指此证书是受信任的起始点，可以使用此证书来证明其它证书。这些证书被预置到软件内的过程是未知的，这也是最关键的安全环节。

---

HTTPS 证书认证流程

1. 浏览器向 Web 服务器发起 HTTPS 请求；
2. Web 服务器用自己的私钥加密内容后，连同自己的数字证书一起发送回浏览器；
3. 浏览器自己的 证书管理器 中有 受信任的根证书颁发机构列表，浏览器在此列表中查找数字证书的公钥是否在内；
4. 如果数字证书记载的 Web 服务器地址和当前访问地址不一致，表明证书被冒用；如果一致但是签发此证书的机构并非权威的 CA 中心（即签发此 CA 的机构并不被浏览器认可），则此时浏览器会警告用户 此证书不受信，是否添加到受信列表中？
5. 浏览器信任该证书并安装后，双方会运行 Diffie Hellman 算法，即双方会协商一个 master-key，这个 master-key 不会在网络上传输和交换，是浏览器和 Web 服务器各自独立计算出来的，值是相同的，只有它们自己双方知道；
6. 通过 master-key 推导出 session-key 用于后续数据流加解密，并由 master-key 推导出 hash-key 用于数据完整性校验。
7. 发送方用 hash-key 生成一个 MAC（Message Authentication Code） 并附在 HTTP 报文后面，然后使用 session-key 加密所有数据（包括 MAC）后发送出去；
8. 接收方先用 session-key 解密后得到发送方发来的 MAC，然后再使用相同的算法计算自己的 MAC，如果两个 MAC 相同则表明数据没被篡改过。

---

场景示例

1. X 有两把钥匙，一把公钥，一把私钥；
2. X 把公钥给了 A B C 三人；
3. A 想要给 X 写一封密函，写完后用 X 给的公钥加密；
4. X 在收到 A 的密函后用自己的私钥解密，看到了具体的内容，B 和 C 或其它人因没有私钥所以看不到密函内容，只要私钥不泄露，密函就是安全的；
5. X 看完密函内容后决定给 A 回信，此过程使用了 数字签名：
   5.1 X 写完回信后先对回信执行 Hash 运算得到回信的摘要（digest）；
   5.2 X 使用私钥对这个摘要加密，生成了 数字签名（signature）；
   5.3 X 将 数字签名 附在回信下方一同发回给 A。
6. A 收到后先取下 数字签名，用公钥解密得到信件的摘要，然后再对信件本身执行 Hash 运算，将得到的结果和摘要进行对比，如果一致则表明信件未被篡改过。
7. 此时出现一名恶意攻击者 Y 想窃取 A 发给 X 的密函，Y 攻击了 A 的计算机，用自己的公钥替换了 X 的公钥。
8. A 怀疑自己拿到的公钥有问题，无法确定是否属于 X，于是 A 要求 X 去 证书认证中心（Certificate Authority，简称 CA） 为其公钥做认证。
9. CA 中心用自己的私钥对 X 的公钥和一些相关信息一起加密生成 数字证书（Digital Certificate）。
10. 有了数字证书以后，后续 X 给 A 的所有信件中都附带上了数字证书。
11. A 收到信件后，用 CA 的公钥解开数字证书，从中取出 X 的公钥，然后再做以上操作，CA 中心保证了 X 公钥的合法性。

---

附录

参考：http://www.youdzone.com/signature.html