Skip to content

HTTPS-digital-certificate.md

Latest commit

 

History

History
183 lines (102 loc) · 9.02 KB

HTTPS-digital-certificate.md

File metadata and controls

183 lines (102 loc) · 9.02 KB

随处可见的公钥证书

一、为什么需要公钥证书？

在上一篇文章中我们谈到了数字签名，数字签名可以识别篡改或者发送者身份是否被伪装，也就是验证消息的完整性，还可以对消息进行认证。还可以防止抵赖。看似一切完美，但是他的弱点也在他的优点上，数字签名需要用公钥来确认发送者的身份。

我们需要从一个没有被伪装的发送者那里得到没有被篡改的公钥才行，为了验证得到的公钥是否合法，必须使用公钥证书。证书是将公钥当做一条消息，由一个可信的第三方对其签名后所得到的公钥。

二、什么是公钥证书？

公钥证书(Public-Key Certificate，PKC)记录着个人信息(姓名、组织、邮箱地址等个人信息)和个人公钥，并由认证机构(Certification Authority、Certifying Authority，CA)施加数字签名。公钥证书也简称为证书(certificate)。

三、公钥证书标准规范

目前使用最广泛的是 ITU(International Telecommunication Union，国际电信联盟) 和 ISO(International Organization for Standardization，国际标准化组织) 制定的 X.509 规范(RFC3280)。基本上大多程序都是遵循这种证书生成和交换的标准规范。

四、公钥证书应用场景

用一个例子来展现证书的应用场景。下图是 Alice 向 Bob 发送密文的场景，在生成密文时所使用的 Bob 的公钥是通过认证机构获取的。

上图中步骤 1 - 7 是按照顺序来标识的。针对特殊步骤增加一些说明：

    1. Bob 的密钥可以是自己生成的，也可以由认证机构代为生成。
    1. 认证机构在拿到 Bob 的公钥以后会开始认证这个公钥是否是 Bob 的。有三种验证等级，Class 1 通过邮箱中的邮件进行确认本人身份；Class 2 通过第三方数据库来确认本人身份；Class 3 通过当面认证和身份来确认本人身份。等级越高，身份认证越严格。
    1. Alice 使用认证机构 Trent 的公钥对证书中的数字签名进行验证，如果验证成功，就确认了证书中所包含的公钥是 Bob 的。
    1. 图上虽然标识的是“公钥加密”的方式，但实际上这一步用混合加密的方式也是可以的。

上图中的步骤 1、2、3、4 并不是每次都需要这样请求。1、2、3 步只需要在注册新的公钥的时候才会进行。第四步仅在第一次需要使用公钥密码的时候需要，之后保存到了电脑中，就不用每次都请求公钥了。

五、什么是公钥基础设施 PKI？

公钥基础设施(Public-Key Infrastructure)是为了能够更有效的运用公钥而制定的一系列规范和规格的总称。英文缩写 PKI。

PKI 是一个总称，并非指某一个单独的规范或规格。RSA 公司制定的 PKCS(Public-Key Cryptography Standards，公钥密码标准)系列规范也是 PKI 的一种，互联网规格 RFC(Request for Comments)也是 PKI 的一种，X.509 也是 PKI 的一种。每个公司编写的 API(Application Programming Interface，应用程序编程接口)和规格设计书也可以算是 PKI 的相关规格。

公钥基础设施 PKI 不能误解为“面向公众的权威认证机构只有一个”，“全世界的公钥都是由一个根 CA 来认证”。这些都是不正确理解。认证机构只要对公钥进行数字签名就可以了，所以任何人都可以成为认证机构。

1. PKI 的组成要素

  • 用户——使用 PKI 的人
  • 认证机构——颁发证书的人
  • 仓库——保存证书的数据库

用户和认证机构都可以是人或者计算机，统称为实体(entitiy)。实体是进行证书和密钥相关处理的行为主体。

用户包括 2 种，一种是希望使用 PKI 的人，另外一种是希望使用已注册的公钥的人。

类似 Bob 注册公钥的用户：

  • 生成密钥对(可以自己生成也可以由认证机构生成)
  • 在认证机构注册公钥
  • 向认证机构申请证书
  • 申请作废已注册的证书
  • 解密收到的密文
  • 对消息进行数字签名

类似 Alice 使用公钥的用户

  • 将消息加密后发送给接收者
  • 验证数字签名

2. 认证机构 CA

认证机构(Certification Authority，CA)是对证书进行管理的人。主要负责以下操作：

  • 生成密钥对(也可以由用户生成)
  • 对注册公钥的人进行身份认证
  • 生成并颁发证书
  • 作废证书

认证机构中还可以细分一个注册机构(Registration Authority，RA)，注册机构专门处理注册相关的业务，认证机构专门颁发证书和作废证书。

3. 仓库

仓库(repository)是一个保存证书的数据库。仓库也叫证书目录。作废的证书也需要制作一张证书作废清单(Certificate Revocation List，CRL)。

4. 证书链

证书也可以具有层次结构，例如顶级根 CA 颁发的证书，到下一级 CA 颁发的证书，这样一级一级形成层次。

六、对公钥证书的攻击

由于证书实际上使用的就是数字签名技术，所以对数字签名的所有攻击方法都对证书有效。

1. 在公钥注册之前进行攻击

中间人可以在对用户向认证机构提交公钥认证的时候，替换成中间人自己的公钥。预防这种中间人攻击有 2 种方法：

  • 用户在向 CA 发送公钥的时候，使用认证机构 CA 的公钥进行加密。
  • 认证机构在确认完用户身份以后，将公钥指纹作为回执发给用户进行确认。

有一个机构叫 PKG (Private Key Generator，私钥生成机构)，这个机构和认证机构 CA 地位并列。它利用一些公开的信息，邮箱，通信地址，姓名，这些基于 ID 的密码来生成私钥。它所依赖的是对 ID 的信任。私钥生成机构负责根据 ID 生成私钥，并将私钥安全的发送给合法的接收者。由于私钥生成机构拥有对所有密文的解密权限，所以自身的安全性需要更加注意。

PKG 相对于 PKI 的优点在于，发送者无需在加密前获得接收者的公钥，接收者在真正解密操作前也无需管理自己的私钥。

2. 注册相似人名进行攻击

注册相似的人名来骗取对方的信任。

3. 窃取认证机构的私钥进行攻击

这种方式就是攻击 CA。如果 CA 发现私钥真的被窃取了，需要及时通知所有用户，并及时作废相关证书，更新 CRL。

4. 攻击者伪装成认证机构

认证机构不需要登记，谁都可以充当认证机构，只是别的 CA 认不认可的问题。攻击者可以通过伪造自己是 CA，给用户颁发证书，这样证书验证肯定都没问题。但是通信之间的内容没有秘密可言了。例如攻击者可以 DNS 污染一片区域或者攻击一个 Wifi 信号，让这片区域的用户都误认为攻击者是信任的 CA，接下来就可以实施攻击了。

如果认证机构不可信，即便证书合法，它对应的公钥也不能使用。

5. CRL 的“漏洞”

攻击者可以利用 CRL 发布的时间差来进行攻击。A 向 B 发邮件说要 100 W，当 B 给 A 转了 100W 以后，A 就抵赖说自己并没有发那封邮件。签名并非是 A 自己，因为证书已经被作废了。B 没有及时更新 CRL，所以导致对方可以抵赖。

应对这种攻击：

  • 当公钥失效的时候尽快通知认证机构(A 用户)
  • 尽快发布 CRL(CA)
  • 及时更新 CRL(B 用户)

七、公钥证书的无法解决的问题

至此，公钥证书介绍完毕。公钥证书目前也没有任何无法解决的问题。它可以识别篡改或者发送者身份是否被伪装，也就是验证消息的完整性，还可以对消息进行认证。还可以防止抵赖。

公钥证书和数字签名的区别就在于认证机构上。有同学可能疑惑认证机构的必要性。

  • 如果能取得可信的公钥，就不需要认证机构。这种情况只能本人面对面才行，否则都不可信。
  • 当持有可信的认证机构的公钥，并相信认证机构所进行的身份确认的情况下，可以信任该认证机构颁发的证书以及通过该途径取得的公钥。
  • 认证机构是在完全不可信的状态下创造出信任关系。

Reference：

《图解密码技术》

GitHub Repo：Halfrost-Field

Follow: halfrost · GitHub

Source: https://halfrost.com/digital_certificate/