It doesn't quite work that way. The files on the device are ultimately encrypted with a dependency on both the hardware key in the Secure Enclave and the user's passcode. It's impossible to update the firmware without both pieces of information or erasing the device, and on A7 or later processors the unlock attempt delay is a direct result of the method of encryption used and tied to the hardware so it must be performed on the device itself.
Do we have any documentation that indicates it's impossible to do firmware updates without the user's passcode? That's what the government seems to believe that it could (at present) do, given Apple's cooperation. The iOS Security Guide doesn't seem to address that particular point.
It's possible to reflash the firmware in DFU mode, but it requires erasing the data on the phone. Or more technically, there's an encryption key in storage that needs to be regenerated to give access to the filesystem, but that encryption key (in conjunction with the hardware key in the Secure Enclave and the user's passcode, if set) is also necessary to read any user data on the phone.
Are you saying the article is wrong or did you not read it?
"As many jailbreakers are familiar, firmware can be loaded via Device Firmware Upgrade (DFU) Mode. Once an iPhone enters DFU mode, it will accept a new firmware image over a USB cable. Before any firmware image is loaded by an iPhone, the device first checks whether the firmware has a valid signature from Apple. This signature check is why the FBI cannot load new software onto an iPhone on their own — the FBI does not have the secret keys that Apple uses to sign firmware."
<spoon feed>
At this point it is very important to mention that the recovered iPhone is a 5C. The 5C model iPhone lacks TouchID and, therefore, lacks the single most important security feature produced by Apple: the Secure Enclave.
In these older devices, there are still caveats and a customized version of iOS will not immediately yield access to the phone passcode. Devices with A6 processors, such as the iPhone 5C, also contain a hardware key that cannot ever be read and also “tangle” this hardware key with the phone passcode. However, there is nothing stopping iOS from querying this hardware key as fast as it can. Without the Secure Enclave to play gatekeeper, this means iOS can guess one passcode every 80ms.
</spoon feed>
And even if it did have a Secure Enclave, from page 5 of your link:
When an iOS device is turned on, its application processor immediately executes code
from read-only memory known as the Boot ROM. This immutable code, known as the
hardware root of trust, is laid down during chip fabrication, and is implicitly trusted.
The Boot ROM code contains the Apple Root CA public key, which is used to verify that
the Low-Level Bootloader (LLB) is signed by Apple before allowing it to load. This is
the first step in the chain of trust where each step ensures that the next is signed by
Apple. When the LLB finishes its tasks, it verifies and runs the next-stage bootloader,
iBoot, which in turn verifies and runs the iOS kernel.
So the LLB is run first, and could be used to contact the Secure Enclave and guess passwords.
And from the article:
At this point you might ask, “Why not simply update the firmware of the Secure Enclave too? That way, Apple could disable the protections in iOS and the Secure Enclave at the same time.” (crossed out)Although it is not described in Apple iOS Security Guide, it is believed that updates to the Secure Enclave wipe all existing keys stored within it. An update to the Secure Enclave is therefore equivalent to erasing the device.(/crossed out) I initially speculated that the private data stored within the SE was erased on update but I now believe this is not true. After all, Apple has updated the SE with increased delays between passcode attempts and no phones were wiped. In all honestly, only Apple knows the exact details.
So, it may be that Apple does have a backdoor to upgrade the SE. Only Apple (and maybe other state actors) really know this. So, it certainly isn't as cut and dried as you imply, if the device did have a Secure Enclave.
But, in this case, the device does not have a SE, so it is clear that with Apple's keys the device could be, with a practical amount of effort, be hacked.
https://www.apple.com/business/docs/iOS_Security_Guide.pdf