How one university uses PGP and digital signatures to make its network secure.

PGP and public-key cryptography are used
all the time for encrypting e-mail and other kinds of messages.
They can also be used in other interesting ways. This article
describes two other uses for PGP and digital signatures that can
help make networks more secure. The University of Maryland
University College European Division (quite a mouthful) has 65
Linux-based computer labs in 10 countries. A Linux box in each lab
serves files via NFS to Windows/Linux dual-boot clients. The labs
are spread out over a huge geographical area, and many are hard to
reach. We depend on Linux's reliability to make the system work. At
the “education centers”, there is usually no technical support.
If a network is down, someone from Computer Field Support must go
to the center on an overnight trip to fix it.

To keep things as maintenance-free as possible, we have to
develop some secure and reliable systems for managing the networks
and the users. The two systems talked about here both use
“clear-signed digital signatures” to accomplish their goals. One
is a system to securely transmit software upgrades; this has been
implemented in Perl and is in use today. The second is a system for
remotely authenticating users without the need to access a user
database. This one is in the design/specification stage.

There are pointers to information about getting started with
cryptography at the end of this article.

Securely Transmitting Software Upgrades

We realized we needed a security system when it came time to
upgrade the software on our lab servers. We had to install new
versions of the client programs, make modifications to the server
config files and other changes. We knew that, in many cases, the
upgrades must be able to be made by people with little computer
knowledge. The fact that server system files might have to be
modified in a particular upgrade meant that superuser privileges
would have to be given out. The three situations we wished to
prevent were:

Simple media unreliability—the software was going
to be delivered via a network connection, on zip drive disks or on
conventional floppies. The system would have to protect itself
against flaws in the media, such as a floppy disk with bad sectors.
The system should refuse to begin the installation if any part of
the package is bad.

“Man in the middle” attack—in general, an attack
in which someone alters the data after it's been sent, but before
it's been received. Once the floppies arrive at the education
center, they're left lying around on the user's desk for a while. A
curious (or devious) student can pick them up and add some special
configuration files to be installed. Since superuser access is
given to the upgrade program, someone could modify the contents of
the packages and gain root access.

Unauthorized upgrades—our goal of making the
upgrades as easy as possible works for approved
and unapproved users. An attacker who gets
access to one of our upgrade floppies could figure out the file
formats and create new upgrades that would change any system
files.

These three problems can be summed up as a must to verify
integrity and authenticity. We must make sure that the data has not
been altered, deleted or added to in any way. We must also make
sure that the data comes from the approved source—in this case
from our Computer Field Support group. Integrity and authenticity
are exactly the functions digital signatures provide. The following
protocol solves our problem:

Computer Field Support (CFS) generates a public and
private key pair.

A package file listing is generated.

An MD5 checksum is generated for each file and
listed in a second column. See Listing
1.

This two-column listing is digitally clear-signed
with CFS's secret key. This compromises the certificate delivered
with the software package. See Listing
2.

At installation time, the digital signature is
checked using CFS's public key, which is stored on the
server.

An MD5 checksum is generated for each file in the
package and checked against the corresponding string in the
certificate.

The installation program in the package is
executed.

Using this system, a file can't be modified, because the MD5
checksums wouldn't match in step 6. The checksums in the
certificate can't be altered, because the certificate's digital
signature would fail in step 5. PGP and md5sum are called from
shell or Perl scripts to do all the work. The script that creates
the certificate is very simple and doesn't require the user to know
how to use PGP. All he needs to know is the correct pass phrase to
enter:

The user in the field runs another program, which also calls
PGP and md5sum. The certificates are more secure when clear-signed
than when encrypted, because at this stage we don't rely on any
“secrets” being stored on the remote servers. Only the CFS public
key is sent into the field. If anyone breaks into one of our
computers, the information in the public key is harmless. When we
encrypt the certificates, we need to make a second public/private
key set for the servers themselves. The private key would be stored
on the server and used to decrypt the messages, which would be
something “interesting” for crackers to get by. Decrypting the
messages also means that a pass phrase must be given to PGP. Either
the user would have to enter it, or it would have to be a
hard-coded parameter to a program. Since our current system needs
to verify only a clear-signed message by using a public key, PGP
doesn't need a pass phrase. This makes the installation process
easier and safer.

CERT's method for releasing software patches uses a similar
system. They digitally sign e-mail messages and README files
containing the checksums of files to be downloaded. People who take
the time to verify the checksums can easily find out whether the
files have been modified.