
AES on the iPhone is Broken by Default - magikarp
http://log.nadim.cc/?p=58
======
tptacek
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"._

~~~
exDM69
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.

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

~~~
tptacek
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.

Sorry for the pedantry.

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

~~~
tptacek
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.

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

------
daniel02216
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>

~~~
tptacek
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

      "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...](http://developer.apple.com/library/ios/#documentation/System/Conceptual/ManPages_iPhoneOS/man3/CCCryptor.3cc.html)

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

~~~
marshray
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.

------
markgamache
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

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

