Long story short: a crypto lib on the iPhone is among the many where the default is an all-zeroes IV. Does any application shipping with the iPhone use that default? The author doesn't know. I think it's unlikely.
How big a deal is CBC with an all-zeroes IV? Well, it's less of a big deal than ECB mode, which is the default in even more AES libraries. But ECB mode, is (inexplicably) an actual "mode". ECB is harder to single out as an error than an all-zeroes IV, which is explainable only as a mistake. Also, no library on the iPhone ships with a ECB default, unlike, say, OpenSSL, Cryptlib, the Java crypto extensions, &c.
In both ECB mode and CBC-with-predictable-IV mode, the problem is that the same 16 bytes of plaintext will (often, in CBC's case; always, in ECB) produce the same ciphertext. This increases malleability and allows attackers to easily rewrite messages. More importantly, if an attacker controls the size of any part of the input, they can arrange to create ciphertext blocks with only 1-2 unknown bytes, which are trivially brute forced.
By the way: here's more than you ever wanted to know about IVs in CBC mode:
The issue is less about applications shipping with the iPhone doing this and more about Apple stating that IVs are "optional," prompting many non-crypto-savvy developers to ignore IVs completely, thus resulting in highly insecure AES implementations by default in many third-party apps.
Again, that is no worse (better, in fact) than any of the many libraries which default to ECB mode. You might just as productively yell at Java and OpenSSL.
I think you're making a "gotcha" point. It's impossible to implement any crypto protocol safely with ECB mode. And yet libraries far more popular than this one aren't subject to blog posts dinging them for being "broken by default".
I actually agree with you that not requiring an explicit IV is a bad interface choice.
On the other hand, I'm appalled by the idea of any library that exposes AES directly to applications anyways. There's a myriad of mistakes developers make using AES directly. CBC IVs are not among the top three.
It's impossible to implement any crypto protocol safely with ECB mode.
But ECB mode may be a useful primitive component of some other, more secure, mode. For example, this API doesn't support CTR mode, but if you needed it, probably the most efficient thing would be to fill a buffer with your nonce and counter values pass it to this API to be encrypted using "ECB mode". It's parallelizable that way.
And that is the point of this level of crypto API: providing efficient access to whatever software implementation or hardware acceleration may be available on the target system.
And yet libraries far more popular than this one aren't subject to blog posts dinging them for being "broken by default".
I want to give Nadim some credit here: he is thinking like an attacker now!
This represents a great improvement over his previous crypto implementation endeavors.
Sure. But I'm not talking about the availability of ECB; I'm talking about ECB as a default.
And, I agree with the fundmental point he's making: optional IVs for CBC mode are a bad interface details for lay programmers. Just remember, every AES library makes similar (usually worse) design mistakes.
Generalists are very poorly served by low-level AES libraries (where "low level" certainly includes any library where you have to think about IVs or, indeed, which block cipher mode to use).
The big difference between the ECB and CBC block cipher modes is that in ECB identical blocks of plaintext will produce identical blocks of ciphertext, within the same communication. This will reveal something (at least that there's lots of identical blocks) about the content of the plaintext which may be used to device an attack.
In CBC (with known IV) you only get the same ciphertext for identical blocks in the beginning of different transmissions if you use the same key for both transmissions. As you're not supposed to use the same key twice for a stream cipher, it's not a really big issue.
It's a significant issue. For instance, Thai Duong and Juliano Rizzo's recent SSL decrypting attack relied on predicting (not controlling) IVs --- in other words, literally the attack this thread is talking about, but under more constraints.
It is not a "really big issue" in the sense of "we forgot to put a MAC on this ciphertext to guarantee authenticity", which is a more common mistake than not setting an IV; or, a "really big issue" in the sense of "we managed to expose a padding oracle", which is a more common CBC mistake. But it is a significant mistake.
How you choose to key streams is an orthogonal concern to whether your block cipher mode leaks data.
The point of using an IV is that you can use the same key for multiple messages. You're not supposed to repeat (key, nonce) pairs for a stream cipher, and CBC's IV is sort-of equivalent to the nonce. (AES-CBC is not technically a stream cipher. Not all stream ciphers have nonces.)
Using the same key+nonce pair in a stream cipher has the effect of generating an identical keystream. It's a much, much worse problem than repeating IVs; it makes decrypting the resulting ciphertext stream almost a pencil/paper exercise.
IANA Cryptographer but as far as I know, the initialization vector (IV) of a cryptographic protocol is usually public and an integral part of the protocol specification. Both parties must agree on the value of the IV so they can understand each other. If the IV were secret, some kind of handshake (similar to key agreement) should take place before the connection is initiated.
I don't know how using a block cipher in cipher block chaining (CBC) would be different here. In the article, OP suggests that it may be related to short messages. Indeed, if the plaintext is less than or equal to one block, and you re-use the same key (which you should never do) it's possible to do replay attacks.
If anyone has deeper knowledge of cryptography and block cipher modes in particular, please explain to us how CBC is vulnerable if the IV is known by the attacker? Why are short messages more vulnerable and to which attack modes?
As I said, I'm not a cryptographer, only a uni student with an exam on crypto tomorrow. To me, it seems like the article had a linkbait title and it didn't describe a very big threat anyway (and it was only superficially related to AES). But if crypto class has taught me anything, it's that intuition often fails. So don't take my word for it, there may be a real threat behind this.
It is a significant problem to have deployed CBC with predictable IVs (all zeroes is no worse than any other predictable IV), for the very same reason it's bad to use ECB mode.
The IV does not need to be secret, but an attacker shouldn't be able to predict what the IV for a given piece of plaintext will be before it's encrypted. If that makes sense.
This is kind of a silly thing to file a bug about.
The library design decision we don't like is that the IV isn't required; ie, an IV is not among the required arguments of some function in the argument.
There's no reasonable hot fix for this problem. It requires an API change to "fix".
Believe me, please believe me, there are much much worse things that developers will get wrong with AES on the iPhone than not remembering to set a random IV.
A low-level API is not the thing to design your cryptographic protocol around.
A low-level crypto API is not prescriptive, it's documentation is merely descriptive. Apple devs were merely documenting and unit testing what happens when you pass in a certain combination of parameters.
So from what I understand, the first block is encrypted in ECB mode, and any blocks there after are done in CBC mode. And that's if the IV is not set by being optional.
This article is 100% wrong. The IV is not a secret, must be know for decryption. In-fact counter mode simply picks a starting IV and increments. Allowing the attacker to manipulate the IV or reuse of an IV can be problematic, but a guessable IV is of NO HELP to an attacker
26 comments
[ 2.3 ms ] story [ 63.4 ms ] threadHow big a deal is CBC with an all-zeroes IV? Well, it's less of a big deal than ECB mode, which is the default in even more AES libraries. But ECB mode, is (inexplicably) an actual "mode". ECB is harder to single out as an error than an all-zeroes IV, which is explainable only as a mistake. Also, no library on the iPhone ships with a ECB default, unlike, say, OpenSSL, Cryptlib, the Java crypto extensions, &c.
In both ECB mode and CBC-with-predictable-IV mode, the problem is that the same 16 bytes of plaintext will (often, in CBC's case; always, in ECB) produce the same ciphertext. This increases malleability and allows attackers to easily rewrite messages. More importantly, if an attacker controls the size of any part of the input, they can arrange to create ciphertext blocks with only 1-2 unknown bytes, which are trivially brute forced.
By the way: here's more than you ever wanted to know about IVs in CBC mode:
http://news.ycombinator.com/item?id=2029640
If you just want to know what "IV" means, it's "fictitious first ciphertext block in a block cipher mode that involves chaining ciphertext values".
I actually agree with you that not requiring an explicit IV is a bad interface choice.
On the other hand, I'm appalled by the idea of any library that exposes AES directly to applications anyways. There's a myriad of mistakes developers make using AES directly. CBC IVs are not among the top three.
But ECB mode may be a useful primitive component of some other, more secure, mode. For example, this API doesn't support CTR mode, but if you needed it, probably the most efficient thing would be to fill a buffer with your nonce and counter values pass it to this API to be encrypted using "ECB mode". It's parallelizable that way.
And that is the point of this level of crypto API: providing efficient access to whatever software implementation or hardware acceleration may be available on the target system.
And yet libraries far more popular than this one aren't subject to blog posts dinging them for being "broken by default".
I want to give Nadim some credit here: he is thinking like an attacker now!
This represents a great improvement over his previous crypto implementation endeavors.
And, I agree with the fundmental point he's making: optional IVs for CBC mode are a bad interface details for lay programmers. Just remember, every AES library makes similar (usually worse) design mistakes.
Generalists are very poorly served by low-level AES libraries (where "low level" certainly includes any library where you have to think about IVs or, indeed, which block cipher mode to use).
In CBC (with known IV) you only get the same ciphertext for identical blocks in the beginning of different transmissions if you use the same key for both transmissions. As you're not supposed to use the same key twice for a stream cipher, it's not a really big issue.
It is not a "really big issue" in the sense of "we forgot to put a MAC on this ciphertext to guarantee authenticity", which is a more common mistake than not setting an IV; or, a "really big issue" in the sense of "we managed to expose a padding oracle", which is a more common CBC mistake. But it is a significant mistake.
How you choose to key streams is an orthogonal concern to whether your block cipher mode leaks data.
Sorry for the pedantry.
Thanks for answering my question.
I don't know how using a block cipher in cipher block chaining (CBC) would be different here. In the article, OP suggests that it may be related to short messages. Indeed, if the plaintext is less than or equal to one block, and you re-use the same key (which you should never do) it's possible to do replay attacks.
If anyone has deeper knowledge of cryptography and block cipher modes in particular, please explain to us how CBC is vulnerable if the IV is known by the attacker? Why are short messages more vulnerable and to which attack modes?
As I said, I'm not a cryptographer, only a uni student with an exam on crypto tomorrow. To me, it seems like the article had a linkbait title and it didn't describe a very big threat anyway (and it was only superficially related to AES). But if crypto class has taught me anything, it's that intuition often fails. So don't take my word for it, there may be a real threat behind this.
It is a significant problem to have deployed CBC with predictable IVs (all zeroes is no worse than any other predictable IV), for the very same reason it's bad to use ECB mode.
The IV does not need to be secret, but an attacker shouldn't be able to predict what the IV for a given piece of plaintext will be before it's encrypted. If that makes sense.
Then add it in here for the benefit of others: http://openradar.appspot.com
The library design decision we don't like is that the IV isn't required; ie, an IV is not among the required arguments of some function in the argument.
There's no reasonable hot fix for this problem. It requires an API change to "fix".
Believe me, please believe me, there are much much worse things that developers will get wrong with AES on the iPhone than not remembering to set a random IV.
http://developer.apple.com/library/ios/#documentation/System...
this does not exonerate Apple having made a wrong choice of design.
A low-level API is not the thing to design your cryptographic protocol around.
A low-level crypto API is not prescriptive, it's documentation is merely descriptive. Apple devs were merely documenting and unit testing what happens when you pass in a certain combination of parameters.