Use of a Cryptographic Primitive with a Risky Implementation
Draft Base
Structure: Simple
Description
This weakness occurs when a product uses a custom, unverified, or non-compliant implementation of a cryptographic algorithm instead of a trusted, standard solution.
Cryptographic systems rely on proven building blocks like encryption, hashing, and digital signatures. These primitives are mathematically designed to withstand a specific number of attack attempts. When developers implement their own versions or use deprecated algorithms, they often introduce subtle flaws that cryptographers already understand, making the entire system vulnerable to data exposure or tampering. Using risky implementations is especially dangerous in hardware, where fixes often require physical recalls. Cryptographic standards are continuously reviewed and updated as computing power grows and new attack methods emerge. Relying on non-standard or weakened primitives, even for a single component, can compromise the security of the entire application over its lifespan.
Common Consequences 1
Scope: Confidentiality
Impact: Read Application Data
Incorrect usage of crypto primitives could render the supposedly encrypted data as unencrypted plaintext in the worst case.
Detection Methods 4
Architecture or Design ReviewHigh
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 custom or proprietary implementations that have not had sufficient public review and approval, then this is a significant concern.Manual AnalysisModerate
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 InterpretationModerate
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 vectors provided by NIST [REF-1236].Dynamic Analysis with Manual Results InterpretationModerate
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 measuring the entropy of a bytestream, from sophisticated ones (like calculating Shannon's entropy of a sequence of characters) to crude ones (by compressing it and comparing the size of the original bytestream vs. the compressed - a truly random byte stream should not be compressible and hence the uncompressed and compressed bytestreams should be nearly identical in size).Potential Mitigations 11
Phase: 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].
Effectiveness: High
Phase: 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].
Effectiveness: High
Phase: 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 works, then it is especially weak.
Effectiveness: Discouraged Common Practice
Phase: 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.
Effectiveness: Discouraged Common Practice
Phase: Architecture and Design
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.
Effectiveness: Defense in Depth
Phase: Architecture and Design
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].
Effectiveness: Discouraged Common Practice
Phase: Architecture and DesignImplementation
Do not use a linear-feedback shift register (LFSR) or other legacy methods as a substitute for an accepted and standard Random Number Generator.
Effectiveness: Discouraged Common Practice
Phase: Architecture and DesignImplementation
Do not use a checksum as a substitute for a cryptographically generated hash.
Effectiveness: Discouraged Common Practice
Phase: Architecture and Design
Strategy: Libraries or Frameworks
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.
Effectiveness: High
Phase: Architecture and DesignImplementation
When using industry-approved techniques, use them correctly. Don't cut corners by skipping resource-intensive steps (Missing Cryptographic Step). These steps are often essential for the prevention of common attacks.
Effectiveness: Moderate
Phase: Architecture and DesignImplementation
Do not store keys in areas accessible to untrusted agents. Carefully manage and protect the cryptographic keys (see Key Management Errors). If the keys can be guessed or stolen, then the strength of the cryptography algorithm is irrelevant.
Effectiveness: Moderate
Demonstrative Examples 1
Re-using random values may compromise security.
Code Example:
Bad
Other
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.
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.
Code Example:
Good
Other
If a cryptographic algorithm expects a random number as its input, provide one. Do not provide a pseudo-random value.
Observed Examples 12
CVE-2020-4778software uses MD5, which is less safe than the default SHA-256 used by related products
CVE-2005-2946Default configuration of product uses MD5 instead of stronger algorithms that are available, simplifying forgery of certificates.
CVE-2019-3907identity card uses MD5 hash of a salt and password
CVE-2021-34687personal key is transmitted over the network using a substitution cipher
CVE-2020-14254product does not disable TLS-RSA cipher suites, allowing decryption of traffic if TLS 2.0 and secure ciphers are not enabled.
CVE-2019-1543SSL/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-9267LDAP interface allows use of weak ciphers
CVE-2017-7971SCADA product allows "use of outdated cipher suites"
CVE-2020-6616Chip implementing Bluetooth uses a low-entropy PRNG instead of a hardware RNG, allowing spoofing.
CVE-2019-1715security product has insufficient entropy in the DRBG, allowing collisions and private key discovery
CVE-2014-4192Dual_EC_DRBG implementation in RSA toolkit does not correctly handle certain byte requests, simplifying plaintext recovery
CVE-2007-6755Recommendation for Dual_EC_DRBG algorithm contains point Q constants that could simplify decryption
References 4
FIPS PUB 140-2: SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES
Information Technology Laboratory, National Institute of Standards and Technology
25-05-2001
ID: REF-267
FIPS PUB 140-3: SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES
Information Technology Laboratory, National Institute of Standards and Technology
22-03-2019
ID: REF-1192
CAVP Testing: Individual Component Testing
NIST
ID: REF-1236
Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Technologies:
System on Chip : Undetermined
Modes of Introduction
Architecture and Design
Implementation
Related Attack Patterns
Related Weaknesses
Notes
Terminology
Terminology for cryptography varies widely, from informal and colloquial to mathematically-defined, with different precision and formalism depending on whether the stakeholder is a developer, cryptologist, etc. Yet there is a need for CWE to be self-consistent while remaining understandable and acceptable to multiple audiences.
As of CWE 4.6, CWE terminology around "primitives" and "algorithms" is emerging as shown by the following example, subject to future consultation and agreement within the CWE and cryptography communities. Suppose one wishes to send encrypted data using a CLI tool such as OpenSSL. One might choose to use AES with a 256-bit key and require tamper protection (GCM mode, for instance). For compatibility's sake, one might also choose the ciphertext to be formatted to the PKCS#5 standard. In this case, the "cryptographic system" would be AES-256-GCM with PKCS#5 formatting. The "cryptographic function" would be AES-256 in the GCM mode of operation, and the "algorithm" would be AES. Colloquially, one would say that AES (and sometimes AES-256) is the "cryptographic primitive," because it is the algorithm that realizes the concept of symmetric encryption (without modes of operation or other protocol related modifications). In practice, developers and architects typically refer to base cryptographic algorithms (AES, SHA, etc.) as cryptographic primitives.
MaintenanceSince CWE 4.4, various cryptography-related entries, including Use of a Broken or Risky Cryptographic Algorithm and Use of a Cryptographic Primitive with a Risky Implementation, have been slated for extensive research, analysis, and community consultation to define consistent terminology, improve relationships, and reduce overlap or duplication. As of CWE 4.6, this work is still ongoing.