4.3　PKI

有了数字证书之后，为了支持网络环境下基于数字证书的公开密钥密码应用（加密与解密、签名与验证签名等），需要一个标准的公钥密码的密钥管理平台来实现证书的管理（包括证书的申请、颁发和撤销）、证书的查询、密钥管理（包含密钥更新、密钥恢复和密钥托付等）和策略管理等任务，这就是公钥基础设施（PKI）。也就是说，创建PKI的主要目的就是用来安全、便捷、高效地获得公钥数字证书。

美国早在1996年就成立了联邦PKI指导委员会，目前联邦政府、州政府和大型企业都建立了相应的PKI。欧盟各成员国和日本也都建立了自己的PKI。1998年，我国的电信行业建立了国内第一个行业认证中心（CA），此后工商、金融、海关等多个行业和一些省市也建立了各自的行业CA或地方CA。目前，PKI已成为世界各国发展电子政务、电子商务和电子金融的基础设施。

4.3.1　PKI组成

作为一种标准的为利用公钥加密技术实现保密通信而提供的一套安全基础平台，PKI主要由公钥证书、证书管理机构、证书管理系统、保障证书服务的各种软硬件设备以及相应的法律基础共同组成。其中，公钥证书是PKI中最基础的组成部分。

一个典型的PKI系统如图4-8所示。

1．签证机构（CA）

在PKI中，CA是所有注册用户所依赖的权威机构，它严格遵循证书策略机制所制定的PKI策略来进行证书的全生命周期的管理，包括签发证书，管理和撤销证书。CA是信任的起点，只有信任某个CA，才信任该CA 给用户签发的数字证书。

为确保证书的真实性和完整性，CA需要在给用户签发证书时加上自己的签名，如图4-1所示。为方便用户对证书的验证，CA也给自己签发证书。这样，整个公钥的分配都通过证书形式进行。

对于大范围的应用，特别是在互联网环境下，由于用户众多，建立一个管理全世界所有用户的全球性PKI是不现实的，因此往往需要很多个CA才能满足应用需要。例如，对于一个全国性的行业，由国家建立一个最高级的CA，每个省建立一个省级CA，根据需要每个地市也可建立自己的CA，甚至一个企业也可以建立自己的CA。不同的CA服务于不同范围的用户，履行不同的职责。等级层次高的CA为下层的CA颁发数字证书，其中最高层的CA被称为根CA（Root CA），面向终端用户的一般是最下层的CA。一般将这种CA层次信任模型称为“树模型（tree model）”或“层次模型（hierarchy model）”，如图4-9所示。图中所示结构称为“信任树（tree of trust）”，树根是根CA，叶子是非CA的终端用户。每个中间层的CA和终端实体都需要拥有根CA的公钥（一般通过安全的带外方式安装），以便与根CA建立信任关系。在这种层次结构中，用户总可以通过根CA找到一条连接任意一个CA的信任路径，如图4-9中虚线所示的是终端用户A到终端用户B之间的信任路径。CA的等级划分可以将工作任务分摊，减轻工作负担。

要验证一份证书（C1）的真伪（即验证CA对该证书信息的签名是否有效），需要用签发该证书（C1）的CA的公钥进行验证，而CA的公钥保存在对这份证书进行签名的CA证书（C2）内，故需要下载该CA证书（C2），但使用该证书验证又需先验证该证书本身的真伪，故又要用签发该证书的证书（C3）来验证，这样一来就构成一条证书链的关系（C1-C2-C3……），这条证书链在哪里终结呢？答案就是根证书。根证书是一份特殊的证书，它的签发者是它本身（根CA），安装了根证书就表明你对该根证书以及用它所签发的证书都表示信任，不需要再通过其他证书来验证，证书的验证追溯至根证书即结束。因此，唯一需要与所有实体都建立信任的是根CA，即每个中间CA和终端实体都必须拥有根CA的公钥—它的安装一般通过安全的带外方式实现。根CA也称为“信任锚（trust anchor）”，即认证的起点或终点。

如果一个组织本身就采用层次结构，则上述层次结构的CA组织方式就非常有效。但是，对于内部不采用层次结构的组织以及组织之间，则很难使用层次结构的CA组织方式。解决这个问题的一般方式是权威证书列表，即将多个CA证书机构内受信任的、含有公钥信息的证书安装到验证证书的应用中。一个被广泛使用的典型应用就是Web浏览器。

大多数Web浏览器中包含有50个以上的受信任的CA证书，并且用户可以向浏览器中增加受信任的CA证书，也可以从中删除不受信任的证书。当接收到一个证书时，只要浏览器能在待验证证书与其受信任的CA证书之间建立起一个信任链，浏览器就可以验证证书。如图4-10所示的是360浏览器中的CA数字证书，主要集中于根CA（图4-10(a)）和中间CA（图4-10 (b)）两个层次。

下面我们通过一个例子来说明Web浏览器与网站服务器间信任关系的建立过程。假定某网站a.b.c.d在如图4-10(a)所示的证书颁发机构SecureTrust CA申请了自己的数字证书（用认证机构SecureTrust CA的私钥签名的含有a.b.c.d身份信息和对应公钥的记录），现在用户小张想使用安全的HTTP协议（即使用HTTPS协议，将在第9章介绍）访问网站a.b.c.d，小张的浏览器就要求网站a.b.c.d提供其数字证书（如前假定，由SecureTrust CA签发）。得到该数字证书后，如果小张使用的浏览器中安装了SecureTrust CA的根证书（见图4-10(a)），则浏览器即可根据SecureTrust CA的根证书中的公钥来验证a.b.c.d提供的证书的真伪。如果验证成功，则浏览器就成功建立了与目标网站间的信任关系，即可从a.b.c.d的证书中获得网站服务器的公钥，开始后续的与a.b.c.d间的安全通信过程；如果验证失败，则浏览器认为它所访问的网站并不是真正的a.b.c.d，而是假冒a.b.c.d的攻击者。

从本质上讲，上述Web浏览器信任模型更类似于前面介绍的认证机构的层次模型，是一种隐含根（将权威证书列表中的证书作为受信任的根CA）的严格层次模型。也有文献将其称为“Web模型（Web model）”。这种模型使用起来比较方便，但也存在许多安全隐患。首先，因为浏览器用户自动信任预安装的所有证书，即使这些受信任的CA中有一个是“不称职的”（例如，该CA没有认真核实被其认证的服务器），则服务器提供的证书的真实性也就得不到保障；其次，如果用户在其浏览器中不小心安装了一个“坏的”CA的证书，则由该CA签发的所有证书都会变得不可信，这将严重威胁用户的信息安全（例如，“坏的”CA可进行中间人攻击）；最后，没有一个好的机制来撤销嵌入到浏览器中的根CA的证书，如果发现一个根CA的证书是“坏的”或与证书中公钥对应的私钥被泄露了，要使全世界所有在用的浏览器都自动地废止该证书的使用基本上是不可能的。

解决非层次组织机构中多个CA的信任问题的另一种方式是使用双向交叉认证证书。交叉认证（cross certification）是指通过某种方法将以前无关的CA连接在一起，建立起信任关系，彼此可以进行安全认证。它通过信任传递机制来完成两者信任关系的建立，是第三方信息关系的拓展，即一个CA的用户信任所有与自己CA有交叉认证的其他CA的用户。相当于把原来局部PKI连接起来构成一个大的PKI，使得分属于原来各局部PKI的用户之间的安全认证和保密通信成为可能，从而实现多个PKI域之间的互操作。实现交叉认证的方式主要有：①各PKI的CA之间互相签发证书，从而在局部PKI之间建立起了信任关系；②由用户控制交叉认证，即由用户自己决定信任哪个CA或拒绝哪个CA。这种方式中，用户扮演一个CA的角色，为其他的CA或用户签发证书。这样，通过用户签发的证书把原来不相关的CA连接起来，实现不同CA域的互联、互信任和互操作；③由桥接CA控制交叉认证。桥接CA（Bridge CA）是一个第三方CA，由它来沟通各个根CA之间的连接和信任关系。一般将上述交叉认证建立的CA信任模型称为“森林模型”。

上述非层次组织机构中多个CA信任问题解决方案中，权威CA列表方式对依赖方有较高要求，且权威列表本身的维护代价较高。在CA交叉认证方式中，只适用于CA数量较少的情况，但当CA数量较大时，大量CA两两进行交叉认证就会形成复杂的网状结构，且证书策略经过多次映射之后会使证书用途大大受限。桥接CA方式类似现实生活中行业协会中介的信任关系，CA数量较多时可以避免两两交叉认证的弊端，但桥接CA运营方的选择是个难题，它的可信程度直接决定了互信关系的可靠程度。

区块链技术的发展为多CA证书互信共享提供了新的解决方案。一种可能的基于区块链的CA证书互信共享机制如图4-11所示[23]。图中CA1~CAn为CA机构，负责验证用户新申请证书的合法性，产生新区块；证书用户是数字证书的实际拥有者；证书使用者指的是信任证书系统的终端用户。CA机构以联盟链的方式，通过共识完成CA证书的验证工作。经过共识的证书将记录到区块链当中，这些证书就被区块链中所有CA认为是可信的证书。

除了上述信任模型，还有一种模型是以用户为中心的信任模型（user centric trust model）。在这种模型中，每个用户自己决定信任其他哪些用户。一个用户最初信任对象包括用户的朋友、家人或同事，通过受信任对象的介绍（用介绍人的私钥进行签名或电话确认等），一个用户可以信任介绍人介绍的对象，从而形成一种信任网（Web of trust）。但是，这种信任关系的传递不一定是必需的。A信任B，B信任C，并不代表A也要完全信任C。在信任传递过程中，信任的程度可能是递减的。这种信任模型的典型代表是常用于安全电子邮件传输的PGP所使用的信任模型，我们将在第10章进行详细介绍。

2．注册机构（RA）

RA（Registration Authority）是专门负责受理用户申请证书的机构，它是用户和CA之间的接口。RA负责对用户进行资格审查，收集用户信息并核实用户身份的合法性，然后决定是批准还是拒绝用户的证书申请。如果批准用户的证书申请，则进一步向CA提出证书请求。这里的用户指的是将要向CA申请数字证书的客户，可以是个人、集团公司或社会团体、某政府机构等。除了证书申请，RA还负责受理用户的恢复密钥的申请以及撤销证书的申请等工作。

由于RA直接面对最终用户，因此，一般将RA设置在直接面对客户的业务部门，如银行的营业部、机构人事部门等。当然，对于一个规模较小的PKI应用系统来说，也可以把RA的职能交给CA来完成，而不是设立独立执行的RA，但这并非取消了PKI的注册功能，而仅仅是将其作为CA的一项功能而已。PKI国际标准推荐由一个独立的RA来完成注册管理的任务，这样既有利于提高效率，又有利于安全。另外，CA和RA的职责分离，使得CA能够以离线方式工作，避免遭受外部攻击。一个CA可以对应多个地理上分散的RA。

申请注册可以通过网络在线进行，也可离线办理。在线申请方便了用户，但不利于RA对申请者的信息的深入了解，而这是离线办理的优势。与用户面对面办理，可以向申请者详细介绍证书政策和相关管理规定，还可以通过面谈的方式详细了解用户的身份及其他相关信息。

3．证书发布系统

证书产生之后，由证书发布系统以一定的方式存储和发布，以便于使用。

为方便证书的查询和使用，CA采用“证书目录”的方式集中存储和管理证书，通过建立目录服务器证书库的方式为用户提供证书服务。此外，证书目录中还存储了用户的相关信息（如电话号码、电子邮箱地址等）。由于证书本身是公开的，因此证书目录也是非保密的。但是，如果目录中还存储了用户证书之外的相关信息，则这些信息一般需要保密。

目前，大多数PKI中的证书目录遵循的标准是X.500。为方便在因特网环境中应用证书目录，人们对X.500进行了简化和改进，设计了“轻量级目录存取协议LDAP（Lightweight Directory Access Protocol）”。LDAP协议在目录模型上与X.500兼容，但比X.500更简单、更容易使用。此外，由于LDAP协议是一种用于存取目录中信息的协议，因此它对目录数据库没有做特殊的规定，因而适应面宽、互操作性好。通过LDAP协议，用户可以方便地查询证书目录中的数字证书和证书撤销列表（CRL），从而得到其他用户的数字证书及其状态信息。

4．PKI策略

PKI策略是指一个组织建立和定义的公钥管理方面的指导方针、处理方法和原则。在PKI中有两种类型的策略：一是证书策略，用于管理证书的使用；另一个是证书实践指南（Certificate Practice Statement,CPS）。

X.509有关证书策略的定义是：一套用于说明证书的适用范围和／或应用的安全限制条件的规则。比如，某一特定的证书策略可以声明用于电子商务的证书的适用范围是某一规定的价格范围。制定证书策略的机构称为“策略管理机构”。

CPS指导用户如何在实践中增强和支持安全策略的一些操作过程，内容包括：CA是怎样建立和运作的；证书是怎样发行、接收和废除的；密钥是怎样产生、注册的，以及密钥是如何存储的，用户是怎样得到它的等。一些由商业证书发放机构（CCA）或者可信的第三方管理的PKI系统必须要有CPS。

4.3.2　证书签发和撤销流程

1.证书签发

证书签发流程如图4-12所示。

如前所述，证书的申请有两种方式，一是在线申请，二是离线申请。在线申请就是通过浏览器或其他应用系统通过在线的方式来申请证书。这样的方式一般用于申请普通用户证书或测试证书。离线方式一般通过人工的方式直接到证书机构、证书受理点去办理证书申请手续。通过审核后获取证书，这样的方式一般用于比较重要的场合。下面介绍CA签发证书的主要流程。

① 申请用户向RA申请注册。

申请用户与注册机构人员联系或通过网络在线填写申请资料，证明自己的真实身份，或者请求代理人与注册机构联系。注册机构操作员对用户提交的信息进行严格审核，如果认为申请符合要求，则将申请信息提交给CA；否则，拒绝用户的申请。

② 经RA批准后由CA产生密钥，并签发证书。

CA收到RA转来的用户证书申请（也可由用户自己向CA提交RA的注册批准信息及自己的身份等信息）后，执行以下操作：CA验证所提交信息的正确性和真实性；CA为用户产生密钥（公钥用于生成证书，私钥交给用户），或由用户自己产生公钥和私钥并提交公钥给CA来生成证书，但需要注意的是用户自行生成私钥情况下，私钥文件一旦丢失，CA由于不持有私钥信息，无法恢复其私钥；CA生成证书，并用CA的私钥对用户的证书进行签名，这样任何人都可以用 CA 的公钥对该证书进行合法性验证；将证书的一个副本交给用户，并存档入库。

③ 将密钥进行备份。

在实际应用中，用户丢失或损坏密钥（私钥）的事情常有发生，导致已加密的数据无法解密，如果是签名密钥丢失，则可能会导致用户签名被伪造，给用户造成损失。一种解决方案是在CA处建立一个密钥备份与恢复服务器，当CA用户签发证书时，将密钥进行备份。需要注意的是只能对用于解密的私钥进行备份和恢复，对用于数字签名的私钥不能进行备份和恢复，因为在PKI中数字签名用于实现不可否认服务，这就要求与时间戳服务相结合，因此数字签名有时间性要求。如果用于数字签名的私钥损坏或泄露，只能撤销证书。

④ 将证书存入证书目录。CA将颁发的证书信息存入证书目录，以便用户下载或查询。

⑤ CA将证书副本送给RA，RA进行登记。

⑥ RA将证书副本送给用户。

2.证书的撤销

如前面图4-1所示，每个证书都是有使用期限的，使用期的长短由CA的PKI政策决定。一旦证书的有效期到期，则该证书应当被撤销。

除了有效期过期，还有一些情况也需要撤销证书，如证书公钥对应的私钥被泄露或证书的持有企业倒闭，或证书的持有人严重违反证书的规定等情况。此外，证书持有人还可申请临时停用证书，称为“证书冻结”，例如持有人临时休假一个月，不会使用证书，则可申请冻结证书，待恢复工作后再解除冻结。

证书的撤销也有经过申请、批准、撤销三个过程。申请可以由证书持有人发起，如持有人发现自己的私钥泄露的情况；也可由RA发起，如RA发现持有人严重违反证书的管理规定；证书持有人所在单位也可申请撤销某个用户的证书，如该持有人离职的情况。RA负责受理撤销证书的申请，并决定接受还是拒绝撤销证书的申请。CA最终实施证书的撤销，在证书目录中标注该证书已撤销等相关信息，并将这一信息发布出去，告知其他用户。

一般有两种发布证书撤销消息的方式：一是CA定期公布证书撤销列表（CRL，如图4-7所示），时间间隔由CA的证书策略决定；二是用户在线查询，如图4-12所示。定期公布的方式的优点是不需要保密，成本低，缺点是撤销信息不能及时告知所有用户，可能会造成已撤销证书的滥用，当CRL太大时会降低效率。对于一些大的CRL可以采用分段发布的方式，即把一个大的CRL分成若干小的CRL，每次发布一个小的CRL，同时要包含其在CRL表中的位置信息（称为CRL分布点）。通过CRL分布点，可以定位到一个目录服务器或目录数据库中的某个具体位置。

对于多个CA的PKI系统，可将多个CA的CRL合并成一个CRL，委托第三方管理和发布。一般将这种CRL称为间接CRL。

CA的证书也需要撤销，描述CA等证书机构的撤销证书的列表称为机构撤销列表（Authority Revocation List,ARL）。

定期发布CRL方式的实时性和效率存在问题，因此比较适合离线操作机制。用户在线查询的方式是指当用户需要使用某一证书时，在线适时地向证书管理机构查询并获得该证书是否被撤销的确切消息。IETF PKIX工作组制定了一个在线证书状态查询协议（Online Certificate Status Protocol,OCSP）支持用户在线查询，实时获得证书的状态（有效、撤销、冻结），如是否已被撤销，如图4-12所示。与定期发布方式相比，在线查询机制更简单和快速。申请者首先向OCSP服务器发送一个查询请求（包含请求者的标识符和要查询的证书的标识符等信息），一次可以查询一个或多个证书的状态。OCSP服务器收到查询请求后向目录服务器查询，然后将查询结果（包括响应者的标识符、产生响应的时间、证书的标识符、证书的状态、其他辅助消息）返回给请求者。为了安全起见，查询响应一般要经过响应者数字签名。

4.3.3　证书的使用

因为PKI提供了完整的加密解密方案，所以有许多用于安全通信的协议和服务都是基于PKI来实现的，如TLS、SSL和IPsec等。

在实际应用中，用户首先必须获取信息发送者的公钥数字证书，以及一些额外辅助验证的证书（如CA的证书，用于验证发送者证书的有效性）。证书的获取有多种方式，如发送者发送签名信息时附加发送自己的证书；用独立信道发送证书；通过访问证书目录来获得，或者直接从证书相关的实体处获得等。

获得证书后，使用前应当首先进行认证。证书认证是指检查一个证书是否真实的过程，主要包括以下认证内容：

（1）用CA根证书中的CA的公钥验证证书上的CA签名（这个签名是用CA的私钥生成的）是否正确，如果正确则说明该证书的真的，否则证书有假。

（2）检查证书的有效期项，以验证证书是否处在有效期内。

（3）验证证书内容的真实性和完整性。

（4）验证证书是否已被撤销或冻结（OCSP在线查询方式或CRL发布方式）。

（5）验证证书的使用方式是否与证书策略和使用限制相一致。

上述过程是证书应用中的一个重要环节，要求安全、高效，否则会影响应用系统的工作效率。

从使用过程来看，CA用于签发证书的私钥的保密性非常重要，如果一旦泄露，所有由该CA签发的证书将不能再使用。因为获得该CA私钥的任何人都可以签发证书，导致用户无法区分是真正CA签发的，还是获得泄露出来的CA私钥的人签发的。

一种可能的解决方案是该CA重新产生一个公私钥对，并公布其新的公钥证书，同时重新给其所有用户颁发新的证书。但是怎么通知给每个证书使用者呢？而且使用者也未必人人都会添加信任证书到自己的系统里。如果CA的用户众多，这几乎是一个不可能完成的任务。因此，大多数情况下，该CA颁发的所有证书将不再被信任。

2011年8月，荷兰CA供应商DigiNotar的8台证书服务器被黑客入侵（实际发现入侵的时间是7月19日，但直到8月份才被公布出来）。黑客利用控制的CA服务器发行了500多个伪造的证书，包括google.com、skype.com、cia.gov、yahoo.com、twitter.com、facebook.com、wordpress.com、live.com、mozilla.com、torproject.org等用户。事件发生后，该公司发行的证书被众多浏览器和操作系统厂商宣布为不受信任的，最终导致该公司破产。

4.3.4　PKIX

在PKI标准化方面，因特网标准化组织IETF成立了PKI工作组，制定了PKIX系列标准（Public Key Infrastructure on X.509，PKIX）。PKIX定义了X.509证书在Internet上的使用规范，包括证书的产生、发布、获取、撤销，各种产生和发布密钥的机制，以及怎样实现这些标准的框架结构等。标准中涉及的相关概念和核心思想在前面已经做了简要介绍，标准的详细内容读者可参见具体的RFC标准。本节主要给出PKIX制定的相关标准。

PKIX中的基础标准以RFC 5280为核心，阐述了基于X.509的PKI框架结构，详细定义了X.509 v3 公钥证书和X.509 v2 CRL的格式、数据结构及操作步骤等，如表4-1所示。

PKIX中与证书操作有关的标准涉及CA/RA或端实体与证书库之间的交互操作，主要描述PKI系统中实体如何通过证书库来存放、读取证书和撤销证书。这些操作标准主要包括RFC 2559、RFC 2560、RFC 2585、RFC 2587，如表4-2所示，定义了X.509 v3公钥证书和X.509 v2 CRL分发给应用系统的方式，以及通过包括基于LDAP、HTTP、FTP等多种手段获取公钥证书和CRL的方式。

PKIX中的管理协议涉及管理实体（CA/RA）与端实体内部的交互，主要描述PKI系统实体间如何进行信息的传递和管理，以完成证书的各项管理任务和实体间的通信与管理。PKIX中管理协议标准包括RFC 2510、RFC 2511、RFC 2527和RFC 2797等，如表4-3所示。

此外，PKIX还定义了一些扩展协议来进一步完善PKI安全框架的各种功能，如安全服务中防抵赖和权限管理等。PKIX中的扩展协议包括RFC 3029、RFC 3161、RFC 3281等多个协议草案，涉及DTS（Digital Time Stamp）、DVCS（Data Validation and Certificate Server）和属性证书等。支持防抵赖服务的一个核心就是在PKI的CA/RA中使用数字时间戳DTS，通过对时间信息的数字签名，确定在某一时间某个文件确实存在和确定多个文件在时间上的逻辑关系。PKI系统中的数据有效性验证服务器DVCS的作用就是验证签名文档、公钥证书和数据的有效性，其验证声明称为数据有效性证书。数据有效性验证服务器DVCS是一个可信任的第三方，用来作为构造可靠的防抵赖服务的一部分。权限管理通过属性证书来实现，属性证书利用属性类别和属性值来定义每一个证书持有者的权限、角色等信息。