AES on the iPhone is Broken by Default

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.<p>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 <i>even more AES libraries</i>. 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, &#38;c.<p>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.<p><i>By the way: here's more than you ever wanted to know about IVs in CBC mode:</i><p><a href="http://news.ycombinator.com/item?id=2029640" rel="nofollow">http://news.ycombinator.com/item?id=2029640</a><p><i>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>

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.<p>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, <i>and</i> you re-use the same key (which you should never do) it's possible to do replay attacks.<p>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?<p>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.

Maybe they just wanted to be compatible with the PS3's version of AES?

If you want the security guys at Apple to hear about the issue, you should file a bug directly with them: <a href="http://developer.apple.com/bugreporter/" rel="nofollow">http://developer.apple.com/bugreporter/</a><p>Then add it in here for the benefit of others: <a href="http://openradar.appspot.com" rel="nofollow">http://openradar.appspot.com</a>

<p><pre><code> "a serious documentation flaw" </code></pre> The all-zeroes IV is documented in the official CCCrypt(3cc) man page at:<p><a href="http://developer.apple.com/library/ios/#documentation/System/Conceptual/ManPages_iPhoneOS/man3/CCCryptor.3cc.html" rel="nofollow">http://developer.apple.com/library/ios/#documentation/System...</a><p>this does not exonerate Apple having made a wrong choice of design.

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

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.