You are misrepresenting the discussion we had, Scutter. The iPhone 5C in question does NOT have an A9 processor, as I pointed out to you. It has a A6 processor.For others' benefit: I am not misrepresenting the conversation at all. I honestly didn't remember if it was an iPhone 6 or 5, and didn't bother to go back and look. But it's totally irrelevant as Apple has been tight-lipped about all the Ax processors. Everything I said is relevant to both.
SwordMaker, I guess you just don't understand the terms you are using. Let me elaborate. What you're referring to as a "secure bootstrap in silicon" is exactly what I was referring to when I said "things necessary to bootstrap a secure code environment". This is a portion of the silicon that is able to verify the signature of the code in the device flash. It works as follows.
All the trusted platform / secure boot facilities work in basically the same way. They uses asymmetric encryption (also called PKI) in which the authors generate a public-private key pair. Apple holds the private key, and keeps that safe and secret. The public key is hard-coded into the chip or into a one-time programmable (fused) portion of the chip that is programmed during device assembly.
At boot, the processor validates the authenticity of the code as follows. It calculates a message authentication code (MAC) on the code. This is effectively a high quality hash/checksum. Then using the public key burned into the silicon, it decrypts a similar MAC contained within the code at a known location, and which has been encrypted using the private key (of the public-private key pair). It is the unique and useful feature of PKI that only data signed with the private key will decrypt correctly using the public key. Since only Apple has this, only Apple code will have a signature (MAC) that matches.
If they do not match, the processor halts and does not continue. If they match, it vectors to the entry point of this code, and the boot process continues. Once it's validated the code and vectored to it, this code can do anything it wants. If Apple wants to change the policy for number of incorrect PIN entries, they build an OS image with that modification, sign it with the private key, and load that onto the flash ram on the phone.
Since Apple has the private key, they can "sign" whatever code they want, load it into the device flash, and the processor will happily verify its authenticity and then run it. You keep saying I'm ignoring your point; I'm not.
No, they are not. They publish quite bit on the capabilities of those processors. You just don't bother to look. Just like you made leaps of assumption about what the iPhone in question was before you jumped in and started making ignorant ex cathedra declarations about what was or was not possible, based on your years' old experiences.
As for the rest of your attempts at teaching me, I've explained that in detail how that works on an iPhone several times. . . and it is essentially NO DIFFERENT than what you've said except in specific Apple details about WHICH chips they use for this and where and what they put in these chips. Apple does not use the same typical approach you are describing.
Quit trying to imply I don't know what I am talking about. . . especially when you are talking about external incoming software at boot up, no, you are not correct and you are demonstrating you don't know anything about iOS security.