A simple and open

By Larry Seltzer  |  Posted 2007-03-08 Print this article Print

standard"> I see this idea as being much in the tradition of OpenID, in that it solves a real-world problem in a very simple way. It should be extremely easy to implement, depending on how involved we get with the XML stuff. XML specifications often seem to get out of hand.

Its also in the tradition of OpenSSL, a program that made secure Web sites available to masses. Prior to OpenSSL, creating a secure Web site was an expensive process. Now, thanks to this free and open-source program, anyone can do all the basic PKI work. As Ive already said, OpenSSL will likely be the common way to implement the PKI behind Simple File Signing.

Im not the first to think of using PKI for file authentication. Microsoft long ago got sophisticated—perhaps too sophisticated—about this problem and created Authenticode, a digital signature system in which the file contains a signature that can prove that the file was not tampered with and shows the name of the publisher of the file, based on the certificate.

The trust in the Authenticode system rests in very large part on that publisher name. Microsoft has tools you can use to make your own certificates, and of course you could use them to create certificates that say you are "Microsoft Corp.," so that alone of course is not trustworthy.

The missing piece of the puzzle in Authenticode is that you need, for all practical purposes, to use a code-signing certificate issued by a trusted certificate authority, such as VeriSign. VeriSign does verify the identity of the organization buying the certificate, so I cant buy one that says Im Microsoft.

This system works really well, as designed, but there are two problems with it: Code signing certs are expensive—hundreds of dollars per year—and they need to be in order for CAs (certificate authority) like VeriSign to do the verification they do. Also, the company name can be somewhat ambiguous as a trust marker. See this old column of mine for an example of a sleazy developer slipping misleading company names through the literal requirements of the program. But I think the cost issue is the far more important one.

VeriSigns iDefense Labs has placed an $8,000 bounty on remote code execution holes in Windows Vista and Internet Explorer 7. Click here to read more. Also like OpenID, which has some excellent opportunities for spoofing, Simple File Signing is likely to be attacked. Im sure there will be attacks on the basic PKI, but whats more obvious is phishing. For instance, its not hard to see e-mails offering www.yes-we-really-are-paypal.com/yes-we-really-are-paypal.com.security-update.exe and an appropriate .sig file. The owner of that domain can set up keys to authenticate the malware he is pushing and it will come through as OK.

Remember, authentication isnt the same thing as trust. In this case, user would trust the file in part because they see and trust the domain name, which is central in Simple File Signing. The answer is for Simple File Signing clients to display the domain name prominently and, after doing a whois on it, the owner of the domain as well. This should raise the alert level for most people.

Clearly the system isnt perfect, but I think its a very useful one and has the potential for quick and wide implementation. Its worth pointing out that the key distribution system is not just useful for file signing. Inevitably other applications for it will come along. Perhaps the web server end of the system will become a standard component for Apache and IIS.

PKI has always been an underachieving technology because of high barriers to entry for cost and complexity. Simple File Signing can enable new growth for it where it is needed most.

In addition to Andrew Jaquith, Id like to thank John Levine and especially Paul Hoffman of the Domain Assurance Council, who listened to me and provided great feedback. Im sure Ill be working with them more in the future on this.

Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983. More from Larry Seltzer Check out eWEEK.coms Security Center for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEKs Security Watch blog.

Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel