3 ms·

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

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

by Arnt 6y ago

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.