Network Defense by Rik Farrow Cryptography is not the Ultimate Solution Several years ago, while helping to setup a firewall for a large communications company, the IS director wondered why they would even need a firewall within a couple of years. He assumed that by 1998 everyone would be using cryptographically protected communications, and firewalls would be unnecessary. During a recent computer security conference (the CSI Annual conference), someone asked a similar question: if we employ strong cryptography, will we still need firewalls? First, you will have noticed that we have not employed strong cryptography in most of our network applications. The IS director was being overly optimistic. And cryptographic solutions by themselves do not replace firewalls. In many ways, the use of encryption through firewalls makes security worse, not better. The use of encryption and authentication can improve network and host security. But there are many steps that must be taken, and done 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 itself. Substitution cyphers, where one letter or token gets substituted by another, were used by the ancient Greeks. Cryptography and the breaking of codes were critical factors in the naval, air and sea battles of World War II. If you have read about the Ultra project at Bletchly Park and the breaking of the German Enigma machine (or even watched the PBS program about Enigma), you will hopefully learn that even the strongest cryptographic solution of its time can be broken with enough time and effort. And through mistakes made by the users of the solution. Older cryptographic engines, like the Enigma, relied on the use of symmetric key cryptography: both the sender and the receiver used the same key, or machine setup. The simplest mechansim for a symmetric key cipher is to exclusive OR the text you want to hide with a key. When the end of the key is reached, you start with the beginning of the key again, as if the key were a wheel that was applied to the stream of data as it passed (see Figure 1). This method of using XOR provides trivially broken encryption. Some modern ciphers, like RC4, use the XOR mechanism, but use the key to make a much more complicated and changing "wheel" for the encryption. One big 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 U Boat (German submarine) provided a code book with information about which keys to use, and allowed the Allies to decrypt German naval messages until the code book was replaced. The solution to having to distribute keys came in 1975, when Whitfield Diffie and Martin Hellman proposed public key cryptography. Diffie and Hellman's scheme, later known as asymmetric key cryptography, permitted the use of two keys, one of which could be published openly and still allow secure, encrypted communications. In their scheme, anyone can know the public key without revealing the private key, as the two are mathemtically related but in a way that is very difficult to calculate (based on computing the discrete logarithm of large numbers). With asymmetric cryptography, two parties can encrypt their communications without having to securely exchange keys. The problem with asymmetric cryptography is that it is very slow, so slow as to make it practically unusable. The solution to this 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 SSL works in your Web browser and how SSH provides secure links. 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. And this is where PKI (Public Key Infrastructure) fits in, as a secure method for obtaining a person's or organization's public key with sufficient assurance that you are getting the correct key. Problems Given that we 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 is that not everyone has learned how to use cryptography correctly. Good examples of poor practice have to do with the generation of keys for symmetric encryption. 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" (RNG) are not really very random, as they are based on computer algorithms, which if you give them the same seed twice, will produce the same results. You can try the small Perl script in Listing 1 and prove this to yourself by providing the same seed twice. Netscape quickly produced a patched version that did not rely on the system's time as the seed for the RNG. Microsoft's PPTP has a different problem, but still relating to the choice of keys. In PPTP, the user's password is used to generate the initial symmetric encryption key, regardless of the number of bits Microsoft claims that they will use for encrypting data. So it matters little if you are using 40 bit or 128 bit encryption with PPTP, because the key used will be based on the same password in either case. If you used a six character password (say, "secret"), the PPTP key is derived from these six letters, the approximate equivalent to an eight bit key. Microsoft released a patched version of PPTP in August of 1998, but it is unclear whether the patch removes the dependence on the user's password for generating a key. These are only two examples of bad implementations of cryptography. There are also 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 emailing. In other words, anyone who received the email 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 (and some of those certificates are out of date). Firewalls Given the current state of the art implementations of cryptography, we would be foolish indeed to turn off our firewalls. The support does not exist yet, and probably will not for many years. If anything, encryption makes it more dificult for firewalls to secure your network. Without encryption, a firewall can check email attachments for viruses. With the attachment encrypted, the firewall cannot check for viruses. VPN solutions providing encrypting tunnels between organizations make it impossible for the firewall to control traffic between the organizations (unless the encrypting tunnel exits within the firewall, or on the outside of the firewall). Encryption is not useless. You should be using encryption to protect the confidentiality of any sensitive information that you transmit across any network that you don't control--including leased lines. Although communications companies are much more careful today, hacking began with breaking into phone company computers and switches. 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 inject packets that the server (or client) will accept as legitimate, allowing the eavesdropper to hijack your connection. 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 makes hijacking into a denial of service attack, rather than stealing your authenticated connection. Steve Bellovin, author of "Internet Firewalls" (see Resources), has suggested using IPSec to create distributed firewalls. 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 allowed by a centrally controlled policy. A distributed firewall provides better defense against internal attacks, as well as attacks that by-pass your firewall via extranets, encrypted tunnels, and PPP links. Cryptography has an important and growing position in Internet security, as well as a long way to go yet. Sadly, we already know how to use encryption safely, but it is the implementation that escapes us. The devil is in the details. Resources: Steve Bellovin's paper on Distributed Firewalls: http://www.research.att.com/~smb/papers/distfw.html. The ~smb/papers/ directories list other related research, and ~smb/talks/ for the talk that inspired this column. Counterpane Labs, http://www.counterpane.com/labs.html, includes easy-to-read papers about cryptography, including http://www.counterpane.com/whycrypto.html, an article about mistakes made when implementing cryptographic solutions and http://www.counterpane.com/pptp.html, the analyses of the implementation of PPTP. A Web page with information about the German Enigma machine, and how its was solved during WWII: http://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, an immense volume about the history of cryptography (search for this at www.amazon.com and find related books). Listing 1: The little Perl script named notrng.pl sets the seed for the random number generator to the first command line argument. When the same seed is used twice, the list of random numbers is identical. % cat notrng.pl #!/usr/bin/perl print "The seed was ", $ARGV[0], ". The first five 'random numbers' are:\n"; srand($ARGV[0]); for (1 .. 5) { print rand(100), "\n"; } % ./notrng.pl 104456 The seed was 104456. The first five 'random numbers' are: 21.240234375 11.7431640625 12.261962890625 25.86669921875 92.059326171875 % ./notrng.pl 104456 The seed was 104456. The first five 'random numbers' are: 21.240234375 11.7431640625 12.261962890625 25.86669921875 92.059326171875 %