如何管理客户端加密的密钥？

本文目录导读：

1. 基于用户秘密（密码/PIN码）的密钥派生（最安全，最普遍）
2. 基于硬件安全模块（TPM/HSM/安全芯片）
3. 基于远程密钥服务（KMS/HSM as a Service）
4. 基于密钥分享/门限方案（Shamir‘s Secret Sharing）
5. 核心安全实践（无论采用哪种策略都需遵守）
6. 决策树（帮助你选择）

管理客户端加密的密钥是安全工程中最具挑战性的问题之一，核心矛盾在于：你需要在客户端（一个不可信的环境）安全地存储或获取一个秘密，同时防止攻击者（或恶意用户）窃取它。

没有一种“银弹”方案可以完美解决所有场景，通常需要根据你的威胁模型（即你最担心谁？黑客？用户自己？服务端泄露？）来选择策略。

以下是几种主流的密钥管理策略，按安全性从高到低（或从复杂到简单）排序：

基于用户秘密（密码/PIN码）的密钥派生（最安全，最普遍）

核心思想： 服务端永远不存储原始密钥，密钥由用户输入的密码，在客户端通过密码学算法（如PBKDF2、Argon2、scrypt）即时派生。

• 流程：
  1. 用户设置密码。
  2. 客户端用密码 + 随机盐值（Salt） + 高强度迭代函数 生成一个加密密钥。
  3. 这个密钥仅存在于内存中，用于加密/解密数据。
  4. 服务端只存盐值和密码的哈希（用于登录验证），不存加密密钥。
• 优点： 服务端被攻破，黑客拿不到盐值和哈希也无法还原密钥；用户密码就是密钥的核心,高度可控。
• 缺点： 用户忘记密码，数据将永久丢失（无法找回）；弱密码易受离线字典攻击。
• 适用场景： 端到端加密（E2EE）聊天、密码管理器（如1Password、Bitwarden）、零知识证明的应用。

基于硬件安全模块（TPM/HSM/安全芯片）

核心思想： 将密钥绑定到物理设备上,使得密钥无法被复制或提取到另一台机器。

• 流程（以Web环境为例，如WebAuthn或Web Crypto API）：
  1. JavaScript调用 crypto.subtle.generateKey()，并设置 extractable: false。
  2. 浏览器将密钥存储于操作系统的安全存储区（如Windows TPM、macOS Keychain、Android TEE、iOS Secure Enclave）。
  3. 进行加密解密时，JavaScript只能调用API,拿不到密钥的原始字节。
• 优点： 极高安全性，密钥不会泄露给任何应用或进程,防钓鱼。
• 缺点： 用户换设备或卸载应用后密钥丢失；浏览器兼容性（老设备不支持）；无法在不同设备间同步。
• 适用场景： 数字签名、支付认证、企业设备管理、需要防物理提取的高安全性应用。

基于远程密钥服务（KMS/HSM as a Service）

核心思想： 客户端不存储密钥，而是向一个专门的密钥管理服务（如AWS KMS、Azure Key Vault、HashiCorp Vault）请求加密解密操作。

• 流程：
  1. 客户端向你的后端服务请求“加密数据”。
  2. 后端使用自己的凭证调用远程KMS。
  3. KMS执行加密，返回密文给后端,后端返回给客户端。
• 优点： 密钥集中管理，轮换、审计简单；不依赖客户端环境。
• 缺点： 客户端在过程中不持有密钥，严格来说是“托管式加密”，不是真正的客户端加密；需要在线；信任服务端。
• 适用场景： 企业级SaaS应用（如密码共享库）、需要合规审计的场景。

基于密钥分享/门限方案（Shamir‘s Secret Sharing）

核心思想： 将密钥拆分成N个碎片，至少需要M个碎片才能恢复（如3/5）。

• 流程：
  1. 用户在客户端生成主密钥。
  2. 使用门限算法（Shamir）将主密钥分成5份碎片。
  3. 客户端将其中一份留给自己（或本地安全存储）,另外四份发送给不同服务器或信任的联系人。
  4. 恢复时，客户端从本地+其他来源收集足够碎片。
• 优点： 即使某个碎片服务器被攻破，也无法恢复密钥；用户可自主找回（通过联系人）。
• 缺点： 逻辑复杂；碎片管理（如联系人丢失/不响应）会导致数据丢失。
• 适用场景： 顶级安全需求的加密货币钱包（如以太坊的多签）、极端防单点故障的场景。

核心安全实践（无论采用哪种策略都需遵守）

1. 绝对不要硬编码密钥：永远不要在源代码、配置文件、Git仓库中写入明文密钥。
2. 使用成熟的加密库：不要自己写加密函数，使用如 libsodium、Tink、Web Crypto API 等经过严格审计的库。
3. 密钥派生函数（KDF）：如果使用密码派生，必须加盐（Salt），并采用PBKDF2、Argon2id等现代KDF，迭代次数要足够高（如100万次以上）。
4. 密钥轮换：定期更换密钥，客户端需要支持使用旧密钥解密旧数据,再用新密钥重新加密。
5. 安全擦除：当密钥不再使用时（应用关闭、用户登出），主动、安全地清零内存中的密钥对象。
6. 考虑平台特性：
   • Web端：使用 window.crypto.subtle（注意其不支持所有算法） + IndexedDB（仅限可提取密钥）。
   • 移动端（iOS/Android）：使用 Keychain（iOS） 或 Android Keystore。
   • 桌面端：使用 OS的凭据管理器（Windows Credential Locker、macOS Keychain） 或 Electron的safeStorage API。

决策树（帮助你选择）

• 如果你的用户需要跨设备同步且不信任服务端？ → 推荐： 基于密码派生（如使用用户的主密码作为种子，再结合设备特定盐值） + 端到端加密,用户密码就是密钥。
• 如果你的应用是单设备高安全性应用（如加密货币钱包、数字身份证）？ → 推荐： 硬件安全模块（TPM/Secure Enclave） + 生物识别,密钥永不离开设备。
• 如果你是普通SaaS应用，用户并不理解密钥概念？ → 推荐： 服务端托管密钥（KMS），用户无感知,由你保证安全。
• 如果你需要防丢失且高安全性？ → 推荐： 门限密钥（Shamir Secret Sharing） + 可信恢复服务。

最后一条黄金法则： 仔细分析你的威胁模型，如果你最担心的是“黑客攻破服务器”，那么密码派生是核心；如果你最担心的是“用户手机被偷”，那么硬件绑定是核心，明确风险后,再做选择。