automating the credential import process for existing securedrop users

[redshiftzero]

For existing SecureDrop users, we need to import the submission private key from the SVS drive and the Journalist Interface URL and associated (HidServAuth/ClientOnionAuthDir) secret from the existing Journalist Workstation.

During this import process we want to ensure that we:

1. Never attach these drives (of most importance for the SVS drive) to network connected VMs.
2. Automate steps that administrators/journalists are at risk of making a mistake during, like attaching a drive to the wrong VM.

Prior to the import procedure we instruct users to:

1. Boot to their SVS drive and export an armored version of their private key to ~/Persistent/sd-journalist.sec (at some later point we could also automate this step by exporting ourselves when we attach the drive in step 4 below).
2. Boot to their Journalist Workstation and verify their app-journalist.auth_private or app-journalist-aths credentials are correct.

We could implement a securedrop-admin command, let's call securedrop-admin --import that:

1. User prompt: Please attach your existing SVS drive and detach any other USB drives.
2. We ask the user for their SVS passphrase (we won't store this).
3. Identically to what we do in securedrop-export (ref: https://github.com/freedomofpress/securedrop-export/blob/be86e421747d379d81d7354e90083b9ecad32a71/securedrop_export/disk/actions.py#L44), we identify block devices in sys-usb, mount them, and attempt to decrypt them using the provided passphrase. We fail if we can't find a drive (we can reuse the securedrop-export error codes here).
4. We attempt to copy the file ~/Persistent/sd-journalist.sec into place in dom0. We fail if it's not in the correct location. We unmount the drive.
5. User prompt: Please attach your existing Journalist Workstation drive and detach any other USB drives.
6. We ask the user for their JI passphrase (we won't store this).
7. Since app-journalist.auth_private and app-journalist-aths are stored in a common location, we copy app-journalist.auth_private if it exists and otherwise app-journalist-aths into dom0. We fail if neither exist. We unmount the drive.
8. We generate config.json based on the above credentials (generating the fingerprint from the private key, and asking the user to confirm). We put config.json and sd-journalist.sec into place for securedrop-admin --apply to use.
9. We instruct the user to remove all drives and proceed with the install.

[zenmonkeykstop]

Keeping this one, this could either be implemented directly as described or with a wee GUI.

[deeplow]

I wasn't aware of the existence of this issue and accidentally created a duplicate. Copying an pasting here my comment

---

The current way to import the Tails SVS' credentials is a bit manual:

• attaching USB
• decrypting USB
• coping the key to dom0
• copy the journalist interface details to dom0
• in dom0 create a config.json with these values

What I am proposing here is a SDW initialization wizard which would be triggered on (first) boot (or when the credentials are not present).

1. Welcome the admin to the SecureDrop Workstation
2. Ask the user to insert the SVS USB (Tails)
3. Ask the user for the decryption key
4. Do the rest in the background
5. Test connection and inform the user in case anything goes wrong

Open Questions

• including in this flow newsrooms who are installing SecureDrop for the first time and starting only on Workstation (no Tails SVS)
• if this shows on the first boot, then we may want to make sure that the Whonix connection wizard does not get in the way. Controlling the ISO and disabling whonix autostart would be away to do this.
• The user should be connected to the internet for the autotesting to work. Should the wizard include some form guidance on connecting to the internet? Or should we leave that to the docs?

[rocodes]

[comments copied over from other issue]

I agree with all of this; once our provisioning is set up we should definitely have an easier install flow that asks for less information and automates a significant portion of the installation.

I think there are a lot of parts and decisions here that might need to be considered separately (I have put my initial impressions in parentheses but open to discussion):

• Can we automate a lot more of the install? (Yes)
• Can we do a better job of "validating" the credentials the user provided before install, including network connectivity testing and/or maybe onion service credential testing? (Yes, probably yes, and re the former, there is an existing network check before our updater runs)
• Can we avoid having the user elaborately construct a config.json or construct any config that requires them to use a text editor? (yes)
  • Can we auto-grab the Submission Private Key (and fingerprint) once the SVS is unlocked (yes)
  • Can we auto-grab the workstation credentials from an admin workstation once the drive is unlocked (yes)
• Should we take control of asking the user for their drive passphrase(s)? (No/maybe but I'm not a fan; this is my least favourite part of the export workflow, and I'd say this should be deferred or descoped)
• Should the same VM handle the SVS and the Admin workstation (No; SVS vm should only be attached to vault, admin VM should be attached to a different VM I think)
• Should the wizard, or a wizard, reappear if valid credentials aren't found? (Yes: relevant Pre-flight check: smoke test on VM / RPC configuration before starting #939, leads to below)
• How should the system validate itself at startup and/or watch for or handle config changes (TBD but ongoing/upcoming work is relevant, as are [4.2] Write vm-specific config values to qubesdb #936, Investigate auditd as a tool for monitoring/validating system state #951)

re non-Tails SDW setups: It's a good question to keep in mind so we don't box ourselves in with any design choices, but I see it as farther off than a number of our other milestones (blocked on at least #932 , freedomofpress/securedrop-client#2158 but more broadly freedomofpress/securedrop-client#1725, also freedomofpress/securedrop-client#1104, and probably some others of that ilk

(Related issue: #942)

[zenmonkeykstop]

This issue and its dupes are a good example of convergent evolution at work!