鄒慧，李彥彪，于晨暉，馬迪，毛偉

1.中國(guó)科學(xué)院計(jì)算機(jī)網(wǎng)絡(luò)信息中心,北京 100083

2.中國(guó)科學(xué)院大學(xué)，北京 100049

3.互聯(lián)網(wǎng)域名系統(tǒng)北京市工程研究中心，北京 100190

引言

互聯(lián)網(wǎng)碼號(hào)資源公鑰基礎(chǔ)設(shè)施（Resource Public Key Infrastructure,RPKI）[1]基于公鑰基礎(chǔ)設(shè)施（Public Key Infrastructure,PKI）技術(shù)為IP 前綴和自治系統(tǒng)（Autonomous System,AS）號(hào)構(gòu)建了一套認(rèn)證系統(tǒng)，用于認(rèn)證資源的所有權(quán)和使用權(quán)。RPKI 的設(shè)計(jì)初衷在于增強(qiáng)邊界網(wǎng)關(guān)協(xié)議（Border Gateway Protocol,BGP）的安全性，然而，PKI 技術(shù)與互聯(lián)網(wǎng)碼號(hào)資源管理體系的融合，從技術(shù)手段上賦予了資源分配者單邊撤銷資源的權(quán)力，換言之，上級(jí)認(rèn)證權(quán)威（Certificate Authority,CA）對(duì)下級(jí)CA 產(chǎn)生了絕對(duì)的控制力和影響力。越靠近認(rèn)證頂層的CA 具備的權(quán)力越大，能力越大意味著責(zé)任越大，越容易成為攻擊對(duì)象或者為特殊組織機(jī)構(gòu)所利用。當(dāng)一個(gè)CA 配置錯(cuò)誤或者遭受攻擊，甚至為政府/法律脅迫，可能導(dǎo)致該CA 或/和下級(jí)CA 的RPKI 數(shù)據(jù)對(duì)象出現(xiàn)異常，無法真實(shí)、準(zhǔn)確地反映互聯(lián)網(wǎng)碼號(hào)資源的分配關(guān)系和授權(quán)關(guān)系，這些錯(cuò)誤的RPKI 數(shù)據(jù)對(duì)象進(jìn)一步映射至域間路由系統(tǒng)，無法準(zhǔn)確指導(dǎo)BGP 路由。特別地，在未部署RPKI 之前，資源申請(qǐng)者和資源分配者在資源撤銷這一問題上需要通過帶外協(xié)商方式達(dá)成共識(shí)，資源分配者才能執(zhí)行資源回收操作。在部署RPKI 之后，資源分配者可以在不經(jīng)過資源申請(qǐng)者同意的情況下，通過撤銷資源證書的方式，單邊回收已分配給資源申請(qǐng)者的合法資源。于是，資源申請(qǐng)者所在的IP 地址空間被RPKI 驗(yàn)證為無效，進(jìn)而導(dǎo)致其所在的IP 地址空間在互聯(lián)網(wǎng)上陷入“路由黑洞”的危險(xiǎn)局面。換言之，RPKI 將域間路由系統(tǒng)的安全風(fēng)險(xiǎn)由協(xié)議技術(shù)層面遷移至了運(yùn)行管理層面。

截止目前，互聯(lián)網(wǎng)上并未發(fā)生由于RPKI 認(rèn)證權(quán)威錯(cuò)誤配置或者惡意操作導(dǎo)致的IP 前綴撤銷事件，主要原因在于RPKI 仍然處于部署初期階段。然而，域名系統(tǒng)（Domain Name System,DNS）和Web PKI系統(tǒng)均發(fā)生過“域名接管（DNS takedowns）”和“證書撤銷”事件。由此可以推斷，IP 前綴撤銷事件的暫時(shí)未發(fā)生并不代表未來不可能發(fā)生，我們需要提前謀劃布局，未雨綢繆地提出應(yīng)對(duì)上級(jí)CA 單邊撤銷權(quán)力這一安全風(fēng)險(xiǎn)的解決方案。為此，本文設(shè)計(jì)并實(shí)現(xiàn)了基于行為透明性（Behavior Transparency,BT）的RPKI 撤銷檢測(cè)機(jī)制（下文簡(jiǎn)稱為“BT 機(jī)制”），開展了豐富的實(shí)驗(yàn)以驗(yàn)證其效果，并從效率、準(zhǔn)確率和傳輸開銷三方面評(píng)估了該機(jī)制的性能。實(shí)驗(yàn)結(jié)果表明，在部署有日志服務(wù)器且日志服務(wù)器足夠安全可控的前提下，該機(jī)制的檢測(cè)效率能滿足當(dāng)前架構(gòu)性能需求，且準(zhǔn)確率達(dá)到100%，傳輸開銷可忽略不計(jì)。

1 相關(guān)工作

1.1 安全分析

文獻(xiàn)[2]首次提出了“RPKI 安全威脅模型”——認(rèn)證權(quán)威存在配置錯(cuò)誤、遭受攻擊或被迫做出不當(dāng)行為，并分析了可能存在的異常操作以及由此帶來的安全風(fēng)險(xiǎn)。該團(tuán)隊(duì)進(jìn)一步擴(kuò)展上述工作，提出了CA“外科手術(shù)式”精確撤銷其子孫節(jié)點(diǎn)的路由起源授權(quán)（Route Origin Authorization,ROA）數(shù)據(jù)對(duì)象的一般流程，并討論了資源單邊撤銷對(duì)RPKI 體系以及域間路由系統(tǒng)的影響[3]。

RFC 8211[4]以RPKI 數(shù)據(jù)對(duì)象為切入點(diǎn)，構(gòu)建了RPKI 數(shù)據(jù)安全威脅模型。通過定義問題域和術(shù)語集的方式，該標(biāo)準(zhǔn)詳細(xì)分析了CA 在不同運(yùn)行模式下，針對(duì)不同類型RPKI 數(shù)據(jù)對(duì)象發(fā)起不同類型誤操作或者惡意攻擊，可能為域間路由系統(tǒng)引入的安全風(fēng)險(xiǎn)。其中，前三種誤操作/惡意攻擊行為需要獲取被攻擊CA 的私鑰，后三種并不需要知曉這一信息。

文獻(xiàn)[5]探討了RPKI 體系的出現(xiàn)對(duì)互聯(lián)網(wǎng)服務(wù)提供商（Internet Service Provider,ISP）、區(qū)域互聯(lián)網(wǎng)注冊(cè)管理機(jī)構(gòu)（Regional Internet Registry,RIR）、互聯(lián)網(wǎng)名稱與數(shù)字地址分配機(jī)構(gòu)（The Internet Corporation for Assigned Names and Numbers,ICANN）和政府等不同類型實(shí)體以及它們之間關(guān)系所帶來的重要影響，涵蓋經(jīng)濟(jì)利益、權(quán)力分配格局、政治策略以及商業(yè)運(yùn)營(yíng)模式等多個(gè)方面，而這一系列的變革對(duì)不同利益相關(guān)方在 RPKI 部署層面的激勵(lì)并不一致。另外，該研究報(bào)告指出RPKI 的部署從本質(zhì)上改變了RIR 這一角色的功能特性，從地址資源的分配管理者轉(zhuǎn)變?yōu)槁酚赏ǜ娴恼J(rèn)證權(quán)威，在一定程度上提高了 RIR 在域間路由系統(tǒng)中的影響力，降低了地址持有者（例如ISP）的自治性，并且重塑了國(guó)際互聯(lián)網(wǎng)治理格局。

1.2 解決方案

針對(duì)RPKI 體系的層級(jí)式認(rèn)證結(jié)構(gòu)導(dǎo)致的集權(quán)問題，學(xué)術(shù)界和工業(yè)界已經(jīng)進(jìn)行了一些研究，大致可分為兩類：（1）“演進(jìn)型”解決方案，即保留RPKI 體系的層級(jí)式認(rèn)證結(jié)構(gòu)，并分別以CA 和RP為切入點(diǎn)，帶內(nèi)地制衡/分散CA 的集中權(quán)力和帶外地部署本地修復(fù)方案化解安全風(fēng)險(xiǎn)；（2）“革命型”解決方案，即改革RPKI 體系的層級(jí)式認(rèn)證結(jié)構(gòu)，基于區(qū)塊鏈技術(shù)實(shí)現(xiàn)資源的注冊(cè)、認(rèn)證和管理的去中心化，消除對(duì)于集中化認(rèn)證權(quán)威的信任和依賴。

1.2.1 “演進(jìn)型”解決方案

（1）基于CA 的解決方案

Consent 機(jī)制[6]和Suspenders 機(jī)制[7]是面向所有CA 的安全保障方案，兩者的核心思想旨在通過賦予下級(jí)CA 一定的權(quán)力，從而改善RPKI 認(rèn)證權(quán)威側(cè)權(quán)力不對(duì)等的局面。在Consent 機(jī)制中，當(dāng)上級(jí)CA 撤銷一個(gè)IP 前綴時(shí)，所有受到影響的下級(jí)CA均需簽發(fā)表示同意的.dead 數(shù)據(jù)對(duì)象并逐級(jí)反饋至上級(jí)CA，于是，RP 可根據(jù).dead 數(shù)據(jù)對(duì)象集合判斷相關(guān)CA 是否就資源撤銷操作達(dá)成一致共識(shí)。然而，Consent 機(jī)制要求所有CA 運(yùn)行在delegated CA模式下，并且僅僅為資源證書提供保護(hù)，此外，復(fù)雜的橫縱向Manifest 哈希鏈加重了部署和維護(hù)負(fù)擔(dān)。在Suspenders 機(jī)制中，CA 使用互聯(lián)網(wǎng)碼號(hào)資源聲明（Internet Number Resource Declaration,INRD）文件記錄一段時(shí)間范圍內(nèi)其持有資源所有權(quán)/使用權(quán)的變更信息，該文件由CA 維護(hù)在獨(dú)立于RPKI 體系的存儲(chǔ)系統(tǒng)中。于是，RP 可根據(jù)INRD 文件的授權(quán)信息，判定一段時(shí)間內(nèi)發(fā)生的資源分配和授權(quán)信息變更內(nèi)容的合法性，一旦發(fā)現(xiàn)未授權(quán)的變更內(nèi)容，RP 延遲更新并通知相關(guān)參與方，嘗試提供一個(gè)合理的解決方案。但是，CA 運(yùn)行模式的多樣性以及 INRD 文件的管理復(fù)雜性，將導(dǎo)致Suspenders 機(jī)制在實(shí)際部署后的安全保障能力大打折扣。

基于門限簽名的多方計(jì)算（Multiple-Party Computation,MPC）方案[8]針對(duì)托管CA（hosted CA）運(yùn)行模式下信任錨點(diǎn)權(quán)力過于集中問題，提出在五大RIR 之間使用門限簽名算法以分布信任，數(shù)據(jù)對(duì)象的簽發(fā)、修改和撤銷需要一定數(shù)量的RIR 共同協(xié)作才能完成，從而防止單一RIR 的權(quán)力濫用。但是，該方案并不能解決除信任錨點(diǎn)之外CA 的權(quán)力不平衡問題。

（2）基于RP 的本地管理/修復(fù)方案

本地信任錨點(diǎn)管理（Local Trust Anchor Management,LTAM）機(jī)制[9]和簡(jiǎn)化版的本地碼號(hào)資源管理（Simplified nUmber Resource Management,SLURM）機(jī)制[10]均是以RP 為部署平臺(tái)，并根據(jù)第三方權(quán)威機(jī)構(gòu)提供的配置文件實(shí)現(xiàn)資源本地化管理的解決方案。其中，前者以RP 作為本地信任錨點(diǎn)（Local Trust Anchor,LTA），并根據(jù)“約束文件（constraints file）”完成全球RPKI 資料庫(kù)的重新掛載——資源證書的本地重簽發(fā)，以準(zhǔn)確詮釋約束文件中表達(dá)的資源分配和授權(quán)關(guān)系信息。后者是一個(gè)簡(jiǎn)化版的輕量級(jí)部署方案，根據(jù)SLURM 文件的配置內(nèi)容過濾或者添加資源授權(quán)關(guān)系信息條目即可達(dá)成與LTAM 機(jī)制相同的管理目的，從而避免了復(fù)雜的證書簽發(fā)和維護(hù)管理工作。需要說明的是，“本地”指RPKI 數(shù)據(jù)對(duì)象的生效范圍，即RP 的服務(wù)范圍，小可為一個(gè)運(yùn)營(yíng)商網(wǎng)絡(luò)，大可至一個(gè)國(guó)家管理區(qū)域。

1.2.2 “革命型”解決方案

BGPcoin[11]、IPchain[12]和InBlock[13]是三種典型的基于區(qū)塊鏈的去中心化解決方案，三者基于IP 地址和AS 號(hào)與數(shù)字貨幣之間的共同特性——可轉(zhuǎn)讓、可分配、不能同時(shí)分配給多個(gè)實(shí)體，實(shí)現(xiàn)了互聯(lián)網(wǎng)碼號(hào)資源分配關(guān)系信息的去中心、可追溯和防篡改認(rèn)證。BGPcoin 將IP 地址和AS 號(hào)作為一種財(cái)產(chǎn)，并基于公共賬本和智能合約記錄每一次互聯(lián)網(wǎng)碼號(hào)資源所有權(quán)變更的交易信息。IPchain 使用權(quán)益證明（Proof of Stack,PoS）共識(shí)機(jī)制實(shí)現(xiàn)了對(duì)IP 地址的分配管理，保證了安全性的同時(shí)降低了存儲(chǔ)開銷。然而，在這種情況下，地址持有者越多的實(shí)體擁有更多的話語權(quán)，仍然存在一定的權(quán)力中心化問題。InBlock引入了收費(fèi)機(jī)制以防止相關(guān)參與方針對(duì)IP 地址的惡意申請(qǐng)、囤積和浪費(fèi)行為，即任何申請(qǐng)IP 地址分配的實(shí)體需要繳納一定的虛擬貨幣，通過物質(zhì)刺激的方式實(shí)現(xiàn)保護(hù)互聯(lián)網(wǎng)碼號(hào)資源的目的。

2 背景知識(shí)

2.1 證書透明性和默克爾樹

在證書偽造事件頻發(fā)的背景下，為了減輕SSL PKI 證書系統(tǒng)的結(jié)構(gòu)性缺陷，Google 于2012年提出了證書透明性（Certificate Transparency,CT）[14]解決方案。CT 機(jī)制的目標(biāo)在于提供一個(gè)開放透明的監(jiān)督和審計(jì)系統(tǒng)，要求CA 向該系統(tǒng)提交所有簽發(fā)的證書。需要說明的是，CT 機(jī)制并不能阻止CA 簽發(fā)錯(cuò)誤或虛假證書，但是正如它的名字所暗示的一樣，它使得相關(guān)參與方（域名所有者、瀏覽器等）更加清楚地看到CA 的證書簽發(fā)行為，從而使得錯(cuò)誤/偽造證書的檢測(cè)過程變得相對(duì)容易，以便相應(yīng)措施的及時(shí)部署。在一定程度上，CT 機(jī)制使得CA 難以錯(cuò)發(fā)虛假/錯(cuò)誤的證書，原因在于CT 機(jī)制鼓勵(lì)Web瀏覽器拒絕沒有經(jīng)過公開審計(jì)的證書，這就迫使CA公開注冊(cè)由其簽發(fā)的證書，從源頭上減少了證書的錯(cuò)誤簽發(fā)機(jī)率。再者，用戶能夠檢測(cè)識(shí)別包含其合法持有域名的偽造證書。

CT 機(jī)制引入了三種全新角色，分別為日志服務(wù)器（Log）、監(jiān)督者（Monitor）和審計(jì)者（Auditor）。在為某個(gè)域名持有者簽發(fā)服務(wù)器證書之后，CA 需要及時(shí)地將該證書發(fā)布至公開的Log 服務(wù)器中。Log服務(wù)器以默克爾樹（Merkle Tree）的形式存儲(chǔ)所有提交的證書，并保證Append-Only（只增不刪）特性。換言之，一旦Log 服務(wù)器接受了某張證書的注冊(cè)請(qǐng)求，該Log 服務(wù)器的屬性可以保證這一證書永遠(yuǎn)不會(huì)被移除、修改或者追溯。Monitor 周期性地下載Log 服務(wù)器中的證書集合，并從中排查可疑證書。Auditor 的設(shè)立旨在審計(jì)Log 服務(wù)器的行為正確性，即是否在承諾時(shí)間范圍內(nèi)發(fā)布向其提交的證書。由此可知，CT 機(jī)制改變了證書的簽發(fā)流程，新流程規(guī)定：證書必須記錄到可公開驗(yàn)證、不可篡改且只增不刪的Log 服務(wù)器中，終端用戶的Web 瀏覽器才會(huì)將其視為有效。CT 機(jī)制允許任何感興趣的相關(guān)參與方查看任一CA 簽發(fā)的任一證書，這一策略能夠促使CA 在簽發(fā)證書時(shí)更加謹(jǐn)慎和負(fù)責(zé)，從而有助于形成一個(gè)更可靠的Web PKI 生態(tài)系統(tǒng)。

2.2 RPKI 體系結(jié)構(gòu)和Manifest

RPKI 體系主要由兩部分構(gòu)成：CA 系統(tǒng)和依賴方（Relying Party,RP）系統(tǒng)。CA 系統(tǒng)與互聯(lián)網(wǎng)碼號(hào)資源管理體系相吻合，頂級(jí)節(jié)點(diǎn)為五大 RIR，下級(jí)節(jié)點(diǎn)包括國(guó)家互聯(lián)網(wǎng)注冊(cè)機(jī)構(gòu)（National Internet Registry,NIR ）、本地互聯(lián)網(wǎng)注冊(cè)機(jī)構(gòu)（Local Internet Registry,LIR）、ISP 以及其他獨(dú)立的IP 地址持有機(jī)構(gòu)。每一個(gè)納入RPKI 認(rèn)證體系的資源持有者均可視為PKI 意義層面上的CA，負(fù)責(zé)資源證書和ROA等數(shù)據(jù)對(duì)象的簽發(fā)，以此認(rèn)證資源的分配和授權(quán)關(guān)系信息。每一個(gè)CA 負(fù)責(zé)維護(hù)一個(gè)邏輯上的發(fā)布點(diǎn)（Publication Point,PP），用于存儲(chǔ)由其簽發(fā)的所有數(shù)據(jù)對(duì)象，所有發(fā)布點(diǎn)共同構(gòu)成全球分布式RPKI 資料庫(kù)（Repository）[15]。

考慮到BGP 路由器的性能和存儲(chǔ)限制以及數(shù)據(jù)包的實(shí)時(shí)傳輸要求，RPKI 并不要求每一臺(tái)BGP路由器自行獲取用于驗(yàn)證路由通告合法性的認(rèn)證依據(jù)。取而代之，RPKI 通過設(shè)立RP 實(shí)體作為BGP路由器的代理，負(fù)責(zé)一些重復(fù)的、可離線處理的事務(wù)，包括數(shù)據(jù)對(duì)象的同步下載、證書鏈的構(gòu)建和驗(yàn)證、資源授權(quán)關(guān)系信息的生成和傳輸以及緩存管理等工作。最后，RP 將驗(yàn)證為有效的資源授權(quán)關(guān)系信息傳輸分發(fā)至BGP 域間路由系統(tǒng)，供路由器驗(yàn)證路由消息的有效性，并作為輸入之一參與路由決策過程。

然而，在RPKI 數(shù)據(jù)對(duì)象的同步下載過程中，可能存在針對(duì)發(fā)布點(diǎn)以及CA 與RP 之間傳輸通道的惡意攻擊，為此，CA 通過簽發(fā)資源清單（Manifest）一一列舉發(fā)布點(diǎn)中除自身之外所有數(shù)據(jù)對(duì)象的文件名和哈希值，以提供面向發(fā)布點(diǎn)的完整性保護(hù)，從而協(xié)助RP 判定攻擊行為的發(fā)生與否。作為Manifest的初始標(biāo)準(zhǔn)文檔，RFC 6486[16]允許異常Manifest（丟失、過期和無效），以及Manifest與發(fā)布點(diǎn)之間沖突（一個(gè)數(shù)據(jù)對(duì)象存儲(chǔ)于發(fā)布點(diǎn)卻未列于Manifest 中，或一個(gè)發(fā)布點(diǎn)未存儲(chǔ)于發(fā)布點(diǎn)卻列于Manifest 中）的存在，針對(duì)上述異常和沖突，RP 可根據(jù)本地策略自行處理。然而，2020年 2月 25日 RIPE NCC 發(fā)布點(diǎn)下的證書撤銷列表（Certificate Revocation List,CRL）過期，引發(fā)了 IETF SIDROPS 工作組針對(duì)異常 CRL的處理策略以及 CRL 存在必要性的討論，并啟動(dòng)了針對(duì)RFC 6486 的修訂工作[17]，強(qiáng)化了Manifest 的重要性并提高了Manifest 的優(yōu)先級(jí)，換言之，異常狀態(tài)的Manifest 不再為RP 所接受，并且，RP 僅接受列于Manifest 中的RPKI 數(shù)據(jù)對(duì)象。

3 機(jī)制設(shè)計(jì)

3.1 威脅模型

PKI 技術(shù)的層級(jí)式、集中化認(rèn)證結(jié)構(gòu)將單邊撤銷問題引入資源管理系統(tǒng)，導(dǎo)致下級(jí)CA 的資源無效。本章假定CA 存在配置錯(cuò)誤或者遭受惡意攻擊的可能性，并定義了資源撤銷威脅模型，包含針對(duì)資源證書的三種操作類型，三者均可以達(dá)成資源撤銷目的，然而，被操作資源證書在Manifest、CRL和發(fā)布點(diǎn)的表現(xiàn)形式并不一致。詳細(xì)信息如表1所示，其中，白色符號(hào)/黑色符號(hào)分別表示資源證書不存在/存在于Manifest/CRL 或發(fā)布點(diǎn)中。其中，刪除指上級(jí)CA 未使用合法撤銷流程將下級(jí)CA 的資源證書從發(fā)布點(diǎn)中刪除，并簽發(fā)新的Manifest 和CRL，此時(shí)，Manifest 和CRL 中均未列出被刪除的資源證書。撤銷指上級(jí)CA 使用合法撤銷流程將下級(jí)CA 的資源證書標(biāo)記為撤銷狀態(tài)并從發(fā)布點(diǎn)中刪除，此時(shí)，Manifest 和發(fā)布點(diǎn)中不包含該資源證書，而CRL 中記錄了該資源證書的撤銷狀態(tài)。根據(jù)被撤銷資源的多少，資源證書撤銷操作可分為兩種：（1）撤銷一張資源證書導(dǎo)致所有資源無效；（2）撤銷一張資源證書的同時(shí)重新簽發(fā)一張包含更少資源的資源證書，導(dǎo)致被減少資源無效。延遲指上級(jí)CA 推遲發(fā)布下級(jí)CA 的新版資源證書（僅更新有效期，資源集并未改變），導(dǎo)致下級(jí)CA 的舊版資源證書存在于發(fā)布點(diǎn)中，但是并未列于新版Manifest 和新版CRL 中。

表1 資源撤銷威脅模型Table 1 Types of resource revocation

3.2 技術(shù)原理

3.2.1 核心思想

BT 機(jī)制借鑒了CT 機(jī)制的核心思想，旨在通過增加CA簽發(fā)行為透明性的方式達(dá)到威懾CA的目的，使得CA 不愿/不敢肆無忌憚地單邊撤銷已為下級(jí)CA 分配的合法資源，在一定程度上制衡了CA 的單邊權(quán)力。Log 服務(wù)器中存儲(chǔ)的CA 簽發(fā)行為歷史記錄，以及數(shù)字簽名提供的不可篡改和不可抵賴性，為相關(guān)參與方提供了及時(shí)檢測(cè)資源證書撤銷狀態(tài)的能力，以及問責(zé)撤銷行為發(fā)起實(shí)體的渠道。另外，本方案提供了資源證書撤銷狀態(tài)查詢服務(wù)，使得CA 具備實(shí)時(shí)感知自持有資源證書撤銷狀態(tài)的能力。

3.2.2 新增角色

與CT 機(jī)制類似的是，BT 機(jī)制為RPKI 體系引入了三種全新角色，分別為L(zhǎng)og 服務(wù)器、Monitor 和Auditor。Log 服務(wù)器的設(shè)立旨在增加CA 簽發(fā)行為的透明性，與CT 機(jī)制不同的是，Log 服務(wù)器并不存儲(chǔ)CA 簽發(fā)的資源證書，而是存儲(chǔ)Manifest 數(shù)據(jù)對(duì)象，即CA 在一段時(shí)間范圍內(nèi)所有簽發(fā)行為的“快照文件”。當(dāng)CA 初始化發(fā)布點(diǎn)或者更新發(fā)布點(diǎn)中RPKI 數(shù)據(jù)對(duì)象的個(gè)數(shù)或/和內(nèi)容后，Manifest 也隨之產(chǎn)生或更新。BT 機(jī)制的“Manifest 注冊(cè)政策”，即要求所有CA 向Log 服務(wù)器注冊(cè)由其簽發(fā)的每一個(gè)Manifest，從而保證了CA簽發(fā)行為的有據(jù)可循。于是，當(dāng)一張資源證書被某一CA 刪除/撤銷/延遲后，一方面，我們可以推斷該CA 簽發(fā)的Manifest 中一定不包含被撤銷的資源證書，否則，發(fā)布點(diǎn)與Manifest的內(nèi)容不一致將導(dǎo)致整個(gè)發(fā)布點(diǎn)的同步失?。ū徊僮髻Y源證書不在發(fā)布點(diǎn)卻列于Manifest 中），CA 付出的代價(jià)太大。另一方面，Manifest 注冊(cè)策略保證了該CA 資源證書撤銷行為的可溯源。需要說明的是，BT 機(jī)制并不能阻止CA 惡意撤銷資源證書，其目的僅僅在于透明化CA 的簽發(fā)行為，從而簡(jiǎn)化和加速惡意撤銷行為的檢測(cè)流程，降低和縮小惡劣影響的持續(xù)時(shí)間和波及范圍。

Monitor 的設(shè)立旨在監(jiān)督CA 的簽發(fā)行為，通過實(shí)時(shí)檢測(cè)資源證書的撤銷狀態(tài)，從而揭露CA 的資源證書撤銷行為。Monitor 角色可由CA、RP、Log服務(wù)器、第三方利益相關(guān)方或者服務(wù)提供商等實(shí)體擔(dān)任。作為資源持有者的CA，也是最關(guān)心資源有效性的實(shí)體，可以通過部署Monitor 定期地向Log 服務(wù)器發(fā)起資源證書撤銷狀態(tài)查詢請(qǐng)求，實(shí)時(shí)地感知自持有資源證書的撤銷狀態(tài)，并及時(shí)地向Log 服務(wù)器發(fā)布爭(zhēng)議信息。根據(jù)RFC 8210[18]中關(guān)于RP 部署場(chǎng)景的介紹，RP 一般部署在ISP 核心網(wǎng)或者大型邊緣網(wǎng)絡(luò)。在ISP 部署場(chǎng)景下，ISP 為每個(gè)客戶（AS）提供有償?shù)幕ヂ?lián)網(wǎng)接入服務(wù)；在大型邊緣網(wǎng)絡(luò)部署場(chǎng)景下，這一網(wǎng)絡(luò)覆蓋一個(gè)或者多個(gè)AS。在上述兩種RP 部署場(chǎng)景下，RP 的運(yùn)營(yíng)者與其服務(wù)范圍內(nèi)的資源持有者（AS）均屬于同一管理域，具有天然的信任關(guān)系。因此，RP 可作為代理，接受來自其服務(wù)范圍內(nèi)CA 的訂閱，并部署B(yǎng)T Monitor 為它們提供資源證書撤銷狀態(tài)的檢測(cè)服務(wù)。另外，由于保存了所有CA 的歷史版本Manifest，Log 服務(wù)器具備檢測(cè)資源證書撤銷狀態(tài)的天然優(yōu)勢(shì)，因此，Monitor 功能也可部署在Log 服務(wù)器。然而，由于被動(dòng)地接受Manifest 的注冊(cè)，Log 服務(wù)器存在一定局限性，即無法檢測(cè)尚未向其提交Manifest 的CA 是否存在惡意撤銷行為。除此之外，類似于Google 的公共遞歸解析服務(wù)器（8.8.8.8），BT Monitor 也可由大型內(nèi)容服務(wù)提供商部署，并對(duì)外提供公開的資源證書撤銷狀態(tài)檢測(cè)服務(wù)。與上述兩種私有BT Monitor 部署情形不同的是，公有BT Monitor 的服務(wù)范圍更加廣泛，接受來自全世界范圍內(nèi)CA 用戶的訂閱，并為其提供資源證書撤銷狀態(tài)的檢測(cè)服務(wù)。此時(shí)，BT Monitor將面臨存儲(chǔ)容量、下載頻率和檢測(cè)能力等多個(gè)方面的挑戰(zhàn)。

Auditor 的設(shè)立旨在審計(jì)Log 服務(wù)器的行為正確性，即是否在承諾時(shí)間范圍內(nèi)發(fā)布由CA 提交的Manifest，并且，是否存在刪除、修改和追加Manifest 的異常操作。作為Manifest 的提交者，CA可作為Auditor 直接審計(jì)Log 服務(wù)器的及時(shí)發(fā)布行為。另外，BT 機(jī)制改變了RP 的驗(yàn)證流程，針對(duì)一個(gè)CA 而言，只有當(dāng)RP 確定RPKI 資料庫(kù)與Log 服務(wù)器中發(fā)布的Manifest 完全一致時(shí)，才會(huì)認(rèn)為Manifest有效并繼續(xù)執(zhí)行后續(xù)的驗(yàn)證和分發(fā)流程。因此，在RPKI 數(shù)據(jù)對(duì)象的驗(yàn)證過程中，RP 可根據(jù)Manifest的存在性差異結(jié)果實(shí)現(xiàn)Log 服務(wù)器行為正確性的一并審計(jì)。

3.2.3 體系框架

BT 機(jī)制的引入改變了RPKI 體系中CA 和RP 的操作流程，其體系框架如圖2所示。在傳統(tǒng)的RPKI 體系中，CA 負(fù)責(zé)簽發(fā)資源證書、ROA、Manifest 等數(shù)據(jù)對(duì)象，并維護(hù)用于存儲(chǔ)上述數(shù)據(jù)對(duì)象的發(fā)布點(diǎn)，所有CA 的發(fā)布點(diǎn)構(gòu)成分布式RPKI 資料庫(kù)。RP 負(fù)責(zé)定期輪詢RPKI 資料庫(kù)以構(gòu)建RPKI 數(shù)據(jù)對(duì)象的本地副本，為每個(gè)數(shù)據(jù)對(duì)象創(chuàng)建一條直達(dá)信任錨點(diǎn)的證書鏈，并驗(yàn)證其有效性。最后，根據(jù)驗(yàn)證狀態(tài)為有效的ROA 數(shù)據(jù)對(duì)象生成IP 前綴和AS號(hào)的映射關(guān)系，并傳輸分發(fā)至BGP 域間路由系統(tǒng)。在部署B(yǎng)T 機(jī)制的RPKI 體系中，CA 需要在每一次數(shù)據(jù)對(duì)象更新之后將新版Manifest 發(fā)布至Log 服務(wù)器。此外，作為資源持有者的CA 可以自主地向Log服務(wù)器發(fā)起資源證書撤銷狀態(tài)查詢請(qǐng)求，也可以通過向RP 訂閱資源證書撤銷狀態(tài)服務(wù)，等待RP 定期地反饋資源證書的狀態(tài)信息。相應(yīng)地，RP 在同步驗(yàn)證完所有數(shù)據(jù)對(duì)象后，需要確認(rèn)每一個(gè)CA 發(fā)布于RPKI 資料庫(kù)的Manifest 是否存在于Log 服務(wù)器中。如果不存在，RP 認(rèn)為該CA 未遵循BT 機(jī)制的Manifest 注冊(cè)政策，拒絕該CA 簽發(fā)的所有數(shù)據(jù)對(duì)象；如果存在，則需要進(jìn)一步比較兩者內(nèi)容的一致性，如果存在差異，RP 則認(rèn)為該CA 并未將最新版本的Manifest 發(fā)布至Log 服務(wù)器中，并判定該CA 的發(fā)布點(diǎn)中所有數(shù)據(jù)對(duì)象無效。

圖2 BT 機(jī)制的體系框架Fig.2 The system framework of the BT mechanism

3.3 運(yùn)行模式

根據(jù)3.2.2 小節(jié)可知，作為一個(gè)可信第三方，Log服務(wù)器應(yīng)該由獨(dú)立于RPKI體系的新增實(shí)體擔(dān)任，Monitor 和Auditor 兩種角色則可由RPKI 體系中現(xiàn)有實(shí)體或者新增實(shí)體擔(dān)任。為了避免引入過多的實(shí)體類型，本文僅討論上述兩種角色分別由CA、RP和Log 服務(wù)器三種實(shí)體擔(dān)任的情形，實(shí)體承擔(dān)角色的數(shù)量和類型，決定了各個(gè)實(shí)體的運(yùn)行模式和功能模塊。下文分別介紹CA、RP 和Log 服務(wù)器的運(yùn)行模式，以及三者需要支持的功能模塊。

3.3.1 CA

根據(jù)CA 承擔(dān)角色的數(shù)量和類型，CA 的運(yùn)行模式可分為以下四類，分別為：“CA 運(yùn)行模式”、“CA-Auditor 運(yùn)行模式”、“CA-Monitor 運(yùn)行模式”和“CA-Auditor-Monitor 運(yùn)行模式”。圖3所示為支持BT 機(jī)制的CA 功能示意圖，其中，藍(lán)色表示BT 機(jī)制引入的新增功能模塊，在不同運(yùn)行模式下，CA 可具備不同類型和數(shù)量的功能模塊。

圖3 支持BT 機(jī)制的CA 功能模塊示意圖Fig.3 The function module of the BT-enabled CA

? CA 運(yùn)行模式

在傳統(tǒng)RPKI 體系中，認(rèn)證權(quán)威分為根CA——信任錨點(diǎn)（Trust Anchor,TA）和非根CA。作為RPKI 的頂級(jí)認(rèn)證機(jī)構(gòu)，TA 發(fā)布一張自簽名的資源證書實(shí)現(xiàn)資源所有權(quán)的自認(rèn)證，因此，TA 并不面臨上級(jí)CA 單邊撤銷其資源證書的安全風(fēng)險(xiǎn)。在這種情況下，TA 只需運(yùn)行在“BT-enabled CA 運(yùn)行模式”（下文簡(jiǎn)稱“CA 運(yùn)行模式”）下即可，并基于圖3所示發(fā)布接口向Log 服務(wù)器發(fā)布最新版本Manifest。另外，非根CA 也可以選擇“CA 運(yùn)行模式”，將資源證書撤銷狀態(tài)的查詢服務(wù)委托給信任的RP。在這種情況下，CA 需要提前通過帶內(nèi)機(jī)制（圖3所示訂閱接口）或者帶外機(jī)制（例如網(wǎng)站注冊(cè)等方式）向其信任的RP 訂閱資源證書撤銷狀態(tài)檢測(cè)服務(wù)。相應(yīng)地，當(dāng)RP 檢測(cè)到CA 訂閱用戶的資源證書被其上級(jí)CA撤銷后，可通過帶內(nèi)機(jī)制（圖3所示信息收集接口）或者帶外機(jī)制（例如郵件通知等方式）向CA 訂閱用戶反饋這一異常信息。

? CA-Auditor 運(yùn)行模式

針對(duì)一個(gè)CA 而言，RP 需要檢測(cè)RPKI 資料庫(kù)中該CA 簽發(fā)的Manifest 和Log 服務(wù)器中發(fā)布的Manifest 的一致性，檢測(cè)內(nèi)容包括存在一致性和內(nèi)容一致性兩個(gè)方面。因此，Log 服務(wù)器需要及時(shí)地發(fā)布由CA 提交的Manifest，否則，Manifest 的不一致將導(dǎo)致該CA 發(fā)布的所有數(shù)據(jù)對(duì)象被RP 判定為無效。因此，CA 可以通過部署Auditor 功能，定期地審計(jì)Log 服務(wù)器的行為正確性，由圖3所示查詢接口支持這一功能實(shí)現(xiàn)。

? CA-Monitor 運(yùn)行模式

由于非根CA 的資源證書均由其上級(jí)CA 簽發(fā)并維護(hù)，面臨資源證書單邊撤銷的安全風(fēng)險(xiǎn)。因此，非根CA 可以選擇運(yùn)行在CA-Monitor 模式下，即同時(shí)實(shí)現(xiàn)CA 功能和Monitor 功能（圖3所示查詢接口），實(shí)時(shí)地向Log 服務(wù)器查詢自持有資源證書的撤銷狀態(tài)。在這種情形下，CA 部署的Monitor 并不關(guān)注其他資源證書撤銷行為，而僅僅關(guān)注自持有資源證書是否被上級(jí)CA 惡意撤銷。

? CA-Auditor-Monitor 運(yùn)行模式

在該運(yùn)行模式下，認(rèn)證權(quán)威同時(shí)實(shí)現(xiàn)CA、Auditor和Monitor 三種功能，即負(fù)責(zé)RPKI 數(shù)據(jù)對(duì)象的簽發(fā)和維護(hù)、Log 服務(wù)器的行為審計(jì)以及資源證書撤銷狀態(tài)的檢測(cè)。然而，在該模式下，Log 服務(wù)器需要響應(yīng)大量的Manifest 發(fā)布請(qǐng)求、資源證書狀態(tài)查詢請(qǐng)求，以及行為正確響應(yīng)請(qǐng)求，加劇了Log 服務(wù)器的運(yùn)行負(fù)擔(dān)。

3.3.2 RP

在部署了BT 機(jī)制的RPKI 體系中，除了擔(dān)任“中轉(zhuǎn)處理站”（同步、驗(yàn)證和傳輸RPKI 數(shù)據(jù)對(duì)象）這一本職角色外，RP 還可以擔(dān)任Auditor 和Monitor兩種角色。因此，與CA 類似的是，RP 同樣具備四種運(yùn)行模式，分別為“BT-enabled RP 運(yùn)行模式”（下文簡(jiǎn)稱為“RP 運(yùn)行模式”）、“RP-Auditor 運(yùn)行模式”、“RP-Monitor 運(yùn)行模式”和“RP-Auditor-Monitor 運(yùn)行模式”。圖4所示為支持BT 機(jī)制的RP 功能示意圖，其中，藍(lán)色表示由于BT 機(jī)制引入的新增功能模塊，在不同運(yùn)行模式下，RP 可具備不同類型和數(shù)量的功能模塊。

圖4 支持BT 機(jī)制的RP 功能模塊示意圖Fig.4 The function module of the BT-enabled RP

? RP 運(yùn)行模式

在該運(yùn)行模式下，當(dāng)RP 同步成功一個(gè) Manifest后，基于圖4所示查詢或下載接口向Log 服務(wù)器發(fā)起該Manifest 的查詢或下載請(qǐng)求，旨在驗(yàn)證CA 是否遵循BT 機(jī)制的行為透明性要求，即及時(shí)向Log服務(wù)器注冊(cè)最新版本Mnifest，以及是否向Log 服務(wù)器“說謊”——提交偽造的Manifest。

? RP-Auditor 運(yùn)行模式

根據(jù)RP 的驗(yàn)證流程可知，針對(duì)一個(gè)CA 而言，只有當(dāng)該CA 發(fā)布于RPKI 資料庫(kù)和Log 服務(wù)器中的Manifest 完全一致時(shí)，RP 才接受由該CA 簽發(fā)的所有數(shù)據(jù)對(duì)象。在這一過程中，RP 首先需要確定Log服務(wù)器中Manifest 的存在性。因此，RP 天然地成為Auditor，具備驗(yàn)證Log 服務(wù)器行為正確性的能力。

? RP-Monitor 運(yùn)行模式

另外，RP 也可以部署Monitor 功能，以協(xié)助其服務(wù)范圍內(nèi)CA 用戶檢測(cè)資源證書的撤銷狀態(tài)。根據(jù)部署場(chǎng)景和服務(wù)范圍的不同，RP 的類型可分為私有RP 和公有RP。一般地，私有RP 僅僅面向同屬一個(gè)管理域內(nèi)的CA 提供資源證書撤銷狀態(tài)檢測(cè)服務(wù)，并且與之具備天然的帶內(nèi)信任關(guān)系，在這種情況下，CA 的數(shù)量有限并且CA 完全信任私有RP。作為一個(gè)中立第三方，公有RP 面向全世界范圍的CA 用戶提供服務(wù)，并供CA 與其自行建立信任關(guān)系，在這種情況下，CA 的數(shù)量龐大并且CA 需要與公有CA提前建立帶外信任關(guān)系。

在上述兩種部署場(chǎng)景下，CA 均需提前向RP訂閱檢測(cè)服務(wù)，RP 將CA 訂閱用戶及其上級(jí)CA 的身份信息（例如資源證書）存儲(chǔ)至圖4所示CA 訂閱用戶信息維護(hù)接口中，當(dāng)檢測(cè)到RPKI 資料庫(kù)中Manifest 發(fā)生更新時(shí)，判斷這一更新Manifest 是否為其CA 訂閱用戶的上級(jí)CA 簽發(fā)，如果是，則進(jìn)一步判斷CA 訂閱用戶的資源證書撤銷狀態(tài)。在私有RP部署場(chǎng)景下，RP 僅僅需要為CA 訂閱用戶維護(hù)它們上級(jí)CA 的最新版本Manifest，并根據(jù)CA 訂閱用戶提供的資源證書作為檢測(cè)依據(jù)，持續(xù)監(jiān)測(cè)CA 訂閱用戶的資源證書撤銷狀態(tài)并實(shí)時(shí)反饋。在公有RP 部署場(chǎng)景下，向RP 訂閱服務(wù)的CA 訂閱用戶數(shù)量較為龐大，在這種情況下，對(duì)于RP 的帶寬能力、存儲(chǔ)能力和處理能力都提出了較高的要求，并且需要及時(shí)響應(yīng)來自全球范圍內(nèi)大量訂閱用戶的并發(fā)查詢請(qǐng)求。

? RP-Auditor-Monitor 運(yùn)行模式

在該運(yùn)行模式下，RPKI 依賴方同時(shí)實(shí)現(xiàn)RP、Auditor 和Monitor 三種功能，即負(fù)責(zé)RPKI 數(shù)據(jù)對(duì)象的同步、驗(yàn)證、維護(hù)和傳輸、Log 服務(wù)器的行為審計(jì)以及局部范圍或者全球范圍內(nèi)資源證書撤銷狀態(tài)的監(jiān)測(cè)。

3.3.3 Log

在部署B(yǎng)T 機(jī)制的RPKI 體系中，Log 服務(wù)器作為一個(gè)獨(dú)立組件被引入，主要負(fù)責(zé)記錄CA 的簽發(fā)行為，需要在承諾時(shí)間范圍內(nèi)將CA 提交的Manifest發(fā)布至其中，供感興趣的相關(guān)參與方監(jiān)測(cè)資源證書的撤銷行為。根據(jù)數(shù)據(jù)流的方向，Log 服務(wù)器可以運(yùn)行在兩種模式下，分別為查詢下載模式和日志發(fā)布模式，此外，Log 服務(wù)器也可以部署Monitor 功能，以提供資源證書撤銷狀態(tài)檢測(cè)服務(wù)。圖5所示為L(zhǎng)og服務(wù)器的功能示意圖，在不同運(yùn)行模式下，Log 服務(wù)器可具備不同類型和數(shù)量的功能模塊。

圖5 Log 服務(wù)器的功能模塊示意圖Fig.5 The function module of the BT-enabled Log server

? 查詢下載模式

在查詢下載模式下，Log 服務(wù)器需要對(duì)外提供查詢和下載兩項(xiàng)服務(wù)，分別響應(yīng)資源證書撤銷狀態(tài)的查詢請(qǐng)求，以及Manifest的單個(gè)或批量的下載請(qǐng)求。前者面向未部署Manifest 驗(yàn)證功能的CA，換言之，CA 向Log 服務(wù)器發(fā)起自持有資源證書撤銷狀態(tài)的查詢請(qǐng)求，并完全信任由Log 服務(wù)器返回的撤銷狀態(tài)響應(yīng)結(jié)果。后者面向具備驗(yàn)證Manifest 能力的CA或者第三方Monitor，根據(jù)Manifest 下載請(qǐng)求，返回一個(gè)或者多個(gè)Manifest，供其自行檢測(cè)資源證書的撤銷狀態(tài)。

?日志發(fā)布模式

在日志發(fā)布模式下，Log 服務(wù)器接收CA 提交的Manifest 并在承諾時(shí)間范圍內(nèi)將Manifest 發(fā)布至其中，以此記錄CA 的歷史簽發(fā)行為。另外，Log 服務(wù)器也可以提供一個(gè)申訴接口，允許下級(jí)CA 提交關(guān)于撤銷資源的爭(zhēng)議信息和合法持有證據(jù)，并對(duì)外提供“展示界面”，供相關(guān)參與方根據(jù)本地策略做出信任決策。需要說明的是，Log 服務(wù)器可以選擇關(guān)閉日志發(fā)布模式，即關(guān)閉發(fā)布接口和展示接口，不再接受Manifest 的后續(xù)發(fā)布和爭(zhēng)議信息的展示，僅對(duì)外提供歷史Manifest 的查詢和下載服務(wù)。

? Monitor 模式

當(dāng)Monitor 功能由CA 部署時(shí)，CA 需要持續(xù)不斷地向Log 服務(wù)器發(fā)起查詢請(qǐng)求，才能及時(shí)地感知自持有資源證書的撤銷狀態(tài)。隨著全球范圍內(nèi)CA數(shù)量的不斷攀升，查詢請(qǐng)求頻率的不斷提高，Log服務(wù)器的處理響應(yīng)能力面臨性能擴(kuò)展性這一挑戰(zhàn)。當(dāng)RP 部署Monitor 功能時(shí)，Manifest 的更新才會(huì)觸發(fā)RP 的檢測(cè)服務(wù)，然而，RPKI 數(shù)據(jù)對(duì)象的同步是周期性執(zhí)行，RP 存在一定的“視野局限性”。換言之，在RP 相鄰兩次同步操作之間，CA 可能已經(jīng)將被撤銷的資源證書重新發(fā)布至RPKI 資料庫(kù)，導(dǎo)致作為Monitor 的RP 無法感知這一撤銷行為的發(fā)生。因此，作為Manifest 的“匯聚地”，Log 服務(wù)器在檢測(cè)資源證書撤銷行為上具有天然的優(yōu)勢(shì)，通過對(duì)比一個(gè)CA 的相鄰兩個(gè)版本Manifest 即可感知該CA 在一段時(shí)間范圍內(nèi)撤銷的資源證書。然而，Log 服務(wù)器同樣存在一定的“視野局限性”，即無法檢測(cè)未向其提交Manifest 的CA 的資源證書撤銷行為。幸運(yùn)地是，RP 可以感知CA 的Manifest 異常注冊(cè)行為，并及時(shí)向相關(guān)參與方發(fā)起警報(bào)信息。于是，兩者能夠各司其職、分工協(xié)作、協(xié)同配合共同完成對(duì)所有CA 的資源證書撤銷行為的全面檢測(cè)。

3.4 部署方案

BT 機(jī)制的部署引入了三種具備不同功能屬性的角色，不同角色可由RPKI 體系中原有實(shí)體或者獨(dú)立實(shí)體擔(dān)任，根據(jù)不同角色的部署實(shí)體，本節(jié)介紹了BT 機(jī)制的五種部署方案，并詳細(xì)說明了每種部署方案的適用范圍。

3.4.1 私有RP 場(chǎng)景下的部署方案

在私有RP 場(chǎng)景下，RP 天然地與其服務(wù)范圍內(nèi)的CA 建立了帶內(nèi)信任關(guān)系，因此，除了為這些CA提供RPKI 認(rèn)證信息的處理服務(wù)之外，還能夠同時(shí)提供資源證書的撤銷狀態(tài)檢測(cè)服務(wù)。在這種情況下，CA 需要提前向RP 注冊(cè)其自身及其上級(jí)CA 的身份信息，實(shí)現(xiàn)資源證書撤銷檢測(cè)服務(wù)的訂閱，因此，RP 的檢測(cè)范圍僅覆蓋CA 訂閱用戶的上級(jí)CA 的資源證書撤銷行為。由于CA 與RP 具備帶內(nèi)信任關(guān)系，CA 沒有必要獨(dú)立地審計(jì)Log 服務(wù)器的行為正確性，因此，Auditor 角色一般由RP 擔(dān)任，實(shí)現(xiàn)Manifest存在性的批量檢查，CA 處于“CA 運(yùn)行模式”下，負(fù)責(zé)將最新版本的Manifest 發(fā)布至發(fā)布點(diǎn)的同時(shí)提交至Log 服務(wù)器。

因此，根據(jù)Monitor 功能的部署實(shí)體，私有RP場(chǎng)景下BT 機(jī)制的部署方案可進(jìn)一步分為兩大類：（1）RP 部署Monitor 功能（部署方案一）；（2）Log服務(wù)器部署Monitor 功能（部署方案二）。在部署方案一中，RP 通過部署Monitor 功能集中地、定期地檢測(cè)已注冊(cè)在籍的CA 訂閱用戶的上級(jí)CA 的證書撤銷行為，RP 處于“RP-Auditor-Monitor 運(yùn)行模式”下，即除了負(fù)責(zé)RPKI 數(shù)據(jù)對(duì)象的同步、下載和傳輸之外，還負(fù)責(zé)監(jiān)測(cè)服務(wù)范圍內(nèi)CA 訂閱用戶的資源證書撤銷狀態(tài)，以及審計(jì)Log 服務(wù)器的行為正確性。Log 服務(wù)器處于“查詢下載模式”和“日志發(fā)布模式”下，提供Manifest 數(shù)據(jù)對(duì)象的注冊(cè)發(fā)布服務(wù)、存在性響應(yīng)服務(wù)和批量下載服務(wù)。在部署方案二中，Log服務(wù)器擔(dān)任Monitor 的角色，負(fù)責(zé)對(duì)外提供資源證書撤銷檢測(cè)服務(wù)。相對(duì)于部署Monitor 功能的RP 而言，由于存儲(chǔ)了Manifest 的歷史數(shù)據(jù)，Log 服務(wù)器提供的資源證書撤銷檢測(cè)服務(wù)更加全面和精確。此時(shí)，RP 處于“RP-Auditor 運(yùn)行模式”下，仍然作為CA 訂閱用戶的代理，負(fù)責(zé)向Log 服務(wù)器查詢資源證書的撤銷狀態(tài)。另外，對(duì)于未及時(shí)向Log 服務(wù)器注冊(cè)Manifest 的CA，由RP 負(fù)責(zé)檢測(cè)并反饋Manifest注冊(cè)異常信息。

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

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

3.4.2 公有RP 場(chǎng)景下的部署方案

在公有RP 場(chǎng)景下，RP 與CA 不具備天然的信任關(guān)系，因此，CA 根據(jù)本地策略決定是否信任公有RP。在這種情形下，CA 一般自行擔(dān)任Auditor 角色，獨(dú)立地審計(jì)Log 服務(wù)器的行為正確性。根據(jù)CA 對(duì)于RP 的信任程度，公有RP 場(chǎng)景下BT 機(jī)制的部署方案進(jìn)一步分為三大類，即零信任部署方案（部署方案三）、部分信任部署方案（部署方案四）和信任部署方案（部署方案五）。需要說明的是，CA 可以選擇完全信任公有RP，該部署方案與私有RP 場(chǎng)景下的部署方案一相同，本文不再贅述。

在零信任部署方案中，CA 處于“CA-Auditor-Monitor 運(yùn)行模式”下，CA 自行向Log 服務(wù)器下載其上級(jí)CA 的Manifest，以驗(yàn)證資源證書的撤銷狀態(tài)。在這種情形下，由于CA 聚焦于自持有資源證書，因此，Log 服務(wù)器將面臨來自大量CA 用戶和RP 系統(tǒng)的下載請(qǐng)求，對(duì)Log 服務(wù)器的服務(wù)能力提出了性能挑戰(zhàn)。

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

在部分信任部署方案中，CA 負(fù)責(zé)審計(jì)Log 服務(wù)器的行為正確性，并且信任由Log 服務(wù)器提供的資源證書撤銷檢測(cè)服務(wù)，處于“CA-Auditor 運(yùn)行模式”下。然而，在這種情形下，Log 服務(wù)器無法（準(zhǔn)確）檢測(cè)未向其注冊(cè)（最新版本）Manifest 的CA 的資源證書撤銷行為。需要說明的是，RP 具備感知CA 未及時(shí)注冊(cè)Manifest 這一異常行為的能力，負(fù)責(zé)將這一警報(bào)信息發(fā)送至Log 服務(wù)器，因此，兩者協(xié)作配合可以實(shí)現(xiàn)全面的資源證書撤銷檢測(cè)服務(wù)。當(dāng)CA查詢自持有資源證書的撤銷狀態(tài)時(shí)，如果上級(jí)CA并未將（最新版本）Manifest 注冊(cè)于其中，Log 服務(wù)器可以根據(jù)RP 提供的警報(bào)信息判定上級(jí)CA 的異常Manifest 注冊(cè)行為，并將這一信息反饋至CA 查詢用戶，于是，CA 可根據(jù)本地策略采取進(jìn)一步措施。

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

在信任部署方案中，RP 可由業(yè)界大型ISP、內(nèi)容提供商等具備公信力的第三方實(shí)體部署，因此，CA 可基于其商業(yè)名氣、服務(wù)能力以及技術(shù)儲(chǔ)備等因素與之建立信任關(guān)系。于是，RP 可基于這一信任關(guān)系同時(shí)部署Monitor 功能負(fù)責(zé)其服務(wù)范圍內(nèi)CA 訂閱用戶的資源證書撤銷狀態(tài)檢測(cè)，處于“RP-Monitor運(yùn)行模式”下。此時(shí)，CA 處于“CA-Auditor 運(yùn)行模式”下，仍然自行負(fù)責(zé)審計(jì)Log 服務(wù)器的行為正確性。

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

3.5 協(xié)議擴(kuò)展

BT 機(jī)制的部署在現(xiàn)有RPKI 系統(tǒng)中引入了新的組件，CA/RP 與組件之間以及組件與組件之間需要互通信息，涉及日志及其操作信息的共享和多種交互操作的執(zhí)行。因此，選擇何種協(xié)議作為新增組件之間，以及新增組件與CA/RP 之間的通信規(guī)范是亟需解決的一個(gè)問題。

設(shè)計(jì)一個(gè)全新的協(xié)議需要考慮多方面的因素，包括正確性、完整性和安全性等，協(xié)議的研發(fā)和測(cè)試往往涉及多個(gè)迭代周期。另外，協(xié)議的標(biāo)準(zhǔn)化進(jìn)程推進(jìn)緩慢，部分原因在于標(biāo)準(zhǔn)化組織的硬性規(guī)定以及相關(guān)流程的繁瑣復(fù)雜。除此之外，協(xié)議的部署過程也并非一蹴而就，相關(guān)參與方的部署意愿決定了這一過程的耗時(shí)長(zhǎng)短。因此，在BT 機(jī)制的部署初期，可采用一種通用的協(xié)議（例如HTTP 協(xié)議）作為過渡方案，實(shí)現(xiàn)相關(guān)參與方之間的信息交互和共享。

隨著BT 機(jī)制的廣泛部署，上述三種角色可能分別由不同類型的獨(dú)立實(shí)體擔(dān)任，實(shí)現(xiàn)精細(xì)分工和各司其職，各個(gè)實(shí)體之間的交互方式和通信內(nèi)容也隨之發(fā)生改變，需要由定制化的協(xié)議支撐特定的數(shù)據(jù)格式和操作流程。因此，在基于通用協(xié)議作為過渡方案的過程中，工業(yè)界也可同時(shí)推進(jìn)定制化協(xié)議的標(biāo)準(zhǔn)化進(jìn)程，并根據(jù)部署過程中遇到的問題及時(shí)反饋并完善協(xié)議內(nèi)容，為BT 機(jī)制的大規(guī)模部署做好充足的技術(shù)儲(chǔ)備。

3.6 安全考量

BT 機(jī)制是一套旨在檢測(cè)、阻止和糾正資源證書惡意撤銷行為的機(jī)制，其中，BT 機(jī)制的Manifest 一致性政策，要求RP 檢查每一個(gè)CA 發(fā)布于RPKI 資料庫(kù)和Log 服務(wù)器的Manifest 是否滿足存在一致性和內(nèi)容一致性兩項(xiàng)要求。上述要求使得CA 必須及時(shí)地將反映其一段時(shí)間范圍內(nèi)簽發(fā)行為的“快照文件”——Manifest 發(fā)布至Log 服務(wù)器中，否則直接影響其發(fā)布點(diǎn)中數(shù)據(jù)對(duì)象的同步下載。由此可知，Log 服務(wù)器的存在使得CA 的資源證書簽發(fā)行為更加透明化，在一定程度上遏制了CA 的惡意撤銷意圖。

此外，Monitor 負(fù)責(zé)實(shí)時(shí)地或者周期地檢測(cè)資源證書的撤銷狀態(tài)，Auditor 負(fù)責(zé)審計(jì)Log 服務(wù)器的行為正確性。然而，BT 機(jī)制中的組件也可能成為攻擊的目標(biāo)，另外，自身的配置錯(cuò)誤或者惡意操作均會(huì)影響B(tài)T 機(jī)制的安全性。本小節(jié)分析了CA、RP 和Log 服務(wù)器三種實(shí)體，以及三者部署Monitor 和/或Auditor 功能時(shí)可能發(fā)生的惡意操作，以及由此產(chǎn)生的安全風(fēng)險(xiǎn)，為此，提出了相應(yīng)的運(yùn)行建議和解決方案。

3.6.1 Log

Log 服務(wù)器并未在承諾時(shí)間范圍內(nèi)發(fā)布CA 提交的（最新版本）Manifest，在這種情況下，當(dāng)RP向Log 服務(wù)器請(qǐng)求該CA 的Manifest 時(shí)，無法獲取Manifest（不存在響應(yīng)）或者同步舊版Manifest（錯(cuò)誤的撤銷狀態(tài)結(jié)果），因此，RP 認(rèn)為該CA 存在異常Manifest 注冊(cè)行為，并拒絕由其簽發(fā)的所有RPKI 數(shù)據(jù)對(duì)象。

為了應(yīng)對(duì)這一安全風(fēng)險(xiǎn)，RP 應(yīng)該及時(shí)向其他多個(gè)Log 服務(wù)器提交這一警告信息，并向相關(guān)CA 反饋Manifest 的注冊(cè)異常，相關(guān)CA 用戶可以根據(jù)Log服務(wù)器中的Manifest 集合，以及RP 反饋的異常信息判斷Log 服務(wù)器的行為正確性。除此之外，其他RP和Log 服務(wù)器也可以判斷該異常Manifest 注冊(cè)事件的責(zé)任方到底是CA 用戶（延遲提交），還是Log 服務(wù)器（惡意操作）。另外，BT 生態(tài)系統(tǒng)可通過部署多個(gè)Log 服務(wù)器并要求一個(gè)CA 至少向兩個(gè)Log 服務(wù)器發(fā)布其新版Manifest，避免形成單點(diǎn)依賴，相應(yīng)地，RP 可以選擇與多個(gè)Log 服務(wù)器建立信任關(guān)系，實(shí)現(xiàn)檢測(cè)結(jié)果的冗余性驗(yàn)證。

3.6.2 RP

當(dāng)發(fā)現(xiàn)一個(gè)CA 在RPKI 資料庫(kù)與Log 服務(wù)器中發(fā)布的Manifest 存在不一致時(shí)，RP 應(yīng)該拒絕信任該CA 簽發(fā)的所有數(shù)據(jù)對(duì)象。然而，惡意RP 可能仍然繼續(xù)使用這些數(shù)據(jù)對(duì)象，且并不公布和反饋這一異常信息。于是，該CA 的資源證書撤銷行為被隱藏，相關(guān)下級(jí)CA 無法準(zhǔn)確感知自持有資源證書的撤銷狀態(tài)，另外，該RP 服務(wù)范圍內(nèi)的BGP 路由器無法獲取完整的真實(shí)的資源授權(quán)關(guān)系信息，即被撤銷資源證書的下級(jí)CA 簽發(fā)的所有認(rèn)證信息將無法用于判定路由消息的合法性。

然而，由于RP 系統(tǒng)的分布式特性，難以實(shí)現(xiàn)全球范圍內(nèi)所有RP 結(jié)盟以協(xié)助某一CA 隱瞞資源證書惡意撤銷行為。因此，當(dāng)其他RP 感知這一撤銷行為并及時(shí)提交至相關(guān)Log 服務(wù)器時(shí)，被撤銷資源證書的下級(jí)CA仍然具備感知上級(jí)CA撤銷行為的渠道。另外，涉嫌故意隱瞞信息的RP 的信譽(yù)值也因此受到影響，網(wǎng)絡(luò)運(yùn)營(yíng)商和CA 可以選擇不再信任該RP 并拒絕使用其服務(wù)。

3.6.3 CA

CA 可能以極高頻率惡意地向Log 服務(wù)器持續(xù)不斷地發(fā)布Manifest，目的在于耗盡Log 服務(wù)器的資源，使得其無法正常地提供服務(wù)，甚至導(dǎo)致其系統(tǒng)崩潰。在這種情況下，Log 服務(wù)器可以從兩個(gè)方面應(yīng)對(duì)上述安全風(fēng)險(xiǎn)，首先，Log 服務(wù)器可以對(duì)Manifest的內(nèi)容進(jìn)行校驗(yàn)，如果后續(xù)提交的Manifest 與已注冊(cè)的Manifest 的內(nèi)容完全一樣，則不再接受Manifest的重復(fù)注冊(cè)；其次，Log 服務(wù)器可以對(duì)Manifest 提交者的身份信息進(jìn)行認(rèn)證，要求在提交Manifest 的同時(shí)提交身份信息（例如RTA[19]），當(dāng)DDoS 攻擊發(fā)生時(shí)可作為依據(jù)對(duì)相關(guān)參與者進(jìn)一步追責(zé)。

3.6.4 Monitor

BT 機(jī)制支持Monitor 功能的多樣化部署。考慮到部署Monitor 功能的CA 旨在檢測(cè)自持有資源證書的撤銷狀態(tài)，在這種情況下，CA 不具備自我欺騙的動(dòng)機(jī)。當(dāng)RP 或者Log 服務(wù)器作為Monitor 提供資源證書撤銷檢測(cè)服務(wù)時(shí)，兩者均可能向CA 訂閱/查詢用戶返回錯(cuò)誤的Manifest 或者撤銷狀態(tài)響應(yīng)結(jié)果。因此，CA 需要綜合多方因素評(píng)估RP 或者Log 服務(wù)器的可信任度，謹(jǐn)慎決定是否與之建立信任關(guān)系，并授權(quán)委托自持有資源證書的撤銷檢測(cè)服務(wù)。當(dāng)發(fā)現(xiàn)RP 或Log 服務(wù)器存在故意隱瞞或者偽造撤銷狀態(tài)響應(yīng)結(jié)果的惡意行為時(shí)，應(yīng)該立即終止與之建立的服務(wù)關(guān)系。

3.6.5 Auditor

在BT 機(jī)制中，Auditor 角色一般由CA 和RP擔(dān)任。類似地，考慮到部署Auditor 功能的CA 旨在檢測(cè)自簽發(fā)的Manifest 是否及時(shí)地被發(fā)布至Log 服務(wù)器中，因此，該CA 不具備自我欺騙的動(dòng)機(jī)。事實(shí)上，BT 機(jī)制針對(duì)RP 提出的Manifest 一致性檢測(cè)要求，決定了RP 是Auditor 功能部署的最佳平臺(tái)。一般地，私有RP 作為代理負(fù)責(zé)其服務(wù)范圍內(nèi)CA 訂閱用戶的Manifest 存在性檢測(cè)。在這種情況下，私有RP 與CA 在同一管理域內(nèi)，兩者的利益一致且具備天然的信任關(guān)系，私有RP 同樣不具備欺騙CA 訂閱用戶的動(dòng)機(jī)。如果某一私有RP 仍然向CA 訂閱用戶隱瞞Log 服務(wù)器的異常注冊(cè)行為，由于RP 的分布式特性，CA 訂閱用戶仍然具備感知Log 服務(wù)器異常操作的其他渠道。

4 實(shí)驗(yàn)與分析

4.1 實(shí)驗(yàn)環(huán)境參數(shù)

本實(shí)驗(yàn)涉及三種實(shí)體，分別為CA、RP 和Log服務(wù)器，各個(gè)實(shí)體的硬件平臺(tái)和軟件實(shí)現(xiàn)相關(guān)參數(shù)說明如表2所示。

表2 實(shí)驗(yàn)環(huán)境參數(shù)說明Table 2 Experimental environment parameters

4.2 實(shí)驗(yàn)方案設(shè)計(jì)

4.2.1 拓?fù)潢P(guān)系

本實(shí)驗(yàn)系統(tǒng)實(shí)現(xiàn)了私有RP 場(chǎng)景下的部署方案一，即RP 部署Monitor 和Auditor 兩個(gè)功能模塊，為局部范圍內(nèi)的CA 訂閱用戶提供資源證書撤銷狀態(tài)檢測(cè)服務(wù)，實(shí)驗(yàn)拓?fù)淙鐖D11所示，其中，Log 服務(wù)器部署在騰訊云上，CA 和RP 部署在科技云上。

圖1 RPKI 體系結(jié)構(gòu)Fig.1 RPKI architecture

圖11 實(shí)驗(yàn)拓?fù)涫疽鈭DFig.11 Experimental topology diagram

4.2.2 具體實(shí)現(xiàn)

具體而言，CA 側(cè)基于Krill 軟件和Docker 容器[22]實(shí)現(xiàn)了CA 實(shí)例的層級(jí)式認(rèn)證部署。首先，所有具備父子關(guān)系的CA 對(duì)基于RPKI 生產(chǎn)服務(wù)帶外設(shè)置協(xié)議[23]完成身份關(guān)系的建立，其次，基于資源證書發(fā)放協(xié)議[24]完成資源證書的申請(qǐng)和簽發(fā)，另外，父CA 負(fù)責(zé)維護(hù)所有子CA 的資源證書。CA 側(cè)的部署信息如表3所示，第一層（level-1）CA 為實(shí)驗(yàn)環(huán)境中RPKI 體系的本地信任錨點(diǎn)且數(shù)量為1；第二層（level-2）CA 為信任錨點(diǎn)的孩子節(jié)點(diǎn)且總數(shù)量為10，其資源證書由信任錨點(diǎn)簽發(fā)且每一個(gè)level-2 CA持有1 張資源證書；第三層（level-3）CA 為level-2 CA 的孩子節(jié)點(diǎn)且總數(shù)量為100，每一個(gè)level-2 CA與10 個(gè)level-3 CA 建立父子關(guān)系并為其簽發(fā)10 張資源證書?？紤]到level-2 CA 的資源證書簽發(fā)負(fù)擔(dān)較重，本實(shí)驗(yàn)為其分配了兩個(gè)核，其他類型的CA均運(yùn)行在一個(gè)核上。

表3 實(shí)驗(yàn)方案中CA 側(cè)的認(rèn)證結(jié)構(gòu)Table 3 The certification structure of CAs in the experimental scheme

本實(shí)驗(yàn)部署了一個(gè)RP 實(shí)例，并基于Routinator軟件和Docker 容器實(shí)現(xiàn)，配置level-1 CA 的資源證書作為信任錨點(diǎn)，并與CA 側(cè)部署在同一臺(tái)服務(wù)器上。CA 基于HTTP 協(xié)議向RP 訂閱資源證書撤銷狀態(tài)檢測(cè)服務(wù)，RP 在本地構(gòu)建了一個(gè)“父子證書對(duì)集合”，負(fù)責(zé)維護(hù)所有CA 訂閱用戶及其上級(jí)CA 的身份信息（資源證書）。當(dāng)同步RPKI 資料庫(kù)后發(fā)現(xiàn)“父子證書對(duì)集合”中父證書對(duì)應(yīng)的Manifest 存在更新時(shí)，RP首先檢查CA 訂閱用戶的資源證書（子證書）是否包含于更新Manifest 中，如果存在，RP 停止檢測(cè)，否則，RP 向Log 服務(wù)器查詢?cè)摳翸anifest 的存在一致性和內(nèi)容一致性。本實(shí)驗(yàn)部署了一個(gè)Log 服務(wù)器實(shí)例，CA 和Log 服務(wù)器，以及RP 和Log 服務(wù)器之間的交互均基于HTTP 協(xié)議。前一個(gè)過程實(shí)現(xiàn)Manifest的發(fā)布，任何一個(gè)CA 的任何一次Manifest 更新均需發(fā)布至Log 服務(wù)器；后一個(gè)過程實(shí)現(xiàn)Manifest 存在性結(jié)果的請(qǐng)求和響應(yīng)，RP 向Log 服務(wù)器發(fā)送需要查詢的Manifest 或Manifest 的哈希值，并接收來自Log 服務(wù)器的存在性響應(yīng)結(jié)果。

4.2.3 測(cè)試方案

本實(shí)驗(yàn)從準(zhǔn)確率和效率兩個(gè)方面測(cè)試驗(yàn)證了RP提供的資源證書撤銷狀態(tài)檢測(cè)服務(wù)的性能。其中，準(zhǔn)確率指該服務(wù)檢測(cè)出的資源證書撤銷行為相對(duì)于實(shí)際發(fā)生的資源證書撤銷行為的占比；效率指檢測(cè)出的資源證書撤銷行為的數(shù)量與檢測(cè)所用總時(shí)長(zhǎng)的比值。針對(duì)準(zhǔn)確率的測(cè)量，本方案通過執(zhí)行腳本的方式在CA 側(cè)隨機(jī)撤銷10、100 和1 000 個(gè)由level-2 CA 簽發(fā)的資源證書，在此之前，保證被撤銷資源證書的CA 已向RP 訂閱資源證書撤銷狀態(tài)檢測(cè)服務(wù)，最后，統(tǒng)計(jì)RP 檢測(cè)出的被撤銷資源證書的數(shù)量。針對(duì)效率的測(cè)量，本方案通過設(shè)置不同CA 訂閱用戶的數(shù)量，統(tǒng)計(jì)了檢測(cè)所有CA 訂閱用戶的資源證書撤銷狀態(tài)的總時(shí)長(zhǎng)。

當(dāng)Log 服務(wù)器存儲(chǔ)Manifest 原始數(shù)據(jù)時(shí)可快速響應(yīng)來自RP 的存在性請(qǐng)求，如圖12中藍(lán)線所示。然而，考慮到未來RPKI 部署場(chǎng)景下CA 訂閱用戶的數(shù)量，以及上級(jí)CA 的Manifest 更新頻率持續(xù)增加等因素，均會(huì)加重Log 服務(wù)器的維護(hù)和存儲(chǔ)負(fù)擔(dān)。因此，本實(shí)驗(yàn)設(shè)計(jì)了兩組對(duì)比方案，每一組對(duì)比方案包含以下兩種實(shí)現(xiàn)方式：（1）RP 向Log 服務(wù)器發(fā)送Manifest 原始數(shù)據(jù)；（2）RP 向Log 服務(wù)器發(fā)送Manifest 的哈希值。需要說明的是，針對(duì)第一種實(shí)現(xiàn)方式，Log 服務(wù)器存儲(chǔ)Manifest 原始數(shù)據(jù)，針對(duì)第二種實(shí)現(xiàn)方式，Log 服務(wù)器基于HashMap 數(shù)據(jù)結(jié)構(gòu)維護(hù)Manifest 的哈希值。

第一組對(duì)比方案測(cè)試RP 的資源證書撤銷狀態(tài)檢測(cè)服務(wù)的效率，通過梯度增加CA 訂閱用戶的數(shù)量，統(tǒng)計(jì)對(duì)比了兩種實(shí)現(xiàn)方式下RP 檢測(cè)資源證書撤銷狀態(tài)的總時(shí)長(zhǎng)。第二組對(duì)比方案測(cè)試RP 與Log 服務(wù)器之間的查詢開銷，通過增加被撤銷資源證書的數(shù)量，統(tǒng)計(jì)對(duì)比了兩種實(shí)現(xiàn)方式下RP 與Log 服務(wù)器之間的傳輸負(fù)載。

4.3 實(shí)驗(yàn)結(jié)果分析

4.3.1 準(zhǔn)確率

針對(duì)一個(gè)CA 訂閱用戶而言，當(dāng)RP 感知其上級(jí)CA 的Manifest 發(fā)生更新后，通過檢查CA 訂閱用戶的資源證書是否在該更新Manifest 中即可檢測(cè)其撤銷狀態(tài)。當(dāng)資源證書撤銷行為確認(rèn)發(fā)生后，RP 無需向Log 服務(wù)器發(fā)起Manifest 存在性請(qǐng)求。因此，Log服務(wù)器中Manifest 的存儲(chǔ)形式并不影響資源證書撤銷狀態(tài)檢測(cè)服務(wù)的準(zhǔn)確率。另外，本實(shí)驗(yàn)分別將被撤銷資源證書的數(shù)量設(shè)置為10、100 和1 000，并分別統(tǒng)計(jì)了三種情形下RP 的資源證書撤銷狀態(tài)檢測(cè)服務(wù)的準(zhǔn)確率，均能達(dá)到100%。

4.3.2 效率

針對(duì)資源證書撤銷狀態(tài)檢測(cè)服務(wù)的效率測(cè)量，本實(shí)驗(yàn)將CA 訂閱用戶的數(shù)量設(shè)置為200、400、600、800 和1000，并分別統(tǒng)計(jì)了基于Manifest 和基于Manifest 哈希值兩種實(shí)現(xiàn)方式下，檢測(cè)所有CA訂閱用戶的資源證書撤銷狀態(tài)的總時(shí)長(zhǎng)，具體信息如圖12所示。

圖12 兩種實(shí)現(xiàn)方式下資源證書未被撤銷和被撤銷情形下RP 的檢測(cè)總時(shí)長(zhǎng)Fig.12 The total detection time of RP under different revocation situations of resource certificate in two implementations

其中，藍(lán)線和紅線分別表示CA 訂閱用戶的資源證書全部被撤銷情況下基于Manifest 和基于Manifest 哈希值實(shí)現(xiàn)方式下，RP 的檢測(cè)總時(shí)長(zhǎng)；綠線表示CA 訂閱用戶的資源證書全部未被撤銷情況下基于兩種實(shí)現(xiàn)方式下，RP 的檢測(cè)總時(shí)長(zhǎng)。根據(jù)圖12可知，在資源證書撤銷發(fā)生的情況下，基于Manifest的實(shí)現(xiàn)方式在檢測(cè)時(shí)長(zhǎng)上略勝一籌，原因在于基于Manifest 哈希值實(shí)現(xiàn)方式下哈希計(jì)算的時(shí)間開銷，以及哈希沖突導(dǎo)致的查詢開銷。另外，在資源證書撤銷并未發(fā)生的情況下，基于兩種實(shí)現(xiàn)方式所需要的時(shí)間完全一致，原因在于當(dāng)RP 檢測(cè)到CA 訂閱用戶的資源證書存在于其上級(jí)CA 的Manifest 后，并不再向Log 服務(wù)器發(fā)送查詢請(qǐng)求。由此可知，當(dāng)資源證書撤銷行為的數(shù)量較少時(shí)，BT 機(jī)制引入的額外查詢開銷可忽略不計(jì)。

由于RP 軟件同步下載和本地驗(yàn)證 RPKI 數(shù)據(jù)對(duì)象需要一定的時(shí)間，本實(shí)驗(yàn)以十分鐘為單位，持續(xù)統(tǒng)計(jì)了兩個(gè)星期時(shí)間范圍內(nèi)資源證書的撤銷情況，發(fā)現(xiàn)這一數(shù)量為個(gè)位數(shù)，平均值為6 張。截止目前，30%左右的 IP 地址空間納入RPKI 認(rèn)證體系，并且，資源證書的簽發(fā)數(shù)量大約為27,000 張。由于資源證書的總數(shù)量不僅取決于資源持有者的數(shù)量，也取決于資源證書中IP 前綴的分布情況，因此，我們可以簡(jiǎn)單地評(píng)估，在未來RPKI 部署場(chǎng)景下，資源證書的簽發(fā)數(shù)量大約為90,000 張，并且，每十分鐘資源證書的撤銷數(shù)量大約為20 張。根據(jù)上述實(shí)驗(yàn)數(shù)據(jù)和評(píng)估數(shù)據(jù)可知，BT 機(jī)制提供的資源證書撤銷狀態(tài)檢測(cè)服務(wù)能夠很好地滿足當(dāng)前RPKI 部署環(huán)境下和未來RPKI 部署環(huán)境下資源證書撤銷狀態(tài)的檢測(cè)需求。

4.3.3 傳輸開銷

隨著RPKI 部署進(jìn)程的持續(xù)推進(jìn)，CA 訂閱用戶數(shù)量的急劇增加，Manifest 更新頻率的逐漸加快，RP 將向Log 服務(wù)器發(fā)送大量的查詢請(qǐng)求，Log 服務(wù)器將面臨巨大的查詢壓力。根據(jù)圖13所示，藍(lán)線和紅線分別表示RP 查詢請(qǐng)求的兩種實(shí)現(xiàn)方式，即RP向Log 服務(wù)器發(fā)送Manifest 和Manifest 哈希值以檢測(cè)其存在性。由圖可知，基于Manifest 哈希值的實(shí)現(xiàn)方式在降低RP 與Log 服務(wù)器之間傳輸開銷上具有更為明顯的優(yōu)勢(shì)。

圖13 兩種實(shí)現(xiàn)方式下RP 與Log 服務(wù)器之間的查詢傳輸開銷Fig.13 The transmission overhead between the RP and the Log server in two implementations

5 結(jié)論與展望

本文針對(duì)RPKI 體系的層級(jí)式、集中化認(rèn)證結(jié)構(gòu)引入的單邊撤銷問題，以及由此導(dǎo)致的資源無效風(fēng)險(xiǎn)，提出了一種基于行為透明性的RPKI 撤銷檢測(cè)機(jī)制。這一想法主要受到了Google 公司于2012年提出的證書透明性方案的啟發(fā)，CT 機(jī)制通過部署Log 服務(wù)器以記錄CA 簽發(fā)的每一張證書，以此透明化CA 的證書簽發(fā)行為，從而實(shí)現(xiàn)偽造證書的及時(shí)檢測(cè)以及相關(guān)CA 的問責(zé)。CT 機(jī)制主要用于解決SSL/TLS PKI 系統(tǒng)中所有CA 具備相同簽發(fā)權(quán)力導(dǎo)致的證書偽造問題，然而，無法透明化證書的單邊撤銷行為。本文提出的BT 機(jī)制，通過設(shè)立Log 服務(wù)器并要求CA 將反映其簽發(fā)行為的Manifest 發(fā)布于其中，達(dá)到透明化CA 的資源證書撤銷行為的目的。Manifest 是一個(gè)CA 在某一個(gè)時(shí)間段內(nèi)簽發(fā)且認(rèn)可的所有數(shù)據(jù)對(duì)象的快照文件，于是，通過查看Manifest的具體內(nèi)容以及對(duì)比相鄰兩個(gè)版本的Manifest 可以有效檢測(cè)一張資源證書的撤銷狀態(tài)以及一個(gè)CA 在某一個(gè)時(shí)間段內(nèi)的所有資源證書撤銷行為。與其他解決方案相比，BT 機(jī)制的優(yōu)勢(shì)也較為顯著：（1）公開的、實(shí)時(shí)性、持續(xù)地的監(jiān)督和審計(jì)；（2）漸進(jìn)式、小規(guī)模部署也能取得較好效果；（3）對(duì)現(xiàn)有RPKI 基礎(chǔ)設(shè)施影響很小。

利益沖突聲明

所有作者聲明不存在利益沖突關(guān)系。