手机解锁用的通行密钥（passkey）能不能直接拿来签链上交易？Sui 在 2023 年提交、状态为 Final 的 SIP-9 给出的回答是：可以，但不能复用原来的签名格式，必须为 WebAuthn 的签名载荷单开一套方案。这篇讲清楚为什么“多出来的数据”不兼容，以及这种钥匙该怎么配保管组合。
WebAuthn 不签任意消息
通行密钥背后的 WebAuthn 标准并不承诺“给它一段任意消息，它签给你”。它的设计场景是登录：认证器对服务器挑战加客户端数据做固定格式的签名，产出里除了签名字节，还附带认证器数据（authenticatorData）和客户端数据 JSON（clientDataJson）。Sui 网络上 secp256r1 这条曲线的原始签名能力本来就有——通行密钥大多也正是用 secp256r1 出签——但现有验签逻辑只看到签名字节，不看那两段附带数据，等于放弃了“谁签的、在哪个来源上签的”这两条关键信息。SIP-9 的判断是：与其把载荷塞进消息哈希里将就，不如新增一种签名方案，把三段数据一起纳入格式。
0x06 标志里的三段结构
新方案命名为 passkey，签名序列化时以标志字节 0x06 开头，后面按 BCS 结构依次放三段：认证器数据、客户端数据 JSON、以及 secp256r1 签名本体。验签方因此可以完整复核：这条签名来自哪个认证器、challenge 绑定的是哪个来源。算法层面提案限定只允许 secp256r1，通行密钥硬件支持的其余算法不在方案范围内。这一套与以太坊侧的思路是两条路线：EVM 走的是给合约加 secp256r1 预编译、让 gas 便宜到可用的方向（通行密钥终于能在链上便宜验签：EIP-7951 与 secp256r1 预编译），而 Sui 直接把认证载荷做进协议签名方案里。同一家族的问题，不同的解法层级。
三种典型签名动线
提案给出了三条动线。桌面浏览器发起交易、手机上的通行密钥来签：钱包扩展弹出二维码，手机扫码后经蓝牙安全通道与桌面设备配对，用 PIN 或生物特征解锁密钥完成签名，签名回传桌面端广播——用户装的外设一个不多。桌面浏览器发起、硬件安全密钥来签：插 USB 或贴 NFC，按提示输入 PIN 或按指纹；提案特别叮嘱，安全密钥上的通行密钥不可导出、没有备份，丢了就没了，建议只把它当多签里的一个签字人用。同设备签名：手机 App 发起、手机自己的通行密钥确认，PIN 或生物特征通过后直接签名广播，这条线最接近普通 App 的支付体验。
方便背后的保管权安排
用通行密钥，意味着私钥材料不出设备的安全区，云同步的密钥由设备生态托管、可在多设备间恢复——这些性质在 通行密钥攥在手里还是存在云上：同步形态与设备绑定形态的边界 里拆过，同步形态省心的另一面是保管权交给了云。SIP-9 给出的对冲示范是多签：按二-of-四门槛，云同步的手机密钥权重一、硬件安全密钥权重一、硬件钱包权重二，日常用手机加安全密钥就能凑够门槛签名，任何单一设备丢了都不至于丢账户，云同步密钥也永远不能单独动钱。它和 zkLogin 也要分清：Sui zkLogin 是什么？为什么 OAuth 登录后没有任何人拿着你的私钥 里那套是拿 OAuth 凭证加零知识证明派生地址，通行密钥则是认证器直接出签名的另一条入口，两者可以在同一个钱包里并存。
动手前值得先弄清的几件事
打算把通行密钥当日常签名方式的读者，建议在小额演练前先回答四个问题：这把密钥存在哪里，跟着哪个云账户同步，换设备时靠什么恢复，以及它出事时谁能替你冻结。云同步形态的恢复走的是账号体系（邮箱、设备锁、身份验证），而不是链上助记词，两者泄露的后果完全不同；设备绑定形态没有云恢复，设备故障即钥匙故障，SIP-9 示范的多签组合正是为这类单点准备的。演练动线也简单：拿小额资产建一个 passkey 地址，发起一笔转账走完“弹窗—认证—广播—回执”全程，再故意拒绝一次签名，确认应用在哪一步中止。签完看不懂的交易弹窗不该顺手按通过，这一条与助记词钱包并无区别。
边界与风险提示
通行密钥签名不是“没有密钥”，只是密钥住进了另一类设施：设备安全区、云账户、生物特征解锁，每一环的信任模型都不同，同步与设备绑定形态的差别不会因为“用了 passkey”这三个字就消失。SIP-9 是 Sui 协议层的方案，其他链的通行密钥路径与限制各自另算。本文为机制说明，不构成投资建议；涉及资产的实际签名，先小额演练再上量。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。