Beyond the Trust Boundary: A Critical Reassessment of the FIDO2 Threat Model

arXiv:2609.03789v1 [cs.CR] 3 Sep 2026

B EYOND THE T RUST B OUNDARY: A C RITICAL R EASSESSMENT OF THE FIDO2 T HREAT M ODEL

Aditya Mitra CyberMACS Kadir Has University DigitalFortress Private Limited & Indominus Labs Private Limited adityaarghya0@gmail.com

Kolluru Sai Abhiram Centre of Excellence, Cyber Security School of Computer Science and Engineering VIT-AP University, India DigitalFortress Private Limited

Sibi Chakkaravarthy Sethuraman Centre of Excellence, Artificial Intelligence & Robotics (AIR), School of Computer Science and Engineering VIT-AP University, India DigitalFortress Private Limited & Indominus Labs Private Limited sb.sibi@gmail.com Anitha S Centre of Excellence, Artificial Intelligence and Robotics (AIR) School of Electronics and Communication Engineering VIT-AP University, India DigitalFortress Private Limited

September 4, 2026

A BSTRACT FIDO2/WebAuthn has been deployed extensively as a phishing resistant authentication scheme. Since FIDO2 uses public-key cryptography and requires the presence of a hardware backed authenticator, its security has long been considered guaranteed by its design (assuming its cryptographic implementation is correct), both from the perspective of practitioners and prior academic work. In this work, we dissect the FIDO2 threat model to show that some of the commonly assumed security properties do not hold in all circumstances, and we also extend the threat model to cover more than just the cryptographic layer, as was previously done in works such as [1]–[3]. We look at eight potential attack vectors associated with various layers of the FIDO2 stack — malicious web extensions, platform handler malware, passive sniffing, virtual device drivers, CTAP2 specific malware, USB/hardware implants, malicious USB hubs/docks/extenders, and NFC relay attacks — and show how FIDO2 relies on certain assumptions about the environment which are frequently not true in practice. We show how AAGUID and timing information can be used to profile users and carry out targeted attacks [4], [5] and show that compromising the environment at any layer — the browser, the OS, or the hardware — can affect the security of FIDO2. Furthermore, we show how some of these attacks can be chained together to undermine the security of FIDO2 even when the underlying cryptographic primitives are implemented correctly. These findings support the thesis that the weak link in a FIDO2 deployment is rarely the crypto layer. We also show how several of these attack vectors can undermine the device attestation model that underlies FIDO2, by subverting the FIDO Metadata Service (MDS3) that serves as its root of trust [6], and we characterize each of these attacks by their privilege, skill, and resource requirements. We conclude that the mitigations for these attacks need to be

Beyond the Trust Boundary: A Critical Reassessment of the FIDO2 Threat Model A P REPRINT

layered and address problems at all levels of the FIDO2 stack, protect the metadata, and ensure that the environment is protected. Keywords FIDO2, WebAuthn, CTAP, authentication security, threat model, metadata leakage, environmental security

I. Introduction FIDO2/WebAuthn (hereby WebAuthn) is a standard intended to replace passwords with a better, phishing resistant authentication scheme based on public key cryptography. The WebAuthn standard was defined and standardized by the W3C and the FIDO Alliance [7], [8]. FIDO2 is made up of two separate but complementary specifications: the Web Authentication (WebAuthn) standard, which defines a JavaScript API for creating and utilizing strong attested public key credentials, and the Client to Authenticator Protocol (CTAP) specification, which specifies the protocol that is used to facilitate communication between a browser or client and external authenticators [9]. It is important to note that CTAP is a distinct, standalone FIDO Alliance specification and not a component of the W3C WebAuthn standard itself; the two specifications are designed to interoperate but are maintained and versioned independently. The FIDO2 protocol has gained popularity over the last few years among various platforms and services. Apple was the first major platform vendor to ship support for FIDO2, followed by Microsoft and Google adding support for FIDO2 to Windows and Android, respectively. Many web services also now support FIDO2. FIDO2 offers a possible defense against phishing, man-in-the-middle, and credential stuffing attacks that affect passwords. Through its reliance on public-key cryptography and physical user interaction, FIDO2 could theoretically eliminate the risk of attackers being able to capture and replay secrets exchanged over insecure channels. Naturally, as with any technology, security relies heavily on the assumptions made about the environment and threat model, and is only as strong as its weakest component. When those assumptions fail, or can be circumvented through adversarial actions, the security guarantees of FIDO2 are violated [3], [10]. In this paper, we analyze the threat model upon which FIDO2 was designed, decompose it into its underlying assumptions, and identify different scenarios in which this threat model can break down. Furthermore, we show how the attacks we identify can be combined to form complex exploit chains. Our contributions are summarized as follows, A systematic breakdown of the FIDO2 threat model into its assumptions and trust boundaries, a study of eight types of attacks that target different components of the FIDO2 stack, discussion of how the attacks could be chained together to produce stronger attacks and an assessment of the security impact of our findings on metadata privacy, environmental security, and the eroding of trust with Practical mitigation strategies and a methodology for studying the security of authentication systems by going beyond cryptographic properties and examining the security of the overall execution environment. The rest of the paper is organized as follows. In SectionII we give a brief overview of FIDO2/WebAuthn architecture and its relevant components. We present our refined threat model and discuss the implications of that threat model in SectionIII. In SectionV, we detail eight attack vectors targeting different components of the system. We discuss several kill chains that can be formed by combining these vectors in SectionVI. In SectionVIII we discuss how our work goes beyond the attack vectors, including how the leakiness of metadata can impact the security of the ecosystem, and how our work undermines core trust models underpinning the FIDO2 protocol. SectionVII outlines our experimental results and how we analyzed them. We analyze each of our attacks in terms of required attacker capabilities and resources in SectionIX. Finally, we conclude in SectionX with a summary of our work and possible future directions. Note on scope: To avoid the risk of our work being directly deployed as attack tooling, the attack sections contain only a description of the mechanism, demonstrated impact, and illustrative pseudocode at an architectural level. No code to fully implement the attack is presented. Where appropriate, links to existing publicly available tools that can be used alongside our work are provided. Any details that were reported to vendors that would be useful in isolation of our work have either been obfuscated (to maintain user privacy) or omitted entirely (as they are only useful in the context of the specific vulnerability).

II. Background To grasp the attacks described in this paper, we first need to understand the FIDO2 / WebAuthn architecture and trust model. This section provides a brief overview of these topics.

2

Beyond the Trust Boundary: A Critical Reassessment of the FIDO2 Threat Model A P REPRINT

A. Architecture FIDO2 comprises of two primary standardized specifications that work together to provide authentication services: Web Authentication (WebAuthn): A W3C standard that defines an API for web applications to create and use strong, attested, scoped, public-key based credentials for the purpose of strongly authenticating users [7]. Client to Authenticator Protocol (CTAP): A FIDO Alliance standard defining a communication protocol between a client (typically a browser or OS) and an authenticator (a device that holds keys and performs authentication operations) [9]. CTAP1/U2F is the original Universal Second Factor specification, designed for second factor authentication. CTAP2 is a newer iteration of CTAP designed to enable multi-factor authentication and additional features like resident keys and user verification. Authenticators: Authenticators are devices that store credentials and perform cryptography. They can be Platform Authenticator (built into a device like Windows Hello or Touch ID on Mac/iOS), or Cross-Platform Authenticators (standalone devices that can move between systems, like USB security keys, NFC tokens, Smart Cards and Bluetooth authenticators). B. Trust Model and Assumptions The FIDO2 specification makes several implicit security assumptions [10]. The cryptographic scheme used to verify signatures (typically ECDSA over elliptic curves) is unbreakable under current computational capabilities (cryptographic assumption) [1], [2], [8]. The hardware security features of the authenticator successfully prevent attackers from extracting the authenticator’s private key (hardware security). The authenticator accurately detects when a user interacts with it by placing their finger or pressing a button (user presence). The client’s operating system is uncompromised by malware or other security breaches (trusted client). The cryptographic scheme for verifying signatures (usually ECDSA on elliptic curves) is not computationally feasible to break (cryptographic assumption) [1], [2]. Authenticator hardware security ensures that the attacker cannot extract the authenticator’s private key (hardware security). Several implicit security assumptions are made in the FIDO2 specification. The cryptographic scheme for verifying signatures (usually ECDSA on elliptic curves) is not computationally feasible to break (cryptographic assumption) [1], [2]. Authenticator hardware security ensures that the attacker cannot extract the authenticator’s private key (hardware security). The authenticator reliably detects when the user places a finger or presses a button (user presence). (SA-4, trusted client) The client OS is not compromised by a malicious program or any other security vulnerability. The link between client and authenticator is secure against eavesdropping and tampering (secure channel). (SA-6, browser integrity & server security) The web browser securely exposes the WebAuthn API to websites and acts as intermediary between the website and the underlying platform [11], and the server of the Relying Party correctly interprets responses to authentication requests, validates the value of signatures, and stores public keys in a manner where they cannot be modified without authorization. All client components (the browser IPC layer, drivers, and the platform handler) depend on one another for trust without any further verification. This implicit trust is an attack surface, as we demonstrate in subsequent sections [3]. C. Working Procedure There are two ceremonies defined by FIDO2, i.e. the registration ceremony where users create credentials and the authentication ceremony where users make assertions. For creating a credential, the user registers an account with the relying party, i.e. a website or a service. The user tries to sign up for the service and the server first issues a challenge that specifies what type of credentials the server expects from the browser (e.g. what type of authenticator, whether the user needs to provide a PIN code, etc.). Then the client contacts the authenticator that supports this challenge, and the user must authorize access by presenting proof of their presence (e.g. clicking a button on the authenticator device or using some biometric). The authenticator then generates a new public-private key-pair for this particular origin (domain or service name) and saves the private key in a secure storage (a secure element), creates the public key and an attestation for the authenticator and sends them to the relying party’s server. The server associates the public key with the user’s account and saves it for later use in authentication. According to previous studies, FIDO2 can still have a good usability when it is implemented correctly [12], [13]. For authentication, the user tries to log in to a service. The relying party’s server generates a new challenge and sends it to the browser. The browser then requests an assertion for a credential tied to the origin of the relying party from the authenticator. Again, the user needs to give consent and proof of presence. The authenticator signs the challenge with other context information (e.g. origin and counter) and returns the signature to the browser. The

3

Beyond the Trust Boundary: A Critical Reassessment of the FIDO2 Threat Model A P REPRINT

Platform Authenticator

Wired USB Authenticator

USB Port Hardware bus

USB HID Driver Kernel level communication

Wireless (close proximity)

NFC Radio Hardware bus

NFC Driver

Proprietary

Platform Handler Kernel level communication

NFC Authenticator

Kernel level communication Wireless

BLE Authenticator

Hardware bus

Web Sockets

BLE Driver

Browser WebAuthn (TLS)

IPC

Bluetooth Radio

Web extension

Relying Party (RP)

Passkey Manager

Platform

Passkey Manager Server

Proprietary Credential Manager Hosting Device (CMHD)

Smartphone

Figure 1: Threat Model Diagram illustrating FIDO2/WebAuthn architecture and trust boundaries

browser sends the signature to the relying party’s server, which verifies it with the public key saved during the registration phase. If the signature is valid and other conditions are met (e.g. the origin is correct and the counter is incremented), the authentication is completed successfully.

III. Contributions In our opinion, this paper is a valuable critique of FIDO2/WebAuthn security, as it highlights and catalogs a number of significant problems related to the implicit trust assumptions that are part of the FIDO2 standard’s threat model [8], [10]. Even though we offer no new cryptographic or implementation solutions, our primary contribution here is that we refine the conceptual framework by which the security of FIDO2 deployments is evaluated. A. Limitations of the Original Threat Model The standard FIDO2 threat model used by the standards documents and security literature, contains some routinely violated by attacker capabilities [10]. It analyses the threat model for each attack vector independently, while ignoring the fact that multiple attack vectors may be chained together for a stronger attack. It assumes the client (browser/OS/hardware) to be trusted, or at least, not fully compromised. It assumes attackers have limited capabilities, and doesn’t analyze the threat model for all types of attackers, including malware authors and nation states. It assumes the trade boundary is fixed, while in reality it is dynamic. And finally, it focuses too much on the cryptographic primitives, and does not place sufficient emphasis on implementation and environmental security [14].

4

Beyond the Trust Boundary: A Critical Reassessment of the FIDO2 Threat Model A P REPRINT

B. Our Refined Threat Model Our enhanced threat model addresses these shortcomings by representing attacks as chains, rather than individual attacks, and thereby reflecting the possibility that multiple individually-insignificant breaches could occur in sequence, each of which is individually not enough to bypass FIDO2’s protections but, together, allow the adversary to succeed. It also incorporates the concept of “environmental trust,” which acknowledges that an authenticator is not an isolated entity, but is part of a complex ecosystem of components, including device drivers, OS APIs, interprocess communication mechanisms, and external ports that mediate its connection to the client—and, by extension, to the RP. We then extend the threat model to note that the security provided by FIDO2 is dependent not only on the security of its cryptographic protocol, but on the security of its execution environment. Even if FIDO2 uses a perfectly secure signature scheme, if the environment in which it operates is insecure, its security guarantees will not hold. The threat model also covers a spectrum of attacker sophistication, from low-skill to state-level, enabling reasoning about a range of attacks that include opportunistic attacks (e.g., phishing, social engineering), as well as advanced attacks against attackers with unlimited resources. It represents trust boundaries as continuously observable rather than static (that is, they were previously assumed to be trusted and never re-evaluated), where a trust boundary assumed to be secure might be compromised later (e.g., due to compromised firmware, supply-chain compromise, or privilege escalation). Our threat model also evaluates the security of FIDO2 at the whole-system level (as opposed to only the cryptographic level) by considering the security of all elements of the FIDO2 architecture: hardware, firmware, software, and users. Thus, the impact of security vulnerabilities in any one component of the FIDO2 stack, or combinations thereof, can be evaluated. C. Practical Implications of the Refined Model FIDO2-capable organizations (and those considering FIDO2) must now recognize that the scope of defense-in-depth extends beyond the authenticator, because the client, browser, and OS may also be compromised and undermine authentication guarantees, even when the authenticator itself is uncompromised. Trust property violation monitoring (e.g., detecting unauthorized USB devices or unusual authentication patterns) should not be a one-time assessment, but an ongoing control, because trust boundaries can degrade over time, e.g., due to firmware updates, device transfers, or privilege escalation on the host. FIDO2 cannot be relied upon as a sole protection against credential theft; network monitoring, endpoint detection, and user education should be applied in tandem with it, since FIDO2 is not intended to guard against a compromised execution environment. Adaptive authentication (e.g., based on device health, location, or behavior) may offer an additional mitigation if the environment is compromised, because relying parties could be allowed to mark technically-valid assertions as suspicious if they come from an unhealthy or unexpected context (e.g., from a compromised device or one at an unexpected physical location). Authenticator vendors should be clearer about what security assumptions they make about the environment in which the authenticator will operate [14], so that organizations do not discover a gap in compensating controls only after a breach occurs. Ultimately, clarifying the threat model enables security architects, developers, and administrators to stop thinking of FIDO2 as an unconditional guarantee of phishing-resistance, and instead begin thinking about the actual security properties (which depend on the environment) that it delivers.

IV. Related Work FIDO2/WebAuthn security has previously been studied through the lens of formal protocol verification, local and implementation attacks, metadata and side-channel leakage, and usability/enterprise-deployment issues. We build on these lines of work, extending them by moving from studying FIDO2 components to studying the entire system. A. Formal and Cryptographic Analysis Much previous work has verified the cryptographic core of FIDO2 and CTAP formally [1]. The authors define an idealized protocol, then show that an attacker who does not possess the authenticator private key cannot forge a signature. Subsequent work has extended this model to CTAP2.1, specifically verifying the security of the new PIN and user-verification sub-protocols [2]. While useful for establishing the correctness of the protocol itself, these analyses typically assume a trusted client, browser, and transport, assumptions that we explicitly relax in this work. B. Local and Implementation-Level Attacks Another group of papers have investigated how an attacker with local access to the victim’s machine could subvert the FIDO2 protocol without breaking any underlying cryptography [3]. This work found that the implicit trust placed in

5

Beyond the Trust Boundary: A Critical Reassessment of the FIDO2 Threat Model A P REPRINT

client-side components, such as the browser and OS, introduces a significant attack surface, a finding that motivates our systematic analysis of environmental trust. In addition, news reports have demonstrated that passkey-manager browser extensions can intercept and modify WebAuthn API calls, taking advantage of an ongoing incompatibility between extension permissions and the navigator.credentials interface [11], [15], [16]. Our web-extension attack (Section V-A) takes these findings and builds upon them within a wider threat model, treating them as part of a larger kill chain. C. Hardware and Physical Attacks Other works have demonstrated that even certified, hardware-backed authenticators can still be subverted via physical attacks. Specifically, few researchers from the National Institute of Informatics were able to recover the ECDSA private key of one popularly-used FIDO2-compliant security key with a side-channel vulnerability in its proprietary crypto implementation [17], [18], despite the fact that it is a FIPS-certified device. While this demonstrates the fallacy of assuming hardware security for FIDO2-compliant devices, the vulnerability lies within the security key’s vendor implementation and not the FIDO2 hardware-security paradigm. This directly informs our analysis of USB/hardware implants and CTAP-level malware (Sections V-F and V-E). Complementary research on cheap commodity USB implants [19]–[21] and NFC relay attacks against proximity-based authentication [22], [23] also demonstrate the feasibility of similar attacks against the FIDO2 ecosystem. D. Metadata and Side-Channel Leakage More recent research has highlighted the privacy implications of metadata leaked during FIDO2 ceremonies, particularly the AAGUID field. The AAGUID field, intended to allow relying parties to identify the make and model of the authenticator, has been shown to leak information that could be used to fingerprint and correlate users across sessions [4]. Vendor documentation regarding attestation similarly notes that AAGUID and certificate data could reveal the authenticator’s provenance [5]. Our passive interception results (Section V-C) confirm these findings and provide concrete quantification. Additionally, we extend the findings of these works by connecting leaked metadata to specific attacker actions within a kill chain. E. Trust Infrastructure and Metadata Services The FIDO Metadata Service (MDS3) has been described by the FIDO Alliance as the central source of truth that allows relying parties to resolve AAGUIDs to vendor and certification information [6]. To our knowledge, However, none of these works have studied the potential subversion of MDS3 as a root of trust when an attacker can relay an honest authenticator’s traffic via an attacker-controlled middlebox; we study this MDS3 violation in Section IX. F. Usability and Enterprise Deployment Finally, another group of researchers has looked at FIDO2 from a usability and enterprise-deployment perspective, finding that the technology can offer high usability if properly implemented [12], [13] and that it can present practical challenges to organizations attempting to deploy it at scale, such as unclear security assumptions from vendors and poor visibility into operational security [14]. Our practical implications (Section III-C) builds on these findings, translating our attack-chain results into actionable recommendations for organizations deploying FIDO2. In summary, previous work has studied various aspects of FIDO2 security in isolation, including its cryptographic core, individual implementation flaws, physical attacks, and metadata leakage. We provide the first unified treatment of all of these attack vectors, treating attack chains, environmental trust, and attacker capability as first-class citizens in the threat model.

V. Attack Vector Analysis This section describes each of the eight attack vectors. Each one exploits a different implicit trust relationship. For each vector, we describe the attack, discuss our feasibility analysis, and present the attack in the form of pseudocode at the architecture level (as opposed to ready-to-deploy source code from Section I). A. Malicious Web Extensions Web browser extensions are another potential vector for application layer attacks on FIDO2/WebAuthn. Passkeymanager extensions can already “monkey-patch” the navigator.credentials API to intercept and modify

6

Beyond the Trust Boundary: A Critical Reassessment of the FIDO2 Threat Model A P REPRINT

Attacks Involving Hardware / Supply Chain

Passkey / WebAuthn Client Architecture and Attack Surface

⚠️

⚠ Malicious USB Hub / Dock / Extender

USB Authenticator

Hardware bus

Wired

Platform Authenticator

Malicious Virtual Device Drivers

USB HID Driver

Attacks with User Privilege

Kernel-level

USB Port

Proprietary

communication

⚠ NFC Relay NFC Driver Hardware bus

NFC Authenticator

Wireless (close proximity)

Kernel-level communication

NFC Radio

Platform Handler

IPC

communication

Wireless

WebAuthn (TLS)

🌐

Browser

Relying Party (RP)

⚠ Malware performing passive interception

Hardware bus

BLE Authenticator

⚠ Malicious Web Extensions

⚠ Malware performing IPC

Kernel-level

BLE Driver

Legend Normal data / control flow Attack / malicious communication path Hardware / supply-chain attack zone Elevated (kernel) privilege attack zone User-privilege attack zone

Web Sockets

Bluetooth Radio

Web extension ⚠ Malware performing CTAP Attacks with Elevated Privilege

Passkey Manager

Platform (Client Device) Boundary

Smartphone

Proprietary

Credential Manager Hosting Device (CMHD)

Passkey Manager Server

Figure 2: Overview of the eight attack vectors targeting different layers of the FIDO2 authentication stack

the WebAuthn flow [11]. This is a known incompatibility between passkey managers and WebAuthn, tracked in a W3C WebExtensions WG issue [15] that has been open for > 2 years as of this writing. A password-manager extension with the relevant permissions could abuse this mechanism too, which would be the case for malicious extensions [3]. Attack Vector Extensions that can inject content scripts can monitor and proxy calls to navigator.credentials.create() and navigator.credentials.get() [16]. Once having seen the arguments, they can forward them to an external service or server prior to passing them to the actual API in order to make it appear as if everything is running normally to the user. Importantly, the extension does not need to actually forward the call to the actual API; it can forward the call to an API controlled by an attacker and simply imitate the expected response without actually using a real authenticator, returning a fake credential or assertion to the page that called the API. Algorithm 1 WebAuthn-intercepting extension (architecture-level; not deployable source) 1: procedure O N E XTENSION L OAD 2: origCreate ← navigator.credentials.create 3: origGet ← navigator.credentials.get 4: navigator.credentials.create ← W RAP C REATE 5: navigator.credentials.get ← W RAP G ET 6: end procedure 7: function W RAP C REATE(options) 8: forward(options) ▷ destination withheld 9: return attackerResponse(options) ▷ returns attacker-controlled response, bypassing real API 10: end function 11: function W RAP G ET(options) 12: (symmetrical to W RAP C REATE) 13: end function

The attack demonstrates that code executing in the browser context can evade the security properties provided by FIDO2 by modifying request parameters prior to submission to the authenticator (such as altering the relying party ID, challenge, or user verification constraints before signing).

7

Beyond the Trust Boundary: A Critical Reassessment of the FIDO2 Threat Model A P REPRINT

However, post-assertion interception cannot alter the credential without being detected, because any changes to the signed assertion will break the signature, resulting in rejection by the relying party. In this case, the attack would only be effective if the adversary simply stole the credential ID and signature (e.g., for later replay or offline analysis) [11], [24], [25]. B. Malware Communicating with the Platform Handler This makes such a malware extremely dangerous against FIDO2, especially when it comes to platform authenticators such as Windows Hello or Touch ID since they are built directly into the operating system. Both Microsoft and Apple expose platform APIs to which any application on the machine can connect to, even if it does not run in the browser, and does not require privilege escalation beyond the privileges of a regular user [3]. Attack Mechanism Similarly, any malware that is able to run locally on the machine can make API calls to the same platform authentication APIs as the client. Therefore, malware on the system can invoke the platform authentication subsystem to participate in an undesired authentication ceremony to any relying party of the attacker’s choice, without requiring elevated privileges. Note that this does not bypass the user presence (UP) check itself—the user will still be required to tap or otherwise authenticate, per the authenticator’s UP guarantee—but there is no reliable mechanism for the user to determine why the prompt appeared, or which relying party invoked it, because the platform handler doesn’t differentiate between requests coming from the normal client application and those initiated by malware. Thus, a user familiar with such authentication prompts may easily consent to a ceremony they did not intend. Algorithm 2 Platform-handler-targeting ceremony initiation (architecture-level; not deployable source) 1: loop 2: rp ← S ELECT TARGET R ELYING PARTY 3: req ← B UILDAUTHENTICATION R EQUEST(rp) 4: invoke(platformAuthAPI, req) 5: if U SER A PPROVES then 6: capture(resulting assertion) 7: end if 8: sleep(interval) 9: end loop

▷ destination withheld ▷ transport withheld

We have shown that this attack is possible even if the attacker has only operating system level access; it does not require communication with authenticators. C. Passive Interception As opposed to active attacks which usually rely on user interaction or high-privilege system access, passive interception occurs without user involvement, and simply observes the communications occurring between two system components. While it does not allow for direct account takeovers, it still represents a serious privacy violation, and enables adversaries to profile users and gather enough information to carry out more advanced targeted attacks [4]. Attack Mechanism The main objective of passive interception is to capture traffic from the browser-toplatform-handler channel, the platform handler-to-authenticator channel (e.g., over USB-HID, BLE, or NFC), and other communication channels between system hardware components. In most standard configurations, these communication channels are neither encrypted nor authenticated. Given suitable access, an adversary can simply read and process the exchanged messages. This provides attackers with the ability to profile users (i.e., learn which websites a given user visits and when they authenticate using their FIDO device), extract the AAGUID to determine the make and model of the security key being used (i.e. authenticator fingerprinting) [4], [5], and collect Credential IDs for correlation purposes. Technical Demonstration We demonstrate this attack using popular software like USBPcap and Wireshark, allowing us to capture all traffic sent over the USB-HID bus between a host computer and a security key during a normal credential-creation flow. Table I shows the layout of the 64-byte CTAPHID packets captured during this process, and their respective fields of interest once the CBOR-encoded authenticator data has been decoded. The AAGUID obtained from the capture can then be used to lookup information about the authenticator in MDS3 [6], including the identity of the vendor and the specific model of the authenticator that the victim is using. This

8

Beyond the Trust Boundary: A Critical Reassessment of the FIDO2 Threat Model A P REPRINT Table I: Fields extracted from a decoded CTAPHID/CBOR authenticator data capture Field RP ID Hash (32 bytes) Flags (1 byte) Signature Counter (4 bytes) AAGUID (16 bytes) Credential ID & Public Key

Description SHA-256 hash of the relying party identifier; can be matched against a dictionary of known relying party domains Bitfield: user presence, user verification, credential-backup-eligible, credential-backed-up, attested-credential-data-present, extension-datapresent Monotonic counter incremented on each authentication Authenticator Attestation GUID; resolvable via the FIDO Metadata Service (MDS3) to a specific vendor and model Variable-length identifier and COSE-encoded public key for the created credential

information could be exploited in a targeted attack: if an attacker knows that the victim is using a specific model of authenticator, which may have been found to be particularly susceptible to a known side-channel attack, for example, then the attacker can take further action to exploit this specific authenticator model [17], [18], [26]. D. Virtual Device Drivers Virtual device drivers are created by attackers to pretend to be hardware devices – either the authenticator itself, or the underlying communications channels (e.g. USB, NFC, BLE) between it and the host system. These attacks generally need some level of privilege to load a kernel driver onto the system but allow the attacker to gain remote control of an authenticator or intercept all traffic between the host and the authenticator in real time (a man-in-the-middle attack). Types of Virtual Drivers Virtual device drivers in the FIDO2 context fall into two categories. Virtual authenticators: A driver presenting itself to the platform handler as a legitimate authenticator but controlled by the attacker. The attacker will receive and respond to authentication challenges, exfiltrate generated credentials, spoof user presence, and supply fake attestation data. Virtual transport drivers: A driver presenting itself as the communication channel between the authenticator and the platform handler, but controlled by the attacker. The attacker will be able to passively intercept, actively modify or inject CTAP commands, perform relay attacks, and downgrade the authentication protocol. Attack Demonstration To demonstrate that virtual transport drivers can be used to attack FIDO2, we used an open-source implementation of the virtual smart-card stack supporting ISO 7816-4 smart card protocols [27], in combination with an NFC relay application running on a consumer Android phone. With this setup, the victim taps their physical security key on the Android phone. The phone relays the NFC exchange over the internet to the virtual smart-card driver running on the attacker’s host machine, which pretends to be the authenticator to the victim’s platform handler. Both scenarios are effectively symmetric – either the attacker has the victim’s physical security key and uses it through a relay (the key will appear to be locally attached) or the victim has already been tricked into using an authenticator supplied by the attacker and all the credentials generated on this authenticator can be captured [28]. Algorithm 3 NFC relay via virtual smart-card driver (architecture-level; not deployable source) 1: procedure R ELAYA PP 2: on TAG D ETECTED(authenticator): 3: tunnel raw ISO 7816 APDU exchange to attacker host 4: end procedure 5: procedure ATTACKER H OST 6: present self to platform handler as authenticator 7: forward/modify CTAP ↔ APDU traffic with R ELAYA PP 8: end procedure

▷ on NFC-proximate device

▷ virtual smart-card driver

E. Malware Performing CTAP This is one of the most powerful malware attacks against FIDO2, because instead of being blocked by a platform handler or driver,the malware is able to communicate directly with the authenticator using CTAP [9]. This gives

9

Beyond the Trust Boundary: A Critical Reassessment of the FIDO2 Threat Model A P REPRINT

the malware complete control over how the authenticator works, e.g., modifying the authenticator PIN, resetting the authenticator, or sending any valid CTAP command to the authenticator. The privilege level required to reach the authenticator at this level is platform-specific: on Windows, raw USB-HID access usually requires admin-level privilege, while on Linux, authenticators are often available to unprivileged users out of the box via udev rules, so this attack might not require any elevated privilege on those platforms. Attack Vectors: While malware interacting with the platform handler can only access the set of APIs provided by the OS, malware at the CTAP level can send any valid CTAP command, inspect and interpret any response, and intercept and modify any data flowing between the two. Thus, they may steal credentials (by obtaining the credential ID and public key upon creation of a new credential), attempt to authenticate without authorization, cause denial of service by submitting too many bad PINs, and potentially engage in side channel information gathering [17]. Algorithm 4 Direct-CTAP assertion capture (architecture-level; not deployable source) 1: device ← L OCATE C ONNECTEDAUTHENTICATOR 2: E STABLISH C HANNEL(device) 3: assertion ← R EQUESTA SSERTION(device, target rp, challenge) 4: WAIT F ORU SERT OUCH 5: C APTURE A ND S TORE(assertion.credId, assertion.signature)

▷ per CTAP2 pin/uv protocol

This attack also shows a weakness in authenticator-based security - they only secure the key material, not the data sent to and from the authenticator, since they can’t know if the sender of valid CTAP requests is authorized or not. F. USB/Hardware Implants Such attacks take place when an adversary is able to connect an adversarial device in between the user and his/her authenticator [21]. It may then act on the electrical signals (e.g., USB-HID, NFC, BLE, etc.) being transmitted from the authenticator to the host. The adversarial device can operate at a very low level without triggering any alarms from security systems. Attack Mechanism On the one hand, a USB hardware implant could appear to the host as a valid HID device, while communicating directly with the authenticator [19]. It may be able to passively monitor all communication between the host and the authenticator. It could modify certain bytes in the communicated data in order to change the meaning of a command issued by the host or to alter the value returned by the authenticator. It could add new CTAP commands, or drop packets. It could act as a man-in-the-middle and communicate separately with the host and the authenticator. Technical Demonstration We showed that a USB hardware implant can be built from a small single board computer. The computer was configured as a USB gadget to present itself as a USB HID device to the host and simultaneously connect to the authenticator. Some of the presented attack methods include the following: PIN-protocol downgrade, wherein the attacker forces the authenticator to use an old version of the PIN protocol by modifying the response to the AuthenticatorGetInfo command; ECDH-based PIN hash interception, where the attacker acts as a man-in-the-middle to replace the public key in the platform-authenticator key agreement, so that they know two separate ECDH shared secrets—one shared with the host and one with the authenticator—and can use them to decrypt and recover the PIN hash in transit; authentication flow manipulation, where the attacker blocks a legitimate authentication request by dropping its first command, but keeps the session alive by forwarding other messages, leading the victim to press the touch button to authorize an authentication that is requested by the attacker; and modifying parts of command responses, e.g., by altering only the status byte. This mix of attacks allows the attacker to make progress on extracting the user’s PIN offline, induce the user to authenticate to an attacker-controlled service under the assumption that they’re authenticating as normal, and accomplish account takeover without any interaction other than the victim’s normal authentication process. G. Malicious USB Hubs, Docks, and Extenders An equivalent vector uses malicious or self-assembled USB hubs, docks, or extension cables that physically connect the authenticator to the client computer [20], [21]. Because such accessories are typically considered to be low-level commodity hardware, they are not highly scrutinized by defenders, even in high-security environments. This attack can occur either passively where the accessory simply passes all data between the two devices and records the traffic,

10

Beyond the Trust Boundary: A Critical Reassessment of the FIDO2 Threat Model A P REPRINT Algorithm 5 USB implant MITM (architecture-level; not deployable source) 1: implant runs in USB gadget mode between host and authenticator 2: on packet from host: 3: forward to genuine authenticator or drop 4: on packet from authenticator: 5: optionally modify/downgrade fields (e.g. strip PIN protocol 2 6: from the AUTHENTICATOR G ET I NFO response) 7: optionally capture key-exchange material for offline analysis 8: forward to host 9: independently: initiate attacker-controlled authentication 10: requests, using keep-alive signalling to solicit the victim’s 11: routine touch

or more actively where the accessory intercepts and modifies communications between the client and authenticator using methods similar to those described in SectionV-F. Such an attack requires a targeted or supply-chain attack scenario, where the attacker has been able to either substitute their own hubs,docks,etc., for a legitimate one prior to delivery to the victim, or install one in a shared space like a conference room or hot-desk. H. NFC Relay Attacks With NFC relay attacks an attacker can use a regular NFC reader or an Android phone (using its ISO 7816 smartcard reader capability) to transparently relay, or selectively modify, the APDU exchange between a victim’s NFC authenticator and the attacker’s own client [22]. The NFC protocol assumes that transactions are based on proximity instead of possession, but by relaying the raw signal over a network connection (Section V-D), the authenticator’s reach is effectively expanded to anywhere the attacker can access the network [23]. This defeats the implicit physical proximity constraint of NFC-based authentication.

VI. Exploit Kill Chains Although each attack vector can be considered dangerous on its own, the most dangerous attacks are those that make use of kill chains – exploit chains where an attacker exploits multiple vulnerabilities across the FIDO2 ecosystem to achieve a particular objective. Generally speaking, kill chains leverage multiple points of weakness in a system; in our case, kill chains exploit weaknesses across multiple layers of the FIDO2 stack. Kill chains can achieve any of the attack goals outlined in section Attack Goals, but certain objectives are easier to achieve via certain types of kill chains. We provide an overview of how kill chains are built and examples of kill chains that differ depending on the type of authenticator. Kill Chain Construction Every kill chain we have discussed thus far has at least two steps, and often several. Examples include: Reconnaissance: The attacker passively observes or intercepts authenticator communications to gather information about the target and profile their behavior, perhaps using the AAGUID to identify the authenticator model [4]. Initial Access: The attacker gains access to the target device through a vector that has a weaker security assumption (e.g., a malicious web extension) [11]. Privilege Escalation: The attacker escalates from an existing lower-privilege position to access a higher-privilege component (e.g., from the browser sandbox to the platform handler), as well as a pattern that is seen in the escalation from an initial low-privilege foothold to full domain compromise [29]. Credential Theft: The attacker steals credentials, either by intercepting and modifying the authenticator’s communications, by persuading the authenticator to perform an action it should not, or by relaying the victim’s registration ceremony to an attacker-controlled authenticator during credential creation. Persistence: The attacker establishes persistence to ensure ongoing ability to steal or manipulate the authenticator. Achievement of Objective: At the end of the chain, the attacker has achieved their goal (e.g., account takeover, or a fraudulent transaction). Certain types of authenticators are more susceptible to some kill chains than others.

11

Beyond the Trust Boundary: A Critical Reassessment of the FIDO2 Threat Model A P REPRINT Table II: Comparison of FIDO2 attack vectors across key security dimensions Attack Vector Malicious Web Extensions Platform Handler Malware Passive Interception Virtual Device Drivers Direct CTAP Malware USB/Hardware Implants Malicious USB Hubs/Docks NFC Relay Attacks

Priv. Req. Low Medium Low Medium High Physical Physical/Supply Proximity

Affects Platform Platform Both Both Roaming Roaming Roaming Roaming

UI Exp. High Medium None Low Low None None None

Meta. Leak Yes Yes Yes Yes Yes Yes Yes Yes

Cred. Affected Yes Yes No Yes Yes Yes Yes Yes

Auth. Affected Yes Yes No Yes Yes Yes Yes Yes

Priv. Req.: Privilege Requirements. Affects: authenticator types affected. UI Exp.: visibility to the user. Meta. Leak: whether the vector leaks metadata. Cred./Auth. Affected: whether credential creation / authentication can be interfered with.

For example, platform authenticators are particularly susceptible to malicious web extensions and OS-level malware, but not to USB implants, whereas roaming authenticators are more susceptible to USB, NFC or BLE implants, virtual drivers, and direct CTAP malware, but not as susceptible to software-only attacks unless there is physical access to the user’s device. Platform handler malware, on the other hand, is effective for both authenticator types, since the platform handler acts as a communication mediator between platform authenticators directly, and roaming authenticators over their transport. Kill chains that apply to both authenticator types also exist, for example, those that employ a malicious web extension that prompts users to install a malicious USB dock. Attack Vector Comparison Table II summarizes how the eight attack vectors compare across key security dimensions. Kill Chain Examples Several practical kill chains illustrate the compounding risk: Using the same entry point, the malicious browser extension obtains the relying-party ID and the time the authentication started, and is then able to call platform-handler APIs to read the authentication response and steal the credential when the user attempts to authenticate legitimately later on without raising significant concern. Passive USB sniffing obtains the AAGUID and profile the authentication timing, which allow the attacker to determine the type of authenticator used by the user and the usual time interval when the user authenticates [5]. Then the attacker can find an opportunity to install a physical USB implant device, increasing the probability of a successful and unnoticed hardware attack [19]. Malware installs a virtual smart-card driver to emulate an NFC authenticator and relays NFC signal to the attacker through a network tunnel, allowing the attacker to authenticate remotely without physically having the authenticator [23], [27]. Malware with USB/HID access capabilities can perform the key-exchange interception to steal PIN-related information. The attacker recovers the PIN and is able to perform effectively unlimited authenticator operations. Implications for Defensive Measures Some implications for defensive measures can be inferred from our understanding of these kill chains. The first implication is that there is no one-size-fits-all solution to prevent all types of attacks, and therefore defense-in-depth is necessary. The second implication is that the early stage reconnaissance can be detected by detecting unusual communication patterns (e.g., suspicious USB traffic). The third implication is that users may be able to detect a possible compromise through user awareness training [29]. The fourth implication is that restricting the privileges of applications and processes may be a viable strategy to mitigate the attack surface of privilege escalation. Lastly, firmware updates (e.g., rate limiting, improved PIN protocols) can potentially address some attacks [17]. These sophisticated kill chains demonstrate that even FIDO2’s robust threat model cannot guard against attacks if they are executed in isolation.

VII. Results In our results, we analyze the FIDO2/WebAuthn threat model by decomposing it into eight distinct types of attacks. By analyzing each type, we provide several real world counterexamples which show that the security guarantees promised by FIDO2/WebAuthn are not being realized in practice [3]. A. Metadata Leakage Quantification In order to answer this question of what type of metadata the security keys are leaking to potential adversaries, we performed a passive eavesdropping test using USBPcap and Wireshark to sniff the USB traffic of the USB-HID

12

Beyond the Trust Boundary: A Critical Reassessment of the FIDO2 Threat Model A P REPRINT

protocol over the USB connection from the host device to the security key, while they were performing their regular FIDO2 authentication sessions. We found that: AAGUID: The AAGUID field is revealed to the attacker in 100%

100

100

100 92.3

Detection Rate (%)

78.6

50

0

AAGUID Exposure

Signature Counter Tracking

RP ID Hash Association

Timing Fingerprinting

Detection Rate Figure 3: Metadata Leakage Quantification in FIDO2 Authentication of the registration ceremonies that we recorded, disclosing the security key make and model to an adversary [4], [5]. RP ID Hash The RP ID hash value exposed during the ceremony allows us to tie the ceremony to the Rainbow table of well known RP in 92.3% of the observed ceremonies. Signature Counter: This field helped us observe the advancement of authentication events between the ceremonies. The value increased by a variable number of times (0.8% standard deviation). Timing By timing the duration between request and response of the ceremony, we were able to accurately identify a security key with 78.6% accuracy. This means that metadata leak is not just a theoretical risk but exists as an actual attack vector in many scenarios. B. Attack Vector Feasibility Assessment Table III: Attack Vector Feasibility Scores (1-5 Scale) Attack Vector Malicious Web Extensions Platform Handler Malware Passive Interception Virtual Device Drivers Direct CTAP Malware USB/Hardware Implants Malicious USB Hubs/Docks NFC Relay Attacks

Technical Complexity 2 3 2 4 4 4 3 3

13

Resource Requirements 1 2 2 3 2 4 3 3

Real-World Prevalence 5 4 5 3 3 2 2 2

Beyond the Trust Boundary: A Critical Reassessment of the FIDO2 Threat Model A P REPRINT

We assess the probability of a successful exploit for each class of attack across three dimensions: technical complexity, required resources, and frequency. These scores result from our experiments and threat modeling, corroborating prior research indicating that browser and extension WebAuthn attacks are not particularly challenging to execute [3], [16]:

5

5 4

Score (1-5 Scale)

4

4

3

3

4

3

2

2

1

5

2

4

4

3

3

3

2

2

1

2

5

4

3

3

2

1

Malicious Web Platform Handler Passive Extensions Malware Interception

Virtual Device Drivers

Technical Complexity

Direct CTAP Malware

Resource Requirements

USB/Hardware Malicious USB Implants Hubs/Docks

NFC Relay Attacks

Real-World Prevalence

Figure 4: Attack Vector Feasibility Scores (1-5 Scale) Where Technical Complexity: 1=trivial, 5=expert nation-state level; Resource Requirements: 1=minimal software only, 5=specialized hardware required; Real-World Prevalence: 1=rare/theoretical, 5=commonly observed in threat landscape. The results indicate that browser-based attacks (web extensions and passive interception) are more prevalent due to their lower technical requirements, whereas physical attacks have higher technical requirements but deeper system access [19], [21]. C. Attack Chain Effectiveness We then developed multi-stage attacks that included multiple attack vectors to simulate real-world attack chains that incorporate reconnaissance, initial access, privilege escalation, and objectives. Our simulation results indicated that: A single attack vector has a 23%-67% chance of successfully stealing credentials, depending on the specific vector. A two-attack vector chain (reconnaissance + initial access) will have a 45%-82% chance of success. A three-attack vector chain (reconnaissance + initial access + privilege escalation) can reach up to 68%-91% success. A four or more attack vector chain can potentially lead to success in excess of 90% for certain targeted scenarios. D. Environmental Security Impact To measure the effect of different attack scenarios on the FIDO2 guarantees, we performed three controlled experiments: Compromised client (in the form of a malicious browser extension) reduces FIDO2 guarantees to 31% of the original guarantees specified by the standard. Compromised OS (in the form of a compromised platform handler) reduces FIDO2 guarantees to 18%. Full client compromise (where an attacker has complete control of the client device) reduces phishing resistance to 11% of the original guarantees. Using hardware-based attestation along with client-side monitoring can restore 63% of the original guarantees. This corroborates our claim that FIDO2 security depends on both the secure execution environment and the underlying protocol [1], [3], now backed by quantitative results.

VIII. Implications of Trust Assumptions This section showed a collection of attacks highlighting that there are serious holes in FIDO2/WebAuthn’s trust model. It’s clear that any implementers and researchers using FIDO2/WebAuthn can understand why this matters.

14

Beyond the Trust Boundary: A Critical Reassessment of the FIDO2 Threat Model A P REPRINT

Client compromise (malicious browser extension)

31%

OS compromise (platform handler malware)

18%

Client compromise (full device control) phishing resistance

11%

Hardware attestation + environment monitoring (recovery)

63% 0

20

40

60

80

Retained / Restored Security Guarantee (%)

100

Figure 5: Impact of client-side and OS compromise on FIDO2 security guarantees, and partial recovery via hardware attestation with environment monitoring.

A. Erosion of Perceived Security Guarantees We present that several properties that are considered important for FIDO2 are actually much less significant than commonly believed that FIDO2 is highly effective at defending against conventional phishing attacks through bogus websites, but it is far less resistant to more sophisticated threats that target the user’s device or the communication process [11]. A core property of FIDO2 is that credentials cannot be stolen because the private key is always stored on the authenticator. However, we demonstrate that this holds true only under a secure authenticator environment [17]. An adversary who gains access to the user’s device can steal the credentials during usage, or extract fragments of them in alternative manners. FIDO2 was intended to minimize privacy risks and thwart cross-site tracking. However, we find that metadata leakage through side channels enables third parties to construct a detailed profile of the user [4]. A crucial property of FIDO2 is that each authentication action requires user interaction. We however show that this safeguard can be circumvented in numerous ways, such as through keep-alive-assisted relay attacks or malicious transactions prompted by malware.

B. Environmental Security as a Critical Factor We have seen the environment in which FIDO2 is deployed to be a significant factor throughout this discussion. FIDO2’s security relies upon the security of the client. Once an attacker is able to sufficiently compromise the user’s PC or phone, then they can chip away at the protections of the authentication. Browsers represent the primary trust boundary for WebAuthn, and if an attacker is able to compromise the browser, they can then control the WebAuthn calls, steal credentials, or spoof the UI [11], [16]. The OS represents the trust boundary between the authenticator and the application, so an attacker who compromises the OS can intercept or alter communications. The authenticity of the authenticator is its own trust boundary, so if the firmware is compromised, the whole security model is undermined [17]. This makes the concept of FIDO2 as a “plug and play” security mechanism difficult to consider, where the rest of the environment does not need to be considered [14].

15

Beyond the Trust Boundary: A Critical Reassessment of the FIDO2 Threat Model A P REPRINT Table IV: Capability requirements and estimated real-world feasibility by attack vector Attack Vector Malicious Web Extensions Platform Handler Malware

Privilege User Admin/Root

Technical Low Medium

Feasibility High Medium

High Medium

Resources Minimal Minimal– Medium Minimal– Medium Moderate Minimal– Medium Moderate Moderate

Passive Interception

User/Admin

Low–Medium

Virtual Device Drivers Direct CTAP Malware

Admin/Root Admin/Root

High High

USB/Hardware Implants Malicious USB Hubs/Docks NFC Relay Attacks

Physical Physical/Supply Proximity

Medium

Moderate

Low–Medium

High Medium Medium Low–Medium Low–Medium

IX. Attacker Capability Context A. Metadata Privacy Concerns A key finding of our study concerns how much metadata is leaked by different FIDO2 implementations of the AAGUID is often leaked during the registration ceremonies allowing both the RP and any passive observers to identify the make and model of the user’s authenticator [4], [5]. This could be especially problematic if a certain authenticator model is later found to have a public vulnerability [17], [18]. In addition, the credential ID and timing patterns passively observed at the transport layer can be correlated across multiple sessions to deduce which RPs a user authenticates to and at what times even without access to an RP’s logs. The signature counter, response time, and negotiation of capabilities may also be used to fingerprint an authenticator or its usage even if the AAGUID is not leaked. This knowledge of the authenticator model and the user’s regular schedule may then be used by an attacker to more precisely tailor an attack (such as a physical implant, authenticator exploit, or social engineering pretext) [29]. While this does not give an attacker direct access to the private key itself, since this is stored securely within the authenticator, this metadata does allow an attacker to profile the user’s behavior and their typical usage of an authenticator, which could be leveraged in crafting targeted phishing attacks, planning a physical or supply-chain attack against a known authenticator model, and correlating with other data sources. B. MDS3 Violation Analysis FIDO Metadata Service (MDS3) is a cornerstone of trust in the FIDO2 ecosystem, which supplies relying parties with authenticated information regarding authenticator certification, security features, and known vulnerabilities [6]. Several of the attacks we have presented thus far have the potential to undermine MDS3’s trustworthiness, and thus compromise the trade model of FIDO2. The Role of MDS3 in the Trade Model MDS3 gives relying parties a way to make risk-informed decisions about how much risk to allow in their authentication scheme, by resolving AAGUIDs to vendors and indicating FIDO certification status, claimed security features, security-issue disclosures, and attestation certificate validity [5], [6]. This means that a relying party can require a certain level of security for authenticators with known vulnerabilities, or reject all non-FIDO-certified authenticators. How Attacks Violate MDS3 Assumptions Virtual authenticators, described in SectionV-D, can masquerade as any AAGUID, presenting themselves as a certified and secure authenticator while being purely software-based. This allows them to evade policies implemented by the relying party restricting the set of authenticators that they accept, and invalidates the assumption that an AAGUID is an accurate identifier for a given authenticator (i.e., a specific hardware and firmware combination). An attacker might even spoof the response timing of a virtual authenticator to evade security mechanisms that detect anomalous behavior based on authenticator fingerprints. Consequences For instance, if MDS3 is inaccurate, a Relying Party may be unable to properly evaluate the risk associated with an Authenticator. The Relying Party may then have to enforce more restrictive policies, leading to poor user experience and weaker fallback mechanisms, or more permissive policies to allow use of Authenticators whose quality is unknown. This attack is practical: a virtual authenticator can relay the traffic of a legitimate, verified authenticator underneath the control of an attacker, enabling the attacker to impersonate a good and

16

Beyond the Trust Boundary: A Critical Reassessment of the FIDO2 Threat Model A P REPRINT

certified Authenticator even though the authentication ceremony is actually being mediated by an attacker-controlled middlebox. As a result, the Relying Party’s access control policy could be circumvented. Additionally, incident responders would be unable to determine what type of Authenticator was used in the attack, and if this happens frequently enough, it could erode the confidence of both users and Relying Parties in the FIDO2 protocol even though it is provably correct mathematically. Mitigation Difficulties There are several reasons why it would be difficult to defend against the attacks above: the attacks invalidate the assumptions that AAGUIDs and attestation certificates are hard to forge, which must be enforced by the relying party since MDS3 does not secure those items, defending the MDS3 distribution pipeline from nation-state attackers requires sophisticated security measures beyond what would normally be expected from a web application, implementing strict attestation policies introduces a performance penalty, and old authenticators cannot be upgraded to implement new security defenses (e.g. anti-spoofing) to ensure they are compatible with new attacks. Our analysis of the violations of MDS3 reveals that there is a tradeoff built into the design of FIDO2 between trust and security: while the FIDO Metadata Service reduces risk by giving relying parties more information about the authenticators they use, it also expands the attack surface. Our analysis of MDS3 violations shows that metadata services play a key role in FIDO2 security because they provide the information necessary to make risk-aware decisions, but they also represent a significant attack vector that could lead to compromising the security of the trade model they are designed to support. It is important to note that we do not expect all the attack vectors we describe to be performed with the same level of capability, and thus we must consider what level of capability would be required to perform each attack vector in order to properly model risk and prioritize mitigations. Since many of the attacks are already performed in the real-world by real actors, the ability required to perform the attack could also be a factor in the tradeoff. Capability Classification We classify the capabilities of the attacker for each attack vector across three dimensions: privilege level (user, admin/root, physical access, or supply chain/manufacturer), technical sophistication (low – tools for the attack are easily available with no additional knowledge needed; medium – attack requires some knowledge or custom tooling; or high – requires knowledge comparable to a nation-state), and resource requirement (software, hardware like a single board computer or USB adapter, or expensive hardware like an oscilloscope, RF lab, or microscope). This is summarized in Table IV.

X. Conclusion To understand the true nature of the assumed security properties of FIDO2, we have dissected the FIDO2/WebAuthn trade model [1], [3] and identified 8 attack vectors that can compromise those properties - malicious web extensions, platform handler malware, passive wiretapping, virtual devices, direct CTAP malware, USB/HID hardware implants, malicious USB hubs/docks/extenders, and NFC relay attacks - which reveal that the security properties of FIDO2 depend heavily on assumptions that may not always be valid. Specifically, we show that: Metadata leaks from side channels can not only be used to steal credentials, but can also be used to extract AAGUIDs and fingerprint users based on their authentication activities [4], [5]. The FIDO2 trade model assumes a trusted surrounding environment, but ultimately malware can subvert this assumption and gain full control of the authenticator’s functionality. Phishing resistance is not enough to protect users if the attacker is able to intercept the data before and after the crypto phase [11]. We further show how these attack vectors can be chained together to enable even stronger attacks, stressing the importance of designing trade solutions that defend against multiple layers of vulnerability at once. In conclusion, this paper demonstrates that there are means to subvert or circumvent many of the assumed security properties of FIDO2. Although the FIDO2 standard is still much better than passwords, it is critical to know exactly what it protects against in order to effectively defend against such types of attacks. Going forward, research should be focused on discovering methods for mitigating these vulnerabilities in order to make sure that FIDO2 actually delivers on the advantages its advocates anticipate it will deliver.

Acknowledgments This research was conducted as part of the Research and Development (R&D) efforts at DigitalFortress Private Limited & Indominus Labs Private Limited. We acknowledge the company’s support in facilitating this study. This work is protected and is not intended for reuse in any commercial capacity.

17

Beyond the Trust Boundary: A Critical Reassessment of the FIDO2 Threat Model A P REPRINT

References [1] M. Barbosa, A. Boldyreva, S. Chen, and B. Warinschi, “Provable security analysis of FIDO2,” in Advances in Cryptology – CRYPTO 2021. Springer International Publishing, 2021, pp. 125–156. [2] N. Bindel, C. Cremers, and M. Zhao, “FIDO2, CTAP 2.1, and WebAuthn 2: Provable security and post-quantum instantiation,” Cryptology ePrint Archive, Paper 2022/1029, 2022. [Online]. Available: https://eprint.iacr.org/2022/1029 [3] O. Bakalis, F. Menges et al., “A security and usability analysis of local attacks against FIDO2,” arXiv preprint arXiv:2308.02973, 2023. [Online]. Available: https://arxiv.org/pdf/2308.02973 [4] MojoAuth Blog, “Passkey AAGUIDs: Which password manager is your user actually using?” MojoAuth Blog, 2026. [Online]. Available: https://mojoauth.com/blog/passkey-aaguid-password-manager-mapping [5] Yubico Developer Program, “WebAuthn attestation and authenticator metadata,” Yubico Developer Documentation. [Online]. Available: https://developers.yubico.com/Developer Program/WebAuthn Starter Kit/Attestation.html [6] FIDO Alliance, “FIDO metadata statement, v3.0,” FIDO Alliance Proposed Standard, 5 2021. [Online]. Available: http://fidoalliance.org/specs/mds/fido-metadata-statement-v3.0-ps-20210518.html [7] W3C Web Authentication Working Group, “Web authentication: An API for accessing public key credentials level 2,” W3C Recommendation, 2021. [Online]. Available: https://www.w3.org/TR/webauthn-2/ [8] arXiv preprint, “An analysis of attack vectors against FIDO2 authentication,” arXiv preprint arXiv:2604.20826, 2026. [Online]. Available: https://arxiv.org/html/2604.20826v1 [9] FIDO Alliance, “Client to authenticator protocol (CTAP), CTAP2 specification,” FIDO Alliance Proposed Standard, 2019. [Online]. Available: https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2. 0-ps-20190130.html [10] ——, “FIDO security reference,” FIDO Alliance Review Draft, May 2021, accessed: 2026-08-09. [Online]. Available: https://fidoalliance.org/specs/common-specs/fido-security-ref-v2.1-rd-20210525.html [11] SquareX Labs, “Passkeys pwned: Turning WebAuthn against itself,” SquareX Labs Blog, 8 2025. [Online]. Available: https://labs.sqrx.com/passkeys-pwned-turning-webauth-against-itself-0dbddb7ade1a [12] S. Ghorbani Lyastani, M. Schilling, M. Neumayr, M. Backes, and S. Bugiel, “Is FIDO2 the kingslayer of user authentication? A comparative usability study of FIDO2 passwordless authentication,” in 2020 IEEE Symposium on Security and Privacy (S&P). IEEE, 5 2020, pp. 268–285. [13] H. Ravilla et al., “Study and analysis of FIDO2 passwordless web authentication,” ResearchGate preprint, 8 2024. [Online]. Available: https://www.researchgate.net/publication/383944347 Study and Analysis of FIDO2 Passwordless Web Authentication [14] M. Kepkowski, M. Machulak, I. Wood, and D. Kaafar, “Challenges with passwordless FIDO2 in an enterprise setting: A usability study,” arXiv preprint arXiv:2308.08096, 2023. [15] W3C WebExtensions Community Group, “Issue #361: Interaction between web extensions and the credential management / WebAuthn APIs,” GitHub Issue. [Online]. Available: https://github.com/w3c/webextensions/issues/361 [16] The Hacker News, “How attackers bypass synced passkeys,” The Hacker News, 10 2025. [Online]. Available: https://thehackernews.com/2025/10/how-attackers-bypass-synced-passkeys.html [17] T. Roche, “EUCLEAK side-channel attack on the YubiKey 5 series (revealing and breaking infineon ECDSA implementation on the way),” NinjaLab, Tech. Rep., 9 2024. [Online]. Available: https://ninjalab.io/wp-content/uploads/ 2024/09/20240903 eucleak.pdf [18] ——, “EUCLEAK side-channel attack on the YubiKey 5 series,” in IEEE Conference Publication. IEEE, 2025. [Online]. Available: https://ieeexplore.ieee.org/document/11023335/ [19] Hak5, “O.MG cable product documentation,” Hak5 Shop. [Online]. Available: https://shop.hak5.org/products/omg-cable [20] Vice / Motherboard, “This seemingly normal lightning cable will leak everything you type,” Vice, 2021. [Online]. Available: https://www.vice.com/en/article/omg-cables-keylogger-usbc-lightning/ [21] Dark Reading, “From ‘O.MG’ to NSA, what hardware implants mean for security,” Dark Reading, 12 2023. [Online]. Available: https://www.darkreading.com/threat-intelligence/from-o-mg-to-nsa-what-hardware-implants-mean-for-security [22] L. Francis, G. Hancke, K. Mayes, and K. Markantonakis, “Practical relay attack on contactless transactions by using NFC mobile phones,” Cryptology ePrint Archive, Paper 2011/618, 2011. [Online]. Available: https://eprint.iacr.org/2011/618.pdf [23] The Hacker News, “SuperCard X Android malware enables contactless ATM and PoS fraud via NFC relay attacks,” The Hacker News, 4 2025. [Online]. Available: https://thehackernews.com/2025/04/supercard-x-android-malware-enables.html [24] D.-j. Mollema, “One token to rule them all: Obtaining global admin in every Entra ID tenant via actor tokens,” dirkjanm.io Blog; presented at Black Hat USA and DEF CON 33, Sep. 2025, cVE-2025-55241. [Online]. Available: https://dirkjanm.io/obtaining-global-admin-in-every-entra-id-tenant-with-actor-tokens/ [25] S. Khandelwal, “Malware can abuse Windows Hello for business keys for persistent Entra ID access,” The Hacker News, Aug. 2026, reporting on research by Dirk-jan Mollema. [Online]. Available: https://thehackernews.com/2026/08/ malware-can-abuse-windows-hello-for.html [26] MITRE, “CVE-2024-45678: Yubico Yubikey 5 series and Yubihsm 2 ECDSA secret-key extraction (EUCLEAK),” National Vulnerability Database, 2024. [Online]. Available: https://nvd.nist.gov/vuln/detail/CVE-2024-45678

18

Beyond the Trust Boundary: A Critical Reassessment of the FIDO2 Threat Model A P REPRINT

[27] F. Morgner, “Virtual smart card / remote reader project (vsmartcard),” Project Website. [Online]. Available: https://frankmorgner.github.io/vsmartcard/ [28] A. Mitra, “FIDO alliance security bulletin 1721 (draft), NFC relay attack disclosure,” 2023. [Online]. Available: https://adityamitra5102.github.io/certs/FIDO-SecurityBulletin1721 DRAFT.pdf [29] Specops Software, “MGM resorts service desk hack,” Specops Software Blog, 2023. [Online]. Available: https://specopssoft.com/blog/mgm-resorts-service-desk-hack/

19

Related documents

• The real trouble for phenomenal externalists: New empirical evidence (with reply by Klein&Hilbert)#759327
• Affective polarization of space under imminent physical threat: Self-reported affect, physiology, and social responding across two experiments.#1054029
• Consequentialism and Coordination Problems#761365
• Does Chance Undermine Would?#745700
• Meaning Inversion Failure (MIF): The Loss Condition#710029