Any mechanism that prevents the application processor from either a) remembering it incremented the count b) corrupts the count or c) patches the logic that handles a retry count of 10, is sufficient to attack the phone.
Somewhere in the application processor, code like this is running:
if (numTries >= MAX_RETRY_ATTEMPTS) { wipe(); }
or
if (numTries >= MAX_RETRY_ATTEMPTS) { retryTime = retryTime * 2; }
Now there are two possibilities. Either there are redundant checks, or there aren't. If there aren't redundant checks, all you need to do is corrupt this code path or memory in a way that prevents it's execution, even if it is to crash the phone and trigger a reboot. Even with 5 minutes between crash reboot cycles, they could try all 10,000 pins in 34 days.
But you could also use more sophisticated attacks if you know where in RAM this state is stored. You couldn't need to de-capp the chip, you could just use local methods to flip the bits. The iPhone doesn't use ECC RAM, so there are a number of techniques you could use.
On phones after the 5C, nothing you can do with the AP helps you here; the 10-strikes rule is enforced by the SE, which is a separate piece of hardware. It's true that if you can flip bits in the SE, you can influence its behavior. But whatever you do to extract or set bits in SE needs to not cause the SE to freak out and wipe keys.
The ultimate way to defeat physical or software attacks is to exploit intrinsic properties of the universe, which suggests finding a mathematical and/or quantum structure impervious to both.
So it falls to either 2-factor or biometric to avoid PINs. Biometric of course has it's own problems.
Perhaps people should really carry around a Secure Enclave on a ring or something, and with a button to self-destruct it in case of emergency. (e.g. pinhole reset)
The entire point of an secure enclave is to completely enclose all the hardware and software needed to generate encryption keys in a single lump of silicon.
This means that all of its processing requirements (it's a complete co-processor) are on chip, it's RAM is on chip (not shared with it the main CPU, and probably has ECC), and it uses secure boot to cryptographically verify that it's firmware has not been tampered with before it starts executing. Additionally it may even be possible to update it bootloader in the future to prevent further updates without a passcode.
The end result means that attacking a secure element is very difficult. There are few, if any, exposure points that would allow you to fiddle with its internal state, and any attempts too should result in the secure element wiping stored keys, making further attacks a moot point.
The point is that state actors have vast resources to pull off these attacks. The NSA intercepted hardware in the supply chain to implant attacks as documented by Snowden. Stuxnet was a super-elaborate attack on the physical resources of the Iranian nuclear program, which was obviously carried out with supply chain vendors like Siemens. Apple uses Samsung as a supplier, and the US government has very high level security arrangements with the South Koreans, so how do we know the chips haven't been compromised even before they arrive at Foxconn for assembly?
Here's an example of a TPM module being decapped and hacked at Blackhat: https://redmondmag.com/articles/2010/02/03/black-hat-enginee...
Attacks have been shown using silicon doping, security fuse cutting, etc.
If the NSA really wanted to crack the Secure Enclave, I have very little doubt about their ability to carry it out.
Well they certainly really want to crack the Secure Enclave, so maybe this case is moot.
Seems to me when we are at a point were every time the NSA wants to get at some data, the have to start a heroic effort of attacking low level hardware, we are in a pretty good state in terms of device security.
Apple's security guide would indicate otherwise, look on page 7. The secure enclave encrypts its portion of memory, but it isn't built into the secure enclave itself.
1. Get a dump of the encrypted data.
2. Try to probe the hardware, potentially destroying it.
3. If the probe works, we're done. If not, put the encrypted data dump onto a fresh iPhone and repeat from step 2.
This way, you effectively get unlimited shots at an otherwise risky hardware probe.
* Decapping and feature extraction even from simpler devices is error prone; you can destroy the device in the process. You only get one bite at the apple; you can't "image" the hardware and restore it later. Since the government is always targeting one specific phone, this is a real problem.
* There's no one byte you can write to bypass all the security on an iPhone, because (barring some unknown remanence effect) the protections come from crypto keys that are derived from user input.
* The phone is already using a serious KDF to derive keys, so given a strong passphrase, even if you extract the hardware key that's mixed in with passphrase, recovering the data protection key might still be difficult.