Electron 桌面钱包怎么存私钥：safeStorage 不够用，看看 MetaMask 和 Phantom 怎么做

前几天我写过一篇拆开 Electron safeStorage 黑盒，结论是：safeStorage 适合存普通 API key，但有不少边界限制——同进程恶意代码能读、Linux fallback 等于明文、调试器附加能抢 master key。

那篇文末我说了一句：“如果你的产品命中威胁模型表后五行（密码管理器、加密钱包、企业 SSO），必须额外加主密码 + 短期解锁窗口。”

这篇就专门讲这个”额外那一层”——Electron 桌面应用要存私钥级别的高敏数据，到底该怎么做。这里的”私钥”特指：加密货币钱包的助记词 / seed phrase / private key、SSH 私钥、PGP/GPG 私钥、企业根证书私钥——一旦泄露损失不可逆的那种。

为什么 safeStorage 一档不够

先把上一篇的结论搬过来，省得读者再翻一遍。safeStorage 的威胁模型上限是：

✅ 防硬盘被偷
✅ 防同机器其他登录用户
❌ 防同用户身份下的其他进程（macOS 弹授权框，Windows 直接通过）
❌ 防同 Electron 应用内的其他模块或扩展
❌ 防应用被供应链攻击注入恶意代码
❌ 防运行时调试器附加抢内存
❌ 防 V8 snapshot 篡改（CVE-2025-55305）

普通 API key 场景，前两条防住够了——丢了大不了 revoke 重发。但私钥场景，任何一条防不住都是灾难：

钱包助记词被读取 → 几万到几百万美元资产瞬间转走，链上交易不可回滚
SSH 私钥被读取 → 攻击者拿到所有你能登录的服务器
PGP 私钥被读取 → 历史所有加密通信被解密 + 未来所有签名被伪造

这个不对称是关键：私钥泄露的代价远远不是”重新申请一个”能止损的。所以任何商用钱包都不会只用 safeStorage——它们都加了一整套额外的防御层。

MetaMask 的做法：主密码 + 内存解密 + 自动锁屏

MetaMask 不是 Electron 应用，但它的浏览器扩展用的也是 Chrome 的存储 API（和 Electron 的 safeStorage 同根同源），代码完全开源、可以照搬到 Electron。它的核心机制：

1. 用户主密码派生密钥

// 概念示意（非 MetaMask 原文）
const masterKey = pbkdf2(userPassword, salt, {
  iterations: 10_000,
  hash: 'sha256',
  keyLen: 32
});

MetaMask 早期默认 PBKDF2 10000 轮 + SHA-256，但在 2023 年之后 @metamask/browser-passworder 已经升级到 600000 轮——这也是 OWASP 当前对 PBKDF2-SHA256 的最低建议值。如果你照着旧博客抄代码，记得把迭代数从 10k 升到 60 万以上。下面 checklist 也是按新标准给的。

2. AES-GCM（带认证）加密整个 vault

注意是 GCM 不是 CBC——GCM 有认证标签（auth tag），密文被改动一个 bit 解密会直接报错。这跟 safeStorage 用的 AES-128-CBC + 硬编码 IV 形成了直接对比，后者可以做位翻转攻击，前者完全免疫。

3. 解密后的私钥只存在内存，不写磁盘

打开扩展输入密码 → 私钥解密 → 存进 memStore 内存对象 → 浏览器关闭或锁定时清掉。磁盘上永远是密文形态。

4. 自动锁屏机制

默认 5 分钟不活动自动锁，重新解锁要再输主密码。这一条把”AI 被 prompt injection 时密钥在内存中”的时间窗口压到最短。

这套机制可以全套照搬到 Electron——所有原语（PBKDF2、AES-GCM、内存清理）Node.js 都原生支持。

Phantom 与 MPC 钱包路线：ChaCha20-Poly1305 + 密钥分片

Phantom 是 Solana 生态主流钱包，桌面版是 Electron。Phantom 公开披露使用 ChaCha20-Poly1305 加密本地 vault——这本身已经比 safeStorage 用的 AES-128-CBC 强一档。

ChaCha20-Poly1305 替代 AES-GCM 的好处：

在没有硬件 AES 指令的设备上比 AES-GCM 快很多（移动端尤其明显）
抵抗 timing attack 更强
密码学界普遍认为是更现代的选择（两者安全强度等价）

关于密钥分片——这部分我必须先说清楚：Phantom 自己披露过用到了 Shamir Secret Sharing 类型的方案，但具体怎么分、分几份、存哪里没有完全公开的技术文档。Phantom 新版的”Embedded Wallet”用的更接近 MPC / TSS（多方计算 / 门限签名），不是传统教科书式 Shamir。所以下面这套是业界（Web3Auth / Torus / Lit Protocol 等开源 MPC 方案）的通用做法，不是 Phantom 实际架构的精确描述：

业界 MPC 钱包通用做法（不是 Phantom 实际架构）

完整密钥 K（从不在任何一处完整存在）
    │
    ├─ Share 1（存设备 Keychain）
    ├─ Share 2（存云端，登录态加密）
    └─ Share 3（用户主密码派生）
    
任意 2 个 share → 恢复 K
单独 1 个 share → 零信息（不是部分信息，是信息论意义上的零）

这种”K-of-N 分片”思路的核心价值：

一份在 macOS Keychain / Windows Credential Manager（OS 级保护）
一份在云端（用户登录态加密）
一份在用户记忆里（主密码派生）

任何单一渠道泄露都不能恢复原私钥——即使攻击者完全控制了 Electron 进程，也只能拿到 1/3 的信息。这是真正的”纵深防御”。如果你要做钱包级产品，MPC 路线（Web3Auth / Privy / Lit）值得花时间研究，比自己造 Shamir 实现安全得多。

一份可以照抄的 Electron 钱包级私钥存储清单

把 MetaMask + Phantom 的做法合成一份工程实践清单，你可以直接用：

□ [必做] 用户必须设置主密码（不要让用户跳过）
□ [必做] PBKDF2 ≥ 60 万轮（OWASP 当前建议；不要省这个 CPU——这是攻击者暴力破解的唯一关卡）
□ [必做] AEAD 算法：AES-GCM 或 ChaCha20-Poly1305（绝对不要 CBC）
□ [必做] 每条加密数据用独立的随机 IV（不要硬编码、不要复用）
□ [必做] 解密后的私钥只在主进程内存，禁止传给 renderer 进程
□ [必做] 自动锁屏（默认 5 分钟），锁屏后清掉内存中的明文
□ [必做] 主密码绝不存盘，每次解锁都要用户输入
□ [必做] 涉及私钥的所有操作（签名、转账、导出）都要二次确认
□ [建议] 用 Shamir Secret Sharing 把密钥分成 2-of-3，单一渠道泄露不致命
□ [建议] 集成硬件 enclave（macOS Secure Enclave、Windows TPM）保存最敏感分片
□ [建议] 启用 Electron sandbox / contextIsolation / nodeIntegration: false 三件套
□ [建议] ASAR integrity 两个 fuse（防代码篡改）
□ [建议] 用户首次设置时强制提示「请抄写助记词到纸上」——纸是最好的防 prompt injection 介质
□ [建议] 对接 hardware wallet（Ledger、Trezor）作为 power user 选项

一个绕不开的诚实结论：硬件钱包永远更安全

写到这里有个必须说的话：纯软件方案的安全上限就在那里，碰不到硬件钱包。

Ledger / Trezor 把私钥存在专用 secure element，签名也在 secure element 内完成——私钥从出厂到报废全程不离开硬件。Electron 应用最多做到”私钥短暂存在内存几毫秒”，硬件钱包做到的是”私钥永远不进通用 CPU 内存”。

所以一个负责任的 Electron 钱包应该：

默认提供软件钱包（用上面那套机制）
强烈提示用户连接硬件钱包（一键签名授权）
金额阈值触发硬件钱包（比如单笔超过 1000 美元强制硬件确认）
诚实告诉用户软件钱包的边界（“这套加密能防硬盘被偷、防部分恶意软件，但不能防深度入侵——大额请用硬件钱包”）

这一步很多钱包不愿意做——因为这等于”承认自己的产品不够安全”。但这才是对用户负责的写法。

给 Electron 开发者的几句话

最后是给同行的：

不要从零造加密原语：用 Node.js 内置 crypto 或 node-forge、tweetnacl 这种被审计过的库。自己实现 AES-GCM 的 95% 概率是错的
不要相信”加密就安全”：safeStorage 名字里的 “safe” 不是银弹——它是个有明确边界的工具。私钥级别的存储 safeStorage 是底层之一，不是全部
威胁模型先于实现：你的产品要防什么？硬盘被偷？普通恶意软件？国家级 APT？不同等级用完全不同的方案。普通钱包做到防 APT 不现实也没必要
CVE-2025-55305 是个警钟：再好的加密也防不住进程本身被注入。所以永远不要把”加密”当成唯一防线，要配合代码签名、ASAR integrity、运行时完整性校验
保守不丢人：商业上”AI 自动签名 / 自动操作钱包”听起来很酷，工程上每多一层自动化就多一个攻击面。私钥场景，人类按确认键的那一下，是最重要的安全垫

写完这篇我自己也更清楚了：Electron 不是不能存私钥，是要做的工程量比想象中大得多。一句”用 safeStorage 加密一下”远远不够。真要做钱包应用，把 MetaMask / Phantom 的开源实现挨个读一遍，比看任何”5 分钟教你写 Electron 钱包”的教程都值。

延伸阅读：

拆开 Electron safeStorage 黑盒（本博客 blog169） - 本篇前传，safeStorage 自身的安全边界拆解
让 Claude Code 改我的真金白银交易代码（本博客 blog175） - 真金白银场景下凭证保护的另一面
MetaMask Vault Decryptor - 官方提供的密文格式参考工具
Phantom Wallet Security 文档 - ChaCha20-Poly1305 + Shamir 实现的官方说明
iOS Secure Enclave 文档 - 硬件级密钥保护的参考实现
Ledger 硬件钱包工作原理 - 私钥永不离开硬件的设计思路