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.
Modes of Introduction:
– Architecture and Design
Related Weaknesses
Consequences
Confidentiality: Read Application Data
Incorrect usage of crypto primitives could render the supposedly encrypted data as unencrypted plaintext in the worst case.
Potential Mitigations
Phase: Requirements
Effectiveness: High
Description:
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-1226].
Phase: Architecture and Design
Effectiveness: High
Description:
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-1226].
Phase: Architecture and Design
Effectiveness: Discouraged Common Practice
Description:
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 works, then it is especially weak.
Phase: Architecture and Design
Effectiveness: Discouraged Common Practice
Description:
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.
Phase: Architecture and Design
Effectiveness: Defense in Depth
Description:
Ensure that the design can replace one cryptographic primitive or algorithm with another in the next generation (“cryptographic agility”). Where possible, use wrappers to make the interfaces uniform. This will make it easier to upgrade to stronger algorithms. This is especially important for hardware, which can be more difficult to upgrade quickly than software; design the hardware at a replaceable block level.
Phase: Architecture and Design
Effectiveness: Discouraged Common Practice
Description:
Do not use outdated or non-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 [REF-267].
Phase: Architecture and Design, Implementation
Effectiveness: Discouraged Common Practice
Description:
Do not use a linear-feedback shift register (LFSR) or other legacy methods as a substitute for an accepted and standard Random Number Generator.
Phase: Architecture and Design, Implementation
Effectiveness: Discouraged Common Practice
Description:
Do not use a checksum as a substitute for a cryptographically generated hash.
Phase: Architecture and Design
Effectiveness: High
Description:
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. However, the library/framework could be used incorrectly during implementation.
Phase: Architecture and Design, Implementation
Effectiveness: Moderate
Description:
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.
Phase: Architecture and Design, Implementation
Effectiveness: Moderate
Description:
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.
CVE References
- 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.
- CVE-2019-1543
- SSL/TLS library generates 16-byte nonces but reduces them to 12 byte nonces for the ChaCha20-Poly1305 cipher, converting them in a way that violates the cipher’s requirements for unique nonces.
- CVE-2017-9267
- LDAP interface allows use of weak ciphers
- CVE-2017-7971
- SCADA product allows “use of outdated cipher suites”
- CVE-2020-6616
- Chip implementing Bluetooth uses a low-entropy PRNG instead of a hardware RNG, allowing spoofing.
- CVE-2019-1715
- security product has insufficient entropy in the DRBG, allowing collisions and private key discovery
- CVE-2014-4192
- Dual_EC_DRBG implementation in RSA toolkit does not correctly handle certain byte requests, simplifying plaintext recovery
- CVE-2007-6755
- Recommendation for Dual_EC_DRBG algorithm contains point Q constants that could simplify decryption