Anyone else a little surprised that apples security feature here is so easy to sidestep? I'd have thought, in the least, that any such keys were stored in the main processor without external read/write capabilities.
What would make you secure here is having a password sufficiently long and complex to make brute forcing infeasible. Touch ID facilitates that by making it practical to use the device even with a strong password set. But if you have a four or six-digit passcode set on such a device, then this technique should still work fine.
First, the iOS security guide makes no mention of any storage besides the flash. When it discusses key erasure, it's always about Effaceable Storage, which according to the guide is a dedicated area of NAND flash.
Second, Apple says that the attack the FBI wants them to carry out could be made against all iPhones. If the Secure Enclave had its own storage, it would be trivial to have it wipe the device if the SE software was updated without a passcode, which would defeat the requested attack. It's possible that the SE has its own storage and Apple just didn't use it this way, of course. Or whoever said this on behalf of Apple could just be wrong that the more recent phones are vulnerable.
The SE does enforce the escalating timeouts, and probably the wipe after ten tries, but that wipe could just be the SE telling the Effaceable Storage to erase the key.
That said, you can bet that Apple is working on a fix for this for future devices. Some way for the Secure Enclave to know that the update was authorized by the user even if the device was subsequently bricked by the update and then recovered. With the ability to maintain proof of authorization even after the device is bricked, they can then make the SE wipe itself if it's updated without authorization.
And fixing a stuck device like that could be done by just not upgrading the Secure Enclave's software during the recovery process. Restore the main OS and you're back where you were. Then you can update the SE firmware.
I'm pretty sure that if the SE doesn't wipe when updated without a passcode, it's because there's no way for it to do so. It just loads the firmware it's presented at boot, no questions asked beyond verifying the signature on that firmware.
No doubt Apple is working on improving this. You'd only need 256 bits of nonvolatile storage within the SE, and corresponding improvements to the SE's bootloader.
As for sending passcodes over the wire, Apple really doesn't want to have this because it makes it a lot harder to reject requests like the one the FBI is making. Disabling the wipe-after-10-passcodes is just turning off a bit of code, that's not an "undue burden", but implementing the ability to send passcodes over the wire is a non-trivial engineering effort and becomes an "undue burden" when the FBI requests that it be added.
Submitting passcodes electronically doesn't really make that much of a difference. It takes at least 80ms to try a passcode that way. Require touchscreen input and you've bumped that up to, what, a second or two? Without the escalating delays and potential wipe, a (very bored) person could crack a four-digit passcode by hand in a day.
Also, did they remove this functionality? The "IP Box" brute forcer submits passcodes over USB. Apple may have removed that when they patched the vulnerability that allowed bypassing the escalating delays, of course, but it did exist.
I don't know why the FBI requested this ability, but it's presumably just something like, while we're here we might as well make things a little easier.
The SE uses a different key for each app, so even if you can decrypt one key, you only get data from one app.