一句话定位：硬件钱包里的对称加密开关
钱包软件想让硬件设备对一段任意数据做对称加密时，绕不开 2014 年 6 月定稿的 SLIP-0011 CipherKeyValue——同一颗助记词能派生加密钥匙吗？SLIP-0021 对称密钥树详解 的动机部分点名批评过的正是它的老用法，但作为设备端原语它至今仍被复用。它解决的问题很具体：密钥永远不离开设备，而且用户想不想强制按确认键，决定权在设备端而不是电脑端。后来常被引用的 密码管理器能装进硬件钱包吗？SLIP-0016 加密存储的原理与局限 和给交易备注加密的 SLIP-0015，都是在这个原语上叠业务规则。理解它，才算理解硬件钱包在转账签名之外的另一半工作。
调用时递给设备的七样东西
一次 CipherKeyValue 请求带上：BIP-32 派生路径、一个会显示在设备屏幕上的提示词 key、要加密的值 value、加密还是解密的方向标志、加密时要不要确认、解密时要不要确认，以及一个可选的初始向量 IV。value 真正被加密，key 则主要起告知作用——设备上弹确认框时显示的就是它。注意长度门槛：value 必须是 16 字节的整数倍，因为底层是分组密码，补齐工作（比如 PKCS7 填充）由调用软件自己负责，设备只认整块。
E1/E0 与 D1/D0：确认选项如何焊进密钥
真正精彩的是防绕过设计。设备把提示词 key 的末尾按方向拼上 E1 或 E0（加密时是否要求确认）、再拼 D1 或 D0（解密时是否要求确认），然后用这条路径下的 BIP-32 私钥对拼好的字符串做一次 HMAC-SHA512。算出的 64 字节里，前 32 字节当 AES 密钥，第 33 到 48 字节当 IV（没有手工指定 IV 时）。也就是说，路径、key、两个确认标志任何一项不同，派生出的 AES 密钥和 IV 就完全不同——想偷偷把确认关掉再解同一份数据，解出来只会是垃圾。确认策略不是界面上的软开关，而是被编码进了密钥本身。
一次真实调用长什么样
把参数摆齐走一遍：假设某密码管理器想让你在设备上确认一次加密操作，它会发路径 m/10016’/0、key 提示串、待加密的 32 字节明文、方向设为加密，并把 ask_on_encrypt 置真。设备先弹屏显示提示串让你按确认键，然后按前述规则算出 AES 密钥与 IV，CBC 模式加密后把密文交回电脑。电脑端拿到密文存进自己的存储或云端；下次解密再发一次请求，方向换成解密。两个方向的确认标志是完全独立的：软件可以把加密方向设为需确认而解密方向免确认，也可以两个都要。设备端逻辑的价值在于，一旦这两个比特被某个应用写进它固定的提示串组合里，别的恶意程序就无法用同一密钥配一组关闭确认的参数来偷偷复用这条通道——它拿到的只会是另一把无关的密钥。
站在原语之上的两栋楼
交易备注放云端会被看到吗？SLIP-0015 元数据加密格式拆解 就是这套机制的下游应用之一：它让设备对路径 m/10015’/0 调用 CipherKeyValue，路径编号取提案号补零，key 参数是提示串 Enable labeling?，密文可以安心放云端，因为密钥只有拿同一台设备才能复现。密码管理器方向的 SLIP-0016 同样走 m/10016’/0。两篇文章里那句该原语定义在 SLIP-0011指的就是这里。惯例值得记住：凡看到 m/100NN’/0 这类路径加提示串的组合，背后基本都是键值加密原语在干活，而提示串会原样出现在设备屏幕上。
边界：谁能信任这台设备
要清醒的几点。第一，SLIP-0011 状态是 Final，但公开实现主要围绕 Trezor 系固件，其他品牌硬件钱包未必提供同名接口，教程里凡涉及具体按钮路径都以设备厂商现文为准。第二，加密强度等于设备自身的强度：固件被提取、种子泄露，密文与明文无异。第三，密文放云端时，云服务商仍看得到文件名、大小、时间这些元数据，SLIP-0015 那类方案防的是内容泄露而不是全部画像。第四，AES-CBC 不验证完整性，篡改密文会安静地解出错误明文，重要数据应在明文层自带校验。
风险提示
本文为密钥派生与加密机制科普，不构成投资建议或安全产品推荐。任何要求你在电脑端输入助记词以复现设备密钥的工具都应视为高危；正规流程中密钥派生只在设备内完成。涉及具体固件行为时，以硬件钱包厂商官方文档当时的版本为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。