[!info] related notes

• KDF: 密钥派生函数（KDF）
• Password Storage: Password Storage & Verification
• Algorithms: Argon2id, PBKDF2
• 对称密码: 对称密码学
• 密码管理器: 密码管理器
• Bitwarden: Bitwarden, [[z/vaultwarden|Vaultwarden]]

零知识加密架构（Zero-Knowledge Encryption）

一句话定义

零知识保险库架构的核心是：

服务端能够同步和认证用户，却没有解密用户保险库明文所需的最终密钥。

关键加解密在客户端完成。

这和普通服务端登录密码存储的目标不同。

两条必须分开的路径

路径 A：Vault Encryption

主密码
→ password-based KDF
→ master key material
→ unlock / derive wrapping key
→ 解锁随机生成的 vault symmetric key
→ 解密保险库数据

目标：

得到实际 encryption key material。

路径 B：Server Authentication

客户端由主密码/派生 key material 计算认证材料
→ 发送给 server
→ server 对 stored verifier 做认证

目标：

证明当前客户端掌握正确主密码派生能力，但不把 vault decryption key 交给 server。

所以：

password-derived encryption key ≠ ordinary server password verifier。

以 Bitwarden 当前模型理解

Bitwarden 当前支持：

• PBKDF2；
• Argon2id；

作为 master-password KDF。

默认账户仍可使用 PBKDF2；用户可切换 Argon2id。

简化模型：

master password

• account salt/KDF parameters
  → Master Key

Master Key
→ HKDF expansion
→ Stretched Master Key

随机生成 Symmetric Key
→ 被 Stretched Master Key 保护
→ Protected Symmetric Key 存服务端

同步时：

Protected Symmetric Key
→ client 下载
→ client 解锁
→ vault symmetric key
→ 解密 vault data

服务端存的是：

• encrypted vault；
• protected key material；
• authentication verifier/material；
• KDF parameters / metadata；

而不是 master password 或可直接解密 vault 的明文 key。

为什么随机 Vault Key 很重要

如果所有 vault data 都直接由：

master password-derived key

长期逐条加密，那么修改 master password 可能需要重加密大量数据。

更常见的设计：

random vault key
→ 加密业务数据

password-derived wrapping key
→ 只保护 vault key

于是改主密码时通常只需要重新保护较小的 key material，而不是重新加密整个 vault。

这就是 key wrapping / envelope-style thinking。

KDF 的角色

Master Password entropy 通常有限。

所以需要 password-based KDF：

• PBKDF2；
• Argon2id；

增加 offline guessing 成本。

这里 KDF 的目标是：

从用户记忆型 secret 派生 cryptographic key material。

这和普通 Web login 中：

password
→ stored verifier
→ yes/no

不是同一个输出语义。

HKDF 的角色

Bitwarden 还使用 HKDF 对已具有高熵的 key material 做进一步扩展。

这再次说明：

password KDF
≠ HKDF

前者面对低熵 password。

后者面对较高质量 keying material，用于：

• expansion；
• domain separation；
• key hierarchy。

服务端为什么仍能认证用户

“Zero Knowledge”不意味着：

server 什么都不知道，也不做任何 authentication。

Server 仍然需要某种认证材料。

关键边界是：

server-side authentication material 不应赋予 server 解密 vault 的能力。

认证与数据解密能力被分离。

Zero Knowledge 不等于 Server Breach 无风险

服务端即使看不到 vault plaintext，仍可能泄漏：

• encrypted vault；
• KDF parameters；
• account metadata；
• email；
• device/session metadata；
• encrypted item count / size pattern；
• authentication material。

攻击者仍可尝试：

offline master-password guessing。

所以：

• 强 master password；
• 合理 KDF 参数；
• MFA；
• 客户端安全；

仍然重要。

恶意客户端风险

零知识架构把信任从 server 大量转移到 client。

如果：

• browser extension 被篡改；
• desktop client 被供应链攻击；
• web vault JavaScript 被恶意替换；

客户端可以在 encryption 前直接读取：

• master password；
• plaintext vault；
• decrypted keys。

因此零知识并不消除 software supply-chain trust。

Account Recovery 的边界

“零知识”不自动推出：

用户忘记主密码就绝对无法恢复。

具体产品可能引入：

• organization recovery；
• emergency access；
• recovery key；
• device-bound recovery；

这些机制会改变 key-recovery trust boundary。

所以必须看具体 recovery design，而不是只背“zero knowledge = 永远不可恢复”。

与普通 Password Storage 的区别

普通 Web Login

password
→ password hashing scheme
→ stored verifier

server 只需要判断：

match / mismatch

Password Vault

password
→ KDF
→ key material
→ decrypt protected vault key
→ decrypt data

server authentication 只是其中另一个独立问题。

详见 Password Storage & Verification。

学习检查

1. 零知识保险库里“认证”和“解密”为什么必须分成两条路径？
2. password verifier 与 password-derived encryption key 有什么不同？
3. 为什么常用随机 vault key，而不是直接用 master-password-derived key 加密全部条目？
4. password-based KDF 与 HKDF 在 Bitwarden 类架构中分别承担什么？
5. server 不知道 master password，为什么仍然可以认证用户？
6. database breach 后为什么仍可能发生 offline master-password guessing？
7. zero knowledge 为什么仍然高度依赖客户端供应链安全？
8. account recovery 为什么可能改变零知识系统的 trust boundary？