CleanRoom

From Guardian Project Wiki

NOTE: In this document "sign" refers to signing a message for integrity purposes, while "certifying" refers to signing another key.

Contents 1 Clean Room 1.1 Summary 1.2 User Workflow 1.3 Tasks 1.3.1 New Setup 1.3.2 Migrate Existing Key 1.3.3 Certifying Keys 1.3.4 OS Setup 1.4 TODO 2 Appendix 2.1 What is this Offline Master Key Thing? 2.1.1 The Problem 2.1.2 A Solution 2.2 Resources

Clean Room

A linux livecd + application combo that provides a secure, usable environment for managing GPG keys.

Summary

Using an offline master key with active subkeys is considered to be the most secure way to use GPG, however the workflow for setting up and maintaining such a gpg key is incredibly laborious. You need look no further for proof of this than the gigantic 18-step procedure provided by the FSFE.

The vast majority of the steps are simply navigating the complicated GnuPG command line interface with very little actual input or decision making necessary on the user's part.

The Clean Room project aims to provide a bootable environment that provides a clean and simple interface for GPG tasks. Balancing user friendliness and security in an attempt to drastically simplify the GPG management process is it's core goal.

Project Sites

• UI Mockups
• [Manual Setup]

User Workflow

TODO: user stories describing workflow and experience

Tasks

The following activities will be supported:

New Setup

For brand new users or users who want to start fresh.

• Generate new master key with only the certification option (default 4096 bits)
  • Add identity information (UIDs)
  • Generate signing and encryption subkeys (default 3072 bits)
    • (optional) Move subkeys to smartcard
  • Save subkeys and master public key to external storage
  • Persist master private key to the system

Migrate Existing Key

Should we support migrating from an existing key? It seems against the entire point of a "clean room".

Certifying Keys

• Auto-detection of an existing master-key setup
• Accept user input of key fingerprints
  • (support qr-code scanning if webcam exists?)
• Fetch keys from keyserver
  • Set trust levels (really?)
  • Allow for "do not publish"
• Perform cert-operation
• Publish keys to keyserver

OS Setup

• based on TAILS
• strip out all non essential apps (gnome, firefox, etc)
• all outbound network traffic blocked except to keyservers
  • implemented before tor with a squid proxy
• add gnupg 2 (more key types and better exporting)
• [install smartcard packages]
• add amnesia user to pcscd group
• install seahorse?

TODO

More things we need to decide:

• The current lexicon blows everything is a damn key: public key, private key, subkey, master key, and so on. Let's come up with some new terms. This should be apart of our larger PSST project.
• How to handle key certifications that shouldn't be published to a keyserver?
  • How do we ferry the certified keys back to the user's main install?

Appendix

What is this Offline Master Key Thing?

The Problem

In a standard GPG arrangement, the user has ostensibly one key (in reality they have one master signing/certifying key and one encryption subkey). The private key material for the keys are stored in $HOME/.gnupg/ on the user's main workstation. When an action that requires access to the private key (e.g., decrypt or sign) is performed, the private key is read straight from disk.

While conceptually simple (as simple as anything surrounding PGP is) there is the unfortunate side-effect that the identity chain is highly-coupled to the keys used for encryption and signing.

User's expend significant effort (remember your last key-signing "party"?) in creating and expanding their identity certifications (aka the Web of Trust). Their PGP key becomes a proof of identity within the relevant social circle.

Yet, the PGP key is actually fulfilling three distinct purposes:

1. Identification
2. Confidentiality (encryption, decryption)
3. Ensuring integrity (message signing)

Of these, identification is the most important, hence the reason user's go to great lengths to certify identity. Without identity verification, the usefulness of confidentiality and integrity become questionable.

There is always the concern that key material stored on a production machine can be compromised. When private key material is compromised in the traditional GPG setup, the affected keys must be revoked obliterating the painstakingly built identity chain.

Wouldn't it be great if we could retain easy encryption and signing ability while protecting one's identity and associated trust links even in the event of a compromise?

Well, by golly, there is just such a solution!

A Solution

Actions concerning signing and encryption are performed quite frequently when compared to actions involving certification, as such the private key material to perform those actions needs to be readily available. Usually certification actions are only performed after key-signing events or when editing the key itself.

So, the solution is too detach the keys used for signing, encryption, and certification. By keeping the signing and encryption keys on hand but keeping the certifying key in a secure location, we can go about our daily interactions signing and {en,de}crypting to our hearts' content. Only when we need to perform a certification (aka, key-sigining) or edit our key do we need to haul out the cert key.

The certification key is known as the master key or the identity key and the encryption+signing keys become subkeys. The master key is always kept offline in a secure location, never touching a network or insecure machine.

For enhanced security, the subkeys should be stored on an OpenPGP smartcard.

Resources

• Tinfoil hat Linux - It started as a secure, single floppy, bootable Linux distribution for storing PGP keys and then encrypting, signing and wiping files. At some point it became an exercise in over-engineering.
• FSFE's guide on setting up offline+subkeys with smartcard
• parcimonie incrementaly refreshes a GnuPG keyring over tor
• OpenPGP Best Practices