5 ms·

Is there any mechanism to validate that the code running on Signal's servers is the same as on Github?

knocte 6y ago
No.
Someone1234 6y ago
How would that work? You'd be layering trust on trust, wherein if they're willing to lie about one thing they're willing to lie about confirmation of that same thing (or not). Unless you're going to hire some independent auditor (that you still have to trust) it seems logically problematic.
- madars 6y ago
  SGX enclaves can attest to the code they are running, so you don't exactly need to take Signal's word on faith.
  - eptcyka 6y ago
    Except SGX enclaves are horribly broken.
    - monocasa 6y ago
      Like, does an SGX enclave attest that meltdown is patched in microcode? That's one way to pull the keys out. The recentish work to get read write access to some Intel CPU's microcode can probably break SGX too. I wouldn't be surprised if the ME code execution flaws could be used that way too.
  - Someone1234 6y ago
    That isn't a solution to the problem being discussed (a provider's server code being verifiable by end users). I'm quite confused by the suggestion that it could be/is.
Foxboron 6y ago
There isn't, but people are working on getting us there. The first project that comes to mind is "System Transparency". https://system-transparency.org/ https://system-transparency.org/
mikece 6y ago
Seems there should be an API endpoint, similar to a health check endpoint, that allows one to validate that the code on the server matches what's in GitHub. How exactly that would work is beyond me since I'm not a cryptographer but seems like an easy way to let developers/auditors/the curious check to see that the code on the server and GitHub match.
- monocasa 6y ago
  validate_endpoint() { return hash_against_other_file_not_exe(); }
- beaconstudios 6y ago
  if you assume that the server can lie to you, then it's physically impossible. Any query could be answered by interrogating a copy of the github version of the server and returning the answer.
- jhugo 6y ago
  How could that possibly work? The API endpoint of a malicious modified server could just return whatever the API endpoint of the non-malicious non-modified server returns.
monocasa 6y ago
That's basically the same problem as DRM, so no, you can't verify that someone is running only code you want them to run against data you gave them, on hardware they own.
- lxgr 6y ago
  Yet DRM does exist. (Yes, these schemes usually end up getting broken at some point, but so does other software.) The problem is more generally called trusted computing, with Intel SGX being an implementation (albeit one with a pretty bad track record).
  - monocasa 6y ago
    DRM has only been successful in the space of making easily replicable attacks more expensive than what is being protected by the DRM. Microsoft has talked about this publicly in this great talk on the Xbox One's physical device security. 'We can't stop people hacking, but we can make each hack more expensive than what someone would spend on games on average'. https://www.youtube.com/watch?v=U7VwtOrwceo https://www.youtube.com/watch?v=U7VwtOrwceo SGX running on centralized servers turns that calculus on it's head by concentrating the benefits of the hack all in one place.
danpalmer 6y ago
I think the argument would be that with end-to-end encryption this is unnecessary, which is good because it's impossible. There's a counter-argument that there is still useful metadata a server can glean from its users, but it's certainly minimised with a good protocol... like the Signal protocol.
- cortesoft 6y ago
  Wait, how would end-to-end encryption help this problem at all? I agree that it is impossible (currently), but not sure how E2E helps anything? E2E encryption only helps you verify WHO you are connecting to, not what they are doing with your connection once it is established.
  - gsich 6y ago
    Because it doesn't matter what the server does in terms of message content.
  - iudqnolq 6y ago
    Because the other end in E2E is your friend's phone, not a server. We call end-to-server encryption "in-flight" encryption.
    - cortesoft 6y ago
      Ah, ok I misunderstood
edejong 6y ago
Yes. Auditors Trusted Enclaves (but then you trust Intel) Signed chain of I/O with full semantics specified (blockchain style).
hoophoop 6y ago
No. If Signal /was/ federated it would be a strong hint that the server code stays the same. And even if it's not the same, people would be able to run their own trusted servers.
- ViViDboarder 6y ago
  Federation pretty much guarantees the opposite. There would likely be many servers running many different versions whereby you’d have no way of knowing which are trusted or not. It, by design, distributes trust. This means there are more parties to trust. Anyway, Signal is designed to handle all the private bits at the client side with e2ee so you have to put as little trust in the server as possible.
gorkish 6y ago
I am curious how this could even possibly be done. As far as my understanding goes, it's hardly possible to even verify that a compiled binary represents a faithfully executed representation of the source instructions, let alone that it will execute that way when run through a modern OS and CPU pipeline. I would think the objective here is more about releasing server code that can be run independently in a way that 1) doesn't involve signal's infrastructure and 2) allows the client/server interactions to be audited in a way that trust of the server side is unnecessary, regardless of what code it may or may not be running.
jiveturkey 6y ago
Yes, via SGX remote attestation. https://sgx101.gitbook.io/sgx101/sgx-bootstrap/attestation https://sgx101.gitbook.io/sgx101/sgx-bootstrap/attestation
deleted 6y ago
[deleted]
codethief 6y ago
As others have already mentioned there is Intel SGX and the Signal developers indeed say they use it, see https://news.ycombinator.com/item?id=26729786 https://news.ycombinator.com/item?id=26729786

No.

How would that work? You'd be layering trust on trust, wherein if they're willing to lie about one thing they're willing to lie about confirmation of that same thing (or not). Unless you're going to hire some independent auditor (that you still have to trust) it seems logically problematic.

madars 6y ago
SGX enclaves can attest to the code they are running, so you don't exactly need to take Signal's word on faith.
- eptcyka 6y ago
  Except SGX enclaves are horribly broken.
  - monocasa 6y ago
    Like, does an SGX enclave attest that meltdown is patched in microcode? That's one way to pull the keys out. The recentish work to get read write access to some Intel CPU's microcode can probably break SGX too. I wouldn't be surprised if the ME code execution flaws could be used that way too.
- Someone1234 6y ago
  That isn't a solution to the problem being discussed (a provider's server code being verifiable by end users). I'm quite confused by the suggestion that it could be/is.

Foxboron 6y ago

There isn't, but people are working on getting us there. The first project that comes to mind is "System Transparency". https://system-transparency.org/ https://system-transparency.org/

mikece 6y ago

Seems there should be an API endpoint, similar to a health check endpoint, that allows one to validate that the code on the server matches what's in GitHub. How exactly that would work is beyond me since I'm not a cryptographer but seems like an easy way to let developers/auditors/the curious check to see that the code on the server and GitHub match.

monocasa 6y ago
validate_endpoint() { return hash_against_other_file_not_exe(); }
beaconstudios 6y ago
if you assume that the server can lie to you, then it's physically impossible. Any query could be answered by interrogating a copy of the github version of the server and returning the answer.
jhugo 6y ago
How could that possibly work? The API endpoint of a malicious modified server could just return whatever the API endpoint of the non-malicious non-modified server returns.

monocasa 6y ago

That's basically the same problem as DRM, so no, you can't verify that someone is running only code you want them to run against data you gave them, on hardware they own.

lxgr 6y ago
Yet DRM does exist. (Yes, these schemes usually end up getting broken at some point, but so does other software.) The problem is more generally called trusted computing, with Intel SGX being an implementation (albeit one with a pretty bad track record).
- monocasa 6y ago
  DRM has only been successful in the space of making easily replicable attacks more expensive than what is being protected by the DRM. Microsoft has talked about this publicly in this great talk on the Xbox One's physical device security. 'We can't stop people hacking, but we can make each hack more expensive than what someone would spend on games on average'. https://www.youtube.com/watch?v=U7VwtOrwceo https://www.youtube.com/watch?v=U7VwtOrwceo SGX running on centralized servers turns that calculus on it's head by concentrating the benefits of the hack all in one place.

danpalmer 6y ago

I think the argument would be that with end-to-end encryption this is unnecessary, which is good because it's impossible. There's a counter-argument that there is still useful metadata a server can glean from its users, but it's certainly minimised with a good protocol... like the Signal protocol.

cortesoft 6y ago
Wait, how would end-to-end encryption help this problem at all? I agree that it is impossible (currently), but not sure how E2E helps anything? E2E encryption only helps you verify WHO you are connecting to, not what they are doing with your connection once it is established.
- gsich 6y ago
  Because it doesn't matter what the server does in terms of message content.
- iudqnolq 6y ago
  Because the other end in E2E is your friend's phone, not a server. We call end-to-server encryption "in-flight" encryption.
  - cortesoft 6y ago
    Ah, ok I misunderstood

edejong 6y ago

Yes. Auditors Trusted Enclaves (but then you trust Intel) Signed chain of I/O with full semantics specified (blockchain style).

hoophoop 6y ago

No. If Signal /was/ federated it would be a strong hint that the server code stays the same. And even if it's not the same, people would be able to run their own trusted servers.

ViViDboarder 6y ago
Federation pretty much guarantees the opposite. There would likely be many servers running many different versions whereby you’d have no way of knowing which are trusted or not. It, by design, distributes trust. This means there are more parties to trust. Anyway, Signal is designed to handle all the private bits at the client side with e2ee so you have to put as little trust in the server as possible.

gorkish 6y ago

I am curious how this could even possibly be done. As far as my understanding goes, it's hardly possible to even verify that a compiled binary represents a faithfully executed representation of the source instructions, let alone that it will execute that way when run through a modern OS and CPU pipeline. I would think the objective here is more about releasing server code that can be run independently in a way that 1) doesn't involve signal's infrastructure and 2) allows the client/server interactions to be audited in a way that trust of the server side is unnecessary, regardless of what code it may or may not be running.

jiveturkey 6y ago

Yes, via SGX remote attestation. https://sgx101.gitbook.io/sgx101/sgx-bootstrap/attestation https://sgx101.gitbook.io/sgx101/sgx-bootstrap/attestation

deleted 6y ago

[deleted]

codethief 6y ago

As others have already mentioned there is Intel SGX and the Signal developers indeed say they use it, see https://news.ycombinator.com/item?id=26729786 https://news.ycombinator.com/item?id=26729786