基于区块链的证书透明

基于区块链的证书透明和撤销透明

王泽1,2,3,林景强1,2,3(B)，蔡全威1,2,王琼霄1,2,3,荆继武1,2,3,和查大仁1,2
1信息安全国家重点实验室，中国科学院信息工程研究所，北京 100093，中国{wangze,linjingqiang,caiquanwei,wangqiongxiao}@iie.ac.cn
2 数据保障与通信安全研究中心，中国科学院，北京 100093，中国
3 中国科学院大学网络空间安全学院，北京 100049，中国

摘要

传统的X.509公钥基础设施(PKI)依赖证书颁发机构(CA)签发用于 SSL/TLS中认证Web服务器和建立安全通道的证书。然而，最近的安全事件表明，证书颁发机构可能（被攻破后）签发欺诈性证书。本文中，我们提出基于区块链的证书透明和撤销透明。我们的方案兼容X.509公钥基础设施，但显著增强了证书的安全保证。SSL/TLS Web服务器的CA签发的证书及其撤销状态信息由主体（即Web服务器）作为交易发布，社区中的矿工在验证交易并挖出新区块后将其追加到全球证书区块链上。证书区块链充当仅可追加的公共日志，用于监控证书颁发机构的证书签发和吊销操作，同时赋予SSL/TLS Web服务器对其证书的协同控制权，以平衡传统公钥基础设施中证书颁发机构的绝对权威。我们使用Firefox和 Nginx实现了原型系统，实验结果表明该系统引入了合理的开销。

关键词 ：PKI · SSL · TLS · Blockchain · Transparency · Trust

1 引言

在X.509公钥基础设施(PKI)中，证书颁发机构(CA)对证书进行签名，以将服务器的公钥与其身份（通常是DNS名称)。然后，这些证书在SSL/TLS中[14,21]用于认证Web服务器。浏览器信任证书颁发机构(CA)，通过SSL/TLS协商从CA签发的证书中获取服务器的公钥，以建立安全通道。

然而，最近的安全事件表明，证书颁发机构并不像人们所假设的那样值得信任。证书颁发机构可能由于入侵[11,24,46,58], 、草率的身份验证[44,54,55,61], 、操作失误[33,45,62],、存在缺陷的加密算法[53,60],或政府强制要求[15,52]而签发欺诈性证书。典型的欺诈性证书将DNS名称绑定到由伪造的Web服务器持有的密钥对[5,11,15]。随后，这些伪造的服务器即使在浏览器严格遵循证书验证[12]步骤建立 SSL/TLS会话的情况下，仍可发起中间人（MITM）攻击。

证书透明度[35]被提出以增强证书颁发机构操作的问责性，采用append-only公共日志。由证书颁发机构签发的证书将被公开记录在日志服务器中，否则浏览器将在SSL/TLS协商期间拒绝该证书。因此，欺诈性证书将被监控方或相关方（尤其是DNS名称或SSL/TLS Web服务器的所有者）发现。日志服务器中的证书以默克尔哈希树的形式组织，审计员会定期验证日志的完整性，以确保其为仅追加模式，即一旦添加，任何证书（包括欺诈性证书）都不得被删除或修改。

证书透明度遵循被动响应机制。它依赖于监控方在欺诈性证书被签名并记录到日志服务器之后进行观察。因此，在相关方发现之前，浏览器可能已经接受了该欺诈性证书。此外，为了确保仅追加记录，对已删除或修改的（欺诈的）证书的检测依赖于审计员的定期检测。考虑到当前证书的巨大数量及其增长量，对公共日志进行监控或审计是一项高负担的任务。

本文提出了一种基于区块链的方案，用于构建仅追加的证书透明度日志。在我们的方案中，由证书颁发机构签名的X.509证书由其主体（即相应的 Web服务器）通过证书交易发布到全球证书区块链中。该全球证书区块链作为天然的仅追加公共日志，用于监控证书颁发机构的操作。为了发布其证书，每个Web服务器都拥有一个发布密钥对，用于对其证书交易进行签名，该密钥对不同于证书中绑定的密钥对。这种主体控制的证书发布设计使得Web服务器能够与证书颁发机构协同管理其证书。该设计与证书密钥的信任声明（TACK）[39]和PoliCert [56]的理念一致，即Web服务器参与其证书的验证过程。

SSL/TLS Web服务器构成一个相互依赖的社区，以平衡传统公钥基础设施中证书颁发机构的绝对权威。具体而言，Web服务器的发布密钥最初由一定数量的这些相互依赖的Web服务器显式认证，同时由一个证书颁发机构隐式认证。因此，证书颁发机构在未经Web服务器社区同意的情况下，无法在证书区块链中发布证书。每个Web服务器的已认证发布密钥也公开记录在区块链中。这意味着证书的发布也是公开可追溯的。

每个证书交易都有一个有效期，比已发布证书的有效期更短。这要求 Web服务器定期发布其证书并更新撤销状态。当一个未过期证书被撤销时，它将不会出现在下一次交易中，而相应的证书吊销列表(CRL)文件或在线证书状态协议(OCSP)响应将被包含在该交易中。因此，证书颁发机构的撤销操作也被记录下来，并在证书区块链中实现了撤销透明度[34,51]。

所提出的方案通过使用欺诈性证书来保护浏览器免受冒充攻击。浏览器利用证书区块链来验证在SSL/TLS协商中收到的证书。只有当证书发布在未过期交易中时，才会被接受，因此由已被攻陷的证书颁发机构签名但未在区块链上发布的欺诈性证书将被浏览器拒绝。

我们使用 Nginx 和 Firefox 实现了原型系统。Nginx 服务器通过 SSL/TLS 扩展将证书交易发送给浏览器，浏览器则借助证书区块链对收到的证书进行验证。基于真实世界统计数据的分析和实验结果表明，我们的方案在存储、证书验证延迟、通信和激励成本方面引入了合理的开销。

其余部分组织如下。在第2节中，我们介绍安全模型，系统细节在第3节中描述。然后，在第4节中对所提出的方案进行分析，并在第5节中对原型系统进行评估。第6节为相关工作，第7节总结了本文。

2 威胁模型和设计目标

攻击者试图使用欺诈性证书冒充SSL/TLS Web服务器，成功的攻击意味着浏览器在SSL/TLS协商中接受了这些欺诈性证书。我们假设攻击者可能破坏一些受信任的证书颁发机构（CAs），以签署将目标Web服务器的DNS名称绑定到任意密钥对的欺诈性证书。攻击者还可能破坏目标服务器的发布密钥，以生成欺诈性消息。然而，我们假设他们无法破坏超过阈值数量的目标服务器认证者，也无法认证一个欺诈性的发布密钥。也就是说，我们的方案所考虑的最坏情况是：发布密钥对被攻击者持有或知晓，同时欺诈性证书由被破坏的证书颁发机构签发。

攻击者所拥有的计算资源不超过社区总计算能力的30%，且所有密码原语都是安全的。攻击者无法长时间阻断网络以实施攻击行为；即诚实实体之间以松散同步方式相互通信。

我们的目标是保护浏览器免受使用欺诈性证书的冒充攻击。如果浏览器遵循我们的方案来验证SSL/TLS协商中的证书，则可确保认证的对等方是合法的服务器的被访问DNS名称。即使在极端情况下，由受损害的发布密钥对在区块链中发布了欺诈性证书，浏览器也很可能会拒绝该欺诈性证书，并且该证书将很快通过证书区块链中的对抗措施交易得到恢复。

3 系统架构

3.1 概述

Web服务器将其证书交易发布到一个唯一的全球证书区块链中。与比特币类似，证书区块链中的每个区块都由一个区块头和多个交易组成，这些交易被组织成一个默克尔哈希树。一个区块头包含以下内容：（a）矿工开始挖该区块的时间；（b）区块链中前一个区块头的摘要；（c）所包含交易的默克尔哈希树根；（d）所包含交易的（类型, DNS名称）元组列表，按字典序排序；以及（e）通过暴力计算得出的工作量证明随机数，使得该区块的哈希值小于工作量证明目标。包含（类型, DNS名称）元组列表，以便浏览器或Web服务器能够方便地查找交易，而无需遍历所有包含的交易。

在证书区块链中，总体上有两种类型的证书交易。I型交易由Web服务器使用其发布密钥对签名，用于定期发布证书。当证书过期并被更新时，新证书将包含在下一次交易中；如果证书被撤销，则该证书将从下一次交易中排除，同时会包含相应的CRL文件或OCSP响应来替代。II型交易用于初始化或重置发布密钥对。当一个DNS名称（或Web服务器）首次加入该社区时，其发布密钥将由多个其他Web服务器（称为认证者）使用它们的发布密钥对进行签名。如果发布密钥遭到泄露或丢失，可以通过另一个II型交易对其进行重置。

所有标记有相同DNSname的证书交易，无论是类型‐I还是类型II，都会按时间顺序链接在一起，如图1所示。对于每个Web服务器，其证书和发布密钥的连续历史将公开存档在区块链中。如果出现欺诈性证书或发布密钥，将很快被发现。我们设计了一系列规则，使诚实的Web服务器能够采取对策并恢复其证书或发布密钥。

矿工根据下述证书交易规则收集并验证来自他人的证书交易，并为其挖出区块。它还会收集其他矿工挖出的区块，验证这些区块的有效性，并将有效的区块追加到其本地副本来延长链的长度。可以将类似比特币的激励机制引入我们的方案以鼓励挖矿。也就是说，成功挖出特定区块的矿工将获得一定数量的币作为奖励，而这些币由Web服务器在发布证书交易时购买和消耗。

在每个区块中，一个Web服务器最多只能发布一笔交易。如果区块链的矿工同时收到针对同一DNS名称的类型‐I和II型交易，则II型交易具有优先权。如果有多个相同DNS名称和类型的交易，矿工将根据自身的实现方式从中选择一个。

浏览器与Web服务器/矿工的P2P网络通信，以下载更新的区块链并维护一个本地副本。当浏览器与Web服务器建立SSL/TLS会话时，它将借助其证书区块链的本地副本验证Web服务器证书。我们将在接下来的小节中详细解释此过程。

3.2 主体控制的证书发布

证书由其主体在I型证书交易中进行签名和发布。只有持有发布密钥对的 Web服务器才能对其DNS名称标记的I型交易进行签名。因此，（被攻陷的） 证书颁发机构无法在未经主体同意的情况下发布证书。每个I型交易包括：
1. DNS名称，Web服务器的DNS名称。
2. 前一交易哈希，与相同DNS名称关联的上一笔交易（无论是I型还是II型）的哈希值。
3. 类型，标记为类型‐I。
4. 有效期，本次证书发布的有效期。
5. 证书链列表，已发布证书链的列表。Web服务器可能持有多个当前有效的证书。
6. 下一个发布密钥，发布公钥。对应的私钥用于对下一笔具有该DNS名称的I型交易进行签名。
7. 签名，使用当前发布密钥对（即在最近一笔与此DNS名称相关的交易中绑定的密钥对，无论是I型还是II型）对该交易进行的签名。

对于证书链列表中的每个证书链，如果该Web服务器的证书是首次发布，则从自签名根开始的整个链CA证书提供给终端实体证书。这有助于矿工验证证书。否则，当该链在后续周期性的I型交易中发布时，仅提供一个简化条目，包括Web服务器证书的哈希值以及用于检查其“动态”有效性状态的信息。此类信息包括证书有效期、CRL 分发点或OCSP位置，以及通过CRL或在线证书状态协议检查其撤销状态的标识符（例如序列号）。这种简化条目的设计使矿工能够验证这些交易的一致性并检查证书的动态撤销状态，同时大幅降低了存储和通信开销。

证书透明度通过将证书作为仅追加区块链中的交易公开可见而实现。对于 I型交易，其有效期需与当前PKI中证书状态刷新的周期相当。因此，在证书的生命周期内通常会多次发布该证书，且其更新的撤销状态也会反映在证书交易中。当证书被撤销时，Web服务器会在下一次交易中立即将该证书替换为相关的撤销信息，并立即发布或等到下一个周期发布。因此，证书颁发机构的吊销操作也被记录在区块链中，从而实现了撤销透明度。

3.3 发布密钥的初始化与重置

II型交易用于（a）初始化Web服务器的发布密钥，以及（b）在密钥受到损害时重置该密钥。一个II型交易包含以下字段：
1. DNS名称，Web服务器的DNS名称。
2. 前一交易哈希，具有相同DNS名称的上一笔交易（无论是I型还是II型）的哈希值。
3. 类型，标记为类型II。
4. 发布密钥，已认证的发布密钥对的公钥。
5. 认证者组，一个认证者的DNS名称列表，对应的Web服务器被授权控制该DNS名称的发布密钥。
6. 证书链列表， Web服务器证书信息的列表，可选。用于在紧急情况下删除之前I型交易中错误出现的欺诈性证书。
7. 所有者签名，由已认证的Web服务器提供的一些签名。这些签名使用与该DNS名称绑定的CA签发的证书进行验证，相关证书也包含在此字段中。
8. 签名列表，由认证者Web服务器使用其当前发布密钥对签署的一组签名列表，签名者的DNS名称也包含在此字段中。

每笔II型交易至少由 G个证书颁发者Web服务器签名。为了对其初始的II型交易（即标记有DNS名称的第一笔交易）进行签名，Web服务器会联系其信任的、拥有发布密钥的至少 G台服务器已在区块链中被认证为其证书颁发者的初始II型交易由所有认证者签名。随后，任何非初始II型交易必须由前一个II型交易的认证者组中指定的至少 G名认证者签名。认证者组可在非初始II型交易中进行修改，但认证者组中的认证者数量不得少于 G。此外，II型交易还需由Web服务器自身通过所有者签名进行签名，该签名间接由一个或多个证书颁发机构认证。

初始的II型交易在已认证的发布密钥生效前会设置一个“冻结期”。这使得相关方（不仅是Web服务器）能够观察到冒充攻击的尝试。在冻结期内，若出现另一个具有相同DNS名称的初始II型交易，且其“所有者签名”中的证书由更多公开信任的证书颁发机构签名，则当前II型交易将被作废。如果发生此类争议情况，冻结期将自动延长，以便为目标Web服务器提供更多时间联系证书颁发机构，并可采取带外措施。在无争议的情况下，冻结期结束后，发布密钥即生效。

List of Cert Chain 字段用于极端攻击场景，即当发布密钥对遭到破坏而发布了欺诈性证书时，目标Web服务器可通过仅一次交易恢复对发布密钥的控制并删除欺诈性证书。在II型交易的该字段中，无需提供撤销信息。请注意， List of Cert Chain 不得包含任何新出现的证书；否则，这将为攻击者提供一条快速发布欺诈性证书的途径。

为了降低矿工的存储需求，每个Web服务器会定期发布其II型交易，即使无需重置发布密钥对或修改其认证者组。在这些“影子”II型交易中，发布密钥和认证者组必须与前一笔交易中的相同，而证书链列表以及所有者签名中的证书必须不存在。影子II型交易仅由Web服务器自身签名，无需认证者的签名。因此，矿工只需在一定时期内存储（a）最近的区块头以及（b）每个域名两种类型的最新交易。

在证书区块链的创世块中，包含 G+1个或更多特殊的II型交易，用于认证至少 G+1个Web服务器的发布密钥。每笔此类交易均由其他 G个Web服务器签名。创世块中的发布密钥由这些Web服务器共同（以及部分证书颁发机构间接）自认证。随后，这些Web服务器将发布其证书。

创始服务器需要一个初始阶段来邀请排名较高的Web服务器（假设为诚实的Web服务器）加入，即最初对其他Web服务器的发布密钥进行认证。在初始阶段，证书区块链是公开可见的，但社区不对外开放加入。当引入一定数量的诚实Web服务器后，使得任何新参与者都不会带来压倒性的计算能力时，社区将向公众开放，非创始Web服务器在它们的发布密钥被认证并发布到证书区块链后，也将作为证书颁发者运行。

3.4 浏览器的证书验证

浏览器借助证书区块链来验证在SSL/TLS协商中收到的证书。首先，浏览器与 Web服务器/矿工的P2P网络通信，逐步下载最新的区块头。浏览器验证所下载 的区块头是否正确链接，并且每个区块头是否包含有效的工作量证明随机数， 并在收到更长的链时更新其本地副本。浏览器仅下载和存储区块头，而不存储 交易，以减少通信和存储的开销。此同步过程可以在没有进行SSL/TLS协商时 执行。

在 SSL/TLS 协商期间，SSL/TLS 消息扩展会将待验证证书的证书交易由 被访问的 Web服务器 发送。同时还会发送区块的标识符以及该交易的 Merkle 审计路径（即用于计算 Merkle 哈希树根的最短附加节点列表[35]）， 以使浏览器能够验证证书交易。

在SSL/TLS协商中收到的证书链是有效的，如果（a）该证书（或其哈希值） 已发布于由访问的Web服务器发送的证书链列表 中，且该交易未过期，（b） 该证书由浏览器所信任的根CA签名，（c）该交易包含在一个完全确认的 区块 中，而非区块链最新的 N若干个区块中，以确保该证书交易已被足够多的矿工 接受[8]，并且已发布的证书已被相关方监控，以及（d）在此完全确认的区块 之后的所有后续区块中，包括 N非完全确认的区块，若存在包含所访问DNS名 称的交易，则收到的证书也必须出现在这些交易中。请注意，浏览器能够免疫 降级攻击，因为它们会根据本地存储的区块头副本判断某个Web服务器是否已 在区块链中发布交易，并对未发布交易的服务器执行标准的证书验证。

由于证书链已经由大多数诚实矿工验证，浏览器只需检查根CA证书是否被 自身信任即可。其他处理[12]，如CA签名、有效期和证书扩展，均无需进行。 也就是说，浏览器的证书验证被委托给了矿工社区，并且这种委托证书验证也 是透明的（即公开可见）。

由于I型交易的有效期可能大于一般的CRL/OCSP更新周期，具有高安全需 求的浏览器可能会采取额外措施来检查收到的证书的撤销状态。

4 安全分析

在本节中，我们分析了在各种攻击场景下所提出的方案。我们提出了对策，并 评估了除目标Web服务器外的某些实体遭到破坏时的影响。同时分析了针对证 书区块链的网络攻击。

4.1 密钥对被泄露情况下的安全性

为了冒充Web服务器，攻击者可能会破坏证书颁发机构，和/或破坏某些Web服务 器的发布密钥对。请注意，只有当浏览器接受了欺诈性证书时，才视为攻击成功。

我们并不假设攻击者能够攻破目标Web服务器的至少 G个认证者，因为 这些认证者是由目标服务器精心挑选的，且 G可以设置得足够大。我们也不考 虑目标Web服务器证书中绑定的密钥对被攻击者攻破的情况，因为在该情况下， 攻击者可以在无需伪造证书的情况下发起中间人攻击。此类攻击应通过证书管 理之外的其他方法进行预防或缓解，这超出了本文的范围。

被攻陷的证书颁发机构 。当仅有证书颁发机构被攻陷时，我们的方案可确保浏 览器不会接受任何欺诈性证书，因为目标Web服务器不会在区块链上发布此类 证书。需要注意的是，在传统公钥基础设施中，攻陷一个证书颁发机构就足以 发起中间人攻击，而在我们的方案中，攻击者必须同时攻陷目标服务器的发布 密钥，这更加困难。

被泄露的发布密钥对 。如果攻击者仅泄露了目标Web服务器的发布密钥对，则 无法冒充该目标Web服务器。攻击者可能会通过包含已过期或已被撤销的证书， 或排除当前有效的证书，来修改证书链列表中的内容在I型交易中。但此类交易 的验证将失败，因为矿工会验证所有包含的证书，并且与前一次交易相比，仅 允许排除已过期或已被撤销的证书。

攻击者可能通过I型交易使用另一个密钥对修改下一个发布密钥，以阻止 Web服务器更新其I型交易。这种情况将在下文进一步讨论。

受损的证书颁发机构和发布密钥对 。攻击者可能会攻破某个证书颁发机构以签 署欺诈性证书，同时攻破目标Web服务器的发布密钥对。然后，攻击者可以在 I型交易中发布欺诈性证书，同时将其持有的另一密钥对设置为下一个发布密钥。 该交易将被矿工视为有效，并最终被包含在已挖出的区块中。

一旦目标Web服务器（或其他任何相关方）发现欺诈性I型交易，该 Web服务器将立即联系其证书颁发机构，签署一个对策性的II型交易，通过正 确设置证书链列表来排除欺诈性证书，并同时在发布密钥中重置其发布密钥。 如图2所示，如果对策性II型交易及时出现（即在欺诈性交易之后的任意一个 N 后续区块中），浏览器将检测到冲突并拒绝该欺诈性证书（参见第3.4节）。此 类II型交易可彻底抵消欺诈性I型交易的影响。如果未及时签署该对策交易，欺 诈性证书可能暂时被接受，但在对策交易生效后将被拒绝。

在上述所有场景中，如果目标Web服务器能够及时发现攻击并采取对策 （即 k ≤ i+ N），则不会产生攻击影响。由于攻击者无法攻破 G证书颁发者， Web服务器始终可以通过II型交易来抵消影响。

4.2 对证书区块链的攻击

攻击者可能会试图阻止浏览器访问证书区块链的最近区块。首先，要将浏览器 与大量P2P节点隔离开，同时仍允许其访问（伪造的）Web服务器，这在技术 上极为困难且成本高昂。即使此类攻击能够实施，由于区块头中包含了挖矿时 间，当后续区块的生成时间远超平均区块间隔时，受害浏览器便会察觉到异常。

强大的攻击者可能会发布一个欺诈性证书，并将其包含在区块链的一个分 支中。随后，攻击者在该分支上挖掘后续区块，同时精心排除对抗措施交易。 这要求攻击者控制33%的计算资源[20]，这打破了我们对攻击者计算能力的安全 假设[48]。

5 实现与评估

本节介绍了所提出方案的原型，并对其性能进行了评估。

5.1 实现与设置

该原型系统由以下部分组成：(a) 在SSL/TLS协商中基于其证书区块链的本地副 本验证证书的浏览器，(b) 在SSL/TLS协商中将其证书交易作为扩展提供的 Web服务器，以及(c) 一个证书区块链实例。

浏览器基于 Firefox Nightly（版本54.0a1）实现。函数VerifySSLServerCert() 按照第3.4节所述进行修改，以验证收到的证书。Web服务器基于Nginx（版本1.10.3）实现。在SSL/TLS握手过 程中，定义并实现了ClientHello和ServerHello扩展，用于请求和响应证书交 易及相应的Merkle审计路径。浏览器与访问的Web服务器直接连接。浏览器 运行在一台配备Intel i7‐4770s/3.10GHz CPU、8GB内存和ST‐1000DM003硬 盘的台式机上，操作系统为Windows 7专业版；Web服务器则位于另一台硬件 配置相同但运行Ubuntu 16.04 LTS（32位）操作系统的台式机上。

表1总结了原型中所有相关参数的值。我们选择这些值的原因在附录中有详细说明。

表1. 原型区块链中参数的取值。

标记	值	Note
TB	2 h	平均区块间隔
TI	10 天	I型交易有效性
TII	100天	影子II型交易的周期
G	5/10	II型交易中已签名证书颁发者的阈值
N	6	完全确认一个区块后其后续的区块数量

根据 Censys.io 的数据，目前大约有 5435 万张有效的 SSL/TLS证书 [43], 平均每个网站拥有 1.34 张证书 [57]。这些证书中近 70% 是免费颁发的（例如 由 Let’s Encrypt 颁发）。我们认为这些免费证书的所有者对价格较为敏感， 不会参与我们方案中的激励机制。因此，我们主要关注付费证书（约 1388 万张， 对应约 1036 万个网站）。需要注意的是，我们的方案并不要求所有证书都参与， 因为我们的方案能够抵御降级攻击。我们纳入所有这些证书基本上是为了进行 性能评估。

我们使用测试CA为1036万个随机DNS名称和平均大小的证书生成一个原 型区块链。该原型区块链包含1200个区块（大约在 TII内）以及所有1036万台 Web服务器的交易。在原型中，每台服务器每隔114个区块定期发布一次I型交 易，以确保在下一笔交易完全确认之前当前交易不会过期。因此，平均每个区 块包含10.36M /114 ≈ 93.06K个I型交易和10.36M/1200 ≈ 8.84K个II型交易。

平均每家网站有1.34条证书链，每条链由三个证书组成。我们使用 OpenSSL‐1.0.1g生成原型证书区块链。此外，根据Alexa顶级100万网站的平 均域名长度[2]，在原型区块链中随机生成DNS名称，其平均长度为14字节。

OCSP响应（平均1.60 KB）被包含作为吊销状态信息，因为OCSP已广泛部署[37] 且比CRL更小（平均 51KB [37]）。根据现实世界的统计数据，撤销率通常为 1%，在紧急情况发 生时可能增加到 11% [37]。

5.2 评估

存储 。表2列出了每个元素的平均大小。浏览器将区块头保存在 TI中用于证 书验证，因此存储开销约为 120 × 1.40兆字节 ≈ 168.00兆字节。

表2. 区块链中数据元素的大小。

Item	平均大小
Type-I transaction	具有1/2/3条证书链: 4.65/8.71/12.77 千字节
	使用 1/2/3 个部分证书: 0.83/1.07/1.30 千字节
Type-II certificate transaction	无证书颁发者签名（阴影）: 1.02 KB
	使用 5/10 个证书颁发机构的签名: 5.10/5.36 KB
Block header	559.18 KB
Block, including the header and transactions	无证书被撤销: 95.05 MB
	1% 证书被撤销（通过OCSP/CRL）和 1% 新证书: 101.05/162.62 兆字节
	11% 证书被撤销（通过OCSP/CRL）和 11% 新证书: 161.13/838.42兆字节

矿工保存每个DNS名称的最新I型交易和II型交易，以及 TII内的所有区块头， 约为10.36M×(0.91 KB+1.02 KB) +1200 × 4 × 1.40 MB ≈ 26.64 GB。其中，0.91 KB是包含1.34个证书链的I型交易的估计大小。此外，必须始终保存所有未完全确 认的区块中的交易，以确保多个并发未完全确认分支中区块的验证；其大小约为 6 ×(93.06K×0.91 KB +8.84K×1.02 KB) ≈ 0.55GB。也就是说，一个矿工至少存 储27.19 GB的数据。如果1%的证书通过在线证书状态协议被撤销，则存储开销增加 到27.36 GB（我们将其视为“典型”大小）；如果有11%的证书通过CRL被撤销， 则开销为109.62 GB。即使所有有效证书都被包含在区块链中，矿工的典型存储开 销也不会超过150 GB。作为对比，比特币中的每个矿工存储超过150 GB的数据。

延迟 。浏览器按如下方式验证收到的证书：（a）检查根CA是否受信任，（b） 从硬盘读取一个区块头，（c）检查该区块头是否包含所访问DNS名称的交易， 以及（d）检查收到的交易是否在找到的区块中，并且证书是否在该交易中。操 作（b）、（c）和（d）会重复执行，直到确认该证书位于最近的已完全确认区 块中的未过期交易内（如果存在，还包括其在非完全确认区块中的所有后续交 易）。

当目标交易位于区块链的中部/末尾时，浏览器会验证证书（各1000次）。 这些操作的平均时间列于表3。

表3. 浏览器中证书验证的时间。

操作	平均时间
Standard certificate validation	9.86毫秒
Basic operation
(a) 检查信任锚	<0.01毫秒
(b) 从硬盘读取区块头	1.11毫秒
(c) 在区块头中搜索DNS名称	0.01毫秒
(d) 验证交易和证书	0.25 毫秒
Validate a certificate with the blockchain
操作 (a)+(b)+(c)+(d)，目标位于中间/末尾	71.87/135.38毫秒
操作 (a)+(c)+(d)，目标位于中间/末尾	0.98/1.65 毫秒

如果浏览器在启动时将所有区块头（约168.00 MB）加载到内存中，时间 开销将大大减少。在这种情况下，操作(b)是不必要的，平均延迟为0.98毫秒。 当所有有效证书都被包含在区块链中时，该数值将增加到3.20毫秒。 浏览器使用标准方法验证证书（不包括检查吊销状态）大约需要9.86毫秒。 采用我们的方法可以显著加快验证过程。

Communication 。在 SSL/TLS 协商中，引入的通信开销通常为一次证书交易， 且不会超过 N+ 1 次交易。其大小约为 1.53 KB，且不超过 10.71 KB (N= 6)。 此外，浏览器会定期更新其区块头的本地副本，每天大约为16.80 MB。通 过常见的商业压缩软件，该数据量可减少至每天约 5∼8MB。与传统方法在 SSL/TLS协商期间需要额外链接来下载CRL/OCSP（即使这些文件很小也会降 低性能）不同，我们的方案允许浏览器在空闲时下载区块头。

6 相关工作

若干 基于公共可审计日志的服务，例如 CIRT[51], RT[34],ARPKI[7],和 CONIKS [41],已被提出，通过在 Merkle 哈希树中记录证书来实现证书透明度 和/或撤销透明度。这些方案不涉及主体对证书发布的控制，因此在相关方发现 之前，欺诈性证书（或公钥）可能已被接受，而我们的基于区块链的方案支持 主体控制的证书发布。AKI[31]和PoliCert [56]使证书主体能够定义其自身的 证书参数（例如，受信任的CA和日志服务器）。主体证书策略也可以列在类型 II交易中，以增强主体的控制权。上述所有仅追加日志依赖于额外的审计员， 而我们的方案不需要这些审计员。相反，我们的方案基于由Web服务器和矿工 维护的仅追加区块链。

其他主体控制的证书服务，如 DANE [27], CAA [26],Sovereign Key [16]， 也被提出以平衡证书颁发机构的绝对权威。在这些增强方案中，浏览器在验证 证书或公钥时需要与额外组件（如 DNSSEC服务器[4,6]或时间戳服务器）通信， 从而导致安全会话的隐私信息泄露；然而，在我们的方案中，所有浏览器都下 载统一的区块头，且不交换此类信息。

公钥固定要求浏览器为特定域名 [19,32,39,50] 本地存储一个公钥（或证书）。 这些方案遵循首次使用即信任的假设，因此首次访问必须在无攻击的情况下建 立。此外，现有的固定机制未考虑证书吊销或更新，而在我们的方案中，这些 事件被作为交易处理。

基于公证的方法允许客户端比较来自SSL/TLS会话和其他来源的证书，例如 Perspectives [59], Convergence [38],ICSI公证 [29],和电子前哨基金会SSL观测 站[17]。Crossbear [28]基于此类记录定位SSL/TLS中间人攻击。 Doublecheck [3,18]和Laribus[42]允许客户端比较从不同网络路径接收到的证书。 一些基于公证的方法 [17,29,38,42,59]会泄露安全会话的隐私信息，而另一些方法 [3,18,42]仅对局部攻击有效。

浏览器在验证证书 [1] 时可能会强制执行增强的安全策略。CA‐TMS [9], Certlock [52] 和 Cage [30] 分别根据客户端的本地经验或证书颁发机构的 域名范围来评估证书颁发机构的可信度。DVCert [13] 向浏览器提供受先前建立 的用户凭证保护的证书列表，以在 SSL/TLS 协商中验证证书。此类增强功能可 作为附加规则集成到我们的方案中，以验证证书。调查 [10,25] 全面讨论了 SSL/TLS 生态系统中的漏洞及相应的对策。

一些基于区块链的替代方案允许主体在区块链[22,23,36,49]中发布密钥或 凭证。在这些DNS系统[22,23,49],中，密钥对完全由DNS名称的所有者控制， 因此一旦私钥被泄露便无法恢复。我们的解决方案将控制权分布在证书颁发机 构和Web服务器社区之间，因此攻击者在攻破单个实体后无法将任意密钥对绑 定到DNS名称。由签发者签名的IKP响应策略和由域名签名的域名证书策略在 以太坊区块链[40],中构成一个智能合约，旨在由欺诈性证书触发。 Blockstack[47]通过分离控制与数据改进了Namecoin。这种分离设计可与我 们的解决方案集成，从而实现证书交易存储的外包。

7 结论

我们提议将证书和撤销状态信息记录在全局证书区块链中，该区块链本质上是 仅追加的，以实现证书透明度和细粒度吊销透明度。我们的方案平衡了证书颁 发机构的绝对权威，并为每个SSL/TLS Web服务器提供连续的证书历史记录。 用于签名交易的发布密钥对由证书颁发机构和Web服务器社区共同控制，并记 录在区块链中。所提出的方案与X.509公钥基础设施兼容，但显著增强了证书的 安全保证。我们的方案还为浏览器提供透明且委托的证书验证服务，因为每个 证书链在被纳入证书区块链之前都由多数矿工进行验证。分析和实验结果表明， 我们的方案在存储、证书验证延迟、通信和激励成本方面引入了合理的开销。

参数选择

两个相邻区块之间的时间间隔（记为 TB）决定了证书在被包含进区块链后，浏览器需要多长时间才能接受该证书。对于Web服务器而言，要求其发布的证书 在24小时内被浏览器接受是合理的，即 N × TB< 1, 440分钟。另一方面，较小 的TB会迫使Web服务器更频繁地监控区块链中的欺诈性证书，并更快地采取 对策。因此，我们将TB= 120分钟设为一个典型值，并令 N= 6（与比特币中 的要求相同）。为了保持区块挖矿的稳定性，社区会定期调整区块链的工作量 证明目标。

I型交易的（表示为 TI）有效期被选择以提供适度的吊销透明度。首先， 只有当一笔交易被包含在一个完全确认的区块中（而不是区块链最新的 N个 区块中）时，其所包含的证书才会被浏览器视为有效。因此，TI (N+ 1)× TB； 否则，在其过期之前永远不会被浏览器接受。同时， TI不应显著大于一般的吊 销状态更新周期，以促使Web服务器及时更新其交易。因此我们要求 TI ≤ 10 × TRevoke，其中 TRevoke为吊销状态更新周期。对于超过95%的 CRL文件， TRevoke不超过1天。在线证书状态协议提供及时的吊销状态服务， 但OCSP响应的有效期通常为4或7天。因此，我们在原型中设置 TI= 14为400分钟（或10天）。

TII决定影子II型交易的频率。我们将 TII=10 × TI（即100天）。