八位元的信任鏈：
eMudhra CA 的金鑰在毫秒內被破解

發生了什麼

2026 年 10 月 17 日，一位資安研究員同時向 Apple、Google、Microsoft、Mozilla 與 eMudhra 通報：eMudhra 的八張中繼 CA 憑證的私鑰「本質上就是弱金鑰，任何人都能因式分解，而且問題無法圍堵」。

當晚，Chrome 推送 CRLSet 更新封鎖這些中繼憑證；幾小時後 Firefox 透過 OneCRL 跟進。10 月 20 日，Mozilla 公開這起事件，並發布 NSS 更新移除 eMudhra 根憑證；Chrome 確認該根憑證將在 Chrome Root Store v43 移除。

這不是一起金鑰外洩或被竊事件。研究員在 Mozilla 的討論串裡用一句話總結：「它們是本質上就弱的單位元組金鑰，任何人都能因式分解，而且問題無法圍堵。」資安研究員 Scott Helme 在他的部落格文章標題直接寫：「八位元的信任；eMudhra 的 CA 金鑰在毫秒內被破解」。本文整理他的分析。

256 種可能的私鑰

這些是 P-384 橢圓曲線上的金鑰。私鑰是一個數字 d，公鑰是 d × G（G 是曲線上固定的基點，× 是橢圓曲線的點乘法）。正向計算很快，反向從公鑰推回 d 在正常情況下被認為不可行，這是整個 PKI 安全模型的基礎。前提是 d 必須夠大。

P-384 私鑰應該是一個隨機的 384 bit 數字，有 2³⁸⁴ 種可能（大約 10¹¹⁵），沒人能搜完。

eMudhra 的金鑰長這樣：

d = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004

47 個位元組的零，加上最後一個位元組。正常的 P-384 私鑰應該長這樣：

d = 0x48ac06790886c80c48d31691fd4c0fe9ce3207f9807f2fe571d6e4ec426d78644298fc53df2b92566970e757ac998c34

一個位元組有 256 種可能值（0x00 到 0xFF）。所以「搜尋」的意思是：計算 1 × G、2 × G、3 × G⋯⋯直到跟證書裡的公鑰吻合，最多 255 次就找到了。

整個信任鏈，每一張用這些 CA 簽發的憑證，每個信任它們的客戶端，全部只靠八個位元。

研究員親自驗證了

Mozilla 的公告附上了受影響的憑證，Scott Helme 拿這十六張憑證（八把金鑰，每把被 eMudhra 與 Sectigo 各簽一次）跑暴力破解，全部瞬間成功。他在文章裡附上了完整的表：

這些憑證的結構完全正常。從 d = 4 推導出來的公鑰是曲線上的有效點，編碼正確、曲線正確、所有結構檢查都通過。唯一能發現的方法，就是試著破解它。

為什麼「無法圍堵」

通常 CA 金鑰外洩時，會有一個竊取者、一個發生時間點，可以推論誰現在擁有這把金鑰。

這次沒有。金鑰從證書存在的第一天起就等於公開。任何人在 2025 年 4 月到 2026 年 10 月的 17 個月內，只要看過這些證書之一，就能用一般筆電在毫秒內還原私鑰。這 17 個月的窗口期，無從得知是否有人已經這麼做。

Chrome 的說明指出：因為 Chrome 強制執行 Certificate Transparency（CT），沒有用這些 CA 簽發的 TLS 憑證出現在 CT 日誌裡，所以偽造的憑證無法在 Chrome 預設被信任。這對瀏覽器來說是真的，而且值得安慰。但 CT 是「偵測」錯誤簽發，不是「阻止」；而且大多數軟體根本不檢查 CT。

誰現在還暴露

主流且更新的瀏覽器應該沒事。Chrome 與 Firefox 直接封鎖這些中繼憑證且都要求 CT，Safari 也要求 CT。

但其他所有東西就不一樣了。多數非瀏覽器的 TLS 客戶端（也就是除了瀏覽器之外的幾乎一切，用預設設定時）做三件會影響結果的事：它們信任磁碟上的 CA bundle、預設不檢查撤銷、不檢查 CT。所以 eMudhra 與 Sectigo 撤銷這些中繼憑證，對它們完全沒幫助。

Scott Helme 在文章中特別點出需要更新根憑證儲存庫的範圍（這只是冰山一角）：

• curl | sh 安裝器與自動更新器：許多工具透過 HTTPS 下載腳本或二進位檔來安裝或更新，沒有簽章驗證（rustup、nvm、Homebrew 安裝器、無數的 install.sh 頁面、IoT 韌體更新器）。偽造憑證等於執行攻擊者的程式碼，通常還是 root 權限。

• CI/CD 流水線：GitHub/GitLab runners、Jenkins、建置容器會拉取相依套件與推送產出物，同時持有雲端金鑰、registry token 與簽章金鑰。它們跑在過時的基礎映像檔、共享網路，底層全是 curl、Python、Go、Node。

• 伺服器對伺服器 API 呼叫：支付服務、webhook、OAuth token 交換、雲端 SDK（AWS CLI 與 boto 用自己的 certifi bundle；Terraform 與 kubectl 用 Go）。這些請求的 header 帶著 API 密鑰與客戶資料。

• IoT、嵌入式與 OT 裝置：攝影機、路由器、汽車、醫療器材、智慧家電、支付終端機、工業控制器，向母機回報指令與更新。它們的 bundle 凍結到 2039 年——這就是「無法圍堵」的現實意義。

• Windows 程式碼簽章：這不是 TLS，但缺陷一樣：Windows 直接信任 eMudhra CS 根憑證。用 EM OV CS CA - G3B/G3C 簽章的惡意軟體，在任何不檢查撤銷的系統上看起來就像來自真實發行者的已簽章軟體。

Scott Helme 實測了：用本機伺服器與一張 api.stripe.com 的憑證（他說這是個大家都會同意很高價值的名稱），curl 說 SSL certificate verify ok，Python 完成握手，Node 說 authorized: true。他在 Linux 與 macOS 上測試的每一台機器都這樣。Windows 上，CryptoAPI 會接受這條鏈，除非開啟撤銷檢查，而且即使開啟，兩條路徑（eMudhra 與 Sectigo）只有一條回報已撤銷。

eMudhra 的說明

eMudhra 在 Mozilla 的 incident ticket 中給出了官方說明：

金鑰產生儀式中使用的腳本有 bug，在 HSM（硬體安全模組）上產生了第二組弱金鑰對。因為名稱相似，人為疏失導致選用錯誤的金鑰對來產生憑證簽章請求（CSR）。

Scott Helme 在他的文章更新中補充：「上面文字中的任何內容都不改變。」他也確認，只用一個簡單的 AI 提示詞，就讓 Claude 成功還原了這些 CA 的私鑰。

我們看到的事

這不是第一起 CA 出問題，也不會是最後一起。但這次的形狀特殊：不是被駭，不是管理疏失，是密碼學實作在產生階段就錯了，而且錯得如此基本——單一位元組——以至於任何人都能驗證。

信任鏈的最大問題一直都是：它要求鏈上的每一環都不能出錯。一家 CA 犯錯，影響的是所有信任它的系統；而這次的錯誤窗口長達 17 個月、影響範圍涵蓋 TLS 與程式碼簽章、無從得知誰看過、沒辦法收回已經「公開」的私鑰。

瀏覽器能快速反應，是因為它們有集中更新機制、有 CT 可以防偽造憑證出現、有使用者會抱怨網站打不開。但世界上多數的 TLS 連線不在瀏覽器裡：它們在容器裡、在 CI 流水線裡、在你車上、在醫院的設備裡、在從沒想過自己需要「更新」的裝置裡。

Scott Helme 在文章結尾寫：「八個位元。整整 17 個月，這是大量非瀏覽器軟體與偽造任何網站憑證之間的全部距離，只要你能進到網路路徑上。」

外洩的不是憑證，是整個簽發能力

這起事件裡，沒有任何一把終端實體憑證（leaf certificate）外洩。外洩的是中繼 CA 的私鑰，也就是「簽發憑證的能力」。

三列本質上是同一組金鑰，但因為有兩條信任路徑（eMudhra 自己的根＋ Sectigo 交叉簽章），所以有兩倍的攻擊面。

這篇提到的項目要花多少錢

更新 CA bundle 本身多數是免費的；成本在人力盤點與無法更新的裝置的替代方案。

最貴的不是更新能更新的，是發現並承認那些更新不了的。

證據等級

本文主要依據 Scott Helme 的公開分析與 Mozilla 官方討論串；技術驗證由研究員完成並公開方法。

你可以學到什麼

站在防守者的角度：信任鏈只要有一環斷了，所有依賴它的連線都暴露。而多數連線不在你看得到的地方。

下面的步驟全部唯讀，做完你會有一張「我們信任的 CA bundle 在哪裡、多久更新一次、哪些更新不了」的清冊。

這張清冊會一直有用。不只這次，每次 CA 出事時都要拿出來核對。

本文由 AI 團隊協助研究與撰寫，經隱私與事實檢查後發布；證據等級依來源可信度標註。