The encryption hasn't quite been cracked. This tool is just brute-forcing the passcode, which by default is 4 digits long, so it wouldn't take that long to brute-force that anyways.
Also, the tool seems to perform an online attack with the phone connected, which means that Apple will be able to stop this from going on.
Seing that only an online attack can be done hints at the fact that the key derivation method that turns the 4 digit passcode into the AES key isn't known (yet).
I'd say that you are (still) pretty save if you use the longer password instead of the passcode and as long as the tool requires the phone to be connected, we can count on Apple patching the issue.
It's funny how these articles always talk about having "cracked the AES encryption" when all they do is brute-forcing a password.
Limiting your keyspace to 10000 combinations is insecure, there's nothing more you need to say really.
The difference between the simple passcode and the complex password is the difference between a little padlock and a vault door. It shouldn't be news, except that the fundamentals of encryption aren't well-known by the public.
You can use a longer alphanumeric pass code if you'd rather, it's an option in settings.
As with all security convenience is played off against security. For most people (who in reality aren't likely to be targeted by such an attack and aren't storing much in the way of critical data on their phones) a four digit pass doesn't seem completely unreasonable.
On top of that, a lot of companies have the requirement that once you hook up your corporate exchange to your iPhone, you have to have a >4 digit password (as in the iPhone forces you to change to a longer password)
Exchange can also enforce a shorter time limit before the phone auto-locks. One of the reasons I was glad to dump the Exchange account from my phone when a client project ended.
It's not just the passcode they are recovering. That recovery requires the phone, but there's also the key reocvery and bit-to-bit image copy. The ElcomSoft describes the 3 statges:
- Extract hardware-dependent keys, file system keys and escrow keys from the device;
- Recover the passcode (subject to passcode length and complexity);
- Obtain bit-to-bit copy of device storage.
When an iPhone 3GS or newer iOS device wipes itself, it clears the key out of a protected memory area that's not accessible to iTunes, so that re-loading the bit-for-bit copy won't work.
This is why I'm happy that Android has some interesting password entry mechanisms that only exist for the iPhone in the jailbreak arena.
Apple really needs to embrace a non-PIN style password and make a way to login that's not a pain in the ass. A friend has an iPhone with a 9-character pass.. it's secure but impossible to use since it takes about 10 seconds to unlock each time... if the user can't be bothered to put a master password because it's not usable to do so, then it almost doesn't matter if there's hardware encryption anyway.
Compared with Google, Apple's views on security are weak. It's like comparing Google's "customer support" to Apple's... demonstrably weaker.
But Android is still converting those gestures to something that's basically a key which can be exposed to a brute force attack.
Android uses a nine cell unlock pattern which gives you roughly 16 bits. A four digit numeric key gives you between 13 and 14.
So while it's better it's not moving it into the realms where a brute force attack of this nature is off the table, it just goes from about 40 minutes to about 4 hours.
Given that in most instances where this sort of attack is being used the attacker will have stolen the phone and therefore there's no practical time limit, that's not a useful improvement.
How many swipes are required to unlock your Android phone? Is there an upper limit? Also, how many hot spots are there on the screen (I assume it's not a free-hand gesture...)?
The swipie unlock that every Android phone I've seen in practice could be represented as a four digit number (actually less, since there's no zero and no repeats IIRC). The only difference I can see between a swipe and a digit is you hold your thumb down and it looks more futuristic.
I don't think that this is brute-forcing the passcode at all, rather I think it is brute-forcing another method to locking the iPhone, namely that of iTunes...
iTunes has a special file on your computer that when you plug in your phone will allow it to start syncing data to and from your phone (including making backups) without requiring you to unlock it.
What I believe they are doing is actually brute-forcing the required entry code for that. Once you get that code (and there is no limit to how many times you can try) you get full access to the phone, including that bit-for-bit copy they are talking about.
Apparently the key space is small enough that it is easy enough to brute-force.
In that case it doesn't matter what kind of protection you use, whether it is the pass code lock, or the alphanumeric that they introduced on the iPhone 4 (IIRC).
Note that all of this is speculation, I have no inside knowledge, but that is how I would go about attacking the iPhone.
So... you can use brute force to break encryption? Is that news? It doesn't sound like there was any security hole in the implementation or a leaked cryptographic key, so in what sense is the encryption "cracked"?
I think it is more that someone is now selling a purpose-built software solution to brute force iPhones, that governments and other interested parties can buy.
Seems to me that the maxim 'put nothing on the internet that you don't want exposed' should be applied to cell phones as well. Given the decreasing protection provided by the courts, this sort of tool will be used more and more often. Those who talk of unreasonable search and seizure need to pay attention to today's realities.
put nothing on the internet that you don't want exposed
IMHO, it's not the exposure I'm worried about, but the discrimination that follows. Getting drunk at a party and posting pictures on Facebook should not be grounds for you getting rejected at an interview.
Also, talking about exposure, companies that found/asked for my social security number or home address, then exposed it on the Internet, should not be surprised when I sue them for huge amounts of money (I'm doing it right now and the only question is how much money I can win).
"Getting drunk at a party and posting pictures on Facebook should not be grounds for you getting rejected at an interview."
I agree with the OP - If you don't want to be discriminated against, keep it off the internet, or it can be used against you.
The only exceptions that I can think of would be those aspects that are considered "protected" - I'm in the rather liberal (but at-will-employment) California, so that includes (at last count, they've probably added more, "age (if over 35), ancestry, color, race, sex (gender), religion, national origin, marital status, physical or mental disability, medical condition, or sexual orientation." - Everything else is fair game. And certainly, drunk pictures of you on facebook would fall within the realm that an employer might reasonably discriminate against you.
If you don't want it used against you, don't place it on the internet, despite the level of protection/encryption/privacy policy you think you have protecting you. The elcomsofts of the world are likely to make your private information less so more quickly than you would think.
>Getting drunk at a party and posting pictures on Facebook should not be grounds for you getting rejected at an interview.
it just provides additional information about you - type of drinks, environment, your friends/girls ... - i mean looking at some pictures one may want to join the party, while looking at others - "thanks, no".
It would seem that this "crack" could simply be circumvented by using an alphanumeric password and/or setting the iPhone to shred its crypto key after 10 consecutive password failures. Obviously, neither of these are standard features, but both are available.
> setting the iPhone to shred its crypto key after 10 consecutive password failures
This seems to do decryption on its own, so this setting wouldn't have an effect. If you have the data sitting there and have the encrypted key, there's nothing stopping you from directly decrypting the key with every possible passcode and checking it for validity.
Why does the iPhone talk to anything on the data port without entering the passcode first?
It seems like this is reading the encrypted data and then brute forcing it, but there's no need to give access to even the 'secure' data without asking the user to enter the passcode. Then you can check for 10 incorrect codes and wipe the device if necessary.
(I believe this is how the Blackberry handles things)
I was under the impression that not all user data is encrypted on an iOS 4 device, mainly just the user data of apps from Apple that are included with the device.
Does Apple's iOS provide for encryption of all user data? Or is it the case that the app's developer has to avail himself of an API to make this happen?
Correct, although Apple does provide an API to use the hardware encryption. Most apps do NOT use it.
If you're paranoid, you can make most data reasonably secure by using the built-in apps and apps like StashPro (which does use the hardware crypto API). This includes putting a decent length password, which is also hard to use.
Full-device encryption backed by hardware would be really great. IIRC, that's not possible on either iOS or Android right now (not sure about other platforms).
Does it mean anything for the Ipad 2 Jailbreak ? I'm confused...
It seems the encryption keys are in the chip in these Ipads, so I wonder if this article means that they could get the keys from the hardware ? If so, how is it related to an OS in particular ?
Of course, I meant, hopefully a successful remote wipe will prevent this method from working. (A number of things could go wrong, including no signal, MobileMe being down, etc.)
Also, the tool seems to perform an online attack with the phone connected, which means that Apple will be able to stop this from going on.
Seing that only an online attack can be done hints at the fact that the key derivation method that turns the 4 digit passcode into the AES key isn't known (yet).
I'd say that you are (still) pretty save if you use the longer password instead of the passcode and as long as the tool requires the phone to be connected, we can count on Apple patching the issue.
It's funny how these articles always talk about having "cracked the AES encryption" when all they do is brute-forcing a password.