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
This table 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)
Nature
Type
ID
Name
ChildOf
Class - 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.
This table 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 "Software Development" (CWE-699)
Nature
Type
ID
Name
MemberOf
Category - a CWE entry that contains a set of other entries that share a common characteristic.
This table 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 "Hardware Design" (CWE-1194)
Nature
Type
ID
Name
MemberOf
Category - a CWE entry that contains a set of other entries that share a common characteristic.
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.
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
This listing shows 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.
This table 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.
Scope
Impact
Likelihood
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
This hardware CWE is really an instance of other RNG CWEs and probably should not be a standalone entry. It is being investigated with other RNG entries.
Maintenance
The example listed does not really illustrate what is called out in the description.
Description
This table 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.
