[Swordmaker]

So when he stated that it was impossible for Apple to do what was requested of them (despite the fact that they indirectly admitted that it was not, btw), my concerns about his honesty were, unfortunately, confirmed. I then started looking into his past and current posts on other threads, and what I found was a pattern of shouting, insulting, and cursing at others. I think people who behave that way need to have that behavior called out until they either stop or go away. Too many of that sort on a forum, and it becomes an unpleasant place to visit.

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. I also posted multiple sources that provided proof that Apple places the start-up IN SILICON specifically on the later processors to prevent exactly what you were claiming. I also said that it was not impossible on the iPhone 5C in question, but it as on later iPhones. . . unless Apple were to rewrite their entire iOS. YOU were one who kept claiming it was trivial. On ALL of these iPhones there is a secure BOOTSTRAP in silicon which you keep ignoring and in that IS exactly what you say is NOT THERE. I posted links to Apple's own Security White Papers outlining how they were doing this, from both the latest, and the one that applied to the A6 processor that had the Encryption Engine in it, along with the Secure iBoot Bootstrap. You just kept repeating your litany that it couldn't be that way.

I used primary sources from Apple.

[Scutter]

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.