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

Description:
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.

Extended Description:
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 cr

Affected languages: Not Language-Specific
Affected technologies: System on Chip
Parent weaknesses: CWE-327

Consequences:
  - Confidentiality: Read Application Data

Detection methods:
  - Architecture or Design Review: Review requirements, documentation, and product design to ensure that primitives are consistent with the strongest-available recommendations from trusted parties. If the product appears to be using cu
  - Manual Analysis: Analyze the product to ensure that implementations for each primitive do not contain any known vulnerabilities and are not using any known-weak algorithms, including MD4, MD5, SHA1, DES, etc.
  - Dynamic Analysis with Manual Results Interpretation: For hardware, during the implementation (pre-Silicon / post-Silicon) phase, dynamic tests should be done to ensure that outputs from cryptographic routines are indeed working properly, such as test ve
  - Dynamic Analysis with Manual Results Interpretation: It needs to be determined if the output of a cryptographic primitive is lacking entropy, which is one clear sign that something went wrong with the crypto implementation. There exist many methods of m

Mitigations:
  - [Requirements] Require compliance with the strongest-available recommendations from trusted parties, and require that compliance must be kept up-to-date, since recommendations evolve over time. For example, US government systems require FIPS 140-3 certification, which supersedes FIPS 140-2 [REF-1192] [REF-267].
  - [Architecture and Design] Ensure that the architecture/design uses the strongest-available primitives and algorithms from trusted parties. For example, US government systems require FIPS 140-3 certification, which supersedes FIPS 140-2 [REF-1192] [REF-267].
  - [Architecture and Design] Do not develop custom or private 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 wor
  - [Architecture and Design] Try not to use cryptographic algorithms in novel ways or with new modes of operation even when you "know" it is secure. For example, using SHA-2 chaining to create a 1-time pad for encryption might sound like a good idea, but one should not do this.

Demonstrative examples:
Re-using random values may compromise security.
While an LFSR may provide pseudo-random number generation service, the entropy (measure of randomness) of the resulting output may be less than that of an accepted DRNG (like that used in dev/urandom). Thus, using an LFSR weakens the strength of the cryptographic system, because it may be possible for an attacker to guess the LFSR output and subsequently the encryption key.
Suppose an Encryption algorithm needs a random value for a key. Instead of using a DRNG (Deterministic Random Number Generator), the designer uses a linear-feedback shift register (LFSR) to generate the value.
If a cryptographic algorithm expects a random number as its input, provide one. Do not provide a pseudo-random value.

Real-world examples:
  - CVE-2020-4778: software uses MD5, which is less safe than the default SHA-256 used by related products
  - CVE-2005-2946: Default configuration of product uses MD5 instead of stronger algorithms that are available, simplifying forgery of certificates.
  - CVE-2019-3907: identity card uses MD5 hash of a salt and password
  - CVE-2021-34687: personal key is transmitted over the network using a substitution cipher
  - CVE-2020-14254: product does not disable TLS-RSA cipher suites, allowing decryption of traffic if TLS 2.0 and secure ciphers are not enabled.