摘要
加拿大 Coinkite 公司生產的 Bitcoin 專用冷錢包 Coldcard，其韌體自 2021 年 3 月（v4.0.0）起，因程式庫連結錯誤，導致種子（seed）產生流程繞過了硬體真隨機數產生器（TRNG），實際落入一個確定性極高、可被逆向重建的軟體 PRNG。此缺陷存在超過五年才被發現，攻擊者已利用此弱點在單次攻擊中於 41 分鐘內從 1,196 個地址盜取約 1,082.65 顆 BTC（約合 7,020 萬美元），後續波次再新增約 208 BTC 損失。此事件是近年硬體錢包產業中最嚴重的熵源（entropy source）失效案例之一，對所有依賴嵌入式安全晶片進行金鑰產生的裝置（HSM、安全元件、IoT 裝置）都具有高度參考價值。
一、設計上的預期架構
依 Coinkite 官方文件，Coldcard 的種子產生機制原本設計如下：
- 主要熵源為主晶片內建的硬體 TRNG（True Random Number Generator），透過量測特殊電晶體產生的類比雜訊取得真隨機性。
- 額外維護一組 PRNG，以 XOR 方式混入 TRNG 輸出作為縱深防禦；此 PRNG 於每次開機時，由兩個安全元件（SE1、SE2）各自的 TRNG 播種一次。
- 最終產出的 256-bit 數值會經過 SHA256 進行「白化」（whitening）處理以去除統計偏差。
此設計若正確實作，理論上應具備完整的密碼學等級熵。
二、實際發生的缺陷
2021 年 3 月，Coldcard 進行了一次加密函式庫遷移（改用 libsecp256k1，commit b18723dd「First pass w/ libNgU」）。這次遷移過程中，種子產生路徑透過連結時期（link-time）的符號解析，被意外接到了 MicroPython 附帶的軟體備援 PRNG，而非原本設計的硬體 TRNG。
2.1 實際使用的演算法：Yasmarang
該軟體 PRNG 實際採用的是 Yasmarang，一個非密碼學安全（non-cryptographic）等級的演算法，其狀態僅於開機時初始化一次，輸入來源僅有三項：
- 晶片的 32-bit 唯一識別碼（UID）
- SysTick 計時器（一個週期性倒數計數器，可能值上限僅約 80,000 種）
- RTC（實時時鐘）暫存器
在 Mk3 機型上，RTC 振盪器實際上處於停用狀態，導致冷開機時 RTC 暫存器多為靜態或近似靜態值，進一步壓縮了實際熵空間。
2.2 錯誤的縱深防禦反而放大問題
底層函式庫 libngu 會將上述 Yasmarang 輸出，與另一個以公開硬編碼常數初始化的 Yasmarang 實例進行 XOR 運算。然而兩個確定性串流的 XOR 結果仍然是確定性的，並不會增加熵。
隨後的健康檢查機制僅檢查「相鄰輸出值是否重複」，這種檢查方式無法偵測任何非退化（non-degenerate）的 PRNG，因此該缺陷未被自我檢測機制攔截。
最終產生的位元組會再經過 SHA256d 雜湊處理，但雜湊函式不會增加輸入的熵：若候選輸入空間僅有 2^40 種可能，輸出空間同樣僅有 2^40 種可能。
2.3 有效熵空間坍縮
綜合上述缺陷，實際可行的種子搜索空間遠低於設計目標的 128-bit：
| 機型 | 韌體版本範圍 | 實際有效熵 | 說明 |
|---|---|---|---|
| Mk2 / Mk3 | 4.0.0（含）以後 | 約 2^32（甚至更低） | UID XOR SysTick 為單一 32-bit 值，RTC 幾乎靜態，攻擊者甚至不需掌握特定裝置資訊 |
| Mk4 / Mk5 / Q | 更新前韌體 | 約 2^40 ~ 2^73（各方估計略有差異） | Coinkite 官方估計約 2^40 / 2^72；部分獨立研究認為結構上限更低 |
攻擊者只要知道錢包的公開地址，即可在完全不接觸實體裝置的情況下，離線重放 PRNG 狀態空間、產生候選種子，再透過位址比對確認正確金鑰。
三、事件時間軸與影響範圍
- 2021 年 3 月：libsecp256k1 遷移過程中引入此連結錯誤（韌體 v4.0.0 起受影響）。
- 受影響機型與版本：
- Mk3：韌體 4.0.1 至 5.0.3 為高風險等級
- Mk4 / Mk5 / Q：在對應熱修復版本發布前的韌體皆受影響
- 不受影響產品：TAPSIGNER、OPENDIME、SATSCARD
- 2026 年 7 月 30 日：首波攻擊爆發，41 分鐘內從 1,196 個地址盜取約 1,082.65 BTC（約 7,020 萬美元）。
- 後續波次：新增約 208 BTC，涉及 1,912 個地址，攻擊手法更趨精細（如將多名受害者的資金批次整合於單一交易中）。
- 獨立研究人員（包括 Bitcoin Core 開發者 instagibbs）已於全新 Mk3 裝置上成功重現此漏洞，確認受影響的程式碼路徑。
- 修復版本：Mk4 / Mk5 需升級至韌體 5.6.0 以上；Q 機型需升級至 1.5.0Q 以上。
重要提醒：韌體更新本身無法修復已經產生的種子。任何在受影響韌體版本上產生過的種子，都應視為已遭破解風險，必須在更新後的韌體上重新產生全新種子，並將資金遷移至新錢包。
四、事件的結構性啟示
此事件的根本原因並非演算法設計錯誤，而是建置與連結流程中的靜默降級（silent fallback）——一次函式庫遷移意外地讓熵源從硬體 TRNG 退化為可預測的軟體 PRNG，且此問題長達五年未被偵測。這類風險對於任何依賴嵌入式安全晶片進行金鑰產生的架構都具有高度共通性，值得特別關注以下幾點：
- 熵源驗證機制的脆弱性：僅檢查「輸出是否重複」的健康檢查，無法偵測確定性但非退化的 PRNG 輸出，凸顯熵源自檢機制需要統計檢定（如 NIST SP 800-90B）而非單純的重複性檢查。
- 建置鏈的符號解析風險：連結時期的符號解析（link-time symbol resolution）屬於供應鏈與建置流程的隱性風險，傳統的程式碼審查未必能發現此類問題，需要建置產物的執行期驗證。
- 雜湊無法補救熵不足：SHA256d 等密碼學雜湊函式常被誤認為可以「修復」低熵輸入，但雜湊只會保留輸入熵的原始上限，不會增加隨機性。
- 確定性金鑰派生的兩面性：此案例也反映出確定性設計（如可重現的 PRNG 播種流程）在特定情境下（如 DICE 憑證派生）具備優勢，但若非刻意設計為確定性且缺乏充足熵源時，反而成為攻擊面。
對於採用 HSM 或安全元件進行金鑰管理的企業與金融機構，此事件再次印證：硬體隨機數產生器的存在本身不足以保證安全，熵源的實際使用路徑必須經過端到端驗證，包括建置流程、連結產物與執行期行為的驗證。
企業級金鑰管理：為什麼 Luna HSM 不會發生這類問題
Coldcard 事件的核心教訓是：消費級裝置的金鑰產生流程缺乏獨立的熵源驗證與認證約束。相比之下，Thales Luna Network HSM 從架構層面根除了此類風險：
- FIPS 140-3 Level 3 認證的硬體 TRNG：Luna HSM 的隨機數產生器經過 NIST 認證實驗室的獨立驗證，符合 SP 800-90B 熵源標準。認證流程涵蓋硬體設計、韌體實作與建置產物的完整審查，從根本上排除了「靜默降級至軟體 PRNG」的可能性。
- 防篡改硬體邊界：金鑰材料始終在通過認證的密碼學邊界內產生與使用，任何試圖繞過硬體 TRNG 的韌體變更都會觸發完整性檢查失敗，裝置將拒絕運作。
- 持續性健康監測：Luna HSM 內建符合 NIST SP 800-90B 的連續熵源健康測試（Continuous Health Tests），而非 Coldcard 僅檢查「相鄰輸出是否重複」的簡易檢查。統計檢定能即時偵測熵源退化，確保每一次金鑰產生都使用真隨機性。
- 獨立的韌體簽章與安全更新機制：韌體更新必須通過 Thales 的程式碼簽章驗證，函式庫遷移或連結變更不可能在未經審查的情況下進入生產韌體，消除了 Coldcard 事件中「一次 commit 靜默替換熵源」的攻擊面。
對於管理高價值金鑰的企業——無論是金融交易簽章、PKI 根憑證、或是區塊鏈託管服務——Luna Network HSM 提供的不只是硬體安全模組，而是一套經過第三方認證、端到端可驗證的金鑰生命週期保護體系。
想了解 Luna HSM 如何保護您的金鑰安全？聯絡我們的資安專家取得免費技術諮詢。