Support distinct v3 client auth keys for JI access

[zenmonkeykstop]

Description

V2 authenticated hidden services (AHSs) originally used a simple access token mechanism - in SecureDrop, the access token was shared by all users of the Journalist Interface. When SecureDrop migrated to v3 services, which use a keypair mechanism for AHS authentication, a single keypair was generated instead, with users adding the private key to their Tails workstation's Tor config.

There's nothing to prevent adding multiple client keys for use with SecureDrop Workstation. For example:

per-client keys

A keypair could be generated on SDW setup, and the public key added server-side via some kind of registration mechanism. This would give admins visibility into SDW clients and allow for selective offboarding in case of the SDW hardware being lost or stolen, or, if it was being used by a single journalist, if that journalist was also being offboarded.

per-journalist keys

A keypair could be generated and registered on journalist account creation, and used to set up the Journalist Workstation in classic mode, or added to the Tor config on login on SDW. This case is more problematic as the journalist would need to provide the key at login (storing it on the SDW doesn't give much benefit over the status quo) but it might be possible to store it on a Yubikey or similar hardware token.

How will this impact SecureDrop users?

Increases security overall by making it more difficult to use stolen credentials, makes onboarding/offboarding journalists and/or SDW client instances easier for admins (as they would not need to roll and distribute a new global key).

How would this affect SecureDrop's threat model?

Mitigates compromise of an SDW workstation by reducing common secrets in the config. (Though this is likely offset by the need to reissue a submission key in most compromise scenarios.)

[cfm]

The zoom-out question here is: How are different parts of the SecureDrop end-to-end flow scoped to be single- versus multi-user?

Credential	(a) Current SecureDrop	(b) Next-gen SecureDrop	(c) This proposal
(1) Submission key (or equivalent)	single	multi	single
(2) Journalist access to SecureDrop	multi	multi	multi
(3) Journalist access to SecureDrop Workstation	single1	single1	single1
(4) Journalist access to onion service	single	n/a2	multi

I think taking (4)(b) seriously makes me doubt that this credential-scope aligning is worth pursuing for current SecureDrop.

Footnotes

1. Because Qubes is effectively single-user. ↩ ↩² ↩³

2. Anonymous/indistinguishable. ↩