CWE-1204: Generation of Weak Initialization Vector (IV)

Description:
The product uses a cryptographic primitive that uses an Initialization
			Vector (IV), but the product does not generate IVs that are
			sufficiently unpredictable or unique according to the expected
			cryptographic requirements for that primitive.

Extended Description:
By design, some cryptographic primitives
			  (such as block ciphers) require that IVs
			  must have certain properties for the
			  uniqueness and/or unpredictability of an
			  IV. Primitives may vary in how important
			  these properties are. If these properties
			  are not maintained, e.g. by a bug in the
			  code, then the cryptography may be weakened
			  or broken by attacking the IVs themselves.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-330

Consequences:
  - Confidentiality: Read Application Data

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Mitigations:
  - [Implementation] Different cipher
			    modes have different requirements for
			    their IVs. When choosing and implementing
			    a mode, it is important to understand
			    those requirements in order to keep
			    security guarantees intact. Generally, it
			    is safest to generate a random IV, since
			 

Demonstrative examples:
In the following examples, CBC mode is used when encrypting data:
In both of these examples, the initialization vector (IV) is always a block of zeros. This makes the resulting cipher text much more predictable and susceptible to a dictionary attack.
EVP_CIPHER_CTX ctx; char key[EVP_MAX_KEY_LENGTH]; char iv[EVP_MAX_IV_LENGTH]; RAND_bytes(key, b); memset(iv,0,EVP_MAX_IV_LENGTH); EVP_EncryptInit(&ctx,EVP_bf_cbc(), key,iv);
public class SymmetricCipherTest { 
                               public static void main() { 
                               
                               byte[] text ="Secret".getBytes(); byte[] iv ={ 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 }; KeyGenerator kg = KeyGenerator.getInstance("DES"); kg.init(56); SecretKey key = kg.generateKey(); Cipher cipher = Cipher.getIn

The Wired Equivalent Privacy (WEP) protocol used in the 802.11
			    wireless standard only supported 40-bit keys, and the IVs were only 24
			    bits, increasing the chances that the same IV would be reused for
			    multiple messages. The IV was included in plaintext as part of the packet, making
			    it directly observable to attackers. Only 5000 messages are needed
			    before a collision occurs due to the "birthday paradox" [REF-1176]. Some
			    implementations would reuse the same IV for each packet. This IV reuse
			    made it much easier for attackers to recover plaintext from
			    two packets with the same IV, using well-understood attacks,
			    especially if the plaintext was known for one of the packets [REF-1175].

Real-world examples:
  - CVE-2020-1472: ZeroLogon vulnerability - use of a static IV of all zeroes in AES-CFB8 mode
  - CVE-2011-3389: BEAST attack in SSL 3.0 / TLS 1.0. In CBC mode, chained initialization vectors are non-random, allowing decryption of HTTPS traffic using a chosen plaintext attack.
  - CVE-2001-0161: wireless router does not use 6 of the 24 bits for WEP encryption, making it easier for attackers to decrypt traffic
  - CVE-2001-0160: WEP card generates predictable IV values, making it easier for attackers to decrypt traffic
  - CVE-2017-3225: device bootloader uses a zero initialization vector during AES-CBC