Keeping email under lock and (public) key

With governments and law enforcement organizations pushing for increasingly intrusive monitoring and logging of business email messages, network administrators are put in an uncomfortable situation. Even disregarding privacy implications, such systems pose security problems at least as serious as those they attempt to solve. A “master archive” of emails is after all an extremely tempting target to external hackers, but it also has staggering potential for internal abuse. Ideally, we would want no centralized mail logs, but legal and corporate requirements mandate suitable record-keeping in the case of an internal or external audit. One way to meet both goals is by encrypting the archive using public key cryptography.

While traditional cryptographic systems can be thought of as safes — secure places where one can put or retrieve things with the help of the appropriate key — public key cryptographic systems are more akin to mailboxes, where practically anybody can drop things in, but only someone with a key can retrieve them. The key (no pun intended) difference is that public key cryptography uses two different keys. One key, known as the public key, encrypts files, and another, the secret key, decrypts them.

As its name suggest, a public key can be distributed as widely as you need. Encrypted material will remain unreadable to anyone without the secret key. This is exactly what we need to set up a relatively benign email archive: to make it straightforward to add material to, but impossible to access without the required key.

For added security, the secret key can be split in two or more pieces, in such a way that only with all the pieces the archive can be opened. Seemingly straight out of a novel of intrigue, it’s perhaps one of the best defenses against internal abuse: the more people have to cooperate to access the archive, the less probable it is that they will do so without sufficient cause. Remember that one of our goals in this case is not only to prevent access by those unauthorized to do so, but also to minimize the chances that people with authorization will misuse their powers. It’s an organizational as much as a technological problem, but the flexibility of public key cryptographic systems gives you useful tools to deal with it.

Let’s see how this works in practice by setting up a simple email archive for a Postfix server with a working Procmail setup, using the open source GNU Privacy Guard software.

Using the GNU Privacy Guard

GPG is an offshoot of the seminal Pretty Good Privacy commercial software. To install it, just download the source package from the GPG site, check it using sha1sum against the.sig file available on the same server (it’s not likely that somebody would tamper one and not the other, or both, but it’s always a good habit to check your source packages), and untar and install it using./configure, make, and make install as root.

Now create an user on the mail server to handle the archiving — let’s say “archiver.” We’ll send to this user a copy of every message going through the Postfix system, and set up a Procmail recipe to encrypt and store them.

Before setting up the mail archive, we need to generate a public/private key pair, and take away the private key from the server. Remember: without that private key, the encrypted archive itself is unreadable, but you don’t need that key to add things to the archive.

To generate the key, log on as the archiver user and run the command gpg --gen-key. It will ask a few simple questions:

• Kind of key: Use the default, which is actually the only one that will work in this case.
• Key size: The longer your key, the more secure your archive it will be, but the slower things will run. Also, if you’re planning to split the key among various people, you will need a longer key to maintain the same level of security. As a rule of thumb, don’t pick anything below 1,024, and ideally test your system with various key sizes and choose the largest one that still gives you acceptable performance.
• How long should the key be valid: Be sure to select 0, which indicates forever.
• For user name and email, choose something abstract and simple, like “Archiver” and “archiver@yourdomain.com.” Don’t tie it to any personal email address. The “User ID” of the key pair will then be “Archiver.”
• Passphrase: A passphrase adds an extra layer of security to the secret key. It’s a (long) password that someone needs in order to use the secret key. Think of it as another part of the key; by itself it will not open the archive, but without it, the secret key itself will be useless. The simplest arrangement might be giving the key (we’ll see in a short while how to export it) to one or more officers of your company, and the passphrase to another.

Once GPG has finished generating the key pair, run gpg --list-secret-keys and gpg --list-public-keys to see the public and private keys that the user is holding. We need to keep the public key on the server to do the encryption, but we will put away
the private key for safety.

Run gpg -a --export-secret-key 'Archiver ' > secret.txt. The result is an ASCII representation of the secret key in the file secret.key (without the -a switch, it’d be a binary representation, which is a bit smaller but less comfortable to work with). Now run gpg -a --delete-secret-key 'Archiver ' and answer yes to all questions in order to remove the secret key. Now, if you lose the contents of secret.txt, anything you encrypt will be lost forever! Print out the contents of this file, put it in an envelope, save the envelope wherever your company stores its most confidential legal papers, and destroy the file. You’re done. Now anything you encrypt with the corresponding public key will be readable only by somebody who knows the passphrase and has access to the contents of envelope. For more security, you can split the paper in two envelopes and put it under the care of two different branches, legal offices, etc. The point of this exercise is making retrieving all the pieces cumbersome enough that only a legitimate use will make sense.

Setting up the archiver

Setting up the archiver itself is easy. Log on as the archiver user, and modify.procmailrc to look like this:

SHELL=/bin/sh
PATH=/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin
PMDIR=$HOME
LOGFILE=$PMDIR/archive.log
VERBOSE=yes
MAILDIR=$HOME/vault:0:
*
| gpg --batch --encrypt -r "Archiver " -a >> VAULT

This configuration file instructs Procmail to run all mail to the archiving account through the gpg command, encrypting its standard input with the public key of “Archiver ” and appending that encrypted mail to the VAULT file. By tweaking and extending this file you can do more complicated things. Check the Procmail Quick Start page for more information and ideas about how use Procmail.

Now all we need to do is to have copies of everything sent to archiver. This is easy in Postfix: set the always_bcc option in the main.cf configuration file to “archiver” (or “archiver@yourdomain.com,” or any valid reference to that account), and restart or refresh Postfix.

Opening up the vault

Accessing messages in the vault is a bit more complicated. First, you need to retrieve all the pieces of the secret key — a process, one hopes, that can happen only in the event of severe suspicion of a security breach, an SEC audit, or a similarly dire situation. Retype everything carefully, headers and all, into a secret.txt file, move it to the server (actually, any machine with GPG installed, although the mechanics change a bit there), and run gpg --import secret.txt. Now the secret key is back in the server, and you can decrypt the vault.

You can use the following Python script to split the vault into individual messages, although it’s trivially easy to write such a program in any language.

#!/usr/local/bin/python

msg = ''
counter = 0
for line in  open('VAULT').readlines():
    msg += line
    if '-----END PGP MESSAGE-----' in line:
        f = open('message.%d'%counter, 'w')
        f.write(msg)
        f.close()
        msg = ''
        counter += 1

Then you can use a for loop in the shell to decrypt all the individual emails using gpg --decrypt filename, and you have the messages there ready to be audited. A piece of advice: to avoid having to enter the passphrase a few thousand times, you can change it before decrypting the vault by using

gpg --edit-key 'Archiver ' passwd

Change the passphrase to the empty one to make it easier to decrypt all the message files as a batch.

A note of caution

In an ideal world, emails would always be encrypted by default, logging would be both comprehensive and reasonably secure from abuse, and hacks like this would not be needed. As it is, this archive doesn’t add any security at all to your present setup; it’s still as easy or as difficult as it ever was to sniff your mails over the network, hack into your users’ computers, or even access the mail server itself. Someone could corrupt or destroy the archive if the mail server isn’t properly secured. But you now have an auditable mail archive (one you can, for example, back up to an external facility without worrying too much about somebody losing the tapes along the way) without adding a major new security vulnerability to your system.