约400万美元损失：Taiko与SecondFi遭受攻击 | BlockSec周报

在过去一周（2026/06/22 - 2026/06/28），共发现 2 起重大安全事件，确认损失约 410 万美元。

• Taiko：攻击者将泄露的 SGX 飞地签名密钥与远程证明策略中缺失的属性验证相结合，将恶意证明者注册为授权实例，表明在缺乏全面属性执行的情况下，仅凭有效认证是不够的。
• SecondFi：密码学实现缺陷使攻击者仅凭公开的交易数据即可恢复地址级签名密钥，展示了看似微小的 Ed25519 规范偏差如何导致密钥的完全泄露。

本周重点：Taiko 事件

在Taiko事件中，攻击者将两个独立的安全缺陷（enclave签名密钥泄露和远程证明策略中缺失的属性验证）组合利用，攻破了基于SGX的证明验证系统。该事件表明，TEE信任链的每一层都必须独立执行其安全属性；有效的远程证明签名链无法弥补未检查的运行时属性。

2026 年 6 月 22 日，Taiko 基于 SGX 的证明验证流程在以太坊上遭到攻击，损失约 170 万美元 [1]。攻击者使用了一个泄露的飞地签名私钥（该私钥已被提交至公开的 GitHub 仓库），为以 DEBUG 模式启动的证明者飞地签署了 SIGSTRUCT。由于链上认证合约未拒绝 DEBUG 模式飞地，攻击者得以注册为授权实例，提交伪造的证明数据，导致 L1 合约接受了一个不存在的 L2 状态并释放了跨链桥资金。

背景

Taiko 是一个以太坊 Layer-2 Rollup，其跨链桥依赖证明系统来决定是否接受特定的 L2 状态或跨链消息。作为该证明系统的一部分，Taiko 使用 SGX 证明者：在物理机器上的 SGX 飞地内运行的链下程序，使用受飞地保护的密钥对证明结果进行签名。

链下（物理机器）                            链上（以太坊）
┌─────────────────────────┐                ┌────────────────────────────────────┐
│  SGX 证明者飞地          │                │  SgxVerifier                       │
│  - 生成证明              │── DCAP 引用 ──→│  ├─ registerInstance()             │
│  - 持有实例密钥          │                │  │  └─ AutomataDcapV3Attestation   │
│                         │── 签名证明 ───→│  └─ verifyProof()                  │
└─────────────────────────┘                └────────────────────────────────────┘

SGX 与 DCAP 概述

SGX 的核心概念是飞地：一个由 CPU 隔离的程序环境。MRENCLAVE 是飞地初始代码、数据、页面布局及相关元数据的度量值，可近似理解为飞地构建的哈希值。MRSIGNER 是飞地签名公钥的哈希值，代表发布者身份。

飞地签名私钥对 SGX SIGSTRUCT 进行签名，SIGSTRUCT 包含飞地元数据，如 MRENCLAVE、ISVPRODID、ISVSVN 和 ATTRIBUTES。该签名不由链上合约验证；它由 SGX 硬件在飞地初始化的 EINIT 阶段进行验证。CPU 会检查 SIGSTRUCT 签名是否有效，以及其中的 MRENCLAVE 是否与实际加载的飞地度量值匹配。只有在此验证通过后，飞地才能被初始化并生成后续报告和引用。

Intel SGX DCAP v3 引用是一个远程认证包，包含三个部分：

• header：元数据，如引用版本、认证密钥类型、QE/PCE SVN 及供应商信息。
• localEnclaveReport：被认证的应用飞地身份信息，包括 MRENCLAVE、MRSIGNER、ATTRIBUTES、ISVPRODID、ISVSVN 和 reportData。reportData 是飞地在生成报告时写入的 64 字节值。Taiko 将证明者实例地址存储在 reportData 的前 20 个字节中。
• v3AuthData：引用的真实性证明，包括引用签名、认证密钥、QE 报告、QE 报告签名和 PCK 证书链。

链上认证

链上认证合约（AutomataDcapV3Attestation，负责远程认证）通过 Intel DCAP 证书链验证引用的真实性。尽管证书链中的颁发者公钥作为外部提交引用的一部分提供，合约仍会逐步验证该链，并要求最终颁发者公钥哈希与合约中固定的 Intel SGX Root CA 公钥哈希匹配 [2]。通过该链，合约确认引用签名所覆盖的 localEnclaveReport 未在 calldata 中被任意篡改。

Taiko 证明者注册

SGX 证明者实例必须首先通过 SgxVerifier.registerInstance() 进行注册。注册期间，调用者提交一个 DCAP 引用。SgxVerifier 将引用验证委托给 AutomataDcapV3Attestation.verifyParsedQuote()。若引用通过验证，SgxVerifier 会读取 localEnclaveReport.reportData 的前 20 个字节作为实例地址，并将其添加至授权实例集合。

签名验证流程可简化为三层：

• SGX CPU 在 EINIT 阶段验证 SIGSTRUCT 签名，确认飞地的 MRENCLAVE 和签名者身份。
• DCAP 证书链和 QE 报告对引用签名密钥进行认证。AutomataDcapV3Attestation 随后使用该密钥验证引用签名，并建立对 localEnclaveReport 的信任。
• Taiko 的证明验证器使用已注册的实例地址验证后续证明签名，并决定是否接受相应的 L2 状态或跨链消息。

漏洞分析

此次事件的根本原因是运营失误与合约级漏洞的组合。两者缺一不可，攻击才得以成功。

运营失误：飞地签名密钥泄露。 Taiko/Raiko 用于签署 SGX SIGSTRUCT 的飞地签名私钥被提交至公开的 GitHub 仓库。MRSIGNER 是对应签名公钥的哈希值。任何获得该私钥的人都可以为证明者飞地的 SIGSTRUCT 签名，使生成的引用中的 MRSIGNER 与 Taiko 的白名单匹配。

合约漏洞：缺少 ATTRIBUTES 检查。 由于 MRSIGNER 匹配（通过泄露的密钥通过白名单），攻击者可以在不修改 MRENCLAVE 的情况下以 DEBUG 模式启动同一已批准飞地（DEBUG 标志不属于 MRENCLAVE 的组成部分）。认证策略本应捕获此问题，但 AutomataDcapV3Attestation（0x5e46...dd72）未检查应用飞地的 localEnclaveReport.attributes。DEBUG 模式的飞地允许主机或调试器读取或修改飞地内存，这意味着本应受 SGX 飞地保护的实例签名密钥不再安全。

这两个条件共同作用意味着，任何一方都可以以 DEBUG 模式启动相同的证明者飞地代码（产生与合法构建相同的 MRENCLAVE），并使用泄露的签名密钥签署 SIGSTRUCT，使 MRSIGNER 与 Taiko 的白名单匹配。生成的引用同时满足 MRENCLAVE 和 MRSIGNER 白名单，同时携带未经检查的 DEBUG 属性。由于 AutomataDcapV3Attestation 不拒绝 DEBUG 属性，此类引用可通过 verifyParsedQuote()，之后 SgxVerifier 将实例地址注册到授权实例集合中。

DEBUG 模式的飞地无法保护其内存不被主机或调试器访问。因此，飞地内部生成的实例私钥可被提取。持有该密钥后，攻击者可以对任意证明数据进行签名，L1 合约将予以接受，从而实现伪造的 L2 状态转换，并从金库（0x9962...15ab）中未经授权地释放跨链桥资金。

攻击分析

攻击者提交了多笔交易。以下分析基于两笔具有代表性的交易：第一笔将攻击者注册为授权实例（0x2f44dc...277260），第二笔执行伪造证明以窃取资产（0x017292...ae35ee）。

• 步骤 1：使用泄露的飞地签名密钥对 SIGSTRUCT 进行签名，使引用的 MRSIGNER 与白名单匹配。

• 步骤 2：以 DEBUG 属性运行飞地。DEBUG 不改变 MRENCLAVE，但会反映在 localEnclaveReport.attributes 中。

• 步骤 3：调用 registerInstance() 并提交真实的 SGX 引用。该引用的 attributes = 0x07...，包含 DEBUG 位（0x02），但 AutomataDcapV3Attestation 未检查该字段，因此 verifyParsedQuote() 返回 true。

• 步骤 4：从 SGX 飞地内存中提取实例私钥（DEBUG 模式禁用了内存保护，故此操作可行），并使用该密钥对恶意证明数据进行签名。

• 步骤 5：提交精心构造的证明，使 L1 合约接受一个不存在的 L2 状态，并从金库中窃取资产。

结论

完整的 SGX 认证策略至少应：

• 在生产部署中拒绝 SGX_FLAGS_DEBUG。
• 检查 MRENCLAVE、MRSIGNER、ISVPRODID 和 ISVSVN。

如果接受 DEBUG 引用，硬件本身可能仍在正常运行，但它不再提供预期的内存保护语义。飞地签名密钥也绝不能提交至公开仓库。泄露的签名密钥允许任何一方生成具有匹配 MRSIGNER 的二进制文件，从而将认证策略剩余的防护屏障缩减为 MRENCLAVE 和属性执行。

更广泛地说，对于任何依赖 TEE 的系统，认证不能止步于确认签名链有效且度量值在白名单中。信任链的每一层都必须独立执行其安全属性。

参考资料

• [1] Phalcon 警报：Taiko 跨链桥漏洞检测
• [2] Intel SGX 开发者指南

本周更多事件

SecondFi 事件

2026 年 6 月 23 日，由 EMURGO 开发的 Cardano 钱包 SecondFi（前身为 Yoroi）披露了其 Ed25519 签名实现中的一个严重漏洞 [1]。该钱包的签名实现仅从公开的交易消息中计算签名随机数，遗漏了必要的秘密输入。这将数字签名简化为单方程问题，使攻击者能够从公开的链上数据中恢复地址级私钥。两名独立攻击者利用该漏洞，从 374 个钱包中盗取了约 240 万美元（1600 万 ADA）[2]。

背景

SecondFi 是 Cardano 区块链的自托管钱包，于 2026 年 4 月从 Yoroi 品牌重塑而来。Yoroi 最初由 Cardano 三个创始实体之一的 EMURGO 开发，此前拥有超过百万用户。

Ed25519 是 Cardano 用于交易授权的数字签名方案。签名者持有签名标量 $k_{L}k\_L$（特定地址的私钥）以及与相同密钥材料关联的秘密随机数前缀 $k_{R}k\_R$。对于给定消息 $MM$（交易载荷），签名随机数计算为 $r=\mathrm{SHA-512}(k_R\mathrm{\parallel }M)Lr\; =\; \backslash operatorname\{SHA-512\}(k\_R\; \backslash mathbin\backslash Vert\; M)\; \backslash bmod\; L$。由于 $k_{R}k\_R$ 是秘密的，即使 $MM$ 在广播后公开，观察者也无法得知 $rr$。

随机数点 $R=r\cdot BR\; =\; r\; \backslash cdot\; B$（其中 $BB$ 是固定的 Ed25519 基点）和签名标量 $s\equiv r+H\cdot k_L(\mathrm{m}\mathrm{o}\mathrm{d}L)s\; \backslash equiv\; r\; +\; H\; \backslash cdot\; k\_L\; \backslash pmod\{L\}$（其中 $H=\mathrm{SHA-512}(R\mathrm{\parallel }A\mathrm{\parallel }M)LH\; =\; \backslash operatorname\{SHA-512\}(R\; \backslash mathbin\backslash Vert\; A\; \backslash mathbin\backslash Vert\; M)\; \backslash bmod\; L$ 将随机数、公钥和消息绑定在一起）共同构成最终签名 $(R,s)(R,\; s)$。该方案的安全性依赖于 $rr$ 的不可预测性：若观察者能计算出 $rr$，签名方程将变为可求解 $k_{L}k\_L$ 的单未知数线性方程。

漏洞分析

此漏洞存在于 SecondFi 的钱包签名软件中，而非智能合约。

结合现有分析 [2] 与我们自己的调查，我们发现 v10.0.3 至 v10.0.6 版本（自 2026 年 6 月 8 日起上线；已在 v10.0.6.2 中修复）均受影响。存在漏洞的实现将签名随机数计算为：

$$r=\mathrm{SHA-512}(M)Lr\; =\; \backslash operatorname\{SHA-512\}(M)\; \backslash bmod\; L$$

而非正确的：

$$r=\mathrm{SHA-512}(k_R\mathrm{\parallel }M)Lr\; =\; \backslash operatorname\{SHA-512\}(k\_R\; \backslash mathbin\backslash Vert\; M)\; \backslash bmod\; L$$

这从随机数推导中移除了唯一的秘密输入（$k_{R}k\_R$）。由于 $MM$ 是公开的，任何人都可以为受影响地址签署的任何交易重新计算 $rr$。

已知 $rr$ 后，签名方程 $s\equiv r+H\cdot k_L(\mathrm{m}\mathrm{o}\mathrm{d}L)s\; \backslash equiv\; r\; +\; H\; \backslash cdot\; k\_L\; \backslash pmod\{L\}$ 变得可求解：

$$k_L\equiv (s-r)\cdot H^{-1}(\mathrm{m}\mathrm{o}\mathrm{d}L)k\_L\; \backslash equiv\; (s\; -\; r)\; \backslash cdot\; H^\{-1\}\; \backslash pmod\{L\}$$

右侧的所有值要么是公开的，要么可从链上签名和交易数据中计算得出。这不是逆向哈希或从 $A=k_L\cdot BA\; =\; k\_L\; \backslash cdot\; B$ 求解离散对数；存在缺陷的实现直接暴露了 $rr$，将密钥恢复简化为直接的模运算。

影响范围为地址级密钥泄露。任何通过存在漏洞的实现产生签名的地址都应被视为已泄露。

将相同的助记词导入已修补的钱包无法保护已暴露的地址；资金必须转移到从未通过存在漏洞的签名实现进行签名的新生成密钥中。

攻击分析

此次攻击不遵循具有可追踪智能合约交互的典型链上攻击序列。由于该漏洞在公开数据与签名密钥之间暴露了确定性关系，密钥恢复在链下执行。

• 步骤 1：识别使用 SecondFi v10.0.3 至 v10.0.6 签署交易的目标地址。

• 步骤 2：对于每个目标，检索交易的公开签名组件（$RR$、$ss$），并从链上交易载荷中重建消息 $MM$。

• 步骤 3：计算签名随机数 $r=\mathrm{SHA-512}(M)Lr\; =\; \backslash operatorname\{SHA-512\}(M)\; \backslash bmod\; L$，利用存在漏洞的签名实现遗漏了秘密随机数前缀 $k_{R}k\_R$ 这一事实。

• 步骤 4：计算挑战标量 $H=\mathrm{SHA-512}(R\mathrm{\parallel }A\mathrm{\parallel }M)LH\; =\; \backslash operatorname\{SHA-512\}(R\; \backslash mathbin\backslash Vert\; A\; \backslash mathbin\backslash Vert\; M)\; \backslash bmod\; L$。

• 步骤 5：求解签名标量：$k_L\equiv (s-r)\cdot H^{-1}(\mathrm{m}\mathrm{o}\mathrm{d}L)k\_L\; \backslash equiv\; (s\; -\; r)\; \backslash cdot\; H^\{-1\}\; \backslash pmod\{L\}$。

• 步骤 6：使用恢复的 $k_{L}k\_L$ 为受攻击地址签署任意交易，并将资金转移至攻击者控制的钱包。

两名独立攻击者分别利用了此漏洞。其中一人分两波攻陷了 171 个钱包，另一人在独立的扫荡中盗取了 203 个钱包，共提取约 1600 万 ADA（约 240 万美元）[2]。EMURGO 随后在攻击者触及之前抢救了另外 1.29 亿 ADA。

结论

根本原因是一个密码学实现缺陷，该缺陷从 Ed25519 随机数推导中移除了秘密随机数前缀，将签名随机数简化为公开数据的确定性函数。每一个受影响的签名都变成了单方程密钥恢复问题。

此次事件强调，钱包开发者应使用经过良好审计的标准 Ed25519 库，而非自定义签名实现。任何偏离规范的做法，即使看似微小（如遗漏单个哈希输入），也可能导致整个密钥被攻破。生产级签名软件在部署前应接受独立的密码学审计，尤其是在处理密钥派生和签名操作时。

参考资料

• [1] SecondFi 事后披露
• [2] Tibane Labs：SecondFi Cardano 取证分析

关于 BlockSec

BlockSec 是一家全栈区块链安全与加密合规服务提供商。我们构建产品和服务，帮助客户进行代码审计（包括智能合约、区块链和钱包）、实时拦截攻击、分析事件、追踪非法资金，并满足反洗钱/反恐融资义务，覆盖协议和平台的完整生命周期。

BlockSec 在权威会议上发表了多篇区块链安全论文，披露了多个 DeFi 应用的零日攻击，阻止了多起黑客攻击并成功救援超过 2000 万美元，并保护了数十亿美元的加密货币。

• 官方网站：https://blocksec.com/

• 官方 Twitter 账号：https://twitter.com/BlockSecTeam

• 🔗 BlockSec 审计服务 : 提交申请

• 🔗 Phalcon Security APP: 预约演示

• 🔗 Phalcon 合规