—

作者:

ai客服

分類: 區塊鏈, 資安工具, 資訊安全

IACR 2025 選舉失效：密鑰遺失凸顯分散式金庫設計的脆弱性

2025 年，國際密碼學研究協會 IACR（International Association for Cryptologic Research）在進行理事會選舉時，因為投票解密金鑰的一個分片遺失，導致整場選舉結果無法解密、選舉被迫作廢。
對一個集合了全球頂尖密碼學家的組織來說，這起事件格外具有象徵意義：

即使使用了形式上「安全」的密碼學方案，如果金鑰管理與作業流程設計不當，整個系統仍可能在關鍵時刻完全失效。

以下從分散式金庫設計、門檻加密（threshold cryptography）、與實務防護建議三個面向，整理這起事件帶來的啟示。

一、事件概述：「投票資料沒被偷，卻永遠解不開」

根據公開報導與 IACR 對外說明，這次選舉採用 Helios 電子投票系統，並由多位「選舉 trustee」共同管理解密金鑰：
- 投票資料經由公鑰加密，只有掌握多個金鑰分片的 trustee 合作，才能解開總票數（門檻加密）。
- 系統實作上採用類似 3-of-3 的門檻設定：所有 trustee 都必須參與解密。app.daily.dev+1
- 實務上，其中一名 trustee 不慎遺失了自己的私鑰分片，導致整個解密流程無法完成。
從安全性角度來看：
- 機密性（Confidentiality）：投票內容沒有外洩，反而是「安全到誰也看不到」。
- 可用性（Availability）：因為缺乏備援與恢復策略，導致投票結果永遠無法被解密使用。
換句話說，這次不是典型的「駭客攻擊」，而是金鑰生命週期管理失敗，造成關鍵服務無法運作。

二、分散式金庫與門檻加密設計的幾個盲點

這起事件凸顯了幾個常見但容易被忽略的設計風險：

1. 門檻設定過於嚴苛（3-of-3 vs. 2-of-3）

門檻加密本來是用來避免「單點掌權」：
- 3-of-3：需要所有 trustee 才能解密，任何一人缺席就全滅。
- 2-of-3：允許部分 trustee 無法參與，仍能完成解密。
IACR 後續已表示將調整為更具彈性的門檻設定，並重新檢討作業流程，以避免類似情況再度發生。The Register Forums+1

啟示：
對選舉、金流、證書簽發等關鍵業務，門檻要在「防內鬼」與「防失誤」之間取得平衡，而不是一味追求最嚴格的 M-of-M。

2. 金鑰備份與復原策略不足

即便採用分散式金庫或 threshold scheme，仍需要：
- 清楚定義：哪些情境下可以啟動備援或恢復流程（例如 trustee 退休、身故、密鑰遺失）。
- 設計「密鑰輪替 + 備援 share 重建」機制，而不是讓同一組分片永久存在、永久風險累積。
在 IACR 案例中，投票結果之所以無法挽回，就是因為沒有為「密鑰分片遺失」預留安全的復原路径。

3. 人為操作與流程管控的薄弱

就算演算法再嚴密，若：
- trustee 的金鑰只存在單一裝置，沒有安全備份；
- 不曾做過「模擬演練」，沒有人意識到少了一片就什麼也不能做；
那麼整個系統仍然極度脆弱。這種情況在企業內部的 HSM、KMS、PKI 也屢見不鮮，只是 IACR 案例被放大檢視而已。

三、這不是 OpenSSL 漏洞：和典型「CVE 式」弱點的差異

目前公開報導中，沒有任何證據顯示 IACR 事件與 OpenSSL 或其他密碼函式庫漏洞有直接關聯，它更像是：

「把金庫設計得很安全，但鑰匙只做三把，而且沒有備份，結果其中一把被丟掉了。」
- 像 Heartbleed (CVE-2014-0160) 是 OpenSSL 內部實作錯誤，會導致機密資料（含金鑰）被遠端讀取，是機密性的破壞。heartbleed.com
- IACR 事件則是「金鑰分片遺失 + 門檻設計」造成可用性被破壞，屬於操作與流程問題，而非密碼演算法或函式庫缺陷。
四、防護與恢復的實務最佳做法

以下是可以給讀者（尤其是有 KMS / HSM / 選舉或簽章系統的組織）的一套具體建議：

1. 採用合理的門檻方案
- 避免過於脆弱的 M-of-M 設定（如 3-of-3）。
- 優先採用 2-of-3、3-of-5 等容錯門檻，確保單一 trustee 失誤不會導致系統停擺。
2. 引入安全的「密鑰生命週期管理」
- 明確定義：產生 → 分發 → 使用 → 輪替 → 停用 → 銷毀的全流程。
- 一旦 trustee 角色變動（離職、退休、無法聯繫），要有正式程序重建金鑰分片。
3. 多層備份與地理分散
- 使用 Shamir Secret Sharing 或其他 threshold scheme，將「master key」拆分存放於多個 HSM / 安全區。
- 備份不只「多份」，還要多管道 / 異地，並有明確的啟用條件（例如需多方簽核）。
4. 變更控制與審計
- 每一次金鑰產生、匯出、輪替、備份、銷毀，都應有嚴格的審計紀錄與多人覆核。
- 使用版本控制與變更管理（例如把 KMS 組態以 GitOps 方式管理），避免誤操作無法追蹤。
5. 定期演練「金鑰遺失情境」
- 不只做「災難復原演練」（DR Drill），還要專門演練：
  - 某一 trustee 無法參與；
  - 某一分片疑似外洩或不可信；
  - 需要緊急輪替整組金鑰。
- 演練結果要回饋到門檻設定、流程與文件修訂。
6. 對第三方金庫 / KMS 供應商的安全評估
- 若使用雲端金鑰管理服務（AWS KMS、Azure Key Vault 等），要確認：
  - 是否支援門檻式或分散式金鑰管理；
  - 備份與復原流程是否透明、可驗證；
  - 供應商是否有明確的 SLA 與災難復原計畫。
五、從 IACR 案例給企業的幾個關鍵提醒
1. 密碼學本身不會救你
  演算法可以很安全，但只要金鑰管理、流程設計、權限控管出錯，整個系統仍然可能在關鍵時刻失效。
2. 可用性與機密性一樣重要
  「結果永遠解不開」在商業或治理場景中，和「資料被偷走」一樣嚴重——都會讓組織失去信任。
3. 分散式 ≠ 不會出問題
  把金鑰分成很多份，並不自動等於安全；如果沒有好的門檻策略、備援與審計，反而會放大人為失誤的風險。
4. 把這次事件當成「免費演習」
  IACR 的例子非常適合作為內部教育教材：
  - 可以拿來檢查你們自己的 KMS / HSM / PKI 設計；
  - 可以模擬「若我們的選舉 / 金流 / 憑證系統發生同樣情況，會怎樣？」。
參考資料
- 報導 IACR 選舉金鑰遺失與選舉作廢的新聞彙整 app.daily.dev+1
- 關於密碼學社群對此事件的評論與討論 LinkedIn
- Heartbleed 漏洞 (CVE-2014-0160) 作為典型密碼函式庫弱點範例 heartbleed.com