跳到内容 你知道了 为什么通行密钥应用程序对 Windows 的处理方式与其他操作系统不同。图片来源：Aurich Lawson | Getty Images 上周，一位研究者概述了他所说的通行密钥中的 “新攻击面”，这一新的身份验证范式提供了一种比基于密码的方法更安全的替代方案。事实上，帖子中演示的攻击既不新颖，也并非通行密钥独有。这一区分很重要，因为这项研究在终端用户和安全专业人士之间造成了困惑，他们在评估这种新机制是否真的安全可用时。这个攻击被称为 Pass-ta-key——是将“通行密钥”与“传递密钥”这个短语结合在一起，并暗指一盘意大利面的名称。安全公司 Palo Alto Networks 的研究员 Arie Olshtein 在上周的帖子中描述了 Pass-ta-key 如何在运行恶意软件的机器上获取 Windows 上存储的 Google 密码管理器应用程序（GPM）中的所有通行密钥。这让许多人感到惊讶，因为他们相信通行密钥只存储在受信任的平台管理器（TPM）中，这是保留用于存储加密密钥和其他高度敏感信息的锁定围 enclave，保证 Windows 机器的安全。如果通行密钥存储在 TPM 中，那 Pass-ta-key 如何能够提取应用程序存储的整个通行密钥集，他们想知道？ 本地通行密钥存储可以，但有一个例外 答案是，与普遍的看法相反，FIDO 2 规范——由行业组织 FIDO 联盟管理——并不要求通行密钥必须保存在 TPM 或任何其他专用硬件中（取决于平台，它们以不同的名称存在，包括安全围 enclave、受信执行环境和强密钥管理箱）。事实上，大多数平台和第三方软件不将通行密钥存储在这种专用硬件中。几乎唯一的例外是微软，它为用户提供了将通行密钥存储在 Windows TPM 中的选项。该公司主要建议企业用户选择此选项，而非消费者。直到我开始为这篇文章进行研究，我才意识到，除了运行 Windows 的平台，所有平台都将通行密钥保存在设备本地。几年前，操作系统和第三方应用程序开发者意识到通行密钥如果无法轻松同步到用户的所有设备，就没有机会获得广泛使用，因此转向本地存储。要求使用 TPM 存储使得同步变得不可能。将它们加载到新设备的 TPM 中的唯一方法是逐一重新创建每一个。最终，FIDO 规范的设计者决定在设备上存储通行密钥通常是安全的。考虑到应用程序权限非常细粒度，因此在设备上潜伏的恶意软件将无法访问构成通行密钥安全基石的私钥。例如，安装在 macOS、iOS 和 Android 的设备上的恶意软件没有能力突破这种隔离，除非操作系统本身通过某种极端的零日漏洞受到威胁。到目前为止，这些假设已在实际操作中得到证明。唯一的例外是 Windows。与其他所有平台不同，Windows 应用通常以用户的所有权限运行，而其他平台则鼓励默认限制每个应用的权限。虽然 Windows 提供了一些沙箱保护措施，旨在隔离应用程序，但并不能阻止未沙箱化的应用（例如恶意软件）访问沙箱应用的数据。也就是说，沙箱只保护一个方向。其他平台的沙箱技术要保护得多。那意味着，Windows 上的恶意软件在访问被单独应用使用的数据时遇到的障碍明显较少。通行密钥设计者深知这种差异，这在很大程度上是为了向后兼容 Windows。由于没有信心确保存储在 Windows 设备上的通行密钥在发生恶意软件感染时不会被采集，许多第三方开发者选择了一种新设计——将通行密钥存储在端到端加密的数据块中，这些数据块位于云端。目前，存储在服务器上的通行密钥不仅是 Windows 的 GPM 使用的设计，还有 1Password、Dashlane 和其他第三方应用也适用于 Microsoft 操作系统。简而言之，这里的运作方式是：当 Windows GPM 用户想要使用通行密钥登录某个网站时，设备从 TPM 中检索用户和/或设备密钥，并将其提供给 Google 的后端身份验证器。密钥的呈现，加上设备已登录用户的 Google 账户，会触发 Google 服务器向用户想要登录的网站提供身份验证声明。该声明是用存储在 Google 服务器上的加密形式的私钥签名的。这样，用户就可以登录。再次强调，大多数其他 Windows 平台的第三方应用也是以相同的方式工作的。其他平台上的相同应用也都是如此。