History

PSST » Products of PSST Work »

CleanRoom

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

Clean Room

A linux livecd + application combo that provides a secure, usable environment for managing an offline master identity crypto key. This setup is most commonly used for GPG keys, but also applies to SSH keys, and others.

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.

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 2048 bits)
    • * (optional) Move subkeys to smartcard
    • Save subkeys and master public key to external storage
    • Persist master private key to the system
  • keys and subkeys can have expiration or not
    • default to long expiry
    • provide easy tools for updating expiry
  • generate all keys on offline OS
    • install subkeys onto HSM from offline
    • in case of smartcard destruction, they can be restored from offline
Here are some writeups of this process:

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

Hardware Security Modules

Hardware Security Modules (HSMs) provide much improved security when working with secret keys. They can also improve usability once setup. Clean Room should support all manner of relevant HSMs. More research on that topic here:

Managing X509 Keys

The Problem

X509 is an old, crufty standard for keys that is in widespread use, in things like TLS, HTTPS, Java .jar signing, and Android .apk signing. Clean room should also support working with this keys so that Clean Room can be used for signing release .jar and .apk files.

The Solution

  • Tails/wheezy will greatly improve things, by including:
    • scdaemon and better opensc support
    • openjdk-7-jdk for improved keytool and jarsigner

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

Also available in: PDF HTML TXT