0.PKI理论基础
网络通讯安全威胁
密码技术
|
密码技术 |
图示 |
解决问题 |
|---|---|---|
|
对称加密（举例：AES） |
|
保证了传输信息的机密性 存在问题： 需要事先将密钥进行共享，密钥的配送问题 |
|
非对称加密（举例：RSA） |
|
解决了传输信息的机密性 与对称加密相比：效率较低 |
|
组合加密技术 |
|
非对称加密用于对称加密的密钥协商，解决了密钥配送问题。 对称加密用于通讯。 |
|
摘要算法（哈希算法）（举例：md5，sha1，sha2） |
|
保证了信息的完整性 |
|
数字签名（摘要算法+非对称加密） |
|
解决了否认的问题 |
信息安全威胁解决方法
|
信息安全所面临的威胁 |
受威胁的特性 |
如何解决？对应的密码技术 |
|---|---|---|
|
窃听（秘密泄露） |
机密性 |
对称加密、非对称加密 |
|
篡改（信息被修改） |
完整性 |
摘要算法---------->数字签名（非对称加密+哈希算法） |
|
伪装（伪装成真正的发送者） 身份证明： 如何告诉别人你是谁？ 如何向别人证明，你确实是此人？ |
鉴别与授权（身份认证） |
数字证书 |
|
否认（事后称自己没有做） |
不可否认性 |
数字签名--------->数字证书 数字签名证明信息已经被发送或接收。
|
数字证书
公钥算法的最大问题：如何确认获得的对方的公钥的身份？A与B通信，A如何知道如何知道这个公钥确实是Alice的?
中间人攻击
如何理解证书？
通过第三方可信机构(CA)签名，将用户身份信息与其公钥进行绑定。
1.什么是PKI？
PKI是Public Key Infrastructure（公钥基础设施）的缩写，是一种普遍适用的网络安全基础设施。
PKI（Public Key Infrastructure）是硬件、软件、人员、策略和操作规程的总和，它们要完成创建、管理、保存、发放和废止数字证书的功能。数字证书是PKI中最基本的元素。
PKI是Public Key Infrastructure的缩写，其主要功能是绑定证书持有者的身份和相关的密钥对（通过为公钥及相关的用户身份信息签发数字证书），为用户提供方便的证书申请、证书作废、证书获取、证书状态查询的途径，并利用数字证书及相关的各种服务（证书发布，黑名单发布，时间戳服务等）实现通信中各实体的身份认证、完整性、抗抵赖性和保密性。
PKI基于公钥加密算法来保证网络通讯安全。
字面理解，为什么叫公钥基础设施（Public Key Infrastructure）？
公钥：基于公钥加密算法保证网络通讯安全
基础设施：可以基于PKI解决网络通信中的4大威胁，身份标识和认证、保密性、数据完整性和不可否认。
2.PKI系统的组成
2.1 PKI系统组成
一个PKI系统由以下几个部分组成：
|
角色 |
描述 |
|---|---|
|
证书签发系统（Certification Authorities) CA |
|
|
证书注册系统（Registration Authorities) RA |
|
|
证书存储系统（Repositories） |
存储证书请求、已签发的证书、已吊销的证书等 |
|
密钥归档服务器（Key Archival Server） |
存储证书对应的私钥，以免私钥丢失时进行恢复 （如果证书的私钥用于加密的话，需要对其进行归档备份） |
2.2 PKI系统如何工作
证书申请
1）新用户发起证书申请，发起注册信息给RA
2）RA系统审核用户身份，审核通过的注册请求发送给CA，CA为用户签发证书下载凭证
3）RA系统将证书下载凭证发送给用户，用户提交证书申请请求
4）证书下载到用户本地，同时，证书发布到证书仓库
应用程序校验证书：
-
获取用户的身份信息
-
进行证书吊销状态检查（CRL、OCSP）
-
检查证书的有效期
-
检验数字证书
3.CA层次结构
3.1 单层
Root CA和负责给实体颁发证书的CA是同一个CA。通常为了安全性考虑，这两个角色是分开的。
3.2 两层
两层结构可以满足大部分公司的需求了。
Root CA是离线的，负责颁发证书的CA是在线的。
相较于单层的优点：
1）安全性提升
Root CA和负责颁发证书的CA是分开的，更重要的是Root CA是离线的，所以CA的私钥可以更好地被保护。
2）灵活性和可扩展性提升
颁发证书的CA可以有多个，多个CA可以在不同的地理位置。
3.3 三层
相较于2级CA，在RootCA和颁发证书的CA间又多了一层。
多了这层有啥原因？
这层CA可以作为Policy CA。Policy CA可以限制颁发证书的CA可以颁发哪种证书。
从管理的角度看，Policy CA可以被用作管理边界，就是说你只能签发指定的证书，在颁发证书前执行指定级别的验证。
4. 信任模型——证书链
证书类型
根证书：RootCA的证书，是自签证书，即证书的申请者和签发者信息是一样的。
中间CA证书：二级CA的证书。
实体证书：最终实体的证书。
信任模型——证书链
如何进行有效性验证？仅仅拥有实体证书是无法进行有效性验证的，需要验证证书链。
安全问题——保证CA的私钥安全
CA，尤其Root CA对整个系统来说至关重要，如果Root CA的私钥被泄露，那么就可以签发任意域名的虚假证书。
另外，如果Root CA被吊销掉，所用使用这个CA签发的证书的网站都会无法访问。
现在仍然还有很多CA直接使用他们的根证书直接签发最终实体证书，这其实是非常危险的。Baseline Requirements限制所有的根证书密钥只能由人手动执行命令(自动化是不允3.4 证书链 59许的)，也就是说根证书密钥必须离线保存。
虽然还有很多依旧在使用的旧系统有这个漏洞，但是直接由根证书签发最终实体证书是不允许的。
5.X.509公钥证书
5.1 X.509公钥证书格式
X.509公钥证书共有3个版本（V1，V2，V3），高版本的会含有低版本的字段。
3.1.1证书字段（v1+v2）
V1基本字段信息
-
版本（Version）
证书一共有3个版本号，分别用0、1、2编码表示版本1、版本2、版本3。
版本1只支持简单的字段，版本2增加了两个标识符，版本3增加了扩展功能。现在大部分证书都采用版本3格式。
-
序列号（Serial Number）
证书的序列号，用于唯一标识证书，为唯一的正整数。
-
签名算法（Signature Algorithm Identifier）
证书签名所使用的算法
-
颁发者（Issuer Name）
证书的颁发者，比如包含了国家、组织和组织单位三个部分。
-
有效期（Validity Period）
证书有效的开始日期和结束日期，在这段时间内证书是有效的。
-
使用者（Subject Name）
指明证书的使用者，和公钥一起用于证书的签发。
在自签名证书里，使用者和颁发者是一样的。
最开始的时候，使用者字段通常为服务器主机名，但是为证书匹配多个主机名就很麻烦。
如今，使用者字段已经被废弃，转而使用使用者可选名称扩展。
-
公钥信息（Public Key Information）
公钥相关信息，主要是算法ID，可选参数和公钥本身。
V2中新加的字段
-
颁发者唯一ID（Issuer unique ID）
-
使用者唯一ID（Subject unique ID）
3.1.2 扩展字段（v3）
为了让原本死板的证书格式变得更加灵活，版本3引入了证书扩展。
|
Extension |
Description |
|---|---|
|
Authority Key Identifier(2.5.29.19) |
Identifies the certification authority (CA) public key that corresponds to the CA private key used to sign the certificate. 这个扩展的内容是签发此证书的CA的私钥对应的公钥的唯一标识符，通常用于在构建证书链时找到颁发者的证书。 |
|
Basic Constraints(2.5.29.35) |
Specifies whether the entity can be used as a CA and, if so, the number of subordinate CAs that can exist beneath it in the certificate chain. 基础约束扩展用来表明证书是否为CA证书，同时通过路径长度(path length)约束字段，来限制二级CA证书路径的深度(例如限制CA证书是否可以签发更深一层的CA证书以及 |
|
Certificate Policies(2.5.29.32) |
Specifies the policies under which the certificate has been issued and the purposes for which it can be used. 该扩展包含了一个或多个策略，每个策略都包括一个OID和可选限定符(qualifier)。限定符一般包括一个URI，从这个URI可以获得完整的策略说明。Baseline Requirements要求每一张最终实体证书需要包括至少一条策略信息，来表明该证书是在何种条款下签发的。另外这个扩展还能表明证书的验证类型。 |
|
CRL Distribution Points(2.5.29.31) CRL分发点 |
Contains the URI of the base certificate revocation list (CRL). 该扩展用来确定证书吊销列表(certificate revocation list，CRL)的LDAP或者HTTP URI地址。按照Baseline Requirements，每一张证书都至少需要包括CRL或者OCSP吊销信息。 |
|
Enhanced Key Usage(2.5.29.46) |
Specifies the manner in which the public key contained in the certificate can be used. 为了更加灵活地支持和限制公钥的使用场景，该扩展可以通过OID支持更多的场景。例如最终实体证书一般都拥有id-kp-serverAuth和id-kp-clientAuth两个OID，代码签名证书 |
|
Issuer Alternative Name(2.5.29.8) 签发者可选名称 |
Specifies one or more alternative name forms for the issuer of the certificate request. |
|
Key Usage(2.5.29.15) 密钥用法 |
Specifies restrictions on the operations that can be performed by the public key contained in the certificate. 该扩展定义了证书中密钥可以使用的场景，这些场景已经定义好了，可以通过设置来让证书支持某个场景。例如CA证书一般都设置了证书签名者(certificate signer)和CRL签 |
|
Name Constraints(2.5.29.30) |
Specifies the namespace within which all subject names in a certificate hierarchy must be located. The extension is used only in a CA certificate. 名称约束扩展可以限制CA签发证书的对象，这样命名空间就在可控范围内。这个功能非常有用，例如，它允许一个组织可以拥有一个二级CA，而这个CA只能签发这个公司所拥有的那些域名下的证书。有了这个限制，这类CA就不会影响整个生态系统了(例如，CA不能签发任意网站的证书)。RFC 5280要求将这个扩展设置为关键扩展，但是实际情况是，大部分CA都将其设置为非关键扩展，而Baseline Requirements也明确表示允许这么处理。主要原因是有一些产品无法解析名称限制这个扩展，如果标记为关键扩展，就会导致这些产品拒绝此类证书。 |
|
Policy Constraints(2.5.29.36) 策略限制 |
Constrains path validation by prohibiting policy mapping or by requiring that each certificate in the hierarchy contain an acceptable policy identifier. The extension is used only in a CA certificate. |
|
Policy Mappings(2.5.29.33) 策略映射 |
Specifies the policies in a subordinate CA that correspond to policies in the issuing CA. |
|
Private Key Usage Period(2.5.29.16) |
Specifies a different validity period for the private key than for the certificate with which the private key is associated. |
|
Subject Alternative Name(2.5.29.17) |
Specifies one or more alternative name forms for the subject of the certificate request. Example alternative forms include email addresses, DNS names, IP addresses, and URIs. 原本使用者证书字段(更准确地说是其中的通用名部分)是用来将身份信息和公钥绑定在一起的。而在实际使用的时候发现使用者字段不够灵活，只能支持与一个主机名进行绑定，无法同时处理多个身份信息。使用者可选名称扩展就是为了替换使用者字段，它支持通过DNS名称、IP地址和URI来将多个身份绑定在一起。 |
|
Subject Directory Attributes(2.5.29.9) |
Conveys identification attributes such as the nationality of the certificate subject. The extension value is a sequence of OID-value pairs. |
|
Subject Key Identifier(2.5.29.14) 使用者密钥标识符 |
Differentiates between multiple public keys held by the certificate subject. The extension value is typically a SHA-1 hash of the key. 该扩展包含了唯一的值，可以用来识别包含特别公钥的证书，一般建议使用公钥本身来建立这个标识符(例如通过散列)。所有的CA证书都必须包含这个扩展，并且它的值要与CA所签发出来的证书上的授权密钥标识符的值一样。 |
|
Authority Information Access 颁发机构信息访问 |
（OCSP URL）颁发机构信息访问扩展表明如何访问签发CA提供的额外信息和服务，其中之一就是OCSP响应程序的HTTP URI地址。信赖方可以使用这个服务来实时检测证书的吊销信息。 （CA证书URL）另外还有一些证书包含了签发CA的URI地址，有了这个地址，即便服务器返回的证书链中缺少了签发CA的证书，客户端也可以通过下载签发CA重新构建证书链。 |
3.2 证书生命周期
证书申请、生成、存储、发布
申请阶段：终端实体注册——》密钥对产生——》证书创建和密钥/证书分发
颁发阶段：证书检索，证书验证
取消阶段：证书过期，，证书吊销，证书恢复
证书吊销
证书具有一个指定的寿命，但 CA 可通过称为证书吊销的过程来缩短这一寿命。
可将下列情况指定为吊销证书的理由：
-
泄露密钥；
-
泄露 CA；
-
从属关系改变；
-
被取代；
-
业务终止；
|
说明 |
优缺点 | |
|---|---|---|
|
CRL |
CRL 证书吊销列表 (Certificate Revocation List ，简称： CRL) 是 PKI 系统中的一个结构化数据文件。 该文件包含了证书颁发机构 (CA) 已经吊销的证书的序列号及其吊销日期。 CRL 文件中还包含证书颁发机构信息、吊销列表失效时间和下一次更新时间，以及采用的签名算法等。 证书吊销列表最短的有效期为一个小时，一般为 1 天，甚至一个月不等，由各个证书颁发机构在设置其证书颁发系统时设置。 CDP 证书吊销列表分发点 (CRL Distribution Point ，简称 CDP) 是含在数字证书中的一个可以共各种应用软件自动下载（下载到本地）的最新的 CRL 的位置信息。 一个 CDP 通常出现在数字证书的 详细信息 选项卡的 CRL 分发点 域，一般会列出多个使用不同的访问方法，以确保如 Web 浏览器和 Web 服务器程序始终可以获取最新的 CRL 。 CDP 一般是一个可以访问 http 网址。 |
优点： 效率高（因为客户端将CRL下载到本地，客户端本地进行比对） 缺点： 1）不能及时反映证书的实际状态 2）随着下发证书增多，CRL会越来越大（解决方法：增量CRL） |
|
OSCP |
Online Certificate Status Protocol, 证书状态在线查询协议， 是用于实时查询数字证书在某一时间是否有效的标准。 CRL的缺点：不能实时 上面已经提到，一般 CA 都只是 每隔一定时间 ( 几天或几个月 ) 才发布新的吊销列表，可以看出： CRL 是 不能及时反映证书的实际状态的。 OCSP实时在线查询 而 OCSP 就能满足实时在线查询证书状态的要求。它为电子商务网站提供了一种实时检验数字证书有效性的途径，比下载和处理 CRL 的传统方式更快、更方便和更具独立性。请求者发送查询请求， OCSP 服务器会返回证书可能的三个状态：正常、吊销和未知。 OCSP 服务由独立的 OCSP 服务器来提供服务。 OCSP 也是一个可以访问的 http 网站。 |
能够及时反映证书实际状态 |
证书校验
1）证书完整性校验
使用CA的RSA公钥解密验证证书上的私钥签名是否合法，如果签名无效，则可认定证书被修改，直接报错。
2）证书有效性校验
CA在颁发证书时，都为每个证书设定了有效期，包括开始时间与结束时间。系统当前时间不在证书起止时间的话，都认为证书是无效的。
3）证书吊销状态监测
证书在有效期之内需要丢了怎么办？需要吊销证书了，那么这里就多了一个证书吊销状态的检测。
用户将需要吊销的证书通知到CA服务商，CA服务商通知浏览器该证书的撤销状态。来看一个证书吊销后的浏览器提醒：
4）验证发行者
HTTPS数字证书的使用分两个角色：
-
证书发行方issuer，有签名的私钥。
-
证书申请方subject，使用证书公钥进行身份验证的用户（一般浏览器）
-
浏览器检查证书的发行者字段与证书路径中上级证书的subject字段相同。
-
为了增加安全性，PKI在实现时，多数都验证了发行方的密钥、签名等信息是否跟当前证书的密钥相同。但对于信任链来说，根证书自己签发的，也就是说它们的issuer和subject是一样的。
根据CA的DN，得到CA证书，得到CA公钥，利用CA公钥校验签名；循环，直到校验到根证书，签发者和申请者是一样的。
3.3 证书示例
百度的证书
|
Root CA证书（自签证书） |
二级CA证书 |
实体证书 |
|---|---|---|
|
|
|
|
6.PKI应用
web安全
SSL/TLS
安全电子邮件
保证电子邮件传输安全
SET
SET协议(Secure Electronic Transaction，安全电子交易)是由VISA和Master Card两大信用卡公司联合推出的规范它采用公钥密码体制和X.509数字证书标准，主要应用于保障网上购物信息的安全性。
VPN
利用IPSec等保证私有性
IPSec
IP层安全
7.PKI安全性
CA私钥保护
对于PKI来说，最重要的就是对CA的私钥的保护。
CA私钥可以
1.颁发证书时的签名
2.发布CRL时进行签名
如何保护CA私钥？
最安全的是HSM。
角色分离（管理上）
可能管理员可以执行CA的全部功能
但是从对安全性有更高要求的环境来说，需要对CA的访问有更细粒度的控制。
-
CA or PKI Administrator ：管理CA
-
Certificate Manager ：颁发和撤销证书
-
Enrollment Agent：代替用户注册用书 -
Key Recovery Manager：当证书的私钥丢失了，进行恢复
其他辅助角色：
Backup Operator：负责备份CA，用于CA故障时恢复数据
Auditor：reivew审计日志，保证security policy没有被违反
安全策略（运营上）
Security policy包括CP和CPS
很多公司，尤其是颁发证书的第三方机构，有公开的Certificate Policy 和Certification Practice Statement。
Certificate Policy : 在签发证书时使用什么方法确定与实体建立联系（比如使用什么加密算法）
Certification Practice Statement：从安全的角度说明PKI操作。
一些由商业证书发放机构（CCA）或者可信的第三方操作的PKI系统需要CPS。这是一个包含如何在实践中增强和支持安全策略的一些操作过程的详细文档。它包括CA是如何建立和运作的，证书是如何发行、接收和废除的，密钥是如何产生、注册的，以及密钥是如何存储的，用户是如何得到它的等等。
参考资料
https://wenku.baidu.com/view/74ff14e66137ee06eef91815.html?from=search PKI技术详解
https://wenku.baidu.com/view/ac0c6aa5f524ccbff121841d.html?sxts=1577168241761 PKI技术及其应用
https://www.anquanke.com/post/id/183339#h2-10
https://www.cfca.com.cn/20150811/101230759.html 证书的有效性管理和验证—CRL及OCSP的异曲同工之妙