签名完全合法，私钥却被人算了出来 $4.1M
过去一周（2026/06/22 - 2026/06/28），共发现 2 起值得关注的安全事件，确认损失约 410 万美元。
核心要点：
2 起事件涉及 Ethereum 和 Cardano，确认损失约 410 万美元。
攻击手法包括利用泄露的签名密钥绕过 SGX 远程证明策略，以及 Ed25519 nonce 派生缺陷实现私钥恢复。
两起事件均表明，密码学信任模型可因实现层面的疏忽而被瓦解：一个未检查的 enclave 调试标志，或一个缺失的秘密哈希输入。
Taiko：攻击者将泄露的 SGX enclave 签名密钥与远程证明策略中缺失的属性验证相结合，将恶意 prover 注册为授权实例，表明仅凭有效的远程证明不足以保证安全，必须全面检查 enclave 属性。
SecondFi：Ed25519 签名实现中的密码学缺陷使攻击者仅凭公开的链上交易数据即可恢复地址级签名密钥，揭示了对规范的微小偏差如何导致完整的密钥泄露。
本周看点：Taiko Incident
在 Taiko 事件中，攻击者将两个独立的安全缺陷（enclave 签名密钥泄露和远程证明策略中缺失的属性验证）组合利用，攻破了基于 SGX 的证明验证系统。该事件表明，TEE 信任链的每一层都必须独立执行其安全属性；有效的远程证明签名链无法弥补未检查的运行时属性。
2026 年 6 月 22 日，Taiko 基于 SGX 的证明验证流程在 Ethereum 上被攻击，损失约 170 万美元。攻击者利用一个被提交到公开 GitHub 仓库的 enclave 签名私钥，为以 DEBUG 模式启动的 prover enclave 签署 SIGSTRUCT。由于链上 attestation 合约未拒绝 DEBUG enclave，攻击者成功注册为授权实例，提交伪造的证明数据，使 L1 合约接受了不存在的 L2 状态并释放了桥接资金。
背景
Taiko 是一个 Ethereum Layer-2 rollup，其桥通过证明系统来决定是否接受给定的 L2 状态或跨链消息。作为证明系统的一部分，Taiko 使用 SGX prover：运行在物理机器 SGX enclave 内的链下程序，使用受 enclave 保护的密钥对证明结果进行签名。
Off-chain (physical machine) On-chain (Ethereum)header：包括 quote 版本、证明密钥类型、QE/PCE SVN 和供应商等元数据。
localEnclaveReport：被证明的应用 enclave 身份信息，包括 MRENCLAVE、MRSIGNER、ATTRIBUTES、ISVPRODID、ISVSVN 和 reportData。reportData 是 enclave 生成 report 时写入的 64 字节值。Taiko 将 prover 实例地址存储在 reportData 的前 20 字节中。
v3AuthData：quote 的真实性证明，包括 quote 签名、证明密钥、QE report、QE report 签名和 PCK 证书链。
链上 Attestation
链上 attestation 合约（AutomataDcapV3Attestation，用于远程证明）通过 Intel DCAP 证书链验证 quote 的真实性。尽管证书链中的颁发者公钥作为外部提交的 quote 的一部分提供，合约逐步验证该链，并要求最终颁发者公钥哈希与合约中固定的 Intel SGX Root CA 公钥哈希匹配。通过该链，合约确认 quote 签名所覆盖的 localEnclaveReport 未在 calldata 中被攻击者篡改。
图：用于 SGX DCAP 证书链信任根校验的 ROOTCA_PUBKEY_HASH 常量
Taiko Prover 注册流程
SGX prover 实例须先通过 SgxVerifier.registerInstance() 完成注册。调用时提交一份 DCAP quote，SgxVerifier 将 quote 验证委托给 AutomataDcapV3Attestation.verifyParsedQuote()。若验证通过，SgxVerifier 从 localEnclaveReport.reportData 的前 20 字节读取实例地址，将其加入授权实例集合。
签名验证流程可简化为三层：
SGX CPU 在 EINIT 阶段验证 SIGSTRUCT 签名，确认 enclave 的 MRENCLAVE 和签名者身份。
DCAP 证书链和 QE report 认证 quote 签名密钥。该合约随后使用该密钥验证 quote 签名，建立对 localEnclaveReport 的信任。
Taiko 的证明验证器使用注册的实例地址验证后续证明签名，决定是否接受相应的 L2 状态或跨链消息。
漏洞分析
该事件的根因是运维失误与合约漏洞的叠加，二者缺一不可。
运维失误：enclave 签名密钥泄露。 Taiko/Raiko 用于签署 SGX SIGSTRUCT 的enclave 签名私钥被提交到了公开的 GitHub 仓库。MRSIGNER 是对应签名公钥的哈希。任何获得该私钥的人都可以用它签署 prover enclave 的 SIGSTRUCT，使生成的 quote 中的 MRSIGNER 匹配 Taiko 的白名单。
合约漏洞：缺少 ATTRIBUTES 检查。 借助泄露的密钥使 MRSIGNER 通过白名单后，攻击者可以在 DEBUG 模式下启动同一份 prover enclave 代码而不改变 MRENCLAVE（DEBUG 标志不属于 MRENCLAVE 的一部分）。远程证明策略本应拦截此类 quote，但 attestation 合约 AutomataDcapV3Attestation（0x5e46...dd72）未检查应用 enclave 的 localEnclaveReport.attributes。DEBUG enclave 允许宿主机或调试器读取或修改 enclave 内存，本应受 SGX enclave 保护的实例签名密钥将不再安全。
图：SGX enclave 标志位定义，SGX_FLAGS_DEBUG 对应 0x02 位
上述两个条件叠加意味着：任何人都可以在 DEBUG 模式下启动同一份 prover enclave 代码（MRENCLAVE 与合法版本一致），并利用泄露的签名密钥签署 SIGSTRUCT 使 MRSIGNER 匹配 Taiko 白名单。由此生成的 quote 同时满足 MRENCLAVE 和 MRSIGNER 白名单，同时携带未被检查的 DEBUG 属性。由于 AutomataDcapV3Attestation 合约不拒绝 DEBUG 属性，此类 quote 可通过 verifyParsedQuote() 验证，随后 SgxVerifier 将实例地址注册到授权实例集合中。
图：Intel SGX 开发者指南指出，验证方必须检查 enclave 属性以避免向 DEBUG enclave 下发秘密
在 DEBUG 模式下的 enclave 不保护其内存免受宿主机或调试器的访问。因此，enclave 内部生成的实例私钥可被提取。持有该密钥后，即可签署 L1 合约会接受的任意证明数据，从而伪造 L2 状态转换并从 vault（0x9962...15ab）中未经授权地释放桥接资金。
攻击分析
攻击者提交了多笔交易。以下分析基于两笔代表性交易：第一笔将攻击者注册为授权实例（0x2f44dc...277260），第二笔执行伪造证明以窃取资产（0x017292...ae35ee）。
Step 1：使用泄露的 enclave 签名密钥签署 SIGSTRUCT，使 quote 的 MRSIGNER 匹配白名单。
Step 2：以 DEBUG 属性运行 enclave。DEBUG 不改变 MRENCLAVE，但会反映在 localEnclaveReport.attributes 中。
Step 3：调用 registerInstance() 并提交真实的 SGX quote。该 quote 的 attributes = 0x07... 包含 DEBUG 位（0x02），但 AutomataDcapV3Attestation 未检查此字段，verifyParsedQuote() 返回 true。
图：攻击交易中解析出的 quote attributes，flags = 0x07 = 0x01 | 0x02 | 0x04，其中 0x02 为 DEBUG 标志
Step 4：从 SGX enclave 内存中提取实例私钥（因 DEBUG 模式禁用了内存保护），并用其签署恶意证明数据。
Step 5：提交伪造的证明，使 L1 合约接受不存在的 L2 状态并从 vault 中窃取资产。
结论
完整的 SGX 远程证明策略应至少：
在生产部署中拒绝 SGX_FLAGS_DEBUG。
检查 MRENCLAVE、MRSIGNER、ISVPRODID 和 ISVSVN。
若接受 DEBUG quote，硬件可能仍在正常运行，但不再提供预期的内存保护语义。Enclave 签名密钥也绝不应被提交到公开代码仓库。泄露的签名密钥使任何人都能构建 MRSIGNER 匹配白名单的 enclave 二进制文件，将远程证明策略的剩余防线缩减为 MRENCLAVE 和属性检查。
更广泛地说，对于任何依赖 TEE 的系统，远程证明不能仅停留在确认签名链有效和度量值在白名单中，信任链的每一层都必须独立执行其安全属性。
本周其它事件
SecondFi Incident
2026 年 6 月 23 日，SecondFi（前身为 Yoroi），一个由 EMURGO 开发的 Cardano 钱包，披露了其 Ed25519 签名实现中的一个严重漏洞。钱包的签名实现仅从公开的交易消息计算签名 nonce，遗漏了必需的秘密输入，将数字签名简化为单方程求解问题，使攻击者可从公开的链上数据恢复地址级私钥。两个独立的攻击者利用该缺陷，从 374 个钱包中窃取了约 240 万美元（1600 万 ADA）。
背景
SecondFi 是 Cardano 区块链的自托管钱包，于 2026 年 4 月从 Yoroi 更名而来。Yoroi 最初由 Cardano 三大创始实体之一 EMURGO 开发，曾服务超过 100 万用户。
Ed25519 是 Cardano 用于交易授权的数字签名方案。签名者持有签名标量 k_L（特定地址的私钥）和与同一密钥材料关联的秘密 nonce 前缀 k_R。对于给定消息 M（交易载荷），签名 nonce 计算为 r = SHA-512(k_R ∥ M) mod L。由于 k_R 是秘密的，即使 M 在广播后公开，r 对观察者仍不可知。
Nonce 点 R = r·B（B 为固定的 Ed25519 基点）和签名标量 s ≡ r + H·k_L (mod L)（其中 H = SHA-512(R ∥ A ∥ M) mod L 将 nonce、公钥和消息绑定在一起）构成最终签名 (R, s)。该方案的安全性依赖于 r 的不可预测性：若观察者能计算 r，签名方程就变成可求解 k_L 的单未知数线性方程。
漏洞分析
该漏洞存在于 SecondFi 的钱包签名软件中，不涉及智能合约。
我们结合既有的分析发现，v10.0.3 至 v10.0.6（自 2026 年 6 月 8 日上线，v10.0.6.2 修复）均受影响。有缺陷的实现将签名 nonce 计算为：
r = SHA-512(M) mod L
而非正确的：
r = SHA-512(k_R ∥ M) mod L
这去除了 nonce 派生中唯一的秘密输入（k_R）。由于 M 是公开的，任何人都可以对受影响地址签署过的任意交易重新计算 r。
在 r 已知后，签名方程 s ≡ r + H·k_L (mod L) 可直接求解：
k_L ≡ (s − r)·H⁻¹ (mod L)
等式右侧所有值要么是公开的，要么可从链上签名和交易数据计算得出。这不是在逆向哈希或求解 A = k_L·B 的离散对数问题；有缺陷的实现直接暴露了 r，使密钥恢复简化为基本的模运算。
影响范围为地址级密钥泄露。通过有缺陷实现产生签名的任何地址都应视为已被攻破。
将同一助记词导入修复后的钱包不能保护已暴露的地址；必须生成全新的密钥并将资金转移过去，且该密钥此前不能使用过有缺陷的签名实现。
攻击分析
该攻击不遵循典型的链上攻击序列。由于漏洞暴露了公开数据与签名密钥之间的确定性关系，密钥恢复可离线完成。
Step 1：识别使用 SecondFi v10.0.3 至 v10.0.6 签署过交易的目标地址。
Step 2：对每个目标，获取交易的公开签名组件（R、s）并从链上交易载荷重构消息 M。
Step 3：计算签名 nonce r = SHA-512(M) mod L，利用有缺陷签名实现遗漏了秘密 nonce 前缀 k_R 这一事实。
Step 4：计算挑战标量 H = SHA-512(R ∥ A ∥ M) mod L。
Step 5：求解签名标量：k_L ≡ (s − r)·H⁻¹ (mod L)。
Step 6：使用恢复的 k_L 从被攻破的地址签署任意交易，将资金转移到攻击者控制的钱包。
两个独立的攻击者分别利用了该漏洞。一个攻击者分两波攻破了 171 个钱包，另一个在独立行动中清空了 203 个钱包，共窃取约 1600 万 ADA（约 240 万美元）。EMURGO 随后赶在攻击者之前抢救了另外 1.29 亿 ADA。
结论
本次攻击事件的根本原因是密码学实现缺陷：Ed25519 nonce 派生中的秘密 nonce 前缀被去除，使签名 nonce 退化为公开数据的确定性函数。每个受影响的签名都成为单方程密钥恢复问题。
此次事件表明，钱包开发者应使用经过充分审计的标准 Ed25519 库，而非自行实现签名逻辑。对规范的任何偏离，即使看似微小（如遗漏单个哈希输入），都可能导致整个密钥泄露。生产级签名软件在部署前应经过独立的密码学审计，尤其是密钥派生和签名操作部分。
