2

Lets say we have a decentralized open source p2p chat client meant for secure communication. The main attack vector seems to be the (centralized) update mechanism. What methods and/or techniques can be used to minimize attacks during the update process. In the end a malicious developer can always introduce malicious code, so the best we can do is minimize those chances.

Some issues I have been thinking about just to get the ball rolling (but don't feel forced to answer those or limit yourself to those):

  • Should auto updates be used? And should they be applied instantly or is it worth it to wait a fixed amount of time allowing it to be pulled back in the case of a hack (coming at the cost of security bugs being out in the open for x days)?
  • Is a simple https connection (with pinned certificate?) be enough to prevent MITM attacks on the download file or should additional things be checked like a checksum downloaded from a different server maybe?
  • Can any steps be taken against for example the government (the only party that can legally do so) seizing the server and uploading a new version? (I was thinking along the lines of some kind of system where the file needs to be hosted in different jurisdictions or something)
  • Are there maybe ways to require at least n of m parties (developers) to sign the new version?

closed as primarily opinion-based by Eric G, TildalWave, M'vy, Xander, Mark Apr 19 '15 at 8:48

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • I realize this is a somewhat broad question and I specifically do not expect an answer to go into the how to's of executing proposed methods and/or techniques, but just giving an outline of possible ways to minimize dangers specifically related to the update mechanism whilst considering governments possible adversaries. – David Mulder Apr 16 '15 at 17:49
  • 1
    ". What methods and/or techniques can be used to minimize this danger." <- danger of eavesdropping, modifying the original update file... please clarify – Eric G Apr 16 '15 at 19:28
  • @EricG Not sure what point there would be to eavesdropping on an update mechanism. The danger is the introduction of an update that in this case would share chat messages with a third party. – David Mulder Apr 16 '15 at 19:37
  • See the edit made, it wasn't clear. – Eric G Apr 16 '15 at 20:36
1

Whatever your strategy, I think the first step is to sign your patches. No matter how many MITM there are, if the users can check your signature in a way they trust that will already provide a massive amount of certainty.

HTTPS is good, but it doesn't really do as much as the signature on your patch, HTTPS will make MITM more difficult, but not impossible.

If you open up auto-updates (configurable, of course), that means you also open up an attack vector. Depending on your philosophy, you can either choose to minimise the attack vectors to highten certainty, or you might feel that getting the security updates in your patches out wide and quick justify the increase in complexity.

You can also look into ways of providing out-of-band checksums, e.g. on external domains or over SMS. It is a lot harder to MITM your domain and your modem number than it is to MITM just your domain. Users that want certainty could use these checksums to see if the program they are running is the right one or if the patch they're accepting is valid. If any of the checksums disagree with another, that's a sign something fishy is going on.

As for the protection of patches within your server, taken far enough you are actually trying to protect against "authorised" intrusions and you want this protection to be verifiable by your users. This is quite a tricky thing to do.

If your project is open-source, you might look into deterministic builds, which Tor tries to do. This way a user could inspect the code (but no one does), and compare their build with yours. Might be lots of work and/or incompatible with your current platform.

If you persue using multiple keyholders or servers you might end up chin-deep in Byzantine fault tolerance, which you and your users might find an enjoyable endeavor, or you might find it to be difficult and tedious to work with.

Whatever you choose to do here, just try to keep it simple. As per AviD's law:

Security at the expense of usability comes at the expense of security.

  • Right now I am in the early phases of writing out a (pretty big) spec for a platform I have been dreaming of for years. You certainly gave me some new ideas (never heard of deterministic builds for example or Byzantine fault tolerance) though I still do not feel comfortable about the design I have so far for the update mechanism. But yes, I am trying to devise a model where authorized intrusions could be noticed by average tech-savvy users, half as mental exercise, but also because I know my history lessons. – David Mulder Apr 16 '15 at 19:52

Not the answer you're looking for? Browse other questions tagged or ask your own question.