3 ms·

I don't know that you really need to put emphasis on "super secret way to break SGX". Any single attestation private key, combined with cooperation from Signal

I don't know that you really need to put emphasis on "super secret way to break SGX". Any single attestation private key, combined with cooperation from Signal (or a compromised Signal operations admin) will suffice. SGX attestation has now been publicly broken twice in two years, first with Foreshadow and then with SGAxe. To give some color to what "publicly broken" means: there's currently a live Twitter bot put up by UM that signs valid attestations using an extracted (non-revoked last I checked) SGX attestation signing key [1]. The previous exploit, Foreshadow, also had one [2]. Enclaves with the very latest microcode updates will reject those attestations (and Moxie says Signal has installed those updates, which I believe), but this vulnerability is now several months old and has been in non-public disclosure for most of that time, long before microcode updates reached end-customers like Signal. This means that any of a team of grad students and professors who worked on this paper (and this is only one such team doing this work) had access to the ability to "super secretly break" SGX during that time. Based on the team's track record: I would personally bet $500 that some team regains this capability sometime during the next 12 months, using an as-yet-undisclosed new exploit. So we're not talking about "NSA levels of exploitation" here. We're talking about "can I pay a smart grad student" levels of exploitation. And one such exploit, combined with Signal's cooperation, means the loss of all backup data in an irrevocable and untraceable way. [1] https://twitter.com/SGAxe_AaaS https://twitter.com/SGAxe_AaaS [2] https://twitter.com/foreshadowaaas https://twitter.com/foreshadowaaas

Arnt 6y ago
If an attacker can force Signal's cooperation, why does that attacker need to worry about SGX at all? Isn't it necessarily simpler to force Signal to change the client? The unique thing here is that Signal controls both sides of the SGX barrier. The strength of the SGX barrier is not terribly important when the same party is on both sites. Not completely unimportant, but not nearly so important as when the attacker is someone else.
- matthewdgreen 6y ago
  Every discussion about encrypted messengers has to begin with the assumption (ideally backed up by actual technical efforts) that the client software is secure. If you can’t make that assumption, there’s no need for any security mechanism. You could just as easily say “why use end-to-end encryption, just send data through the servers in plaintext, since a client compromise could functionally eliminate any protection offered.” In practice what designers do is they try to build the most secure system they can, under the assumption that they can prevent a forced compromise/update of the client. To do anything else makes the entire problem foolish, because then nothing works. In practice, there are real (if not perfect) defenses against a forced client compromise. From a technical perspective, Signal uses reproducible builds, at least on Android. They are also legal: we haven’t seen any court case where a US company has been forced to push software updates, although we do see routine attempts by law enforcement to gain data from back-end systems —- eg Yahoo, Lavabit. Nobody says Signal’s client defenses are perfect, and we aren’t yet in a world where client compromise is absolutely ruled out. But the problems of designing a secure back-end and a secure client are largely separable. You can work on both at the same time, and being imperfect in one area does not justify a bad solution in the other.

Arnt 6y ago

If an attacker can force Signal's cooperation, why does that attacker need to worry about SGX at all? Isn't it necessarily simpler to force Signal to change the client? The unique thing here is that Signal controls both sides of the SGX barrier. The strength of the SGX barrier is not terribly important when the same party is on both sites. Not completely unimportant, but not nearly so important as when the attacker is someone else.

matthewdgreen 6y ago
Every discussion about encrypted messengers has to begin with the assumption (ideally backed up by actual technical efforts) that the client software is secure. If you can’t make that assumption, there’s no need for any security mechanism. You could just as easily say “why use end-to-end encryption, just send data through the servers in plaintext, since a client compromise could functionally eliminate any protection offered.” In practice what designers do is they try to build the most secure system they can, under the assumption that they can prevent a forced compromise/update of the client. To do anything else makes the entire problem foolish, because then nothing works. In practice, there are real (if not perfect) defenses against a forced client compromise. From a technical perspective, Signal uses reproducible builds, at least on Android. They are also legal: we haven’t seen any court case where a US company has been forced to push software updates, although we do see routine attempts by law enforcement to gain data from back-end systems —- eg Yahoo, Lavabit. Nobody says Signal’s client defenses are perfect, and we aren’t yet in a world where client compromise is absolutely ruled out. But the problems of designing a secure back-end and a secure client are largely separable. You can work on both at the same time, and being imperfect in one area does not justify a bad solution in the other.