‘패스타키’ 공격이 말해주는 패스키의 오해와 진실

Text settings Story text Size Small Standard Large Width * Standard Wide Links Standard Orange * Subscribers only Learn more Minimize to nav 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 over 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. 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. 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. 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. 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. 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. 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. 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. 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 was fully authenticated into other sensitive apps. The attacker on the other side of the keyboard would likely be able to activate the mechanisms in the credential management app to log in to a site or download all the passwords. This risk has always been present and is the reason some people regard password managers as unsafe to use. Based on Olshtein’s write-up, it’s possible that GPM lacks some protections found in password managers like 1Password, such as calling OS APIs to restrict other processes from reading its memory. Generally speaking, though, it is universally accepted that it’s game over whenever an infected device is logged in to a sensitive account. In other words, Pass-ta-key is a fact of life that has existed for as long as computing security has. There’s nothing novel here, and the attack surface extends to any data that requires authentication for access. The purpose of passkeys is to eliminate a shared secret that can be phished or obtained through server breaches. Passkeys aren’t intended to withstand physical attacks against the devices that store them. It’s not surprising that Pass-ta-key can extract keys when a Windows device is compromised. The research may not be novel, but it will be helpful nonetheless if it helps users understand that once a device—particularly one running Windows—is compromised while it’s logged in to an account, all data stored there is free for the taking. Dan Goodin Senior Security Editor Dan Goodin Senior Security Editor Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene. Dan is based in San Francisco. Follow him at here on Mastodon and here on Bluesky. Contact him on Signal at DanArs.82. 44 Comments