Use of a Risky Cryptographic Primitive
This device implements a cryptographic algorithm using a non-standard or unproven cryptographic primitive.
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.
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.
The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.
Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.
Re-using random values may compromise security
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.
Weaknesses in this category are related to hardware implementations of cryptographic protocols and other hardware-security primitives such as physical unclonable funct...
Weaknesses in this category are related to the design and implementation of data confidentiality and integrity. Frequently these deal with the use of encoding techniqu...
This view (slice) covers all the elements in CWE.
CWE identifiers in this view are weaknesses that do not have associated Software Fault Patterns (SFPs), as covered by the CWE-888 view. As such, they represent gaps in...
This view (slice) lists weaknesses that can be introduced during implementation.