The whole story is weird. Since the iPhone in question does not have a tamper-resistant device, the FBI should be able to open the case, read the whole Flash chip, and then run the exhaustive search themselves without even running the phone's firmware. Updates from Apple should have no effect at all.
(Edit: in fact it is a bit more complex; see below.)
Conversely, assuming that there was a technical impossibility in the description above (which would amount to claim that the FBI's level of incompetence is at least as large as their budget), and that an Apple firmware would solve the case, then it would be easy for Apple to make a firmware version that does the exhaustive search as the FBI wants, but only after having checked that the hardware serial number exactly matches some expected value, i.e. the exact phone from the San Bernardino case. Such a firmware would comply with the exact demand from the FBI without compromising the privacy of anybody else.
That the FBI claims to have tried decrypting the phone for one month and failed, is weird. That Apple refuses to help with the decryption with a firmware update limited to a single phone, is equally weird. What the whole thing seems to be is a political struggle about the right to privacy and the legality of non-judicial eavesdropping by law enforcement. The San Bernardino case is merely a pretext that is used to elicit reflex support from non-technical electorate. Apple found it expedient to play the role of the White Knight, from which they cannot now back away without alienating their consumer base.
Edit: the security system in an iPhone is a tower of elements, described (succinctly) in this document. An iPhone 5C runs on an Apple A6 chip, which the 5S and later models use an A7. The A6 has an onboard tamper-resistant device called the "UID"; the A7 has a second one called the "Secure Enclave". Since the iPhone in the San Bernardino case is a 5C, I won't talk any more of the Secure Enclave.
The UID contains an internal key that is unique to the device (let's call it Ku), and is unknown to anybody else, including Apple (whether the UID generates it itself, or it is generated externally and then injected in the UID on the processing chain, is unknown; I'll assume here that if reality matches the latter case, then Apple really did not keep the key). The UID never let that key out, but it can do an AES-based computation that uses that key.
The iPhone data is encrypted with AES, using a 256-bit key (Kd) that is derived from the combination of the user PIN and the UID key. Though Apple does not exactly detail that combination, it says it involves key wrapping, which is another name for encrypting a key with another key. We also know that a user can change his PIN, and it would be impractical to change the actual data encryption key Kd in that case, because it would involve reading, decrypting, re-encrypting and rewriting the gigabytes of user data. Thus, a plausible mechanism is the following:
- The key Kd has been generated once.
- When the phone is off, what is stored (in Flash, out of the UID) is an encryption of Kd by another key Kz.
- Kz is itself the encrypting (wrapping) of the user PIN by Ku.
Thus, the unlocking entails obtaining the user PIN, submitting it to the UID, who returns Kz by encrypting the PIN with Ku. With Kz, the phone's firmware then recovers and decrypts Kd, and configures the crypto engine to use that key for all accesses to the user data.
While the actual scheme may differ in its details, the general outline must match that description. The salient point are that, although the tamper-resistant device (the UID) must be involved with each PIN try, it does not actually verify the PIN. The UID has no idea whether the PIN was correct or not. The wrong PIN counter, the delay on error, and the automatic deletion, are handled externally, by the firmware. This must be so because otherwise there would be no sense in Apple allowing the break to be performed with a firmware update.
Of course, one can imagine a kind of extended UID that would enforce the PIN verification and lock-out strategy, and could do so by running its own firmware that would be updatable by Apple. Such a device would really make Apple's help crucial. However, such a device would then be called a "Secure Enclave" because that's exactly what it is, and if it was added in the A7 CPU, it is precisely because it was lacking in the A6 and that absence was a vulnerability.
So what does it mean for a brute-force attack ? This implies that the UID must be invoked for each user PIN try. However, that's the UID -- not the phone's firmware. If you open the iPhone case, then the A6 CPU sub-packaging, the device UID can be accessed by connecting to it directly. It will involve some precision laser-based drilling and an electronic microscope to see what you are doing, so it certainly is not easy -- let's say it will cost a few thousands of dollars because that's the same kind of thing that is done (routinely !) by people who clone and resell satellite-TV access smart cards. Once connected, an external system can submit all possible user PIN for the UID to encrypt them all and provide the corresponding Kz keys (in my terminology above). Then the rest is done offline with a PC and a copy of the Flash storage. At no point is the phone's firmware invoked.
What the FBI currently asks for is an automatization of the process. They don't want to do precision drilling with lasers. They want to be able to plug something in the iPhone port without having to even open the case, so that the brute-forcing is done by the iPhone's CPU itself and the whole process can be done smoothly.
Thus, it is really not about the San Bernardino case. The FBI does not want a one-shot intervention from Apple; what they ask for is a tool that will be usable repeatedly on many phones. Apple is right in claiming that what the FBI asks for exceeds the specific case that serves as emotional pretext.
On the other hand, Apple could produce a firmware update that does as the FBI asks for, but only on the specific iPhone (identified through, for instance, the CPU serial number). And that firmware update would be specific to the 5C, and would not work on later models. There is no inevitability in Apple's producing a new firmware leading to a generic cracking tool for all phones of all models. But even if Apple complies with the a firmware that is specific to a single iPhone, the legal precedent will have been established, and Apple would find it hard to refuse other requests, from the FBI or from other countries where Apple has business interests (i.e. all of them).
A system which would ensure protection against user PIN cracking would need a tamper-resistant device that not only enforces the PIN failure counter and key erasure, but that device should also run a firmware that is not upgradable. The Secure Enclave has its own firmware, but it can be upgraded (firmware upgrades are signed by Apple, the Secure Enclave hardware verifies the signature). Even on an iPhone 6, Apple retains the ability to unlock arbitrary phones.