CWE-329, Generation of Predictable IV with CBC Mode, describes a product that creates and uses a predictable initialization vector with Cipher Block Chaining mode. Under the same key, this makes the encryption susceptible to dictionary attacks.
It matters to any team calling AES or another block cipher directly instead of through a high level authenticated interface.
How it happens
MITRE explains that CBC fixes a flaw of ECB mode, where identical plaintext blocks give identical ciphertext blocks. CBC XORs an IV into the first plaintext block, so every block in the chain is mixed with a different value before encryption. If IVs are reused, identical plaintexts again encrypt to identical ciphertexts. Even if IVs differ, predictable ones still weaken the scheme.
// Vulnerable: fixed all-zero IV
byte[] iv = new byte[16];
Cipher c = Cipher.getInstance("AES/CBC/PKCS5Padding");
c.init(Cipher.ENCRYPT_MODE, key, new IvParameterSpec(iv));
The observed examples cover three versions of the mistake. CVE-2020-5408 is an authentication framework using a fixed null IV with CBC. CVE-2017-17704 is a door unlocking product whose messages use a fixed IV that is the same after each restart. CVE-2017-11133 is an application using AES in CBC mode where the secret and IV came from math.random, which is not cryptographically secure.
What an attacker gains
The record lists confidentiality. If the IV is not properly initialized, encrypted data can be compromised and leak information, such as which messages are identical.
How to find it
Static analysis can flag constant IV arguments and IVs built from non-cryptographic random sources. In review, trace each IV back to where it is created.
How to fix it
MITRE cites NIST recommendations for generating unpredictable IVs in CBC mode:
- Generate the IV randomly, using a cryptographically secure generator, for every message.
- Or encrypt a nonce with the same key and cipher used for the plaintext. The nonce must be unique but may be predictable, since the block cipher acts as a pseudo random permutation.
// Fixed: fresh random IV per message, stored with the ciphertext
byte[] iv = new byte[16];
new SecureRandom().nextBytes(iv);
Better still, prefer an authenticated mode so tampering is detected too.
Quick check
Does the IV need to be secret?
Typically it needs to be unpredictable, not secret. It is normally sent with the ciphertext.
