Encrypting and Signing Files with GnuPG

previous Securing Linux

Linux comes with the GNU Privacy Guard (GnuPG, or simply GPG) encryption and authentication utility. With GPG, you can create your public and private key pair, encrypt files using your key, and also digitally sign a message to authenticate that it’s really from you. If you send a digitally signed message to someone who has your public key, the recipient can verify that it was you who signed the message.

Understanding public key encryption

The basic idea behind public key encryption is to use a pair of keys — one private and the other public — that are related but can’t be used to guess one from the other. Anything encrypted with the private key can be decrypted only with the corresponding public key, and vice versa. The public key is for distribution to other people while you keep the private key in a safe place.

You can use public key encryption to communicate securely with others; Figure 2-1 illustrates the basic idea. Suppose Alice wants to send secure messages to Bob. Each of them generates public key and private key pairs, after which they exchange their public keys. Then, when Alice wants to send a message to Bob, she simply encrypts the message using Bob’s public key and sends the encrypted message to him. Now the message is secure from eavesdropping because only Bob’s private key can decrypt the message — and only Bob has that key. When Bob receives the message, he uses his private key to decrypt the message and read it.

Figure 2-1: Bob and Alice can communicate securely with public key encryption.

At this point, you need to stop and think and say, “Wait a minute! How does Bob know the message really came from Alice? What if someone else uses Bob’s public key and sends a message as if it came from Alice?” This situation is where digital signatures come in.

Understanding digital signatures

The purpose of digital, or electronic, signatures is the same as pen-and-ink signatures, but how you sign digitally is different. Unlike a pen-and-ink signature, your digital signature depends on the message you’re signing. The first step in creating a digital signature is to apply a mathematical function to the message and reduce it to a fixed-size message digest (also called a hash or a fingerprint). No matter how big your message, the message digest is usually 128 or 160 bits, depending on the hashing function.

The next step is to apply public key encryption. Simply encrypt the message digest with your private key, and you get the digital signature for the message. Typically, the digital signature is added to the end of the message, and voilà — you get an electronically signed message.

What good does the digital signature do? Well, anyone who wants to verify that the message is indeed signed by you takes your public key and decrypts the digital signature. What that person gets is the message digest (the encrypted hash) of the message. Then he or she applies the same hash function to the message and compares the computed hash with the decrypted value. If the two match, no one has tampered with the message. Because your public key was used to verify the signature, the message must have been signed with the private key known only to you. So the message must be from you!

In the theoretical scenario of Alice sending private messages to Bob, Alice can digitally sign her message to make sure that Bob can tell that the message is really from her. Figure 2-2 illustrates the use of digital signatures along with normal public key encryption.

Figure 2-2: Alice can digitally sign her message so that Bob can tell it’s really from her.

Here’s how Alice sends her private message to Bob with the assurance that Bob can really tell it’s from her:

Alice uses software to compute the message digest of the message and then encrypts the digest by using her private key. This is her digital signature for the message.
Alice encrypts the message (again, using some convenient software and Bob’s public key).
She sends both the encrypted message and the digital signature to Bob.
Bob decrypts the message, using his private key.
Bob decrypts the digital signature, using Alice’s public key. This gives him the message digest.
6. Bob computes the message digest of the message and compares it with what he got by decrypting the digital signature.
If the two message digests match, Bob can be sure that the message really came from Alice.

Using GPG

GPG includes the tools you need to use public key encryption and digital signatures. You can figure out how to use GPG gradually as you begin using encryption. The following shows you some of the typical tasks you can perform with GPG.

Generating the key pair

The steps for generating the key pairs are as follows:

Type gpg --gen-key.
If you’re using gpg for the first time, it creates a .gnupg directory in your home directory and a file named gpg.conf in that directory. Then GPG asks what kind of keys you want:
Please select what kind of key you want:
(1) DSA and ElGamal (default)
(2) DSA (sign only)
(4) RSA (sign only)
Your selection?
Press Enter for the default choice because it’s good enough.
GPG then prompts you for the key size (the number of bits).
Press Enter again to accept the default value of 2,048 bits.
GPG asks you when the keys expire. The default is to never expire.
If the default is what you want (and why not?), press Enter.
When GPG asks if you really want the keys to never expire, press the Y key to confirm.
GPG prompts you for your name, your e-mail address, and finally a comment to make it easier to associate the key pair with your name.
Type each piece of requested information and press Enter.
When GPG gives you a chance to change the information or confirm it as is, confirm by typing o and pressing Enter.
GPG next prompts you for a passphrase that protects your private key.
Type a long phrase that includes lowercase and uppercase letters, numbers, and punctuation marks — the longer the better — and then press Enter.
Be careful to choose a passphrase that you can easily remember.
GPG generates the keys. It may ask you to perform some work on the PC so that the random-number generator can generate enough random numbers for the key-generation process.

Exchanging keys

To communicate with others, you have to give them your public key. You also have to get public keys from those who may send you a message (or someone who might sign a file and you want to verify the signature). GPG keeps the public keys in your key ring. (The key ring is simply the public keys stored in a file, but it sounds nice to call it a key ring because everyone has a key ring in the real world, and these are keys of a sort, right?) To list the keys in your key ring, type

gpg --list-keys

To send your public key to someone or to place it on a Web site, you have to export the key to a file. The best way is to put the key in what GPG documentation calls an ASCII-armored format, with a command like this:

gpg --armor --export kdualney@insightbb.com > kdulaneykey.asc

This command saves the public key in an ASCII-armored format (it basically looks like garbled text) in the file named kdulaneykey.asc. You would replace the e-mail address with your e-mail address (the one you used when you created the key) and replace the output filename to something different.

After you export the public key to a file, you can mail that file to others or place it on a Web site for use by others.

When you import a key from someone, you typically get it in an ASCIIarmored format as well. For example, if you have a us-cert@us-cert.gov GPG public key in a file named uscertkey.asc (obtained from the link at www.us-cert.gov/pgp/email.html), you then import it into the key ring with the following command:

gpg --import uscertkey.asc

Use the gpg --list-keys command to verify that the key is in your key ring. For example, here’s what you might see when typing gpg --listkeys on the system:

/home/kdulaney/.gnupg/pubring.gpg
-----------------------------
pub 1024D/7B38A728 2010-08-28
uid Kristin Dulaney <kdulaney@insightbb.com>
sub 2048g/3BD6D418 2005-08-28
pub 2048R/F0E187D0 2004-09-08 [expires: 2010-10-01]
uid US-CERT Operations Key <us-cert@us-cert.gov>

The next step is to check the fingerprint of the new key. Type the following command to get the fingerprint of the US-CERT key:

gpg --fingerprint us-cert@us-cert.gov

GPG prints the fingerprint:

pub 2048R/F0E187D0 2009-09-08 [expires: 2010-10-01]
Key fingerprint = 049F E3BA 240B 4CF1 3A76 06DC 1868 49EC F0E1 87D0
uid US-CERT Operations Key <us-cert@us-cert.gov>

At this point, you need to verify the key fingerprint with someone at the US-CERT organization. For a large organization such as US-CERT, you can verify the fingerprint on the US-CERT Web page (www.us-cert.gov/pgp/encryptmail.html).

If you think the key fingerprint is good, you can sign the key and validate it. Here’s the command you use to sign the key:

gpg --sign-key us-cert@us-cert.gov

GPG asks for confirmation and then prompts you for your passphrase. After that, GPG signs the key.

Because key verification and signing is a potential weak link in GPG, be careful about what keys you sign. By signing a key, you basically say that you trust the key to be from that person or organization.

Signing a file

You may find signing files useful if you send a file to someone and want to assure the recipient that no one tampered with the file and that you did, in fact, send the file. GPG makes signing a file easy. You can compress and sign a file named message with the following command:

gpg -o message.sig -s message

To verify the signature, type

gpg --verify message.sig

To get back the original document, simply type

gpg -o message --decrypt message.sig

Sometimes you don’t care about keeping a message secret, but you simply want to sign it to indicate that the message is from you. In such a case, you can generate and append a clear-text signature with the following command:

gpg -o message.asc --clearsign message

This command basically appends a clear-text signature to the text message. Here’s a typical clear-text signature block:

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDEhAtaHWlHHs4pygRAhiqAJ9Qj0pPMgKVBuokDyUZaEYVsp6RIQCfaoBm
9zCwrSAG9mo2DXJvbKS3ri8=
=2uc/
-----END PGP SIGNATURE-----

When a message has a clear-text signature appended, you can use GPG to verify the signature with the following command:

gpg --verify message.asc

If you had indeed signed the message, the last line of the output says that it’s a good signature.

Encrypting and decrypting documents

To encrypt a message meant for a recipient, you can use the --encrypt (or -e) GPG command. Here’s how you might encrypt a message for US-CERT using its GPG key:

gpg -o message.gpg -e -r us-cert@us-cert.gov message

The message is encrypted using the US-CERT public key (without a signature, but you can add the signature with the -s command).

When US-CERT receives the message.gpg file, the recipient has to decrypt it using US-CERT’s private key. Here’s the command someone at US-CERT can use:

gpg -o message --decrypt message.gpg

GPG then prompts for the passphrase to unlock the US-CERT private key, decrypts the message, and saves the output in the file named message.

If you simply want to encrypt a file and no one else has to decrypt the file, you can use GPG to perform symmetric encryption. In this case, you provide a passphrase to encrypt the file with the following GPG command:

gpg -o secret.gpg -c somefile

GPG prompts you for the passphrase and asks you to repeat the passphrase (to make sure that you didn’t mistype anything). Then GPG encrypts the file using a key generated from the passphrase.

To decrypt a file encrypted with a symmetric key, type

gpg -o myfile --decrypt secret.gpg

GPG prompts you for the passphrase. If you enter the correct passphrase, GPG decrypts the file and saves the output (in this example) in the file named myfile.

Monitoring System Security

Even if you secure your system, you have to monitor the log files periodically for signs of intrusion. You may want to use Tripwire (a good tool for detecting any changes made to the system files) so that you can monitor the integrity of critical system files and directories. Your Linux system probably doesn’t come with the Tripwire package. To use Tripwire, you have to buy it from www.tripwire.com. After you purchase and install Tripwire, you can configure it to monitor any changes to specified system files and directories on your system.

Periodically examine the log files in the /var/log directory and its subdirectories. Many Linux applications, including some servers, write log information by using the logging capabilities of syslogd or rsyslogd. On Linux systems, the log files written by syslogd and rsyslogd reside in the /var/log directory. Make sure that only the root user can read and write these files.

The syslogd configuration file is /etc/syslog.conf, and the rsyslogd configuration file (existing on many newer systems) is /etc/rsyslog.conf. The default configuration of syslogd generates the necessary log files; however, if you want to examine and understand the configuration file, type man syslog.conf for more information.

Securing Internet Services

For an Internet-connected Linux system (or even one on a TCP/IP LAN that’s not connected to the Internet), a significant threat is that someone could use one of many Internet services to gain access to your system. Each service — such as mail, Web, or FTP — requires running a server program that responds to client requests arriving over the TCP/IP network. Some of these server programs have weaknesses that can allow an outsider to log in to your system — maybe with root privileges. Luckily, Linux comes with some facilities that you can use to make the Internet services more secure.

Potential intruders can employ a port-scanning tool — a program that attempts to establish a TCP/IP connection at a port and then looks for a response — to check which Internet servers are running on your system. Then, to gain access to your system, the intruders can potentially exploit any known weaknesses of one or more services.

Turning off standalone services

To provide Internet services, such as Web, e-mail, and FTP, your Linux system has to run server programs that listen to incoming TCP/IP network requests. Some of these servers start when your system boots, and they run all the time. Such servers are standalone servers. The Web server and mail server are examples of standalone servers.

Another server, xinetd, starts other servers that are configured to work under xinetd. Some Linux systems use the inetd server instead of xinetd to start other servers.

Some servers can be configured to run standalone or under a super server such as xinetd. For example, the vsftpd FTP server can be configured to run standalone or to run under the control of xinetd.

In Debian, Ubuntu, and Xandros, use the update-rc.d command to turn off standalone servers and use the invoke-rc.d command to start or stop servers interactively. To get a clue about the available services, type ls /etc/init.d and look at all the script files designed to turn services on or off. You have to use these filenames when you want to turn a service on or off. For example, to turn off Samba service, type update-rc.d -f samba remove. If the service was already running, type invoke-rc.d samba stop to stop the service. You can use the invoke-rc.d command to stop any service in a similar manner.

In Fedora and SUSE, you can turn standalone servers on or off by using the chkconfig command. You can get the names of the service scripts by typing ls /etc/init.d. Then you can turn off a service (for example, Samba) by typing chkconfig --del smb. If the service was already running, type /etc/init.d/smb stop to stop the service. You can run scripts from the /etc/init.d directory with the stop argument to stop any service in a similar manner.

Configuring the Internet super server

In addition to standalone servers such as a Web server or mail server, other servers — inetd or xinetd — have to be configured separately. These servers are Internet super servers because they can start other servers on demand.

Type ps ax | grep inetd to see which Internet super server — inetd or xinetd — your system runs.

Debian, Ubuntu, and Xandros use inetd, and Fedora and SUSE use xinetd.

The inetd server is configured through the /etc/inetd.conf file. You can disable a service by locating the appropriate line in that file and commenting it out by placing a pound sign (#) at the beginning of the line. After saving the configuration file, type /etc/init.d/inetd restart to restart the inetd server.

Configuring the xinetd server is a bit more complicated. The xinetd server reads a configuration file named /etc/xinetd.conf at startup. This file, in turn, refers to configuration files stored in the /etc/xinetd.d directory. The configuration files in /etc/xinetd.d tell xinetd which ports to listen to and which server to start for each port. Type ls /etc/ xinetd.d to see a list of the files in the /etc/xinetd.d directory on your system. Each file represents a service that xinetd can start. To turn off any of these services, edit the file in a text editor and add a disable = yes line in the file. After you make any changes to the xinetd configuration files, you must restart the xinetd server; otherwise, the changes don’t take effect. To restart the xinetd server, type /etc/init.d/xinetd restart. This command stops the xinetd server and then starts it again. When it restarts, it reads the configuration files, and the changes take effect.

Configuring TCP wrapper security

A security feature of both inetd and xinetd is their use of the TCP wrapper to start various services. The TCP wrapper is a block of code that provides an access-control facility for Internet services, acting like a protective package for your message. The TCP wrapper can start other services, such as FTP and TELNET; but before starting a service, it consults the /etc/ hosts.allow file to see whether the host requesting the service is allowed to use that service. If nothing appears in /etc/hosts.allow about that host, the TCP wrapper checks the /etc/hosts.deny file to see if it denies the service. If both files are empty, the TCP wrapper provides access to the requested service.

Here are the steps to follow to tighten access to the services that inetd or xinetd are configured to start:

Use a text editor to edit the /etc/hosts.deny file, adding the following line into that file:
ALL:ALL

This setting denies all hosts access to any Internet services on your system.
Edit the /etc/hosts.allow file and add to it the names of hosts that can access services on your system.

For example, to enable only hosts from the 192.168.1.0 network and the localhost (IP address 127.0.0.1) to access the services on your system, place the following line in the /etc/hosts.allow file:

ALL: 192.168.1.0/255.255.255.0 127.0.0.1
If you want to permit a specific remote host access to a specific Internet service, use the following syntax for a line in /etc/hosts.allow:

server_program_name: hosts

Here, server_program_name is the name of the server program, and hosts is a comma-separated list of hosts that can access the service. You may also write hosts as a network address or an entire domain name, such as .mycompany.com.

next Using Secure Shell (SSH) for Remote Logins

Linux