Skip to content

SecureDrop Research Project Ideas

Jump to bottom
Conor Schaefer edited this page Nov 5, 2021 · 15 revisions

Context and strategy

Securedrop-related project ideas suitable for short-term engagements are useful to have for programs like Google Summer of Code, as well as for students and researchers looking to engage with the project in an academic contest. FPF participated in GSoC in 2018, offering the following suggested areas of focus: https://github.com/freedomofpress/securedrop/wiki/Google-Summer-of-Code-2018-Ideas

Some of the GSoC ideas have already seen some action, some may no longer be valid, and new ideas may have come up since. The purpose of this async meeting was to brainstorm on updated project ideas, with the assumption that said ideas should be achievable by an individual - with some level of mentoring support - within a time frame of about 3 months.

Logistics:

General findings:

  • It would be important to budget for mentoring time - this is more true for projects like GSoC and Outreachy than for thesis work, but it should be expected that all projects will require at least some team time.
  • Projects like SecureDrop Workstation have a significant barrier to entry, mostly due to Qubes and hardware requirements. Supporting simplified development environments that can run at least part of the system on typical systems (OS X, WSL (maybe?), virtualized Debian boxes) should be a priority.
  • For short-term projects involving security-sensitive topics (addressing vulnerabilities, audits, etc), it would be helpful to have standardised processes for creating private repos, working with 3rd parties, and integrating the results back into the public codebase.

Project Ideas

Suggested ideas can be roughly categorized as follows:

SecureDrop Workstation Features:

  • Add encrypted journalist-journalist conversations to the SecureDrop client. Currently, the client supports conversations initiated by sources, with journalists having the ability to reply to sources and download/view submissions. A more general client would support journalist-to-journalist conversations as well, potentially including file sharing.
  • Add Signal integration. It is possible to set up a Qubes VM running Signal Desktop in order to share files and messages, but the sharing process is clunky, involving: exporting from the client to an encrypted USB; re-attaching the USB to the Signal VM; and importing from the USB. More direct integration would make it easier for journalists to communicate with other team members not using SecureDrop.
  • Add Veracrypt integration. The workstation's export-to-USB functionality currently supports LUKS-encrypted USB drives only. Adding Veracrypt as an option would make it easier to work with submitted documents on non-Linux OSes while preserving the encryption-at rest requirement
  • Add per-source DispVMs. Currently each submissions is viewed in a separate disposable VM, to protect against malware. This can get costly in terms of system resources in practice, as a full VM must be started for each submission. As per https://github.com/freedomofpress/securedrop-workstation/issues/333 one alternative would be to open all the submissions from a given source in a single disposable VM.
  • Add a custom file-handling Qubes-RPC service. A critical role of the SecureDrop Workstation is to handle untrusted documents, of various formats, safely. Currently we rely heavily on MIME type interpretation, which has some unpleasant failure modes. Perhaps we should create a new Qubes RPC service to handle filetype associations. Some initial discussion in https://github.com/freedomofpress/securedrop-workstation/issues/671
  • Set up full automated end-to-end testing for SecureDrop Workstation.

SecureDrop Server Features:

  • Use Signal to deliver high-severity OSSEC alerts - OSSEC alerts are currently delivered via GPG-encrypted email. While relatively secure, this is inconvenient, not least because the alert threshold is pretty low so the message signal-to-noise ratio is pretty high. Using Signal to deliver high-severity messages would provide admins with more immediate and useful information.
  • Replace OSSEC with an app-server-hosted IDS and notification system. The monitor server's sole purpose is to run OSSEC. While an intrusion detection system is an important SecureDrop component, it would be worth investigating replacing OSSEC specifically with a tailor-made system that could run on the application server, making OSSEC (and the monitor server) optional.
  • Add FDE support to the servers. SecureDrop servers are rebooted nightly as part of their update cycle, and also to ensure submissions are not stored in memory indefinitely (thanks, Python). This makes FDE with manually-entered passphrases impractical. A project to investigate alternative approaches (storing FDE credentials in a TPM, supporting remote entry of passphrases, etc) would help to improve the physical security of SecureDrop servers.
  • Investigate grsecurity alternatives. SecureDrop uses grsec-patched kernels, offering protection against a wide range of attacks (buffer overflows in particular) but also complicating hardware support. This project would investigate alternative approaches (eg. hardened malloc implementations) to achieve the same security goals while reducing hardware compatibility issues.
  • Add DDOS protection to SecureDrop. SecureDrop is vulnerable to DDOS attacks against the Source Interface. This project would investigate anti-DDOS solutions suitable for use on the Tor Network (eg Endgame integration, adding an optional captcha, adding support for OnionBalance)

Research and Prototyping

  • E2EE support. Work is ongoing (slowly!) on a prototype version of SecureDrop using the Signal protocol and Rust+WASM to replace GPG and get closer to a full e2ee workflow. This project would continue and extend this protoype, and could cover areas such as adding file uploads, disappearing messages, or adding signature verification of the client-side WASM code.
  • Research: Is the 500MB upload limit still valid? A limit was set on file upload sizes due to network observability/deanonymization concerns. Is this limit still valid given the current state of the Tor Network?
  • Research: are HTTPS onion services riskier than HTTP?: Some SecureDrop instances use TLS and EV/DV certs to prove their validity - does this increase circuit fingerprintability? (Note: This is more a Tor concern than a strictly SD concern.)
  • Research: Are there compelling alternatives to Tor and GPG in the current SecureDrop architecture? Alternative anonymization technologies to Tor include i2p and nym. GPG could also be replaced with other encryption technologies such as age. Do any of these alternatives offer significant improvements over the current choices?

Pad archive

(pad snapshot for posterity: fpf-epic-brainstorm.txt) 
GSoC-alike/Thesis/Internship Project Ideas - Brainstorming

Logistics
Asynchronously open for participation until 28 Oct 2021
Sync meeting time: 20 Oct 2021  1330 Eastern
Sync meeting: meet.google.com/ekb-kkhf-mrk

Intro
We started work on this during the synch meeting on Oct 21 - it's now available as a worksheet for folks working through it asynchronously. Instructions are italicized below.

Who's Here and how are you feeling??? 
Write your name and a word/phrase describing how you're feeling right now as you fill this out 
	* [ example of something a participant might write: Sisi Wei, excited ]
	* 
	* 
	* 
	* 
	* Abigail, just observing :)
	* Gonzalo, curious. I'll probably be mostly observing :)
	* Conor, stoked to try a new meeting regimen. Really liking the inclusive nature of the explicit pro-async framing.
	* Erik, beep boop! I am asynchronous participant (may join later)
	* Kev, feeling a tad apprehensive
	* Cory, appreciative of the opportunity to follow and contribute async beforehand and/or (in this case) afterwards!
	* Allie, contemplative about how i am feeling introspective


Context and strategy
A potential contributor recently reached out via https://forum.securedrop.org/t/project-ideas/1431 looking for help  picking something SecureDrop-related to work on for a thesis project. They'd independently found https://github.com/freedomofpress/securedrop/wiki/Google-Summer-of-Code-2018-Ideas and expressed an interest in the first idea (better monitoring) but didn't know if it was still a priority and wanted some advice.

Some of the GSoC ideas have already seen some action, some may no longer be valid, and new ideas may have come up since. To help this person and others looking for larger projects than a single issue, we could put together a list of ideas along with related metadata as per the GSoC list, and make that available publicly.
The purpose of this session is to brainstorm on ideas, with the assumption that said ideas should be achievable by an individual with some level of mentoring within a timeframe of about 3 months. It's also assumed that we'll follow the same format as the existing GSoC ideas. (Please feel free to challenge said assumptions)

	* [Collective notes welcome here!]
	* 
	* 
	* 
	* Should we remove/archive the GSOC 2018 wiki page?
	* https://securedrop.org/research/ <-- Published research, should we post CFPs there too?
	* https://github.com/freedomofpress/securedrop-workstation/issues/602 <-- SecureBoot research ask, for Workstation
	* Likely we should capture any and all of those ideas in the GH wiki (seems like an accessible, visible, easy to edit)


Check-in Moment: After hearing (learning about? hearing/reading) the context and strategy, how clearly do you understand the context and reasoning behind what we’re doing? (1 being "I'm really confused", 3 being "I think I get it", 5 being "It's crystal clear I could explain it to someone else")
	* 
	* 
	* 
	* 
	* 
	* Gonzalo 5
	* Conor 5
	* Erik 13/10 would async again
	* Kev sez 5
	* Cory: 5.  This is like giving context for a pull request, but in the case of a meeting what you're pulling/requesting is folks' time and attention!  :-)
	* Allie, 3 (when is the sync meeting mentioned above?)


Reflecting back on past experiences
Pick one of the following prompts and share your response below:
1. How have similarly-scoped projects like this worked out before for participants?
2. Based on prior experience,what could we do to optimise both for good participant outcomes and for useful project outcomes?

Responses/thoughts/reactions:
	* 
	* 
	* 
	* 
	* 
	* I'd make sure we allocate a resonable amount of time for someone* to dedicate to supporting/collaborating/stakeholding with the participant, as they will likely not have most of the context that day-to-day experience provides us all. *I believe it's important for that person to be familiar with the project goals, and with how the project outcome would fit within FPF's larger goals.
	* +1, that's certainly key for programs like Outreachy & GSoC. For a thesis the person will want to operate with a fair degree of autonomy so we'll want to find the right balance.
	* In the past, such as with osresearch's suggestion about SecureBoot in the Workstation, we tend to refer the interested party upstream, so that we can minimize our maintenance obligations while maximizing impact of the work if it's accepted.
	* SD/W can be extremely challenging to get started with: containers exist for server code dev, but installing Qubes for Workstation dev is a big ask.
	* Having time/resources available for mentoring is important - expectations need to be set and it needs to be included in planning
	* Agree with the above. Also in-house mentorship is a useful way to build our mentorship muscles.


What stuck with you from the responses above?: 
If others have shared already, read through their responses above, and if something really strikes you, jot it down below. If you're the first person to do this, come back later in the week and see if there's anything you want to react to!
	* 
	* 
	* 
	* 
	* 
	* We seem to assume that most SD development will be performed by FPF staff, or at least an SD expert.
	* We aren't explicitly allotting time for external mentorship (well, recently we've started with Outreachy!)
	* We tend to assum a uniform and pretty beefy development setup (possibly even a dedicated Qubes machine) - this may not work for non-staff
	* For the client, we have ways to do most development without Qubes. Since Debian is free and easy to run in a VM, it's a good option for newcomers. I think clear system requirements is extremely helpful rather than poorly maintaining too much hardware
Brainstorm time!!! 
Before reading any ideas below, do a free form brainstorm and jot down your ideas below. Once you're done, read through what others have written below and add reactions (such as +1) or comments if you want to share more or iterate on an idea, or just give it more love. Finally, when you're ready to move to the next section, add some blank lines right below these instructions, like you see now, so the next person can have some blank space to work!
Prompt: Here's a cool SD-related project for someone to work on...
	* 
	* 
	* 
	* 
	* focus on e2ee
	* support encrypted conversations between journalists
	* signal vm integration with the client
	* sanitization workflow
	* create a *-security private repo for the rest of our repos (also convert securedrop-security to a private clone) and start tracking more of our security conversations there when there is a vulnerability or audit that involves bugs
	* add a more user-friendly api for building reproducible wheels: https://github.com/freedomofpress/securedrop-security/issues/64
	* support veracrypt
	* Get high severity OSSEC alerts via Signal: https://github.com/freedomofpress/securedrop/issues/3182
	* Replace OSSEC with a more tailor-made notification system that lives on the app server and treat OSSEC as an optional part of a SecureDrop setup or deprecate it entirely
	* Explore ways to fully support full-disk encryption on the server
	* SecureBoot support! https://github.com/freedomofpress/securedrop/issues/5867
	* grsec alternatives?
	* End-to-end testing strategies for Qubes
	* Per-source DispVMs: https://github.com/freedomofpress/securedrop-workstation/issues/333
	* What if SecureDrop but not GPG (swapping in e.g. age strikes me as a passable improvement, just without the complexity of a migration)
	* What if SecureDrop but i2p or nym instead of Tor? (comparative properties of anonmyzation networks in the context of a whistleblowing app?)
		* +1 given past comments from Kev, Ro, &a. re: countries where a Tor dependency is a nonstarter.
	* Is the 500MB upload limit reasonable? A lot has changed in the past years. Is there a meaningful impact on network observability/deanonymization for very large (e.g. >1GB) uploads?
	* Does using HTTPS over Onions increase circuit fingerprintability? (This is more a Tor concern than a strictly SD concern, but still interested to know).
		* ^ These last two suggest a distinction between "ecosystem research" projects and "SecureDrop R&D/prototyping" projects.
	* Adding DDOS protection to SecureDrop (eg. Endgame threat modeling/integration, adding an optional captcha, Onionbalance support)
	* Custom file-handling RPC service for Qubes


Next steps
#1: Who's willing to provide low-effort advice/mentorshop to external contributors, and for what ideas?
	* 
	* 
	* 
	* Allie: I will commit to team, project-based, and outreachy (or a similar org) mentorship
	* Happy to provide some product-y guidance on notification systems for admins
	* Conor is interested in network/onion/ddos research
	* Cory is interested in "shadowing" mentorship (if/as appropriate), (a) to connect past (e.g.) network-stack interests to the SecureDrop project and (b) to learn from this kind of relationship- and capacity-building in an open-source project.
	* 

#2: Can you commit to writing a short blurb about a idea, including skill prerequisites, relative difficulty, links to docs? (if yes, which do you want?)
	* 
	* 
	* 
	* See https://www.outreachy.org/outreachy-december-2021-internship-round/communities/securedrop/
	* Could expand on alerting/OSSEC issues above; end-to-end testing for SecureDrop Workstation
	* Sure, Conor would be happy to provide a blurb on forum thread, provided folks agree that the network/onion/ddos ideas are worth sharing
	* Kev also into writing up the DDOS one and the ones about swapping out different parts of the tech stack.
	* 

This meeting template is licensed by Creative Commons (CC BY 3.0) by OpenNews, and was created by Sisi Wei during her RJI Fellowship in support of the DEI Coalition.
Clone this wiki locally