通行密钥如何在 CardanoWall 中保护你的身份保险库

在 CardanoWall 中，通行密钥并不是你的身份，而是用来解锁身份加密副本的那把钥匙。你真正的身份是一段 32 字节的身份种子；通行密钥的作用，只是让你自己的设备能打开那个存放种子的加密保险库，这样每次签名或解密时，你就不必再粘贴一遍种子。

Face ID、Touch ID、Windows Hello、跨设备同步的平台通行密钥，或者一把兼容的硬件密钥，都可以充当这扇日常使用的门。门后面是 CardanoWall 服务器无法读取的密文。这种分离——种子才是身份，通行密钥只是一个解锁要素——就是整个设计的核心。

通行密钥究竟解决了什么问题？

它让本就强健的身份存储在日常使用中真正用得起来。

如果没有这样一层便利机制，每个回访的用户每次想签名或解密时，都得重新粘贴一遍身份种子。从狭义上说这是安全的，但很别扭——而别扭的安全往往会退化成不安全。人们会把秘密复制到不该放的地方，写在没有保护的便签里，或者干脆放弃使用这个工具。

通行密钥消除了这种摩擦。CardanoWall 为你的账户保存一个加密保险库，你自己的设备在完成一次用户验证（指纹、人脸识别、PIN，或者轻触硬件密钥）之后将其解锁。你只需轻触一次即可访问，而无需把种子的明文副本交给 CardanoWall。

这里所说的通行密钥是什么？

通行密钥是一种 WebAuthn 凭据——支撑它的公钥登录技术，正是现代网络上「用 Face ID 登录」背后的同一套机制。

在 FIDO 与 WebAuthn 模型中，凭据是为某个特定的依赖方（这里就是 CardanoWall 的域名）创建的，私钥那一半则由认证器持有。这个认证器可能内置在你的手机或笔记本里，可能通过通行密钥提供方同步，也可能保存在一把独立的硬件安全密钥上。

但对于身份保险库来说，普通的登录还不够。CardanoWall 需要认证器向浏览器释放一些高熵的秘密材料，浏览器才能用它来解密保险库。这正是 WebAuthn PRF 扩展所提供的能力。

用大白话说，WebAuthn PRF 是什么？

PRF 是伪随机函数（pseudorandom function）的缩写。支持 PRF 的认证器能产生一段秘密输出，它唯一对应于某个特定的凭据、依赖方，以及应用提供的一个盐值；只要输入相同，每次产生的输出也完全相同。

CardanoWall 会根据你的账户标识符确定性地派生出这个盐值，因此 PRF 输出被限定在你的账户范围内：同一把物理密钥若用于另一个账户，产生的材料就不同，无法打开错误的保险库。随后，浏览器会把 PRF 输出当作那把用于解开保险库的密钥。

从用户视角看，要点很简短：

认证器始终守着自己的秘密，从不导出；
浏览器只在验证仪式进行的那一刻看到解锁材料；
服务器只存储加密后的保险库密文；
服务器无法靠自己重新产生 PRF 输出。

正是这一点，让你的通行密钥成为保险库的解锁要素，而不是其中秘密的一份副本。

到底有哪些东西被加密了？

是你账户里的身份集合。

一个账户可以持有多个身份。这个集合记录了每个身份的身份种子及其私有标签，整个集合在被存储之前就已加密。保险库在每个账户下只有一行密文——它是不透明的服务端状态，而非托管。

CardanoWall 把它加密成一段 age-v1 密文，且仅寻址到 WebAuthn-PRF（fido2prf）接收方 stanza——每注册一把通行密钥对应一个 stanza。任何一把已注册的通行密钥，在成功完成验证仪式后都能打开保险库；具体实现会拒绝构建任何携带其他类型接收方的保险库，因此从构造上保证这套加密始终是纯对称的。

如果没有任何已注册的通行密钥，那么在服务端就根本不存在打开它的路径——这没有关系，因为种子本身才是真正可携带的身份。你随时都能从种子恢复。

为什么用通行密钥封装的保险库比用密码保护的更安全？

因为这里没有任何由密码派生的 stanza 可供离线穷举。

当攻击者窃走一份由用户自选密码保护的文件时，他们可以在本地对其进行猜测，速度只受硬件限制。这就是经典的离线暴力破解问题，弱密码或重复使用的密码必败无疑。

CardanoWall 托管的保险库不是围绕密码构建的。它封装到由认证器持有的 PRF 材料上——一把随机的 256 位密钥，藏在你的设备内部。因此，即便数据库泄露，攻击者拿到的也只是密文：没有可供攻击的密码哈希，也没有可读取的种子。这也是通行密钥总体上更适合日常访问的原因——它们规避了钓鱼和密码重复使用，同时让服务器彻底接触不到身份秘密。

那么针对保险库的量子攻击呢？

在这个问题上，准确比夸张更有价值。

托管保险库刻意不包含任何非对称公钥接收方 stanza。这一点很重要，因为人们担忧的那种大规模量子攻击——Shor 算法——针对的正是公钥系统。保险库的机密性是纯对称的：一把通行密钥的 256 位 PRF 输出将其封装，整个设计中根本没有公钥可供 Shor 式攻击瞄准。

针对对称密钥，相关的通用量子加速是 Grover 式搜索，通常被描述为大致把有效安全裕度减半。对于一把 256 位密钥，这会留下约 128 位的有效裕度——仍然是个天文数字。

所以诚实的说法不是「量子攻击不可能」，而是一个更克制、也更稳固的论断：托管保险库没有由密码派生的暴力破解面，没有可供 Shor 攻击瞄准的公钥目标，并且即便在通用量子搜索的假设下，对称密钥的安全裕度依然非常高。这听起来不那么炫，但它是一位安全读者真正能信赖的论断。

为什么不直接用 Cardano 钱包来解锁？

因为对一个挑战签名，并不能得到稳定的保险库密钥。

钱包签名对某些公开声明确实有用，但若要把它当作一个原语，用来重新派生出能跨设备、跨浏览器、跨钱包版本、跨不断变化的硬件支持去解密同一个保险库的秘密，它就太弱了。把保险库绑到钱包上，你就在不知不觉中让钱包的行为变成了账户恢复机制。

CardanoWall 让这些角色各司其职：

身份种子派生出你的 Label 309 签名密钥和接收密钥；
通行密钥解锁托管保险库；
Cardano 钱包签名则保留给明确的、绑定钱包的记录——当你刻意选择走这条路时才用。

同步通行密钥还是硬件密钥——我该用哪个？

两者都可以；正确的选择取决于该身份的价值。

同步通行密钥是便利的默认选项。它们可以通过你的提供方在新设备上重新出现——根据你的配置，这个提供方可能是操作系统钥匙串，也可能是密码管理器——这让寻常的恢复轻松得多。同步通行密钥继承的，是持有它的那个提供方的安全与恢复模型。

硬件密钥则更受控。因为访问需要那台物理设备，它们适合高价值或团队共享的身份——你希望把这个要素绑定在某件可以锁进抽屉的东西上。

一条合理的准则是：让通行密钥的形态匹配身份的价值。对大多数人而言，一把同步的平台通行密钥就是不错的日常之选。对于敏感的团队身份，一把硬件密钥外加一份妥善保管的种子，往往是更划算的取舍。同步通行密钥与硬件密钥之争一文详细梳理了二者的差别。

如果我的浏览器或密钥不支持 PRF 怎么办？

那么 CardanoWall 会退回到种子路径——这是有意为之的设计。

WebAuthn PRF 的支持情况取决于浏览器、操作系统和认证器的组合。CardanoWall 会在你注册保险库要素之前，先检测这套组合是否能够执行 PRF，因此你绝不会被引导进一个日后无法解锁的保险库。

仅凭种子访问并不是一种降级模式，而是那条主权之路：种子就是身份，其余一切都只是当平台能够安全支撑时，叠加上去的便利。

还有哪些地方可能出问题？

通行密钥封堵了一大类风险，但仍有几个现实问题存在，把它们直白地说清楚才是负责任的做法。

种子被盗即意味着身份被完全攻破。 谁持有你的身份种子，谁就是那个身份。应对之道是创建一个新身份并停用旧身份——而不是重置密码，因为根本没有密码。
已解锁的会话是一个活靶子。 在保险库处于解锁状态时，你的种子和派生出的私钥会驻留在浏览器内存中，以便你签名和解密。CardanoWall 会把这些材料置于 React 状态之外，并在锁定和退出登录时尽力将其清零，但在一个已解锁的会话里，恶意脚本或扩展仍可能读取内存中的秘密。严格的内容安全策略和最小化的脚本能降低这种风险，却无法将其消除。在一台你无法完全掌控的机器上，离开时请锁定保险库，而不要把会话开着就走人。
移除通行密钥不具有追溯效力。 当你移除某个要素时，客户端会把保险库重新加密给剩下的要素，旧的密文行会被硬删除，因此被移除的那把密钥再也打不开当前的保险库。但如果攻击者在你移除之前就已经用过那把通行密钥，移除并不能撤销他们已经做过的事。参见移除通行密钥会发生什么。
一旦全部丢失，那扇门就没了。 如果你弄丢了种子的每一份副本和每一个解锁要素，那个身份就再也无法被使用了。你已经发布的证明依然永远可验证——它们存在于 Cardano 上，而不在你的保险库里——但你不能再以那个身份行事了。

通行密钥能降低风险，但它们并不会免除你保护种子和设备的责任。

简短版

通行密钥让 CardanoWall 用起来方便，又不让 CardanoWall 成为托管方。

服务器存储的只有加密的保险库密文，没有任何它自己能解密的东西。你的通行密钥让浏览器派生出解锁所需的材料。你的身份种子，始终是整个身份那个可携带的根。先把种子保存好，再依靠通行密钥来完成日常访问。便利在上，主权在下。如果你想弄明白为什么在注册了通行密钥之后种子依然重要，请阅读为什么身份种子依然重要。