Cryptography Is Not the Ultimate Solution

Encryption can help secure your network, but don't throw out your firewall yet.

by Rik Farrow

On This Page

Network Magazine
Crypto Magic
Cryptography Problems
Firewalls Recommended
Resources

Network Magazine

Several years ago, while I was working with a large communications company to set up and configure its corporate headquarters firewall, the company's IS manager was pondering why his company would even need a firewall in a couple of years.

He assumed that by 1998 everyone would be using cryptographically protected communications, making firewalls unnecessary. During the 1999 Computer Security Institute (CSI) conference, someone asked me a similar question: If we employ strong cryptography, will we still need firewalls?

Yes. This is partly because we have not employed strong cryptography in most network applications. The IS manager was being overly optimistic about the implementation of encryption technology. In addition, cryptographic solutions by themselves do not replace firewalls; in some ways, the use of encryption through firewalls makes security less effective, not more.

It's true that the use of encryption and authentication can improve network and host security, but many steps must be taken, and taken correctly, before cryptography becomes part of a secure solution.

Crypto Magic

The history of cryptography goes back almost as far as the beginning of written history. The ancient Greeks used substitution ciphers, in which one letter or token was substituted for another. Cryptography and the breaking of codes were critical factors in the naval, air, and sea battles of World War II.

If you've read about the Ultra project at Bletchly Park in England that helped break Germany's Enigma code machine during World War II, you know that even the strongest cryptographic solution can be broken with enough time and effort—and through mistakes made by the users of the solution.

Cryptographic engines like the Enigma relied on the use of symmetric key cryptography, in which both the sender and the receiver used the same key or machine setup. A simple (and unsafe) mechanism for a symmetric key cipher takes each character to be encrypted and combines it with another value using binary arithmetic. When the end of the key is reached, you start with the beginning of the key again, as if the key was a wheel applied to the stream of data as it passed.

This method provides encryption that is easy to break. Some modern ciphers, like RC4, use the exclusive OR mechanism, but they use the key to make a much more complicated and changing "wheel" for the encryption.

One problem with symmetric key cryptography is that you must have a secure method for exchanging keys between participants. In World War II, the capture of an intact German submarine provided a codebook which let the Allies decrypt German naval messages.

The solution to key distribution came in 1975, when Whitfield Diffie and Martin Hellman proposed public key cryptography. Diffie and Hellman's scheme, later known as asymmetric key cryptography, permits the use of two keys, one of which can be openly published and still permit secure, encrypted communications. In their scheme, anyone can know the public key without revealing the private key, as the two are mathematically related, but in a way that is very difficult to calculate (based on computing the discrete logarithm of large numbers).

The problem with asymmetric cryptography is that it is so slow as to make it practically unusable. The solution has been to use asymmetric cryptography to exchange symmetric keys that are used with symmetric cryptography for encrypting lots of data. For example, this is how Secure Sockets Layer (SSL) works in your Web browser.

Finally, asymmetric cryptography can also be used for authentication. By encrypting a signature (often a checksum of a document) using a private key, anyone with access to the public key can verify that the signature belongs to the owner of the private key. This is where PKI fits in, offering a secure method for obtaining a person's or organization's public key with sufficient assurance that you are getting the correct key.

Cryptography Problems

Given that humans have had thousands of years to learn how to do cryptography correctly, why do we still need firewalls? There are several answers to that, with the first answer being that not everyone has learned how to use cryptography correctly. For instance, the generation of keys for symmetric encryption has often been poorly handled.

The Netscape Navigator browser had a problem with the keys generated for use with SSL. A system's current time was used as a "seed" value for generating random numbers to be used as the symmetric key. But Random Number Generators (RNGs) are not really very random, as they are based on computer algorithms. This means that if you give an RNG the same seed twice, it will produce the same results (see figure ). You can try the small Perl script in the figure and prove this to yourself. Netscape quickly produced a patched version that did not rely on the system's time as the seed for the RNG.

Microsoft's Point-to-Point Tunneling Protocol (PPTP) has a different problem, but one that still relates to the choice of keys. In PPTP, a user's password is used to generate the initial symmetric encryption key, regardless of the number of bits Microsoft claims that it will use for encrypting data.

Under this method, it doesn't matter if you're using 40-bit or 128-bit encryption with PPTP because the key will be based on the same password. If you use a six-character password (say, "secret"), the PPTP key is derived from these six letters, which is the approximate equivalent to an 8-bit key. The problem is that standard password cracking techniques, such as trying words found in a very large dictionary, would generally be successful in guessing the password, and thus the key. Microsoft released a patched version of PPTP in August 1998, but it's unclear whether the patch removes the dependence on the user's password for generating a key.

In addition to bad implementations of cryptography, there are weak implementations: for example, the use of 40-bit keys. A fast desktop system can try all possible 40-bit keys in about one day, making the use of 40-bit encryption unsafe. An even more amusing example was a software program that produced self-decrypting messages for e-mailing. In other words, anyone who received the e-mail message could "decrypt" it by double-clicking on the attachment.

And then there is the problem of PKI, or rather, the lack of a PKI. Without a functioning, universal PKI fabric, we cannot reliably and easily acquire the certificates containing public keys for persons or organizations we might wish to communicate with. Web browsers like Internet Explorer and Netscape Navigator include rudimentary support for PKI by including the certificates for some top-level Certificate Authorities (CAs), but some of those certificates are out of date.

Firewalls Recommended

Given the current implementations of cryptography, network managers would be foolish indeed to turn off their firewalls. In some cases, encryption makes it more difficult for firewalls to secure your network. Without encryption, a firewall can check e-mail attachments for viruses. If the attachment is encrypted, the firewall cannot check for viruses.

VPN solutions that provide encryption tunnels between organizations also make it impossible for the firewall to control traffic between the organizations (unless the encrypting tunnel exits either within the firewall or on the outside of the firewall).

This is not to say that encryption is useless. You should use encryption to protect the confidentiality of any sensitive information that you transmit across any network that you don't control—including leased lines.

Encrypting communications can also protect you against TCP hijacking. As an eavesdropper can acquire all the information necessary to spoof your packets, the eavesdropper can also inject packets that the server (or client) will accept as legitimate, leaving your connection vulnerable to hijacking. There are several commercial products that can do this as well as hacker tools, although none work reliably beyond the exchange of a small number of packets. Encrypting your connection transforms a hijacking attempt into a denial-of-service attack, which, while annoying, is better than having your authenticated connection stolen.

Steve Bellovin, coauthor of Firewalls and Internet Security (with William R. Cheswick, 2nd edition, Addison-Wesley Publishing), has suggested using IPSec to create distributed firewalls (see Resources). IPSec is a part of IPv6 (the next generation of IP) that has been retrofitted to IPv4 (the current version).

By using the authentication feature of IPSec, Bellovin suggests creating a firewall on every system in your network. Each system would only accept connections from systems that can produce an IPSec authentication, and only for those applications permitted by a centrally controlled policy. A distributed firewall provides better defense against internal attacks, as well as attacks that bypass your firewall via extranets, encrypted tunnels, and PPP links.

The distributed firewall relies on having a local CA to securely provide public keys. The central administration would not be absolute, as users who controlled their own systems could still misconfigure the local firewall by overriding the central administration. Bellovin's paper also suggests hybrid solutions that combine distributed firewalls with current technology: for example, protecting roving systems through the use of distributed firewalls installed on each system.

Cryptography has an important and growing position in Internet security, but improvements still need to be made. A correctly implemented cryptography solution can enhance your network security, but in its current state it is not a replacement for standard security measures. We already know how to use encryption, but it is the implementation that escapes us. The devil is in the details.

Resources

Steve Bellovin's paper on distributed firewalls is at https://www.research.att.com/~smb/papers/distfw.html. The ~smb/papers/ directories list other related research. See https://www.research.att.com/~smb/talks/ for several of Bellovin's talks.

Counterpane Labs at https://www.counterpane.com/labs.html offers easy-to-read papers about cryptography, including https://www.counterpane.com/whycrypto.html, an article about mistakes made when implementing cryptographic solutions; and https://www.counterpane.com/pptp.html, which is an analysis of the implementation of the Point-to-Point Tunneling Protocol (PPTP).

A Web page with information about the German Enigma machine, and how it was solved during World War II, is located at https://www.gl.umbc.edu/~lmazia1/Enigma/main.html.

The Codebreakers: The Comprehensive History of Secret Communication from Ancient Times to the Internet, by David Kahn, is an immense volume about the history of cryptography. You can find it at https://www.amazon.com.

Rik Farrow is an independent security consultant. His Web site, https://www.spirit.com , contains security links and information about network and computer security courses. He can be reached at rik@spirit.com.

The above article is courtesy of Network Magazine. Click here to subscribe to Network Magazine.

Copyright © 1999, Miller Freeman Inc. All rights reserved

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice.

Click to subscribe