Roland's cryptography page
Roland's cryptography page |
|
When I started writing this page, it was about how to use encryption on FreeBSD. During the writing process I realized that a lot of what is written here is applicable on other systems like Linux and OS X as well, so I changed the title. :-) Those pieces that are specific to FreeBSD are marked as such.
Encryption is a process that uses an algorithm to transform information so that it becomes unreadable for anyone who does not have a key to the information. It is a part of the discipline of cryptography.
Basically, I use encryption to protect my privacy. In this age of networked and portable computers it has become relatively easy for someone to peek in the files stored on your computer/laptop/netbook, especially if they are lost or stolen.
According to Article 12 of the Universal Declaration of Human Rights, your privacy is a right;
No one shall be subjected to arbitrary interference with his privacy, family, home or correspondence, nor to attacks upon his honour and reputation. Everyone has the right to the protection of the law against such interference or attacks.
For us Europeans, this is codified in Article 8 of the ``Convention for the Protection of Human Rights and Fundamental Freedoms’’.
In my opinion sharing knowledge is a very good thing, as is giving back. That’s why I release the source code for own my programs under the simplified BSD License. It is also the reason that I wrote and maintain these pages; in the hope that they are useful to others as software and information provided by others has been useful to me.
But my data is nobody’s business unless I choose to share it!
Encryption software requires a password or -phrase and/or a token to decrypt material so you can use it. It is important that these passwords remain secret, and they should not be easy to guess.
Although it is not a topic that will interest users, the choice of encryption algorithm used is important.
My recommendation would be that you only use encryption algorithms that are publicly available and have been thoroughly tested by cryptographers. If the security of an encryption algorithm depends on it being kept secret (that is called security through obscurity), it’s not very good. And more important, nobody can tell. E.g. read Bruce Schneiers essay about openness in security, and his May 2002 newsletter about Kerckhoffs’ Principle.
So for now, stick with algorithms like AES, Serpent, Blowfish or Twofish.
Colin Percival has created a new key derivation function called scrypt, as well as en encyption routine based on it. He has published a paper on it at the BSDcan’09 conference. He estimates;
On modern hardware and with default parameters, the cost of cracking the password on a file encrypted by scrypt enc is approximately 100 billion times more than the cost of cracking the same password on a file encrypted by ‘openssl enc’.
He bases this argument, as far as I can deduce from the slides from his talk at BSDcan’09, on the fact that openssl uses MD5 as a key derivation function, and by his estimate scrypt is 2³⁷ (1.37·10¹¹) more expensive to attack than MD5. While I cannot evaluate his claims, as I am not a cryptographer nor mathematician, Colin holds a B.Sc in mathematics and a doctorate in computer science, and is well known as FreeBSD Security Officer. So I suspect he knows what he is doing.
If you lose a laptop, or if your desktop is stolen, your data is accessible to everybody unless you use disk encryption.
Disk encyption means that the information as written to disk is encrypted. Before the filesystem on the encrypted disk or partition can be used, the key is supplied to the operating system enabling it to decipher the data. The consequence of this is that if your computer is running and the encrypted disk or partition is in use, the data is accessible. So if someone were able to gain access to your computer while it is running and the encrypted filesystem is in use, that attacker can read it! (Note: This implies that you either have to lock your computer or remove the encrypted filesystem or shut down the computer to keep the data safe if you are not using the system. It also implies that it it important to keep unauthorized people from getting access to your computer.) This is why this method of encryption is most usefull in case of hardware loss or theft.
FreeBSD comes with a flexible framework that allows you to encrypt whole disks
or FreeBSD partitions. The different methods are covered in the
disc encryption section of the FreeBSD Handbook. Since I use FreeBSD
primarily for my desktop and laptop and not as a server, I am mostly concerned
with securing the user data under /home. My method is to put /home on a
separate partition and encrypt that with geli(8). In order to use this, it
must be built into the kernel or loaded as a module. This is explained in the
manual page. Since encrypted partitions (or rather their device nodes to be
technical) are recognizable by the system, the FreeBSD startup scripts know to
ask for the password for this partition before trying to use it.
Another use is backup disks. Harddisks with a USB connection are extremely convenient as a backup medium because they are faster and easier to work with than DVDs or tapes. But because they are easily lost or stolen, I encrypt those as well.
When using a new disk, you first have to slice it with fdisk(8) (This is
called partitioning it in the PC world), then use bsdlabel(8) to create the
labeled BSD partitions. This is covered in more depth in my installation
page. I will use a USB connected backup disk as an example.
For backups, I use an external hard disk with a USB connection. This device
uses the umass driver, which in turn needs the scbus and da devices. If
I plug this disk in, a device node is created. I’ll use da0 as an example,
but it could use another number if there are other da devices in use. This
disk has a single BSD slice, divided into two partitions. The first 20BG
partition (da0s1a) is for the dumps of /, /usr and /var. The rest of the
disk is a geli(8) encrypted partition (da0s1d.eli) to store data from /home.
# fdisk -I /dev/da0
# bsdlabel -w /dev/da0s1
# setenv EDITOR /usr/bin/ee
# bsdlabel -e /dev/da0s1
The EDITOR variable is set to a somewhat friendlier editor (ee(1)) then the default vi(1)! Next, the slices are made with the second bsdlabel command.
# /dev/da0s1:
8 partitions:
# size offset fstype [fsize bsize bps/cpg]
a: 20971520 16 4.2BSD 2048 16384 28528
c: 488392002 0 unused 0 0 # "raw" part, don't edit
d: 467420466 20971536 4.2BSD 0 0 0
We now have a partition called /dev/da0s1d that we want to encrypt. The first
step is to fill this disk with random data. This will deny any attacker
knowledge of which parts of the partition are actually in use.
# dd if=/dev/random of=/dev/da0s1d bs=32k
You can experiment with larger block sizes. Last time I timed this, it took about an hour to fill 120 GiB this way.
Next, use geli(8) to prepare and attach the partition;
# geli init -l 256 /dev/da0s1d
# geli attach /dev/da0s1d
This will initialize /dev/da0s1d for use with geli with a 256-bit key (using
the AES algorithm) supplied by a passphrase. The second command will
create the device node /dev/da0s1d.eli, which provides access to the
unencrypted data. The ‘#’ prompt indicates that these commands have to given
as the root user. Next we will create a filesystem on this device using
newfs(8), and mount it.
# newfs -U /dev/da0s1d.eli
# mount /dev/da0s1d.eli /mnt/backup
After this, the filesystem is ready to be used. The ‘geli init’ and ‘newfs’
steps only have to be carried out once. But attaching the geli provider and
mounting the filesystem always have to be done once before using the
filesystem. As I mentioned before, the .eli suffix on a device when used in
/etc/fstab enables the startup scripts to make sure that the encryption
device is attach-ed before use. But if you want to do it by hand, use:
# geli attach /dev/da0s1d
# mount /dev/da0s1d.eli /mnt/backup
After you’re finished with it:
# umount /mnt/backup
# geli detach /dev/da0s1d
The open-source truecrypt software provides disk encryption for Windows XP/Vista and 7, Linux and OS X. It seems to use good encryption algorithms, but since I’ve never used it yet.
Mac OS X also comes with en encryption feature called FileVault. However, this is closed source, and I would hesitate ro recommend it on that ground alone. It also has significant limitations as discussed on the Wikipedia page.
For extra safety, you can also additionally encrypt individual files. This means that you need to decrypt them before you can even read them. Use this for e.g. files containing passwords.
UNIX-like systems like FreeBSD and Linux comes with a program named crypt(1) that was originally used for this purpose. Do not use this program to encrypt your files! Its encryption algorithm has long since been broken. Use some of the alternatives listed below.
(I’m mentioning this here because it is part of the FreeBSD base system. So some of the remarks in this section are FreeBSD specific. )
The openssl program that also comes with the FreeBSD base system (see openssl(1)) can safely be used. See also enc(1). Some tips for using openssl;
-salt option when encrypting files.-k or -pass options. Let the program ask you for a
password.rrm program from my software page, or one of the *wipe ports
you can find under /usr/ports/security.As you can see, there are some things you need to keep in mind when using openssl for encryption. Since it is part of the FreeBSD base system, you can always decrypt things encrypted with openssl even on a machine without any additional programs installed. That can be a plus in case you need to restore encrypted backups to a new machine. To use openssl effectively, it would probably be better to write a wrapper script that calls openssl and takes care of the details, like this;
#!/bin/sh
# Uses openssl to encrypt a single file.
# Check if the argument is a file
if [ ! -f $1 ]; then
echo "Error: $1 is not a file."
exit;
fi
# Append .aes to the filename to create the output filename.
outname=${1}.aes
# Use the AES algorithm in cipher-block chaining mode with a 256 bit key.
openssl aes-256-cbc -e -salt -in $1 -out ${outname}
# If the encryption fails, bail out.
if [ $? ]; then
exit 1;
fi
# Overwrite the old file, and remove it.
SZ=`du $1|awk '{print $1}'`
dd if=/dev/zero of=$1 bs=1k count=$SZ >/dev/null 2>&1 && rm $1
The fact that openssl uses MD5 as a key derivation function has me slightly worried. According to Colin Percival’s slides, this is relatively cheap to attack by brute force. So I don’t think this is the optimal solution for encrypting files.
The ccrypt program was designed as a replacement for the broken crypt(1)
program. It uses the same Rijndael cipher that is used in aes. One handy
feature is that it by default overwrites the target file with its encrypted
contents. This means that you cannot forget to delete the old file. On FreeBSD
it is available from the port /usr/ports/security/ccrypt.
This program uses the scrypt key derivation function mentioned above. In
FreeBSD it is available from ports as /usr/ports/security/scrypt.
A good program to use is the GNU Privacy Guard. One thing to remember is
that this program uses public key cryptography, using a combination of a
public and private key. (All the other programs I’ve mentioned before use only
a private key.) This makes the gpg2 program usefull for more than just
encrypting your own files, it can also be used for encrypting or signing
e-mail messages destined for someone else. If you encrypt a file using another
person’s public key, only that persons private key can be used to decrypt it.
This program is a good choice because of its multiple uses. It integrates well with several mail programs. There are also several frontends available to make it even easier to use.
The only downside to using this program is that you need to have your keyfiles available. But carrying your private key around is generally not a good idea; you want to keep that private (even though it is protected by a password).
—– Copyright © 2010, Roland Smith rsmith@xs4all.nl
This <span xmlns:dc=“http://purl.org/dc/elements/1.1/” href=“http://purl.org/dc/dcmitype/Text” rel=“dc:type”>work is licensed under a Creative Commons Attribution 3.0 Unported License