Off-board Administrators and Journalists
When journalists and SecureDrop administrators leave your organization, it is important to off-board them from SecureDrop.
What you need:
An Admin Workstation. Contact SecureDrop Support or follow our guide to rebuilding an Admin Workstation if you do not have one.
An admin account on the Journalist Interface
Additional measures may need to be taken if the user’s departure is on unfriendly terms. These measures will vary depending on the circumstances and your own internal incident response procedures, and may include doing a full reinstall of SecureDrop. If you are in such a situation, feel free to contact us for further assistance.
Inform the SecureDrop Support team that the user’s support portal account should be deactivated, and indicate if any new staff members should be added.
Delete the user’s account on the Journalist Interface.
Retrieve Admin Workstation or Journalist Workstation USB drive(s), Transfer, Export, and Backup drive(s), and any other SecureDrop hardware or materials.
If the user receives email alerts (OSSEC alerts or daily submission notifications), either directly or as a member of an email alias, remove them from those alerts and set up someone new to receive those alerts.
(Circumstance-dependent) If you have specific concerns that the Submission Key has been compromised, you should consider a full reinstall of SecureDrop. At minimum, you should rotate the Submission Key.
Additional steps for off-boarding administrators
If the departing user was your primary SecureDrop admin, designate the next person who will take over their function. Ideally, your outgoing administrator will be able to provide as much training as possible on the use and maintenance of the system, as well as on your organizational policies (such as backup strategies, and so on) before they leave; if this is not the case, contact the SecureDrop Support team.
We do not recommend enabling remote management for SecureDrop’s network firewall. However, if your SecureDrop firewall can be accessed remotely, even if only from within your organization’s network, you may want to rotate its login credentials.
Back up and rotate the Admin Workstation SSH key to prevent unauthorized SSH access to the Application and Monitor Servers in the event that this user has retained their Admin SSH credentials.
Rotate SSH keys on the SecureDrop Servers
If you are concerned that the user may have a copy of the Admin Workstation USB or that they may have kept a copy of the Admin Workstation SSH key, you should rotate the key in the following manner.
Create a new SSH keypair. From an Admin Workstation, run
ssh-keygen -t rsa -b 4096
and make sure to change the key name. This is the only parameter you need to change. For example, instead of
/home/amnesia/.ssh/id_rsa, call the key
/home/amnesia/.ssh/newkey. You don’t need a passphrase for the key.
Copy new public key to the SecureDrop Servers. Copy the public portion of the key to the Application and Monitor Servers by running
scp /home/amnesia/.ssh/newkey.pub scp://app
scp /home/amnesia/.ssh/newkey.pub scp://mon
Add this key to the list of authorized keys. SSH to the Application Server and append this new key to the list of authorized keys by using
cat newkey.pub >> ~/.ssh/authorized_keys
Be sure to use the command as above so that you append the key, instead of replacing the file. While you are still on the Application Server, you can then delete the file
newkey.pubfrom wherever you scp’d it to (i.e. your home directory). Repeat this process with the Monitor Server.
Rename SSH keys. Exit all SSH sessions and, on your Admin Workstation, rename
id_rsa.pub(the old SSH keys) to something else. For example,
mv /home/amnesia/.ssh/id_rsa /home/amnesia/.ssh/id_rsa_old mv /home/amnesia/.ssh/id_rsa.pub /home/amnesia/.ssh/id_rsa_old.pub
Then, rename your
Test SSH connection. Test that you can still ssh into the Application and Monitor Servers (you can test with
ssh app hostand
ssh mon host).
Restrict SSH access to the new key.
If you have other users who also have SSH access to the Application and Monitor Servers, the next step will revoke their access. Their public keys will have to be re-appended to the
authorized_keysfile on each server, as in step 3.
From an Admin Workstation, run~/Persistent/securedrop/securedrop-admin reset_admin_access
This removes all other SSH keys, except for the new key that you are currently using, from the list of authorized keys on the Application and Monitor Servers.
Rotate the Submission Key
The Submission Private Key is held on the airgapped Secure Viewing Station, and is not normally accessed by SecureDrop users anywhere but on the SVS. Therefore, we recommend rotating the Submission Key under the following circumstances:
If the user’s departure was not amicable
If the user is still holding on to any Secure Viewing Station USB drive or backup
If you have any other reason to believe the Submission Private Key or the entire Secure Viewing Station USB may have been copied or compromised.
You should still keep the old key on the Secure Viewing Station, or else you will not be able to decrypt submissions that were sent to you while that key was in effect.
You will need:
The Admin Workstation
The Secure Viewing Station
A Transfer Device (LUKS-encrypted USB drive)
On the Secure Viewing Station
From the Secure Viewing Station Applications Menu, choose Accessories ▸ Kleopatra, and select the Submission Key from the list of available keys.
From the details view that appears, click the Add email address button.
In the dialog window that appears, choose Advanced.
Set the name field to “OLD SecureDrop Submission Key - Do Not Delete”, and set the comment field to “Retired <Date of Retirement>”. Click OK to add this information to the key.
This is a local-only change to stop you from mixing up the old and new keys
Return to the Terminal, then run:
In the output, locate the Retired SecureDrop Submission Key. It should look similar to this:
pub rsa4096/0x1CB396626CA370AB 2022-08-16 [SC] Key fingerprint = 6A7F 116B 3C22 4F36 7275 236A 1CB3 9662 6CA3 70AB uid [ultimate] OLD SecureDrop Submission Key (Retired 2022-08-16) uid [ultimate] SecureDrop (SecureDrop Submission Key) sub rsa4096/0x228C92459E3D16DE 2022-08-16 [E]
Make note of the ID of the key, which is the portion of the key after the slash in the first line. In this example, the key ID would be:
Generate a revocation certificate, by running the command below (replacing
<KEY_ID>with the ID you noted in the step above):
gpg --output revoke.asc --gen-revoke <KEY_ID>
This will launch an interactive prompt, where you can supply the following values:
Create a revocation certificate for this key? (y/N) y Please select the reason for the revocation: 0 = No reason specified 1 = Key has been compromised 2 = Key is superseded 3 = Key is no longer used Q = Cancel (Probably you want to select 1 here) Your decision? 2 Enter an optional description; end it with an empty line: > <Just Press Enter> Reason for revocation: Key is superseded (No description given) Is this okay? (y/N) y ASCII armored output forced. Revocation certificate created.
Import the revocation certificate:
gpg --import revoke.asc
Return to Kleopatra, and make sure the key is now marked as Revoked.
Now follow the instructions to create a PGP key on the Secure Viewing Station. This will be your new Submission Key. Copy the fingerprint and new Submission Public Key to your Transfer Device.
On the Admin Workstation
Ensure that your Admin Workstation is up-to-date before performing these steps.
Take the Transfer Device with the new Submission Public Key and fingerprint to your Admin Workstation. As you did during the initial install, copy the public key,
SecureDrop.asc, to the
install_files/ansible-base/directory, replacing the existing public key file that is there.
If the new public key that you placed in
install_files/ansible-basehas the same name as the old public key,
SecureDrop.asc, the only part of the configuration you will change is the SecureDrop Submission Key fingerprint, which you will update with the fingerprint of your new key.
Once you have completed the above, run
to push the changes to the server.
You may want to immediately create a test submission, then use a Journalist account to log into the Journalist Interface, download your submission, and take it to the Secure Viewing Station.
Return to the Secure Viewing Station
On the Secure Viewing Station, decrypt the test submission you made to ensure that your new key is working properly.
Do not delete your old submission key! You’ll want to maintain it on the SVS so that you can still decrypt old submissions that were made before you changed keys.
If you have any other Admin Workstations, make sure that you have copied the new Submission Public Key into the
install_files/ansible-basedirectory, replacing the old public key file, and updated the Submission Public Key fingerprint by running
and updating the fingerprint when prompted. You do not have to run
./securedrop-admin installagain, since you have already pushed the changes to the server.
If you have any questions about the steps in this guide, we’re here to help:
Community support is available at https://forum.securedrop.org
If you are already a member of our support portal, please don’t hesitate to open a ticket there. If you would like to request access, please contact us at email@example.com (GPG encrypted). Note that your ticket will be visible to all support portal users at your organization; if this is a concern, reach out by email to the above address or to a staff member directly.
The Freedom of the Press Foundation offers training and priority support services. See https://securedrop.org/priority-support/ for more information.