PaperlayerView exact revision on arXiv

Source-linked AI summary

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

Aditya Mitra, Kolluru Sai Abhiram, Sibi Chakkaravarthy Sethuraman, Anitha S

arXiv:2609.03789v1cs.CRcs.ET

TL;DR

FIDO2’s threat model relies on assumptions about the client, hardware, and trust boundaries, while prior models may treat attacks separately. This paper broadens the analysis to chained attacks and the full execution environment, finding that these assumptions can be violated and that attack vectors can combine to undermine FIDO2’s assumed protections.

  • Problem

    The standard threat model assumes a trusted client and fixed trust boundaries, analyzes attacks individually, and emphasizes cryptography over environmental security.

    Source: A. Limitations of the Original Threat… · p. 4

  • Method

    The paper refines the threat model by evaluating chained attacks, environmental trust, changing trust boundaries, and a spectrum of attacker sophistication across the system.

    Source: B. Our Refined Threat Model · p. 5

  • Results

    The analysis identifies attacks that can compromise assumed FIDO2 security properties and shows that separate attack vectors can be chained into stronger attacks.

    Source: §X · p. 17

  • Takeaways & Limitations

    FIDO2 deployments require defenses that account for the execution environment, since the paper finds that its assumed protections can be subverted or circumvented.

    Source: B. Our Refined Threat Model · p. 5, §X · p. 17

    The standard threat model assumes that attackers have limited capabilities and that the client is trusted or not fully compromised.

    Source: A. Limitations of the Original Threat… · p. 4

Abstract

from arXiv · show

FIDO2/WebAuthn has been widely deployed as a phishing-resistant authentication scheme. Because FIDO2 relies on public-key cryptography and hardware-backed authenticators, its security is often assumed to be guaranteed by design, provided that the cryptographic implementation is correct. In this work, we critically reassess the FIDO2 threat model and show that several commonly assumed security properties do not hold under realistic deployment conditions. We extend the threat model beyond the cryptographic layer to examine eight attack vectors across the FIDO2 stack: malicious browser extensions, platform-handler malware, passive sniffing, virtual device drivers, CTAP2-specific malware, USB/hardware implants, malicious USB hubs/docks/extenders, and NFC relay attacks. Our analysis shows that FIDO2 depends on environmental assumptions that may not hold in practice. We demonstrate how AAGUID and timing information can enable user profiling and targeted attacks, and how compromise of the browser, operating system, or hardware can undermine FIDO2 security even when the underlying cryptographic primitives remain uncompromised. We further show that attack chains spanning multiple layers can bypass the intended security guarantees of FIDO2. These findings indicate that the primary weakness in a FIDO2 deployment is often not the cryptographic layer, but the surrounding trusted environment. We also examine how these attack vectors can undermine device attestation by targeting the FIDO Metadata Service (MDS3), which serves as a root of trust for authenticator metadata. Finally, we characterize the attacks according to privilege, skill, and resource requirements. We conclude that effective FIDO2 security requires layered mitigations covering the browser, operating system, hardware, protocol stack, and metadata infrastructure.

I. Introduction

FIDO2 combines WebAuthn’s web-facing credential API with CTAP communication to authenticators. This paper examines how assumptions about the surrounding environment affect its security.

I. Introduction

  • FIDO2 is intended to replace passwords with phishing-resistant authentication based on public-key cryptography.WebAuthn defines the API for creating and using credentials, while CTAP specifies communication between the client and external authenticators.Source: §I · p. 2

A. Architecture

  • WebAuthn and CTAP are complementary but distinct specifications: WebAuthn defines a JavaScript API, while CTAP governs client-to-authenticator communication.CTAP is a FIDO Alliance specification maintained independently from the W3C WebAuthn standard.Source: §I · p. 2

I. Introduction

  • FIDO2 adoption has spread across major platforms and web services.Apple shipped support first among major platform vendors, followed by Microsoft and Google.Source: §I · p. 2
  • FIDO2’s security depends on environmental assumptions, and violating them can undermine its guarantees despite its potential defenses against phishing and credential attacks.The paper analyzes those assumptions, eight attack types, and how attacks can be chained across system components.Source: §I · p. 2

A. Architecture

  • Authenticators may be built into a platform or supplied as separate devices, including USB keys, NFC tokens, smart cards, and Bluetooth authenticators.Authenticators store credentials and perform cryptographic operations.Source: A. Architecture · p. 3

B. Trust Model and Assumptions

FIDO2 relies on assumptions about cryptography, hardware, user presence, and the client environment. The paper describes the ceremonies and highlights trust dependencies that the standard threat model may understate.

B. Trust Model and Assumptions

  • The standard threat model assumes uncompromised cryptography and hardware, reliable user presence, a trusted client, secure communications, and correct relying-party validation.The assumptions cover both the authenticator and the browser, operating system, transport, and relying-party server.Source: B. Trust Model and Assumptions · p. 3
  • Browser IPC, drivers, and the platform handler rely on one another without further verification, creating an attack surface.The paper describes this dependency as implicit trust between client components.Source: B. Trust Model and Assumptions · p. 3

C. Working Procedure

  • Registration creates an origin-specific key pair after a relying party issues a challenge and the user proves presence; authentication later uses a signed challenge.The authenticator stores the private key, while the relying party stores the public key for subsequent verification.Source: C. Working Procedure · pp. 3–4

III. Contributions

  • The paper frames its contribution as refining how FIDO2 deployment security is evaluated, rather than proposing new cryptographic or implementation solutions.It catalogs problems arising from implicit trust assumptions.Source: §III · p. 4

A. Limitations of the Original Threat Model

  • The original threat model treats attack vectors independently, assumes a trusted client and fixed trust boundary, and gives limited attention to attacker capability and environmental security.It also focuses heavily on cryptographic primitives, according to the paper’s critique.Source: A. Limitations of the Original Threat… · p. 4

B. Our Refined Threat Model

The refined model treats FIDO2 as a system whose trust boundaries can change and whose security depends on more than cryptography. It accounts for chained attacks and attacker capabilities, informing ongoing, layered defenses.

B. Our Refined Threat Model

  • The refined threat model represents attacks as chains and includes environmental trust, attacker sophistication, and the execution environment alongside protocol security.It considers how multiple individually insufficient breaches may combine to bypass protections.Source: B. Our Refined Threat Model · p. 5
  • Trust boundaries are treated as continuously observable, and the model evaluates hardware, firmware, software, and users at the whole-system level.This lets the analysis consider vulnerabilities in individual components or combinations of components.Source: B. Our Refined Threat Model · p. 5

C. Practical Implications of the Refined Model

  • Organizations should extend defense-in-depth beyond the authenticator and monitor for changing trust conditions, since client, browser, and OS compromise can undermine authentication.The paper also recommends tandem controls and says adaptive authentication may help identify technically valid assertions from unhealthy or unexpected contexts.Source: C. Practical Implications of the… · p. 5

A. Formal and Cryptographic Analysis

  • Prior formal analyses verified cryptographic properties but typically assumed a trusted client, browser, and transport; this work relaxes those assumptions.The cited prior work includes analysis of CTAP2.1 PIN and user-verification sub-protocols.Source: A. Formal and Cryptographic Analysis · p. 5

B. Local and Implementation-Level Attacks

  • Prior local-attack research and reports on passkey-manager extensions motivate examining client components and extension attacks within a wider threat model.The paper treats browser-extension activity as part of a larger attack chain.Source: B. Local and Implementation-Level… · pp. 5–6

C. Hardware and Physical Attacks

  • Prior work showed that certified hardware-backed authenticators can be subverted physically, including through a side-channel recovery of a security key’s private key.Related work also demonstrated commodity USB implants and NFC relay attacks, informing the paper’s hardware and CTAP analyses.Source: C. Hardware and Physical Attacks · p. 6

D. Metadata and Side-Channel Leakage

The paper links FIDO2 metadata and component-level attacks to broader trust concerns. It presents a unified view of attack chains and describes how browser extensions can interfere with WebAuthn requests.

D. Metadata and Side-Channel Leakage

  • AAGUID and attestation data can reveal authenticator provenance and support user fingerprinting or correlation across sessions.The paper says its passive interception results quantify prior findings and connect leaked metadata to attacker actions in a kill chain.Source: D. Metadata and Side-Channel Leakage · p. 6

E. Trust Infrastructure and Metadata Services

  • The paper identifies potential MDS3 subversion through an attacker-controlled middlebox relaying an honest authenticator’s traffic.MDS3 is described as the source relying parties use to resolve AAGUIDs to vendor and certification information.Source: E. Trust Infrastructure and Metadata… · p. 6

F. Usability and Enterprise Deployment

  • The paper’s unified treatment brings attack chains, environmental trust, and attacker capability into a literature that studied FIDO2 security aspects in isolation.The preceding work covered cryptographic, implementation, physical, and metadata issues.Source: F. Usability and Enterprise Deployment · p. 6

V. Attack Vector Analysis

  • Each attack-vector analysis describes the exploited trust relationship, feasibility, and an architectural-level pseudocode representation.The paper distinguishes this from deployable source code.Source: §V · p. 6

A. Malicious Web Extensions

  • Extensions with relevant permissions can monitor and proxy WebAuthn create and get calls, forwarding their arguments before invoking the API.A malicious extension can instead return an attacker-controlled fake credential or assertion without using a real authenticator.Source: A. Malicious Web Extensions · p. 7
  • Browser-context code can alter request parameters before authenticator submission, but changing a signed assertion afterward breaks its signature and leads to rejection.Post-assertion interception is limited to stealing the credential ID and signature for possible later replay or offline analysis.Source: A. Malicious Web Extensions · pp. 7–8

B. Malware Communicating with the Platform Handler

Platform-handler malware can initiate unintended FIDO2 ceremonies through operating-system APIs, while passive interception exposes authentication metadata that supports profiling and targeted attacks.

B. Malware Communicating with the Platform Handler

  • Platform authenticators such as Windows Hello and Touch ID expose APIs that applications can access without privilege escalation beyond regular-user privileges.Source: B. Malware Communicating with the… · p. 8
  • Regular-user malware can invoke platform authentication APIs to trigger an unintended ceremony, although the user must still satisfy the authenticator’s user-presence check.The platform handler does not distinguish malware-initiated requests from normal client requests, so users may not know which relying party prompted them.Source: B. Malware Communicating with the… · p. 8

C. Passive Interception

  • Passive interception can reveal visited websites, authentication timing, authenticator make and model through AAGUID, and credential IDs for correlation.Source: C. Passive Interception · p. 8
  • USBPcap and Wireshark captured USB-HID traffic during credential creation; Table I presents the 64-byte CTAPHID packet layout and fields of interest in decoded CBOR data.Source: C. Passive Interception · p. 8, Table I · p. 9
  • A captured AAGUID can be looked up in MDS3 to identify the authenticator vendor and model, supporting targeted exploitation of models susceptible to known side-channel attacks.Source: C. Passive Interception · pp. 8–9

D. Virtual Device Drivers

Virtual drivers can impersonate authenticators or transports, while direct CTAP malware can control authenticator commands and data beyond the platform-handler API layer.

D. Virtual Device Drivers

  • Virtual authenticators can receive challenges, exfiltrate credentials, spoof user presence, and supply fake attestation; virtual transport drivers can intercept, modify, inject, relay, or downgrade traffic.Source: D. Virtual Device Drivers · p. 9
  • A virtual smart-card driver paired with an NFC relay application can make a physical key appear locally attached, or capture credentials generated on an attacker-supplied authenticator.The demonstration relayed the victim’s NFC exchange over the internet to the attacker’s host machine.Source: D. Virtual Device Drivers · p. 9

E. Malware Performing CTAP

  • Direct CTAP access gives malware control to modify PINs, reset authenticators, issue valid commands, inspect responses, and intercept or modify data.Source: E. Malware Performing CTAP · pp. 9–10
  • The privilege needed for raw USB-HID access varies by platform: it usually requires administrator privileges on Windows, but may require none on Linux.Source: E. Malware Performing CTAP · p. 10
  • Authenticator-based security protects key material but cannot determine whether the sender of valid CTAP requests is authorized.Source: E. Malware Performing CTAP · p. 10

F. USB/Hardware Implants

Hardware implants can monitor or manipulate authenticator traffic, and malicious USB accessories can provide a less scrutinized route for similar interception or modification.

F. USB/Hardware Implants

  • A USB hardware implant can monitor, modify, add, or drop host-authenticator traffic while presenting itself to the host as a valid HID device.Source: F. USB/Hardware Implants · p. 10
  • Implant techniques include PIN-protocol downgrade, ECDH key substitution to intercept PIN-related hashes, and manipulation of authentication flows or command responses.Source: F. USB/Hardware Implants · p. 10
  • The combined attacks can advance offline PIN extraction, induce authentication to an attacker-controlled service, and enable account takeover during the victim’s normal authentication process.Source: F. USB/Hardware Implants · p. 10

G. Malicious USB Hubs, Docks, and Extenders

H. NFC Relay Attacks

NFC relays defeat the protocol’s proximity constraint by tunneling authenticator exchanges over a network. The paper also describes cross-layer kill chains whose applicability varies by authenticator type and motivates layered defenses.

H. NFC Relay Attacks

  • Relaying raw NFC APDU exchanges over a network effectively extends an authenticator’s reach beyond proximity and defeats NFC’s implicit physical-proximity constraint.Source: H. NFC Relay Attacks · p. 11

VI. Exploit Kill Chains

  • Kill chains combine weaknesses across FIDO2 layers to pursue an attack objective, and platform and roaming authenticators have different exposure to attack vectors.Source: §VI · pp. 11–12
  • The described chain stages include reconnaissance, initial access, privilege escalation, credential theft, persistence, and achievement of an objective.Source: §VI · p. 11
  • Platform authenticators are more susceptible to web extensions and OS malware, while roaming authenticators face greater exposure to USB, NFC, BLE, virtual-driver, and direct-CTAP attacks.Platform-handler malware can affect both types, and a malicious extension can also prompt installation of a malicious USB dock.Source: §VI · p. 12
  • One example chain combines extension access, passive USB profiling of AAGUID and authentication timing, and later installation of a physical USB implant.Source: §VI · p. 12
  • The authors infer that defense-in-depth is needed because no single solution prevents all attack types; suggested measures include detecting unusual communications, restricting privileges, and firmware updates.Source: §VI · p. 12

VII. Results

The results use eight attack classes to provide real-world counterexamples to FIDO2/WebAuthn security guarantees. Passive interception also exposed authenticator and relying-party metadata and enabled timing-based identification.

VII. Results

  • The analysis decomposes the threat model into eight attack types and supplies real-world counterexamples to FIDO2/WebAuthn security guarantees.The authors state that these guarantees are not realized in practice [3].Source: §VII · p. 12

A. Metadata Leakage Quantification

  • AAGUIDs appeared in 100% of recorded registrations, while RP ID hashes matched well-known relying parties in 92.3% of observed ceremonies.The AAGUID discloses the security key's make and model.Source: Figure 3 · p. 13, A. Metadata Leakage Quantification · p. 13
  • Timing request-response intervals identified a security key with 78.6% accuracy, and signature counters tracked authentication-event advancement with 0.8% standard deviation.These observations show multiple fields and timing patterns can reveal information during authentication.Source: A. Metadata Leakage Quantification · p. 13

B. Attack Vector Feasibility Assessment

The assessment compares attack feasibility across technical complexity, resources, and prevalence, then examines multi-vector chains and environmental compromise. Longer attack chains achieved higher reported credential-theft success, while client and OS compromise sharply reduced FIDO2 guarantees.

B. Attack Vector Feasibility Assessment

  • Browser-based attacks were assessed as more prevalent because of lower technical requirements, whereas physical attacks require more technically demanding resources but offer deeper system access.Feasibility scores consider technical complexity, resource requirements, and real-world prevalence; Table III and Figure 4 present the scores.Source: Table III · p. 13, Figure 4 · p. 14, B. Attack Vector Feasibility Assessment · p. 14

C. Attack Chain Effectiveness

  • Four-or-more-vector chains could exceed 90% success in targeted scenarios, compared with 45%-82% for two-vector chains and up to 68%-91% for three-vector chains.A single vector had a 23%-67% chance of successfully stealing credentials, depending on the vector.Source: C. Attack Chain Effectiveness · p. 14

D. Environmental Security Impact

  • Compromised clients reduced FIDO2 guarantees to 31%, compromised operating systems to 18%, and full client compromise reduced phishing resistance to 11%; hardware attestation with client monitoring restored 63%.The authors say these results corroborate dependence on both the secure execution environment and the underlying protocol, [3].Source: D. Environmental Security Impact · p. 14

VIII. Implications of Trust Assumptions

The implications analysis argues that FIDO2 protections depend on the surrounding environment as well as the authenticator and protocol. It links metadata leakage and weaknesses in MDS3 to user profiling, targeted attacks, and uncertainty in relying-party risk decisions.

A. Erosion of Perceived Security Guarantees

  • FIDO2 remains highly effective against conventional phishing through bogus websites but is less resistant to sophisticated threats targeting users’ devices or communications.The discussion also describes credential theft during use, metadata-based profiling, and ways malware or relay attacks can circumvent user interaction.Source: A. Erosion of Perceived Security… · p. 15

B. Environmental Security as a Critical Factor

  • The browser, operating system, and authenticator form distinct trust boundaries: compromise can control WebAuthn calls, intercept or alter communications, or undermine the security model through firmware.The authors caution against treating FIDO2 as plug-and-play security that makes the rest of the environment irrelevant,,, [14].Source: B. Environmental Security as a… · p. 15

A. Metadata Privacy Concerns

  • AAGUID leakage can reveal an authenticator’s make and model, potentially exposing users to targeted attacks if that model is later found to have a public vulnerability.Credential IDs and timing patterns can also be correlated across sessions to infer relying parties and usage times, supporting profiling and tailored attacks,,,,.Source: A. Metadata Privacy Concerns · p. 16

B. MDS3 Violation Analysis

  • MDS3 lets relying parties assess authenticator certification, security features, and known vulnerabilities, but virtual authenticators can spoof AAGUIDs and masquerade as certified hardware.This can evade relying-party authenticator policies and invalidate the assumption that an AAGUID identifies a specific hardware and firmware combination.Source: B. MDS3 Violation Analysis · p. 16
  • A virtual authenticator can mediate traffic from a legitimate verified authenticator, potentially circumventing relying-party access policies and obscuring which authenticator was used.If MDS3 information is inaccurate, relying parties may face a choice between restrictive policies with poorer user experience and permissive policies accepting authenticators of unknown quality.Source: B. MDS3 Violation Analysis · pp. 16–17
  • Defending MDS3 is constrained by forgery assumptions that relying parties must enforce, sophisticated distribution-pipeline threats, performance costs from strict attestation, and unupgradable older authenticators.The authors characterize MDS3 as both a source of risk-reducing information and an expansion of the attack surface.Source: B. MDS3 Violation Analysis · p. 17
  • The paper classifies attacker capabilities by privilege level, technical sophistication, and required resources to support risk modeling and mitigation prioritization.The capability framework spans user, administrator/root, physical-access, and supply-chain/manufacturer privilege, and software through specialized hardware resources.Source: B. MDS3 Violation Analysis · p. 17

X. Conclusion

Eight attack vectors expose assumptions behind FIDO2 security, and metadata leakage, environmental compromise, and interception can undermine intended protections. Chaining attacks across layers reinforces the need for defenses that address multiple vulnerabilities.

X. Conclusion

  • Eight vectors—extensions, platform malware, wiretapping, virtual devices, CTAP malware, USB implants and hubs, and NFC relay—challenge assumptions underpinning FIDO2 security.Source: §X · p. 17
  • Side-channel metadata can expose credentials, AAGUIDs, and authentication-activity fingerprints; malware can control authenticator functionality, while pre- and post-cryptographic interception defeats phishing resistance.Source: §X · p. 17
  • Combining attack vectors can enable stronger attacks, motivating defenses that address vulnerabilities across multiple layers.Source: §X · p. 17
  • FIDO2 remains better than passwords, but effective protection requires understanding its boundaries and developing mitigations for the identified vulnerabilities.Source: §X · p. 17
Loading 2609.03789v1…