Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple's 'Unbreakable' iOS Device Encryption Highlighted
- Thread starter MacRumors
- Start date
- Sort by reaction score
Please see after the quote below.
Could you please be less condescending? If I have a particular formula, simply ask where I got it from, rather than asking me if I'm dreaming about? Never mind, see below.
As far as the maths is concerned, I apologize. I didn't do log_2{100000000} as I don't know how to calculate log base2 values in spotlight. I simply kept dividing 100000000 by 64 which I treated as 2^8 instead of 2^6. See my edit in the first post in case still unclear. Sorry about that.
As for the rootN formula —, it's essential to understand why we take half of the key space.
In general if an element can take on N different values, then one can expect a collision after choosing about sqrt(N) random elements. Here we talk about n-bit values. For an n-bit value, N = 2^n, i.e. 2^n possible values for the key. Therefore, we need almost sqrt(2^n) = 2^(n/2) elements in the set before you can expect a collision. This is also called 2^(n/2) bound.
EDIT: + You'd be wrong about 50 million choices to be tested if there are a total of 100 million choices. Where did you get that from? Please cite if possible? As far as I know — it's always testing on an average 2^(n/2) values if the key space is n bits.
What you are saying is that of the possible 2^n values, one tests (2^n)/2 = 2^(n-1). I have never seen that before. In case you can link me to somewhere I can read about this? Thanks.
Last edited:
Could you provide a citation to the rootN formula and/or why it is relevant to the problem? What you're suggesting is that if I choose a random number between 1 and 100, you could "expect" the right answer in 10 guesses. How? It doesn't matter if I search these 100 elements randomly or in order, I'd still be averaging 50 guesses before I got the correct answer.
I'm struggling to find any real citations for this but this Wikipedia article (last sentence of "Entropy as a measure of password strength") says it will take on average half the possibilities. A more practical example is this article that's collated the results of a number of brute force attacks on keys. In each cases around 50% is searched, and never less than 22.2%.
Last edited:
Removing memory from the device wouldn't work because every device use different AES key stored in AES chip. The chip is designed so it breaks (deletes the key) when compromised (e.g. removed from the device).
+1
Wow.
I couldn't be more wrong. Kind of pathetic I feel right now.
I'm afraid, please disregard my post. I will eventually follow with a rootN explanation but it surely doesn't apply here. Probably to a birthday attack but I guess I'm out of touch and need to brush up a bit.
Sorry.
Wow.
I couldn't be more wrong. Kind of pathetic I feel right now.
I'm afraid, please disregard my post. I will eventually follow with a rootN explanation but it surely doesn't apply here. Probably to a birthday attack but I guess I'm out of touch and need to brush up a bit.
Sorry.
Really 15 years?
"using optimised cracking tools such as the Elcomsoft iOS Forensic Toolkit a four digit PIN can be cracked in as little as 8 seconds"
http://www.scmagazineuk.com/mobile-security-an-update/article/250033/
Once the PIN Code is entered; you have access to all the data on the device anyway.
Plus with iOS you could use the Escrow Keybag exploit which allows you to clear a users passcode.
From:
http://blog.nightlionsecurity.com/news/2012/05/iphone-forensics-analysis-of-ios-5-backups-part-1/
"Escrow Keybag attack bypasses theiPhone data protection mechanism and allows decryptingevery file on the device without requiring theusers passcode. Escrow Keybag is a copy of theSystem Keybag and contains a collection of protectionclass keys that are used for data encryption on theiPhone."
Plus with iOS you could use the Escrow Keybag exploit which allows you to clear a users passcode.
From:
http://blog.nightlionsecurity.com/news/2012/05/iphone-forensics-analysis-of-ios-5-backups-part-1/
"Escrow Keybag attack bypasses theiPhone data protection mechanism and allows decryptingevery file on the device without requiring theusers passcode. Escrow Keybag is a copy of theSystem Keybag and contains a collection of protectionclass keys that are used for data encryption on theiPhone."
There is a world of difference between a 4 digit PIN and an 8 digit PIN. A single digit PIN would have 98 possible codes. With up to 4 digits, the possibilities are 98^4 + 98^3 + 98^2 + 98, or about 93 million possible codes, so you would have to make an average of 46.5 million guesses to get the correct code. With an 8 digit PIN, there are 8.6 quadrillion (10^15) possible codes, nearly 100 million times as many possibilities, so 4.3 quadrillion guesses would be needed on average to crack the passcode.
Of course, it could be cracked on the first guess, to "unbreakable" could be considered to be a relative term, although the probability of this happening is almost infinitesimal.
I'm wondering how all of this PIN cracking software bypasses lockout. My son forgot the PIN on his iPod, and after about 20 attempts, he can't get into the iPod at all (requires connection with iTunes due to lockout, but iTunes says it can't be accessed because it's locked out).
Last edited:
I don't understand why you're asking me to do the math for you but:
26 lower case letters + 26 uppercase letters + 10 numerals = 62 characters
Assuming an 80ms iteration.
62^8 * 80ms ~= 553514.257 years
Your point being?
Symbols are also allowed, and spaces, so a total of 98 characters are possible for each digit of the passcode.
He asked for alpha-numeric, upper & lower case, so what's allowed is irrelevant.
What AES does in most implementations is effectively one-time-padding thanks to block chaining, input vectors etc. So the belief that one-time-padding is "unbreakable" is likewise untrue, as when AES is used properly each block should appear different, even if they contain identical data.
If you're assuming that the key (and input vector if used) is secret for a one-time-pad then you can assume the same thing of AES. In both cases the time required to brute force the decryption is based on the length of the key(s) used, and whether or not you are able to test for the data having been decrypted; for example if you know a drive is an encrypted HFS+ volume then you'll look for the HFS format after each key you try.
I mean, practically speaking this is "unbreakable" if the key is so long that it isn't worth trying every combination. But even so there's always the freak possibility that the first key a hacker tries is the right one, as it's not always safe to assume that a 128-bit key is going to require 2^128 operations to guess.
The only way to ensure cryptographic security would be encrypt using an secret combination of cryptographically secure (truly random) algorithms and keys, or invent a unique one of your own, then kill everyone that knows those keys and/or how the system works, but then, the value of such a technique would be fairly dubious
I think that for all intents and purposes AES-256 is as secure as any system can reasonably be at a low-level for now. After that it is purely a high-level challenge, i.e - getting users to pick sensible passwords, not share them etc.
Last edited:
Good to know, but do you need the key? Brute force attack is trying every possible combination anyways. If the phone is left intact, won't OS wipe the device after 10 wrong guesses?
In the strict sense of the term, you are correct. I was merely expanding on the definition to illustrate the reality of the situation (i.e., you are not restricted to alphanumeric code).
I'm not sure what you're trying to say.
We can't really compare AES and OTP. Of course we should assume that the key is secret for both, but while you would be guessing the key for AES, when it comes to OTP you would be basically guessing the plaintext message (assuming you would be using it correctly, i.e. the key is the same size or bigger then plaintext).
So AES is possible to crack, OTP (if used correctly) is not.
My point was that nothing is "unbreakable"; OTP, like AES, is only as strong as the key that was used, as any cryptographic key can eventually be broken by trying every permutation of value with the same length as the key.
OTP's only real difference is that it's so simple that it can shown that know weakness in the basic method exists (provided a truly random key etc.), but that doesn't make it unbreakable.
As I say though, AES with block chaining is effectively as secure as a full-length one-time pad; indeed, if that key is only used once then the effect is pretty much the same, except that an AES key of course can encrypt longer data, without effectively requiring twice the space.
The best that any encryption algorithm can do is make it unlikely that the key will guess within the useful lifetime of the data. If the data contains a credit card number for example, then most cards expire in 3-4 years, so any encryption that (should) take longer will make it unfeasible to even try to decrypt it.
It's also worth remembering that regardless of the length of the key, it's always possible that a system could guess the correct key first time, i.e - if a truly random number generator can produce a key of zero, and your brute-force program starts guessing from zero, then the unlucky person who randomly got a key of zero would be screwed silly example perhaps, but a 128-bit key only means the chance to guess it is 1 in 2^128, it doesn't guarantee that it will take 2^128 operations to do-so.
Anyway, that's all really besides the point; AES-256 hasn't had any viable attacks on its algorithm (aside from faults with particular implementations) so it should be more than adequate for the time being, until computers progress to the point that they can trivially break 256-bit keys of course. The weak point as a result is always going to be the user password used to protect (or generate) the encryption key, as the chances of guessing that are pretty much always going to be lower than the chance of guessing the key itself; no matter that you could guess it first time, the possibility that it will take the full 2^256 attempts, or even somewhere in the middle of that, means it's not worth it.
It mentioned in the article link
"Even with MDM in place, if a jailbreak is available for the iOS and hardware version, there is the potential to capture a forensic image of the device. That's where attacks get interesting. While you're usually limited to brute force against a PIN, instead of the MDM locking out after x number of strikes and wiping local data, you simply brute force the image instead. After, say, four attempts, you automatically reload the image and continue cracking."
And how would a collision help you cracking a password? With 100 million possible passwords, if I write down 10,000 possible passwords, and you write down 10,000 possible passwords, then yes, two passwords are likely to match. However, your iPhone only has one password.
No, the user doesn't have to do anything. This can be done on an un-jailbroken, regular device. What I'm talking about is a vulnerability where an attacker (with physical access to a phone) can remove a passcode from a pre-4S iPhone (until someone comes up with a bootrom/iBoot exploit for newer devices) by rebooting the device into DFU mode and running a simple ramdisk. Like this article acknowledges, on the iPhone 3GS and iPhone 4, this requires brute-forcing the passcode, but with most passcodes this takes a matter of minutes. This is a huge security risk, and cuts through many of the security features that are flaunted in this article. In fact, a similar technique could be used to just copy all of the data from the device. Once the password is gone, when an iOS device is booted - whether normally or via ramdisk - the data partition is automatically decrypted on-the-fly and all of the user's data is completely available (unless additionally encrypted).
What are you talking about? Wiping the passcode would allow you direct access to the device. Once you get rid of the password, you can just slide to unlock, and there you have it: complete access to the device's contacts, mail, calendars, notes, and anything sensitive. And like I said above, the exploit used to wipe the password also decrypts the NAND.
See also: http://msftguy.blogspot.com/2010/07/data-recovery-not-just-for-iboot-pwned.html http://msftguy.blogspot.com/2012/01/automatic-ssh-ramdisk-creation-and.html http://code.google.com/p/iphone-dataprotection/
Last edited:
No. You're wrong.
The whole premise of OTP makes it unbreakable. You cannot brute force it. It has nothing to do with the key being strong (?), because you simply cannot guess the key. It's impossible. If you guess the key, it means that you know the encrypted message in the first place, because otherwise you cannot tell that you found the key!
Do you understand how it works? If you learn cryptography at university, OTP is presented as an example of an unbreakable encryption method. It is quite logical actually.
EDIT:
But don't take my word for it, read about it:
http://www.ranum.com/security/computer_security/papers/otp-faq/
http://www.pro-technix.com/information/crypto/pages/vernam_base.html
http://www.cryptomuseum.com/crypto/otp.htm
http://www.aspheute.com/english/20010924.asp
http://keithwiley.com/mindRamblings/unbreakableEncryption.shtml
OTP is unbreakable. No buts. If you want, I can explain it to you.
Last edited:
It's unbreakable. Doesn't mean it hasn't been broken. "In the 1930s and 1940s, The Soviet Union was using one-time pads to encrypt messages sent to diplomatic missions throughout the world. In 1942, the Soviet crypto center accidentally printed duplicate copies of one-time pads. US cryptanalysts discovered this flaw in 1943 and were able to extract information from many messages sent between 1942 and 1948. [CIA]"
Well, it wasn't used properly, so you can't really say it was broken, it wasn't because of the encoding solution itself. It just proves that although it is unbreakable, it is impractical, and that's why it's not used very often (imagine carrying a hard drive that is used to decrypt your other hard drive).
iOS was never and still is not secure
Just see this:
http://www.elcomsoft.com/eift.html
So all this whitepaper release is just PR stuff, in reality, iOS is proven to be not secure.
Just see this:
http://www.elcomsoft.com/eift.html
So all this whitepaper release is just PR stuff, in reality, iOS is proven to be not secure.