区块链密码学实现中的高危风险：从随机数生成到MPC协议的深度剖析

查找币:余老师 | 学术研究 | 2026-05-09 20:14 | 3 次浏览 | 0 条回复

查找币学术研究安全研究 Web3安全区块链安全

## 引言：密码学——Web3安全的第一道防线在区块链技术的底层架构中，密码学组件并非可选的增强模块，而是整个信任体系的基石。从用户私钥的生成、交易签名的构造，到智能合约中哈希函数的调用，每一个环节都依赖于密码学原语的正确实现。然而，在实际的Web3项目开发中，我们发现大量团队将注意力集中在业务逻辑与性能优化上，而对底层密码学实现的细微缺陷缺乏足够的警觉。这种认知偏差带来的后果往往是灾难性的：一个不安全的随机数生成器可能导致私钥被预测，一个错误的签名算法调用可能允许攻击者伪造交易，而对多方计算（MPC）协议实现细节的忽视，则可能让整个托管系统面临密钥泄露的风险。查找币安全团队在长期的一线攻防实践中，系统性地梳理了区块链应用中常见的密码学实现风险。本文旨在将这些典型案例与最佳实践分享给开发团队，帮助项目方在开发初期便筑牢密码学安全防线。完整内容已开源至GitHub，欢迎关注与贡献。 ## 0x01 私钥随机数安全：熵的缺失是致命伤 ### 1. JavaScript `Math.random()` 的伪随机陷阱 **严重性**：高 **技术原理**：JavaScript的`Math.random()`基于伪随机数生成器（PRNG）实现，在V8引擎中采用Xorshift128+算法。该算法的种子和状态空间有限，且在不同浏览器中存在实现差异，但其共同特征是**可预测性**——攻击者通过观察少量输出即可推断后续随机数序列。 **利用场景**：在去中心化应用（dApp）的前端代码中，若使用`Math.random()`生成钱包私钥、会话令牌或交易nonce，攻击者可通过分析前端JavaScript代码或观察生成的随机数模式，直接推导出私钥，进而窃取用户资产。 **修复建议**：在需要加密安全随机数的场景中，务必使用`crypto.getRandomValues()`（Web Crypto API）。该接口直接调用操作系统底层的熵源（如/dev/urandom），提供不可预测的加密安全随机数。 ### 2. Java `java.util.Random` 的线性同余缺陷 **严重性**：高 **技术原理**：Java的`java.util.Random`基于线性同余生成器（LCG），其核心公式为`X_{n+1} = (a * X_n + c) mod m`。LCG的周期性和可预测性已被广泛研究，攻击者只需获取少量连续输出即可逆向计算种子，从而重现整个随机数序列。 **利用场景**：在基于Java的区块链服务端（如钱包后端、交易所签名服务）中，若使用`Random`生成RSA或ECDSA私钥，攻击者可通过分析多次签名输出的nonce或公钥，破解私钥。历史上，Android Bitcoin钱包的随机数生成漏洞正是由此类问题引发。 **修复建议**：始终使用`java.security.SecureRandom`替代`Random`。`SecureRandom`从操作系统熵池获取种子，并提供加密安全的伪随机数输出。对于密钥生成，优先使用标准库的`KeyPairGenerator`。 ### 3. Android `SecureRandom` 的初始化缺陷（4.1-4.3版本） **严重性**：高 **技术原理**：在Android 4.1至4.3版本中，`java.security.SecureRandom`的实现存在一个严重缺陷：其初始化过程未能正确从`/dev/urandom`获取足够熵值，导致生成的随机数序列高度可预测。具体而言，该实现会复用初始种子，使得不同设备上生成的随机数序列存在相关性。 **利用场景**：在受影响的Android设备上，使用`SecureRandom`生成Bitcoin私钥的钱包应用，其私钥存在被暴力破解的风险。攻击者可通过分析同一设备生成的多个地址，推断私钥生成模式。 **修复建议**：在调用`SecureRandom`生成私钥前，显式调用`SecureRandom.setSeed()`方法，并结合高熵来源（如用户触摸事件、加速度传感器数据）增强随机性。此外，建议使用硬件支持的密钥存储（如Android KeyStore）。 ### 4. 变量类型空间不足导致密钥空间缩减 **严重性**：高 **技术原理**：在私钥生成过程中，若使用32位整数（`int`）等小空间变量存储随机数，则实际生成的密钥空间将从2^256（secp256k1曲线）缩减至2^32。攻击者可通过暴力搜索或预计算（如彩虹表）在极短时间内枚举所有可能的私钥。 **利用场景**：2018年的Profanity工具漏洞正是典型案例。该工具使用32位种子生成以太坊钱包地址，攻击者通过分析地址生成模式，成功破解多个钱包并窃取大量ETH。 **修复建议**：始终使用256位或更高位数的变量类型（如`uint256`、`byte[32]`）存储随机数，确保密钥空间与椭圆曲线安全参数一致。 ### 5. Libbitcoin Mersenne Twister弱熵漏洞 **严重性**：高 **技术原理**：Libbitcoin Explorer（版本3.0.0至3.6.0）的`bx seed`命令使用Mersenne Twister（MT19937）PRNG生成钱包种子。MT19937虽然具有较长的周期（2^19937-1），但其状态空间仅为624个32位整数（共19968位），且状态转换函数具有线性可逆性。攻击者通过收集624个连续输出即可完全恢复状态，预测所有未来输出。 **利用场景**：使用Libbitcoin Explorer创建的钱包，其种子可由攻击者通过观察少量已生成地址进行逆向计算，导致所有关联私钥泄露。 **修复建议**：立即升级至Libbitcoin Explorer 3.6.0以上版本，该版本已改用`/dev/urandom`作为熵源。对于所有钱包种子生成场景，应使用操作系统提供的加密安全随机数源。 ## 0x02 多方计算（MPC）协议实现风险：GG18/GG20的Paillier密钥漏洞 ### 漏洞概述 **严重性**：高 **影响范围**：该漏洞存在于GG18和GG20两个广泛使用的MPC协议规范中，影响了超过10个钱包和托管服务库，包括币安托管服务。漏洞的根本原因在于协议实现**未验证攻击者提供的Paillier模数N是否包含小因子或是否为双素数**。 ### 技术原理在GG18/GG20的签名协议中，每个参与方需要生成一个Paillier同态加密密钥对（公钥N，私钥λ），用于加密其秘密分片。攻击者可以构造一个包含小因子（如2^20大小的素数）的恶意Paillier模数N，并提交给签名方。由于协议未强制要求验证N的素数性质，签名方会使用该恶意公钥加密其秘密分片。攻击者随后可以： 1. 利用N的小因子快速分解模数，恢复Paillier私钥λ 2. 解密签名方发送的密文，获取其秘密分片 3. 结合自身分片，重构完整的主密钥 ### 攻击实例在2021年披露的漏洞利用案例中，攻击者通过构造包含2^20大小素因子的Paillier模数，成功与MPC签名方完成多轮交互。在每次签名过程中，攻击者逐步收集签名方的秘密分片信息，最终在约200次签名交互后，完全恢复了主私钥，盗取了托管钱包中的所有资金。 ### 修复建议 1. **小素数因子检查**：在接收其他参与方的Paillier公钥N时，必须执行小素数因子分解检查，确保N不包含小于2^40的素数因子 2. **双素数验证**：验证N是否为两个大素数的乘积（即双素数），可通过计算gcd(N, φ(N))等统计方法进行概率性验证 3. **零知识证明**：要求参与方提供N为双素数的零知识证明，防止恶意构造 ## 总结：构建密码学安全的开发实践查找币安全团队开源的《区块链应用中常见的密码学风险》旨在系统性地揭示私钥生成、数字签名、哈希函数及对称加密等核心环节中潜藏的高危安全风险。Web3项目方可以参考本文对各类漏洞的原理剖析、利用场景及修复建议，深化对密码学安全的理解，规避常见的实现陷阱。我们强烈建议开发团队： - **在开发初期**，将密码学组件安全纳入设计评审流程 - **在编码阶段**，严格遵循加密安全随机数生成、密钥管理等最佳实践 - **在测试阶段**，引入密码学专项审计，覆盖边界条件和异常输入 - **在运维阶段**，持续关注底层库的漏洞公告与安全更新唯有将密码学安全内化为开发流程的有机组成部分，才能真正保障项目和用户的资产安全。 --- *本文由查找币安全团队整理发布*

区块链密码学实现中的高危风险：从随机数生成到MPC协议的深度剖析

查找币安全研究院

主题延伸阅读