密码管理器能装进硬件钱包吗？SLIP-0016 加密存储的原理与局限

把密码库放进 Dropbox，谁能看到

SLIP-0016 是 2016 年由 Peter Jensen 提出的标准，状态 Final，回答一个很具体的问题：密码条目要同步到不可信的云服务（规范点名 Dropbox 这类），格式该怎么定，才能让云服务商看不到内容，同时硬件钱包用户用起来不费力。它的设计目标写得很坦白：为了让用户不接设备也能改标签，变更在不可信主机上加密签名，规范原话承认这带来一个”不幸的后果”——如果攻击者拿下的是这台主机，他既能读也能改元数据。换句话说，这份标准防的是云服务商和链路窃听，不防已经中毒的电脑。这一条常被二手介绍省略，但它决定了适用边界。

主密钥从设备里来：m/10016 一次调用

一切密钥都从硬件设备派生。规范规定向设备发送 CipherKeyValue（该原语定义在 SLIP-0011）：路径用 m/10016’/0——10016 就是 SLIP 编号加零前缀，走硬化派生；ENC_KEY 参数是明文提示串 Unlock encrypted storage?，长度上限 256 字节；ENC_VALUE 是一段 64 字节固定十六进制常量的两倍重复串；encrypt、ask_on_encrypt、ask_on_decrypt 都置 true，iv 不设。ask_on 双 true 的含义是：加密和解密都必须在设备上物理按按钮确认。返回结果切两半：前半做文件名密钥，后半做存储加密密钥。

文件怎么命名，条目怎么二次加密

文件名不是随机 UUID 而是 HMAC-SHA256：以文件名密钥（主密钥前半段）为 HMAC 密钥，对一个固定常量串 5f91add3fa1c3c76e90c90a3bd0999e2bd7833d06a483fe884ee60397aca277a 做 MAC，摘要即文件名。这样同一台设备在任何主机上都指向同一个远端文件，而外人从文件名反推不出设备身份。文件本体是加密 JSON，含配置、标签和条目数组。每个条目内部还有第二层：条目自身的 value 和 tag 字段用从设备另行派生的密钥单独加密——即使主密钥因主机失陷泄露，攻击者不接设备也解不开单个条目的值。

威胁模型逐条对照

把规范的承诺和没承诺的列清楚。能防的：云服务商看到密文与无法关联到设备的文件名；同步链路窃听；不带设备的人试图伪造修改（主密钥材料出不了设备）。防不住的：已在失陷主机上明文驻留的密钥与已解锁会话——规范明写攻击者可在该主机上读写元数据；离线字典攻击文件名（这部分强度取决于主密钥熵）。和 KeePass 之类本地库、以及keystore 文件是什么：加密私钥备份怎么看、怎么用讲的 keystore 文件相比，SLIP-0016 的差异在于信任根是硬件设备而不是主密码或口令 KDF：库文件本身不含口令派生的 KDF 参数保护，泄到公网后能否扛住爆破完全依赖设备派生密钥的不可获得性。

一次真实登录里密钥怎么流转

把 m/10016 派生放进具体动作里走一遍。假设你首次在带设备的钱包里启用密码管理：第一次初始化时主机把路径 [(10016 与 0x80000000) 按位或取无符号, 0]、提示串和那串固定 ENC_VALUE 发给设备，你在设备屏上按两下确认（一次加密一次解密的询问），主机拿到 64 字节主密钥并切半。之后每次读写库文件，主机先在本地用文件名密钥算出目标文件名，从云端下载密文，再向设备请求解密——设备屏幕上会再次出现”解锁加密存储”类提示。整个链路里长期驻留在电脑内存的是密文与文件名，明文只在读写条目的瞬间出现。规范还给每个条目配了独立的解密参数：加密条目时先生成 32 字节随机串（规范自嘲”被错误地叫作 nonce”），再以”Unlock 加 title 加 for user 加 username”为 key 参数向设备请求一次 cipherKeyValue，其结果连同 AES-256-GCM 的输出（12 字节 IV、16 字节认证标签加密文段）一起存进条目——解密时必须用同样的路径和同样的输入向设备重放这一次请求才能还原。这意味着条目的 title 或 username 被同步冲突改写后，该条目会因解密参数对不上而无法打开，多端合并时宁可保留双版本也不要覆盖式同步。

使用边界与替代现状

这套格式服务于 2016 年前后的 Trezor 密码管理生态，规范的作者署名是一个个人邮箱而非机构维护方，近年没有活跃演进。今天的现实是：主流密码管理器用零知识端到端加密加账户口令 KDF，硬件设备降级为第二因子。Passkey钱包安全吗？和助记词区别讨论过 passkey 路线，它与本协议同为”设备持私钥”，差别在注册的是账户凭证而不是可派生身份；如果你手上是老设备想验证”我的密码库到底安不安全”，正确的核对顺序是：确认库文件是否真按该格式由设备加密（拿设备重算一次文件名看能否对上）、条目 value 是否二次加密、以及你授权的设备上确认弹窗是否被习惯性地盲按。最后这条与安全习惯一致：ask_on_encrypt 和 ask_on_decrypt 全部置 true 的意义，只在你会读弹窗内容时才存在；把”设备上每一次确认按钮”当成无脑流程，等于自愿退回规范承认的那个漏洞。另外要分清楚层次：SLIP-0016 管的是口令库，不是钱包资产；两个体系共用同一颗种子，靠的是 m/10016 与 m/44’ 的路径隔离，密码库泄露本身不会推出任何币的地址私钥。