New Pass-ta-key attack reveals all the things we didn’t know about passkeys

新型“Pass-ta-key”攻击揭示了我们对通行密钥（Passkeys）的认知盲区

Last week, a researcher outlined what he said was a “novel attack surface” in passkeys, the new authentication paradigm that offers a more secure alternative to password-based methods. In fact, the attacks demonstrated in the post are neither novel nor unique to passkeys. This distinction is important because the research has generated confusion among end users and security professionals as they assess whether this new mechanism is truly safe to use.

上周，一位研究人员概述了他所称的通行密钥（Passkeys）中的一个“新型攻击面”。通行密钥是一种新的身份验证范式，旨在提供比传统密码更安全的替代方案。事实上，文章中演示的攻击既不新颖，也不是通行密钥所独有的。这一区别至关重要，因为这项研究在终端用户和安全专业人员评估这种新机制是否真正安全时，引发了困惑。

The attack is called Pass-ta-key—a blending of the word passkey with the phrase “pass the key” and a nod to a plate of pasta. Arie Olshtein, a researcher at security firm Palo Alto Networks, described in a post last week how Pass-ta-key could obtain all passkeys stored in the Google Password Manager app (GPM) for Windows when it’s running on a machine infected with malware. This came as a surprise to many people because they believed passkeys are stored exclusively in the trusted platform manager (TPM), the locked-down enclave in a hardened silicon chip that’s reserved for storing cryptographic keys and other highly sensitive information on Windows machines. If passkeys are stored in the TPM, then how was Pass-ta-key able to extract the entire set of passkeys stored by the app, they wanted to know.

这种攻击被称为“Pass-ta-key”——它是“passkey”（通行密钥）与“pass the key”（传递密钥）这两个词的结合，同时也戏仿了“pasta”（意大利面）。安全公司 Palo Alto Networks 的研究人员 Arie Olshtein 上周在一篇文章中描述了 Pass-ta-key 如何在感染了恶意软件的 Windows 机器上，获取存储在 Google 密码管理器（GPM）中的所有通行密钥。这让许多人感到惊讶，因为他们一直认为通行密钥仅存储在可信平台模块（TPM）中——即 Windows 机器上用于存储加密密钥和其他高度敏感信息的加固芯片中的封闭区域。人们不禁要问：如果通行密钥存储在 TPM 中，Pass-ta-key 又是如何提取出该应用程序存储的所有密钥的呢？

Local passkey storage is OK, with one exception

本地存储通行密钥没问题，但有一个例外

The answer is that, contrary to common belief, the FIDO 2 specifications—managed by the industry group FIDO Alliance—don’t mandate that passkeys be kept in TPMs, or any other sort of dedicated piece of hardware (they go by different names, depending on the platform, including secure enclaves, trusted execution environments, and StrongBoxes). In fact, most platforms and third-party software for managing passkeys do not store passkeys in such dedicated hardware. Virtually the lone holdout is Microsoft, which gives users the option to store passkeys in the Windows TPM. The company mainly recommends this choice to enterprises, not consumers.

答案是，与普遍认知相反，由行业组织 FIDO 联盟管理的 FIDO 2 规范并不强制要求将通行密钥保存在 TPM 或任何其他类型的专用硬件中（根据平台不同，它们有不同的名称，包括安全隔离区、可信执行环境和 StrongBoxes）。事实上，大多数平台和用于管理通行密钥的第三方软件都不会将密钥存储在这些专用硬件中。几乎唯一的例外是微软，它为用户提供了将通行密钥存储在 Windows TPM 中的选项。该公司主要向企业而非消费者推荐此选项。

Unbeknownst to me until I began research for this article, all platforms other than those running Windows store passkeys locally on the device. The shift to local storage came a few years ago after OS and third-party application developers realized that passkeys had no chance of gaining widespread usage unless they could easily be synced to all of a user’s devices. Requiring TPM storage made syncing impossible. The only way to load them into the TPM of a new device would be to re-create each one individually.

在开始撰写本文进行研究之前，我并不知道除了运行 Windows 的平台外，所有其他平台都将通行密钥存储在设备本地。几年前，当操作系统和第三方应用程序开发人员意识到，如果通行密钥不能轻松同步到用户的所有设备，就不可能得到广泛应用时，他们转向了本地存储。要求使用 TPM 存储使得同步变得不可能。要将它们加载到新设备的 TPM 中，唯一的办法就是逐个重新创建。

Ultimately, architects of the FIDO specifications decided that it was generally safe to store passkeys on the devices. The thinking was that app permissions are so granular that malware lurking on the device would have no ability to access the private keys that form the lynchpin of passkey security. Malware installed on a device running macOS, iOS, and Android, for instance, has no ability to defeat this isolation unless the OS itself is compromised through some sort of exotic zero-day exploit. So far, these assumptions have been proven correct in real-world practice.

最终，FIDO 规范的设计者们认为，将通行密钥存储在设备上通常是安全的。他们的想法是，应用程序权限非常细化，潜伏在设备上的恶意软件无法访问作为通行密钥安全核心的私钥。例如，安装在运行 macOS、iOS 和 Android 设备上的恶意软件，除非操作系统本身通过某种罕见的零日漏洞被攻破，否则无法打破这种隔离。到目前为止，这些假设在现实实践中已被证明是正确的。

The lone exception is Windows. Unlike all the other platforms, Windows apps generally run with all the privileges of the user, whereas other platforms encourage the restriction of the privileges of each application by default. While Windows provides some sandboxing protections designed to isolate apps, it doesn’t prevent unsandboxed apps, such as malware, from accessing the data of a sandboxed app. That is, the sandbox only protects in one direction. Sandboxing technologies on other platforms are much more protective. That means Windows malware has decidedly fewer problems accessing data used by a separate app.

唯一的例外是 Windows。与其他所有平台不同，Windows 应用程序通常以用户的所有权限运行，而其他平台则默认鼓励限制每个应用程序的权限。虽然 Windows 提供了一些旨在隔离应用程序的沙箱保护，但它无法阻止未沙箱化的应用程序（如恶意软件）访问沙箱化应用程序的数据。也就是说，沙箱保护是单向的。其他平台上的沙箱技术保护性要强得多。这意味着 Windows 恶意软件在访问其他应用程序使用的数据时，遇到的阻碍要少得多。

Passkey architects have been keenly aware of this difference, which is largely necessary for Windows backward-compatibility reasons. With no confidence that passkeys stored on a Windows device won’t be harvested in the event of a malware infection, many third-party developers opted for a new design—storing the passkeys in end-to-end encrypted blobs located in the cloud. Server-stored passkeys are now the design used not just by GPM for Windows, but 1Password, Dashlane, and other third-party apps for the Microsoft OS as well.

通行密钥的设计者们非常清楚这种差异，这在很大程度上是出于 Windows 向后兼容性的需要。由于无法确信存储在 Windows 设备上的通行密钥在感染恶意软件时不会被窃取，许多第三方开发人员选择了新的设计——将通行密钥存储在云端的端到端加密数据块中。目前，不仅 Windows 版 GPM 使用这种服务器存储通行密钥的设计，1Password、Dashlane 以及其他针对微软操作系统的第三方应用程序也采用了这种方式。

At a simplified level, here’s how it works: When a Windows GPM user wants to use a passkey to log in to a site, the device retrieves a user and/or device key from the TPM and presents it to Google’s backend authenticator. Presentation of the key, combined with the device already being signed in to the user’s Google account, triggers the Google server to present an authentication assertion to the site the user wants to log in to. The assertion is signed with the private key, which is stored in encrypted form on the Google server. With that, the user is logged in. Again, most other third-party apps for Windows work the same way. Those same apps for other platforms, by contrast, store passkeys locally on the device. When a user wants to log in using a passkey, the local device—not the one in the cloud—presents an authentication assertion. It’s signed by the private key, which is also stored in encrypted form on the local device.

简单来说，其工作原理如下：当 Windows GPM 用户想要使用通行密钥登录网站时，设备会从 TPM 中检索用户和/或设备密钥，并将其呈现给 Google 的后端身份验证器。密钥的呈现，加上设备已登录用户的 Google 账户，会触发 Google 服务器向用户想要登录的网站发送身份验证断言。该断言由存储在 Google 服务器上的加密私钥进行签名。至此，用户即可登录。同样，大多数其他 Windows 第三方应用程序的工作方式也相同。相比之下，这些应用程序在其他平台上则将通行密钥存储在设备本地。当用户想要使用通行密钥登录时，是本地设备（而非云端）呈现身份验证断言。该断言由同样以加密形式存储在本地设备上的私钥进行签名。

When your device is infected, all bets are off

当你的设备被感染时，一切皆有可能

The malware in the Pass-ta-key attacks uses its access to the Google account—and in some cases, the user or device key stored in the TPM—to obtain the secret passkeys. The most powerful of the three attack variants causes the infected Windows machine to masquerade as an iPhone. This triggers a synchronization capability in GPM that allows users to transfer all stored passkeys to a new device. The keys are now transferred to the infected Windows device. Olshtein described Pass-ta-key as a “novel” attack that targets the attack surface in the passkey ecosystem. The reality is more nuanced. The stakes of this attack would be much the same if an infected Windows machine…

Pass-ta-key 攻击中的恶意软件利用其对 Google 账户的访问权限（在某些情况下还包括存储在 TPM 中的用户或设备密钥）来获取秘密通行密钥。三种攻击变体中最强大的一种，会使受感染的 Windows 机器伪装成 iPhone。这会触发 GPM 中的同步功能，允许用户将所有存储的通行密钥传输到新设备。此时，密钥便被传输到了受感染的 Windows 设备上。Olshtein 将 Pass-ta-key 描述为一种针对通行密钥生态系统中攻击面的“新型”攻击。但现实情况更为微妙。如果一台 Windows 机器被感染，这种攻击的风险与……（原文中断）