Book review: Secrets and Lies by Bruce Schneier

After writing a wonderful book on Applied Cryptography, Bruce Schneier lost his faith in mathematics. This loss of faith came from looking at truly applied cryptography, namely looking at actual source code. This code so scared him that he wrote a book saying that cryptography is not The Answer(tm). I beg to differ.

He thinks real code should scare you so much that you should hire his company on continuously monitor your computer. Not a onetime vetting -- you should pay him every day for the rest of eternity. Not a bad racket.

The key points he makes are as follows:

There are about 5 - 15 bugs per 1000 lines of code.
Software has been doubling in complexity and size every year or two.
Windows NT has 35 - 60 million lines of code and hence about 100k bugs.
Therefore no modern product will every actually be secure.

Modern software will generate new bugs at a faster rate than even the "many-eyeballs" of open source can squash them.

But code doesn't have to be written this way. You can put all of your risky code in a small enough package that it could be checked for errors. The word kernel comes to mind. :-) But, he also says that Linux suffers the same problem that MS has. Unfortunately, I don't know the kernel well enough to comment on how much it has grown and he doesn't provide data on the growth of Unix kernels. Somehow I think this absence of information might reflect the fact that the current Linux kernel is not 1000 times bigger than say a Solaris kernel of the early 80s.

But under Linux, is even counting the lines of code a good measure? Somehow I think the kernel is modular enough so that if I load a new PCMCIA module, it wouldn't automatically be given rights to read and write to arbitrary files on the system. Please correct me if I'm wrong, and I'll sleep much less well at night. So not all the code in the kernel should be counted as being the same. (Oops! I've been corrected that this paragraph is incorrect. But, I've also been told not to lose sleep over it.)

I would be much happier with his analysis if he had looked at contrasts between sendmail (which is notoriously buggy) and qmail (which doesn't appear to be as buggy). The software point is that the dangerous code in qmail is all in one program--and that program doesn't trust any of the other pieces that make up qmail. So if that part is actually programmed bug-free, then there shouldn't be ANY possible bug in the rest of the code that can undermine security. This is good design. Almost any line of the sendmail program could undermine the security of the system. This is a truly a monolithically bad design.

To list another example, almost all of current open source pgp (namely gpg and its supporting material) uses gpg for the actual encryption and some other program for the viewing. So no matter how stupid the viewing program is, it is impossible for it to undermine security. (OK, it could send a copy of the plain text after it sends a copy of the encrypted message--but that would be a easy bug to catch.)

Even viruses like the ILOVEYOU worm in a hopelessly insecure operating system should be fairly easy to avoid. If you simply had Visual Basic always run in something equivalent to a change-rooted environment, it would have been impossible to write such a virus. Whether this could be done in windoz isn't the issue--instead the point is that people have known about this sort of problem for years and there has been a simple fix for years.

In his defense, he does seem to spend most of his time working in the MS world. That he worries about someone running a game server on their machine without having vetted all of the code would be a very rational worry in MS. But, there are ways this could be done under Linux that would maintain total security of the machine it ran on without looking at even one line of source code (run the program as a regular user in a chroot environment sounds safe to me).

So I see the picture something like this.

Cryptography is not a solution to all problems:
- Digital cash probably won't catch on.
- Smart cards probably won't ever work.
- All the fancy algorithms for voting and sharing information will never replace the voting booth.
- Playing poker will probably use a trusted intermediary instead of a cryptographic protocol.
Cryptography can solve some things: SSH, GPG and VPNs all work.
But, the key reason a system will be cracked into is not new mathematics but bad coding.
There are ways of coding (see Lakos for many good ideas) that will lead to secure programs.
Users will always be a weak link, but a good system (say Linux) should only compromise what that user had access to and not the whole network.

Conclusion

Schneier is incorrect when he says that security is a process. Instead, security is a solvable software engineering problem. In fact, I think a few small pieces of it have actually been solved. I think mail handling has been solved (qmail) and telnet has been solved (ssh2 with public/private keys). Certainly serving static web pages is solved (apache).

Keeping users from getting the root access should be a solvable problem, but I don't know if it is currently solved or not on Linux systems. Once that is solved, serving CGI scripts, running arbitrary servers, downloading arbitrary code off the net and running it on your local machine should all be safe things to do. (Now I don't think the automatic updates to GNOME is going to pass security muster anytime soon.)

So let me make a statement that most clearly separates Schneier's position from my own. Consider the following two systems:

A Linux system running ssh2 and qmail that is never patched. Total passive management. (Of course the ssh2 would require public key/private key pairs instead of passwords.)
An NT system (or whatever is the latest and greatest MS product) that has an active administrator who installs all MS patches within 24 hours of their release and upgrades to the newest version whenever it comes out.

Which do you think has a higher chance of being secure over the next few years? Schneier argues that active management is the only way of providing reasonable security, so my strawman version of him would pick the NT system. I think the Linux machine would probably be safe for 10 years. (I'd go longer, but don't trust the key length of ssh2 to protect against all new mathematics and hardware past about 10 years.)

If you went with NT, read Schneier's book. He will give you good arguments to believe that active management is the only answer. If you went with a limited Linux system, then join the open software movement and see if we can add more features to the Linux box without compromising security.

Last modified: Sat Apr 12 09:06:28 2003