4. Passkey技术原理

要真正把Passkey用好，不能只停留在“它比密码安全”的层面，而必须理解它在协议层是如何被构造、存储和迁移的。Passkey并不是一种全新的密码学算法，而是WebAuthn凭证在“可发现、可同步、可托管”三个维度上的工程化组合。本节围绕四个核心问题展开：凭证如何被服务端“发现”，同步型与设备绑定型Passkey有何本质差异，多设备同步如何做到不泄露私钥，以及密钥托管在安全模型中引入了哪些新的信任假设。

一、可发现凭证：从“先输用户名”到“无用户名登录”

传统WebAuthn认证流程通常要求用户先输入用户名，服务端返回该用户已注册的凭证ID列表，浏览器再调用navigator.credentials.get()并传入allowCredentials。这种方式称为“服务端凭证发现”。而可发现凭证（Discoverable Credential，旧称Resident Key）把凭证ID和用户信息直接存放在认证器内部，登录时无需先提供用户名，认证器即可自行列出可用账户供用户选择。

可发现凭证的关键在于认证器需要持久化保存user.id、user.name、rp.id以及私钥句柄。注册时通过authenticatorSelection声明需求：

{
  "rp": { "id": "example.com", "name": "Example" },
  "user": {
    "id": "b3J5YW4tMDAx",
    "name": "ryan@example.com",
    "displayName": "Ryan"
  },
  "challenge": "随机挑战值",
  "pubKeyCredParams": [{ "type": "public-key", "alg": -7 }],
  "authenticatorSelection": {
    "residentKey": "required",
    "userVerification": "preferred"
  },
  "excludeCredentials": []
}

当residentKey为required时，认证器必须把凭证写入可发现存储区。登录时服务端只需下发空allowCredentials，浏览器弹出账户选择器，用户选中后返回userHandle，服务端据此定位账户。这一机制是“无用户名登录”和“一键登录”体验的基础，但也意味着认证器存储容量成为约束——平台认证器通常有数量上限，超出后需用户清理或依赖同步机制。

二、同步型Passkey与设备绑定Passkey

Passkey按私钥是否可跨设备迁移，分为同步型（Synced Passkey）和设备绑定型（Device-bound Passkey）。同步型Passkey的私钥由平台密钥链（如iCloud Keychain、Google Password Manager）加密后同步到同一生态的其他设备；设备绑定型Passkey的私钥永不离开单一认证器，例如YubiKey等硬件安全密钥。

选择哪种类型，取决于风险模型。同步型Passkey提升了可用性和恢复能力，但把信任部分转移给了平台账户；设备绑定型Passkey降低了平台托管风险，却提高了丢失和运维成本。高安全场景常采用“同步型为主、设备绑定型为辅”的双凭证策略。

三、多设备同步机制与端到端加密

同步型Passkey的核心难题是：私钥如何在设备间迁移，同时平台服务端又不能读取私钥。主流实现采用端到端加密（E2EE）：私钥在源设备上使用同步密钥加密，密文上传到平台云；目标设备通过平台账户体系获取同步密钥后解密。平台云只存储密文，理论上无法解密。

同步密钥的派生与保护通常依赖平台账户的主密钥或安全隔区（Secure Enclave）。以典型流程为例：

1. 设备A生成Passkey私钥，使用同步密钥K_sync进行AEAD加密，得到密文C。
2. 密文C与元数据上传至平台云，服务端仅做存储与版本管理。
3. 设备B登录同一平台账户，通过账户恢复或设备配对获得K_sync。
4. 设备B拉取密文C，本地解密得到私钥，完成Passkey可用。

四、密钥托管与信任模型复盘

密钥托管是同步型Passkey无法回避的现实：为了让用户换机后仍能登录，私钥必须可恢复。托管方式主要有三类：平台密钥链托管、企业MDM托管、以及第三方密码管理器托管。每种方式都改变了信任边界。

• 平台密钥链托管：信任平台账户安全与E2EE实现，恢复体验最好，但跨生态迁移困难。
• 企业MDM托管：企业可管理员工Passkey生命周期，适合合规场景，但需防范管理员权限滥用。
• 第三方密码管理器托管：跨平台能力较强，但用户需信任该厂商的加密与运营安全。

复盘一个真实场景：某团队为管理员启用同步型Passkey，但平台账户仍可用邮箱验证码恢复。攻击者通过钓鱼获取邮箱验证码后重置平台账户，进而获得同步密钥并解密Passkey。修复方案是为管理员账户强制使用设备绑定型Passkey，并将平台账户恢复改为硬件密钥验证。这说明Passkey的安全强度不仅取决于WebAuthn协议本身，还取决于密钥托管与恢复链路的整体设计。

理解可发现凭证、同步与设备绑定、多设备同步及密钥托管，是制定Passkey认证策略的前提。只有把凭证类型、同步机制和恢复流程作为一个整体来设计，才能在安全性与可用性之间取得可控的平衡。