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

1.中國科學院計算機網(wǎng)絡信息中心,北京 100083

2.中國科學院大學，北京 100049

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

引言

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

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

1 相關(guān)工作

1.1 安全分析

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

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

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

1.2 解決方案

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

1.2.1 “演進型”解決方案

（1）基于CA 的解決方案

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

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

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

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

1.2.2 “革命型”解決方案

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

2 背景知識

2.1 證書透明性和默克爾樹

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

CT 機制引入了三種全新角色，分別為日志服務器（Log）、監(jiān)督者（Monitor）和審計者（Auditor）。在為某個域名持有者簽發(fā)服務器證書之后，CA 需要及時地將該證書發(fā)布至公開的Log 服務器中。Log服務器以默克爾樹（Merkle Tree）的形式存儲所有提交的證書，并保證Append-Only（只增不刪）特性。換言之，一旦Log 服務器接受了某張證書的注冊請求，該Log 服務器的屬性可以保證這一證書永遠不會被移除、修改或者追溯。Monitor 周期性地下載Log 服務器中的證書集合，并從中排查可疑證書。Auditor 的設立旨在審計Log 服務器的行為正確性，即是否在承諾時間范圍內(nèi)發(fā)布向其提交的證書。由此可知，CT 機制改變了證書的簽發(fā)流程，新流程規(guī)定：證書必須記錄到可公開驗證、不可篡改且只增不刪的Log 服務器中，終端用戶的Web 瀏覽器才會將其視為有效。CT 機制允許任何感興趣的相關(guān)參與方查看任一CA 簽發(fā)的任一證書，這一策略能夠促使CA 在簽發(fā)證書時更加謹慎和負責，從而有助于形成一個更可靠的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)碼號資源管理體系相吻合，頂級節(jié)點為五大 RIR，下級節(jié)點包括國家互聯(lián)網(wǎng)注冊機構(gòu)（National Internet Registry,NIR ）、本地互聯(lián)網(wǎng)注冊機構(gòu)（Local Internet Registry,LIR）、ISP 以及其他獨立的IP 地址持有機構(gòu)。每一個納入RPKI 認證體系的資源持有者均可視為PKI 意義層面上的CA，負責資源證書和ROA等數(shù)據(jù)對象的簽發(fā)，以此認證資源的分配和授權(quán)關(guān)系信息。每一個CA 負責維護一個邏輯上的發(fā)布點（Publication Point,PP），用于存儲由其簽發(fā)的所有數(shù)據(jù)對象，所有發(fā)布點共同構(gòu)成全球分布式RPKI 資料庫（Repository）[15]。

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

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

3 機制設計

3.1 威脅模型

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

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

3.2 技術(shù)原理

3.2.1 核心思想

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

3.2.2 新增角色

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

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

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

3.2.3 體系框架

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

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

3.3 運行模式

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

3.3.1 CA

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

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

? CA 運行模式

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

? CA-Auditor 運行模式

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

? CA-Monitor 運行模式

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

? CA-Auditor-Monitor 運行模式

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

3.3.2 RP

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

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

? RP 運行模式

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

? RP-Auditor 運行模式

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

? RP-Monitor 運行模式

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

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

? RP-Auditor-Monitor 運行模式

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

3.3.3 Log

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

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

? 查詢下載模式

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

?日志發(fā)布模式

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

? Monitor 模式

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

3.4 部署方案

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.5 協(xié)議擴展

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

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

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

3.6 安全考量

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

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

3.6.1 Log

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

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

3.6.2 RP

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

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

3.6.3 CA

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

3.6.4 Monitor

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

3.6.5 Auditor

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

4 實驗與分析

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

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

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

4.2 實驗方案設計

4.2.1 拓撲關(guān)系

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

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

圖11 實驗拓撲示意圖Fig.11 Experimental topology diagram

4.2.2 具體實現(xiàn)

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

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

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

4.2.3 測試方案

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

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

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

4.3 實驗結(jié)果分析

4.3.1 準確率

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

4.3.2 效率

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

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

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

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

4.3.3 傳輸開銷

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

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

5 結(jié)論與展望

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

利益沖突聲明

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