Yep. The root of trust for IME is within silicon, so unless there's a serious flaw in their IME initialization process, it will only run code signed with the root of trust in silicon.
I don't agree with the motivations behind the IME (DRM foremost), but Intel seems to have built a very secure trusted boot chain. If the IME cannot boot a trusted firmware, it will shut down the rest of the platform and you'll have a fancy brick.
This has been the situation for many years and it's why you cannot buy Intel based computers without IME made after ~2008 (X200/T400). Although recently Trammell Hudson seems to have found a way to mostly disable the IME boot process on the X220. 
ARM vendors offer a similar feature with their on-silicon root of trust. The BROM (boot ROM) on silicon will only load and execute code signed by a trusted authority. 
Decrypting the SEP's firmware is huge for both security analysts and hackers. It could be possible, though xerub says it's very hard, to watch the SEP do its work and reverse engineer its process, gain access to passwords and fingerprint data, and go even further toward rendering any security relying on the SEP completely ineffective.
That's not how it works! The secrets that protect your data aren't embedded in the SEPOS firmware binary; it's embedded in the phone's hardware.
(In fact, this is probably a case where the "market value" of the bug greatly exceeds Apple's stated bounty value, because you could probably charge governments a nosebleed per-phone rate to extract secrets from locked phones.)
Fair point actually, that was a bit careless for them to add.
Regarding SEP bounty: Apple offers $100,000 just for accessing the contents. Selling it as a capability would require additional low level exploits to actually interface with SEP in order to actually exploit it, so you could do per-phone deals if you have that type of vulnerability on hand, but I am not so sure many folks do. iBoot and friends (along with everything else pre-lockscreen) are reasonably secure these days.
>Decrypting the firmware itself does not equate to decrypting user data," xerub said. There's a lot of additional work that would need to go into exploiting decrypted firmware—in short it's probably not going to have a massive impact.
The author seems to be playing it up a bit, gotta get those clicks.
Why would the third-party market value be zero? It seems tremendously valuable to many extremely well-resourced parties.
Uh, the A-series is the "main" series of processors -- the ones in iPhones and iPads. The S-series is just in the Apple Watch.
"very important: secure enclave has not been hacked. decryption key in this case is for the firmware, allowing more researchers to look at it" https://twitter.com/chronic/status/898217462029791232
Also, people would still be able to decrypt the firmware even if the decryption key (or how to retrieve it) was publicly disclosed at a later time. Apple can't release a fix for this retroactively.
Every other secure enclave has been hacked because the environments are far too complex. Engineers are recapitulating all the same mistakes that plague existing operating systems and software stacks. It's so bad that now secure enclave environments are adding mitigations like ASLR and stack canaries.
Maybe Apple was smart enough to keep things simple, and doesn't try to implement things like dynamic linking, processes, or multi-tasking in the enclave. Given their production and retail model, they're about the only company capable of doing this. But I doubt it.
Runs its own operating system (SEPOS)
* Includes its own kernel, drivers, services, and
So, yes, it seems like a better design. Very nice. Still, I hold to my criticism. At the end of the day, complexity is anathema to security. If you build an OS, people will use and abuse it. The presentation also mentions that most Apple drivers have now moved partly to the enclave,
* Most drivers have a corresponding app in the
* Based on Darbat/L4-embedded (ARMv7)
- Custom modifications by Apple
This is actually totally irrelevant to secure enclave's security. They just got access to the unencrypted binaries for the SEP firmware, which doesn't give any access to anything by itself.
I don't see why xerub would release the method for this yet, unless it is now burned/useless.
Anything in particular that makes you think this is probable? There's evidence to the contrary as mentioned in another comment https://news.ycombinator.com/item?id=15040972
> If they don't have the binary, they can't find vulnerabilities in that, right?
No, vulnerabilities can still be found (and they've had the binary all along). This just allows them to decrypt it and inspect the source code, which makes it easier to identify vulnerabilities than a black box.
decrypt the firmware and inspect the binaries