> The best Apple could do is sign a malicious update to the Secure Enclave firmware that either removes the time delays or dumps the keys.
Dumping the Secure Enclave would not result in the keys necessary to read the files on the filesystem. Each file has a unique key, which is wrapped by a class key, and for some classes, the class key is wrapped by a key derived from the passcode. If you don't have the passcode, you can't unwrap any of the keys (Page 12 of https://www.apple.com/business/docs/iOS_Security_Guide.pdf).
You could bruteforce the passcode.
Yes, if you could recover the SE key (or factory-burned SoC key for older phones), you could crack the passcode on your own cluster rather than being limited to what the phone hardware/software can do.
> for older phones
To my knowledge, all keys are still wrapped with the UID, and the UID is still a factory-burned SoC key (not accessible to any firmware). Possible to extract, but not easy to do at scale.
The phone involved in the San Bernadino case is a 5C, which does not have Secure Enclave.
Where have you heard about the erase-on-update feature?
When a passcode is entered, the SoC queries the Secure Enclave with the passcode. If the passcode is correct, the Secure Enclave responds with the decryption key for the flash storage.
The best Apple could do is sign a malicious update to the Secure Enclave firmware that either removes the time delays or dumps the keys. However, some people suspect the SE erases its secrets on firmware update, although this behavior isn't documented in Apple's security reports.