私鑰強度崩潰：從理論上的天文數字到實際的個位數
橢圓曲線加密（如 P-384）的安全性建立在私鑰是一個極大的隨機數，標準應為 384 位元，擁有約 10^115 種可能性。然而，eMudhra 的八張中介憑證私鑰實際值僅為單一位元組（8 位元），例如其中一張 TLS CA 的私鑰數值為 4，另一張為 56。
這種極短的私鑰意味著攻擊者只需計算 G×1, G×2... 直到匹配公開密鑰，最多只需 255 步即可破解。研究員 Scott Helme 在筆記型電腦上於一秒內便還原了所有受影響的私鑰，證實這些憑證自 2025 年 4 月簽發以來，其安全性實質上等於公開。
事件起因與瀏覽器端的即時防護
漏洞於 10 月 17 日由研究員 Wayne Thayer 通報給 Apple、Google、Microsoft、Mozilla 及 eMudhra。Chrome 當晚即透過 CRLSet 更新阻擋相關憑證，Firefox 隨後透過 OneCRL 進行阻擋，並移除 eMudhra 根憑證信任鏈。
eMudhra 在 Mozilla 的 Bugzilla 單據中說明，事故源於簽發儀式腳本的錯誤：HSM 生成了第二組弱密鑰對，因名稱相似導致人為失誤選用了錯誤的密鑰生成 CSR（憑證簽名請求）。受影響的包括六張 TLS 簽發 CA 與兩張程式碼簽章 CA。
非瀏覽器用戶端的高風險暴露面
雖然 Chrome、Firefox 和 Safari 因強制檢查憑證透明度 (CT) 而能偵測並拒絕偽造憑證，但大多數非瀏覽器 TLS 用戶端（如 curl, Python, Node.js, Go, Java）預設行為不同。這些工具通常信任磁碟上的 CA bundle，且不預設檢查撤銷狀態或 CT。
測試顯示，使用預設設定的 curl、Python 和 Node.js 在本地伺服器模擬偽造憑證時，均驗證通過並接受連線。這意味著若攻擊者位於網路路徑上，可對這些軟體的加密流量進行中間人攻擊，且因不檢查撤銷，即使 CA 已撤銷憑證，這些用戶端仍會信任它。
難以修補的長期風險：IoT 與自動化基礎設施
受影響的憑證有效期至 2039 年 7 月，這對於無法更新韌體的 IoT 設備（如路由器、醫療器材、工業控制器）構成長期威脅。這些設備的信任根存儲是凍結的，直到到期前都會信任 eMudhra 的弱密鑰 CA。
除了 TLS，Windows 程式碼簽章也受影響。若軟體使用 eMudhra 的弱密鑰 CA 簽章，且不檢查撤銷狀態的系統會將其視為可信賴發行者的軟體。此外，CI/CD 管線、套件管理器安裝腳本及伺服器間 API 呼叫均依賴這些未檢查撤銷的用戶端，增加了憑證偽造的攻擊面。
建議措施與社群反應
對於可更新的系統，建議更新作業系統的 ca-certificates 套件、certifi、Node.js 及 Homebrew 等工具，並重建容器映像檔以確保基礎鏡像包含最新的信任存儲。然而，對於無法輕鬆更新的設備，風險將持續存在直至憑證過期。
社群討論指出，此事件凸顯了 PKI 生態系的脆弱性，特別是對非瀏覽器用戶端的關注不足。有評論建議利用這些弱密鑰生成看似有效的憑證來測試或「越獄」某些 IoT 設備，並質疑是否還有其他 CA 的私鑰被截斷至較短長度（如 32 或 64 位元）而未被發現。
