Information Security News mailing list archives

Perspective: Decrypting the secret to strong security


From: InfoSec News <isn () c4i org>
Date: Fri, 17 Jan 2003 00:38:32 -0600 (CST)

http://news.com.com/2010-1071-980462.html

By Whitfield Diffie 
January 16, 2003, 4:00 AM PT

Is open-source software better for security than proprietary software? 

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.



-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomo () attrition org with 'unsubscribe isn'
in the BODY of the mail.


Current thread: