Cryptography Tools for the Systems Administrator
Bruce Alan Wynn and Michael Carpenter
Recently, cryptography and crypto tools have received considerable publicity in technical forums. Much glamor is associated with this previously little-known topic, but once you peel back the flash and glitter, how important is cryptography to the casual systems administrator? What tools are available, and what can they do for you? What is the cost of implementing these tools, and how valuable are the benefits? In the following article, we will explore these and other questions. The History of Ciphers and Cryptography Cryptography has been around since the invention of writing and arose from a desire to keep secrets. A cipher is an algorithm that translates one word or letter into another. Most ciphers can be reversed, giving the original message. While ciphering a message will make it unreadable to the casual observer, some information about the encoded message will still be available: the number of words, the number of letters in each word, and possibly even the frequency of each letter. This makes ciphers easy to use, but also easy to break. Around 400 B.C., the Spartans developed the scytale, which consisted of a rod around which a piece of "paper" was wrapped. Text was written on the paper, and when the paper was removed from the rod, all that appeared on the paper was a string of meaningless letters. To decode the message, you had to use a rod of the exact diameter as the rod on which the message was written. Julius Caesar developed what has become known as the Caesar Cipher. He wrote out all letters of the alphabet, and beneath them he wrote the alphabet again, but shifted it three letters. Thus, the letter A became D, and E was substituted for the letter B, etc. Many ciphers that we used as children were based on a type of Caesar Cipher. Many UNIX systems contain an encryption program called "ROT13." In this program, the letters are shifted 13 places. The letter M becomes the letter Z, and the letter B is the letter O. The problem with this cipher is that if a file is encrypted twice with ROT13, it becomes the original plaintext file. ROT13 is definitely not intended to be secure. Because ROT13 doesn't hide the frequency of the occurrence of the letters, an expert could break the code easily. Encrypting a message hides information about the message itself, and may or may not be reversible. One of the most common examples of encryption in a UNIX environment is the login password. Whether stored in /etc/passwd or a shadow password file, the actual string the user types during login is not stored. Instead, when the user first sets their password, an encryption algorithm is applied and the encrypted password is stored on the system. When somebody attempts to log into an account, the password they type is encrypted and compared against the stored encrypted password: it is never decrypted. Making Encryption Better The algorithms used to encrypt data can be loosely classified into two types: weak and strong. In general, these terms describe how difficult it would be to "break" an encryption. A weak algorithm is one that is easily breakable or compromised. The Caesar Cipher is an example of a very weak cipher. The advantage of weak algorithms are that they are very easy to implement, and usually the encryption process can be done very quickly. Software vendors may use a weak encryption algorithm merely so they can say they use encryption - be careful about purchasing software just because it claims to use encryption! If an algorithm is strong, then it cannot be compromised with either current or future resources. Even if an algorithm is theoretically breakable but would take more time than since the dawn of man to break, it is still considered a strong algorithm. The best feature of a strong algorithm is that it is difficult to break. If you are using strong encryption, someone will be less likely to decrypt your data without your key. Note that the terms "weak" and "strong" in this context are highly relative. What makes an algorithm strong is that there is no known mathematical method of decrypting data encrypted with that algorithm without the key. In the past, the Data Encryption Standard (DES) was considered a strong algorithm. When methods were discovered that would allow a person to decrypt DES-encrypted data without the key, the DES algorithm lost much of its "strong" status. The amount of time required to break a cipher is called the "work factor." It is reported as an order of magnitude. If a cipher has a work factor of 264, then it will take 264 computations to break it. The factor remains constant, but as we have seen over the past few years, computing power does not. What is considered secure today, by tomorrow's standards may be as easy to crack as the Caesar Cipher. Part of what makes the Caesar Cipher easy to crack is the fact that once you know the "key" (i.e., shifting each letter three positions), you know the cipher. The cipher could be made more complex by varying this "key" from one message to the next, or even from one line or sentence to the next. Even the UNIX password encryption would be relatively easy to break if it always used the same key for each encryption. One could simply make a list of all possible combinations of valid password characters and the encrypted string associated with them. Then, by looking at the encrypted password on the system and consulting your list, you would know what to type during the login process. As a matter of fact, the UNIX operating system varies the encryption key each time it generates an encrypted password. The first two characters of the encrypted password are not part of the encrypted password per se: they are the encryption key. Thus, having approximately 100 printable ASCII characters available to make up this key, we extend the number of encrypted passwords from one per plaintext password to 100 100, or 10,000, per plaintext password. This makes it much more difficult to generate a list of all plaintext passwords and their encrypted values. The Key Exchange Dilemma Let's assume we've come up with a wonderful encryption algorithm. We've implemented a variable key so that the algorithm cannot be easily broken. But now how do we get the encryption key to the message recipient? How do we know that the key arrived at the destination uncompromised? In the past, many governments employed couriers to transport a list of keys. These lists were placed in a briefcase handcuffed to the courier. If the courier arrived at the destination intact, it was assumed that the list was uncompromised. A failure in delivery was an indication to the originators that they should not use the keys on that list. Encryption algorithms that use only this single encryption key - and therefore fall prey to the key exchange dilemma - are known as private key encryption algorithms. Obviously, in the electronic age, this method of exchanging keys will not scale. Some other method must be used. Public Keys Complex encryption programs today employ what is known as Large Number Theory. Large number theory is a belief held by most mathematicians that if a sufficiently large number didn't have properties of a random number, then mathematicians would have figured out the other properties the number holds. Many cryptographic attacks assume that numbers have certain characteristics. If a very large number is picked at random, it is extremely hard to find the number's properties. It is much easier to figure out the properties of a small number very quickly. The programs in use today rely on very large prime numbers to encrypt documents. The theory behind this is that if a number is big enough, it can be thought of as a random number. Let's say we want to find the factors of 435. We would immediately notice that it's divisible by 5, and perhaps we'd notice that it's also divisible by 3. Factoring these out leaves us with 29, which we know to be prime. Now suppose we want to factor a larger number, such as 1517. This is not easy, because 1517 has only two nontrivial factors - 37 and 41, both of which are prime. Most strong encryption algorithms use the product of two large prime numbers in determining their key, because there is not currently a simple means of factoring besides trial and error or exhaustive attempts. This method allows one of the keys to be publicly available; messages encrypted with this "public" key can only then be decrypted with the unadvertised, or "private" key. Encryption Utilities In the past few years, an encryption package called Pretty Good Privacy, or PGP, has come into rather widespread use. This software was created by Phil Zimmermann. In PGP for example, using random prime numbers and a pass phrase in a technique called key crunching generates a key. Key crunching converts text or numbers from easily remembered strings to a bit string. To ensure that the key will be random, the pass phrase must be sufficiently long enough. One theory is that you need one character in the pass phrase for every bit required in the key. For example, for a 128-bit key, you would need a pass phrase 128 characters long. To increase the randomness of the key, use the entire ASCII character set. This allows the user to create a method to encrypt sensitive data that is reliably secure. A very informative book on this subject is available from O'Reilly & Associates, entitled PGP, Pretty Good Privacy. Digital Signatures The most obvious use of encryption is to keep other people from reading your document. But encryption has also been used to implement a means of digitally "signing" a document. To use encryption as a digital signature, the contents of the document are used to generate the encryption key. This key is appended to the document itself. If the reader chooses, he or she can check this signature against the contents of the file; if they match, the reader knows that the contents of the file have not been changed since the signature was placed there. PGP supports the digital signature feature. Encryption Algorithms The most commonly used encryption algorithm is the RSA algorithm. The mathematics of this algorithm are fairly straightforward, and are described in detail in the O'Reilly PGP book. RSA is the first successful public key encryption algorithm designed in the United States. PGP also uses another encryption algorithm: the data is encrypted using a European algorithm called IDEA. The IDEA algorithm uses a private key, which PGP generates randomly at encryption time. To exchange this private key, PGP then encrypts the IDEA encryption key using RSA. Another commonly used algorithm is the Data Encryption Standard, or DES. DES uses a 56-bit encryption key. Although widely used in the industry, DES is known to be crackable using conventional computers, although it would take about one year to exhaustively try all possible DES keys. Encryption for Authentication One security problem that systems administrators face is the transfer of plaintext passwords across computer networks. Recently, we ran a publicly available piece of software that allowed us to view information from the packets on our network. From another machine, we used telnet to log into the machine we were monitoring. When the password was entered during login, we were able to see each character as it was sent across the network. The alarming part is that this software is readily available. So, any time you are entering a password across the network, somebody could be watching it. There are a number of ways to get around this problem, including "one-time" passwords, so that even if somebody detects the password you use, they cannot use it for a future login. A better solution is called "authentication." The general idea behind authentication is that once you have successfully identified yourself, remote machines no longer challenge you for a password. A primitive version of this idea was implemented with the UNIX "r" commands - rlogin, rsh, rcp, etc. Placing the name of "authorized" hosts in a file in your home directory indicates to these commands that they need not prompt you for a password. Unfortunately, this mechanism is easily compromised. Two recent additions to the authentication arena are kerberos and the Secure Shell (SSH). kerberos is a series of library functions that can be incorporated into applications; SSH is a standalone application. kerberos To use the kerberos authentication, an application must be designed and compiled to use the kerberos library. These applications are then said to be "kerberized." Kerberos allows the administrator to configure which kerberized applications are available to a given user. Users can then invoke applications on remote machines without supplying a password for each invocation. In general, when a kerberized client wants to access a kerberized application, it verifies that it is allowed to do so with a kerberos server. The kerberos server issues a "ticket" stating that the operation is allowed. The kerberized client then presents this ticket to the application. The application examines the ticket, verifies it, and then provides the requested service. One important feature of the kerberos software is that the tickets are generated using the current time. This requires that all machines involved in a ticket exchange are synchronized. The benefit of this is that an old ticket may not be presented at some future time; the client must request a new ticket each time it uses a kerberized application. Kerberos supports the concept of "realms," which are logical areas of authentication. For example, you might define one realm that includes your engineering staff, and another that includes your accounting staff. The engineering realm might have access to the CAD software, and the accounting realm might be granted access to the spreadsheet software. Additional information about kerberos and instructions for obtaining the software itself is available from:
ftp://athena-dist.mit.edu/pub/ \ kerberos/README_KRB5
SSH The SSH is less powerful than kerberos, but easier to implement. It provides the same functionality of rlogin and rsh, with the added feature of public key (RSA) encryption of transmitted data. Developed at Helsinki University of Technology, Finland, SSH is currently available at many ftp sites. For the most recent information, look at:
http://www.cs.hut.fi/ssh
Encryption for Data Without a doubt, the most common desire for encryption in practice is that of electronic mail. Because any systems administrator can read your mail, the only way to safeguard it is to encrypt it. A number of mail tools are becoming available that implement encryption to one degree or another. Pronto Secure Pronto Secure is a email program from CommTouch (www.commtouch.com). The program features encryption and decryption, allows key registration and certification, automates the exchange of locks and certificates, and makes using PGP almost invisible to the user. It also allows automated key exchange between Pronto Secure clients. For more information on Pronto Secure, see:
http://www.commtouch.com/secnon/ secintl1.htm
PGPmail Pretty Good Privacy, Inc. has recently released PGPmail version 4.5, available for Windows 95 and Windows NT. Developed by the people who brought us PGP, PGPmail makes full use of the power of PGP to safeguard your mail. For more information on PGPmail, see:
http://www.pgp.com/products/ \ PGPmail.cgi
Under the name of ViaCrypt, PGPmail is also available for more than a dozen UNIX platforms:
http://www.pgp.com/products/ \ viacrypt-products.cgi
PGPmail also includes a plug-in for Eudora 3.0 and compatibility with Netscape Mail. Conclusion Up-to-date information about developments in the encryption world can be obtained through a number of special interest groups. The most popular encryption SIG is CypherPunks; they can be contacted via their Web site at:
ftp://ftp.csua.berkeley.edu/pub/ \ cypherpunks/Home.html
In this article, we asked a number of questions about the usefulness of encryption in a standard environment. As described above, the actual software tools that use encryption are few and are still in their infancy. Installation of tools such as PGP and SSH are fairly straightforward, but they require some user training. Kerberized applications must be specifically written and built to use the kerberos libraries. Whether this cost of implementation justifies the added security depends on your environment and on how strongly your users feel they need that added security. How necessary is encryption in daily life? The answer depends upon both the value of your data and your estimate of the likelihood that somebody might gain unauthorized access to it. Businesses are beginning to encrypt proprietary data to protect it from competitors. Electronic mail users are using encryption to feel "safer" about their privacy. Only you can decide how necessary encryption is for you.
About the AuthorBruce Alan Wynn and Mike Carpenter are members of the Pencom Systems Administration team. Bruce is the manager of the PSA University training program, and Mike is the manager of the PSA AnswerDesk. They can be reached at: wynn@psa.pencom.com and mikec@psa.pencom.com, respectively.
|