Chrome 146 中的 DBSC：TPM 会话保护

Chrome 146 引入 DBSC：TPM 绑定会话防钓鱼新机制

Windows 上的 Chrome 146 现已启用设备绑定会话凭证（DBSC）——这一协议使被盗的会话 Cookie 在非授权设备上完全失效。会话的私钥安全存储于 TPM 芯片内，永不离开硬件，必须通过硬件签名才能刷新令牌。这从根本上提升了认证安全性，突破了纯软件方案的局限。

DBSC 工作原理：从密钥生成到会话刷新

DBSC 针对 LummaC2、Vidar 等钓鱼攻击，这些恶意程序会从内存中窃取浏览器 Cookie。与长期有效的令牌不同，服务器发放的是短时效令牌，仅在验证了持有 TPM 私钥的加密证明后才可刷新。

具体流程如下：

• 会话注册：Chrome 向 TPM 请求密钥对，私钥保留在芯片中，公钥发送至服务器。
• 初始 Cookie：服务器保存公钥并发放一个短期令牌。
• 会话刷新：当 Cookie 过期时，浏览器收到挑战，通过 TPM 使用私钥签名，并将签名返回。
• 验证：服务器使用公钥验证签名，确认无误后发放新令牌以延长会话。

核心权衡是什么？会话与设备深度绑定。若无原始 TPM，即便复制了 Cookie 也无法使用。谷歌与 Okta 测试表明，会话窃取事件显著下降，具体数据未公开。

硬件安全优势：

• 私钥即使对 Chrome 或恶意软件也完全不可访问。
• 每次会话使用唯一密钥，有效防止跨站追踪。
• 对不支持 DBSC 的浏览器提供优雅降级机制。

应用绑定加密的经验：为何 TPM 更胜一筹

谷歌此前在 Chrome 127 中尝试过应用绑定加密（App-Bound Encryption），利用 Windows 系统服务加密 Cookie。但仅两个月后，MeduzaStealer、LummaC2 和 Rhadamanthys 就通过逆向工程绕过，且无需系统权限。

DBSC 将逻辑迁移至硬件：

| 特性 | 应用绑定加密 | DBSC |

|--------|----------------------|------|

| 密钥存储 | Windows 内存 | TPM 芯片 |

| 恶意软件访问 | 软件漏洞利用 | 仅限物理接触 |

| 绕过时间 | 2 个月 | 无硬件无法实现 |

| 隐私风险 | 可能暴露设备 ID | 仅共享公钥 |

这不是简单的混淆，而是信任根的转移。TPM 2.0（Windows 11 必备）支持不可导出密钥，真正实现硬件级保障。

后端实现：改动极小，轻松集成

前端无需修改——Chrome 自动处理加密逻辑。你只需新增两个接口：

• /register-session：接收公钥（WebCrypto 格式），与会话关联。
• /refresh-session：下发挑战，验证签名，轮换 Cookie。

实现逻辑：

• 设置较短的 Cookie TTL（如 5–15 分钟）。
• 刷新时生成随机数，验证 ECDSA 签名。
• 若 DBSC 不可用，回退至传统 Cookie 机制。

示例伪代码（Node.js/Express）：

const crypto = require('crypto');

app.post('/register-session', (req, res) => {
  const publicKey = req.body.publicKey; // JWK
  session.publicKey = publicKey;
  res.cookie('session', shortToken, { httpOnly: true, secure: true });
});

app.post('/refresh-session', (req, res) => {
  const { challenge, signature } = req.body;
  const isValid = crypto.verify(session.publicKey, Buffer.from(challenge), signature);
  if (isValid) {
    res.cookie('session', newShortToken, { httpOnly: true, secure: true });
  } else {
    res.status(401).end();
  }
});

W3C 规范开源（由谷歌与微软联合推动）。Edge 将采纳该标准；Firefox 与 Safari 是否跟进尚不确定。

平台限制与未来展望

• Windows：Chrome 146 已支持 TPM 2.0。
• macOS：未来版本预计支持 Secure Enclave。
• Linux：尚无统一的 TPM 替代方案。
• 移动端：Android StrongBox 有潜力；iOS 取决于 Safari 支持情况。

若 TPM 故障（如更换硬件），用户需重新登录并生成新密钥对。该机制不适用于无硬件 TPM 的虚拟桌面环境（VDI）。

核心要点：

• DBSC 打破信息窃取者的商业模式：没有 TPM，盗取的 Cookie 一文不值。
• 它不替代双因素认证（2FA），而是强化登录后的会话安全。
• 后端改动极少：仅需增加两个接口和设置 TTL 逻辑。
• 硬件绑定有效防范跨设备滥用。
• 开放的 W3C 标准提升广泛采用的可能性。

对中高级工程师建议：在身份认证（IAM）、银行等高价值服务中优先部署。务必测试降级路径及边缘场景（如缺失 TPM）。

— Editorial Team