如何避免靜默降級：Coldcard冷錢包事件的3個檢查點

2026年7月30日,一批使用Coldcard硬體錢包的用戶,在41分鐘內看著1,196個地址、合計1,082.65枚比特幣被轉出。以Galaxy Research持續追蹤的累計數字來看,受影響地址後來擴大到4,585個,金額約8,860萬美元。多數人看到這則新聞的第一反應,是把它歸類成「冷錢包被駭」。

但這裡要先問一個更前面的問題:攻擊者到底做了什麼?沒有人打開那台裝置的外殼,沒有人騙用戶點連結,也沒有惡意程式在裝置上執行。私鑰是被算出來的,不是被偷走的。這個差異,決定了整篇事件該怎麼理解,也決定了三個月後這篇文章還有沒有參考價值。

這不是「冷錢包被駭」

核心事實是一個安全機制被關掉了,而系統每一層都以為自己正常運作,裝置本身並未遭到入侵。 真正該問的問題,是這個機制什麼時候失效,又為什麼沒有人發現。

41分鐘、1,196個地址、1,082.65枚比特幣

第一波攻擊的速度說明了問題的性質。如果私鑰真的隨機且不可預測,攻擊者不可能在41分鐘內鎖定1,196個特定地址並精準轉出資金。這種速度只有一種解釋:攻擊者早就知道要找哪些地址,因為那些地址的私鑰空間小到可以事先窮舉或大量並行破解。Galaxy Research後續的鏈上分析指出,至少有兩波攻擊共享交易結構與行為特徵,顯示背後是有組織的操作,而非零星的個人行為。

私鑰是被算出來的,不是被偷走的

一般談冷錢包安全,焦點通常放在「裝置會不會被實體竊取」「韌體會不會被植入惡意碼」「使用者會不會被釣魚」。這起事件完全不落在這三類威脅裡。攻擊者實際拿到的,是重新計算出裝置在產生種子當下所使用的亂數;裝置本身、助記詞、韌體簽章、用戶的操作紀錄全數未被觸碰,也全部正常。壞掉的只有一件事:亂數夠不夠亂。這也是為什麼把這起事件單純理解為「冷錢包不安全」會誤導後續的因應方向。

• 攻擊路徑不是實體竊取、不是釣魚、也不是韌體被植入惡意碼
• 私鑰是被重新計算出來的,前提是原本的亂數產生過程可被預測
• 討論重點應該從「裝置安不安全」轉向「熵源何時失效、如何被發現」

一個組態值,四代機型,五年

根因是一個建置組態旗標的判斷方式錯了。 MICROPY_HW_ENABLE_RNG被設成零,但負責檢查的函式庫只驗證這個巨集「有沒有被定義」,不驗證它的值是不是零,於是系統以為硬體亂數產生器正常啟用,實際上整條路徑早就被切換到一個非密碼學等級的軟體亂數產生器。

MICROPY_HW_ENABLE_RNG=0到底關掉了什麼

Coldcard的產品設計原本刻意把MICROPY_HW_ENABLE_RNG設為零,因為裝置本身提供了獨立的硬體RNG包裝層,理論上不需要MicroPython內建的路徑。問題出在負責密碼學運算的函式庫libngu,它用#ifndef這種前置處理器指令檢查這個巨集,而#ifndef測試的是「這個巨集有沒有被定義」,不是「這個巨集的值是不是非零」。

巨集確實被定義了,只是值為零,檢查因此判定為「已啟用」,libngu於是綁定到MicroPython的rng_get()函式。而MicroPython看到值是零,便編譯出軟體端的Yasmarang亂數產生器來替補,而不是呼叫STM32晶片的硬體亂數周邊。這是一次名稱判斷的錯位,不是邏輯運算寫錯,建置照樣成功,不會報錯也不會警告。

Yasmarang只在裝置啟動時初始化一次狀態,依據的是晶片的32位元唯一識別碼、SysTick計時器(一個週期性倒數計數器,可能值最多八萬種),以及即時時鐘暫存器。這三項輸入都不是秘密,對有耐心的攻擊者而言也不難重建,尤其在Mk3機型上,即時時鐘的振盪器並未啟用,代表冷開機時這組暫存器很可能停留在靜態或接近靜態的數值。

熵從2^128掉到2^72或2^40是什麼概念

一組12個單字的BIP-39助記詞,理論上帶有128位元的熵,也就是2的128次方種可能組合,這個數字大到即使動用全世界的運算資源窮舉也不切實際。受影響的Mk4、Mk5與Q機型,退化後的有效熵大約只剩72位元;更早的Mk2、Mk3機型甚至掉到約40位元。72位元對現代運算資源而言仍然龐大,但已經進入「有組織的攻擊者可以負擔」的範圍;40位元則是個人電腦等級就能在合理時間內窮舉的規模。熵的下降不是線性的,每少一個位元,搜尋空間就少一半,掉了56到88個位元,等於安全邊際幾乎全數蒸發。

機型	受影響韌體版本	退化後有效熵	修復版本
Mk2 / Mk3	4.0.1–4.1.9	約 2^40	4.2.0+
Mk4 / Mk5 標準版	<5.6.0	約 2^72	5.6.0+
Mk4 / Mk5 Edge	<6.6.0X	約 2^72	6.6.0X+
Q 標準版	<1.5.0Q	約 2^72	1.5.0Q+
Q Edge	<6.6.0QX	約 2^72	6.6.0QX+

資料來源:Coinkite官方安全公告。

為什麼code review不會看到這裡

這個問題橫跨四代機型、存在五年,關鍵在於它根本不在一般程式碼審查的視野裡,不是沒人審查過這段程式碼。#ifndef MICROPY_HW_ENABLE_RNG這一行語法完全合法,邏輯上也「說得通」,審查者要嘛不會特別去查這個巨集在建置組態裡實際被設成什麼值,要嘛即使查了,也很難光靠看程式碼判斷出「巨集存在但值為零」與「巨集根本沒定義」之間的差異會導致完全不同的執行路徑。這類缺陷通常長在程式碼與建置組態之間的介面上,兩邊分開看都沒問題,合起來才出錯,問題不會顯現在演算法邏輯本身。

為什麼五年沒被發現:fallback的悖論

因為降級後的路徑在正常情況下永遠不會被觸發,而觸發之後產生的輸出在統計上仍然像隨機數。 測試能驗證的是「系統有沒有照設計運作」,但一個從未被走到的分支,不會出現在任何測試報告裡,直到它被利用的那一刻才第一次「被看見」。

先澄清:「AI八分鐘找出漏洞」沒有官方背書

事件曝光後,社群流傳一則說法:有開發者用Claude Code對Coldcard的開源韌體進行掃描,「僅用八分鐘」就精準定位出這個沉睡五年的漏洞。包括本文引用的區塊客報導在內,不少媒體的標題都直接採用了這個說法,但媒體收錄一則流傳的說法,不等於這則說法已經過查證。這個說法目前沒有官方或第三方鑑識報告背書。技術根因的溯源工作,是由Block工程團隊完成並公開發表分析;鏈上資金流向的分析,是由Galaxy Research持續追蹤發布。

所謂「八分鐘找到漏洞」的說法,來自一位匿名Reddit用戶,而且是在漏洞細節、資金被盜與技術分析都已經公開之後才貼出的測試紀錄,缺乏完整、可覆核的測試環境紀錄。社群自述不等於鑑識結論,這篇文章沿用的技術事實,以Coinkite官方公告與Block的公開分析為準。

Block工程團隊在技術分析報告《Predictable RNG Fallback and 32-Bit Reseed in COLDCARD Firmware》的「Libngu巨集判斷錯誤」一節中指出:「#ifndef僅驗證巨集是否存在,它不會拒絕一個值為零的巨集。」這句話精準點出了整起事件的技術根因所在:出錯的關鍵是一個判斷式的邊界條件,不在演算法本身。

降級路徑在正確情況下永遠走不到,所以永遠測不到

多數測試策略,不論是單元測試、整合測試或滲透測試,驗證的前提都是「系統依照設計運作」。而fallback機制的設計初衷,恰恰是「萬一正常路徑失效時的備案」,它存在的意義就是不常被用到。這造成一個結構性的矛盾:一個機制越是「安全網」性質,測試涵蓋它的動機就越低,因為在絕大多數的測試執行中,它根本不會被觸發。Coldcard這個案例更進一步,問題不在fallback機制的邏輯本身有錯,而在判斷「該不該啟用fallback」的那個條件式誤判了,導致本該罕見觸發的降級路徑,其實一直都是唯一在跑的路徑,只是沒有人知道。

壞掉的亂數看起來仍然像亂數

即使問題被觸發,系統也不會發出任何警訊。Yasmarang的輸出經過XOR運算與重複值健康檢查,統計上通過了一般的隨機性測試;種子產生過程還會再做一次SHA256雜湊,雜湊函式的輸出在外觀上均勻分布,但雜湊沒有能力替一個熵本來就不足的輸入,補上原本沒有的資訊量。美國國家標準與技術研究院(NIST)在SP 800-90系列標準裡明確區分了這兩件事:一個亂數產生器合不合格,關鍵在輸入端的熵源品質,而不是輸出通過了多少統計檢定。換句話說,壞掉的亂數在外觀檢查上完全正常,唯一能揭穿它的方法,是回頭檢視輸入端到底提供了多少真正不可預測的資訊,而這件事沒有任何一層執行期斷言在做。

• fallback機制天生難測,因為它的設計目的就是「很少被用到」
• 這次的問題出在「該不該啟用fallback」的判斷條件錯了,不是fallback邏輯本身有誤
• 退化後的輸出仍能通過一般隨機性檢查,沒有執行期機制能揭穿熵source本身不足

三個可以做的檢查

三個方向:安全關鍵路徑禁止靜默降級、熵源要有開機自測與健康檢查、建置組態要納入安全審查範圍。 這三項都不需要重寫演算法,重點是把「降級」這件事從隱形變成有紀錄、可被攔截的事件。

1. 安全關鍵路徑不給靜默fallback。 當系統拿不到預期強度的熵源時,正確的行為是拒絕產生種子並明確報錯,而不是安靜地換一套較弱的機制頂替上去,讓使用者以為流程正常完成。
2. 熵源要有開機自測與健康檢查。 硬體亂數產生器可以在每次開機時執行自我檢測,確認實際被呼叫的是哪一條路徑,並將結果記錄下來,而不是只在文件裡假設它「應該」被啟用。
3. 建置組態要納入安全審查範圍。 程式碼審查通常聚焦在邏輯本身,但這起事件說明,組態旗標與程式碼邏輯的交界處,同樣需要被視為安全關鍵區域,納入審查清單。

這三項做法背後是同一個原則:當一個環節的失效可能導致無法挽回的損失時,系統寧可明確中止,也不要用一個看起來能動、實際上不合格的替代方案矇混過去。

唯一真的擋下來的東西:縱深防禦

是縱深防禦。它在這起事件裡不只是理論建議,而是唯一真正生效的防線。 單一熵源失效時,能保住資金的用戶,是那些原本就沒有把全部信任放在裝置本身的人。

Coinkite公告:骰子熵源與強passphrase用戶不受影響

Coinkite的官方公告明確指出兩種不受這起事件影響的情境。第一種,是在產生種子時額外加入至少50次公正、獨立、私密的骰子擲擲,這樣的骰子熵本身就足以貢獻完整的128位元獨立熵,不論裝置端的亂數品質如何,整體熵值都不會被拖垮。第二種,是搭配一組強且唯一的BIP-39密碼短語,即使裝置產生的種子熵不足,額外的密碼短語仍構成攻擊者必須另外突破的一層屏障。這兩種情境的共通點,是使用者沒有把全部信任壓在單一元件上。

Galaxy Research研究主管Alex Thorn在事件持續追蹤期間多次於社群媒體示警,他的判斷是:凡是在2021年3月那次有瑕疵的韌體更新之後產生的Coldcard單簽地址,遲早都會被掏空,只是時間早晚的問題,並持續呼籲用戶儘快將資金移往安全處。這則提醒本身也印證了縱深防禦的邏輯,在根因尚未完全修復、資金仍在持續流失的階段,額外的一層保護是唯一能立即降低風險的手段。

這也是這起事件裡最容易被忽略的一課。多數討論聚焦在「誰該負責、漏洞怎麼修」,但對已經持有資產的使用者而言,真正發揮保護作用的,是原本就存在、平常看起來「多此一舉」的第二層與第三層防護,不是靠等待廠商修復。

回到我們自己的系統

同樣的風險模式不只存在於硬體錢包,任何仰賴亂數或唯一識別碼的系統,都可能有一段「理論上不會走到」卻從未被驗證過的路徑。 差別只在於出錯時看到的是資產被轉走,還是資料被連結回真人。

數位健康與醫療資訊系統裡,有好幾個環節與Coldcard的熵源問題結構相同:當熵源函式庫、亂數硬體,或依賴的系統呼叫在特定環境下(例如虛擬化主機、容器裡沒有硬體亂數裝置)無法取得預期強度的熵時,程式庫可能悄悄切換成內建的軟體亂數產生器頂替上去,而呼叫端完全無感,產生出來的值一樣格式正確、一樣能通過型別檢查。去識別化流程裡的假名產生器,如果剛好走的是這條退化路徑、亂數強度不足,理論上不可回推的假名就可能被重新關聯回原始病患身分,而系統本身不會有任何警訊,因為輸出看起來仍然是一串正常的亂碼。SMART on FHIR授權流程中的code_verifier與state參數,設計初衷是防止授權碼被攔截或偽造,如果產生這些值的亂數來源同樣可預測,攻擊者便有機會在OAuth流程中插入偽造的請求,而系統端看到的仍是格式正確的參數。

session token與稽核軌跡的產生邏輯也是同樣道理,一旦亂數來源被弱化,攻擊者實際能預測或重放的,就是原本應該無法被預測的存取權杖。

這些系統平常運作時完全正常,問題只會在有心人刻意測試邊界條件時才浮現,而那正是Coldcard事件真正的提醒:一個系統「看起來正常運作」與「真的安全」之間,中間隔著的關鍵往往在於有沒有人回頭檢查過那些理論上不該被觸發、卻悄悄成為唯一路徑的角落,不是功能夠不夠完整。

常見問題

Q1: 所有Coldcard用戶都受影響嗎?

不是。只有在受影響韌體版本上產生種子的用戶才有風險:Mk2/Mk3為4.0.1–4.1.9,Mk4/Mk5標準版為5.6.0以前、Edge版為6.6.0X以前,Q標準版為1.5.0Q以前、Edge版為6.6.0QX以前。沒有額外使用骰子熵源或強BIP-39密碼短語的用戶風險較高。TAPSIGNER、OPENDIME與SATSCARD不受此問題影響。

Q2: 現在應該怎麼做?

Coinkite官方建議先安裝修復韌體,在更新後的裝置上產生新種子,驗證備份與接收地址無誤,做一筆小額測試交易確認無誤後,再將剩餘資金遷移過去,並在遷移完全確認前保留舊備份。

Q3: 這代表硬體錢包整體不安全嗎?

不能這樣推論。這起事件的根因是特定產品的建置組態缺陷,不是「硬體錢包」這個類別本身的架構性問題。這次事件真正突顯的,是縱深防禦(額外熵源、密碼短語)在單一元件失效時的實際價值。

Q4: 「AI八分鐘找出漏洞」是真的嗎?

目前沒有官方或可覆核的第三方鑑識報告支持這個說法。技術根因的正式分析來自Block工程團隊,鏈上資金流向分析來自Galaxy Research,所謂AI八分鐘找到漏洞的說法出自匿名社群貼文,且是在漏洞公開之後才發布,缺乏完整可驗證的測試紀錄。