Cardauth Solutions LLC v. Yubico Inc

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: CardAuth Solutions LLC (Texas)
  • Defendant: Yubico, Inc. (Delaware)
  • Plaintiff's Counsel: Bradford Black P.C.
• Case Identification: 4:26-cv-03576, N.D. Cal., 07/24/2026
• Venue Allegations: Venue is alleged to be proper in the Northern District of California because the defendant maintains a regular and established place of business in the district and has committed alleged acts of infringement there.
• Core Dispute: Plaintiff alleges that Defendant's YubiKey hardware security keys, when performing FIDO U2F/CTAP1 authentication, infringe a patent related to securely managing and delivering cryptographic keys to an authentication device.
• Technical Context: The technology concerns hardware security tokens used for multi-factor authentication, a foundational practice in modern cybersecurity for securing access to digital accounts and resources.
• Key Procedural History: The complaint makes arguments based on the patent's prosecution history, noting that language central to the asserted claim was added via an Examiner's Amendment following an RCE to distinguish prior art. The complaint also alleges that Defendant had pre-suit knowledge of the patent and its alleged infringement based on a notice letter sent approximately five months before the filing of the suit.

Case Timeline

Date	Event
2008-10-21	Priority Date for U.S. Patent No. 8,689,013
2014-04-01	Issue Date for U.S. Patent No. 8,689,013
2026-02-05	Plaintiff allegedly sent notice letter to Defendant
2026-07-24	Complaint Filing Date

II. Technology and Patent(s)-in-Suit Analysis

U.S. Patent No. 8,689,013 - "Dual-Interface Key Management"

• Patent Identification: U.S. Patent No. 8,689,013 ("the '013 Patent"), titled "Dual-Interface Key Management", issued on April 1, 2014.

The Invention Explained

• Problem Addressed: The patent addresses challenges in securely updating cryptographic keys on portable authentication devices like smart cards Compl. ¶¶8-9 Traditional methods required an intermediate computer (e.g., a user's PC) to have specialized, trusted software to receive, decrypt, and manage keys, creating "design, deployment, maintenance, and security burdens" Compl. ¶9 '013 Patent, col. 13:30-51 This architecture exposed sensitive key-management operations on the potentially insecure intermediate computer Compl. ¶9
• The Patented Solution: The patent proposes a "conduit approach" where the intermediate computer simply passes communications from a remote server to the access card without needing to process the sensitive payload Compl. ¶10 The invention embeds the encrypted key-management information within what appears to be a standard challenge message for an authentication protocol Compl. ¶11 '013 Patent, col. 15:22-36 The access card itself receives this "payload-bearing challenge data," decrypts it to recover the new key information, stores the new key, and then processes the challenge portion to complete the authentication protocol Compl. ¶12
• Technical Importance: This design enhances security by ensuring encrypted key-management data is only decrypted within the secure hardware of the access card, while simplifying deployment by reducing the need for specialized, trusted software on host computers (Compl. ¶10, Compl. ¶12; '013 Patent, Compl. ¶¶col. 14:12-24).

Key Claims at a Glance

• The complaint asserts direct and indirect infringement of at least Claim 28 of the '013 Patent Compl. ¶28 Compl. ¶29
• Independent Claim 28, an apparatus claim directed to an "access card," requires, in essence:
  • A processor configured to receive "challenge data" according to an authentication protocol, where this data is received "in lieu of a challenge".
  • The "challenge data" itself comprises "encrypted key-management information".
  • The processor is configured to obtain the "key-management information" by decrypting the "encrypted key-management information" from the "challenge data".
  • The processor is configured to "store" the recovered "key-management information" in the access card's memory.
  • The processor is also configured to process the "challenge" to generate an authentication "response".

III. The Accused Instrumentality

Product Identification

The complaint identifies the "Accused Instrumentalities" as the "YubiKey 5 FIPS 140-2 Series" of hardware authentication tokens, particularly those with specific firmware versions (5.4.2 or 5.4.3), when using their FIDO U2F/CTAP1 authentication functionality Compl. ¶21 A screenshot from Defendant's product webpage is included to identify an exemplary product, the YubiKey 5 NFC FIPS (140-2) Compl. p. 8

Functionality and Market Context

• The accused products are described as portable hardware tokens used for controlling logical access to digital resources Compl. ¶22 The relevant functionality is the FIDO U2F authentication process. In this process, a relying party (e.g., a website) issues a challenge. A client (e.g., a web browser) constructs a U2F Authenticate request message, which includes a challenge parameter and a "key handle," and sends this message to the YubiKey Compl. ¶23
• The complaint alleges, based on Defendant's own documentation, that the key handle is an encrypted data structure containing a private key specific to the user's registration with the relying party Compl. ¶25 The YubiKey allegedly decrypts this key handle to "re-form the private key," which is then used to sign the challenge parameter, generating a response that proves possession of the key Compl. ¶¶24-25

IV. Analysis of Infringement Allegations

'013 Patent Infringement Allegations

Claim Element (from Independent Claim 28)	Alleged Infringing Functionality	Complaint Citation	Patent Citation
An access card comprising: an interface; a memory; and a processor...	The YubiKey is a portable hardware token containing an interface (USB/NFC), internal memory, and a processor.	¶22	col. 2:23-25
receive challenge data, according to an authentication protocol... wherein the challenge data is received in lieu of a challenge...	The YubiKey receives a structured U2F Authenticate request message, which the complaint alleges is the "challenge data". This is received in place of a "bare challenge." A screenshot shows this message structure. Compl. p. 11	¶23	col. 15:9-13
the challenge data comprises encrypted key-management information	The U2F Authenticate request message contains a "key handle" field. The complaint alleges this field is the "encrypted key-management information", citing Yubico documentation stating the key handle is the private key encrypted with a device-specific master key. A screenshot details this process. Compl. p. 15	¶25	col. 15:22-26
obtain key-management information... by decrypting the encrypted key-management information	During authentication, the YubiKey receives the key handle and decrypts it to "re-form the private key needed to sign the challenge."	¶25	col. 2:25-34
store the key-management information in the memory of the access card	The complaint alleges the recovered private key "resides at least transiently in the YubiKey's internal memory" (e.g., RAM) during the signature operation, citing a FIPS security policy table identifying storage as "Plaintext in Flash or RAM." Compl. p. 17	¶26	col. 2:27-29
process the challenge to generate the authentication response	The YubiKey processes the "challenge parameter" from the U2F Authenticate request message by cryptographically signing it with the recovered private key to generate the response.	¶24	col. 2:30-32

• Identified Points of Contention:
  • Scope Question: A central issue may be whether the term "challenge data", as defined in the patent, can be construed to read on the standardized FIDO U2F Authenticate request message. The complaint argues the U2F message is a "richer, payload-bearing" message received "in place of a separate bare challenge" Compl. ¶14, while a defense may argue the message is not "in lieu of" a challenge but rather contains a challenge.
  • Scope Question: The analysis will likely focus on whether the FIDO U2F "key handle" constitutes "encrypted key-management information" within the meaning of the patent. While the complaint provides evidence from Defendant's documents that the key handle is an encrypted private key Compl. ¶25, a defense could argue it is merely an opaque identifier whose specific implementation differs from the "key management" contemplated by the patent's embodiments.
  • Technical Question: A potential point of dispute is whether the YubiKey's alleged transient use of the decrypted private key in RAM during a signing operation satisfies the claim element to "store" the key-management information in "memory". The interpretation of "store" and "memory" in the context of the patent will be a likely focus.

V. Key Claim Terms for Construction

• The Term: "challenge data"

  • Context and Importance: The infringement theory depends on equating the FIDO U2F Authenticate request message with the patent's "challenge data". The complaint distinguishes "challenge data" (the entire payload-bearing message) from "challenge" (the random number within it) Compl. ¶14 The construction of this term is fundamental to determining if the accused protocol falls within the claim scope.
  • Intrinsic Evidence for a Broader Interpretation: The specification suggests "challenge data" can be part of a complex protocol, stating that challenge strings in a challenge-response PKI protocol can serve as "vehicles for carrying the key-management information" Compl. ¶11 '013 Patent, col. 2:17-22
  • Intrinsic Evidence for a Narrower Interpretation: The specification also states that "challenge data" "can consist of or include, for example, a large random number" '013 Patent, col. 19:15-19, which could be used to argue for a simpler structure than the multi-field FIDO message.

• The Term: "encrypted key-management information"

  • Context and Importance: Plaintiff's infringement case hinges on the accused "key handle" being "encrypted key-management information" Compl. ¶25 Practitioners may focus on this term because its definition will determine whether the core of the YubiKey's security model is captured by the claim.
  • Intrinsic Evidence for a Broader Interpretation: The patent provides a broad, functional definition, stating it "includes a key that is to be used in making access requests" '013 Patent, col. 2:6-7 and can be "an encrypted version of the short-term access keys, or other key-management information" '013 Patent, col. 15:22-26
  • Intrinsic Evidence for a Narrower Interpretation: A party could argue that the patent's examples, which focus on keys for physical or logical access in a "dual-interface" system for loading keys, imply a narrower context than the wrapped private key used in the standardized, single-purpose FIDO U2F authentication flow.

VI. Other Allegations

• Indirect Infringement: The complaint alleges active inducement of infringement under 35 U.S.C. § 271(b). The basis for this allegation is that Yubico provides "product documentation, developer materials, support materials, and instructions" that describe and encourage customers and end users to use the Accused Instrumentalities in the allegedly infringing manner (i.e., performing FIDO U2F authentication) Compl. ¶31
• Willful Infringement: The complaint alleges willful infringement based on Yubico's alleged continued infringement after receiving notice. It states that Yubico had knowledge of the '013 Patent and its alleged infringement since "at least February 5, 2026," but continued to make, sell, and support the accused products and functionality Compl. ¶¶30, 32-33

VII. Analyst's Conclusion: Key Questions for the Case

This case will likely depend on the outcomes of several key questions regarding claim interpretation and technical application.

• A core issue will be one of definitional scope: Can the patent's terminology, developed in the context of managing keys for proprietary access cards (e.g., "challenge data", "encrypted key-management information"), be construed to cover the distinct, standardized components of the open FIDO U2F protocol (e.g., "Authenticate message", "key handle")? The outcome will likely depend on how the court interprets evidence from the patent's specification and prosecution history.
• A second key question will be one of technical mapping: Does the accused YubiKey's internal operation-specifically, decrypting a "key handle" to transiently use a private key in RAM for a signing operation-satisfy the claim requirements to "obtain... by decrypting" and then "store" the key-management information in "memory" as those terms are understood in the context of the '013 Patent? The court will need to resolve potential mismatches between the patent's description and the accused device's actual function.