search

freedomofpress / securedrop

GitHub repository for the SecureDrop whistleblower platform. Do not submit tips here!
https://securedrop.org/
Other
3.6k stars 683 forks source link

Upload to Tahoe-LAFS grid instead to local FS #106

Closed ghost closed 9 years ago

ghost commented 10 years ago

I was thinking that uploading to tahoe-lafs grid can secure the storage of the leaks.

garrettr commented 10 years ago

Can you explain in further detail the benefits of tahoe-lafs for our use case?

ghost commented 10 years ago

1) The organization which run Securedrop won't be prosecuted for storing the submitted content. The content won't be available on their systems. Not even encrypted.

2) Its harder to compromise a whole tahoe-lafs grid than two single computers. We are putting more randomness - we don't know where in the grid the content will be stored.

3) If grid is powered from large number of participants, the chance of broken hard disk and lost of valuable content is minimal.

4) As the Tahoe Lafs grid will be in the middle between the source and the storage interface, and other people will be using the grid too, we adding one more layer of anonimity - will be harder to find which is the journalist interface server connecting to the tahoe-lafs introducer to get the content from the source.

5) Tahoe-LAFS Is really cool.

garrettr commented 10 years ago

This looks like it has some very beneficial properties. We should keep it in mind as we evalute #85.

DrWhax commented 10 years ago

I would love to hear the thoughts on this from the tahoe-lafs team! I will forward this to them.

fpietrosanti commented 10 years ago

@DrWhax when discussing with @zooko for the integration with http://github.com/globaleaks/globaleaks we identified that the best way to integrate any kind of third party application is to use the REST interface.

https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/frontends/webapi.rst

The same approach i think will apply to SecureDrop.

ABISprotocol commented 10 years ago

Decentralization is good.

david415 commented 9 years ago

After several conversations with both James and Gerrit, it seemed like they were not interested in exploring Tahoe-LAFS integration. If this is indeed the case then I suggest closing this ticket to state that intention... otherwise I would be interested in assisting with the Tahoe-LAFS integration.

garrettr commented 9 years ago

@david415 Thanks for reviving this issue!

I have had numerous conversations with various people involved in the Tahoe project (yourself included) about the potential value of Tahoe for SecureDrop. The consensus has seemed to be that there isn't much. Allow me to explain why, and how Tahoe could be useful if SecureDrop were designed differently.

At the moment, every organization that operates a SecureDrop runs their own isolated instance. This means that there is little benefit in using Tahoe rather than just storing data locally on the instance.

I could see Tahoe being potentially beneficial in the following imaginary use cases:

  1. A SecureDrop instance operator wants to use a Tahoe grid that they've set up for their own reasons
  2. Maybe a SecureDrop operator has a limited amount of storage available on their SecureDrop server and wants to use untrustworthy cloud storage (S3, etc.). I'm assuming that Tahoe has a way to sensibly integrate with common cloud storage backends. This would still likely be unworkable "out of the box", since the 3rd party would learn information about submission timing and approximate size, and SecureDrop would have to implement mitigations for such information leakage vectors.
  3. Maybe SecureDrop's architecture is changed so all of (currently isolated) servers communicate with each other for various purposes. Perhaps they could collaborate to frustrate traffic analysis. Perhaps they could all be in a Tahoe grid, and the takedown of any one instance would not necessarily result in the loss of that instance's information.
    • While collaborating SecureDrop servers sounds like a cool idea, I am not sure that it is a good one. At least in the US, that would probably imply that the SecureDrop operators are third parties, since they would be storing information on behalf of other people/organizations. As a result, the third party doctrine would apply and would make those instances much more vulnerable legally.

SecureDrop's design means Tahoe offers little benefit, at least as far as I can see. I would love to hear any interesting potential uses that I haven't mentioned here.

In the meantime, SecureDrop operators are probably best off using RAID and performing regular encrypted backups of their data.

zooko commented 9 years ago

Hi there! I'm one of the architects and maintainers of Tahoe-LAFS. I think I agree with what @garrettr said in https://github.com/freedomofpress/securedrop/issues/106#issuecomment-68800996, as far as it goes. I wanted to add a few things.

Tahoe-LAFS has many features:

What @garrettr wrote in point 2 of https://github.com/freedomofpress/securedrop/issues/106#issuecomment-68800996 applies to the remote-storage feature of Tahoe-LAFS. His objection about traffic analysis in point 2 is very valid!

What he wrote in point 3 applies to the "use servers from different organizations" feature, and what he wrote about it seems valid to me.

But what about the other features?

Easy uses for Tahoe-LAFS right now

Well, the first thing that comes to mind is from the end of Garrett's note:

In the meantime, SecureDrop operators are probably best off using RAID and performing regular encrypted backups of their data.

That seems like a good practice, and I think Tahoe-LAFS would be an excellent tool to handle the "regular encrypted backups" part of it. You could use Tahoe-LAFS for just that purpose, as an alternative to, say tarsnap (https://www.tarsnap.com/), and you don't have to think about any of the ideas further down in the rest of this note. :-)

So, seriously, just because I suggest a few more possibilities below, please don't let the flaws or limitations of those schemes reflect badly on the option of just using Tahoe-LAFS as your secure backup tool.

More advanced uses of Tahoe-LAFS, still exclusively on the server side

Okay, now what about the other features of Tahoe-LAFS that we haven't really touched on yet?

• confidentiality

It might be possible to make it so that if a SecureDrop server is seized, or imaged, by an enemy, that only those messages and replies which were actively being examined by legitimate users at the time of seizure are visible to the enemy, and all other messages and replies remain undecryptable, even if the enemy uses the technique of keeping the server powered up and imaging its memory when seizing it. This is a natural consequence of Tahoe-LAFS's capability-based encryption architecture.

• integrity and access control

It might be possible to have an unforgeable history of documents, so that if an enemy compromises a SecureDrop server and sabotages the contents of some documents, the administrators can use the unforgeable history to determined which documents were corrupted, and when, and which documents are still unchanged since before the compromise.

More advanced uses of Tahoe-LAFS, end-to-end

Those ideas above are about an architecture in which the client-side is still a vanilla TBB. If the client has Tahoe-LAFS itself, for example, if Tahoe-LAFS were included with Tails (https://labs.riseup.net/code/issues/6227#note-20), then this would be a very good solution to the "end-to-end encryption" goal: https://github.com/freedomofpress/securedrop/issues/92

In this case, all of the confidentiality, integrity, and access control properties would be extended from the computer of the submitter (if she were using a full Tahoe-LAFS client instead of a web client), to the computer of the journalist.

Reiterating what I just wrote

dolanjs commented 9 years ago

Thanks for that write up @zooko. First, I do think there are plenty of use cases for Tahoe-LAFS in support of journalists and film makers that we work with and it definitely could be a solution to some of the issues they are facing. The ability to use Tahoe-LAFS grid for the journalist or filmmaker's file storage/backup (non SecureDrop stuff) while crossing borders and travelling makes a lot of sense and something we would like to look into more in the future.

For:

Tahoe-LAFS can be used, today, as a backup tool which provides strong encryption for the backups. I am not aware of any reason not to start doing this right away.

Currently we are storing the backups on airgapped Tails persistent media. Which at least for now is simpler and I'm not sure what we would gain by moving that back to networked computers.

Tahoe-LAFS might be useful as a safer server-side storage tool for, at least, the messages and replies. This would require coding and maybe architecture changes. I'm not entirely sure how difficult it would be, nor am I sure what security SecureDrop already has for the messages and replies.

Currently the messages and replies are gpg encrypted and stored locally on the server until the journalist downloads and transfers them to the airgapped host. The gpg private key used for decryption only exists on the airgapped host. After viewing the documents on the airgapped host the journalist secure wipes the docs off the server.

zooko commented 9 years ago

Currently we are storing the backups on airgapped Tails persistent media. Which at least for now is simpler and I'm not sure what we would gain by moving that back to networked computers.

Oh, okay, that makes sense.

Currently the messages and replies are gpg encrypted and tored locally on the server until the journalist downloads and transfers them to the airgapped host.

Oh! I'm surprised because when I looked at the docs (https://github.com/freedomofpress/securedrop/blob/develop/docs/journalist_user_manual.md#interact-with-sources) I interpreted it as showing documents available only on airgapped computer, but messages as available through the web ui. Now that I look again, I'm not sure why I thought that. Apologies for wasting your time with my misunderstanding.

So, the only remaining use that SecureDrop might have for Tahoe-LAFS is:

david415 commented 9 years ago

ah yes but iirc those gpg encrypted messages are actually encrypted on the securedrop server... therefore they are not end to end encrypted and Tahoe-LAFS could improve that situation.

on the other hand it is interesting to note how google and yahoo are going to solve this problem... with in-the-browser-cryptos.

dolanjs commented 9 years ago

@david415 you are correct the submissions and replies are both encrypted on the server not client side. Source submissions are decrypted on an airgapped, and Journalist replies are encrypted and decrypted on the server. We do have a road map to a native client/browser plugin to move the encryption/decryption to the Source's client for the SD 1.0 version.

Correct me if I'm wrong, but even if we leverage Tahoe-LAFS clients for both the source and journalist clients in some fashion, when the document is retrieved on the journalist end it will be in clear text. That is doesn't actually provide end to end encryption to an airgapped host.

garrettr commented 9 years ago

Since we don't have a clear use case for integrating Tahoe-LAFS with SecureDrop at the moment, I am going to close this issue for now.

Zooko mentioned some interesting ideas in his comments, so I've made a note of this issue and we might consider revisiting it in the future.

ABISprotocol commented 9 years ago

I have a nice solution for this problem.

Encrypt the journalist and send the journalist to the server. Then the document never would have to be retreived on the journalist's end. This solves the problem of tahoe-lafs not actually providing end to end encryption to an airgapped host, for example.

The only other issue is how to you encrypt the journalist and get the journalist into the machine in some kind of encrypted format. This is a difficult endeavor, but I think there is a way. I believe the answer was found in the beginning of the movie 'Timeline' (2003).