利用 Merkle Tree Certificates 打造後量子憑證授權機構

當你在瀏覽器中輸入網址時，如何確認連線的是正確的網站？Web 公開金鑰基礎架構（Web PKI）是由政策、協定及基礎架構營運商所組成的複雜分散式生態系統，協助你信任自己沒有被導向錯誤或惡意的網站。過去數十年來，這個生態系統歷經重大變革。其中之一是透明度的引入：目前已強制要求所有憑證記錄於公開的憑證透明度記錄中。如今它又面臨新的挑戰：量子電腦的到來已近在眼前，促使我們必須在 2029 年前完成向後量子（PQ）密碼學的升級。

這場轉型並不簡單：若僅是將後量子密碼學直接套用於網際網路規模的憑證，將造成無法接受的效能下降。此刻需要一套全新的 Web PKI 方案，將透明度作為核心屬性而非附加功能，並設計出能夠有效擴展後量子簽章的新系統。

在獲得業界廣泛支持後，Merkle Tree Certificates（MTC）已成為前進的方向。今年，在與 Chrome 完成成功的實驗性部署後，Cloudflare 正全力推進 MTC 的落地。

隨著今天 Cloudflare 宣布成為憑證授權機構 (CA)，我們很高興宣布該 CA 將支援 MTC 核發，目標是在 2027 年初納入 Chrome 新推出的抗量子根憑證庫。秉持協助打造更好網際網路的使命，以及 Cloudflare 一貫免費提供最強加密技術的傳統，我們將免費提供標準 MTC 核發服務。擁有同時支援傳統憑證與 MTC 核發的 CA，讓我們能夠預設採用最安全的身分驗證方式，為大部分的網際網路提供順暢且高效能的 PQ 升級途徑。

現行的信任生態系統

要瞭解 MTC 如何改變格局，先讓我們從今日網路信任機制的背景說起。

在用戶端，瀏覽器（在此語境中稱為「TLS 用戶端」）維護根憑證計畫，規定 CA 必須遵守的一套政策才能獲得信任。在伺服器端，CA 是受信任的把關者：它們營運憑證核發基礎架構，驗證網域擁有權，並證明網域名稱與能夠證明該網域擁有權的公開金鑰之間的綁定關係。

但我們如何確認 CA 確實遵守規則？這便引出了憑證透明度（CT）——讓憑證核發過程可以被公開稽核。CA 核發憑證時，還必須將該憑證提交至至少兩個公開記錄。Cloudflare 自 2016 年起營運 Nimbus CT 記錄系列，並正在推出新的靜態 CT 記錄系列 Raio。

CT 生態系統讓憑證可以被公開檢視，但這不代表憑證都已正確核發或可安全使用。監控透過比對記錄記錄與網域擁有者的預期並回報可疑活動來協助確認。Cloudflare 於 2019 年推出憑證透明度監控，並於近期正式上線。我們也在 Radar（前身為 Merkle Town）的憑證透明度頁面發布大規模憑證統計數據。

隨著各組織開始將伺服器升級為使用 PQ 身分驗證，憑證透明度監控在偵測潛在後量子降級攻擊上將扮演更重要的角色。已將網域升級至後量子身分驗證的網域擁有者，應監控 CT 記錄中意外核發的傳統憑證，以防止用戶端落入惡意降級路徑。

目前系統的部分問題在於透明度是後來追加的功能，因而衍生出擴展性瓶頸。憑證常以不同形式在多個記錄中重複記錄，要求監控方下載並處理每個記錄以免遺漏核發記錄。這代價高昂，使得在網際網路規模上鼓勵多元化記錄營運商更加困難。根據我們的估算，PQ 簽章將使 CT 記錄所需的儲存資料量膨脹 40 倍。這一擴展性挑戰及其背後的激勵機制失衡，正是後量子擴展性問題的核心。

後量子擴展性問題

我們已就後量子密碼學擴展的挑戰進行深入探討，簡言之：要在網際網路規模上支援伺服器身分驗證，Web PKI 必須在不向每個用戶端預先載入每台伺服器公開金鑰的情況下，對約十億台 TLS 伺服器進行身分驗證。傳統上，CA 透過憑證鏈作為信任分發機制來解決這個問題。然而隨著時間推移，金鑰撤銷檢查和憑證透明度等附加內容增加了更多公開金鑰與簽章——典型的 TLS 交握需要五個簽章與兩個金鑰。PQ 簽章約是傳統簽章的 40 倍大，在規模上對用戶端、CA、記錄和監控方而言將產生難以承受的額外負擔。

Merkle Tree Certificates (MTC) 由此登場。這是 IETF PLANTS 工作組的草案規範，描述了一種面向緊湊、高效、後量子憑證的架構。MTC 將憑證批量放入僅附加的 Merkle 樹，CA 只需對樹的根簽章而無需對大量個別憑證簽章。瀏覽器或其他用戶端可透過緊湊的包含證明（一系列密碼雜湊）對簽章樹頭進行驗證，而無需逐一驗證每張憑證。MTC 背後的核心理念是「不要記錄你核發的內容，而是透過記錄來核發」。將核發與記錄相結合，透明度便成為營運的必要條件而非附加功能。

重新設計的 PKI 中，憑證授權機構的角色

我們正將 MTC 核發能力的建立作為創設 Cloudflare CA 的核心組成部分。這意味著在追蹤新的 PQ 根憑證計畫要求的同時，還要在建置傳統 CA 的設施、營運及合規功能的同時，開發核發與鏡像軟體堆疊，任務繁重，不可小覷！

好處在於，我們可以從第一天起便優先考量這一新後量子 PKI 的需求與架構，以符合 Cloudflare 價值觀與全球網路的方式建立體系，並在這段新旅程中盡可能保持透明。

讓我們來看看為 MTC 更新後的架構：

與傳統 CA 生態系統相比，你會發現 CA 的職責大致相同：驗證對網域的控制權、將其與公開金鑰綁定、核發憑證。主要差異在於，在 MTC 生態系統中，CA 不再直接對憑證簽章再記錄，而是維護一個由 Merkle 樹支撐的透明度記錄，憑證確實在樹中的包含證明充當信任錨。CA 還將營運鏡像共同簽署方，儲存核發記錄的副本、驗證其僅附加的一致性，並確保這些記錄對更廣泛生態系統的透明度與可用性。

核發 MTC

MTC 有兩種形式，兩者都可編碼為當今用戶端軟體能識別的 X.509 憑證格式——只是使用了「特殊」的簽章演算法。在獨立形式中，憑證的簽章值包含核發記錄的共同簽署樹頭，以及證明憑證包含於該記錄中的包含證明（一系列雜湊值）。若用戶端能以帶外方式取得共同簽署樹頭（例如透過瀏覽器更新機制），憑證可改以相對 landmark 形式提供，此時簽章值僅包含輕量包含證明，完全不含繁重的後量子簽章。

為便於理解，讓我們看一個獨立憑證核發的範例。當網站需要為其網域申請憑證時，可透過 Automatic Certificate Management Environment（ACME）協定向 CA 提出請求，該協定處理憑證請求、網域控制驗證和核發流程。Cloudflare 的 ACME 基礎架構將是 Boulder 的分支版本，Boulder 是驅動 Let's Encrypt 的廣泛部署且久經驗證的 ACME 軟體。Let's Encrypt 正積極在 Boulder 中開發 MTC 支援，我們計劃維護自己的分支，納入這些上游變更以及 Cloudflare 特有的修改，並在可能的情況下向上游貢獻程式碼。

當 MTC CA 收到憑證核發請求時，CA 的 ACME 伺服器會核實伺服器確實控制該網域。核實通過後，CA 將資料序列化並新增至僅附加記錄中。

將 MTC 項目加入核發記錄後，CA 計算記錄的更新狀態，然後對該狀態簽署檢查點。該檢查點證明 CA 已在該時間點之前核發了記錄 Merkle 樹中包含的每一筆項目。

CA 隨後將更新的記錄狀態與新檢查點發送給受信任的共同簽署方。共同簽署方持久儲存 CA 核發記錄的副本，並驗證每個新狀態是否僅附加、與前一棵樹保持一致且格式正確。這一額外的共同簽章讓用戶端和監控方確信另一個受信任的方已觀察到相同的記錄狀態，並驗證了 CA 沒有向生態系統的不同部分呈現不同的核發視圖。它也確保了即使 CA 核發記錄不可用，核發的憑證仍可供監控使用。

Chrome 的抗量子根憑證計畫草案政策要求至少兩個共同簽章：一個來自由獨立組織營運的 Chrome 認可鏡像共同簽署方，一個來自核發 MTC 的 CA 本身。因此，我們將為其他試驗 CA營運鏡像，並要求自己核發的憑證至少獲得一個獨立的共同簽章。

Cloudflare 將在 Azul（我們的開源 Rust 透明度記錄）中實作鏡像共同簽署方，並為實現最大互通性，實作 c2sp 的 tlog 鏡像協定。

最終，在成功從鏡像共同簽署方取得共同簽章後，CA 以共同簽章、伺服器公開金鑰和包含證明建構 MTC，並將其傳送給伺服器，伺服器此後即可將其用於 TLS。

高效分發 PQ 簽章：landmark 最佳化

雖然獨立憑證可以正常運作，但它們在 TLS 交握過程中仍需傳輸大量 PQ 簽章，限制了效率。MTC 設計帶來的真正效能提升來自相對 landmark 憑證。

CA 不必在每張憑證中傳送共同簽章，而是可以將覆蓋記錄中所有有效憑證的子樹序列指定為 landmark，並透過帶外更新服務將這些子樹（及用於驗證它們的資料）分發給用戶端。在 TLS 交握期間，對伺服器的實際身分驗證透過瀏覽器檢查伺服器的憑證資料（包括網域名稱和公開金鑰）是否出現在 CA 記錄的受信任子樹中來完成。若包含證明將該憑證與經共同簽署的 landmark 相連結，且公開金鑰在 TLS 交握期間證明了擁有權，用戶端便確認自己正在與正確的伺服器通訊。

透過定期以帶外方式將這些簽章和樹元資料傳輸給 TLS 用戶端，少量的 MTC 批次簽章就能高效覆蓋特定 CA 核發的數十億張憑證。雖然 landmark 在規模上更高效，但並不能消除對獨立 MTC 的需求——用戶端可能是新安裝的、處於離線狀態，或缺少相關的 landmark 更新。因此，伺服器保留獨立憑證作為備援方案至關重要。

MTC 的實戰成果：與 Chrome 實驗的結果

今年，我們與 Chrome 進行了一次實驗，測試用戶端與伺服器之間 MTC 的可行性。我們營運了一個「引導 CA」（模擬核發管道的假 CA），為 Cloudflare「免費」方案中部分 Cloudflare 網域核發了由傳統憑證鏈支援的 MTC，並向 Chrome Beta 146 的 50% 使用者提供服務。實驗期間，我們成功提供了數十億張 MTC。

對於 TLS，我們發現常見情況相當高效：使用相對 landmark 憑證時，交握僅需傳輸一個公開金鑰、一個簽章以及不到 1 kB 的包含證明。在實驗中，當無法與用戶端協商相對 landmark 憑證時，我們回退至傳統憑證鏈而非獨立憑證。在 CT 方面，MTC 也改變了透明度的擴展特性：記錄只需保存公開金鑰的雜湊；沒有按項目的簽章，樹頭的簽章涵蓋整個記錄。這防止了憑證爆炸——CA 核發記錄是 CA 所核發所有憑證的唯一可信來源，記錄使用者只需取得每張憑證的單一副本。

結果：MTC 確實有效！以中位數計，使用相對 landmark MTC 比傳統簽章鏈快 9%（坦白說，這一效能優勢大部分來自中間憑證的省略）。由於我們是以傳統簽章測試 MTC 的，預計採用後量子簽章後改善幅度將更大。對這些結果以及 IETF PLANTS WG 中 MTC 跨行業合作水準感到滿意，我們於上個月（2026 年 8 月）開始逐步結束實驗。

MTC 的未來展望

我們很高興，與 Chrome 的實驗證明了 MTC 在實務中可以運作，更對能以真正的 CA 身份核發憑證感到振奮。

然而，還有一些更宏觀的問題，只能透過與整個 PKI 生態系統開展這場大規模實驗才能回答。獨立監控方能否在生產規模下消費並驗證 MTC 核發記錄？是否會出現多個 CA 與共同簽署方，使系統獲得韌性所需的多樣性？瀏覽器應如何在緊湊 landmark MTC 的效能優勢與缺少最新 landmark 的用戶端所需的備援路徑之間取得平衡？MTC 已成為後量子身分驗證的權威設計，但要在生產網際網路規模上加以驗證，需要多元化的根憑證計畫、瀏覽器廠商、CA、鏡像、監控方以及更廣泛社群的參與。

我們將參與 Web PKI 下一階段的機會視為榮耀，並認真對待營運 CA 基礎架構的責任。CA 在信任生態系統中佔據特殊地位——瀏覽器、網域擁有者和一般使用者都仰賴它們正確驗證身分、保護簽署金鑰、遵守政策並可靠運行。在 Cloudflare 的 CA 被瀏覽器信任以核發 MTC 之前，我們需要向 Chrome 的 Quantum Resistant Root Store 提出申請，並經過嚴格的評估流程。我們歡迎這樣的審查，並期望讓自己達到任何其他被信任協助保障網際網路安全的 CA 的同等高標準。我們希望有更多 CA 能夠涌現以支援 MTC 的採用，也期待與任何有意部署 MTC 的瀏覽器攜手合作。