CTRAPS-CTAP Impersonation, API Confusion Attacks on FIDO2

CTRAPS: CTAP Impersonation and API Confusion Attacks on FIDO2

Speakers: Marco Casagrande, Daniele Antonioli

Conference: DEF CON 33

YouTube: https://www.youtube.com/watch?v=WZChYxX5i_I

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/Marco%20Casagrande%20Daniele%20Antonioli%20-%20CTRAPS%20CTAP%20Impersonation%20and%20API%20Confusion%20Attacks%20on%20FIDO2.pdf

Overview

FIDO2 is the current gold standard for phishing-resistant multi-factor and passwordless authentication, deployed by major platform vendors and recommended by CISA, NIST, and enterprise security guidance everywhere. Hardware security keys (YubiKey, Google Titan, Apple Passkeys on platform authenticators) rely on the CTAP (Client to Authenticator Protocol) to communicate between the authenticator device and the host platform. This talk — based on a 2025 EuroS&P research paper — presents CTRAPS: a systematic attack framework targeting the CTAP protocol layer that produces client impersonation attacks and API confusion man-in-the-middle attacks against FIDO2.

Marco Casagrande (a postdoc at KTH Sweden) and Daniele Antonioli (assistant professor at EURECOM, France) demonstrate that the CTAP protocol — despite securing authentication — contains design-level vulnerabilities that allow a malicious or compromised host to impersonate legitimate authenticator clients, confuse the authenticator about the context of an operation, and in certain conditions execute man-in-the-middle attacks that undermine the phishing-resistance guarantees that FIDO2 is specifically designed to provide.

The research involved responsible disclosure to the FIDO Alliance, the standards body that governs FIDO2 and CTAP. The talk includes a discussion of how the FIDO Alliance responded to the findings and what countermeasures were proposed or implemented.

Background

▶ Watch: CTAP authenticator impersonation attacks (0:07)

FIDO2 Architecture

FIDO2 consists of two main components:

• WebAuthn — a W3C standard defining the browser-to-website API for authentication using public key cryptography
• CTAP (Client to Authenticator Protocol) — the FIDO Alliance standard defining communication between the authenticating platform (browser/OS) and the authenticator (security key or platform authenticator)

The authentication model is:

1. A website sends a challenge to the browser via WebAuthn
2. The browser's platform (OS/CTAP layer) forwards the challenge to the authenticator via CTAP
3. The authenticator signs the challenge with its private key and returns the signed assertion
4. The browser returns the signed assertion to the website
5. The website verifies the signature against the registered public key

FIDO2's phishing-resistance guarantee comes from the fact that the authenticator cryptographically binds its response to the requesting origin (website domain), making it impossible to phish credentials in the traditional sense — even if a user is tricked into entering credentials on a phishing site, the signed assertion cannot be used on the real site.

CTAP Protocol Details

CTAP (currently CTAP 2.1) defines the message format and transport for authenticator communication. Transports include USB-HID, Bluetooth, NFC, and the platform's internal API for platform authenticators (e.g., Windows Hello, Apple's Passkeys). The protocol includes:

• CTAP2 commands — authenticatorMakeCredential, authenticatorGetAssertion, authenticatorClientPIN, and others
• PIN/UV auth protocols — cryptographic protocols for user verification without transmitting the PIN in the clear
• Authenticator configuration — commands for managing authenticator settings, biometric templates, and resident credentials

The threat model for CTAP assumes that the client platform (the OS/browser that relays CTAP messages) is trusted. The attacks in this paper challenge that assumption and demonstrate what becomes possible when the client platform is malicious or compromised.

Key Findings

▶ Watch: Live demonstration of CTAP impersonation attack (1:59)

Client Impersonation Attacks

CTAP lacks a strong authentication mechanism for the client side of the protocol — i.e., the host platform communicating with the authenticator. While the authenticator proves its identity through cryptographic attestation (during credential creation) and through signed assertions (during authentication), the client does not prove its identity to the authenticator.

This asymmetry means that any software running on the host — including malware — can send valid CTAP commands to a connected authenticator. In the impersonation attacks, a malicious client:

1. Intercepts the legitimate WebAuthn request from the browser
2. Modifies parameters (e.g., the RP ID — the relying party identifier — or the UV requirement)
3. Forwards a modified CTAP request to the authenticator
4. Receives the authenticator's response and uses it in a way that differs from what the user intended

This can enable, for example, an attacker who has malware on the victim's machine to generate a signed CTAP assertion for a target website by hijacking a legitimate authentication attempt and redirecting it to their chosen RP ID.

API Confusion Attacks

The API confusion attacks exploit ambiguity in how CTAP commands are interpreted depending on context. Different CTAP commands share some parameter structures, and the authenticator does not always have sufficient context to distinguish between a legitimate invocation of one command and a manipulated invocation that reuses data from another command in an unexpected way.

Casagrande demonstrates a specific API confusion attack where the attacker abuses the handling of the allowList parameter in authenticatorGetAssertion. By crafting a request that appears to be a legitimate GetAssertion call but specifies credential descriptors that the authenticator interprets differently from what the browser's WebAuthn layer intended, the attacker can induce the authenticator to perform an assertion for a credential that was not the one the relying party intended to use.

This is a subtle but important attack: it does not require the attacker to have the authenticator's private key, but it allows the attacker to confuse the binding between a credential and the relying party context in which it is used.

Man-in-the-Middle Attacks

The most serious findings are the man-in-the-middle attacks that, under certain transport and configuration conditions, allow an attacker positioned between the client and the authenticator to intercept and modify CTAP messages in transit.

CTAP over USB-HID and Bluetooth does not mandate end-to-end encryption between the client and the authenticator (PIN/UV auth protocols provide some protection but are not applied to all message types). An attacker who can intercept the transport layer — for example, via a malicious USB hub or a malicious Bluetooth proxy — can modify CTAP messages in transit.

The team demonstrates a concrete MitM attack using a hardware proxy: a device placed between a YubiKey and a USB host that intercepts and modifies CTAP HID reports. This allowed the attacker to change the effective RP ID in an authentication request, potentially redirecting a FIDO2 authentication for Site A to produce a credential assertion usable at Site B (if the credential was registered with an RP ID that can be manipulated at the CTAP level before the authenticator's cryptographic binding takes effect).

This attack scenario — while requiring physical access or a compromised USB stack in the current form — demonstrates a class of vulnerability in the CTAP protocol design that should be addressed in future versions.

CTRAPS Toolkit

The researchers developed CTRAPS, an open-source toolkit implementing all of the attacks described in the paper. CTRAPS provides:

• A CTAP protocol fuzzer for discovering new vulnerabilities in authenticator firmware
• Attack modules for each of the described attack classes (impersonation, API confusion, MitM)
• Transport plugins supporting USB-HID, Bluetooth, and NFC
• Integration with existing WebAuthn/CTAP testing frameworks

The toolkit is released open-source following responsible disclosure, enabling other researchers to build on the work.

Technical Deep Dive

▶ Watch: Protocol specification flaws enabling these attacks (6:25)

CTAP Message Structure

A authenticatorGetAssertion request contains:

• rpId — the relying party identifier (a domain string)
• clientDataHash — SHA-256 of the WebAuthn CollectedClientData (includes the origin and the challenge)
• allowList — list of credential descriptors specifying which credentials may be used
• options — authentication options (user presence, user verification)
• pinUvAuthParam — PIN/UV authentication parameter (if user verification is required)

The client impersonation attack targets the gap between what the browser's WebAuthn layer put in the original request and what the malicious CTAP client forwards to the authenticator. Since the authenticator signs the clientDataHash (not the original WebAuthn request), and since the clientDataHash is computed by the client before being sent to the authenticator, a malicious client can supply a clientDataHash that corresponds to a different origin than the browser's actual origin.

PIN/UV Authentication Protocol Weaknesses

The PIN/UV authentication protocols (CTAP 2.0 pin protocol 1 and CTAP 2.1 pin protocol 2) are designed to allow user verification without sending the PIN to the authenticator in plaintext. However, the protocols rely on a shared secret established during a PIN-set or PIN-change operation, and the impersonation attacks show that a malicious client that has observed previous PIN/UV exchanges can derive the shared secret (or can manipulate the PIN/UV protocol flow to produce auth params that the authenticator accepts for unintended operations).

Transport Layer Analysis

The USB-HID transport for CTAP does not provide channel encryption or authenticator-to-client authentication. The CTAP spec includes a channel ID (CIDO) mechanism for USB-HID that provides some replay protection, but does not prevent a hardware-level interceptor from modifying individual HID reports. The Bluetooth transport nominally relies on Bluetooth security (pairing), but the researchers demonstrate that Bluetooth's security model is insufficient to prevent a dedicated proxying attack.

Vulnerable Authenticators and Scope

The research was tested against multiple production FIDO2 authenticators including YubiKey devices (multiple generations), Google Titan keys, and platform authenticators (Windows Hello, Apple platform authenticators). The vulnerability scope varies by device and transport: platform authenticators are less susceptible to the transport-layer MitM but are still vulnerable to the client impersonation attacks (since the malicious code runs on the same platform).

Demo / Proof of Concept

▶ Watch: Authentication bypass achieved via API confusion (10:58)

Casagrande demonstrates multiple attacks live:

1. Client impersonation demo: A malicious CTAP client running on the victim's machine intercepts a WebAuthn authentication request for bank.example.com, substitutes the RP ID with attacker.example.com, and receives a signed assertion from the authenticator — demonstrating that the authenticator cannot distinguish between legitimate and malicious clients.
2. API confusion demo: An API confusion request causes the authenticator to return an assertion for an unintended credential.
3. USB MitM demo: A hardware proxy device intercepts CTAP HID reports between a YubiKey and a USB host, modifies the RP ID, and successfully receives an authenticator response for the modified request.

Defensive Implications

▶ Watch: CVE disclosures for FIDO2 implementation vulnerabilities (44:22)

For end users and IT administrators:

• The attacks described require either a compromised host or physical access (for transport-layer MitM). Keeping host endpoints secure — patched, EDR-protected, without unauthorized software — remains the primary mitigation.
• Platform authenticators (Windows Hello, Apple Passkeys stored in Secure Enclave) are more resistant to transport-layer MitM than hardware keys used via USB or Bluetooth, because the CTAP communication is internal to the platform's trusted execution environment.
• Be aware that even FIDO2 security keys do not protect against a fully compromised endpoint — the threat model for CTAP explicitly trusts the host.

For FIDO Alliance and authenticator vendors:

• The responsible disclosure process resulted in the FIDO Alliance acknowledging the findings and discussing mitigations in the CTAP 2.2 and future versions
• Proposed countermeasures include: mandatory channel binding between the transport layer and the CTAP session, stronger client attestation mechanisms, and clarification of the RP ID binding semantics in the spec
• Authenticator vendors should review their implementations against the CTRAPS attack modules and the paper's findings

For WebAuthn relying parties:

• Implement attestation verification during credential registration to ensure that authenticators used in your deployment meet a minimum security standard
• Consider requiring hardware-backed platform authenticators (not roaming authenticators) for high-value accounts where endpoint compromise is a concern

Key Takeaways

• CTAP, the protocol underlying FIDO2 hardware security key authentication, contains design-level vulnerabilities that allow client impersonation, API confusion, and under certain conditions transport-layer man-in-the-middle attacks.
• These attacks can undermine FIDO2's phishing-resistance guarantees in scenarios where the host platform is compromised or an attacker has physical access to insert a hardware proxy on the USB/Bluetooth transport.
• The CTRAPS open-source toolkit implements all described attacks and is available for further research and testing.
• Responsible disclosure to the FIDO Alliance was completed prior to the talk, and the findings are informing CTAP protocol evolution.
• Defenders should prioritize endpoint security alongside FIDO2 deployment, as a compromised host negates key CTAP security properties.

About the Speakers

Marco Casagrande is a postdoctoral researcher at KTH Royal Institute of Technology in Sweden. His research focuses on security and privacy of IoT devices, authenticators, and wireless protocols including Bluetooth, NFC, and Wi-Fi. He conducted this research during his PhD at EURECOM in France under the supervision of Daniele Antonioli.

Daniele Antonioli is an Assistant Professor at EURECOM, a university and research center located in Sophia Antipolis in southern France. His research group works on security and privacy across Bluetooth, FIDO2, electric scooters, web tracking, and other domains. He is the PhD supervisor of Marco Casagrande and principal investigator of the CTRAPS project.