基于行为透明性的RPKI撤销检测机制

邹慧，李彦彪，于晨晖，马迪，毛伟

1.中国科学院计算机网络信息中心,北京 100083

2.中国科学院大学，北京 100049

3.互联网域名系统北京市工程研究中心，北京 100190

引言

互联网码号资源公钥基础设施（Resource Public Key Infrastructure,RPKI）[1]基于公钥基础设施（Public Key Infrastructure,PKI）技术为IP 前缀和自治系统（Autonomous System,AS）号构建了一套认证系统，用于认证资源的所有权和使用权。RPKI 的设计初衷在于增强边界网关协议（Border Gateway Protocol,BGP）的安全性，然而，PKI 技术与互联网码号资源管理体系的融合，从技术手段上赋予了资源分配者单边撤销资源的权力，换言之，上级认证权威（Certificate Authority,CA）对下级CA 产生了绝对的控制力和影响力。越靠近认证顶层的CA 具备的权力越大，能力越大意味着责任越大，越容易成为攻击对象或者为特殊组织机构所利用。当一个CA 配置错误或者遭受攻击，甚至为政府/法律胁迫，可能导致该CA 或/和下级CA 的RPKI 数据对象出现异常，无法真实、准确地反映互联网码号资源的分配关系和授权关系，这些错误的RPKI 数据对象进一步映射至域间路由系统，无法准确指导BGP 路由。特别地，在未部署RPKI 之前，资源申请者和资源分配者在资源撤销这一问题上需要通过带外协商方式达成共识，资源分配者才能执行资源回收操作。在部署RPKI 之后，资源分配者可以在不经过资源申请者同意的情况下，通过撤销资源证书的方式，单边回收已分配给资源申请者的合法资源。于是，资源申请者所在的IP 地址空间被RPKI 验证为无效，进而导致其所在的IP 地址空间在互联网上陷入“路由黑洞”的危险局面。换言之，RPKI 将域间路由系统的安全风险由协议技术层面迁移至了运行管理层面。

截止目前，互联网上并未发生由于RPKI 认证权威错误配置或者恶意操作导致的IP 前缀撤销事件，主要原因在于RPKI 仍然处于部署初期阶段。然而，域名系统（Domain Name System,DNS）和Web PKI系统均发生过“域名接管（DNS takedowns）”和“证书撤销”事件。由此可以推断，IP 前缀撤销事件的暂时未发生并不代表未来不可能发生，我们需要提前谋划布局，未雨绸缪地提出应对上级CA 单边撤销权力这一安全风险的解决方案。为此，本文设计并实现了基于行为透明性（Behavior Transparency,BT）的RPKI 撤销检测机制（下文简称为“BT 机制”），开展了丰富的实验以验证其效果，并从效率、准确率和传输开销三方面评估了该机制的性能。实验结果表明，在部署有日志服务器且日志服务器足够安全可控的前提下，该机制的检测效率能满足当前架构性能需求，且准确率达到100%，传输开销可忽略不计。

1 相关工作

1.1 安全分析

文献[2]首次提出了“RPKI 安全威胁模型”——认证权威存在配置错误、遭受攻击或被迫做出不当行为，并分析了可能存在的异常操作以及由此带来的安全风险。该团队进一步扩展上述工作，提出了CA“外科手术式”精确撤销其子孙节点的路由起源授权（Route Origin Authorization,ROA）数据对象的一般流程，并讨论了资源单边撤销对RPKI 体系以及域间路由系统的影响[3]。

RFC 8211[4]以RPKI 数据对象为切入点，构建了RPKI 数据安全威胁模型。通过定义问题域和术语集的方式，该标准详细分析了CA 在不同运行模式下，针对不同类型RPKI 数据对象发起不同类型误操作或者恶意攻击，可能为域间路由系统引入的安全风险。其中，前三种误操作/恶意攻击行为需要获取被攻击CA 的私钥，后三种并不需要知晓这一信息。

文献[5]探讨了RPKI 体系的出现对互联网服务提供商（Internet Service Provider,ISP）、区域互联网注册管理机构（Regional Internet Registry,RIR）、互联网名称与数字地址分配机构（The Internet Corporation for Assigned Names and Numbers,ICANN）和政府等不同类型实体以及它们之间关系所带来的重要影响，涵盖经济利益、权力分配格局、政治策略以及商业运营模式等多个方面，而这一系列的变革对不同利益相关方在 RPKI 部署层面的激励并不一致。另外，该研究报告指出RPKI 的部署从本质上改变了RIR 这一角色的功能特性，从地址资源的分配管理者转变为路由通告的认证权威，在一定程度上提高了 RIR 在域间路由系统中的影响力，降低了地址持有者（例如ISP）的自治性，并且重塑了国际互联网治理格局。

1.2 解决方案

针对RPKI 体系的层级式认证结构导致的集权问题，学术界和工业界已经进行了一些研究，大致可分为两类：（1）“演进型”解决方案，即保留RPKI 体系的层级式认证结构，并分别以CA 和RP为切入点，带内地制衡/分散CA 的集中权力和带外地部署本地修复方案化解安全风险；（2）“革命型”解决方案，即改革RPKI 体系的层级式认证结构，基于区块链技术实现资源的注册、认证和管理的去中心化，消除对于集中化认证权威的信任和依赖。

1.2.1 “演进型”解决方案

（1）基于CA 的解决方案

Consent 机制[6]和Suspenders 机制[7]是面向所有CA 的安全保障方案，两者的核心思想旨在通过赋予下级CA 一定的权力，从而改善RPKI 认证权威侧权力不对等的局面。在Consent 机制中，当上级CA 撤销一个IP 前缀时，所有受到影响的下级CA均需签发表示同意的.dead 数据对象并逐级反馈至上级CA，于是，RP 可根据.dead 数据对象集合判断相关CA 是否就资源撤销操作达成一致共识。然而，Consent 机制要求所有CA 运行在delegated CA模式下，并且仅仅为资源证书提供保护，此外，复杂的横纵向Manifest 哈希链加重了部署和维护负担。在Suspenders 机制中，CA 使用互联网码号资源声明（Internet Number Resource Declaration,INRD）文件记录一段时间范围内其持有资源所有权/使用权的变更信息，该文件由CA 维护在独立于RPKI 体系的存储系统中。于是，RP 可根据INRD 文件的授权信息，判定一段时间内发生的资源分配和授权信息变更内容的合法性，一旦发现未授权的变更内容，RP 延迟更新并通知相关参与方，尝试提供一个合理的解决方案。但是，CA 运行模式的多样性以及 INRD 文件的管理复杂性，将导致Suspenders 机制在实际部署后的安全保障能力大打折扣。

基于门限签名的多方计算（Multiple-Party Computation,MPC）方案[8]针对托管CA（hosted CA）运行模式下信任锚点权力过于集中问题，提出在五大RIR 之间使用门限签名算法以分布信任，数据对象的签发、修改和撤销需要一定数量的RIR 共同协作才能完成，从而防止单一RIR 的权力滥用。但是，该方案并不能解决除信任锚点之外CA 的权力不平衡问题。

（2）基于RP 的本地管理/修复方案

本地信任锚点管理（Local Trust Anchor Management,LTAM）机制[9]和简化版的本地码号资源管理（Simplified nUmber Resource Management,SLURM）机制[10]均是以RP 为部署平台，并根据第三方权威机构提供的配置文件实现资源本地化管理的解决方案。其中，前者以RP 作为本地信任锚点（Local Trust Anchor,LTA），并根据“约束文件（constraints file）”完成全球RPKI 资料库的重新挂载——资源证书的本地重签发，以准确诠释约束文件中表达的资源分配和授权关系信息。后者是一个简化版的轻量级部署方案，根据SLURM 文件的配置内容过滤或者添加资源授权关系信息条目即可达成与LTAM 机制相同的管理目的，从而避免了复杂的证书签发和维护管理工作。需要说明的是，“本地”指RPKI 数据对象的生效范围，即RP 的服务范围，小可为一个运营商网络，大可至一个国家管理区域。

1.2.2 “革命型”解决方案

BGPcoin[11]、IPchain[12]和InBlock[13]是三种典型的基于区块链的去中心化解决方案，三者基于IP 地址和AS 号与数字货币之间的共同特性——可转让、可分配、不能同时分配给多个实体，实现了互联网码号资源分配关系信息的去中心、可追溯和防篡改认证。BGPcoin 将IP 地址和AS 号作为一种财产，并基于公共账本和智能合约记录每一次互联网码号资源所有权变更的交易信息。IPchain 使用权益证明（Proof of Stack,PoS）共识机制实现了对IP 地址的分配管理，保证了安全性的同时降低了存储开销。然而，在这种情况下，地址持有者越多的实体拥有更多的话语权，仍然存在一定的权力中心化问题。InBlock引入了收费机制以防止相关参与方针对IP 地址的恶意申请、囤积和浪费行为，即任何申请IP 地址分配的实体需要缴纳一定的虚拟货币，通过物质刺激的方式实现保护互联网码号资源的目的。

2 背景知识

2.1 证书透明性和默克尔树

在证书伪造事件频发的背景下，为了减轻SSL PKI 证书系统的结构性缺陷，Google 于2012年提出了证书透明性（Certificate Transparency,CT）[14]解决方案。CT 机制的目标在于提供一个开放透明的监督和审计系统，要求CA 向该系统提交所有签发的证书。需要说明的是，CT 机制并不能阻止CA 签发错误或虚假证书，但是正如它的名字所暗示的一样，它使得相关参与方（域名所有者、浏览器等）更加清楚地看到CA 的证书签发行为，从而使得错误/伪造证书的检测过程变得相对容易，以便相应措施的及时部署。在一定程度上，CT 机制使得CA 难以错发虚假/错误的证书，原因在于CT 机制鼓励Web浏览器拒绝没有经过公开审计的证书，这就迫使CA公开注册由其签发的证书，从源头上减少了证书的错误签发机率。再者，用户能够检测识别包含其合法持有域名的伪造证书。

CT 机制引入了三种全新角色，分别为日志服务器（Log）、监督者（Monitor）和审计者（Auditor）。在为某个域名持有者签发服务器证书之后，CA 需要及时地将该证书发布至公开的Log 服务器中。Log服务器以默克尔树（Merkle Tree）的形式存储所有提交的证书，并保证Append-Only（只增不删）特性。换言之，一旦Log 服务器接受了某张证书的注册请求，该Log 服务器的属性可以保证这一证书永远不会被移除、修改或者追溯。Monitor 周期性地下载Log 服务器中的证书集合，并从中排查可疑证书。Auditor 的设立旨在审计Log 服务器的行为正确性，即是否在承诺时间范围内发布向其提交的证书。由此可知，CT 机制改变了证书的签发流程，新流程规定：证书必须记录到可公开验证、不可篡改且只增不删的Log 服务器中，终端用户的Web 浏览器才会将其视为有效。CT 机制允许任何感兴趣的相关参与方查看任一CA 签发的任一证书，这一策略能够促使CA 在签发证书时更加谨慎和负责，从而有助于形成一个更可靠的Web PKI 生态系统。

2.2 RPKI 体系结构和Manifest

RPKI 体系主要由两部分构成：CA 系统和依赖方（Relying Party,RP）系统。CA 系统与互联网码号资源管理体系相吻合，顶级节点为五大 RIR，下级节点包括国家互联网注册机构（National Internet Registry,NIR ）、本地互联网注册机构（Local Internet Registry,LIR）、ISP 以及其他独立的IP 地址持有机构。每一个纳入RPKI 认证体系的资源持有者均可视为PKI 意义层面上的CA，负责资源证书和ROA等数据对象的签发，以此认证资源的分配和授权关系信息。每一个CA 负责维护一个逻辑上的发布点（Publication Point,PP），用于存储由其签发的所有数据对象，所有发布点共同构成全球分布式RPKI 资料库（Repository）[15]。

考虑到BGP 路由器的性能和存储限制以及数据包的实时传输要求，RPKI 并不要求每一台BGP路由器自行获取用于验证路由通告合法性的认证依据。取而代之，RPKI 通过设立RP 实体作为BGP路由器的代理，负责一些重复的、可离线处理的事务，包括数据对象的同步下载、证书链的构建和验证、资源授权关系信息的生成和传输以及缓存管理等工作。最后，RP 将验证为有效的资源授权关系信息传输分发至BGP 域间路由系统，供路由器验证路由消息的有效性，并作为输入之一参与路由决策过程。

然而，在RPKI 数据对象的同步下载过程中，可能存在针对发布点以及CA 与RP 之间传输通道的恶意攻击，为此，CA 通过签发资源清单（Manifest）一一列举发布点中除自身之外所有数据对象的文件名和哈希值，以提供面向发布点的完整性保护，从而协助RP 判定攻击行为的发生与否。作为Manifest的初始标准文档，RFC 6486[16]允许异常Manifest（丢失、过期和无效），以及Manifest与发布点之间冲突（一个数据对象存储于发布点却未列于Manifest 中，或一个发布点未存储于发布点却列于Manifest 中）的存在，针对上述异常和冲突，RP 可根据本地策略自行处理。然而，2020年 2月 25日 RIPE NCC 发布点下的证书撤销列表（Certificate Revocation List,CRL）过期，引发了 IETF SIDROPS 工作组针对异常 CRL的处理策略以及 CRL 存在必要性的讨论，并启动了针对RFC 6486 的修订工作[17]，强化了Manifest 的重要性并提高了Manifest 的优先级，换言之，异常状态的Manifest 不再为RP 所接受，并且，RP 仅接受列于Manifest 中的RPKI 数据对象。

3 机制设计

3.1 威胁模型

PKI 技术的层级式、集中化认证结构将单边撤销问题引入资源管理系统，导致下级CA 的资源无效。本章假定CA 存在配置错误或者遭受恶意攻击的可能性，并定义了资源撤销威胁模型，包含针对资源证书的三种操作类型，三者均可以达成资源撤销目的，然而，被操作资源证书在Manifest、CRL和发布点的表现形式并不一致。详细信息如表1所示，其中，白色符号/黑色符号分别表示资源证书不存在/存在于Manifest/CRL 或发布点中。其中，删除指上级CA 未使用合法撤销流程将下级CA 的资源证书从发布点中删除，并签发新的Manifest 和CRL，此时，Manifest 和CRL 中均未列出被删除的资源证书。撤销指上级CA 使用合法撤销流程将下级CA 的资源证书标记为撤销状态并从发布点中删除，此时，Manifest 和发布点中不包含该资源证书，而CRL 中记录了该资源证书的撤销状态。根据被撤销资源的多少，资源证书撤销操作可分为两种：（1）撤销一张资源证书导致所有资源无效；（2）撤销一张资源证书的同时重新签发一张包含更少资源的资源证书，导致被减少资源无效。延迟指上级CA 推迟发布下级CA 的新版资源证书（仅更新有效期，资源集并未改变），导致下级CA 的旧版资源证书存在于发布点中，但是并未列于新版Manifest 和新版CRL 中。

表1 资源撤销威胁模型Table 1 Types of resource revocation

3.2 技术原理

3.2.1 核心思想

BT 机制借鉴了CT 机制的核心思想，旨在通过增加CA签发行为透明性的方式达到威慑CA的目的，使得CA 不愿/不敢肆无忌惮地单边撤销已为下级CA 分配的合法资源，在一定程度上制衡了CA 的单边权力。Log 服务器中存储的CA 签发行为历史记录，以及数字签名提供的不可篡改和不可抵赖性，为相关参与方提供了及时检测资源证书撤销状态的能力，以及问责撤销行为发起实体的渠道。另外，本方案提供了资源证书撤销状态查询服务，使得CA 具备实时感知自持有资源证书撤销状态的能力。

3.2.2 新增角色

与CT 机制类似的是，BT 机制为RPKI 体系引入了三种全新角色，分别为Log 服务器、Monitor 和Auditor。Log 服务器的设立旨在增加CA 签发行为的透明性，与CT 机制不同的是，Log 服务器并不存储CA 签发的资源证书，而是存储Manifest 数据对象，即CA 在一段时间范围内所有签发行为的“快照文件”。当CA 初始化发布点或者更新发布点中RPKI 数据对象的个数或/和内容后，Manifest 也随之产生或更新。BT 机制的“Manifest 注册政策”，即要求所有CA 向Log 服务器注册由其签发的每一个Manifest，从而保证了CA签发行为的有据可循。于是，当一张资源证书被某一CA 删除/撤销/延迟后，一方面，我们可以推断该CA 签发的Manifest 中一定不包含被撤销的资源证书，否则，发布点与Manifest的内容不一致将导致整个发布点的同步失败（被操作资源证书不在发布点却列于Manifest 中），CA 付出的代价太大。另一方面，Manifest 注册策略保证了该CA 资源证书撤销行为的可溯源。需要说明的是，BT 机制并不能阻止CA 恶意撤销资源证书，其目的仅仅在于透明化CA 的签发行为，从而简化和加速恶意撤销行为的检测流程，降低和缩小恶劣影响的持续时间和波及范围。

Monitor 的设立旨在监督CA 的签发行为，通过实时检测资源证书的撤销状态，从而揭露CA 的资源证书撤销行为。Monitor 角色可由CA、RP、Log服务器、第三方利益相关方或者服务提供商等实体担任。作为资源持有者的CA，也是最关心资源有效性的实体，可以通过部署Monitor 定期地向Log 服务器发起资源证书撤销状态查询请求，实时地感知自持有资源证书的撤销状态，并及时地向Log 服务器发布争议信息。根据RFC 8210[18]中关于RP 部署场景的介绍，RP 一般部署在ISP 核心网或者大型边缘网络。在ISP 部署场景下，ISP 为每个客户（AS）提供有偿的互联网接入服务；在大型边缘网络部署场景下，这一网络覆盖一个或者多个AS。在上述两种RP 部署场景下，RP 的运营者与其服务范围内的资源持有者（AS）均属于同一管理域，具有天然的信任关系。因此，RP 可作为代理，接受来自其服务范围内CA 的订阅，并部署BT Monitor 为它们提供资源证书撤销状态的检测服务。另外，由于保存了所有CA 的历史版本Manifest，Log 服务器具备检测资源证书撤销状态的天然优势，因此，Monitor 功能也可部署在Log 服务器。然而，由于被动地接受Manifest 的注册，Log 服务器存在一定局限性，即无法检测尚未向其提交Manifest 的CA 是否存在恶意撤销行为。除此之外，类似于Google 的公共递归解析服务器（8.8.8.8），BT Monitor 也可由大型内容服务提供商部署，并对外提供公开的资源证书撤销状态检测服务。与上述两种私有BT Monitor 部署情形不同的是，公有BT Monitor 的服务范围更加广泛，接受来自全世界范围内CA 用户的订阅，并为其提供资源证书撤销状态的检测服务。此时，BT Monitor将面临存储容量、下载频率和检测能力等多个方面的挑战。

Auditor 的设立旨在审计Log 服务器的行为正确性，即是否在承诺时间范围内发布由CA 提交的Manifest，并且，是否存在删除、修改和追加Manifest 的异常操作。作为Manifest 的提交者，CA可作为Auditor 直接审计Log 服务器的及时发布行为。另外，BT 机制改变了RP 的验证流程，针对一个CA 而言，只有当RP 确定RPKI 资料库与Log 服务器中发布的Manifest 完全一致时，才会认为Manifest有效并继续执行后续的验证和分发流程。因此，在RPKI 数据对象的验证过程中，RP 可根据Manifest的存在性差异结果实现Log 服务器行为正确性的一并审计。

3.2.3 体系框架

BT 机制的引入改变了RPKI 体系中CA 和RP 的操作流程，其体系框架如图2所示。在传统的RPKI 体系中，CA 负责签发资源证书、ROA、Manifest 等数据对象，并维护用于存储上述数据对象的发布点，所有CA 的发布点构成分布式RPKI 资料库。RP 负责定期轮询RPKI 资料库以构建RPKI 数据对象的本地副本，为每个数据对象创建一条直达信任锚点的证书链，并验证其有效性。最后，根据验证状态为有效的ROA 数据对象生成IP 前缀和AS号的映射关系，并传输分发至BGP 域间路由系统。在部署BT 机制的RPKI 体系中，CA 需要在每一次数据对象更新之后将新版Manifest 发布至Log 服务器。此外，作为资源持有者的CA 可以自主地向Log服务器发起资源证书撤销状态查询请求，也可以通过向RP 订阅资源证书撤销状态服务，等待RP 定期地反馈资源证书的状态信息。相应地，RP 在同步验证完所有数据对象后，需要确认每一个CA 发布于RPKI 资料库的Manifest 是否存在于Log 服务器中。如果不存在，RP 认为该CA 未遵循BT 机制的Manifest 注册政策，拒绝该CA 签发的所有数据对象；如果存在，则需要进一步比较两者内容的一致性，如果存在差异，RP 则认为该CA 并未将最新版本的Manifest 发布至Log 服务器中，并判定该CA 的发布点中所有数据对象无效。

图2 BT 机制的体系框架Fig.2 The system framework of the BT mechanism

3.3 运行模式

根据3.2.2 小节可知，作为一个可信第三方，Log服务器应该由独立于RPKI体系的新增实体担任，Monitor 和Auditor 两种角色则可由RPKI 体系中现有实体或者新增实体担任。为了避免引入过多的实体类型，本文仅讨论上述两种角色分别由CA、RP和Log 服务器三种实体担任的情形，实体承担角色的数量和类型，决定了各个实体的运行模式和功能模块。下文分别介绍CA、RP 和Log 服务器的运行模式，以及三者需要支持的功能模块。

3.3.1 CA

根据CA 承担角色的数量和类型，CA 的运行模式可分为以下四类，分别为：“CA 运行模式”、“CA-Auditor 运行模式”、“CA-Monitor 运行模式”和“CA-Auditor-Monitor 运行模式”。图3所示为支持BT 机制的CA 功能示意图，其中，蓝色表示BT 机制引入的新增功能模块，在不同运行模式下，CA 可具备不同类型和数量的功能模块。

图3 支持BT 机制的CA 功能模块示意图Fig.3 The function module of the BT-enabled CA

❖ CA 运行模式

在传统RPKI 体系中，认证权威分为根CA——信任锚点（Trust Anchor,TA）和非根CA。作为RPKI 的顶级认证机构，TA 发布一张自签名的资源证书实现资源所有权的自认证，因此，TA 并不面临上级CA 单边撤销其资源证书的安全风险。在这种情况下，TA 只需运行在“BT-enabled CA 运行模式”（下文简称“CA 运行模式”）下即可，并基于图3所示发布接口向Log 服务器发布最新版本Manifest。另外，非根CA 也可以选择“CA 运行模式”，将资源证书撤销状态的查询服务委托给信任的RP。在这种情况下，CA 需要提前通过带内机制（图3所示订阅接口）或者带外机制（例如网站注册等方式）向其信任的RP 订阅资源证书撤销状态检测服务。相应地，当RP 检测到CA 订阅用户的资源证书被其上级CA撤销后，可通过带内机制（图3所示信息收集接口）或者带外机制（例如邮件通知等方式）向CA 订阅用户反馈这一异常信息。

❖ CA-Auditor 运行模式

针对一个CA 而言，RP 需要检测RPKI 资料库中该CA 签发的Manifest 和Log 服务器中发布的Manifest 的一致性，检测内容包括存在一致性和内容一致性两个方面。因此，Log 服务器需要及时地发布由CA 提交的Manifest，否则，Manifest 的不一致将导致该CA 发布的所有数据对象被RP 判定为无效。因此，CA 可以通过部署Auditor 功能，定期地审计Log 服务器的行为正确性，由图3所示查询接口支持这一功能实现。

❖ CA-Monitor 运行模式

由于非根CA 的资源证书均由其上级CA 签发并维护，面临资源证书单边撤销的安全风险。因此，非根CA 可以选择运行在CA-Monitor 模式下，即同时实现CA 功能和Monitor 功能（图3所示查询接口），实时地向Log 服务器查询自持有资源证书的撤销状态。在这种情形下，CA 部署的Monitor 并不关注其他资源证书撤销行为，而仅仅关注自持有资源证书是否被上级CA 恶意撤销。

❖ CA-Auditor-Monitor 运行模式

在该运行模式下，认证权威同时实现CA、Auditor和Monitor 三种功能，即负责RPKI 数据对象的签发和维护、Log 服务器的行为审计以及资源证书撤销状态的检测。然而，在该模式下，Log 服务器需要响应大量的Manifest 发布请求、资源证书状态查询请求，以及行为正确响应请求，加剧了Log 服务器的运行负担。

3.3.2 RP

在部署了BT 机制的RPKI 体系中，除了担任“中转处理站”（同步、验证和传输RPKI 数据对象）这一本职角色外，RP 还可以担任Auditor 和Monitor两种角色。因此，与CA 类似的是，RP 同样具备四种运行模式，分别为“BT-enabled RP 运行模式”（下文简称为“RP 运行模式”）、“RP-Auditor 运行模式”、“RP-Monitor 运行模式”和“RP-Auditor-Monitor 运行模式”。图4所示为支持BT 机制的RP 功能示意图，其中，蓝色表示由于BT 机制引入的新增功能模块，在不同运行模式下，RP 可具备不同类型和数量的功能模块。

图4 支持BT 机制的RP 功能模块示意图Fig.4 The function module of the BT-enabled RP

❖ RP 运行模式

在该运行模式下，当RP 同步成功一个 Manifest后，基于图4所示查询或下载接口向Log 服务器发起该Manifest 的查询或下载请求，旨在验证CA 是否遵循BT 机制的行为透明性要求，即及时向Log服务器注册最新版本Mnifest，以及是否向Log 服务器“说谎”——提交伪造的Manifest。

❖ RP-Auditor 运行模式

根据RP 的验证流程可知，针对一个CA 而言，只有当该CA 发布于RPKI 资料库和Log 服务器中的Manifest 完全一致时，RP 才接受由该CA 签发的所有数据对象。在这一过程中，RP 首先需要确定Log服务器中Manifest 的存在性。因此，RP 天然地成为Auditor，具备验证Log 服务器行为正确性的能力。

❖ RP-Monitor 运行模式

另外，RP 也可以部署Monitor 功能，以协助其服务范围内CA 用户检测资源证书的撤销状态。根据部署场景和服务范围的不同，RP 的类型可分为私有RP 和公有RP。一般地，私有RP 仅仅面向同属一个管理域内的CA 提供资源证书撤销状态检测服务，并且与之具备天然的带内信任关系，在这种情况下，CA 的数量有限并且CA 完全信任私有RP。作为一个中立第三方，公有RP 面向全世界范围的CA 用户提供服务，并供CA 与其自行建立信任关系，在这种情况下，CA 的数量庞大并且CA 需要与公有CA提前建立带外信任关系。

在上述两种部署场景下，CA 均需提前向RP订阅检测服务，RP 将CA 订阅用户及其上级CA 的身份信息（例如资源证书）存储至图4所示CA 订阅用户信息维护接口中，当检测到RPKI 资料库中Manifest 发生更新时，判断这一更新Manifest 是否为其CA 订阅用户的上级CA 签发，如果是，则进一步判断CA 订阅用户的资源证书撤销状态。在私有RP部署场景下，RP 仅仅需要为CA 订阅用户维护它们上级CA 的最新版本Manifest，并根据CA 订阅用户提供的资源证书作为检测依据，持续监测CA 订阅用户的资源证书撤销状态并实时反馈。在公有RP 部署场景下，向RP 订阅服务的CA 订阅用户数量较为庞大，在这种情况下，对于RP 的带宽能力、存储能力和处理能力都提出了较高的要求，并且需要及时响应来自全球范围内大量订阅用户的并发查询请求。

❖ RP-Auditor-Monitor 运行模式

在该运行模式下，RPKI 依赖方同时实现RP、Auditor 和Monitor 三种功能，即负责RPKI 数据对象的同步、验证、维护和传输、Log 服务器的行为审计以及局部范围或者全球范围内资源证书撤销状态的监测。

3.3.3 Log

在部署BT 机制的RPKI 体系中，Log 服务器作为一个独立组件被引入，主要负责记录CA 的签发行为，需要在承诺时间范围内将CA 提交的Manifest发布至其中，供感兴趣的相关参与方监测资源证书的撤销行为。根据数据流的方向，Log 服务器可以运行在两种模式下，分别为查询下载模式和日志发布模式，此外，Log 服务器也可以部署Monitor 功能，以提供资源证书撤销状态检测服务。图5所示为Log服务器的功能示意图，在不同运行模式下，Log 服务器可具备不同类型和数量的功能模块。

图5 Log 服务器的功能模块示意图Fig.5 The function module of the BT-enabled Log server

❖ 查询下载模式

在查询下载模式下，Log 服务器需要对外提供查询和下载两项服务，分别响应资源证书撤销状态的查询请求，以及Manifest的单个或批量的下载请求。前者面向未部署Manifest 验证功能的CA，换言之，CA 向Log 服务器发起自持有资源证书撤销状态的查询请求，并完全信任由Log 服务器返回的撤销状态响应结果。后者面向具备验证Manifest 能力的CA或者第三方Monitor，根据Manifest 下载请求，返回一个或者多个Manifest，供其自行检测资源证书的撤销状态。

❖日志发布模式

在日志发布模式下，Log 服务器接收CA 提交的Manifest 并在承诺时间范围内将Manifest 发布至其中，以此记录CA 的历史签发行为。另外，Log 服务器也可以提供一个申诉接口，允许下级CA 提交关于撤销资源的争议信息和合法持有证据，并对外提供“展示界面”，供相关参与方根据本地策略做出信任决策。需要说明的是，Log 服务器可以选择关闭日志发布模式，即关闭发布接口和展示接口，不再接受Manifest 的后续发布和争议信息的展示，仅对外提供历史Manifest 的查询和下载服务。

❖ Monitor 模式

当Monitor 功能由CA 部署时，CA 需要持续不断地向Log 服务器发起查询请求，才能及时地感知自持有资源证书的撤销状态。随着全球范围内CA数量的不断攀升，查询请求频率的不断提高，Log服务器的处理响应能力面临性能扩展性这一挑战。当RP 部署Monitor 功能时，Manifest 的更新才会触发RP 的检测服务，然而，RPKI 数据对象的同步是周期性执行，RP 存在一定的“视野局限性”。换言之，在RP 相邻两次同步操作之间，CA 可能已经将被撤销的资源证书重新发布至RPKI 资料库，导致作为Monitor 的RP 无法感知这一撤销行为的发生。因此，作为Manifest 的“汇聚地”，Log 服务器在检测资源证书撤销行为上具有天然的优势，通过对比一个CA 的相邻两个版本Manifest 即可感知该CA 在一段时间范围内撤销的资源证书。然而，Log 服务器同样存在一定的“视野局限性”，即无法检测未向其提交Manifest 的CA 的资源证书撤销行为。幸运地是，RP 可以感知CA 的Manifest 异常注册行为，并及时向相关参与方发起警报信息。于是，两者能够各司其职、分工协作、协同配合共同完成对所有CA 的资源证书撤销行为的全面检测。

3.4 部署方案

BT 机制的部署引入了三种具备不同功能属性的角色，不同角色可由RPKI 体系中原有实体或者独立实体担任，根据不同角色的部署实体，本节介绍了BT 机制的五种部署方案，并详细说明了每种部署方案的适用范围。

3.4.1 私有RP 场景下的部署方案

在私有RP 场景下，RP 天然地与其服务范围内的CA 建立了带内信任关系，因此，除了为这些CA提供RPKI 认证信息的处理服务之外，还能够同时提供资源证书的撤销状态检测服务。在这种情况下，CA 需要提前向RP 注册其自身及其上级CA 的身份信息，实现资源证书撤销检测服务的订阅，因此，RP 的检测范围仅覆盖CA 订阅用户的上级CA 的资源证书撤销行为。由于CA 与RP 具备带内信任关系，CA 没有必要独立地审计Log 服务器的行为正确性，因此，Auditor 角色一般由RP 担任，实现Manifest存在性的批量检查，CA 处于“CA 运行模式”下，负责将最新版本的Manifest 发布至发布点的同时提交至Log 服务器。

因此，根据Monitor 功能的部署实体，私有RP场景下BT 机制的部署方案可进一步分为两大类：（1）RP 部署Monitor 功能（部署方案一）；（2）Log服务器部署Monitor 功能（部署方案二）。在部署方案一中，RP 通过部署Monitor 功能集中地、定期地检测已注册在籍的CA 订阅用户的上级CA 的证书撤销行为，RP 处于“RP-Auditor-Monitor 运行模式”下，即除了负责RPKI 数据对象的同步、下载和传输之外，还负责监测服务范围内CA 订阅用户的资源证书撤销状态，以及审计Log 服务器的行为正确性。Log 服务器处于“查询下载模式”和“日志发布模式”下，提供Manifest 数据对象的注册发布服务、存在性响应服务和批量下载服务。在部署方案二中，Log服务器担任Monitor 的角色，负责对外提供资源证书撤销检测服务。相对于部署Monitor 功能的RP 而言，由于存储了Manifest 的历史数据，Log 服务器提供的资源证书撤销检测服务更加全面和精确。此时，RP 处于“RP-Auditor 运行模式”下，仍然作为CA 订阅用户的代理，负责向Log 服务器查询资源证书的撤销状态。另外，对于未及时向Log 服务器注册Manifest 的CA，由RP 负责检测并反馈Manifest注册异常信息。

图6 部署方案一Fig.6 Deployment plan one

图7 部署方案二Fig.7 Deployment plan two

3.4.2 公有RP 场景下的部署方案

在公有RP 场景下，RP 与CA 不具备天然的信任关系，因此，CA 根据本地策略决定是否信任公有RP。在这种情形下，CA 一般自行担任Auditor 角色，独立地审计Log 服务器的行为正确性。根据CA 对于RP 的信任程度，公有RP 场景下BT 机制的部署方案进一步分为三大类，即零信任部署方案（部署方案三）、部分信任部署方案（部署方案四）和信任部署方案（部署方案五）。需要说明的是，CA 可以选择完全信任公有RP，该部署方案与私有RP 场景下的部署方案一相同，本文不再赘述。

在零信任部署方案中，CA 处于“CA-Auditor-Monitor 运行模式”下，CA 自行向Log 服务器下载其上级CA 的Manifest，以验证资源证书的撤销状态。在这种情形下，由于CA 聚焦于自持有资源证书，因此，Log 服务器将面临来自大量CA 用户和RP 系统的下载请求，对Log 服务器的服务能力提出了性能挑战。

图8 部署方案三Fig.8 Deployment plan three

在部分信任部署方案中，CA 负责审计Log 服务器的行为正确性，并且信任由Log 服务器提供的资源证书撤销检测服务，处于“CA-Auditor 运行模式”下。然而，在这种情形下，Log 服务器无法（准确）检测未向其注册（最新版本）Manifest 的CA 的资源证书撤销行为。需要说明的是，RP 具备感知CA 未及时注册Manifest 这一异常行为的能力，负责将这一警报信息发送至Log 服务器，因此，两者协作配合可以实现全面的资源证书撤销检测服务。当CA查询自持有资源证书的撤销状态时，如果上级CA并未将（最新版本）Manifest 注册于其中，Log 服务器可以根据RP 提供的警报信息判定上级CA 的异常Manifest 注册行为，并将这一信息反馈至CA 查询用户，于是，CA 可根据本地策略采取进一步措施。

图9 部署方案四Fig.9 Deployment plan four

在信任部署方案中，RP 可由业界大型ISP、内容提供商等具备公信力的第三方实体部署，因此，CA 可基于其商业名气、服务能力以及技术储备等因素与之建立信任关系。于是，RP 可基于这一信任关系同时部署Monitor 功能负责其服务范围内CA 订阅用户的资源证书撤销状态检测，处于“RP-Monitor运行模式”下。此时，CA 处于“CA-Auditor 运行模式”下，仍然自行负责审计Log 服务器的行为正确性。

图10 部署方案五Fig.10 Deployment plan five

3.5 协议扩展

BT 机制的部署在现有RPKI 系统中引入了新的组件，CA/RP 与组件之间以及组件与组件之间需要互通信息，涉及日志及其操作信息的共享和多种交互操作的执行。因此，选择何种协议作为新增组件之间，以及新增组件与CA/RP 之间的通信规范是亟需解决的一个问题。

设计一个全新的协议需要考虑多方面的因素，包括正确性、完整性和安全性等，协议的研发和测试往往涉及多个迭代周期。另外，协议的标准化进程推进缓慢，部分原因在于标准化组织的硬性规定以及相关流程的繁琐复杂。除此之外，协议的部署过程也并非一蹴而就，相关参与方的部署意愿决定了这一过程的耗时长短。因此，在BT 机制的部署初期，可采用一种通用的协议（例如HTTP 协议）作为过渡方案，实现相关参与方之间的信息交互和共享。

随着BT 机制的广泛部署，上述三种角色可能分别由不同类型的独立实体担任，实现精细分工和各司其职，各个实体之间的交互方式和通信内容也随之发生改变，需要由定制化的协议支撑特定的数据格式和操作流程。因此，在基于通用协议作为过渡方案的过程中，工业界也可同时推进定制化协议的标准化进程，并根据部署过程中遇到的问题及时反馈并完善协议内容，为BT 机制的大规模部署做好充足的技术储备。

3.6 安全考量

BT 机制是一套旨在检测、阻止和纠正资源证书恶意撤销行为的机制，其中，BT 机制的Manifest 一致性政策，要求RP 检查每一个CA 发布于RPKI 资料库和Log 服务器的Manifest 是否满足存在一致性和内容一致性两项要求。上述要求使得CA 必须及时地将反映其一段时间范围内签发行为的“快照文件”——Manifest 发布至Log 服务器中，否则直接影响其发布点中数据对象的同步下载。由此可知，Log 服务器的存在使得CA 的资源证书签发行为更加透明化，在一定程度上遏制了CA 的恶意撤销意图。

此外，Monitor 负责实时地或者周期地检测资源证书的撤销状态，Auditor 负责审计Log 服务器的行为正确性。然而，BT 机制中的组件也可能成为攻击的目标，另外，自身的配置错误或者恶意操作均会影响BT 机制的安全性。本小节分析了CA、RP 和Log 服务器三种实体，以及三者部署Monitor 和/或Auditor 功能时可能发生的恶意操作，以及由此产生的安全风险，为此，提出了相应的运行建议和解决方案。

3.6.1 Log

Log 服务器并未在承诺时间范围内发布CA 提交的（最新版本）Manifest，在这种情况下，当RP向Log 服务器请求该CA 的Manifest 时，无法获取Manifest（不存在响应）或者同步旧版Manifest（错误的撤销状态结果），因此，RP 认为该CA 存在异常Manifest 注册行为，并拒绝由其签发的所有RPKI 数据对象。

为了应对这一安全风险，RP 应该及时向其他多个Log 服务器提交这一警告信息，并向相关CA 反馈Manifest 的注册异常，相关CA 用户可以根据Log服务器中的Manifest 集合，以及RP 反馈的异常信息判断Log 服务器的行为正确性。除此之外，其他RP和Log 服务器也可以判断该异常Manifest 注册事件的责任方到底是CA 用户（延迟提交），还是Log 服务器（恶意操作）。另外，BT 生态系统可通过部署多个Log 服务器并要求一个CA 至少向两个Log 服务器发布其新版Manifest，避免形成单点依赖，相应地，RP 可以选择与多个Log 服务器建立信任关系，实现检测结果的冗余性验证。

3.6.2 RP

当发现一个CA 在RPKI 资料库与Log 服务器中发布的Manifest 存在不一致时，RP 应该拒绝信任该CA 签发的所有数据对象。然而，恶意RP 可能仍然继续使用这些数据对象，且并不公布和反馈这一异常信息。于是，该CA 的资源证书撤销行为被隐藏，相关下级CA 无法准确感知自持有资源证书的撤销状态，另外，该RP 服务范围内的BGP 路由器无法获取完整的真实的资源授权关系信息，即被撤销资源证书的下级CA 签发的所有认证信息将无法用于判定路由消息的合法性。

然而，由于RP 系统的分布式特性，难以实现全球范围内所有RP 结盟以协助某一CA 隐瞒资源证书恶意撤销行为。因此，当其他RP 感知这一撤销行为并及时提交至相关Log 服务器时，被撤销资源证书的下级CA仍然具备感知上级CA撤销行为的渠道。另外，涉嫌故意隐瞒信息的RP 的信誉值也因此受到影响，网络运营商和CA 可以选择不再信任该RP 并拒绝使用其服务。

3.6.3 CA

CA 可能以极高频率恶意地向Log 服务器持续不断地发布Manifest，目的在于耗尽Log 服务器的资源，使得其无法正常地提供服务，甚至导致其系统崩溃。在这种情况下，Log 服务器可以从两个方面应对上述安全风险，首先，Log 服务器可以对Manifest的内容进行校验，如果后续提交的Manifest 与已注册的Manifest 的内容完全一样，则不再接受Manifest的重复注册；其次，Log 服务器可以对Manifest 提交者的身份信息进行认证，要求在提交Manifest 的同时提交身份信息（例如RTA[19]），当DDoS 攻击发生时可作为依据对相关参与者进一步追责。

3.6.4 Monitor

BT 机制支持Monitor 功能的多样化部署。考虑到部署Monitor 功能的CA 旨在检测自持有资源证书的撤销状态，在这种情况下，CA 不具备自我欺骗的动机。当RP 或者Log 服务器作为Monitor 提供资源证书撤销检测服务时，两者均可能向CA 订阅/查询用户返回错误的Manifest 或者撤销状态响应结果。因此，CA 需要综合多方因素评估RP 或者Log 服务器的可信任度，谨慎决定是否与之建立信任关系，并授权委托自持有资源证书的撤销检测服务。当发现RP 或Log 服务器存在故意隐瞒或者伪造撤销状态响应结果的恶意行为时，应该立即终止与之建立的服务关系。

3.6.5 Auditor

在BT 机制中，Auditor 角色一般由CA 和RP担任。类似地，考虑到部署Auditor 功能的CA 旨在检测自签发的Manifest 是否及时地被发布至Log 服务器中，因此，该CA 不具备自我欺骗的动机。事实上，BT 机制针对RP 提出的Manifest 一致性检测要求，决定了RP 是Auditor 功能部署的最佳平台。一般地，私有RP 作为代理负责其服务范围内CA 订阅用户的Manifest 存在性检测。在这种情况下，私有RP 与CA 在同一管理域内，两者的利益一致且具备天然的信任关系，私有RP 同样不具备欺骗CA 订阅用户的动机。如果某一私有RP 仍然向CA 订阅用户隐瞒Log 服务器的异常注册行为，由于RP 的分布式特性，CA 订阅用户仍然具备感知Log 服务器异常操作的其他渠道。

4 实验与分析

4.1 实验环境参数

本实验涉及三种实体，分别为CA、RP 和Log服务器，各个实体的硬件平台和软件实现相关参数说明如表2所示。

表2 实验环境参数说明Table 2 Experimental environment parameters

4.2 实验方案设计

4.2.1 拓扑关系

本实验系统实现了私有RP 场景下的部署方案一，即RP 部署Monitor 和Auditor 两个功能模块，为局部范围内的CA 订阅用户提供资源证书撤销状态检测服务，实验拓扑如图11所示，其中，Log 服务器部署在腾讯云上，CA 和RP 部署在科技云上。

图1 RPKI 体系结构Fig.1 RPKI architecture

图11 实验拓扑示意图Fig.11 Experimental topology diagram

4.2.2 具体实现

具体而言，CA 侧基于Krill 软件和Docker 容器[22]实现了CA 实例的层级式认证部署。首先，所有具备父子关系的CA 对基于RPKI 生产服务带外设置协议[23]完成身份关系的建立，其次，基于资源证书发放协议[24]完成资源证书的申请和签发，另外，父CA 负责维护所有子CA 的资源证书。CA 侧的部署信息如表3所示，第一层（level-1）CA 为实验环境中RPKI 体系的本地信任锚点且数量为1；第二层（level-2）CA 为信任锚点的孩子节点且总数量为10，其资源证书由信任锚点签发且每一个level-2 CA持有1 张资源证书；第三层（level-3）CA 为level-2 CA 的孩子节点且总数量为100，每一个level-2 CA与10 个level-3 CA 建立父子关系并为其签发10 张资源证书。考虑到level-2 CA 的资源证书签发负担较重，本实验为其分配了两个核，其他类型的CA均运行在一个核上。

表3 实验方案中CA 侧的认证结构Table 3 The certification structure of CAs in the experimental scheme

本实验部署了一个RP 实例，并基于Routinator软件和Docker 容器实现，配置level-1 CA 的资源证书作为信任锚点，并与CA 侧部署在同一台服务器上。CA 基于HTTP 协议向RP 订阅资源证书撤销状态检测服务，RP 在本地构建了一个“父子证书对集合”，负责维护所有CA 订阅用户及其上级CA 的身份信息（资源证书）。当同步RPKI 资料库后发现“父子证书对集合”中父证书对应的Manifest 存在更新时，RP首先检查CA 订阅用户的资源证书（子证书）是否包含于更新Manifest 中，如果存在，RP 停止检测，否则，RP 向Log 服务器查询该更新Manifest 的存在一致性和内容一致性。本实验部署了一个Log 服务器实例，CA 和Log 服务器，以及RP 和Log 服务器之间的交互均基于HTTP 协议。前一个过程实现Manifest的发布，任何一个CA 的任何一次Manifest 更新均需发布至Log 服务器；后一个过程实现Manifest 存在性结果的请求和响应，RP 向Log 服务器发送需要查询的Manifest 或Manifest 的哈希值，并接收来自Log 服务器的存在性响应结果。

4.2.3 测试方案

本实验从准确率和效率两个方面测试验证了RP提供的资源证书撤销状态检测服务的性能。其中，准确率指该服务检测出的资源证书撤销行为相对于实际发生的资源证书撤销行为的占比；效率指检测出的资源证书撤销行为的数量与检测所用总时长的比值。针对准确率的测量，本方案通过执行脚本的方式在CA 侧随机撤销10、100 和1 000 个由level-2 CA 签发的资源证书，在此之前，保证被撤销资源证书的CA 已向RP 订阅资源证书撤销状态检测服务，最后，统计RP 检测出的被撤销资源证书的数量。针对效率的测量，本方案通过设置不同CA 订阅用户的数量，统计了检测所有CA 订阅用户的资源证书撤销状态的总时长。

当Log 服务器存储Manifest 原始数据时可快速响应来自RP 的存在性请求，如图12中蓝线所示。然而，考虑到未来RPKI 部署场景下CA 订阅用户的数量，以及上级CA 的Manifest 更新频率持续增加等因素，均会加重Log 服务器的维护和存储负担。因此，本实验设计了两组对比方案，每一组对比方案包含以下两种实现方式：（1）RP 向Log 服务器发送Manifest 原始数据；（2）RP 向Log 服务器发送Manifest 的哈希值。需要说明的是，针对第一种实现方式，Log 服务器存储Manifest 原始数据，针对第二种实现方式，Log 服务器基于HashMap 数据结构维护Manifest 的哈希值。

第一组对比方案测试RP 的资源证书撤销状态检测服务的效率，通过梯度增加CA 订阅用户的数量，统计对比了两种实现方式下RP 检测资源证书撤销状态的总时长。第二组对比方案测试RP 与Log 服务器之间的查询开销，通过增加被撤销资源证书的数量，统计对比了两种实现方式下RP 与Log 服务器之间的传输负载。

4.3 实验结果分析

4.3.1 准确率

针对一个CA 订阅用户而言，当RP 感知其上级CA 的Manifest 发生更新后，通过检查CA 订阅用户的资源证书是否在该更新Manifest 中即可检测其撤销状态。当资源证书撤销行为确认发生后，RP 无需向Log 服务器发起Manifest 存在性请求。因此，Log服务器中Manifest 的存储形式并不影响资源证书撤销状态检测服务的准确率。另外，本实验分别将被撤销资源证书的数量设置为10、100 和1 000，并分别统计了三种情形下RP 的资源证书撤销状态检测服务的准确率，均能达到100%。

4.3.2 效率

针对资源证书撤销状态检测服务的效率测量，本实验将CA 订阅用户的数量设置为200、400、600、800 和1000，并分别统计了基于Manifest 和基于Manifest 哈希值两种实现方式下，检测所有CA订阅用户的资源证书撤销状态的总时长，具体信息如图12所示。

图12 两种实现方式下资源证书未被撤销和被撤销情形下RP 的检测总时长Fig.12 The total detection time of RP under different revocation situations of resource certificate in two implementations

其中，蓝线和红线分别表示CA 订阅用户的资源证书全部被撤销情况下基于Manifest 和基于Manifest 哈希值实现方式下，RP 的检测总时长；绿线表示CA 订阅用户的资源证书全部未被撤销情况下基于两种实现方式下，RP 的检测总时长。根据图12可知，在资源证书撤销发生的情况下，基于Manifest的实现方式在检测时长上略胜一筹，原因在于基于Manifest 哈希值实现方式下哈希计算的时间开销，以及哈希冲突导致的查询开销。另外，在资源证书撤销并未发生的情况下，基于两种实现方式所需要的时间完全一致，原因在于当RP 检测到CA 订阅用户的资源证书存在于其上级CA 的Manifest 后，并不再向Log 服务器发送查询请求。由此可知，当资源证书撤销行为的数量较少时，BT 机制引入的额外查询开销可忽略不计。

由于RP 软件同步下载和本地验证 RPKI 数据对象需要一定的时间，本实验以十分钟为单位，持续统计了两个星期时间范围内资源证书的撤销情况，发现这一数量为个位数，平均值为6 张。截止目前，30%左右的 IP 地址空间纳入RPKI 认证体系，并且，资源证书的签发数量大约为27,000 张。由于资源证书的总数量不仅取决于资源持有者的数量，也取决于资源证书中IP 前缀的分布情况，因此，我们可以简单地评估，在未来RPKI 部署场景下，资源证书的签发数量大约为90,000 张，并且，每十分钟资源证书的撤销数量大约为20 张。根据上述实验数据和评估数据可知，BT 机制提供的资源证书撤销状态检测服务能够很好地满足当前RPKI 部署环境下和未来RPKI 部署环境下资源证书撤销状态的检测需求。

4.3.3 传输开销

随着RPKI 部署进程的持续推进，CA 订阅用户数量的急剧增加，Manifest 更新频率的逐渐加快，RP 将向Log 服务器发送大量的查询请求，Log 服务器将面临巨大的查询压力。根据图13所示，蓝线和红线分别表示RP 查询请求的两种实现方式，即RP向Log 服务器发送Manifest 和Manifest 哈希值以检测其存在性。由图可知，基于Manifest 哈希值的实现方式在降低RP 与Log 服务器之间传输开销上具有更为明显的优势。

图13 两种实现方式下RP 与Log 服务器之间的查询传输开销Fig.13 The transmission overhead between the RP and the Log server in two implementations

5 结论与展望

本文针对RPKI 体系的层级式、集中化认证结构引入的单边撤销问题，以及由此导致的资源无效风险，提出了一种基于行为透明性的RPKI 撤销检测机制。这一想法主要受到了Google 公司于2012年提出的证书透明性方案的启发，CT 机制通过部署Log 服务器以记录CA 签发的每一张证书，以此透明化CA 的证书签发行为，从而实现伪造证书的及时检测以及相关CA 的问责。CT 机制主要用于解决SSL/TLS PKI 系统中所有CA 具备相同签发权力导致的证书伪造问题，然而，无法透明化证书的单边撤销行为。本文提出的BT 机制，通过设立Log 服务器并要求CA 将反映其签发行为的Manifest 发布于其中，达到透明化CA 的资源证书撤销行为的目的。Manifest 是一个CA 在某一个时间段内签发且认可的所有数据对象的快照文件，于是，通过查看Manifest的具体内容以及对比相邻两个版本的Manifest 可以有效检测一张资源证书的撤销状态以及一个CA 在某一个时间段内的所有资源证书撤销行为。与其他解决方案相比，BT 机制的优势也较为显著：（1）公开的、实时性、持续地的监督和审计；（2）渐进式、小规模部署也能取得较好效果；（3）对现有RPKI 基础设施影响很小。

利益冲突声明

所有作者声明不存在利益冲突关系。