We then want Apple to improve their security so that no such request by governments would be possible in future. Tighten the security so that not even a special custom version of iOS would make a difference to the self destruct measures in place. Then we wouldn't need to waste any time arguing about it.
Just to be clear, I'm against mandated backdoors in products. I should be allowed to make my product as secure as I want to, even against myself. Yes, that might hinder government search and seizure, but that's the government's problem, not mine. I agree with Apple and most other tech companies on this.
But Apple isn't being asked to create a backdoor. The door already exists, and was voluntarily created by Apple. Apple has all of the tools and knowledge in its possession to walk through it. Whether that's the PIN itself (it's not), or the code-signing key and source code needed to disable attack mitigations (without which a 4-digit PIN is worthless), doesn't make a difference. As you observe, they could design the phone such that this attack is not possible. They did not, even though they've been claiming otherwise for years now.
All of the arguments in favor of Apple boil down to a general opposition to government search and seizure, worries about damage to Apple's reputation, a claim that code-signing occupies a privileged legal position (akin to attorney-client privilege), or a slippery-slope argument that the government will ask for mandated backdoors on all iPhones next. None of these has a chance in court. I'm more and more convinced that Apple is well aware of how legally wrong it is, and is just doing this to save face over erroneously advertising that their phones were secure even against Apple itself (and therefore any government coercion of Apple).
If someone is going to challenge me on this, please answer this two-part question: If Apple had the phone's PIN stored in their database, do you think the government should be able to compel them to hand it over? And why is that any different?
It's not completely unprecedented to require active assistance from a third-party. There's a Supreme Court case about this very issue, United States vs New York Telephone Co. The FBI wanted New York Telephone to install monitoring hardware on their premises and assist the government in its operation. The district court issued an order to that effect. The company offered to instead give the FBI only information, which the FBI could then use to install and maintain the system themselves. The Supreme Court ultimately ruled in favor of the FBI.
The main criteria that people have read out of that case is "unreasonable burden". I don't think that the FBI's request to Apple is an "unreasonable burden", especially since the government will pay for any costs. The biggest burden will be on Apple's reputation, but that is self-inflicted from making claims (honestly or not) that ultimately weren't true. I can't imagine the court allowing Apple to keep its technical assistance from the government.
> If Apple had the phone's PIN stored in their database, do you think the government should be able to compel them to hand it over? And why is that any different?
Well, I think, they should not, but I don't claim its different.
Apple wants to have it both ways, build it so that they have full control and they can be compelled by nobody to give up that control. I would rather they build a system, where nobody is in control at all.
This is also the idea behind TPM chips which are in almost every phone/laptop these days, so consumers couldn't tamper with DRM and other similar crypto systems.
I find it ironic that this argument in support of TPM, etc. is being made for phones (not necessarily by you), but this same site has vigorously opposed it for PCs, especially Linux.
You can also seal against some other value. So you'd have seal(plaintext, pin) and unseal(secret, pin). Unseal only returns the plaintext if the PIN is the same that was used to seal.
This is where it gets really fancy. The TPM has a bunch of built-in registers called PCRs (Platform Configuration Registers). You set a PCR by calling extend(newmeasurement). At boot, the firmware hashes the bootloader and sticks the hash in the first PCR by calling extend(hash). Then the bootloader measures the next boot component (probably a second stage bootloader, or perhaps the BIOS settings), and stores that hash in a PCR, and so forth. The resulting value of each PCR is based on both the measurement passed to extend() and the previous measurements, so the whole chain is verified. The cool thing is that seal() and unseal() can use these PCRs the the same way as, and in addition to, a PIN. Now your disk will only be decrypted if you boot the OS that you used to encrypt it. If you're willing to trust the firmware and OS makers, you don't even need a PIN anymore. The OS's built-in authentication could be enough.
Windows PCs tend to have TPMs, but iOS devices have their own hardware encryption solution.
I've glossed over and simplified away important details, but that's the gist of it.
Apple can either create a special update key for the TrustedZone and distribute it to User (SmartCard in the package you buy the phone in) or they could just put in a non-upgradable system.
Both would work.