also food for thought...
When we set out to create the best possible mobile platform, we drew from decades of experience to build an entirely new architecture.
There's a general rule of thumb in the security community regarding security components (one that's applied most specifically and frequently to encryption): "Don't make your own."
The principle is that established and standardized processes have undergone the "test of time" and have had the subtle flaws removed or worked around. Security tends to be one of those "You have a bucket with 100 holes, and you must plug all 105 of them". Miss one and you lose. Subtle, unobvious issues and small issues "that shouldn't be exploitable" can end up completely defeating your security. Time and public exposure are the best ways to catch these. People may find a way to chain several innocuous-appearing behaviors into an exploitable flaw. Even experienced people that roll their own security have to deal with this angle.
Of course even then you will still get owned from time to time. Linux had a severe kernel bug discovered last year that had been in there for decades, leading Linus to comment that "although the free software mantra of 'many eyes make for shallow bugs', on rare occasion one will still persist". Bash's recent 'shell shock' bug is another good example of that effect..
Also this is the part I specifically
do not like:
The authorization server checks the presented list of measurements against versions for which installation is permitted and, if it finds a match, adds the ECID to the measurement and signs the result.
Sounds good right? OK try this. You support a lab of 25 iPads, and have been running a specialized App for the last 2 years. One of the iPads crashes or gets buggy or something and you have to restore it. When you restore it, it wants to download the latest iOS of course. But you know from experience that the App you need to run isn't compatible with the latest iOS, and the developer isn't going to be updating it. The iPad won't go past iOS 9, but you need to run say 9.1.2 and it wants to give you 9.1.5 which is the latest revision of 9. So you grab your copy of 9.1.2 that you saved and try to install it. Guess what? The "activation server" (because that's what it really is) at Apple
will refuse to sign the activation request and you can't install it. I've literally spent
weeks with Apple engineers trying to get around this, without any success. The result? You now have a lab of 24 iPads. Actually, I now have a lab of
22 iPads as this has happened three times now. Apple has a history of ceasing signing of older versions of iOS about 2 weeks after the new one comes out. That's your window to back grade entire labs of iPads if the update breaks a critical app. And that requires you to get it on at least a few iPads for testing
immediately when it comes out because two weeks from now the upgrade will be an immediate one-way trip.
You'll notice it's not just stopping you from installing modified / hacked versions of their OS, it also prevents you from installing older,
legitimate versions, regardless of what risks you are prepared to accept.
I don't like this concept on principle. We've probably all seen stories of people trying to reinstall old games or apps that phone home from activation, that they can't reinstall because the vendor is out of business and the activation servers are long gone. Apple isn't likely to go away anytime soon, but it irks me to know that I am dependent on them for "permission to use my product". And I have personal experience as to what can happen when they say "
NO!"
