1:17-cv-00737
Cryptopeak Security LLC v. Abercrombie & Fitch Co
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: CryptoPeak Security, LLC (Delaware)
- Defendant: Abercrombie & Fitch Co. (Delaware)
- Plaintiff’s Counsel: Devlin Law Firm LLC
- Case Identification: 1:17-cv-00737, D. Del., 06/13/2017
- Venue Allegations: Venue is alleged to be proper in the District of Delaware because the Defendant is a Delaware corporation.
- Core Dispute: Plaintiff alleges that Defendant’s servers, by using certain standard internet encryption protocols (TLS 1.2 with ECDHE ciphersuites), infringe a patent related to methods for generating and verifying escrowed cryptographic keys.
- Technical Context: The lawsuit concerns the foundational cryptographic protocols used to secure a vast range of internet communications, including e-commerce websites.
- Key Procedural History: The complaint notes that the patent-in-suit, U.S. Patent No. 6,202,150, was previously asserted in the Eastern District of Texas against other defendants. In that prior litigation, the court reportedly denied motions to dismiss challenging the patent’s validity under 35 U.S.C. §§ 101 and 112, holding that the asserted claims recite a method rather than an impermissible mix of method and apparatus.
Case Timeline
| Date | Event |
|---|---|
| 1997-05-28 | U.S. Patent No. 6,202,150 Priority Date |
| 2001-03-13 | U.S. Patent No. 6,202,150 Issue Date |
| 2006-05-01 | RFC 4492 (ECC Cipher Suites for TLS) Published |
| 2008-08-01 | RFC 5246 (TLS Protocol Version 1.2) Published |
| 2017-06-13 | Complaint Filing Date |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 6,202,150: "Auto-Escrowable And Auto-Certifiable Cryptosystems" (Issued Mar. 13, 2001)
The Invention Explained
- Problem Addressed: The patent describes a tension in public key cryptography between the need for user privacy and the desire of law enforcement or organizations to access encrypted data through "key escrow" systems. It notes that prior key escrow systems could be inefficient, require special trusted hardware, or be vulnerable to the creation of covert, unescrowed "shadow public key systems" by sophisticated users. (ʼ150 Patent, col. 2:42-50; col. 3:5-14).
- The Patented Solution: The invention proposes a method where a user's system generates a public/private key pair along with a "certificate of recoverability." This certificate is a publicly available string of information that serves as a proof that the corresponding private key was generated correctly and is recoverable by escrow authorities. Critically, this proof can be verified by any third party (e.g., a Certification Authority) without needing access to the private key itself, thereby ensuring that only properly escrowed keys are certified and used. (ʼ150 Patent, Abstract; col. 5:15-38).
- Technical Importance: The described approach sought to create a key escrow system that could be implemented in software, be publicly verifiable to build trust, and integrate into existing public key infrastructures without significant protocol overhead. (ʼ150 Patent, col. 4:16-37).
Key Claims at a Glance
- The complaint asserts independent claims 1 and 3. (Compl. ¶¶25, 41).
- Independent Claim 1 recites a method for generating public keys and a proof, with the key steps being:
- a user's system generating a random string of bits based on system parameters;
- the user running a key generation algorithm to get a secret key and public key using the random string and public parameters;
- the user constructing a proof (a string of bits) whose public availability does not compromise the secret key, requires access to the secret key to construct, but provides confidence to other entities that the public key was generated properly by the specified algorithm.
- Independent Claim 3 recites a method for publishing public keys and a proof, with the key steps being:
- the user's system reading the system parameters;
- the user's system running a key generation algorithm to get a private key and public key;
- the user's system constructing a proof that the private key was generated properly, where constructing the proof requires access to the private key but verification of the proof does not.
- The complaint does not explicitly reserve the right to assert dependent claims.
III. The Accused Instrumentality
Product Identification
The "Accused Instrumentalities" are identified as computer servers operated by Abercrombie & Fitch, such as those hosting www.abercrombie.com, that use specific Elliptic Curve Cryptography (ECC) ciphersuites for secure communications. (Compl. ¶¶25-26, 29).
Functionality and Market Context
- The accused functionality is the implementation of the Transport Layer Security (TLS) protocol version 1.2, specifically using ciphersuites that employ Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange. (Compl. ¶¶25, 29). These protocols are used to establish a secure, encrypted channel between a user's web browser and the Defendant's servers for activities like online shopping. (Compl. ¶29).
- The complaint presents a screenshot from a third-party server testing tool that lists the specific ciphersuites supported by the Defendant's servers, highlighting those beginning with "TLS_ECDHE" as the basis for infringement. This list of supported ciphersuites is presented as evidence of the accused functionality. (Compl. ¶25, p. 6).
IV. Analysis of Infringement Allegations
’150 Patent Infringement Allegations (Claim 1)
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| a method for generating public keys and a proof that the keys were generated by a specific algorithm comprising the steps of: the user's system generating a random string of bits based on system parameters; | The Accused Instrumentalities (servers) generate random values ("ServerHello.random") during the TLS 1.2 handshake, allegedly using system parameters like hardware timers as described in relevant technical standards (RFCs). | ¶¶31-33; Fig. 1-4 | col. 13:25-29 |
| the user running a key generation algorithm to get a secret key and public key using the random string and public parameters; | During the TLS handshake, the server allegedly uses the random values and public parameters (e.g., elliptic curve definitions) to generate a "master secret" (the secret key) and a "premaster secret" (related to the public key). | ¶¶34-35; Fig. 5-10 | col. 13:30-34 |
| the user constructing a proof being a string of bits whose public availability does not compromise the secret key and wherein said constructing of said proof requires access to said secret key, but at the same time said proof provides confidence to at least one of a plurality of other entities that said public key was generated properly... | The server constructs and sends a "Finished" message during the TLS handshake. The complaint alleges this message serves as the "proof," as its creation depends on the "master secret," but its verification by the client confirms the key exchange was successful without revealing the secret key itself. | ¶¶36-40; Fig. 11-12 | col. 13:35-42 |
’150 Patent Infringement Allegations (Claim 3)
| Claim Element (from Independent Claim 3) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| A method...for publishing public keys and a proof that the keys were generated by a specific algorithm comprising the steps of: the user's system reading the system parameters; | During the TLS 1.2 handshake, the server and client exchange messages ("ClientHello", "ServerHello") that establish cryptographic parameters, which the complaint alleges constitutes "reading the system parameters." | ¶¶46-48; Fig. 13-14 | col. 13:66 |
| the user's system running a key generation algorithm to get a private key and public key; | The server allegedly runs an algorithm to generate a "master secret" (private key) from a "premaster secret" (public key) and other exchanged values during the TLS handshake. | ¶¶49-50; Fig. 15-19 | col. 14:1-2 |
| the user's system constructing a proof that the private key was generated properly using the system parameters, and where said constructing of said proof requires access to said private key and verification of said proof can be performed by any other entity with no access to any portion of said private key. | The server sends a "Finished" message, which the complaint alleges is the "proof." The message's contents are derived from the "master secret" (private key), and its verification by the client allegedly confirms proper key generation without revealing the key. | ¶¶51-54; Fig. 20-22 | col. 14:3-9 |
- Identified Points of Contention:
- Scope Questions: A central question will be whether the claim term "proof," which the patent describes as a "certificate of recoverability" involving non-interactive zero-knowledge proofs, can be interpreted to read on the standardized "Finished" message of the TLS protocol. The complaint describes the verification of the "Finished" message as proof of proper key generation. (Compl. ¶38, ¶53).
- Technical Questions: The patent appears to describe a system for generating and escrowing persistent, certified public keys. The accused ECDHE ciphersuites, however, are specifically designed to use ephemeral (single-session) keys to provide "forward secrecy," a concept intended to prevent later decryption even if a server's long-term private key is compromised. A potential dispute is whether the patent's method for escrowing a user's key is technically congruent with a protocol designed to ensure keys are temporary and cannot be recovered later.
V. Key Claim Terms for Construction
The Term: "proof"
Context and Importance: This term is the lynchpin of the infringement allegation. The complaint equates the TLS protocol's "Finished" message with the "proof" required by the claims (Compl. ¶38). The patent, however, describes this "proof" as a "certificate of recoverability" that establishes a private key is escrowed and recoverable by authorities. Practitioners may focus on whether the function and structure of a TLS "Finished" message (a hash digest for handshake integrity) is the same as the patent's "certificate of recoverability" (a non-interactive zero-knowledge proof of escrow).
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: Claim 1 describes the proof broadly as "a string of bits" that "provides confidence...that said public key was generated properly by the specified algorithm" without compromising the secret key (ʼ150 Patent, col. 13:35-42). This functional language could arguably encompass any cryptographic message that serves a verification purpose.
- Evidence for a Narrower Interpretation: The detailed description repeatedly links the proof to a "certificate of recoverability" and explains its construction using "three non-interactive zero-knowledge proofs" ('150 Patent, col. 7:10-15). The summary of the invention states the system is for verifying "that a user generated private key is contained within an encryption under the public key of the escrow authorities" ('150 Patent, col. 5:2-5). This suggests a more specific structure and purpose tied to key escrow, not just session integrity.
The Term: "secret key" / "private key"
Context and Importance: The claims require the generation of a secret/private key that is then subject to the "proof." The complaint maps "secret key" to the TLS "master_secret" (Compl. ¶38). The viability of this mapping is critical, as the patent appears to contemplate a persistent user key pair, whereas the master secret in an ECDHE session is ephemeral.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The claims themselves do not explicitly require the key to be persistent or long-term. Claim 1 refers to "a secret key and public key" in general terms ('150 Patent, col. 13:31-32), which could potentially cover session-based keys.
- Evidence for a Narrower Interpretation: The patent's background and summary are framed around solving problems with Public Key Infrastructure (PKI) and providing a mechanism for law enforcement to recover keys, contexts which typically involve long-term, identity-linked keys rather than ephemeral session keys ('150 Patent, col. 2:13-28; col. 4:40-48).
VI. Other Allegations
- Indirect Infringement: The complaint does not allege facts to support claims for either induced or contributory infringement.
- Willful Infringement: The complaint does not contain an explicit count for willful infringement or allege facts such as pre-suit knowledge of the patent. However, the prayer for relief requests a declaration that the case is "exceptional under 35 U.S.C. § 285," which is the statutory basis for awarding attorney's fees, often in cases of willful infringement or litigation misconduct. (Compl., p. 23).
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of definitional scope: Can the term "proof," as defined and described in the ʼ150 patent with specific ties to a "certificate of recoverability" and zero-knowledge proofs for key escrow, be construed to cover the standardized "Finished" message in the TLS 1.2 protocol, whose primary purpose is to verify the integrity of the handshake?
- A second central issue will be one of technical congruence: Does the patent’s system for generating and escrowing what appear to be persistent user keys map onto the accused TLS_ECDHE protocol, which is specifically designed to use ephemeral (temporary) keys to achieve forward secrecy and prevent long-term key recovery?
- A key procedural question will be the impact of prior litigation: To what extent will the court be influenced by the prior E.D. Texas ruling that denied early-stage validity challenges, and will the arguments that were unsuccessful at the pleading stage in that case re-emerge with more force during claim construction and summary judgment in this proceeding?