签名完全合法,私钥却被人算了出来 $4.1M

📅 2026/7/3 18:20:12
签名完全合法,私钥却被人算了出来 $4.1M
签名完全合法私钥却被人算了出来 $4.1M过去一周2026/06/22 - 2026/06/28共发现 2 起值得关注的安全事件确认损失约 410 万美元。核心要点2 起事件涉及 Ethereum 和 Cardano确认损失约 410 万美元。攻击手法包括利用泄露的签名密钥绕过 SGX 远程证明策略以及 Ed25519 nonce 派生缺陷实现私钥恢复。两起事件均表明密码学信任模型可因实现层面的疏忽而被瓦解一个未检查的 enclave 调试标志或一个缺失的秘密哈希输入。Taiko攻击者将泄露的 SGX enclave 签名密钥与远程证明策略中缺失的属性验证相结合将恶意 prover 注册为授权实例表明仅凭有效的远程证明不足以保证安全必须全面检查 enclave 属性。SecondFiEd25519 签名实现中的密码学缺陷使攻击者仅凭公开的链上交易数据即可恢复地址级签名密钥揭示了对规范的微小偏差如何导致完整的密钥泄露。本周看点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 字节中。v3AuthDataquote 的真实性证明包括 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 quoteSgxVerifier 将 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 代码而不改变 MRENCLAVEDEBUG 标志不属于 MRENCLAVE 的一部分。远程证明策略本应拦截此类 quote但 attestation 合约 AutomataDcapV3Attestation0x5e46...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 状态转换并从 vault0x9962...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 attributesflags 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 Incident2026 年 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·BB 为固定的 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 库而非自行实现签名逻辑。对规范的任何偏离即使看似微小如遗漏单个哈希输入都可能导致整个密钥泄露。生产级签名软件在部署前应经过独立的密码学审计尤其是密钥派生和签名操作部分。