...
 
Commits (40)
= Proposed Workflow for OpenPGP Clean Room Live Environment =
By [[JacobAdams|Jacob Adams]] (Tookmund) for GSoC 2018
<<TableOfContents()>>
== First Boot ==
=== Storage Devices ===
* At least one USB flash drive or SD card is required to export the public keys to an internet-connected computer
* Three USB flash drives or SD cards required if the key is to be generated on disk:
1. Offline backup disk RAID1
2. Offline backup disk RAID1
3. Public key export disk (and possibly private subkeys)
==== Why two backups with RAID1? ====
Flash drives and SD cards, as with all computer storage, can fail randomly. You don't want your master key to be stored in your
regular backups, but you don't want a single point of failure either. Two flash drives with identical contents seems like the
best option to ensure the safety of one's master key. There are other disk mirroring options, like btrfs or zfs, but they are
generally used and designed for larger disks. RAID1 seems like the simplest and best option for mirroring two small storage devices.
==== USB Port Exhaustion ====
Many modern laptops have two or even fewer USB ports. To manage a RAID1 device we'll probably need at least two free ports which could be extremely problematic if the device is actually booted from a USB. We'll need to ensure the boot device can be removed while in operation (everything on the ramdisk) and that the user has a minimum of two usb ports.
=== Setup Storage ===
* Ask the user where they want to generate their key
==== On Disk ====
* Detect that at least 3 USB flash drives/SD cards are connected.
* If not, explain to the user why we need them and wait for them to be connected
* Have the user pick two as offline backup and one as public key storage
* Setup usb disks after confirming one last time with user
==== On A PGP Smartcard ====
* Ask the user to connect their smartcard
* Check that we can actually generate a PGP key on it
* Switch to the smartcard backend
* Ask user for new admin pin
* Ask user for new user pin
* Enable touch to sign/encrypt/authenticate or whatever that key's equivalent settings are
=== Initial Key Generation ===
* Ask user for email, full name, and password
==== On Disk ====
* Generate RSA 4096 signing master key in a temporary directory
* Generate RSA 2048 signing, encryption, and authentication keys
* Move them to offline backup
==== On A Security Key ====
* (This will probably be different depending on which smartcard the user has)
* Generate encryption, signing, and authentication keys on the smartcard
* Move public keys to public key storage
=== Manage Subkeys ===
* Ask user if they have a smartcard to set up.
* Ask if multiple and if so export private keys from backups to temp home to repeat process.
==== Smartcard ====
* Optionally export on disk subkeys to a smartcard
==== Or Export Private Subkeys ====
* Export private subkeys to public key export disk
* Explain to user the importance of keeping this safe now
=== Finish up ===
* Wipe temporary GNUPGHOME
* Add script to public key export disk to import new keys, send them to keyservers, and delete any private key material once imported
* Ensure offline backups and public key export disk are safely ejected
* Tell the user to store the offline backup disks in a safe place, preferably two different safe places.
* Tell them to use the public key export disk to add their new key using the script we installed earlier.
* Shutdown
== Key Management ==
If we detect an existing setup, go into key management mode
=== Keysigning ===
* Check public key export disk for new public keys that haven't already been signed by our master key
* Ask the user if they want to sign all of them or one-by-one
* If one-by-one, ask trust level, otherwise assume "rather not say"
=== Key Revocation ===
* Ask which key has been compromised
* Export revocation certificate to public key export disk
== Misc ==
=== Testing, testing, testing! ===
Once skeleton workflow is in place, this should be tested on non-technical users. How can explainations be improved, what makes sense and what doesn't, etc. GPG will always have some level of complexity but it should be minimized as much as safely possible.
A call for testing via planet debian might be a good idea once the project is close to completion.
=== Networking Concerns ===
Networking should be disabled as much as possible but preferably using Debian packages. If we use custom packages, its probably more likely that they would become out of date over time and thus more vulnerable than the original packages, especially with significant modifications.
* Remove isc-dhcp-client and ifupdown ([[https://salsa.debian.org/tookmund-guest/make-pgp-clean-room/commit/3f4d399c8f36318830790eac6d50f62c9b79658e|done]])
* Remove networking kernel modules ([[https://salsa.debian.org/tookmund-guest/make-pgp-clean-room/commit/6aeaa1798098da61dce3b18ca449f8cc3c995f25|done]])
=== Device Detection ===
We'll need some way to distinguish between USB drives and SD cards as opposed to HDDs and SSDs. We don't want to present the user with devices they shouldn't be using for this.
=== Translation ===
[[https://docs.python.org/3/library/gettext.html|gettext]] should allow easy translation.
This diff is collapsed.