This project aims to improve journalists' experience working with SecureDrop while retaining the current security and privacy features SecureDrop provides. The journalist tools currently span multiple machines and require data to be moved using physical USB drives. We are re-designing this cumbersome process by moving the journalist workflow to a single computer running multiple virtual machines with Qubes OS. Data is moved as automatically and transparently as possible between otherwise isolated VMs.

IMPORTANT: This project is in alpha, has known bugs and shortcomings, and should not be used in production environments. This README is geared towards interested technical users and developers. When reviewing the state of the project, please take into account known bugs and security issues that will be addressed in future releases.

1. Detailed Rationale
2. Architecture
3. What's In This Repo?
4. Installation
   • Install Qubes
   • Download, Configure, Copy to dom0
   • Provision the VMs
5. Development
   • Testing
   • Automatic Updates
   • Building the Templates
   • Building workstation deb packages
   • Building workstation rpm packages
6. Using the SecureDrop Client
   • Signing in
   • Viewing messages and documents
   • Exporting documents
   • Manual export flow
   • Automated export flows
   • Transferring files via OnionShare
   • Printing
7. Distributing and Releasing
8. Threat model

SecureDrop's architecture and threat model are proven, but the current approach also has major drawbacks:

• Journalists must access a separate, airgapped device to even validate that a submission is relevant. The airgapped workflow is complex and slow, and may reduce the reliance on SecureDrop overall.

• The complexity of the setup and the usage procedures create operational security risks. For example, journalists may accidentally boot up the wrong device using the Secure Viewing Station (SVS) USB drive, breaking the airgap, or they may attempt "workarounds" to shortcut the laborious process of checking for submissions.

• Applying security updates to the SVS is difficult, which may cause administrators to wait a long time before doing so. While the SVS is airgapped, an insecure SVS still exposes additional vectors of attack, especially since the journalist is by design opening unknown files on the workstation.

• Once a document has been decrypted on the SVS, a journalist is more or less on their own right now. Work on the submission and the collaboration with other journalists are "not our department". Yet, security failures are likely during this stage. It's difficult to address this fundamental issue with the current workflow, since the SVS is essentially a dead end as far as SecureDrop is concerned.

The Qubes OS approach addresses this at multiple levels:

• By disabling Internet access and mitigating against other exfiltration risks on a per-VM basis, we can combine multiple functions into a single device. Checking SecureDrop submissions is as simple as booting up your workstation, downloading recent submissions, and inspecting them. This has the potential to greatly reduce time and effort spent by SecureDrop journalists, administators and trainers, and to increase day-to-day SecureDrop use.

• Qubes OS' security model lets us add specific software features (such as redaction of documents) with careful consideration in each case what level of system or network access an application requires. This lets us gradually extend the functionality we can offer to journalists beyond the mere download of submissions.

• We can potentially add VMs that enable end-to-end encrypted communication with other SecureDrop journalists, intermediated by the SecureDrop server. This enables us to add software features that, for example, let journalists collaborate in categorizing submissions, assigning work, versioning changes to documents, and so on.

However, the Qubes OS approach is not without downsides. It stands and falls with the security of Qubes OS itself, which in turn may be impacted by Spectre/Meltdown type CPU level vulnerabilities, hypervisor vulnerabilities, and so on. These risks must be compared against the operational security risks of the current architecture, including the work that journalists do after downloading a submission. The Qubes OS website provides a useful comparison of its security model with that of using a separate machine.

While we are strongly committed to piloting the use of Qubes OS for SecureDrop, no final decision has been made to move to this new architecture. This decision will require a full audit of this new approach, consideration of alternatives, and extensive validation with SecureDrop's current user community.

The current architecture replaces the Journalist Workstation and Secure Viewing Station Tails installations with specially-configured Qubes VMs; these are the VMs the user will primarily interact with. There are a number of other configured VMs which provide ancillary services.

Currently, the following VMs are provisioned:

• sd-proxy is where the SecureDrop proxy resides, which allows the non-networked sd-svs vm to communicate with the Journalist Interface over Tor.
• sd-svs is a non-networked VM in which the SecureDrop Client runs used to store and explore submissions after they're unarchived and decrypted. Any files opened in this VM are opened in a disposable VM.
• sd-whonix is the Tor gateway used to contact the journalist Tor hidden service. It's configured with the auth key for the hidden service. The default Qubes Whonix workstation uses the non-SecureDrop Whonix gateway, and thus won't be able to access the Journalist Interface.
• sd-gpg is a Qubes split-gpg AppVM, used to hold submission decryption keys and do the actual submission crypto.
• sd-dispvm is an AppVM used as the template for the disposable VMs used for processing and opening files.

Submissions are processed in the following steps:

1. Journalist uses the SecureDrop Client to access the Journalist Interface via the Journalist API. After logging in, the journalist clicks on any submission of interest.
2. The SecureDrop Client will use sd-gpg to decrypt the submission using Qubes' split-GPG functionality (decryption is done in a trusted, isolated VM, keeping GPG keys off of the system-wide DispVM).
3. The decrypted submission is stored on the sd-svs Secure Viewing Station VM, where it's placed in a local database.
4. Any file opened by the SecureDrop Client in the Secure Viewing Station VM is opened in a Disposable VM, largely mitigating attacks from malicious content.

See below for a closer examination of this process, and see docs/images for screenshots related to the steps above.

This project can be broken neatly into two parts: 1) a set of salt states and top files which configure the various VMs, and 2) scripts and system configuration files which set up the document handling process.

Qubes uses SaltStack internally for VM provisionining and configuration management (see https://www.qubes-os.org/doc/salt/), so it's natural for us to use it as well. The dom0 directory contains salt .top and .sls files used to provision the VMs noted above.

• Makefile is used with the make command on dom0 to build the Qubes/SecureDrop installation, and also contains some development and testing features.
• The SecureDrop Client is installed in sd-svs and will be used to access the SecureDrop server Journalist Interface via the SecureDrop proxy.
• The SecureDrop Proxy is installed in sd-proxy to communicate to the SecureDrop server Journalist Interface via sd-whonix.
• Within sd-svs, the SecureDrop Client will open all submissions in the sd-svs-disp disposable VM.
• config.json.example is an example config file for the provisioning process. Before use, you should copy it to config.json, and adjust to reflect your environment.
• sd-journalist.sec.example is an example GPG private key for use in decrypting submissions. It must match the public key set on a SecureDrop server used for testing. Before use, you should copy it to sd-journalist.sec, or store the submission key used with your SecureDrop server as sd-journalist.sec.

Installing this project is involved. It requires an up-to-date Qubes 4.0 installation running on a machine with at least 12GB of RAM. You'll need access to a SecureDrop staging server as well.

Before trying to use this project, install Qubes 4.0.1 on your development machine. Accept the default VM configuration during the install process.

After installing Qubes, you must update both dom0 and the base templates to include the latest versions of apt packages. Open a terminal in dom0 by clicking on the Qubes menu top-right of the screen and left-clicking on Terminal Emulator and run:

sudo qubes-dom0-update

Finally, update all existing TemplateVMs:

qubes-update-gui

Select all VMs marked as updates available, then click Next. Once all updates have been applied, you're ready to proceed.

Decide on a VM to use for development. We suggest creating a standalone VM called sd-dev. Clone this repo to your preferred location on that VM.

Next we need to do some SecureDrop-specific configuration:

• create a config.json based on config.json.example and include your values for the Journalist hidden service .onion hostname and PSK.
• create an sd-journalist.sec file in the root directory with the ASCII-armored GPG private key used to encrypt submissions in your test SecureDrop instance. The included key sd-journalist.sec is the one used by default in the SecureDrop staging instance.

Qubes provisioning is handled by Salt on dom0, so this project must be copied there from your development VM.

Understand that copying data to dom0 goes against the grain of the Qubes security philosophy, and should only done with trusted code and for very specific purposes, such as Qubes-related development tasks. Still, be aware of the risks, especially if you rely on your Qubes installation for other sensitive work.

That process is a little tricky, but here's one way to do it: assuming this code is checked out in your work VM at /home/user/projects/securedrop-workstation, run the following in dom0:

qvm-run --pass-io work 'tar -c -C /home/user/projects securedrop-workstation' | tar xvf -

After that initial manual step, the code in your development VM may be copied into place on dom0 by setting the SECUREDROP_DEV_VM and SECUREDROP_DEV_DIR environmental variables to reflect the VM and directory to which you've cloned this repo, and running make clone from the root of the project on dom0:

export SECUREDROP_DEV_VM=sd-dev    # set to your dev VM
export SECUREDROP_DEV_DIR=/home/user/projects/securedrop-workstation    # set to your working directory
make clone

If you plan to work on the SecureDrop Client code, also run:

qvm-tags sd-dev add sd-client

Doing so will permit the sd-dev AppVM to make RPC calls with the same privileges as the sd-svs AppVM.

NOTE: The destination directory on dom0 is not customizable; it must be securedrop-workstation in your home directory.

Once the configuration is done and this directory is copied to dom0, you must update existing Qubes templates and use make to handle all provisioning and configuration by your unprivileged user:

make all

The build process takes quite a while. You will be presented with a dialog asking how to connect to Tor: you should be able to select the default option and continue. You may wish to increase the scrollback in the dom0 terminal from 1000 (the default) to 100000, to ensure you can review any errors in the verbose output.

NOTE: Due to issue #202, the installation may fail with disk quota errors. If this happens, reboot the entire workstation and run make all again. The error will contain the following informating in your dom0 terminal:

qfile-agent : Fatal error: File copy: Disk quota exceeded; Last file: <...> (error type: Disk quota exceeded) '/usr/lib/qubes/qrexec-client-vm dom0 qubes.Receiveupdates /usr/lib/qubes/qfile-agent /var/lib/qubes/dom0-updates/packages/*.rpm' failed with exit code 1!

When the installation process completes, a number of new VMs will be available on your machine, all prefixed with sd-.

This project's development requires different workflows for working on provisioning components and working on submission-handling scripts.

For developing salt states and other provisioning components, work is done in a development VM and changes are made to individual state and top files there. In the dom0 copy of this project, make clone is used to copy over the updated files; make <vm-name> to rebuild an individual VM; and make all to rebuild the full installation. Current valid target VM names are sd-proxy, sd-gpg, sd-whonix, and disp-vm. Note that make clone requires two environment variables to be set: SECUREDROP_DEV_VM must be set to the name of the VM where you've been working on the code, the SECUREDROP_DEV_DIR should be set to the directory where the code is checked out on your development VM.

For developing submission processing scripts, work is done directly in the virtual machine running the component. To commit, copy the updated files to a development VM with qvm-copy-to-vmand move the copied files into place in the repo. (This process is a little awkward, and it would be nice to make it better.)

Tests should cover two broad domains. First, we should assert that all the expected VMs exist and are configured as we expect (with the correct NetVM, with the expected files in the correct place). Second, we should end-to-end test the document handling scripts, asserting that files present in the sd-proxy VM correctly make their way to the sd-svs AppVM, and are opened correctly in disposable VMs.

These tests assert that expected scripts and configuration files are in the correct places across the VMs. These tests can be found in the tests/ directory. They can be run from the project's root directory on dom0 with:

make test

Note that since tests confirm the states of provisioned VMs, they should be run after all the VMs have been built with make all.

Individual tests can be run with make <test-name>, where test-name is one of test-svs, test-journalist, test-whonix, or test-disp.

Be aware that running tests will power down running SecureDrop VMs, and may result in data loss. Only run tests in a development / testing environment.

The securedrop-update script will automatically update packages in all TemplateVMs, as well as dom0, as part of a daily cron job. This script will also run the salt provisioning logic to ensure the state is consistent. Because AppVMs must be rebooted after a TemplateVM upgrade, a message will inform users to reboot their workstations to apply changes.

To update workstation provisioning logic, one must use the work AppVM that was created during the install. From your checkout directory, run the following commands (replace <tag> with the tag of the release you are working with):

git fetch --tags
git tag -v <tag>
git checkout <tag>

In dom0:

make clone
make all

In the future, we plan on shipping a SecureDrop Workstation installer package as an RPM package in dom0 to automatically update the salt provisioning logic.

1. Create a fedora-29 AppVM for building the templates. It's going to need Docker and several other packages every time you use it, so it might be worth creating another template derived from fedora-29, into which you can install those extras, and basing the builder VM on that, or just using a StandaloneVM to save time and repetition.
2. Increase the disk size to at least 15GB (as the build uses over 10GB): qvm-volume extend sd-template-builder:private 15GB (if your VM is not named sd-template-builder, adjust that command)
3. Import the QubesOS master key and the GPG key used to sign tags (see https://www.qubes-os.org/security/verifying-signatures/)
4. Run make template in the top-level of this repository.
5. Copy the rpm generated in /home/user/src/securedrop-workstation/builder/qubes-builder/qubes-src/linux-template-builder/rpm/ to dom0
6. Install the template in dom0 : sudo rpm -i <file>.rpm (this takes a few minutes)
7. Create a new VM based on this template:

qvm-create --template securedrop-workstation test-securedrop-workstation --class AppVM --property virt_mode=hvm --property kernel='' --label green

# go to the builder/ directory:
cd builder/packages
# build a specific package (e.g, grsecurity metapackage)
make securedrop-workstation-grsec
# OR build all the packages
make all
# run the tests
pipenv install -d
pipenv shell
# install test requirements and run the test
apt install lintian
make test

make build-dom0-rpm

This uses a base docker image as defined in https://github.com/freedomofpress/containers/. If you need to bump versions of the rpmbuild tooling, make an update to that repo's metadata, and increment the version as defined in the Makefile. See the RPM_BUILD_VER variable.

Once your workstation environment is set up, you will be able to manage messages and submissions through a graphical user interface.

First, power on the workstation. When prompted, enter the Disk Password and press Enter to unlock the workstation. Then, when the login dialog box appears, enter the Login Password and click Log in.

To launch the SecureDrop Client, temporarily until this issue is resolved, you should from a dom0 terminal qvm-run sd-svs securedrop-client. This will start the SecureDrop Client in the sd-svs AppVM.

You should see a login prompt similar to the following:

In the background, you will see any previously downloaded messages. This is intended behavior: You do not have to sign into the server to browse the messages and files you have downloaded using the client. To work offline, press Esc to close the sign-in dialog.

If the sign-in fails, make sure to wait for another Two-Factor Code before trying again. To troubleshoot, verify that you can successfully sign in by visiting the .onion address of your Journalist Interface in the Tor browser in the sd-proxy AppVM.

After the sign-in or the next time you attempt to view encrypted content, you will be prompted by a dialog asking “Do you allow VM ‘sd-svs’ to access your GPG keys (now and for the following 28800 seconds)?”. Click Yes.

Once you are successfully signed in, you should see a screen similar to the following:

On the left-hand side, you will see a list of sources who have submitted messages or documents to your SecureDrop instance. Each source is represented by a two word designation like “controlled gate”. You can display the messages and documents associated with a source by clicking its entry in the list.

On the right-hand side, you will see the messages and documents associated with the currently selected source, in chronological order (newest at the bottom).

Replies, if any, from onboarded journalists to SecureDrop will appear in the conversation flow.

When the client starts, it will begin downloading messages and replies, and immediately decrypt them such that it can show the decrypted content in the conversation view. This will produce a request to access your GPG keys as described above, and is part of normal behavior.

Because of their potential size, documents are not downloaded immediately to the workstation. To download a document from the server, click its entry, which should say something like “Download (10MB)” for a 10MB file.

To open a downloaded file, click the “Open” icon. Note that we do not currently display the filenames of files that have been downloaded and decrypted, but this will be done in a future release.

Opening a file in this manner will launch a non-networked disposable Virtual Machine with the Debian GNU/Linux operating system. This process takes several seconds. You will see a Qubes OS notification telling you that the DispVM is starting. After a few seconds, another notification will be displayed telling you that the DispVM has started.

Do not repeatedly click the “Open” icon; instead, wait for the process to complete. Your workstation memory limits the number of disposable VMs you can launch; we recommend closing previously opened documents before opening new ones.

Files are opened in disposable VMs to ensure that any malware contained within files cannot access any other part of the workstation. The disposable VMs do not have Internet access, to prevent exfiltration of data through embedded resources or scripts. Changes you make within the disposable VM will be lost after you close the associated window(s).

Note: If an appropriate application is not available in the disposable VM, you will be alerted with the following dialog: “Unable to handle mimetype of the requested file (exit status: 768)!”. Click OK. The DispVM will shut down and be deleted. Please don't hesitate to file an issue for formats that you believe should be supported. For now, we recommend testing with TXT, PDF or MP4 files. Common word processor formats will be supported soon, once we have sufficiently hardened the installation of LibreOffice (issue 205).

While you are logged in, the workstation will check for new messages and documents every 5 minutes. You can also force a check by clicking the “Refresh” button.

Closing the client application will sign you out of the server. If you manually sign out using the “Sign out” button, you can browse previously downloaded messages and documents without Internet connectivity.

After you have completed your session, we strongly recommend shutting down the workstation (as opposed to sleeping the system) and storing it in a secure location.

Replies and Source Deletion will be added in the next major release of the SecureDrop Workstation.

WARNING: Opening files from an unknown origin presents certain risks (malware, fingerprinting). While the workstation helps reduce these risks by offering VM-level isolation, transferring documents to another host without the same level of isolation may expose you to these risks. Using tools to sanitize submitted documents, such as right-clicking a .pdf and selecting "Convert to trusted PDF" in Qubes OS, may help mitigate some of these risks. Further mitigating these risks will be a focus of future development.

Exporting documents directly from within the SecureDrop Client is not currently supported, but you can export documents manually via USB by following these steps:

1. Start the sd-export-usb VM. Again from the Qubes menu:
   1. Select "Domain: sd-export"
   2. Click "export: Files". This will launch the file manager in the export VM.
   3. Insert your USB drive into the workstation. A notification will pop up indicating the name of your USB device, e.g. "Innostor_PenDrive".
   4. In the upper right hand side of your screen, there is a small icon in the system tray with a USB drive. Click that icon.
   5. Select the name of your USB drive.
   6. Click the + icon next to the sd-export-usb VM.
2. You can use the command line in sd-svs to manually move selected files:

qvm-copy-to-vm sd-export-usb ~/.securedrop_client/data/name-of-file

4. You may now use the File manager that you opened in sd-export-usb to move files from ~/QubesIncoming/sd-svs to the USB drive. Delete the original file from ~/QubesIncoming/sd-svs once it has been moved. Note that the drive and files are not encrypted, so ensure that the key is properly erased and/or destroyed after use.

The development plan is to provide functionality in the SecureDrop Client that automates step 3, and assists the user in taking these steps via GUI prompts. Eventually we plan to provide other methods for export, such as OnionShare (this will require the attachment of a NetVM), using a dedicated export VM template with tools such as OnionShare and Veracrypt. The next section includes instructions to approximate the OnionShare sharing flow.

The sd-export-usb disposable VM handles exports to USB devices through qvm-open-in-vm. USB device IDs are configured in config.json. The automated export flows make use of the qvm-usb --persistent feature. This means that the persistent USB device must be available for sd-export-usb to start. In other words, a USB memory stick or a printer must be connected before the call to qvm-open-in-vm sd-export-usb <file> is made.

The SecureDrop Workstation can automatically export to a luks-encrypted USB device provided the correct format. The file extension of the tar archive must be .sd-export, containing the following structure:

.
├── metadata.json
└── export_data
    ├── file-to-export-1.txt
    ├── file-to-export-2.pdf
    ├── file-to-export-3.doc
    [...]

The folder export_data contains all the files that will be exported to the disk, and the file metadata.json contains the encryption passphrase and method for the USB Transfer Device (only LUKS is supported at the moment). The file should be formatted as follows:

{
  "device": "disk"
  "encryption-method": "luks"
  "encryption-key": "Your encryption passhrase goes here"
}

The SecureDrop Workstation can automatically print files to a USB-connected printer provided the correct format. The file extension of the tar archive must be .sd-export, containing the following structure:

Note that only Brother printers are supported now (tested with HL-L2320D)

.
├── metadata.json
└── export_data
    ├── file-to-export-1.txt
    ├── file-to-export-2.pdf
    ├── file-to-export-3.doc
    [...]

The folder export_data contains all the files that will be printed, and the file metadata.json contains an instruction indicating that the archive will be printed:

{
  "device": "printer"
}

Optionally you can use the printer-test device to send a printer test page and ensure the printer is functional

{
  "device": "printer-test"
}

You can find instructions to create a luks-encrypted transfer device in the SecureDrop docs.

A single USB port will be assigned to the exporting feature. Qubes will automatically attach any USB device to the Export VM. It should be labeled and only used for exporting purposes. You will be able to use different USB Transfer Devices, but they will always need to be plugged into the same port. Note that a USB stick must be connected during the entirety of the provisioning process. If you forget, you can run make sd-export after the install.

1. Connect the USB device to the port you would like to use. Then in dom0, run the following command:

qvm-usb

2. Take note of the device ID (e.g. sys-usb:3-4) used by your USB Transfer Device
3. Populate config.json with this value
4. Run the configuration of the sd-export feature.
5. If this is a new install, you can run, in dom0:

make all

2. If the workstation has already been properly configured and you wish to reconfigure the USB export functionality, run the following commands in dom0:

make remove-sd-export
make sd-export

1. Plug in the USB drive into the dedicated export port on your workstation.
2. In sd-svs, run the following command:

qvm-open-in-vm sd-export-usb <name-of-file>

If you are experiencing issues with the export flow, or would like to use a different port, you can re-run the configuration steps and apply the configuration to the VMs. In dom0, ensure your config.json contains the correct usb device identifier (see above) and rebuild the export machines (with the USB device attached):

make remove-sd-export
make sd-export

1. Create an sd-onionshare-template VM based on fedora-29:
   1. Click on the Qubes menu in the upper left, select "Template: Fedora 29", click on "fedora-29: Qube Settings", and click on Clone Qube
   2. Name the cloned qube sd-onionshare-template
   3. In the Qubes menu on the top-left, select "Template: sd-onionshare-template" and click on "sd-onionshare-template: Terminal"
   4. Install OnionShare: sudo dnf install onionshare
   5. Shut down the template: sudo poweroff
2. Create a new AppVM based on sd-onionshare-template
   1. Click on the Qubes menu in the upper left of the screen.
   2. Click Create Qubes VM
   3. Name the VM sd-onionshare
   4. Set the template as sd-onionshare-template
   5. Set networking to sys-firewall.
   6. Check the box "launch settings after creation"
   7. Click OK to create the VM.
   8. In the settings, under "Applications", add OnionShare from the "Available" to the "Selected" list.
   9. Click OK.
3. Start the sd-onionshare VM and open OnionShare
   1. In the Qubes menu on the top-left, select "Domain: sd-onionshare" and click on "OnionShare"
   2. Click the settings gear on the bottom right of the OnionShare window and de-select "Stop sharing after first download" (this due to a known bug in OnionShare)
4. You can use the command line in sd-svs to manually move selected files (this part will be replaced by functionality in the sd-svs client):

qvm-copy-to-vm sd-onionshare ~/.securedrop_client/data/name-of-file

5. You may now return to the OnionShare window, click on add and select the file you transferred from sd-svs by browsing to ~/QubesIncoming/sd-svs.
6. On the target machine, navigate to the Tor onion service URL provided by OnionShare using the Tor Browser to retrieve the file.
7. Close OnionShare and delete the decrypted submission on sd-onionshare from ~/QubesIncoming/sd-svs

Printing directly from the sd-svs AppVM or the disposable VMs will not be supported. The development plan is to instruct admins to install printer drivers in a template associated with a new printing VM. This template will not be shared with any other VMs.

SecureDrop Workstation code spans across the following repositories:

• https://github.com/freedomofpress/securedrop-client
• https://github.com/freedomofpress/securedrop-debian-packaging
• https://github.com/freedomofpress/securedrop-proxy
• https://github.com/freedomofpress/securedrop-sdk
• https://github.com/freedomofpress/securedrop-workstation
• https://github.com/freedomofpress/qubes-template-securedrop-workstation

1. For each release, a tag for each release will be signed and pushed to each of the above repos.

2. Create a Makefile target in securedrop-debian-packaging repo that contains release tags / commit hashes for each repository used for the release. To verify the tag signature and check out the packaging logic:

git tag -v <tag>
git checkout <tag>

3. Metadata (e.g. commit hash for release) should be tracked inside the .deb (e.g.: /usr/share/packagename/release-info.txt)

Apt repository Release file will be signed, containing checksum of the debs.

The entire RPM must be signed. This process also requires a Fedora machine/VM on which the GPG signing key (either in GPG keyring or in qubes-split-gpg) is setup. You will need to add the public key to RPM for verification (see below).

rpm -Kv indicates if digests and sigs are OK. Before signature it should not return signature, and rpm -qi <file>.rpm will indicate an empty Signature field. Set up your environment:

sudo dnf install rpm-build rpm-sign  # install required packages
echo "vault" | sudo tee /rw/config/gpg-split-domain  # edit 'vault' as required
cat << EOF > ~/.rpmmacros
%_signature gpg
%_gpg_name <gpg_key_id>
%__gpg /usr/bin/qubes-gpg-client-wrapper
%__gpg_sign_cmd %{__gpg} --no-verbose -u %{_gpg_name} --detach-sign %{__plaintext_filename} --output %{__signature_filename}
EOF

Now we'll sign the RPM:

rpm --resign <rpm>.rpm  # --addsign would allow us to apply multiple signatures to the RPM
rpm -qi<file.rpm>  # should now show that the file is signed
rpm -Kv  # should contain NOKEY errors in the lines containing Signature
# This is because the the (public) key of the RPM signing key is not present,
# and must be added to the RPM client config to verify the signature:
sudo rpm --import <publicKey>.asc
rpm -Kv  # Signature lines will now contain OK instead of NOKEY

You can then proceed with distributing the package, via the "test" or "prod" repo, as appropriate.

For the Debian packages, see https://github.com/freedomofpress/securedrop-debian-packaging/. For the RPM packages, such as the securedrop-workstation TemplateVM package, first build the package (e.g. make template), then sign the RPM, as outlined above.

To upload the package to S3, you'll need valid AWS credentials. Talk to a member of the ops team. Once you have valid credentials configured, install the dependencies (pipenv install), then run:

./scripts/publish-rpm

The RPM will immediately be available in dom0. Provided you've run the Salt configurations, find it via:

sudo qubes-dom0-update --action=search qubes-template-securedrop-workstation

You can then install it directly.

This section outlines the threat model for the SecureDrop Workstation, and should complement SecureDrop's threat model. This document is always a work in progress, if you have any questions or comments, please open an issue on GitHub or send an email to [email protected].

• The SecureDrop Application and Monitor servers are properly installed and configured.
• Operational security, administration and usage of the SecureDrop instance follows the guidance provided by the SecureDrop documentation.

• SecureDrop Workstation was installed correctly
• Updates are applied to SecureDrop Workstation provisioning code, VM templates and dom0 as they are available.

• The security assumptions of dm-crypt and LUKS are valid.
• The security assumptions of Tor, the Hidden Service protocol and Hidden Service authentication are valid.
• The security assumptions of RSA are valid.
• The security assumptions of the Qubes operating system are valid.
• The security assumptions of the Xen hypervisor are valid.

As the SecureDrop Workstation is not Internet-reachable, an attacker must first obtain code execution on a virtual machine. This can be achieved through a malicious SecureDrop submission, websites visited by a journalist or a vulnerability in the provisioning code and its dependencies. The Virtual Machine in which the adversary obtains code execution will dictate what information is potentially compromised, as well as the attack surface exposed for lateral movement or escalation of privilege.

The Display VM (sd-svs-disp) is disposable, does not have network access, and is used to display only one submission before being destroyed.

• An adversary can read the decrypted submission.
• An adversary can attempt to elevate their privileges and escape the VM.
• An adversary can attempt to communicate through a side channel to another VM or device in the SecureDrop Workstation's environment.

• An adversary can intercept and modify any and all communication between the Tor Browser and the SecureDrop Journalist Interface, including but not limited to:
  • Send messages to (but not view messages from) sources.
  • Delete messages and submissions.
  • Access encrypted messages and submissions.
  • Access plaintext journalist passwords to the Journalist Interface.
• An adversary can attempt to elevate their privileges and escape the VM.

• An adversary can obtain the Journalist Interface's ATHS cookie.
• An adversary can intercept and modify any and all communication between the Proxy VM and the SecureDrop Journalist Interface, including but not limited to:
  • Send messages to sources (but not view messages from a source).
  • Delete messages and submissions.
  • Access encrypted messages and submissions.
  • Access plaintext journalist passwords to the Journalist Interface.
• An adversary can attempt to elevate their privileges and escape the VM.

The SVS VM is where securedrop-client resides. It does not have network access, and the Qubes split-gpg mechanism permits access to GPG keys from this VM.

• An adversary can view all decrypted submissions.
• An adversary can decrypt arbitrary encrypted submissions.
• An adversary can interact with the SecureDrop Journalist Interface or modify SecureDrop client code.
• An adversary can attempt to elevate their privileges and escape the VM.

The GPG VM does not have network access, and the Qubes split-gpg mechanism restricts access to this VM per the Qubes GPG RPC policy.

• An adversary can decrypt and encrypted message or submission.
• An adversary can store and view any message that is being decrypted by the SecureDrop Workstation.
• An adversary can attempt to elevate their privileges and escape the VM.

dom0 can do all of the above: spawn arbitrary virtual machines, access all data, modify all SecureDrop Workstation provisioning code, as well as introduce mechanisms to establish persistence and exfiltrate data. By design, Qubes' dom0 does not have network access, files cannot be copied to dom0, and clipboard sharing is disabled.