Hacker News Reader

Comment by qubex | Hacker News Reader

Has anybody verified this? Does anybody know whether xerub went through (or attempted) responsible disclosure?

I'm not sure what responsible disclosure would look like in this case? It's only the firmware decryption key that's been released. Also:

"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

I suppose that responsible disclosure would look like a detailed and formal equivalent of "Hey guys, your firmware decryption key is XYZ and I got it in the following manner".

Uhm I don't think xerub disclosed how he got the key, but Apple will probably look into that now for future SEP devices/firmware updates. Not an expert on this but as far as I can tell that wouldn't really make the disclosure of the decryption key itself more or less "responsible".

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.

This doesn't bode well for Apple's secure enclave. Apple's enclave environment has benefited from obscurity, though that was always destined to fail eventually.

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.

I don't think this is true. There was already a blackbox analysis of the SE presented at Blackhat and it concluded it seemed pretty secure: https://news.ycombinator.com/item?id=12231758. They specifically mentioned that there wasn't much code in the SE and so the attack surface was pretty small.

From the Blackhat presentation:

  Runs its own operating system (SEPOS)
  * Includes its own kernel, drivers, services, and
  applications

OTOH, the enclave is a separate processor entirely, unlike (AFAIU) on Android phones. And applications on the processor run outside the TrustZone, so there are really two enclaves: the outer enclave (the security processor), and the inner enclave (the TrustZone on the security processor). The hardware restrictions on IPC (both ways between the main processor and security processor) also seems really nice. And they're using an L4 derivative for the OS.

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
  SEP

There's a tension there, like with DRM. The more people rely on the enclave to run sophisticated software, the more pressure there'll be to add more features and more complexity. Again, Apple may be better positioned than most to push back, but being smart will only get you so far.

Is SEPOS based on an open-source or proprietary derivative of L4?

From slide 60:

  SEPOS
  * Based on Darbat/L4-embedded (ARMv7)
    - Custom modifications by Apple

>This doesn't bode well for Apple's secure enclave. Apple's enclave environment has benefited from obscurity, though that was always destined to fail eventually.

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.

No responsible disclosure needed. The method of gaining access to this key is on-device, not on a server, so so patching would only prevent future use while a device remaining on the firmware which allowed decryption could continue to decrypt the SEP firmware for all future revisions on existing hardware.

I don't see why xerub would release the method for this yet, unless it is now burned/useless.

"responsible disclosure" as a term is a meme started by vendors (and later rebuked by the same vendors) that is highly subjective. It's best that people don't focus on this.

Reply on news.ycombinator.com