CWE-1240: Use of a Cryptographic Primitive with a Risky Implementation

ID CWE-1240
Abstraction Base
Structure Simple
Status Draft
Number of CVEs 2
To fulfill the need for a cryptographic primitive, the product implements a cryptographic algorithm using a non-standard, unproven, or disallowed/non-compliant cryptographic implementation.

Cryptographic protocols and systems depend on cryptographic primitives (and associated algorithms) as their basic building blocks. Some common examples of primitives are digital signatures, one-way hash functions, ciphers, and public key cryptography; however, the notion of "primitive" can vary depending on point of view. See "Terminology Notes" for further explanation of some concepts.

Cryptographic primitives are defined to accomplish one very specific task in a precisely defined and mathematically reliable fashion. For example, suppose that for a specific cryptographic primitive (such as an encryption routine), the consensus is that the primitive can only be broken after trying out N different inputs (where the larger the value of N, the stronger the cryptography). For an encryption scheme like AES-256, one would expect N to be so large as to be infeasible to execute in a reasonable amount of time.

If a vulnerability is ever found that shows that one can break a cryptographic primitive in significantly less than the expected number of attempts, then that primitive is considered weakened (or sometimes in extreme cases, colloquially it is "broken"). As a result, anything using this cryptographic primitive would now be considered insecure or risky. Thus, even breaking or weakening a seemingly small cryptographic primitive has the potential to render the whole system vulnerable, due to its reliance on the primitive. A historical example can be found in TLS when using DES. One would colloquially call DES the cryptographic primitive for transport encryption in this version of TLS. In the past, DES was considered strong, because no weaknesses were found in it; importantly, DES has a key length of 56 bits. Trying N=2^56 keys was considered impractical for most actors. Unfortunately, attacking a system with 56-bit keys is now practical via brute force, which makes defeating DES encryption practical. It is now practical for an adversary to read any information sent under this version of TLS and use this information to attack the system. As a result, it can be claimed that this use of TLS is weak, and that any system depending on TLS with DES could potentially render the entire system vulnerable to attack.

Cryptographic primitives and associated algorithms are only considered safe after extensive research and review from experienced cryptographers from academia, industry, and government entities looking for any possible flaws. Furthermore, cryptographic primitives and associated algorithms are frequently reevaluated for safety when new mathematical and attack techniques are discovered. As a result and over time, even well-known cryptographic primitives can lose their compliance status with the discovery of novel attacks that might either defeat the algorithm or reduce its robustness significantly.

If ad-hoc cryptographic primitives are implemented, it is almost certain that the implementation will be vulnerable to attacks that are well understood by cryptographers, resulting in the exposure of sensitive information and other consequences.

This weakness is even more difficult to manage for hardware-implemented deployment of cryptographic algorithms. First, because hardware is not patchable as easily as software, any flaw discovered after release and production typically cannot be fixed without a recall of the product. Secondly, the hardware product is often expected to work for years, during which time computation power available to the attacker only increases. Therefore, for hardware implementations of cryptographic primitives, it is absolutely essential that only strong, proven cryptographic primitives are used.

Modes of Introduction

Phase Note
Architecture and Design This weakness is primarily introduced during the architecture and design phase as risky primitives are included.
Implementation Even in cases where the Architectural phase properly specifies a cryptographically secure design, the design may be changed during implementation due to unforeseen constraints.

Applicable Platforms

Type Class Name Prevalence
Language Not Language-Specific
Operating_system Not OS-Specific
Architecture Not Architecture-Specific
Technology System on Chip

Relationships

View Weakness
# ID View Status # ID Name Abstraction Structure Status
CWE-1000 Research Concepts Draft CWE-327 Use of a Broken or Risky Cryptographic Algorithm Class Simple Draft

Common Attack Pattern Enumeration and Classification (CAPEC)

The Common Attack Pattern Enumeration and Classification (CAPECâ„¢) effort provides a publicly available catalog of common attack patterns that helps users understand how adversaries exploit weaknesses in applications and other cyber-enabled capabilities.

CAPEC at Mitre.org
# ID Name Weaknesses
CAPEC-97 Cryptanalysis CWE-1240

CVEs Published

CVSS Severity

CVSS Severity - By Year

CVSS Base Score

# CVE Description CVSS EPSS EPSS Trend (30 days) Affected Products Weaknesses Security Advisories Exploits PoC Pubblication Date Modification Date
# CVE Description CVSS EPSS EPSS Trend (30 days) Affected Products Weaknesses Security Advisories PoC Pubblication Date Modification Date
Loading...
Loading...