深度揭秘：如何正確識別證書實際控制機構
一、前言
在上次《撥開俄烏網絡戰迷霧-域名證書測繪篇》里，對俄烏雙方網站域名證書的存活情況和頒發機構分布情況變動研究中，發現難以從部分證書解析得到的頒發者名稱及機構中，正確識別其證書頒發機構（Certificate Authority, CA）。針對此類問題進行調研，發現一篇發表在USENIX 2021的論文工作[1]，如圖1所示。其作者提出基于CA對證書的操作行為特征進行聚類的Fides系統，能夠檢測實際控制數字證書的CA（即證書運營商），并建立了一個新的證書運營商數據庫[2]。所謂控制，就是對證書關聯的加密密鑰具有操作訪問權限，并能夠對由密鑰頒發的證書負責。
圖1 論文標題、作者信息
二、基本概念
2.1
公鑰基礎設施（PKI）
如圖2所示，公鑰基礎設施（Public Key Infrastructure, PKI）是創建、管理、分發、使用、存儲和撤銷數字證書以及管理公鑰加密所需的一組角色、策略、硬件、軟件和程序[3]。
圖2 公鑰基礎設施關鍵角色
2.2
證書頒發機構（CA）
其中，證書頒發機構是存儲、簽署和頒發數字證書的權威機構。這里CA分為兩種，能夠簽發根證書的根CA和簽發中間證書的下級CA（根證書和中間證書統稱CA證書，而直接簽發給訂閱者的為葉證書）。根CA也可以簽發中間證書。根CA和下級CA的主要區別在于，簽發的中間證書的實際控制權在哪兒。一般情況下，根證書簽發的中間證書控制權有三種情況，由相同的根CA控制所有、由根CA控制但法律上屬于下級CA、由下級CA控制所有。這里主要把第三種與前兩種進行區分。即，中間證書雖然可以繼承根證書的信任，但它不一定繼承和根證書相同的證書運營商。同時，下級CA可以對葉證書具有獨立的身份驗證和撤銷機制。
2.3
審計機構
第三方專業審計機構對CA運營情況進行審查，除了披露CA操作是否與其政策一致或偏離的情況外，還包括審核范圍內的證書列表。
2.4
用戶代理（瀏覽器）
通常情況下，每個驗證證書的用戶代理（如Web瀏覽器）都附帶一組受信根證書，作為Web PKI中的可信根。根CA很少使用根證書直接簽發葉證書，而是通過根證書簽發中間證書，再利用中間證書處理葉證書的日常簽發。因此根證書可以保持離線狀態，從而保護它們免受損害。不同的瀏覽器具有自己的根證書庫，同時對庫中包含的證書具有一定要求。例如，Mozilla要求根CA在Common CA Database (CCADB)[4]中公開披露不受約束的中間證書。
CCADB是一個由Mozilla運營的CA信息庫，其中存儲有關證書的元信息。它為CA證書運營商提供了一種自我披露證書、證書策略和審計的方法。CCADB被許多瀏覽器用來管理他們的根證書庫，以提高安全性、透明度和交互性。
2.5
訂閱者（網站）
訂閱者是使用葉證書的實體。葉證書被簽發給某個域名或IP，往往直接作用于某個網站，為網站用戶提供身份認證、加密通信等功能。
三、 研究動機
由前述概念介紹可知，通常情況下，證書的頒發機構，是實際控制證書的機構。但由于頒發者命名要求不嚴、機構所有權更改和證書生存期極長等原因，可能會導致證書解析的CA與實際控制機構不一致。這不僅會混淆訂閱者對可信CA的選擇，還會妨礙瀏覽器將證書問題正確地歸咎于某個CA。
3.1
瀏覽器基于CA判定是否信任證書
如圖 3 所示，由于在2009年至2017年期間賽門鐵克一再錯誤地頒發證書，2017年，Chrome、Mozilla、Apple和Microsoft瀏覽器宣布不信任賽門鐵克頒發的證書。不過，即使賽門鐵克的所有根證書都不受信任，也并非所有的中間證書都不受信任。Apple和Chrome運營著與賽門鐵克根證書相關聯的7個下級CA，它們由于獨立運營而被明確列入白名單。
圖3 賽門鐵克證書不受信事件
3.2
證書解析相似但實際運營商不同
如圖4所示，證書字段值雖然相似，但并沒有共享相同證書運營商。它們一個屬于DigiCert，一個屬于Sectigo。考慮探索實際控制證書的運營商前提下，重新構建已有研究工作，可能得到更準確的結果。
圖4 不同證書運營商的相似證書
四、 方法流程
4.1
Fides：揭示證書所有權的系統
Fides揭示CA證書所有權的基本假設是，來自同一個組織機構簽發的證書，在使用的證書生成軟件、證書驗證/撤銷相關網絡基礎設施、證書審計策略等方面，存在相似性。
因此，如圖5所示，Fides首先利用證書生成軟件、網絡基礎設施、審計細節來構建大量證書的指紋信息；其次通過對滿足條件的證書指紋信息進行聚類，檢測可能被同一個組織機構控制的證書；然后結合CCADB的標簽對聚類過程進行優化；最終構建了一個更準確地描述CA證書運營商的新數據集。
圖5 Fides系統處理流程
4.2
實驗數據集構建：CT+CCADB+SSPKI
數據集的初始來源是，在2020年7月1日前證書透明度（Certificate Transparent, CT）日志中，Chrome和Apple信任的2.9B個葉證書。CT旨在監控、審計、記錄由CA頒發的所有證書，從而有效識別錯誤或惡意頒發的證書[7]。通過對葉證書中的CA證書進行提取、過濾Google簽發的臨時CA證書、添加CCADB中揭露的CA證書、利用撤銷列表標記證書等處理步驟，最終得到了如圖 6 所示，包含2.9B個受信任葉證書和9,154個CA證書的數據集，其中具有6,549 個Subject+Subject Public Key Info (S+SPKI=SSPKI)對。
圖6 數據集概況
4.3
葉證書指紋生成：證書ASN.1結構
通過開發證書ASN.1指紋識別工具[5]，分析每個CA證書簽發的葉證書ASN.1結構，識別出證書結構一致的集群。如圖7所示，分析證書ASN.1結構時，無需提取葉證書的節點值。這使得生成的指紋，更關注由于不同證書生成軟件/配置導致的不同。
圖7 證書ASN.1結構指紋[6]
4.4
CA網絡基礎設施：AIA+CRL+OSCP
CA網絡基礎設施包括用于在線證書鏈構建的頒發機構信息訪問（Authority Information Access, AIA）CA頒發者，以及與證書撤銷相關的證書撤銷列表（Certificate Revocation List, CRL）和在線證書狀態協議（Online Certificate Status Protocol, OSCP）。該文從葉證書中共計提取了2,334個完全合格域名（Fully Qualified Domain Name， FQDN），包括991個OCSP、938個CRL和800個AIA頒發者域名。通過解析每個FQDN對應的IPv4地址，得到在309個AS自治系統中共計835個IPv4地址。如圖8所示，展示了FQDN和IP在CA證書中的分布，發現大約一半的FQDN僅與單個CA證書關聯，同時許多FQDN共享相同的底層IPv4地址。
圖8 證書關聯網絡基礎設施分布
4.5
CA審計：CCADB審計報告
通過下載CCADB中保留的所有從公共數據源收集的CA審計報告，對生成的1,266個PDF文件進行文本提取，利用開發的正則表達式獲取每個審計報告中的證書SHA-256指紋，用來關聯CA證書審計數據。
4.6
判定標準：滿足至少2個維度相似/相同
如圖9所示，只有通過至少兩個維度關聯的證書才被認為具有共同的CA證書運營商。應用此啟發式標準后，Fides生成320個集群類別，其中包含2,599個CA頒發者，集群規模從2到696個CA證書不等。
圖9 啟發式CA運營商集群生成流程[6]
4.7
效果評估：精度高，召回低
標注數據集。由于目前沒有CA證書運營商的公開標注數據集，因此很難直接評估Fides是否正確。通過搜集2014年5月至2019年7月期間，由瀏覽器根證書庫管理人員手動檢查發現的28個錯誤報告，把它們作為近似的標注數據集。
評估方法。首先提取與每個錯誤報告相關的CA證書和頒發者（SSPKI），并根據錯誤詳細信息手動確定CA所有權；然后通過查看Fides每個集群的證書指紋、網絡基礎設施和審計報告，手動標記包含錯誤報告CA證書的集群，為每個集群分配一個可能的CA運營商；最后將Fides的CA運營商與每個錯誤報告中披露的CA進行比較。
評估結果。如圖10所示，共計檢查了28個錯誤報告，涉及150個頒發者。Fides正確識別了150個頒發者中32%的運營商，并能正確標記3/28個錯誤報告中的所有頒發者。排除47個身份不明的頒發者，Fides能夠正確識別47%頒發者的運營商，并能正確標記7/22個錯誤報告中的所有頒發者。由于Fides中所有48個頒發者都出現在正確的集群中，Fides整體上具有較高的精度，但召回率較低，僅能標記不到一半的頒發者。
圖10 Fides評估結果
五、 實踐發現
本節利用Fides發現CCADB中具有錯誤或誤導性所有權數據的CA證書。如圖11所示，首先使用CCADB的所有權數據標記CA證書，其次對CA證書利用Fides進行聚類，然后當檢測到CCADB標簽與聚類標簽沖突、未標記CA證書屬于某個集群時，通過手動檢查審計報告和操作特征糾正不一致數據，最后構建一個更接近CA證書實際操作控制機構的數據集。
圖11 CA運營商數據集構建流程[6]
5.1
標記Fides節點：解決SSPKI所有權不一致
CCADB通過SHA-256指紋標識單個CA證書，Fides通過SSPKI標識頒發者。通過SSPKI對CCADB證書進行分組，發現39個頒發者（110個證書）映射到多個CCADB所有者。其中31個SSPKI包含被撤銷、過期或作為下級CA正確披露的證書；另外8個SSPKI（20個證書）的CCADB控制權模糊，單個密鑰似乎擁有多個CCADB所有者。之后通過檢查審計和證書主體進行人工識別，以解決此39個SSPKI所有權沖突（更正了64個證書）。通過發現有557個不在CCADB中的CA證書，與帶CCADB標簽的證書共享一個SSPKI，將CCADB標簽進行擴展，原理如圖12所示。
圖12 CCADB標簽擴展至Fides[6]
5.2
多運營商集群：白名單+未公開+筆誤+誤報
單個Fides集群中存在多個CCADB所有者，表明CCADB標簽（包括下級CA報告）與Fides自動推斷的CA證書控制之間可能存在不一致。如圖13所示，通過手動檢查這11個集群以確定不匹配的根本原因。其中2個是誤報，另外9個集群由581個證書的728個頒發者組成。通過解決下級CA白名單、未公開控制、筆誤、誤報問題，最后更正了125個頒發者和136個CA證書的標簽。
圖13 11個多運營商集群
5.3
少數未標記集群：節點標記個數占比大于70%
如圖14 所示，發現少數節點未標記的17個Fides集群，集群中絕大多數（超過70%）節點共享相同的CCADB所有者標簽。Fides總共標記了94個證書，涵蓋84個頒發者。由于這些新標記CA證書的審計數據和CCADB元數據不足，無法正確評估這些新標簽的準確性，并且可能存在一定誤報。為了減少這些可能性，選擇每個集群中未標記節點占比不高于30%的閾值。
圖14 17個未標記集群
5.4
CA運營商數據集：優化了6.2%的CA證書
如圖15所示，Fides生成了一個新的CA運營商數據集[2]，該數據集為來自85個頒發者的90個受信CA證書更正了CA運營商標簽，同時擴展了115個受信CA證書的覆蓋范圍，Fides共計改進或擴展了208個受信CA證書覆蓋范圍，占Microsoft、Apple或NSS信任的所有3,338個CA證書的6.2%。
圖15 CCADB vs. Fides
六、 推薦建議
Fides雖然可以發現CCADB證書所有權標簽和運營實踐的不一致，但它的啟發式方法并不完美，精度高而召回率低。為了真正解決CA證書控制權透明度的問題，該文提出以下推薦建議。
6.1
CCADB結構化數據：添加證書所有權顯式字段
由于CA證書控制更改的頻率超過了CA證書更換的頻率，當前的CA證書必須將其名稱（存儲在證書中）與其身份（存儲在證書之外）分開。CCADB是跟蹤誰控制每個CA根證書和中間證書的自然位置，為所有權詳細信息添加顯式字段將允許瀏覽器和研究人員更好地跟蹤CA行為。瀏覽器還可以執行更嚴格的CCADB策略，以幫助消除拒絕向CCADB提交詳細信息CA的信任依賴。
6.2
增加中間限制：瀏覽器要求包含證書所有權信息
瀏覽器可以要求中間CA證書包含最新的所有權詳細信息，類似擴展驗證證書的要求，并限制其所有權更改。同時還可以進一步限制中間證書的有效期，以抑制所有權轉移并減少證書控制變化的影響。
6.3
反思根CA標簽：暫時忽略證書Subject Name字段
考慮是否應該暫時忽略證書包含的信任錨主體名稱字段，就目前而言，根證書上的標簽對很大一部分CA具有誤導性，而瀏覽器提供的標簽可能可以提供更多最新的所有權細節（如從CCADB中提取）。
6.4
Fides未來發展：驗證審計文檔與外部測量結果一致性
Fides目前可以幫助識別用戶錯誤和可疑CA實踐，未來可以驗證CA文檔/審計聲明與外部可測量行為之間的一致性。比如，通過擴展Fides包括CA向訂閱者提供證書的IP地址，可以自動檢查CA文檔/審計中披露的操作位置準確性；進一步發展Fides證書指紋技術，以識別不同CA使用的CA軟件，從而更好地發現和修復證書頒發問題。
七、 總結
數字證書作為提供身份認證、加密通信、可信機制的網絡空間基礎資源十分重要。目前面向證書測繪的工作，往往通過直接解析證書，得到頒發者名稱及機構字段值來判定證書控制機構。但由于頒發者命名要求不嚴、機構所有權更改和證書生存期極長等原因，使得證書解析的CA與實際控制機構不一致。從而導致測繪結果不全或者不準確，影響分析結果。
本文介紹的這篇研究工作[1]，基于證書ASN.1結構指紋、網絡基礎設施、審計報告等特征構建的Fides系統，利用啟發式方法得到實際控制CA證書的運營商標簽，再結合CCADB和人工分析糾正的方式，構建了一個更準確的證書運營商數據集[2]，包含6,846個證書及其操作指紋、證書運營商標簽等。
后續面向證書測繪的研究工作，可以借鑒其思路及相關開源代碼工具和數據庫，在證書解析基礎上，進一步實現對CA字段的校準優化，有助于準確關聯機構，提高數據和分析的準確性。
參考文獻
[1] Ma Z, Mason J, Patel S, et al. What's in a Name? Exploring {CA} Certificate Control[C]//30th USENIX Security Symposium (USENIX Security 21). 2021: 4383-4400.
[2] https://github.com/zzma/ca-transparency
[3] https://en.wikipedia.org/wiki/Public_key_infrastructure
[4] https://www.ccadb.org/
[5] https://github.com/zzma/asn1-fingerprint
[6] https://www.usenix.org/conference/usenixsecurity21/presentation/ma
[7] https://en.wikipedia.org/wiki/Certificate_Transparency
往期回顧：
內容編輯：創新研究院 黃彩云
責任編輯：創新研究院 陳佛忠
本公眾號原創文章僅代表作者觀點，不代表綠盟科技立場。所有原創內容版權均屬綠盟科技研究通訊。未經授權，嚴禁任何媒體以及微信公眾號復制、轉載、摘編或以其他方式使用，轉載須注明來自綠盟科技研究通訊并附上本文鏈接。
