6 ms·

So this breaks SGX completely. Signals new PIN thing relies (almost) entirely on SGX being secure to make their encrypted profile and contact backups secure.

So this breaks SGX completely. Signals new PIN thing relies (almost) entirely on SGX being secure to make their encrypted profile and contact backups secure. This attack reduces the security of the Signal encrypted backups to just the PIN. Edit: Indeed the authors point this out explicitly in the SGAxe paper.

usmannk 6y ago
> Signals new PIN thing relies (almost) entirely on SGX being secure to make their encrypted profile and contact backups secure. This just seems irresponsible. How could they excuse this? It seems like anyone who has even peripherally been working with TEEs recently is _well_ aware that SGX is broken beyond repair. It's not just a matter of patching bugs, this whole model seems bunk.
- RL_Quine 6y ago
  Seems unlikely they were mentioned in the paper in this depth without being made even casually aware that this paper would be published. Which means they just went ahead with it anyway.
- lima 6y ago
  Still useful for plausible deniability if the government comes knocking.
- saagarjha 6y ago
  Even people not working on TEEs are aware that SGX is broken. Actually, you don't even have to even know what SGX is to bring up the concern that their entire scheme relies on SGX working correctly.
anonymousDan 6y ago
Nah. If it can be fixed with a microcode update it's not the end of the world.
- lxgr 6y ago
  Definitely not the end of the world, but the utility of a trusted computing implementation depends a lot on the track record of actually being one, and SGX's isn't exactly great.
  - uluyol 6y ago
    To be honest, you could say the same about SSL/TLS, browsers, and (probably) virtualization. Secure enclaves are new. It takes time to develop new technologies and work out all the issues. I probably wouldn't trust my data to SGX today, but I'm not opposed to it as an idea. In 5-10 years it may be in a reasonable state.
    - yjftsjthsd-h 6y ago
      If we had a heartbleed every month, then I'd be rethinking whether I want to trust anything to TLS, yes. Browsers are awful, and tolerable only because they provide so much value (and even then, I overwhelmingly only run a browser with extra mitigations in place). And no, virtualization probably shouldn't be trusted against hostile code.
      - pjmlp 6y ago
        As long as we rely on languages like C for our foundations, we will have them, just not always on TLS, that is why it is so relevant to push for better foundations, even when most of us aren't doing systems programming.
- rcxdude 6y ago
  If you're relying on it for remote attestation (which is what signal is doing) it's not any use for that, because you have no real verification that the microcode has been updated.
  - ENOTTY 6y ago
    In SGX, you do have verification that the microcode has been updated. This is known as the CPUSVN value, it is part of the SGX report that gets issued, and mixed into the keys used to sign reports.

usmannk 6y ago

> Signals new PIN thing relies (almost) entirely on SGX being secure to make their encrypted profile and contact backups secure. This just seems irresponsible. How could they excuse this? It seems like anyone who has even peripherally been working with TEEs recently is _well_ aware that SGX is broken beyond repair. It's not just a matter of patching bugs, this whole model seems bunk.

RL_Quine 6y ago
Seems unlikely they were mentioned in the paper in this depth without being made even casually aware that this paper would be published. Which means they just went ahead with it anyway.
lima 6y ago
Still useful for plausible deniability if the government comes knocking.
saagarjha 6y ago
Even people not working on TEEs are aware that SGX is broken. Actually, you don't even have to even know what SGX is to bring up the concern that their entire scheme relies on SGX working correctly.

anonymousDan 6y ago

Nah. If it can be fixed with a microcode update it's not the end of the world.

lxgr 6y ago
Definitely not the end of the world, but the utility of a trusted computing implementation depends a lot on the track record of actually being one, and SGX's isn't exactly great.
- uluyol 6y ago
  To be honest, you could say the same about SSL/TLS, browsers, and (probably) virtualization. Secure enclaves are new. It takes time to develop new technologies and work out all the issues. I probably wouldn't trust my data to SGX today, but I'm not opposed to it as an idea. In 5-10 years it may be in a reasonable state.
  - yjftsjthsd-h 6y ago
    If we had a heartbleed every month, then I'd be rethinking whether I want to trust anything to TLS, yes. Browsers are awful, and tolerable only because they provide so much value (and even then, I overwhelmingly only run a browser with extra mitigations in place). And no, virtualization probably shouldn't be trusted against hostile code.
    - pjmlp 6y ago
      As long as we rely on languages like C for our foundations, we will have them, just not always on TLS, that is why it is so relevant to push for better foundations, even when most of us aren't doing systems programming.
rcxdude 6y ago
If you're relying on it for remote attestation (which is what signal is doing) it's not any use for that, because you have no real verification that the microcode has been updated.
- ENOTTY 6y ago
  In SGX, you do have verification that the microcode has been updated. This is known as the CPUSVN value, it is part of the SGX report that gets issued, and mixed into the keys used to sign reports.