AES on the iPhone is Broken by Default

http://log.nadim.cc/?p=58

by magikarp • 15 years ago

39 25 15 years ago

log.nadim.cc

zbowling• 15 years ago

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

tptacek8• 15 years ago

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:

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".

magikarp2• 15 years ago

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.

tptacek8• 15 years ago

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.

exDM692• 15 years ago

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.

tptacek8• 15 years ago

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.

JoachimSchipper• 15 years ago

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.)

soc88• 15 years ago

Before clicking on „comments“ I wondered how long it would take the John Gruber brigade to declare it non-relevant.

Thanks for answering my question.

maksoorah• 15 years ago

The author is also the creator of crypto.cat. I think he knows what he is talking about.

marshray3• 15 years ago

I looked at the source to crypto.cat and, in the politest possible way, I wish to disagree.

exDM692• 15 years ago

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.

tptacek8• 15 years ago

The article had a linkbait title, to be sure.

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.

daniel02216• 15 years ago

If you want the security guys at Apple to hear about the issue, you should file a bug directly with them: http://developer.apple.com/bugreporter/

Then add it in here for the benefit of others: http://openradar.appspot.com

tptacek8• 15 years ago

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.

program• 15 years ago

  "a serious documentation flaw"

The all-zeroes IV is documented in the official CCCrypt(3cc) man page at:

http://developer.apple.com/library/ios/#documentation/System...

this does not exonerate Apple having made a wrong choice of design.

marshray3• 15 years ago

Yes, it does. (IMHO)

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.

wildmXranat• 15 years ago

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.

markgamache• 15 years ago

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

AES on the iPhone is Broken by Default

Related Stories