Home > Cryptography, Risk > AES on the iPhone isn’t broken by Default

AES on the iPhone isn’t broken by Default

December 14, 2011

I wanted to title this “CBC mode in the AES implementation on the iPhone isn’t as effective as it could be” but that was a bit too long.  Bob Rudis forwarded this post, “AES on the iPhone is broken by Default” to me via twitter this morning and I wanted to write up something quick on it because I responded “premise is faulty in that write up” and this ain’t gonna fit in 140 characters.  Here is the premise I’m talking about:

In order for CBC mode to perform securely, the IV must remain impossible for the attacker to derive or predict.

This isn’t correct.  In order for CBC mode to be effective the initialization vector (IV) should be unique (i.e. random), preferably per individual use.  To correct the statement: In order for AES to perform securely, the key must remain impossible for the attacker to derive or predict.   There is nothing in the post that makes the claim that the key is exposed or somehow able to be derived or predicted. 

Here’s the thing about IV’s: they are not secret.  If there is a requirement to keep an IV secret, the cryptosystem is either designed wrong or has some funky restrictions and I’ll be honest, I’ve seen both.  In fact, the IV is so not secret, the IV can be passed in the clear (unprotected) along with the encrypted message and it does not weaken the implementation.  Along those lines, there are critical cryptosystems in use that don’t use IV’s.   For example, some financial systems leverage ECB mode which doesn’t use an IV (and has it’s own problems).   Even a bad implementation of CBC is better than ECB.  Keep that in mind because apparently ECB is good enough for much of the worlds lifeblood.

So what’s the real damage here?  As I said in order for CBC to be effective, the IV should not be reused.  If it is reused (as it appears to be on the implementation in the iPhone Nadim wrote about), we get a case where an attacker may start to pull out patterns from the first block.  Which means if the first block contains repeatable patterns across multiple messages, it may be possible to detect that repetition and infer some type of meaning.  For example, if the message started out with the name of the sender, a pattern could emerge (across multiple encrypted messages using the same key and IV) in the first block that may enable some inference as to the sender on that particular message.

Overall, I think the claim of “AES is broken on the iPhone” is a bit overblown, but it’s up to the interpretation of “broken”.  If I were to rate this finding on a risk scale from “meh” to “sky is falling”, off the cuff I’d say it was more towards “meh”.  I’d appreciate this fixed from apple at some point… that is, if they get around to it and can squeeze it in so it doesn’t affect when I can get an iPhone 5…  I’d totally apply that patch.  But I certainly wouldn’t chuck my phone in the river over this.

About these ads
Categories: Cryptography, Risk
  1. December 14, 2011 at 8:41 pm | #1

    I’m not a cryptologist, but I am the maintainer of the Python Cryptography Toolkit (apt-get install python-crypto), so I try to keep up on these things.

    For CBC mode, the IV for each block really does need to be unpredictable, at least at first. Once a block is encrypted, the IV for that block no longer needs to be secret, but it’s important that the IV not be predictable beforehand, or the system loses its security against adaptive chosen-plaintext attacks. For something like PGP, where you encrypt an entire message before revealing any of the ciphertext, you’re right that it’s only important that the IV be unique. On the other hand, a predictable IV is disastrous for HTTPS, a fact that was published in 2006[1] and was demonstrated as a real-life attack against PayPal this September (2011) at Ekoparty in Buenos Aires[2][3].

    What you describe is actually called a “nonce”—a non-secret number that must only be once (hence, “N_once”). If we were talking about counter(CTR)-mode encryption, you would be correct. However, CBC-mode encryption needs an IV that is not just unique: it also needs to be unpredictable by any attacker who can influence the plaintext. This is a subtle difference, but these sorts of subtleties are why cryptography is hard (and fun!).

    Finally—and this is just my own anecdotal observation—it seems to me that a large number of exploitable, cryptography-related security holes have been the result of non-cryptologist developers and/or managers saying “that’s not exploitable” and being wrong. I’m sorry, but cryptography is really hard to do successfully[4], and most of these folks simply aren’t qualified to make statements like that. Our information security would be much stronger if we all started actually following the advice of the world’s cryptologists, rather than ignoring them because we think we know better. We don’t.

    - Dwayne

    [1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=
    [2] http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/
    [3] http://www.youtube.com/watch?v=BTqAIDVUvrU
    [4] Think about it: Every time someone builds a cryptosystem, they’re saying, “I have built a something that nobody in the world is going to be able to bypass—even if they know how the system works, even if they’re really clever, even if they get help, even if they have money, and even if they’re all FROM THE FUTURE.”

    • December 14, 2011 at 9:05 pm | #2

      Dwayne Litzenberger :
      For something like PGP, where you encrypt an entire message before revealing any of the ciphertext, you’re right that it’s only important that the IV be unique.

      Oops, actually, no, the IV needs to be unpredictable then, too.

  2. December 14, 2011 at 9:55 pm | #3

    @Dwayne, Great Response and thank you!
    Could you think up an example on an iphone of an adaptive chosen plaintext attack? Wouldn’t an attacker need to inject the plaintext and then get at the cipher text in order to be successful and all done inside the iphone?
    If I understand what you’ve stated (and I could be totally off here) but it’s not so much that the IV is predictable, but reused (which means it is then predictable). And in order for that attack to be successful, the attacker would have to leverage the phones application and use of the key (which is never disclosed) and its reused/predictable IV in order to conduct the attack. Plus, it would require a brute-force (chosen-plaintext) on the target message on block at a time… on an iphone. I think I understand that and thanks for bringing that up, I hadn’t thought through that this morning.
    I would agree this is a sub-optimal implementation of the CBC mode in AES. However, I would also say that this does not present any practical risk to iphone users and Apple has plenty of time to fix this. But I’m going off of several assumptions (and admittedly no idea how iphone is applying AES internally), so I hope more research is done on this.

    As you’ve mentioned, cryptography is really stinkin’ hard. But it’s also a double-edged sword. It is entirely possible to toss the baby out with the bath water in cryptography and focus on fixing a sub-optimal implementation that would still prevent 99.9% of the attackers, when other things are left unfixed. Could this be vulnerable to that .1%? Sure, but the cost to the .1% makes attacking my angry-birds machine unlikely.

  3. December 19, 2011 at 8:27 pm | #4

    I think the mark was missed on this one. The author is more-pointing out that Apple states that you can leave the IV blank, which will result in all zeros being placed:

    “When using CBC mode, an Initialization Vector (IV) is provided along with the key when starting an encrypt or decrypt operation. If CBC mode is selected and no IV is provided, an IV of all zeroes will be used.”

    This is the fail – because the IV will be well know and not randomized or unpredictable making replay possible. AES CBC isn’t broken – Apple’s documentation and stance on implementation is. *That* is the problem and the original point of the linked document.

Comments are closed.

Get every new post delivered to your Inbox.

%d bloggers like this: