Apple vs DOJ - how strong is the 10-try wipe brute force barrier?
Edit 2: See this question for discussions based on more accurate and up-to-date info.
Edit: See also this question which has loads of discussion on this already with quotes from the actual request.
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.
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.