[docs] Overhaul Transfer Device and export recommendations

[eloquence]

Status

Ready for review

Description of Changes

• More clearly prioritizes printing as the recommended method to get documents off the SVS whenever feasible;

• Introduces a recommended workflow using a VeraCrypt-encrypted Export Device intended to be clear and consistent, while still closely resembling current practices;

• Removes instructions to set up per-journalist GPG keys;

• Updates diagrams consistent with the above.

Resolves #4620
Resolves #4646
Resolves #4434
Resolves #4670
Resolves #3598

Review plan

Review the documentation against the issues below. Does it now provide instructions to administrators that are clear, sensible, and consistent? Please note the significant updates to the diagrams in the documentation.

The biggest change for end users is the recommendation to provision a USB drive encrypted with VeraCrypt as the Export Device. I have done this and used it both in Tails and on my regular Linux workstation. I would recommend that the reviewer similarly provision a VeraCrypt drive and attempt to access it in a recent version of Tails and on their everyday workstation (bonus points for testing on Mac or Windows).

I have tested that VeraCrypt successfully mounts read-only drives, both using the application, and using the graphical integration in Tails. On the command line, cryptsetup must be invoked with the --readonly option for this to work.

[eloquence]

Still a lot to do here, but I wanted to get the current WIP up for any early feedback. Most of this should be consistent with our recent discussions. Couple of areas where I think it could be useful for FPF to do a bit more hardware testing, if we haven't already done so:

• USB write blockers like this one seem like a relatively cost effective way to prevent infecting drives that may be taken back to the SVS.

• VeraCrypt is still pretty cumbersome and slow, and a hardware encrypted drive honestly seems more user-friendly and practical for SecureDrop uses. If we can recommend such an option, it would seem to potentially bypass a lot of usability and cross-platform issues. There are hardware-encrypted NitroKeys, which are advertised as fully open source & open hardware w/ third party audits. If these hold up under scrutiny, it would be nice to be able to officially recommend them.

[eloquence]

As a side note, the recommendation in this PR (to use separate USB drives for Export and Transfer Device) is in fact exactly identical to the architecture in this diagram where these are called "USB Key A" and "USB Key B". The only problem is that "USB Key A" and "USB Key B" are only referred to in this diagram and nowhere else in the docs.

[conorsch]

Great clarifications throughout, @eloquence. Left a few comments for further improvements to readability, but overall these changes are already quite strong.

[eloquence]

9a5349a is potentially the single most contentious part of this PR. It removes all references to setting up individual GPG keys for journalists, and instead provides instructions for using VeraCrypt.

As a reminder, VeraCrypt replaces LUKS as the previous recommendation -- a recommendation which was impossible to follow in practice. The documentation effectively instructed journalists to double-encrypt files, with LUKS and with their personal keys, and to do so in a manner that is impossible to decrypt on their everyday workstation (due to LUKS not being cross-platform). That said, whether to copy to Tails or to their everyday workstation -- even that part was not clearly spelled out.

Our docs provided minimal instructions for working with GPG keys (instead linking out to the EFF guides), and suggested that the private key be stored on the Journalist Workstation -- which is defined in the glossary as the Tails-based workstation used to access the journalist interface. That makes little sense in the real world, where journalists will need to leave Tails behind pretty quickly.

An easier option than introducing VeraCrypt would be to make the previous GPG instructions a bit more sensible, and to ask journalists to use an ordinary, unencrypted USB drive to copy files off the SVS, encrypting them first to their public key. This may well be current practice in at least some organizations.

The downsides of that approach are significant, IMO:

• Relying on GPG as the standard way to encrypt data signs organizations not already committed to GPG up for a lot of complexity, compared with using an encrypted drive.

• Encrypting individual submissions while keeping the drive unencrypted keeps metadata (time/date of export, file size, etc.) in unencrypted form. There's a high risk of accidentally decrypting submissions directly on the Export Device, or accidentally copying data in unencrypted form.

• An adversary gaining access to an unencrypted Export Device may be able to successfully recover "deleted" files without any additional credentials.

For these reasons, I don't think it's even a good idea to suggest a GPG workflow as an alternative to the VeraCrypt approach in the docs.

If all of this leaves you with a bad feeling, I share the same concern. I'm not a fan of any of these solutions. VeraCrypt is non-free software (due to legacy TrueCrypt bits), difficult to use (a lot of complexity in the UI that should be hidden behind progressive disclosure patterns and sensible defaults), and a bit flaky: I've had it randomly freeze on me twice during testing.

In terms of cross-platform usability, I've not tested them personally, but it seems hard to beat an integrated hardware-encrypted solution like the Kingston DT-2000 with on-device PIN entry. And of course there are more open solutions like the NitroKey encrypted drives that may be worth considering.

But if we have to choose between the devil and the deep blue sea, I think just recommending VeraCrypt and purging GPG from the docs is our best long term bet, and consistent with our current plan of record to use VeraCrypt on the SecureDrop Workstation. Really, much of this complexity is inherent in working with an air-gapped system, and the Workstation will greatly reduce the end user complexity here.

Finally, I'll mention Jen's suggestion to get files off the SVS by way of Tails+OnionShare. Tails does have pretty nice built-in OnionShare integration, and this would allow us to use LUKS for both the Transfer Device and the Export Device. It does introduce a new layer of complexity -- downloading files from Tor on the journalist's everyday workstation, and keeping the OnionShare on Tails running while that's happening, plus the usual concerns about Tor speed and reliability. This makes me think that OnionShare is always a good candidate as a secondary option (both here and on Qubes), but not so much as the primary recommendation.

[eloquence]

OK, I'm going to call this ready for review! I've tried to be as thorough as possible in updating all existing references in the docs to the workflow that's being described here, but it's possible that I have missed some. I will take a couple more passes myself.

Because this PR impacts our training practices, it should not be considered ready for merge unless and until @harlo gives her +1.

[emkll]

Thanks @eloquence for the changes, I've made a first pass review and left a few comments inline. Regarding the write protection, If we are to recommend it on the export device, it might also be worth recommending it on the transfer device for completeness, preventing files to be written by the svs to the transfer device

[harlo]

I'm comfortable with this, @eloquence; thanks for strongly enumerating the caveats up-front. 👍

[huertanix]

I read through the VeraCrypt updates and I think they look great; Only two minor things that might be 🆒 to add in the future.

• Adding something along the lines of "read out guide to learn about how password managers work and how to pick one" linking out to our guide when mentioning using a personal/phone password manager to keep the Export key passphrase in.
• Mentioning, either in the instruction bullet point asking the user to open VeraCrypt on their everyday workstation or wherever it makes more sense, that they need to first install VeraCrypt on their everyday workstation. This also might be a place to link to the VeraCrypt downloads page and our guide on verifying open source software.

[eloquence]

Thanks @huertanix, @harlo and @olivemartini (who sent comments privately), much appreciated :)

Adding something along the lines of "read out guide to learn about how password managers work and how to pick one" linking out to our guide when mentioning using a personal/phone password manager to keep the Export key passphrase in.

This is currently linked to, here:

https://github.com/freedomofpress/securedrop/blame/docs-transfer-to-export/docs/set_up_transfer_and_export_device.rst#L89-L93

I tried to address this in a single place ("Decide how to manage passphrases") since it comes up a few times.

I agree re: the VeraCrypt requirement, will clarify.

[eloquence]

@huertanix VeraCrypt docs clarified in 920ac10; feedback appreciated if you have time :)

[emkll]

Thanks for the changes and for your patience @eloquence . I've taken another pass through your changes, and the content looks great, I have no further comments to provide, and think this is good to merge.
However, I've included two comments regarding the commit history. From the GitHub review menu, it seems like we will be losing the git history for two files, due to a file name change. Are those file name changes strictly required? If so, would it be possible to use git mvinstead?

[eloquence]

I squashed this PR into a single commit, and split the rename operations into a follow-up commit. GitHub's combined "Files" view still shows the operations as deletions, but if you git log --follow on the renamed files, you should now get the full history.

[emkll]

Changes identical to the ones reviewed previously in 54301d8 (https://github.com/freedomofpress/securedrop/compare/54301d89a200a5c98e814cec905f1e6e1407dc33..14bdc72f946387ac79c155e6816d5590a280f949)

Confirming that git log --follow now works for those files, 🎉 thanks @eloquence

[zenmonkeykstop]

The technical procedures for use of a Veracrypt-encrypted Export USB look good. I'm concerned about the practicality of some of the recommendations around hardware choices and solutions to prevent malware being copied to the SVS, but there's nothing there that should block approval. The updates to the threat model document are incomplete, however.

[zenmonkeykstop]

It might be worth being explicit here and saying that you need to create the Veracrypt volumes off Tails. It's possible that someone would read this as saying you should install additional software on Tails to create Veracrypt volumes. We don't want to encourage this IMO. Users shouldn't be customizing their Tails distros without good reason.

[eloquence]

Added a note to the effect that it should not be installed on the SecureDrop drives in 60cc802. (IMO another Tails drive may be a fine choice.)

[zenmonkeykstop]

Threat model doc refers to SD 0.3 - unclear if it should be changed piecemeal, or edited in its entirety to include references to other assets. This change adds an Export USB and recommends the use of a password manager on the journalist's mobile device, neither of which are covered here.

[eloquence]

Per discussion earlier today, I've made minimal updates to the threat model consistent with the new terminology and updated data flow in 60cc802.

[emkll]

Changes in the threat model document look good to me. Not a blocker for merge, but I think it might be useful to track the differences with the implications of compromise of the transfer device (which should have only gpg-encrypted submissions, on a luks-encrypted device) vs export device (veracrypt encrypted device, without necessarily having per-file encryption).

[eloquence]

@emkll I've tried to clarify the potential use of write protection for the Transfer Device as a defense-in-depth strategy in 86db461 (amended existing commit, which seems more readable in this case).

Regarding the threat model, note that it speaks already to the point you're mentioning, as it notes that an attacker will have access to SecureDrop submissions if the Export Device is in use:

View, modify, and delete decrypted submissions, if they are stored in decrypted form on the Secure Viewing Station, or if the Export Device is in use.

If the journalist follows the recommended procedure, this will not be the case even if the Transfer Device is in use.

I think the Export Device / Transfer Device risks could be more clearly separated from the workstation-related risks, but I also think the way this information is organized right now could be improved, so I would recommend leaving that to a follow-up PR.

[emkll]

thanks for the changes @eloquence , looks good to me. I won't immediately merge however to ensure @zenmonkeykstop is satisfied with the changes that were requested.

[zenmonkeykstop]

LGTM, thanks for updates.