一台设备一把钥匙用到老？SLIP-0017 把服务 URI 变成 ECDH 会话密钥

加密通道的钥匙从哪来

端到端加密的会话建立要靠 ECDH——原理层ECDH 密钥协商是什么？两个从不共享秘密的人如何算出同一把锁讲过：各自亮出公钥，各自用对方公钥乘自己私钥，两边得到同一个点。硬件钱包参与这类协议时的尴尬是：设备里那棵树是为管钱设计的，加密会话如果也随手借资金链路的密钥，等于把通信秘密和资产秘密捆在一起丢进同一口锅；而如果给每个服务临时造一把新钥匙，备份又成了噩梦。2016 年 5 月 29 日 Roman Zeyde 提出的 SLIP-0017 给出第三条路：为每个服务从同一颗种子派生一把专用密钥——备份模型和备份钱包完全一致，用途却彼此隔离。官方状态 Final，类型 Standard。

服务身份：URI 加索引

与登录协议用硬件钱包登录网站是什么原理？SLIP-0013 服务身份与签名登录拆解一样，这份规范把”某个服务”抽象成身份二元组：一部分是符合 RFC 3986 的 URI，形如协议前缀加可选的用户名与主机、端口、路径（示例风格如 https 前缀的站点、ssh 前缀带端口的主机）；另一部分是一个三十二位无符号整数索引，让同一 URI 能派生多把密钥。两部分的组合先做一步哈希加工：索引按小端字节序拼在 URI 前面，拼串取 SHA-256，截前一百二十八位，切成四个三十二位小端整数 A、B、C、D，再把每整数的最高位置起（等效全部转成硬化索引），最终按 SLIP-0010 体系派生 m/17’/A’/B’/C’/D’。整条路径完全由”服务是什么”决定，与任何会话参数无关——同一设备、同一颗种子，对同一服务永远落在同一把密钥上。

会话密钥的调用与限制

共享秘密环节走一个设备端调用：钱包先取到对方的公钥 P2，调用形如 GetECDHSessionKey 的接口，让设备在内部用自己的私钥 k1 乘 P2 得到曲线点 Q；对方用自己的私钥乘本方公钥也能算出同一个 Q，这就是会话共享秘密。规范示例选的是”索引 42 加某站点登录路径”这样一条具体身份演示六步换算。需要记住的边界在曲线支持上：按 SLIP-0010 的通用派生框架，secp256k1 与 NIST P-256 支持常规与硬化两种派生，而 ed25519、curve25519 只支持从私钥到私钥的硬化派生、不支持由公钥向下推导——对加密会话场景这通常无碍（会话密钥用后即抛，本就不需要对外暴露派生链），但对比服务文档时不要把两套曲线的规则混着引用。

为什么值得单独一层

与 SLIP-0013 同构的 URI 哈希设计说明：把”服务身份”塞进 HD 树的思路在当年被视为整个身份族规范的公共底座，用途层 13 管认证、用途层 17 管加密，各自把服务映射进树的互不相交分支，任何一条分支泄露都不牵动资金路径（m/44’ 等）。这也让”跨设备恢复”免费获得：换一台支持本规范的设备、导入同一颗种子，所有服务的 ECDH 密钥原位复现，对方甚至不需要重新交换公钥。代价是密钥的”前向性”完全依赖种子安全——种子在手等于全部会话历史密钥在手，这是这套可恢复模型的固有取舍，和”设备内每会话现造临时密钥”的 Signal 式方案是两类安全目标。

落地现状的核对方法

这份 Final 状态的规范主要出现在 Trezor 生态与借鉴它的实现里；主流消费级钱包是否暴露 ECDH 能力、对哪些曲线开放，以各厂商开发者文档为准，无法从规范本身推断。用户侧的核对很朴素：如果某加密产品宣称”用你的硬件钱包密钥加密会话”，问三件事——它派生用的是 17 层还是别的用途号、目标曲线在设备上支持哪种派生模式、设备屏上是否完整显示了服务身份让你确认。三问皆哑，多半是把 ECDH 当作营销词而非真实密钥管理。顺带一提，本族规范与登录类规范同页共存于 satoshilabs 的 SLIP 仓库，读文档时留意编号，13 与 17 常被二手资料张冠李戴。

一句合规提醒

机制讨论不等于隐私承诺：端到端加密的强度还取决于协议其余环节（密钥确认、元数据泄露、端点安全），本规范只解决密钥的组织与恢复。本文不构成投资、产品或合规建议；涉及跨境通信的合规义务请以所在地法规为准。