Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Any iOS device with a bootrom exploit (so, all iPhones except the iPhone 4S, currently) can have their passcode lock wiped with a simple ramdisk. I'm almost tempted to make a tool that does it - but I don't know who I would be helping.

Yeah, iOS security is pretty good in some areas, but it's far from perfect. Jailbreak exploits are commonplace, and many of them could even be used for zero-day access to the device.
 
Apple doesn't know what your 4-digit passcode is, so there's no way thay can tell you what it is.

----------



Unless you have information on your iPhone worth enlisting the use of a quantum computer for several weeks or months, I wouldn't work about it.

Well, those Cheezburger people have near infinite resources, but I don't want them cracking my phone to get my cat pictures. :D
 
Not to be picky, but "a device with an eight-digit passcode could take up to 15 years to compromise" does not equal 'unbreakable'.
And the security/complexity of the lock-screen password is inversely proportional to the likelyhood that one will actually be used.
Still, good that they're using strong AES.
But passwords aren't the solution.

Someone figured out my password, so I had to change my dogs name.
 
Not true. Blackberries, yes. Android, no, until 4.01 or later, as far as I know. Even then, it's optional. You have to perform additional steps to enable it.

4.0.1 was released in October 2011, same month and year that iOS 5 got released which introduced the passcode lock feature (which is also optional), which we are discussing here.

However the ability to encrypt all data was introduced in Android 3.0 - a tablet only version of the OS of course.

So I'm not sure what is "not true" about my statement.
 
4.0.1 was released in October 2011, same month and year that iOS 5 got released which introduced the passcode lock feature (which is also optional), which we are discussing here.

However the ability to encrypt all data was introduced in Android 3.0 - a tablet only version of the OS of course.

So I'm not sure what is "not true" about my statement.
I know nothing about Android history.

But iOS5 just introduced improvements. v4 introduced decent encryption, and passcodes were in place well before that.
 
I know nothing about Android history.

But iOS5 just introduced improvements. v4 introduced decent encryption, and passcodes were in place well before that.
No. The encrypted passcode lock feature was introduced in iOS5.

----------

Right and wrong.

Yes, with OTP, a brute force attack would eventually uncover the plaintext. However, the thing with OTP is that the return of the original plaintext is no more or less likely than the return of any other equivalent length string.

For example, of the plaintext is "The car was green," brute forcing an OTP cypher will eventually return "The car was green" but is equally likely to return "Our son has drugs", "Her dad has aids." "The PCP has moved" "The hit was done." or any one of countless, equally non-trivial phrases. This is in contrast to non-OTP cyphers where it's rather obvious that recovered plaintext that makes any kind of sense is probably a successful decryption.

This, probably more than anything, makes OTP, not worth the brute force. Coupling OTP with code phrases makes it even less worth the trouble because without the meaning of the code phrases, or even a list of code phrases, one has no idea if they've recovered a code phrase or just some other sentence.
If we know nothing about the encrypted message, it is simply not possible to "brute force" an OTP cypher. It's not just "not worth it", it's not "hard" nor "laborious" nor "time consuming", it's simply not possible since we have no way of determining that we have encountered the encrypted message in the process.

It's as if I told you that my secret message is a hundred characters long and then refused to tell you whether you guessed it or not. Unless of course you brute force me with a blunt weapon, that might achieve better results.
 
No. The encrypted passcode lock feature was introduced in iOS5.
You must be talking about something pretty specific. The encryption hardware was in the 3gs, and the first run at decent software to match was in 4.0. 5.0 is better, not original.
 
Will Apple phone tech support tell you your key if you give them your home address and last 4 digits of your credit card number?

If you are talking about your pin code the article says its hashed which means Apple doesn't know it.
 
Last edited:
They are probably assuming the memory is removed from the device, so the operating system is not running, hence unable to start the wipe process.

----------


There must be a water boarding app for that. :)

Since the article states that the brute force would have to be done on the device itself. I just assumed it would have to be on and running therefore able to lock down. If that is the case it would be quite secure even with a mediocre password.
 
Any iOS device with a bootrom exploit (so, all iPhones except the iPhone 4S, currently) can have their passcode lock wiped with a simple ramdisk. I'm almost tempted to make a tool that does it - but I don't know who I would be helping.

Yeah, iOS security is pretty good in some areas, but it's far from perfect. Jailbreak exploits are commonplace, and many of them could even be used for zero-day access to the device.

Um, yeah, but the user has to jailbreak the device. So if they do they can only blame themselves for the consequences. Also Jailbreaking will not give you full and total access as it does on Android phones which are basically wide open.

----------

Not to be picky, but "a device with an eight-digit passcode could take up to 15 years to compromise" does not equal 'unbreakable'.
And the security/complexity of the lock-screen password is inversely proportional to the likelyhood that one will actually be used.
Still, good that they're using strong AES.
But passwords aren't the solution.

Which is exactly what Apple says. Or more like they are part of the solution but not the whole thing. Read the article you are commenting on.

----------

So Apple is using AES. Big deal. Most systems are not cracked by breaking the encryption algorithm, but by exploiting weaknesses in key management. XBOX, PS3, Bluray, iCloud, FileVault are notable examples where the best encryption algorithm in the world wouldn't have changed anything.

*sigh*
Read the article. You are missing the point. Also they are not just using AES but AES 256 and many other phones do not in fact use AES 256 or to the extent Apple does. Google certainly doesn't.

----------

The 256-bit AES key and the passcode are not the same thing. The security system is layered. One is on top of the other.

The AES system is truly not breakable. But the passcode can be easy or hard depending on the code. I bet most phones are set to "1234"

Exactly. Someone who actually read and comprehended the article before commenting. Nice.

----------

And yet tools like MacLockPick can extract the information from iOS devices.

Additionally, this is the same encryption used by OS X yet the government can crack it in a matter of minutes.

Wrong on both.
http://blog.cocoia.com/2007/debunking-maclockpick/
Also state your source for your second highly incorrect statement. Wait, before you do that read the article you are commenting on and understand the two step process in place by Apple.

----------

Not true. Blackberries, yes. Android, no, until 4.01 or later, as far as I know. Even then, it's optional. You have to perform additional steps to enable it.

Also Android encryption doesn't encrypt everything. If it did they wouldn't be able to follow peoples data and movements which is the purpose of Android existence in the first place.
 
Big deal. Most smartphones use encryption.

Moreover:


That's not true.

Direct quote from Apple's white paper:


An eight-digit passcode would "only" take 92 days to compromise. A four-digit passcode (from my experience the most popular one) would only take 13 minutes to compromise.

"a device with an eight-digit passcode could take up to 15 years to compromise." You say it's not true. Did you notice the word "could" was used and not "would"? Since we're using the word would. How long would it take to compromise an 8 digit alpha-numeric, uppercase/lowercase password?
 
Any iOS device with a bootrom exploit (so, all iPhones except the iPhone 4S, currently) can have their passcode lock wiped with a simple ramdisk. I'm almost tempted to make a tool that does it - but I don't know who I would be helping.

Wiping the passcode will not decrypt the NAND. In fact, you risk breaking the decryption of the NAND in normal operation, resulting in a bricked device. So what good would wiping the passcode do you ?

This is essentially talking about Filevault for iOS.
 
*sigh*
Read the article. You are missing the point. Also they are not just using AES but AES 256 and many other phones do not in fact use AES 256 or to the extent Apple does. Google certainly doesn't.


AES 256 is simply AES with a key size of 256, it's still AES, so saying that they're not using AES is highly inaccurate. And what makes you so certain that Google doesn't use it?

----------

"a device with an eight-digit passcode could take up to 15 years to compromise." You say it's not true. Did you notice the word "could" was used and not "would"? Since we're using the word would. How long would it take to compromise an 8 digit alpha-numeric, uppercase/lowercase password?

Where I come from, digit is any of the numerals from 0 to 9. A character can be alpha-numeric.
 
Also Android encryption doesn't encrypt everything. If it did they wouldn't be able to follow peoples data and movements which is the purpose of Android existence in the first place.

Hum, tracking doesn't require decrypted data. Once the user is using the phone, applications have access to the encrypted data just fine. To the application, it's just making normal syscalls to read and write files it can access, like for the browser to set and send tracking cookies, etc..

----------

AES 256 is simply AES with a key size of 256, it's still AES, so saying that they're not using AES is highly inaccurate. And what makes you so certain that Google doesn't use it?

Apparently, Google uses AES with a key size of 128 bit. Source.
 
Any iOS device with a bootrom exploit (so, all iPhones except the iPhone 4S, currently) can have their passcode lock wiped with a simple ramdisk. I'm almost tempted to make a tool that does it - but I don't know who I would be helping.
Of course, any software or user exploit that runs while the device is unlocked can do anything on the device, at the very least read all data from it.

----------

4.0.1 was released in October 2011, same month and year that iOS 5 got released which introduced the passcode lock feature (which is also optional), which we are discussing here.

However the ability to encrypt all data was introduced in Android 3.0 - a tablet only version of the OS of course.
And what percentage of Android devices can run 4.0.1 or later? And what percentage of iPhones can run iOS 5 (about 85%)?
 
Eight binary digits or Eight decimal digits?

Eight decimal digits ~ 34 binary digits. => 2^34 probably keys.

So according to the rootN formula, on an average it would take approximately 2^17 trials to find the random key. This is such a small number that I maybe able to crack in a matter of days and not 15 years.

Moreover, if the encryption was so hard that a brute force attack took 15 years, I would call it 'unbreakable' as there is no perceivable way to break the encryption for a forceable future.

One big pile of bad maths.

Eight decimal digits = 100,000,000 choices. 2^34 is about 172 times more.

On the other hand, what "rootN formula" are you dreaming about? With 100 million choices, and no idea which of those 100 million choices was used, you'd need to test on average 50 million choices. And the algorithm that converts password to decryption key is designed to take about 1/20th of a second, for a total of 2.5 million second or about one month. That's how long 8 decimal digits take to crack.
 
"The algorithm is so strong that no computer imaginable for the foreseeable future..."

Humans have a bad record of "imagining" what computers will be capable of doing. Also, what happens after the foreseeable future? Imagine that.

There are unbreakable physical limits. Quantum physics gives a lower bound for the amount of energy needed to do _anything_. Multiplied by 2^256 you get a number that is enormously larger than the mass of the entire universe converted to energy according to e = mc^2. If it takes 2^256 operations to break encryption, then it cannot be broken.
 
And what percentage of Android devices can run 4.0.1 or later? And what percentage of iPhones can run iOS 5 (about 85%)?

20%, that's native OS support, many manufacturers such as Motorola have their own encryptions systems on their phones (e.g. Motorola uses SHA-256) which increases that percentage (but probably still lower than the 85%).

However one cannot say Android phones are not encrypted.
 
And what percentage of Android devices can run 4.0.1 or later? And what percentage of iPhones can run iOS 5 (about 85%)?
There's a difference between "can and "do".
"Can"... a lot of them.
"Do"... not very many. (approx. 16%) Source

4.0.1 will run on an original Nexus just fine, which is not a very powerful device by today's standards.

Still trying to figure out how you came up with the 85% number for iOS other than pulling it out of your rear.

Apple has only made 5 iPhones (Original, 3G, 3GS, 4 and 4S)
Only the 3GS,4 and 4S can run iOS 5.
That means only 60% can run iOS5. ;)
 
Actually it does

Not to be picky, but "a device with an eight-digit passcode could take up to 15 years to compromise" does not equal 'unbreakable'.
Actually it pretty much does. Your working on a logarithmic scale so adding one more digit would take an average of several centuries. Much longer than the device could function. And a nine digit code isnt very hard to remember. Therefore it is unbreakable unless you enter the right pass code by shear luck. By the way there is no other form of security. Everything is at its core just a a pass code key to the encryption.

Of course no encryption method could ever be completely unbreakable but no form of security ever is. You simply have to make it harder to break than it's worth. In this case it would simply take longer than any information stored on the device could be useful.
 
Still trying to figure out how you came up with the 85% number for iOS other than pulling it out of your rear.
Very simple. All iPhones from the 3GS onward have the necessary hardware for device encryption and run an OS that supports it (duh, no point putting in the hardware if the OS does not support it).

And thanks to the current trial, we have detailed sales numbers. I did not dig down deep enough to get the precise numbers but this here is good enough for a rough number:
https://www.macrumors.com/2012/08/10/apple-and-samsung-reveal-u-s-mobile-device-sales-in-court-case/
All sales up to the second quarter of 2009 are the original iPhone and the 3G (minus a million or so of 3GS sales at the end of June 2009), ie, devices without encryption, all sales since (minus a million or so of iPhones 3G sold until June 2010 as entry level model) are of models that support device encryption.

That is 14.455m without encryption out of a total of 88.956m iPhones (I added 3m for half of the current quarter). That is 84% that support encryption. We can probably quibble about a percentage point or two but that should be roughly it.
 
Last edited:
If you are talking about your pin code the article says its hashed which means Apple doesn't know it.

Kind of funny apple can kill any program from your device (kill switch). So if our iPhone is so secure, how can apple remote kill a program? Apple and the rest of any company who use encryption has a master key.
 
AES 256 is simply AES with a key size of 256, it's still AES, so saying that they're not using AES is highly inaccurate. And what makes you so certain that Google doesn't use it?

----------



Where I come from, digit is any of the numerals from 0 to 9. A character can be alpha-numeric.

Good one! But... how long would it take to compromise
an 8 "character" alpha-numeric , uppercase/lowercase password?
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.