HCIE-Security Day34：PKI证书

PKI基本架构

公共基础设施，public key infrastructure。通过使用公钥技术和数字证书来提供系统信息安全服务，并负责验证数字证书持有者身份的一种体系。

PKI的核心围绕数字证书的申请、颁发、使用等整个生命周期展开，使用到：对称密钥加密、公钥加密、数字信封、数字签名等技术。

解决问题

1、公钥合法性

A与B进行通信，C作为攻击者存在于网络中，它有A和B的公钥，C拦击了B发送给A的B的公钥，并将自己的公钥发送给A，A获得的是C的公钥，C再拦截了B发送给A的信息，用自己的私钥对伪造的信息进行签名，然后使用A的公钥对伪造信息进行加密，将这两部分发给A，A收到后会使用自己的私钥进行解密得到明文，通过使用C的公钥来验证信息完整性，这期间A始终以为是B发给自己的信息，但从一开始就没有搞清楚B是谁，根本原因就是无法保证公钥的合法性。

2、私密性

3、通过数字证书来验证---不可否认性和源认证性。

4、数字证书中的数字签名---完整性

密钥管理面临的挑战

在使用任何基于rsa服务之前，一个实体需要真实可靠的获取其他实体的公钥。

1、通过非信任的通道，公钥交换必须是安全的

2、在密钥交换的过程中，公钥必须不能被截获和更改

3、交换呈现full mesh的复杂度（网络中实体非常多，它们互相直接需要建立信任关系，这个复杂度是n(n-1)/2。

4、由最终用户来确认密钥有效性，非常不靠谱，即非对称加密中，无法验证公钥合法性。

为了解决这个问题，只能手工密钥交换与确认，即带外验证：

1、回读收到的密钥（指纹），比如对其进行hash，通过一个安全的通道/途径（电话）进行确认。

2、如果它是匹配的，说明密钥在传输过程中没有被更改

3、它不具备可拓展性（不能给1000个人去确认啊）

验证公钥的方法

1、带外验证：打电话、发短信、发邮件，缺点是不具备可拓展性

2、受信任的介绍：实体们通过与一个公认的受信任的实体离线确认公钥后得到该受信任实体对该公钥合法性的背书，再通过该公认的受信任的实体代为转达其公钥。

具体是受信任的实体使用自己的私钥为其他实体的公钥进行签名（背书），其他实体使用受信任的实体的公钥解密，得到了实体的公钥。之后这些实体间互相验证签名就是靠谱的了。

这个公认的受信任实体就是CA，我们可以将其理解为公安局。为什么我们的身份证在国内处处被信任呢？因为公安局在给我们背书。

PKI的组成

一个PKI体系由终端实体、证书认证机构、证书注册机构、证书/CRL存储库四部分共同组成。

证书认证机构CA：证书颁发机构，PKI的核心，比如某某市公安局。是一个用于颁发并管理数字证书的可信实体。它是一种权威性、可信任性和公正性的第三方机构，通常由服务器充当，例如Windows Server 2008

1、仅仅只有一个受信任的介绍者(证书颁发机构）

2、CA签署每一个人的公钥

3、每个人都拥有CA的公钥

证书注册机构RA：RA是CA面向用户的窗口，是CA的证书发放、管理功能的下放，负责接受用户的证书注册和撤销申请，对用户的身份信息进行审查，并决定是否想CA提交签发或者撤销数字证书的申请，比如某某镇派出所户籍办理大厅。RA作为CA的一部分而存在，也可以独立CA存在，减轻CA压力，增强CA的安全性。

终端实体EE:PKI产品或者服务的最终使用者，即需要得到可信公钥的一个实体，包括个人、机构、设备、进程。

证书/CRL存储库：由于用户名称的改变、私钥泄露或业务中止等原因，需要存在一种方法将现行的证书吊销，即撤销公钥及相关的PKI实体身份信息的绑定关系。在PKI中，所使用的这种方法为证书废除列表CRL。

任何一个证书被撤销以后，CA就要发布CRL来声明该证书是无效的，并列出所有被废除的证书的序列号。因此，CRL提供了一种检验证书有效性的方式。

证书/CRL存储库用于对证书和CRL等信息进行存储和管理，并提供查询功能。构建证书/CRL存储库可以采用LDAP（Lightweight Directory Access Protocol）服务器、FTP（File Transfer Protocol）服务器、HTTP（Hypertext Transfer Protocol）服务器或者数据库等等。其中，LDAP规范简化了笨重的X.500目录访问协议，支持TCP/IP，已经在PKI体系中被广泛应用于证书信息发布、CRL信息发布、CA政策以及与信息发布相关的各个方面。如果证书规模不是太大，也可以选择架设HTTP、FTP等服务器来储存证书，并为用户提供下载服务。

PKI体系架构

 

1、用户通过与PKI的管理层RA进行交互，通过RA身份验证后，就可以提交申请到CA进行证书申请，CA就可以颁发证书给用户。

2、现实生活中以网银为例，RA的角色由银行扮演，比如网银需要用到证书，这个证书的申请还需要到银行填写表格，由银行确认，CA才会颁发。

3、在一些具体的解决方案中，可以使用计算机通过网络来实现整个PKI结构的使用及其服务申请。

证书申请/吊销/存储方式

证书的申请是PKI实体向CA自我介绍并获取自己证书的过程。

申请

• 在线申请

  PKI实体支持通过SCEP（Simple Certificate Enrollment Protocol）协议向CA发送证书注册请求消息来申请本地证书。

• 离线申请（PKCS#10方式）

  离线申请是指PKI实体使用PKCS#10格式打印出本地的证书注册请求消息并保存到文件中，然后通过带外方式（如Web、磁盘、电子邮件等）将文件发送给CA进行证书申请。

还有种方式，PKI实体可以为自己颁发一个自签名证书或本地证书，实现简单的证书颁发功能。

吊销

由于用户身份、用户信息或者用户公钥的改变、用户业务中止等原因，用户需要将自己的数字证书撤销，即撤销公钥与用户身份信息的绑定关系。在PKI中，CA主要采用CRL或OCSP协议撤销证书，而PKI实体撤销自己的证书是通过带外方式申请。

存储

CA生成本地证书后，CA/RA会将本地证书发布到证书/CRL存储库中，为用户提供下载服务和目录浏览服务。

证书验证四部曲

第一步：验证前的准备

A有：A的公钥，A的私钥，CA颁发的A的证书，CA的证书

B有：B的公钥，B的私钥，CA颁发的B的证书，CA的证书

数字证书主要有：个人信息、公钥信息、数字签名（把个人信息+公钥信息做HASH,使用CA的私钥加密得到数字签名）

数字证书只解决这个公钥的持有者是谁的问题

不要混淆数字证书、CA证书、个人证书和数字签名的关系

CA证书可以简写为

个人证书可以简写为

 

CA证书的组成

CA生成的证书

版本：即使用X.509的版本，目前普遍使用的是v3版本

序列号：在CA服务范围内唯一

签名算法：CA签名使用的算法

颁发者：CA的名称

有效期：包含有效的起止日期，不在有效期范围内的证书为无效证书

主题：证书所有者的名称

公钥信息：对外公开的公钥

拓展信息：通常包含了使用者备用名称、使用者密钥标识符等可选字段

签名：CA的签名信息，又叫做CA的指纹信息

 

 

个人电脑中也有证书，运行键入mmc

第二步：交换证书

A把CA颁发的A的证书发给B

B把CA颁发的B的证书发给A

现在

A有：A的公钥，A的私钥，CA颁发的A的证书，CA的证书，B的证书

B有：B的公钥，B的私钥，CA颁发的B的证书，CA的证书，A的证书

第三步：验证证书合法性

以B来验证A的证书为例。

  

使用CA公钥解密SIG|CA私[hash(A公)]得到hash(A公),再将A公进行hash，与解密到的hash(A公)进行对比。公钥是真的，说明证书是真的。

注意CA合法性的验证需要带外验证，绝不能想当然用CA公去解密SIG|CA私[hash(CA公)]得到hash(CA公)去比较。

第四步：验证证书的持有者合法性

身份证是真的，不代表持有者是真的， 如果C把CA颁发给A的证书发给B，B是否就认为C是A？那么C即使有了CA颁发给A的证书，那么C还是不会有A的私钥的，验证A是不是A就是看它有没有A的私钥了。判断方式是让A发送一个hash值的时候用自己的私钥进行签名后连同源数据一起发送给B，那么B就可以使用A的公钥进行解密后得到hash值，再对源数据进行hash进行比较。就可以判断A是不是A。

 在IKEV1的主模式中，如果使用证书方式

 Initiator                          Responder
       -----------                        -----------
        HDR, SA                     -->
                                    <--    HDR, SA
        HDR, KE, Ni                 -->
                                    <--    HDR, KE, Nr
        HDR*, IDii, [ CERT, ] SIG_I -->
                                    <--    HDR*, IDir, [ CERT, ] SIG_R

 

作为发起方，第一步对自己的ike安全提议进行hash散列，然后用自己的私钥对其进行签名（解决证书持有者合法性验证问题)，然后拼接自己的证书（自己的证书中含有ca的签名，解决证书合法性验证问题），自己的个人信息，个人信息同时也在证书中存放，再加上头部，进行发送。 

作为接收方，第一步使用ca证书中ca的公钥对发起方个人证书中ca签名的发起方公钥进行解密，验证发起方身份（解决证书合法性验证问题），第二步得到发起方个人证书中的发起方个人信息，第三步使用发起方的公钥解密报文中发起方签名过的提议信息（解决证书持有者合法性验证问题)，进行比较。

证书申请步骤

第一步：同步时间

时间是整个PKI系统的重中之重，必须要先确保参加PKI系统的设备和主机的时间同步，才能开始PKI的部署。

第二步：部署证书服务器

证书服务器是整个pki系统的核心，可以选择微软的证书服务器。

第三步：客户端产生密钥

每一个实体在申请证书之前，需要预先产生RSA密钥对

 

第四步：验证证书服务器

每一个实体需要获取证书服务器的根证书，里面包含证书服务器的公钥，获取了根证书后，可以通过fingerprint离线验证证书服务器。

第五步：申请个人证书

每一个实体发送自己的个人信息和公钥到证书服务器

第六步：审核并签名证书

管理员对每一个证书请求进行审核，并且对个人信息和公钥内容进行数字签名，签名后的文件即为数字证书。

第七步：颁发数字证书

证书服务器把签名的证书颁发给实体

第八步：交换公钥

交换证书，证明实体与公钥之间的关联，公钥的具体作用由运用来决定。