3 ms·

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: secur

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 https://twitter.com/chronic/status/898217462029791232

qubex 9y ago
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".
- runesoerensen 9y ago
  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.
wahern 9y ago
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.
- Analemma_ 9y ago
  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 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.
  - wahern 9y ago
    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.
    - walterbell 9y ago
      Is SEPOS based on an open-source or proprietary derivative of L4?
      - wahern 9y ago
        From slide 60: SEPOS * Based on Darbat/L4-embedded (ARMv7) - Custom modifications by Apple
- 9y ago

qubex 9y ago

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".

runesoerensen 9y ago
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.

wahern 9y ago

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.

Analemma_ 9y ago
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 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.
- wahern 9y ago
  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.
  - walterbell 9y ago
    Is SEPOS based on an open-source or proprietary derivative of L4?
    - wahern 9y ago
      From slide 60: SEPOS * Based on Darbat/L4-embedded (ARMv7) - Custom modifications by Apple
9y ago