~$400萬損失：Taiko、SecondFi遭攻擊

在過去一週（2026/06/22 - 2026/06/28），共發現 2 起值得關注的安全事件，造成約 $4.1M 的確認損失。

日期	事件	類型	估計損失
2026/06/22	Taiko	金鑰洩露與驗證不完整	~$1.7M
2026/06/23	SecondFi	密碼學實作缺陷	~$2.4M

Taiko：攻擊者結合已洩露的 SGX enclave 簽署金鑰與不完整的attestation 政策，將惡意 prover 註冊為已授權的實例，說明僅憑有效的 attestation 本身並不足夠，還需要全面的屬性執行機制。
SecondFi：密碼學實作缺陷使攻擊者僅憑公開的交易資料即可還原位址層級的簽署金鑰，說明看似微小的 Ed25519 規範偏差如何導致金鑰完全洩露。

每週重點：Taiko 事件

Taiko 事件之所以被列為重點，是因為此次攻擊結合了兩個獨立的安全缺陷（已洩露的 enclave 簽署金鑰與不完整的 attestation 政策），進而破壞了一套基於 SGX 的證明驗證系統。此事件說明 TEE 信任鏈的每一層都必須獨立執行其安全屬性；有效的 attestation 簽章鏈無法彌補未受檢查的執行期屬性所帶來的風險。

2026 年 6 月 22 日，Taiko 基於 SGX 的證明驗證流程在以太坊上遭到利用，造成約 $1.7M 的損失 [1]。攻擊者使用已洩露的 enclave 簽署私鑰（該私鑰曾被提交至公開的 GitHub 儲存庫），為以 DEBUG 模式啟動的 prover enclave 簽署 SIGSTRUCT。由於鏈上 attestation 合約並未拒絕 DEBUG 模式的 enclave，攻擊者得以註冊為已授權的實例，提交偽造的證明資料，並使 L1 合約接受一個不存在的 L2 狀態，進而釋放橋接資金。

背景

Taiko 是一個以太坊 Layer-2 rollup，其跨鏈橋依賴一套證明系統來決定是否接受特定的 L2 狀態或跨鏈訊息。作為此證明系統的一部分，Taiko 使用 SGX prover：在實體機器的 SGX enclave 中執行的鏈下程式，以受 enclave 保護的金鑰對證明結果進行簽署。

鏈下（實體機器）                            鏈上（以太坊）
┌─────────────────────────┐                ┌────────────────────────────────────┐
│  SGX Prover Enclave     │                │  SgxVerifier                       │
│  - 產生證明             │── DCAP quote ─→│  ├─ registerInstance()             │
│  - 持有實例金鑰         │                │  │  └─ AutomataDcapV3Attestation   │
│                         │── 已簽署的證明→│  └─ verifyProof()                  │
└─────────────────────────┘                └────────────────────────────────────┘

SGX 與 DCAP 概述

SGX 的核心概念是 enclave：一個由 CPU 隔離的程式環境。MRENCLAVE 是對 enclave 初始程式碼、資料、分頁佈局及相關元數據的量測值；可近似理解為 enclave 建置的雜湊值。MRSIGNER 是 enclave 簽署公鑰的雜湊值，代表發布者身份。

enclave 簽署私鑰用於對 SGX SIGSTRUCT 進行簽署，其中包含 enclave 的元數據，例如 MRENCLAVE、ISVPRODID、ISVSVN 與 ATTRIBUTES。此簽章並非由鏈上合約驗證，而是在 enclave 初始化時的 EINIT 階段由 SGX 硬體進行驗證。CPU 會確認 SIGSTRUCT 簽章有效，且其中的 MRENCLAVE 與實際載入的 enclave 量測值相符。唯有在此驗證通過後，enclave 才能完成初始化，並產生後續的報告與 quote。

Intel SGX DCAP v3 quote 是一個遠端 attestation 封包，包含三個部分：

header：元數據，例如 quote 版本、attestation 金鑰類型、QE/PCE SVN 及供應商資訊。
localEnclaveReport：受 attest 的應用程式 enclave 身份資訊，包括 MRENCLAVE、MRSIGNER、ATTRIBUTES、ISVPRODID、ISVSVN 及 reportData。reportData 是一個 64 位元組的值，由 enclave 在產生報告時寫入。Taiko 將 prover 實例位址儲存於 reportData 的前 20 個位元組中。
v3AuthData：quote 的真實性證明，包括 quote 簽章、attestation 金鑰、QE 報告、QE 報告簽章及 PCK 憑證鏈。

鏈上 Attestation

鏈上 attestation 合約（AutomataDcapV3Attestation，負責遠端 attestation）透過 Intel DCAP 憑證鏈驗證 quote 的真實性。儘管憑證鏈中的發行者公鑰是作為外部提交的 quote 的一部分提供的，合約仍會逐步驗證整條鏈，並要求最終發行者公鑰的雜湊值與合約中固定的 Intel SGX Root CA 公鑰雜湊值相符 [2]。透過此憑證鏈，合約確認受 quote 簽章覆蓋的 localEnclaveReport 並未在 calldata 中被任意修改。

Taiko Prover 註冊

SGX prover 實例必須先透過 SgxVerifier.registerInstance() 完成註冊。在註冊過程中，呼叫者需提交一個 DCAP quote。SgxVerifier 將 quote 驗證委派給 AutomataDcapV3Attestation.verifyParsedQuote()。若 quote 通過驗證，SgxVerifier 會讀取 localEnclaveReport.reportData 的前 20 個位元組作為實例位址，並將其加入已授權的實例集合。

簽章驗證流程可簡化為三層：

SGX CPU 在 EINIT 期間驗證 SIGSTRUCT 簽章，確認 enclave 的 MRENCLAVE 及簽署者身份。
DCAP 憑證鏈與 QE 報告對 quote 簽署金鑰進行鑑別。AutomataDcapV3Attestation 再使用該金鑰驗證 quote 簽章，並建立對 localEnclaveReport 的信任。
Taiko 的證明驗證器使用已註冊的實例位址來驗證後續的證明簽章，並決定是否接受對應的 L2 狀態或跨鏈訊息。

漏洞分析

此事件的根本原因是一個操作失誤與一個合約層級漏洞的組合。兩者缺一不可，攻擊才得以成功。

操作失誤：enclave 簽署金鑰洩露。 Taiko/Raiko 用於簽署 SGX SIGSTRUCT 的 enclave 簽署私鑰被提交至公開的 GitHub 儲存庫。MRSIGNER 是對應簽署公鑰的雜湊值。任何取得此私鑰的人都可以對 prover enclave 的 SIGSTRUCT 進行簽署，使產生的 quote 中的 MRSIGNER 與 Taiko 的允許清單相符。

合約漏洞：缺少 ATTRIBUTES 檢查。 在 MRSIGNER 相符的情況下（透過洩露的金鑰通過允許清單），攻擊者可以 DEBUG 模式啟動相同的已核准 enclave，而無需更改 MRENCLAVE（DEBUG 旗標並非 MRENCLAVE 的一部分）。attestation 政策本應捕獲此情況，但 AutomataDcapV3Attestation（0x5e46...dd72）並未檢查應用程式 enclave 的 localEnclaveReport.attributes。DEBUG 模式的 enclave 允許宿主機或除錯器讀取或修改 enclave 記憶體，這意味著原本應受 SGX enclave 保護的實例簽署金鑰不再安全。

這兩個條件共同作用，意味著任何一方都可以用 DEBUG 模式啟動相同的 prover enclave 程式碼（產生與合法建置相同的 MRENCLAVE），並利用洩露的簽署金鑰簽署一個使 MRSIGNER 與 Taiko 允許清單相符的 SIGSTRUCT。產生的 quote 同時滿足 MRENCLAVE 與 MRSIGNER 的允許清單，同時帶有未受檢查的 DEBUG 屬性。由於 AutomataDcapV3Attestation 並不拒絕 DEBUG 屬性，此類 quote 可通過 verifyParsedQuote()，之後 SgxVerifier 便將實例位址加入已授權的實例集合。

DEBUG 模式的 enclave 不會保護其記憶體不被宿主機或除錯器存取。因此，在 enclave 內部產生的實例私鑰可被提取出來。持有該金鑰的人可以對任意證明資料進行簽署，而 L1 合約將予以接受，進而實現偽造的 L2 狀態轉換，並從金庫（0x9962...15ab）中未經授權地釋放橋接資金。

攻擊分析

攻擊者提交了多筆交易。以下分析基於兩筆具代表性的交易：第一筆將攻擊者註冊為已授權的實例（0x2f44dc...277260），第二筆執行偽造的證明以竊取資產（0x017292...ae35ee）。

步驟一：使用已洩露的 enclave 簽署金鑰對 SIGSTRUCT 進行簽署，使 quote 的 MRSIGNER 與允許清單相符。
步驟二：以 DEBUG 屬性執行 enclave。DEBUG 不會改變 MRENCLAVE，但會反映在 localEnclaveReport.attributes 中。
步驟三：呼叫 registerInstance() 並提交一個真實的 SGX quote。該 quote 的 attributes = 0x07...，其中包含 DEBUG 位元（0x02），但 AutomataDcapV3Attestation 並未檢查此欄位，因此 verifyParsedQuote() 回傳 true。

步驟四：從 SGX enclave 記憶體中提取實例私鑰（因為 DEBUG 模式停用了記憶體保護），並用其對惡意證明資料進行簽署。
步驟五：提交精心製作的證明，使 L1 合約接受一個不存在的 L2 狀態，並從金庫中竊取資產。

結論

完整的 SGX attestation 政策至少應：

在生產環境中拒絕帶有 SGX_FLAGS_DEBUG 的 enclave。
檢查 MRENCLAVE、MRSIGNER、ISVPRODID 與 ISVSVN。

若接受 DEBUG 模式的 quote，硬體本身可能仍在正常運作，但其所提供的記憶體保護語義已不再有效。enclave 簽署金鑰也絕不能提交至公開的儲存庫。已洩露的簽署金鑰允許任何人產生具有相符 MRSIGNER 的二進位檔案，使 attestation 政策僅剩 MRENCLAVE 與屬性執行作為防護屏障。

更廣泛而言，對於任何依賴 TEE 的系統，attestation 不能止步於確認簽章鏈有效且量測值在允許清單內。信任鏈的每一層都必須獨立執行其安全屬性。

參考資料

[1] Phalcon 警報：Taiko 跨鏈橋攻擊偵測
[2] Intel SGX 開發者指南

本週其他事件

SecondFi 事件

2026 年 6 月 23 日，由 EMURGO 開發的 Cardano 錢包 SecondFi（前身為 Yoroi）披露了其 Ed25519 簽署實作中的一個嚴重漏洞 [1]。該錢包的簽署實作僅從公開的交易訊息中計算簽署 nonce，省略了必要的秘密輸入。這使數位簽章淪為一個單方程式問題，讓攻擊者得以從公開的鏈上資料還原位址層級的私鑰。兩名分別行動的攻擊者利用此漏洞，從 374 個錢包中共榨取約 $2.4M（1,600 萬 ADA）[2]。

背景

SecondFi 是 Cardano 區塊鏈的自託管錢包，於 2026 年 4 月由 Yoroi 更名而來。Yoroi 最初由 Cardano 三個創始實體之一的 EMURGO 開發，曾服務超過百萬名用戶。

Ed25519 是 Cardano 用於交易授權的數位簽章方案。簽署者持有一個簽署純量 $k_{L}$ （特定位址的私鑰）以及與相同金鑰材料關聯的秘密 nonce 前綴 $k_{R}$ 。對於給定的訊息 $M$ （交易負載），簽署 nonce 的計算方式為 $r = \operatorname{SHA-512}(k_R \mathbin\Vert M) \bmod L$ 。由於 $k_{R}$ 是秘密的，即使 $M$ 在廣播後公開，觀察者仍無法得知 $r$ 。

nonce 點 $R = r \cdot B$ （其中 $B$ 是固定的 Ed25519 基點）以及簽章純量 $s \equiv r + H \cdot k_L \pmod{L}$ （其中 $H = \operatorname{SHA-512}(R \mathbin\Vert A \mathbin\Vert M) \bmod L$ 將 nonce、公鑰與訊息綁定在一起）共同構成最終簽章 $(R, s)$ 。此方案的安全性取決於 $r$ 的不可預測性：若觀察者能計算出 $r$ ，簽章方程式便成為一個可解出 $k_{L}$ 的單未知數線性方程式。

漏洞分析

此漏洞存在於 SecondFi 的錢包簽署軟體中，而非智能合約。

結合現有分析 [2] 及我們自身的調查，我們發現 v10.0.3 至 v10.0.6 版本（自 2026 年 6 月 8 日起上線；已於 v10.0.6.2 中修復）受到影響。有漏洞的實作將簽署 nonce 計算為：

r = \operatorname{SHA-512}(M) \bmod L

而非正確的：

r = \operatorname{SHA-512}(k_R \mathbin\Vert M) \bmod L

這移除了 nonce 推導中唯一的秘密輸入（ $k_{R}$ ）。由於 $M$ 是公開的，任何人都可以為受影響位址所簽署的任何交易重新計算 $r$ 。

在已知 $r$ 的情況下，簽章方程式 $s \equiv r + H \cdot k_L \pmod{L}$ 變得可解：

k_L \equiv (s - r) \cdot H^{-1} \pmod{L}

右側的所有值均為公開的，或可從鏈上簽章與交易資料中計算得出。這並非逆轉雜湊或從 $A = k_L \cdot B$ 解決離散對數問題；有缺陷的實作直接暴露了 $r$ ，使金鑰還原淪為直接的模運算。

影響範圍為位址層級的金鑰洩露。任何透過有漏洞的實作產生簽章的位址，都應被視為已遭洩露。

將相同的助記詞匯入已修補的錢包並不能保護已暴露的位址；資金必須轉移至一個從未透過有漏洞的簽署實作進行簽署的全新生成金鑰。

攻擊分析

此攻擊不遵循具有可追蹤智能合約互動的典型鏈上攻擊流程。由於該漏洞在公開資料與簽署金鑰之間暴露了一種確定性關係，金鑰還原是在鏈下離線執行的。

步驟一：識別曾使用 SecondFi v10.0.3 至 v10.0.6 簽署交易的目標位址。
步驟二：針對每個目標，取得交易的公開簽章元件（ $R$ 、 $s$ ），並從鏈上交易負載中重建訊息 $M$ 。
步驟三：計算簽署 nonce $r = \operatorname{SHA-512}(M) \bmod L$ ，利用有漏洞的簽署實作省略了秘密 nonce 前綴 $k_{R}$ 這一事實。
步驟四：計算挑戰純量 $H = \operatorname{SHA-512}(R \mathbin\Vert A \mathbin\Vert M) \bmod L$ 。
步驟五：求解簽署純量： $k_L \equiv (s - r) \cdot H^{-1} \pmod{L}$ 。
步驟六：使用還原的 $k_{L}$ 對來自已洩露位址的任意交易進行簽署，並將資金轉移至攻擊者控制的錢包。

兩名攻擊者各自獨立利用了此漏洞。其中一人分兩波攻陷了 171 個錢包，另一人則在單獨的掃蕩中榨取了 203 個錢包，合計提取了約 1,600 萬 ADA（約 $2.4M）[2]。EMURGO 隨後在攻擊者觸及之前，搶先救回了另外 1.29 億 ADA。

結論

根本原因是一個密碼學實作缺陷，該缺陷從 Ed25519 的 nonce 推導中移除了秘密 nonce 前綴，使簽署 nonce 淪為公開資料的確定性函數。每一個受影響的簽章都成為了一個可解的單方程式金鑰還原問題。

此事件凸顯了錢包開發者應使用經過充分審計的標準 Ed25519 函式庫，而非自定義簽署實作。任何偏離規範的做法，即使看似微小，例如省略單個雜湊輸入，都可能導致整個金鑰遭到洩露。生產環境的簽署軟體在部署前應接受獨立的密碼學審計，尤其是在處理金鑰推導與簽署操作時。

參考資料

[1] SecondFi 事後披露
[2] Tibane Labs：SecondFi Cardano 鑑識分析

關於 BlockSec

BlockSec 是一家全方位的區塊鏈安全與加密合規服務提供商。我們構建產品與服務，協助客戶在協議和平台的完整生命週期中進行程式碼審計（包括智能合約、區塊鏈及錢包）、即時攔截攻擊、分析事件、追蹤非法資金，並履行 AML/CFT 合規義務。

BlockSec 已在多個頂級會議上發表多篇區塊鏈安全論文，回報了 DeFi 應用程式的多個零日攻擊，阻止了多起駭客攻擊並搶救超過 2,000 萬美元，同時保護了數十億美元的加密資產。

官方網站：https://blocksec.com/
官方 Twitter 帳號：https://twitter.com/BlockSecTeam
🔗 BlockSec 審計服務 : 提交申請
🔗 Phalcon Security APP：預約演示
🔗 Phalcon Compliance

~$400萬損失：Taiko、SecondFi遭攻擊 | BlockSec週報

每週重點：Taiko 事件

背景

SGX 與 DCAP 概述

鏈上 Attestation

Taiko Prover 註冊

漏洞分析

攻擊分析

結論

參考資料

本週其他事件

SecondFi 事件

背景

漏洞分析

攻擊分析

結論

參考資料

關於 BlockSec