「私鑰未洩露」，是最危險的安慰劑：如何選擇真正可靠的加密產品？

如果一款加密產品從未發生過用戶私鑰洩露，是否就意味著它足夠安全？

答案顯然沒有那麼簡單。

眾所周知，從 9 月下旬到 10 月底，加密行業經歷了一場相當密集的安全大考，從全球頭部中心化交易平台，到老牌知名硬體錢包廠商，接連曝出多起影響深遠的安全事件。

如果仔細審視這些事件後的官方公告，會發現一個反覆出現的表述：「沒有證據表明私鑰遭到洩露」，或者「用戶私鑰與助記詞未受影響」。

但攻擊者尋找的入口，可能就不在於私鑰——當交易所的內部權限可以被盜用，當第三方安全產品成為進入管理系統的跳板，當硬體設備被植入惡意模組，甚至當用戶的真實姓名、聯繫方式與家庭住址因為資料洩露被暴露，單純強調「私鑰沒有洩露」，顯然不足以覆蓋用戶面臨的全部風險。

畢竟，私鑰安全，只是加密資產安全的起點，而不是終點。

這也意味著，我們需要重新審視一個問題：在今天的加密世界，到底應該如何判斷一款產品是否真正安全可靠？

一、攻擊者如何繞過私鑰，資產與資料是如何失守的？

上一篇文章曾經提到，如果把近期的安全事件放在一起觀察，會發現一個明顯的趨勢：攻擊者不一定需要直接攻破密碼學和私鑰本身，反而可能從整條「信任鏈」中尋找突破口。

從員工終端、第三方安全產品，到軟體供應鏈、服務容器乃至交易授權流程，任何一個環節出現裂縫，都可能讓原本看似嚴密的安全體系失去作用：

• 像 Bybit 事件中，攻擊者通過社會工程手段入侵 Safe 一名開發者的設備，取得其相關存取憑證，進而控制 Safe 錢包基礎設施中的前端資源；
• Bitget 事件中，攻擊者則是利用第三方安全產品的漏洞，獲取了內部高權限憑證，隨後通過偽造的提現指令繞過原有風控機制；
• 到了最新的 Binance 事件，攻擊路徑又很可能始於一名 DevOps 工程師的筆記型電腦遭到入侵（不過 Binance 隨後表示，進一步調查又發現了其他入侵點，完整攻擊路徑仍有待確認）；

三起事件，分別涉及第三方錢包基礎設施、第三方安全產品和內部開發維運環境。

這也解釋了為什麼傳統的冷錢包、多簽機制並不能包治百病，畢竟攻擊者真正利用的，恰恰是那些能夠影響最終交易執行、卻沒有得到充分獨立驗證的信任環節。

說到底，在中心化資產管理體系中，攻擊者未必需要直接獲得用戶私鑰，只要能夠控制交易指令、審批流程或錢包執行系統，就可能觸發未經授權的資產轉移。

而除了資產執行鏈條，另一類風險則更容易被普通用戶低估：資料洩露。

2025 年 5 月，Coinbase 披露了一起內部人員資料竊取事件。攻擊者通過賄賂部分海外客服人員，利用其正常工作權限存取內部客戶支援系統，竊取了一部分用戶的個人資訊、帳戶資料和交易相關資訊。

Coinbase 表示，事件沒有導致用戶密碼、私鑰或資金直接洩露，但攻擊者獲取這些資料的目的，正是為了後續實施精準的社會工程攻擊，冒充官方客服誘導用戶轉移資產。

Keystone 的事件則進一步說明，用戶資料洩露還可能影響硬體錢包的設備真實性驗證。

10 月 20 日，Keystone 官方網站遭到未授權存取，根據其後續披露，攻擊者利用網站第三方資料監控工具中的漏洞，獲取了部分用戶購買記錄，以及用於驗證設備真偽的 WebAuth 密鑰。

這意味著，即使用戶的助記詞和私鑰沒有直接洩露，攻擊者仍可能利用被盜的驗證密鑰製造能夠通過官方認證的仿冒設備，讓用戶在不知情的情況下使用存在風險的硬體錢包。

更不用說 Ledger 所揭露的設備與供應鏈安全問題，還要求廠商必須確保硬體生產、認證、物流和銷售過程中，杜絕設備被替換、篡改或植入惡意模組的可能。

這些問題看似發生在產品不同位置，最終卻可能匯聚到同一個結果，那就是用戶失去對自己資產的控制。

所以，私鑰沒有直接洩露，並不意味著整個產品的安全體系沒有失守，尤其是 AI 的快速發展，也在讓這種風險進一步放大。

二、如何判斷一款加密產品是否安全可靠？

理解了這些事件，再回到普通用戶真正需要面對的問題：如果想選擇一款相對安全可靠的加密產品，究竟應該看什麼？

相比於品牌知名度、產品功能和行銷宣傳，imToken 認為至少有三個維度值得優先考察。

1. 私鑰控制權：資產究竟由誰掌控？

這是判斷加密產品安全架構時，最基礎也最重要的問題。

首先需要區分兩種完全不同的模式：託管與非託管。

以中心化交易所為例，用戶通常通過帳戶體系管理自己的資產。充值之後，資產進入交易所控制的錢包體系，平台通過內部帳戶系統記錄用戶餘額，並負責提現、風控和資金管理。

這種模式的優點是使用方便，用戶不需要自行管理私鑰，但也意味著用戶需要信任平台的資產託管、內部權限和營運管理機制，一旦平台出現系統故障、內部權限失控或資金管理問題，用戶可能無法正常存取或提取資產。

非託管錢包則不同。

用戶創建錢包時，私鑰由本地環境生成，並由用戶自行保管，錢包主要承擔密鑰管理、交易建構和簽名等功能，真正的資產記錄在區塊鏈上。

從結構上看，兩者存在明顯區別：

• 中心化託管： 用戶 → 平台帳戶與權限體系 → 平台控制的錢包 → 鏈上資產；
• 非託管錢包： 用戶掌握私鑰 → 錢包提供管理與簽名工具 → 用戶直接控制的鏈上位址；

這意味著，非託管模式減少了平台作為資產託管人的角色，也減少了用戶必須依賴中心化平台才能控制資產的環節。

當然，這並不意味著非託管錢包絕對安全。

用戶需要自行備份助記詞、保護設備安全，並對每一次交易和簽名負責。一旦助記詞洩露，或者用戶主動簽署惡意交易，資產仍然可能遭到損失。

因此，選擇錢包時，至少應該弄清楚三個問題：私鑰究竟是在用戶設備上生成，還是由伺服器端生成？私鑰和助記詞是否會上傳到服務商伺服器？用戶是否真正掌握簽名權，能否在其他相容錢包中恢復自己的資產？

2. 資料隱私：產品到底收集了多少關於你的資訊？

第二個維度，是很多用戶容易忽略的隱私保護。

在使用加密產品的過程中，用戶可能會留下大量資訊，包括電子郵件、手機號碼、身分驗證資料、設備資訊、購買記錄、物流地址，甚至帳戶餘額和交易歷史。

這些資料並不是每一種產品都必須收集。

例如，中心化交易所由於涉及帳戶體系和合規要求，通常需要進行身分驗證；而一款基礎的非託管錢包，核心功能是本地管理密鑰和發起鏈上交易，並不需要以同樣的方式掌握用戶的真實身分資訊。

這裡最值得關注的，是產品有沒有遵循必要的資料最小化原則。

例如，用戶的真實身分、聯繫方式、設備資訊和鏈上位址，是否存在不必要的關聯？

一旦這些資料被集中儲存，攻擊者就更容易建立完整的用戶畫像，導致「5 美元扳手攻擊」，畢竟再強的加密演算法，也無法解決攻擊者直接找到資產持有人的問題（延伸閱讀《Web3 錢包「多事之秋」：AI 時代，如何理解 Crypto 安全的「矛與盾」演進？》）。

3. 安全架構：有沒有經過持續驗證的安全機制？

第三個維度，是產品背後的技術安全能力。

對於軟體錢包來說，應該重點關注私鑰生成、加密儲存、交易簽名和程式碼安全；對於硬體錢包，則還需要進一步關注安全晶片、韌體完整性、設備認證和供應鏈管理。

但無論是哪一種產品，都有一些可以通用的判斷標準。

首先，核心程式碼是否具備可審查性。開源並不意味著絕對安全，但至少可以讓外部開發者和安全研究人員有機會審查關鍵程式碼。

其次，是否經過獨立安全審計，可以關注產品是否與專業安全機構合作，審計覆蓋哪些模組、對應哪個版本，以及發現的問題是否得到修復。

需要注意的是，審計報告只是特定時間和特定範圍內的安全評估，並不意味著整個產品從此不存在漏洞。

再次，是否建立漏洞獎勵和持續測試機制，因為安全不是一次性工作，隨著產品不斷升級、接入新的鏈和第三方元件，攻擊面也會持續變化，所以是否有公開漏洞回饋管道、漏洞獎勵計畫，以及完善的版本審查和權限管理機制，都是值得關注的指標。

最後，還要看產品是否具備足夠的安全透明度，就像發生安全事件後，能否及時披露影響範圍、攻擊原因、用戶應對措施和修復進度，同樣是衡量一家產品是否值得長期信任的重要標準。

歸根結底，安全審計、開源、硬體隔離和漏洞賞金都不是單獨的護身符。

真正可靠的安全體系，應該能夠把風險尽可能隔離在局部，即使某個環節發生問題，也不至於輕易演變成用戶資產控制權的全面失守。

三、Web3 產品，如何建構長期安全體系？

回到錢包產品本身，以 imToken 的安全理念為例，核心就在於尽可能讓用戶自己掌握資產控制權，同時透過產品架構和持續的安全審查，減少私鑰及敏感資訊暴露的可能性。

1. 非託管架構：讓私鑰真正掌握在用戶手中

與需要集中託管用戶資產的平台不同，imToken 採用非託管錢包架構。

在這一模式下，用戶創建錢包時，私鑰在本地生成，並由用戶自行保管，imToken 不儲存用戶的私鑰和助記詞，也不透過中心化帳戶體系代替用戶控制鏈上資產。

目前 imToken 軟體錢包使用 iOS 和 Android 系統提供的安全隨機數來源，在本地生成私鑰，核心程式碼 TokenCore 也自 2018 年起就已開源。

對於 imKey 硬體錢包，則透過安全晶片內建的真隨機數生成器（TRNG）生成助記詞和私鑰，為密鑰生成提供獨立的硬體安全基礎。

這種設計的意義，不只是讓用戶擁有一份助記詞。

更重要的是，它從架構上減少了服務商接觸和集中管理用戶私鑰的必要性，降低了平台伺服器、內部人員權限或中心化託管系統出現問題時，直接影響用戶資產控制權的風險。

2. 從資料隱私到程式碼審計：安全不止於私鑰

非託管架構解決的是資產控制權問題，但一款錢包仍然需要面對應用程式、伺服器、第三方元件和外部互動帶來的安全挑戰。

在資料隱私方面，imToken 曾公開說明，產品會使用 Sentry、Firebase 等開發工具進行錯誤回報和統計，但不會收集涉及錢包安全的敏感資料，這意味著，必要的產品運行統計與用戶私鑰、助記詞等核心安全資訊，需要在產品設計中保持明確邊界。

在技術審查方面࿰