近期，硬件钱包行业出现了与助记词随机性有关的安全事件。不少用户开始担心：硬件钱包是不是也不安全了? 这也再次提醒我们：硬件钱包的安全，不仅取决于私钥是否离线保存，也取决于私钥最初是如何生成的。
先说结论：由 SafePal S1、S1 Pro、X1 生成的助记词不受此次事件影响。但比”我们没事”更值得聊的，是这次事件本身提出的一个问题：随机数生成，是硬件钱包安全里最容易被忽视、却也最基础的一环。在这篇文章里，我们希望以尽量简单易懂的方式，把 SafePal 助记词背后的随机数架构讲清楚。
TL;DR：
- 你不需要做任何事。 SafePal S1 / S1 Pro / X1 生成的助记词不受此次事件影响，无需重新生成助记词或迁移资产。
- 原因： SafePal 每次创建钱包都会现场获取真随机数，再通过双芯片架构 + 密码学混合处理，不依赖单一芯片或单一随机源。
- 唯一例外： 如果你的助记词最初是在受影响版本的 Coldcard 固件上生成、之后才导入 SafePal，请按 Coldcard 官方指引处理。这取决于助记词最初在哪里生成，而不是你现在用哪个钱包。
随机数的质量，决定了安全的上限
随机数生成，好比建筑打地基。如果地基在浇筑之初就存在结构性缺陷，后续无论上层装修多精致、工艺多复杂，整栋建筑的安全性都无法达标。而且这类地基问题，往往难以在事后补救。密码学算法(比如 SHA3-256)在这个过程中扮演的角色，更接近对结果做进一步的处理和加固：它可以把输入充分混合，让结果在外观上不再能看出原始规律，但它无法凭空创造出原本不存在的随机性。
这也是此次行业安全事件的核心问题：如果最初的随机数种子本身处于一个较小、可被穷举的范围内，那么无论后续处理逻辑多复杂，攻击者仍然可能通过遍历这个有限范围找到对应结果。
SafePal 的首要原则：先拿到真随机数，再谈处理
SafePal 的原则很简单：先确保拿到的是足量、新鲜、真正安全的随机数据，再做处理，而不是反过来。
具体来说，每次创建新钱包时，SafePal 都会重新调用设备侧的安全随机数接口，获取生成 12 词或 24 词助记词所需的初始熵，再按 BIP39 标准加入校验信息并映射成用户看到的单词。
SafePal 不会用固定值、可预测状态或低熵伪随机数起步，再用哈希算法”拉长”成一个看起来很复杂的 256 位数字：因为哈希算法虽然可以混合、压缩和隐藏输入数据的结构，却造不出原本不存在的随机性。
如果安全随机数在某一步无法正常获取、返回长度不足或调用失败，钱包创建流程会直接停止，而不是在用户不知情的情况下，悄悄切换到低质量的软件随机数继续生成助记词。
在这个基础上，我们再进一步说明 SafePal 为什么采用双芯片架构，以及不同输入在随机数生成过程中分别承担什么作用。
SafePal的设计理念：不依赖于单一的随机数生成器
现代芯片大多内置硬件真随机数发生器(TRNG)，正常情况下非常可靠。但安全设计要考虑的从来不只是”正常情况”，还包括那些概率很低、但一旦发生就无法挽回的意外：随机数模块失效、固件调用或配置出错、数据被重复读取等。助记词通常只生成一次，却可能被使用很多年（一旦生成那一刻随机数出了问题，即使设备后续恢复正常，也没办法让已经生成的助记词重新变得安全）。
这就是为什么 SafePal 的硬件钱包(S1、X1 系列)均采用双芯片架构：
- 一颗安全芯片（Secure Element）
- 一颗应用芯片（MCU）
且两颗芯片均各自拥有独立的硬件随机数发生器和唯一设备编码。
在生成随机数时，SafePal 会综合两颗芯片的随机数据、各自的唯一设备编码、设备运行计时器、以及用户操作过程中形成的动态状态，通过密码学算法进行混合，最终形成用于生成助记词和密钥的随机数据。
不同的数据输入分别起什么作用：
| 输入来源 | 作用 |
| 两颗芯片各自的随机数据 | 最主要的不可预测来源。两个独立来源意味着即使其中一个异常，另一个仍能继续提供随机性 |
| 两颗芯片的唯一设备编码 | 每颗芯片在出厂时的唯一设备编码，它不是秘密，也不作为随机数本身使用，作用是让不同设备即使执行完全相同的流程，也不会进入相同的内部状态 |
| 设备运行计时器 | 每台设备都有独立运行的计时器。设备启动时间、进入创建钱包流程的时间，以及用户在各个步骤停留的时长，都会使设备内部状态发生变化。它不是主要的随机来源，用于进一步拉开不同设备、不同操作过程之间的差异 |
| 用户操作动态状态 | 按键、翻页、确认等操作形成的额外动态输入，用户无需刻意”制造随机数”，这些操作将作为附加输入，与芯片随机数据和其他设备状态共同参与随机数生成 |
为什么要混合多个来源？
SafePal 不会直接把某一个来源的原始数据当作最终结果，而是把多个来源混合处理。这背后的理念，不是假设每一个随机来源都永远不会出错，而是希望即使其中一个环节出了问题，其他仍在正常工作的来源也能撑住整体的安全性。
当然，密码学算法无法凭空创造随机性：如果所有真正提供随机性的来源同时失效，任何算法都无法把可预测的数据变成真正随机的数据。多来源设计要解决的，从来不是”绝对不出问题”，而是”一个环节出了问题，不至于让整个机制崩塌”。
随机数安全，不只是"芯片有没有 TRNG"
判断一个硬件钱包的随机数是否安全，不能只看芯片规格表上有没有标注真随机数发生器。真正决定安全性的，是：
- 固件有没有正确调用随机数模块
- 有没有读取足够长度的数据
- 有没有正确处理错误返回
- 是否存在重复或未初始化数据
- 是否只依赖单一随机源
- 混合算法是否可靠
- 每次固件升级后是否经过充分测试
随机数安全，从来都是硬件和软件共同实现的结果：这也是此次行业安全事件真正值得所有硬件钱包厂商深思的地方。
我需要重新生成助记词并迁移资产吗？
不需要。这次行业内被披露的问题来自特定产品的特定实现，不代表所有硬件钱包都存在同样的问题。目前没有证据表明 SafePal 用户需要因为此次事件重新生成助记词或迁移资产。
唯一的例外： 如果你的助记词最初是在Coldcard受影响的固件上生成的，即便后来导入了 SafePal 或其他钱包，这组助记词本身仍处于受影响状态，请按Coldcard发布的官方迁移指引处理。这取决于助记词最初在哪里生成，和你现在用什么钱包无关。
另外提醒一句：请不要仅仅因为社交媒体上的讨论，就仓促地把助记词导入其他设备、网站或软件。仓促迁移、钓鱼网站和助记词泄露，往往比这次事件本身带来更直接的资产风险。
无论用哪家硬件钱包，都建议做到：
- 优先选择有独立安全芯片和真随机数发生器的设备
- 不要导入其他钱包生成的助记词，除非你清楚它的生成方式
- 助记词不拍照、不截图、不做任何电子化保存
- 任何网页都不要输入完整助记词
- 固件只通过官方渠道下载和升级
- 大额转账前，先做小额测试
- 看到安全公告，先确认受影响型号和版本，不要仓促行动
- 任何要求你输入助记词来”检查随机性”“修复漏洞”“升级固件”或”领取补偿”的网站，一律视为钓鱼
结语
用户看到的，只是 12 个或 24 个单词。但这背后，是双芯片架构、硬件随机数发生器、设备内部状态、用户动态输入和密码学算法共同完成的一次关键过程。地基打得牢，上层建筑的安全才有意义。
SafePal 的设计理念一直没变：不假设任何一个随机来源永远不会失败，也不让某一个局部异常轻易演变成整个机制的崩塌。我们会持续接受社区和安全研究人员的审查，持续完善随机数生成机制和整体安全设计，为用户提供更可靠、更安全的硬件钱包产品。
关于SafePal
SafePal成立于2018年，是服务全球超过三千万用户的Web3全栈钱包，旗下产品包括硬件钱包、App钱包和浏览器插件钱包，致力于为Web3投资用户提供安全、可靠的去中心化钱包工具。
SafePal背后的投资者来自行业顶尖投资机构，包括Binance、AnimocaBrands以及淡马锡旗下的Web3基金Superscrypt。
目前，SafePal产品已经服务于全球200多个国家和地区的用户，支持16种语言、200+条公链及链上资产，并在App里提供跨链闪兑、币币及NFT聚合交易（内置Binance，Bitget，BingX等交易所小程序）、理财、合规法币账户等功能。
访问官网www.safepal.com，或关注推 https://x.com/SafePalCN 了解更多详情。
