Apple vs DOJ - how strong is the 10-try wipe brute force barrier?

Out of curiosity and with the hope of helping other beginners and journalists.

The current Apple vs DOJ standoff in a nutshell - Apple is resisting DOJ with statements like what they're asking is "something too dangerous to create". A summary with a quote from The Washington Post:

The order does not ask Apple to break the phone’s encryption, but rather to disable the feature that wipes the data on the phone after 10 incorrect tries at entering a password. That way, the government can try to crack the password using “brute-force”.

Binaries of such iphone os with the brute-force features disabled would enable anyone in possession of said binaries to just flash any iphone in their possession which opens it to brute-force attacks.

Now assuming this brute-force protection acts as a compensation for weak passwords (if the game really is over after 10 tries, the bar is set pretty low)

How feasible would be the following crude attempt:

1. Cloning the phone data
2. Running the cloned image(s) in an emulator / Virtual Machine
3. Cluster runs online attacks on a bunch of VMs.

The issue preventing virtualization, as stated in the apple iphone security whitepaper I assume is all the ties to hardwareIDs, the extraction of which is "complicated and expensive"?

Am I correct in assuming successful extraction of hardware IDs would at the same time open new avenues of (offline) attacks?

How solid (read: future-proof) is security of this design, will the extraction of hardwareIDs always be deemed "too complicated and expensive"?

• Yes, Apple could get it virtualized within a week if they wanted to, and therefore avoid the 10-try limit, but there's no "imminent threat on human life" motivating them to do it. – bobuhito Feb 17 '16 at 22:02

Edit 2: See this question for discussions based on more accurate and up-to-date info.

I think the problem might be more complicated than what can be solved by a simple clone. Recent iDevices comes with a security enclave which is an isolated security processor.

Typically, such processor have its own on-board non-volatile memory which is used to store key material. All encryption/security related operations only happen inside this processor and the encryption key never leaves the chip.

The main disk/flash memory can now be completely encrypted and the "wipe" only need to happen in the enclave as opposed to having to overwrite the entire flash chip.

In this kind of scheme, simply copying the flash is obviously completely useless so an attacker/FBI/DOJ must find a way to compromise the security enclave as well.

That is why Apple's cooperation is needed. The security enclave processor does have to run firmware, which are often field-updatable. Security is typically ensured by checking vendor's signature of the firmware. The court order is probably trying to force Apple to sign an insecure version of the firmware that would allow brute-forcing.

The side-effects of this is also obvious. Anyone who gets hold of the firmware can completely bypass the most secure part of the system and steal very sensible data like TouchID fingerprints and Apple Pay card details also stored in the security enclave.

• Good answer! What about the avenues of attack on the enclave, as apple's whitepaper puts it "attacking the silicon directly" which is a "costly" prospect, how future-proof is that? edit: ah that topic was posted after mine, it's more about legalities, an excellent read too! Especially the part about it perhaps being a "one-time win" at best. – Multicon Feb 18 '16 at 18:26
• @Multicon "Attacking the silicon directly" most likely means destroying the package to expose the die and then attach wires or use a microscope to read out the internal memory directly. Obviously, this requires a lot of skills and expensive equipment. See cl.cam.ac.uk/~rja14/tamper.html for details. – billc.cn Feb 22 '16 at 11:44

The entire article (theme behind DOJ) is broad. For example, define password. Was it a PIN used, or a tried and true password. If it's a PIN used for a password (digits) this should not be an issue. My guess is that it's a bonafide password which is where the issue comes along. So my theory on how this works, and why cloning a phone, won't work.

PASSWORD CREATION -> stored in keychain

When you power up your phone, and your phone is prompting you for a PIN/PASSWORD, it needs to compare what you enter against something stored. Would be horrible by design to store it remotely. (What if you have zero connectivity).

CLONE: So you cloned the phone. You have N (10) attempts before it erases your data. You fail. Take another clone, rinse and repeat. (At what cost now?)

How many clones will you be willing to clone to even attempt this? Let's say their password is 8 characters (grand total of 37.2 bits of entropy).

a = combination of letters and numbers only
b = only the alphabet
c = only numbers


(a) 368 − (b) 268 − (c) 108 for a total of 2.612182 x 1012 combinations (if you used a, b, and c ONLY. Now divide that result by 10, and that is the total number clones you will need to make more or less if you think the password is 8 chars. You would run out of time in your life attempting that many clones, not to mention the space needed to store the clone. (My math is likely to be off here but you get the gist). Looking back at the answer, it kind of covers clustering, VM imaging, etc.

SIDENOTE Supposedly Cellebrite is supposed to be able to get by even iOS for imaging. I haven't used the UFED, but either Cellebrite is making things up (as they would be my first choice) or again as I started, the wording is so broad, and the gov is after something else.

SUMMARY? Bruteforcing no matter how many clones you think you can generate is a big waste of time and money. Considering you don't know what you're up against. My password for my personal email is 26 characters. That is just ONE password. Good luck bruteforcing that. Hope I somewhat helped on the thought process of cloning for bruteforcing.

• Good explanation, but it's very rare to see users use an actual bona fide password on an IOS device -- instead they typically use numbers (since a keypad is brought up rather than the full keyboard at the login screen, it's quicker). Then, you simply have 10x(8th power) combinations, making brute force a lot more feasible. – Herringbone Cat Feb 17 '16 at 20:49
• Everyone I know who uses an iPhone has a password. For those who I have seen use PINS, the only reason they did use them was because they didn't know how to enable it... Also of note 10<sup>8</sup> combinations means they'll need 10 millions clones. If the phones are 16gb, another 160 Petaybytes of storage – munkeyoto Feb 17 '16 at 21:12
• might be some significant selection bias there..the default on iOS 9+ is to use a 6 digit "passcode." It used to be a 4-digit one. Users would have to know to, and manually select other options such as a full password. – Herringbone Cat Feb 17 '16 at 21:15
• To respond to your edit about 10 million clones: That's not how cloning an OS would work for brute force purposes. First, a deduplicated SAN would bring that down..but .. chances are they'd only need one image as a snapshot, and then could run virtual vms from the snapshot..and revert back when the brute force failed. This would make total disk usage look more like a few hundred GB for tons of instances. In addition, it would be 10 (6th power) if default settings were used, making it a million clones to try all combinations. This isn't very unrealistic to brute force if you're the FBI. – Herringbone Cat Feb 17 '16 at 21:27
• Excellent answers and comments! Good point munkeyoto, "average Joe's pw" is undefined. I think Herringbone Cat sets a more realistic context. I can only add police around the world explore all kinds of educational avenues with the hope of reducing fraud, identity theft, etc by simply educating citizens on password strength and I've read statements along the lines of 'amazement' by police depts at just "how uneducated the general population is on the issue". This would also be a password entered more often than any web, service, etc. password, so convenience may play a role too. – Multicon Feb 17 '16 at 22:20