超越安全儲存：第 1 部分——設計安全的付款與簽署流程

Binance 對其 2026年10月30日 事件的初步說明指出，遭竊的部署權杖使攻擊者得以存取內部簽章服務，並在正常出金流程之外發起交易 [1]。依據已揭露的攻擊路徑，攻擊者無須先取得錢包私鑰，就能請求簽章。

在此情況下，攻擊者瞄準的是系統的簽章能力。包括加密與硬體隔離在內的安全儲存措施可以保護金鑰，卻無法判定一筆付款是否獲得有效的業務授權。這帶出一個問題：未經授權的操作如何取得有效簽章？

要回答這個問題，必須追蹤業務請求如何變成已簽署並執行的交易。透過錢包執行的付款，會依序經過業務授權、交易建構、簽章，以及執行與結算 [2, 3]。下圖除了呈現此工作流程遭濫用的情況，也列出另一條取得簽章能力的路徑：利用密碼學實作缺陷還原金鑰。

超越安全儲存系列透過真實事件，歸納出應對這些風險的設計與實作原則。第 1 部分，設計安全的付款與簽章工作流程，探討攻擊者如何在未取得私鑰的情況下，濫用原有系統的簽章能力。第 2 部分，安全實作錢包密碼學，探討使攻擊者得以還原金鑰並自行簽章的實作缺陷。這兩條路徑都不需要直接竊取受保護的祕密資訊。

第 1 節透過真實事件，檢視付款工作流程中的風險與被忽略的假設，並據此提出設計與實作上的檢查項目。第 2 節假設這些檢查未能阻止未經授權的操作，探討如何限制由此造成的損失。第 3 節說明如何透過設計審查、稽核、滲透測試與演練，驗證預防措施及損失控制措施。

1. 透過設計防止未經授權的操作

同一套付款工作流程可以服務不同的業務目的。下圖以三種具代表性的託管操作為例：入金用來確立帳戶權益，出金依據客戶指示辦理，資金庫轉帳則執行機構的資金調度決策。

經驗證的入金會產生帳戶入帳記錄，而不會自動構成付款指示。出金需要獨立的客戶請求與核准；資金庫轉帳則始於機構的資金調度決策。兩者之後都會經過交易建構、簽章、執行與結算。在資產集中託管的模式下，帳本記錄客戶權益，但不要求資產留在每位客戶的專屬地址。

三種具代表性的託管操作。功能分離本身並不代表身分或權限邊界彼此獨立。

這些操作移動資金的理由各不相同。其他業務操作也可能經過相同階段，但需要不同的佐證或核准。在每個階段，安全上的關鍵問題都是：付款依據、交易、簽章權限的使用及結算，是否仍符合原定操作。

每個階段都可能成為攻擊者影響簽署或執行內容的切入點。偽造的請求可能製造出表面上的付款義務；交易建構可能置入未經核准的操作；權限遭入侵可能使攻擊者取得簽章權限；執行或結算環節的失誤則可能讓不該繼續有效的權限仍可使用，或觸發沒有正當依據的付款。

下表將風險對應至工作流程階段，以及用來檢視風險的案例。

1.1 付款依據與授權

付款進入交易建構與簽章階段之前，機構必須確認請求真實、請求人有權動用該筆資金，且指定操作已獲有效核准。僅有客戶餘額或經過身分驗證的內部請求，並不足以確立這三項條件。

失效案例：偽造付款依據

在 Bitget 於 2026年9月24日 發生的事件中，攻擊者利用一款第三方安全產品取得高權限的內部憑證。根據 Bitget 的官方說明，這些憑證被用來向錢包系統發送詐欺性的出金指令，導致轉帳繞過其既有風控措施 [4]。這些指令透過內部存取權限進入付款流程，但該存取權限並不能證明存在正當的客戶指示或資金庫決策。

BigONE 披露，其熱錢包於 2025年7月16日 發生未經授權的資金轉移，並表示私鑰仍然安全。BigONE Eurasia 將全球平台的這起事件歸因於正式環境中的帳戶與風控邏輯遭到變更 [5, 6]。這指出一個相關問題：用來證明付款有正當依據的記錄與規則，本身也可能遭到竄改。公開說明並未揭露請求記錄或簽章 API 的細節，因此無法據此認定其攻擊機制與 Bitget 相同。

這些案例揭示了將內部存取權限或帳戶記錄視為充分付款依據的風險：攻擊者可能竄改付款決策所依賴的憑證、記錄或規則。

應驗證的控制措施

因此，設計與實作審查應檢查每項請求是否都能追溯至真實的業務依據，以及提交請求的一方是否也能偽造其佐證記錄或自行核准請求。

• 驗證請求的來源、完整性與授權。 每筆付款都必須能追溯至真實的客戶指示、業務事件或機構決策，並有資金動用權及核准的證據。應驗證請求及其佐證記錄的變更是否始終可追溯，且偽造或遭竄改的證據不會僅因來自內部服務或與帳戶餘額相符，就足以確立授權。
• 讓驗證與核准獨立於請求建立程序。 提交請求的一方不得同時有能力偽造佐證資料或核准請求。在作業權限與管理權限上都應維持這種區隔。應驗證記錄、核准規則或角色指派的變更（包括人工例外處理及復原程序），是否可能讓同一方同時控制請求，以及原本應用來否決該請求的檢查機制。

付款依據經獨立確認後，下一個問題是交易是否表達了獲核准的操作。

1.2 交易建構與驗證

付款請求獲核准後，交易建構程序會將其轉換為提交簽章的未簽署資料。完整的交易資料——包括目的地、金額、操作，以及對錢包控制權的任何變更——都必須表達獲核准的請求。核准轉帳並不等於授權其他操作；驗證時必須檢查實際待簽署的資料，而不能只看介面上的描述。

失效案例：已簽署的操作與核准內容不符

Bybit 原本打算將 ETH 從冷錢包轉入溫錢包。其官方更新指出，入侵事件源於 Safe 開發人員憑證遭到盜用，攻擊者因此得以存取該服務供應商的基礎設施，並欺騙簽署者 [7]。Safe 透過 execTransaction，驗證涵蓋 to、value、data 和 operation 等交易欄位的簽章 [15]。但遭入侵的介面保留了預期轉帳的外觀，卻在簽署前替換了惡意欄位。這些簽章對替換後的位元組而言是有效的 [7]。

最終產生的交易使用 DELEGATECALL 更改錢包的實作，使攻擊者無須取得原持有者的新批准，就能轉走資產 [7, 8]。獲批准的業務操作是轉帳；實際簽署的操作卻改變了誰能控制錢包。僅檢查畫面顯示的收款方或交易當下轉移的金額，無法確認完整操作是否與批准內容相符。

Kiln/SwissBorg 事件顯示，惡意交易也可能透過修改執行中的交易建構服務而被引入。Kiln 表示，遭盜用的 GitHub 權杖經由 CI 工作流程，讓攻擊者取得正式環境憑證。攻擊者修改了執行中的 Kubernetes pod，而未變更其已部署的映像檔，使其在回傳合法的 Solana 質押停用交易時，一併回傳一筆變更提領權限的交易。客戶的託管簽署者批准了新增的交易；Kiln 指出，簽署發生於 8 月 31 日，事件則於 2025年9月8日 被發現 [9]。SwissBorg 也將交易遭竄改歸因於服務供應商的基礎設施。雙方對當時可用的解碼工具是否易於使用，以及其整合情況，意見並不一致 [10]。

應驗證的控制措施

Bybit 和 Kiln/SwissBorg 事件顯示，交易可能偏離簽署者原本打算批准的內容。系統設計必須將批准與完整操作綁定，且驗證時必須獨立於建構或顯示交易的服務，檢查實際交易。

• 將批准與完整操作綁定。 批准必須涵蓋交易的全部效果，包括資產控制權的任何變更，或執行權限的委派 [16]。超出該範圍的變更需要重新批准。應驗證替換或新增的操作無法沿用合法付款的批准，重試也無法重複使用同一項批准來授權額外付款。
• 獨立驗證交易及其效果。 將實際提交供簽署的資料與獲批准的業務操作比較，涵蓋一批交易中的每一筆交易，以及它們對資產和權限的影響。驗證作業必須獨立於建構或顯示交易的服務。應檢查該服務能否修改驗證機制或繞過其檢查，以及具有誤導性的顯示內容或遭修改的交易是否會被拒絕。

上述檢查處理的是交易是否符合獲批准的請求。簽署階段則帶出另一個問題：是否有人能直接使用金鑰，或透過變更存取權限，在沒有必要業務授權的情況下使用金鑰？

1.3 簽署授權與金鑰使用

經驗證的交易必須透過獲授權的呼叫方送達簽署服務。金鑰政策和管理角色決定誰能使用相關金鑰，以及誰能變更該存取權限。擁有呼叫簽署功能的權限，不代表所有交易都獲得授權；管理服務的權限也不得形成未受檢查的簽署途徑。因此，這個階段同時涵蓋為獲批准的操作使用金鑰，以及對金鑰存取權限的控制。

失效案例：簽署存取權限遭入侵

Resolv 於 2026年3月22日 發生的事件顯示，變更金鑰存取政策如何開啟一條簽署途徑。其代幣鑄造流程要求使用者存入抵押品，並由獲授權的鏈下服務完成發行。官方事後檢討報告指出，攻擊者在先前的存取嘗試遭拒後，透過程式碼儲存庫和雲端存取權限取得更高權限的角色，進而變更簽署金鑰的存取政策。該變更使攻擊者在一項同時要求身分層級權限及金鑰層級存取政策的雲端金鑰管理服務中，取得簽署權限 [11]。

變更誰能簽署，讓攻擊者不必說服原簽署者，就能授權不符合預期抵押品關係的發行。這份事件說明證實的是攻擊者控制了簽署權限，而非取得了原始私鑰資料。

Binance 對 2026年10月30日 事件的初步更新，描述了另一條取得簽署權限的途徑。據 Binance 表示，員工裝置及一項內部 AI 工具遭入侵，使攻擊者得以存取錢包工程師的裝置；攻擊者隨後使用竊得的容器部署權杖部署容器，並執行惡意指令碼。攻擊者未經授權存取了內部錢包簽署服務，並發起正常出金流程以外的交易 [1]。這份說明將部署權限與簽署服務的存取權限連結起來，但未揭露具體繞過了哪些內部權限檢查。與 Resolv 通報的金鑰政策變更不同，此處披露的入侵途徑是簽署服務的執行環境。

應驗證的控制措施

這些案例揭示了在預期業務流程之外取得或使用簽署存取權限的風險。審查應確認每一條簽署途徑都會執行業務授權檢查，包括透過政策變更或部署權限開啟的途徑。

• 在每一條簽署途徑上執行業務授權檢查。 擁有金鑰使用權限，不代表特定操作已獲授權 [17, 18, 19]。應將金鑰使用限制在獲批准的業務範圍內，並驗證其他呼叫方或直接存取方式無法繞過該限制。授權檢查的執行必須獨立於能提交任意簽署請求的呼叫方。若某條途徑無法執行此項要求，應記錄該缺口，並依第 2 節評估其後果。
• 控管簽署權限的變更。 即使某個身分一開始無法簽署，管理和部署權限仍可能讓其取得簽署存取權限 [20, 21, 22]。應將金鑰使用權限與變更簽署政策、身分或已部署程式碼的權限分開，並要求這些變更取得獨立批准。應驗證任何一方都無法利用其合併持有的權限，授予自己簽署存取權限，或移除規範該存取權限的業務檢查。

授權檢查不能在簽章產生時就結束：交易仍須在獲批准的條件內執行，且其結果必須正確結算。

1.4 執行與結算

簽署後，授權仍須持續有效，涵蓋廣播、執行，以及相關業務紀錄與餘額預留的結算。簽章不代表付款已完成。執行必須維持在授權範圍及有效條件內；結算則必須確定哪一項義務已履行，以及是否確實仍須支付另一筆款項。僅憑既有簽章或觀察到的轉帳，無法確立新的付款義務。

失效案例：已簽署權限遭濫用與結算回饋

Drift 的案例說明，具有誤導性的簽署請求如何留下日後可用的權限。在其 2026年4月1日 事件中，預先取得的批准被保留在 Solana 持久化 nonce 交易中，之後再提交這些交易，以接管管理權限 [12]。持久化 nonce 控制交易的有效性，與密碼學簽署所使用的秘密 nonce 不同。它支援離線或延後提交，而不受一般近期區塊雜湊值的到期限制；不過，帳戶或程式狀態的變更仍可能阻止交易執行。推進持久化 nonce 會使綁定舊值的交易失效 [23]。

Drift 於 4 月 16 日發布的復原更新，提議使用專用簽署裝置、在主要簽署介面之外進行驗證、對關鍵管理操作設置時間鎖，以及為簽署者停用持久化 nonce [24]。這些措施同時處理簽署者批准的內容，以及已簽署操作可於何時執行。它們是作為復原計畫對外公布的；該更新並未證實這些措施當時已部署。

Chainflip 區分客戶兌換、流動性提供者（LP）出金，以及稱為 fetch 的內部存款歸集作業 [25]。在 Tron 上，交易備註可承載兌換指令。Chainflip 在 9 月 15 日就其於 2026年9月12日 發生的事件所發表的說明中指出，攻擊者提交了一筆由驗證者簽署、帶有攻擊者控制的格式錯誤備註的 fetch。見證層將其情境誤判為失敗的兌換，除了正常的 LP 出金外又發放退款，導致六筆出金各被支付兩次 [13, 14]。

這項錯誤使內部資產轉移被當成新增客戶付款義務的證據。即使轉入 Chainflip 金庫的轉帳包裹在其他合約呼叫中，Chainflip 仍會解讀其備註。其修正措施將兌換備註的解讀範圍限於一般 TRX 轉帳或直接的 TRC-20 轉帳，排除包裹在其他呼叫中的轉帳 [14]。經有效簽署的 fetch 有其自身用途；執行該作業並不足以構成額外退款的理由。

應驗證的控制措施

已簽署的交易可能在超出預期的時間內仍可執行，而執行回饋也可能被誤認為新的付款義務。因此，審查時應確認執行條件確實受到強制執行，且每筆付款或退款都對應一項真實、尚未結清的義務。

• 強制執行核准的執行條件。 已簽署的交易仍須受核准範圍、有效期間及取消條件約束。驗證舊交易在到期、取消或授權變更後是否仍能執行。將相關條件綁定至已簽署的作業，並驗證鏈上規則或錢包執行邏輯會強制執行這些條件；僅有業務系統中的紀錄並不足夠。
• 僅結清真實且未清償的義務。 每筆付款或退款都必須對應一項真實且尚未結清的義務。保留原始業務事件、付款嘗試與已確認結果之間的關聯。驗證重試、重複通知、不確定的結果或內部轉帳不會產生缺乏正當理由的付款，且解讀執行證據的規則無法被修改來規避這些檢查。

2. 以限制損失並支援事件應變為目標的設計

第 1 節利用事件證據，找出工作流程風險，以及處理這些風險所需的設計與實作檢查。此處假設這些檢查因遺漏、實作錯誤或遭到繞過，而未能阻止未經授權的作業。此時，設計必須限制攻擊者可轉移的金額、計入仍處於風險中的資金，並保有偵測濫用及阻止進一步資金流出的能力。這些損失控制措施必須與預防性控制措施一同在事件發生前完成設計與測試。

下表概述限制損失及支援事件應變的三項設計目標。

2.1 獨立強制執行的支出限額

即使未經授權的付款通過前述檢查，系統仍應限制該筆及後續付款可轉移的總金額。這需要在假定攻擊者可控制的範圍之外強制執行預算，同時涵蓋單筆交易與累計支出。如果遭入侵的核准服務或簽署者能停用或繞過已設定的限額，該限額就無法限制損失。

• 獨立於付款核准程序強制執行限額。 通過授權檢查的付款仍須受到在假定攻擊者可控制的範圍之外強制執行的支出限額約束。驗證每一條簽署與執行路徑（包括替代執行路徑 [26, 27]）都遵守這些限額，且攻擊者無法變更或停用限額的強制執行機制。若無法強制執行獨立限額，就不要將已設定的預算描述為損失上限。
• 限制累計支出，而非僅限制單筆付款。 定義每項預算的適用範圍、期間與估值基準，並一致核算已完成的付款及預留金額。驗證重複請求、並行處理與重試合計不會超出預算，也不會過早解除預留。若限額取決於資產價格，須驗證遭操縱、過時或無法取得的價格不會拉高允許的支出金額。

2.2 資金存量、補充資金與尚未執行的已簽署交易

接下來的問題是，在機構偵測並控制攻擊的期間，哪些資金仍面臨風險。錢包餘額、補充資金及尚未執行的已簽署授權決定了這項風險敞口，其中也包括事件開始後流入的資金。應將這些因素與第 2.1 節所述可強制執行的限額一併評估；僅憑目前餘額無法估計損失。

• 限制攻擊者可能存取的資金。 評估受影響簽署授權可觸及的全部資產範圍，包括其他錢包、鏈與合約。納入現有餘額與後續流入的資金。補充資金必須經過獨立授權，並受到累計限額約束。驗證反覆的資金流出不會觸發財庫持續補充資金，且能夠重新導向或停止新增資金，同時不忽略仍會流入的存款。
• 納入受尚未執行的已簽署授權影響的資金。 停止新的簽署，不一定會使已發出的交易或授權失效。辨識這些交易或授權仍可轉移的資金，同時避免重複計算同一批資產。驗證已確認的付款會記錄為已支出，並核對其預留金額；未執行交易的預留金額則應維持，直到可靠證據確認交易已無法執行。僅憑本地端逾時或取消請求，不得降低已記錄的風險敞口。

2.3 獨立監控與事件應變

限額與資金補充控制措施限制潛在損失；監控與應變則決定攻擊者能持續行動多久。機構需要能揭露濫用行為的證據，即使付款服務將這些作業視為有效亦然；也需要在一般作業環境無法使用或遭入侵時，仍可運作的應變途徑。

Binance 的初步說明顯示，僅關閉應用程式未必能達到這個目的：關閉應用程式並未清除既有的 EIP-7702 委託。撤銷委託需要鏈上交易，而且在其 MPC 部署架構中，還需要一套另外設計的程序 [1]。這是該部署架構的限制，而非 MPC 本質上無法撤銷授權。因此，偵測與控制需要分別驗證：可靠的證據必須導向能實際切斷損失途徑的行動。

• 運用受到獨立保護的證據偵測未經授權的活動。 比對業務核准、簽署活動與執行結果，並監控權限及控制規則的變更。受影響的服務不得能夠改寫監控所依據的證據。驗證工作流程接受的作業在與業務授權不符時，即使本地紀錄缺失或遭操縱，仍能觸發可據以採取行動的告警。
• 確保應變控制措施可用且有效。 維持獨立的權限，以停止新的簽署與資金注入，並在支援的情況下使尚未執行的交易失效，或撤銷持續有效的授權。驗證在一般作業存取途徑無法使用或遭入侵時，仍能採取應變行動，且這些行動確實能阻止進一步的資金流出。辨識剩餘的風險敞口及與外部協調的需求；停止應用程式本身不會撤銷已簽署的授權，也不能假定資產可以追回。

3. 驗證設計與實作

前文各節探討工作流程中的檢查能否防止未經授權的操作，以及當這些檢查未能奏效時，能否限制損失。驗證工作必須在已部署的系統中檢視這兩項目標，包括各項控制措施如何在整個資金流轉過程中相互作用。以下方法可提供相互補充的證據：

• 架構與安全設計評估檢查資金流轉、權限邊界和控制措施之間的依賴關係，是否有助於達成預期的防範及損失控制目標。評估應明確列出控制措施獨立性及損失上限所依據的假設。
• 程式碼與設定稽核驗證已部署的程式碼、設定和權限是否落實預期的檢查，包括可能繞過檢查的例外情況和替代路徑。
• 滲透測試檢視應用程式與基礎設施中的弱點，是否可能被組合利用，以繞過授權或損失控制措施。測試範圍應涵蓋完整的資金流轉路徑，而非止於個別元件。
• 攻擊與應變演練驗證監控能否促成及時行動，以及支出限額、暫停機制與權限撤銷能否協同運作。演練應釐清仍有多少資金面臨風險，以及達成有效控制需要多久。

針對每個驗證情境，應說明哪項操作應遭拒絕，或哪種損失應受到控制，並列出對攻擊者能力的假設。記錄觀察到的結果、任何剩餘的風險敞口，以及所聲稱損失上限成立的條件。程式碼、設定或權限發生重大變更後，應重複執行相關檢查。

第三方安全團隊或專家可在這些評估、稽核、測試和演練中，與內部團隊形成互補。他們的審查應涵蓋支付邏輯、簽名基礎設施與營運權限如何相互作用，並為系統的防範及損失控制能力提供證據。

4. 結論

本文探討的攻擊揭示了從最初的付款請求，到交易建構、簽名、執行及結算各階段的授權失效問題。這些攻擊也顯示，當攻擊者突破防線後，系統需要具備哪些能力才能限制損失。由此得出的設計原則涵蓋防範、損失控制，以及實際評估這兩者所需的測試。

核心結論是，保護私鑰本身並不能確保已簽名的操作獲得授權。實際執行的操作必須與真實的業務決策一致；當工作流程中的檢查未能阻止未經授權的操作時，獨立的控制措施則必須限制其後果。這需要檢視完整的工作流程，包括能夠變更其中檢查機制的權限，以及偵測並阻止進一步損失所需的工具。

本文分析聚焦於濫用原系統簽名能力的情況。第 2 部分安全實作錢包密碼學將探討另一種途徑：實作缺陷讓攻擊者無須直接竊取受保護的秘密資訊，就能預測或還原私鑰，進而在原工作流程之外簽名。

參考資料

• [1] Binance，中文：2026年10月30日 安全事件：初步調查結果與應變進展（2026年11月3日）；英文：2026年10月30日 安全事件：初步調查結果與應變進展（2026年11月3日）。
• [2] BlockSec，加密貨幣支付的金鑰管理與營運安全。
• [3] BlockSec，加密貨幣支付系統架構：6 個層級及資金如何在其中流轉。
• [4] Bitget，Bitget 遭駭事件解析：時間線、影響與安全應變（更新於 2026年10月20日）。
• [5] BigONE，關於 2025年7月16日 BigONE 安全事件的公告。
• [6] BigONE Eurasia，平台暫時維護（2025年7月16日）。
• [7] Bybit，確認在 Safe{Wallet} 事件期間安全性未受影響（2025年2月26日）。
• [8] BlockSec，Bybit 15億 USD 遭駭事件：惡意 Safe 錢包升級攻擊的深入分析。
• [9] Kiln，Kiln 服務重新啟用與安全事件資訊（2025年10月7日）。
• [10] SwissBorg，關於 2025 年 9 月 8 日 Kiln 遭入侵事件及其對 SwissBorg 影響的安全資訊。
• [11] Resolv，Resolv 事件事後檢討：2026年3月22日 事件（2026年4月4日）。
• [12] BlockSec，Drift Protocol 事件：利用持久化隨機數破壞多簽治理。
• [13] Chainflip，Tron USDT 漏洞遭利用：發生了什麼，以及接下來會如何發展（2026年9月13日）。
• [14] Chainflip，讓 Chainflip 恢復運作（2026年9月15日）。
• [15] Safe，execTransaction。
• [16] Ethereum，EIP-7702：為 EOA 設定程式碼。
• [17] AWS KMS，Sign API。
• [18] Google Cloud KMS，cryptoKeyVersions.asymmetricSign。
• [19] Azure Key Vault，Sign API。
• [20] Google Cloud KMS，職責分離。
• [21] Google Cloud IAM，服務帳戶驗證所需的角色。
• [22] AWS IAM，授予將角色傳遞給 AWS 服務的權限。
• [23] Solana，使用隨機數進行持久化與離線交易簽名。
• [24] Drift，事件復原進度更新（2026年4月16日）。
• [25] Chainflip，EVM（Ethereum）金庫設計。
• [26] Safe，守衛。
• [27] Safe，模組。