Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Swift: detect the use of static initialization vectors #11084

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

karimhamdanali
Copy link
Contributor

@karimhamdanali karimhamdanali commented Nov 2, 2022

Using a static initialization vector (IV) for encryption is not secure. To maximize encryption and prevent dictionary attacks, IVs should rather be unique and unpredictable (e.g., randomly generated).

The rule currently supports all ciphers that the CryptoSwift API provides, but we can always extend it further if more APIs are added.

I'd appreciate a review of the query itself, the accompanying tests, and the associated documentation.

@github-actions
Copy link
Contributor

github-actions bot commented Nov 2, 2022

QHelp previews:

swift/ql/src/queries/Security/CWE-1204/StaticInitializationVector.qhelp

Static initialization vector for encryption

When a cipher is used in certain modes (such as CBC or GCM), it requires an initialization vector (IV). Under the same secret key, IVs should be unique and ideally unpredictable. If the same IV is used with the same secret key, then the same plaintext results in the same ciphertext. This behavior may enable an attacker to learn if the same data pieces are transferred or stored, or help the attacker run a dictionary attack.

Recommendation

Use a randomly generated IV.

Example

The following example shows a few cases of instantiating a cipher with various encryption keys. In the 'BAD' cases, the IV is hardcoded or constant, making the encrypted data vulnerable to recovery. In the 'GOOD' cases, the IV is randomly generated and not hardcoded, which protects the encrypted data against recovery.


func encrypt(padding : Padding) {
	// ...

	// BAD: Using static IVs for encryption
	let iv: Array<UInt8> = [0x2a, 0x3a, 0x80, 0x05]
	let ivString = "this is a constant string"
	let key = getRandomKey()
	_ = try AES(key: key, iv: ivString)
	_ = try CBC(iv: iv)

	// GOOD: Using randomly generated IVs for encryption
	let iv = (0..<10).map({ _ in UInt8.random(in: 0...UInt8.max) })
	let ivString = String(cString: iv)
	let key = getRandomKey())
	_ = try AES(key: key, iv: ivString)
	_ = try CBC(iv: iv)

	// ...
}

References

Copy link
Contributor

@geoffw0 geoffw0 left a comment

A few minor points, otherwise docs, query and tests look great to me!

@@ -0,0 +1,72 @@
/**
* @name Static initialization vector for encryption
* @description Using a static initialization vector (IV) for encryption is not secure. To maximize encryption and prevent dictionary attacks, IVs should rather be unique and unpredictable.
Copy link
Contributor

@geoffw0 geoffw0 Nov 2, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the bit about dictionary attacks right, I thought the main attack on this one is recognizing repeated plaintext?

"CCM", "CTR"
], fName) and
fName.matches("%init(%iv:%") and
arg = [0, 1] and
Copy link
Contributor

@geoffw0 geoffw0 Nov 2, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will sometimes recognize flow to arguments other than the iv.

let randomIv = getRandomArray()
let randomIvString = String(cString: getRandomArray())

let blockMode = CBC(iv: randomIv)
Copy link
Contributor

@geoffw0 geoffw0 Nov 2, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe blockMode is unused.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants