NewsForge
The Online Newspaper for Linux and Open Source
http://software.newsforge.com/
Title Keeping email under lock and (public) key
Date 2005.07.01 11:00
Author Marcelo Rinesi
Topic
http://software.newsforge.com/article.pl?sid=05/06/27/1614233
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 "[EMAIL PROTECTED]" 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 "[EMAIL PROTECTED]," 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.
Links
1. "GNU Privacy Guard" - http://www.gnupg.org/
2. "Pretty Good Privacy" - http://www.pgp.com/
3. "Procmail Quick Start" -
http://www.ii.com/internet/robots/procmail/qs/
You are a subscribed member of the infowarrior list. Visit
www.infowarrior.org for list information or to unsubscribe. This message
may be redistributed freely in its entirety. Any and all copyrights
appearing in list messages are maintained by their respective owners.
