A Racket's Brewing in the Code Signing Cert Business

By Larry Seltzer  |  Posted 2008-03-03 Print this article Print

Corrected: If code signing certificates are free or cheap they lose some of their value, but that doesn't mean they're better if they're more expensive.

EV-SSL certificates have been available for about a year. The absolute numbers of them are low, but the growth rate looks good on a line graph and it's not like everyone is supposed to have them.

They're a good thing I think, although they're less about combating phishing than inspiring confidence in genuine sites. VeriSign even has a new Coen Brothersesque marketing campaign for them, No More Abandoned Carts, which -very subtly-promotes EV certificates as a way to keep customers from abandoning carts.

But what about code signing certificates? I've long been a qualified fan of code signing certs. If you have the proper perspective on them, they can provide valuable information that you can use to assess whether a program file is trustworthy.

Of course you can't blindly trust a program just because the file is signed. By whom is it signed? Is the signing certificate issued by a trusted authority?

One problem with this system was demonstrated recently with some malware written up by Sunbelt Software in this blog entry. The interesting part of it is that the malware was digitally signed. The certificate used to sign it was issued by the UserTrust network, which is run by genuine certificate authority Comodo (the specific name is UTN-USERFirst-Object).

Comodo revoked the certificate shortly after it became clear that it had been used to sign malware. It's uncommon, but this was a certificate sale that had survived an actual identification check. The buyer lost their certificate for having violated terms of service.

Two things that make code signing certs less accessible to hackers are that vendors like Comodo and VeriSign actually do some verification of identity before issuing a cert. They have terms of service which prohibit abusive practices and provide a web form on which 3rd parties can rat you out for violating those terms. And the certificates are expensive: hundreds of dollars a year.

It's true that the questions a user needs to ask when presented with a code signing cert are difficult ones involving complex concepts. This was one of the problems the CA/Browser Forum attempted to deal with when designing EV-SSL.

There's talk now that the CA/Browser Forum will now take up code signing certificates, and of this I am much less sanguine.

Prior to EV, if you wanted to check who issued a cert you needed to dig down through several complex dialog boxes. EV certs also set user interface standards for browsers; as part of the green bar you immediately see the name of the company that owns the cert. Click on that name and you immediately see the name of the issuing CA. And a hacker can't just make up their own CA and issue certs, the browser maker (or Microsoft for IE) has to know about the CA and include it in their trusted roots list. This is a pretty good thing.

So code signing certs could benefit from better user interface, but do we really need an industry organization to do that? It's not like OS vendors treat code signing certs in remotely similar ways now. What's really needed is clearer and more prominent treatment of certificates by OS vendors, especially Microsoft. They started making things better in Windows XP SP2, but if they really take code signing certs seriously they need to bring this information out into the user's face and explain it. Microsoft also needs to be diligent about who they allow into the trusted root certificates list.

Conventional code signing certs may be expensive, the Lexus of the cert world, but EV certs are Bentleys. $1500 for one year from VeriSign. Not a lot of money if you're protecting and promoting a popular and valuable brand. But if the CA/Browser Forum intends to bring this sort of pricing structure to the code signing world they're setting up for failure. These $179 certificates don't sell well enough; raising the price can't help.

Lots of security experts deride code signing because it's not perfect. But it's a necessary element of many systems for securing software. If you would ever want to implement a whitelisting system for software, you'd probably need to use code signing for it, for example. Code signing is widely used by mobile networks to control what code gets on to phones. This market needs to be made more accessible.

Editor's Note: This story has been corrected to make clear that the malware in the attack was signed with a standard Comodo code signing certificate which was purchased at standard price, and was revoked when Comodo determined that it had been abused

Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.

For insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer's blog Cheap Hack

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