CWE

Common Weakness Enumeration

A Community-Developed List of Software & Hardware Weakness Types
CWE Top 25 Most Dangerous Weaknesses
Home > CWE List > CWE- Individual Dictionary Definition (4.4)  
ID

CWE-1240: Use of a Risky Cryptographic Primitive

Weakness ID: 1240
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
This device implements a cryptographic algorithm using a non-standard or unproven cryptographic primitive.
+ Extended Description

Cryptographic algorithms (or Cryptographic systems) depend on cryptographic primitives as their basic building blocks. As a result, cryptographic primitives are designed to do one very specific task in a precisely defined and highly reliable fashion. For example, one can declare that a specific crypto primitive (like an encryption routine) can only be broken after trying out N different inputs (the larger the value of N, the stronger the crypto). If a vulnerability is found that leads to breaking this primitive in significantly less than N attempts, then the specific cryptographic primitive is considered broken, and the entirety of the cryptographic algorithm (or the cryptographic system) is now considered insecure. Thus, even breaking a seemingly small cryptographic primitive is sufficient to render the whole system vulnerable.

Cryptographic primitives are products of extensive reviews from cryptographers, industry, and government entities looking for any possible flaws. However, over time even well-known cryptographic primitives 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 such implementations will be vulnerable to attacks resulting in the exposure of sensitive information and other consequences.

+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.327Use of a Broken or Risky Cryptographic Algorithm
+ Relevant to the view "Software Development" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.310Cryptographic Issues
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1205Security Primitives and Cryptography Issues
+ Background Details
This issue is even more difficult for hardware-implemented deployment of cryptographic algorithms for several reasons. Because hardware is not patchable as easily as software, any flaw discovered after release and production of the hardware, cannot be fixed in most cases 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

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and DesignThis weakness is primarily introduced during the architecture and design phase as risky primitives are included.
ImplementationEven 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
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: System on Chip (Undetermined Prevalence)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

Incorrect usage of crypto primitives could render the supposedly encrypted data as unencrypted plaintext in the worst case.
High
+ Demonstrative Examples

Example 1

Re-using random values may compromise security

(bad code)
 
Suppose a Hashing algorithm needs a random value. Instead of using a DRNG (Deterministic Random Number Generator), the designer uses a LFSR to generate the value.

While an LFSR does provide pseudo-random number generation service, its entropy (measure of randomness) is less than that of a DRNG. Thus, using an LFSR weakens the strength of the crypto.

(good code)
 
If a cryptographic algorithm expects a random number as its input, provide one. Do not provide a pseudo-random value.
+ Potential Mitigations

Phase: Architecture and Design

Follow these good cryptography practices:

  • Do not create your own cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. As with all cryptographic mechanisms, the source code should be available for analysis. If the algorithm may be compromised when attackers find out how it works, then it is especially weak.
  • Do not use outdated or not-compliant cryptography algorithms. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong.
  • Do not use LFSR as a substitute for an actual Random Number Generator.
  • Do not use a checksum as a substitute for a cryptographically generated hash.
  • Design the hardware at a replaceable block level so that one cryptographic algorithm can be replaced with another in the next generation. Use wrappers to make the interfaces uniform. This will make the upgrade path to stronger cryptographic algorithms easier.
  • Do not store keys in areas accessible to untrusted agents. Carefully manage and protect the cryptographic keys (see CWE-320). If the keys can be guessed or stolen, then the strength of the cryptography algorithm is irrelevant.
  • Use a vetted cryptographic library or framework. Industry-standard implementations will save development time and are more likely to avoid errors that can occur during implementation of cryptographic algorithms.
  • When using industry-approved techniques, use them correctly. Don't cut corners by skipping resource-intensive steps (CWE-325). These steps are often essential for the prevention of common attacks.

Effectiveness: High

+ Notes

Maintenance

The example listed does not really illustrate what is called out in the description.

Research Gap

This HCWE is really an instance of the RNG CWEs and probably should not be a standalone HCWE.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-10Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Background_Details, Common_Consequences, Demonstrative_Examples, Description, Maintenance_Notes, Modes_of_Introduction, Potential_Mitigations, Related_Attack_Patterns, Research_Gaps
More information is available — Please select a different filter.
Page Last Updated: March 15, 2021
 

Use of the Common Weakness Enumeration (CWE) and the associated references from this website are subject to the Terms of Use. CWE is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and managed by the Homeland Security Systems Engineering and Development Institute (HSSEDI) which is operated by The MITRE Corporation (MITRE). Copyright © 2006-2021, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation.