People use passwords and secret keys for a lot of different services, e.g., firefox, pidgin, gnome keyring, ssh keys, pgp keys. All of this data is normally stored in the home directory of a user.

An easy solution is to make the filesystem itself encrypted, see EncryptedFilesystems.

Things get more complicated if several different computers are in use, e.g. a laptop and a desktop system. A way to make this possible is the storage of the credentials on an (encrypted) USB stick.

Use cases

This should allow:

• more or less single-signon if the USB key is available

This should protect against:

• Usage of the laptop without the USB key or a password
• Usage of the stored credentials on the key without the laptop/desktop system or a password
• Being forced to decrypt the hard drive of a PC during customs (just send the USB stick with somebody else)

Basic Idea

• Use pam-gnome-keyring to decrypt the 'login' keyring stored on the laptop/desktop
• the 'login' keyring contains the password for a LUKS partition on the USB stick, which is automatically decrypted and mounted on login
• the LUKS partition contains the 'default' keyring for Gnome with additional passwords, the keyring password can also be stored in the 'login' keyring or just be empty

Credentials

Epiphany / Firefox

• epiphany's profile is in ~/.gnome2/epiphany/mozilla/epiphany/

• firefox's profile is in ~/.mozilla/firefox/<random>/

• Master password (default is empty) encrypts key3.db
• randomly generated triple-DES key in key3.db encrypts credentials in signons2.db
• epiphany has no way to set a master password
• Further information can be found at

  • http://groups.google.com/group/netscape.public.mozilla.general/msg/7ad96c740c97f6da

  • http://groups.google.com/group/netscape.public.mozilla.crypto/msg/595619356d001a32

  • http://groups.google.com/group/netscape.public.mozilla.security/msg/a6d5d59dac4f4788

  • http://groups.google.com/group/netscape.public.mozilla.security/msg/d8b5fc4a5553de64

  • http://kb.mozillazine.org/Signons2.txt

Pidgin

• ~/.purple/accounts.xml, cleartext password

• bug report over gnome keyring integration: http://developer.pidgin.im/ticket/673

• There is a pidgin-gnome-keyring.patch in the openSUSE package: http://download.opensuse.org/repositories/GNOME:/STABLE/openSUSE_10.3/src/pidgin-2.1.1-34.2.src.rpm

Gnome keyring

• AES encrypt/decrypt, MD hash, and SHA-256 encryption
• Several different keyrings, one default keyring determined by ~/.gnome2/keyrings/default

• Gnome keyring on a removable disk: http://live.gnome.org/GnomeKeyring/Removable

• 'login' keyring is unlocked by libpam-gnome-keyring on login, but this keyring can not be on a removable medium because it is mounted by gnome-volume-manager which is not active yet. Other keyrings may have their unlock passwords stored in the 'login' keyring, and are then automatically unlocked when necessary: http://live.gnome.org/GnomeKeyring/Pam

• if an application tries to store a password while the default keyring is inaccessible, ~/.gnome2/keyrings/default gets reset to an empty file, and the 'login' keyring becomes the default keyring, in which all further keys are stored

SSH keys

• stored in ~/.ssh/

PGP keys

• stored in ~/.gnupg/{secring.gpg,pubring.gpg,trustdb.gpg}

---

This is from a mail from evan to scott:

The use case for this is obvious. People have authentication information for a variety of systems: pam login credentials, ssh keys, pgp keys, firefox keyring, gnome keyring. Managing these is a pain, so efforts have been made to centralize your credentials (firefox, gnome), but using such systems means that if your computer is compromised, so is every system you have access to. We recently saw this with a distro team member having to revoke his PGP key because his laptop was stolen.

Your passwords and keys should be on a separate physical device, ideally a USB key. While using a smart card (which is the approach that Fedora seems to be taking: google for fudcon-buston-2007-single-sign-on.ogg) would be best, they are not easy to come by.

• The USB key should store information for a single user. This should include, but does not have to be limited to, their PAM credentials, ssh keys, firefox keyring, gnome keyring, kerberos tickets, and pgp keys.
• There will be a GUI to provision new USB keys, and will be added as an option in the right click menu of the fast-user-switching-applet or as a modified version of "user settings".
• Inserting the USB key and then typing the username in any PAM mechanism, such as GDM, logs the user in without requiring their password. This can already be done easily, but if we want to extend it further, since we want to use one USB key per user (see above), perhaps we can modify PAM or GDM to grab the username from the USB key, so inserting the key alone would log the user in. This would look fantastic.
• Pulling out the USB key logs the user out. This has the side benefit of not confusing any application that doesn't have its keyring in memory. The USB key should be mounted using sync or flush to prevent corruption.
• To prevent the USB key from being easily compromised if it is stolen, the filesystem on the USB key will be encrypted using a private key. The key passphrase will be stored on any computer it's paired with (I guess kind of like bluetooth). Inserting the USB key into a computer that hasn't been previously paired with the key, when setting up the key as a new user on the system, will require the user enter the paassphrase for the key.
• Ideally the key should be backed up in case the key is destroyed, stolen, or the flash dies, but I cannot think of a way to do this easily and securely. My current thoughts are to use a combination of unionfs and some sort of crazy encrypted loopback disk, but I am open to better ideas.

* * Probably the best way of backing up the key would be simply to have two USB keys, with the option in Password Manager to duplicate the key when a new blank USB disk is inserted. That way one copy could be kept in a secure location, for example in a safe or lockbox. If both keys are inserted at the same time, the system would recognise that two copies of the same key have been inserted and silently sync or update the older copy.

• I suppose this could be part of the installer, but I'd rather to force the admin user to log in at least once with a real password to help prevent them from forgetting it.
• We should also try to do something with those fancy fingerprint readers found on newer laptops.