Cryptopeak Security LLC v. MGM Resorts Intl

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: CryptoPeak Security, LLC (Delaware)
  • Defendant: MGM Resorts International (Delaware)
  • Plaintiff’s Counsel: Devlin Law Firm LLC
• Case Identification: 1:17-cv-00745, D. Del., 06/13/2017
• Venue Allegations: Venue is alleged to be proper in the District of Delaware because the Defendant is a corporation incorporated in the State of Delaware.
• Core Dispute: Plaintiff alleges that Defendant’s servers, by using standard Elliptic Curve Cryptography protocols for secure web communications, infringe a patent related to methods for generating and verifying cryptographic keys in a way that ensures they are recoverable by an escrow authority.
• Technical Context: The lawsuit concerns the foundational technology of secure internet connections (TLS/SSL), specifically the Diffie-Hellman key exchange process using elliptic curve cryptography (ECDHE), which is used ubiquitously to protect online data transmission.
• Key Procedural History: The complaint notes that the patent-in-suit was previously asserted against multiple defendants in the Eastern District of Texas starting in 2015. In that prior litigation, the court denied defendants' motion to dismiss, which had argued the patent claims were invalid under 35 U.S.C. §101 and indefinite under §112. This prior ruling, while not binding, suggests the patent has survived an initial validity challenge.

Case Timeline

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

U.S. Patent No. 6,202,150 - “Auto-Escrowable And Auto-Certifiable Cryptosystems,” issued March 13, 2001

The Invention Explained

• Problem Addressed: The patent addresses the tension between the need for strong encryption for private communications and law enforcement's need to access communications of criminal suspects. It notes that prior key escrow systems suffered from drawbacks such as requiring trusted hardware, creating protocol overhead, or being vulnerable to "shadow" cryptosystems that allow users to secretly bypass the escrow mechanism (’150 Patent, col. 3:5-17; col. 4:7-17).
• The Patented Solution: The invention describes a cryptographic method where a user generates a key pair along with a "certificate of recoverability." This certificate is a publicly verifiable proof that the key was generated using an algorithm that makes the private key recoverable by escrow authorities. A key feature is that anyone can perform this verification without access to the private key itself, making the system "auto-certifiable" and removing the need for a single, trusted entity to perform all verifications (’150 Patent, Abstract; col. 5:1-9).
• Technical Importance: The technology proposed a software-based solution to the contentious "crypto wars" debate of the 1990s by creating a system for key escrow that was designed to be publicly verifiable and resistant to certain known attacks (’150 Patent, col. 4:16-25).

Key Claims at a Glance

• The complaint asserts independent claims 1 and 3.
• 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; and
  • the user constructing a proof that requires the secret key to create, but whose verification does not require the secret key, and which provides confidence that the public key was generated properly by the specified algorithm.
• Independent Claim 3 recites a similar method for publishing public keys and a proof, with the key steps being:
  • a user's system reading system parameters;
  • running a key generation algorithm to get a private key and public key; and
  • constructing a proof that the private key was generated properly, where the proof requires the private key to create but can be verified by any entity without access to the private key.

III. The Accused Instrumentality

Product Identification

The "Accused Instrumentalities" are identified as computers or servers operated by Defendant MGM Resorts International that use specific Elliptic Curve Cryptography (ECC) ciphersuites for secure communications (Compl. ¶25). The complaint specifically identifies servers for "www.mgmgrand.com" as an example (Compl. ¶29).

Functionality and Market Context

The accused functionality is the implementation of the Transport Layer Security (TLS) version 1.2 protocol, specifically using ciphersuites that perform an Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange (Compl. ¶¶25, 29). This is a standard method used across the internet to establish a secure, encrypted session between a server and a client (such as a user's web browser). The complaint provides a screenshot from a public SSL testing tool showing that Defendant's servers support and prefer these "TLS_ECDHE" ciphersuites (Compl. ¶25, Fig. on p. 6). The complaint alleges that the steps of the TLS/ECDHE handshake process directly map to the steps of the methods claimed in the ’150 patent.

IV. Analysis of Infringement Allegations

’150 Patent Infringement Allegations (Claim 1)

’150 Patent Infringement Allegations (Claim 3)

Identified Points of Contention

• Scope Questions: A central dispute may arise over whether the terminology of the patent, which describes a purpose-built key escrow system, can be read onto the components of a standardized, general-purpose security protocol like TLS. For example, a court may need to decide if an ephemeral "master secret" generated for a single web session constitutes the "secret key" or "private key" contemplated by the patent, which the specification frames in the context of a user's key being registered in a Public Key Infrastructure (PKI) (’150 Patent, col. 9:19-25).
• Technical Questions: A key technical question is whether the TLS "Finished" message performs the same function as the claimed "proof." The complaint alleges the "Finished" message serves as a "proof that the... key was generated properly" (Compl. ¶¶38, 53). However, the function of the "Finished" message in the TLS standard is to verify that the key exchange and handshake process were not tampered with and that both parties calculated the same session keys. The question for the court will be whether this integrity-checking function is equivalent to the claimed function of proving that a key was generated by a specific "escrow-enabling" algorithm.

V. Key Claim Terms for Construction

The Term: "proof"

Context and Importance

The infringement theory hinges on equating the TLS "Finished" message with the patent's "proof." The definition of this term is therefore critical. Practitioners may focus on this term because if the TLS "Finished" message does not meet the definition of "proof," the entire infringement allegation may fail.

Intrinsic Evidence for Interpretation

• Evidence for a Broader Interpretation: The claims define "proof" functionally as a string of bits that "provides confidence... that said public key was generated properly" without compromising the secret key (Claim 1). Plaintiff may argue that any data structure meeting this functional description, like the TLS "Finished" message, falls within the claim scope.
• Evidence for a Narrower Interpretation: The specification describes the proof as a "certificate of recoverability" that includes three "non-interactive zero-knowledge proofs" (’150 Patent, col. 8:6-15). A defendant may argue that the term "proof" should be limited to this more complex cryptographic construct, not the hash-based message used in TLS.

The Term: "secret key" / "private key"

Context and Importance

The complaint alleges that the ephemeral "master secret" generated during a TLS handshake is the claimed "secret key." The patent, however, was written in the context of escrowing a user's primary keys for law enforcement access. The viability of the infringement claim may depend on whether a transient session key is considered a "secret key" under the patent.

Intrinsic Evidence for Interpretation

• Evidence for a Broader Interpretation: The claims themselves do not contain an explicit limitation requiring the "secret key" to be long-lived or permanently associated with a user identity. Plaintiff could argue that any secret value that fits the algorithmic role described in the claim qualifies.
• Evidence for a Narrower Interpretation: The patent’s background and detailed description discuss escrow systems in the context of a Public Key Infrastructure where "users certify their public keys" (’150 Patent, col. 4:45-48). This context suggests a more persistent key associated with a user identity, rather than an ephemeral key that exists only for the duration of a single, secure communication session.

VI. Other Allegations

Indirect Infringement

The complaint does not plead a count for indirect infringement and focuses its factual allegations on Defendant's direct infringement through the operation of its servers.

Willful Infringement

The complaint does not contain allegations to support a claim for willful infringement, such as pre-suit knowledge of the patent or infringement. The prayer for relief includes a request for a finding that the case is "exceptional" under 35 U.S.C. § 285, which relates to an award of attorneys' fees.

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

• A core issue will be one of definitional scope: can the terms "secret key" and "proof," as defined in a patent for a specific key escrow architecture, be construed to cover the functionally distinct and ephemeral components of a standard TLS/ECDHE handshake, such as the "master secret" and "Finished" message?
• A key evidentiary question will be one of functional equivalence: does the TLS "Finished" message, which primarily functions to confirm the integrity of a completed key exchange, perform the specific claimed function of a "proof" that provides confidence that the key was "generated properly" by a specific "escrow-enabling" algorithm as described in the ’150 patent?