Linux Means Business

Security and Authentication with Digital Signatures

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

by Robb Shecter

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:

#!/bin/sh
rm listing.asc 2> /dev/null
md5sum * | pgp -staf > listing.asc

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.

Weaknesses

This system has a couple of weaknesses. For one thing, it offers only file-level protection. It checks all the logical possibilities of modified files, deleted files and extra files. What about someone modifying the disk in some strange way that fools the upper level routines? Digitally signing a representation of the raw disk data is more secure.

This system is also vulnerable if the public key on the server could be modified or replaced with a different one. The same vulnerability exists for the upgrade software on the server. In practice, getting root access in order to replace the public key and creating unauthorized upgrades is a roundabout way to launch an attack. If the attacker already had root access on a particular computer, there wouldn't be any reason to use the upgrade system to get privileges or modify the server.

Authenticating Users without a Database

With the labs gradually coming on-line, we're dealing with the problem of authenticating student access. Most schools can just put a login program on their client PCs which checks the user's password against a central database via a high-speed campus LAN. This won't work for us for many reasons. Many of our labs will not be on-line in the near future. Even when on-line, the network support is unreliable and often slow. Another problem is that we have lots of weekend seminars students sign up for at the last minute. The students sign up for classes in small ``education centers'' that send us floppy disks with registration information via snail-mail long after the fact. Even if every lab were on-line, the logistics of collecting and distributing all of the information overnight would be extremely difficult. Luckily, public key cryptography and clear-signed digital signatures offer a solution:

A public and private key pair are generated for use by Field Representatives (FRs).
The FR public key is stored on the computer lab servers.
At registration time, a student entitled to computer lab access brings a floppy disk to the FR.
The FR clear-signs a certificate with the student's name, ID number, dates of validity and, optionally, information about which privileges are granted.
At least five characters are removed from the digital signature block and given to the student as his ``password''. In Listing 3, the last five characters of the second encrypted line were used as the password.

The first time a student uses any particular computer lab, he inserts the disk into a client PC and enters his student ID number and password. The password and certificate on the disk are recombined and sent to the server where it is checked using the FR's public key. If the signature is both valid and unexpired (based on the dates in the certificate), access is granted.
One final step makes the system more convenient for students when returning to a lab. The server maintains a simple database, keyed on the student ID number with the student's password encrypted with a standard one-way encryption routine like crypt(1). The next time a student visits that particular lab, he doesn't need to bring the floppy disk; he can just enter his password and be validated.
This database is automatically managed in the same way as a DNS cache. The date of expiration from the user's certificate becomes a ``time to live'' field in their database record. A cron job can be set up to periodically delete all expired entries.

This scheme has a lot of advantages. Reliable communication between the field staff, the main office and the labs is not required. Each of the three can be in completely separate, isolated locations. (And this is often the case.)

As in the first system, no real ``secrets'' are stored on the lab servers. If someone gets access to a lab server, there's no information that can help him: the public key can be read by anyone. The encrypted passwords are stored on the server; however, since they're random strings and not picked by the users, they aren't susceptible to the typical dictionary attack. Apart from dictionary attacks, standard Unix passwords are usually a secure system.

Various user access levels and periods of validity can be assigned to students by adding them to the certificates. The certificate can contain more information than just the student's name and ID number. Any kind of information that's worth keeping track of can be put into it.

Students have instant access to the computer lab once they've received their certificate. There is no delay waiting for a database to be propagated.

Since the certificates are in plain text, students can see at a glance if the certificates are correct, if they've expired yet, etc. This should make the system user-friendlier, and also limit the amount of assistance needed for help desk calls. There would never be any question about whether a certificate was still valid, issued for the correct person or contained the correct information.

Weaknesses

This scheme reduces the security requirements in the labs, but increases the precautions that need to be taken in the Field Staff's offices. Their PCs will have the secret keys on them, and plans should be made for when a computer is ``compromised''. A possible fix is to give each education center a separate key set and put all possible public keys on the servers. If a system/key/passphrase is stolen, that particular key set is revoked and not used any more.

PGP and MD5 Resources

Robb Shecter is a longtime Unix user and has been a Linux fan since v. 0.98. He's interested in object-oriented design, Java, IP routing and bass guitar. He's currently a network and Unix specialist at the University of Maryland European Division, and can be reached at shecter@acm.org.