Mon, 13 Mar 2006

Encrypting your information

I have some files on my computer that I would rather not let people read. I have a file that stores authentication information to certain websites. I also have backups that I like to store on remote machines. I keep all of these files encrypted for privacy.

In a previous article about backups I talked about encrypting off site backups using openssl and a passphrase. After some discussion with colleagues I decided to move to key pair encryption. There are some pros and cons to either method.

Passphrase

Pros

• The passphrase can never be lost. It's in your head.

Cons

• A cracker need only guess the passphrase to compromise your privacy.
• Encryption cannot be automated without storing your passphrase on your computer.

Key Pair

Pros

• The cracker has to acquire a copy of your private key to attempt a crack. Even with the key, the cracker still has to guess the passphrase that encrypts the key itself.
• Encryption can be securely automated with the use of a public key.

Cons

• Extra effort must be take to ensure you have safe backups of your key pair.

Using keys encryption

Generating keys

I choose to use GnuPG as my encryption application. I generated a key pair using the normal method. References on how to do this are at the bottom of this article. Before I put these keys into action I must ensure that they are safely backed up. Without a backup, I will never be able to decrypt my information should I lose my keys.

Export your keys to the the ~./gnupg directory using these commands:

Private key:

gpg -ao user-secret.gpg --export-secret-keys "user"

Public key:

gpg -ao user-public.gpg --export "user"

Copy these two files to a safe place. A CDROM for example. Make multiple copies. Store them in multiple locations (e.g. your home, friend's house, safety deposit box). It is crucial that you never lose these files.

Password storage

Now that I have safe backups of my keys I can put them into action. I have a file that I use to store various passwords and pin numbers. I wrote a script that decrypts the file to a RAM drive for editing. By using a RAM drive I leave no evidence of it on the hard drive.

To set up a RAM drive. As root:

mount -t tmpfs -o size=64k /dev/ram /ram

Make sure you have write permissions to /ram. To make this permanent, add this line to your /etc/fstab file:

/dev/ram	/ram	tmpfs		size=64k		0 0

Now we have a ram drive that acts like a hard drive yet is in pure RAM.

Password storage script:

#!/bin/bash

# Secrets helps to maintain a secrets file
# using encryption and a ram drive.

usage="USAGE: secrets -e (edit) -p (print to stdout)"
id="Neil Watson"
efile="/home/neil/docs/accesslist.en"
dfile="/ram/accesslist.txt"
ram="/ram"

umask 177 $ram

while getopts "ep" options; do
    case $options in

        # Edit file
        e)
            # Decrypt to ram drive
            gpg -qr "$id" --decrypt -o $dfile $efile || { echo "could not decrypt"; exit; }

            # Edit file
            cd /ram 
            vi $dfile

            # Encrypt to original and remove encrypted file
            gpg -qr "$id" --encrypt --yes -o $efile $dfile || { echo "could not encrypt"; exit; }
            rm $dfile || { echo "could not delete file"; exit; }
            echo "Re-encrypted edited file"
            exit 0;;

        # Decrypt to stdout
        p)
            gpg -qr "$id" --decrypt -o - $efile || { echo "could not decrypt"; exit; }
            exit 0;;

        \? ) echo $usage
            exit 1;;

        * ) echo $usage
            exit 1;;

    esac
done

echo $usage

This script allows me to print my passwords to stdout or write them to /ram for editing. After editing the script re-encrypts the file and deletes the unencrypted file.

Encrypted backups

My earlier entry on backups stated that the actual amount of data you need to backup is usually not very large. For me, not including music files, it is less than 300MB. I copy this information to other servers, in other locations around the world. Since I don't control these servers I want to be sure that, should the server be cracked, my data is still safely encrypted.

The first thing you need to do this is an account on another server. The administrator of that server has some options that allow you access but, limit you to specific backup actions.

Allow public key authentication only. Use /bin/rbash shell to limit your account abilities. Use the command directive of the authorized_keys files. This tells the server to allow the account, once authenticated, to execute this command, automatically, without interaction. Other options to add to the authorized_keys file:

• no-port-forwarding
• no-X11-forwarding
• no-agent-forwarding
• no-pty

This ensure that you or anyone gaining access to that account have limited access to the rest of the server.

Another method of securing a remote user is to use rssh. Rssh is a restricted shell, used by ssh, that allows very limited commands: scp sftp, rdist, rsync, and cvs. Rssh can even be run in a chroot jail.

Once the remote account is ready, files can be stored there.

If I have remote rbash account:

gpg -r "user" -o - -e mybackup.tar.bz | ssh user@example.com "dd of=mybackup.tar.bz.en"

The result is a file, on the remote host, called mybackup.tar.bz.en that has been encrypted using my public key. Only my private key can reveal its secrets.

If have a remote account using rssh I'll have to encrypt the files locally and then copy them using scp or sftp. I can encrypted them locally using:

gpg -r "user" -o mybackup.tar.bz.en -e mybackup.tar.bz

References