Risky business: Keeping security a secret

The open-source movement argues that it's better because "lots of eyes can look at it and find the bugs." Those who favor proprietary software offer two counterarguments: The first is that a lot of hostile eyes can also look at open-source code--which, they say, is likely to benefit attackers more than anyone else. The second point is that a few expert eyes are better than several random ones; a dedicated organization with responsibility for the software is a better custodian than the many eyes of the open-source community.

There is probably some truth to the notion that giving programmers access to a piece of software doesn't guarantee they will study it carefully. But there is a group of programmers who can be expected to care deeply: Those who either use the software personally or work for an enterprise that depends on it.

If anyone has both the right and the need to study the code and be assured of its correct functioning, it is users. In fact, auditing the programs on which an enterprise depends for its own security is a natural function of the enterprise's own information-security organization.

Moreover, just because a program is open-source software does not mean that no one is responsible for it. The automotive industry provides a clear example: Before cars contained software, they were an "open-source" technology. Manuals and parts lists were available together with all sorts of after-market products for both repair and customization. A professional class of mechanics mastered the workings of cars and performed a function similar to the auditors of software programs. Look at it this way: A mechanic who checks your brakes is acting to ensure the correct functioning of a system essential to your security.

But all this does not mean that there is no group responsible for the car. At a level different from the mechanic, the manufacturer follows the repair history of each car model, then issues repair advisories and occasionally recalls a model for maintenance if a serious fault is found.

As for the notion that open source's usefulness to opponents outweighs the advantages to users, that argument flies in the face of one of the most important principles in security: A secret that cannot be readily changed should be regarded as a vulnerability.

If you depend on a secret for your security, what do you do when the secret is discovered? If it is easy to change, like a cryptographic key, you do so. If it's hard to change, like a cryptographic system or an operating system, you're stuck. You will be vulnerable until you invest the time and money to design another system.

It isn't that secrets are never needed in security. It's that they are never desirable. This has long been understood in cryptography, where the principle of openness was articulated as far back as the 1870s (though it took over a century to come to fruition). On the other hand, the weakness of secrecy as a security measure was painfully evident in World War II, when the combatants were highly successful at keeping knowledge of their cryptosystems out of general circulation but far less successful at keeping them from their enemies.

Today, at least in the commercial world, things are very different. All of the popular cryptographic systems used on the Internet are public. The United States recently adopted a new, very public system as a national standard and it is likely that before long, this Advanced Encryption Standard--based on an internationally accepted algorithm--will be used to protect the most sensitive traffic.

It's simply unrealistic to depend on secrecy for security in computer software. You may be able to keep the exact workings of the program out of general circulation, but can you prevent the code from being reverse-engineered by serious opponents? Probably not.

The secret to strong security: less reliance on secrets.

Whitfield Diffie, the co-inventor of public-key cryptography, is chief security officer and senior staff engineer at Sun Microsystems. He is co-author of "Privacy on the Line: The Politics of Wiretapping and Encryption," published by MIT Press in 1998.