eMudhra 八張中繼憑證的私鑰全是單位數字，筆電幾毫秒就能還原。十七個月裡，整個信任只靠八個 bit 撐著。以下一次收齊：原文翻譯、HN 討論整理、一頁懶人包。
手機看不到上方懶人包時，可開備援連結：https://derek-static.pages.dev/emudhra-8bit.html
原文翻譯
作者 Scott Helme，原文：https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/
eMudhra 其中一支憑證機構（CA）私鑰，就是數字 4。
不是以 4 開頭、後面跟著幾百個隨機數字的數字，就是 4 本身。另一支是 56，還有一支是 115。我知道，因為我剛剛在筆電上從這些公開憑證把私鑰全部還原出來了，花不到一秒。
發生了什麼事
10 月 17 日週六，一位安全研究員向 Apple、Google、Microsoft、Mozilla 和 eMudhra 通報：eMudhra 八張中繼憑證的私鑰已洩露。當晚 Chrome 就推送 CRLSet 更新擋掉它們，幾小時後 Mozilla 也經由 OneCRL 在 Firefox 擋掉。10 月 20 日週二，Mozilla 公開宣布，並釋出移除 eMudhra root 的 NSS 更新，Chrome 也確認該 root 將在 Chrome Root Store v43 被移除。
這八張中繼憑證是六張 TLS 簽發 CA（DV、OV、EV，各兩個世代）加兩張程式碼簽署 CA，全部建於 2025 年 4 月。每一張在 2025 年 5 月都被 Sectigo 的 AAA Certificate Services root 交叉簽署。
「發生什麼」大概就是這樣，有趣的是「怎麼發生」。Ian Carroll 在討論串裡用一句話總結：它們本質上就是單一 byte 的弱金鑰，任何人都能破解，這件事無法收拾。
私鑰到底是什麼
這些是 P-384 曲線上的橢圓曲線金鑰。私鑰就只是一個數字 d。公鑰，也就是放在憑證裡給全世界看的東西，是 d × G，其中 G 是大家共用的曲線固定基點。
正向計算很容易，反向從公鑰推回 d 則被認為不可行。整個安全模型就建立在這點上，前提是 d 必須是天文數字。P-384 私鑰應該是一個隨機 384-bit 數字，有 2 的 384 次方種可能，沒人能窮舉。
eMudhra 的金鑰長這樣：47 個 byte 全是 0，最後只剩一個 byte。正常 P-384 私鑰應該是 48 個 byte 全是隨機值。單一 byte 只有 256 種可能，所謂搜尋就是：算 1×G、2×G、3×G，對到憑證就停，最多 255 步。
換句話說，這些 CA 能簽發的所有憑證、所有信任它們的客戶端，全都只靠八個 bit 撐著。
我驗證過了
Mozilla 在公告裡附上了受影響憑證，所以作者把 16 張全抓下來（8 支金鑰，每支各有兩張憑證：一張 eMudhra 簽的、一張 Sectigo 簽的）暴力破解。每一張都瞬間倒下：
| 中繼憑證 | 類型 | 私鑰 d |
|---|---|---|
| EM DV TLS CA – G3B | TLS | 156 |
| EM DV TLS CA – G3C | TLS | 230 |
| EM EV TLS CA – G3B | TLS | 115 |
| EM EV TLS CA – G3C | TLS | 56 |
| EM OV TLS CA – G3B | TLS | 155 |
| EM OV TLS CA – G3C | TLS | 4 |
| EM OV CS CA – G3B | 程式碼簽署 | 66 |
| EM OV CS CA – G3C | 程式碼簽署 | 237 |
有趣的是，這些憑證外觀完全正常。從 d=4 推導出的公鑰是曲線上完全合法的點，編碼沒問題、曲線沒問題，所有結構檢查都會過。唯一能發現的方法就是動手試試看。
為什麼無法收拾
正常 CA 金鑰洩露，是有人偷走它。有小偷、有事發時間點，至少能推論現在誰手上有那把鑰匙。
這次根本沒人需要偷。從憑證存在的那天起，金鑰實際上就是公開的。從 2025 年 4 月以來，任何看過這些憑證的人，用一般硬體幾毫秒就能還原私鑰。這是長達十七個月的空窗，而且無從得知有沒有人真的動手。
Chrome 指出，因為 Chrome 強制要求 Certificate Transparency，而從未有鏈到這些 CA 的 TLS 憑證出現在 CT log 裡，所以在 Chrome 預設信任下不會有偽造憑證得逞。這是真的，對瀏覽器來說也令人安心。但 CT 只能偵測錯發，不能預防錯發，而且很多軟體根本不檢查 CT。
今天誰還暴露
主流且有更新的瀏覽器大概都沒事。Chrome 和 Firefox 直接擋掉這些中繼憑證，兩者都要求 CT，Safari 也要求 CT。
其他一切就是另一回事了。多數非瀏覽器 TLS 客戶端，像 curl、Python、Node、Go、Java、git、套件管理器，有三個致命共通點：信任磁碟上的一包 CA bundle、預設不檢查 revocation、不檢查 CT。所以 eMudhra 和 Sectigo 撤銷了這些中繼憑證，對它們一點幫助都沒有。
* curl / sh 安裝器和自動更新器：經 HTTPS 下載 script 或 binary 且不做簽章驗證，偽造憑證就等於以 attacker 的程式碼執行，通常還是 root。
* CI/CD pipeline：runner、build container 拉依賴、推 artifact，手上拿著雲端金鑰與簽署金鑰，底層全是 curl、Python、Go、Node。
* Server-to-server API 呼叫：金流商、webhook、OAuth token 交換、雲端 SDK，header 全是 secret。
* IoT、嵌入式和 OT 裝置：監視器、路由器、車、醫療裝置、家電、刷卡機，韌體凍結到 2039 年。
* Windows 程式碼簽署：Windows 直接信任 eMudhra CS root，未檢查 revocation 就會把惡意程式當合法軟體。
作者用本地 server、簽一張 api.stripe.com 的憑證實測：curl 回 SSL certificate verify ok，Python 完成交握，Node 回 authorized true，Linux 和 macOS 皆然。Windows 上除非打開 revocation 檢查，CryptoAPI 都接受這條鏈。
現在該怎麼做
能更新的裝置做法不複雜，結論就是更新它們。麻煩的是那些不能更新的裝置。
- 更新所有自帶 CA bundle 的東西：OS 的 ca-certificates 套件、certifi、Node、Homebrew，base image 修掉後重建 container image。
- 不能更新的裝置才是硬骨頭：路由器、印表機、電視、韌體凍結的家電，會信任這些憑證到 2039 年 7 月。
八個 bit。整整十七個月，這就是擋在大量非瀏覽器軟體和偽造憑證之間的全部東西。
來源：MDSP 討論串、研究員公告 emudhra.we-have-a-problem.com。10 月 20 日更新：Mozilla 公開 incident ticket（bugzilla 2083449），eMudhra 說 key ceremony 用的 script 有 bug，在 HSM 上多建了一組弱金鑰對，名稱相近導致人為失誤拿錯 key 去發 CSR。
HN 留言整理（416 則，872 分）
怎麼發現
通報人 Wayne 回信：用的就是 google/paranoid_crypto，開箱即用。本來只想拿 CCADB 當語料庫快速測試，之後才要看 subscriber 憑證。已把 CCADB 現存憑證全部更徹底掃過，幸好沒再中。大部分時間都在補那些大家以為別人早就做過的基礎檢查。
程式碼位置：paranoid_crypto/lib/ec_single_checks.py。那個 repo 已在 2026-08 被 archive，網友酸：檢查完了所以以後不會再犯，就不用維護了？
為何是單一 byte
* 取餘或截斷 bug：八支全在 0 到 255，不可能是運氣。像把 x mod 2 的 256 次方寫成 x mod 256，或該 memcpy 整串只寫 1 byte。
* 序號誤用：把序號當成私鑰。
* 人工手選 1 到 384：八個數字全小於 384，剛好是 P-384 的位元數。疑似以為 1 到 384 挑一個隨機數就好。
* 鍵盤隨機：數字全是鍵盤由左往右，疑似手打假隨機。
eMudhra 在 Bugzilla 說：當天 KGC 腳本有缺陷，在 HSM 上多建了一組弱金鑰對，名稱相近導致人為失誤。網友補刀：FIPS 認證的 HSM 產的是強金鑰，是後面蠢 script 把前面 47 bytes 歸零。CA 稽核只查有用 FIPS 模組產生，不管之後怎麼亂搞，制度破洞在這裡。
稽核與信任體系
* 有 100 個受信任 CA 太多了？作者 Scott 本人回：root 就有約 350 個，中繼加起來超過 3,600 個。
* 連個最小能力檢查都沒有是疏失。反駁：能力難系統化檢查，問題在稽核清單比 FIPS 短太多，只查有用 FIPS 產生器加多人儀式紀錄。
* 惡意還是無知？一方說當 CA 有這種 ceremony 還能出錯，推定惡意合理。另一方說 CA 本來就能簽 MITM 憑證，故意產弱金鑰毫無動機，極大概率是 bug。
* 早該強制 Name Constraints 加讓 curl、Python 驗 CT 簽章時間戳。CT 只能偵測錯發、不能預防，CAA 只是建議性。
誰真的有事
瀏覽器大致沒事，非瀏覽器才是重災區：curl、Python、Node、Go、Java、CI runner、IoT 凍結韌體到 2039、Windows 程式碼簽署。revocation 加 CT 預設都不檢查，撤銷了也沒用。Arch 更新後假憑證已不信任。靈魂拷問：一年零簽發、CT 零紀錄的中繼，為何還要信任？
幽默與行動派
xkcd 221（4 是公平骰子選的）、4 甚至不是質數、手工密碼學、有機 nonce。行動派做了 test.key4.lol 一鍵測裝置是否仍信任，GitHub 已有人放出可用 key，有人已拿它解開兩台鎖死的 ESP32 韌體。下一步擔憂：該掃 unix-time 種子 PRNG、被截成 32、64、128-bit 的金鑰。8-bit 都在外面擺一年沒人測，沒資格說低垂果實摘完了。
懶人包
全文重點已做成一頁懶人包（見文首嵌入），含時間線、八支金鑰表、誰安全誰危險、為何無法收拾、現在怎麼做、網友精華。主連結：https://static.blog.derekhsu.net/emudhra-8bit.html，備援：https://derek-static.pages.dev/emudhra-8bit.html。