The product 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 emergence 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 implementation will be vulnerable to attacks resulting in the exposure of sensitive information and/or 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)
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 issue is even more prominent for hardware-implemented deployment of cryptographic algorithms due to a number of reasons. Firstly, because hardware is not replaceable like software, if a flaw is discovered with a hardware-implemented cryptographic primitive, it 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
In many cases, the design originally defines a proper cryptography primative, but this is then changed during implementation due to unforseen 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.
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.
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. This would compromise any security property, including the ones listed above.
High
Demonstrative Examples
Example 1
Re-using Crypto primitive could compromise security
(bad code)
Suppose a Hashing algorithm needs random seed. Instead of using a DRNG (Deterministic Random Number Generator), the designer uses a LFSR to generate the seed.
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 crypto expect a proper (or deterministic) random number as its input, do equip it with one - do not give it something that is pseudo-random.
Potential Mitigations
Phase: Architecture and Design
Follow these good cryptography practices:
Do not create your own crypto algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. Reverse engineering techniques are mature. As with all cryptographic mechanisms, the source code should be available for analysis. If the algorithm can be compromised when attackers find out how it works, then it is especially weak.
Do not use outdated/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 proper Random Number Generator IPs.
Do not use checksum as a substitute for proper Hashes.
Design the hardware at the IP 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 it easier to upgrade to stronger algorithms.
Do not store keys in areas accessible to untrusted agents. Carefully manage and protect cryptographic keys (see CWE-320). If the keys can be guessed or stolen, then the strength of the cryptography itself is irrelevant.
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. Industry-standard implementations will save development time and might be 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 preventing common attacks.
Description
