 Hello. Hi, everyone. We're going to get started. All right. So I'm Redshift Zero, and I'm the lead developer of SecureDrop, and I work at Freedom of the Press Foundation. So SecureDrop is a project where some people are working, it work at Freedom of the Press Foundation, and others work in the community. So today, we're going to talk about what SecureDrop is, if you're not familiar with the project, what the motivation is, the problems it's trying to solve, how the system architecture works, and then we're going to walk through how it works from the perspective of both sources and journalists. And then we'll talk a little bit about the challenges and pain points that people are experiencing and how we're trying to address them. And if people are interested in contributing, we would love that. Okay. So many of the most important stories that have been done via investigative journalism have been possible thanks to anonymous sources and leaked documents. So like Watergate, the snowdened disclosures, the pentagon papers, the list goes on. And it used to be the case that a journalist could protect their source by just not revealing the source's identity when asked. And that was sufficient. But today we know that in the surveillance state that exists in most countries, almost every interaction between one human and another is mediated in some way by a third party. And that third party is collecting data about who is talking to who. And so the government does not need to ask a journalist who their source is because there's a data trail that they can go and investigate. And specifically, they can do things like subpoena, the phone records of journalists. So if I'm trying to talk to someone at the Associated Press, the government can subpoena Verizon and get the telephone metadata and figure out that I'm talking to a journalist at the AP and identify me. And this is something in the US that's been done to leak investigations to identify sources and prosecute them. And this has happened many more times in the past 15 years than in the entire history of the US because it's now so easy to do so. So that's the problem that SecureDrop is trying to solve. And it's put nicely by this guy, Charles Barrett, who did a report on the impact of the SecureDrop project. We're trying to restore this privilege of reporters to protect sources and that'd be a meaningful action. So the approach is that we're trying to eliminate third parties from the equation. All data is encrypted at rest and in transit. We're doing this also to minimize the metadata trial between sources and journalists so everything is routed through Tor. And the servers that, where the submissions are stored are hardened to reduce risk of compromise. So this is a project that's been going on since 2012, 2013, started by the late Aaron Swartz. And Freedom of the Press Foundation took it over after he passed away. And now it's in about 50, 60 news organizations, including some of the biggest ones, mostly in the US, like New York Times, Washington Post, the AP that did get all our phone records subpoenaed, now does Run SecureDrop. So it's increasingly popular. So how does it work? So we have two servers, one that runs the SecureDrop application and we'll talk in detail about what that means. And one that is just monitoring the first server. And both of these are Ubuntu server and they run a G Security kernel. So just to make exploiting vulnerabilities, using memory corruption a little bit more difficult. The application server exposes two Tor-Onion services, but that are web applications, one for sources, one for journalists. It also exposes Tor-Onion services for admins to SSHN. And then the monitoring server is running a host-based intrusion detection system that's just monitoring the first server. And so alerts are sent when unusual activity is seen on the first server to administrators. And administrators in this context means people at the news organization that are charged with being the stewards of their SecureDrop. So they're not going to me or anyone at Freedom of the Press Foundation and we're not running them. Because that would be another third party. And then these two servers, we connect to a network firewall where the intention is that we're trying to segment off the SecureDrop network as much as possible from the rest of the news organization's network. And all of this is on-prem at a news org. So it's either in their data center or it's in a secure room or sometimes in the general counsel's office like the head lawyer at the news org. So if they are subpoenaed, they will know about it and they can fight it. They're not gonna, this legal order is not gonna go to a third party and they're gonna be gagged. So they will know and they can fight. So that's cool. So then on the workstation side, when a journalist is using SecureDrop, they have a special workstation where they boot to tails and they connect, again, via tour and in services to the application server. And then they have another workstation that is air-gapped. It has never touched the internet. Usually we recommend that people put epoxy in the network ports and remove physically all the wireless hardware from the laptops. So that's where the decryption of submissions is done. So I said the word decryption, so now I'm gonna explain that. So each deployment has an associated GPG key pair and the purpose of the application server or one of the purposes is to take submissions and encrypt them to the system's public key. And so everything on disk is encrypted. And then the only place where the private key to decrypt these submissions is stored is on that air-gapped station. So, and then everything's connected to tour or tour on in services, which we heard about just now, which was awesome. And then sources connect to an organization's SecureDrop using tour on in services only. There is no way that they can get to, well, unless they get clever for the average source, there's no way for them to get to SecureDrop without using tour browser. And that's to protect them. So now this kind of uses this. So first thing is a source needs to find out that SecureDrop A is a thing and B, a news organization is running it. And right now that happens in a bunch of different ways. So in one case, this is the Globe and Mail. They are a popular newspaper in Canada and they just put on the front page of their physical newspaper that they want to SecureDrop, what it is and they have a link to how you can access it. In other cases, we've seen in one case, someone had a billboard outside the Department of Defense in the US with their SecureDrop address on. It's pretty cool. And then I think a pretty interesting targeted approach is if you're interested in sources from a particular area, you might go to a conference where you know those people are gonna be there and then just fly them all. And that produces very little metadata, which is nice. So all of these kind of physical methods direct people to what we call the landing page. And the landing page in our nomenclature is the page on the news organization's website that describes what SecureDrop is, any operational security concerns that the source should be aware of and how to get to SecureDrop. And then we also, Freedom of the Press Foundation, have a directory of a subset of the SecureDrop instances that exist that have the landing pages, what orders are running them and the only address. So sources can cross-check, is this valid by looking at that directory? And that's also available over TorOnion services. We're a big fan of that. Okay, so the goal here are they have to be able to successfully download and install TorBrowser. So that's a barrier, but not that difficult to do for most sources. And they need to get the valid Onion address to access the source interface. And they have to do all of this without creating a data trail. So you could imagine other ways that people might find out about SecureDrop, like if they're searching in Google, that creates a data trail. And there's not a ton that we can do about that other than encouraging people to come in through these control channels. People have a clever idea there, would be very interested. So in terms of the landing page itself, there's a lot of concerns that we have there. One being an adversary can just passively monitor traffic of visitors to the news organization. So if I don't have HTTPS, then I can just go ahead as a passive observer and see. Source is connecting real source IP, because I'm not using Tor at this stage, is connecting to news org website slash super secret leaks. And that's a pretty clear indication of what they're doing. An adversary could also intercept and modify traffic to tamper with the content of the landing page. If I really wanna know where these leaks are, then I can just replace the Onion URL on the landing page with an Onion URL that I control. They could also get data from a third party. Most websites load stuff from all over the place. Ads on, certainly on news organizations, web pages, fonts, images. So if a landing page has an image that is only, that's loaded from a third party and it's only on the landing page, that is a very clear indication to that third party of who the sources are. Again, it's the source's real IP. Or I can just hack the web server. So in order to address these threats, and this is one of the reasons why our directory only contains a subset of secure drops because we check each landing page and kind of work with the news organization and go back and forth like, hey, you should almost definitely have HTTPS. And if they are not able to do that, then we don't put them in the directory. So to mitigate the passive monitoring, they must use HTTPS and they must enforce HTTPS. And they should avoid using subdomains. If your secure drop is hosted at superscret.newsorganization.com, that's not encrypted. So that's a problem. In terms of ensuring the integrity of the landing page content, again, HTTPS is helping us there. And then we check to make sure that all third-party trackers, ads, et cetera, are removed from just the landing page, requiring that for the entire news org website would be infusible. And then we encourage the news org to follow security best practices. Most of the big news orgs who are doing this, but in some cases will suggest that they get an external pen test. And sources can compare with the directory. So that's one of the reasons why we're doing this. So here's an example. This is the Associated Press of their landing page. So it has some details for sources. So let's say they download Tor, they fire it up and they copy, paste that currently short on in address, seem to be much longer, into the address bar. And they land on a page like this. So this is being served by the application server. And the source has two choices. They can submit documents or if they've already submitted something, they can return and continue interacting with the journalist. So journalists can respond and sources and journalists can maintain a kind of long-term relationship only through a secure drop. So sources get this code name and this is their username and password. So all I need to remember are these diceware words when they return on a future visit. And then they can just submit materials. It's a simple form. And they can submit any type of file and as many messages as they desire. So that's pretty simple. So what's going on? On the architecture side when this happens is a source, so let's zoom into the application server. A source is submitting information and as that hits the server, it's getting encrypted by a simple flask Python application. And then we store those encrypted submissions on disk and then we store a little bit of data about the source, the minimum necessary in a database. And so the data that we store are the code name. Obviously, we don't just throw the code name in the database. We hash and salt it because it's the password and then the journalist designation. So the journalist wants to talk with other journalists about sources. They might say, oh, colorful shower head submitted something yesterday. I think it might be interesting to you. You know, Glenn Greenwald. And so that's a way that journalists can communicate about that and those are auto-generated. And we also store the date and time that the most recent submission occurred so that we can show in the journalist side, you know, it's been two days or two days ago, Bob submitted something. Okay, so now let's kind of run through the journalist perspective real quick. So first, if you're not familiar with newsrooms, there are some constraints. It is very rare for a newsroom to have dedicated like digital security people. I can only think of like two news organizations, the New York Times and the Intercept, where that is the case. Journalists are usually non-technical. So if you are asking them to use the command line, it's gonna be a bad time. And some admins even might be less familiar with the Linux command line. They, in these enterprise environments, might be mostly using Windows. And so, you know, when we ask them to do certain things, they might kind of get a little frustrated. Another constraint is that journalists and admins often travel a lot and are distributed across several offices. So for a secure drop where we have a big focus on physical hardware, you know, there's an actual secure room in the news organization where someone is decrypting this stuff, we have to have some way for journalists and admins to communicate. And we usually recommend signal to do that. So again, when a journalist is logging in, let's zoom into the application server. They are using an onion service that is, so it's using this feature in Tornian service, Tornian service is called hit serve auth. So in order for that connection to be made between the journalist workstation and the application server, it is the case that the journalist must provide a secret that is in their tall config file. And so if they don't have that, they can't even connect. So that's a really great feature for a defense in depth. So they log in, they download the encrypted submissions from another simple Flask web application and they download those to the online workstation and then they must use either USB drives or in some cases CDs to shuttle them across to their air gap machine. And so in the case of CDs, this is a pretty laborious process where you're burning your CD and then you're taking it over and then if you wanna transfer stuff back, then you've gotta do it again the other way. But that is how it currently works. And people get used to it. They just put the two machines next to each other in the secure room. And once you've done it a few times, it becomes second nature. So this is the journalist interface is what it looks like. And again, pretty simple. They also send replies to journalists at two sources using the journalist interface so they can have a kind of long-term interaction. Okay, so one issue that we have found is that this procedure is very laborious as I described, you can imagine. And it's also the case that the air gap machine, it's not getting automatic security updates, obviously because we put epoxy in the network port. So it's kind of showing some age in some cases. So right now we use tails for both the secure viewing station and the journalist online station. And we did that for a few reasons. One is because it has integration with Tor. So that's already done for us. It has a lot of tools that are useful to journalists like the metadata anonymization toolkit, things like onion share, so journalists can send documents to other people in the newsroom if they desire. And what we really like is this amnesiac property. So when I reboot, then it's set to reset to a default state. And this is particularly relevant because SecureDrop is a system where you can submit something, anything, and it's definitely gonna be opened by a journalist. So obviously malware is a massive concern. And so that's why we like this amnesiac property. Even if maybe something bad happens, it's gonna reset to its default state. Something bad malware being submitted and opened by a journalist. So if there were a way that we could preserve the same level of security while making the process less onerous for journalists, that would be really excellent. As it's something that Cubes might be really great for. We again have the Tor integration with the Hoonix VM that Cubes has. And it provides these isolated environments. And something that's very cool is that we can now provision all the VMs using salt. So obviously we don't wanna have admins type out a bunch of commands, or hey, click this, then click that to set up all your VMs exactly as we desire. We wanna be able to do that in an automated way. And so that's something that we have a prototype for, which basically works as follows. The journalist workstation is now just what's called in Cubes an ameclature on our VM. And that connects through another VM that's running Hoonix, which has the hitser forth token, that secret that journalists must have in order to make a connection with a secure application server. And when a journalist downloads a document, they just double click and a document is magically opened in a disposable VM. So it's decrypted, it's open in the disposable VM. And then when they close the document, that VM is destroyed. So even if there is malware, it's just gonna pop that one VM. So that's pretty sweet. And so this is something that over the next year, we hope to have journalists test and see how they like it. We have a few journalists that we know of that are using Cubes as a daily driver, but there's still a lot of work to do there. So if this is interesting to people, I encourage you to join us. That's how it works right now, but you could also imagine a VM for printing or a VM for doing research. So this sky's the limit, well memory's the limit, but yeah. Okay, yeah. So if this is interesting to you, I hope that you found this interesting. If you're a developer or you write documentation or you wanna translate, that would all be excellent. Our chat room where we do development chat is listed here, take a picture of the slide. And then our two code repositories, one that has server side code, and then one that has the Cubes prototype workstation. And then here the developer getting started docs. PulverQuests, welcome. Thanks, that's it. Escape the host and then gets, well acquires the private key. Yeah, so the question was, don't we have concerns about if we're moving to VMs, attacks that escape the host and acquire the private key? And yes, that is definitely a concern. And so the, I mean, that's like the main concern. So for us going forward, the question is, is it better to have a less usable gap environment where we don't really have guardrails? For example, there's no client program running in the air gap. Or, but it is air gapped. And there have been attacks trying to jump the air gap in production secured wraps, which is concerning. Or is it better that we move to this environment where that is possible if someone has, you know, a million dollar exploit, they could potentially get the private key, is it better that we do that and have all those guardrails so that, you know, the experience is as contained as possible and people can't, yeah. Go off. Hello, okay. Any more questions? So it looks like you take care of the operational security of the journalist until the point where they receive the documents and it looks like it works very well. But do you have any plans to go further? Because with what happened recently with our famous journalist, we've seen that they are very, very bad at operational security. And maybe they need help further than just receiving the document. Yeah. So part of what we do, and I didn't talk about this, is when we install a secure drop for someone. So people can install it themselves. But if we install it for them, we will train journalists. And part of that is how to safely remove, for example, metadata from documents. But it's definitely the case that there is a lack of good tooling in this area generally. And there is a lack of awareness by some journalists about the problem. And I think that there's a lack of procedures in some news organizations. Oh, that's very bad. So yeah, that's something that Cubes can help us with in terms of the tooling. Like they have this converter trusted PDF thing. So that it opens a PDF and takes a picture of every page. That wouldn't be sufficient for all kinds of metadata like printer dots, for example. But it would help. So more of that kind of tooling is really important and is something that we care a lot about. Hey, you mentioned that the GPG encryption happens at the app server, not on the client. I can kind of understand that since, for example, you don't usually have JavaScript to do something in Tor browser. But you also mentioned that this app server is written in Flask. And in Python, typically you don't really have any control over the memory lifecycle of anything which goes into memory. So at some point you have to have this unencrypted data in memory. And in Python, it's very difficult to guarantee that you're purging it from memory. So what are you doing to make sure that the memory lifecycle is managed? Yeah, totally. That is entirely true. We do have unencrypted submissions in memory. So we reboot the server.