Apple’s iOS 4 hardware encryption has been cracked(geek.com)
geek.com
Apple’s iOS 4 hardware encryption has been cracked
http://www.geek.com/articles/chips/apples-ios-4-hardware-encryption-has-been-cracked-20110525/
10 comments
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.
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.
It doesn't limit it to that, it defaults to that.
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.
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.
- 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.
Isn't there this setting that says "wipe my iPhone after ten failed attempts"? I imagine that would be quite an effective solution.
Is there a way to copy the data on an iphone bit for bit before trying to guess the passcode?
If it gets wiped, just reimage and start where you left off.
If it gets wiped, just reimage and start where you left off.
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.
But couldn't you copy that memory as well? Eventually the 1's and 0's are crossing a bus somewhere and you don't need iTunes for that.
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.
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.
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.
[deleted]
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.
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
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.
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.
On that matter, I had a list of bad practices in HR that cause most of the problems here:
http://news.slashdot.org/comments.pl?sid=2082332&cid=358...
>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 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.
I guess that by "neither of these are standard features" you mean "not on by default". It's two clicks in settings to turn these on.
> 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.
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)
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)
Will this also work if one has his iPhone set to delete its crypto keys after 10 failed attempts?
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?
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).
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 ?
Hopefully Remote Wipe will still work by shedding the keys altogether.
Remote wipe wouldn't work if network access was disabled.
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.