Crypto 101

Kurt Seifried

Cryptography is the science (some say art) of keeping data secret. Cryptography allows you to prove identity, or conceal identity, verify the integrity of data, encrypt the data, and a variety of other services that are increasingly critical in the modern world. No one would even consider sending their credit card number over the Internet unencrypted, yet it is routine for administrators to log onto remote systems without any protection with their passwords moving around in plain sight. People send and receive email, not knowing who it is actually from, or if it has been tampered with or read by a third party. Most people will cite complexity or lack of options when asked why they don't use cryptographic software more often. Luckily, this situation has changed a lot in recent years.

There is a large quantity of good cryptographic software now available for free and with OpenSource licenses (BSD, artistic, GPL, etc.) making deployment simpler. This article covers OpenSource cryptographic software for several reasons:

• Code auditing is possible, for the truly cautious.
• Fewer restrictions on use make deployment easier.
• There is usually no cost, which makes licensing a simple matter.

In general, the main obstacle to deploying OpenSource software will be managers who may have a dim view of OpenSource “non-supported” software. Several benefits you can point out are the cost factor (none), availability (high), and response time on security problems (fast). The other alternative is to “just do it” and hope that you can placate your boss when (or if) he or she finds out.

Background

Cryptography is based on math and, more specifically, on sets of mathematical problems and operations that are difficult to solve. Various cryptographic systems exploit this property so that if you have the complete equation (i.e., all the terms, which may include a very large number), you can easily solve it and decrypt the message. If you do not have the data, you must solve the equation by trying out all the possibilities. When using numbers in the range of 2 to the power of 1024, this can take a while.

There are two main families of algorithms. One uses a symmetric key (i.e., both parties must possess the key, which is used to encrypt and decrypt data. The other uses asymmetric keys, also known as public and private key cryptography. Symmetric key cryptography is useful but hindered by the simple fact that you must securely get the key to the other person and make sure no one else grabs a copy of it while in transit. Public key cryptography is more useful for large systems because the person you wish to communicate with only needs to get a copy of your public key, which they can then use to encrypt data to send to you or to verify data that you have signed with your private key (also known as the secret key).

In a nutshell, public and private key encryption usually means you can encrypt data with one key that you can decrypt with the other key. If you have my public key, you can encrypt data that only I can decrypt with my private key, or by guessing every possible key and trying them all. Additionally, I can encrypt the data I send to you, and you can decrypt it with my public key, so that you can verify that the data was sent by me. This is referred to as “signing data”.

The next major problem is establishing that the person you want to talk to is actually the person you end up talking to, and that the communications have not been intercepted or modified (called a “man-in-the middle” attack). This is a very difficult problem because no secure channel exists to communicate through. This is where algorithms like RSA, DSA, and Diffie-Helman come into play. The most popular of these is RSA, named after its three inventors' initials, and has become the standard for most key exchanges. Unfortunately, it is patented in the United States. Basically, it is a method for exchanging keys securely so that a man-in-the-middle attack has a small chance of succeeding. A man-in-the-middle attack occurs when two parties (Alice and Bob) try to establish a secure connection, but another party (Charlie) intercepts it and impersonates Bob to Alice or Alice to Bob. Alice and Bob think they are talking to each other, when in fact they are talking to Charlie, who then passes the possibly altered message along. Needless to say, if you are conducting a credit card transaction or exchanging corporate R&D plans, you do not want this to happen. For the real details about RSA and other algorithms, please see John Savard's “A Cryptographic Compendium”.

Caveats

The current status of laws regarding cryptographic use, import, and export is a mess in many countries. Generally, the import and use of cryptographic software is okay in most places, and export will not concern most companies (unless you are a multi-national and need to deploy it company-wide). In this case, you need to consult your lawyers. For example, Canada's export laws have a specific exemption for “public domain” software, but the United States does not. The recent “relaxation” in U.S. export laws is far from perfect, and you should consult a lawyer first. However, the new crypto export regulations in the United States do make allowances for companies deploying encryption for internal company communications.

The other major difficulty is the RSA patent in the United States, which expires September 20, 2000. Unless your company has an RSA license (and owning a copy of a secure Web server with licensed RSA components does not count) you will need to compile any software that use RSA with RSAREF (an old RSA reference implementation that is freely available). There was recently a buffer overflow found in RSAREF that resulted in some problems, so make sure you are using the latest one. RSAREF cannot be used for any activities that generate revenue, so you cannot use it for an e-commerce server, for example, and there are some gray areas with universities, which charge students (however indirectly) for access to computing resources. Several universities have decided that using RSAREF would be in violation of its license. ssh is now giving ssh 2.1 away free to universities; the exact details will probably have been worked out by the time you are reading this article.

Common Problems

Most computer networks suffer from a variety of common problems that encryption can solve. One of the most common is unencrypted logins, and unencrypted sessions. In most networks, running a password sniffer will result in the majority of the username and password pairs being copied off the network in a few days. Common services such as telnet, ftp, POP, and IMAP, all send usernames and passwords in text format, which attackers can easily read. The next biggest item (and my personal pet peeve) is unsigned and unencrypted email. People now send email with extremely sensitive information and imagine the hassle of trying to prove that an email asking for kiddie-porn was not from your account. All of these issues involve users, so it's important to sell the them on security. In some cases, this will be relatively easy (like securing POP and IMAP), and in some cases not so easy (like replacing telnet with OpenSSH). You can disable the insecure service and force users to use the secure one, but this is usually a bad idea, as it can lead to a backlash. Another major factor to consider is the added load that encryption will add to a server. There are a variety of cryptographic accelerator cards that can be used, but generally speaking they are still primarily aimed at secure Web encryption (https). Test server load carefully before deploying any encryption.

Remote Administration

The default set of tools available for UNIX administrators (such as telnet, RSH, etc.) are not secure enough for most modern network environments. The alternative is OpenSSH, a subset of the OpenBSD project and has been ported to a variety of other operating systems as well. OpenSSH is fully compatible with ssh protocol version 1, but not yet compatible with ssh protocol version 2 (which is commercially licensed, however there is a program to provide universities with SSH 2.1 for free). All of the Windows clients (ssh protocol version 1) I have tried are compatible with OpenSSH. The ssh protocol allows you to encrypt the session with a variety of algorithms (also called ciphers -- idea, blowfish, etc.), making it much more secure than traditional tools. OpenSSH also has the ability to forward ports, and it can connect to another server via ssh and establish a secure “tunnel”. You can check email via POP (port 110, tcp) securely, since the session would run over an ssh connection. The manual page for ssh describes this, and most of the free Windows ssh clients support this functionality, but you will have to educate your users on how to use it.

You may encounter problems using the 1.2.x ssh client when trying to connect to an OpenSSH server, as OpenSSH does not implement all the ciphers that ssh uses, since some are patented. You might get a “Selected cipher type idea not supported by server” or something similar, which means the default cipher (encryption algorithm) it tried to use is not supported by the other end. To get around this, you must specify a different cipher -- blowfish for example:

$ssh -c blowfish hostname.example.org

#./configure ; make ; make test ; make install

#./configure ; make ; make install

/usr/bin/ssh
/usr/bin/ssh-add
/usr/bin/ssh-agent
/usr/bin/ssh-keygen
/usr/sbin/ssh

Remote Mail Access

The previous section, remote administration, is actually one facet of a larger problem -- remote authentication. The majority of Internet users access restricted data (email, Web sites, corporate ftp sites, etc.) and are required to authenticate to the remote site. This is usually accomplished with a username and password, because it uses one of the cheapest methods of authentication and requires no special equipment (such as a smart card or token). Unfortunately, most systems that use a username and password to authenticate the user do so insecurely. When retrieving email remotely, you are probably using POP or IMAP, and thus your username and password are sent over the network plain text. The following is a packet dump (modified, of course) of an IMAP session:

`g0@e
`g0@e
* CAPABILITY IMAP4 IMAP4REV1 NAMESPACE IDLE SCAN SORT \
    MAILBOX-REFERRALS LOGIN-REFERRALS AUTH=LOGIN THREA
00B4 LOGIN "username" "qwertyasdf"
`g0@e
Pm;P
`g0@e

#tcpdump -i eth0 port 143 -w output

0001 LOGIN "userjoe" "PaSsWoRd"
0001 OK LOGIN completed
000E LOGIN "userbob" "drowssap"
000E OK LOGIN completed
000K LOGIN "usersue" "love"
000K OK LOGIN completed

The good news is that you can secure these services using the same encryption methods used for secure Web browsing. The bad news is that if you are in the United States, you may not be able to legally use SSL with RSA or RSAREF. SSL (secure sockets layer) allows two computers to establish an encrypted session for pretty much any tcp protocol (WWW, POP, IMAP, ftp, etc.). It also allows you to authenticate the server to the client, and optionally the client to the server, before the username and password are even used (or any other authentication scheme for that matter). SSL uses certificates, or pieces of digital identification that include things such as the server name, organizational name, etc., that have been signed by a trusted party (such as Verisign, or your corporate IT department). The client machine needs software (such as Outlook, Netscape, or Eudora) that supports POP or IMAP over SSL. (Netscape 4.7 for Windows supports IMAP over SSL, but not POP over SSL). The primary advantage of using SSL over ssh port redirecting is that most mail client software packages have built-in support and can be easily configured rather than installing an ssh client and trying to train users.

Most POP and IMAP servers do not support SSL. To SSL wrap a service, you will need SSL software (such as OpenSSL) and a program to act as the wrapper. The simplest answer is to use a program like “stunnel”, which handles the SSL session and then communicates locally with the POP or IMAP server. It effectively acts as a proxy, wrapping itself around the unsecured service. The installation of OpenSSL and stunnel are relatively straightforward. You download source or binary packages, compile if necessary, and install, followed by reconfiguration of inetd. inetd is typically used to listen for connections, such as POP, IMAP, and ftp, and when it sees a connection request, it starts the appropriate daemon, such as IMAP, which handles the request. You might also need to add a line for SPOP (port 995, tcp), or SIMAP (port 993, tcp) to /etc/services:

simap           993/tcp
# IMAP over SSL
spop3           995/tcp
# POP-3 over SSL

simap stream tcp nowait root /usr/sbin/stunnel imap -l imap

RANDFILE = stunnel.rnd
[ req ]
default_bits = 1024
encrypt_key = no
distinguished_name = req_dn
x509_extensions = cert_type
[ req_dn ]
countryName = Country Name (2 letter code)
organizationName = Organization Name (eg, company)
0.commonName = Common Name (FQDN of your server)
[ cert_type ]
nsCertType = server

#openssl req -new -x509 -days 365 -config stunnel.cnf -out \
  stunnel.pem -keyout stunnel.pem

Jan 17 03:09:16 mail stunnel[4727]: /usr/certs/stunnel.pem: \
  No such file or directory (2)

-----BEGIN RSA PRIVATE KEY-----
[encoded key]
-----END RSA PRIVATE KEY-----
[empty line]
-----BEGIN CERTIFICATE-----
[encoded certificate]
-----END CERTIFICATE-----
[empty line]

Signing and Encrypting Email

Email is one of the killer applications on the Internet. Security solutions for email exist, but many people do not bother to use them. A perfect example is a recent email I got from deraadt@cvs.openbsd.org (Theo de Raadt, leader of the OpenBSD project) with a rather strange request to change some URLs from www.openssh.org to www.openssh.com. Since the email was not digitally signed, I could not be sure it was actually from Theo de Raadt. So how was I to verify that it came from him? I first had to get his public key (not a public key server, anyone can upload keys to them). In this case, the OpenBSD Web site had a copy of his key. All it took then was to encrypt a response to him that only he would be able to decrypt using his public key, and await a reply confirming the request, which I got shortly thereafter.

Signing and encrypting email is easy. The real headache is in getting the other person's public key. There are very few reliable sources from which to retrieve them. The whole problem boils down to one of trust -- since some people lie, how do you know that the key you are retrieving isn't a result of such a lie? For example, I can upload a key for “Joe Smith, joesmith@example.org”. Most public key-based cryptographic systems employ key signing, which is the signing of a user's public key with a trusted private key. This signature can then be verified with the corresponding public key. The simplest example of this is X.509 certificates. You create a private and public keypair, send the public key along with some personal information that supposedly proves who you are to a trusted third party (such as Verisign). The third party verifies the information, signs your public key, and sends it back to you. Thus, when you use your private key to sign an email, the recipient can retrieve your public key and check that the key is actually associated with the email address used, and so on. This is what SSL is (SSL typically uses RSA-based X.509 certificates), except instead of signing or encrypting a block of text or data, you sign or encrypt a stream of text and send it. There is one significant limitation to X.509 certificates, however, and that is only one entity can sign a certificate.

PGP and GnuPG, on the other hand, allow multiple entities to sign a key. This means that I can get my employer and a friend to sign it. If someone downloads my key and happens to know and trust my friend, then they can choose to trust me. Or, if they know my employer, they can choose to trust that entity and by extension, my key (this is known as the web of trust). An X.509 certificate can only have one signature on it -- meaning you must use multiple X.509 certificates if you deal with multiple entities (say one to access systems at work, one to access your online brokerage account, one to sign general email with, and so on).

If you are running a UNIX-based platform, several of the mailers (notably pine and mutt) have support for PGP and GnuPG (pgp4pine, which also can use GnuPG, for mutt there is a good HOWTO document available). The links at the end of the article point to sites that cover the installation and configuration of such support in detail. I advise using GnuPG; it is unencumbered by patents or licensing restrictions, and since it was created in Germany (the German federal government has even donated $250,000 DM to fund it), there are no export restrictions on it. On major caveat, if you are using GnuPG or PGP on a multi-user server; be aware that anyone with administrative access (i.e., root) can \ copy your key files, run a keystroke logger, and get your passphrase. An attacker that gains access can also do this, or simply replace the GnuPG or PGP binary with one that emails the secret keys to a Hotmail account. It might be safe, or it might not be safe -- if you plan to use PGP or GnuPG on a server, be aware of potential problems like key compromise.

PGP is free for non-commercial use, there are U.S. and international versions available. If you need it for commercial use you can buy it, starting around $30 USD per copy (you get some additional goodies like PGPdisk). The install consists of running the executable file and is simple in the extreme. PGP has plug-in support for Eudora, Outlook (Express), and Netscape Messenger.

Summary

Encryption can be used to enhance network security at a very reasonable cost if you are willing to use some elbow grease (keyboard grease perhaps?). For those of you in the United States, some of these methods won't be readily available unless you purchase an RSA license (which costs a lot) or wait until September 20th for the RSA patent to expire. The major things to watch out for are increased CPU usage (especially with RSAREF) and making sure your users are prepared. The best way to get encryption into the enterprise is to start with a thin wedge; offsite users checking email and so on are a good start.

Bibliography

Cryptographic software solutions and how to use them: http://www.securityportal.com/research/cryptodocs/basic-book/

A Cryptographic Compendium:
http://fn2.freenet.edmonton.ab.ca/~jsavard/entry.htm

RSA Labs FAQ on patent issues: http://www.rsasecurity.com/rsalabs/faq/ \
6-3-1.html

Crypto Law survey containing most countries: http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm

Tools and Resources

Free SSH for universities: http://www.ssh.com/products/ssh/universities.html

Open ssh primary site: http://www.openssh.com/

OpenSSL primary site: http://www.openssl.org/

Zlib primary site: http://www.cdrom.com/pub/infozip/zlib/

ssh client for Windows, uses patented RSA components: http://www.chiark.greenend.org.uk/~sgtatham/putty.html

ssh client (compatible with Open ssh) written in Java: http://www.mindbright.se/mindterm/

stunnel mirror site: ftp://ftp.cryptoarchive.net/pub/ \
cryptoarchive/SSL/wrappers/

sslwrap primary site: http://www.rickk.com/sslwrap/

GnuPG primary site: http://www.gnupg.org/

PGP/GnuPG add on for pine:
http://www.rhrk.uni-kl.de/~lamm/pgp4pine/

PGP/GnuPG HOWTO for mutt: http://www.linuxdoc.org/HOWTO/ \
Mutt-GnuPG-PGP-HOWTO.html

PGP Freeware: http://web.mit.edu/network/pgp.html

PGP International: http://www.pgpi.org/

PGP Commercial: http://www.pgp.com/

Crypto packages for Red Hat Linux: ftp://ftp.redhat.de/pub/ \
rh-addons/security/i386/

Crypto packages for SuSE Linux: ftp://ftp.gwdg.de/pub/linux/suse/6.3/i386.de/suse/sec1/

Crypto packages for Debian GNU/Linux: ftp://ftp.ca.debian.org/ \
debian-non-US/dists/slink/non-US/binary-i386/

About the Author

Kurt Seifried is senior analyst for SecurityPortal and somewhat confused as to what that actually means. His primary interests are security, crypto, privacy, and sushi. He may be reached at: seifried@securityportal.com.